Neither the three backticks ``` nor the indentation method seem to work for me. Inline code does not seem `to work as well`.
However it should according to https://support.zendesk.com/hc/en-us/articles/203691016-Formatting-text-with-Markdown or am I mistaken?
You can just extend the Room prototype on your own.
```javascript
Object.defineProperties(Room.prototype,{
"powerspawn" : { get : _powerspawn },
"my" : { get : _my },
});
function _powerspawn() { return this.find(FIND_MY_STRUCTURES,{filter:{structureType:STRUCTURE_POWER_SPAWN}})[0]; }
function _my() {
return this.controller && (this.controller.my || this.controller.reservation && this.controller.reservation.username === MY_NAME);
}
```
To improve performance, you can add an additional caching step, which pulls the IDs from memory if available (which might not necessarily be faster depending on your memory structure).
> all the most common functions my creeps could need to use
This sounds like you should expand the according prototype:
main.js
```
require("Prototype_Creep");
```
Prototype_Creep.js
```
_.assign(Creep.prototype,{
get : function(val){return this.memory[val]},
});
// or another way to write:
Object.defineProperties(Creep.prototype,{
"costs" : { get : costs },
"Class" : { get : function(){return this.get("Class");}},
"type" : { get : function(){return this.get("type");}},
"task" : { get : function(){return this.get("task");}},
MAX_LIFE : { value: CREEP_LIFE_TIME, enumerable:false,writable:false},
MAX_BODYPARTS : { value: MAX_CREEP_SIZE , enumerable:false,writable:false},
});
```
I guess I will never understand, why people gloat about fighting people who don't fight back...
My script just sets a special "start" flag you can check. Once I'm a few ticks into the game, I disable the init script anyway to save CPU.
@Raskvann, that is exactly my point. I did not reserve or distance mine, power harvesting only once in a blue moon when I was in the mood (and CPU bucket was full). I have a lot of code which I cannot run since it is (imo) impossible to do with 10 CPU. That's why I am asking, since the devs advertise it with "enough to run a couple of rooms".
With only 1 maintenance creeps per room I ended up at 8 CPU average. This however was nothing else than mining, repairing ramparts, taking care that the controller does not downgrade and monitoring my rooms for attackers.
@RaskVann I mean 11 CPU for all 10 rooms. Running 3 creeps per room taking care of maintenance and upgrading, occasionally running reactions and fending off attackers, that was basically all my script was doing atm. Had to keep memory at under 100kB, preferably under 50k, since parsing the memory json object takes a enormous amount of time.
I despawned at the moment, because my credits (old model) ran out. Since maintaining a fully developed empire is considerably easier than building a new one from scratch I could not make up my mind yet to respawn somewhere with a 10 CPU limit.
I wonder if somebody is running successfully on that limit. I have 10 rooms and cannot get below the 10 CPU ( my avg is ~ 11 CPU ), just because of the sheer amount of basic scripts and checks I have running. So I wonder if it is really worth getting the client and have a serious shot on running a basic economy...
I would appreciate if the limit was raised to 20 CPU like it was the minimum with the old credit model, since this would give some headroom to actually do something useful.
I experienced the same yesterday - my usage jumped from 12 to 23. It is back to normal now.
What are the constraints of these portals? Can they link to inhabited and reserved rooms or only to unoccupied ones?
I'm talking about the Levenshtein distance between Nuke and Nuker and the human habit of interpolating words. As you may know, you are not reading entire words but rather abstracting them. Thus StructureNuke and StructureNuker have to small LD, to be easily recognizable, especially when you are having another Object that is already called Nuke, which creates assumption bias. It basically violates best practices of naming conventions.
And about your computer-themed world, sorry for being ignorant, but so far I didn't realize you had a theme and also I'm not aware of a computer term for e.G. "minerals" nor do i see any other (easily recognizable) terms related to computing. Anyway, the word nuke in IT is a derivate from the real-life "nuclear warhead", soas of now, you already have plenty of real-life terms in the game.
Just to be clear, I definitely would like to see a consistent theme for the screeps world, I just don't recognize it atm.
Also, please notify us, when updating the PTR. At least a oneliner in the IRC channel like "resetting PTR in 10 minutes" would make it able to save your work and not constantly wondering what happened.
Thank you for removing the ambiguity in the name STRUCTURE_NUKE, which made it sound expendable. However, I think, the new name is not a real improvement. Just adding a R at the end does not provide enough lexical distance to NUKE. The R is easily overlooked and typos are hard to spot this way.
I suggest:
STRUCTURE[_NUKE|ROCKET]_SILO
or
STRUCTURE[_NUKE|ROCKET]_LAUNCHER
Currently, nukes don't go off. Instead they receive a negative landing timer: https://screeps.com/ptr/#!/room/W13S11
- nuke cannot be place in the room via UI. Placing it via API works though.
- picture missing in UI
- graphic of structure missing (see https://screeps.com/ptr/#!/room/W18S13 [30,28])
Also, the naming convention is a bit off. The structure should be called "StructureNukeSilo" (or "launch facility" or however you want to name it) to emphasize, it's a real structure, not the nuke itself.
Also, range of 5 seems rather "low". I would like to see a (slightly) higher range with launch delays depending on the range.
> It is not a breaking change, and there is not really much to test. Preparation could take forever though, it’s easier to play with when it’s deployed. I doubt there will be immediate nuking all around at the very start.
That's what a PTR is for, not the live system.
The new rollout on PTR already introduced several problems, see separate posts in PTR section. I would prefer a robust Game world and have the experiments restricted to the PTR...
Why is such an important change included 3 days before the estimated Patch date? Shouldn't there be more time for testing and preparation? I think, there have enough changes for the 12th piled up to create a decent amount of non-working code and confusion. I think, moving it to a later rollout date would be wise.
I wonder if anyone of you is already working actively with the REACTION constant? I found it somehow useless and built my own, which looks like following:
const REACTION_CHAIN = {
/*....*/
G : {needs:["ZK","UL"],reacts:["GO","GH"]},
GO : {needs:[ "G","O" ],reacts:["GHO2"]},
GH : {needs:[ "G","H" ],reacts:["GH2O"]},
GH2O: {needs:["GH","OH"],reacts:["XGH2O"]},
GHO2: {needs:["GO","OH"],reacts:["XGHO2"]},
XGH2O:{needs:["GH2O","X"]},
XGHO2:{needs:["GHO2","X"]},
OH : {needs:["O","H"],reacts:["UH2O","UHO2","ZH2O","ZHO2","KH2O","KHO2","LH2O","LHO2","GH2O","GHO2"]},
}
This is an improvement in two ways: 1) You can specify the compound you need and easily determine the chain of needed reactions and the according reagents. 2) It is less verbose than the current one.
I wonder if you think alike, that the existing reaction object is not very useful? Perhaps - if not many people use the REACTION constant at the moment - we can ask the devs to change it in a way similar to the one above
.
The change with dedicated pages for each structure is very nice and provides a good overview of all the important properties.
One thing though:
Links have 800 Energy (Docs still say 500)
An overview of all inherited properties would be handy (e.g. as expandable list below the native properties) to not have to switch to different pages all the time.
Adding the relevant constants would be a nice bonus. E.g. for Links LINK_HITS, LINK_HITS_MAX, LINK_CAPACITY, LINK_COOLDOWN, LINK_LOSS_RATIO
1) The docu is wrong on Spawn.spawning. It returns undefined, not null.
2) Spawn.canCreateCreep could use a distinction between not being able to spawn because of:
a) not enough energy
b) not enough energy capacity
At the moment, there is only ERR_NOT_ENOUGH_ENERGY, but it doesn't tell you, whether it is case a) or b). I have my own prototype extension, which distinguishes these two cases, but honestly it would be nicer, if there were two distinct return codes for this.