PTR Changelog 2016-09-29
-
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.
-
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.
-
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.
-
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
-
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
-
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.
-
Let's move this discussion to the follow-up thread.