Jump to content
Bohemia Interactive Forums

Wolfenswan

Member
 View Profile  See their activity

  • Content Count

    212

  • Joined

  • Last visited

  • Medals

Posts posted by Wolfenswan

  1. Posted

    A thing to keep in mind is that mods are always modifications of a game in it's current state. Neither can modders foresee the in-engine changes in future developments, nor can engine developers consider all requirements or hack-jobs mods implement. The legacy version of 1.38 exists for precisely this reason.

    Yes it's annoying if something you've gotten used to does not work for a while (or won't ever again) but such is the world of software development.

  2. Posted

    Everything vanilla related (fixing bugs, tweaking and balancing the game) needs to be based on vanilla observations. Don't report stuff happening with mods active.

    Seconded.

    The new update changed the danger.fsm, which is why, for example, ASR_AI3 currently does not work. I'd not be surprised if it also has weird effects in conjunction with other AI mods.

  3. Posted · Edited by Wolfenswan

    First off: I love it, great functionality without unnecessary baggage.

    I've noticed a bug which allows duplication of explosives and mines as engineer with a toolkit.

    Reproduction:

    1. Be "explosive specialist" or similar class. Select explosive charge or satchel and find a spot to place it.

    2. Note that despite the green indicator, the action defaults to "disarm explosive" (the X icon) once your character "spots" the mine.

    3. Press your action key without using the action menu.

    4. Observe the charge being placed, but you are still in placing mode. You can now place a second explosive or cancel the action and keep the duplicate explosive.

    It works fine when not using the default action but always using the scroll wheel action.

    There are two workarounds I can think of:

    1. Somehow override the default "disarm explosive" action. Ideally the default action would be the explosive menu when facing an explosive.

    2. Instead of using the explosive object itself use a more abstract representation the engineer class won't "spot". The bug does not occur when placing tripwires as it does not use the tripwire object.

    Suggestions:

    1. A conditional for the explosive menu action to only display it if a) the user has active explosives under his control or b) an armable explosive is in the proximity. And/Or use a key-eventhandler to bind it to a key. This would help in de-cluttering the action menu. Ideally it would also be the default action when a user is facing an explosive.

    You said

    Balance issue. The only way to disarm the mines is via the menu, so if the menu shows up when there's mines nearby, it's a cheap way to act as a mine detector.

    but I think this can be solved by using mineDetectedBy or detectedMines.

    2. Really minor, but a way to select the color for the tripflares? It's straightforward to change the class in the function itself but an obvious global variable would make things a little easier. I also find it a bit more powerful when the smoke is given the same color as the flare, but that's a matter of taste.

    Edit: After seeing how nice the flare effects are I changed my own tripFlare function to use those instead of chemlights and modified it to recreate the flare as long as the smoke is present. That way the flare lasts about 1 1/2 minutes rather than 25 seconds. Feel free to use it if you think it's useful.

    What do you think a better name for the APERS mine would be? I'm thinking of writing a small client-side addon just to change the name to reflect the new functionality better.

  6. Posted

    Currently bunkers, bean-bags and h-barriers and some misc. fortifications are impervious to damage as they are missing destruction effects in their config (despite being marked as destructible building). I am not sure if this is a bug or working as intended, but in any case I'd advocate to change them to just disappear into the ground when damage is 1 instead of simply being unaffected.

    Ticket:

    http://feedback.arma3.com/view.php?id=22880

  9. Posted · Edited by Wolfenswan

    For those curious, here's what you might call a short roadmap:

    We are currently working on improving the TFR and ACRE2 functionality, which we will release as 3-2-3. Barring any hot-fixes, this will then be our last F3 3-2-x release.

    As for version 3-3-0, we have no set goals yet but some features we are considering are a complete rewrite of the current group Marker system, an improved garbage collector and improving the functionality of the current admin briefing, possibly into a full-fledged in-game menu. We have also been throwing around the idea of reworking the current assign Gear system into something more intuitive but this will need extensive testing.

  10. Posted

    Had to hotfix the silly bug that caused player to throw smoke when hit, so 0.9.17 is out

    I assume that only affects players who have ASR_AI3 running locally? If not I'm tempted to stick with 0.9.16 on our server just to mess with our players :rolleyes:

  11. Posted

    Giving individual AI units/squads waypoints of hold, or sentry, as Seba suggested, seems to hold them to a degree. BUT if you are using the default sites modules for observation post, Base etc, you cant give them waypoints, & they wont now stay in position, that's both friendly & enemy AI units.

    The only solution seems to be that, until there is another update roll back to previous version.

    Re "doStop" as in your link I have used that for a while, problem is since the last ASR AI3 0.9.15.66 update, doStop dont stop!

    You could try getting the group spawned by the site and giving it a HOLD waypoint. It's what I've done for my garrison script which formerly only used doStop.

  14. Posted

    That issue was valid only for units in MP environment and only those that were remote to the server. (units on server had correct skills - in terms of behavior, only the skill/skillFinal commands were getting wrong values)

    Can you clarify one thing about the fix:

    In a MP environment with a dedicated server, will the AI-values set in server.cfg (precision & skill) affect ALL AI (no matter locality) or will client settings still affect AI local to them?

  16. Posted · Edited by Wolfenswan

    I also tested this in vanilla but I don't know what to expect. What are you seeing ? There was no obvious change in behavior for me.

    Oh and btw thanks for making me watch vanilla AI again. Geez.. :D

    Sorry for that ;) Must have been confirmation bias on my end. I do remember AI not engaging when disabling said AI-modes but maybe that has changed on BI's part.

    Btw. I just spotted this fix/comment which might be of interest to you and should hopefully fix reading skillFinal.

  17. Posted

    To clarify, you say:

    serverTime variable which will let you tell you how much time the mission has been up for on the server

    and the Wiki states:

    Note that in ArmA2 1.05 Final, this command only returns the time since the Server was actually started.

    Which to implies the total up-time, not time since mission was launched. Is the wiki wrong here ? Also, is bug mentioned by Crowe fixed in A3?

  18. Posted

    How would a script look like that informs a player (JIP and right from mission start) by hint (or globalchat or cuttext) how much time is left until the mission ends? (a message like "MISSION ENDS IN 41 MINUTES" when he joins the game).

    It should also be compatible to all daytimes of mission start and end. E.g. the mission starts at 0:30 and ends 01:30 the next (ingame) day.

    Been thinking about this every now and then for months but I just don't get it :-/

    Just to be clear: when you say 45 minutes, do you mean real time or in-game time?

    Anyway, a very simple setup would be:

    [] spawn {
 waitUntil {time > 0}
 sleep 300; // Time in seconds for the "tick".
 cutText [format["%1 minutes have passed.",time/60],"PLAIN DOWN",2]; 
};

    If you want the total time left, you need to define it as a global variable somewhere.

    If you want to use the in-game time, you can use the date command and check the hours/minutes.

    To get this working properly with JIP, you could just run most of the code on the server and use BIS_fnc_MP to broadcast the message. I wrote this script doing that for a mission of mine. It has a slightly different purpose but you should get the idea.

  19. Posted

    am i an idiot or did i miss something on this danger.fsm where do i apply or find this? or is this a sub file within the ASR_AI's PBO's? I am making sure my whole Squad is running the ASR_AI mod now in conjunction with the server to provide enhanced functionality is that what im gathering from reading this post? everyone runs it everywhere and it just works better?

    It's a sub-file. And no, clients only NEED to run ASR_AI if:

    • they are in charge of AI as a group leader
    • are CREATING AI local to them (e.g. as a ZEUS)

    Of course, running the same version on every client is the obvious "better safe than sorry" measure and won't cause issues.

  20. Posted

    Not intentionally at least. Maybe a weird side-effect of who knows what. Need a way to repro this so I can start debugging.

    Place yourself as either NATO or CSAT. Place a group of INDP. Use the intel screen to set them friendly to your side.

    In-game open the debug console and execute: resistance setFriend [west/east,0];

    In a vanilla game, the AI will attack you straightaway. With ASR_AI3 the AI will recognize as enemy but not engage reliably.

    For disabling AI it's similar: Compare AI engagement behavior between vanilla and ASR_AI3 after running {_x disableAI "TARGET"; _x disableAI "AUTOTARGET"} forEach allUnits;

  21. Posted · Edited by Wolfenswan

    Does ASR AI3 interfer with setFriend/getFriend in some way? When using setFriend to shift allegiance in Vanilla, the AI reacts almost immediately and engages new threats. With ASR_AI3 they seem to be aware of them (go prone, knowsAbout is 4 etc.) but don't or only very sporadically engage.

    This only occurs when shifting from friendly to hostile. A shift from hostile to friendly will cause the AI to stop engaging.

    Similarly, disabling AI "TARGET" & "AUTOTARGET" does not seem to have an effect on AI when using ASR_AI3.

  22. Posted

    Thanks for clearing that up. One more question regarding config:

    asr_ai3_main_joinlast: Does this apply to all groups or only groups which took losses and were reduced to this number? E.g., would a single unit placed in the editor (as it's own group) merge with a nearby group?

  23. Posted

    Is AI engaging armored vehicles with turned-out crew with small-arms a vanilla or ASR_AI feature? I noticed that when the AI does this, they seem to burst for longer than feasible (crew's already turned in) before shifting fire to softer targets.

    We have also noticed that AI engages from much further with 0.9.14 (which in and by itself is great) but from distances where any hit would be pure luck (e.g. 750m+ with no scope) and there's no point to return fire. I haven't observed this enough to give a good recommendation or nail down when and how it occurs but figured it's worth a mention.

  25. Posted

    A mod can run client side, it doesn't mean it should be run by one chap on the server while the others don't...

    You are looking for problems if you do so.

    (Just my opinion...)

    A free-for-all approach is certainly going to cause issues but it is not going to have an effect on what the other players are experiencing. E.g. JSRS 3.0 is not going to have an effect on what other players can or can not hear, unless it would be not entirely client-side.

×