Posts made by WarInternal

I'm not necessarily worried about it keeping up with season goals. I care mostly about the interesting new runtime and world layout.

/bump

Yeah so this is still an issue. Some people are discussing how to utilize this for storage. Seems a creep name of 1 mb is achievable in the PS, unknown in MMO. > 50 though.

We should probably fix this before it gets abused as heavily as the flag name length was.

50 doesn't necessarily need to be the exact limit, but seems like a fair number. I wouldn't go any smaller. But there definitely needs to be a limit in place.

Is this really the best solution you could come up with to the problem?

Logically this is going to be bad to wire up. And for those of us generating a pixel it means once every 17 - 50 ticks we're going to skip the entire tick and nothing in our entire codebase gets to act?

I understand needing to slow down pixel generation. But this is a terrible solution.

The engine code actually very rarely to never calls the structure isActive method, it's hard coded to check against controller and does a very, very expensive partition operation every time it's callled. It's also however not easy to fix, as the ideal would be to calculate and cache this information whenever RCL changed or a structure was placed/destroyed.

If possible, it would be helpful if the console was available while in map view as well

Thanks! I can confirm it does work now!

The engine code suggests it should but I think this line is what's preventing it from working:

var extensions = _.filter(roomObjects, i => i.type == 'extension' && i.user == target.user && !i.off);

at https://github.com/screeps/engine/blob/master/src/processor/intents/power-creeps/usePower.js#L112

I think it's caused by the i.user == target.user portion, and containers not being owned.

Looks better now

Probably related to the recent downtime, but at time of writing I've got several rooms on shard0 not ticking properly. Containers with negative decay, creeps with no ticksToLive, invaders not moving, downgrade timers running but not accepting upgrade actions (despite displaying the animation).

Facing a situation I could resolve with a single cpu halt, but can't execute anything due to the error.

@o4kapuk That's in shard0 E55S37

Invader cores can also apparently overlap structures

Since invader cores are hostile structures in room, we should be allowed to dismantle them.

Better, I can actually log in now. But there appears to be a visual bug. Room visuals appear to be working, walls and ramparts appear to draw (although the texture on constructed walls is missing), but few other structures seem to draw at all and creeps do not. The invisible items can still be selected however.

MMO-PTR seems to render correctly in this client, so this bug appears limited to connections to private servers.

The structures that do render appear to change each time the room view is opened.

@o4kapuk Any input on this? It's still a problem.

I can't test the store and factory changes on MMO-PTR with 15 second ticks and no history, I'd like to test it locally with the steam PTR branch but it's currently not working. Please assist.

Steam client PTR branch is stuck on "new update has been downloaded", won't actually update or allow me to enter the game, this is with a fresh install. Unable to test PTR changes locally.

@saruss A minor inconvenience is not a reason to never rebalance things.

Also maybe consider moving away from a hardcoded modifier.. If you use 0.25 because it's 500 energy, write it as 500 / CONTAINER_CAPACITY, and then figure out where your buffer amount of 500 is calculated from, because it's probably dependent on room or empire factors.

You're both wrong with regards to breaking changes. This is why we have a storeCapacity property and CONTAINER_CAPACITY constants. If a user has hard-coded these numbers into their code without using the constants or the actual object's capacity then they have made a mistake. In no other circumstance would changing that value break anything.

I think containers should be significantly larger, to increase risk/reward and reduce cpu by sending out haulers less often. At least 2x or 4x the size. Currently a container is only worth maybe two creeps worth of carry parts, and not even the size of normal source.