And less than 20 minutes after I post this, it appears to be fixed. Thanks!
Posts made by edanaher
-
RE: Exceptions showing up as "[object Object]"
-
Exceptions showing up as "[object Object]"
I love the way the script now runs up until the exception, but there seems to be an unfortunate side effect: I'm now seeing a red
[object Object]
in the console and e-mails, rather than an exception and stack trace. Sounds like someone forgot to pretty-print the exception...
-
RE: Simcity?
While I don't disagree that it would be nice to have more rankings around fighting and strength, I know I'm focusing on just getting a solid economy going at the moment. Once I get to the point that I can just place a spawn and come back in a few days to a nicely-running room, I'll be much more interested in starting to figure out warfare.
Though FYI, I did have a neighbor send a single enemy into my room and destroy it a couple times before I built basic defense. I'm tempted to do something similar soon: just have a couple creeps wandering around the board randomly, attacking anything they see. That'll at least get people thinking a bit about defense (and possibly how to attack me back )
-
RE: Strangeness around being wiped out and respawning in same room
And for the record, I still find it a little strange the I can apparently kick an enemy creep out of the room by spawning there. Though I suppose if you couldn't, a malicious player could drop a creep in a bunch of nearby rooms until someone else killed them.
-
RE: Strangeness around being wiped out and respawning in same room
Hah, you're right; I remember checking that the walls didn't expire for 10k ticks or so, and didn't think through the fact that that's only 3 hours.
I'm not sure how I feel about that - getting three days for each respawn did seem a bit overpowered, but very convenient for experimenting and improving my build. Three hours, on the other hand, isn't a lot of time to do that.
Guess I'll throw up some basic defenses to at least avoid a single creep killing me.
-
Strangeness around being wiped out and respawning in same room
I'm still having fun optimizing my internal network, and haven't started messing with offense and defense.
Not shockingly, yesterday my base was destroyed (AFAICT, by a single enemy soldier; as I said, no defense yet). As I still have a couple bits hardcoded to that room, I was hoping to reuse it, but the enemy creep was still there. But I tried anyway, and succeeded! It looks like the enemy creep was teleported to the next room over. Convenient for me, but annoying to the other player if he/she was hoping to claim that room.
Moreover, I came back this morning to see that I was wiped out, and had e-mails letting me know that all my creeps were attacked (and while there is a source keeper in my room, most of my creeps should never (and have never that I've seen) go anywhere near it). I assumed that I'd get another three days of protection after respawning, but either that didn't happen or something went wrong with it.
I don't particularly mind, since I'm getting a chance to test my early build, but this seems like it might be the sort of thing the beta's supposed to find.
-
Disable/limit e-mail on error when active
The e-mails sent on errors are wonderful for debugging, but can be a bit much during active development. It would be nice to have (or document? A quick search didn't find anything) an option to turn off these e-mails.
Better yet, they already seem to be somewhat batched; perhaps if there is some form of interaction with the game world (uploading new code, changing memory, running a console command, etc.), that batch could be discarded. This would preserve the value of alerts when idle, but avoid spam during active development.
-
RE: Knee-jerk reaction to 2015-05-27 update
I just noticed that ramparts are built at 1k, and repairable up to millions. That actually seems pretty well balanced.
And I see that the creeps page is now updated to cost 100 per work unit. Thanks for fixing that!
-
Knee-jerk reaction to 2015-05-27 update
Gah! My controller only stores 300 energy! That breaks my strategy of using the spawn point as an energy store for transferring/insurance, so there's no safety margin if I lose all my miners. I guess I'll just spin off a full-carry creep to store a bit more. Also, that makes starting off annoying, since you can't build a 300-cost miner and a 300-cost carrier, so I need to tweak my start.
Also, the creeps documentation page still has work body parts costing 20, when they're 100; that confused me for a bit when I couldn't build a new high-work unit.
Links looks interesting, but I probably won't bother with them for a while since they're one more complication. I haven't even started on structures while I focus on optimizing mining and upgrading the controller, so those tweaks won't affect me, though they look a bit overpowered (millions of hitpoints on ramparts? They may have been underpowered before, but that seems to weight things pretty heavily for the defender.)
Overall, ignoring the "oh no I need to fix my scripts" annoyance, I feel like the change in extension system is probably for the best, though it's going to be irritating that the spawn can only hold 300 energy.
-
RE: This game has potential if all the irritations are fixed...
Thanks for the reply! I've been playing with the live game, along with a quick script to sync my local code using the API. The local development and better syntax errors from the live game are making my life much more pleasant.
Regarding dead creeps, I'll see if I can run into that again and get it consitently.
And yeah, I understand that the game is at an early stage; this was a combination rant and list of the things that most irritated me; I was hoping that you would fix them. And sure enough, I learned in another thread about /api/user/code (I saw grunt, but I don't want to deal with a whole new tool when I can use a couple of lines of Ruby to do the same thing), syntax errors working on the server, and use strict, which handle most of my complaints about development.
It sounds like you have solid plans to handle my other complaints around debugging; I think things are good enough to live with for now.
-
RE: Separating running/editting code
Eh... I'm happy enough with the API access; I can keep code in git locally for development. Then if I break something at a terrible moment, just "git stash; push-to-server.rb; git stash pop" to get a good version running.
Since pushing code seems to take effect within a tick or two, that works just fine.
-
RE: Syntax errors missing line information
sigh
I do pretty much all of my development in the simulation mode, since being able to pause while debugging is useful. But I guess it might be useful to keep a real game going as well for this reason...
-
RE: Upload code via API?
Huh... I thought I looked through pretty much the entire web site, but somohow missed those links. Thanks!
-
RE: Faster testing environment
Another thought - simple "rewind" and "step" functionality for simulations. If I could go back to the previous tick and rerun my code with fresh debug statements, that would at least solve the problem of reproducibility, if not finding bugs in the first place.
-
This game has potential if all the irritations are fixed...
I've just made a number of posts of bugs and feature requests, but here are my general thoughts:
I love the idea behind the game; it feels like a modern version of core war combined with a typical simplified Flash RTS. (Though I don't think this is quite "The world's first MMO strategy open world game for programmers" - schemaverse has you beat by at least three years, judging by the date on this blog post
The API is fairly well documented, though there are a number of irritating edge cases (how do you tell when a creep dies? Dead creeps seem to sometimes hang around in Game.creeps with zero hits remaining or undefined ticksToLive, but a newly-spawning creep also has undefined ticksToLive, so my solution is to treat a creep with one ticksToLive as dead, since it'll go away next tick). And the distinction between dinstance and range caught me a few times; attacking the "closest" enemy will attack the one with the shortest path, which might miss one close by but with a longer path. These aren't insurmountable issues, but the lack of a good development environment makes these bugs painful to track down.
And that leads to my major issue with the game - the development environment is impressive for a small online game, but miserable for any real work. I've posted separate bugs or wishlists for these, but the fact that the only way to "save" is to make the code live, and typos cause the entire system to grind to a halt is irritating. More seriously, testing against enemies seems to require either spending time (tens of minutes? I haven't actually tried) building up a custom map to test what you wan't, or waiting in the survival simulation for the right set of enemies to show up. And then when something goes wrong, pause the game, add some debugging statements, run a step, see what happened. And then suddenly there's an undefined reference! Okay, comment out the offending line (and anything depending on it) and add more debug statements to the area to figure out what's going on. But those don't trigger! Because the creep that caused the error just died, and so that bit of code isn't being hit at all anymore.
There are just too many ways things can go wrong in ways that are undetectable until the exact right trigger, and then there's no way to go back and re-run that exact situation and see what happened. This is getting more and more frustrating as I try to add more and more elaborate functionality.
And finally, the straw that will keep from playing (at least for a few days; I may be back): the editor sometimes losing code if you pop it out, start a new game, and keep editing in the old window. Losing ten minutes worth of work isn't the end of the world, but on top of all the frustrations above, I just can't bring myself to re-implement it.
I'll definitely be keeping an eye on screeps (and I have a few more ideas I'd like to implement), and might come back to play with the MMO side of it. But for now, I'll have to satisfy myself with my (current) third place on the May survival.
-
Faster testing environment
Right now, I'm trying to add features to get a better survival score. Unfortunately, testing these is a huge pain, since many of them depend on having a good number of enemies of varying types around to attack; my current approach is to start a simulation round on max speed, wait until round 1200-2000 or so, and then start paying attention to see what's happening, pause and tweak as appropriate.
This is aggravated by the dynamic nature of javascript; it's not unusual to suddenly start seeing errors due to mistyped variable names (or similar stupid issues that a type system would catch) in the console during a simulation (or survival game). At least in the simulation I can pause it and see what's going on; in a survival game, I just have to do my best to read the messages scrolling by. And half the time the bugs go away due to creeps dying, and there's no easy way to reproduce them.
I could probably set up a test environment in the custom mode simulation, but my guess is that that would be more effort than writing my solution so far (and, AFAICT, would have to be re-done manually for each run, though I may be mistaken).
One solution I see would be to allow skipping ahead in the survival simulation (e.g., just set the tick counter to 2000 so that the round 2000 attackers show up now.) I'd love to see something better, but anything would be better than the current situation.
-
Syntax errors missing line information
When I have a syntax error, the errors is along the lines of:
SyntaxError: Unexpected token ) at m:4:29618 at main:5:14 at m:4:29618 at Object.c.runCode:4:35220
I figured out that some of the lines give a hint as to the file; in this case, main:5 is a require statement, so the error is somewhere in that required file. But it would be nice to have more information, say, a line number within that file.
-
Separating running/editting code
Right now, if you have a syntax error in the "committed" code, everything just stops as all code breaks. This is reasonable for the current world where everything is short-term, but I'd hate to be editting a persistent world and lose a couple hundred ticks while I'm trying to find the typo. It would be nice to be able to automatically revert the running code to a previous known good state, while keeping the code in the editor the current debugging version.
-
Upload code via API?
The github integration is a nice touch, but I'm not willing to give that access to an app. And while I could edit code separately and paste it into the editor, that's a pretty terrible workflow since any minor typo would require re-copy/pasting a chunk of code (or editting it twice and risking getting out of sync).
Why not have a public REST API to modify modules? Something along the lines of "GET api.screeps.com/v1/modules/modulename" to get the source of a module, and "PUT api.screeps.com/v1/modules/modulename" to update it? This would make it much simpler to develop outside the browser.
-
Code windows from old games lose code
I've been doing development by editting in a popout window, letting me use the console on the main window. Unfortunately, sometimes (maybe always?) after starting a new game, the popup stays around, but any changes committed to it are lost.
This is incredibly irritating when I change a couple modules after restarting and forgetting to reopen the popup, and then the changes don't show up in the running game. So to save them, I have to manually copy/paste every file I might have touched into a spare buffer, then close the popup reopen it for the current game, and paste the code back in.