madrussian

To me, the current ArmA2 system of complete stop to instant full bore sprint to instant complete stop again is about as "clumsy" as it gets! Please BIS, any attempt to model the acceleration from stop to sprint and back would be a vast improvement over what we have currently, regardless of what players may be "expecting" in the short term. If you haven't noticed how abrupt things are currently in ArmA2, setAccTime to slow-motion, go into 3rd person, use free look to view yourself from the side, and start sprinting. The instant you let off the forward key, your character will cease any forward motion. The ridiculous part is, the slow-down animation still plays, even though you aren't moving forward anymore! Looks especially silly in slow-mo. In any event, there's definitely lots of room for improvement with regard to human body acceleration/deceleration (player and AI) in Arma3. Let's hope they get it right. :) This also explains BIS's rational in having two different animation speeds for the same animation. One that you see, and one other players will perceive. It you're not quite sure what I'm talking about, try this: It is quite comical to have a single ArmA2 multiplayer game running side by side on two computers, with two playable men (one you control and the other a stationary spectator). Go into 3rd person, and run around. Although your ground speed is the same on both computers, the animation speed varies greatly between the computer you're controlling the man on, and the spectator computer. What you see is a sped up version of what they see. Move around in a crouch to really see the discrepancy. CfgMovesMaleSdr values relSpeedMin and relSpeedMax control this, I believe. In addition to these adjustable values, we could really use an "animationSpeed" value to simply speed up or slow down the animation speed (different from the "speed" value, which currently affects both speed of animation and ground speed).

I have no problem paying $60 USD or even $100+ for Arma3. But if they go above $50 in a semi-niche market like this they will lose money overall, as many who may be curious simply won't buy it. Less money = less game (inc sequels). So I voted $50, and will buy my two copies as usual.

While trying to solve a locality issue preventing me from using selectPlayer effectively, I happened to stumble upon references to what appears to be three hidden Event Scripts. Many of us are aware of "onPlayerKilled.sqs", "onPlayerRespawnOtherUnit.sqs", and "onPlayerRespawnAsSeagull.sqs", which are very good at... <cough> moving the camera around. Meanwhile, the BIS respawn system works its hidden magic, doing mysterious things like successfully pulling off a functional player takeover to a new unit... that ports identity! And does not lose client player control due to lost locality! And many other exciting and as-of-yet unknowable things! If only we could see inside this crystal ball and unveil the mystical secrets within. OK, got a little excited there. A total of six references can be found inside "UI.pbo" in "config.cpp", related to player death, respawn, and teamswitch (three new in addition to the original three). Apparently, a whopping eight other people on Google found them too. Here are the six scripts: playerKilledScript = "onPlayerKilled.sqs"; playerRespawnScript = "onPlayerRespawn.sqs"; playerRespawnOtherUnitScript = "onPlayerRespawnOtherUnit.sqs"; playerRespawnSeagullScript = "onPlayerRespawnAsSeagull.sqs"; playerResurrectScript = "onPlayerResurrect.sqs"; teamSwitchScript = "onTeamSwitch.sqf"; By my reckoning: "onPlayerRespawn.sqs" must handle "INSTANT" and "BASE" respawns (and probably "BIRD" as well). "onPlayerResurrect.sqs" must handle "GROUP" respawn. "onTeamSwitch.sqf" must handle "SIDE" respawn and player switching via switchableUnits. One can easily do a loadFile or preprocessFile on any of these to check whether or not they actually exist in "mission space" alongside your regular mission directory files. The three regular Event Scripts can be loaded and viewed in-game via a hint. Sadly, the three new and exciting ones do not load via either load command. So what do you guys think? I'm hoping somehow that the filenames have been changed slightly and these are perhaps old references. If that's the case, these virtual files are waiting out there in your mission directory, taunting you with their hidden secrets, waiting for someone to write a quick file scanner in sqf that looks for them. [And then let it run all weekend, scanning away. :D ] Or they are simply hard coded in the game engine. Anyhow, only one way to find out! :) Thoughts?

Awesome! :) Let's hope BI can sort some of this (locality loss in particular) by ArmA3, if not yet for ArmA2. In the mean time, if there really is some sort of workaround they are using in the default scripts (hard-coded or otherwise hidden from us), it would sure be nice to know how they are doing it, as we could start doing it too! (Of course, provided it's all possible via commands available in the command ref)

I use "call compile _str" to convert things back from a string to what they were originally. So you can probably skip the step of having to pull your number back out of the resulting array you end up with while using toArray. You will likely need the format command as well, depending on what you're doing.

OK, not useless, but we both agree it is a serious limitation. Believe me, I have spent hours and hours trying to get client/server units together in one group with server as lead, to no avail. But I keep making progress, so I remain undeterred. PvPscene, you are almost making it sound like you would rather not see into how BIS is performing functional player swap, even if that option was available to you! My friend, we are both on the same team here, along with others in the community who would like to see resolution to this locality issue. Why not be an advocate here towards a shared solution? :)

Well I wouldn't call it "black magic", but BIS certainly has managed to implement a functional player swap (no locality issues, etc), and I for one would like to see how they do it! I firmly believe a functional player swap is not only possible, but can accomplished using only the commands available to us in the command ref. We just need to see how BIS does it. Ran a quick test on the Teamswitch dialog config: _cfg = configFile >> "RscDisplayTeamSwitch" >> "Controls" >> "CA_ButtonViewUnit" >> "onButtonClick"; hint (getText _cfg); sleep 5; _cfg = configFile >> "RscDisplayTeamSwitch" >> "Controls" >> "CA_ButtonContinue" >> "onButtonClick"; hint (getText _cfg); Sure enough, the "onButtonClick" event shows up for the Teamswitch View button, but not the Switch button. Looking inside "RscDisplayTeamSwitch.hpp", we can see how the View button has "onButtonClick" implemented, but the Switch button does not: class CA_ButtonViewUnit : RscIGUIShortcutButton { idc = 32; shortcuts[] = {0x00050000 + 2}; x = 0.414724; y = 0.609076; text = $STR_TEAM_SWITCH_VIEW_UNIT; onButtonClick = "_dummy = [_this, ""CA_TS_ViewUnit""] execVM ""\ca\ui\scripts\TeamSwitch.sqf"" "; }; class CA_ButtonContinue : RscIGUIShortcutButton { idc = 1; shortcuts[] = {0x00050000 + 0, 28, 57, 156}; x = 0.770934; y = 0.609076; default = 1; text = $STR_DISP_SWITCH; }; The Switch button obviously has it's own "onButtonClick" event (which performs the actual player swap), it's just hidden somehow. I wonder if there's a way to hide config info... otherwise events for certain dialog controls may well be hardcoded into the game engine. Agreed. It seems to be like this with all the Event Scripts. We have access to the stuff that just moves the camera around, etc. Meanwhile the useful code is successfully hidden away, just beyond our reach. For the record, I don't really feel like I need to modify the existing death/respawn code. It's easy enough to disable, by keeping respawn="NONE", and dropping a "onPlayerKilled.sqs" file into the mission directory with a simple delay: ~100000000 Turns out that one of these Hidden Event Scripts (or their hardcoded equivalent) will end the mission the moment "onPlayerKilled.sqs" terminates, so keeping this script alive keeps the mission going. In any event... The whole goal of this undertaking, for me anyhow, is a functional player swap, so that I can implement a reasonable "return to play" feature, where a dead player (in deathcam), can take over as a new (and very important here...) different unit. Using selectPlayer alone results in locality issues, which prohibit the selectPlayered client player unit from being in the same group with the server player unit, with server unit as lead. This is a serious limitation! It makes selectPlayer essentially useless in an MP environment, without additional and necessary steps to make selectPlayer work properly. I believe if we could simply see into these Hidden Event Scripts, we could solve the locality issue with selectPlayer. BIS swaps the player without issue in group and side respawn every time we die using these respawn methods. A functional player swap is possible! Alternately BIS could provide one of the following: 1. A new command: forcePlayerLocality 2. A usable selectPlayer 3. A BIS dev drop in and comment 4. Access to the player swapping code (i.e. Even if we cannot modify it, we can still see how it's done.) I and many others would be extremely grateful for any of these solutions. That's in addition to all the gratitude we've already got for all your hard work and the end result... your wonderful games. :)

Thanks twirly. Interesting... somehow apparently I have more code in my "\UI\Scripts\Teamswitch.sqf" than you do, which makes me wonder. I just noticed that all (or pretty much all) the files in the Addons directory are also located in the Common directory. When comparing "Ca.pbo" from one dir to the other, turns out that the one in Addons is bigger, and the one in Common is newer. I kind of assumed that the game loads Common first, and then Addons effectively patches by loading second. Can anyone confirm? Took a closer look inside my "\UI\Scripts\Teamswitch.sqf", and I made a startling discovery. There's a comment in there that directly refers to one of our three hidden event scripts (onTeamSwitch.sqf): //script executed by onTeamSwitch.sqf after unit is switched case "CA_TS_onTeamSwitch": { }; This comment pretty much spells out that "onTeamSwitch.sqf" is indeed doing the functional player swap!!! I'd say we have our smoking gun. :) I also noticed that most of the TeamSwitch dialog buttons are covered in there, including "CA_TS_ViewUnit", but the "Switch" button (the one that actually performs the player swap in-game), is mysteriously missing! If these three Hidden Event scripts really turn out to not exist anywhere in the file structure, then maybe we can take a top down approach in-game. Set respawn = "SIDE", die in game, get the TeamSwitch dialog up, access it via findDisplay 632, and then try to access that "Switch" button and see exactly what it's code does (via copyToClipboard). Worth a try anyhow.

Pretty stumped here and hope someone can help! The trouble is regarding selectPlayer and having two players co-habitate the same group. First off, for those who have yet to attempt the selectPlayer command in MP, let's just say it's... fraught with hazard. The primary complication is that if you selectPlayer to a unit that is not local to your client computer, the takeover will occur but the player will be left with no control over the intended unit. Fortunately, I was able to get selectPlayer working correctly on a MP client by first making the desired unit local to the client, as specified in the selectPlayer notes (via a Game Logic created on the client, which is always local), using this code: _tempGrp = group Loon; ClientLogicGrp = createGroup sideLogic; "Logic" createUnit [[0,0,0], ClientLogicGrp]; [Loon] join ClientLogicGrp; selectPlayer Loon; [Loon] join _tempGrp; Good so far. Client computer has taken over Loon with full control, as expected. Here's where the trouble comes in. At this point, if I join the server player to the group (so the players are together), both players maintain distinct locality (and thus control), provided that the client unit is the group leader, which is good. HOWEVER, as soon as I make the server unit the leader, the client computer loses locality over the client player unit and thus control. :eek: For those interested, I'm working on a Group Linked Respawn system, similar to the one in Ghost Recon 1 MP. Works just like "GROUP" respawn in ArmA2, only when you lose your last unit in one group, you takeover a man in the next group. There's also a death cam and the ability to return to play as a new unit if mission allows (i.e. remaining players find survivors, reinforcements provided upon objective completion, etc). It's going better than I expected (streamlined and user friendly) and I'd like to finish and release it to the community, but for now I've hit this snag. It is absolutely critical to be able to have two players in the same group, with either the server unit or the client unit as group leader after a character takeover. BIS does this routinely with both "GROUP" and "SIDE" respawn, so I know it's 100% possible. Any ideas on how to maintain client unit locality when the server unit takes over as group leader? When there's a will there's a way! Any help is much appreciated! :)

Alright... made some major progress towards solving this (I hope). Managed to get both the selectPlayered client unit and the server unit in the same group... with both players simultaneously as group leader! No loss of control for either player. Each player can command the AI in the group. Yeah, it's kinda strange, but certainly a step in the right direction. :D Also, I uncovered references to some Hidden Event_Scripts. Three new and mysterious files in addition to the three regular event scripts. Here are the new and exciting ones, which I am certain actually execute the working default "GROUP" and "SIDE" unit takeovers: "onPlayerRespawn.sqs" "onPlayerResurrect.sqs" "onTeamSwitch.sqf" (not to be confused with the onTeamSwitch command, which does something after the teamSwitch is complete). If I can find a way to see inside these hidden Event Scripts, I should be able to smite this selectPlayer "lost locality -> lost control" issue in short order. I will not be deterred.

Yes, I'm aware of the identity transfer issue with selectPlayer, and I too hope they address it someday. However, selectPlayer will work just fine for what I'm trying to accomplish despite the identity issue. It's the client losing locality that is the deal-breaker currently. I'm almost certain there is a workaround, as BIS takeovers work 100% as expected. If I could just get one quick look at that BIS player unit takeover code! Does anyone suspect it is indeed hardcoded in the game engine and not in a PBO somewhere? Any way of finding out definitively?

The important thing to re-emphasize here is that BIS are somehow able to perform functional unit takeover without any lost control on client computers (via "group" and "side" respawn). Players on any machine (client or server) routinely takeover as group leader, while other players remain in the same group as subordinates. All the while no one ever loses control! It's not magic. How are they doing it?

Oh the good old days of GR1, 3 groups of 3 men each. Perfect for a nice co-op with you and just a friend or two! Thanks for that thread link twirly. :) I checked it out... Interesting and informative, but not related directly to selectPlayer and locality. So to summarize the issue above: I can get a selectPlayered client player and server player into the same group, with both players maintaining respective locality and thus in control of their respective units. When selectPlayered client player is the group leader and server player is his subordinate... both players retain control of their units. But when server player is made leader and selectPlayered client player is his subordinate... client player's unit locality is magically switched back to the server, resulting in loss of control on the client computer. If only I could see exactly what BIS is doing when they perform a team-switch or a "GROUP" respawn death / subsequent unit takeover. I spent a considerable amount of time pouring over "CA.pbo" contents. Found all the "Event Scripts" related to respawn in there, including "onplayerkilled.sqs", "onPlayerrespawnOtherUnit.sqs", "onPlayerRespawnAsSeagull.sqs", but these don't actually do any player switching. They mostly consist of what the camera does. The selectPlayer or similar (facilitation of character takeover) that BIS is doing is located somewhere else apparently. Anyone know where I might find the BIS code for unit takeover? Certainly it's not hard-coded?!? Alternately, I wonder if there is any way to detect in-game the default code that gets run upon certain events, such as the default "killed" event handler, etc. In any event, I am confident if we can see what BIS is doing to maintain player control during a unit takeover, we can do it too! EDIT: @PvPscene I'd wager that it is indeed possible. Otherwise, how is BIS doing it? :) Regarding my group linked respawn, my goal is to have multiple player lead groups, with "GROUP" respawn style automatic unit takeover and the groups linked in the sense that when you lose the last man in one group, you takeover a unit in another. Also the ability for dead players to "return to play" (from deathcam) when new playable units appears later in the mission, which regular "GROUP" and "SIDE" respawn do not permit. For various reasons, it is important also that the players be allowed in the same group.

Spent that past few hours exploring Taviana and it's capital. This is simply mind-boggling with all the custom buildings, realistic layout, subterranean features, etc, etc, etc! BIS, please put this man to work! Biggest issue I've noticed (aside from the obvious alpha-stage collision detection issues), is all the blue hand-rails next to roads in the capital. They look GREAT and add so much to the atmosphere, but you can't climb over them, causing you to go WAY out of your way to simply cross the street, sometimes forcing you to double back and go all the way around the block. Where-as in real life you could hop them easily. Maybe make them shorter... for gameplay purposes? (Ideally, we'd create a special animation for climbing over something a bit higher like that.) Oh yeah, found the dead guy with the severed head laying on the gurney in the bathroom. Nice! :D

Tweaking the action menu to be a bit more organized is probably fine. Just none of those awful "radial" menus please! (Ya know, the ones from other games that hijack your mouse!)

Let's see... In ArmA series, you can: 1. Mod everything as much or as little as you fancy. 2. Create new units, vehicles, terrains, and other game assets, then share them with the community as addons. 3. Design your own SP and MP missions. Even invent your own original game modes. Yeah, I'd say the entire philosophy of ArmA is completely opposite to what MMOs are all about. Sorry! :)

Greetings. :) A while back I made a discovery about All Unknowns being Enemy, supported by my own testing, and rightfully challenged with evidence provided by others. Since then, I decided to spearhead an effort to understand the mechanics underlying the following: To that end, I've been busy creating a Troop Marker System that shows individual units (footmen and vehicles) on the map and color codes them by side. Kind of like what DAC does (when DAC markers turned on), but more advanced in many ways (using editor markers, fading in and out marks based on criteria if desired, etc). Two of the applicable features for this discussion: "Differentiate Unknowns": When turned on, monitors the status of all Units/Vehics with respect to the player knowing about them (via countUnknown). Units/Vehics show up as their own color by default. When "Differentiate Unknowns" is turned on, Unknown units/vehics turn white. If they are discovered (and no longer register via countUnknown), they turn the appropriate color again. "Hide Non-Knowsabout": When turned on (possible individually for "Friendly", "Enemy", and "Empty"), makes the markers disappear for units/vehics the player does not know about (via knowsAbout). This works with a threshold setting. (I have experimented with both 0.225 and 0 and gotten interesting results). Note the distinction between "Differentiate Unknowns" (which turns things white and back to normal side color) and "Hide Non-Knowsabout" (which makes them disappear and reappear). It all works dynamically. I have spent a tremendous amount of time to ensure there are no bugs in my system, and I do plan on releasing once it's feature-ready, polished, and documented. Here are some of the discoveries I've made so far. Note that I'm running no mods except my Markers mod (just some additional markers in CfgMarkers) and CBA which my system requires. (No reveal command is being called unless occurring within CBA which I think we can rule out 100%): Discoveries related to "Differentiate Unknowns" (with none of this set being based at all on "Hide Non-Knowsabout" just yet): 1. Indeed all starting friendly units/vehics on the players side (except mounted foot units) always show up and remain known (i.e. non-white). Enemy, Civ and Different-Side-But-Friendly units/vehics behave as expected (white when unknown to player, appropriate color when known to player). Again it seems same-side friendlies (aside from mounted foot units) are always known... at least as far as countUnknown is concerned. Updates in RED. 2. AIs in the player group will silently reveal civilians. I had one AI in my group and a gigantic army of Civs (foot units and civilian vehicles) incoming from their starting position across the map behind a bunch of hills. One by one, the civ men and vehics turned from white to yellow, and my AI never said anything. 3. When it's just the player (with no friendly AI in his group or otherwise), and enemy units present, ALL enemy units remain white until the player manually reveals them (via "Reveal target"). Indeed you can sneak up right to the back of an enemy tank facing it the whole time, and no silent reveal will occur. :confused: Only if they fire at you (or perhaps the fire technically hits "near you") will they change to non-white (or again of course by manually revealing them). Conclusion: Silent reveals are a matter of one of two things and nothing else: Player or AI performing a manual reveal on the target -OR- Target firing at the player (either "hit" or "firedNear" event). 4. OK, here's where it gets a bit crazy: AI in other groups of the player's side will silently reveal units to the player (change from white to appropriate color), even if they are across the map. I was pretty shocked by this!!! :eek: That means there is internal revealing going on within ArmA2. I don't recall that in ArmA1 or OFP, but then I never had a marker system at the time to be able to check it. I do know, however that back in OFP, folks went to great lengths to get groups of the same side to reveal units to one another. Apparently, it's all happening automatically now! Now, I thought for a moment it had something to do with the fact I was carrying a radio, so I repeated the test after dropping the radio first. Same result. Units in other groups (on my side) on the other side of the map were silently revealing targets to me. [btw- Tried a similar test with units on a Res side (friendly to my side)... and no silent reveal. So turns out these non-group reveals do not span from one friendly side to another.] 5. Back to AI verbal reveals. After carefully monitoring color changes, turns out there is far more silent revealing going on than verbal revealing. Perhaps by a factor of 10 to 1 or more! :don3: The more I think on it though, it kind of makes sense, because otherwise the player would be overwhelmed by all those calls coming in. 6. I did finally manage to get the AI to verbally reveal unknown friendlies, on a very specific basis. For me, they were all pilots who bailed out. Update: Indeed, it turns out mounted units on the players side (but not in his group) start out as unknown (appearing white). Once they dismount, the newly unmounted unit appears to remain Unknown (white) for a very brief moment, and then they are revealed (and appear non-white), regardless if anyone is there to reveal them. More updates: To further illustrate this, in a short test I just ran, I created 2 units only, the player (alone in his own group), and a same sided flying parashoot completely on the other side of the map. From the start, the parashoot vehicle appears known (non-white) but the man inside the parashoot appears unknown (white). Once the parashoot lands, the parashoot vehicle goes away (as expected) and within moments the (now-unmounted) man appears known (non-white). The issue detailed here and in #1 is that friendly same-side unmounted units and vehicles are considered known, even though the player has no real-world way of knowing about them (across the map, etc). Perhaps though, that is consistent with the automatic shared reveals by same-side friendlies going on in #4. I know it's a lot to take in, but I'm very curious what you all think about these discoveries. I do think we still have a major problem with knowing that Unknowns are really Enemy. Or maybe it's really something like "knowing that Unknowns are Enemy 95%+ of the time". Hopefully this discussion will prove fruitful, providing all of us with a better understanding of these important mechanics. :)

I am really hoping that they add some forests of various sizes... even if they are ficticiuos compared to the real island. Last thing we need is a completely de-forested landscape! :eek:

Funny you mentioned it, ArmA3 description made me think of Abandoned Armies as well! We can only hope for something again so grand.

I really don't think AMD card owners will miss much, as far as playing Arma 3 out of the box goes. Rather, everyone will benefit tremendously from the use of a modern physics engine like PhysX, over the wonky and now decrepit ODE. Indeed, our beloved series has been plagued with terrible physics since the beginning in OFP. For this fact alone, AMD and nVidia card owners alike should rejoice at this announcement, knowing our shared affliction through all these years, will be finally and forever more be banished. Mods are quite another story though. I have a strong feeling that we will being seeing a plethora of mods that take full advantage of the new hardware acceleration capability, and it will all be simply mind blowing! :eek: In any event, those concerned have a full year to plan ahead and join the dark side, before the mighty power gets unleashed. :D EDIT: Well you can't turn on hardware accelerated physics without the hardware, now can you?!? EDIT2: Titles like Mafia 2 have that "hardware acceleration" option, which drastically increases the amount of physics going on, and only video cards with that capability can currently handle it. So yeah, I think ArmA3 out of the box needs to accommodate users with and without nVidia cards with this capability. But hopefully, ArmA3 will have a similar "hardware acceleration" option, which really cranks things up. Anyway, it's the mods I'm the most excited about! But in the mean time, I really hope we get at least actual crumbling buildings out of the box. Maybe the chunk size can scale or something (where nVidia owners get many more and much smaller chucks, etc, after turning on HA).

I hope they accelerate everything with PhysX. It will all still work just fine on AMD video card with their physics being calculated on CPU. And just think of how powerful CPUs will be in a year. The only difference would be Nvidia owners will get a boost. Looking at the scant list of PhysX titles available today, ArmA3 implementing PhysX is quite a welcome addition for Nvidia card owners. And even if the hardware acceleration is limited to vehicles, isn't everything pretty much a vehicle anyway? Or at least, anything can be built as a "vehicle". Imagine entire buildings built of individual "vehicle" bricks, and then being blown to smithereens, all using the latest in hardware acceleration!

Just made my day! And wow, can't wait for the new PhysX support! :)

While playing around on the excellent looking (and well made) jungle island Razoreniya, I got terribly frustrated by seemingly biotic x-ray vision AI. I thought maybe all I needed to do was sprinkle some default scrubs and weeds in amongst the existing jungle (in the mission area) and see if that helped matters. But no matter how much vegetation I added, I saw no improvement what-so-ever. :confused: So then I brought up Utes, the huge wideopen area at the airstrip. Then I found the scrub/weed that looked like it block AI vision the best, and made several rows of these things that a human absolutely COULD NOT see through. But the x-ray AI could still pick me off like magic, in spite of the vegetation barrier. At this point, I did a mass copy paste and made these scrubs/weeds maybe 20x thicker... a virtual sea of this stuff... and to my shock and horror, again no improvement what-so-ever. :eek: I haven't checked in Oxygen, but I think a number of the scrub and weed items are probably missing View LODs altogether. Can anyone confirm missing View LODs in default ArmA2 scrub/weed objects? IMO, most of the time in ArmA2, AI vision seems somewhat plausible, but when it comes to woods and jungle, sometimes it's just not fun. (btw- I have messed around with the various AI settings, including "spotDistance" and "spotTime"... there's obviously something else going on.) What do you guys think? Do we need some kind of Durg's for ArmA2?

Trying not to get overly excited here, but I still think this is the cover for Ep2. So what scenario would involve the "Seattle & the surrounding area" -and- "South East Asia" terrains? Well, WW3 of course! There are plenty of totally realistic and chilling ways it could go down. Internal nuke attack on numerous American cities (ala Jericho)? Just look how we responded after 9/11 and extrapolate exponentially from there. Two years after Peak Oil and the ensuing aftermath? Do you think the US will sit idly by starved of energy, when other countries control the majority of the world's oil? Or how about the current war in the Middle East continuing to escalate and spiraling totally out of control? Unnerving and all to possible, to say the least. Yes there are plenty of alarming real-world scenarios we could end up with the Chinese invasion of North America. Perhaps the early (or late?) stages of the war play out in the jungles and cities of SE Asia. And just think of the enormous population advantage China would bring to the table. My fingers are still crossed. My thinking is that BIS are just using preliminary versions of the first built up terrain for their elaborate and entertaining April ruse. ;) Or... Maybe it really is a sim about a family struggling to make ends meet in the helicopter business? Well, I suppose I wouldn't rule that out either... :eek: In any event, my money is with BIS, as I'm certain they could actually pull it off.

I hope for nothing more and nothing less than a completely enterable and destroyable Seattle. And then the community will go totally nuts and various American cities will go pop, pop, pop, popping up all over the place. And if BIS throws in a Chinese army I will not complain. :D