jcobleigh
Level: Legendary Architect

Rank Points: 25
Registered: 09-17-2003
IP: Logged

File: drod-ktrace.txt.bz2 (13.4 KB)
Downloaded 55 times.
License: Other
From: Unspecified

Originally posted by trick
In this kind of situation the strace util is very useful (just run strace ./drod >drod-strace 2>&1). It generates a lot of output, but you can see exactly what DROD looks for in the filesystem and what errors it gets back (among other things). If you haven't got strace installed, install it.

OS X does not have strace, which is Linux specific. However, it does have ktrace, which appears to do the same thing. I have attached the output from ktrace to this post because I am very confused as to what is going on. I can tell that it is looking in many places for the Data files. At one point, the following gets printed:

   466 drod     CALL  open(0xbfffd870,0,0x1b6)
   466 drod     NAMI  "/Users/jmc/drod/Data/drod1_6.dat"
   466 drod     RET   open 9
   466 drod     CALL  close(0x9)
   466 drod     RET   close 0
   466 drod     CALL  access(0x2b381a0,0x5)
   466 drod     NAMI  "/Users/jmc/drod/Data/Bitmaps/HalphHopeful.bm_"
   466 drod     RET   access -1 errno 13 Permission denied
   466 drod     CALL  access(0x2b380e0,0x5)

So it looks like it is finding drod1_6.dat, but I have no idea why the file "/Users/jmc/drod/Data/Bitmaps/HalphHopeful.bm_" is not getting found. The file exists and its permissions are 644. The directories in the tree are all have permissions set to 755. According to sys/errno.h, errno 13 is EACCES, "Permission denied", which doesn't make sense to me. Any thoughts?

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

I did a search on ktrace, and it appears there's a tool called kdump that makes ktrace-logs "human readable". I actually kinda liked the ktrace format, tho

In any case, the reason DROD searches for that file is just a simple test to check if the resources are present. From the log it seems it looks for access permissions 5, ie R-X, so giving the file exe permissions will solve this. There was a bug in the code before that required it to have that, although I thought that had been fixed. Maybe the bug was reintroduced. (Jikes.)

- Gerry

jcobleigh
Level: Legendary Architect

Rank Points: 25
Registered: 09-17-2003
IP: Logged

File: drod-kdump.txt.bz2 (13.3 KB)
Downloaded 52 times.
License: Other
From: Unspecified

trick wrote:
I did a search on ktrace, and it appears there's a tool called kdump that makes ktrace-logs "human readable". I actually kinda liked the ktrace format, tho

Actually, what I posted before was the results of taking the ktrace and running kdump on it, so my previous post contained the "human readable" logs.

In any case, the reason DROD searches for that file is just a simple test to check if the resources are present. From the log it seems it looks for access permissions 5, ie R-X, so giving the file exe permissions will solve this. There was a bug in the code before that required it to have that, although I thought that had been fixed. Maybe the bug was reintroduced. (Jikes.)

OK. I made the file HalphHopeful.bm_ have permissions R-X, which seems to work for that file . However, I'm still getting some bizarre results. When DROD goes through looking for the files, it finds the drod1_6.dat file in /Users/jmc/drod/Data. Right before it fails with the message "Couldn't find DROD data. This problem might be corrected by reinstalling DROD.", it looks for the file in "/Users/jmc/drod", a place it already looked without success. This seems odd to me and I've attached the full trace from kdump.

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

jcobleigh wrote:
Actually, what I posted before was the results of taking the ktrace and running kdump on it, so my previous post contained the "human readable" logs.

That explains that, then

OK. I made the file HalphHopeful.bm_ have permissions R-X, which seems to work for that file . However, I'm still getting some bizarre results. When DROD goes through looking for the files, it finds the drod1_6.dat file in /Users/jmc/drod/Data. Right before it fails with the message "Couldn't find DROD data. This problem might be corrected by reinstalling DROD.", it looks for the file in "/Users/jmc/drod", a place it already looked without success. This seems odd to me and I've attached the full trace from kdump.

Hum. There's definitely something fishy going on there. I'll look into it more later when I have some time to, but in the mean time, have you tried setting the DROD_1_6_DAT_PATH and DROD_1_6_RES_PATH envvars to bypass the pathsearcher (as a temporary workaround) ?

- Gerry

jcobleigh
Level: Legendary Architect

Rank Points: 25
Registered: 09-17-2003
IP: Logged

trick wrote:
Hum. There's definitely something fishy going on there. I'll look into it more later when I have some time to, but in the mean time, have you tried setting the DROD_1_6_DAT_PATH and DROD_1_6_RES_PATH envvars to bypass the pathsearcher (as a temporary workaround)?

I tried setting these environment variables, but it didn't seem to help. I set both DROD_1_6_DAT_PATH and DROD_1_6_RES_PATH to /Users/jmc/drod/Data. However, when I run drod, it gives the same error. The results of ktrace show the same problem:

   526 drod     CALL  open(0xbfffdc30,0,0x1b6)
   526 drod     NAMI  "/Users/jmc/drod/drod1_6.dat"
   526 drod     RET   open -1 errno 2 No such file or directory
   526 drod     CALL  write(0x2,0xbfffda80,0x50)
   526 drod     GIO   fd 2 wrote 80 bytes
       "Couldn't find DROD data.  This problem might be corrected by reinstalling DROD."

I'm quite confused.

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

Hm. Could you attach your version of BackEndLib/Files.cpp ?

- Gerry

jcobleigh
Level: Legendary Architect

Rank Points: 25
Registered: 09-17-2003
IP: Logged

File: Files.cpp (41.5 KB)
Downloaded 50 times.
License: Other
From: Unspecified

trick wrote:
Hm. Could you attach your version of BackEndLib/Files.cpp?

It is attached. Thanks!

Jamie

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

Looks like you're using the Windows version of the path searching code. Nothing wrong with that, it should still work (the windows searcher just tries the exe dir and then all higher dirs), although the env-vars will have no effect since they're checked in the linux code.

Anyway, at least this explains why the need-exe-flag bug came creeping back. To fix that, replace the calls to IsValidPath with DoesFileExist at line 1101 and 1108. This will also fix the can't-find-res problem, since IsValidPath also checks if the found file is a directory and returns false if it isn't.

Hope this gets it working

- Gerry

jcobleigh
Level: Legendary Architect

Rank Points: 25
Registered: 09-17-2003
IP: Logged

trick wrote:
Hope this gets it working

I now have a version of DROD running on my OS X box. There are still a few issues that need to be worked out, but for the most part, things look good. Sound works. I was able to create a player and start to move through the first level and if I quit and restore the game, it starts me in the room I was last in. I have noticed two issues:

1. When I change any of the options in the settings window and click on "Okay" to leave the settings, none of them get saved. This happens within a single session of drod. Meaning, if I go into settings, change a setting, hit Okay, then go back into settings (without quitting drod), the setting I changed gets reset to its default value. This is particularly annoying because I want to rebind the movement keys because I am on a laptop and don't have a numeric keypad.

2. When I go into the settings window, in the name box, each letter is shown as a box rather than a letter. My guess is this is a Wchar/endian issue, but it doesn't affect the game play.

Any idea on how to make the settings persist?

Thank you very much for all of the help!

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

jcobleigh wrote:
I now have a version of DROD running on my OS X box.

That's awesome! Great work!

1. When I change any of the options in the settings window and click on "Okay" to leave the settings, none of them get saved. This happens within a single session of drod. Meaning, if I go into settings, change a setting, hit Okay, then go back into settings (without quitting drod), the setting I changed gets reset to its default value. This is particularly annoying because I want to rebind the movement keys because I am on a laptop and don't have a numeric keypad.

I had a look, and I think the problem is here (in DRODLib/DbPackedVars.h):

	WCHAR *	SetVar(const char *pszVarName, const WCHAR *pwczValue) 
	{
	   return (WCHAR *) SetVar(pszVarName, (const void *) pwczValue, (WCSlen(pwczValue)+1)*sizeof(WCHAR));
	}

There's no LittleToBig conversion here (no existing sgi define), so unless you've added one in your copy, the string passed to the other SetVar will consist of all zeros (assuming ascii chars). So, no variables can be saved through this function. You could call UnicodeToAscii (from BackEndLib/Wchar) to convert the WCHAR string properly.

Edit: Wops, that explaination was partly wrong.. The var name is passed as a char, so it should still get set (although to an invalid value), and you shouldn't convert with UnicodeToAscii. Try byteswapping the WCHAR string before passing it on.

(Hm, actually I think you need to do this with the rest of the SetVar functions there as well)

2. When I go into the settings window, in the name box, each letter is shown as a box rather than a letter. My guess is this is a Wchar/endian issue, but it doesn't affect the game play.

Well, if all other texts work, the Wchar stuff should be fine. There may be some obscure TextBoxWidget-specific bug, of course, but there's other things that can cause this -- input handling, for example. Can't see anything obviously wrong at first glance, though =/ . Have a look in DROD/SettingsScreen.* and FrontEndLib/TextBoxWidget.* , and try to see what happens by running it through a debugger.

Good luck

- Gerry

[Edited by trick on 05-17-2004 at 10:41 PM GMT]

[Edited by trick on 05-17-2004 at 11:00 PM GMT]

[Edited by trick on 05-17-2004 at 11:04 PM GMT: see above]

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

jcobleigh wrote:
2. When I go into the settings window, in the name box, each letter is shown as a box rather than a letter.

This is where I would start--the first problem is likely related. Some logging or step-through debugging to narrow down the problem would be helpful. Does the name look screwed up before you update settings? If so, then I would probably examine the call to this->pNameWidget->SetText(pPlayer->NameText) in CSettingScreen :: UpdateWidgetsFromPlayerData () to see if the text from NameText is in the correct byte order. If the problem only happens after you update the settings, then I would check out the call to pPlayer->NameText = pTextBox->GetText () in CSettingsScreen :: UpdatePlayerDataFromWidgets () to see if the data going into NameText was byte-ordered the right way. At least, it seems like that would be fruitful, but I could be wrong.

I see something that at first glance looks wrong, but I'm not sure about it right at the moment. Some input from Schik or Trick might be valuable: In DbBase.cpp, GetMessageText() has a byte-reordering block, but GetAllocMessageText(), AddMessageText(), and ChangeMessageText() don't. Is that right?

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

ErikH2000 wrote:
I see something that at first glance looks wrong, but I'm not sure about it right at the moment. Some input from Schik or Trick might be valuable: In DbBase.cpp, GetMessageText() has a byte-reordering block, but GetAllocMessageText(), AddMessageText(), and ChangeMessageText() don't. Is that right?

Yeah, sounds to me like you found a bug there (same as the SetVar bugs, really ... although I'm not really that familiar with the db stuff, so I should probably pass it on to Schik ), but would this affect input while he's writing ?

(Btw, Jamie, if you already read the message I wrote above, note I made a mistake before and made a few edits).

- Gerry

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

trick wrote:
(Hm, actually I think you need to do this with the rest of the SetVar functions there as well)

It depends on the variable type. These are the methods that need byte-swapping, I believe:

WCHAR *       SetVar(const char *pszVarName, const WCHAR *pwczValue);
DWORD *       SetVar(const char *pszVarName, DWORD dwValue);
int *         SetVar(const char *pszVarName, int nValue);
UINT *        SetVar(const char *pszVarName, UINT wValue);
const WCHAR * GetVar(const char *pszVarName, const WCHAR *pwczNotFoundValue = NULL) const;
int           GetVar(const char *pszVarName, int nNotFoundValue = 0) const;
UINT          GetVar(const char *pszVarName, UINT wNotFoundValue = 0) const;
DWORD         GetVar(const char *pszVarName, DWORD dwNotFoundValue = 0) const;

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

jcobleigh
Level: Legendary Architect

Rank Points: 25
Registered: 09-17-2003
IP: Logged

File: DbPackedVars.cpp (15.7 KB)
Downloaded 50 times.
License: Other
From: Unspecified

trick wrote:
That's awesome! Great work!

I didn't do that much except do what I was told. But I'm glad its (mostly) working.

ErikH2000 wrote:
It depends on the variable type. These are the methods that need byte-swapping, I believe:

WCHAR *       SetVar(const char *pszVarName, const WCHAR *pwczValue);
DWORD *       SetVar(const char *pszVarName, DWORD dwValue);
int *         SetVar(const char *pszVarName, int nValue);
UINT *        SetVar(const char *pszVarName, UINT wValue);
const WCHAR * GetVar(const char *pszVarName, const WCHAR *pwczNotFoundValue = NULL) const;
int           GetVar(const char *pszVarName, int nNotFoundValue = 0) const;
UINT          GetVar(const char *pszVarName, UINT wNotFoundValue = 0) const;
DWORD         GetVar(const char *pszVarName, DWORD dwNotFoundValue = 0) const;

I tried to perfrom byte swapping in these methods. However, the settings window is even more broken. When I go to the settings window, every setting now has the value of "Unspecified". I've attached my version of DbPackedVars.cpp because I think I did things correctly. I call LittleToBig in each GetVar method. I call LittleToBig twice in each SetVar method (once to convert the input value and once to convert the value that will be returned).

When (if?) you look at my code, I moved the code for the SetVar methods from DbPackedVars.h to DbPackedVars.cpp. Because the makefile does recompilation based on dependencies, without this move every time I changed a SetVar method, every file that included DbPackedVars.h was getting recompiled which took up time and annoyed me.

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

jcobleigh wrote:
I call LittleToBig twice in each SetVar method (once to convert the input value and once to convert the value that will be returned).

This is a problem. We're using one variable to hold both the little-endian byte-ordered storage value and the machine-byte-ordered return value of GetVar() and SetVar(). To be honest, I think it is a design flaw of CDbPackedVars and will be a bit tough to deal with. So here is the gist of changes I would make to CDbPackedVars. Sorry, they aren't real cut and dry. Up to you, Jamie, if you want to try making them.

Suggested 1.6 Changes

The "pValue" member of UNPACKEDVAR always contains data in machine byte order, and the buffer returned from CDbPackedVars::GetPackedBuffer() will have reversals performed as needed. That buffer goes straight into the database, BTW, which is why it must be little-endian.

That part would be easy enough, but when you read the data back out in CDbPackedVars::UnpackBuffer(), you don't know which variables need byte reversal, because like a big stupid dummy, I didn't store type info in the buffer. We could change this, but that would effectively invalidate the existing 1.6 data format and create a new one, which would be a large pain.

So I think we could instead make a kludgy function like this...

bool CDbPackedVar:: Does1_6VarNeedByteReversal(const char *pszVarName) const
{
  return (strcmp(pszVarName, "somevar" ) ==0 || strcmp(pszVarName, "someothervar" ) ==0 || ... );
}

Hunt around for SetVar() calls and make a list of names and types passed in the second param. If variable name corresponds to a type that needs byte-ordering then it goes in the above strcmp code.

Suggested 2.0 Changes

The ugly function above should die with 1.6. For 2.0 we fix packed vars to store variable type.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

I'll have a better look at this later, but I'm guessing you're converting something twice. Also try using fresh dats from cvs, the ones you've got are probably corrupted by now.

ErikH2000 wrote:
Hunt around for SetVar() calls and make a list of names and types passed in the second param. If variable name corresponds to a type that needs byte-ordering then it goes in the above strcmp code.

An easy way to find these is to let the compiler do it for you. Find the SetVar calls that require byte-swapping (ie the ones with types longer than one byte) and define them to be deprecated in the prototype (in the header), like this:

WCHAR * SetVar(const char *pszVarName, const WCHAR *pwczValue) __attribute__((__deprecated__));

Then do a make. gcc/g++ will tell you where those functions are being called, and you can go to see what variables are being used for those calls. Remember to remove the attribute when you're done.

- Gerry

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

ErikH2000 wrote:
So I think we could instead make a kludgy function like this...

Um... If there's no type information, the calling function wouldn't know how to swap. An int with bytes 1234 gets swapped into 4321, while a 2-char WCHAR string turns bytes 1234 into 2143. Or did I misunderstand ? I have a feeling I might have.

I guess you could prefix all the variable names in the code with type information chars, but that'd be... ugly.

- Gerry

[Edited by trick on 05-18-2004 at 11:35 PM GMT: typo]

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

trick wrote:
I'll have a better look at this later, but I'm guessing you're converting something twice. Also try using fresh dats from cvs, the ones you've got are probably corrupted by now.

Yeah, he is converting a buffer twice in SetVar() calls. He reverses it once to put the buffer in the right little-endian order for database storage, and then he correctly noticed that the app is expecting SetVar() to return a value in machine byte order, so he reversed the return buffer a second time. The return buffer is also the same as the storage buffer, so storage gets screwed up.

It isn't so tough to find a solution that will store values correctly in the database and also return correctly-ordered buffers from SetVar() and GetVar(). Bigger trouble comes up when you attempt to read the data back from the database and order it correctly. Some variable buffers need reversal and others don't, but the cues for this weren't stored with the data. Hence, my ugly solution of using variable names to indicate which buffers need reversal.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

trick wrote:
Um... If there's no type information, the calling function wouldn't know how to swap. An int with bytes 1234 gets swapped into 4321, while a 2-char WCHAR string turns bytes 1234 into 2143. Or did I misunderstand ? I have a feeling I might have.

No, you didn't misunderstand. I just forgot about this part. How about we just change my ugly function to...

enum { UVT_uint, UVT_dword, UVT_wchar, .... } UNPACKEDVARTYPE;

UNPACKEDVARTYPE CDbPackedVar::Get1_6VarType(const char *pszVarName) const

...And then have calling code determine the proper way to fix byte-ordering based on var type?

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

jcobleigh
Level: Legendary Architect

Rank Points: 25
Registered: 09-17-2003
IP: Logged

ErikH2000 wrote:
Yeah, he is converting a buffer twice in SetVar() calls. He reverses it once to put the buffer in the right little-endian order for database storage, and then he correctly noticed that the app is expecting SetVar() to return a value in machine byte order, so he reversed the return buffer a second time. The return buffer is also the same as the storage buffer, so storage gets screwed up.

Let me see if I understand what is going on. SetVar is returning a pointer to the memory in the database. The DROD methods (i.e. everything outside of the database) that operate on these pointers expect the values to be in machine byte order. But since this memory is in the database which expects the value to be little-endian, there are now two entities sharing this memory which expect the data to be in different orders creating problems.

Why can't I, in the SetVar methods, make a copy of the data and return the copy (after calling LittleToBig on it)? Does this create a memory leak? (I haven't done C++ programming in several years and am used to Garbage Collection in Java where you don't have to worry about these things).

The other reason I can think that this might not work is that the DROD methods that use these pointer might expect them to point to the memory in the database. If this is the case and the DROD methods write to this memory (without using SetVar), then I need to look for places where this memory gets written and do LittleToBig conversions before the assignments happen. If this is the case, the safest solution (at least to me), is to change the SetVar methods so they don't return a pointer into the database (i.e. return void) or make what is returned const, so that all changes get made through a call to SetVar.

Does this make sense or have I completely misunderstood the problem?

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

jcobleigh wrote:
Let me see if I understand what is going on. SetVar is returning a pointer to the memory in the database.

Not exactly. SetVar is returning a pointer to memory that has been prepared for storage in the database. The code that actually stores values from CDbPackedVars variables into the database will call CDbPackedVars :: GetPackedBuffer ( ) to get a storable buffer.

The DROD methods (i.e. everything outside of the database) that operate on these pointers expect the values to be in machine byte order. But since this memory is in the database which expects the value to be little-endian, there are now two entities sharing this memory which expect the data to be in different orders creating problems.

Yeah, that is all correct except for the pointer coming from the database.

Why can't I, in the SetVar methods, make a copy of the data and return the copy (after calling LittleToBig on it)? Does this create a memory leak? (I haven't done C++ programming in several years and am used to Garbage Collection in Java where you don't have to worry about these things).

This is one of the solutions I typed up in a reply to you and then deleted. We could do that and it would give us a CDbPackedVars that stored data correctly and also returned machine-byte-ordered values from it's methods after you set values of variables, but... This solution doesn't address the problem of reading the values back in from the database. When you read a variable value back in, you need to know if it needs byte reordering and, as Trick pointed out, what kind of byte reordering.

Also, it is cleaner to handle byte-ordering in just two places, when the packed buffer is being created in preparation for database storage ( CDbPackedBuffer :: GetPackedBuffer () ) and when the packed buffer is being unpacked from storage ( CDbPackedBuffer :: UnpackBuffer () ). This way, you don't need to worry about allocating and cleaning up extra buffers for machine-byte-ordered values returned from GetVar( ) and SetVar( ). Since we don't have garbage collection, that would entail either asking the caller to delete returned pointers or keeping track of the extra returned buffers in CDbPackedVars and destroying them along with the object. It's better to do away with these hang-around buffers by confining byte-reordering code to the two methods that need it.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

jcobleigh
Level: Legendary Architect

Rank Points: 25
Registered: 09-17-2003
IP: Logged

File: DbPackedVars.cpp (17.4 KB)
Downloaded 47 times.
License: Other
From: Unspecified

ErikH2000 wrote:
Also, it is cleaner to handle byte-ordering in just two places, when the packed buffer is being created in preparation for database storage ( CDbPackedBuffer :: GetPackedBuffer () ) and when the packed buffer is being unpacked from storage ( CDbPackedBuffer :: UnpackBuffer () ).

Well, I gave it a shot. I've attached my version of DbPackedVars.cpp which I think should work, but does not. When I go into the settings window for the first time (after starting DROD), everything looks normal. When I make changes, quit, and go back in a second time, everything is either blank or unspecified and I'm not sure why. If someone could take a look at the GetPackedBuffer and UnpackBuffer methods and give me a clue on what to try next, I'd really appreciate it. I'm going to be away for a week starting on Monday, so I may not be able to do much on this until I get back. But, since I will have my laptop with me, I still may be able to try a suggestion if you have any.

Thanks!

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

Just a little note... I haven't forgotten about you (yet ), but I'm in the middle of a bunch of exams, so I've no time to help you at the moment. I'll be back

- Gerry

jcobleigh
Level: Legendary Architect

Rank Points: 25
Registered: 09-17-2003
IP: Logged

File: DbPackedVars.cpp (17.6 KB)
Downloaded 44 times.
License: Other
From: Unspecified

trick wrote:
Just a little note... I haven't forgotten about you (yet ), but I'm in the middle of a bunch of exams, so I've no time to help you at the moment. I'll be back

I understand. Thanks for the post. Even if you made a post last week, I wouldn't have been able to act on it since I was in Scotland. I made a few changes to DbPackedVars.cpp which I thought would help. Unfortunately, they didn't. I've attached my most recent working version of the file.

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Jamie, are you around? I sent you an e-mail a little while back.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)