Delta99

The PLAYER_ENTER_UNIT has been a long standing issue. Typically I think people get around this by entering a spectator slot first then switch over to a regular slot. Can you test that to see if your original code fires in that case? Otherwise an interesting workaround.

Rather than doing this: BAIPlane = GROUP:FindByName( "BAI_Test#001" ) use an OnSpawnGroup() method of SPAWN to get the group that was just spawned. Then you can use that group in the rest of your code. Most likely "BAI_TEST#001" is not the group name or I think it is created with spaces. In any event, using OnSpawnGroup makes it so you couldn't care or know what the group name actually is that is spawned

Elaborate on this because I don't know what this means exactly.

I never had a chance to look into this fully even in the previous update. As far as I can tell there was an issue in the previous update that broke the OnEngineShutdown but it didn’t cause a DCS crash. It just wouldn’t delete the group. So I think they can look into what changes they made in the last two builds. Got bad two builds ago, got even worse in the last build. Thanks for doing a proper test Grimes for this latest one.

Oh damn. I thought it stopped working a while back. Or maybe it has for me or I don’t have the latest. So I just have been waiting for an update. I will double check things and see if I can get it going again.

It has been for ages, just never worked well if at all. Or it was problematic on a subset of systems or something. Sometime in the last month or so after some update it started working better for me.

Yeah, I asked Grimes again and we discussed it further. I'm sure he said the opposite before but no matter. It looks like you have decent test cases and you are correct. In the DCS API there is this: https://wiki.hoggitworld.com/view/DCS_func_addGroup If you look at the groupData you'll see an entry for "task". I believe this is the role it is getting from the editor. I haven't tested or looked further but most likely. We can probably easily have Moose handle this in something like an init on spawn. InitRole("CAP") or something like that. Then it would set this in the structure and we would be good most likely. But we should note this somewhere in the DOCS in BOLD. If you want planes to do a certain role via scripting it should be set accordingly in the ME template group. Thanks for being persistent with this.

This is NOT the case according to Grimes as far as I remember discussing with him or reading in Discord or the forums. I can't find the reference. When you select CAS or CAP for example in the editor this sets up Enroute Tasks in the advanced waypoints for you. That is why it APPEARS to be working for you. I'll bet if you remove those in your mission you will see it is the same behaviour. So your test likely isn't proving anything unless you removed those enroute tasks in the editor. The Tasks likely are not working in Moose due to other issues like the unit not being seen and the task being thrown away or for other reasons the AI throwing the task away. I think tasks are supposed to happen immediately but the AI has decision processes it will go through and for whatever reason, if it thinks perhaps that task can't be accomplished OR there are better things to do, it probably throws it away. The editor ROLE option is strictly there to just limit followup selections. I would suggest to use EnrouteTasks because they stick around are work way better.

Discord is 99.9% text based at least with our Moose community. You'll find a lot more info there and much more help there.

Great to hear @Tiramisu. Moose has a steep learning curve so it will take time. That is also why there are a lot of demo missions. But learning the basics will certainly help in the long. If you haven't already, join us on Discord. You'll find a lot more people there helping each other. Should be a link in the OP.

Very highly unlikely. Haven't seen anything in the API to do this.

Yeah, for some reason people keep suggesting to remove the trigger and re-add but I've NEVER had to do that and never had any problems. Probably a bug crept up in one of the updates and this was the way to do it but was likely fixed quickly.

Looks like you are mixing a lot of different stuff together. Some of this looks like MIST or straight DCS API syntax so not sure whats going on here. That is fine BTW but more difficult to understand. You'll want to checkout the CONTROLLABLE class here https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/Wrapper.Controllable.html There may or may not be demos available showing how to setup something like this. Check all the demos here: https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/master/GRP%20-%20Group%20Commands What you'll probably also want to do is use OnSpawnGroup() method so that you don't care what your units are called. You can easily just grab the Group that was just spawned. In fact you need to do this in a lot of cases because there will be a delay sometimes with spawning and therefor the object will not be available as of yet. Although perhaps you just discovered that as well.

Correct. Probably best to post directly to github issues here

Not really. This isn't possible in any scripting for DCS as far as I know (Moose or otherwise). Except maybe for creating a very complicated script that would continuously create waypoints along the way and moving zones etc and setting various ROE options continuously. Even then you wouldn't be able to control certain missile types etc. So it would basically be a massively complicated script that could potentially bring DCS to its knees and only accomplish 1/10th of you really want. And it probably wouldn't work well. You are basically stuck with the lousy DCS AI for this kind of thing.

Yeah, won't matter how big or small your mission is. I have messed with radio stuff with only a couple of units and the radio. Buggy as all hell in MP. Usually works fine in SP. Gonna have to see what Vannipos is doing in detail one of these days. Ah, wait a minute, is this all within the ME? I usually mess around only in the scripting environment. Will have to see if the same thing can be applied there but my guess is NOT!!!

Same issue here. Although some seem to be in the right spot I THINK. I need to go back in and take a look. At first I just figured most of the switches just don't work but then realized some seemed to be offset so far that couldn't tell for certain. Is there a list as to what should and shouldn't work somewhere? Again this is in VR. Maybe works fine in 2D.

1. Sounds like a fuel issue. Double check they are starting with full fuel. If so, could be a bug with either DCS (most likely) or Moose. There have been DCS fuel bugs lately. 2. Lousy DCS AI. Not sure there is anything you can do there.

What is the difference that Vannipos is doing? Because this has always been buggy with the Huey. Works mostly in SP but not in MP.

Hey don’t call it a Western system. We use metric here in Canada. Actually we are pretty fluent in both. Growing up using a mixture of both.

Nope, it’s not possible to pickup ejected pilots. There are scripts out there that will simulate this though. They will spawn a unit on the ground when an air unit is taken out.

Probably never happen

You can look at Moose demo missions that will do exactly what you are trying to do. All you babe to do is piece together the menu with the spawn.

Yeah trying to do this with a wingman in your own group likely isn’t going to work to well. As a separate group should work fine.

Usually people sync using GitHub desktop or something like that but downloading the entire .zip source code is alright too. Usually you need to hit F5 in Eclipse to update. Or close the LDT and reload it. I find that one minute intellisense can work properly and the next it doesn't. F5 to update or close and reopen usually fixes things. You shouldn't need to do much else if it worked previously.