Unit spawn in a random given area

[TheTrooper]

I'm sure something like this has been mentioned before but I think it should be high up the list to implement.

I personally love creating missions in the editor and flying them. The downside is I know all the possibilities and locations. It would be good to have a trigger area linked to a unit where somewhere within the trigger the unit would spawn.

A good scenario for this would be something like SCUD hunting.The player would have to look within a given area of which the SCUD could be anywhere within it. That functionality would open the game up to allsorts of possibilities.

[Hairdo1-1]

If you can do 4 lines of scripting this is super easy to accomplish with MOOSE scripting.  I think it’s possible with MIST too but I don’t use it

[TEMPEST.114]

3 hours ago, Hairdo1-1 said:

If you can do 4 lines of scripting this is super easy to accomplish with MOOSE scripting.  I think it’s possible with MIST too but I don’t use it

It's almost 2023. You shouldn't have to use scripting for this. Nor should you be restricted to a 4 point polygon in the M.E. The overhead for almost 172000 lines of lua (Moose) is too high. 

[TheTrooper]

6 hours ago, Hairdo1-1 said:

If you can do 4 lines of scripting this is super easy to accomplish with MOOSE scripting.  I think it’s possible with MIST too but I don’t use it

If you have any examples for MOOSE scripting to acheive this (or a .miz file) that could be helpful for now for what I was hoping to do in a current mission.

[cfrag]

56 minutes ago, TheTrooper said:

If you have any example

Roughly 10 seconds in DML. Secret is in the zones 

 

Three random vehicle positions.miz

[TheTrooper]

21 hours ago, cfrag said:

Roughly 10 seconds in DML. Secret is in the zones 

 

Three random vehicle positions.miz 129.24 kB · 2 downloads

Wow, that is a lot of code

[cfrag]

1 hour ago, TheTrooper said:

a lot of code

It's pretty much "Lego for Missions". The libraries just sit there (you never change them), and you control everything with Trigger Zones (look at the attributes). No Lua code of your own, no code customization - everything is controlled via Trigger Zones  

[TheTrooper]

33 minutes ago, cfrag said:

It's pretty much "Lego for Missions". The libraries just sit there (you never change them), and you control everything with Trigger Zones (look at the attributes). No Lua code of your own, no code customization - everything is controlled via Trigger Zones  

Ah ok. got it. That's very useful! At thew moment there's messages popping up on the top right. Guessing that's in the script somewhere if wanted to remove?

[cfrag]

Just add a final action ‚out text to all‘ with no text and clearscreen checked after the modules load in the on mission start. That clears the screen. If there are other messages popping up, that‘s my bad - I’ll look into it asap

 

 

[Hairdo1-1]

On 11/22/2022 at 11:03 AM, Elphaba said:

It's almost 2023. You shouldn't have to use scripting for this. Nor should you be restricted to a 4 point polygon in the M.E. The overhead for almost 172000 lines of lua (Moose) is too high. 

Preaching to the choir! MOOSE HAS DEMO MISSIONS ON THE GITHUB

https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/master/SPA - Spawning

Edited November 24, 2022 by Hairdo1-1

[cfrag]

10 hours ago, TheTrooper said:

At thew moment there's messages popping up on the top right.

Removed by adding an action 'Message to All' with Clearscreen after loading the last library on mission start:

Now you get a pristine screen when the mission starts (please see attached miz)

Three random vehicle positions.miz

Edited November 24, 2022 by cfrag

[TheTrooper]

10 hours ago, cfrag said:

Removed by adding an action 'Message to All' with Clearscreen after loading the last library on mission start:

Now you get a pristine screen when the mission starts (please see attached miz)

Three random vehicle positions.miz 129.37 kB · 0 downloads

 

That's great. Didn't k now that was a thing. Amazed it's not already included in the editor able to link a trigger to a specific unit or group.

[Amarok_73]

@cfragPerhaps it's good idea to implement the boolean attribute that would make it possible to randomize position of spawned units/groups within the zone (quad or circle)?

[Exorcet]

Randomized unit positions are needed, but there is a problem with truly random placement in a zone, not everywhere in the circle is going to (or should be treated as) a valid point.

Units could end up on buildings, on mountains, in rivers, in trees, etc. If we do have this feature it needs to do a little bit more than just randomize positions within a zone.

I think it might actually be preferable to define spawn points instead of zones and have the points be selected randomly. These points can be kept in reasonable locations to avoid the issues of a purely random in zone spawns.

[Amarok_73]

In meanwhile I've found this in the Quick Reference document:

 

I've tested it quickly and it seems, that while in circle zone it works perfectly, the quad point one is spawning the unit, but then the parameters like "time" are disregarded.

 

Other discoveries for the Cloner zone so far are, that even if it is circular, the onRoad and rndHeading seems to have no effect on spawned unit, whether the value for these parameters are "true" or "yes".

Edited January 24, 2023 by Amarok_73

[TJTAS]

I use Moose and DML and they both work well, Kudos to the guys who made them. I do agree with the OP that this should be available in the mission editor. Arma has an option for "Placement radius" which does exactly this. I would love to see this behavior in the ME.

[cfrag]

18 hours ago, Amarok_73 said:

the quad point one is spawning the unit, but then the parameters like "time" are disregarded.

I'm not entirely sure what you mean by that. AFAIK, "time" is not a clone tone attribute.

18 hours ago, Amarok_73 said:

the onRoad and rndHeading seems to have no effect on spawned unit, whether the value for these parameters are "true" or "yes".

That is strange. Can I trouble you to verify if you are using the most recent version, and if so, please post the miz (or pm it) so I can have a look?

[Amarok_73]

Thank You @cfrag for the response.
I have edited slightly the demo mission downloaded yesterday from the GitHub (with GitHub Desktop application), so I assume it uses most current version of the DML.
The demo mission I've amended is the "demo - Forever-looping spawns.miz", and the attribute "time" exists there for the helicopter cloner zone. By default it causes to respawn the heli in between 10 and 20 seconds, and it works correctly as long as I am not changing the trigger zone to the quad point type.
Then I've tried also the onRoad on transporter and heli, both without expected effect, and rndHeading attributes that seems to have no effect on the helicopter, so it always spawns with the heading 158.
Here's the screenshot from the original mission with heli attributes, and the mission with my changes.

demo - Forever-looping spawns edited.miz

[cfrag]

46 minutes ago, Amarok_73 said:

By default it causes to respawn the heli in between 10 and 20 seconds

Ah! Good one  --  One of the cool features of DML is that you can stack multiple modules on the same zone. The drawback is that in ME you can't see which property belongs to which module.

The pulse! attribute marks that this zone also adds the 'Pulse' module that creates an output every 'time' attribute (10 to 20 seconds) on the (local) output flag *restartHeli - which is also the flag that is wired into the cloner's clone? input. Hence it clones a new batch of units every 10-20 seconds - but only when the pulser gives the signal. That's probably missing from your clone zone.

If you haven't done so, I recommend you also download the big scary manual. In it, there is a chapter for each and every demo in DML, and I try my best to explain how that demo works. It could help you to quickly learn these neat little tricks that make DML such a nice set of lego for mission builders

 

[Amarok_73]

Does it means, that the attributes (properties, as I prefer to name it) for few modules, that are grouped within one trigger, have to be kept in specific order?
By the way, I am in somewhere like the 1/3 of the "Big (not-so-much)Scary Manual", but I did not noticed if anywhere was mentioned, if the boolean type properties accept yes/no, as well as true/false? Looking into screenshots and in the missions, I noticed that You're using the yes/no, but also in the description of some parameters I can see, that You're using true/false.
It may be, that I am swallowing too quick this manual so I omitted this information.

[cfrag]

3 hours ago, Amarok_73 said:

I have edited slightly the demo mission downloaded yesterday from the GitHub (with GitHub Desktop application), so I assume it uses most current version of the DML

Uh, that's a dangerous assumption. It's a bit much effort for me to update all demos each time that I add new features, and that demo indeed uses old code. It uses code that's good enough to demonstrate what the demo wants to show, but not more.

I updated the libs in the demo and now it works. That plser was a red herring for me

 

demo - Forever-looping spawns edited.miz

Just now, Amarok_73 said:

Does it means, that the attributes (properties, as I prefer to name it) for few modules, that are grouped within one trigger, have to be kept in specific order?

No, any order is fine, DML doesn't care.

Just now, Amarok_73 said:

if the boolean type properties accept yes/no, as well as true/false?

It's a quality of life feature. DML internally converts yes to true, and no to false. I found that yes/no make the attributes a much better read

 

[Pikey]

I've invested the last 5 years as a Moose evangelist, learned the lua scripting language from no prior experience, and even I think the Mission Editor should have this feature!

If we have to show folks 2 lines of scripting every time this topic arises then we aren't making headway with what people REALLY want.

I play other games that use lua like CMANO, but do i touch scripting there? No. There's so much to learn that's not anything to do with the lua itself like the API. I dont want to invest. SO I think its reasonable that view is shared and its my experience that people will refuse, DCS is hard enough.

The model i propose would be the same way MOOSE has it setup, that there is a template or several possible template groups, that they can spawn randomly in zones or in situ, that they can keep duplicating up to a limit on a schedule, and so on https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Spawn.html