USGrant
-
Posts
100 -
Joined
-
Last visited
Never
Posts posted by USGrant
-
-
<BLOCKQUOTE>quote:</font><HR>Originally posted by Madmatt:
Now this even more troubling as I have heard from several people in email that the new drivers ARE working for people. Okay, I see what we can drum up from 3Dfx on this once again.
<HR></BLOCKQUOTE>
I installed DirectX 8 tonight and was not able to reproduce the problem after a half-hour of fooling around with a saved Chambois scenario. Perhaps DX8 plus Voodoo 1.06 fixed it.
I'll report any future probems.
------------------
USGrant
When the game is over, the kings and pawns go in the same box. - Old Italian Saying
-
<BLOCKQUOTE>quote:</font><HR>Originally posted by Madmatt:
As a side note, did you happen to adjust the AGP Aperture setting in your Bios? That fixes an unrelated issue with another brand of video card but I am wondering if it might not work with this one as well. People have had luck with both 16 and even 8 megs as the setting.
<HR></BLOCKQUOTE>
No AGP at all on my system, it is PCI only, hence the Voodoo 3 2000 PCI. I'll experiment some this week and post any conclusions I get here.
Oh, and I misstyped, I have a Pentium 233 MMX, not P3 233.
------------------
USGrant
When the game is over, the kings and pawns go in the same box. - Old Italian Saying
-
Bumping this up to confirm that it is NOT fixed with the new Voodoo3 1.06 drivers.
Running a P3 MMX 233 mhz, Voodoo 3 2000 PCI. Whiteout on Chambois after a couple of turns. Seems to be exacerbated by esc to desktop and back.
BTS, could you get back with 3dfx on this?
------------------
USGrant
When the game is over, the kings and pawns go in the same box. - Old Italian Saying
-
I would be thrilled if someone would do both with a high-rez and low-rez compilation. I have a fairly low-end system and have had to fall back to low-rez.
I just got done reinstalling the original bmps and reapplying only low-rez mods. When I first started adding mods I didn't worry about high vs. low because I did not notice significant slowdowns. As they were incrementally added things got slower and slower. I'm pretty much back to just gridded velvet grass and the low-rez vehicles.
I'm not suggesting that you go beyond your offer and do this, but rather floating the idea for anyone that feels motivated.
------------------
USGrant
When the game is over, the kings and pawns go in the same box. - Old Italian Saying
-
<BLOCKQUOTE>quote:</font><HR>Originally posted by Germanboy:
I think that if passage through the walls is made universal, it will be equally unrealistic as the current system with no passage is, therefore there will be no gain
<HR></BLOCKQUOTE>
I guess I disagree. I think that forcing troops to run into the street 6 times a block is a worse realism compromise than allowing them to advance within the modeled row of buildings. Again, I think allowing movement "through" abutted buildings would model a host of micro-terrain that is not represented (gardens, roofs, basements, alleys less than 20 ft across, exterior stairwells).
All arguments about "solid walls" were invalidated by BTS when they decided to model buildings without specific doors and windows (which I have no problem with at this scale - this isn't Sniper!).
------------------
USGrant
When the game is over, the kings and pawns go in the same box. - Old Italian Saying
-
<BLOCKQUOTE>quote:</font><HR>Originally posted by chrisl:
Use view #5, and zoom (with the square brackets) if you need better resolution. This doesn't answer your other question, but should reduce your problems with placement.
<HR></BLOCKQUOTE>
Thanks, I'll try that. View #5 always seemed to be just the wrong scale for whatever I was trying to do at the time, and I have tried is so infrequently that I never connected the zoom feature with it.
------------------
USGrant
When the game is over, the kings and pawns go in the same box. - Old Italian Saying
-
<BLOCKQUOTE>quote:</font><HR>Originally posted by RMC:
MA,
What I am curious about is the bit of coding that makes the rule that buildings that are adjacent automatically have to have an inpenetrable wall between them. This deprives a scenario designer from making large buildings in shapes other than squares that can be considered a single building. It is always gonna be several buildings stuck together to try an look like one big one. I recognize that there will be many cases where you would want to have the buildings separate to simulate rowhouses or whatever. But we can't do large factories or any other building that is not a variation on the rowhouse. <HR></BLOCKQUOTE>
I'm bumping this back up looking for a response from BTS on the adjacent building coding issue. I just got done playing the "A Walk in Paris" scenario and grudgingly came to the conclusion that CMBO really does not work too well for urban combat.
I've learned to live with the catastrophic destruction model of buildings and the difficulty of selecting locations inside buildings (on my low-end system things get very jumpy when placing waypoints in buildings; and forget about moving an in-building waypoint, it will jump out of the building and won't go back in - conversely, I cannot seem to ever move a waypoint into a bulding that was accidently or on purpose place outside). However, forcing troops to run into the street in urban environments as they advance down blocks just doesn't seem right according to my readings and impressions. I did a tiny bit or research and found the following article which confirms my unease about the current movement algorithms http://147.238.100.101/dtdd/armormag/nd99/6casey99.pdf The author paraphrases and quotes the U.S. Field Manual FM31-50 which instructs:
At the squad level, soldiers were cautioned
to avoid moving on streets as
“they are usually well covered by enemy
fire.”21 Instead, it was preferable to move
through buildings, over rooftops, and
through backyards. Blasting entry holes
in walls with explosives was preferable to
entering through doorways and windows
that would be covered by the enemy
within the building. In general, soldiers
were instructed to enter the building from
as high as possible and fight downward to
drive the enemy into the street where he
could be killed by supporting forces.22
I think, given the abstractions already included in the game, that allowing movement directly from one adjacent building to another would be a reasonable representation of the preceeding. It would also allow representation of large buildings, and model the small scale terrain (gardens, alleys, rooftops, exterior stairs) not depicted in the game.
I wonder if changing the coding to allow movement between adjacent buildings, perhaps with an extra delay, is feasible?
BTS?
------------------
USGrant
When the game is over, the kings and pawns go in the same box. - Old Italian Saying
[This message has been edited by USGrant (edited 11-19-2000).]
-
About the only true bugs that appear to remain are a problem with the scores in operations, a potential problem with calculating hull-down positions, and an itermitent problem with spotting ambush markers. Also, BTS themselves have called the off-road speed of wheeled vehicles a bug.
Presumable these will all be addressed in 1.06, though BTS has not confirmed what they are working on for 1.06 other than TCP/IP and wheeled off-road speeds.
------------------
USGrant
When the game is over, the kings and pawns go in the same box. - Old Italian Saying
-
TCP/IP, presumably, but what about:
Hull Down Bug
Operation Scoring Bug
Wheeled off-road movement
Other cool stuff...
There have been a number of threads about this, but few BTS answers other than add-hoc comments.
------------------
USGrant
When the game is over, the kings and pawns go in the same box. - Old Italian Saying
-
Ditto, and please work it into TCP/IP while you are at it. Thanks.
------------------
USGrant
When the game is over, the kings and pawns go in the same box. - Old Italian Saying
-
I came across mine in a magazine just a couple of weeks ago and thought it fit games, life, and ubertanks very well.
------------------
USGrant
When the game is over, the kings and pawns go in the same box. - Old Italian Saying
-
In any game that lets you pick parameters for a random battle I prefer that the previous pick simply stick. If you played "allow human" in a game, that is what would show up until you changed it.
------------------
USGrant
When the game is over, the kings and pawns go in the same box.
-
Check out TGN's TOAW scenario design section for some nice OOB/TO&E info and links:
http://toaw.thegamers.net/toaw_design_frameset.html
The maps links are kind of interesting too, though generally too large-scale for CM use.
OT/ The 1.03 patch for TOAW/CW came out yesterday.
------------------
USGrant
When the game is over, the kings and pawns go in the same box.
-
<BLOCKQUOTE>quote:</font><HR>Originally posted by Big Time Software:
More details later, but for now take heart that turn swapping will be much quicker for TCP/IP games than PBEM. Not sure if this can be retrofitted into PBEM, but if it can it will probably happen for CM2.
Steve<HR></BLOCKQUOTE>
Cool, I can't wait and thanks for the reply.
------------------
USGrant
When the game is over, the kings and pawns go in the same box.
-
If I had to have just one it would be Esposito's "West Point Atlas of American Wars"
His newly reprinted "A Military History and Atlas of the Napoleonic Wars" is on my wish list at Amazon.com. I borrowed it and Chandler's "Campaigns of Napoleon" from a wargaming buddy once and loved both. I never should have returned them...
Old Persian Proverb that I learned from a not-so-old Iranian:
If you loan out a book, cut off your hand;
If you borrow a book and return it, cut off both hands.
I'm sure it is more poetic in Farsi.
------------------
USGrant
-
<BLOCKQUOTE>quote:</font><HR>Originally posted by Big Time Software:
Hey,
Inspite of initial delays due to the first batch of patches and poorly documented APIs, things are going very well.
At the moment all the underlying technology needed is in there and working well. This means establishing connections, handling dropped players, etc. Preliminary real data swapping (i.e. a turn and not just test packets) is in and working.
...clip...
Steve<HR></BLOCKQUOTE>
A while back I asked a question about the "lag" in TCP/IP. I don't mean ping times, but rather the fact that the current data structure generates film files that typically run anywhere from 100k to 1mb. Playing by email with both players online can involve 20+ mins. per turn of just uploading and downloading over dialup connections. This heavy load of data transfer after both players hit the GO button could be a real drag in TCP/IP.
So how is TCP/IP looking wrt this issue? Are you implementing an approach that reduces that the data transfer load, perhaps by designating one player a host?
-
I also use the a, b, c convention as in:
descriptivename 01a.txt
descriptivename 01b.txt
descriptivename 01c.txt
descriptivename 02a.txt
etc.
All you have to do is backspace one to three times and type in the new ending, but you can still find stuff by turn if you desire.
-
Well I grew up in Harrisburg and my regular PBEM opponent is still there. I'm in Knoxville TN now, but if you are doing PBEM count me in to represent Central PA (high water mark of the Confederacy you know!).
-
Well, today I asked George Patton how he spent his points in his last QB (you can do that up here). He replied "What is points and what is a QB?"
My point is that points have nothing to do with "realism" but rather are a GAMEY balancing mechanism, primarily for QBs. The various physical models in the game to a large extent represent realism. IMHO, discussions of rarity, material availability, etc. are not really relevant to battles on the scale of CM.
I vote for the following:
1. Continue to tweak the physical models as flaws are discovered (as Steve and Charles have indicated that they will do with wheeled vehicles spotting at fast speed off-road).
and
2. Modify the mysterious-point-value-equation-that-only-Steve-and-Charles-know by adding a unit specific factor (some might call it G for gaminess adjustment, others might prefer PB for play-balance adjustment)to account for all of the factors not in THE EQUATION. G or P would be assigned at the discretion of the designers, and would probably be 0 for most units and could even be negative.
So:
Points = (THE EQUATION) + PB
This would allow BTS the discretion to, after digesting the various AARs, add 5 or 10 points to MG Jeeps (if necessary after the physics tweaks), and subtract 10 or 20 points from Shermans.
I think this would work better than tweaking the whole scale because I also think compressing the bottom of the scale will create more inforseen problems than it will solve.
------------------
USGrant
-
Count me in for TCP/IP.
------------------
USGrant
-
The discussions in this thread are getting a little confused (and I think I started the problem with an earlier example). A number of posters mention purchase of a single veteran King Tiger vs. so many "normal" tanks.
I think we need to compare like versus like. In other words, IF you ARE going to buy a King Tiger, should it be veteran or regular? The price difference might buy you an extra armored car, but certainly does not get a you second tank.
This goes back to my point about the purchase points being too flat. You cannot buy "hordes" of extra units by dropping down an experience level or two. You can buy a few extra, which don't seem to make up for the compounded advantages of veterans.
All IMHO of course.
------------------
USGrant
-
Buy the veterans.
Recent PBEM games have shown me that veterans will ususally wipe an equal cost force regulars, let alone greens. The compounded effects of better spotting, better shooting, quicker response, and better morale are huge, and not sufficiently accounted for in the point system.
IMO the whole purchase point structure of the game is too "flat". Effectiveness goes up faster than cost, so one should almost always buy fewer of the "best" units available. Best may mean veterans versus regulars, or Panthers versus PzIVs.
------------------
USGrant
-
I can't wait for TCP/IP but I am concerned about how well it will work. With the current data structure of the game, turn files are frequently over 500 kb. Dowloading an email with this attached takes 4 or 5 minutes (over a dialup). Can we expect a 5 minute or more lag between the second player hitting "GO" and the results in TCP/IP? If so this will hurt the appeal of TCP/IP - but is still faster than a half-hour a turn over email and so I will play!
------------------
USGrant
-
I have seen the same thing. In the "Day in the Cav" operation the it said I lost 25 vehicles. I did pretty bad with only about 9 vehicles surviving, but did not lose more vehicles than I ever had!
------------------
USGrant
BTS- What is wrong with the tanks???
in Combat Mission Archive #2 (2000)
Posted
I saw the same behavior playing "Singling Shootout." I targeted infantry in buildings with tanks and got smoke everywhere. Next turn the tanks were showing white target lines.
------------------
USGrant
When the game is over, the kings and pawns go in the same box. - Old Italian Saying