Jump to content

jarni

Member
  • Content Count

    18
  • Joined

  • Last visited

  • Medals

Community Reputation

2 Neutral

About jarni

  • Rank
    Private First Class
  1. Done. That's the third ticket in 2 days :(. I'm curious if Reforger is of the same "quality".
  2. Thank you for confirmation. In the end, I do delete non-repeatable triggers after activation, storing their state to a hashmap for fast checks. I don't need their area anymore when they are done, so I can delete them. Otherwise, I'd just simply disable simulation for them. This stops checking, but doesn't remove area related calls. Another trigger related question, partially related to this one. Trying to optimize load I tried to prolong intervals between trigger checks to 30-60 seconds, but, I actually received an opposite result, trigger checks started to run faster. My findings are: Trigger intervals x in range [0, 10] -> 1:1 ratio -> check every x seconds Trigger intervals x in range (10,600] -> 1:0.1 ratio -> check every x/10 seconds with very non-regular timing (for example, if set to 600, the check condition is done in range of 57-63 seconds) Is this a know feature/bug? Again, I don't see it anywhere in documentation for triggers, for setTriggerInterval particularly.
  3. Unfortunately, this is not mentioned anywhere in documentation :(. Would have gone with the hashtable of evaluated triggers right from the start.
  4. I have a trigger (main_trigger) which checks it's own simple condition (player present in area) as well as activation of other trigger. So, it's condition looks like following: this || triggerActivated some_other_trigger My first problem has raised when some_other_trigger has not yet been created (I do create triggers dynamically in scripts, but with fixed, predefined names). triggerActivated some_other_trigger returns nil and whole expression returns nil. Trigger is never activated (well, until that other trigger is actually created). To solve this, I wrote a small function orTrigger which evaluates an array of triggers taking into account non-existent triggers (taken as false). During debugging that function I see that it is called, even when the condition has evaluated to true (triggerActivated main_trigger starts returning true). My expectation was: if Repeat check-box in trigger attributes is un-checked, the trigger stops evaluating it's condition after evaluating to true for the first time. I know that documentation says that it simply stops calling OnActivation code after first time. But still, it looks non-logical. It also means that tons of triggers continue consuming resources even when their value already know and will never change. Deleting trigger can't be used in my case because I need main_trigger value for other triggers. I ended up simply disabling simulation for it. Do I miss something? Do I understand the logics or usage wrong?
  5. Thank you! But, is this really necessary? As I've mentioned, I have 2 other scripts done in similar manner and they work just fine. I'd like to avoid spawning script on every load without being sure that the previous instances are not running and consuming scheduler time. All 3 scripts are started in init.sqf: execVM "globals\runAC.sqf";//! Area Control execVM "globals\runGCC.sqf";//! Group Combat Checker execVM "globals\runSAD.sqf";//! Seek&Destroy The last one is the only which stops working after restart. AC has update time 30 seconds, GCC every 1 second, SAD initially 60 seconds (but reduced to 15 seconds for tests). The biggest difference is that neither AC nor GCC make "call" in them.
  6. Hello community. For my singleplayer mission I've created several script which run in background and do different stuff periodically. 2 out of 3 works just fine if I do Save&Load. But one is not restarted after loading game. The scripts spawn group from current "spawn level". The spawn coordinates are hard-coded in Altis's Kavala. "Seek&Destroy" WP added to group. WP is located on player. To check script: 1. Run in editor 2. Add player somewhere in Kavala with radio in inventory (logs are done through sidechat) 3. Wait a few update intervals (15 s) to see that script periodically checks the conditions for spawn 4. Save, wait, load and see that script still works 5. Set through debug console the "sad_level" variable in mission namespace to 1, this enabled first spawn level 6. Wait till next update interval that script spawned group. 7. Wait a few update intervals and see that group's WP is updated with player's current position 8. Save&Load 9. No more WP updates happen, no more "[SADs] Loop" messages, nothing By commenting different parts of the script I found out that the problem is with "_group = call _level_script;" line. But I don't get why and how I can work around it.
  7. Hello community. Been experimenting with different ambient animations using this call [test_subject, "<animation>", "ASIS"] call BIS_fnc_ambientAnim; and built this list: //! + "STAND1", "STAND2", "WATCH", "WATCH1", "WATCH2" //! - "STAND_U1", "STAND_U2", "STAND_U3", "GUARD", "LEAN_ON_TABLE" //! ? "LEAN" //! + "SIT1", "SIT", "SIT3", "SIT_HIGH1", "SIT_HIGH", "SIT_LOW", "SIT_SAD1", "SIT_SAD2" //! - "SIT_AT_TABLE", "SIT_LOW_U", "SIT_U1", "SIT_U2", "SIT_U3" //! - "REPAIR_VEH_PRONE", "REPAIR_VEH_KNEEL", "REPAIR_VEH_STAND" //! - "PRONE_INJURED_U1", "PRONE_INJURED_U2" //! ? "PRONE_INJURED" //! + "KNEEL" //! - "KNEEL_TREAT","KNEEL_TREAT2" //! - "BRIEFING", "BRIEFING_POINT_LEFT", "BRIEFING_POINT_RIGHT", "BRIEFING_POINT_TABLE", "LISTEN_BRIEFING" + - doesn't change equipment, i.e. respects equipmentLevel parameter - - removes primary weapon and backpack ? - removes backpack only This is not mentioned in description or Notes here https://community.bistudio.com/wiki/BIS_fnc_ambientAnim 1. Is this a bug or intended behavior? 2. Is there a simple\existing\proper way to bypass this except storing equipment list and restoring it after animation is terminated?
  8. That did the trick. Thank you! I can, the question is why it is added in the first place. Will try that out, thank you.
  9. Hello community, I want to create a situation when there is a BLUEFOR hostage of class B_soldier_repair_F (with some ambient animation like PRONE_INJURED) and a group of OPFOR units guarding him. There is a trigger which changes hostage's group to player's. Works perfectly if ran from editor or as exported mission. But I got into troubles when trying to do this from script. 1. If hostage is (WEST, B_soldier_repair_F), he is killed immediately by OPFOR guards after being spawned. 2. If hostage is (CIV, B_soldier_repair_F) result is the same. Civilians do not have soldier_repair_F class, afaik 3. If hostage is (EAST, B_soldier_repair_F) result is the same!!! 4. If hostage is (EAST, O_soldier_repair_F) all works fine. 5. If hostage is (WEST, O_soldier_repair_F) all works fine!!! So, it seems like OPFOR units completely ignore group and look at the unit class only. I might have gone with option 4 or 5, but O_* classes are CSATs with arabic names, faces, voices etc. I do set name, face and voice explicitly but the engine seems to ignore that. I even tried to do this twice, once when unit is created and the second time when group changing trigger is executed. Name, face and voice are changed in that case, but not the unit name shown in group units list. See following screenshots O_solder_repair_F after spawn and joining player group: name, face and voice are arabic O_solder_repair_F after running unit_o setRank "CORPORAL"; unit_o setname "Greer Lee"; unit_o setface "GreekHead_A3_05"; unit_o setspeaker "Male01ENG"; unit_o setpitch 1.03; So, there are couple of questions bugging me: 1. How can I spawn WEST unit which is ignore by EAST units? 2. If above is impossible, how can I spawn EAST CSAT (arabic) unit but with ensured custom name, face, voice settings? I've also noticed that even though I spawn hostage with empty inventory, he, sometimes, is spawned with glasses. Not a problem, but looks like the engine ignores different bits of unit setup. The test scenario and spawn scripts are here: https://www.dropbox.com/s/ow77tugr7pfiexc/group_test.altis.zip?dl=0 or here spawn_east.sqf spawn_west.sqf
  10. 2pierremgi: Man, you made my day. For some reason, I've missed the scenario->export menu option. Thank you very much for extensive explanation how this works, especially the layers. It's a bit unfortunate that there is no option to import that, this makes editing the existing layers difficult.
  11. Ok, it took around 10 minutes to export, and then around 30 minutes of fighting with unresponsive EDEN editor to get that copied. In the end I have 40k lines script file to work through. Thank you, baton1990, for pointing to that function. As of blacklists, I don't see anything related to that in resulting script. Either nothing was blacklisted or it doesn't work.
  12. Exactly what I need in my case. I'm going to leave all static objects in the scenario and just move group spawn into scripts. Thank you.
×