[karajorma]

Yeah, I'm going to have to agree that bad data causing a null vec should in general be caught somewhere before the in-game crash (unless it's pretty obvious immediately what is causing the crash). Now the argument can be made that this should be caught before the model even gets into the game (in some cases, it should be PCS, etc catching it) but yeah, we shouldn't be closing errors caused by bad data unless

1) They were caused by bad practice, not simply bad data (for instance I have little sympathy for crashes caused by notepadding a mission as they bypass the FRED safety checks).
2) They're so unlikely to ever be seen again that the time spent finding the cause is less than the time needed to fix the cause.


That said, in that argument (which I only caught part of) you did seem to be arguing in favour of having the non-retail solution that existed between 3.6.11 and 3.6.13 restored. And that's not a good idea. If I've got that wrong, please tell me.

[Goober5000]

FUBAR's IRC log contains cherry-picked quotes.  The comment log for Mantis #2346 tells the whole story.  You can read it over and come to your own conclusion.

EDIT: And as for the shield issue, that hasn't even been resolved/closed yet.

[FUBAR-BDHR]

No I was arguing that the retail solution be reinstated.  Retail is a shield value of 0 = no shields.  That was deemed to not be an incorrect assumption the code made in retail and thus the change from retail behavior the correct behavior.  Since it does not affect retail or fsport since all player ships have non 0 shield values it is apparently OK to change that behavior.  Breaks TBP , Breaks BTRL, and possibly 12 years of other mods using shield = 0 to disable shields. 

[FUBAR-BDHR]

FUBAR's IRC log contains cherry-picked quotes.  The comment log for Mantis #2346 tells the whole story.  You can read it over and come to your own conclusion.

EDIT: And as for the shield issue, that hasn't even been resolved/closed yet.

Which has again been closed with no check of the vector call.  Unless you are 100% positive that the only way for that data to cause a null vec3d is coming from that modelread then there is still an issue.  There should be a check right before the call in set_goal_dock_orient() to make sure what is passed is valid data. 

[wesp5]

Retail is a shield value of 0 = no shields.

Okay, so I know nothing about what's going on here behind the scenes, but the above seems perfectly logic to me, independent on anything else. So now shield value = 0 won't work anymore? What if I wanted to have a ship with shields disabled in a mod where ships usually have shields? What is the solution they implemented now?

[niffiwan]

The new solution is to give the ship a flag which says "no shields" (called SIF2_INTRINSIC_NO_SHIELDS within the codebase).

But it's a moot point anyway, as a fix to keep shields = 0 working has been committed 

(also see this if you've got a mantis account)

[Slasher]

Thanks for getting that worked out. 

Okay, so I know nothing about what's going on here behind the scenes, but the above seems perfectly logic to me, independent on anything else. So now shield value = 0 won't work anymore? What if I wanted to have a ship with shields disabled in a mod where ships usually have shields? What is the solution they implemented now?

When ships usually have shields, they can be disabled in FRED2 through the Shield Editor or the Ship Editor.  Since, with the exception of the Thirdspace fighter, TBP ships don't really have to worry about shields they got set to zero in the table to save everyone from having to do that step in the editor. 

Ancient History Note:  At least in Release 1, all TBP fighters had shields to provide nominal protection against explosion damage.  I don't know how many times Fury had to field annoying questions about that, usually from me.

[niffiwan]

I feel I should clarify a little so that credit is given where it's due, I didn't have anything to do with the fix, it was Goober.  I was just reporting on what has happened

[wesp5]

But it's a moot point anyway, as a fix to keep shields = 0 working has been committed 

Great ! So can we go ahead planning and testing for the next Zathras release now ?

But speaking of shields, I don't really know how FS2 shields look, but if you watch B5 closely, I'm pretty sure the First Ones had some kind of shielding directly over their armor. Just look how Shadow ships dissipate incoming energy in Shadow Dancing! This could just be a feature of their bio-organic armor of course...

Back on topic, one Mantis link shared here showed FUBAR talking about the fighter/docking bay/null vector problem. So has the issue with fighters launching from Nova dreadnaughts been fixed in the meantime?

[Goober5000]

Which has again been closed with no check of the vector call.  Unless you are 100% positive that the only way for that data to cause a null vec3d is coming from that modelread then there is still an issue.  There should be a check right before the call in set_goal_dock_orient() to make sure what is passed is valid data.

I am 100% positive.  As I said in the Mantis ticket, the Warning is displayed as soon as the dockpoint data is loaded, if the data is invalid.  And the dockpoint data is never changed before it is used.

I feel I should clarify a little so that credit is given where it's due, I didn't have anything to do with the fix, it was Goober.  I was just reporting on what has happened

Thanks.

[FUBAR-BDHR]

I'm glad it's fixed but it does kind of prove my point.  This issue was just dismissed as bad data because it was found in TBP.   If I wouldn't have argued it would have simply been closed for that reason.  On top of that I now have at least 3 people stating they are just ignoring my bugs because of "**** models" now.  This really doesn't bode well for the future of TBP or the SCP if coders can just have that kind of attitude.   

[FUBAR-BDHR]

I haven't confirmed it yet but I'm guessing that the null vec3d errors in GOL_4_Un_Situation.fs2 are caused by attempting to launch 6 fighters from ships with only 4 bay paths.

Okay, I have narrowed it down a bit now. Launching 6 fighters from the Hyperions is no problem, but as soon as I launch only 1 fighter from the Nova dreadnaughts, I get the null vec3d error. So I suspect there is a similar issue there like with the Dilgar ship and it's not about the numbers of fighters that are actually launched...

Well it turns out this is a different version of the same bug as the Sekhmet.  Basically both crashes are caused by the fighters launching straight down.  The Sekhmet because of the path, this mission because the ships happen to point their docking bays in that direction.  Mission could be tweaked by tuning the ships a bit but the bug can happen with any ship that happens to launch a fighter on a downward path.  Amazed no one else has run into it yet.  Guess missions not on the x/z plane aren't that common. 

[mjn.mixael]

I'm glad it's fixed but it does kind of prove my point.  This issue was just dismissed as bad data because it was found in TBP.   If I wouldn't have argued it would have simply been closed for that reason.  On top of that I now have at least 3 people stating they are just ignoring my bugs because of "**** models" now.  This really doesn't bode well for the future of TBP or the SCP if coders can just have that kind of attitude.   

I'm ignoring your tickets because you assume we are doing it wrong, always. So meh. And it doesn't prove your point because...

A: a warning was put in place to tell the modder/user that the bad data exists and they should fix it before going forward. It wasn't rightly ignored as you'd like everyone to believe.
B: you still assumed it was done wrong after Goober "fixed" it, until he explained himself to you. Which is an example of why I won't be working on or testing your tickets.

So meh. You are perfectly capable of debugging/testing/fixing your own bugs since you can't seem to trust anyone else to do it.

EDIT: Note, it has nothing to with TBP. Just your attitude throughout the process.

[FUBAR-BDHR]

I'm glad it's fixed but it does kind of prove my point.  This issue was just dismissed as bad data because it was found in TBP.   If I wouldn't have argued it would have simply been closed for that reason.  On top of that I now have at least 3 people stating they are just ignoring my bugs because of "**** models" now.  This really doesn't bode well for the future of TBP or the SCP if coders can just have that kind of attitude.   

I'm ignoring your tickets because you assume we are doing it wrong, always. So meh. And it doesn't prove your point because...

A: a warning was put in place to tell the modder/user that the bad data exists and they should fix it before going forward. It wasn't rightly ignored as you'd like everyone to believe.

Which did absolutely no good if the user wasn't running debug.

B: you still assumed it was done wrong after Goober "fixed" it, until he explained himself to you. Which is an example of why I won't be working on or testing your tickets.

Which is why there is supposed to be a code review process before committing fixes and closing the bugs.  Also the bug should have never been closed.  Closed means it was a false bug report.  It wasn't a false report as a change was required to prevent the issue.

EDIT: Note, it has nothing to with TBP. Just your attitude throughout the process.

My attitude?  All I did was find a bug and try to explain it while Zacam and then you started *****ing at me and complain about TBP data.   Sorry but I'm not going to sit back and just take bashing of TBP or myself. 

[mjn.mixael]

I'm not bashing TBP, as much as you might want to think I am. Sorry.

You have a habit of comments like "No, that patch won't work. Try again". You could instead have an attitude of, "Hmmm, that approach might help, but doesn't fix the specific issue. What if you tried X,YZ?"

You are creating this conspiracy where we are trying to get down to 100 bugs on mantis at the cost of TBP. What the heck, man? Mantis is littered with bugs that are years old. It's not easy sorting through all of them. Most of them really are not relevant anymore, but we aren't just closing bugs left and right. We aren't just ignoring TBP data ones. We are methodically testing them and doing what we think is the best approach. You disagree with a specific approach or fix? Fine. Tell us why and work with us to get things fixed efficiently. That will be much better than this conspiracy theory you are trying to push here with hand selected log quotes and references to still unresolved mantis tickets.

It's also probably not best to go all WCS on us and start blaming SCP for all of TBP's issues. If you start communicating and working alongside everyone else, then things will get fixed properly.

Or we could just leave the status quo on Mantis with it's bugs from 2006 still open and unresolved... few people actively working on bugs... etc.

For anyone who cares to see our process than just take mine or FUBAR's word for it.. here's a log from today's work weeding out old bugs.