PTR Changelog 2016-11-25
-
> There is no tick property
I'd love to have this though, this way you can check things by tick:
if not changed for 1500 ticks do stuff
compared to
if (date now - average of 1500 ticks time) > sign.date
It's also useful for the history view.
-
Why would you need to sign something once per 1500 ticks? There is no real game mechanic related to it, it's only a visual property. You better sign it once per 2-3 days rather than once per 1500 ticks.
-
It's just the concept of days or real time that is weird to screeps. I'd like to think in generations (1500 ticks). "After 10 generations re-sign controller".
-
Well, you say that the date is going to be used to figure out whether a room should be used for a novice zone. So it does make sense for us to track how long it's been since we've updated the message in order to make sure it stays "current". I agree with Dissi, from an in game perspective "time" shouldn't exist other than ticks, so I think having the tick time added in to this would be a good thing (it can be every 40k ticks rather than every 1500 as dissi said, but it's still much easier to track ticks than time).
-
Well, you say that the date is going to be used to figure out whether a room should be used for a novice zone. So it does make sense for us to track how long it’s been since we’ve updated the message in order to make sure it stays “current”.
Sure, it is why the
controller.sign.dateproperty exists.I agree with Dissi, from an in game perspective “time” shouldn’t exist other than ticks, so I think having the tick time added in to this would be a good thing (it can be every 40k ticks rather than every 1500 as dissi said, but it’s still much easier to track ticks than time).
But we’re going to measure this in days, not in ticks. For example, 3 days without a renewed sign means the room is “uncontested”. You would need to convert ticks to days anyways, but with the
dateproperty you can simply check it asnew Date() - controller.sign.date > 3*24*60*60*1000.
-
We could have both, this way you can use whatever you want.
The novice area check could also be written as
days = (Game.time - sign.tick) *3 / 3600 / 24
Or even say, after 300k ticks of signing it's uncontested:
Game.time - sign.tick > 300000
It's a lot easier on the CPU as well.
-
Maybe it should be measured in ticks instead of days though, as ticks are the "time" of the screeps universe. As far as I know there aren't any other mechanics that work using Time instead of ticks, and if they are they aren't really exposed to the players.
As another point, what happens if you have to revert a backup or turn the server off for a day? In that case all of the player scripts would have "lost" time for updating their messages, but if this mechanic was based on ticks then any lost time would automatically be taken into consideration when the next tick starts.
-
Ticks are hard to measure, display and understand when you are a human and events happen on days scale. This is why all Novice Area periods are in days. It is much easier to say “this novice area will end on the next Monday” than force players to bring their calculators and evaluate it on their own.
It’s also useful for the history view.
Good point, it can be useful to see the exact moment when the sign was set. Yeah, I think we can do both.
-
Was not this feature implemented as a part to avoid unwanted novice areas? http://screeps.com/forum/topic/446/Interesting-novice-area
If it's still that I think the the documentation should say something about how often you need to resign it to avoid novice area. I know from experience that a novice area can pop up in just in few hours from a lost room (https://screeps.com/a/#!/room/W25S23) so it would be useful to know if I need to resign it every hour or every day.
-
If it’s still that I think the the documentation should say something about how often you need to resign it to avoid novice area.
Every day will be safe. I think even 2-3 days is a good estimate. We’ll add this to the documentation when this feature goes live.
I know from experience that a novice area can pop up in just in few hours from a lost room
If it really was the case, it’s a mistake on our end then. Usually it’s 4-5 days timeout.
-
Now
StructureController.signhas bothdatetimeandtimeproperties. Also, changed the launch date to November 27.
-
Awesome for adding it artch! So quickly as well!
-
Has the feature to use this mechanic for preventing novice areas from being designated been implemented yet? There's still no word of it in the documentation, and I'm wondering if I should still be reserving rooms to prevent novice areas, or if signing the controller ever 2-3 days will suffice.
-
@kshepard the novice areas are not an automatic feature. The devs are responsible for approving and generating each of them.
The reservations are 100% full proof to block reassignment. However, I've been relying on the new sign controller functionality for the past month and it seems to work just as well.
