madrussian

Just had another thought... If you do indeed choose to wait for ArmA maybe just give us (I can sense Silola's cringe already when he reads this  ) the undocumented, not 100% tested, (dare I say unsupported?) patch with appropriate disclaimers so all your elustrious DAC users will be at least up to date for the time being.  Plus if the next release is indeed for ArmA, at least with the OFP patch DAC for OFP could then be considered "complete"? Playing devils advocate- Maybe doing that would actually cause you more headaches in the future? Just an idea, but it would probably make a lot of DAC users happy anyway.  It would be like Christmas in October!

Greetings, I really like the concept (being big into both CTI and DAC)... and I intend to try this soon when time allows. Â Plus I guess I've never used this particular island... anyhow sounds cool! Quick question for the moment: Â Did you happen to include any measures so that you don't start out right on top of any enemy DAC units? Also, this next is just my own related idea I've been tossing around, in case you are interested: One thing that always bugged me about CTI was that in the beginning, all the towns are occupied (by resistance forces generated upon approach), which is good. Â However, once the towns are taken over by your side (and then later the opposing side, etc), there are often more and more vacant towns. Â This is because each side gradually gets spread out as they accumulate more towns... and of course once a town has been captured by either side, no more generated forces. So, after the initial town grab, the game tends to devolve into a sort of whack a mole experience. Â IMO, from here out, too much of the game is spent recapturing vacant towns. Â DAC sure seems like the answer, and it certainly sounds as though you made good use of it in your mission, through the use of initially placed DAC resistance forces. IMO, the next step could be to include, for lack of a better word, friendly "garrison" forces, that would spawn in towns that are taken over, perhaps once you vacate, thus eliminating all the vacant towns as the game progresses. Â An even better idea might be to have an option to "garrison" your own forces if desired (and perhaps start over back at the base). Over on the DAC thread, (in case you hadn't noticed already) Silola has whipped up a new "DAC_Insert_Group" script (per one of my requests), that might just make this sort of thing possible. Â I'm sure these "garrisons" would add some degree of lag, but with the DAC's group reduction capability, eh, you never know. Â Anyhow, I totally understand if all that's way past the scope of what you're doing. Â Just thought I'd mention it, as you're the first (I've noticed anyways) to release a combined CTI + DAC, which like I said before, is way cool. Can't wait to try out your mission! Â

I say ask yourself how excited you are to continue development prior to ArmA... If it continues to give you satisfaction and enjoyment, then there's your answer! Â Plow forward with the patch!!! Â If the anwser is no for now, then take a well deserved break... surely when ArmA arrives, the passion will then return. Like Kutya said many posts ago, it's your hobby and it should be fun. Â As for us, your ravenous DAC consumers, we'll be here regardless, lurking, chomping at the bit, ready for any new DAC functionality to emerge... then gobble gobble gobble like a pack of hungry Gremlins!!! Â Â Â Â Â Â Â Â Â <- your hungry DAC Gremlins

Thanks Silola for the excellent continued support (not to mention humor)!  The new “DAC_Insert_Group.sqs†script is just what the doctor ordered... I've got helos flying in and dropping off the reinforcements (new groups created using grpnull), which join their DAC allies... very cool. Now, I'd like to also be able to "break out" individual groups from the DAC on command.  Have you considered a "DAC_Remove_Group.sqs" script, which would compliment the insert? From looking at your code, it appears this would be much more involved than the DAC_Insert_Group script (due to the insert simply setting everything up via calls... where as the remove would have to undo all of that on many levels). However, if implemented, the overall impact of this new functionality would be HUGE. For instance DAC removal would allow a DAC group to separate from the DAC (leaving on a temporary hiatus), complete some task (like demolition), and then return to the DAC zone (or a different DAC zone) when desired and reincorporate back into the DAC. In addition, it would be possible to "shift" groups from one DAC zone to another based on evolving circumstances (as determined by the mission designer). Example - This area of the front has withstood multiple attacks, but is about to break.  Although our forces in the east can ill afford to spare the men, nevertheless we must bolster the line here!  To sum things up, IMO the DAC removal functionality described would add a great deal of flexibility and potential to the DAC.  In any event, thanks a million, Silola!  Keep up the good work!

Man Silola, that was quick!!! It’s extremely exciting to see you already had this in the queue.  And the new script has many useful parameters that I had not even contemplated! (i.e. adding them to multiple zones, the last parameter set, etc)  Got to try this tonight after work! It appears adding non-infantry is a bit more difficult to implement  ... do you think we'll see this at some point in the future? In the mean time, I’ve got a few other things I’ve been thinking about. First off, I understand that the DAC currently requires zones to be rectangular and oriented upright (at zero degrees), for technical reasons.  However, given these constraints, it would be nice to be able to create zones with the waypoints in the shape of an oval.  Seems it would be fairly simple to implement, by applying a trig function for ovals that checks distance from the zone center, when the waypoints are chosen (throwing out the ones which do not conform).  So all the waypoints would still fall inside the bounds of the zone.  I wonder if there’s anything I’m not thinking of here? Next, have you considered providing an option to disable using the group lead defined in the unit config for infantry groups, and instead pick the leader from the pool, on a case-bay-case basis?  There are plenty of situations where one might want to randomize the group lead.  Currently when using small group sizes (and the same unit config), you tend to keep seeing the same (leader) unit. Finally a couple of very minor things: DAC currently has many useful error messages (hints) that pop up to let you know when things have gone awry, such as if a necessary dummy is missing.  However, I don’t think there’s an error message for if any of the dummies are killed during initiation.  I personally got stumped on this for a couple of hours the other night.  (My east dummy was drowning in shallow water.  )  In any event, that one might save a few users some frustration. Also, about the issues surrounding not defining more than one DAC zone at the same point… I had been doing this for some time, and was not aware of the impact.  Perhaps an error message to the user would be useful here as well? In any event, thanks for everything… glad to see you re-energized! This is Silola:  This is Silola on DAC:  Any questions?

Wow kutya... you've sure been busy. Â Can't wait to try out the new version. Â In the mean time I've been hammering away at my respawn system. Â Lots more polishing to do, but I haven't forgetten your request to see it. Also, I've been compiling a list of ideas for GDCE Coop, and for these type of dynamic campaigns/missions in general. Â I'll fire it out in a few days once my brain dump is complete (or earlier if you are ready for it.) Oh yeah, did you happen to see my latest post over on the DAC thread? Â Silola is apparently re-energized and is intending to implement an idea of mine that might just have big implications for your work. Well, glad to see you are still in the zone... I for one, can't wait for all the new dynamic stuff that's coming down the pipe!

Thank you Silola and company for your wonderful product!  You have provided the OFP community with what can only be considered as a “Must Haveâ€.  Like ECP and CTI before, your contribution is a triumph of OFP development that is clearly without precedent, and simply unrivaled.  Your documentation and support are purely top notch.  Keep up the good work!!!  I remember the first time I fired up the DAC as if it were yesterday.  As all those markers heaved and oscillated, I got shivers up and down my spine.  Then as the new units started appearing, I lost my breath as my heart skipped a few beats.  Finally, when all those forces started to move about (as if by magic), my jaw about hit the floor as I sat there, shocked, speechless, in a trance-like state.  Before my very eyes, the (already impressive) dynamics of vanilla OFP were multiplied 100 fold!!!  I think I almost had a seizure.  Although I’ve been using the DAC from the beginning (love the docs) and I’ve been following along periodically on this thread, I just took a moment (ok, several hours) re-reading this whole thread in its entirety.  I’m a bit surprised to find that thus far, no one seems to have posed a question I’ve been wondering about for quite a while.  I’ve spent a considerable amount of time looking through your code, and know my way around a bit.  Any chance you could point me in the right direction on something? My understanding is that the current DAC Respawn re-uses existing DAC groups.  Unfortunately, in certain instances, this type of respawn would not be appropriate.  (Example- Suppose if new units were to be flown in on a C130, disembarked, and then and ordered into a DAC zone.) So here’s the question:  How would I go about taking an existing non-DAC group and making it into a DAC group (added to a particular DAC zone) on command, well after DAC initiation has completed? That is, what I intend to do is this: Incorporate an existing completely non-DAC group into a particular DAC zone, at the desired moment (via, say, a new function).  At this point the previously non-DAC group becomes a DAC group (and belongs to a DAC zone, uses DAC waypoints, responds to DAC AI requests, etc.) In short, how to convert a non-DAC group into a DAC group (assigned to a particular zone)? This feature would be extremely useful to all sorts of DAC users, for a number of reasons, but here’s the biggie: It would provide an alternate method of repopulating DAC Zones. With this feature, incoming “Reinforcement†groups added into the DAC could supplement the current “Respawning†groups (already provided by the DAC via the Respawn Camps). The mission designer would recieve the additional functionality to decide upon what new units enter particular DAC zones, when they enter, and from where! In relation, it would also be nice to be able to “break out†a particular group from a DAC zone.  This would allow a DAC group to, for instance, separate from the DAC (leaving on a temporary hiatus), complete some task, and then return to the DAC zone (or a different DAC zone) when desired and reincorporate back into the DAC.  All of this would be up to the mission designer’s behest. I’d even try and write a pair of functions to accomplish this if you could get me started.  Of course I’ll be happy to elaborate on any of this if necessary, as it’s a somewhat complex idea to describe. @all DAC users (who've made it this far... I know, I'm long winded  ) Please chime in if you think this would be a useful feature set for the DAC! Regardless, Silola and others, thanks for everything you’ve done thus far.  We all understand it’s a lot of hard work, and you must know, we appreciate it more than words can describe.  Please know we’re with ya through the highs and the lows.  Take as long as you need.  Like Kutya said, the OFP passion always comes back.  In the mean time… Looking forward to future releases of the DAC!!! MadRussian

I realize my last post was probably a bit hard to follow.  I could use a beer or two right about now as I reread it! Suffice to say, even if my respawn system (or Mapfact’s) does not completely suit your needs there's a good chance we can come up with something that does. A few of my own thoughts on MP coding to help get you going: Start thinking in terms of Client and Server.  What should the Client(s) do… what should the Server do.  You’ve already hit the jackpot with snYpir’s MP tut… it really is a great place to start.  I would recommend rereading it a number of times. If you don’t already have it, you’ll 100% definitely want 2 PC’s on a LAN with separate copies of OFP loaded to get started.  I’m sure there are plenty of folks out there who code MP without that, but it will save you TONS of time. Next, I would probably download a couple of simple MP missions, and spend a descent amount of time figuring out how they work.  Then download Zeus CTI, dePBO it, and do your best to try and figure out how they did everything… this is a great model to work from. If I were you, I’d then go over and pick up COC Network Services version 2.0, which would simplify this conversion process at least ten fold.  (Of course you gotta ask em for permission to use it in any releases, I’m sure, but I’m preaching to the choir).  Start getting familiar with their network commands. The main thing to realize is this... Coding in MP is an order of magnitude more complex than in SP, especially when you've got a complex (not to mention dynamic) system like your own GDCE.  I didn't want to believe it at first, but eventually I had to accept it.   Earlier you mentioned “multiplayer component†I think.  It’s probably wise to think more in terms of starting over from scratch (and re-integrating the majority of your code in phases along the way). Again, all of these are just my own related thoughts based on my experience creating my respawn system, so take em for what their worth.  It definitely won’t be a cakewalk, but I don’t see any reason to believe converting GDCE to multiplayer isn’t doable. One thing I’m extremely excited about is this:  As dynamic as GDCE is currently, just think of the possibilities once it goes multiplayer… like multiple objectives, players going in to rescue other players that went MIA on the last mission, etc, etc, etc!!!

Kutya, Glad to hear you all your enthusiasm!  I’m getting the impression BIG things are in the works.  Apology in advance for the big read: First off, I am a HUGE fan of Mapfact and all their stuff, and I extend them the utmost respect.  Having said that, as far as the Mapfact respawn system goes, my understanding is that it has some limitations, though I’ve can’t confirm these personally as I haven’t tried it out.  Tacrod was apparently using it on Coin2, but had to pull it out.  The killer was that Mapfact respawn does not allow friendly AI units in your squad… it culls them all out upon initiation. That’s not very flexible, IMO.  I would like to be able to play with any number of players (or by myself for that matter), and have the friendly AI filled in accordingly.  I’m also not a huge fan of reviving, as it’s not terribly realistic (although I understand you can probably turn it on and off). So here’s a little more on my Group Linked Respawn system with (integrated death cam and return to play based on mission design), which I am nearing completion on. Have you ever noticed that there is a “Side†respawn option in OFP?  Ever notice that it does not work (and instead works exactly like the “Group†option)?   My overall aim with this effort was to create a functional “Side†respawn. My secondary aim was to avoid entirely any artificialness, such as the standard simple respawn (i.e. opps I died but look, I’ve been reborn!!! ), or the aforementioned revives (i.e. I was grievously wounded and incapacitated moments ago, but luckily a medic came by and stuck me with a syringe, now I'm good to go!!! ), etc.  If you’ve ever played the original Ghost Recon Coop in multiplayer, your pretty close to understanding the way my system works.  Each player leads a group of AI.  As the players are killed, they “respawn†into the bodies of remaining friendly AI units within their own group (similar to the “Group†respawn option).  However, when a player dies and there are no more AI units within his own group, he “respawns†into the bodies of another friendly player’s AI unit.  This continues until only the players remain.  At this point, the next time a player dies he enters a spectator mode.  This system works with units on foot and in any vehicle station (commander, driver, gunner, cargo), and priorities are in place that put the player, upon “respawnâ€, in the most optimal spot given the situation.  (i.e. Player died, replaces AI unit within his group, the gunner in the M1A1 nearby, but because loon was the only unit in the vehicle, put the player into the commander station, so he has access to the entire vehicle without disembarking and remounting, etc) I’ve got all that working, and it works with multiple “respawn setsâ€.  So you can have, for example, a set of four West players (each a group leader of his own AI) that share respawns, and four independent East players (each a group leader of his own AI) that share respawns. I’m nearing completion on the ability for players to “return to playâ€, in the form of “reinforcementsâ€.  The system will be able to handle any number of groups designated as “reinforcements†(well, until you hit the 63 group max per side that is).  The system will likely include options to easily turn on or off certain components as desired.  For example, if you love the reinforcements but don’t like any other respawns, just turn em off.  If you like the respawns within the group, but don’t want any of your friends stealing your loons, simply turn off group-linked sharing.  Also, if there is interest, I could potentially add in revive capability. The system should not introduce any lag during play, due to measures I’ve taken.  For one, I’ve shifted as much of the load as possible to the clients to keep it off the server.  Load is actually something of a misnomer here, because I’ve avoided any ongoing looping scripts and instead made use of event handlers.  As a result, the code only runs when it absolutely needs to.  Applying this system should be a breeze, because I’ve designed it to be virtually plug and play, similar to DAC.  Simply drop in the “Group Linked Respawn†(GLR) folder, add a couple items to the mission in the editor, call the init function, and walah!  Then, whenever desired based upon mission design, call the reinforcements function to add a reinforcements group for a given “respawn setâ€.  Then the appropriate players who are in death cam can return to play. I should emphasize that this system relies on each player being the leader of his respective group.  I actually consider this a feature, as you can split off and surround your enemy more effectively, instead of all the loons just following the single leader. Anyhow, lemme know what you think.  I’ve actually taken a bit of a break from developing this, but any interest will only serve as spur me forward towards release.  In the mean time, I am super excited about the development of multiplayer GDCE!!! -MadRussain

@kutya Great system!  Extremely well polished and executed.  I've been playing your VTE version.  Can't wait to try SAS.  Long live GDCE!!!  Considering the AMAZING potential for the future of your system, have you seriously considered making this MP?  If so, I have some thoughts. Based on my experience, ideally it’s always best to build your system to be MP compatible from the beginning, or convert to MP as soon as possible.  Considering the infinite improvements and additions that are possible for GDCE (like new mission types and even fronts/resupply, etc; i.e. DCG for Il-2 Sturmovik stuff mentioned earlier), every new line of code added makes it that much more difficult to convert to MP. In short, what I’m saying is if you ever want to make the GDCE multiplayer compatible, now is the time!  I’ve spent quite a bit of time looking through your code, and I’m fairly confident that I could eventually take what you have and make it MP.  Eventually is the key word… Due to RL time constraints (as most of us unfortunately have), single-handedly, it would take me a really, really long time.  Based on your last post, looks like you'd like to assemble a team.  If you are interested in converting GDCE to MP, I assume you’d probably want at least a few talented, dedicated folks to help take this on. When one thinks about converting a long duration mission such as GDCE to multiplayer, several design decisions come to mind: What happens to one player if he dies but his fellow players are still trying to complete the objective at hand?  One life only?  That seems a bit harsh considering the long durations we’re talking about.  Does he simply respawn are the base with the option to reinsert and rejoin his player buds?  Seems way too forgiving to me, considering the players could just whittle away at the enemy until objective complete.  As you attempt to find answers, the questions expand and multiply from there.  I’ve put considerable thought into this, and I’d love to share my ideas if you’re interested.  Also (again if you’re interested), my upcoming Group Linked Respawn system (with integrated death cam and return to play based on mission design) may be of use.  Its creation was inspired by GDCE, it’s precursors, and the DAC.  In reality however, although I’ve designed it to be quite versatile and portable, I’m really creating it for this very type of dynamic game play. In any event, congrats on everything you’ve accomplished… GDCE is the future of OFP/ArmA!!!  How bout some dancin bannanas!  Â

As much as I love this mission in SP, it would really rock in MP! Â I tried a bit to make this work in multiplayer (for own purposes) and the big problem I was getting was that server(/client) system would see the wound textures on the zombies but the clients would not. Â Maybe I was doing something wrong... Does anyone know if the zombie mod in general is compatible with multiplayer?

First off, order parts/build new mega-system once we know the release date. Â Then, the day that shiny new ArmA box arrives, I'm gonna: 1. Call in sick, install that puppy, and bade farewell to the outside world for the foreseeable future! 2. Go straight to the editor with an AT unit (or M1A1 if necessary), find the closest destructible building (now that they've confirmed), and blast it to smithereens! Â 3. Check out the new selectPlayer command to see if (as I'm hoping), with that single line, you really can switch player control from one unit to any other seamlessly. Â Used selectively, that little command will open up a world of mission-making possibilities! 4. Fire up OFP on one of my other PCs and run an ArmA/OFP side by side AI foot unit and AI vehicle unit speed comparison. Â I sure hope that haven't sped things up, even a bit... but after seeing some of ArmA gameplay movies, I have my doubts. Â (In terms of realistic real-world-like movement and speed for all units, OFP nailed it.) 5. Confirm coop campaign mode. Â (Last I checked it sorta dropped off the features list... hope I'm wrong.) Â 6. If all goes well, hail the triumph that is ArmA! 7. Launch Single Player Campaign and lose myself for days. Â 8. Once bodily function signals return and scream loudly enough (like bathroom, food, h2o, etc), pry my poor carpel-tunneled hands away and drag my emaciated body from computer. Â Oh, the humanity! Â

I'll have to give EiS a look when (or rather "if") it ever comes out. Â Mafia and H&D2 were both enjoyable, but had their issues. Mafia had the best driving model of any game I've played to date. Â I'm talking about realistic physics, accelleration, and contol. Â The deformable damage your car could take was cool, but they had it adjusted to be way, way too forgiving. In certain parts of the city, you could really get going fast (in certain cars) and use the overpass as a giant ramp, flying through the air for several seconds, and then hit the ground at a tremendous velocity, all of which was very real! Â Now in a similar real world collision, you and your car would be utterly destroyed... But, in Mafia, as long as you ended up with 4 wheels on the ground, you were golden. Â Maybe your bumper got crumpled... a little, but you could drive away into the sunset like nothing happened! Â H&D2 was good, but did not fulfill my expectations. Â However, it did have some good qualities. Â The inventory system and variable speed modes (sneak, walk, run, sprint - limited by endurance and inventory load) were realistic as compared with real life and truley top notch. Â Indeed, the on foot controls were best I've ever seen, and included the ability to climb up onto things... things of variable height at that. Â The one issue here was while prone, you could spin your body just as fast as you could spin the mouse. Â I'm talking about 60 plus revolutions per second here! Â One thing I'll never understand was why they nixed the analog joystick controls in H&D2 and went to inadequate binary driving, after the triumph of Mafia. Â Also, in 3rd person, the fixed crosshair (and thus whatever you were shooting at) were obscured by the players body. Â (Me loves the "floating" 3rd person crosshair of OFP.) Â And imo H&D2 didn't do tank-infantry combat very well... In that arena (as with most others) OFP reings supreme!

I noticed that too when I read the acticle. Â I also would have expected quite a bit more excitement. Â Seems like CGW usually has an adequate perspective on things. Â Not this time though. Â I have to wonder if they will rave about ArmA when it finally comes out and name it their GOTY and then forget again a few years later... that is until Game 2 is released! Â

I'm in heaven! This one has huge implications: expectedDestination I can see a number of revolutionary new user created AI systems being possible due to that little command, with respect to stacking up individual unit orders/priorities. Â i.e. Alright loon, take up that position, no wait, run away from that grenade <BOOM>, ok now back to taking up that position, oh no take cover from that MG that just opened up, OK, he's dead, now back to taking up that position! Sounds like we may already have those sorts of improvements with vanilla ArmA, what with hiding (cover) built into the engine now. But the one I've been waiting for all this time... selectPlayer!!! Â Â Â (and the other related team switch stuff, although selectPlayer appears to be the foundation and the most flexible) I am picturing a D-day mission... as 82nd Airborne parachute in and take out those 88's as quickly as possible... because you are soon going to "switch" and land on the beach as the 1st Infantry Division! And of course the obvious ones: new waypoint and trigger controls enableAI new interface stuff a gazillion other new commands that will just make our lives a little easier, such as getPosASL. Thank you BIS!!! Â

Just read the German magazine “PC Powerplay†write-up (translated). Lots of good info, including AI "fortifying themselves on rooftops"... I hope this means they'll actually take up positions instead of having to be placed up there with disableAI called on them. Regarding helicoptor controls, the reviewer did have one line of complaints I must respectfully oppose: My short answer for the author is... get a joystick.  In this ultimate realistic game of OFP/ArmA, flying a helicoptor is SUPPOSE to be lifelike and challenging.  You should absolutely NEED a joystick to fly them with any precision. I personally spent considerable time learning to juggle all these "helicoptor tasks" effectively in OFP... and I didn't mind this a bit.  Overcoming this "difficulty" was the fun part!  Indeed, I'm quite happy not being spoon fed with simplistic arcade-like Battlefield 2 style controls!  Please don't take any of the "simulation" out of our simulation's controls.

You do have a point... in fact I recall the first time I loaded ECP up, getting a bit queasy to my stomach when those guys bailed out of that burned up T72, on fire and screaming to their deaths... bonechilling, really. Â Hmmm... It would also be cool if we had AI dragging and/or carrying friendly wounded AI out of harms way. Â This would be best integrated into the core game engine, as it would be extremely difficult for a scripter to sync the combined animations (for the two units) and make it look and run like it should. Â I can also see having two men carrying a wounded man on a stretcher, which would add quite a realistic environment to friendly bases. Another realism improvement could be med-evacs (by air or ground) integrated into the core game engine to get those wounded off the battlefield! Â I suppose we may see this last one in Game 2, based on the description of an ongoing war where units are issues orders dynamically based on a number of factors inculding proximity (and in this case if they are med-evac or not).

With respect to injury realism, I like the idea of adding "incapacitating" injuries to the existing system (optional of course). Â In this case, the mortally wounded unit would no longer be functional or even playable, but would go on clinging to life. Once "incapacitated", the unit may flail, quiver, scream, gasp, attempt however futilely to crawl to safety, and/or do anything else you would expect a mortally wounded soldier to do. Â He would go on in this state until he expires or is med-evaced. Â With this level of injury, no game-like instant heal can help him. If the unit were a player, at the moment of "incapacitation", the player would experience the same "death" as he does currently with OFP (and respawn or not depending on the settings, as currently). Â But the incapacitated unit (now controlled by the AI) would remain alive, yet in this death thrall, as described above. Of course, not all injuries would result in incapacitation, and units could still get killed outright or experience varying degrees of lesser injury, as it is now with OFP. This could be scripted but would ideally be incorporated into the game engine. Â It would expend a small amount of additional resource, but would yield a huge payoff in terms of an amped up level of immersion and be well worth it, IMHO anyhow. A vision of Saving Private Ryan comes to mind, in the final battle those two grievously wounded men, feebly dragging their selves along the ground along until they were put out of their misery execution style. Â Indeed, the whole thing would be similar to the burning men in ECP, just taken to a whole new level. Alright, alright... I got a vivid imagination!!! Â

Even if I can move my head independently from the body I would like to have my "box" so I also can move my gun to some degree without moving my body. I agree completely with andersson and feel this is an important topic... We still need the "floating box". Even if the TrackIR will serve the purpose the "floating box" currently serves, it's important to realize that not all players will end up getting a TrackIR. Â (In fact, probably only a relatively small % will.) In 3rd person specifically, this "floating box" feature (unique to OFP) allows the freedom to get a proper view of what your looking/shooting at! In so many other shooters (in 3rd person), the crosshair is FIXED in place and is positioned so close to the player's head that your own head and body obscure your view. Â Just try and shoot (in 3rd person) from a standing or prone position in H&D2! Â Please keep the "floating box" feature, or at a minimum make the position of the crosshair above the player's head in 3rd person an adjustable setting, for those of us who may or may not be getting a TrackIR. In summary, IMO it's important that both of these "settings" be optional: 1. The display of the crosshair itself 2. The "floating box" Whether they are set, (i.e. allowable) on the server or not is another debate. AA is gonna rule! Â