Topics created by WarInternal

Should be fixed with server version 4.0.0-beta.1.

I've changed my mind I don't think container up sizing is worth the disruption. However, double the number of containers might allow for some new and interesting solutions, especially in SK rooms. 10 remote containers cost 5 energy per tick to upkeep, but allows for more CPU efficient hauling. I think that is an interesting tradeoff. Currently you need 8 sources in range to feed a T3 boosted 40 CARRY. Double the number of containers means you could feed it with 4 single source rooms where each source has 8 containers. Running the hauler less often is easier but efficiently mining out a source into 8 containers as worthy trade off. Caravans have two problems. One is buffering between trips. But I find the second to be a bigger issue. Caravans don't offer any advantages over 5 single haulers. If we tweaked the pulling mechanic to allow for single intent caravan movement that would give me a reason to use caravans.

Good idea. Instead of zoom I would wish width and height in tiles, so that it's guaranteed that your area of interest is completely visible on every display / window size.

I find the entire even log system as it is right now very unwieldy and nigh-useless. Certainly not what it could be. Also parsing event logs for every room you run is a significant investment of CPU cycles, which pretty much prevents its use for every day tasks.

That did it. Thanks

This is known issue but thanks for the report anyway

It's possible to use the call stack to determine which file you're in. https://github.com/deft-code/typescreeps/blob/master/src/debug.ts#L9 This is very similar to the code I've using now. I use this trick to add a file and line number to my console.log messages. Using this trick you could write an alternative require proof of concept entirely in game code rather than in the engine. You might have use a different separator; I don't know what the api will do with files with / in the name. (the current require implementation ignores leading ./ so might have to work around that also.

Quick hack to fix this. Creep.prototype._notifyWhenAttacked = Creep.prototype.notifyWhenAttacked; Creep.prototype.notifyWhenAttacked = function(notify) { const spawning = this.spawning; this.spawning = false; const ret = this._notifyWhenAttacked(notify); this.spawning = spawning; return ret; }; The processor doesn't check that the creep isn't spawning. So bypassing the client side check in Game is all you need. Getting rid of the restriction entirely is better idea though. The change is simple and sane enough that you would probably get it done faster by creating a pull request than asking them to do it for you. PS: Devs, please make an official intents api, most (all?) client side checks can be bypassed anyways.

Sure, feel free to make a PR.

Thanks for reporting, fixed.

sparr, when the server is open source you can make a pull request

See this thread.

I'm pretty flexible on the implementation details. Maybe it's a purely aesthetic, visual change and doesn't affect the find or look calls, as you need room visibility still, which means you would either need a unit in the room or an observer. Even if it only affects the UI, it could still offer a minor strategic difference.

I've created 200+ single MOVE part creeps once. Besides the loss of my cpu bucket, my client lagged severely. So that is a thing at least. >.>