Random Unit Spawn

OMG!


Hats off there TJ, another brain **** I gave you that you managed to accomplish. That looks amazing and is going into DRZ/i

And Thanks very much for getting a solution to my question although you were thinking of doing a module for it in one way or another.

Hey, I recognize that last pic! lol... piloting skillz

I've got summit wrong.

Thanks TJ!

HomerPepsi wrote:Thanks TJ!

No worries Homer, I've just been working on this one. I'll need to get the update out. There is 2 small error in the code. I've fixed them plus added functionality for selecting whether to spawn pla or us. Kind of a "side" ownership variable thing.

Oh, and I've got the "Mortar Code module" ready. Just havn't written any instructions.

Hello,

Running into an issue with this module....

I'm using the recon point naming scheme (very nice) to mount my spawned entities to a truck. Good so far, but if i leave the triggerzone, the game completely freezes and I have to kill from task manager. Any ideas?

I have a crude mssn i'm working if needed for dbg'ng.

freezing without crashing is almost always caused by a while loop that does not break. Have you got any while loops in there?

Code:

function onLeave(zoneName, unitName)
    if OFP:isPrimaryPlayer(unitName) then
        if zombieIDsets[zoneName] then
            for iz,vz in pairs(zombieIDsets) do
        --        OFP:displaySystemMessage("iz = "..iz)
        --        most = zombieSpawnPoints[zoneName]["most"]
        --        least = zombieSpawnPoints[zoneName]["least"]           
                dis = zombieSpawnPoints[zoneName]["dis"]
                zoms_spawned = #vz
                if not zom_remove[iz] then
                    zom_remove[iz] = {}
                end
                for i,v in pairs(vz) do   
                    dist = OFP:getDistance(unitName,v)
                --    OFP:displaySystemMessage("dist = "..dist)
                --    OFP:displaySystemMessage("zoms_spawned = "..zoms_spawned)
                    if not OFP:isAlive(v) then
                        OFP:destroyEntitySet(i)
                        if iz == zoneName then
                            zoms_spawned = zomCleanUp(iz,v,zoms_spawned,true)
                            if zoms_spawned < zombieSpawnPoints[zoneName].most  then
                                zombieSpawnPoints[zoneName].most = zoms_spawned
                                zombieSpawnPoints[zoneName].least = zoms_spawned
                            end
                                if zoms_spawned < 1 then
                                    zombieSpawnPoints[zoneName].spawn = false
                                    OFP:displaySystemMessage("zone clear")
                                end   
                        elseif iz ~= zoneName then
                            zoms_spawned = zomCleanUp(iz,v,zoms_spawned,false)   
                        end
                    elseif OFP:isAlive(v) and dist > dis then
                        OFP:destroyEntitySet(i)
                        zoms_spawned = zomCleanUp(iz,v,zoms_spawned,false)
                    end               
                end
                z = #zom_remove[iz]
                while z < 1 do
                    table.remove(zombieIDsets[zoneName],zom_remove[iz][z])
                    z = z - 1
                end
            end
        end
    end
end

that's straight from the module script. not up to debugging it right now since i've got a (crude) work-around.

upon quick glance, that while loop near the end looks rather suspect

Good coding practice 101 : NEVER build a while loop without a breaker!

Code:


                while z < 1 do
                    table.remove(zombieIDsets[zoneName],zom_remove[iz][z])
                    z = z - 1
                end


see if changing that to

Code:


                local breaker = 0
                while z < 1 and breaker <= 500 do
                  breaker = breaker +1
                    table.remove(zombieIDsets[zoneName],zom_remove[iz][z])
                    z = z - 1
                end


ive never used this module thing, so I am just guessing here

Yeah... that loop should read while z > 0 do.

Hi Regg,
Great find and happy to hear someone getting some use out of the mod.
I'd found this error a while ago but had not updated it since, sorry.
That section of code has been completely re-written.

update link...
http://filebeam.com/cd6780eb206c9357e59caca1b8b16981
main download link also updated.

There are few other changes too..

---------------------------
--Random unit Spawner Mod--
---------------------------

--by Tjdagger 2012-2013
--This mod will allow you to place triggerzones on the map and associate spawn points to said trigger.

--You set a most(max) and least(min) amount of units to spawn.

--dis...distance from player--
--determine a suitable dis(distance) to handle despawning of spawned units still alive when leaving said zone.
--Unit that are alive but are under the dis are added to a table called units_left.
--This table is then monitored and checked against the current dis anytime the player leaves any spawn zones.

--side...zone control--
--you can control spawning with a true or false setting. Spawning can be set at anytime... eg. unitSpawnPoints[name_of_trigger].spawn = false
--Side can be set to either "pla" or "us". Side can be changed at anytime... eg. unitSpawnPoints[name_of_trigger].side = "us" ...
--...if all spawned units for a said zone are killed whilst the player is inside said zone, then the side(ownership) will automaticly change to the opposite...
--..."pla" will become "us" and vise versa.

--Paths--
-- you can place paths in an entity set and name it in the table.
-- these should be placed in proxcimity to patrol spawn points so that they are the closest path to the patrol unit spawning.
-- A patroling unit will stop at waypoints along a path for a random amount of time, before continuing on.
-- The 2 modifiers below describe the time (in seconds) from which a random time to stop will be generated.

stoptime_min = 5
stoptime_max = 15

--Naming spawn points--
--placing spawnpoints and naming them specificly will allow you to control a units behaviour upon spawning
-- "defend" = defendLocation of spawn point
-- "search" = searchAndDestroy 300m radius from spawn point
-- "assualt" = assault nearest enemy
-- "pbaf" = patrol "backandforth" along nearest path, starting from nearest point
-- "pcyc" = patrol "cyclic" along nearest path, starting from nearest point

-- you can add more point names and set(code) their behaviour in the onSpawnedReady function.

Regg,
I noticed you mentioned using this mod to make units board a vehicle.

You should check out the mssn below. It's a test file for a vehicle mod I am currently developing. It also includes an IED/mine placeable mod, and the random spawn mod working together.

http://filebeam.com/ecfdd835b771c9ee70669202e7be6fc8

I've also included my DB just in case.



Would appreciate your thoughts.

TemplarGFX wrote:Good coding practice 101 : NEVER build a while loop without a breaker!

Sorry TemplarGFX I disagree with this statement.

A while loop will fail only if there is an underlying error. Using a "breaker" is a "band aid" solution, merely covering the error and not addressing the underlying cause.

How will you know an error exists if you disguise it??

Code:


breaker = 0
while 1 = 1 and breaker <= 100 then
  breaker = breaker + 1
end
if breaker > 100 then
  log("1 = 1 will never stop!")
end


thats how, I did not put a log bit in the code above, as I do not know how this person is doing logging

TJDagger ---

I'll have to check out your updated spawner and vehicle spawn set-up. One oddity after another with the previous random spawner code drove me to spend the last six hours re-writing everything to a little more object-oriented approach.

Not trying to re-invent the wheel, as I like what you have done, but I still see improvements and features that have been bugging me for a couple days now. Like setting up a one-way spawn (units never despawn, even if you leave the zone), and accounting for Co-op playback (activate zone upon any 'real' player entering, and do not despawn until all 'real' players are out of zone).

So far my code just gets things set-up and does some checking on whether or not its sane before starting to spawn units. From there, I plan to basically re-use your "onEnter" and "onLeave" functions. I also plan to expand the "onSpawnedReady" functionality. Very slick thinking with using the spawn point's name for the command, so definitely want to keep that, but also allow parameters to get passed for things like assault targets, vehicle mounting, waypoints/paths.

I set it up to allow spawn points to be added to the system either individually or by passing a table of points (to the same function), thus you can easily set parameters for a whole group of "assault" or "move" points, or specify parameters for each spawn location!! Not only that, you'll be able to (optionally) assign a specific function to run for each point in addition to the standard name-based action! Trying to keep it simple too, so you can just call a point "assaultfoo" and if a target parameter isn't passed, it defaults back to assaulting the nearest enemy.

Sounding good so far? Probably 1/3 to half way done. Need a break......


BTW -- been using this for a refence on OOP LUA -- http://www.troubleshooters.com/codecorn/lua/luaoop.htm

Hi Regg, make sure you check out the update... cause the one your using for reference is bugged... the update is expanded in concept. It will despawn enemy if they are over the dis(this is a value in the table which you need to set for each zone... too big in a small zone and it won't work, plus that was one of the bugs of that release), any left will be monitored and despawned later. This is to prevent any units too close from despawning in front of you.

Another concept I want to include is instead of listing the spawn points in the table, I want to place the spawn points into an entity set named in the table and activate it for the zone. Then check the names onSpawnedReady to add them to a table of possible spawn points. If you look into the IED/Mine mod you will see this concept in action. It works very well and requires less coding plus allow for multiple entity sets with spawn points to be set up for zones.

As for the co-op issue. This is a tough nut to crack. I am yet to find a one size fits all solution to this.

The problem is less evident in large zones where the zone is around 1km across. With a despawning distance of 500m combined with the tether zone with an approx 250 radius. Neighbouring zones should overlap by about 250m and each zone should be populated in such a way that the action is nearer the centre of each zone.

Allowing any player to trigger a spawn presents it's own set of issues. eg. If player one enters a zone and spawns in 30 enemy units... then player two enters a nearby zone and spawns in another 20 or so units... and player three enters another nearby zone and there is no room to spawn in any more enemy... then all players decide to follow player three, then there will be no enemy to fight, because as part of your checking each time a unit enters a zone you would be to check in any player is already in there. Even if you devise a system to monitor enemy numbers upon entry for the entered zone you could easily end up with a situation by when the last player enters the zone, the others could be several hundred metres inside and have units spawn in front of them.

The original concept behind all my mods are that they are simple and easy tools in which to populate large areas of the map with ambient units, vehicles, props and gun emplacements. What I wanted to do was create a whole island populated environment in which missions could then be take place. All these are part of my long term goal to make an adventure type game with a cash reward and spending system.

Would love to hook up on something like skype and discuss concepts and issues with ya mate. Even collaborate on some of this stuff. Been thinking of re-writing some of it. Plus it's been a mammoth task just trying to test all this stuff.

sent you a pm with my skype name.
Cheers

TemplarGFX wrote:

Code:


breaker = 0
while 1 = 1 and breaker <= 100 then
  breaker = breaker + 1
end
if breaker > 100 then
  log("1 = 1 will never stop!")
end


thats how, I did not put a log bit in the code above, as I do not know how this person is doing logging

Ok, so, in that light it makes sense.

NEW Update to RandomUnitSpawner Mod!

Download link below

http://filebeam.com/cd6780eb206c9357e59caca1b8b16981

all links update including main page.

NEW FEATURE!
-- No longer need to list spawn points, only need to put them in an entity set to be activated.

Will post a "how to" video soon.

tjdagger--

I'm still playing around with my spawner, but I think I figured out why I was having issues with your module. I forgot to include an echelon with each AI unit! I've been looking over your updated code, but I haven't bothered fixing my mission yet. There's a number of things I've been wondering about...

Please excuse my ignorance on these matters, but what is the purpose of the echelon? Is this for issuing commands? If so, why couldn't the commands be issued directly to the unit?

From what I'm starting to find, it looks like CM didn't bother making all the 'command' functions universal in the sense that you can issue the command to either a single unit, an echelon, or a group. Maybe we should start a topic with all the commands and what they'll accept? Or make universal functions for the EDX?

Back to the spawning... If the echelon is needed for each spawned unit, why not just have one in its own entity set, spawn it along with the unit, and attach the unit to the echelon?

Too bad CM left all these mysteries for the community to figure out!

Cheers

Echelons--
when DR's editor was first being used a lot of users commented on the useless AI and how stupid they where. There was even a video floating around that clearly highlighted the issue with a demonstration showing the player move around an AI enemy, who refused to attack the player despite a clear line of sight.
A rebuttle video was posted, re-enacting the first video but with the AI unit in an echelon. The AI promptly shot the player and sort out cover.
It was then discussed in great length how the AI command flow and "playbooks" where linked to the echelon and not to units them selves. Without being attached to an echelon an individual unit is somewhat stupid.

Commands like patrol can only be given to and echelon. This is why some of your commands would have failed.

Back to the spawning... If the echelon is needed for each spawned unit, why not just have one in its own entity set, spawn it along with the unit, and attach the unit to the echelon?

No reason you couldn't go this way, it would just involve another step. I did consider this, but since echelons don't count towards entity limits I didn't bother.
You'll also notice I use the echelon_Name to record and keep track of the setID and checking to see if is alive. In order to keep track using the above method you would need to record the setID for the echelon plus any units attached to it.
I also found it simpler, in regard to keeping entity limits in check. To spawn one unit at a time.
Remember that the purpose of the spawning mod is to populate an area with "ambient" units going about their business. Quickly and easily, and to be self managing in regards to spawning and despawning. The simpler you can make your mission elements the less there is to go wrong and the more you can do.

The bunker module is used to place structures and the units to mount them, whilst self managing all the spawning and despwning. Another key goal was to have gun emplacement disappear if the bunker was destroyed.

The vehicle mod handles spawning and despawning of vehicles, their crews and passengers. Also handles path finding and threat response behaviour, including passengers dismounting to defend vehicles and re-boarding when a threat has passed etc.

and there are more on the way.

As I mentioned before... get a headset for your PC and pick my brain on skype(skype is free).

Too bad CM left all these mysteries for the community to figure out!

Save yourself some headaches.

Cheers,

Thanks for the explanation! I was thinking something along those lines... the echelon providing the command and control structure for units. I know formations only work with units in the same echelon. Was any research done as to how the AI acts when alone in an echelon versus having a true echelon hierarchy? (Hence, the 'stickTogether' option for 'searchAndDestroy')

I forgot I had a laptop around with mic and cam, so we'll definitely have to skype sometime!

P.S. -- can't wait to see the vehicle module; that's what i was attempting to do with the spawner. i had a 1km trigger zone around a village to generate the ambient AI, and two smaller 300-400m zones - one for AI inside the buildings, and one to spawn a truck down the road for reinforcements.

Cheers

Ok so I'm looking at this script and wonder how do I put this into my mission so I have random patrols ext. How does this work where do I put it thanks...

gtaekwondo33 wrote:Ok so I'm looking at this script and wonder how do I put this into my mission so I have random patrols ext. How does this work where do I put it thanks...

All the modules go into your mission the same way.

File/MarkersCollection/Load.

you then select the module you need, in your case the randonSpawnModule and it will place itself on the map when you select it.

You then fill in the tables as instructed in the module. they pretty much follow the same format but have varying results as per the module you select.

for the patrols to be random you:

1. make a patrol path with the waypoints.

2. place those into a set in the explorar tab.

3. name that set in the script where it says .....pathsID = " "

4. you assign the reconpoints using pbaf or pcyc.

5. In the table concerning that triggerzone you need to place either pbaf or pcyc inside it.

When they spawn in the code already made for you will assign those units to get the nearest waypoint path and they will patrol either back and forth or do a cycle depending on what you choose for that closest recon point.

the images don't show the pathsID = " " becasue they need updating but Tj will get around to doing a video eventually for them.