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.

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.