Minimum information needed:

Which shard is affected?

• All

What happened?

• When utilizing an some functions, such as attack(), in a room with safe mode, misleading values can be returned (example: attack returns -12 ERR_NO_BODYPART)

What should have happened?

• Up for discussion, see below

How can we reproduce this?

• Have a creep attempt to attack a hostile structure/creep in a room with safeMode active

While I was going to submit a PR changing the return values for functions like attack() and rangedAttack(), in my opinion rangedMassAttack() raises a problem.

When utilizing attack functions like these in a room that is not yours, and has safe mode active, the return value is ERR_NO_BODYPART.

Engine /src/game/creeps.js #604-605

        if(this.room.controller && !this.room.controller.my && this.room.controller.safeMode) {
            return C.ERR_NO_BODYPART;

When doing something like attempting to withdraw(), the return code is ERR_NOT_OWNER when you were never the owner of the targeted container!

Engine /src/game/creeps.js #528-529

        if(this.room.controller && !this.room.controller.my && this.room.controller.safeMode) {
            return C.ERR_NOT_OWNER;

I feel this is extremely misleading. Granted you should (ideally) not be utilizing these methods in a room with safe mode in the first place (often saves CPU on find checks/pathfinding to avoid these sections entirely, and keeps creeps from exploring into rooms they have no purpose in), but I don't believe it is appropriate to design the API with idealized code in mind. New players may utilize these functions and be confused by this return code (as happened in the Discord today with attack()) I spent a bit of time trying to help this player identify the cause, only for their suggestion of safe mode being active to finally lead me to this issue.

In my opinion, the ideal solution is a new error value: ERR_SAFEMODE_ACTIVE or similar, but ERR_INVALID_TARGET is also acceptable. My reasoning for these two are as follows:

Argument for ERR_SAFEMODE_ACTIVE

I originally wanted to suggest a change to ERR_INVALID_TARGET, but this raises two issues.

Less importantly, it does not make a distinction that safe mode is active. A target that would otherwise be a valid target (eg. a hostile spawn) can become an invalid target the tick that safe mode is activated. This might(?) be confusing for a new developer, but I find this less problematic as players have the responsibility to have an understanding of the game mechanics.

More importantly: ERR_INVALID_TARGET would be an extremely odd return code for functions like rangedMassAttack() which have no target.

Especially for new players, ERR_SAFEMODE_ACTIVE or similar would be extremely clear as to the cause of failure for that action. While these actions are often executing with invalid targets, some actions now (and possibly in the future) are not targeting and thus would not

Argument for ERR_INVALID_TARGET

While less specialized, this does not require the adding of a new constant. It is much more clear than ERR_NO_BODYPART, as that is what is happening: whatever you are doing (even rangedMassAttack()), the target is not valid (since you cannot target anything within a safemode room for these actions.)

There is even precedent for this. When attempting to move into a space where any creep is present while safe mode is active the game returns ERR_INVALID_TARGET

Engine /src/game/creeps.js #799-807

        if(_.contains(C.OBSTACLE_OBJECT_TYPES, target.structureType)) {
            if(_.any(objectsInTile)) {
                return C.ERR_INVALID_TARGET;
            }
            const blockingCreeps = (this.room.controller && this.room.controller.my && this.room.controller.safeMode) ? myCreepsInTile : creepsInTile;
            if(_.any(blockingCreeps)) {
                return C.ERR_INVALID_TARGET;
            }
        }

Power creeps also return things such as ERR_INVALID_ARGS or ERR_INVALID_TARGET for certain actions when safe mode is active in the room. usePower(), if it functioned similar to things like attack() on creeps, would return ERR_NO_BODYPART if we were remaining consistent with our return codes.

I hope one of the two will be considered. It is not a pressing change, but either solution should be a minor change to the engine code that would be much clearer and more accurate in my opinion.

I know this would be fairly low on the priority list, but I wanted to present it.

The short version: I think it's a neat idea to allow creeps to apply Grafitti as a temporary object to any room, whether you own it or not. I think players should also be able to use their creeps to remove (dismantle) that Grafitti objects.

Currently, as far as cosmetics you can receive from Pixelization goes Grafitti might be one of the least valuable ones, and almost certainly the least noticed. While some Grafitti is visible from the world map, the majority likely go unnoticed even by the players that placed them. I know I have a few personal favorites that I am happy to see in my rooms, but they are definitely below creep customization, landscape customizations, and badges.

I would like to suggest the ability to apply Grafitti, as actual Grafitti. The ideal system might be something similar to this.

1. A creep is able to apply Grafitti objects you own via code.
   • This would likely require the creep to have an appropriate part, work seems to fit the role best.
   • This could require energy to apply, which would limit application via both resources and time (similar to construction sites.) Higher rarity Grafitti (customizable lighting, appears on the world map) could even possibly require rarer resources to apply.
   • This could be another construction project, which would fit the above (Work part required, energy required to apply)
   • This could degrade over time, and require repairs to maintain. It could be permanent until removed, but might clutter the world since current Grafitti is limited to rooms the player owns. Grafitti degrading would cause unmaintained Grafitti to not take up server resources.
   • This would likely have to target a square on the map which has the 'Wall' terrain present. This would not be as fine placement as current Grafitti application, but would be a reasonable compromise for simplicity of the implementation.
2. A creep is able to remove Grafitti objects
   • As above, this would likely require a creep with the appropriate part. Work seems appropriate, via the dismantle action, although whether or not you should recover the energy would be a topic of discussion.
   • This would fit with the nature of Grafitti. Players can remove Grafitti for any reason.
3. Grafitti is able to be applied to any room. This could include rooms you own, other players own, or neutral rooms.
   • This would enable many of the interactions I believe would benefit it in the below list.
4. Whether or not you are still able to apply 'permanent' grafitti to the rooms you own would be a topic of discussion. It would limit some of the benefits I list below.

Some of the benefits of implementing this, in my opinion:

1. More player interaction options. Players are able to tag rooms with their favorite symbols, collaborate with Grafitti between allied players, remove Grafitti of other players, tag rooms they take, or for any reason they deem appropriate. It also becomes a point of contention. You decide whether to spend your resources to do things like attacking creeps that are only there to tag your room, or to spend your creep's lifespan to remove Grafitti or let it stand. If you apply Grafitti of your own, how do you differentiate between hostile tags and your own? If a friend comes to apply a tag you like, you have to maintain it or risk losing it until they can apply it again. Perhaps player trading becomes an option, paying players in resources to apply highly desired Grafitti to your room? There are quite a few possibilities here.
2. Grafitti as a form of prestige Grafitti as a temporary object that requires maintenance, for lack of a better term, becomes a bit of a flex. Being able to maintain large amounts of Grafitti, at a long distance, or in hostile areas becomes a demonstration of your free resources and your code.
3. Grafitti as another code reference. If it is possible to uniquely identify the owner and image allows some interesting code possibilities. The fact that it decays over time can allow it to serve as a time-sensitive flag, scouts can take note of the owners of grafitti they pass by and its freshness (noting that a creep was here and dedicated time to place it), coordination and communication between different AIs via Grafitti becomes an option,

I imagine there are other benefits, but I wanted to list a few possibilities here. I think it lends value to the Grafitti objects we get, encouraging players to trade Grafitti by giving it more interesting uses than just decoration for your room, encourages players to find and save their favorites for different purposes, provides another use for energy (and possibly other resources), and provides another interesting coding project for players to pursue.