Latest SVN update

The development of the game itself or new resources for it. Any new stuff you're working on would go here, as well as the discussion of in-development stuff.

Moderator: Developers

Post Reply
bgbirdsey
{]-[0{0|307 (Developer)
{]-[0{0|307 (Developer)
Posts: 1864
Joined: Wed Jul 23, 2008 4:22 am
Location: Minnesota, USA

Latest SVN update

Post by bgbirdsey »

I created a new sticky because there really was no place to post these messages... it really isn't a binary, is it?
bgbirdsey
{]-[0{0|307 (Developer)
{]-[0{0|307 (Developer)
Posts: 1864
Joined: Wed Jul 23, 2008 4:22 am
Location: Minnesota, USA

Post by bgbirdsey »

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.
User avatar
Zefz
Squirrel Knight (Administrator)
Squirrel Knight (Administrator)
Posts: 3820
Joined: Wed Jul 23, 2008 1:27 am
Location: Norway
Contact:

Post by Zefz »

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:

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 :)
bgbirdsey
{]-[0{0|307 (Developer)
{]-[0{0|307 (Developer)
Posts: 1864
Joined: Wed Jul 23, 2008 4:22 am
Location: Minnesota, USA

Post by bgbirdsey »

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.
User avatar
Zefz
Squirrel Knight (Administrator)
Squirrel Knight (Administrator)
Posts: 3820
Joined: Wed Jul 23, 2008 1:27 am
Location: Norway
Contact:

Post by Zefz »

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.
bgbirdsey
{]-[0{0|307 (Developer)
{]-[0{0|307 (Developer)
Posts: 1864
Joined: Wed Jul 23, 2008 4:22 am
Location: Minnesota, USA

Post by bgbirdsey »

Check what the return value for fs_getSaveDirectory(). You are running on Vista, yes? Maybe SHGetFolderPath() is not working properly?
User avatar
Zefz
Squirrel Knight (Administrator)
Squirrel Knight (Administrator)
Posts: 3820
Joined: Wed Jul 23, 2008 1:27 am
Location: Norway
Contact:

Post by Zefz »

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\"

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\
bgbirdsey
{]-[0{0|307 (Developer)
{]-[0{0|307 (Developer)
Posts: 1864
Joined: Wed Jul 23, 2008 4:22 am
Location: Minnesota, USA

Post by bgbirdsey »

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?

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).
User avatar
Zefz
Squirrel Knight (Administrator)
Squirrel Knight (Administrator)
Posts: 3820
Joined: Wed Jul 23, 2008 1:27 am
Location: Norway
Contact:

Post by Zefz »

Adding the missing folder fixed the problem.

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().
bgbirdsey
{]-[0{0|307 (Developer)
{]-[0{0|307 (Developer)
Posts: 1864
Joined: Wed Jul 23, 2008 4:22 am
Location: Minnesota, USA

Post by bgbirdsey »

Adding the missing folder fixed the problem.


ahhh.... that part is hard to alpha test! If I already created the folder for some reason it would never cause an error! LOL
bgbirdsey
{]-[0{0|307 (Developer)
{]-[0{0|307 (Developer)
Posts: 1864
Joined: Wed Jul 23, 2008 4:22 am
Location: Minnesota, USA

Post by bgbirdsey »

update to the physics.

characters really slide down slippery slopes now, but don't jump as high. It definitely needs a bit of tuning.
User avatar
Zefz
Squirrel Knight (Administrator)
Squirrel Knight (Administrator)
Posts: 3820
Joined: Wed Jul 23, 2008 1:27 am
Location: Norway
Contact:

Post by Zefz »

I noticed jumping is severely handicapped when you are standing on a platform. This makes certain puzzles impossible to complete. This was before the revision you mentioned in last post.
bgbirdsey
{]-[0{0|307 (Developer)
{]-[0{0|307 (Developer)
Posts: 1864
Joined: Wed Jul 23, 2008 4:22 am
Location: Minnesota, USA

Post by bgbirdsey »

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!
User avatar
Zefz
Squirrel Knight (Administrator)
Squirrel Knight (Administrator)
Posts: 3820
Joined: Wed Jul 23, 2008 1:27 am
Location: Norway
Contact:

Post by Zefz »

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:

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;
   }
bgbirdsey
{]-[0{0|307 (Developer)
{]-[0{0|307 (Developer)
Posts: 1864
Joined: Wed Jul 23, 2008 4:22 am
Location: Minnesota, USA

Post by bgbirdsey »

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.
Post Reply