PTR Changelog 2018-11-05: preboosting
-
@mrfaul While I agree that hardcoding structure instances is not a good practice, they will find a way to do it without names (by id, for example)
-
I think I said this before, possibly in slack, I don't use pre-boosting and can't see I ever really would (never say never). But when I heard about it I went, that's cool.
In my mind it doesn't confuse the API (more than it already is), its an action which is part of the creation process. I can already cancel it, set the direction it will come out, and change its memory in preparation for its birth, I don't see why I couldn't also boost it. I.e. there are already some inconsistencies.
As others have mentioned I don't think anyone has suggested any other actions, attack, heal, transfer etc that should be done to it, and I don't think its that hard to enumerate them, I've looked over the API and can see (along with my feelings):
- Creep object actions on itself: all: not allowed
- Creep effecting other creeps: attack, heal, transfer: not allowed
- Spawn: recycle and renew: not allowed
- Tower: attack, heal: not allowed
- Spawn.Spawning: all: allowed
- Lab: boost, unboost: only boost allowed (can see an argument for allowing unboost to be consistent, i.e. Lab and StructureSpawn.Spawning are the only things allowed to affect it before it pops out; and it might be useful to do before doing a cancel)
Can anyone else think/see of any other functions that can take a creep as a parameter which would need to be decided upon?
All that said, to reiterate my first point, I don't use the mechanic so if its removed I'm not going to worry, just seems unnecessary to remove what seems to be a cool mechanic with the only reason being to be clean when there are other inconsistencies which continually trip me up (why is a controller a structure but a source and mineral aren't, why does a container, storage and tombstone have a store, but a creep has carry and then resources, labs, nuker, source and mineral all have their own versions)
-
@mrfaul The discussion we wanted to open is not about whether to remove this hidden behavior or not, but whether this game mechanic is valuable enough to critical number of players so that we develop and introduce it as a proper game feature. We are not going to leave it as-is in either way.
-
Creep object actions on itself: all: not allowed
Creep effecting other creeps: attack, heal, transfer: not allowed
Spawn: recycle and renew: not allowed
Tower: attack, heal: not allowed
Spawn.Spawning: all: allowed
Lab: boost, unboost: only boost allowed (can see an argument for allowing unboost to be consistent, i.e. Lab and StructureSpawn.Spawning are the only things allowed to affect it before it pops out; and it might be useful to do before doing a cancel)
This is a nice visual representation of inconsistency. Not allowed, not allowed, not allowed, allowed, not allowed, not allowed... wait, what? It's definitely looks like someone overlooked a missing check somewhere. But now we decide that no, it's intended to miss that check, and it's a feature, not just a mistake. Simply due to the fact that someone managed to take advantage of that missing check.
(why is a controller a structure but a source and mineral aren't, why does a container, storage and tombstone have a store, but a creep has carry and then resources, labs, nuker, source and mineral all have their own versions)
While I admit these don't represent perfect design (and honestly today I'd design them in a different way, and probably will do in some Screeps API 2.0), they are not inconsistences though, they are different API pieces trying to represent different in-game situations.
-
Would it be possible to benchmark on the live server how many people use this feature?
There is only a handful of people really invested in the forum, a shout out in slack would also be nice.Because it is a really nice coding challenge for people who like hardcore optimization problems.
I'm really interested how the entire community thinks about that.
A poll would also be a good idea regardless of how we proceed in this matter.
-
-
Well I'll voice my two cents since everyone seems to want this feature. I think it doesn't make sense, and even if it was in the documentation, it is very easy to miss things in the documentation.
It doesn't fit with the other mechanics, and I think it's best to remove it.
-
I wish I'd know about this before I spent weeks redesigning my layout to put all the spawns next to the labs!
One thing I would like to point out is that MOVE boosts are fundamentally tied to the body of the creep (unless you're equally boosting MOVE and CARRY). For all other cases of boosting MOVE, the unboosted creep will be intolerably slow-moving. With preboosting removed, we have to make sure it can exit the spawn directly onto a square which is both adjacent to the labs for boosting and out of the way of other creeps.
Although in fairness, with the whole unboost-renew-boost system you actually need such an area anyway.
-
@systemparadox This is why we're adding
Creep.pullat the same time.
-
This is a nice visual representation of inconsistency. Not allowed, not allowed, not allowed, allowed, not allowed, not allowed... wait, what? It's definitely looks like someone overlooked a missing check somewhere. But now we decide that no, it's intended to miss that check, and it's a feature, not just a mistake. Simply due to the fact that someone managed to take advantage of that missing check.
But the first "allowed" is still going to be allowed (on the spawn), so its still going to be inconsistent. As I said I don't use the mechanic and I'm not likely to, but I don't agree with breaking a mechanic used by quite a few people to tidy up an API in a way that still won't be "clean", I've not seen a single person confused by and has what I see as bigger inconsistencies . It just seems like an unwanted change, but at the end of the day it's not my decision and won't affect me so I shouldn't care, I just do for some reason.
-
@qgazq can you quantify your "quite a few people?" I feel like the number of players using it can only be identified by the devs, and if "quite a few people" were using it, there would be a much larger community outrage than there was...
-
Well just based on this post and from slack, there must be 10 maybe have said they are to some degree. And there will be those that don't use the forums/slack. I'm not saying it is a huge number, but "if it ait broke don't fix it", or in this case, "if it ait broke don't break it".
-
@qgazq I think people with pre-boosting code will be more engaged with the game, and therefore more likely to be around in Slack or on these forums. So there's some selection bias in the population you used for your observations.
