astutavian

[i hope this the right place to talk about this - wasn't sure if I should start a new thread] I'm guessing Arma 4 will have some level of engine overhaul. To me, this is ideally what would happen: Threading model would be redone with a render thread, a master game thread, and then a pool of worker threads. Anything that involves waiting - like disk or network I/O - would be done non-blocking with a prioritized work queue. Threads would never be tied up waiting for I/O - workflows/tasks would be as necessary, but the threads could be doing something else. This is how modern multithreading works. The render thread would never be tied up waiting for game logic. It would only be tied up as necessary to load assets from disk. It would never have to wait for locks - it would render each object in the state it was in when it got to it. If temporary copying was necessary, this would still be more efficient than waiting for unpredictable game logic to run. The scripting engine would be switched from SQF to ECMAScript/JS 7 (or C# Script - even more preferable to me, but others might disagree).ES7, or Javascript 7, as some people would know it, is an almost universally known language. It is one of the most optimized dynamic languages due to extensive work done by browser and nodejs devs. There are extensive libraries available for use with it. It is easy to sandbox for security. This would allow the async scripting that SQF currently supports without the weird syntax. ES7 supports the await keyword which allows a piece of code to wait until something completes/occurs before continuing the code, without blocking the thread it executes on. For example, the typical "give weapons back on respawn" script: while(true){ await until(() => !player.isAlive()); _weapons = player.weapons; ... await until(() => player.isAlive()); _weapons.forEach(w => player.addWeapon(w)); ... } DirectX 12 support of course. Support for underground objects without hacks. Currently you have to lower the terrain to add underground objects, and then when the objects above them are outside of object view distance, you can see the holes in the ground. Earth curvature. Once we can get better FPS (see the above items), some people will want to raise view distance further.

Does anyone else use a HOJAM (hands on joystick and mouse) setup for flight in Arma 3? I recently got a Thrustmaster T16000M and have been experimenting with this. My bind setup looks like this (still experimenting): The advantages are that I can do constraint-free freelook with my mouse while using the joystick for flying. I am left-handed so perhaps I am uniquely suited to be able to do this. I used to fly right-handed with my mouse, using my keyboard for throttle and occasional sharp adjustments, so controlling all aspects of flight with my left hand is nonetheless taking a little bit to get used to, but I am already coming to rely on the freelook capabilities and do better at steep maneuvers than I was able to with the mouse. I'd be interested to hear from anyone else who has done this, or just thoughts/ideas in general about it.

I have a Thrustmaster joystick so my equiv would be T.A.R.G.E.T. but I haven't really explored it much - just a few things here and there for games other than Arma 3 that don't let you directly bind joystick functions.

Southpaw? Northpaw? I don't have pedals but the twist function works fine as long as I have a friction pad under the joystick. What I do wish my joystick had was an on-stick throttle slider and more stick buttons.

I'm just working off the scripts I extracted from the @alex_ais mod on Six. But I'm kind of restructuring the script, so that it will aim for one projectile at a time (when multiple projectiles come in at once, it seems to try to track them all at once, so it gets confused if there are very many).

@bwph4273 have you used any kind of source control before (git or svn etc)? We could set up a repository to coordinate our code changes in one place.

OK, I am back at this again - hoping to make this track faster / more efficiently.

First drafts are always rougher than the final product. The good thing is you got something out there for us to build on!

So... I'm working on a restructuring of this code to be more efficient and do better targeting. I have a fair bit of travel planned for this month though so not sure when I'll be done, but hopefully within the month.

Yep, it does work now. You are right - CBA is probably the most-downloaded mod ever. I actually had it already, but I did not include it in the launch parameters in SIX when I was testing this mod, since I wanted to avoid any unintentional side effects from other mods.

OK, I got a chance to look more at the code and noticed something: the mod has a dependency on the CBA mod. SIX doesn't list that as a dependency and nor does Armaholic, and I had -nologs on so I was totally unaware until I dug into the code. I know Foxhound put this mod on Armaholic... I wonder who I would contact to get the docs updated for the SIX package? Anyway, now that I'm more familiar with this code, maybe I can tidy up some of these other issues. Thanks for your help alexboy!

No need to be sorry. This mod wouldn't even exist without you - thank you for creating it and putting it out here for us to enjoy! Is there a more recent version of the mod that I should be making changes on or has the structure not changed majorly since 0.5?

After looking at the code and collaborating with livefire to test in the editor, I suspect this has to do with leaking variables - the aim calculation for one c-ram is leaking to the others and throwing them off. I don't know for sure, but I did notice a number of undeclared private variables and livefire and I noticed that the closer together the turrets are, the more accurate they are, which would support this. livefire was able to make it work sometimes under specific conditions: he had to be opfor and fire the rounds himself. Even then it works only on some game loads. I suspect that it is some sort of race condition in the loading. It also seems like the mod as distributed by SIX is incompatible with itself - whichever of the PBOs loads first works, and the rest don't, presumably because alex_running is already set to true. I did try deleting all but one of the PBOs though, and it still didn't allow them to fire on incoming shells for me. I am an experienced software developer and have reasonable although not super good knowledge of ARMA scripting. I will continue to try to pinpoint the causes of these issues exactly.

Funny thing is I work with computers for a living and I haven't figured the issue out yet - lol. To be clear, the C-RAMs fire at and awesomely destroy any vehicle or infantry within their sight. But they fail to target or fire at incoming mortar and artillery rounds. As for the alex_ais.hpp file, yes it puts it into userconfig\alex_ais\ under arma's steamapps folder in program files (x86) - matching the path you gave but with (x86). EDITED to add: No error is displayed anywhere.

Thanks for the reply - and the awesome mod! I did put alex_ais.hpp into that folder, except "Program Files (x86)" not "Program Files" since Steam is installed in "Program Files (x86)" in 64-bit Windows (there's no C:\Program Files\Steam in 64-bit Windows). I also tried deleting it from the userconfig folder altogether to see what would happen, and alex_ais.hpp was automatically recreated in the correct folder when I ran Arma 3 (maybe SIX does that?). Since I installed the mod using SIX, it was automatically put into an @alex_AIS folder in my mods folder. The ammo being fired was the stock ammo from the opfor MK6 mortar, plus each of the standard round types from the Sochor, using opfor AI and a Fire Mission waypoint. Since my last post, I also tried firing from the sochor myself as an opfor player and then teleporting using scripting to a location nearby the artillery target to see the effect. I also tried scripting a mortar with opfor AI in it to fire: In all cases, the rounds landed where they were targeted to, nearby the blufor C-RAMs (one of each type, with blufor AI inside) but they did not fire.

I have the same issue. The C-RAMs fire at enemy tanks and planes (and destroy them like a boss) but do not fire on incoming mortar and artillery rounds, fired by enemy AI from enemy vehicles and static launchers (2S9 Sochor and MK6). The C-RAMs are Blufor and I placed the Sochors and MK6's as Opfor units at varying distances from the target zone and set Fire Mission waypoints for them. The arty rounds land where expected, both close and medium distance from the C-RAMs, but the C-RAMs never fire. The version I'm using is v0.5 from the SIX manager. I also tried the version on ARMAholic. I made sure to place alex_AIS.hpp into C:\Program Files (x86)\Steam\SteamApps\common\Arma 3\Userconfig\alex_AIS\. I also tried putting it into C:\Program Files (x86)\Steam\SteamApps\common\Arma 3\Userconfig\.

The OP has asked us to avoid derailing his thread so I'll keep it brief: those constructs exist in most languages but they are blocking, rather than non-blocking operations - they tie up the thread for the duration of the wait.

Definitely - anything that allows us the power of a true programming language and allows us to use existing code libraries will be welcomed by everyone, whether or not it's their favorite choice. Did not mean to derail your thread.

Any kind of language runtime that would allow "real" programming languages to be used to create missions etc would be welcome - but I'd rather see something like the Mono VM implemented. Mono and C# grow and progress faster than Java and the JVM, which are somewhat stagnant lately. Plus, C# has language features built in that would be highly advantageous in an asynchronous environment. Consider this piece of SQF script: [] spawn { While{true} do{ //Free up thread until player dies... WaitUntil{not alive player}; //...then execute some script... _priWeapon = primaryWeapon player; _secWeapon = secondaryWeapon player; //...then free up thread again until player respawns... WaitUntil{alive player}; //...and execute some more script removeAllWeapons player; player addWeapon _priWeapon; player addWeapon _secWeapon; player addAction["Support...","x_scripts\dialog_support.sqf",[],0,false,true,"","_this == _target"]; }; }; As you can see, it runs an infinite loop that waits for something to happen (in this case, conditions to become true) without tying up the thread. When the condition becomes true, a thread executes the code and then is freed up again until the next time. This is something that Java is ill suited to do without resorting to callbacks, (which can't even be in the form of true closures because it only has inner classes). With C#, however, you could implement it so that you can write code that looks quite similar to the SQF: Spawn(delegate { while(true) { //Free up thread until player dies... await Until(()=> !Player.Alive); //...then execute some script... var priWeapon = Player.PrimaryWeapon; var secWeapon = Player.SecondaryWeapon; //...then free up thread again until player respawns... await Until(()=> Player.Alive); //...and execute some more script Player.RemoveAllWeapons(); Player.AddWeapon(priWeapon); Player.AddWeapon(secWeapon); Player.AddAction("Support...", ShowSupportDialog, condition: (p, t) => p == t ); } }); ...thus having the best of both worlds.