I ran into quite a nifty little bug here with a file I've tried to convert from an old world to a new one. Frankly, there's only been a few minor issues, but some of them have been rather quirky.
One of the things that we save out to disk is a property called ObjectType. Frankly, I don't think we actually have to save it. We use it at runtime to help discriminate between Multis, boats, spawners, items and characters, as a quick numeric check.
When we create a new object, it's ObjectType property is automatically set by what we create (so CBO == 0, CHAR == 1, ITEM == 2 and so on). But these values are automatically set when we create them at load time, based on the header section (eg [HOUSE] will create a multi object).
Here's the thing: The converter validly writes out the new section information with a proper header, but doesn't adjust the ObjectType.
So I see 2 potential solutions
1) Don't bother saving out the ObjectType flag, as it's automatically recreated at load time. This will improve save/load times only minutely, as its another property we don't have to write/read. But it will solve the convert issue.
2) Adjust the converter. This will have to be done in some degree anyway, to bring it more up to date with flags. But it still leaves the redundnant information that we load/store.
I'm inclined to head for number 1 (and I'll be testing that shortly). But thoughts and ideas are always welcome, and others may see something I don't.
WorldConverter and saving issues
-
giwo
- Developer
- Posts: 1780
- Joined: Fri Jun 18, 2004 4:17 pm
- Location: California
- Has thanked: 0
- Been thanked: 0
I'm actually quite suprised we store that... wasn't aware we did.
It's my opinion, that as much as possible, anything stored in an enum (at least anything stored without a definate number assigned to it) should not be stored statically. Since, obviously, one addition at the beginning of that enumerator would cause a world of trouble.
That being the case, I would say rip it out, as long as they are stored with the proper [headers] we shouldn't need to know the numerical object type.
It's my opinion, that as much as possible, anything stored in an enum (at least anything stored without a definate number assigned to it) should not be stored statically. Since, obviously, one addition at the beginning of that enumerator would cause a world of trouble.
That being the case, I would say rip it out, as long as they are stored with the proper [headers] we shouldn't need to know the numerical object type.
Scott
