ID:1835181
 
Not a bug
BYOND Version:507.1283
Operating System:Windows 10 Pro Technical Preview - Build 10049
Web Browser:
Applies to:Dream Daemon
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:Dream Daemon shut itself down.

Numbered Steps to Reproduce Problem:1.Host a buggy game???
2.Wait for Dream Daemon to shut itself down.

Code Snippet (if applicable) to Reproduce Problem:
Not Applicable...any code that generates a runtime error will work fine.


Expected Results:Dream Daemon not to shut down my server.

Actual Results:Dream Daemon shuts itself down.

Does the problem occur:
Every time? Or how often?Every Time
In other games?Not Applicable
In other user accounts?Yes
On other computers?Yes

When does the problem NOT occur?When you have a project without(any or a lot of) runtime errors?

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
1282 and below never did this to me even after hosting for 2 days straight, 1283 did this to me in under 2hrs

Workarounds:Unknown

The message I got was ***Shutting down after encountering too many critical errors

I don't know if it was caused by buggy code or not, but I get the message,

Warning: further proc crash messages are being suppressed to prevent overload...

I do get a lot of runtime errors in the code, this is Rise of Heroes, and it's simply buggy the way it was coded, but I can't be bothered to fix it in a day just so that the server will stay up.

Dream Daemon should never stop hosting the game, even if there's a billion runtime errors, it's just bad practice. Of course it's not good to have all the runtime errors, but it should do as it does now showing errors and suppressing them when it gets to be too much while also continuing to host indefinitely.

Unless this was caused by another issue I'm unaware of, in which case I am on it by doing further testing.

***If it turns out not to be re-producible right away, please give me some time(a few days) so I can figure out some exact steps to re-production and further ensure the cause is what I think it's or figure out the real cause of the issue.

Might want to post the log file..
In response to A.T.H.K
I don't know if I have to create one or what...I don't have anything setup to log on my end though, and if there's a logfile created somewhere, I need to know where it's at because I don't know this since I haven't been using BYOND too much recently.

If the logfile is identical to what I see output in dream daemon then, it has lots of errors that are for the game only, and don't really mean much for anyone but me.

The only 2 messages that were output not by errors from my game itself were the 2 from the bug report, which is to suppress errors and when it shutdown.

***I also don't see any changes in 1283 which would account for this problem, it doesn't make any sense. But 1282 worked fine hosting for days, and I've had my server shutdown 3 times with RoH in 1283.

Creating a test project just to create runtime errors and shutdown has also not seemed to do anything. The server is staying up like it should, so maybe the cause isn't runtimes.
Honestly, it doesn't seem like you know what you're doing. You're also using a source that you don't seem to have any idea about.

I don't think this bug report can be taken seriously when you've admitted that the source has issues..
I know about the source fully but I didn't make the errors, I am fixing them slowly but I can't be expected to fix every runtime error in 24hrs, I work full time as well and don't have the time to devote to fixing it so quickly.

As for the logs, I know you can create logs of the output yourself, but that will only log what's shown in dreamdaemon, all that text full of my game-specific errors...nothing about this problem here.

I don't usually ever have to create bug reports, make or send logs to others, or anything of that nature, so I'm not up to date on how to do everything or where all the functions are in all the BYOND programs.

You can't expect every user just because they play BYOND games, or even host them to know everything about BYOND and the whole software suite.

EDIT: As for the bug report being looked over simply because the source has issues, well that's what the bug report is all about, if the source was bug free with no runtime errors it likely wouldn't have shut itself down, unless the error in question had nothing to do with runtime errors and shutdown for another unknown reason.

***In any case whether it's runtime errors or not, DreamDaemon should not shut the server off under any circumstances, no matter how many runtime errors there are, and if it's another bug, DreamDaemon should recover from any other errors or not have them to begin with and continue hosting.

There are no circumstances where I want DreamDaemon to simply stop hosting, it should keep going until it crashes or I take it down myself.
In response to Superbike32
Superbike32 wrote:
I know about the source fully but I didn't make the errors, I am fixing them slowly but I can't be expected to fix every runtime error in 24hrs, I work full time as well and don't have the time to devote to fixing it so quickly.

If you did, you wouldn't be hosting a poorly programmed game.

You can't expect every user just because they play BYOND games, or even host them to know everything about BYOND and the whole software suite.

No, thats up to the developers, in this case, yourself.

***In any case whether it's runtime errors or not, DreamDaemon should not shut the server off under any circumstances, no matter how many runtime errors there are, and if it's another bug, DreamDaemon should recover from any other errors or not have them to begin with and continue hosting.

There are no circumstances where I want DreamDaemon to simply stop hosting, it should keep going until it crashes or I take it down myself.

"until it crashes" this is what's more than likely happening, BYOND won't close due to runtime errors.

I am not going to respond to any more of your posts should you choose to post again, I don't want this to just be an argument between the two of us.

Developers can be anyone really, it's easy to code and in BYOND's case is even free, so new and old developers alike no matter who they are in your way of thinking should know every detail about everything in BYOND, which just isn't the case.

If that were the case we should remove the developer help forums, every developer knows every function and knows how to do everything even if they just started developing last week.

As for hosting a poorly programmed game, none of the runtime errors prevent proper gameplay. I know how to fix these errors and why they occur but just haven't yet gotten around to re-doing some of the systems that cause the problem to fix it.

It's either host it or make everyone wait a few months while I re-do a lot of the systems to prevent the runtime errors that are happening, so I am hosting it so that they don't have to wait to play an otherwise fully functional game.

***And dreamdaemon stayed open in this case and displayed that message, if it were an out-right crash windows would pop up an say dreamdaemon.exe has stopped responding.

This is the type of crash I'm referring to, in this case it's more like a "soft crash" in which the server shuts off and dreamdaemon continues to run.

The message I got was output in DreamDaemon and not to any logfile, and after the "soft crash" as I'm calling it now, I was able to click "start" and continue hosting again right away.

By the message I got it makes sense that it simply stopped hosting, since it said ***Shutting down after encountering too many critical errors
Of course, you know best I'm very sorry for mentioning anything at all.
This is intentional behavior. Funnily enough I was going over that code just today when I was looking into error handling stuff.

The critical error thing comes up only when you've reached the maximum recursion level in a proc, basically blowing the stack out. Which is to say, something is very very wrong in your code. When those kinds of errors happen the odds of the server remaining stable are low anyway.

You really need to fix the runtime errors you see, because even the small ones are still obscuring the big ones like this. Runtime errors aren't that hard to fix: You identify what it's telling you is wrong and where (turning on debug mode is important), and deal with them. Maybe it's something like a var being null so you get "Cannot read null.myvar"--in which case you look at the line where that happened and see what's in front of myvar, and figure out how it got to be null. Often these things stem from the lack of basic sanity checks.

Even if you only get to a handful of runtime errors at a time, clearing them up makes it possible to clear up others.
Lummox JR resolved issue (Not a bug)