Jump to content
Bohemia Interactive Forums

fn_Quiksilver

Member
 View Profile  See their activity

  • Content Count

    2697

  • Joined

  • Last visited

  • Medals

Posts posted by fn_Quiksilver

  2. Posted

    11 hours ago, eric963 said:

    My small group really likes your framework setup.

    Last night we tried use the Campaign mode.
    Is the campaign mode functional. I set it up and we drove around a bit but never found any enemy units.

    Thanks
    Eric


    Sent from my iPhone using Tapatalk

     

    take a screenshot of the map and send it to me via PM, also a copy of your server RPT.

     

    for the screenshot, wait 2-3 minutes after server boots up, as init of the campaign mode can take a bit

    • Like 1

  4. Posted

    Hi lads, 

     

    Trying to improve the SP-compatibility of a few of my scripts

     

    Right now people are having trouble with load/save issues. Like, the mod works once they start the mission, but if they load a save-game, it no longer works. 

     

    Is there a standard approach for handling this sort of thing?

     

    basically compiling a few functions and adding a couple UI event handlers, but i guess it needs to re-init when client loads a save.

     

    The issue is i dont do anything for singleplayer and dont have a testing environment set up for it (and dont really want to put one together)

     

    thanks for the help

  6. Posted

    On 6/26/2018 at 6:53 PM, tuskohopkins said:

    Hi,

    Has BI officially abandoned Combat Patrol game mode? Or can we still hope for improvements, updates form the devs?

    (Sorry if I missed some info)

    Thanks
     

     

    It wasn't clear on the intention for it for awhile,

     

    but if you download Argo, you'll see that development continued over there.

     

    I wouldn't say BIS has abandoned it, since Argo is theirs too. But probably development of CP within the ArmA 3 title has finished

  8. Posted

    Updated to 1.0.9

    Slingload enhancement, code cleanups, bug fixes, game-play tweaks

    - [ADDED] QS Slingload Assistant (incl. Taru Pod enhancement) feature. (allows raising and lowering of sling ropes + Taru pod attachment to Taru helicopter).
    - [ADDED] Framework parameter for artillery computer access.
    - [ADDED] Advanced Hints system.
    - [TWEAKED] Added sanity checks to "Unload Incapacitatated" user interaction.
    - [TWEAKED] Wrong orientation when sitting on "Sofa" chair.
    - [TWEAKED] Enemy mortar fire missions now fire extra shells if more targets are in the area.
    - [TWEAKED] Friendly UAVs had incorrect "featureType"
    - [TWEAKED] Enemy reinforcement transport helis had incorrect "featureType"
    - [TWEAKED] Removed all "comment" command compiles (micro-optimization).
    - [TWEAKED] Added safety check to admin "cleanup" functions.
    - [TWEAKED] Sling Load Assistant panel will automatically open when interacting with helicopter sling loading.
    - [TWEAKED] UAV operator uavs get AI disabled when towed/sling loaded.
    - [TWEAKED] Weather config data now uses default values (prevents errors on unofficial terrains).
    - [TWEAKED] Major code refactor for main client script, reducing its size by 1500 lines.
    - [TWEAKED] Disabled "Random" button in Arsenal.
    - [TWEAKED] Attempt to improve enemy transport heli waypoint loyalty.
    - [TWEAKED] Removed MP admin commands from chat code blocker.
    - [TWEAKED] Some small function speed optimizations.
    - [TWEAKED] Aircraft carrier island doors forced open during init.
    - [TWEAKED] Disabled the "hint" and "hintSilent" script commands (replaced with scripted system for more control).
    - [TWEAKED] Player menu mouse cursor position to remember last position between sub-menus.
    - [TWEAKED] Reduced AO size, especially on higher player counts.
    - [TWEAKED] Classic AO defend mission, disabled the randomized "extended timer" chance (can still be activated manually).
    - [TWEAKED] Added script suspension to AI info-gathering during Classic AO defend mission (to improve performance).
    - [FIXED] Getting incapacitated while carrying a player would leave them suspended in "carried" animation.
    - [FIXED] Taru assets were being improperly skinned in vehicle setup.
    - [FIXED] Wind direction variability on Tanoa was not correct.
    - [FIXED] Destroyed structures were being handled incorrectly by the remains collector.
    - [FIXED] Greyhawk UAV turret was unable to use the bombs.
    - [FIXED] Some small issues with the player menu system.
    - [FIXED] Small script error in anti-cheat.

     

     

    • Like 2

  9. Posted

    On 6/27/2018 at 2:55 AM, pierremgi said:

    Interesting... if it occurs in Vanilla Arma! I'll give it a test.

    I already found that incapacitated AIs are considered as healthy for orders (it's ridiculous that AI's leader are still ordering incapacitated units to do something...)

    and this other weird problem is not solved: The usual "need more info" is not fair at all for a 2 minute test in vanilla. BI devs don't care with that.

     

     

    is a "simulation bubble" issue.

     

    simply the life state is not propagated to the distant networked entities. there is no way to address this issue thru scripting

  10. Posted

    7 hours ago, pierremgi said:

    AI driving has some remaining weird engine controls. There is no real trouble for a HUNTER traveling on roads. Difficulties come with lack of road segments (or sometimes weird connections between them), blocks like rocks, "invisible" objects for collision, other moving vehicles.

    - I'm not familiar with PID, so I'm sure I could spend weeks or months failing doing better than BI devs. I just remarked (see video below) that vanilla tanks are "week" in city progression.

    - the collisions are garbled by two things, imho:

        + the lack of inertia (Never seen in real world a tank bouncing and looping in the air);

        + the "velocity" of the event. I means, if you "instantaneously" spawn an object into another one (messing with "can_collide" for example), the cinematic is totally inaccurate.

    - There is no logical "exit" "issue" for maneuvering when stuck. You can see an HEMTT trying billions of times to maneuver  right/forward, left/backward.... no matter where the obstacle is, (it doesn't "know" where it is in fact), without attempting something else...

     

    Anyway, even if a convoy is submitted to all these following points on each vehicle, the new setConvoySeperation is not too bad!

    As you can see in the following video (full AIs!), you can mix the types of vehicles. You can even add an helicopter following the convoy!

    The tank remains a hard point for the convoy progression, except on long straight parts of the track.

     

     

    So, what I tested so far, with some success:

    - place your vehicles in good order for the convoy,

    - group them to the vehicle leading, one by one, in the order you want them to start (currently the same as above!). If you make any change (for example changing a HEMTT for another one in editor object type), the order is broken. You have to ungroup all then group them one by one the vehicles again.
    Do not hesitate to do that. Otherwise the group order is broken. that's a weakness of the editor (like for support modules which can loose their efficiency if slightly modified afterwards).

     

    - in "composition state" field of the group icon (right click):

    behavior Safe, column, limited speed mode,

    - I used to add :

    { _x disableAi "autoCombat"} forEach (units this select {driver _x == _x && vehicle _x != _x});

    It's useful in specific case, like when you want the convoy to cross a battle field while the drivers continues on road. Problems rise when some vehicles are destroyed... So, perhaps, keep that on mind for video trailers if you help with indestructible vehicles.

     

    - in init field of the leading vehicle:

    this limitSpeed 40;  // a good average

    in the init field of all the vehicle. I didn't remark a difference if the leader has the code or not, so let's say all vehicles but leader.

     

    this setConvoySeparation 20; // do not try a too close distance. The close distance can break the separation and even stop definitively the vehicle!

    With some experience of broken convoy, I added:

    0 = this spawn {while {alive _this} do {waitUntil {sleep 1; speed _this == 0}; _this setConvoySeparation 20}};

    just to "rearm" the command. It's not 100% guaranteed but I remarked so improvements with that... Just to be tested before giving up!

    If you add an helo, increase to separation for it. And reduce the flyInHeightASL ([20,20,20] seems OK).

     

    About waypoints:

    The idea is: the less intermediate waypoints, the better!

    The engine will calculate a path anyway, before the leader starts. Then, all is fluid and there is no stop, like you can see that on each waypoint (probably for calculation).

    On the other hand, intermediate waypoints are useful for alternate navigation and offer a little stop allowing the convoy to regroup (especially with tanks!).

     

    The convoy separation is certainly a complex behavior and I can say BI did a great effort on that. The vehicles are trying to keep their separation and the leader waits for late queue, driving at low speed. The last intermediate vehicle seem to make the junction with an intermediate position. On the other hand, any sluggish vehicle sucks!

    Last but not least, I'm rather sure the AI leader can order (they love to give orders!) the vehicle to repair or refuel or rearm to another one... They have their own trait, after all.

     

     

    Now, combat!

    The fact is the event issue is unpredictable! You can play the same scenario, again and again without the same result. Never! If the convoy behavior depends on the machine state(Arma engine, scheduler, memory, CPU load...), then be sure the combat mode is far more stormy!

    So, as written above, for trailers, do what you want and disable damage on vehicles (at least the leader!), Make enemies dumber, remove some ATs, AAs,...

    For an immersive scenario, keep the convoy "AWARE" and cross fingers.

     

    How does things work with setConvoySeparation?

    - when vehicle leader or leader dies, // the speed limitation is not switched of course. The convoy separation seems to work and the waypoints are not erased. The combat behavior can shift within a short delay. Not too bad.

    - when a vehicle can't move anymore, // not sure the convoy separation manages this case. There is perhaps a max distance to keep the convoy, but it's way too long.

    - with squad embarked into vehicles... // not sure the convoy stuff is 100% compatible with the setUnloadInCombat... Units embark/disembark repeatedly and sometimes fall stuck in column formation outside. Not great to allow this behavior in convoy.

     

     

     

    Note: the HE shells fires on enemy infantry with tank or APC is an added script.

    Have fun. Stay positive.

    Pierre

     

     

     

     

     

    you're wasting your time

     

     the job of fixing and making sense of the AI is BIS job. they hide their AI code from us for whatever reason, and expect us -- through tedious trial and error -- to find a useable and non-broken pathway to creating fun game content. they could, with few button clicks, post us the AI driving code so we can inspect and 'navigate a path' through the buggy code, but they choose daily to instead conceal and not publish.

     

    if BIS wants a change in situation, post the FSM of the buggy/garbage driving AI and the modding community will figure out how best to make use of it to create fun gameplay, while you guys focus on ArmA 4 enfusion. Hopefully there is no link between A3 driving and A4 driving, so there should be no intellectual property concerns with posting the A3 driving FSM. If however there is some link between A3 AI driving and A4 AI driving, there is reason to worry..

     

    tag @oukej @klamacz @dr. hladik

    • Like 5
    • Thanks 1

  11. Posted

    On 6/26/2018 at 4:05 PM, froggyluv said:

     

     Simply cant overstate how absolutely critical this is to a genuine infantry gaming experience. Ill never forget first time I was in Sahrani and was about to get a seemingly brilliant squad on squad firefight on those raised terraced areas in downtown Paraiso - a nice multi leveled staired area would be so intriguing when blam - AI couldnt move on or around them at all... Literally couldnt believe why an artist who games would put in a movement deadzone in the middle of a critical city! Happened again years later in Tanoa (also Terraced) but this time they said it was 'more meant for multiplayer'..

     

    Anyways enough crying over spilt milk. really hope that AI team and Map terrain and object team work hand in hand this next time around. Where and how high windows that have AI placement points really do matter! Half shuttered windows really do suck! Shit, crying again my bad. NearestBuilding needs tweaking as it sometimes tries to locate the center of the building model some 60meters away...but this is critical for those of us trying to implement an interior AI fighting component. AI crawling under fences works remarkably not bad but man would it be great for them to actually vault over small walls etc -as they are far more common than high fencing. And some nice Nav mesh of roofs, bridges and carrier decks to prevent AI suicide would be nice as well -im starting to take them personally.

     

    it is sad that there is minimal/no communication between the terrain designers and the engine/gameplay/ai designers. this is what happens with outsourcing to cut cost :\

     

    like, do the vietnamese Tanoa designers really know what the Prague designers want in terms of AI useability? rip

    • Like 2
    • Thanks 1

  12. Posted

    2 hours ago, dragon01 said:

    Wrong. If this was not a hard fix, it would've been fixed.

     

    by whom?

     

    Quote

     

    You're assuming the AI code has been written 100% sensibly and logically, when it's not the case, considering its history. For example, the Z reference is very likely "quietly assumed" by the whole bloody code to be unchanging and permanently set to 0 (just a guess, it's the first such shortcut that came to my mind). Whatever's the reason, it probably made sense in OFP, given the limits processing power and memory back then. Maybe there's a way to fix it, but it is likely hard, will break other stuff and the people most qualified for fixing it have been shunted away to Enfusion a while ago.

     

    just fanboi fluff, nothing here to respond to

     

    what we do know from the outside looking in, is that there has been very little--close to nil--effort put into either resolving or improving things, and similarly low effort put into exposing these systems for modders to fix/replace themselves. and the timeframe i use is 2012-present (6 years)

    • Thanks 2

  13. Posted

    4 hours ago, dragon01 said:

    I can tell you that 1). Enfusion is highly modular, so changes in other places shouldn't affect AI (not saying it won't spaghettify by ArmA7, but the architecture is inherently modular). 2). It's being done with a relatively good idea of what vehicles are going to be like (note that OFP didn't have too many vehicle problems, which is when the AI was made). 3). As a science, AI development has considerably advanced since OFP days, so more refined methods can be used.

     

    Do remember that there was no revolution in ArmA AI at any point between OFP and now. There was some evolution, but it's running an outdated core made under outdated paradigms. Do note, for example, that there is one vehicle type (VTOL) that wasn't in OFP and was implemented later (in ArmA1, to be precise, with the Harrier). Also note that this vehicle type is one that the AI pretty much can't cope with without very heavy scripting, and even then it's basically a variation on the airplane. Granted, OFP did cover almost all the bases (which is why we're only getting a replacement now), but it's becoming increasingly clear that it just isn't enough today.

     

    a couple of the things which bothered some of us, was that its been clear there hasn't even been an attempt to address some rather simple AI bugs. a core part of the game (everything non-pvp) neglected almost completely. 

     

    for instance, simple QA and testing (or even just devs playing their own title) could have discovered and fixed this bug:

     

     

    ^ thats not a hard fix, simply adjusting the slope and using the target as Z reference instead of ASL=0

     

    but zero fixes can be made if BIS has committed zero resources for such a core part of the game.

     

     

    on top of that, its also the least open and least moddable parts of the game. since it is truly abandoned, why was there not some effort to expose the systems for modders to fix? is there valuable intellectual property in the spaghetti? embarrassment? all unknowns and question marks

     

    it appears zero effort in that regard as well.

     

    note this is just retrospective, not suggesting BIS raise the effort level from zero in these regards

     

    • Like 3
    • Thanks 1
    • Sad 1

  14. Posted

    thanks!

     

    the anti cheat is not infallible and its ‘cautious’ in that it prefers to just log instead of kick, and kick instead of ban. its also less intensive and isnt scanning some things every second, to reduce its performance impact.

     

    if its a concern, you can work on the battleye scripts.txt filters using the template provided. i might cook up a new set for the official version, but the template is already there. also make sure that the createvehicle.txt and remoteexec.txt files are active, they should still be serviceable without tweaking

  16. Posted

    1 hour ago, HazJ said:

    Like these? This would just save you doing your own arrays, etc... As for the checking if AI auto reports, not sure if there is an EH. You'd have to have some kind of loop.

    https://community.bistudio.com/wiki/targetKnowledge

    https://community.bistudio.com/wiki/targetsQuery

    // reset...

    https://community.bistudio.com/wiki/forgetTarget

     

    I find the new "targets" command is quite good

     

    https://community.bistudio.com/wiki/targets

     

    does roughly what "targetsQuery" does but without the baggage from backward compatibility

     

    some AI event handlers would have been nice but alas, it was not to be in a3

    • Like 1

  18. Posted

    11 hours ago, oukej said:

    Primary reason for lately low "investments" in AI in A3 has been a way too low cost-benefit ratio (spend days, weeks fixing seemingly simple issue) and relatively high risk connected to code changes (fixes causing issues on remote places).
    AI devs have been the first ones to put their hands on Enfusion, building up the AI from the very foundations.

     

     

    nothing unexpected :) i wish the driving bugs were resolved but it makes sense. i never pushed for broad AI improvements/fixes due to the above.

     

    hopefully enfusion AI isn't just zombie AI, given its zombie dayz legacy (although i would take zombies if they could drive reliably)

     

    i appreciate the candid points regarding cost-benefit, helps put some questions to rest :)

    • Like 1

  20. Posted

    6 minutes ago, Dedmen said:

     

    yes

     

    i wonder if shutting the units up via 

     

    https://community.bistudio.com/wiki/enableSentences

    https://community.bistudio.com/wiki/setSpeaker

     

    would have any effect

     

    i toggle enablesentences to stop AI speech once server fps drops below 20, but that was in hope to reduce network load, didn't consider a leak on the server

     

    in any case i hope it gets fixed pronto

    • Like 1

  23. Posted

    1 hour ago, Harzach said:

    It's a complex subject, and one that I can only truly approach from my own position, where it seems counterproductive.

     

    There is no question that you are one of the good ones here, Haz. If you feel it's in your best interest to obfuscate some of your work, that's your decision to make and I can absolutely respect that. I think the practice gets a bad rap from those who gladly take assistance from those like you, and maybe even "borrow" code from other people's missions, but have no intention to be a part of this fine little community.

     

    we see this in torrents as well. 5 seeders and 50 leechers. the number of people who take but give nothing in return far outnumber those who give too

    • Like 2

  24. Posted

    5 hours ago, HazJ said:

    removed

     

    EDIT: Maybe we don't want you to take, even if you credit. Maybe we just don't want to share because it is a good idea and want players. I know @fn_Quiksilver did this at first with his I&A Apex Edition. Maybe we just don't want to share it at all? A license with SQF code isn't gonna do much, at least I haven't heard anything about it. And by then, it is done. They took and shared already. People see "protection" and "obfuscation" instantly as he is not sharing with the community, cry, cry. That isn't the case, not always at least, and especially not with me.

     

    i typed a longer reply but it disappeared :(

     

    but yes we stored many script components serverside to prevent re-hosting. we wanted a full 60-player server during development for balancing and tuning gameplay, and allowing re-hosting would probably have bled some of that community away. we ended up having a great community and a great 18 month experience and we were all sad when the time came to shut the server down, though running a community with hundreds of people does take its toll (and also takes away from dev time).

     

    modders already get close to nothing for their time (from the users of their mods), and people who have run populated arma servers would understand how scummy the arma community can be with respect to modders time/effort. thankfully there are enough good people in the community to make it usually worthwhile.

    • Like 2
×