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.

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.

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

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.