Make Love Not War

Development A couple of weeks back ProGamer contacted me asking for help with formulating a feedback ticket requesting an attachToWithMovement type SQF command for A3. Meaning, allow one object to be attached to a second, moving object, yet simultaneously allow for the attached object to move independently on its own impetus. Or, to put it in a more concrete way, allow a soldier to walk about while riding on the inside or on the outside of a moving vehicle. I responded that the best method for ascertaining what might be needed within such a command would be to create a mock-up or proof-of-concept using the tools currently at our disposal. Working off an excellent idea presented earlier this year by JDog (HERE), I quickly wrote up a script attempting to emulate one possible method for implementing such a feature within the game. The results were much more impressive than either myself or ProGamer had anticipated. Script The most recent version of the attachToWithMovement script can be downloaded HERE. Note, you will also need to D/L the WIP PhysX enabled LCS 2 trimaran addon from HERE in order to play the demo mission. As it stands currently, the script allows a player unit to move about and perform all regular actions - ie., walk, run, crawl, shoot, etc. - while riding a moving vehicle which has a properly defined roadway LOD. Furthermore, both the attached and attachedTo objects are still affected by the PhysX component of the engine. So, the effects of wave action and friction, for instance, are automatically handled by the underlying RV engine. The script has also been successfully tested on a land "vehicle", namely a moving shipping container. Although the initial versions of the script were somewhat glitchy when moving over rough terrain, the latest (yet unreleased) builds offer a pretty smooth ride. With further modifications, this should also work for aircraft interiors - such as the cargo bay of a Osprey - but I haven't directly investigated such an application yet. Although I can already predict some of the issues that an airplane would cause, I believe they should be solvable. No guarantees, however, until a working example has been implmented. Limitations Ok, now for the not-so-awesome news. Driving around in land vehicles while attached to another object is extremely problematic. Without getting too deep into the technical details, the primary issue is wheels (the ones contacting the ground and not the one in the driver hands) animations. While a wheeled vehicle can be scripted to move around, say, a ship deck, the RV engine handles vehicle and infantry simulation quite differently. Whereas using the script, the soldier anims will play without any problems, vehicle suspension and wheels rotations does not sync properly to the perceived actions of the two objects. The second big limitation ATM is AI. In short, AI are unable to move around using normal methods. So, giving them a waypoint elsewhere on the ship deck is useless, for instance. Third, roadway LODs need to be defined within the model p3d, and those are missing from most BIS objects. So, you cannot, for instance, ride around on the back of a HEMTT using just this script. Finally, everything so far has been written with SP in mind and without a thought towards MP useability. And one final final caveat: these are the limitations that I am aware of and spring immediately to mind. Who knows what undiscovered issues and bugbears may lurk. Hopefully no unforseen showstoppers. Future The next step in my plan is to try and enable use of this script with BIS native models. In theory, one should be able to attach an invisible roadway LOD to an object so that the roadway is just above the model surface one wants to ride on. I did some preliminary testing of this concept last week and it seemed promising, although there was some unfortunate and unexpected glitchiness, so it remains to be seen whether this will ultimately prove satisfactory. Next, as already mentioned, I would like to attempt an adaptation of this concept for aircraft. After that an attempt to see if AI can be hacked into the script. Off-hand it should be possible, at least in terms of footmobiles, although it's a major undertaking as I expect all the movement, animations (and pathfinding?) would need to be done "by hand" from within the script. Thank You First off, a thank you to JDog for his extremely informative post. Also, mankyle and Gnat for creating and working on the PhysX enabled LCS 2 ship. A quick mention to zooloo75 for some testing and feedback an early build. And, finally, last but not least, ProGamer who provided both the original impetus as well as continued support for this little project. Without his testing, feedback, questions, advice, promotion, passion and tireless encouragement none of this would have happened. Thanks, buddy! He should also be shortly posting some really nice YT vids he made of the script in action.

I have to jump in here and remind you that there was two of us working on Armageddon! Still, your words of support here mean a great deal to me (and super-truite as well, I'm sure). Thank you! And, yes, the mod required overcoming numerous technical challenges on both our parts and it was very gratifying to see the enthusiastic reception from the player community upon release.

The balance is such that you'll probably die a lot, but with the current system of unlimited respawns it shouldn't be impossible. :) The one big, game breaking issue with playing the mission in localhost on your own, however, is that, at thi moment, you are pretty much forced to take a repair specialist. Any other character class is unable to use the tool kit to repair vehicles. We'll probably "fix" this by creating a special, universal Tool Kit item that is available for all classes to use. In fact, at some point in the not to distant future, we're hoping to improve and expand upon the entire vehicle repair process similar to what AGM does. Looking forward to seeing your changes! I hate to say this because everybody is very excited for the volcanoes, but it seems unlikely that we'll be able to get working volcanoes into existing maps - such as Altis - due to performance and engine limitations. It would be possible, however, to create a new terrain just for ArmAGeddon with working volcanoes already built-in - that's an option we are considering. Yeah, that's actually my job really. A proper SP version shouldn't be too much work; we're looking to release an (somewhat larger) update by the end of the month which will hopefully include the SP.

Keeping the data out of the criminals' hands is the stated purpose behind your idea, and yet here you admit that not only would the underground continue to maintain access, but, in fact, they would become the ONLY people with access. You want to punish legit users in order to create a minor inconvenience for the outlaws.

Ebos would create greater damage to the modding community than the problem they are attempting to solve (piracy). Without the ability to learn and build upon the work of others the Arma modding community will largely cease to exist in short order as the barrier of entry for potential newcomers will become far too daunting.

First off, thanks for all the praise and the feedback, guys! Konaba, can you be a bit more specfic as to what is happening when you experience fps lag spikes? Are there any obvious patterns as to when these occur? So, if I understand corrrectly, you disabled just the earthquakes and all the other special effects are active and you're seeing lag spikes?

Many thanks for the rpt log, IHUNTERI. Yeah, we ran into this once or twice during our playtesting, but it was so intermittent that we were unable to replicate the issue properly. Good news is that I know exactly where this is occuring - it's the empty vehicles spawn/caching script - so hopefully we'll be able to track it down soon. Also, for the record, I too consider myself one of the "old grumblers" (although I prefer "miltard" or "milsperg" personally :D), but we thought since this mod was for the contest it was the perfect time to fool around and try something a little different. My future mod plans are a lot more "hardcore", BTW, but not before ArmAGeddon (possibly) gets a lot more crazy in the not to distant future. In any case, great to hear that our fellow "grumblers" are also enjoying the mission!

Lachesis580, thanks for taking the time to try it out on dev build. Yeah, I had a feeling it might be working on stable and not dev. It might very well be an issue they are aware of, but we should probably let BI know that ctrlText is no longer working with HUD elements in dev build before it is migrated over and becomes a pernament fixture within stable. At a glance, I don't see it reported anywhere. Seeing as you are much more familiar with the issue than me, would it be possible for you to create a feedback ticket or post something in this thread? If you do post a ticket let us know back here so we can go and vote (already voted on your original currentGrenade ticket, BTW).

Hey, OK, addon is running and function is there, but it produces following errors: And the SCW_fnc_currentGrenade function itself is returning: [string,""] I'm on dev build 1.35.128059 and loaded only @CurrentGrenade and latest @CBA (1.0.9.140907 RC4) as addons into SP.

How does one launch without this RPT timestamp?

Great idea, but I downloaded from Armaholic and I'm getting: Warning Message: Script CurrentGrenade\580Addons\CurrentGrenade\CurrentGrenade.sqf not found on startup. Seems like you forgot to pack the actual script file into the .pbo? :)

Just had a peek at the code, and currently the whole central isthmus and airport area is generally no higher than 15m which means it gets flooded in 25 minutes at current rates. Starting in the far east, players would almost never make it. We could certainly play with increasing that time to, for instance, 45 minutes, but then that would mean for anybody who did make it to western highlands they could easily forget worrying about the water for another hour or more. Still, there are perhaps other, much more dastardly, solutions to this pacing problem... :D We will certainly have another look into these things! That's not a bad idea. We couldn't use any of the 3rd party revive systems for the contest and certainly didn't have time to write our own, but now it could be something to look into. Could be done, although 10 men is the max number that fit into a Ghosthawk (which is what got the players to Altis followed by a prompt crash upon arrival), so adding slots might be a bit of a credibility stretch. Again, there are probably creative ways around such limitations. ;) Thanks! And thanks for the feedback. :)

Sounds like everybody is enjoying the mission, and, even better from my perspective, there have as of yet been no real reports of bugs! :D Yes, as BadLucky1776 discovered, the addon has to be turned off when not playing the mission or it will flood the island in any other mission you attmept to play. Perhaps BIS will provide us with a setWaterLevel scripting command some day, but for now we create the flood by modifying the maxTide value within the island's config file. Yes! The idea is to grab a helicopter - either find one and fix it up or hijack one from the AI - and escape the island before time runs out and it is completely flooded. So, if you guys were exploring around in a helicopter you had pretty much already won. :) The only thing left to do is fly off past the edge of the map. Although there is a help hint that pops up briefly at the start (just after the intro video snippet plays) that explains the situation and the mission goal, we should probably make things more clear. Perhaps a further explanation within the briefing screen? Or some more help hints popping up when a player enters their first chopper? A title text in the centre of the screen at the beginning screaming: "Get to da choppa!"? Yeah, probably not the latter idea. ;) Also, while we're talking about escaping the island, there are currently plans to introduce boats as another method of egress. The idea being similar to the AI helicopters flying in to extract their teams, there would also be AI boat pickups. But, there's a number of pretty serious technical issues to sort out before this can happen. I will write more about those and other technical aspects and challenges (past, present and future) in an upcoming post. Most probably. If it's the Armadeus server then that is indeed super-truite's. Many thanks! We'll make sure to release an SP version. It really shouldn't be too much of a problem; most of our pain in the making of this mission came from dealing with MP hijinks, so back-porting to SP will hopefully be child's play for us (famous last words ;)). Thanks for the feedback, guys. Don't be shy about reporting bugs and making feature requests. Work on version 1.2 has already started with new fixes, improvements and goodies coming down the pipe soon. But, again, I'll leave that discussion for an upcoming post. ;)

New YT vid: .

Howdy, I do believe super-truite is refering to myself. Admittedly, all these "make this, not that", "do this, don't do that" names can get a little confusing. ;) Currently, super-truite is working on the special effects and other goodies, while I am trying to sort out the underlying scripting framework dealing with spawning, objectives, AI, game logic update, etc.. Right now, my primary goals are: Replayability - ie., a fair bit of randomized and procedurally generated gameplay, such as new starting locations and objectives on every playthrough. Performance - writing various scripts and systems within SQF isn't terribly hard, but writing them so things run fast and smoothly is quite the "challenge" (read: involves a lot of swearing, alcohol and despair). AI - ideally, we want the AI to react to and navigate around the rising water and other hazards, but, as one can imagine, this will be no easy task to script without eating up server resources. Gotta admit, HADES does have a nice ring to it. :)

Didn't realize you were one of the BBE Simulation guys, Christie. Nice work on the terrains!

No, sorry, I must respectfully disagree. You seem to be thinking strictly from an infantry perspective, while I think Arma should be a combined arms simulator. Vehicles - especially aircraft - need room to manuever, so, provided details aren't sacrificed, the bigger the better as far as map size is concerned. Although Chernarus++ sounds sexy, I find the suggestion of a mid to late 20th century historical setting for A4 the most intriguing. Korea or Vietnam perhaps? More than anything, however, I think we need to see more improvements to the base simulation engine. A historical setting may help with that task as the variety and complexity of technologies is reduced the further back one goes in time which in turn should alllow the devs to concentrate more of their efforts upon core functionalities and features.

That's an interesting find, Gnat. Probably some sort of material property setting within the .p3d itself? I recall reports from months ago regarding the helicopters sticking to all surfaces in an unrealistic manner as if super-glued, so I'm thinking heli wheels and skids are simply given some silly high friction co-efficient. Has anyone looked within the model configs? Didn't have any time for Arma this past week, BTW, so no further progress on any of this was made from my end, but I'll be back at it shortly. Ed: Just looked inside one of the helicopter model configs and nothing about friction or physx.

Indeed, it's the holidays and the devs deserve a break. Either way, first I want to take a day or two to investigate this idea of using a proxy vehicle. If that fails, I'm thinking the wisest course of action will be to release a working version of the script implemented to the maximum of my abilities, evaluate the specific engine changes needed to allow the script complete functionality and then present all of this to the devs as one package. I think making requests of them to re-write portions of the game code whilst demonstrating an almost fully functional script solution will make for a much more powerful statement than going at them in a more ad-hoc manner. Another quick thought: although A3 is problematic ATM, I'm pretty confident that a version of this script could be adapted to work in A2 with relative ease. Any interest in such an attempt? Ed: Also, thanks for stopping by, Krem. Yeah, this is pretty exciting. :)

Problem with switchMove is that it switches to the start of the anim passed to the command. There does not appear to be a method to switchMove to a specified frame of an animation, so calling it per frame simply locks the character into the first frame of the passed animation. One has to use playMoveNow instead, but the freefall anim overrides that command. SwitchMove also locks the character's upper torso and prevents both aiming animations and freelook. AttachTo has pretty similar effects in that again it locks the character along with preventing freelook and weapon aiming. The is a problem introduced with Arma 3, as Dsylexci succesfully used AttachTo for his LittleBird addon in A2. Yes, once the unit is attached to the vehicle object by either using attachTo in A2 or setPos'ing to match the vehicle's movement in A3, the next step is to use the keyDown and keyUp display eventhandlers to read keyboard inputs to displace and animate the character accordingly. Most of the trigonometry is trivial; you just have to add up a few vectors. This is how the truck part of the script works; it just fails with aircraft because we lose script control over the animations at altitude. Yeah, the invisible proxy vehicle idea I have also thought of and played around with a bit, but it might be worth another shot. It might be possible to create an invisible proxy vehicle which allows the character to use the full spectrum of his usual animations while inside of it. From there one simply attaches the proxy vehicle to the vehicle being ridden and then steers the proxy around while playing corresponding character animations. I suggested pretty much this idea in a post somewhere on these forums more than a few months back.

Ok, just tested the roadway LOD idea and I don't think it can be applied to this case. If the unit begins by standing on a roadway which is then moved upwards above the 100m ATL mark, then everything functions as normal with the unit able to walk around on the surface and so forth. So far, so good. If the unit becomes detached from the roadway in the slightest, however, he immediately goes into the freefall anim and becomes subsequently stuck there. More crucially from the standpoint of this script, all attempts to use any of the setPos commands on the unit while he is standing on the roadway and > 100m ATL immediately throw him into the freefall anim again. Seeing as all variations of this script are built around the ability to setPos the unit onEachFrame, this line of inquiry appears to be a bit of a dead end.

It's always an option, but we can't depend on it. I'm hoping the community might have some suggestions or ideas that I overlooked. Thanks Sealife! If roadway LODs really do return height 0 then that would probably be the fix I need. I actually played around with this idea yesterday, but it didn't seem to work. As I was trying out a variety of solutions, however, I ended up rushing through this one and it's quite likely I set things up wrong. I will most definitely investigate this further and report back. Thanks again. Edit: Screw showstoppers, the show must go on! ;) Don't worry, I'll definitely release everything that I was able to get working and semi-working, so that even if the script isn't fully functional right now future generations might be able to make use of the knowledge gained. I mean, aircraft do work pretty much as expected provided they stay below 100m ATL.... just a wee limitation is all. :)

Aircraft Regretfully, moving or shooting while onboard aircraft does not appear possible in A3 using the same or similar techniques that I applied to ground vehicles and ships. Using the script with aircraft works as expected without significant problems except for one complete showstopper of a bug. Namely, the game is hardcoded so that any unit which is above 100m ATL and not seated inside of a vehicle (as a proxy) is automatically forced into the freefall animation on every frame. Until I find a way to override this animation the script cannot proceed (in regards to aircraft). Any help and/or suggestions will be very much appreciated.

Excellent rundown, Bad Benson. Sums up my feelings perfectly. Considering BI's current cash flow - primarily thanks to DayZ - there's no better time than the present for a serious house cleaning. More than anything, we need native stackable EHs. Functions such as BIS_fnc_addStackedEventhandler are a step in the right direction, but incomplete and should be considered a stop-gap measure at best.

@Gnat: Good observation; always much appreciated whenever people let me know that they see something weird or otherwise "fishy". Good news regarding the reloads, however. I just tested it and the reloads work without a hitch. Seems like ProGamer just hit reload and started moving backwards during the animation . See anything else that looks strange or unexpected?@Sealife: Leaning - the 'Q' and 'E' keys - is in and works flawlessly. Should have showed that off, huh? :) Stance adjusts, prone and weapon switching are some of the big ones that are not in yet, however. It's mostly a question of sitting down and going through all the animations and adding them to the code, although there will still be a few extra technical issues to sort out such as re-working the collision detection for the prone animations. The other big thing left to implement here is mount and dismount code. I'll release somethig for everybody to play with in a week or two, but there's still so much missing right now that there's no point in wider scale testing yet. Nevertheless, things are looking really good again (inb4 I come back tomorrow with more rage posts crying about why SQF won't let me do this or that :mad:). Thanks for the feedback, guys!