Egoboo SVN 2.7.3 bugs

Report bugs, errors and balance issues you may encounter ingame here.

Moderator: Developers

Locked
User avatar
Zefz
Squirrel Knight (Administrator)
Squirrel Knight (Administrator)
Posts: 3820
Joined: Wed Jul 23, 2008 1:27 am
Location: Norway
Contact:

Egoboo SVN 2.7.3 bugs

Post by Zefz »

Okay here is a bug thread of bugs I discovered in the SVN so far:
- The game usually crashes when SDL_mixer closes down (on game quit)
- I cant break idols (Healer Starter)
- You can kill tranches that are hidden inside chests and idols (before breaking the idol or opening the chest)
- No death message (IfKilled not running?)
- G'nome Starter module crashes upon start
- Archaeologist Starter also crashes upon start
- There seems to be something funky going on with the game physics
Last edited by Zefz on Wed May 20, 2009 3:28 pm, edited 2 times in total.
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 »

This part in script.c causes a number of bugs.

Code: Select all

// characters that are not "alive" should have greatly limited access to scripting...
// in the past it was completely turned off
if ( !pchr->alive ) return;


No AI scripts are run on dead stuff. Particle effects, messages, death sounds and AI respawning doesn't work with this line of code. What was the specific reason you disabled this? Commenting this out also fixed the healer not being able to break idols (and the death messages).

Also another minor issue:
- Dead bodies have no bump resistance (bump dampen?). They are pushed around like they weigh nothing. Bodies were previously almost unmovable and required jumping over (making a body littered combat field more difficult to navigate).
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 »

No AI scripts are run on dead stuff.


I did a check and the only way to previously run scripts on "dead" objects was if they were crushed or cleaned up.

That specific line was added in error and would restrict the script from running on even those objects, though the grub mum is still able to run "clean up" on the grub bugs to get them to respawn...

I think the solution is to move the "gatekeeping" code from let_all_characters_think() to run_script(), since there are ways of running scripts without calling let_all_characters_think(), and those should have the same exact restrictions on running as all other scripts AFAIK.


Dead bodies have no bump resistance


They have exactly the same properties as live bodies. The "problem" is the way that friction is handled on all objects. It does not work like real world friction, and has never been able to keep heavy objects from moving.

The reason that living objects don't get pushed around is that usually the script tells them to move in a way that masks this behavior (like they move toward the object that bumps them, or they seem to run away).

Currently, the bumpdampen variable is only used in actual collisions, a lot of the object-object collision behavior is determined by a pressure-like effect to keep objects from overlapping.

We do not want to turn this off if both objects have bumpdampen set to 0, but I can figure out something to do so that the object with the lower bumpdampen moves less.

As I said, the real fix is to fix the friction.

Bodies were previously almost unmovable


Bodies were completely ignored in collision calculations. If it was not alive it did not collide with anything.
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 »

Bodies were completely ignored in collision calculations. If it was not alive it did not collide with anything.

But I am certain that bodies could block your path. Some classes even got a skill for auto jumping over corpses.

Most AI script even change their bump height upon death to tell Egoboo that the body is lying down now and not standing upright anymore.
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 are right about the collision calculations, it is just that object-particle interactions ignore dead bodies.

Collisions used to ignore held items (unless they are charged, like flaming swords ... :twisted:), and inventory items.

At the present time, I believe that I allowed all objects to collide, including held objects.
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 »

Ah you are right! Enemies can't move through my held sword anymore :) I guess this is a good thing we want to keep, right people? I take it the extra collision calculation for held items don't affect FPS much? (on my new pc I always get 40 FPS -the limit-, no matter how high my video settings are)

Ah and this explains why you can attack monsters that hide inside chests. The tranch is "held" inside the chest and can be attacked by others. I guess this also rules for pets that are either held in hand or in inventory (the latter is bad and should be considered a bug).
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 »

Ah and this explains why you can attack monsters that hide inside chests.


Argh, I did not mean that inventory objects are allowed to collide, just that all objects that are drawn on the screen including held items...

You should not be able to attack things in someone's inventory. Those objects still do not show up in the collision calculations.

I want inventory items to be able to think, though, so we can have eggs that hatch into pets and such.
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 »

The G'nome Starter and Archaeologist Starter modules seem to work correctly now.

I discovered a AI targeting bug:
- SetTargetToWideBlahID doesn't work correctly. It seems Zombi helpers in the Zombi Starter do not grab weapons that lie on the ground anymore. Also the Lumpkins in the Elf starter recognize a morphed player always as an enemy (BLAHINVERTID not working problerly, i.e excludeid in get_target() function)
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've noticed that too. It seemed to be working before, but it not working at all right now... Everything ignores each other.
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 »

It seems my Cobol Palace module crashes if I start it with a Release binary. The Debug binary seems to work perfectly fine. The log gives no error and the crash does not even give any error or warning message. (The game simply quits, but not the "good" way).
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 »

Make sure that you have the .exe capture all the unhandled exceptions. It should always pop up a dialog box when you get an exception asking if you want to debug ( I think ).

The big Release vs. Debug problems are usually:

- debug memory allocations are usually zeroed out, but not in Release
- debug uses a different heap to keep track of allocations (which causes problems with linking some non-debug .dlls or .libs)

If it was something like buffer overrun, you might have caught it in the debug version.

More likely it is an uninitialized pointer?
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 am running it in debug mode now and placing break points all over the place to track down where it quits. It quits with code 3. So far I've tracked it down to draw_main().
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 could just look at the egoboo code for all the exit() calls. if there are none with exit(3) then the problem is in some function that egoboo calls.
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 found the error. In render_fan() there is an error.
In this line

Code: Select all

v[cnt].s = tile_dict[type].u[badvertex] + offu;

it crashes when hitting fan number 5554.


The question is why this does not happen in the debug binary?
Last edited by Zefz on Tue May 05, 2009 8:57 pm, edited 1 time in total.
User avatar
penguinflyer5234
Sheep (Developer)
Sheep (Developer)
Posts: 3025
Joined: Wed Jul 23, 2008 1:39 am
Location: Best Southwest

Post by penguinflyer5234 »

Zefz wrote:The question is why this does not happen in the debug binary?


The memory structure is different in the debug build.
...
Locked