I think it's time to say good by
-
When they kill the runner itself, it restarts the node process itself, which can contain hundreds of user's globals, hence why its a hard reset. (Only one user should ever be running at once per node)
-
Considering that most people get one of these hard timeouts and then nothing else after it does seem like the issue isn't their code. Perhaps giving people one or two penalty free hard resets per 20k ticks would solve the problem- this way people who are constantly getting hard timeouts will still get 'punished' but for times when it's not the player causing the issues there is some leeway.
-
But the hard resets are a symptom not the "problem" the problem is I can't control my own CPU usage.
module.exports.loop = function () {
return true
}
May take 1 CPU or 100 CPU (and may cause a timeout) and there's nothing I can do about it.
-
And before we go down the path of "it's not that bad" YES IT IS!!!! That's my complaint. Sometimes things do exactly like they should and that code uses a tiny amount of CPU, but other times, for no reason that I have any control over it doesn't and it "uses" a ton of CPU.
-
Yeah, that's why I mentioned the deal with the broader issue. They should definitely look into the CPU fluctuations, but the current symptom should also be addressed because it could have rather catastrophic consequences, ie: losing 5 ticks in a battle could be devastating.
-
I think each function, api call, instruction, etc. should have a virtual cost in cpu time wich should be the same whenever the server is overloaded or not...
-
My guess is, that the current time measurement simply compares time before and after the script run. If this is the case, then any kind of server overload will also block the thread and cause CPU time to spike, even thought he thread was paused for most of the time. As long as you measure time like this, there is no solution for this issue, because server overloads can happen at any time.
Part of the problem is definitely the choice of language, as JS does come with very poor threading support, lacks basic script-language features, is inherently slow on its own and comes with quirks like sudden GC hickups. If other scripting languages would have been chosen, those issues probably wouldn't exist at all. I.E. Lua has an instruction counter mechanism, that lets you run N instructions then returns to the caller. Proper limiting of execution time would have been a piece of cake with Lua.
But since the devs seem to only know about JS the game will certainly not be rewritten in a different language in any foreseeable future. Which also means that at least some of the issues will stay as they are unfixable thanks to the choice of programming language. Which is in the end kind of a killer argument for me as well.
But at least I get a mail every morning that my bots squished some random noob that thought "what a lovely free area around this guy", which makes me smile.
-
@TwoThe I'm fairly certain the choice of JS as the language of the game was not influenced by how suitable the language is in terms of performance or reliability. The choice for JS was most likely influenced by practical considerations of the availability and accessibility of the language.
@coteyr What do alliances mean?
As far as I am aware, alliances/clans/communities are a natural occurrence of any MMO game. I also don't feel that the alliances in Screeps are particularly aggressive towards independent players. Most alliances I know off will leave independent players alone for the most part.
Regarding CPU fluctuations, it is a valid point. I would certainly appreciate an accurate CPU behavior and this area is certainly worth the investment by the devs IMHO. Perhaps in favor of the development of power creeps or other game functionality.
I've currently coded "around" it and I'm not particularly concerned, but this reality forces me to run my AI at reduced capacity to deal with the CPU fluctuations.
Regardless of the case, this game is still a fascinating experience for me both in the technical and community side.
-
@Atavus If practicability had any influence on the choice of language, then JS would not have been chosen for a server-side software. What other languages would have to offer would be significantly advanced over Node.js and also run a lot faster. That is why I assume that the dev(s) know mostly JS and no alternatives.
-
@TwoThe I think you misread my statement. The choice of using JS was likely NOT influenced by predictability, reliability or performance. It was most likely chosen due to its accessibility and availability.
I do not know the professional qualifications of Artem and his team, but if you are suggesting that their skills are lacking I strongly disagree.
There are plenty of programming games out there using any number of different languages. I've been grabbing and abandoning such games for 20 years now and I've never found anything remotely as exciting and complex as Screeps. Perhaps you have had better fortune than I and can point me to better alternatives.
For the moment I remain quite satisfied with Screeps, Artem and their efforts. My only wish is that community would be a bit more supportive.
-
The guys doing screeps are obvious javascript developers.... without javascript developers there would not be a decent web client
Of course there would be much faster choices for the backend .. but you also have to see where screeps is coming from. When you look for the original indigogo campain (which I backed btw
) you will see that it wasn't really overrun. If they would have chosen LUA for example I'm pretty sure it would have been much less people interested in screeps They developed a prototype running completly in the browser.. and from that they created the server.
I'm very interested in different runtimes for the usercode .. and it should be possible to implement if you look at the server architecture page.. ( lua runtime gets state from redis, executes code, puts intentions back to redis )
But also I'm enjoying typescript and I'm not sure if I could do all the stuff I have done for creeps in LUA
It should be possibe to replace parts of the backend chain with compiled modules... maybe the module that resolves all the intentions and does the room. Maybe something that takes load from the mongodb. (I'm not really a fan of mongodb)
But all that takes time .. they are looking for developers... I guess they have some stuff in the backlog.
But .. we don't have the insight what would be most important or most useful to optimize .. since we don't have any benchmarking data
-
@Atavus It's a minor gripe, but I just don't like alliances. I don't have an alternative. The largest thing I don't like about them is they create a "red v blue" situation. If I go to poke a bear, I first make sure it's smaller then me, then I poke. Alliances mean the bear you just poked suddenly gets 500 friends. That great for the pokie, but the only "counter" to that is to bring my 500 friends. Which leads to a EVE like red v blue situation. Specially with the timers and cool-downs and tick lengths.
It's been years sense I played EVE but all I see is a TCU and several POSes every time the "safe mode" kicks in. Alliances just aren't my thing, but, as I said, minor gripe, and totally on my end. What would be nice is an in game representation of an alliance. At least that way I could make sure I was poking a small lonely bear and not 500 unknown bears.
As to supportive, I try to be where I can, but IMHO the game play is just purely broken. Not in the teenager, "match making sucks how come this noob is on my team broken", but fundamentally flawed. It's not that you have to account for CPU that part of the game, it's that you CAN NOT account for CPU. For no reason at all that you the player can control, you not only use more CPU this tick but are also blocked for 5 ticks. That's a big deal in a fight. It's even a big deal in a game where the SCOREBOARD's margins come down to 0.00001% differences in resource collection.
Now again, it's not that I care, like a couple of days ago when the servers are down. That happens. Everyone sucks the same. But with the CPU issue it seems to be isolated to "nodes". Every once in a while your code will get stuck on a "bad" "node" and then no matter what you do, your screwed.
Having to "work around" the issue is not fun, mostly because the work around doesn't exist. You simply have to accept that though no fault of your own, your code just vomits this tick, and you get punished for it.
Currently there is no way to "win", there may be a lot of objectives to aim for, but you simply can not reach them. You have the score board and it's metrics, except when you get punished DAILY for something outside of your control and the top spots are all very close in terms of efficiency, your not going to be doing things there. Mostly, because the "punishment" is not handed out to everyone equally, it's "random".
There are PVP aspects, which you may or may not be able to win, but in a fight when your actually using 80-90% of your CPU your can be damn sure your going to get locked out. How will that effect the fight. Your opponent get's 5 free hits? Well if your HEAL tanking a tower shot there goes your expensive, possibly boosted creep.
Maybe you just want to strive for efficiency, except there again, looking at the "top players" a whacking or two with the ban hammer is all the difference that exists between the top 10.
So once again you have this, thing (CPU Usage) that is core to your game play (most of the game is actually managing CPU v.s. your goals) and you get no control over it. It would be like me saying Tedvm and ags131 enter into a race from Florida to London. But I will dish out the gas. You can pick out anything else you want, but you must use a car, boat, or plane, and I will give you the fuel. They ask how much fuel, I will give you 1 gallon of fuel every 30 mins. They start the race, but this I give ags131 1 gallon of gas and tedvm .8 gallons. Then for some unknown reason I give Tedvm 1 gammon of gas but tell ags131 he can have any for 2.5 hours. Later I give Tedvm .5 gallons and tell ags131 he gets no gas again for 2.5 hours. When asked why, I just shrug and say it's the way gas works, and hand them both an empty gas can, but I continue to dish out gas at seeming random amounts.
I hope that makes sense.
-
> What would be nice is an in game representation of an alliance. At least that way I could make sure I was poking a small lonely bear and not 500 unknown bears.
You should install the tampermonkey/greasemonkey extension. It adds alliance data to the in game map and the leaderboards.
https://github.com/LeagueOfAutomatedNations/loan-browser-ext
-
I keep getting hit with these every once in awhile, I can tell you it's extremely irritating.
There is no way in hell my code can cause this, as it can run fine for weeks, than in 1 day I get hit with 20 of these for no reason whatsoever.
My code is fine-tuned to do tasks with as small as creeps as possible. Due to this issue these creeps get killed off because they can't fire commands (Source keeper miners, invader defenders, power bank miners).
I find the lack of communication quite disturbing, as it's affecting the people who can't do anything about it. People with shitty code who cause large timeouts should be punished. Not the people playing the game as intended, and with proper codes without infinite loops.
@artem, please fix this issue. It's seriously taking the joy out of the game at the current rate these things are happening.
-
You'll be missed, you were always an insightful part of the discussion in the forum and on slack.
Agreed about the hard resets. It is getting to the point where I don't really want to work on my code. Every time I've sat down to work on code over the last few months it has been trying to get to the bottom of that issue.
-
What fish?
-
@starwar15432 really?
https://www.youtube.com/watch?v=N_dUmDBfp6k
What do they teach you in school these days?