Jump to content

haleks

Member
  • Content Count

    3984
  • Joined

  • Last visited

  • Medals

Posts posted by haleks


  1. On 1/24/2024 at 5:12 AM, Greasy_Randingo said:

    Hey @haleks is this coming back at any point? Would really love to see a return 😞

     

    Honestly, being a Single Player kinda guy, and now that it's clear that Reforger won't ever be SP-friendly, my interest in modding it has pretty much vanished...

    I might boot it up some day and fix it, but I reckon it will be the last time I touch anything Reforger-related.

     

    Although I do need to fix (ideally replace) my CPU first... 😑

    • Like 1

  2. 4 hours ago, gatordev said:

    I have seen where walls will get destroyed by .50 cal rounds on Lythium.  I'm guessing that's Impact causing it

     

    That 's unlikely : currently Impact is pretty much just a conditional addForce command plugged into a hitPart EvenHandler; it cannot have any effect on anything other than units.


  3. Hey guys,

     

    Tiny update for MP :

    Quote

    * the Impact function is now remotely executed where the target is local.

     

    Apparently, the addForce command I'm using requires the target unit to be local... And since the hitPart EH fires on the shooter's machine, I'm guessing the previous update wasn't properly working.

    • Like 1

  4. Hello chaps !

     

    I've pushed a small update after realizing that Impact wasn't working properly in MP.

    Since the "hitPart" EH I'm using needs to be added from any potential shooter's machine, it is important to remember that Impact should be loaded on both server & clients.

     

    Have fun people !

    • Like 3
    • Thanks 1

  5. 15 hours ago, EO said:

     

     

    Hey man, following on from our conversation about running audio/visual detection independently from the module settings, is it correct to assume Damage Output/Damage Multiplier use a similar global variable? 

     

    Correct.

    Good thing you're asking mate - I realize I can easily add the same workaround as the visual detection tweak to both the damage output and the damage EH.

     

    The "legacy" update isn't quite ready, but I reckon I'll try to push a tiny patch around next week-end with a few improvements I've made so far. 😉 

    • Like 1

  6. Your code won't do anything because you're not running it on any object : your mossRocks array is holding classnames, not objects.

     

    But before we dig into the syntax errors, you should know that you can't modify terrain objects; if the idea is to adjust the size of all those objects on the terrain, the process is going to be a bit more involved :

    - you'll need to detect all corresponding terrain object and hide them. And then spawn the same model with a random size - spawn them as simple objects to do so.

    - buuuuut, the sheer number of objects to keep in memory will most likely be enough to crash the game while attempting to save in SP, and/or cause many issues in MP.

    • Like 2

  7. @hongerTo expand on what EO suggested :
    The spawn system looks for any "static" structure to generate spawn positions; that means that fences and street lights along main roads will tend to monopolize the potential spawns outside of urban areas.

    Ravage does have a backup method to spawn zeds in the absence of static structures, but since that's a rather generic reference, it doesn't even kick in most of the time...

    The spawn module does allow you to blacklist specific structures though, that could improve things in your situation.

    My Remnant mod has a more advanced and modular system, but I don't see any easy way to port it to Ravage without potentially breaking custom scenarios. 😕

    • Like 1

  8. Hello chaps,

     

    Here comes another update !

     

     

    Ravage v1.0.5
    * fixed script compilation error
    * added Entity Catalog to Infected Faction
    * fixed BT using obsolete scripted nodes
    * fixed infected being unable to sprint and attack at the same time
    * Infected can now jump over obstacles in their idle state
    * BT tweaks & optimization
    * The Request Climb scripted node now enters a FAIL state if climbing isn't needed
    * Infected no longer try to move to their target if they are close enough
    * Reduced leading movement time during chase sequence
    * fixed infected using an obsolete voice amplitude config
    * fixed obsolete keywords following recent Reforger updates
    * improved infected textures

     

     

    The mod is playable again, and the patch features several AI improvements & optimization.

    Note that infected audio needs further tweaks - sound occlusion doesn't seem to work properly, and audio levels need to be adjusted to work better with their amplitude config. Another thing to keep in mind, regarding zeds being able to climb in their idle state : the original plan was to limit that feature to low obstacles, but the current functions related to climbing don't seem to be 100% working right now... I was unable to obtain the data I'd need to distinguish between climbing and vaulting - at least not in a reasonable or optimized way; so that will need some adjustment too.

     

    Have fun guys !

    • Like 3
    • Thanks 1

  9. I gotta say, even though I have no love for Reforger and its full on MP orientation, working with the workbench is always nice.

    The game breaking issues caused by the last updates were easy to fix, and I've already made some sensible improvements to the infected behavior. 🙂 

     

    Here's a preview of the next changelog :

    Quote

    v105
    * fixed script compilation error
    * added Entity Catalog to Infected Faction
    * fixed BT using obsolete scripted nodes
    * fixed infected being unable to sprint and attack at the same time
    * Infected can now jump over obstacles in their idle state
    * BT tweaks & optimisation

     

    I'm considering lowering their sprint speed even more, now that they will happily try and grab their target while chasing it - previously they had to slow down a bit before they could attack, which made them easier to evade...

    I'm not sure how much of a threat they were in a solo/coop environment though, so any feedback is welcome in that regard.

     

    I'm going to take the time this week-end to rework their textures, fix some minor errors, and maybe adjust their audio configs; the update should be ready in a few days. \o/

    • Like 2

  10. @PolskiOski : Thanks for reporting!

     

    I'm working on a fix right now; beyond that error (already fixed on my dev build), that update broke the AI BT nodes... again. 😅

    While I fix them, I'll probably tweak their behavior a bit more (their pathfinding needs improvements) - the next update should also feature improved textures for the infected.

     

    Sorry for reacting a bit late on this folks, RL work has kept me away from doing much modding lately. 😕 

    • Like 2

  11. 11 hours ago, Undeceived said:

    Sorry to dig out this old thread. I thought that it would solve my problem but it didn't.

     

    You guys @Grumpy Old Man @GEORGE FLOROS GR talked about how to prevent the player from opening a backpack, when he selects the action "Search backpack".
    But how can I prevent the action itself appearing in the first place?

     

    As far as I know, you can't modify actions defined in configs; the only way to do that would be to override the config (either in cfgActions or in the object's class config), and since this can't be done from the mission file, you'd need a custom mod just for that. 😕 

    • Like 1

  12. 9 hours ago, redarmy said:

    sorry for necroing an old thread however i never got around to looking at this fix years ago. Im unsure where or how i call this syntax in order to fix the issue you described. Do i need to edit the PBO or can i edit something in the init of mission,and if so how exactly ?

    I'm not on my "arma" PC right now, but yeah, this would require to unpack, edit & repack a PBO file.

    I reckon installing AGM Goggles is a much simpler solution : https://github.com/KoffeinFlummi/AGM/wiki#agm_goggles  😉 


  13. Not sure I understood the goal, but I reckon you're looking for something like this ?

     

    all_markers = ["rm01","rm02","rm03","rm04"];
    unused_markers = all_markers;
    
    _selectm = selectRandom unused_markers;
    unused_markers = unused_markers - [_selectm];//remove it from our list so it gets picked once only
    if(unused_markers isEqualTo [])then{
    	unused_markers = all_markers//if list is empty, repopulate it for next time
    };
    _posm = getMarkerPos _selectm; sleep 1;

     

    • Like 1
    • Thanks 1

  14. 10 hours ago, EO said:

    Maybe I should have provided more context...

    I'm already using the setFog command in specified areas of the map activated by triggers, so ideally I want the overriding fog forecast to stay the same both before and after the player leaves these triggered zones, hence my original question.  

     

    I can't remember why exactly, but setFog would tend to cause transition issues in my scenarios; I've been using a small script to constantly adjust fog from its current value to avoid that.

    Here's a modified version that should work as an example :

    //fog.sqf
    mystforecast = 0.1;
    handle_forecast = 0 spawn {
    	while {true} do {
    		default_forecast = (rain*0.75) max (overcast*0.175);
    		mystforecast = call {
    			if (isNil "override_forecast") then {
    				default_forecast
    			}else{
    				missionNamespace getVariable "override_forecast"
    			}
    		};
    		sleep 5;
    	};
    };
    handle_fog = 0 spawn {
    	while {true} do {
    		_slp = 0.05 + random 0.1;
    		_fog = fog + (0.001 * ([-1, 1] select (fog <= mystforecast)));
    		0 setfog [_fog max 0 min 1, 0.0075, (getPosASL cameraOn)#2];
    		sleep _slp;
    	};
    };
    
    //override from trigger
    override_forecast = 1;
    
    //cancel override
    override_forecast = nil;

    Not actually tested, but if you replace your setFog commands in your triggers by the last bits above, it should do the trick. Note that fog is dynamic with this example, and depends on rain and overcast; you can just change the 'default_forecast' variable with a fixed or random value. 😉 

    Same for the '_slp' variable in 'handle_fog' if you want faster or slower transitions.

    • Like 2
    • Thanks 1

  15. 16 hours ago, EO said:

    [...] regarding audio, I still prefer to have my zombies almost deaf as I still find their reaction to gunshots is to sometimes revert to that “conga” style path finding especially around road networks which is sometimes a little immersion breaking.

     

    That's an interesting input - there is indeed a difference in their pathfinding between their "acquired visual target" and "heard a gunshot" states. In the former state, their pathfinding is regularly updated as long as they have visual contact; in the latter, it's generated only once per gunshot as long as zeds don't have a visual target...

    I reckon it's a good lead to eliminate the last "conga lines" - I'll certainly look at polishing the gunshot reaction part for the update. 😉 

    • Like 1

  16. 18 hours ago, EO said:

    Hey @haleks

     

    For hand placed zombies, is there a way to control their visual and audio detection independent from the Ambient Zombies module settings?

    I have my zombies spawned by the module configured to be fairly docile but I'd like my hand placed zombies to have more of an "edge".

    My hand placed zombies are already running the code you shared a while back that "tethers" zombies within a certain radius.  

    :icon_biggrin:

     

     

    That's impossible right now - they're using yet another global variable for that.

    However, I just made a little change in the code that will make it easy to override the visual detection range per zed with the legacy update : you'll just need to set a variable on them (this setVariable ["z_visual_coef", 10]), in the absence of an attached variable, zeds will use the global missionNameSpace one. That will work for visual detection, but audio is trickier to tweak, since the code is attached, not to zombies, but to regular units... One direct consequence being, if a mission maker decides to have a zombie with huge audio range, it may have a big impact on related functions performances. I will have to carefully consider if it's worth it, since the number of gunshots can go high pretty quickly in any environment.

    • Like 1

  17. 3 hours ago, MuRaZorWitchKING said:

    Hey @haleks, if you are still working towards that legacy patch, you should look into possibly changing up the animations for certain actions, I've been testing a lot of hold actions, etc... while working on my re-write and I stumbled upon what I think may just be another Arma bug.

    I've always been one to use medic animations for certain actions especially "AinvPknlMstpSnonWnonDnon_medic4" which almost simulates a "dig like" animation. 

    While testing respawns for MP compatibility however, I stumbled upon an issue where frames bounce from 100 all the way down to 15 - 25 while commencing an action with any of the medic animations. However, this only seems to happen when the player doesn't have a primary weapon, or any weapon at all. 

    At first glance I thought it was because the way my inventory handle is setup, but then I browsed over RVG's handle and they're pretty similar, so then I tested and tested and finally realized whenever you don't have a weapon equipped when you do an action with medic animations then frames crash - the frame drop is a quick one lasts for maybe 2 seconds or so, but the choppy-ness is VERYYYY notice-able and some may wonder what is happening, I tested repairing a vehicle without a weapon and same frame crash, even removed my inventory handle and used RVG's just in case it had something to do with that but same bug happened.

    May be something to look into, may even be my mod since I have some separate .pbo files added and they run in the background, just a heads up!
     

    Thanks for reporting buddy!

    This was tested locally in editor?


  18. On 3/15/2023 at 7:25 AM, EO said:

    The tent is only shown as an example, plus Ravage tents are already configured to have an inventory, I created the configs for it. :f:

    The request was aimed at @haleks as a possible QoL improvement as part of his legacy update. :icon_biggrin:

     

     

    I will look into it, but iirc, magazines won't show up in the editor if they aren't linked to a weapon or an object (I guess "standalone" mags aren't supposed to exist from the engine point of vue).

    @Nemanjic if we're talking about the same issue, do you happen to have a link to the discussion?

    • Thanks 1
×