Latest SVN update
Moderator: Developers
-
- {]-[0{0|307 (Developer)
- Posts: 1864
- Joined: Wed Jul 23, 2008 4:22 am
- Location: Minnesota, USA
Latest SVN update
I created a new sticky because there really was no place to post these messages... it really isn't a binary, is it?
-
- {]-[0{0|307 (Developer)
- Posts: 1864
- Joined: Wed Jul 23, 2008 4:22 am
- Location: Minnesota, USA
I added in the new PhysicsFS-based virtual filesystem. The API functions are pretty self-explanatory if you have ever looked at a vfs before.
One thing to keep in mind is that when accessing "external libraries" you need to use the vfs_resolve*Filename functions to pass the correct system-dependent lfilename to the library.
It is pretty obvious that SDL_mixer and similar things are be treated as external. However, the mpd loader, the configfile system, and the md2 loader will be treated as "external" too.
There are still several known bugs due to importing and exporting objects, and the menu info being deleted at the wrong time. I will work on those next.
One thing to keep in mind is that when accessing "external libraries" you need to use the vfs_resolve*Filename functions to pass the correct system-dependent lfilename to the library.
It is pretty obvious that SDL_mixer and similar things are be treated as external. However, the mpd loader, the configfile system, and the md2 loader will be treated as "external" too.
There are still several known bugs due to importing and exporting objects, and the menu info being deleted at the wrong time. I will work on those next.
- Zefz
- Squirrel Knight (Administrator)
- Posts: 3820
- Joined: Wed Jul 23, 2008 1:27 am
- Location: Norway
- Contact:
Hurray! Been waiting for this update a while now In the meantime I'll try to fix/debug some of those game-play bugs that were reported:
Great work birdsey
Code: Select all
- Walking next to someone , with the magic carpet in hand, makes them ride it without you dropping it
- Splitting a stack of fortune cookies makes the dropped cookie unburned and unsoggied.
- If I start bishopia city or forgotten fortress comes only the text: press escape for quit.
- Wizard starter: the unlock spell dont work on chest.
- The position of the end text when you finish a module is wrong
- My squirrel get no exp
- The water wierd moves very strange
Great work birdsey
-
- {]-[0{0|307 (Developer)
- Posts: 1864
- Joined: Wed Jul 23, 2008 4:22 am
- Location: Minnesota, USA
we also may need to decide on where the user data is going to be stored.
Right now, it is being stored under C:\Documents and Settings\$USER\Application Data\egoboo. A lot of cross-platform apps make it .egoboo, though to make it a hidden directory on *nix.
If we keep this dir, then you need to add a link to this directory in the installer?
I still need to work on th *nix file stuff to make sure that everything is in the right place.
Right now, it is being stored under C:\Documents and Settings\$USER\Application Data\egoboo. A lot of cross-platform apps make it .egoboo, though to make it a hidden directory on *nix.
If we keep this dir, then you need to add a link to this directory in the installer?
I still need to work on th *nix file stuff to make sure that everything is in the right place.
- Zefz
- Squirrel Knight (Administrator)
- Posts: 3820
- Joined: Wed Jul 23, 2008 1:27 am
- Location: Norway
- Contact:
If we keep this dir, then you need to add a link to this directory in the installer?
To create the /players folder with any players that come with the installer?
Oh and PhysFS won't work for me yet. I have it included and followed all install instructions but for some reason PHYSFS_getWriteDir() decides to return a NULL pointer.
- Zefz
- Squirrel Knight (Administrator)
- Posts: 3820
- Joined: Wed Jul 23, 2008 1:27 am
- Location: Norway
- Contact:
No, I'm running Windows XP 64-bit. PhysFS documentation said it should work properly. The game starts up and initializes everything properly until PHYSFS_getWriteDir() is run through vfs_resolveWriteFilename() when vfs_removeDirectoryAndContents() is run to delete the "import" folder. I checked the string it sends through and nothing seems wrong there.
Commenting the following line makes the game run:
fs_removeDirectoryAndContents( write_dir, recursive );
fs_getSaveDirectory()
"C:\Documents and Settings\Administrator\Application Data\egoboo\"
Commenting the following line makes the game run:
fs_removeDirectoryAndContents( write_dir, recursive );
fs_getSaveDirectory()
"C:\Documents and Settings\Administrator\Application Data\egoboo\"
Code: Select all
Game: C:\Documents and Settings\Administrator\My Documents\Programmering\Egoboo 2.7.x
Temp: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\
Save: C:\Documents and Settings\Administrator\Application Data\egoboo\
Import: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\import\
-
- {]-[0{0|307 (Developer)
- Posts: 1864
- Joined: Wed Jul 23, 2008 4:22 am
- Location: Minnesota, USA
You said that " for some reason PHYSFS_getWriteDir() decides to return a NULL pointer". AFAIK, it should just return whatever was given to it using PHYSFS_setWriteDir().
Does "C:\Documents and Settings\Administrator\Application Data\egoboo\" exist? If not, manually create it and see what happens.
You may also need to compile everything eliminating unicode specifically?
Not exactly, the player's controls.txt and settings.txt will be in those folders (as well as any /players/blah.obj), so the player may need to have access to the directory for detailed settings changes, and possible development purposes.
We have had several problems with people on linux modding the wrong version of settings.txt (IIRC).
Does "C:\Documents and Settings\Administrator\Application Data\egoboo\" exist? If not, manually create it and see what happens.
You may also need to compile everything eliminating unicode specifically?
To create the /players folder with any players that come with the installer?
Not exactly, the player's controls.txt and settings.txt will be in those folders (as well as any /players/blah.obj), so the player may need to have access to the directory for detailed settings changes, and possible development purposes.
We have had several problems with people on linux modding the wrong version of settings.txt (IIRC).
- Zefz
- Squirrel Knight (Administrator)
- Posts: 3820
- Joined: Wed Jul 23, 2008 1:27 am
- Location: Norway
- Contact:
Adding the missing folder fixed the problem.
For some reason this part was not triggered when the folder was missing:
where write_dir is a <Bad Ptr> which caused the next function to fail and make the game crash. I fixed this by adding a check for bad pointers in fileIsDirectory().
For some reason this part was not triggered when the folder was missing:
Code: Select all
// make sure that this is a valid directory
write_dir = vfs_resolveWriteFilename( dirname );
if( !fs_fileIsDirectory(write_dir) ) return VFS_FALSE;
where write_dir is a <Bad Ptr> which caused the next function to fail and make the game crash. I fixed this by adding a check for bad pointers in fileIsDirectory().
-
- {]-[0{0|307 (Developer)
- Posts: 1864
- Joined: Wed Jul 23, 2008 4:22 am
- Location: Minnesota, USA
standing on a platform should not affect jumping.
AFAIR, I made the jump speed add to the platform speed (like in reality) for a while. I think it is now relative to the floor, like it was in 2.22.
In either case, you will think that the jumping is less when the platform is going up (the original) or going down (my method).
Could we do something to change the jump speed, like holding the button down longer makes you jump higher?
------------------------
- fixed a bug in the joystick reading function that did not allow for analog control of the joystick. Now you can control the character's speed much better with an analog joystick... Rogues rejoice!
AFAIR, I made the jump speed add to the platform speed (like in reality) for a while. I think it is now relative to the floor, like it was in 2.22.
In either case, you will think that the jumping is less when the platform is going up (the original) or going down (my method).
Could we do something to change the jump speed, like holding the button down longer makes you jump higher?
------------------------
- fixed a bug in the joystick reading function that did not allow for analog control of the joystick. Now you can control the character's speed much better with an analog joystick... Rogues rejoice!
- Zefz
- Squirrel Knight (Administrator)
- Posts: 3820
- Joined: Wed Jul 23, 2008 1:27 am
- Location: Norway
- Contact:
Try the Wizard Starter for example. Jumping normally works fine, but as soon as you step on that stool for example (located in the room you spawn) you will notice that your jumping is almost not existing.
Also there is some strange targeting bug. In the Adventurer Starter Brom constantly attacked thin air and the Grub Mum boss battle was triggered from a very long distance.
----------
I found out what was causing the AI targeting bug. The following section in get_target() is the source:
If we return MAX_CHR certain monsters (like the Mephit) will think there is no enemy around and do nothing but if we return the previous target, some AI like Brom or the Grub Mum will think they have found a new proper target, even though they are out of range and not facing them. What do we do? Do we do a whole target calculation for that single target before returning? If the target doesn't fulfill all the requirements, it should return MAX_CHR.
Replacing it with the following code seems to fix all AI targeting related bugs:
Also there is some strange targeting bug. In the Adventurer Starter Brom constantly attacked thin air and the Grub Mum boss battle was triggered from a very long distance.
----------
I found out what was causing the AI targeting bug. The following section in get_target() is the source:
Code: Select all
// just return the old target if
if ( 0 != ChrList.lst[ichr_src].stoppedby && ChrList.lst[ichr_src].ai.los_timer > current_ticks )
{
return MAX_CHR;
//return ChrList.lst[ichr_src].ai.target;
}
If we return MAX_CHR certain monsters (like the Mephit) will think there is no enemy around and do nothing but if we return the previous target, some AI like Brom or the Grub Mum will think they have found a new proper target, even though they are out of range and not facing them. What do we do? Do we do a whole target calculation for that single target before returning? If the target doesn't fulfill all the requirements, it should return MAX_CHR.
Replacing it with the following code seems to fix all AI targeting related bugs:
Code: Select all
// just return the old target if
if ( 0 != ChrList.lst[ichr_src].stoppedby && ChrList.lst[ichr_src].ai.los_timer > current_ticks )
{
Uint16 current_target = ChrList.lst[ichr_src].ai.target;
if( VALID_CHR(current_target) )
{
float dist2 = max_dist2;
GLvector3 diff;
bool_t is_hated;
// Skip non-existing objects, held objects and self
if ( VALID_CHR(ChrList.lst[current_target].attachedto) || ChrList.lst[current_target].pack_ispacked || current_target == ichr_src || ChrList.lst[ichr_src].attachedto == current_target ) return MAX_CHR;
// Target items
if ( !target_items && ( ChrList.lst[current_target].isitem || ChrList.lst[current_target].invictus ) ) return MAX_CHR;
// Either only target dead stuff or alive stuff
if ( target_dead == ChrList.lst[current_target].alive ) return MAX_CHR;
// Dont target hostile invisible stuff, unless we can actually see them
if ( !ChrList.lst[current_target].canseeinvisible && FF_MUL( ChrList.lst[current_target].inst.alpha, ChrList.lst[current_target].inst.max_light ) < INVISIBLE ) return MAX_CHR;
//Correct team
is_hated = TeamList[ChrList.lst[ichr_src].team].hatesteam[ChrList.lst[current_target].team];
if ( target_type != TARGET_ALL || (target_type != TARGET_ENEMY && !is_hated) || (target_type != TARGET_FRIEND && !is_hated) )
//Calculate distance
diff = VSub( ChrList.lst[current_target].pos, ChrList.lst[ichr_src].pos );
dist2 = VDotProduct( diff, diff );
if ( dist2 <= max_dist2 ) return current_target;
}
return MAX_CHR;
}
-
- {]-[0{0|307 (Developer)
- Posts: 1864
- Joined: Wed Jul 23, 2008 4:22 am
- Location: Minnesota, USA
Also there is some strange targeting bug. In the Adventurer Starter Brom constantly attacked thin air and the Grub Mum boss battle was triggered from a very long distance.
When certain ai's loose a target (in this case probably because the grub mum went too far into the shadow), they just keep hitting attack. I think this is because they have themselves for the target (target == none really means target == self), but they are still in attack mode.
It doesn't seem to bother other AIs, though.
-----------------
Hmmmm.....
The code to throttle the rate was introduced to reduce computation for "bad" AIs that call the search function pretty much every frame.
I think I see the reason that the "higher intelligence" AIs are having a problem... They only check for a new target when the old one is dead or out of range, not all the time.
Maybe we could abstract a portion of the code to make a function that determines whether a target is valid (apart from the distance criterion)? You seem to have done that by repeating part of the code.
In any case, we definitely need to throttle access to the search function so that the AIs do not do some stupid things. An AI can be switch two or more targets on a frame by frame basis. Nothing ever gets done and the AI looks stupid. I have actually seen this happen with grub bugs, though not normally.