Disable proc crash suppression in BYOND Discussion

Page: 1 2
ID:133077
 
Apr 24 2009, 2:47 pm
I think it would be quite useful to have a method of disabling proc crash suppression. Here's the problem:

* Host a game for 2 hours
* One null reference in a timed game loop (not a for loop) causes the 95-100 message limit to be reached very quickly
* BYOND starts suppressing messages 10 minutes into the game - BYOND Warning: further proc crash messages are being suppressed to prevent overload...
* Any OTHER bugs that occur generating an error will not display that error for the remainder of the 2 hours

Current solution:
* Fix the bug (if it's not a quick fix, this could take an indeterminable amount of time)
* Close Dream Daemon, disconnecting all clients
* Lose portions of game-state that are not saved, which is a considerable loss for most games
* Open Dream Daemon
* Re-host
* Wait another 5 minutes just to get everyone logged back in

I am currently doing very controlled beta tests for my new game sequel Survival, and the current solution is troublesome compared to the alternative - being able to log all crashes and then peruse them later to take care of bugs after the beta is closed for the night.


~Polatrite~
#1 Apr 24 2009, 3:04 pm
Even if you can't fix whatever is causing the bug to begin with; it should be super simple to just say "if(!whatever) return", or whatever you want it to do instead of crashing.
#2 Apr 24 2009, 3:14 pm
In response to Falacy (#1)
Falacy wrote:
Even if you can't fix whatever is causing the bug to begin with; it should be super simple to just say "if(!whatever) return", or whatever you want it to do instead of crashing.

You still have to full reboot Dream Daemon, world.Reboot() does not reset the proc crash message suppression (if the limit has been reached), only killing and restarting the Daemon process itself.

As far as I can tell, it's a limitation in Daemon and Seeker, not the code interpreter itself.


~Polatrite~
#3 Apr 24 2009, 4:14 pm
In response to Polatrite (#2)
Polatrite wrote:
As far as I can tell, it's a limitation in Daemon and Seeker, not the code interpreter itself.

RunTime Errors = you screwed something up. I was giving you a way to prevent them without actually needing to fix whatever was causing them.
#4 Apr 24 2009, 9:43 pm
In response to Falacy (#3)
Falacy wrote:
Polatrite wrote:
As far as I can tell, it's a limitation in Daemon and Seeker, not the code interpreter itself.

RunTime Errors = you screwed something up. I was giving you a way to prevent them without actually needing to fix whatever was causing them.

When you run Dream Daemon during a beta, even if you reboot in the middle of the beta using Dream Daemon's reboot option, or world.Reboot(), it does not reset the "proc crash suppression limit" rendering your method of "solving" the problem insoluble.

The goal is to be able to see all proc crash messages through the duration of an extended hosting without having to restart the process. It's not an unreasonable request.
#5 Apr 25 2009, 1:35 am
In response to Falacy (#3)
Falacy wrote:
Polatrite wrote:
As far as I can tell, it's a limitation in Daemon and Seeker, not the code interpreter itself.

RunTime Errors = you screwed something up. I was giving you a way to prevent them without actually needing to fix whatever was causing them.

Icon Ultima frequently runs into the error "bad icon" which only happens on icon uploads (since it only happens on verbs such as Edit Object or Change Icon at the upload stage) and is apparently some manner of client upload, caching, or resource deployment problem. There's nothing I can seem to do to prevent the error from happening, but six hours or less into any hosted session I've already received the "further proc crash messages are being suppressed to prevent overload" message and I don't get any log of errors I can actually fix (or that were actually caused by myself to boot).
#6 Apr 25 2009, 5:01 am
In response to Polatrite (#4)
Polatrite wrote:
It's not an unreasonable request.

Agreed. It is always a good idea to have as much information as possible about bugs, and having diagnostic information limited after a certain amount of testing would be a hinderance.

I will go one step further, however, and suggest that we need a lot more control over error handling. The following are my suggestions...

1) Something like what Polatrite just suggested, but more. Perhaps a world function (setErrorOutputLevel(level)?) that could set the server to 1 of 3 levels, where 1 is ignore errors, 2 is suppress extended error information (so it outputs just the error but not its info, as when you have had too many errors), and 3 is full error output and would be default.

2) It would be nice if we had a way to handle errors from inside the game too, like good programming languages do. Java has an awesome error system that could be modeled after, where all exceptions are objects, and different types of errors are sub-types of a base Exception type, and you can get whatever information you want out of the Exception, and you can even make your own custom ones. I actually started making a Byond library that could, as far as I could accomplish with a library anyway, mimic this system, though I decided its not worth it to implement as a library, as you lose so much and have to contend with runtime errors anyway for what you don't catch.

If Byond would handle errors as objects, and, if a function crashes, just have it return the error object, that would be awesome. Imagine the following:
mob/var/mob/target
mob/proc
    hurt(amount)
        hp -= amount
        if(hp < 0)
            del(src)
    attack()
        if(!target) return
        target.hurt(strength)
        target.retaliate()
obj/item/verb/use()
obj/item/weapon/use()
    set src in contents
    usr.attack()

Even though you were thoughtful enough to check and make sure target is not null up front, that should cause a "cannot access null.retaliate()" error, or something to that effect, when target dies. Now, what if we could do
obj/item/weapon/use()
    set src in contents
    var/error/e = usr.attack()
    if(e)
        onlineAdmins << "Oh noes, there's an error!\n[e]"

And since Byond is not strongly typed, it would work even if the function you are catching an error for already returns something, since it won't be returning its normal value if it crashes.
proc/myProc()
    var/mob/M = getRandomMob() // assuming getRandomMob() has some reason to cause an error
    if(istype(M, /error))
        ...


3) I still think that we should be able to read the value of world/log to find out where the output is going. This, at the very least, would allow us to create our own better error handling systems.

The suppression message poses an interesting question though: what is the supposed "overload" that it is trying to avoid? Perhaps it is a limitation in the way Byond handles the errors that would cause undefined behavior if the error stream received too much output? For example, perhaps, for whatever reason, errors are referencd internally and kept around? I think the likeliest explanation is more than the overload refers to simply flooding whatever text field the output is going to; in this case, I don't think it's a good idea to do it at all, as the only situation where it would be a good idea is when someone is playing single-player and getting the output directly in their game session when they are playing and not testing, but, in that case, it's the programmer's job to fix the issues, not Byond's job to butcher the error stream. A better "fix" would be to give Dream Seeker an option to hide error output.
#7 Apr 25 2009, 7:20 am
In response to Loduwijk (#6)
I second this notion. That isn't necessary, but would be nice; I think They™ sometimes decide not to implement such features however because they make the language more complex, but meh.
Also, (*plug*) I wonder if we could be given general control of RTEs' output; like, it might be possible to have an event hook that's called when a runtime error occurs with the error info as args. Then you could format it however you want, and direct it (or not) to whatever interface control, player, or file you want. And of course it would do the default error stuff if you call ..().
#8 Apr 25 2009, 1:54 pm
In response to Falacy (#3)
The point of an error message is that it tells you how you screwed up. Sometimes you overlook things; it's just fact. If this didn't happen, professional games would have no bugs or glitches.
#9 Apr 25 2009, 2:24 pm
In response to Jeff8500 (#8)
Jeff8500 wrote:
The point of an error message is that it tells you how you screwed up. Sometimes you overlook things; it's just fact. If this didn't happen, professional games would have no bugs or glitches.

Yea, and those professional games fix those bugs (the good ones do at least). They don't just add an option to let the error reports spam to infinity so they can ignore them. Though I'm not sure how that logic even works out o.O
#10 Apr 25 2009, 2:28 pm
In response to Falacy (#9)
The idea is more that he can ignore the ones he knows about, and look for new ones further down the list. Then he fixes them all in one go, and reboots, instead of rebooting after every fix or two.
#11 Apr 25 2009, 2:33 pm
In response to Stephen001 (#10)
Stephen001 wrote:
The idea is more that he can ignore the ones he knows about, and look for new ones further down the list. Then he fixes them all in one go, and reboots, instead of rebooting after every fix or two.

As he said
* One null reference in a timed game loop (not a for loop) causes the 95-100 message limit to be reached very quickly
Fixing that one bug, or at least preventing it from run timing should be easy enough. Hopefully he doesn't have multiple things that are causing enough run time errors to stop the reporting system...
#12 Apr 25 2009, 2:40 pm
In response to Falacy (#11)
Yeah, I kinda figured so too, seen it was discussed in Chatters a bit before the suggestion. But I guess the OP's suggestion is driven by not fixing the runtime as soon as it's picked up and rebooting. I guess if you did a 24 hour un-manned test session then you might hit the limit. It'd have to be a big or busy game to manage that though, I'd think.
#13 Apr 25 2009, 6:39 pm
In response to Stephen001 (#12)
Stephen001 wrote:
But I guess the OP's suggestion is driven by not fixing the runtime as soon as it's picked up and rebooting.

This is exactly what I am talking about. Log ALL bugs for a given session, fix them all later - and fix them all correctly. Not doing things on the fly can lead to a higher quality product: when you take your time to fix things the right way instead of hacking a fix together in short order.


~Polatrite~
#14 Apr 25 2009, 6:44 pm
In response to Polatrite (#13)
Polatrite wrote:
Not doing things on the fly can lead to a higher quality product: when you take your time to fix things the right way instead of hacking a fix together in short order.

It can also lead to a 10 gazillion gigabyte error log <.<
#15 Apr 25 2009, 6:50 pm
In response to Falacy (#14)
Falacy wrote:
Polatrite wrote:
Not doing things on the fly can lead to a higher quality product: when you take your time to fix things the right way instead of hacking a fix together in short order.

It can also lead to a 10 gazillion gigabyte error log <.<

I currently run additional games outside of BYOND. Huge logs are nothing remotely out of the ordinary, and with a firm grasp of regular expressions and a few handy C# utilities I've created, managing those logs is absolutely no problem.



These logs contain every single action from every players for the entire uptime of the game, except for movement. (which is easily determined by logging coordinates of every other action)

It really helps for statistical analysis of a game, and it's a completely normal concept for any large budget production. (e.g. logging monster kills to see popular and unpopular zones and make corrections)

Point: Just because huge log files aren't desirable for you doesn't mean that this functionality is undesirable, especially since it's an option, not expected behavior.


~Polatrite~
#16 Apr 25 2009, 7:04 pm
In response to Polatrite (#15)
Polatrite wrote:
http://www.polatrite.com/files/logfiles.JPG

These logs contain every single action from every players for the entire uptime of the game, except for movement. (which is easily determined by logging coordinates of every other action)

Either those logs have some super epic formatting, are lacking in details, or there's just no players on the game. Even a simple chat-log with something like [time][user][message] should be larger than that over a 24 hour period on any mildly populated game. Not to mention every action ever taken.

Point: Just because huge log files aren't desirable for you doesn't mean that this functionality is undesirable, especially since it's an option, not expected behavior.

Let me just say I'm not at all against them improving the way their run time error reporting systems works. I just think the change you're requesting for it is completely idiotic. Instead of having to look through 1000 spam messages to find the 10 varied ones, it would be much better if they created some sort of grouping system. Or even just caused repeat messages to stop reporting, while still allowing different ones to continue.
#17 Apr 25 2009, 7:17 pm
I second this. It would be nice to have these errors exported to a log file, and the DD log cleared, rather than DD just suppressing them.
#18 Apr 25 2009, 7:17 pm
In response to Falacy (#16)
Falacy wrote:
Either those logs have some super epic formatting, are lacking in details, or there's just no players on the game. Even a simple chat-log with something like [time][user][message] should be larger than that over a 24 hour period on any mildly populated game.

Highly off topic:

MOVE(22:59:35 - (991,1023,6) Yayo [0,36] - moved 1 spike sword (0,0,0)\n
from black backpack (991,1023,6) to Yayo (991,1023,6)
MOVE(22:59:35 - (1468,1137,9) Aether Storm [50,300] - moved 1 dead serpent spawn (-1,0,0)\n
from a tile (1469,1137,9) to a tile (1468,1137,9)
CCMD(22:59:36 - (1144,382,7) Drizzit Jr [10,223] - 1: !online
MOVE(22:59:37 - (920,598,10) Zeigfried [0,145] - moved 2 dragon ham (-1,-1,0)\n
from dead dragon lord (921,599,10) to backpack of holding (920,598,10)


6715 kb (that's 6.87 million characters) of logs is 87586 logged actions over 14 hours of runtime.

Assuming 9 bytes for time, 10 bytes for average user name, and 50 bytes for the average message, 2 bytes for spacing... divided into 6.87 million bytes, you're assuming that 96760 messages are transmitted in 24 hours, 4031 an hour, and 67 a minute. I challenge you to find a simple chat log on almost any BYOND game that fulfills your alleged benchmark for a game with "no players" - and this is a SMALL log compared to some of the 25+ meg logs.

I also challenge you to keep the topic ON topic from this point forward, and don't bother trying to degrade my ideas or projects further, subtle or not. If you have a point to make, make it.


Back on topic:

We've both agreed that the current system could use an improvement, and I've presented a quick and easy fix as a useful option. I look for the shortest route to implementation out of respect for the limited development time that the BYOND developers have available. I can make my own grouping system using a C# app, I don't need to be lazy and have BYOND staff implement it for me.


~Polatrite~

Edit: Threw in line breaks to keep the DM tagged stuff from expanding your window.
#19 Apr 25 2009, 7:43 pm
In response to Polatrite (#18)
Polatrite wrote:
I also challenge you to keep the topic ON topic from this point forward, and don't bother trying to degrade my ideas or projects further, subtle or not. If you have a point to make, make it.

Yes, I seem to have greatly overestimated the size of text files. And I believe I've already made my point! (improvements could help, but not necessarily the ones you're suggesting)

EDIT: Now I go to bed! *flee*
Page: 1 2