Hard Light Productions Forums
Hosted Projects - Standalone => The Babylon Project => Public Development => Topic started by: FUBAR-BDHR on November 21, 2012, 01:47:27 am
-
Zathras 2.3 (http://fubar.org/TBP/Zathras_2.3.rar) available for dev testing only. If your just playing the game this is not for you.
To use I suggest extracting into a new directory (something like Zathras2.3) and pointing the mod in the launcher there. This way you can switch back and forth to confirm any issues with the previous version. Of course you will need 3.6.14 or 3.6.15 exes.
Know issues:
-Multiple warnings from the launcher about invalid flags such as -spec, -normal, -env, -glow. These were removed and now default to on. (most of these should be fixed in 3.6.15 r9329 and above)
-Warning about the tech description of the Brakiri 57mm. This is an old bug that was not caught before. It is fixed in Zathras but there is no way around the warning as it still reads the 3.4b weapons.tbl first.
-Collision issue with rotating subsystems. This seems to be code related as the models work with the old collision code.
-Warnings about docking points. This check was recently added. I will have the models fixed for the next revision.
Changes since 2.2:
All Centauri ships now have lods and debris as well as some other fixes. Full list Mantis 510 (http://hard-light.net/mantis/view.php?id=510#c1062)
Fix a docking path issue on the Sharlin.
Fixed quite a few mismatches between number of lods in tables vs actual number model has.
Changes 2.3 to 2.3b
All Narn ships now have lods and debris as well as other fixes. Full list Mantis 510 (http://hard-light.net/mantis/view.php?id=510#c1070)
Added Zathras-hdg.tbm with extended escort and directive lists.
Fixed issue with Vorchan turret pivots from 2.3
-
Oh yeah, more debris to litter the space lanes. :yes: Also, I can't believe that Sharlin docking glitch was missed for eleven years.
Link above goes to "Zathras 2.2." and the archive is the same size as the old Zathras_2.2.rar. Wrong link/filename?
-
That will teach me to copy/paste. Link fixed.
-
Okay, I tested it with some of MAGs missions and everything works fine, like with Zathras 2.2 :)! I still get the two warnings at the start though. I guess 0rph3u5 could easily fix the issue with his Drums of War campaign, once he gets around to read about it here, but what about the other one? Wouldn't it be possible to include a fixed weapon.tbl with the next Zathras to be placed into the main TBP folder overruling the buggy one? Or is the not-changing-anything-in-TBP policy so strict, that you won't do this even for such an obvious fix? Also how will the -glow etc. warnings be fixed?
Anyway, I'm quite pleased with my beam changes now, and I also modified the Drakh scatter gun and the Nial beams a bit. Please take a look at the files attached below. To get the yellow beams into Zathras only the "Wesp5" parts of the weapon.tbl and the df_* effect files would be needed ;)!
[attachment deleted by a basterd]
-
Its been a while since I played TBP, but I recall that the sound for the Nial beams was considerably different than the one from the show. The one from the show sounds like something metal scraping along a steel cable, while the one we have sounds more like a Freespace beam... that is unless its been changed in the last 2 years or something.
-
The turret barrels on the Vorchan seemed to be removed from the rest of the mesh. I think this is 2.3 specific.
(http://img812.imageshack.us/img812/5659/vorchangun.jpg)
-
Looks like the pivot on the barrels was set to center for some reason. Not surprising as the mesh was corrupt and I had to export it piecemeal to get it into max. Even the original .scr and .cob files (actually had the ones for this ship) were corrupt. Had one hell of a time salvaging it and still was only able to save detail0 and the debris. Figures one of the few ships with full lods and debris and I had still had to make new lods.
-
Its been a while since I played TBP, but I recall that the sound for the Nial beams was considerably different than the one from the show.
Speaking of the Nial beams, in TBP they are almost yellow-white, because their main base bitmap is black and white. I changed that to the usual green-yellow of the Minbari, check the archive above for the fixed bitmap!
-
Okay, I'm through with MAGs missions now and everything works fine! If you want, I can upload my patch somewhere or attach it here.
Now I have started vidmasters lovely Dark Children campaign and I can't survive the mission with the explorer anymore on very easy. I did the whole campaign with an older Zathras and engine versions, so did the latest Zathras made the Shadow spitfires weaker somehow? Also the Spitfires weapon description "Quantum Bolt" doesn't fit on the screen, bolt is cut off. Maybe Zathras 2.4 should get rid of the "Quantum" part of it!
Update: I had forgotten completely about the Shadow reflex feature, maybe this is the reason I failed. I'll try tomorrow with that again :)!
-
Updated to Zathras 2.3b. Same download link.
Turrets on Narn and Centauri ships could use some testing. I don't think the Bin'Tak turrets have ever worked correctly and will look at that later. If they do work I don't know how.
Narn Vortex Generator could also use some checking in existing missions. When doing the lods and debris I noticed that the way it was set up it wouldn't have had proper collision detection on the top arm. Also the arms were not spaced properly with the distance between the 2 lower arms being greater then the distance between the top arm and the lower ones. The white is the old locations
(http://fubar5.fubar.org/tbp/narngate.jpg)
I did the best I could to preserve the distance between the 2 lower ones and the existing center point.
-
does the new zathras have the normal map?
-
Well since I don't think I have them probably not.
Confirmed that I do not have them and the thread with them end with a note that the links are broken. Can you please post a valid link or send them to me.
-
I think I found the reason for the "Guardian of Light" Dilgar mission warnings: The Dilgar capital ship has no docking bay! So I get the warning when their fighters leave from there, but no warning when they come in from hyperspace. This is a thing the next Zathras should fix!
-
The DI Sekhmet does have a fighterbay. It's in the center of the ship with 6 paths heading forward.
-
The DI Sekhmet does have a fighterbay. It's in the center of the ship with 6 paths heading forward.
Hm, but it isn't mentioned in the ships-adv.tbl and I'm pretty sure the warning pops up the moment a fighter is supposed to leave. Can I just add the fighterbay info to the table or does it need to go somewhere else too?
-
Where are you getting a ships-adv.tbl from? I'm pretty sure that's not even a valid table name. The DI Sekhmet is in additional-shp.tbm and it has a fighterbay there as well.
-
Where are you getting a ships-adv.tbl from?
It's right there in B5-Core-3_4.vp and I took a look at it to get the weapon names I needed to change to make the Centauri and Brakiri beams yellow. What else could cause these warnings? Once you make the fighters appear from hyperspace instead of docking bays, they are gone!
-
So it is. Another old unused file that should have been removed before the VP was made.
Just about anything could be causing the warning. A ship appearing on top of another ship but that should be ruled out as there are 6 paths and you can only have 6 ships in a wing. So again we are back to needing to find the call stack.
-
Well I was able to confirm an issue with launching any ships from the Sekhmet. I've reproduced it with a retail compatible version of the ship and filed a ticket on it to get that code checked. Still no idea why it's happening.
-
Well I was able to confirm an issue with launching any ships from the Sekhmet. I've reproduced it with a retail compatible version of the ship and filed a ticket on it to get that code checked.
Great :)! I tried a similar remove-or-change-events-until-the-error-dissappears with the Vorlon against EA mission, but couldn't really narrow it down. I have no clue why warnings pop up...
-
Try this version of the Sekhmet (http://fubar5.fubar.org/tbp/sekhmet.pof). It should work around the null vec3d issue.
-
Try this version of the Sekhmet (http://fubar5.fubar.org/tbp/sekhmet.pof). It should work around the null vec3d issue.
Sorry, but it didn't. Unless I need to do more than just put it into the models folder...
-
Strange it fixes it on my end. You put in in Zathras\data\models correct?
-
Do any of you get a blank entry for the tech room description of the EA Skylark transport?
-
Just checked and yes it's blank. There is on in the table so no idea why it's not showing. I'll have to investigate further.
-
Yeah, that stumped me too. I checked the old 3.4 Core ships.tbl and the one in Zathras and the Skylark entry looks correctly formatted in both. :confused:
-
Found it. Missing $end_multi_text for the +description line. Fixed on my end and will be in the next update.
-
Strange it fixes it on my end. You put in in Zathras\data\models correct?
No, I placed it in the main models folder, I moved it into Zathras and now the issue is solved :)! So I guess this will make it into the next Zathras?
-
I finished another version of the Sekhmet last night that will be in the next Zathras. It has the same fix as well as some others.
So can you make a list of other missions where the null vec3d still happens.
-
So can you make a list of other missions where the null vec3d still happens.
The only other mission where I encountered this error yet, having played all of MAGs missions, Dark Children and Guardian of light, is the last mission of the latter (GOL_4_Un_Situation.fs2), in which it happens once the Vorlon dreadnaught blows an Omega destroyer to pieces. But I haven't found any reason for this yet...
-
OK is that from GOLdemo2.vp? If not can you link the mission.
-
OK is that from GOLdemo2.vp?
Exactly. It's sad Darkmaster never continued this campaign! BTW, do you think it would be possible to finish the Earth Minbari war demo campaign for the next DVD release or something? One thing that could easily be done would be to add MAGs missions that play during that time, namely Sheridan blowing up the Dark Star, and the Battle of the line. He would certainly allow them to be used, and both would kind of complete this campaign :)!
-
EMW demo is finished. It's a demo. If you want to make a full EMW campaign you are talking a lot of work but have at it. As far as integrating MAGs missions that is something you would need to ask him about. You would probably still need new voice actors unless you can find the old ones to do the other missions.
-
EMW demo is finished.
To me a demo is never finished. It's part of an upcoming final product, so both the EMW demo and the GOL demo are basically just mementos that the interest in TBP died before they could be completed :(. Now, while some revival of the space combat genre is visible, not only with Diaspora, but with several Kickstarters as well, it may be time to finish them!
If you want to make a full EMW campaign you are talking a lot of work but have at it.
I'm not good enough for something like this, all I can do is remove obvious mission bugs with a text editor ;).
As far as integrating MAGs missions that is something you would need to ask him about.
I'm pretty sure he would allow this, after all he allowed me to patch up his missions too :)!
You would probably still need new voice actors unless you can find the old ones to do the other missions.
MAGs missions only use sounds from the show itself, so this shouldn't be necessary. I'm only thinking, you put so much work into Zathras and if a new version of TBP should be released as TBP Zathras Edition 3.5 or DVD 2.0 or whatever, it would make a better impression to get rid of the demo label of that campaign! After all, there are short and long campaigns and I don't think Diaspora's campaign was much longer either ;)!
-
I think you are taking the word demo in EMW demo wrong. It's not a demo for an upcomming campaign like GOLdemo is it's a demo of what TBP itself can do set in the EMW. It does what it's supposed to do.
-
It's a demo of what TBP itself can do set in the EMW.
Are you sure? I mean, a full campaign was never planned? It surely can be misunderstood the way I did. Maybe renaming it into mini-campaign or something would fix that, because I think the word 'demo' in the game world right now is used to mean what I thought it would mean. After all the Raider Wars campaign isn't labeled as a 'demo' in the same context, no?
-
Pretty sure. EMW and RW were released as finished. EACW, BHX and possibly something called ITF were not finished.
-
I know from internal forums discussion back in late 2001 there was some very brief talk of expanding the EMW campaign, but mission design focus quickly shifted to Release 2 and campaigns that took place ~2261 and later.
-
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. This results in 2 ships being in the exact same position. I've run into this before in multiplayer and already have a ticket on it. If you want to test it try either reducing those wings to 4 ships or slitting them into 2 wings of 3 with a couple of second delay between them.
-
I'm not good enough for something like this, all I can do is remove obvious mission bugs with a text editor ;).
Sounds like all you need to do is actually learn how to FRED. It's a lot easier to learn than most people think. Mastering it takes ages but even a few weeks of practice can get you putting out fairly solid missions if you have the talent.
And it's not like you wouldn't have experienced FREDders around to help you out if you got stuck. :)
-
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...
-
I will upload the normal maps and some textures updates ASAP
-
Well it's not like the Sekhmet because I can't repo it in a test mission with just a Nova and wings launching. Although as predicted you do end up with 2 groups of 2 fighters stacked on top of each other which not only looks bad but causes them damage.
-
Here (http://www.mediafire.com/?2t59tk5loq1aaas) are the updates textures.
-
Well I just found out a TBP game breaking bug exists since 3.6.13. Anytime you fly a default ship in a mission you are given shield energy regen that you aren't supposed to have. Basically this means that power to your engines and weapons has been cut to power the shields that don't exist. So if your wondering why some missions seem a lot harder then they used to there is your answer.
Of course this is another area where it's being labeled TBP's fault for bad data. So at this point it looks like 3.6.12 and Zathras 2.0 is the end of the line. I'm not going to continue work on something that the SCP can change a whim and decide it's our data's fault and I don't expect anyone else to work under those circumstances either. TBP has always been the red headed step child of FS2_Open and frankly I'm tired of it.
-
Surely that wasn't intentional on SCP's part. The first fourth of FS1 is spent without shields and it sounds like 3.6.13 and later builds would change things in those missions too.
-
All FSPort player ships have shields they are just disabled in FRED. Retail code disables shields if the shields are disabled in FRED or if shields are set to 0 in the table and that is the way TBP did it by setting shields to 0 in the tables. That is now being ruled the wrong way to do it and we need to fix all our tables. So it not only affects TBP but any other mods written before the 3.6.13 change that set ships to not use shields by setting shield value to 0 in the tables.
-
Regarding the discussion of a full EMW campaign, it should be noted that Den5's "In The Beginning" incorporates the EMW demo missions (with some slight alterations IIRC). I had taken it upon myself to revise this campaign and make it compatible with the current mod (and comprehensible in English), but alas this was several years ago and my attempts often ran out of steam or encountered RL complications.
-
So has the "shields" field been removed from the ships.tbl or does the engine just handle a value of 0 for that field differently now? This seems like, either way, it would retroactively change the balance for any mod that used a value of 0 for shields in the table.
-
It only affects the ship class of the player. What it does to AI ships I don't know. If your default ship is say a tiger and you change to a badger your ETS will be fine. If you stay as a tiger it's broke.
-
Huh. TBP's done it that way for years. I didn't think SCP was supposed to alter things that could break old work like that.
-
I didn't think SCP was supposed to alter things that could break old work like that.
I really don't understand all the technical details here, but can't someone complain about these changes? On the other hand, what would be needed to fix them? There can't be many ship tables in TBP, no? I remember about 3 or 4 and some of them are unused as you told me...
-
I know FUBAR is regularly talking with coders in the #scp channel. Don't worry, this is not a closed environment.
-
Huh. TBP's done it that way for years. I didn't think SCP was supposed to alter things that could break old work like that.
Nope as long as it doesn't break retail or fsport they can change whatever they like and the mods are expected to adjust.
Also the problem is not just fixing this issue. That I could do. The issue is with the attitudes of most of the SCP towards TBP. They don't see it as a valid project just some mess they wish would disappear. That I can't fix and it makes continuing work on the project an uphill battle. It's only a matter of time before some other project wants a change in behavior that breaks behavior for TBP and I wont be able to work around it. Why continue to put time and effort into something that is just going to end up useless anyway?
-
The issue is with the attitudes of most of the SCP towards TBP. They don't see it as a valid project just some mess they wish would disappear.
Huh? Why do they think that? Is there another FS2 game out there even close to the size and beauty of TBP? I played the much hyped Diaspora lately and compared to the fantastic world of Babylon 5 you all brought to life here, it's only a handful of short missions with grey ships firing volleys of grey projectiles at other grey ships ;)! Or is this because of the IPAndrews trouble from the past and the way TBP can't be continued in a combined way because of it? Maybe then for sure we should release another big DVD issue with all the cool campaigns already done :)!
-
I'm an SCP newcomer so I don't know the TBP history (that's probably a good thing, I don't believe I've got any pre-existing prejudice :)), but I'm not sure where the "SCP is sick of TBP" thing comes from. In this particular case I think the reason you're getting so much blowback from parts of the SCP is because there is an "easy" workaround for the problem (which is the new preferred way of implementing the no-shield feature), and a code side fix looks like it could be a real pain. I don't believe the change wasn't intentional, I think it was an accident as a result of fixing mantis 2326.
It's only a matter of time before some other project wants a change in behavior that breaks behavior for TBP and I wont be able to work around it.
I can't speak for the whole SCP, but I believe that if there was something that broke TBP that didn't have a work-around, it'd be fixed.
-
I'm not privy to SCP's internal decision making myself. In the past I always thought they were pretty accommodating. We had our own little checkbox in the Launcher at one point. But TBP is one of the few mods/TCs here that has been around since before the source code was even released. I guess they got tired of dragging us into the future? If that's the case, I can't blame FUBAR for calling it quits.
-
As probably the only other person on both projects, I don't think this there is as much of an issue between TBP and the SCP as FUBAR makes out. There is somewhat of a bone of contention around the fact that TBP doesn't want to release a new version (which quite frankly no one in the SCP can fully understand the reason for at this point) but as long as the issues with TBP can be fixed in Zathras then there's no issue between the two projects.
And if something comes along that can't be fixed in Zathras, it's going to have a hard time getting into the codebase cause there's a good chance I'll rip out any code that does that myself.
-
Apparently you haven't been on IRC lately then. It's been nothing but complaining about TBP.
[12/03-20:11] <Zacam-Work> Add the flag into a TBM for Zathras and anybody still playing vanilla TBP can go **** themselves for being so die-hard legacy shafted.
[12/03-20:13] <FUBAR> yea any mod made before 3.6.11 did it the only way available then 3.6.13 broke that
[12/03-20:13] <Zacam-Work> No.
[12/03-20:13] <Zacam-Work> Don't confuse "any other mod" with TBP.
[12/03-20:13] <Zacam-Work> Just don't.
[12/03-20:30] <Zacam-Work> But expecting that we're going to continue having to default "like it used to" for a production -plagued- with these kinds of issues that continue to bring to light the very reason why TBP released the way that it did, no.
[12/03-20:30] <Zacam-Work> Zathras can over-ride that to continue the "expected" behaviour with the newer flag via TBM as a forward compatibility to the older data.
[12/03-20:31] <Zacam-Work> Just like any other mod that was too cheap to do it the right way the first time.
12/03-20:44] <@Goober5000> As far as I'm concerned, the default, no-change behavior should be the same as retail. If that's the case, we'll fix it. If, instead, SCP worked differently for a long period of time but now works as it did in retail, well, that's unfortunate but not our problem
[12/03-20:44] <@Goober5000> second sentence should read "if that's not the case"
[12/03-22:20] <Zacam-Away> FYI, the TBP adv.ships.tbl defines the shields for the Aurora as "20" not "0"
[12/03-22:21] <Zacam-Away> sorry, ships-adv.tbl, whatever the **** that was supposed to be for.
[12/03-22:21] <Zacam-Away> and in ships.tbl, the Aurora also has a value of "20", not "0"
[12/03-22:22] <Zacam-Away> Per TBL pulled from TBP Release DVD, b5_core_3_4.vp
[12/03-22:22] <Zacam-Away> Content flaw.
Yea that last one was a flaw. The flaw was Zacam looking at a table the engine doesn't even parse. And note Goobers exact words on anything that breaks anything but retail. It's not their problem.
Same kind of things are happening in mantis. Funny thing is most of those bugs were filed for Diaspora.
I think this is all coming from the push to get under 100 bugs for 3.6.16. It's getting out of hand with the try to fix as many as possible without really looking at the underlying causes. File a ticket for a null vec3d caused by bad data and get a response of closed due to bad data. Null vec3d not fixed so while the issue may not be able to happen again for that one circumstance it the data still isn't being validated to prevent other circumstances from causing it. BTW that one was a Diaspora bug but they *****ed none the less about bad TBP data.
-
I hope other mods, Diaspora in this case, don't suffer for vanilla TBP's well known content problems. :blah:
That said, it sounds like the SCP is moving back to retail behavior they didn't intend on deviating from in the first place. That makes me wonder what else might change in the future.
-
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.
-
FUBAR's IRC log contains cherry-picked quotes. The comment log for Mantis #2346 (http://scp.indiegames.us/mantis/view.php?id=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.
-
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's IRC log contains cherry-picked quotes. The comment log for Mantis #2346 (http://scp.indiegames.us/mantis/view.php?id=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.
-
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?
-
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 (http://svn.icculus.org/fs2open?limit_changes=100&view=rev&revision=9397) :D
(also see this (http://scp.indiegames.us/mantis/view.php?id=2747) if you've got a mantis account)
-
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.
-
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 ;)
-
But it's a moot point anyway, as a fix to keep shields = 0 working has been committed (http://svn.icculus.org/fs2open?limit_changes=100&view=rev&revision=9397) :D
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?
-
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. :)
-
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 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.
-
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.
-
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.
-
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. (http://pastebin.com/M75RpHRs)