Thanks. Noticed a bug with the lights, they don't turn off when the sun rises.The first vector seems to correspond to the offset of the hardstand mesh. IIRC, the lights were part of the hardstand mesh, so I used MeshWizard to get the positions and then added the offset.
This is just a suggestion, nothing else: How about configurable ET types in the mission file(s)? Currently we're flying SLWTs for all missions, when it would be appropriate to fly a LWT or a SWT.
The first five flights used the initial SWT batch. STS-6 was the first flight to use a tank from the second batch which was LWTs. STS-7 used the sixth and last SWT. From that point on until the introduction of the SLWT on STS-91, all flights used LWTs.Was planned to do...just like also supporting the early tanks of STS-1 to STS-3
Somebody just needs to code and document it... I am sure we have already something there, but I don't know where it is left.
Well, the type of ET has a direct impact on the mission. The whole reason for initiating development of the SLWT was that ISS got moved from its optimal 28.5° inclination orbit to a suboptimal 51.6° inclination orbit.I think there are much more worthwhile things to be finished, before thinking about what ET's flew. How about manuevering the SSME's into orbit stow position, radar rendezvous, or KU tracking ? JMHO
Here's a screenshot of the bug(the red color is just to make the lights stand out better in daylight):Thanks. Noticed a bug with the lights, they don't turn off when the sun rises.
The ET needs to be resized. A while ago I resized the ET to fit the new pad not knowing that the vertical offset was incorrect. Once I'm done with the Centaur mods to the orbiter, I'll deal with the ET. That's just a simple rescaling.Should the stack be raised or the beanie cap lowered ? It doesn't quite cover the LOX vent in your screen shot.
The reason for the different versions is that the FSS/RSS was different back in in the mid-80's. The FSS and RSS didn't have the large OWP Curtain Walls they now have. Those were added sometime in 1986.I just had a look at the pad code, and I noticed that a new project (Pad1985) has been created. Is there a reason why we have two distinct sets of code for the different pads? If the only issue is animation/mesh creation, we can have a config file line to specify the mesh version.
---------- Post added 04-21-11 at 12:05 AM ---------- Previous post was 04-20-11 at 10:53 PM ----------
BTW, the pad light bug is fixed; I'll check the code in once I know what's happening with the different Pad projects.
No. It's just that the 1985 code removes the OWP animations while adding another (RBUS). So it isn't just the coordinates that's different, it's the animations themselves along with the control dialog.Is there any actual difference in the code (apart from animation coordinates and mesh names)? I don't get why we need 2 different dlls, instead of one dll which can support both pad meshes.