Posts made by Xist

FWIW I've dealt with that by checking for error codes.

If you try to send from an inactive link, it tells you RCL not enough or whatever that error is.

If you try to send to an inactive link, it tells you invalid target.

As the cost of isActive() is significant, I never actually call it.  I just look at the error codes and mark them as internally inactive the first time I get an error trying to use one.  Worst case you have 1 error returned when you try to do something, and in any case you never waste extra CPU polling isActive.

There are well documented cases where the Screeps server gets overloaded or otherwise locked up, and it starts telling you that you are using too much CPU.

There are other well documented cases where again the Screeps server is overloaded, and it starts charging you 5 CPU for a move (or other API) command instead of 0.2 CPU.

There is nothing you can do about it.  It is a problem with the server.  All you can do is ask the devs to fix it.  

I also use Chrome, and I paste in truly massive JS snippets into the console to run adhoc reports.  Never had an issue with it.

I do notice that Screeps breaks miserably on Edge, so it's possible there are similar problems with Firefox.

@Crusher48 you may already know this, but you should not ever use look()

Basically look() calls lookFor() 8 different times, one for every possibly LOOK_* constant, and merges the results for you.  This is an insane waste of CPU since you likely only need a small subset of the results.

TL;DR don't use look().  Use lookFor() instead.

In this room https://screeps.com/a/#!/room/E73N48

It used to be owned by a player named sleukeleire and he had placed an extractor construction site on the H node.  It was not built, it was just a construction site.

I claimed the room and destroyed his extractor along with all the other buildings.

Then I unclaimed the room.

The player sleukeleire was able to RE-PLACE his extractor construction site on the mineral.

I am unable to place extractors anywhere unless I have claimed the room and have upgraded its controller.

It seems there is a bug that is allowing sleukeleire to continue to rebuild the extractor even though he no longer owns this room?

EDIT: I have since started reserving the room myself again, and his construction site remains.  There is no way for me to remove it without reclaiming it again which I cannot do until my GCL increases.

Looks like you're on the right track.  That entire structure has an X value too small and a Y value too big.  Maybe adding an offset to the Y instead of the X in one of the calcs?

I'm working on similar code myself.

I've found that using the RoomVisuals system is amazing for debugging code like this.

Without reading through your code looking for errors, and since you didn't say what kind of help you want except that apparently the code isn't doing what you think it should - my advice is to add some debug code to draw circles/squares/polygons/etc on the screen when your code detects collisions or when it thinks it has found a nice spot to put structures down.

I imagine once you can visualize its calculations you'll find your issues fairly easily.

Good luck!  

@Atavus I understand what you mean.

If tunnels were implemented, I'd see them sort of like links.  Not available until your room is a higher level, so you still have to deal with the complexity of random room designs.

However, just like links, tunnel implementation could save (in some cases considerable) CPU for mining and remote mining operations, once the user has reached a high enough RCL/GCL.

If done right it would add to the game complexity and help reduce CPU usage, rather than simplifying the game which seems to be your concern.

Interesting idea.  Some rooms have SO many terrain walls that it takes 100s of ticks to move just a few tiles away.  A tunneling system would definitely be interesting in those cases.

Great idea, I'd love to see this implemented.  As it stands I'm wondering if I should implement my own caching, which would use potentially a lot of CPU/RAM, as I'm using visuals to see the results of very intense calculations (automatic room layout, etc).  It is not feasible to run those every tick to keep the visuals on screen - if there was a client-side way to keep the visuals it would be really handy.

EDIT:  I am blind.  Please delete this post.  Thanks and sorry for the confusion.  

@Finndibaen I totally understand and agree that the playing field is level if everyone uses JavaScript.

I only meant to suggest that, since the cost of running the servers is almost purely based on how much CPU/RAM is used, and thus the game devs wish for us to make the most CPU efficient code possible, then allowing us to use a language which is significantly more CPU efficient than JavaScript would likely go a long way to reduce their expenses.

I'm sure this is no small amount of work for them as they are very heavily invested in JavaScript.  However it's something for them to consider if indeed they do want to save probably-significant money without the consequences of simplifying/reducing the game that we all enjoy playing.

Relatively new player chiming in here, but I have 25+ years programming experience.

I've found it to be really funny that ultimately this game boils down to trying to optimize JavaScript code for CPU usage.  JavaScript has to be one of the worst languages ever invented when it comes to CPU optimizations.  The entire benefit of using JavaScript is its asynchronous nature (which we the players are not really able to take advantage of without costing ourselves more CPU) and its amazing efficiency at performing I/O (which again, is useless to we the players).

TL;DR JavaScript is a horrible language for us to be using, if CPU optimization is the end goal of our code.

I'd love to be able to submit C++ code, pay for the compile costs via my bucket, and then see it run at 2x or 3x more CPU efficient than the JavaScript code will ever be capable of running.

Sure JavaScript is a fun language.  It's easy for people to learn.  It is not at all CPU efficient, and if the game really boils down to CPU efficiency being the highest priority, then ultimately JavaScript is the wrong language to be using.

WTB C++ compatibility!  

Several months later, now that I have plenty of CPU, polling the market every tick is indeed nothing to be concerned about.

When I wrote this comment I had a very very low GCL with maximum remote mining consuming 100% of available CPU - polling the market looking for deals all the time was not insignificant overhead that was preventing me from leveling up my GCL at maximum speed, which was (and still is) my primary concern.

FWIW I am fairly active in the subscription token market now.  Because of the market's poor implementation, it is easy to make a lot of credits by setting buy orders at very low prices.  Along comes a low GCL player who is forced to sell to me even though my pricing is not at all competitive, and voila!  I've made a small fortune.  Rinse and repeat.

Am I happy that it's so easy to make credits if I use the system like this?  Not really, but I do it anyway.  Does it show that the market is working?  No.  It only illustrates how broken the market really is when it comes to forcing new players to use buy orders rather than allowing them to create competitively priced sell orders.

FWIW I have noticed that the server often seems to have background processes that consume CPU. Since the method they use for measuring our CPU usage is to check how much real time it takes, it is highly succeptible to incorrect measurements.

As I use every bit of CPU available, I really notice when this happens, like you do.

My strategy has been to start disabling some less important part of the code when the bucket drops so that this situation isn't catastrophic. I think that's about all you can do.

I think this is mostly a documentation bug, and the feedback I got in the Slack channel suggests this is a general problem with all of the RoomPosition documentation, but here is the issue.

Example:

Creep is on a room boundary at W2N1 @ 0,25 and computes a path to move to W2N1 @ 1,25 (e.g. move 1 tile to the RIGHT)

On the next tick, the creep has been magically teleported to W1N1 @ 49,25 and when I call creep.pos.getDirectionTo(W2N1 @ 1,25) it returns the direction LEFT instead of the expected RIGHT.

Thus the creep moves LEFT to W1N1 @ 48,25 which is completely the wrong direction.

The documentation for RoomPosition does not say anything at all about it failing to work when the 2 positions are in different rooms, and every example I have seen regarding path finding completely ignores this problem with room boundaries.

At the very least I think a big "THIS FUNCTION FAILS TO WORK IN CROSS-ROOM SITUATIONS" notice should be added to RoomPosition documentation, especially to getDirectionTo which definitely does not work.

Such a notice would likely have saved me hours of debugging.  

Generally speaking the functioning of room boundaries is not discussed in any documentation and I further suggest an in depth review of it if you can get around to it.

Thanks!  

Sorry, the formatting was pretty messed up when I posted here.

I made a gist on github, and updated the OP.

https://gist.github.com/gamrxist/ae1c945fccdda5b32496d0939a0994b3

Multiple browsers with attached consoles:  `CURRENT_ROOM` in window A would be room A, in window B would be room B.  Should be very easy for the console to sniff the URL to see what the current page is but I suspect it's even easier than URL sniffing.

In a popout console, I'm not sure it would be able to deduce which room you meant, and so the console should probably throw an exception if you use the macro in that context.

Just a thought.  

Yes, I understand that.  

I'm just asking for the console to not be so simple, and instead of passing my command thru verbatim, do a little pre-processing on it.  Recognize that I want to refer to the current room, which the console knows and the server doesn't, and convert it before sending to the server.

It would be like a client-side macro or something.

I often use the world map when I need to change views to a room more than 2 rooms away from the one I was viewing before.

When I enter world map mode, the Console stops getting messages.

Even if I'm only on the world map for a few seconds while clicking on the next room, I can miss messages that I'd really like to see.

Request: Keep the console active even when looking at the world map.  Even if it isn't displaying them for me, listen for them and display them when the console appears again in the new room.

The console is already keeping the history that existed before, it is just failing to receive new messages that come in while the world map is active.

It has been pointed out to me that I can pop the console out, but that is cumbersome and I think a much more elegant solution would be for the console itself to continue listening for messages as long as I have the client open, whether or not I'm looking at the world map.

Thanks