|
2006-12-13 02:12
|
Luxor-rings.jpg (81,256 bytes) |
|
|
This is not a docking problem. It's a positioning and/or AI problem. |
|
|
Incidentally, do the mediaVPs replace the Typhon and/or Ganymede models? |
|
|
I just looked through the media VPs that I'm using - I don't see any model replacements for the ship or the ring. As I said, I also disabled the mediavps entirely and just ran FSOpen with no options except Derelict enabled and the problem still appears. Perhaps a positioning problem with the build itself and its interpretation of the positions of the ring and the ship? |
|
|
This is VERY VERY WEIRD ... + If I use mediavps (3.6.8.zeta + alpha patches or even the new DaBrain's WIP edition) the Ganymede is fine ("With Mediavps.jpg"). Please MP-Ryan CHECK this case as it seems you suffer it all the time. + If I use no mediavps I get the error. ("Without Mediavps.jpg") I've used fsopen 3.6.9 (latest official version) and Taylor's XT 0419. I've taken a look to my data and vps structure and, as MP-Ryan says, there aren't any Ganymede or Typhon replacement in 3.6.8.zetas. BUT 3.6.8. mv_models.vp has a drydock2t-01.ibx for Ganymede which at least in my computer is different from the ibx I've got in FS2\Data\cache, (checked with Windiff). But the ibx doesn't seem to matter. Copying, modifying or deleting them to Derelict\Data\Cache, (the highest priority place), I've forced the use of one or the other, and I've also regenerated another new one but it doesn't matter: + All of them are valid ibx, the game doesn't change them whenever they find any of them. (I've checked this looking at the archive time and date after every FS2 run). + With any of them, mediavps+retail get a good mission; retail vps get a bad mission. (Of course if I use DaBrain WIP mediavps, the ibx is regenerated because they have a DIFFERENT drydock) Also, look at the screenshots, it seems that my starting point and/or other ship starting points are different between runs ... (Although I don't know if this is supposed to happen). |
|
2007-05-05 14:39
|
With MediaVPs.jpg (142,050 bytes) |
|
2007-05-05 14:39
|
Without MediaVPs.jpg (80,913 bytes) |
|
|
Well I've done a brute force test with Derelict and Mediavps. I've made a mediavpstest folder, (loaded from derelict with secondarylist instead of normal mediavps), and I've started copying vps from mediavps 3.6.8.zeta till I've found which one fixes the problem. Then I've deleted ALL of them but that file to be sure it is just one file which fixes it. And the winner is ... ** mv_models.vp ** There's something inside it which fixes the issue AND IT ISN'T the drydock2t-01.ibx. I've retested extracting it to Derelict\Data\Cache, not using mv_models.vp, but, as said before, the Ganymede Ring is misplaced and the ibx is not regenerated. (Well I feel I can't test anything more, some more expert knowledge is needed). |
|
|
Well I've done another brute force test to narrow this bug down. I've extracted mediavps 3.6.8. zeta mv_models contents to an auxiliary folder. In this way I can partially load its contents by renaming/deleting the folders. And the winner is .... mv_models > models folder. If I load these contents the bug is gone. BUT the folder doesn't have any pof for Ganymede (drydock2t-01) or Typhon (capital03). ?????? |
|
|
It's probably a combination of the Typhon and the Ganymede. One combination blocks the fighterbays, while another doesn't. You might be getting inconsistent results because the shuttle might choose one fighterbay one time you run the mission, and the other fighterbay another time. Just take a look at the models in FRED, and let us know which combination blocks one or both fighterbays. |
|
|
In FRED the same thing happens. I upload two screenshots: + Derelict + retail FS2 vps: You have the bug ("FRED Without models.jpg") + Derelict + just model folder from mv_models.vp from Media vps 3.6.8.zeta + retail FS2 vps: You don't have the bug ("FRED With models.jpg"). But Goober, the real problem is that the Ganymede ring is sometimes rotated, despite the docking point the shuttle selects (compare the "with" and "without" screenshots). An as previously said, the funniest and weirdest issue is that the model folder which "fixes" the bug hasn't got any of the conflictive models. So I'm always loading retail (sparky_fs2.vp) Ganymede and Typhon. As I'm no FREDer at all, I'm also uploading the conflictive mission (although I suppose EVERYONE has derelict). In this mission, Derelict vps are really needed as it has a GTFf Saphaf class ship inside. |
|
2007-05-09 00:32
|
FRED Without models.jpg (148,083 bytes) |
|
2007-05-09 00:33
|
FRED With models.jpg (147,643 bytes) |
|
2007-05-09 00:38
|
|
|
|
Well, I'VE GOT IT (and now I see all the time I've wasted, just because I don't use FRED really well :-( ). It seems it isn't a code bug but a model + mission bug. By successive models content halving, I've detected the model that "fixes" the bug. And the winner is ... ** Science01.pof (GTSC Faustus) ** Then I've opened the mission and there's only one Faustus in it: "Impresari". Then, and only then, (how stupid I've been!), within FRED, I've noticed that Luxor Ring is docked with Impresari. As the second model is different it is affecting the position of the Luxor Ring too. Luxor Ring has an arrival Cue of false and Impresari an arrival Cue of true (both arrive from Hyperspace). So it seems that the primary ship is Impresari, which maintains its position and Luxor Ring is rotated because of the different docking point info within the HTL science01.pof. I've changed the arrival Cues (true for Luxor ring and false for Impresari) and then the Impresari is rotated instead of the Luxor Ring. I upload the fixed mission. So unless someone more expert says something different it seems this isn't a code bug. OTOH: Should we fix the GTSC Faustus? We have two clear incompatible models. But fixing HTL science01.pof to make it behave exactly like retail, can break some recent missions, as an obvious example: "Rites of Passage" in Derelict. If you don't fix it, it can break some older "retail" missions or MODs. A good discussion topic for the SCP team. |
|
2007-05-09 20:58
|
|
|
|
Wow. Great work. :) That's SCP-quality debugging right there. :D This looks like a job for two people. First, Blaise Russel should update the missions. Second, DaBrain should update the mediaVPs with the correct model. Assigning to DaBrain for now. |
|
|
As this doesn't seem to have an effect on the retail missions, I tend to keep the 'error'. Especially when fixing it means breaking new missions. Still I'm not sure about this one. |
|
|
The only thing that needs to be changed is that the HTL model's dockpoint should be rotated to match the retail model's dockpoint. As it is now, it breaks old missions. :p |
|
|
Just my opinion, after a deeper thought about it: + Backwards compatibility is the main guideline in SCP enhacements. So fix the Faustus. In this way, I agree with Goober even if there isn't any other mission through the universe which uses GTSC Faustus dock point. (And even when fixing this issue means "breaking" a hit MOD like Derelict). If you start relaxing full backwards compatibility motto, it can be really dangerous, because, where do you stop? (OTOH, Derelict needs a new fresh release nevertheless. Even, I, who am not a FREDer, have fixed some small issues in several missions) |
|
|
Acutally fixing it doesn't make sense to me, because it isn't used in the campaign, but I'll fix it anyway. |
|
|
So, has the Faustus model been repaired and updated into the 3.6.8 mv_models alpha patch? |
|
|
There's a huge discussion about the issue in this thread:http://www.hard-light.net/forums/index.php/topic,50544.0.html mv_models.vp faustus is supposed to fix the problem. No extra patch or update needed. If, like MP-Ryan says, he still suffers the issue with a "perfect" mod and mediavps installation, then there's some other hidden bug too. But I cannot replicate it. Please provide more info. |
|
|
I just retested and noted that with 3.6.9 Final and the 3.6.10 XT build from Oct 28, the bug no longer appears if the 3.6.8zeta + patch mediavps are installed corretly. I can't re-confirm the original issue with 3.6.9RC7 as I don't have that build. Note that my mediavps content has not changed since the original bug submission. So for the moment this can be deemed repaired. |
|
|
I like problems that magically get fixed, but I'll keep this one open till the next MediaVP version is out or this is confirm by someone else. |
|
|
Mediavps 3.6.10 (Beta) Faustus is like 3.6.8. one It fixes the problem so it is "incompatible" if compared with retail Faustus. |
|
|
So let me get this, the retail faustus is broken, Blaise made missions which rely on it, and now the latest Faustus about to go in the 3.6.10 set is fixed, which will break his missions that have been around for quite some time? So either we fix those missions, or any other missions that use it also have to work around an intentionally broken model? What about including a second Faustus that's fixed but with a different name, that still shows up the same in game? Like Faustus#fixed? |
|
|
>>> So let me get this, the retail faustus is broken, Blaise made missions which rely on it, and now the latest Faustus about to go in the 3.6.10 set is fixed, which will break his missions that have been around for quite some time? AFAIK retail Faustus is OK. It's just that HLT Faustus has a docking point rotated 90º over its own axis. >>> So either we fix those missions, or any other missions that use it also have to work around an intentionally broken model? I think that, because of backwards compatibility, Mediavp HTL Faustus should behave exactly like retail one. Of course, then some "new" missions, like Rites of Passage, can become broken and unplayable. But this situation is quite unlikely and the fix is very easy. (In this same report there's a fixed "Rites of Passage"). >>> What about including a second Faustus that's fixed but with a different name, that still shows up the same in game? Like Faustus#fixed? Because, there's going to be so few broken missions, (I bet no-one rather than Derelict one), making Mediavp contain two models, (one canon retail-compatible and other HTL-compatible), is not a good idea. |
|
|
Well, Zacam has stated that the Faustus in the internal Gamma MediaVPs should be correct and he doesn't intend to change it. |
|
|
I hope so. It worked with the retail Faustus, so that doesn't need to be changed. And the HTL models need to be exactly backwards compatible with retail models anyway. |
|
|
>>> I hope so. It worked with the retail Faustus, so that doesn't need to be changed. Nope, it was the other way round (in Rites of Passage, I mean). It works with Mediavps Faustus, not with retail Faustus. The mission was made with a "bugged" model so it is incompatible with the original canon one. >>> And the HTL models need to be exactly backwards compatible with retail models anyway. I absolutely agree with you. |
|
|
The retail faustus has its dockpoints aligned vertically, the current MVP one has them aligned horizontally. From what I gather here, we should leave it horizontal - as missions have been designed or updated since retail that rely on this being the case. The alignment of the points will not affect older or retail missions except that ships docking with these small ship dockpoints will just turn 90° before docking.(The ports look like they're supposed to just be for transports anyway - not really to dock it to big ships/stations as has happened here) This type of 'problem' would present more of an actual problem if it _were_ fixed. Far more than it can do if just left as is. :) |
|
|
VA, I disagree. Backwards compatibility should be THE golden rule, even if it breaks new missions built on a "bugged" model like this one. The other way round can be seriously dangerous. When or where do you stop changing retail behaviour because of no good reason (ie. a retail bug)? |
|
|
Yeah, I think it should match retail as well. |
|
|
I strongly disagree with VA. It should match retail. We need to have one universal benchmark, and retail is best suited to be that benchmark. We have had several instances where a bug was introduced in SCP, people made missions taking that bug into account, and then the bug was fixed. People were inconvenienced by the need to release patches, but they understood the reason. This situation is no different. |
|
|
Nevermind that it was re-oriented to match the docking points to the texture of the docking rings then, eh? Or, here is an idea, put in both docking points, and anything that wants to use the vertical wrong ones can specifically apply to $Dock With to that dock point. Or, if the Gaynamde is being rotatd instead of the faustus (stupid error to have) rotate the faustus in the mission. Quality models means that when some one see's a docking ring, they expect that things will dock there. THAT is the Golden Rule. And on Retail and compatibility: Can any one cite me a single FS1 or FS2 campaign mission where something is docked with a faustus and if so: Does the current horizontal dock point model break it? If there are, and it does not, then I see no reason to change anything about the model for a mod. |
|
|
If someone were to try to develop a retail compatible mission that used the faustus, how could they go about supporting both the retail and mediavp faustus? The only way I can see this being acceptable is if the retail faustus can't be used as it is. Then, without the mediavps, you could never dock with a faustus. If that's the case, then docking with a faustus pretty much necessitates having a working faustus model, either including it yourself or using the mediavps. But if the retail one can be used as it is, then changing that to match the texture doesn't sound right. |
|
|
"Nevermind that it was re-oriented to match the docking points to the texture of the docking rings then, eh?" What do you mean? If you mean the center of the dockpoint was moved to the center of the docking circle as seen on the texture, then that's fine. An offset of just a meter or two is not going to have a substantial impact; the mediaVP models probably differ in size by the retail models by a meter or two anyway. The problem here is the *orientation* of the dockpoint. A change in 90 degrees for the orientation makes a *huge* difference, as evidenced by the Derelict mission. "Or, here is an idea, put in both docking points, and anything that wants to use the vertical wrong ones can specifically apply to $Dock With to that dock point." If the retail dockpoints are not the default, then that doesn't solve the problem. "And on Retail and compatibility: Can any one cite me a single FS1 or FS2 campaign mission where something is docked with a faustus and if so: Does the current horizontal dock point model break it?" A simple grep can provide the answer to this, if you're so inclined. But off the top of my head, I can think of two: Running the Gauntlet, where the transports bring the GTSC Rosetta's scientists to Deneb; and On the Run, where a Satis transport tows the GTSC Ratna. In the latter case, the Satis is aligned to dock properly with the Faustus at the beginning of the mission. Requiring it to back up, turn 90 degrees, and re-approach screws up the timing. EDIT: The Big Bang, where the GTSC Asimov is evacuated, is another mission where transports dock to a Faustus, and where timing could make a difference. |
|
|
Wow, strong response about a dockpoint alignment of all things. o_O Goob, I've looked up that mission in the wiki, and in those circumstances yeah - we will have to rotate the dockpoint back, or else the mission critical Satis will be towing the Ratna in a bizzare and stupid looking manner. As much as I'd really rather not massively break a Derelict mission simply because of an alignment, ST is retail and so takes compatability preceedence over Derelict. (It would be really really awkward for ST:R to accomodate for as well as you'd need to include a separate retail-aligned POF of the faustus, and splitting off from MVP content for that would be very bad.) In a last ditch attempt to resolve it so that neither well known mission is broken - can someone with ST look up which dockport the satis uses in 'On the Run'? The Ganymede in the derelict mission appears to use the Faustus' portside dockpoint. If the Satis uses the portside one as well then we're stuck and will have to break the Derelict mission rather badly, but if it uses the starboard one then we could rotate just the starboard one back to retail, and leave the portside one rotated as a concession to Derelict. :) There shouldn't be any other circumstances other than towing or huge ship/station docking that will be in any way affected by a rotated dockpoint, as from what I have observed in docking behaviours is that the rotation will occur _during_ the final approach, where it cannot affect timings. *sigh* Galemp, why did you rotate the dockpoints in the first place. :p |
|
|
Oh, oh oh! I was missing something. Goob - I think Galemp intentionally reorientated the dockpoint for exactly that mission in ST:R. Have a look here: The red arrow indicates the direction in which a Satis would point when docked with this port (same thing applies on the other side). http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/FaustusDock_Retail.jpg http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/FaustusDock_MVP.jpg So, by 'fixing' the docking ports of the faustus to match retail, we would actually break BOTH missions - either actually in the Derelict mission case or aesthetically in the ST mission's case. |
|
|
Actually, Derelict was originally created for retail, so that argument doesn't apply. ;) Derelict SCP had better behave the same way, otherwise BR broke one of the cardinal rules of campaign design -- always test the campaign without the mediaVPs present. Incidentally, regarding the ST:R mission that originally used the rotated dockpoint -- I ended up creating a brand new dockpoint because I found a solution that suited the mission much better than rotating the existing dockpoint did. (And the FSPort mediaVP makes allowances for the additional dockpoint.) As for your "last ditch" attempt -- ST uses the starboard dockpoint. But really, that shouldn't make a difference. Retail compatibility must be maintained. And as for On the Run -- I tested it, and yes, there is a 20+ second difference between the time the Satis docks at the various orientations. |
|
|
In code yes I'd agree, but in the extremely localised media content problem cases like this one I think we should look at a bit differently and weigh up the alternatives, rather than doing the 'retail wins by default' thing we do everywhere else. ;) First thing is: No one will be trying to run ST with MVPs unless it's in ST:R, which as Goob has said has a separate model already anyway. Such an attempt would have hundreds of other errors long before the extra 20 seconds of the trip caused issues, so we don't need to worry about breaking MVP compatability with that mission. It was broken between ST and FS2 already. ;) The MVPs are designed to be compatible with FS2's main campaign and the existing campaigns made for the FSO and pre-FSO engines, so those are the ones we're concerned with. Therefore, if we leave it as is (ie, different from retail, both docks horizontal): Advantage: -> The Derelict SCP mission will work correctly with the MVPs with no Derelict SCP patch nessecary. Disadvantage: -> Of all the campaigns currently released (if they're not this could easily be picked up and corrected during testing so we can ignore them as an issue) there are two scenarios that could cause problems: 1) A large ship or station being pre-docked to a faustus (not the other way around) with retail dockpoints. Here the current faustus will rotate the big ship or station in a bizzare way in the exact opposite way to what happened with the Derelict mission. Then it may or not be a mission critical object. 2) Missions revolving around a critical element in the form of towing a faustus somewhere. In these missions the docked ships will in all likelyhood look much better while moving (ie, not like a giant cancer sticking out), BUT if they need to turn around before they start moving it will add around 10-20 seconds to the whole trip, which may then in some very very rare cases break the mission for balance reasons. So, in weighing that up - going with retail alignment we DEFINITELY break that mission in Derelict SCP, which is a very widespread and well known campaign, whereas if we leave it as is we face only hypothetical problems that in all likelyhood don't exist or don't in any way break a mission in other currently released campaigns. I definitely say we DON'T break an entire Derelict mission (requiring a patch) because of ghost problems. ;) As far as we know, no retail or retail based campaign mission relies on the faustus' docking point alignment except Derelict, so I'm happy to make a concession for it here. Obviously though, this shouldn't happen at all - and I'll be ensuring nothing like it does in the future with all MVP content submissions. :) |
|
|
People seem to be under the mistaken impression that Silent Threat is bug-ridden to the point of uselessness. Not at all. There was only one mission bug (the red-alert mission, which has been fixed in the Port distribution) and one design fault (the battle against the Hades). I don't know where you got the idea that running ST with the MVPs will cause "hundreds of errors". Anyway. Your argument about imposing an undue patch burden doesn't hold water. If Hades Combine / FSMods / Blaise Russel / whoever had no problem patching Derelict SCP *in the first place* to work around the MVP bug, then they should have no problem undoing that patch now that the MVPs are fixed. Two wrongs don't make a right. Also, remember reading through that long laundry list of changes in retail behavior that mission makers must now account for if they design a campaign for SCP and/or mediaVPs? You don't, because THERE ISN'T ONE. We can't afford to make exceptions because then everybody will want to make their own favorite exception, and they'll quickly grow too numerous to keep track of. We stick to retail behavior, period. What works without the SCP should also work with it. What works without the mediaVPs should work with them, and vice versa. Both the mediaVPs and the SCP (assuming a campaign doesn't use new SCP features) are optional. Always have been, always should be. |
|
|
Nono - my point about running ST is not that the missions were full of bugs or anything (remember - I've not even played it yet so how could I fairly judge that?) but that it's an expansion to FS1. To my knowledge you can't simply dump ST VPs into FS2 retail and expect it to work any more than you can dump FS1 VPs into it. Therefore the only way people could possibly play ST with MVP content is if they were running ST:R, because otherwise it just wouldn't work. Is this not the case? Anyway, I do not at all agree with breaking an existing mission and requiring a patch for this sort of tiny trivial change (and I still can't ever see it affecting much else), but if you feel this strongly about it then I suppose that's what we'll do. :\ Please keep in mind though that no matter how much effort the FSU puts into maintaining 100% retail compatability (and we put in a huge amount), it will always behave differently in _some_ way to retail. |
|
|
Well, Silent Threat is included with the Port. You can play the Port on retail FS2, on SCP without mediaVPs, and on SCP with mediaVPs. It works in all three situations. Keep in mind that modifying the Faustus required a "tiny trivial change" to Derelict in the first place, and this is simply undoing that change. ;) But I do appreciate your being willing to restore the old version. I will contact Turey ASAP so that the modification can be added to the Installer. And I understand that it's not feasible to keep SCP 100% in synch with retail -- but the point is that we make every effort to do so. If we see an anomaly, we fix it. (Which reminds me that I'm overdue in adding an ai_profiles option on another bug. I'll do that this weekend.) |
|
|
Ah - if the fixed mission is to be included in the installer that'd go a long way to solving it more universally, thanks. :) Anyway I've updated the model in our SVN, so I think this bug can be resolved? And wait, so a full version of ST has been sitting under my nose since I d/led the Port?! I've been wanting to play it for ages, and now I have to resist till ST:R comes out! Blah! :p |
|
|
About a fixed mission. You have a fixed mission in this very same thread. And it works with both the bugged and the original model. (Instead of a Ganymede docked to a Faustus, it has a Faustus docked to a Ganymede. Then, instead of the Ganymede, the Faustus is rotated depending on the used "version", which has no impact in the mission). |
|
|
Yup, that's how I was thinking of fixing it anyway. |
|
|
Yeah VA, the port of the original ST campaign has been around for well over a year, probably even since I've been around. You could have played it with 3.0.4 at any time :) |
|
|
Okay, I've emailed Turey the patch, so hopefully we can put this to bed. (BTW, in addition to the Impresari dockpoint mixup, the patch also fixes the subsystem repair thresholds in a few missions.) Closing as fixed. |
- Anonymous
