haleks

Thanks mate ! \o/ By the way, that little MGI_dryCheck function came in handy. 😉

It's night and day compared to the Arma3 suite. The only tools I ever used before Enfusion were DsUtils, TextView and the AddonBuilder, and that's it. I remember opening the FSMEditor a couple of times, and deciding that, nope, thank you but I'll write my AI in SQF. ^^ Reforger : once I open the Workbench, I stay in it. Having everything you need in one place is very comfortable; being able to edit and test on the fly without having to reboot anything is mindblowing to me. The tools are very well made, and for once we have graphical interfaces that are actually well done : BTs were surprisingly easy to get into, and sound design seems to be very similar (the audio setup for the infected is going to be much more detailed than what we had). Animation, though, looks like another beast... In terms of UI and accessibility, Reforger sets the bar high. The fact that I no longer need to "hack" my way through scripts (so far) to achieve what I want just says it all : at the moment, the new Ravage has one small custom script - in Arma 3, at this stage, the mod would be 75% of painfully, slowly written scripts already...

A small suggestion, if I may : The doc on Enforce presentation is fine, I think. But judging by the kind of questions that pop up often, I reckon the From SQF to Enforce Script page could use additional information. The examples and applications in the doc are mostly abstract; presenting concrete case illustrations would help people to quickly put what they read in practice - stuff like how to get a position, return team members or collect terrain objects. It would also touch on new concepts such as casting, and help understand why or when it's needed. Basically, just a handful of concrete examples to wrap up and illustrate the most common practices would be nice to have. The "Object" notion in Object Oriented Programming is somewhat confusing when you come from procedural coding (you just don't know what the fuck is an object at first, or why you have to deal with instances), and the bottom-up approach adds another layer of confusion. The documentation lacks a couple of things to really get you started, IMO. Explaining how, for instance, to access methods in an entity's component or presenting a basic layout of the class hierarchy would give a clearer picture. Right now we have to constantly work our way up through auto-completion searches, which I find to be a tad frustrating. And I don't even know if what I just typed makes any sense - OOP is that weird to me.

I couldn't resist... I did a few tests yesterday and managed to have them climb obstacles using a wacky combination of logics in the BT. It worked pretty well in the tests, but zombies would briefly hop in place when loosing track of their target. Out of frustration I guess. All I needed was to write a proper script to determine if climbing is needed and possible, the rest is done with vanilla components. The feature is available as a scripted BT node and can be plugged in on any kind of unit. The implementation is a bit rough at the moment (I'll have to fine-tune it and find the correct height threshold to abort the action), but it's already a game changer... Next-gen ravagers are going to need higher walls to protect their camps. 🙂

I don't think a BT approach would fit the situation - we would have to constantly monitor a very specific action, and in any case, some amount of coding would still be required. A more straightforward and efficient solution would be to override the component attached to door actions (that would be the SCR_DoorUserAction.c file in scripts/Game/UserActions/). From there you have access to detailed information, like how wide open is it or who is opening it. Then you can just plug in your own code to force nearby entities to look at it - and that would work every time a door is opened, be it by players or NPCs.

What happens when you go "okay, just one bit of polish here and there" : The main tree has grown quite a bit. That's the target acquisition sequence along with the chase & attack processes. The idle routine is handled by a smaller tree : Right now the infected AI is pretty much on par with the old zombies from Arma 3 : they select their target in a similar manner, will investigate their last seen position etc. They react to occupied vehicles too, but have trouble attacking them at the moment. I did have a few difficulties to fine tune the AI so it can perform inside buildings, but I think I got something solid enough on that part - they can run in them corridors and are much more dangerous than before... I reckon it's time to work on sound design if I want to release an Alpha soon, but I already have a few ideas for future AI iterations - how terrifying would it be to see those infected climb up fences and stuff?

Another one !

Hello gents, I've pushed a small update for Aradus : Those are updates to the mission file, so you'll need to restart the scenario. @RZNUNKWN: this should be fixed now, let me know if it happens again. 😉

@sarogahtyp Thank you for this. I was looking at setting up something similar to have common functions readily available; I find the extreme encapsulation in OOP to be, frankly speaking, a pain in the ass.

From what I see, a lot of features are somewhat present in the code but not complete or fully implemented. I saw mentions of "goggles" eventhough we don't have a slot for it in inventory, there's a "holster weapon" action but no keybinding for it, etc... I even saw a comment about, maybe, turning "gadgets" into melee weapons, such as shovels.

Just precaution, and force of habit : using _this will auto convert the argument into an array if the programmer forgets to pass it as such.

In triggers, the 'this' magic variable isn't the trigger itself, it's actually its Condition parameter. What you want is 'thisTrigger' : https://community.bistudio.com/wiki/Magic_Variables#thisTrigger [thisList, thisTrigger] execVM "Spawning\spawnVehs.sqf"; _this params ["_arrayOfEntitiesInTrigger", "_trigger"]; _spawnPos = position _trigger;

Current version : 1.1 Welcome to the Discipline Mod! The purpose of Discipline (previously known as "HAL Protocol") is to improve the vanilla audio & radio landscape during infantry combat in Arma3. This addon is based on config changes and disables excessive or annoying behaviours such as constant and irrelevant combat shouts from the AI or groaning sounds when injured. All files are signed and MP-ready. Features : - All variations of "Cover me!", "Covering, go!" etc. have been disabled in both stealth and combat modes; constant shouts such as "Ready to fire!" have been completely disabled. AI units still report spotted target, acknowledge orders and report in as usual, only useless and repetitive behaviours have been edited. Each language has its own PBO file (English, Greek, Persian, French and Chineese). - Suck it up and carry on like a pro! Moaning sounds when injured are disabled. - You can also disable breathing sounds when fatigued with the "NoBreathing" file. - Tired of your avatar or team mates calling out targets before you actually see them? Use the "NoContactReport" file and enjoy pure tension during your patrols. All files except HAL_discipline are optional and can be removed to tailor your experience. License : APL-SA: Arma Public License Share Alike (APL-SA) Uploading Discipline on Steam Workshop is stricly forbidden. Changelog : Download : Discipline v1.1

It's an absolute blast ! Pretty much all I ever did in Arma 3 has been scripting in SQF; C++ being another beast, I find myself doing a bit of everything except scripting. ^^ It's refreshing; so far I only wrote that one single script for Autowalk, currently the new Ravage version has zero script in it. Oh yeah, by the way, I started a new thread for Ravage Reforged :

Okay we're getting somewhere... BTs are completely new to me, but the AI set up is going surprisingly well. After about 2 days of trial and error, I got something pretty solid for the most basic behaviors : zombies can prioritize and select target, chase said target and melee them once in range. And the tree isn't too messy (yet) : Now, I need to program some kind of "idle" routine - and I think we'll have a pretty functional AI already. And melee is working too (I thought I'd have spent weeks on that one) !

Behavior Trees, part 1 : Target Detection.

Please read the forum rules (merci de lire les règles du forum) : https://forums.bohemia.net/guidelines/

Tiny update : If you find that Autowalk gets in the way of other actions, let me know. 😉

Can we hope for a proper enfusion syntax highlighting within code tags on the forums (or at least something that is easier to read)?

Yeah they do have different settings compared to DNL - and those may change in the future. They take more time now to notice a target, that's why they have a tendency to reveal themselves at the last minute when you walk slowly. For now, I suggest making sure they aren't actually onto you before throwing anything. The next feature I'd like to add to Remnant/Aradus would allow you to make it past these close-call encounters without having to just wait for the phantom to move on. But until then, I'm afraid you'll have to rely on chems. Programming uncertainty in AI behaviour is one tricky thing to balance. ^^'

Thanks guys. 🙂 iirc, you won't have a notification until you reboot all 4 relays, but the task marker should point you to the closest relay that needs rebooting. I'll probably tweak the main objective and have one sub-task for each relay : rebooting them will progressively unlock the Human Activity Mapping feature (right now it's only enabled once all relays are active). The bike, which is a hidden easter egg right now, will probably be easier to find too. Remnant/Aradus for Reforger is something I've been thinking about. Some aspects like assets and terrain creation will be easier I reckon, plus, I can see a 'shoes wearing out' script, now that the loadout system is more detailed. ^^ Phantoms may be tricky though...

Right now the duration is fixed (you can't feed on one nest for more than x seconds), and usually your hunger level will return to 0 before it times out. I'm looking into tying it to the hunger variable to make it dynamic and more instinctive. The current implementation is a bit confusing, and the stamina/hunger UI has a minor bug when updating - that should be fixed with the next update, along with other small issues. In any case, the action disappearing after some time is intended - them cryptobiotes don't like being eaten and will hide. 😉

Technically, we don't have mission files per say anymore : everything, including mere scenarios, is an addon in Reforger, so the mod/mission distinction doesn't exist anymore. Maybe we could use a "mission/scenario" tag when appropriate?

Nope, it's safe to use it. 😉

Hey guys, Finally, the first version of "Aradus" has been released : Polishing the current prototype took more time than I thought, but I think the result is solid enough for a demo - and to be somewhat enjoyable. As pointed out in the workshop description, it's very much WIP and incomplete in terms of features/story/gameplay. Right now I'm just trying to make sure the foundation is robust enough before I add more features and start working on the actual scenario : on the technical aspect, Aradus is my most ambitious project, and its procedural generation system is something I never attempted before (not to that scale anyway). The demo is a slow paced scenario, so please, take your time with it, and let me know how it runs. I don't expect anyone to actually complete the main scenario's objective (that's more or less a placeholder), but try to reboot the first relay if you want a rough idea of what the demo has to offer. A considerable amount of work has been put into keeping you guys immersed, hopefully this tech demo will provide memorable sensations already! 😉 EDIT : I chose not to create any dependency for the supported addons, but I suggest loading up the Scion Conflict mod when playing Aradus.