Guru Meditation Error

[GoogleCodeExporter]

Ever since recent builds around r453 (I have not pinpointed it yet), loading a 
save file as the first thing after starting MineDS results in a red screen guru 
meditation error. Most likely something obvious.

Original issue reported on code.google.com by Matthew3...@gmail.com on 17 Dec 2014 at 3:07

[GoogleCodeExporter]

Tested, working fine on r451

Original comment by Matthew3...@gmail.com on 17 Dec 2014 at 8:56

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Every change to struct worldObject breaks old savefiles. r454
Does it work if you save then load on the latest version?

Original comment by toaster2...@gmail.com on 17 Dec 2014 at 10:10

[GoogleCodeExporter]

It is all using the same version save file. I tested and it started 
specifically r453.

Original comment by Matthew3...@gmail.com on 17 Dec 2014 at 11:23

[GoogleCodeExporter]

It still happens with the latest release.

Original comment by Matthew3...@gmail.com on 17 Dec 2014 at 11:27

[GoogleCodeExporter]

I think this is the problem:
http://stackoverflow.com/questions/4550503/what-happens-when-you-use-fwrite-with
-a-class

Original comment by toaster2...@gmail.com on 18 Dec 2014 at 2:51

[GoogleCodeExporter]

I'll look into that tomorrow. That, or maybe something to do with polymorphism 
since playermob is of type basemob.

Original comment by Matthew3...@gmail.com on 18 Dec 2014 at 3:19

[GoogleCodeExporter]

Loading a save where you have stored the player "class" on disk will crash the 
game when you try to call one of the functions in the player class, due to the 
fact that the vtable of the classes, which point to the virtual functions and 
variables, will no longer be intact. Another issue is that the loadPlayer 
function does not insure that the player mob has been created, and memory space 
for all the players variables has been allocated, potentially leading to a 
memory overflow, which could lead to a GURU.

I would recommend that a mobSave and mobLoad function is created in 
mobHandler.cpp which when saving would print the type of mob that is being 
saved, then calling the mob::saveToFile function to save anything that that mob 
wants to save. On load, you should fscanf for a mobId, spawn a mob by that type 
and call mob::loadFromFile. If the mob's loadFromFile is not implemented, the 
loadFromFile should kill the mob to prevent an excess of mobs at a particular 
position on the map.

Original comment by goldenscruff on 10 Feb 2015 at 10:20

[GoogleCodeExporter]

OK, I now understand about how the corruption occurs, but how are you saying to 
save the mob in the mobHandler function? Create a data class that is saved and 
loaded in which its primitive data members are transferred between the savedMob 
class and the actual mob?

Or are you suggesting writing text data to a save file and then parsing the 
text when loading?

Original comment by Matthew3...@gmail.com on 11 Feb 2015 at 3:35

[GoogleCodeExporter]

I'll try to implement this later tonight.

Original comment by goldenscruff on 11 Feb 2015 at 6:06

[GoogleCodeExporter]

Saving and loading of mobs has been fixed in r488. This should no longer occur.

Original comment by goldenscruff on 11 Feb 2015 at 10:50

• Changed state: Fixed