aka_tom_w

I have never used the grid how big is each square? why to some players prefer the gridded look is it used to determine distances? if so what are the dimenisions of each grid? are you refering to this grass? thanks -tom w

Hi Tom Good to see the old relative spotting beast reappear! Your point about the bailed crews is the nub of the whole problem IMO. We all intuitively know that bailed crews couldn't possibly generate battlefield intel at the CM level. As players we shouldn't need or be able to control those crews in any way, nor gain info about enemy forces from them. Does everyone agree with that? (I doubt it, but never mind) That being the case, why should we be able to control and obtain intel from any unit that is totally out of C&C; the lone marksman, the AT team, the half squad and so on? (I know, define totally). Thr sinple fact is we shouldn't. This has nothing to do with suggesting a 'command level' game. It has everything to do with helping to reduce borg spotting, being realistic and historical, to boot. "But what happens if a big shell happens to blow up my company HQ, I won't be able to issue any orders" Of course this occurs all the time doesn't it and if it did then, guess what, you are spot on. You are in the ****! Anyone who has read much around WW11 company/battalion level actions will know that more often than not attacks ground to a halt not because of huge manpower losses (although that could do it) but because of the loss of officers and nco's. Your average WW11 squaddie (I don't care whose army he was in ) was bollixed if deprived of leadership - the few that weren't either got a VC, got dead or both. If you want gamey (and I think a lot do) then field a force of half squads, marksmen, AT teams etc,well in advance of your main force and youv'e got lots of good battlefield intel at very little cost. Just explain to me how that marksman, 500yards ahead, instantly informs his side that he has spotted a tank (that no one else can see)? I really believe we need to alter our thinking on this whole issue. The middle ground that CM treads at the moment, around command control, time delays etc is better than most. The only way it will be improved is if we can accept that we cannot control every single unit, all of the time. Units out of C&C should be like units that are panicked or broken; they will do their own thing and, most of the time that will be little other than defending themselves, until leadership is re-established in one form or another. That is the reality of a WW11 battlefield, like it or lump it. The trick to successful battles will then be holding things together on the C&C front as much as pushing tanks and troops hither and thither. </font>

ok perhaps we can agree to disagree I don't really see it from that perspective "some form of battlefield scavaging), I might want my crews (in instances where they had just spotted [before tank-death] a relatively nearby friendly unit) to join that (e.g.) deplenished squad, arm themselves from the battlefield and be a productive addition to my force. " It is my opinion Steve and BTS will never permit that level of "gameyness" to flourish in CMX2 I think we will be VERY lucky if we can permit vechicle crew members to dismount for recon on foot purposes (ONLY) and then remout their vehicle. It will likely be suggested here that once a vehcile crew has its ride shot out from under it that crew should be next to useless to the player and in an operation should be "saved" for the next battle and in CM battles that are not operations the TAC AI should correctly take TAC AI control over them and save them for the theoretical next battle -tom w [ May 03, 2003, 11:08 AM: Message edited by: aka_tom_w ]

anyone in Canada got theirs yet? :confused: I suspect Canadians will be amongst the LAST to receive them -tom w [ May 03, 2003, 11:08 AM: Message edited by: aka_tom_w ]

Shift T turn off the Trees Shift C will make your units BIGGER What happend to who Shift G will turn on warning labels which is VERY handy at the begining of the battle to tell who is taking fire. Shift B will toggle the unit bases on and off Shift I will remove smoke graphics can't find who is embarked on what vehicle? : Shift V will make all vehicles disappear You should ALWAYS start the battle with warning labels ON this will REALLY help at first contact oh... and another thing this is not just another "video game" it is an historically accurate small unit tacitical WWII combat simulator. EVERY attempt has been made to remove and "gamey" tools that do not add to the REALISM of the game like getting LOS from ANYWHERE to anywhere when you don't have units on the ground that can spot from that location. Please read the comments from the CREATOR in my signature below if this concept is still unclear. good luck in you next combat mission battle simulation. -tom w [ May 03, 2003, 08:24 AM: Message edited by: aka_tom_w ]

thats the only available solution at this time if you want to play CMxx you need a used Mac that will dual boot, NO way around that. That is the only work around, buy a used Mac. :eek: -tom w

Steve Jobs is now totally preoccupied with the Apple Music store and his new online music says service anyway. ($.99 per song available through iTunes 4) I am not sure where the truth is here but since I posted that letter to the mac game developers list server mail list I have been SWAMPED by responses. I have not replied to any but I have posted the most "representative" samples of their thoughts here in this thread. For me the BIG issue is CMAK I am WAY more enthusiastic about the African front and the Med than CMBB (can't understand what anyone (either side) is saying during the battle) BUT it won't run in OSX and there is no work around for the RAVE problem so by the time this game comes out the MAC verision of it will ONLY work on a MAC that will boot into OS 9 and that will mean the latest macs won't run it, and in fact you will need a Mac that is AT LEAST a year OLD (Dual boot) to play the latest game from BTS. :confused: BUT if the Mac market is only equal to or LESS than 10% and if MOST of those folks already have at least a 1 year old computers ANYWAY, then the impact of this issue is probably limited to less than (I would GUESS :confused: :eek: ) 100 customers. oh well -tom w [ May 02, 2003, 11:35 PM: Message edited by: aka_tom_w ]

more of the same " On Wednesday, April 30, 2003, at 07:00 AM, tcw wrote: > The first is for Apple to properly implement the same > RAVE API that OS 9.2.2. had. RAVE is dead. Has been for a long time. Apple made this extremely clear. > So there you have it, another sterling example of how Apple manages > to make the great leap backwards in a boneheaded move some of us deem > worse than scrapping the clone licenses. Although there may be a very small number of developers that wish Apple was keeping RAVE alive, I think it's safe to say that the majority of developers understand that it's a dead-end API, isn't worth putting any resources into and are fully supportive of Apple's decision to adopt OpenGL as the only supported 3D API. Your community's lack of understanding of that doesn't make Apple's decision "boneheaded." They made the correct move. The failure of the developer to adopt a supported API is not Apple's fault either. RAVE was introduced in a time when no clear API winner existed in the market. That has changed completely. The winners are OpenGL and DirectX (on the PC). > We of the CMBB gaming > community in particular and the Mac gaming community at large earnestly > solicit your help in protecting a tiny Mac game developer (so few > left!) > from Apple's dumb moves, in restoring our beloved game to the > functionality it should've had if Apple had only done what it said it > would, Apple never said it would support RAVE forever, and I don't recall them saying they'd support it in OS X. When the decision was made to adopt OpenGL, it was made very clear that OpenGL would be the supported API going forward. In short, you're wasting your time and energy lobbying Apple for RAVE support in OS X. It's not going to happen, period. It shouldn't take a decent programmer long to write a RAVE-compatibility layer for OpenGL. That's the path you should be pursuing, rather than calling Apple stupid and asking for things which are not going to occur. Wade "

I would guess this could be nominated for the most elitest...... :eek: "Dude, I am very sorry to hear your woes however I think you will find that writing a RAVE API wrapper to wrap to OpenGL will take less code then the length of your rant. I am sure there are plenty of people on this list and other who would be willing to support you in every way possible. This is not the time for accusations but the time to get 'the red book' out! good luck. -- be seeing you dazza@home _______________________________________________ mac-games-dev mailing list | mac-games-dev@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/mac-games-dev Do not post admin requests to the list. They will be ignored. "

this guy says the port to Open GL "should" take a day " >The company, now a whole six people, is Battlefront.com >(www.battlefront.com), which created and marketed via the Internet the >revolutionary, 3-D, hybrid turn based wargame Combat Mission: Beyond >Overlord (CMBO), winner of a slew of awards. Battlefront.com, which >does all its development on Macs and then ports for PCs, then followed >up with a new, even more successful game based on an enhanced version of >the same engine, Combat Mission: Barbarossa to Berlin (CMBB) >(www.battlefront.com/index.htm), relying on Apple's statements about >there being full RAVE API support in the as then unreleased OS X. There >was no money or manpower to migrate to Open GL. The shift to Open GL >was set for the new game engine set for debut about two years from now, >CMX2. Here's what happened. Ok here is where you are missing things. If you have any kind of abstracted 3D api layer like you probably should for doing cross platform work. Moving to GL might take you a day. It took only me a few hours to move my engine from RAVE to GL and carbon. -- Email: chrisd@plaidworld.com iChat / AIM: crackbunny@mac.com Buy Art : http://www.starbounce.com Listen to Music: http://www.trance-o-matic.com Play Games: Plaid World Studios http://www.plaidworld.com Learn game programming at http://www.idevgames.com Day job: Software Engineer for http://www.riskwise.com, Part of LexisNexis"

as you can see there is a lot of negativity "On Wed, 30 Apr 2003, tcw wrote: > The situation, bad as it is, has been compounded by Battlefront.com's > recent announcement that special, expanded (better visuals, lots of new > scenarios) retail editions of CMBO and CMBB will be Windows only. Why? > "Known OS X compatibility issues." This will of course further > negatively skew public perception of the Mac for gaming. The sordid > tale (and related driver woes) is here: > The fact that Rave won't be supported in Mac OS X was clear from the start. Die-hard Rave-only developers like Brian Greenstone of Pangea sucessfully switched to OpenGL, and even released early titles for OS X 10.0 (Cro-Mag Rally comes to mind). Which 3D API is the Windows version using? Direct3D? If so, then there must be some sort of abstraction layer for the underlying 3D API. Adding an additional OpenGL backend should be a simple thing. The game graphics look dated anyways, since they're using Rave, they can't add any special support for the features of today's graphics hardware (vertext and pixel shader, etc.). This should make the OpenGL porting task even simpler. Lots of other developer have done this. Apple is not to blame here. The developers clearly made a lot of mistakes. For one, they didn't get involved with the ADC to find out which APIs are going to be supported and which won't. They didn't adopt OS X as a development platform (it's been out for 2 frickin' years!), and they didn't try to find a suitable cross-platform solution,otherwise they would have decided to use OpenGL on Mac & Windows. So I'm not really feeling sorry for them for lost sales. Regards, Andreas"

I am now receive a LOT of replies to the original post I mailed to the apple gamer developers mail list this reply is typical: "LOL! Let's see... In Dec '96 one of our QD3D engineers ported it to use (Conix's) OpenGL in about a week (This was never a "shipping" product). I believe it was Jan of '99 that we announced we were purchasing Conix and embracing the "standard". At WWDC in May of that year (99?) we very plainly stated that QD3D & RAVE would NOT be in Carbon and we that we had no plans to port ether to Mac OS X. Since that time a well implemented open source version of QD3D has been written: <http://www.quesa.org>. I've actively supported that effort as well as been directly involved in the porting of RAVE applications to OpenGL. It just isn't that difficult and in almost all cases performs better that the RAVE versions. (And definitely more cross-platform.) My guesstimate is that the average RAVE application took about a week (5 working days) to port to OpenGL. Granted this was being done by a knowledgeable (of RAVE & OpenGL) engineer so that wouldn't include the OpenGL learning curve. <http://maccentral.macworld.com/gaming/news/9811/09.conix.shtml> <http://maccentral.macworld.com/news/9901/06.conix.shtml> For me OpenGL vs. RAVE was a "no-brainer". But if you want to discuss QD3D... -- Enjoy, George Warner, Mixed Mode Magic Fragment Scientist Apple Developer Technical Support (DTS)"

GREAT Thanks I am looking a buying a used one just like that I just wanted to know if you had that psychadelic graphics problem. I 'm pretty sure there is only one graphics card for the entire run/model line of the 800 mHz TiBook THANKS that would be my dream laptop -tom w

that sounds good thanks are we talking about days, weeks or Months, for the expected release (when its DONE ) of the final 1.03 patch? just curious you know :confused: -tom w

did you run CMBO? or CMBB? Curious? :confused: -tom w

yup this OSX thing is still a problem -tom w

it still looks UGLY has anyone found a work around to this issue yet? -tomw

Good question I don't have one to test on right now. -tom w

Has anyone seen it run? I think (I could be wrong) the 800 mHz TiBook is a dual boot machine. I am considering buying one used. I KNOW the 867 mHz TiBook WON'T run CMBB without the pyschadelic display (unplayable) probably because of the video drivers. Does anyone know anything about the 800 mHz TiBook? What is the FASTEST Mac Laptop that will run CMBB without any problems? Thanks -tom w

If the player orders the tank to button up IT SHOULD STAY BUTTONED that would be logical and make sense to me. THe TacAI should be able to button the tank when it wants to it. If the Tac AI buttoned the tank the TAC AI should be able to unbutton it. BUT the players order to Button Up (Damn it!) SHOULD override all Tac AI orders to unbutton. I find this issue only a minor annoyance and basically if I lose a TC (CC for some here) due to TAC AI error, I just chalk it up to the fog of war (EFOW) or simply "**** Happens", say "oh well" and move on. I can live with it either way. -tom w

um..... the audience on the Mac games developers new groups is not VERY sympathetic. OF course it would be my guess that everyone at Apple says its all an issue for the developer (BTS ) to deal with. notice the posts below here are a few of this mornings replies "The fact that Rave won't be supported in Mac OS X was clear from the start. Die-hard Rave-only developers like Brian Greenstone of Pangea sucessfully switched to OpenGL, and even released early titles for OS X 10.0 (Cro-Mag Rally comes to mind). Which 3D API is the Windows version using? Direct3D? If so, then there must be some sort of abstraction layer for the underlying 3D API. Adding an additional OpenGL backend should be a simple thing. The game graphics look dated anyways, since they're using Rave, they can't add any special support for the features of today's graphics hardware (vertext and pixel shader, etc.). This should make the OpenGL porting task even simpler. Lots of other developer have done this. Apple is not to blame here. The developers clearly made a lot of mistakes. For one, they didn't get involved with the ADC to find out which APIs are going to be supported and which won't. They didn't adopt OS X as a development platform (it's been out for 2 frickin' years!), and they didn't try to find a suitable cross-platform solution,otherwise they would have decided to use OpenGL on Mac & Windows. So I'm not really feeling sorry for them for lost sales. Regards, Andreas AFAIK RAVE on OS X won't happen. RAVE development was dropped way before OS 9 was dropped from the development plan. As RAVE isn't part of the PC development either, I'm surprised it's lasted so long in this project. OpenGL isn't all that nasty to learn and use. Maybe someone would want to do a RAVE to GL conversion API for the RAVE holdouts ? Aaron Fothergill I don't think that this is the place for that. Although I don't think that there is a place for that. Personally I'm glad that Apple has buried Mac OS 9. Even still good luck to you. Perhaps someone else can port or write RAVE for OS X. Long live Apple, Long live Mac OS X, Joshua E Smith" [ April 30, 2003, 09:04 AM: Message edited by: aka_tom_w ]

HI John did you try to send that to Steve.jobs@apple.com? Would you mind if I tried to? Sure you can all laugh but what harm would it do? someone out there must know steve jobs e-mail address? or at least some at Apple who is responsible for games and game developers? no? GREAT letter by the way Excellent work! -tom w

there was a theory once I forget how it went but it was based on minutes per points like 1 minute for every 500 pts of troops? or was it 5 minutes for every 1000 points? who else here can remember it was ONLY a suggestion but what ever it was (the suggestion) it seemed about right to me at the time? :confused: But I can't remember what the suggested guideline was. -tom w

Many thanks for the clarification Matt! We are of course looking forward to the FINAL v1.03 (d? z?) final final patch -tom w

Actually that is how it is supposed to work. HUNT stops to shoot at AFV type targets only AFAIK, and MOVE to CONTACT stops at all contacts. Additionally HUNT will resume if the target first ID'd is destroyed while M.T.C. the vehicle stops until next you give them an order to move or TACai makes the thing move. </font>