PTR Changelog 2016-09-29
Few notes on Landmarks-
- They should work just like flags as far as placement and removal goes- the closer the APIs are to each other the easier it will be for people to use them with existing code.
- Unlike flags they would require room visibility, since they are attached to the room object.
- They should *not* be included by default in the look* functions, since that would force them to get created each tick and the whole point is that they should allow us to only have to access them when needed.
Amadox last edited by
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.
Hernanduer Culture last edited by
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:
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.
Tanjera last edited by
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!
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
RoomVisuallayer, 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
Flaginstance 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
Roominstance 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?
Irrational last edited by
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.
SteeleR last edited by
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.