aka_tom_w

in the documentaries they are also refered to as the d-boys -tom w The Mr. T quotes ARE Funny "Now come 'on over here BOY and let me ....." (al a Eddie Murphy!) (sorry)

I could be wrong be even the dongle is not fool proof I don't know of any games out there that use dongles but there are other software titles that require dongles and EVEN that does not prevent me from finding a downloadable cracked version of the software to download (illegally of course) and install without the dongle. A dongled vesion of the game for the Mac might never be cracked because there is very little demand, but I would guess even with a dongle the PC version would be cracked and available for illegal download in all the usual places in a form that would run without the dongle. I could be wrong but I don't think dongles are as secure or fool proof as some folks he might think. -tom w [ September 12, 2005, 07:14 PM: Message edited by: aka_tom_w ]

Which opinion? What normal consent? sorry I did not understand the post of the comment -tom w

WW II something This is as good a guess as any.... -tom w [ September 12, 2005, 12:02 PM: Message edited by: aka_tom_w ]

Remember Steve said: "We haven't decided yet. The problem is one of consistency." this is a fairly big challenge and it would be easier to do nothing then try to make the management of the wounded more realistic. We ought not to expect too much for the first release. -tom w

I support the AI vs AI option completely C vs. C has my vote. -tom w

I am under the impression that might change in CMx2 -tom w

havok news from sept 2000 Havok GDK 1.2 Features: Havok provides an underlying rigid body simulator and a toolkit for higher-level access layered on top. Havok's constraint system is weak compared to the other libraries, supporting only spherical joints and point-to-path. The collision subsystem is full-featured, supporting simple collision volumes as well as convex hulls and true concave objects. A number of contact-solver friction types are included. In addition to basic rigid body dynamics, the system simulates soft body objects (such as blobs and cloth) and particles, as well as a simple fluid model; however, we didn't test these features and can't vouch for their completeness. Documentation: Havok provides a nice set of documentation along with updates on Havok's web site. While not as thorough as MathEngine's documentation, the documents were useful. There were a few minor consistency problems with function names and terms. There is a great variety of well-documented examples of various levels of complexity. The underlying simulator API is not as well documented. Ease of use: The Havok GDK toolkit is very easy to use, with the code organized in an easy to understand class hierarchy. The system provides helper utilities for common math functions. The underlying simulation API seems slightly more difficult to use and not quite as completely exposed as MathEngine's, but is more complete because of the advanced collision detector. Production: Because the system provides a plug-in for 3D Studio Max, artists can easily start using it. They can create models with boundary volumes and run them in the simulation without programmer involvement. Another nice feature allows you to dump the state of the objects in the simulation at any point to a file to reload later or examine for debugging purposes. When trying to debug a physics-heavy game, features like this are very useful. The library is available for the PC, Macintosh, and Playstation 2 platforms. Havok does not license the engine source code, though they will discuss full source-level needs individually. Dynamically controlled objects in a scene in Havok. Integration: Havok breaks the package up into several libraries. While it may be possible to leave out unused portions, they are very tightly integrated. This makes programming easier at the expense of modularity. Input and feedback: Input to the simulation is through "action" classes that are called back during integration, and through a complete set of access functions on the bodies. Because the constraint system only supports one type of constraint, there are no constraint actuator functions. The Havok GDK provides a complete set of event callbacks and access functions to determine what is happening inside the simulator. Cost: The Havok 3D Studio Max plug-in is $495 per seat with multi-seat discounts available. The Havok GDK is available for $65,000 to $75,000 per title without royalties. Royalty pricing and other pricing options are available on an individual basis. Technical support: Like MathEngine, the Havok web site has a developers' forum for discussion of the toolkits. Technical support was very good, but again, it was not attained anonymously.

Ok OK sorry this post is NOT CMx2 specific but it does have to do with the state of the union in Mac Games and that Damn Havok physics middle wear game engine code havok wants HARD cash to offer the Mac Code for games on the MAC Quote: State of the Game - Wreaking Havok May 6, 2005 | Tuncer Deniz "If you've owned a Mac for as long as I have (20 years to be exact), you know that being a Mac gamer can be challenging at times. We've had our ups and downs over the years but recently, especially in the last few years, things have been looking pretty good for Mac gaming. Apple is selling a ton of iPods and Macs and game publishers are cranking out as many games as possible. But as good as things have gotten, major bumps along the road have appeared. One that has crept up recently has been the discussion of many Mac gamers and developers alike. How bad is this bump? Well, let me put it this way. Today's second biggest threat to a healthy Mac gaming market is Havok (piracy, in case you were wondering, is the first), the physics game engine used by popular games such as Medal of Honor: Pacific Assault, Halo 2, and oh yes, Half-Life 2. In at least a few cases, a few Mac ports have been shelved because of a lack of a Mac version of Havok. Ever wonder why Deus Ex 2 never made it to the Mac? Havok. To make matters worse, upcoming games such as Age of Empires III and HellGate and possibly dozens of other games will be using Havok. It takes no genius to see that the Havok problem is now dire. So, what exactly is said problem? Why isn't Havok available for the Mac? As you might expect, it comes down to money. According to industry sources, the folks at Havok want a six figure dollar amount for Havok Mac. The issue, of course, is that there's no way any Mac game publisher could afford this, especially when you consider that the Mac publisher has to pay a PC publisher the rights for a game. Imagine having to pay $50,000 for the Mac rights to a title, then having to turn around and pay $150,000 just to have Havok on the Mac (my dollar figures are just examples, folks, I don't know the actual numbers). Ok, now here's the worst part of it. According to my sources, the Havok code is already available on the Mac. That's right. It's pretty much ready to go. Havok just needs to get paid. The issue at hand, it seems, is the amount of money Havok wants for their precious physics code. With the Mac gaining popularity, it seems to me that companies such as Havok and GameSpy are trying to take advantage of the situation by raising their prices to such astronomical levels that just don't make sense. Would you charge $100 to feed one dog or $5 each to feed 100? But as we all know, man is not always rational, especially when it comes to money. Sure, we could just say, "man, those Havok guys are f'ing greedy", but I'm sure in their own little world, and in their own business sense, in order to have Havok on the Mac, they need...no...demand to hear that magical term: "return on investment." But hey, the Mac is cool! You have to let us have Havok! Pfft, no way. Sympathy isn't going to work either. Havok is run by super smart mathematicians and PhD's who are in the business of calculating how much money they can make with their spiffy physics code. Can you blame them for trying? Let us for argument's sake say that Havok won't budge on the price unless someone ponies up the big dough and pays Havok what they want. In today's Mac gaming market where piracy is rampant (well, on all platforms), a publisher like Aspyr can't afford to pay that kind of money for a physics engine. Hmm, ok, who else has gobs of money and billions of dollars in cash? How about Apple? Apple is interested in seeing more Mac gaming titles appear on the Mac, so why not have Apple pick up the bill? Certainly if Apple had thoughts of buying Bungie at one point for a few million dollars a few years back, then they can sure afford a paltry hundred grand to pay for Havok on the Mac. Apple has been deeply involved in getting Havok on the Mac. How deep is something I'll leave up to your imagination. But Apple simply has no business paying for physics engines. This is not a purchase the Board of Directors is going to approve. "You want us to buy a physics engine so that someone like Aspyr can benefit from it?" As much as it might makes sense to you and I, Apple is not in the business of paying every 3rd party developer that comes along just for the sake of having them bring their tools to the Mac." END Quote. there's more at the web link What does this have to do with CMx2 ??? Absolutely nothing as long as Charles is not using the Havok physics engine, AND given the outrageous licensing fee I would bet BFC has NOT licensed the Havok code. Please correct me if I am wrong -tom w [ September 10, 2005, 07:23 PM: Message edited by: aka_tom_w ]

still an interesting thread....

here are a few threads to read relative spotting more recent thread in which Steve talks about Relative spotting [ September 10, 2005, 01:29 PM: Message edited by: aka_tom_w ]

it took a while to learn the UI, but after I learned it I still found it too cumbersome -Steve I suspect this has come up before but I think the same could be said of the Map editor in CMx1. But not the game it self. -tom w

Well yes it is ALL about how they execute and implement Relative Spotting in the UI of CMx2. I am confident it will be GREAT and I am looking forward to playing the DEMO (many months off still) with great anticipation! -tom w

The Colonel Junior Member Member # 17335 posted September 07, 2005 11:21 AM KEEP: 1. I know I'm in the minority on this, but hear me out. I think Borg spotting has to stay. The reason is that a player essentially has "Borg control" over all of his forces. In other words, you can still give orders to a unit that is out of command, albeit with some delay. In reality you may not even know where your own units are or be able to give any orders at all if it is the real-world equivalent of "out of command". But as a player we get a "God's eye view" which is necessary to be able to play the game. Therefore you know exactly where all your own units are and can always communicate with them. Borg spotting is a necessary side effect of this. Imagine how complex it would be if an enemy unit were moving toward your lines. First you have to check each unit to see who has LOS to that unit, like we do now, then you have to somehow determine who is actually seeing it. And if a unit has LOS to the emeny, but doesn't "see" it, what will we do? Would there be a "hey look over there" order? Because if any my units on the map spots an enemy unit, then I as the player have knowledge of that unit. And if I as the player can communicate with any of my units at anytime, then that should include all the current knowledge of the enemy locations. Which means Borg spotting. I know it's not necessarily realistic, but I think the gameplay mechanics would be a disappointment to many if we did away with it. 2. Please keep the flexibility in size of game that can be played, as I like scenarios approaching Division size. Well I am under the asumption the Relative spotting will eliminate the BORG and Borg Spotting. I am hoping this is NOT open for discussion. -tom w

Um... If they can somehow add some extra commands and maybe some extra fidelity to the cover arc order OR something better or more innovative than the old cover arc, that can be used in conjunction with the move/hunt/fast commands then maybe they have found a way to (hopefully) "blend" the SOP's we are looking for into the game without making a whole new interface and SOP mode or screen. I too was looking forward to something like Standard Operating Procedures (orders) that could be issued to tell a unit what to do and exactly how to react in varying circumstances to different types of the enemy threat. oh well -tom w

I could be wrong but I am thinking Modules are NOT upgrades to the title or the game code they are JUST an add-on set of units and "maybe" some new terrain tiles. hence: "Players have to have the same TITLE to play against each other. If they want to play a particular MODULE they both have to have that MODULE, not all of the modules or all the same modules." -Pvt. Ryan followed by: "Pvt. Ryan has it right. You don't need to have to have ALL the same things to play, just whatever is common to the game settings you want to use. At a minmum this is the Title. If you want to play content in a Module then both people need the same one." -Steve -tom w

That may seem too simple and too "harsh" for some players but I LIKE it! Snipers and sharp shooters with Binocs could be the most easily exploited gamey loophole of the whole Relative Spotting paradigm. I hope they play test the HELL out of snipers and relative spotting in general so players don't use snipers like bailed crews in CMBO to gain Relative spotting intel. I agree, I am also hoping they take a long hard look at sharp shooters so they can NOT be exploited for gamey intel gathering/spotting purposes. It might be a good idea to leave their targeting and firing %100 up to the tacAI but as always some players might complain about the lack or control over target selection. I say "Oh Well" to that. -tom w [ September 09, 2005, 07:07 PM: Message edited by: aka_tom_w ]

that's good enough for me Just as long as MG fire causes LOTS of supression that should be close enough to keep most folks happy the MG model in CMAK and CMBB was Much improved over CMBO I figure CMx2 will show some more improvement again. I would say the CMBB and CMAK model for MG supression seemed fairly realistic and well modeled in the first place. LOF and LOS and collision detection for the heavy stuff is what I am far more concerned about. (Tank and anti tank rounds). But thats just me, the lover of GREAT tank battles! -tom w [ September 09, 2005, 04:56 PM: Message edited by: aka_tom_w ]

re: Battle scope and size Battlefront.com Administrator Member # 42 posted September 09, 2005 12:40 AM Yes, AEB and Pvt. Ryan are correct. That is what I have been saying. I have also been saying that we aren't purposefully supporting BN/RGT sized battles in CMx2 any more than we did for CMx1. And since we had zero support for them in CMx1, we have zero support for them in CMx2. That being said, we aren't doing anything special to restrict huge games in CMx2, just like we didn't for CMx1. Basically, whatever you guys manage to do with what we release is your own business BTW, I remember a scenario that Rune did. In fact, it was one of the scenarios that got him the nickname "Evil Rune". It was a massive CMBO scenario called "Battle of the Bulge" or something like that. I think there was a battalion of tanks on each side. Each turn took something like 10 minutes to crunch once the shooting started. My framerate was, oh, at about slideshow rates too. And I had a pretty good system at the time. People that bought CMBB and CMAK only don't remember those days because, even though the core engine is the same the hardware wasn't. Oh, and then there was Rune's massive 101st assault on Berchtesgaden. What a monster that was! Less tanks so better crunch times (tanks SUCK up the CPU cycles), but still far too long for turn crunchings for me to finish. Of course on my current computers it would probably take 30seconds to crunch Steve

OK then at least THAT is settled! -tom w

The post that started this thread off is very interesting and I have read it over more than a few times, but no where in that post does Steve address the variable of "Time to Crunch the turn". No comment on length of time to crunch. If my understanding is correct better collision detection "could" be had at the cost of longer wait times for the crunch, but so far there has been no real discussion of the possibility or option in this thread. Perhaps I am mistaken. (longer crunch times will NOT in fact yield a more high fidelity collision detection model.) -tom w [ September 08, 2005, 05:20 PM: Message edited by: aka_tom_w ]

no one has discussed wait times for the crunch very much. If the game has better collision detection and more high fidelity combat resolution AND better Armour penetration calculations then MOST realtime time games how is it that most turns crunch in under one minute? (if that is true) If this game happened in Real Time is it true to suggest every one minute turn would crunch for 1 Minute? I don't think so Is 1 minute really too long to wait for the crunch? (I don't think so) (no one has really answered that here.) For those of us seeking a more high fidelity collision detection model the wait time for the crunch would have to be longer. BUT how much longer? still wondering -tom w [ September 08, 2005, 04:45 PM: Message edited by: aka_tom_w ]

MOVE TO CONTACT BONE Battlefront.com Administrator Member # 42 posted September 08, 2005 06:36 PM Oh, it gets even better. It is now possible for a unit with a Move to Contact order to not fire. Instead it can creep along, spot something, and be quiet so that it can observe instead of announce to everbody where you are. As with CMx1, the Move to Contact command works best in dense terrain. It gives you a chance to see the other guy before he sees you. In open terrain all it really does is avoid getting closer to the enemy before you figure out what to do. And yes, Thomm is correct... in CMx2 ambushes should be a lot easier to acheive. Part of the whole "slower pace" I've talked about before. The more uncertainty a commander has, the more hesitation and deliberate action instead of instant and hasty moves. And that is a good thing. More tension! Steve tom w comments: OK... So unless it is a clever RUSE the first game is NOT a Napoleonic game! So that is a good start I think ( while it is still speculative) we can also rule out the Civil War for the SAME reasons listed below. -tom w Battlefront.com Administrator Member # 42 posted September 07, 2005 10:46 PM Hi Gordon! Well, if we were to do a Napoleonic game right now we would likely have to dumb down the game quite a bit. Graphics would have to be at much lower resolutions, guys would have very limited autonomous behavior, and so forth. We'd probably have to reduce the terrain resolution too, but that wouldn't be a big deal. On the plus side, there are a lot of calcuations that wouldn't be needed due to the ridged formations and lack of variety in weapons. We might also have to do some sort of "figure = x men" where x is greater than 1. These are all just thoughts about how hardware limitations of today would cause us to change what we are building. Instead, we are looking forward to the day when the game system we're building now can support larger environments without dumbing down the system. And that's the beauty of the CMx2 system... its scalable Steve [ September 08, 2005, 04:49 PM: Message edited by: aka_tom_w ]

rarity and the whole cost structure could be viewed (at least by me) as JUST ANOTHER artifical construct on top of a game system to try to fix an artificial problem caused by the way some folks prefer to play (but that is their choice ) What is the problem? Some people think playing the game means "buying" units to do better then your opponent. The whole concept of "buying" units is an artificial way to try to simulate a WWII battle in CMx1 in the first place (just to set things straight). grr SO what is the whole rarity thing JUST another artificial compromise or set of limitations on top of an artificial cost structure concocted to try to determine victory points. IMHO I know my comment has no creadence or place in this thread because many dedicated gamers LOVE this game because they can buy units and do battle. That's great if that's what you like BUT please don't complain about rarity as though it is part of the problem because for me the problem starts when you think its fun to "buy" units for a battle. And yes if you are wondering I only play double blind scenarios against trusted opponents on pre-build scenario and yes I prefer the historically accurate scenarios the most. (sorry for the "Stick in the mud" post but rarity is not the problem, IMHO, but what do I know, I never buy units for a battle, ever.) Rock on -tom w [ September 07, 2005, 08:16 PM: Message edited by: aka_tom_w ]