Jump to content

tecumseh

Members
  • Posts

    260
  • Joined

  • Last visited

Posts posted by tecumseh

  1. Originally posted by JasonC:

    Russian tank losses for the whole war are around 100,000, dwarfing all other fronts. The portion of those coming in the period of the Russian offensive is around 3/4.

    and

    Originally posted by JasonC:

    Around a quarter of the Allied AFVs lost were Russian lights destroyed before midwar.

    How many Soviet light AFVs were lost pre-Kursk to get this to work? Must have been a huge number.
  2. Originally posted by KNac:

    Wow, that's great thanks for the links.

    There is any place where I can find a reference map to know where belongs each of those grid references?

    It's a bit diffcult to go just by "The lower the letter of the alphabet, the further north the grid is. The higher the number, the further east.

    "

    Many thanks!

    There's a key for the ukraine/caucasus set here

    http://www.lib.berkeley.edu/EART/x-ussr/ukraine.html

    For others, use these:

    http://mapy.mk.cvut.cz/data/Rusko-Russia/Blank-ost.jpg

    http://mapy.mk.cvut.cz/data/Rusko-Russia/Blank-west.jpg

    [ July 09, 2003, 12:04 AM: Message edited by: tecumseh ]

  3. Originally posted by HarryInk:

    Tecumseh...have you got a tighter ref for that military atlas?

    The military atlas link has been posted a lot:

    http://www.dean.usma.edu/history/dhistorymaps/Atlas%20Page.htm

    Not much detail for EF, but still helpful while reading.

    Also there are additional grids from the EART/x-ussr maps, beyond the ukraine/caucasus ones that are more commonly known. Below are some links, plus Herr Oberst hints he knows more...

    http://sunsite.berkeley.edu/EART/x-ussr/100k/

    http://mapy.mk.cvut.cz/data/Rusko-Russia/Topo%201_100%20000/East%20Russia/

    http://mapy.mk.cvut.cz/data/Rusko-Russia/

    The lower the letter of the alphabet, the further north the grid is. The higher the number, the further east.

    Finally, Herr Oberst has personally scanned some great maps. They are generously available for FTP - check out his recent thread on maps for scenario designers.

  4. For reading Erickson's map-free books I relied on printouts from that excellent online military atlas (at www.dean.usma.edu) and some laser-copies of 1:2.5M soviet maps from the library's Times Comprehensive atlas. Together they folded up into a useful bookmark, and all for free :D

    I also got from the library the Osprey Campaign Series #42 BAGRATION, which looks a bit like a kids book (ie. you'll want to hide it under some big sophisticated novels when approaching the pretty librarian) but it's packed full of photos, maps (incl 3D ones) and a decent text by S. Zaloga.

  5. Originally posted by Martyr:

    Hmm. I read "Split squads don't have direct negative effects on global morale or victory points" to suggest that each split squad no longer lowers global morale slightly during the game. This was always an incentive not to split your squads unless truly necessary, since splitting lots of them would affect global morale quite a bit (and thus affect whatever calculations *it* affects).

    That was just a side effect of the bug. Split squads will still panic quicker than full squads. There are still reasons not to split them.

    The *global* effect on moral from splitting squads was an undesired side effect of the bug that treats the second half of the squad as dead. As was suddenly seeing your percentage victory points change for the worse when a squad was split. That's my take on it anyway..

  6. Originally posted by Martyr:

    Wow--this is a pretty major revision! Would someone explain the remaining downsides of using split squads? Does a split squad get suppressed/panicked faster when coming under fire? (I assume that actual casualties will definitely affect a split squad more, since the lost men are a greater proportion of the unit.)

    I'd love to hear the official reasoning behind this change.

    AFAIK previously splitting a squad of 12 men into two teams of six (for example) would count as six dead soldiers for victory/score/morale purposes. If you rejoined the squad, the error would be corrected. Hence the rule: only split squads that you can rejoin before the game finishes.

    This is just a bug fix. It would not effect the weaker morale of split-squads feature.

    [ April 07, 2003, 08:56 PM: Message edited by: tecumseh ]

  7. Originally posted by sturner:

    The way to lose customers is to piss them off. Basic Business Rules 101.

    AFAIK the card and drivers that are causing the problems are newer than CMBB, so it's not BFC's fault. It would be nice if they fixed it, but I imagine it would take a lot of effort for a small return.

    This issue, together with assorted other mac problems, pressure from work, and a general concern over Apple, has caused me - after 15 years of daily mac use - to sell my mac and buy a PC. I am half ashamed, and half liberated.

    :(:D :eek: :confused:

    [ March 19, 2003, 07:59 PM: Message edited by: tecumseh ]

  8. After an evening of trying various combinations of old ATI drivers and different screen resolutions and different ram settings I have made no ground.

    I know the Radeon 8500 displays CM perfectly, but unfortunately those drivers will not work for the 9000.

    Infact, if anyone is contemplating getting a 9000 Pro for a mac, I advise against it. So far the performance across most games has been SUCKFUL. :(

    EDIT - The 9000 Pro drivers for OS 9 are shyte. But it seems the drivers for OSX are good, particulary the ones included in the 10.2.4 upgrade. That REALLY sucks, because I doubt the OS 9 drivers will ever be updated. And I doubt CM or CMBB will ever be OSX capable.

    [ March 17, 2003, 09:37 PM: Message edited by: tecumseh ]

  9. Originally posted by jbertles:

    warning - computer-dope post...

    Ok, I have a dual chip G4 tower (mac of course) with (according to my system profiler) an NVDA GeForce4MX.

    I tend to run the 17" flat screen at 800x640 (which seemed plenty big for me).

    After searching and reading the downsampling threads, it is still not clear to me whether my beast is downsampling or is just muscling through.

    Any insights?

    All Geforce cards on the mac cause downsampling in CMBB, even the 128MB GF4.

    I'm looking forward to testing this mod tonight...thanks MikeyD

    [ March 09, 2003, 07:21 PM: Message edited by: tecumseh ]

  10. Originally posted by Panzer76:

    Ive searched the forums for an offical answer on this, but found none.

    As it is, it *can* be a bug, but I suspect it is a engine limitation.

    It's definately been posted before. All through CMBO "hulldown" meant lower hull only is protected. I think redwolf started a thread about it...maybe tips and tricks forum? Anyway, it is critical to playing the game well, as you have to look at the upper hull armour ratings very carefully.
  11. Originally posted by gibsonm:

    I can also purchase a ATI Radeon 32Mb AGP card seperately (i.e as an additional expense).

    (good images / effects are preferred - but I don't need to know if the guy has shaved this morning or not)

    Based on that, I'd say stick with the GF2. CMBB looks a bit blurry up close (subtle - most people wouldn't notice) but it displays weather correctly and is an OK card for something you're getting for free.
  12. Originally posted by Mike:

    I never encountered such abuse - what was it? What was the effect?

    The abuse was apon the ass of any player who used few waypoints, and it was inflicted by the gamey, micro-managing player (like me) who used lots of waypoints to control their units better.

    Now a friggin nOOb can select all his units, click advance, and beat me :(

    :D

  13. Thanks Matt. I had simplified the situation too much I guess - "Just don't downsample if the card has 128mb VRAM!!!!" is not as simple as it looks.

    It would be great if there was a command line-style hack to turn downsampling off (like downsample="0"), for screenshots, and people like Michael whose card could probably handle it fine.

    From FPS games I know the more user-controlled graphic options the better, because of the huge spectrum of opinion on what is "optimum"

  14. Originally posted by Strontium Dog:

    Its definitely happening in CMBO on my dual 867 G4 with 32Mb Nvidia MX4. The graphics performance is considerably worse than on my G3 466 with a 32Mb Radeon card and its also acting a little weird in other respects.

    Worse, as in blurry or worse as in slower?

    This is weird because I have seen only perfectly crisp CMBO on some crap cards (2mx, rage pro etc...)

    As to your other problem, yes I have that too. And another you might see is the very slllooooowwww bug when the mouse and the sounds are very slow and the game runs at 1 fps. It's fixed by a restart too.

  15. Originally posted by Schrullenhaft:

    I'm not sure why a small battle would see downsampling on a high VRAM video card, but I believe that Madmatt answered the question as to why the two sets of textures seemed 'downsampled' in the above pic

    Yeah things have got a bit confused coz we hijacked this thread to moan about the mac bug. ;) None of my comments relate to the first post because it's a PC and I know a number of the CMBB default textures are *relatively* lo-res.

    However the first part of your quote above is the crux of our mac problem: downsampling on a high VRAM video card.

    All I want is for CMBB to do this:

    1) determine graphics card being used

    2) is it 16mb or below? Downsampling=full

    3) else, is it 32mb or below? Downsampling=partial

    4) else, downsampling=none

    SIMPLE!! At the moment, mac geforce cards only make it to the first "else", even 128mb ones

    This has nothing to do with drivers! The variable "downsampling" is internal to CMBB.

    I have run a large thread on this in the main forum, including proof and screenshots.

  16. Originally posted by Schrullenhaft:

    The issue is most likely with the video drivers.

    I'm pretty sure it is not. The downsampling is done by CMBB, not the card. It has nothing to do with the card being stressed, because it happens on a flat map with one unit. And - more telling - it doesn't happen in CMBO, even in the biggest scenario. Why? Because BFC introduced it's internal downsampling code in CMBB. It was added to make the game playable on old 32mb (and below) cards.

    Great idea, only BFC didn't include the ability to turn the option off, and didn't properly test it on nvidia cards. Doh. Now we have high spec 128mb cards being treated - by CMBB - like 16mb cards.

    That's a bug, and the bug is in the CMBB routine that determines what card the mac is running and hence how much downsampling to perform.

    Other computer games successfully determine my card (some even display it's name and vram in the options screen), so it can't be that hard.

    [ December 01, 2002, 04:50 PM: Message edited by: tecumseh ]

×
×
  • Create New...