Make Love Not War

Development Update ProGamer just kindly posted a short video of a little showcase he put together demo'ing the latest version of the script being used to move around and shoot from the back of a HEMTT truck. Yeah, I managed to sort out those animation issues I was having last week and created a method for being able to move/shoot around while riding vehicles that don't have a roadway LOD in the model p3d (ie., BIS vanilla vehicles). Seems to work pretty well, although there's a lot more work that needs to be done before this is ready for any sort of wider release. A few more notes: there's still some annoying jitter present which is particularly visible when the truck goes up slopes, but I'm fairly sure that can be fixed. Also, after the success of this test, I'm now confident that - by hook or by crook - it should be possible to script shooting from the interior of vehicles. The biggest obstacle to a solid implementation are animations. I imagine that shooting a rifle from the inside of a car is somewhat of an awkward proposition at best IRL. Trying to replicate that in-game so that it's functional yet still looks and feels realistic is going to be a difficult task, particularly animation-wise. Anyway, don't want to get too bogged down into the details just yet, so for now I'm going to leave the HEMTT and other ground vehicles and move onto testing an implementation for aircraft. Think I'll start with seeing what can be donw with Littlebirds. :)

Didn't know that; thanks for the tip. Oh, for sure! No argument from me. We certainly do need many more commands that allow us to read and modify various physics simulation properties. Even where there are workarounds, they're usually elaborate and cost a lot more CPU resources than having one native SQF command handling the task.

Su-22 attacking ground targets in Syria. Fearless pilot(s) aren't messing around. The sound alone will give you goosebumps. Mod looks lovely, BTW. Awesome textures.

That's not a problem. Just use lineIntersectsWith to check for objects under your feet. Or, better yet, you could start by checking if your unit is at terrain level, and if that returns false proceed to check for any objects that you might be standing on (you could be falling, for instance).

@Sakura_Chan: Pretty much my thoughts as well. It can certainly be done if an emergency situation calls for it, but, like you said, it pretty much means that you're going to have guys sitting on the floor hanging onto tie-down eyelets or whatnot. Although, if Arma doesn't simulate anything along the lines of crew safety, wouldn't that make an increased official cargo capacity less plausible? Something semi-realistic could probably be scripted for such situations. In fact, I'd be willing to give it a go after I get the basics of the attachToWithMovement script hammered out (my animations issue from earlier this week is getting slowly sorted out and I'm hoping to move onto aircraft in the next few days).

Please have a look at page 23 of Boeing's own marketing handbook. That looks like 24 troop seats OR 12 litters. To me the diagram suggests that you can combo litter stations with seat banks, but you can't combine all at the same time. Are we sure that original 24+12 number is even correct?

Shouldn't the addon attempt to simulate the true capabilities and specifications of the real aircraft though? At a certain point it just becomes a fantasy aircraft and we might as well call it the MV-23 Bald Eagle (or some other fishing raptor name). I doubt the real MV-22 can even carry 24 fully equiped soldiers in most conditions - it's probably less a question of cargo space and more a weight limitation issue. And even if you can get off the ground with x number of troops on board, doesn't mean you're going to have much if any flight envelope left for manueverability. So, your practical operational limits are probably going to be even lower. Kind of how the A-10 can theoretically carry 6 (or is it 8?) AGM-65s, but during real operations they almost always only load two. The ideal way to do this would be to allow the aricraft certain max cargo seating and volume capacities (so that you could fit in 32 unarmed passengers without backpacks or gear, for instance), but the amount of weight you carry has a significant impact on perfromance. You'd probably have to define multiple proxy models within the config and switch them in and out dynamically on the fly every time the aircraft is loaded and unloaded, but the effect would be super-cool. Ed: And for those who absolutely, positively need higher operational capacity, we're also going to be getting a C-130.

Reading this and the other threads on this topic, it's pretty clear who has and hasn't had to compete and fend for themselves out in the real world.

You say that like it's a bad thing?

Thank you! That would be very helpful if you could find a possible fix. As for the dev heaven link, do you mean this A3 feedback tracker ticket? Yeah, I'll post a link there, but honestly other than some dev posting a solitary "we thank you for your feedback" copypaste more than half a year back, not much suggests that BIS even read that thread. It's the holidays anyway, so we shouldn't expect to hear anything from BIS till after the new year. @zooloo75: we could start an exclusive drinking club just for arma modders where we can gather around with several bottles of whiskey and retell all our war/sob stories about all those "mods that got away". ;)

I'd say yes' date=' but entitlement doesn't mean much if the X refuses to share. Then X's only real recourse is to hire a lawyer and sue. Don't see BIS adjucating any such disputes; they'd be fools to do so as it would put liability on them. What if X only started working on his contest entry after he got the help? Or maybe he didn't expect to use Y's solution in his entry, but then ended up doing so anyway? We can't expect X to be omniscient either.

Almost undoubtedly. Although they can stand in place on the moving vehicle, currently the AI aren't capable of moving around, so there's not much to test yet. Wondering if that's the problem we're seeing with the LCS rear deck as well? A quick update: was trying to move forward with this script last night by making it work with vanilla BIS vehicles lacking a proper roadway LOD. Got everything working just fine, except for animation problems. At times the RV engine is just too clever in regards to how it plays both character and vehicle animations and doesn't allow you to force or override certain anims when necessary. I'm not a happy camper today. This seems an all too common story for me with Arma editing: I can get so very close with a certain feature, only to be foiled by one, single misbehaving component and/or behaviour which sinks the entire thing. GRRRRR...

Honestly, I'm in quite a bit of disbeleif that I got even this far on such a long standing problem. Thanks for the kind words. :) Yeah, I discovered the no joins thing myself while creating my invisible roadway LOD objects for BIS vehicles. Thanks for the info. Very useful. I'm off to see if I can sort out some of the issues I was getting with the HEMTT last week. Word of warning, in order to make the current script work with a different object you'll have to go into the 'position.sqf' file in the 'init' folder and fiddle with the player positioning as it's currently hardcorded to work specifically with LCS. Let me know if you run into any problems and we can try and work them out together. EDIT: These guys: intersect' date=' lineIntersects, lineIntersectsWith. Cool. From the video it looks like there was already a solution six years ago? It's frustrating that the devs aren't more communicative about these things. Also' date=' BSim has apparently implemented this feature into VBS3. Quoting from their press release: So, this is clearly possible within the RV engine. Maybe we'll see it officially ported to A3 within the year? Who knows? Yes. The attach/detach logic is specifically hardcoded for the purposes of this basic demonstration at this point. It's not a fully operational script, by any means. Couldn't get it working for the frigate? See my earlier comments above. It won't work! For starters, I'm translating the attached object's position relative to the attachetTo object in 2D right now; for an aircraft I'm going to have to do it in 3D. I will defintely try it all! As for the contest: I don't think this is something for the contest. This is an outstanding technical issue that has frustrated Arma players for years, but I don't think the contest is at all about feats of script engineering. It's about delivering an interesting and unique gameplay experience (and not so much from a military sim standpoint either). Thank you. Yes, curently it works using the onEachFrame command, but the CBA display EH method would also probably work as well. Don't see how it could be done any way other than re-drawing the attached object's position and facing per render frame. Again, thanks for all the encouragment, guys! We'll try and take this as far as the technology allows.

Thanks! Since the vessels would just slide up the ramp without any need for wheel or track animations, driving a CRRC up a moving LHD's well deck ramp should be doable. Friction co-efficient of the surface materials would be the ideal way to bring a boat like that to a stop, but failing that - or if the PhysX somehow interferes with the operation - it wouldn't be terribly hard to script some custom physics functions to handle such events. Don't consider this a promise or anything. Because the RV engine uses a multitude of systems to handle different things, one constantly runs into unexpected behaviours when trying to adapt any given script solution to a differnt situation. So, we can't start counting chickens until an actual working implementation is in place, but I believe this should be possible. Do you - or does anyone else - have an LHD model with a roadway LOD'ed ramp included that I could experiment on? FFAA mod perhaps? Well, the currently released demo is a very quick demonstration, so there's pretty much little else you can do with this specific code other than run around the LCS deck. But, in the more general sense, don't think this script technique would incur any such restrictions. The attached object can be either on the outside or on the inside (like an interior deck) of the attachedTo object, and it shouldn't be a problem to get in and out of an attachedTo vehicle's positions after the attach and detach logic was properly updated. Sure. There's no reason per se that this technique wouldn't work in an MP environment, but the real question is desync and smooth performance. I imagine the first step would be to ensure all attached objects have the same locality as the object they are attached to, so any desync would be visual rather than simulated within the world itself. But I'm a total MP coding noob, so I can't offer much more ATM. Maybe somebody with MP coding experience could chime in?

My pleasure. :) I'll take things as far as I am able! What would you like to see me attempt next? Gnat, do any of you modelling gurus know why the man class falls through the LCS deck, and whether it could potentially be fixed or is this always going to be a problem with models of this size? If it's the latter, I could probably come up with something (ugly and hacky) that works around it. Also, I can't get any of the intersect commands to return the LCS object. Checked through all the available LODs - "FIRE", "VIEW", "GEOM", "IFIRE" - and can't get anything. Again, is this just a WIP problem or a pernament limitation? I ask because one of the easiest and best ways of formulating the logic for determining when to attachToWIthMovement one object ot another is simply checking to see what is directly underneath an unit. In short, if he's standing on top of a vehicle, then we can attach him so that he can ride it. This method currently doesn't work with the LCS. As for why BI hasn't done this yet: to be fair to them, in order to implement a feature like this from their end would require a lot more work. Remember, this is a proof-of-concept; to fully integrate something like this into the game would require that it works for All The Things and in all situations. MP is also a big potential stumbling block. OTOH, maybe BI will look at this script and perhaps realize that such a feature is closer to realization than they previously thought. Hoping this might inspire a dev or two, if you will.

This script could potentially work for man class objects with a Nimitz-sized carrier provided that the carrier could be made to move. I'd be very surprised, however, if somebody was able to create a PhysX enabled carrier of that size. The other - and much more deadly - problem with a moving fleet-sized carrier is the vehicles. Proper functioning of wheeled vehicles would be essential, and I'm not even close to developing a technique that works for those.

Fair enough. No doubt VBS, like any other piece of software, has its faults. Didn't mean to suggest otherwise. And, yes, of course you're much more isolated with VBS as the non-pro community is tiny compared to even a game like Arma. That's a fair and valid point as well. Nevertheless, the key difference is that one product appears to be pushing forward and innovating while the other feels stagnant on some very important fronts. Not that BIS hasn't made strides forward with A3, but since the Alpha release the development process from a feature standpoint has been awfully dry. I'm not even talking about seeing new, wonderful and crazy stuff from BIS either; I'm talking about the team simply finding the time to properly finish off introduced features such as grenade throwing or sea-based operations. Also, don't want to come across like I don't appreciate that BIS and BSim are working from two totally separate pools in terms of financial support from clients. Nevertheless, BIS can't be suffering too badly considering they just threw 500k Euros at the community contest. If they are so hard pressed for resources, then I would have prefered they had spent the money on increasing their programmers' salaries and incentivizing new hires. Think that couse of action would have been much more useful to both players and the modding community in the long run. All this is complete speculation on my part, of course, so please take everything with a healthy dose of salt, but thought it might still be beneficial to share some of my thoughts.

No arguments from me. I agree completely. If the inability of AI to make proper and intelligent use of trenches and underground structures was the hang-up, then why do we still have buildings in A3? The only possible way to approximate dug-in fortifications and positions in Arma is to do what you guys did in ACE and fake them by making them above ground. Iron Front did some pretty nice work using the same technique.

Climate is the deal breaker? Try the fact that Florida is FLat... so very, very flat. And a swamp. Also, you want seasons but don't mind England? :P OK, I think it's more than fair to say that now you are officially teasing us! Not that I'm complaining; these videos are sexy enough that I actually don't mind watching even if I can't touch. :)

Ooh, extremely useful. These are exactly the type of tools we need. Thanks, BIS! :)

If so, VBS has my undivided attention; they are this >< close to getting my money. I'm not sure what the limitations of the simulator's personal edition are going to be, but both as a gamer and an aspiring modder it makes a lot more sense for me to invest, say, $250 into a sim and company that is pushing the tech forward and seems to be in-touch with its (potential) users' wants and needs, rather than spending $30 (a fraction of the money) upfront but then wasting countless hours and massive amounts of psychological capital on trying to wrestle with an extremely limiting SDK (calling SQF and its attendant tools that for lack of a better term). Watching especially this last vid makes me weep for Arma.

Like the idea very much. A feature along these lines whereby AI groups establish a base-of-fire with AR units etc is very much needed. Good thinking.

Hey, Fabrizio: you need to pull the "maxRange" numbers from the AI firemode sub-classes found within the respective weapon class. Try, for instance: getNumber (configFile >> "cfgWeapons" >> _weapon >> "far_optic2" >> "maxRange") Ed: A few examples of some other possible AI firemode classnames: "Single", "FullAuto", "close", "medium","single_far_optics2", etc.. Keep in mind that not all are defined for every weapon.

Cool beans. Don't have time to play iwth it today, but will make sure to check the script out later. Thanks for the release.

Damn. You're probably running out of patience with all this, but maybe try: {_this disableAI _x;} forEach ["TARGET","AUTOTARGET","FSM"]; Other than that, I think it's time to re-create the Star Trek teleporter Arma-syle. :) Thanks for the update.