dwpenney

Thanks FlightControl! I am looking forward to digging into the new release in the new year!

The DCS Witchcraft utility does work and provides a Lua interface that can be used to query the game live. That lives here: https://jboecker.github.io/dcs-witchcraft/ I have that working but each patch/update means I have to reconnect it. :-) That an there is a utility called snake-tail which will follow log files as they are generated (like the tail utility for unix)

Thanks FlightControl! I have been using MOOSE in my missions a fair bit. I have a semi-dynamic helicopter mission based on nodes I scatter around the map - meaning ground forces attack and defend the nodes. I am hoping to make some use of the Mission Orchestration and Cargo Handling features of MOOSE .. when I get back into that mission. If I can, anything I come up with I am going to try and contribute to the code base but that is a looong way off at the moment! Thanks for doing this work! It has made my mission building life so much easier.

Looks good. Order placed :-) And I have mentioned this on the Mudspike forums too. More exposure never hurts :-) https://forums.mudspike.com/t/the-contollr/2990/54?u=fridge

That is true and a cool idea. I was thinking more of the panel that sits in front of the throttle (with the knobs on it). I think it slopes up a little more than the throttle. But either way, options are good. I wouldn't stress or delay anything because of this :-)

I think that is probably ok. I thought at first that everything on the side panels (left and right sides of the cockpit) were all flat. I see that the panel that goes in front of the throttle slopes down to the throttle a little, which is what I was looking for. Plus, if you design/make the CUBs able to connect like that, it doesn't take too much to adapt to that design and help them tilt a little more if you need it. It is really hard to find a good profile picture of the side panels (or at least my google skills are not up to the challenge) :-)

This would be quite useful! If I could have the panel sit in front of my Warthog throttle and slope up it would fit my setup perfectly! Looking forward to this addition, the DYI set and the next box! :-)

I should have clarified that earlier. I match group and unit names for these. Since the groups that I use for paths are single unit groups, I match the group name and unit name to make it clear (to me) which group I am referencing without having to worry about it having a different unit name. That is possibly not the clearest thing I could have done but it seems to work :-) So in this case, I am re-using UnitName as both the Unit to spawn in as and the GROUP Name to get the path for. I did post an edited version of this question (my earlier post) to the DCS World OpenAlpha forums and Grimes did a quick test and did find that the late activation units are moving. His code for spawning the unit, however, did reset the path. I take this to mean that the Late Activation unit is moving (and it shouldn't) but when he assigns the position and path to the cloned unit it seems to reset to the path start. I am waiting for a follow up on that post to to see if there is a difference in how MOOSE handles the clone and path/route assignment and how his code handled it. I could be that the way MOOSE clones and assigns the route was sensitive to the position of the Late Activation unit in a way that his code is not (a choice of how to assume where the 'start' position is). I will let you know what comes of it. Here is the brief thread: https://forums.eagle.ru/showthread.php?t=177975

I have a really stupid question. Should 'Late Activation' units be moving? I have a situation where I am trying to spawn in some 'target' units via radio calls. So here is the expected MOOSE pseudo-code 1. Put a pair of 'spawnable' units in the ME. One is a single element group (1 ship) of target aircraft and the other is a pair element (2-ship) of target aircraft; 2. Put in a set of paths that these spawnables get assigned to randomly; 3. Set all of these groups/units to 'Late Activation' so that they, I think, do not spawn it. 4. Set up a radio menu to allow the pilot/client to request a spawn; 5. Set up a spawn function to spawn one of the spawnables (point 1 above), get a random path (point 2 above) and spawn the spawnable in on that unit (SpawnFromUnit) and assign that route (Route( GROUP:FindByName( UnitName ):GetTaskRoute() ); The issue is that at mission start, if I call the radio commands then the appropriate actions happen (the requested group spawns in on the randomly assigned unit/route). That is all fine. The problem is that if I wait, take off and fly to the target area and then request the spawn, the unit/route position is a hundred miles off to the west?? So, to try and figure out what might be happening I added a debug menu command to send a message to everyone with the North and East positions of all of the paths (point 2 above). And, before spawning anything, I call that menu command twice to view the output. I expect that the positions of the 'Late Activation' units would be 'static' until they are activated via the above SpawnFromUnit and Route calls BUT I am seeing changes in the position! That tells me that the 'Late Activation' units are actually activating but are hidden? Am I crazy? I want to ask here before to make sure my MOOSE calls are correct. I want to avoid the obvious first response :-) So here are the spawnables: SpawnSingle_Template = SPAWN:New("RED Target 01"):Limit( 10, 10 ) SpawnPair_Template = SPAWN:New("RED Target 02"):Limit( 10, 10 ) and here is the array of unit/route/path units: RedRoutes = { "RED Target Route #001", "RED Target Route #002", "RED Target Route #003" } and here is how they would be spawned: local idx = math.random( #RedRoutes ) local UnitName = RedRoutes[ idx ] local SpawnUnit = UNIT:FindByName( UnitName ) SpawnSingle_Template:SpawnFromUnit( SpawnUnit ):Route( GROUP:FindByName( UnitName ):GetTaskRoute() ) and here is what I am doing to get and report on the positions of the 'Late Activation' units: for unit_idx,unit_val in pairs (RedRoutes) do local tmpunit = UNIT:FindByName( _unitname ) local tmppos = tmpunit:GetVec2() <cut putting that into a message for all> end Everything from the MOOSE code should be fine but it seems that my assumptions about 'Late Activation' has changed with a recent patch ... oh ... DCS World 2.0.4

Question: If I despawn a group with the DCS destroy() command, the count of those units get removed from the Spawn object? Example: I have a supply group that I create a SPAWN object for. That group and set it to Limit (10 Units and 2 groups). When they are spawned with Spawn from unit, they are assigned a Route with the proper call and they head out. If they reach the destination (something I am polling for), they are destroyed by getting the DCS group and calling destroy. I can do this one more time before I run out of units from the SPAWN object instance. Is there a way that I can 'return them to the pool' of spawnable units? EDIT: Switched to the MOOSE GROUP:Destroy() call and I can see the SPAWN:SpawnCount stays the same but the SPAWN:AliveUnits goes down. It seems that the SpawnCount (counting groups) does not (and maybe is not intended to) be lowered when a group is destroyed?

That is the way I always feel in Lua :-) And don't worry about rushing a new release. All of that documentation, testing, demoing and training takes a lot of time. I will share what I am working on when it gets a little clearer. Right now I have the framework for something that may provide something for helicopter pilots to fly against :-)

Yes. I thought they might maintain their order once they were placed with something like SpawnFromVec2. I see the difference now :-) BTW: Much respect for hat you have done here. The code, documentation and test missions are very well done! I can see the obvious work that you put into them!

I think I understand. The Array () function is intended to have the Spawn object visible and ordered ... which means that the template is visible. When I call SpawnFromVec2 I am creating a clone of that template at the vector but it does not conform to the ordered positions of the template. IE: the template placement on the map (positions of each unit in the group) does not get copied to the cloned instance. TLDR: I am misinterpreting the function.

Ok here it is. I think I have stripped out most of the useless bits. In the DG_Ops_tmp-01.lua script, lines 91,92. I think that each of the depot groups should be spawning in formation but I may have something wrong. Depots-tmp-01.miz

Thanks for the reply. I will try to get that done either tonight or tomorrow night.

I have a question. Maybe I am just misunderstanding the behaviour but is it possible to spawn a group as an array at a particular Vec2? This works to spawn my group in the intended zone Depot_Spawned = SPAWN:New ( Depot_Template_Name ):Limit (5,1) Depot_Spawned:SpawnFromVec2 (Zone_Vec2, 50, 5) Which works .. in that the units I intended get spawned within 50m of the zone Vec2 position. When I add the array call in, like this: Depot_Spawned = SPAWN:New ( Depot_Template_Name ):Limit (5,1):Array (45,10,30,30) Depot_Spawned:SpawnFromVec2 (Zone_Vec2, 50, 5) which I think means to spawn them facing 45 degrees, 10 wide, 30 m, delta 30x, and delta 30y), I get a nice line of units from the right group but (there had to be a but :-) ) they are located at the position of the template group and not at or near the Vec2. I assume I am doing something wrong. Lua is not mu first language :-)

That. Is. Cool. If that worked in Multiplayer it would be awesome! Wonder if that is something on ED's radar? To fix that for Multiplayer?

I had not thought of that. Thanks. Ahh, what? This sounds interesting but I am not sure I understand. Do you set the audio transmission up as a Task Action and then use AI PUSH to trigger it? Interesting.

So adding a Stop Radio Transmission call immediately after the Radio Transmission call terminates the transmission before it really starts (I am assuming nanoseconds of processor time). The only way I could think of to get around this, and still have the transmissions occur on a particular radio frequency, was to add a Flag On call after the Radio Transmission and then another Continuous event to capture the Flag is True AND Time Since Flag conditions ... allowing me to way a few seconds before terminating the transmission. This seems really odd. The only way around this (if it is indeed implemented as intended) is to just use Sound To Coalition/Group instead. But that means people can not 'tune out' of those calls if they are doing something else (ie: they can not tune to a different frequency). I am a little worried that having n Continuous Event checks in the mission editor gets worse when you have m additional Continuous Events to clear the radio comms. Maybe I am not using these functions as intended in the Mission Editor?

Ahh. Ok. I was wondering if Stop Radio Transmission was required or not. Do you know if it is called immediately after Send Radio Transmission, does it cut off the initial transmission? I can test this later today after work.

Sorry to necro an old thread. Ranger, did you get it working for more than 1 radio transmission? I have a mission where I get only the first, followed by continuous static ... until the second is triggered. When the second is triggered, the static stops but I do not hear the second transmission. No transmissions after that seem to do anything. This is all from the same zone, same frequency, power, everything ... except different ogg files on DCS World 2 OpenAlpha. Anyone else getting this?

I am late to the party here but I have been looking at MOOSE over the past two months and thinking that this could build into something really significant and something really useful. As with most DCS Mission Editing, it is a serious up-hill battle in a quiet part of the forum. It takes time to generate momentum but the design and implementation of this tool set looks very promising. I am sad to read that it may be abandoned. I realize that it is a lot of work and hearth and family obviously come first. I hope to see you back here again someday and I appreciate the hard work you put in to this.

Donated!

I am interested!

Looking forward to it!