Aug 10 2015, 6:19 pm
In response to A.T.H.K
|
|
PJB3005
 |
Yet there is gonne be a game that has a KICKSTARTER on BYOND.
|
This is a lot of words over something that makes sense as a daemon cli option
| |
PJB3005 wrote:
Yet there is gonne be a game that has a KICKSTARTER on BYOND. And that's relevant how? | |
This is the problem. Let's look at what happens if we ignore problems in real life. There's a hole in your boat.
1. You ignore it. What you guys are working hard to do. You see the ships sinking but your still trying to hit that land and ignore it. 2. You get some workers to patch the hole. Just as you can patch the game. A.t.h.k. Is just looking out for you guys, he doesn't want you guys to have a sinking ship | |
No it isn't. Firstly simple is subjective. Secondly I could make the simplest game ever and run a kickstarted for it
| |
DanteVFenris wrote:
This is the problem. Let's look at what happens if we ignore problems in real life. There's a hole in your boat. If you took any look at MrStonedOne's examples, you'll realise we don't have a sinking ship. With your ship anology, the people on the ship think there's a leak due water that flings itself over the side of the ship. Then after 3 times of it happening they go insane and blow the ship to shreds. | |
PJB3005 wrote:
That's relevant to the argument of "BYOND should stay very simple" I'm not sure why you've turned all nasty towards me, I was only voicing my opinion .. If you read back I've agreed that it should be implemented .. It has pros and cons, mostly cons when you look at the majority of programmers around here that have no idea what they're doing again using it to mask issues. I'm not sure why it's so hard for you to understand any of that, you've come back with no argument against anything I've said except for a Gif .. Which was childish by the way. | |
PJB3005 wrote:
DanteVFenris wrote: Than their should be mechanism to make sure your people do not think there is a leak when there is not. A ship would have a microphone or some sort of device to prevent that | |
Ding, BYOND does, but the microphone is too sensitive and the crew still goes insane.
The fix here is to give the crew therapy so they don't trash the ship. AKA this feature request. | |
DanteVFenris wrote:
PJB3005 wrote: And thats what we are asking for from byond. | |
Everyone is agreeing with you.
Basically we are just chiming in that you could also tie up those loose ends in the functions so that they don't crash to begin with. Look at it from Byond devs side. Would you drop everything you are doing to immediately cater to one game out of the hundreds that are on byond? They are busy and if you can clean your code and fix the problem rather than make the developers drop everything they are working on to implement a new feature for you, that is ideal; if not they will try to implement the feature if it is just and due but that will take time. | |
Oops my bad. What should happen is your people shouldn't think that. As no real people would. That's what I meant. Not something to ignore it. Just fix it yourself. The easy way is so boring and causes no sense of pride
| |
A.T.H.K wrote:
PJB3005 wrote: Luckily for us, advanced can be simple. This is why I use BYOND. Vylocity still looks good to me though. I wish we could produce client side code on BYOND. | |
Wow, this thread exploded. Anyway here's my two cents:
First, although I doubt many games would need this feature, I do see a value in it. However, I think maybe it makes more sense to modify it so that a recursion limit reached in a try block won't increment the counter. There's really not much good reason that this shouldn't be treated like any other proc crash when a catch is available. Second, I do think the recursion issue can and should be worked around where it's known to come up. Simply put, there should be no reason to ever recurse that many times. In the event of chained actions, there are probably better ways to organize the chaining that would avoid that recursion. There are also two clear avoidance strategies: spawn(-1) if feasible, which should reset the stack, and using a counter in any routine that might be recursion-happy to detect when to bail out. So while I see enough value in a Band-Aid type of approach to help out with this problem, I also think it's very, very important for any game that could possibly run into it to plan for those scenarios and pursue methods that would avoid recursion overflow. | |
Ya, we should, and can fix the overflows, and we have no issue with them crashing the proc.
But I see no reason for this one runtime to trigger a DD crash, when no other runtimes do. Ya, the runtime should be fixed, no, that doesn't mean that runtimes should be shutting down DD. | |
Shutting down the world in the event of too many problems of that severity is a safety feature, though. It was put in intentionally (albeit not by me).
| |
MrStonedOne wrote:
Ya, we should, and can fix the overflows, and we have no issue with them crashing the proc. Think of it as the same as when your computer bluescreens. It is saving it from itself. | |
See, I get where you're coming from, but try to look at it from my point of view:
I'm a systems administrator, for a program where all errors are automatically printed to a log file, and prevented from crashing the server, Super nice, but it also means programmers aren't worried about every bug crashing the server, and this influences their programming habits. Only, one error, for some undocumented reason, doesn't. It crashes the server after 3 or 6 times. To me, anything that can crash the server is a DoS exploit, It's in my training. Like, what if certain php errors caused apache to shutdown, and this was undocumented? What if a redirect chain caused apache to shutdown? Errors triggering shutdowns is a system administrator's nightmare. Think of how it would be if certain record not found errors in a dns server shut the dns server down in certain cases, where users could use that to shutdown domain name resolution for entire isps. OH WAIT! That happened: http://www.securityweek.com/ critical-dos-flaw-bind-exploited-target-dns-servers And it killed Comcast's internet service in certain areas for half a day. If you wanted to make it so that errors were required to be caught to avoid a server crash, thats fine, but its too late for that. About 1,000 projects and 300,000 lines too late. We are stuck with the system we have, where programmers have been able to not have to worry about runtime errors crashing the server, and have made mountains of code that assumed that. It makes sense that in the case of this one bug, it should be brought into line with the rest of the runtime errors. For consistency if not for the plethora of other reasons listed in this thread and the bug report I made. Like, what harm could 4 stack overflows do that 3 couldn't, that is worst then shutting down the server, disconnecting all players, and causing all current round state to be lost? | |