Jump to content
Bohemia Interactive Forums

baermitumlaut

Member
 View Profile  See their activity

  • Content Count

    71

  • Joined

  • Last visited

  • Medals

Posts posted by baermitumlaut

  1. Posted

    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.

    • Like 1
    • Thanks 1

  6. Posted

    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?).

    • Like 3

  8. Posted

    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.

    Spoiler

    Noon, no overcast, comparison inside to outside. Too dark inside imo.

    RmjZDUZ.jpg

     

    Nighttime with full moon shining through windows. Full moon nights are quite bright, but I can't even see where the room ends.

    E6RYat4.jpg

     

    No AO vs HBAO+ High.

    y48k37N.jpg

    aWVfXFf.jpg

     

    Gray-ish environment lighting?
    tA6zsb3.jpg

     

    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.

    Spoiler

    Too dark inside with bright sunshine outside (no overcast).

    7jE5xHI.jpg

     

    Can you guess what overcast level this is?

    40SLNs6.jpg

    Spoiler

    No overcast, noon

     

    Way too dark inside with full moon shining in.

    4wRZQu3.jpg

     

    "Brightness bump" - note the time.

    lAwGS3c.jpg

    Csph274.jpg

     

    So in general I'd say insides are too dark now, and the contrast should be toned down.

    • Like 3

  9. Posted

    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

    • Like 3
    • Thanks 1

  12. Posted

    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.

    Spoiler

    Ad2fJI9.jpg

     

     

    Here's how it would look with 50% before, 50% after:

    FwezW2X.jpg

     

    This would already be better imo.

    • Like 11

  13. Posted

    Ace developers have to understand the basics of programing and inheritance, you don't mess up a base class for every one, but create a derivative for your mod so it can coexist with other community work.

    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.

    • Like 2

  15. Posted

    Is ace fast rope availability on modded helicopters controllable through config code during game play?

     

    EDIT:

    I was trying to use ace_fastroping_enabled = 0/1 but suspect the correct way is to create a custom FRIES.

    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.

  16. Posted

    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

  17. Posted

    Hmmm  My unit uses RHS, and ACE3 in our modset.  Without using any compat PBO's we are able to access fast roping from our CH47, some MI8 variants, as well as various others like Taru. However, we can't use it from the Vanilla GhostHawks.  

    I think we're going to have to experiment some more and see if we can find an exhaustive list of what will work and what doesn't right now.

    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.

  18. Posted

    Its it possible somewhere, to see a list of vehicles, ready for Fastrope, Vanilla and otherwise? Wich Vanilla helis are ready?

    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.

  23. Posted

    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:

     

    5kj3YZO.jpg

    • Like 2

  25. Posted

    ok I have something weird going on. Not sure if this needs to be sent to bug tracker or not. I just updated from steam, ace 3.5. Thought I would try out the new fast roping. Helos do nothing but fly straight up. I dropped all my mods except cba and ace. Made a simple test mission. I put down a helo gave it a move waypoint and first test it moved to the way point, went in and turned on fast roping, helo went straight up.

     

    As Max255 already said, fastroping is not really made for AI pilots. They recognize the FRIES as something they could collide with, so they try to avoid it and fly straight up. I'd recommend only using fastroping with human pilots.

    • Like 1
×