4. Spawn.spawning doesn't update until the following tick

Spawn.spawning doesn't update until the following tick


  • Hey,

    When calling createCreep on a spawn then immediately afterwards calling .spawning it returns null.  From looking at the documentation (http://support.screeps.com/hc/en-us/articles/205990342-StructureSpawn#spawning) there's nothing there that should require a round trip to the server.  Please can we make .spawning immediately return data?

    This would be great if it also fixed the issue where multiple calls to .createCreep all return OK when the first one should really return OK and subsequent ones should return ERR_BUSY.


  • Yes that would make some thing easier. Well, other things harder. 

    This is how the game works. 

    When you call creep.say multiple times, only the last command is executed. 
    When you call creep.move multiple times, only the last command is executed.

    Each of those commands will return OK, as long as the command itself is executable and it will overwrite the command before. 

    It's the same with the spawn. You may call createCreep multiple times in a loop. It will return OK and overwrite the same command (to create an other creep) you entered before. 

    If I understand game mechanics right,
    all those commands you are entering will be executed AFTER the loop (on client side) has ended. like a post to the server.

    The immidiate OK response is only a first check against some defined cases, but still no guarantee. 

    You can use this behaviour to your advantage. This (current) way you can revise a given order within the same loop by simply giving a new one. 

    So it's not a real 'Problem'. It's simply a kind how things are designed and working. If you know it, you can handle it. 

    If you need to know wether you already gave an order to create a new creep, you can set spawn.busy = true and check for that value afterwards...


  • You could always hook the createCreep method and set the property yourself -- this allows you to get the desired behaviour while keeping everything else uniform.


  • Almost all calls are like action to queue. What I mean is that it's not really a "return to server" as much as it is "do x in the next tick". If you have done programming like this before it's really second nature, but if you haven't it can be a bit confusing. 

     

    The best way to think of it is that each of the objects in the game have a action buffer. When you do stuff you write to that buffer, then finally then your ticks is done that buffer is executed.  That's not totally accurate, but close enough. 

     

    So 

     

    var tick = function() {

    spawner.bufffer = createCreep(1)

    spawner.buffer = createCreep(2)

    spawner.buffer = createCreep(3)

    }

     

    and the game engine calls tick() only createCreep(3) is actually there and actionable.  That's basically what happens (again not totally accurate) on each tick.  spawer.spawning can't be true yet because it hasn't started spawning yet. It doesn't start spawning till after the tick ends. 

     

    For a better example, 

     

    var amount = creep.carry.energy

    creep.transfer(container, RESOURCE_ENERGY, 50)

    amount === creep.carry.energy // will always be true because the energy is only queued to transfer. 

     

    all actions, only replace the queue and don't start till after the "tick"