Changelog 2017-09-28


  • Dev Team


  • Culture

    When you click “Respawn”, all structures now don’t vanish, but change their owner to SYSTEM_USERNAME, so that other players are able to withdraw resources from them.

    This is amazing. I think it was one of the most annoying ways you could troll another player. Someone put in lots of effort to bring your controller down, than you click respawn and the spoils of war disappear. Now they will remain for the attacker to pick up!



  • Why the change to createCreep and canCreateCreep?

    Unless I missed something, I don't see any "reasons behind the change" parts?

    :)


  • Dev Team

    @pathurs See discussion in this pull request.


  • fsoc

    As for backwards compatibility, all I know at the moment is my spawn code is maintaining what I had before the transition but will not allow me to spawn more/additional creeps until i change my code over.

    So my rooms are at their "stable position" that ive had them at for a few days, but if i want to create a builder, it won't do it because hey, new code stuff now. xD

    I'll have to try and convert this stuff later today.


  • Overlords

    Does the order of spawns/extensions in energyStructures effect the order that energy is used?

    If it did it would let use optimise the refill order by having energy always drawn from the beginning of the refill route first.


  • Dev Team

    @arcath Yes it does.



  • I would like to ask about the CPU cost of the new spawnCreep function.

    By now, I am using this code snippet from the api documentation with ("low CPU" + 0.2 CPU) cost.

    if(spawn.canCreateCreep(body, name) == OK) {
        spawn.createCreep(body, name);
    }
    

    If I replace this by

    if(spawn.spawnCreep(body, name, { dryRun: true }) == OK) {
        spawn.spawnCreep(body, name);
    }
    

    am I right the CPU-costs would be charged 2*0.2CPU, since the function spawnCreep returns OK two times?

    edit: corrected copy-paste-error


  • Overlords

    @artch Awesome.



  • @artch Currently a bug in the implementation.

    ReferenceError: roomObjects is not defined
        at spawnCreep (C:\Program Files (x86)\Steam\steamapps\common\Screeps\server\node_modules\@screeps\engine\dist\game\structures.js:1253:70)
        at . (evalmachine.:1:72)
    

    when passing in energyStructures


  • Dev Team

    @naskamal No, dryRun: true doesn't register an intent, so no CPU will be charged for this call.


  • Dev Team

    @warinternal This has been fixed already.



  • @artch So spawnCreep will still use globals.Memory even when you don't specify a memory?



  • I just noticed that spawnCreep (as opposed to createCreep) does not automatically assign a name to created creeps anymore.

    I think this is an unneccessary complication for new players, which should not use a deprecated method like createCreep, should they?

    Was there a particular reason to leave that behaviour out? The pull request does not at all mention this change, I discovered it by chance after seeing that my spawning code does not work after changing to the new method signature.

    In case you want to keep the behaviour as is: The documentation of return values should be updated. Currently it only points at an errorneous creep body, but not at a missing name.


  • Dev Team

    @nobodysnightmare said in Changelog 2017-09-28:

    I just noticed that spawnCreep (as opposed to createCreep) does not automatically assign a name to created creeps anymore

    That's correct. There are multiple reasons why it was changed to this, but I'd rather like to know if you guys think this should be re-added.

    Pro's and cons for re-adding this: Pro's:

    • Easy code, no need to deal with names
    • Lower entry level

    Con's:

    • Makes spawning code return an ambiguous type (error code or creep name)
    • Prone to bugs (what if you name generator generates an undefined name?)
    • Already easy to generate a unique name (spawn.name + "-" + Game.time)

    What do you guys think about removing the automatic naming? :)



  • @dissi-mark said in Changelog 2017-09-28:

    Con's:

    • Already easy to generate a unique name (spawn.name + "-" + Game.time)

    What do you guys think about removing the automatic naming? :)

    I've had this, and similarly obvious long name strings fail to be unique (seems impossible).

    I think the pros, particularly the Lower Entry Level speak for themselves. Not something a beginner needs to deal with.

    A great game has a low entry level, and a ceiling that just keeps on going...


  • Culture

    @mashee said in Changelog 2017-09-28:

    ve had this, and similarly obvious long name strings fail to be unique (seems impossible).

    I'd love to see this code fail, game.time is unique for every tick, and one spawn can never generate 2 creeps at the same time, so something else might have been off.

    I do agree with the low ceiling. We can add this example to the tutorials though and explain it that way as well.


  • Dev Team

    This is already in the tutorial by the way, see here.



  • @dissi-mark

    I must admit that I'm a bit nostalgic about the default names that were generated by createCreep. Is there a way to expose the function that it was using to generate creep names?


  • Culture

    @hyramgraff said in Changelog 2017-09-28:

    @dissi-mark

    I must admit that I'm a bit nostalgic about the default names that were generated by createCreep. Is there a way to expose the function that it was using to generate creep names?

    The function is posted in this thread https://screeps.com/forum/topic/626/please-give-us-access-to-random-name-generator-for-creeps/5


Log in to reply
 

Looks like your connection to Screeps Forum was lost, please wait while we try to reconnect.