• entries
    500
  • comments
    1888
  • views
    333262

Testing Day 4

Sign in to follow this  
EDI

65 views

Not much happened yesterday, testing wise.

Ive removed my focus from the configuration window bug, since I have bigger fish to fry.

Right now my focus is on the save system, and removing the bugs from it.

Last night while debugging it I ran into a strange bug, which was causing it to crash.

Upon further examinaton it turned out that I was doing some HOOOORRRRIIBBLE =D

For Instance:


script=new Script();
script.Load(file);
process=new ScriptProcess(script);
process.ResumeExecution();
m_processes.InsertObject(process);


Looks fine and dandy? well it's not =D

the issue comes from these two lines:

process.ResumeExecution();
m_processes.InsertObject(process);

now, ResumeInstruction makes a script execute,
now depending on the script, this function could totaly finish before it even gets to inserting the process into the processes list.

This is bad because the executor is responsible for removing the process from the list. So if it did finish (and try to be removed) before it even got to the insertion, then it would insert it after the fact, WHICH IS BAD!!!! =D

so, a simple swap of things fixed it, not sure what I was smoking when I coded that ;)

m_processes.InsertObject(process);
process.ResumeExecution();


Somthing you may find funny =D

Saving is done through our engine by a pair of functions, Pack and Unpack, both of which pass an Archive object which is used for saving and loading data to/from file, respectively.

I discovered that the classes MWDoor and MWChest, were not overriding these functions, and as such were not getting thier state (such as opened,locked,blocked...) saved.

So a simple addition of a function and a few calls to arc->PackByte() and it's unloading counterpart UnpackByte(), saved the state.

However, when i run the program, I now have no doors =D

*scratches head*

now wait just a minute! [grin]

After a bit of searching I discovered that while I did override Pack and Unpack, I failed to call super in either [grin]

This of couse did not forward the superclass chain of processing and esentially did not save anything about the door object save for the few states in the subclass.

I found it rather funny =)




The current issue with the save is actually quite interesting =)

The save and load work fine, until i cast a single spell, or more precicely, added a sprite to the 'undersprites' layer.

if i save after this point the save goes fine
but when i try to load it again it cant seem to find said sprite in the reloaded objects list, strange indeed, and will require lots of tracing to insure that i am saving things properly *ugh* [grin]
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now