3. PTR Changelog 2017-02-01

PTR Changelog 2017-02-01


  • This does indeed look great.

    I've also left you a comment at the commit regarding the choice of design, would be great if you could answer my question here or directly in GitHub.

    From a user's view it would also be great if we can get a variable for currently viewed rooms (VIEWED_ROOMS or Game.viewedRooms), so we only generate Visuals for rooms we're actively watching. Would this be possible to implement at all?

  • Dev Team

    PostCrafter, I copy-pasted your comment here if you don’t mind. We try to keep all PTR discussions here on the PTR forum.

    This looks great and we’re already actively discussing in slack on how we are going to use this addition. May I ask what made you decide to attach the functions (addVisual, getVisualSize and cleanVisual) to console instead of RoomVisual (the constructor, not the prototype)?

    It was done due to internal mechanics, since console object is shared between runner and runtime spaces, but RoomVisual is only visible to the runtime space.

    From a user’s view it would also be great if we can get a variable for currently viewed rooms (VIEWED_ROOMS or Game.viewedRooms), so we only generate Visuals for rooms we’re actively watching. Would this be possible to implement at all?

    I can’t see any viable way to implement this right now.

  • Culture

    Nice! it looks much simpler to use than my screeps-visual userscript, looking forward to it in the main server 😄


  • Thanks a lot for the fast response. I'll try and keep my future discussions in the forum.

    I arguably don't know enough about how the different processes interact with each other and which context objects they share yet.
    If it's possible I'd prefer the functions to be removed from console, so they can be implemented at a cleaner place (Game.visual(s) comes to my mind), before people start using that in their code.


  • @Artem Why the limit on 20 rooms?

  • Dev Team

    @Artem Why the limit on 20 rooms?

    Otherwise you could create a RoomVisual for every single room in the world, post hundreds of visuals to it and crash the server.

  • Culture

    >Otherwise you could create a RoomVisual for every single room in the world, post hundreds of visuals to it and crash the server.

     

    Wouldn't we get an out of memory before that? (created one of those once, sorry)

     

    Could we tie this to GCL? I'd love to have my home rooms visualized when I'm online without having to alter my memory:

    Memory.enabledVisuals = {};
    Memory.enabledVisuals["E5N7"] = true;
    Memory.enabledVisuals["W3N9"] = true;
    Memory.enabledVisuals["E3N8"] = true;

    This way we won't have to override the visuals methods to "mock" or "ignore" those visuals. Math.ceil(GCL * 1.5) seems like enough, with a base of 20.

  • Dev Team

    I actually got an idea of how to get rid of this limit completely. Will post an update tomorrow.


  • @Dissi Tying it to GCL sounds pretty reasonable. I say that as a GCL2 player.

     

    EDIT: @Artem but that's just as good. 🙂

     


  • To track which rooms your clients are looking at...

    Client side

    https://github.com/Esryok/screeps-browser-ext/blob/master/visible-room-tracker.user.js

    Server side

    https://github.com/Esryok/screeps-browser-ext/blob/master/agent-modules/VisibleRoomTracker.js


  • This is amazing! Thank you! Is there an estimate on when it will go live?