Changelog 2017-09-28

[Pathurs]

Why the change to createCreep and canCreateCreep?

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

[artch]

@pathurs See discussion in this pull request.

[Shylo132]

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.

[Arcath]

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.

[artch]

@arcath Yes it does.

[naskamal]

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

[Arcath]

@artch Awesome.

[WarInternal]

@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

[artch]

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

[artch]

@warinternal This has been fixed already.

[googol]

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

[NobodysNightmare]

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.

[dissi-mark]

@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?

[Mashee]

@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...

[Dissi]

@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.

[artch]

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

[hyramgraff]

@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?

[stybbe]

@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

[shedletsky]

@dissi-mark Why do creeps have names in the first place? Seems like they should have ids like other game objects.

[Dissi]

@shedletsky creeps have ids