3. PTR Changelog 2016-11-25

PTR Changelog 2016-11-25

  • Dev Team

    This post describes changes on the Public Test Realm. The estimated launch date is November 27. See all commits in the ptr branch at our GitHub repositories: engine, common.

    Introduced controller signing mechanics. It allows to sign any (owned, unowned or hostile) room with a random text message visible to all players (up to 100 characters). This message will appear in the room UI and in the world map:

       

    Tell us what do you think about these upcoming changes in the comments below!

  • Culture

    Amazing change, I'm going to love it!

    It would be cool of we could also see the tick number in addition to the date. I'd love to avoid dates in this game altogether and just base everything of ticks. 

    Does this change also include the PR's from the github repository (ramparts/labs)? If so, is it preferred to make PR's to PTR in stead of the master branch? This way you'll have to do less work.

     

  • Dev Team

    It would be cool of we could also see the tick number in addition to the date. I’d love to avoid dates in this game altogether and just base everything of ticks.

    There is no tick property, since the timeframe here is intended to be days and weeks, not minutes and hours. Using the tick number is not very reasonable for an event that happened a week ago.

    Does this change also include the PR’s from the github repository (ramparts/labs)? If so, is it preferred to make PR’s to PTR in stead of the master branch? This way you’ll have to do less work.

    Yes, the PRs have been merged to the ptr branch, as you can see here. You can send your PRs to whatever branch you wish, we always merge them manually anyway, since some local testing is always needed.

  • Culture

    > 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.

     

  • Dev Team

    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.

  • Culture

    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".

  • Culture

    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).

  • Dev Team

    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.date property 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 as new Date() - controller.sign.date > 3*24*60*60*1000.

  • Culture

    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.

  • Culture

    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.

  • Dev Team

    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.

  • Culture

    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.

  • Dev Team

    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.

  • Dev Team

    Now StructureController.sign has both datetime and time properties. Also, changed the launch date to November 27.

  • Culture

    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.