Boosting 'Bug' fix with No testing, No announcement, and working 30% of the time.



  • @duckymirror This is not bad. This is game mechanics. It can be different depending on how to present it.

    I can imagine how creeps is creating from differents parts in the spawn structure, but I can't imagine how lab can boost something that not really created yet.



  • This post is deleted!


  • @likeafox Oh, I drifted a bit off-topic.


  • Dev Team

    BECAUSE IT STILL WORKS

    Thank you for reporting this. It turned out there was a deployment failure on some nodes, we've redeployed the patch (and some previous patches as well), now it should work on 100% of cluster.

    There was no error code created by this

    The error code is ERR_INVALID_TARGET.



  • I am affected by this change. I think this sort of thing can be handled better in the future. To give credit where it's due, developer communication is at an all-time high right now. I think all the players enthusiastically appreciate that. This update does present a problem though, and I believe more communication was needed.

    Based on the commit message, the developers have taken the stance that this was a bug. For a minor bugfix, it is reasonable to slip in a change without forum announcements. Unfortunately, I was unaware that this was considered a bug. As a player, it was not obvious to me. Here was the sequence of events from my perspective.

    • Heard about preboosting in my alliance slack. This sounded like a very cool thing, but it definitely sounded like an "unitended consequence" sort of thing.
    • After a few weeks, I saw discussion about preboosting in official slack (which I don't keep up on very well.) The two categories of responses I saw were "Neato" and "Neato, I think I'll do that." I did not see anyone flag it as a flagrant abuse or indicate they thought it would/should be patched out. There was no developer response that I saw discouraging implementation of this feature. If players who used this feature thought it was OK to openly discuss, they probably didn't consider it an exploit either.
    • I waited. I am a cautious person by nature. I have 300M ramparts in my rooms. Getting my old lab reaction+boosting code to work right took me months of debugging edge cases, and I had no desire to rewrite it if there was a chance of preboosting being removed. Note that I did consider this possibility. However, there had been very little updates in the last year, and similar features (multiple mineral harvesters harvesters at the same time, harvesting just minerals in SK rooms to avoid invader spawns) that existed for longer had never been patched. My completely rational conclusion as a player was that preboosting is part of the game, unlikely to be removed, and fair game for implementing.
    • In July, I made a completely new room layout to take advantage of preboosting and reacting all 10 labs. It was a nightmare to implement, and I got it absolutely seamless. The boosting happened during the gaps between reactions. I could run 10 labs and boost and there was never a hiccup for all but the cheapest cooldown time reactions. I'm pretty proud of this, I think it was the most elegant piece of code I have ever written. Note that there were tradeoffs/sacrifices in base layout required to make this work.
    • I started updating my rooms to use the new layout. Currently I think I have 18 of them on the preboost layout. I had to move spawns, labs, storages, terminals, and 300M ramparts to make this work. Not Fun.
    • 3 days ago I heard a rumor preboosting might be removed.
    • Today I found out that it was patched out with no announcement. Over half of my rooms are now defenseless, since I had preboosting reliably implemented and there was no fallback boost mechanism needed. The rooms either preboost, or they don't boost at all. I have economic features the depend on boosts, and those are broken as well.

    I hope you will understand that this is a big problem for me as a player. My new rooms don't have enough space to switch to my non-preboosting method. The new layout made significant sacrifices in walk-ability of labs in order to get preboosting to work. I now have to code up a third boosting solution (internal weeping), that will have only the worst properties of both my previous solutions, and in the meantime, I am vulnerable to attack. My feelings are probably not relevant to this discussion, but I feel that I have been royally screwed.

    I would like to request the following actions from the developers. I acknowledge that this is not a democracy. You will make the game that you want to make, and it's for us to play or not play if we enjoy it.

    • Please consider reverting this change for a month to ameliorate the damage to affected players.
    • Please make a public statement regarding similar "bugs." (multiple mineral harvesters harvesters at the same time, harvesting just minerals in SK rooms to avoid invader spawns, ect.). We need to know if these are going away before more people implement them.
    • With power creeps on the horizon, there are going to be necessary re-balances that break people's code. As soon as you are aware that a feature is overpowered and needs to be re-balanced or removed, please make a forum post stating such. Nothing is worse for me as a player than having weeks of work rendered useless, and it will be important to mitigate that.
    • Please consider taking a less binary approach to preboosting. I do not see this as a game-breaking issue. There are advantages to having your creep preboosted, and there are disadvantages to laying out your base in such a way that it is possible. Just because it wasn't originally intended doesn't make it not awesome. I think it is cool, and it was a good coding challenge to implement my solution. If the preboosting feature/bug is just too unpalatable as-is, consider a fatigue penalty as mentioned above. That would give preboosting players no benefit from preboosting, but would prevent our bases from being broken.

    This is a very long-winded post. I tried not to say unnecessary things, but there was a lot to be said. I hope the tone has remained respectful, in spite of my current emotions.

    Sincerely, omnomwombat

    👍


  • I think a better solution for balancing pre-spawn boosting is a higher energy cost. Then your creeps don't block the spawn when they come out.


  • Dev Team

    Alright, it looks like this change is more breaking than we thought before. Sorry for that, we're always trying to announce potentially breaking changes in advance. This patch is now reverted. We'll include it into one of the PTR deployments for proper discussion and announcement.

    👍


  • @artch thank you, very much appreciated.



  • This post is deleted!


  • I also spent quite a bit of effort as I redesigned my base layouts and updated my layout template system, to allow spawn-boosting.

    👍


  • @flyasd1 A child exists too before it's born.



  • Would love pre-boosting as a feature!



  • I also really think this bug should be turned into a feature. Like many of the other people in this thread, I spent a lot of time designing a base layout and implementing lab code that would allow for creeps to be boosted while they are spawning. I think allowing in-spawn boosting significantly raises the "skill ceiling" of lab/boosting mechanics without making it any less accessible to newer players, and I would be sad if this feature got removed.



  • @duckymirror said in Boosting 'Bug' fix with No testing, No announcement, and working 30% of the time.:

    A child exists too before it's born.

    Yes, but to heal child you will give a medicine to mother, but not a child. This is a philosophical question and one can argue long about this.