Crash on resized lots at 7PM -- any ideas?
dizzy:
Quote from: pbox on 2007 November 03, 14:14:19
Dizzy:
Can you see any significant difference in the error logs depending on what lot the error occurred on? Or can you point me at where to look in the logs, so that I can see that for myself? (it's probably not very interesting reading, going through 25 logs all over again) This could be interesting in order to see whether there's any difference in what is *on* the lots (walls, roofs, foundations) .. you said
...
I can see where it say's "EIP" in the logs but I have no idea where/how to look for an index or overflowing multiplyers, if you'll forgive my ignorance =).
No, the logs tell you very little. In fact, I wish they had outputs on the FP registers as well as some other stuff, but you take what you can get. I did a very preliminary analysis using a debugger, and that led me to the conclusion of bad pointers due to screwy offsets. Basically, they are trying to load a value from [EAX+ECX] after doing a multiply using EDX. I assume there is a boundary error considering you are getting an Access Error from the CPU/MMU, however the code itself clearly does no bounds checking of its own (due to some compilation optimizations, no doubt).
Mootilda:
Quote from: dizzy on 2007 November 03, 16:11:34
the code itself clearly does no bounds checking of its own (due to some compilation optimizations, no doubt).
Interesting hypothesis (that the compiler optimization is removing the bounds checking). What do you base that on? I've been assuming that the developers are using a language without bounds checking (nobody really writes software with C#, do they?) and that they are too rushed in development to add bounds checking on their own.
[Update:]
Did a quick check with friends in compiler development and game development and they agree. Games are likely written in C / C++ and have no bounds checking unless the developers add it themselves. Compiler optiimizations would never remove bounds checking unless they were fundamentally broken. Let's not blame the compilers for the fact that the game developers are working too hard fast to do proper bounds checking.
(Sorry about the rant, but I work on program development tools for a living.)
Inge:
I suppose they never reckoned with us writing these tools. So if it's not the game protecting its own data, I am pleased with the job my operating system is doing! I have not yet had a totally borked hood and you should see some of the things I get up to!
dizzy:
Let's not change the subject, Mootilda. I don't think anyone else cares about the details of how compilers work. My point is, whether you believe compilers are involved, the program is severely lacking in what I would consider common robustness that is taught even at the college level.
Mootilda:
Quote from: Inge on 2007 November 03, 16:40:31
I suppose they never reckoned with us writing these tools. So if it's not the game protecting its own data, I am pleased with the job my operating system is doing! I have not yet had a totally borked hood and you should see some of the things I get up to!
Absolutely. What we've doing with shrinking of lots to allow walls at the edges is well ouside of normal game play.
Quote from: dizzy on 2007 November 03, 16:47:04
the program is severely lacking in what I would consider common robustness that is taught even at the college level.
Agreed. However, that doesn't stop us from modding. We just need to be careful to avoid doing things that the game can't handle.
Navigation
[0] Message Index
[#] Next page
[*] Previous page