Posts made by DoctorZuber

The idea is to take away visibility from rooms that your script cannot see. No longer would you be able to just look at the map and know what your script cannot know, letting you essentially bypass the visibility rules with direct commands and manually placed flags. If possible, in this world, even terrain should be hidden in non-visible rooms.

For an extra challenge, a second rule could be to no longer show usernames of unfriendly creeps and structures. I think this would neatly eliminate any form of allied play, and bring some interesting strategic puzzles to consider.

Spawning new into a shard with these rules should be handled a bit differently. Instead of allowing a player to select a room on the map, a short list of rooms should be randomly selected for the player to choose from, showing the terrain, source, mineral, controller as usual. If the player finds these choices unsuitable, he can request that the server re-roll a new set of suitable starting rooms after a brief cooldown time (30 seconds or so).

Admittedly, this would also break any concept of spectating on this shard, but I think the individual challenge in such a world could be refreshing for some players. Of course, this is a major world rule, and I wouldn't want to break what already exists. This is proposed merely as a possible set of rules for an alternative shard. Those who find these rules unappealing, are free to play on other shards.

One of my oldest grievances with this game is the instant respawn issue.

The issue is that a player can click the spawn controller and release control of the room. Then in mere seconds, a different player, or in some cases even the same player can click respawn, select the room and lock it down for an additional 20k ticks of safe mode.

There should be a cooldown when any room drops to RCL 0 preventing any player from respawning into that room for at least 24 hours, possibly as long as 72 hours. Claim creeps would be unaffected.

That would prevent a lot of the headaches players have with bad manners and just plain bad luck when they clear a room to expand.

I'm not so sure there's really a difference. The obvious doomsday scenario is pay to win multi-account empires. But we already have massive multi-account empires dominating the game.

Personally I hate how alliances have changed the world of screeps, although I have long since accepted that whether I like it or not, they are here to stay.

So from my perspective, I really don't see a downside to allowing multi-account play anymore. They would not be any different than what we already have.

fixed, apparently.

I have not tested exhaustively, but it appears this function reports false for all rooms in shard 1.

Something tells me this is not intended behavior.

Reported by several people in Slack.

Nuff said.

Currently, we have a code branch for sim, and a code branch for world. With the very soon to exist shard system, it would be very helpful to have a code branch for each shard as well.

What we do on our primary shard, could be quite different than what we do with a small colony on a different shard. 

Why should it only be PvP? If an Invader or a Source Keeper damages you, you should get that information too.

Alternatively, if the idea of a dead creep telling no tales is really such a big issue for people. the alternative is to extend it off of Room. If this direction is chosen it should be subject to normal visibility rules. As already suggested, I think an array of damage sources would make sense, but in this case it needs to list both attacker and defender for each event. 

If we are killed instantly, I'm perfectly okay with that data being unavailable. Killed too fast to report. No problem. As for the target being killed in the same timeframe, I am also completely okay with this. It can be our responsibility to test for null on Game.getObjectById(); I suggest storing the following data in an array. on any creep or structure. This data should only be available on the very next tick only. i.e. it should ONLY list damage from the previous tick, or nothing. It should be an array because there could be multiple damage sources.

creep.prototype.damageSources (array)

.id

.amount (of damage)

.owner

structure.prototype.damageSources (array)

...

the potential forest of attackers that could have attacked you, starting with just ranged attack is 48 creeps, assuming the admittedly unlikely scenario that a veritable swarm of creeps surrounds you. Then you need to consider towers. And whenever Power creeps get added to the mix there will be additional potential damage sources since there is a creep that can buff your range to 4, and there is a sniper who can strike at range 10.

So the total number of potential targets is 54 in a hostile room with towers. If you add in range 4 and snipers from potential future content this number grows to 87. That's 87 tiles that your creep needs to scan for creeps to even begin to try to GUESS who just actually hurt you.

is it really too much to ask for a simple list of who damaged you last tick?

Creep.attackedBy();

OwnedStructure.attackedBy();

returns null, or an Array of entities that damaged your Creep or Structure Last tick. entities could include Towers, Creeps, and in future PowerCreeps.

The problem is that the code has absolutely no way to distinguish which creep or even potentially which player just damaged it. If your code gets attacked, If you are in an alliance, and someone betrays you, you have a very real problem. What if two different allies are in range of your creep at the same time? Is your code supposed to flip a coin to decide which ally you must now break the alliance with? 

It's not that it's a difficult problem to solve in code currently, it's actually an impossible one. Our code should not be forced to GUESS who just attacked it.

I get that the 'sim' is a single room environment. But if the room exits simply wrapped back around to the same room this would be invaluable to me for testing purposes. 

And if you look at it, the exits already line up perfectly. So you wouldn't even have to alter the shape of the room. Just map these exits so that they link right back to the opposite side of the 'sim' environment.

I know you've got a lot on your plate, but keep this one in mind please? Thanks!

Memory.creeps(creepName)

Object.keys(Memory.creeps);

the name is your hash key. having a .name tag as well would be somewhat redundant.

I agree, this should be added.

In the meanwhile we will be stuck turning an object(hash), into an array, selecting the first element of that array, feeding it back into that same object to select the first object of the object(hash), and then selecting one property from that object. That's one of the more backwards lines of code I have had to come up with just to do a basic thing like know what your own username is.

Game.spawns[Object.keys(Game.spawns)[0]].owner.username

I personally think it's a good idea. The exact numbers are open for debate, but a limit that expands a little, but still feels restrictive to an experienced player would be more inline with the concept of a newbie area that expands. 2-4 would work for me. since at either 15 tiles, or 81 tiles that is not nearly enough rooms to really control the entire newbie zone, but it would give new and old players alike a fair shot at trying to get as much as they can. 

The title says it all really. There should be an optional argument in Creep.pickup() to let you specify an amount of something you want to pickup. 

I realize it is a bit of an edge case where someone would want that option, but I see no way for us to code in that functionality ourselves if we do want it.

I still agree with this one in the context of newbie zones, although this has been adjusted quite a lot by the modified timers for controller decay, so it's not as big of an issue as it once was.

Outside of newbie zones, I completely understand and agree with the longer timers for control decay since it is actually a very real possibility that alliances could help recover a fallen comrade.

All of this has been debated before in other threads.

it would be helpful for my sanity to have a way to test if a string is a valid room name or not.

While I admit that I could write something myself that would do the job, the gets thorny quickly when you consider non-visible rooms as well. Then I need to either depend on some assumptions about the map size and shape and use constants, or somehow find some function I can abuse to somehow test if a non-visible room name even exists.

To the best of my awareness from digging, the only clean and reliable option here is going to be to ask you nicely to provide something.

Thanks!