Posts made by pruby

MMO - Shard 2

Thank you for the explanation. This seems like it changes the incentives on how to respond to these cores somewhat!

I was trying to debug why my code was incorrectly handling rangedMassAttack by hostile creeps, and just recorded this log in a room:

[{"event":1,"objectId":"5fee717da02332f70f4ad9b2","data":{"targetId":"5fee6d39091d6698f9dc2b0c","damage":60}},{"event":1,"objectId":"5fee717da02332f70f4ad9b2","data":{"targetId":"5fee70f22c15f314c4c5b581","damage":60}},{"event":10,"objectId":"5fee71d545cefeca948d1e84","data":{"room":"E42N44","x":27,"y":0}}]

Note that creep -ad9b2 attacks twice, hitting two separate targets for 60 damage. This creep was attacking with a rangedMassAttack, however the event data does not include the attackType field specified in the documentation.

The docs claim that each invader core can spawn 10 lesser cores... well this is 21 [EDIT more: didn't notice ruins were stacked on top of each other] and counting, absolutely continuously. What's going on?

https://screeps.com/a/#!/history/shard2/E43N45?t=30047600

@artch Ah hah, I have it. I habitually open links like that in a new tab by middle-clicking. This doesn't trigger your logic to clear the flag.

This is a really good solution to make sure people see announcements! Only issue for me is it's not going away - what's the logic for when it shows?

How about a "race" variant where a tall fixed-height map keeps expanding to the east, while losing rooms along with anything in them at the western edge (e.g. by a column per day)? Minerals could be very much biased in to vertical bands, and never all available at once, so you have to carry forward a stockpile from room to room if you want boosts.

Oh for goodness' sake guys. Having accounted for the change you announced, and prepared some days in advance, I come back here after seeing errors I couldn't explain (lost ticks), to find that you made a different change and didn't start a new announcement. Lucky this is a game and not something that actually matters...

As I understand it, Node's Buffer is dangerous to expose from a security perspective. This is because it allows you to allocate and access uninitialised memory... though perhaps in the context of IVM this is cleared? Anyway, at the very least it's a bunch of pointer leaks they probably don't want.

Back to your original idea, providing TextEncoder and TextDecoder would be really useful not just for Rust users, but for anyone wanting to do custom memory or WASM modules. I'm in the JS crowd, but would love to have a proper way to store an ArrayBuffer in RawMemory or segments without an incredibly slow polyfill. JavaScript strings are just awful to deal with.

Like the others, I think this is a strange and abrupt way of dealing with the overly simplistic generation of pixels. Perhaps instead you could make it behave more like Bitcoin mining and self-balance:

EDIT: hadn't read post immediately above, crossed out impractical bits.

• Introduce a "hash function" as Game.cpu.hash, which is artificially expensive and actually taken off the current tick's use (e.g. 100CPU). You could implement this behind the scenes as an HMAC with a per-shard secret, so people can't actually implement it.
• Introduce a "difficulty" level for the "Pixel Chain". You have to find an input in a particular format (e.g. ${shard}-${Game.time}-${random} that has a hash value below that difficulty (interpreted as a number in ?-endian order).
• Submitting an entry could also cost CPU to "validate" (whether or not it's correct) and have to be done in a particular tick used as part of the input. This means you need to have enough left over after generating them to submit it...
• Perhaps a penalty if you sub invalid inputs?
• Periodically update the difficulty level to reflect the amount of mining happening, targeting a constant generation rate. People then have to decide what their CPU is worth...
• When people get this right, you could give them a batch of pixels at once, introducing more randomness to the process. Nothing, nothing, nothing, 100 pixels!, nothing, nothing...

Fantastic!

Heya,

It would be quite cool from a logistical/optimisation perspective if I could "tow" one creep with another. This would require me to (1) set an intent to tow an adjacent creep (same owner), and (2) move the towing creep to another square.

This would create a low-priority intent to move the towed creep to the spot previously occupied by the towing creep, and add the appropriate fatigue (treating even MOVE parts as weight?) to the towing creep as well as the cost of its own movement.

The main and obvious use of this would be to place immobile creeps elsewhere (e.g. harvesters) and to more quickly deploy creeps at extra cost. It would be effective as a tactic only if the towing creep could then be re-used. This would be complicated to get right, but offer an opportunity to optimise for those willing to do so.