Jump to content

haleks

Member
  • Content Count

    3852
  • Joined

  • Last visited

  • Medals

Community Reputation

7792 Excellent

About haleks

  • Rank
    Chief Warrant Officer

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

12121 profile views
  1. haleks

    Remnant

    @Valken: Safehouses will work pretty much the same way (at least in SP). 😉
  2. In my experience it really takes overusing the most demanding commands to actually cause a freeze when called (like allMissionObjects or nearestTerrainObjects) or processing very large data, and usually such scripts will tank framerate when run scheduled.
  3. haleks

    Remnant

    Phantoms in this situation are most likely hesitating on the whereabouts of their target. Whenever someone throws chems or flares (or anything), phantoms pick up that sudden movement and are attracted by it - but they will "forget" it pretty quick since it is not a valid target, and will wander around the position where this happened. The problem that sometimes occurs is phantoms detecting the throw as soon as it happens, leading them directly to you... I might need to add some sort of reaction time to prevent that, but it's worth noting that distracting phantoms this way will be more difficult than before in any case... The last update toned down their tracking abilities : it can play in favor of players wandering too close, but it also reduces the efficiency of that distraction method. Once the first Aradus beta is released, I'll start adding more advanced features to interact with phantoms - the "throwing stuff around" is meant to be a basic, low efficiency tactic to avoid them and was a bit overpowered in previous versions. Speaking of Aradus, I've made good progress recently! The "private room" bit, aka the player's hub, is almost done. \o/ Right now it's only implemented for personal safehouses (Vrana facilities will offer that feature too, once they're done); those are structures that give access to an underground bunker, from where players can adjust their loadouts, plan their trips or sleep the night off. Once Aradus is ready to be ported to other terrains, safehouses will come as editor-ready compositions for mission makers. WIP screenshots : Right now I'm aiming to finish the custom endurance system, and to add a few light survival stuff; a first beta release should follow - but don't expect anything too fancy, as it will mainly focus on testing performances at first...
  4. haleks

    Remnant

    Hey guys! o/ Still working hard on Aradus - and tweaking Remnant along. I took some time to rework some of the phantoms behavior scripts recently, and came to realize that a misplaced code block was breaking their "investigative" state... They would home in on their target pretty much every time and end up hovering right over it if they happened to lose track of it - that was not intended behavior (and it took me more time than I care to admit to notice it). So yeah, update time! Fixing the investigative state alone drastically changes how phantoms feel up close - especially if you play hide-and-seek with invisible ones - and several other parameters have been tweaked to make them more interesting to interact with. This update significantly alters the phantoms AI - I don't think the overall balance changes much, but in case you need to adjust the difficulty of your own missions, I suggest increasing or decreasing their "sensitivity" as needed via the Settings module. Here's the complete changelog : Download : Remnant v0.2.7 Enjoy!
  5. haleks

    Ravage

    Haven't touched that mission in a long long time, but iirc it should be a matter of copy/pasting the content of the scenario to the new one (there should be a bunker object that acts as the exit point for the intro sequence, you'll need to find a sweet spot for it), and then doing the same with all files from the original scenario except for mission.sqm.
  6. @mrcurry: use "super simple objects" locally, their simulation is disabled and they won't generate any traffic on the network. But for MP, you'll have to design your code so that replacement objects are identical on all clients - without broadcasting anything... My current approach with a Remnant related project is to use the data of the original vegetation object to determine the type and positioning of the replacement; but if you choose to do all those calculations at once before mission start, you're looking at increased loading times (possibly more than an added minute)... I ended up using a mix of both : environment around the player is processed during the initial loading screen, and the rest is done dynamically as the player moves around. Given the amount of objects to manipulate in any case, I strongly suggest constantly testing the performance of your code. ^^
  7. If it's done before mission start, it won't affect performances at all. @Fr3eMan: if you want to do that for a single player scenario, keep in mind that the amount of data and objects might crash the save system.
  8. haleks

    m3mory

    I really don't know - that's a completely different problem... I've been working on & off on a custom persistency framework for Remnant, one that would work in both SP & MP... I'm quite happy with how it's shaping up to be, but it is very far from completion. The cool thing is that it is designed to allow mission makers to push any kind of data to be saved (as well as what should be done with said data) with minimal configuration, on the other hand, that modular approach is more difficult to build... And on top of making a persistency system from the ground up, there's also a few potential exploits to solve (something I've been stuck on for a few days now). To this day I don't know yet if the next Remnant expansion will use that system, or if I'm going to stick with the m3mory approach (cleaning-up data before the engine saves) - both have their advantages and problems. But if I do finish the custom one, I'll most likely release a standalone version, stripped from Remnant specific features.
  9. haleks

    m3mory

    And it's on! M3mory is now available on the workshop. Since the mod is meant to improve user experience for long-term scenarios, I've made sure it can update itself from any saved file that has a m3mory hook : you won't need to restart your favorite SP missions if m3mory is updated. A quick note : in theory, m3mory could be used to repair heavily cluttered save files, but apparently it's impossible to inject new scripts or event handlers in a mission that has been initialized already...
  10. haleks

    m3mory

    Mod version : 0.10.0 (2021.11.08) m3mory Hello people! Here comes a new tool to keep your Arma3 saves in good health... M3mory is a tiny mod that will keep the size of your save files in check and ensure they remain usable for as long as you want. It doesn't require any configuration : simply load the mod whenever you're playing in single player, and it will automatically do its job anytime the engine saves your progress. Works with all types of engine saving event (mid-game, save & exit, autosaves - including during Alt+F4), in any mode (campaigns, scenarios - official or custom). Why? The engine indiscriminately saves any change made to terrain objects, amongst many other things : any opened door, any damage to any structure, any broken tree, wall or fence, ends up in the file. This means that no matter what, the size of your saves will increase - either gradually over time or dramatically depending on several factors. It can take some time in a "quiet" and well designed scenario, or it can happen very quickly in more intense, all out war scenarios. Loading or saving takes more and more time as this happens, and, on the bigger or denser terrains, this will cause the engine to crash eventually... While it may not be problematic for the most typical mission designs, it can potentially cause game-breaking issues for "endless" type or very long scenarios. M3mory is designed to solve this problem by excluding unnecessary terrain-related data from the save system. Every inconsequential object that is not in the player's vicinity is reverted to its original state whenever progress is saved, with the exclusion of destroyed structures (avoiding any potential conflict with mission critical objectives). This effectively puts a hard limit on the maximum size of your saves, or rather, it limits the impact of terrain objects interactions on your save files. Keep in mind that the mod doesn't interact with scripts or variables, which also have a direct influence on the volume of data that is saved. A few considerations Initial Test Results Download Want to support my work?
  11. That was fast o_O Thanks @killzone_kid, this is going to be very useful! \o/
  12. @killzone_kid: It's mostly ruins spawned on hidden structures, wrecks, vegetation and rocks. There're all stored in global variables, which are deleted after running the delete command : fnc_save_eh = { //terminate all procedural systems { terminate _x; } forEach aradus_ex_systems; //revert all terrain edits { _x hideObject false; } forEach aradus_ex_hiddenobjs; aradus_ex_hiddenobjs = nil; { _x switchLight "AUTO"; } forEach aradus_ex_lampobjs; aradus_ex_lampobjs = nil; { deleteVehicle _x; } forEach (aradus_ex_spawnedobjs); aradus_ex_spawnedobjs = nil; //delete all rcks from veg sys { _so = (missionNamespace getVariable "aradus_var_spwnd_rcks") get ("myst_rock_"+str _x); deleteVehicle _so; } forEach aradus_var_veg_hndld; //delete all wrecks from roads sys { _o = missionNamespace getVariable ("aradus_var_" + "m_s_r_o_"+str _x); deleteVehicle _o; } forEach aradus_var_r_hndld; //clean up vars { missionNamespace setVariable [_x, nil]; } forEach ((allVariables missionNamespace) select {(_x find "aradus_var_") isNotEqualTo -1}); true }; From what I saw, all deleteVehicle commands are properly registered and executed, and all variables are destroyed right away; but I think the sheer number of objects (more than 100.000) slows things down and causes some objects to be deleted a bit late. I've reworked the script to work from a loading screen, which seems to speed things up enough - the only remaining problem was the "loaded" EH triggering the reboot process twice, since its execution also get saved from the fnc_save_and_reboot_systems function (unless I use a longer delay method, but that's unreliable), which is needed for mid-game saves. I solved that with a simple variable check : aradus_fnc_sys_init = { if (!isNil "aradus_var_process") exitWith {true}; aradus_var_process = true; aradus_ex_hiddenobjs = []; aradus_ex_spawnedobjs = []; aradus_ex_lampobjs = []; aradus_ex_systems = []; //terrain edits call arad_fnc_ds;progressLoadingScreen 0.33; //register & spawn procedural systems aradus_ex_systems pushback (call arad_fnc_vegetation);progressLoadingScreen 0.66; aradus_ex_systems pushback (call arad_fnc_roads);progressLoadingScreen 0.99; true }; _sysreboot = addMissionEventHandler ["Loaded", {//used for 'save & exit' type call aradus_fnc_sys_init; }]; [missionNamespace, "OnSaveGame", { startLoadingScreen [""]; call fnc_save_eh; 0 spawn { waitUntil {isNil "aradus_var_process"};//defined in aradus_fnc_sys_init function call aradus_fnc_sys_init; endLoadingScreen; }; }] call BIS_fnc_addScriptedEventHandler; Not sure why the variable check wasn't working when I posted, but I was pretty tired, so it's likely that I missed something then... The new script seems to work just fine right now, but still, I think that stuff would be simpler to do, and cleaner, if saveGame returned something once it's done writing. ...Or better yet, a way to exclude some type of objects or data from being saved. Even without the "I wanna spawn tons of stuff" problem, vanilla saves get bigger and bigger in 'endless' scenarios (partial damage to structures, broken walls etc...) - I think that's why Antistasi uses its own save system.
  13. haleks

    Remnant

    Hello people! Remnant has been updated! \o/ This is a small update (well, "small"... I actually spent the weekend fixing stuff on this one...); I've decided to split the Big One into several smaller patches and release new features and tweaks as I finalise them, in order to ease the workflow on my end. Considering the time I spent fixing a last minute, game breaking issue, I reckon it was a wise decision. Anyways, here's the changelog : The "Do Not Linger" scenario is now using the basic components of the Terrain Modification tech : I've finally managed to work around the limits of the vanilla save system! Malden is now as desolated as can be - every building that has a proper ruin model is now destroyed, every single bush or tree is gone and all road segments are cluttered with objects (wrecks and vegetation)... I don't have the stats right now, but that is a huge amount of edits and objects. And the average framerate is actually higher compared to the previous version. Adapting the save system to work with the new tech was... painful (I almost gave up on that one). There are a few minor downsides compared to the vanilla saves : players are limited to one save only, and it is no longer possible to restart from the mission once the game has been saved - you'll have to exit the mission and restart it from the menu (that, and the engine no longer autosaves when Alt+F4 out of the game). Not a big deal I reckon. Also, do note that saving will trigger a loading screen : no worries there, this is intended behaviour. I strongly encourage you guys to (re)play the showcase and test the new tech, and to report any issue or oddity you may encounter - hopefully, there won't be any... ^^' The Terrain Modification system will need more tweaks to work with Altis, which is a wholly different beast in terms of size and number of objects to edit or spawn, but I'm quite happy with its performances on Malden. Fighting Phantoms back should feel a bit more satisfying now - I'll probably redo the Livonia scenario to showcase that, but that'll have to wait a bit (I'm completely spent right now)... The Timefall module has received substantial changes too, and the Vegetation VFX looks a bit better now. I suggest using the same condition parameter as the one you use for the Phantom spawner module : this way, "Timefall flowers" will serve as visual clues indicating that Phantoms are around... Note that Timefall won't trigger if the ingame "rain" value is below 0.1. And one last note : the "rest" mechanic of the new Health module is meant to complement the usage of First Aid Kits : health will only regenerate if the player's damage value is at 0.25 or lower. I hope you'll enjoy this update! Special thanks to my long time supporters on Patreon! 😉 Download : Remnant v0.2.6
  14. I have, but it comes with its own problems... When using it to reboot the population systems, I end up with double the expected amount of simpleObjects... I spent hours debugging this, and here's the weird thing : I've removed the "rebooting" part from the save function, and I have 0 simple objects when loading a save - as expected. As soon as I add a Loaded EH, I have twice as many objects (even if I use a variable check to prevent executing the reboot function twice), which doesn't occur when rebooting from the save function. That's driving me crazy... >_<' EDIT : I think I just found a workaround... by exploiting the issue I mentioned. Since the reboot process ends up being saved, I use it instead of a Loaded EH : deleting objs & variables gives enough time for the engine to save without crashing, and the reboot is resumed upon loading. Probably not ideal, but it'll have to do...
  15. Small suggestion for future updates : It would be super nice if the saveGame command could return 'true' once the engine is actually done saving... Right now there's no easy way to detect that, and the OnSaveGame EH is pretty much useless in that regard. EDIT : a practical example : I have a scenario that spawns enough simpleObjects to crash the save system, so I'm using a script to destroy said objects before saving : fnc_save_and_reboot_systems = { _targetcount = (count (allSimpleObjects []) - count (aradus_ex_spawnedobjs + aradus_var_r_hndld + aradus_var_veg_hndld)); call fnc_save_eh;//a function that destroys thousands of simpleObjects and variables waitUntil {count (allSimpleObjects []) isEqualTo _targetcount};//it takes some time to actually delete objs, so this makes sure objs are actually deleted before saving saveGame; waitUntil {isNull findDisplay 13};//wait for the "saving..." display to disappear call fnc_sys_init;//save is supposed to be done, so we can start repopulating the map }; 2 problems with this : - I found that deleting objects takes some time, resulting in the fnc_save_eh function returning 'true' before objects are actually deleted (therefore said objects end up being saved and cluttering the save file)... This is solved with the waitUntil _targetCount stuff. - Even if I wait for the "saving..." display to disappear before repopulating the map with the fnc_sys_init function, newly spawned objects end up being saved, indicating that saving wasn't actually finished, and the save file is cluttered with the objects and variables I was trying to exclude... It's a pain in the ass to deal with...
×