3. PTR Changelog 2016-09-29

PTR Changelog 2016-09-29


  • On the bottom of page 1 of this thread, dissi suggested something I wanna repeat so it doesn't get lost:

     

    I think if we can emit events for the game to display:

    Game.rooms['someRoom'].displayIcon(SomeRoomPosition, COLOR_BLUE, COLOR_RED, "path.to.memory") // Maybe public/private? vision required!

    A lot of people would be happy. Of course you can still choose to use the flags, but at a cost.

     

    I was wondering for quite some time if this would be a possibility: adding methods that let us influence the game rendering, like drawing an icon at a certain position, a line between 2 positions, etc - just to visualize what our scripts are doing, for debug purposes or whatever. so far I've been using flags for that, but that never felt quite right. i don't need actual persistent objects there, i just want some visuals.

  • Culture

    I just want to point out how much difference there is between the reaction from players now versus when this far more drastic change happened:

    http://support.screeps.com/hc/en-us/articles/205193752-Important-change-CPU-cost-of-API-methods

     

    It seems like the increased interaction is a good thing, coming up with more ideas. Hopefully there will be many more in the future, even on not such intense changes.


  • Artem, seriously, a great big thank you for maintaining the game. I know you need to push updates and security fixes and patches for balance and sometimes it either breaks our code or breaks our style of gameplay... and it makes some of us unhappy... but I can see that you have the future of the game's security, balance, and development goals at the forefront of your mind. Even if I don't like some of the changes as they roll out now, I look forward to playing this game from now into its future.

    And thank you for noticing some peoples' utilization of flags as free memory (kilobytes per flag? wtf?) and making changes so that we don't collectively pay for those individuals' intelligent but generally taxing shortcut around memory utilization.

    And thanks to the community for helping to come up with solutions for these issues when you feel like Artem is too heavy-handed on the updates. A shout-out to tedivm for not rage quitting and even putting some good solutions out there (landmarks? I can dig it). I say thank you because I don't have any solutions to the issues of flag usage, since I don't use any flags, therefore I'll kindly bow out of this conversation!

  • Dev Team

    I was wondering for quite some time if this would be a possibility: adding methods that let us influence the game rendering, like drawing an icon at a certain position, a line between 2 positions, etc - just to visualize what our scripts are doing, for debug purposes or whatever. so far I’ve been using flags for that, but that never felt quite right. i don’t need actual persistent objects there, i just want some visuals.

    It is a whole other take on this problem. We actually debated a thing like this before, some RoomVisual layer, where you can draw lines, rectangles, icons using the SVG-based API like that:

    Game.rooms.W1N1.visual.drawLine(from, to, 'red');

    But it is just about UI representation, it will only be displayed in the game client as a separate visual layer on top of your room, your script won’t have access to this info, so it’s useless in terms of room positions markup.

  • Dev Team

    Since the new Flag() part is the problem, using a memoized getter to lazy initiate the flags could help with the CPU issue. Such as below:

    Another issue with this approach - you’re creating a separate getter function closure for each flag, so it is about creating thousands of closures, and they are also slow in V8. Our quick test shows that this approach is even slower than creating the Flag instance right away.

  • Culture

    The main reason I use flags myself is to have a point in another room, which doesn't require vision and can be gotten by a method in game using some form of ID:

     

     

    If the landmarks wont be build-able, or "visible" when not being in a room I'd have to do a lot more refactoring and would like to know this beforehand.

     

    Is the intention to remove flags completely from the game? Or just have a hard limit on 10k flags max? 

     

    > Game.rooms.W1N1.visual.drawLine(from, to, 'red');

     

    This would be good if it were private, so you can visualize stuff from/to could just be RoomPositions, and the data should only be there next tick. It doesn't solve the script access in non-visioned rooms.

     

     

     

  • Dev Team

    Is the intention to remove flags completely from the game?

    No, there is no such intention. Flags are a great tool, they just need to get revisited a bit.

    This would be good if it were private, so you can visualize stuff from/to could just be RoomPositions, and the data should only be there next tick.

    Of course, they are private, like flags.

    It doesn’t solve the script access in non-visioned rooms.

    Actually, we might be able to do something with this. It might be feasible to allow to create a Room instance explicitly and call some methods on it even without vision:

    var room = new Room('W1N1');
room.createFlag(10, 20, 'Flag1'); // OK
room.visual.drawLine(from, to, red); // OK
room.find(FIND_CREEPS); // Error - no vision
  • Culture

    Is it possible to create an object buffer of sorts to store "pre-made" flag objects in? And later set the data using setters?

    This could relieve object allocation pressure. Something like a circular buffer could do the trick.

    When dealing with massive amounts of small-short-lived objects it's best to keep older ones around and re-purpose them somehow.

    Does such a system function in the engine?


  • Overall, this seems like a good change.  Anything that prevents abuse at the expense of other players is good. 

    What about creep names?  Seems like we should limit creeps to 50 characters also, else someone will just create a bunch of creeps with 50kb in the name, and just put them in a corner of their room.


  • I have another suggestion (or wondering in general) - at the moment each structure has an isActive property - if the people are so using the flags to mark locations for future buildings - just remove the limit of placing the buildings early on. If they need it to be rebuild when destroyed - that's what the Memory is for. 

    10k flags is a lot lot lot.. a limit like 1000 in total seems appropriate so that they are not used as a memory alternative even for saving locations

  • Culture

    Flag names should be at least a few characters longer than creep names, as many people use the CREEPNAME_ACTION format to order their creeps around on an individual level.

  • Dev Team

    Let's move this discussion to the follow-up thread.