baermitumlaut

I didn't read through all of it, but I found the same issue there, in a similar variation. First you should know that you should avoid compile if you can, which is almost always the case (except for compiling files at game start of course), simply because it's slow and there's usually better alternatives. One of the few use cases of compile is compiling code that is saved in a config. Here is the line I'm referring to: [_newVeh, compile Format ["%1=_This",_varName]] remoteExec ["call"]; You're trying to make sure the variable name refers to the same object on all machines. This line has two issues however: you're using compile even though there are alternatives, which is a performance issue you're transferring code over the network and then executing it, which is a security issue The latter is particularily interesting. This line seems harmless at first, but it requires the server admin to allow using call with remoteExec, which is often blocked on public servers for a good reason. It allows an attacker to execute arbitrary code on any machine, which could be abused in various ways. You could for example try crashing the server this way. Of course, you can't use = here, because the variable name isn't fixed. However, you can use setVariable: missionNamespace setVariable [_varName, _newVeh, true]; Besides that, you have a large cluster of selects in one of the event handlers. You should replace it with params, which will look much nicer and more readable: (_destroyed getVariable "MGIrespVehDATA") params [ "_type", "_pos", "_side", "_fullOldCrew", "_varName", "_initDir" ]; That's getting a little off topic though.

@pierremgi What you're doing is the equivalent to instead of just copying a PDF, printing it, then scanning it, then saving the scanned file under a different name. It makes no sense at all. Please stop copy-pasting code that you found somewhere unless you understand what it does.

Please don't speak for a team you're not being part of. As it says in the OP of that pull request, it's still WIP.

The PBO opens the map automatically, so just start any mission with the PBO.

Repro PBO for the FPS drop issue Works perfectly fine in v18, but causes massive framedrops on the map in v19 (or any newer).

We (some ACE and ACRE devs) just found the issue for the FPS drops when opening the inventory or the map with ACE and/or ACRE. Because there is no way to create scripted namespaces, both ACE and ACRE use a custom location type, which gets created at [-10000,-10000]. Now both location types use an undefined draw style ("bananas in ACE, "acre" in ACRE) which is thankfully now being logged to the RPT as an issue. It seems like if there is any type of map control in the UI, that control tries every frame to draw those locations with said invalid draw style, apparently even when the control is invisble and even though the location would be far out of the rendered area, which then causes immense frame drops. Our solution was to just use the CBA_fnc_createNamespace function which does the same, but its location type uses a valid draw style. So yeah, proper scriped namespaces would be cool too (pretty please?).

Yes.

I have downloaded the dev branch and here are my observations so far: Altis Contrast from outside to inside is a bit too high as I said before, but not as bad as the screenshot in the OP. Inside is a bit too dark at noon and too dark with a full moon shining through the windows. Not sure if this is supposed to be intentional, but the brightness/time curve has a little bump in it, so between 7:20 and 7:50 it gets darker again. The same occurs in the afternoon when the sun goes down. I guess this is supposed to emulate the sun shining at a flatter angle? Felt a bit odd but not too bad. This is far worse on Tanoa, so I only made screenshots there. I did also notice that HBAO+ High is too intense in corners and I'm not sure if the environment lighting was changed, but it feels a bit grayed out. Tanoa Definitely worse than Altis, insides feel very much too dark with full sunshine outside (feels always cloudy) and full moon nights are too dark as well. The same brightness/time bump I described above occurs here, but at a much greater intensity. This does not feel right at all. So in general I'd say insides are too dark now, and the contrast should be toned down.

Hi @Incontinentia! Sorry, I've only seen you tagging me just now, I'm usually not active here. The state machine system is very similar to a FSM in its basics, as it provides states and transitions and you can model a finite (or even an infinite!) state machine with it. However, it is a bit more flexible than what BI offers themselves and its full power can be seen if you feed it with a list of things - it can work with anything that supports setVariable (objects, groups and locations would be the most common ones I assume). The magic here is that it checks the state and transitions of only one element of its list per frame in the unscheduled environment, so the same amount of code is executed every frame by the state machine, no matter the amount of AI (so absolutely no frame rate loss due to the amount of units in the state machine). This is a very efficient way to do controlled load balancing without relying on the scheduler or the scheduled environment in general, which would bog down your performance if you'd try to do a similar thing there (or even get slowed down itself due to other scripts blocking it). So let's compare this with an FSM. Let's say you want to run an FSM for each AI unit you have, like we do with the ACE3 medical AI. What would happen is that each unit will start their own FSM and we would let Arma and its scheduler take care of when what is executed. Which means depending on the current workload, a lot of the FSMs might get (partially) executed at once or only a couple. Depending on the FSM itself, it could execute a lot of code and slow down other scripts and general performance, or if the scheduler is filled with scripts to run, FSM performance will decay and our units would react considerably lower. The more AI, the more FSMs will run and the worse performance will get. Not ideal. Now if you use a CBA state machine instead, only one unit will get processed per frame. So if we have 50 AI units, this would mean that it would take 50 frames for a unit to get processed again, and if we have 100 units it would take 100 frames. At first glance this doesnt seem ideal either - the actual time between units being processed varies on framerate and unit count. However, does this matter? In most cases, no. First off, the same would happen with an FSM, but far less predictable due to the scheduler. Here, more AI means lower reaction time, but at in an easy to predict linear fashion. You could even run a seperate state machine for each 50 units or similar if you really need faster reaction time. The state machine also doesn't use the scheduler, so scheduled script performance will be unaffected by the amount of the AI in the state machine. Second, even 100 frames aren't an issue at all, that is 2 seconds with 50fps (the maximum framerate of a dedicated A3 server). If you really need to do time precise stuff (like animations), use CBA_fnc_waitAndExecute from within a state. Another advantage is that our code within the state machine can be fairly small, because we can expand it over multiple states and transitions. If you take a look at what code runs in the medical AI you will see why it's fast. By no means is the state machine system a solution to all performance problems. Your code will still have to be optimized, and you will still have to think about how to structure your code for what you want to achieve. The state machine system just provides a solid structure to build upon. If you want to know how to build a state machine, check out the examples I included in CBA: https://github.com/CBATeam/CBA_A3/blob/master/addons/statemachine/example.hpp https://github.com/CBATeam/CBA_A3/blob/master/addons/statemachine/example.sqf

It seems like you haven't read the OP: Feel free to provide your feedback on these improvements.

@genesis92x : I just saw that I was mentioned here regarding the CBA state machine stuff. I'm usually not active here on the BI forums, but I'm always online on the ACE3 slack, so if you need any help feel free to poke me over there.

This is worse than the original. White walls and floor will reflect a lot of light, the walls will never be this dark when the sun shines so bright The spot the sun shines through has too much contrast with the surrounding floor, this would only happen in the dark when a car light would shine through the window The god rays are way too strong, is the room filled with gas or a dust cloud? When removing the bright spots from the image, you cannot tell at all that this is supposed to be noon - I'd guess it would be bright full moon or very cloudy day with rain Is this how your room looks in summer? I don't think so. Here's how it would look with 50% before, 50% after: This would already be better imo.

We do not modify any vanilla values in base classes, we only add our own config values with an ACE prefix which help us make other mods compatible with our frameworks without them having to add any values themselves. I don't know why you think this might break other mods, because it certainly doesn't. Those 3 lines in the RPT will not slow down your game, they're are just a small warning to let you know why something might not work as expected. No need to panic.

It recently came to my attention how many addons use vulnerable userconfig files. Almost all addons that use userconfig files are able to get exploited to execute custom code, and I only found very few exceptions (don't worry, ACE is safe!). To help addon makers to fix their addons to stop such vulnerabilities in the future and to make it public so hacks that currently use these ways become useless, I decided to make a little guide on how to save and how to not save user settings for your mod. Below is a list with of methods to save user settings, each with a short list of pros and cons and a short example how it could be used and how it can be abused. What you need to know first If you didn't know yet, #include simply copies the content of a file into the #include line. It does not care what you include, it does not care about the file extension, it does not execute anything on it's own, it's a very "stupid" command if you want to say it like that. However, that makes it very abusable, too. profileNamespace Variables ProfileNamespace variables can be easily set with setVariable and are a great way to save settings for your addon. Because you can save raw datatypes such as numbers and booleans, these don't allow any possible attack points unless you save code in them which you want to execute. Don't do that and everything is fine. +fast and easy to use +can be set in game -need an interface to be set -cannot be changed on servers Example: Malicious example: Parsing files Parsing files manually (that means, you open a file and interprete its content manually without executing anything) is a safe way to read user settings. These files can be stored in the userconfig without any risks. However, it depends on the implementation of the parsing function how secure and how user friendly it is. I have implemented a safe parsing function for userconfig files here: https://github.com/BaerMitUmlaut/Arma-script-snippets/blob/master/fn_readConfig.sqf CBA also includes a YAML parsing function, you can find an example on how to use it here: https://github.com/CBATeam/CBA_A3/blob/master/addons/common/test_parseYaml.sqf +settings can be stored in a file & can be used on servers -safety depends on implementation -might be buggy if the user feeds you useless data Example: Malicious example: - Executing SQF files This is a very critical method. Make very sure that you are only doing this on the server! With this method, you save the settings as SQF code in a userconfig file, load it dynamically on startup and read its values. If this does not happen only on the server, the user can simply append any code he wants and it will get executed by your addon, even using signature files won't help with this! +easy to use +settings can be stored in a file & can be used on servers -very dangerous if not used only on the server -allows execution of any code the user puts into the file Example: Malicious example: Including SQF files This method can be exploited, no matter what you do. Do not use it! By including a file into your code, you allow that code to run within your (signed) addon. It cannot be detected and can do whatever it would like to do. This means that your addon can be the hole that lets malicious code run on a server. -allows execution of any code the user puts into the file Example: Malicious example: Including config files This method can be exploited, no matter what you do. Do not use it! By including a userconfig file into your config.cpp you allow that any custom config from the userconfig will be loaded. This could be changes to CfgVehicles (init event handlers!), CfgAmmo, or even worse, Extended Event Handlers. Those can only be used with CBA running, but so many addons require CBA anyways, so don't rely on that. -allows injection of any config changes the user puts into the file Example: Malicious example: Why you should be concerned Barely any addon that uses a userconfig files is safe. That means: a ton of addons are unsafe! I know of a few VERY popular addons that can be abused this way! This is a major issue, and you should as a server owner double check what kind of addons you have whitelisted. Rather take one off the whitelist than leave it on there. Thank you for reading!

Unfortunately that's not possible to do without causing issues due to some technical limits. You can find more information here: https://github.com/acemod/ACE3/pull/2794

I'm not sure what you mean with "during gameplay". You cannot change the config while the game runs, if you mean that. Otherwise, the helicopter needs the proper config for "accepting" a FRIES, but you do not need to create your own FRIES model if you don't want to. You can instead use simple attachment points or one of the existing FRIES. You can find more information about that on the ACE3 wiki.

You can equip helicopters with a FRIES with the following piece of code: [_vehicle] call ace_fastroping_fnc_equipFRIES With _vehicle being your helicopter. This function should be called serverside and is not public API (yet), so it might change at a later stage. @dvdbrewster: If you mean the ace_fastroping_enabled value in the config, 0 means you cannot fastrope from that helicopter, 1 means you can, and 2 means it requires a FRIES. All of this is documented in the ACE3 wiki. @Bamse & @svarun: I've heard of these issues and I am looking into them. I'm not sure what's causing it yet. @jinker: You should take a look at the following functions: ace_interact_menu_fnc_createAction ace_interact_menu_fnc_addActionToClass ace_interact_menu_fnc_addActionToObject

The RHS helicopters have the option to fastrope already because that's how the RHS configs are made. I can't tell Arma "only give the vanilla helicopters fastroping capability" because they inherit from the vanilla helicopters. Thus the attachment points for the ropes on RHS helicopters are way off and it's generally not in a usable state right now, which is why you should definitely wait for that compatiblity PBO ;) As Max already said, you need to synch an "Equip FRIES" module with the Ghosthawk or select the "Equip helicopter with FRIES" attribute in Eden.

In Vanilla you can fast rope from all helicopters but the Little Bird and some Taru variants. You can only fast rope from the transport and the bench variant of the Taru. As for mod helicopters, it is on the modmakers to make their helicopters compatible, I don't know who has already added compatibility. For 3.5.1 I have worked on the RHS compatibility PBO which will then add fast roping capability to the UH-1Y, the UH-60, the CH-47 and the Mi-8.

So you placed a Little Bird, synched it with the "Equip FRIES" module and on preview it did not show an error message? Definitely works for me, please check if you did everything correctly.

@kennyleif: you cannot fastrope from the vanilla Little Bird. Normally it shows an error message, but the BI function used for showing said error message doesn't work in Eden.

Did you synch the module with the helicopter, as described in the ACE3 Wiki?

What are you missing specifically? As written in the changelog, the ragdolls module has been removed because BI tweaked the ragdolls themselves with 1.56, deprecating the changes from the module.

Why would you do that? There's no need to replace the whole config. Nevermind, I think I misunderstood you. You can simply add stuff to an existing config. For example, I used the following for testing fastroping with the MELBs: class CfgPatches { ... }; class CfgVehicles { class MELB_base; class MELB_MH6M: MELB_base { ace_fastroping_enabled = 1; ace_fastroping_ropeOrigins[] = {{1.17, 0.06, 0.98}, {-1.17, 0.06, 0.98}}; }; }; This works perfectly fine as you can see here:

Please ready my post two posts above yours.