Changelog 2018-09-22
-
-
We've noticed a couple of oddities with tunnels. The last ptr update said the multiplier was changing from x100 to x150. And the blog post and docs also use x150. However, the actual deployment seems to use x100:
An even stranger one that thecreepz noticed and I recreated, if you build a tunnel on a wall which is on a swamp (which there doesn't seem to be any way to see, but if you try walls at random that are near a swamp you'll find one) then you get both x5 and x100:
Note I haven't yet actually had either built, these are just the constructions sites.
-
In the time its taken me to type the above, both seem to have been fixed ...
-
Hello, I am concerned about the potential blocking of renewing of boosted creeps. This change could break parts of my code in that I use boosted creeps in a room that are spawned in another room to cycle through RCLs quickly, and these creeps are renewed in the fast upgrading room. I don't think unboosting would be feasible with the upgrade boost due to the lengthy cooldown. Was this change to the gameplay considered or is this change partly to reduce the effectiveness of these 'prayer' rooms. Thanks.
-
@slowmotionghost We're considering another way to run unboosting (e.g.
StructureLab.unboostCreep(true)), that doesn't return any minerals and doesn't trigger the cooldown. If renewing doesn't remove boosts, it can be allowed to renew other players' creeps which opens many interesting possibilities.
-
@artch That would be great if we could choose to lose the minerals in certain use cases. Thanks for the fast response. Otherwise good work on getting all these changes out, looking forward to implementing some.
-
@artch ooh yes that would be interesting - probably more useful for alliances than lone wolves, but interesting nonetheless
-
The new Room.Terrain.get() function seems to be "missing" a constant for the return of a Plain. The function it is replacing had clear returns of each type of terrain.
In the documentation it says it is returning values 0-1-2 and that there are constants describing walls and swamps, but there is no constant for the return of a plain. This makes it easy to check if a terrain is a swamp, but to check if the terrain is a plain i have to check if the functions return a vale of 0. This makes me use "magic numbers" in my code which i prefer to aviod. I can of course create my own constant and compare this, but why then is it defined for the two other two return values and just not for the first value? Also, if this return is ever changed for whatever reason by the server, by creating my own constant i would not evaluate the return correctly. If i used the accompanying constants my code would not care if the raw number returned was changed.
As i understod, the used constants "TERRAIN_MASK_WALL" and "TERRAIN_MASK_SWAMP" is used for bit masking and since the value 0 is not checkable with a bit mask it has no constant. However the return of this function does not appear to have multiple possibilities, the return is always either 0-1-2, so no need for a bit mask?
It just feels a bit inconsistent to provide constants for 2 of the 3 return values. Maybe we could get a new set of constants that describes the terrain types returned?
-
On the room.getEventLog() call, I like it! Some of those events look really useful, and I mean in a room management way, not combat.
I have a question as to the EVENT_OBJECT_DESTROYED event. Is the Id it returns usable as an Id, or is it only good for comparing to other Ids you have cached to find the now dead one? That would be fine, it would be better than having to try "Game.getObjectById(Id);" on EVERY structure looking for it.
I also like the EVENT_BUILD event, as there is no way to determine when a new structure is born except when a builder is done building it, and that fails when 2 builders both shoot the last shot. (Neither can mathematically determine if it finished it, or that was the penultimate shot at it.)
-
Finally got around to testing unboosting and holy crap the cooldowns this puts on labs makes it almost not worth the effort.
Even T1 boosts can get you a 1000+ tick cooldown on a lab. T3? Forget about it.
- edit to remove the mention of it blocking boosting, I was mistaken.
-
@shibdib The cool-down doesn't effect boosting. I take advantage of that in my own unboosting.
Ultimately it's 'free' minerals if you can code around the limitations. In particular most lab setups have two labs that never act as a target for reactions that can be used as well.
