Page 1 of 1

UnitSpawnerGadget

Posted: 19 Sep 2013, 15:19
by PicassoCT
Would be more efficient if there was a way for the gadget only to be called upon table change.. but meh..


Code: Select all

    function gadget:GetInfo()
            return {
                    name = "UnitSpawner",
                    desc = "Works around",
                    author = "jk",
                    date = "3rd of May 2010",
                    license = "Free",
                    layer = 0,
                    version = 1,
                    enabled = true
            }
    end
     
    --GG.UnitsToSpawn:PushCreateUnit(name,x,y,z,dir,teamID)
     
    if (not gadgetHandler:IsSyncedCode()) then
            return
    end
     
    local function PushCreateUnit(self, ...)
            self[#self+1] = {...}
    end
     
    if GG.UnitsToSpawn== nil then GG.UnitsToSpawn = { PushCreateUnit = PushCreateUnit } end
     
    function gadget:GameFrame(frame)
            if (frame % 10 == 0) and GG.UnitsToSpawn and GG.UnitsToSpawn[1] then
                    local cur = GG.UnitsToSpawn
                    GG.UnitsToSpawn = { PushCreateUnit = PushCreateUnit }
                    for i=1,#cur,1 do
                            Spring.CreateUnit(unpack(cur[i]))      
                    end
            end    
    end
Post Scriptum: Working Gadget now. Thanks go to JK

This allows for unit to be spawned (with slight delay) from any function in unitscript..

Re: UnitSpawnerGadget

Posted: 19 Sep 2013, 16:31
by Google_Frog
Why can't you just put a function in GG which spawns units? RecursionMonster strikes again?

Re: UnitSpawnerGadget

Posted: 19 Sep 2013, 16:53
by PicassoCT
Honest Answer: Did not try. Would be elegant, if we could escape the boundaries of context that way..

but no dont think it would work.

Re: UnitSpawnerGadget

Posted: 19 Sep 2013, 16:59
by CarRepairer
jK's lua programming style always seems to have the goal of being as weird as possible. Why not this?

Code: Select all

     
    local function PushCreateUnit(...)
            GG.UnitsToSpawn[#GG.UnitsToSpawn+1] = {...}
    end
     
    GG.UnitsToSpawn = {}
     
    function gadget:GameFrame(frame)
              local cur = GG.UnitsToSpawn
              for i=1,#cur do
                      Spring.CreateUnit(unpack(cur[i]))      
              end
              GG.UnitsToSpawn = {}
    end

Re: UnitSpawnerGadget

Posted: 19 Sep 2013, 17:19
by knorke
Why not just spawn in unit script?
iirc (last week or so) even this:

Code: Select all

function script.Create()
	Spring.CreateUnit (...)
did work.

Re: UnitSpawnerGadget

Posted: 19 Sep 2013, 18:19
by FLOZi
Why not use Delay api? So much neater.

Re: UnitSpawnerGadget

Posted: 19 Sep 2013, 18:19
by PicassoCT
I have units that spawn units. The end.

A standard Unit spawns a buildanimation, which spawns a decalfactory.
This is needed.

Re: UnitSpawnerGadget

Posted: 19 Sep 2013, 18:31
by jK
FLOZi wrote:Why not use Delay api? So much neater.
So true
CarRepairer wrote:jK's lua programming style always seems to have the goal of being as weird as possible. Why not this?

Code: Select all

     
    local function PushCreateUnit(...)
            GG.UnitsToSpawn[#GG.UnitsToSpawn+1] = {...}
    end
     
    GG.UnitsToSpawn = {}
     
    function gadget:GameFrame(frame)
              local cur = GG.UnitsToSpawn
              for i=1,#cur do
                      Spring.CreateUnit(unpack(cur[i]))      
              end
              GG.UnitsToSpawn = {}
    end
Your code fails:
1. GG.UnitsToSpawn is reset _after_ you processed it means any changes done during processing it get dismissed
2. PushCreateUnit is local, but pica wanted an API gadget available in LUS!

Re: UnitSpawnerGadget

Posted: 20 Sep 2013, 07:27
by CarRepairer
1. But how can there be changes during processing if it's within a gameframe callin? I thought that guarantees atomicity.

2. Oops, should be GG.PushCreateUnit then.

Also UnitsToSpawn doesn't need to be in GG table anymore, but I was doing it hastily.

Re: UnitSpawnerGadget

Posted: 20 Sep 2013, 12:04
by jK
CarRepairer wrote:1. But how can there be changes during processing if it's within a gameframe callin? I thought that guarantees atomicity.
Spring.CreateUnit still triggers a UnitCreated callin