Superfluous ConstructionSites - Relocating structures



  • You could see this as a player challenge: implementing a "move structure" function yourself 😉 I'm not a fan of having this supported by the game. Let pull remain creep only.

    It's not that difficult either after RCL 4. Just ensure you have a storage with sufficient energy.

    • CONSTRUCTION_COST["spawn"] is 15,000
    • BUILD_POWER is 5 in the game constants, so 15,000 / 5 = 3,000 work actions.
    • RCL 4 allows spawning [6 WORK, 6 CARRY, 6 MOVE] creeps.
    • 3,000 / 6 = 500 ticks of creep.build() with a single builder.
    • Because the builder has equal WORK and CARRY, it's used all energy it can carry after 10 ticks.
    • Therefore haulers effectively need to replenish 6 x 50 = 300 energy every 10 ticks.
    • Because RCL 4 allows for [17 CARRY, 9 MOVE] creeps they can haul 17 x 50 = 850 energy per run and move every tick on roads.

    That should be enough to solve the rest of your puzzle. The pieces don't match up perfectly, but there are numerous ways to work around that.

    ☝

  • TMB

    @MrFaul
    One thing we could do to limit their use as backup buildings is reduce the health and max health of active building the more ReconstructionSites and the more progress there is : let's say having all ReconstructionSites set up and fulfilled would limit all other structures of that type to 1HP.

    Pulling structure would be a good idea too; it's a little odd, but it also solves the issue of moving the content of storages along with the storage.
    Though that would mean the position of structures is no longer constant, and that might be a breaking change for some.

    @keenathar
    That is assuming the room you wish to remodel is RCL4 or above, which you doesn't reach in a snap, and 3,000 ticks of not being able to spawn creeps is still 3,000 ticks of other activities being potentially halted.
    Even with the perfect code, relocating would still be major inconvenience at lower RCL, not in term of how I can script this, but in term of how much it may impact the rest of the room's economy even if I do it right, and especially if I do it wrong.



  • I think moving/pulling is quite simple to achieve all you do is updating their position,
    well and add the move command so they can accept the pull request.
    (... why do I now think about git hub... 🤔 )

    I think that is a very cheap method without the need of big changes, a lot of updates and unnecessary edge cases.


  • TMB

    For pulling, all the edge cases I can think about are :

    • Pulling structure nearby or onto a room exit.
    • Pulling a rampart into another rampart.
    • Pulling a road onto another road.
    • Pulling a container onto another container.
    • Pulling structures into a tunnel.
    • Pulling the room controller.
    • Pulling an extractor (wouldn't be an exploit, but would be pointless)

    It's allowed in the simulation to stack structures on top of each other, so we know it may happens if we're not careful.

    Another alternative that comes to my mind: fully embrace the idea that a superfluous site is solely for reconstruction.
    The site has to be linked to an existing structure: if the structure is destroyed, the site is destroyed as well; when the site is complete, it produces a carbon copy of the linked structure, thus including content and current HP. (Might as well say that the site would teleport the linked structure, but I prefer giving a whole new ID to the relocated structure.)
    In that case they might not exactly be ConstructionSite, rather a new Class that derives from ConstructionSite, and they would not be placed from the Construct menu, but from a "Relocate" button on a structure's inspector. From the script, they would be placed through a .relocate(pos) function of an existing structure.



  • Most of that is fixed with the same check that the construction sides use...
    so not really a concern in my view.
    And roads walls etc. should be unmovable anyway there no point in moving those.


  • Dev Team

    I'm not sure that I understand a game value of the proposed feature... but I definitely see how this breaks existing game values. Wisely choosing how to build and how to maintain your room is not an 'unnecessary obstacle' for anything, it's a challenge that makes the game deeper. Like, a player can't destroy his structure when hostiles in the room for the sake of balance.

    As for your problem, you probably should raise your room to RCL7 which support two spawners, build second and then safely rebuild the first one.



  • @o4kapuk yes I'm not complaining but could be fun watching creeps pulling on buildings 😆
    but I'm still a bit annoyed that there is no option for allowing your script to set your first spawn.

    That is still manual I would much prefer to click "Spawn in here" and let the script handle it, maybe with some kind of "first function" that allows to place it.


  • Dev Team

    @mrfaul if we run code for all players who don't exist in the game world every tick at each shard, the game would be unacceptably slow.

    I think there was an external script for spawning somewhere in the community, try lurking around.


  • TMB

    @o4kapuk I understand that a room's layout shouldn't be changing every day of the week, but the spawn is the very first thing you have to place in order to start a room, when there's nothing else around to guide your choice; RCL7 is the penultimate stage of the room.

    Having to plan ahead the entire history of the room before allowing myself to take the very first step is not something I'd be fond of, neither is having to carry an initial misguided choice until the room is basically finished.
    So it's more for quality of life than actual gameplay.

    As for your solution, I can't "just" rise to RCL7, this one will take a lot of time; it's a room-scaled game ending to my novice eyes, and I have yet to reach it in any of my rooms.

    (Aside, I don't see how destroying structure during invasions has anything to do with game balance. The only advantage I can think of is destroying tunnels to block off accesses, and that's still very situational.)



  • If you have at least GCL 2, you can claim a neighboring room and use that room for spawning until you can rebuild your spawn.

    👍


  • FWIW I've written code to relocate any structure in one of my bases, and it's not an unsolvable problem. To relocate storage, it evacuates all resources into terminal before destroying the storage, and vice versa. This wouldn't work pre-rcl 6 but I can live with that restriction. To relocate a spawn before the 2nd spawn turns up at RCL7, I enforce a minimum amount of energy in a storage, and spawn a certain number of builder creeps before destroying the existing spawn.



  • @o4kapuk said in Superfluous ConstructionSites - Relocating structures:

    @mrfaul if we run code for all players who don't exist in the game world every tick at each shard, the game would be unacceptably slow.

    I think there was an external script for spawning somewhere in the community, try lurking around.

    That is true but I never said anything about that, I talked about a button that runs your "setup code" which could be exported like the main loop.
    And I personally don't view relocating structures as that difficult I just thought pulling structures could look really funny.
    I just have this picture in my mind of a train of screeps all desperately pulling at one spawn 🤣



  • I like the idea of the "setup code" button. If the problem with placing spawn by code is just that you want to avoid running code for all players that dont have a spawn, this would solve it. Have some button for claiming a room, this will enable running your code even without a spawn/creeps/structures etc for a set period of ticks before timing out. Means your code can run and place the first spawn automatically, but it will only run for some ticks before it would get disabled if the spawn fails to place within the allowed time automatically.

    ☝


  • @estecka said in Superfluous ConstructionSites - Relocating structures:

    That is assuming the room you wish to remodel is RCL4 or above, which you doesn't reach in a snap, and 3,000 ticks of not being able to spawn creeps is still 3,000 ticks of other activities being potentially halted.

    I explicitly stated that as a criteria, hardly an assumption. After you've played a bit longer, RCL 4 isn't as daunting anymore. In some players are able to reach it within the safe mode after respawning, so in less than 20.000 ticks (roughly 16 hours). You'll get there 🙂

    Additionally, I said 3000 work actions: it would be 3000 ticks if you used 1 builder with 1 WORK part. Divide the number of actions by the number of WORK parts used to build each tick, like the builder with 6 parts in my example, and you'll get the total number of ticks spent on building. At RCL4 this can be finished in 500 ticks with a single builder, which gives a lot of margin for error (delays).

    @estecka said in Superfluous ConstructionSites - Relocating structures:

    Even with the perfect code, relocating would still be major inconvenience at lower RCL, not in term of how I can script this, but in term of how much it may impact the rest of the room's economy even if I do it right, and especially if I do it wrong.

    Well, yes, it is an inconvenience. But everything in this game is. Not being able to control creeps like in an RTS is an inconvenience. Not having vision in certain rooms is an inconvenience. Pathfinding brings inconvenience. Some structures have .store and some having .energy brings inconvenience.
    Overcoming these challenges is at the core of this game.



  • @geir1983 I also like the idea, it's a bit odd that I have to handle two cases - my bot builds the room around where I manually placed a spawn, vs the spawn is placed based on how my bot decides to build the room.

    👍

  • TMB

    @keenathar said in Superfluous ConstructionSites - Relocating structures:

    Well, yes, it is an inconvenience. But everything in this game is.

    These examples are hardly on the same scale, and can all have a definitive solution.
    I can give orders to my creeps through simplistic memory edits and flag placing. I haven't had to worry as much about room vision since I've been using a wrapper class for roomobjects.
    Some structures use store instead of energy and you can't harvest the extractor? those are the easiest. It takes three lines to write any of these properties then you won't have to think about it ever again.

    My bad for the misunderstanding about the work actions. I realized it as I attempted doing it myself, but it was still a whole operation that required human supervision and a tailor-made solution.


  • Dev Team

    @geir1983 I'm not sure if we can do anything like this being usable. You see, providing vision on all of the rooms is not possible technically, but without vision, you can't make decisions based on the most important starting criteria: controller and sources locations... even sources count! So even if we can add a special export for finding the initial spot, that doesn't add any game value.



  • @o4kapuk I think the player would still need to choose what room to claim, just not place the first spawn. That way he would claim the controller in the room, providing vision for his script who can then calculate the base layout and place the spawn. It is a special case scenario, as you dont respawn that often (except in botarena and swc) and you need to have code for creating your base layout, but it is a common request i believe.

    👍

  • Dev Team

    @geir1983 did you try the community solution I mentioned earlier?



  • @o4kapuk I never tried it, but from what i understand it does not call my own room planner, it has a seperate set of functions to do it "offline", so i would need to export and rewrite my own room planner to python to make it fit the needs of my own planner. Its quite interesting, but makes me have to maintain two different room planner projects for it to work.