Did .400/GDS INVENT the freakin' RTE???

[Ben E Lou]

How many different text sims have I played? How many other bits of indie software (some buggy) have I used? I have no idea. I do know, though, that I've never seen the "Run Time Error" other than in a .400 or GDS product. Do they use a different programming language than the rest of the planet, or what? I'm not trying to be critical, but I'm genuinely curious about this.

Oh, and by the way, TCB 1.3 gives RTE13 two out of three seasons for me when trying to view assocation awards.

[Easy Mac]

we have a tcb thread

[Ben E Lou]

This isn't about TCB. It's about TCB, BBCF, TPF and TDCB and what causes that type of error to be seemingly unique to those games.

[Easy Mac]

with exterior prettiness comes interior problems... you've obviously never dated an insane hot girl

[Joe]

yes they did

[JonInMiddleGA]

I've seen RTE's in a wide variety of programs from a wide variety of developers.
Obviously, YMMV

[RPI-Fan]

I used to get it in FBCB a long time ago (on the training screen), but I know HR fixed that with a patch way back when.

FBCB was coded in Visual Basic, I don't know about GDS.

[Gary Gorski]

Skydog if you want to zip up your league file and folder and email me I'll be happy to try and find the source of this error. The awards error has been a tough one to figure out because when I find one source of it another file seems to generate it for a different reason and many files are fine. One thing that seems to prevent the crash most of the time is to save before the awards - its an extra step to take right now (and if it still crashes at least you didnt lose whatever you did to that point). Again though, if I can see your file and replicate the error on my machine I'll be happy to get a patch out for it ASAP

[Ben E Lou]

Originally Posted by Gary Gorski

Skydog if you want to zip up your league file and folder and email me I'll be happy to try and find the source of this error. The awards error has been a tough one to figure out because when I find one source of it another file seems to generate it for a different reason and many files are fine. One thing that seems to prevent the crash most of the time is to save before the awards - its an extra step to take right now (and if it still crashes at least you didnt lose whatever you did to that point). Again though, if I can see your file and replicate the error on my machine I'll be happy to get a patch out for it ASAP

I save it before awards every time, based on my 1.2 experience. It crashed two of the three seasons even after saving it. On the reload after the two crashes, though, it was fine. I've moved on to the next season now, so I don't have a savegame at that point. I'll save it when I get there in my next season.

But back to the point, what the heck IS an RTE?

[Bee]

I've seen run time errors in other games on occasion, but nothing to the extent of the group of games SD mentioned.

Edit: So they may not have invented it, but they did perfect it.

[CraigSca]

An RTE is something that's not going to be found when the code is compiled. It's an error that occurs only after running the program. For instance, if you had a division by zero - that's an error, but not necessarily a problem the compiler would find (it's up to the developer to make sure whether the data in their application is valid or not).

[CraigSca]

dola

using my above example:

a = b / c

A compiler will compile that fine and find no errors. However, until the program is run, the compiler will have no idea whether "c" is a valid number or zero. In this case, if "c" is zero, a "RTE" will be created.

[Ben E Lou]

Originally Posted by CraigSca

An RTE is something that's not going to be found when the code is compiled. It's an error that occurs only after running the program. For instance, if you had a division by zero - that's an error, but not necessarily a problem the compiler would find (it's up to the developer to make sure whether the data in their application is valid or not).

Gotcha. So the compiler would catch, say, a misspelled command?

[CraigSca]

Correct. Those type of things are always caught. Most languages are so open-ended, however, that it's almost impossible for a compiler to validate the actual data your application uses/creates. That's the domain of the developer and where the majority (if not all) RTEs are caused.

[Easy Mac]

They didn't invent the RTE, they made it better.

[sterlingice]

Yeah, if you're a programmer, you're well versed in run time errors as they're much harder to find then compile time

SI

[gstelmack]

RTE is Visual Basic's version of the "Unhandled Exception" you see from every real programming language out there...

[Coffee Warlord]

Bring back "Proper" seg faults.

[Young Drachma]

I'm glad it's not just me with this problem. I've never had a problem running any other text sims, but I always have a problem with these for the same problem. All sorts of automation errors and the sort.

Grr..

[Glengoyne]

For me it was PureSim. I've had more than my fair share of RTEs from Puresim. Sometimes it would cost me my association. So I pathologically backup my associations/leagues. Another text sim, I've had them in was TDCB, so that isn't too far off from a GreyDog origin.

They are there, in lots of programs..some are more severe than others. I really think they are more prevalent in our little niche market of text-sims because the developers are more likely to be responsive to customer feedback. Therefore deadlines are tighter, testing is cut short, and bugs slip in. I really don't have a problem with it, as long as the finally released version doesn't come to the screaching halt of an RTE on regular basis. The occasional problem isn't a big deal, it is the repetitive errors that keep me from coming back.

[gstelmack]

I'm actually amazed at how stable FOF remains. Only time I've ever out-and-out crashed it was messing around with Extractor and sending bad Windows messages to it, and those were all my fault.

[Ben E Lou]

To be clear, I'm not bashing .400/GDS games for being more unstable than others (although I agree that FOF is remarkably stable). It was more the issue of when I've seen other software crash, it is usually the "windows has had a problem and needs to shut down this software" thing, or a crash to desktop. For me, the RTE crashes have (I think) only come from .400 or GDS. Just found it odd, that's all.

[gstelmack]

Originally Posted by SkyDog

To be clear, I'm not bashing .400/GDS games for being more unstable than others (although I agree that FOF is remarkably stable). It was more the issue of when I've seen other software crash, it is usually the "windows has had a problem and needs to shut down this software" thing, or a crash to desktop. For me, the RTE crashes have (I think) only come from .400 or GDS. Just found it odd, that's all.

Yeah, that's just the Visual Basic runtime. As pointed out, FBCB / FBB will do it as well when they crash. Anything written in C++ or .NET will give you a more standard windows error. Not sure what Java will yell out.

[21C]

There's always the lazy way out in VB:

ON ERROR RESUME NEXT

[Young Drachma]

Originally Posted by SkyDog

To be clear, I'm not bashing .400/GDS games for being more unstable than others (although I agree that FOF is remarkably stable). It was more the issue of when I've seen other software crash, it is usually the "windows has had a problem and needs to shut down this software" thing, or a crash to desktop. For me, the RTE crashes have (I think) only come from .400 or GDS. Just found it odd, that's all.

Same here. And I felt like it was just me, so it was sorta frustrating, because it didn't make a whole lot of sense was all.

[Icy]

The RTE come from GDS games and not from other games like FOF for the reason Gstelmack said, "Run Time Error" is the Visual Basic error name, while "CTD" (crash to desktop) are the other languages errors (like C++, used in FOF).

To show you how hard must be to detect that kind of errors GDS guys are having, i'll tell you a small story from my university student days.

As part of the programming classes, as end of course project, i had to program in Java a software like the one used by the air lines companies, to book all the plane sits (of course a basic one). The teacher told us that he was going to be really picky about errors handling, we should program totally avoiding any possible error.

I programmed the software, and once it was working properly, being able to book the sits as i input it, etc, i decided it was the time to test it for errors. To do that, i started to input stupid things to the software questions like:

Number of sits to book?-> abc
The software crashed, as it was expecting a number, so i had to add an error handler to make sure that the input was a number, else to ask again.

Number of sits to book?-> 1.5
The software crashed, as it was not expecting a decimal number, so i had to add an error handler to make sure that the input was not a decimal number, else to ask again.

Number of sits close to windows?-> 100000000000
The software crashed, as there weren’t as many windows sits, so i had to add an error handler to make sure that the input was not over the maximum sits, else to ask again.

Etc, etc. As you can see, there are thousands of possible errors when the software gets a non expected input. My software was too simple, but now think on the same idea applied to a game that has thousands or millions calculations, stats, etc and you imagine how hard would be to detect all the possible wrong data and math outcome provided to/by the engine.

For sure error handling is the nightmare of every programmer as it can't be detected by compilers, you must use your brain, lots of tests and of course some programming techniques/knowledge to imagine all the possible problems related to the more weird situations outside the standard ones. Also the different programming languages have different error handling routines built in, and VB is not specially good on that.

With all that i wrote, i'm not excusing anybody, just explaining what are that RTE's from where do they come and how are detected.

[flere-imsaho]

Originally Posted by JonInMiddleGA

I've seen RTE's in a wide variety of programs from a wide variety of developers.
Obviously, YMMV

Ditto.

[Arles]

Sometimes you can get more info from an RTE than just a handled exit (same end). C++ has different error trapping so you might see different "exiting errors" from other games using that language.

From a .400/GDS standpoint, 6-7 games have been first versions which usually have more errors than a 4th or 5th version. That's not meant to be a crutch for this, but it would explain why there seem to be more from .400/GDS than say an FOF, OOTP or SI games. BBCF, TPF, TDCB, TCB, TPB, WreSpi, TEW, are all on their first version (or had a first version in the past couple years). The hope is as you refine each title, the number of unaccounted errors diminishes. But, most first versions from any develop have a larger number of errors than (I'm sure) that developer would like.

Again, this isn't a defense for errors being in games, it's simply an attempt at explaining it.

[sabotai]

Originally Posted by CraigSca

An RTE is something that's not going to be found when the code is compiled. It's an error that occurs only after running the program. For instance, if you had a division by zero - that's an error, but not necessarily a problem the compiler would find (it's up to the developer to make sure whether the data in their application is valid or not).

No offense to anyone, but if you're having problems with division by zero, you're a pretty lazy programmer.

(And that's coming from a lazy programmer. )

[gstelmack]

Originally Posted by sabotai

No offense to anyone, but if you're having problems with division by zero, you're a pretty lazy programmer.

(And that's coming from a lazy programmer. )

When you write 3D real-time simulations with non-deterministic inputs, then you can talk about lazy programmers. Besides, a floating point divide-by-zero isn't an unhandled exception, it just generates NaNs, which love to hide in your code and just make things look a little wonky...

[sabotai]

Originally Posted by gstelmack

When you write 3D real-time simulations with non-deterministic inputs, then you can talk about lazy programmers. Besides, a floating point divide-by-zero isn't an unhandled exception, it just generates NaNs, which love to hide in your code and just make things look a little wonky...

Hello Mr. lazy programmer, how are you today?

[gstelmack]

Originally Posted by sabotai

Hello Mr. lazy programmer, how are you today?

Not quite cranky enough to have posted the first response that occurred to me when I read your post: "Bite me"

[Mac Howard]

"Run Time Error" is merely the terminology used by particular languages/development systems but the same type of error can occur in all languages - these will merely use other terminology. RTEs will occur in the German GFA system I use for SaaP etc.

As has been said, they indicate that the code itself is good but is failing to deal with the extremes of data that the program produces or the user introduces. RTEs can be very useful in debugging as they usually include a number which indicates the nature of the problem. The divide by zero error is a common one - RTE #1 in the system I use - but there are 128 listed RTEs in total.

Unfortunately these errors are sometimes discovered by users as they can often occur only rarely and only in circumstances almost unique to this user. They're missed during testing precisely because of this. They can be a pig to isolate and fix as the circumstances are often either unknown or difficult to reproduce.

[Neon_Chaos]

Run Time Errors are usually Visual Basic-related errors. Mostly concerned with illegal operations done by a certain code that cannot be caught during compilation of the source code into the executable file.

e.g. dividing by zero, selecting an array element not within an array, attempting to add 1 to a value with a current value and a limit of 100