Jump to content

funkyfranky

ED Closed Beta Testers Team
  • Posts

    2523
  • Joined

  • Last visited

  • Days Won

    4

Posts posted by funkyfranky

  1. When a pilot ejects, a static object is created at the position where the parachute goes down. This static object can be retrieved by the initiator of the rather new S_EVENT_LANDING_AFTER_EJECTION event.

     

    However, important scripting engine functions like :getName() or :getCoalition() fail when applied to the static object representing the pilot.

    2021-05-01 20:13:21.291 INFO    SCRIPTING: Trying to get the name via Event.initiator:getName()
    2021-05-01 20:13:21.291 ERROR   SCRIPTING: Mission script error: [string "C:\Users\frank\AppData\Local\Temp\DCS.openbeta\/~mis00003FEF.lua"]:38: Unit doesn't exist

     

    The :getName() function is important for identification and for house keeping. The :getCoalition() function is obviously important to know who would send a rescue team to simulate a SAR mission. Other functions like getPosition() and :destroy() work like expected.

     

    Simple example mission attached. Setup is a Hornet with zero fuel so the pilot ejects right after mission start and the track file is kept short.

    EjectedPilot.trk

    Hope this helps.

     

    PS: I would prefer a normal unit as ejected pilot (not a static object). This would allow to pick up the guy with a helo.

    EjectedPilot.miz

    • Like 1
  2. A group of four MLRSs is rearming as shown in the pic. However, only three of the four units get new rockets. The reason is probably that the fourth unit is too far away and not in the valid "rearming range".

     

    The group got a waypoint very close to the rearming truck. But as we cannot control individual units of a group, it can easily become impossible to rearm a whole group.

    Needless to say that the issue becomes more likely with increasing group size!

     

    rearming.thumb.png.31e6b221faeac2bb9347e01e4c9155be.png

     

     

  3. Hell, no! Please don't tell me that Heatblur puts button assignments for all Tomcat versions under one category?

    That means an unnecessary waste of controller inputs on our side. For example, any button you assign to the "Mid Compression Bypass CB Pull" for the A-model will not be usable in the B-variant.

     

    Please make this a clean solution and differentiate between the models.

  4. I really like the new feature of the historical list of units.

     

    However, I noticed that this is a "global" setting, i.e. once turned on or off it will be that for every mission I load.

     

    I would prefer this setting to be "per mission", i.e. off by default if a new mission is created. And once activated or deactivated it would only apply to that very mission and not to all missions I load.

    In other words, the setting would be saved in the miz file.

     

    Hope that makes sense.

     

    Thanks!

  5. When disembarking (from Mi-8 for example), soldiers are placed close to each other, and, when receiving order to move somewhere, they can not assume selected formation and spin around in one place. Same occurs with tanks too, but you can move tanks apart manually. With sufficient distance between individual units move orders are executed normally, units have enough maneuvering room to form column/line/whatever formation is selected.

    Sound like this bug https://forums.eagle.ru/showthread.php?t=288405

     

    But there is a fix coming according to BN.

  6. Thanks for your suggestion but I don't want to manually place each static type in ME.

    Okay, no problem. Which static object do you want to spawn exactly? I'm not sure if the category returned is the one, that is required as input for the static template. I even think there is no way to extract that via scripting. I usually get that by looking in the mission file that is located inside the miz.

     

    But it is definitely possible to spawn all statics without any template in the mission.

  7. The stage we are at with this is that if it was to be implemented it could create more problems for the team and DCS that would require a lot more work, hence the reluctance to enable it.

    Oh, I surely hope it's not an easy fix. Otherwise six years would really be a long time ;)

     

    As mentioned I have brought it up with the team again, but can make no promises.

    And I am very grateful that you did that again. This is not to blame the messenger and all in good faith. Similar to Grimes, I had already given up on this ever being fixed. It's something we can work around, but the workaround is not working rigorously due to another DCS bug affecting multicrew aircraft. So for those, we are currently in a situation where even the workaround of the bug is broken. And that is the point where working around stuff is simply getting "a bit" too much.

  8. I will ask the team about it, but can not make any promises.

    Thank, BN. I hope you will be more successful then the last couple of times you said that.

     

    But don't worry, this is just one of the most important (MP) events in the game. Fortunately, there is a workaround otherwise it would simply not be possible to create player specific stuff like F10 menus and the like.

     

    Sorry, if I sound a bit sarcastic. But we have been begging on our knees for this to be finally fixed and all we ever got was "I will ask about it", "it takes time".

×
×
  • Create New...