[Nifelheim]

So if you aren't sure it's debris that cause it, ehy don't you make a simple mission, only debris and see if it crashes again. It may not solve the problem, but it'll give you a hint to what you should be looking for...

[Drew]

iv encoured this bug when targeting normal ships. Iv had this bug when: A ship is still exploding and i target its debris right after the ship explodes. but mostly when i target normal ships

[StratComm]

I hate to drag up an old question, but I was talking to my roommate (a CS major) and he said this sort of bug can occur with floating point variables (especially in comparisons) and that inserting a print command before the offending line can cause them to behave properly.  It makes very little sense, but I figured I'd put up the input ASAP.  If someone could post (or PM if it's long) the offending function in its original form, I'd like to take a look at it.  I don't know enough C to mess with CVS or I'd dig it up myself.

[Bobboau]

that makes no sence...
have your frend post here

[StageTech]

I dont really understand the difference between the open-source and the original coding so this may sound like I am a fool for asking, but why would it not crash on the retail release yet does on the open-source release?  I guess my lack of knowledge on this kinda is confusing me.

[Kakis]

Originally posted by StageTech
I dont really understand the difference between the open-source and the original coding so this may sound like I am a fool for asking, but why would it not crash on the retail release yet does on the open-source release?  I guess my lack of knowledge on this kinda is confusing me.

I belive it does crash in the old Volition FS2 retail as well. It's with a special kind of build to eliminate bugs, called a debug build, it does not crash.

[Goober5000]

The reason fs2_open crashes is that somebody somewhere along the line accidentally let a bug into the code.  It never crashed in retail fs2.

Debug builds do not "eliminate bugs"... they are designed to make bugs easier to see.  The fact that this particular bug does not appear in a debug build is highly unusual.

[StageTech]

ah, thank you for clarifying that, was curious.

[Setekh]

Ah, not fair, newbie while I was having a night on the town.

Welcome to HLP, StageTech!

[Kakis]

Originally posted by Goober5000
Debug builds do not "eliminate bugs"... they are designed to make bugs easier to see.  

That was what I meant . They are built to eliminate bugs with, of course you have to do the hard work yourself. And ok I wasn't sure about the original FS2 part, you're probably right.

This code below is the first half of the function that decides which one of the targets that are in the reticle that will be the new target. Code starting at line 2686 in HUDtarget.cpp (of whatever version I have).

Is it possible that this might do a hackish fix to alter the code to always culls the debris out (it's not altered below, but you get it)? I haven't made a succeful build yet so I can't tell.

[EDIT] Changed the function to a much simpler one. This is a function called to determine if it's a allowed target to target through the reticle function. It's called from hud_target_in_reticle_new() and hud_target_in_reticle_old(). As before this is the original one below.

Code: [Select]


// Return !0 if target_objp is a valid object type for targeting in reticle, otherwise return 0
int object_targetable_in_reticle(object *target_objp)
{
int obj_type;
if (target_objp == Player_obj ) {
return 0;
}

obj_type = target_objp->type;

if ( (obj_type == OBJ_SHIP) || (obj_type == OBJ_DEBRIS) ||
(obj_type == OBJ_WEAPON) || (obj_type == OBJ_ASTEROID) || (obj_type == OBJ_JUMP_NODE) ) {
return 1;
}

return 0;
}


[SnakeEyes]

I haven't experienced the crashing yet, but I've seen that the debris models lack any kind of detail when I'm playing with HT&L, Large Textures and FS2_Open_3.5.5 with the latest media VP.

I mean that when a ship explodes and I target in reticle a piece of the ship...... It looks like a model with no texture at all.

[Col. Fishguts]

kakis could be right with this 750 ms stuff. I encountered this bug for the very first time today, when I looked at a exploding ship an pressed "target-in-reticle" very fast, which resulted in targeting various debris parts and then  a crash to desktop.
If I do the same thing slower no crash occurs.

[CP5670]

The procedure that Kakis gave seems to work fairly reliably to reproduce the bug, but I have had the same thing occur (spontaneous in-mission crash to desktop) in a number of other situations that did not involve targeting or debris at all. I have had it happen when I launched missiles, ships fired beams, messages were sent and a number of other things. Maybe we are dealing with more than one bug here.

[Kakis]

Can I get a comment on my code suggestion from one of the real SCP coders that actually knows their stuff?

[Kakis]

Bumping thread (I know this about bumping old threads...sorry...I just really want this bug solved)

Any updates? If not a bit of a guess follows below:

I was talking to a friend the other day and somehow got into coding and stuff and for some reason I mentioned this weird bug. He replied that it would probably be that somewhere there is apointer that isn't initalized. I didn't understand it fully but in some way debug builds would always initlaize it to null which the release build won't do (sort of).

Then there is perhaps some place in the code that checks if it's a null pointer and if so then something happend and do this instead, otherwise carry on...which would lead to a crash with a bad pointer.

[phreak]

here's a part of the dev log sticks posted on the new webpage

1. The "Y" Targeting Bug

Unfortunately, this week the "Y" bug has not yet been solved. There were a number of theories. Here's what Goober had to say.

    Okay, the 2/19 build crashes, which means the bug was introduced between 2/14 and 2/19. I'm guessing it all happened in Bobboau's commit on 2/16.

    A CVS diff between those dates produces a fair amount of output... there are modifications in twelve files: freespace.cpp, grd3drender.cpp, gropengl.cpp, multimsgs.cpp, object.cpp, managepilot.cpp, aicode.cpp, ship.cpp, shiphit.cpp, beam.cpp, weapon.h, and weapons.cpp. Can you guys take a look, do a date diff, and see what you come up with?

The slipperiness of the bug reared its ugly head as well. Sticks said, "Debug and release work fine for me, I did the same thing as RT." After much confusion, the probable source has been located, although no devs can say why exactly. From Goober:

    Okay. Following Phreak's suggestion, I systematically rolled back each file committed on 2/16 to pinpoint the error. The results are disturbing.

    The 'Y' targeting bug was introduced in weapons.h, when version 2.6 was updated to version 2.7.

    This doesn't make any sense! Look at the CVS diff between those two versions. The changes were trivial - one #define and two float declarations. Why on earth would this introduce a bug?!? Could the size change of the BWI struct have anything to do with it?

The issue currently remains unresolved.

[J3Vr6]

Looks like you're getting somewhere though...

[Goober5000]

Actually, we reached a dead end.  We'll have to turn around and try something different now.

[CP5670]

I'm no programmer, but could it be a memory issue? As I said before, it occurs with many seemingly disparate events, but the one thing I noticed was that whatever causes it has always done so in its first instance of a game session. For example, firing bombs caused it when I did so for the first time since the exe was opened up, and so on. It may well just be coincidence, or it could point to some problem if stuff is being loading into memory in the middle of a game.

[Sticks]

Yay! The Dev Log got quoted already!

The problem with this type of bug is that they are very unreproduceable, which means that tracing through the code is almost impossible unless you just happen to stumble upon it while debugging.