Aug 10 2015, 6:35 pm
In response to MrStonedOne
|
|
PJB3005
 |
I think A.T.H.k. is more going at the fact that we should code to not trip the infinite loop detector.
|
MrStonedOne wrote:
But I see you still aren't getting the point, so i'll continue writing up examples of server crash exploits caused by this "feature" No I get the point, of being lazy. I don't want to argue anymore, I understand both sides have valid points. But NOOOOOOO, apparently this one kind of runtime has to turn fun situations into a DoS exploit. I get it but again, can be stopped with code, sure they won't get throw around like a rag doll like you wanted .. but you'll stop getting the crashes. | |
So what, adds spawns and action queues to everything, killing performance, because he thinks that asking to allow an annoying "feature" to be disablable is wanting byond to do the work for us?
Just crash the proc, and move on. Every other runtime does this, its one of byond's strengths, that every bug doesn't turn into a DoS exploit. By his logic, byond should just remove all passive runtimes, and crash the server on every null error. | |
The solution to the space lube is indeed merely putting in a check that prevents it from multi-uses. Simple game design.
Just because the project is so expansive doesn't really mean that they system should cater itself to it, what about other projects? When a workload is large like that it is best to break it down into smaller sections/categories and assign it to multiple groups of people so that each category gets the equivalent amount of work. It is the same as cutting a piece out of a pie, you don't eat the whole pie yourself in one sitting, do you?? ( I suppose some do, but that is besides the point! :P) | |
PJB3005 wrote:
I think A.T.H.k. is more going at the fact that we should code to not trip the infinite loop detector. Pretty much .. I'm all for having the ability to remove the limit or up it .. If you're doing it to bypass some poorly written code or using it to mask the fact something is crashing .. That's just ludacris .. | |
The solution to the space lube is indeed merely putting in a check that prevents it from multi-uses. Simple game design. But, we WANT that functionality. Thats its whole function, to create slip&slides. | |
MrStonedOne wrote:
The solution to the space lube is indeed merely putting in a check that prevents it from multi-uses. Simple game design. But do you see the functionality error? The reason it is crashing is because it doesn't know what to do if multiple are ran into. If you code that mechanism it won't crash, that is all we are saying. As it is, each time it gets triggered it is repeating itself and thus causing problems and crashing. If you want three subsequent space lubes to make the people go that much faster, you have to program them to do that (not just expect it to work and not crash ...when it crashes). | |
MrStonedOne wrote:
So what, adds spawns and action queues to everything, killing performance, because he thinks that asking to allow an annoying "feature" to be disablable is wanting byond to do the work for us? I think you need to take a step back.. Take into account that BYOND isn't just written for you SS13 programmers.. All your requests revolve around it, sure they may be good for your game .. but half the time they're very SS13 orientated. What you think is awesome and great may not be best for the software as a whole. | |
Large operations like these are more than common enough to not be "SS13 oriented".
You could even argue that SS13 is a stress test for BYOND (there's no denying SS13 is the biggest game on BYOND) | |
A.T.H.K wrote:
MrStonedOne wrote:So crashing after 3 caught infinite loops is best for the software as a whole, do you use the crash as an indicator that its time for a break or something? | |
A.T.H.K wrote:
MrStonedOne wrote:Wanting better error handling is not SS13-specific. It allows other games to gracefully handle crashes and gives everyone better stability. | |
Pomf123 wrote:
So crashing after 3 caught infinite loops is best for the software as a whole, do you use the crash as an indicator that its time for a break or something? I'm really sorry but that makes absolutely no sense. I never said that at all. | |
N3X15 wrote:
Wanting better error handling is not SS13-specific. It allows other games to gracefully handle crashes and gives everyone better stability. Sure, which is why I'm not ... arguing against it .. have you actually read anything I posted? I'm simply saying, using it to mask an issue is not the solution to your problem .. I clearly said I'm all for it.. In the end, I see it being abused by people that have no idea what they're doing .. They'll "up the limit" as soon as a crash happens without investigating it, again .. masking the issue. Face it half the games here are "coded" by fucking twelve year olds that grab the source from some website.. | |
We don't want it to mask an issue.
The issue here is that it's too trigger happy. | |
PJB3005 wrote:
We don't want it to mask an issue. Others will however.. That's my point .. people that have no idea will just up the limit to mask the issue. Look I'm sick of repeating myself.. I'm out. | |
 That gif sums up your argument fully. BYOND as a platform should not be slowed down by idiots. | |
This is gonna be the big issue, I'm sure.
Making the language work with new users, and allowing it to grow with projects. You have to make it user friendly, while allowing projects to advance byond that. Its a balance, but i don't see why removing functionality (remember, recursive functions is a well known mathematical and programming concept, and have their place) from advance projects is needed for that balance. Byond's design is a godsend for somebody wanting to start a project like this, but i think it is prudent to understand that projects grow, and ensuring byond can grow with them should be a goal as well. Because once a project gets to that point, where byond may no longer be the best tool for the job, it's too late, you're at 300k lines, and moving to another engine becomes impossible. You claim we want byond to do the work for us, but isn't that byond's main strength? That it does so much of the work for you? In this case its actually the opposite, we want a little bit of control of how much of the work byond does for us, and the power to tell it, "don't worry byond, we got this". Sadly world.loopchecks doesn't quite fit that bill. world.crashontoomanyerrors would, as would DreamDaemon.exe "tgstation.dmb" -nevercrash. | |