Descriptive Problem Summary:
While mapping clicking on any mob after already selecting a mob causes a crash. (Pretty much opening the mob category and clicking on the types in succession.)
Numbered Steps to Reproduce Problem:
(stated above.)
Expected Results:
The mob becoming selected.
Actual Results:
The window flickers for a moment as a error report appears.
When does the problem NOT occur? Never.
Workarounds: Nope.
Reduced instances in source to 0 after reading some other bug-reports but it didn't help.
I've noticed it ONLY happens in the mob's categories so I tried to reduce the size of the category but it had no effect.
Not sure if this helps...
AppName: dreammaker.exe AppVer: 1.0.0.1 ModName: ntdll.dll
ModVer: 5.1.2600.5755 Offset: 00010a19
ID:102568
 Sep 28 2010, 1:09 pm (Edited on Sep 28 2010, 5:29 pm)
|
|||||||||||||
Resolved
| |||||||||||||
Yeah, I have a feeling it's something in the source - I'll send you the source now.
- Sent. | |
The crash does happen with your source. Looking into this now.
| |
The problem seemed to be a very very old bug that was being triggered by one piece of your code. This probably doesn't come up very often because the code in question represents bad practice. These are some of lines I saw defining mob vars:
KO_SYMBOL = icon('Player_Overlays.dmi',"Ko'ed") These vars are each initialized by their own special proc during New() so that they will be available when you need them. The reason this is bad practice is that you shouldn't be initializing anything but the mob itself during its creation if you can help it. If the mob needs any icons, lists, etc. it should have another way to get them when they're needed. Otherwise, they get created for every single mob, which wastes memory. The specific line that was crashing was the KO_SYMBOL line, because that's making a call to new/icon(). While the bug fix will take care of the crash, you will probably see a speed and memory improvement in your project if you find a different way to initialize that var, and cache the icon once it's created. Every call to new/icon() like this has to load up an icon and then extract the state you asked for. It's creating a bunch of separate /icon objects when you could just have most mobs sharing the same one. So my recommendation for a workaround until 478 is released would be to eliminate all cases like that and only initialize things when you need to, and keep icons in a cache. | |
Oh wow... I wasn't aware of how bad that was. Thank you for the tips and speedy response.
| |
No problem. I appreciate that you got the source to me quickly--it wouldn't have been possible to spot this without it.
| |
[edit]
Naturally if you can distill this down to a smaller demo project that showcases the problem, that works too. My gut says that the size and complexity of your project is a player in this issue though so it'd probably be difficult to trim to a simple demo.