3. Flag Bugs.

Flag Bugs.


  • This post is deleted! 👌
  • Dev Team

    Hey likeafox,

    Thank you for the report. The issue is queued for investigation and fixing.

  • Culture

    It gets really fun when you place a flag by hand in a room that has no active entities in it (enemy or friendly creeps). The flag gets added to your Game.flags object but you can't modify it in the code, which means if you try to change the color it fails to actually change the color even though setColor returns 0.


  • Programmatically creating flags is, to me, one of the most inconsistent and frustrating experiences in the game, and I think it should be a high priority issue to work on. Here are my biggest issues I have with how flags are handled.

    You cannot create flags in rooms you don't have vision in. This would be understandable if the only way to create a flag was room.createFlag(pos), since the room object needs to be defined to call createFlag, but you can also call new RoomPosition(x,y,roomName).createFlag(). Room positions can be defined without vision of the room they are in, so you would expect that this would be a valid way to place a flag, especially since there is no return code on createFlag such as ERR_NO_VISION.

    However, you can create flags in a room you have vision and then move them to a new position where you lack vision, although this works very inconsistently as @likeafox has mentioned. If we ignore the inconsistencies with this, the natural way to place a flag where you lack vision would be to place it in a room with vision and set a memory property, say moveFlagTo, and move it on the next tick.

    But you can't easily do this either, because unlike creating a creep with spawn.spawnCreep, you cannot specify the initial memory of a flag. There are, of course, workarounds to this, but given that flags are one of the first game mechanics that new players encounter, it seems like a good idea to make them as easy as possible to work with.

    What makes this even more frustrating is that you can do all of these operations manually in the GUI without issue. I'm not as much of an automation purist as some others, and I don't want to kick the "everything should be automatable" horse, but flags are a pretty integral part of the game and act as a very natural attachment point for processes in your code. Since they are such an important and frequently used part of the game, I definitely think that you should be able to do any operation with flags programmatically which you can do manually.

    If I may be presumptuous enough to suggest the way that I would refactor flag creation:

    • Remove the Room.createFlag(pos) method and only allow flags to be created from RoomPosition
    • Ideally, allow flags to be placed at room positions without vision. If there is some compelling technical reason this can't be done, add ERR_NO_VISION as a return code option
    • Allow the user to specify a memory object for the flag to have upon creation (this is already easy enough to do - cache the object in Memory.temp.flagMemories[flagName] and move the object to flag memory at the beginning of the next tick - but it would be great to have this natively supported to be consistent with the way creep memories are initialized)
    • Change the function to accept an object with named properties, similar to the recent changes with StructureSpawn.spawnCreep()

    A refactored function signature could then look like: RoomPosition.createFlag(opts?: {name?: string, color?: string, secondaryColor?: string = color, memory?: any})

    Just my two cents.

    1 Reply
  • Culture

    @muon said in Flag Bugs.:

    However, you can create flags in a room you have vision and then move them to a new position where you lack vision, although this works very inconsistently as @likeafox has mentioned.

    The problem is very straightforward. The server doesn't simulate rooms with no active objects. When flags were moved from being objects to serialized assets (some time ago...) they no longer forced the server to simulate that room. Creating a construction site, using an observer to observe the room, or using some other mechanism to make the server acknowledge the existence of that room will make the flags in it visible to your code. Until this is done, any actions done on the flag "object" (which is only generated when the server recognizes the room from real objects and deserializes the flag data) will not be processed because, like I just said, the object doesn't really exist.

    This isn't to say that the [Flag NAME] object doesn't exist, just that any modifications done to it are not processed.


  • Is there any effort to resolve the issue?


  • I think it could be done by reworking how flags are handled by server. Make them not like room objects but just a lightweight objects created by player on each shard (storing can be done by roomNames for more efficient search logic). They have properties name, position (which determined by roomName, x, y), color and secondaryColor. Memory is just stored in player's Memoty.flags object. Sure it will require room search code account for this new way of flags storing.

  • Dev Team

    Wait, this issue should be currently fixed.