3. PTR Changelog 2017-07-30

PTR Changelog 2017-07-30

  • Culture

    Here's a forum post from Dissi reference the documentation you claimed to have erased-

    http://screeps.com/forum/topic/1257/Add-MODE-PTR-to-the-modes-list-inside-a-room

    Note the date on that post- it's december 2015, which is seven months after you claim to have erased it from the documentation site. That means it was in fact on the main website documentation well after the early preview. Unfortunately you took the old documentation site down already, but I don't remember you ever removing the mode and you certainly did not announce it.

    Also, if you erased it from the documentation site before I started playing then how did I find it?

  • Culture

    Hell, it's still on the main docs site!

    http://docs.screeps.com/api/#Room.mode

  • Culture

    Indeed Room.mode still exists in the version of the documentation as of the time of this comment.
    It is incomplete, but it is there, therefore I have to back tedivm on the fact that removing a property like that without a grace period of deprecation can lead to a lot of code crashes.

  • Dev Team

    So how are you using it without knowing the possible values? Or, how did you learn what are the possible values? Obviously, experimenting with its behavior, right? It is what people call "undocumented feature" exactly. The undocumented part is the values, not the property itself. This property doesn't have any documented values, so you are supposed not to mess with it.

  • Culture

    > So how are you using it without knowing the possible values? Or, how did you learn what are the possible values? Obviously, experimenting with its behavior, right? It is what people call "undocumented feature" exactly.

    I did not have to experiment or look at at. It was literally documented on the old website. The only difference between the new and the old website here is that the constants are missing now, but they were on the old site. 

    Again, read the link from Dissi. He flat out mentions the MODE_ constants and recommends you add a new one (MODE_PTR). Why would he recommend adding a new one if the other ones weren't already documented?

    Also, this conversation is ridiculous. You made a mistake, which all humans tend to do- you thought that the documentation was updated in May 2015, but it turns out it was accidentally left in place. Instead of arguing with me about it just own up to the mistake and move on. There is no reason this should be as complicated or argumentative as you're making it.

  • Culture

    You also still have the constants defined on the "CONSTANTS" section of the website-

    http://docs.screeps.com/api/#Constants

  • Culture

    The post literally has comments from a month ago showing that people are using this feature.

    Literally one single month ago.

    http://support.screeps.com/hc/en-us/community/posts/205954075/comments/115001001945

  • Dev Team

    You still seem to misunderstand the point here. “Deprecated” is simply a wrong word here, since there is no process of deprecation of something that worked before and doesn’t work now. It never worked. It is just an obsolete remainder from Early Preview game release which is not in effect since 2015. You may have guessed on your own that it’s obsolete from things like MODE_ARENA and MODE_SURVIVAL, they are the reason why this property existed.

    I can’t remember whether they were present on the old documentation site or not, but I’m pretty sure that we simply copied all HTML content to the new documentation site, so it should have been copied as well if it were there.

    I still insist that if you rely on something that is not explicitly and fully documented, and do this without proper checks, then you should not blame us when your code breaks.

    However, we wouldn’t like to make anyone upset, so we’ve run a quick check for usage of this property in players’ scripts. It has shown that some players use MODE_ constants and removing them from the global scope will create an exception in their scripts, so I've added this commit. Literally all usage cases look like .mode == MODE_SIMULATION, it is not something that would break your colony. In case of .mode == MODE_WORLD, it will still remain a valid check, since it’s undefined == null now. There is no players doing === comparison.

    I believe we should be fine now.

  • Culture

    Game.map.getWorldSize() isn't currently working- it's returning an array with objects that seem to correspond to rooms.

  • Dev Team

    Fixed.

    By the way, if you’re looking for a replacement for Room.mode == MODE_SIMULATION, the correct check now is Game.shard.name == 'sim'.


  • I don't care about the change. 
    But I wanted to note, that the old documentation indeed contained mode values as well. 
    There is a cached version of that page here. Well, it's not loking the same anymore, I guess it's lacking some stylesheets... 

    Whatever. Keep up the good work 😉

  • Dev Team

    Fun fact! It might have been hidden somehow, since I can’t remember that we manually removed anything while moving to the new site, it was fully automated. Or it might be marked as obsolete in styles and thus the migration script didn’t process it.

    Anyway, the main reason why it must be removed now is that Game.shard is a more correct way to distinguish between sim/ptr/live. Room.mode is no longer needed and can be safely removed without breaking anyone’s live code.