Jump to content
Bohemia Interactive Forums

astutavian

Member
 View Profile  See their activity

  • Content Count

    19

  • Joined

  • Last visited

  • Medals

Posts posted by astutavian

  1. Posted

    [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.

     

    • Like 2

  2. Posted

    ...

    If you got saitek software. pm me 'cause i got lots of tricks.

    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.

  3. Posted

    Keybord is alien to me --always stick in one hand; Mouse in the other.

    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.

  4. Posted

    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):

    uiTedaF.png?1

    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.

  11. Posted

    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!

  12. Posted

    Sorry about this man... I am not like a scripter.. i am using bakerman's script (which was allowed) and just let my mind go on it and it worked... i know for a fact that this code can be transformed into a more "scripted" manner ... just dont know how to do it since i am not a scripter... but ya... if anyone wants to figure out problems since im not like 100% good at this... im always open to help guys... hopefully ill be able to fix this with some other people i am working with as of recently to get this addon at a better handling...

    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?

  13. Posted

    The more c-rams there are the more inaccurate they are... i have seen this...

    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.

    just wondering how did you make it work to see that more there are the more inaccurate they are...

    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.

  14. Posted

    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.

  15. Posted

    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:

    mortarA commandArtilleryFire [getposatl artytarget, "8Rnd_82mm_Mo_shells", 50]

    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.

    did you add all .pbo to an addon folder ? at_phalanx and at_phalanx_missile and alex_ais into a addon folder... and just put alex_ais.hpp into alex_ais folder in the

    I dont know if this is an issue of yours being (x86) dont know how this affects it.... also just try placing a c-ram with unit inside blufor... and a like static mortar with unit inside Opfor and you fire them as a player from the mortar to the c-ram and see if that works... possibly your scripting may not be firing the right ammo... it checks for certain ammos in the air / weapons being fired.... like if you do what is in the video (artillery fire one) it should work if still having problems post again and ill try to look into it more...

  16. Posted

    I may be missing something here...but how do I get it to counter artillery? I placed them in the editor and waited a bit to make sure they initiated...and nothing.

    The CRAM2 with missiles did engage air targets though.

    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\.

  17. Posted

    Wouldn't conditions satisfy what you are looking for? This exists in Java as well:

    http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/Condition.html

    Semaphores also do the trick if you prefer those:

    http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/Semaphore.html

    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.

  18. Posted

    If BIS would rather use an alternative that has a similar feature set to java, I'm sure most of us would be happy to just escape SQF.

    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.

  19. Posted

    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.

×