Search results

There seems to be an issue with using rotated fonts (i.e. calling oapiCreateFont with nonzero orientation). In SSU, the HUD drawing function creates and then releases a font which is rotated to match the shuttle's bank angle (see code below). At some point after landing, during rollout, the HUD...

If we're going to be breaking scenarios because the mesh is changing, I think we should just have one release with the final version of the mesh.

I though that since we have a new mesh we would include it in the release, but I'm fine with releasing a version using the old (Rev. 1462) mesh, and then releasing a later version with the new mesh. One question: will we have to modify scenarios (attachment points, etc.) to handle the Rev. 1462...

The animations need to be updated to use the new mesh. And the remaining mesh issues have to be fixed. I'm guessing it'll take a couple of weeks at least.

A few comments on the new mesh: It doesn't seem to work using the default graphics client; it only works using the DX9 client. The FWD PLBD latch group seems to be missing. The star tracker doors are missing (is this related to the other star tracker issues?) Also, the branch you created...

Can you create a new branch and check the new mesh in? That way the rest of use can have a look. Also, if the animations need to be changed because of the resizing, we can start on that while you fix the distortions (I'm assuming fixing the distortions won't affect the animations; correct me if...

OK, I changed the branch to use the Rev. 1462 mesh.

Can this be fixed by going back to an even older mesh?

I've created a new branch (Mesh-Rev1463), which contains the latest revision (rev. 1814) after undoing the changes in Rev. 1601. I've only done minimal (very minimal) testing, but the results are surprisingly good. Can someone take a look and see if the mesh in this branch needs any changes?

There's been a lot of discusson recently about who is responsible for this situation, and I don't think it's useful. We all saw the changes DaveS was making to the mesh when he checked them in. It would have been nice if someone pointed out the issues with the mesh at the time, instead of months...

Can you reproduce this using the built-in graphics client (orbiter.exe)? I can reproduce the issue using the DX9 client, but not the built-in graphics client.

I've checked in revised code, along with VS 2013 solution & project files.

It looks like math.h has changed in VS 2013 to add some new functions (round, acosh and asinh) which were not in previous versions. Since there are still people using VS 2010, I think the best solution is to rename these functions to avoid conflicting with the math.h names.

Here's the description from the DPS dictionary, which is a bit clearer: So for most of entry, the tape shows Mach, and the display below the tape shows KEAS. For M < 0.9, the tape shows KEAS, and the display below the tape shows the mach number.

I think that's correct. The MEDS displays are drawn by the MDU, not the IDP. The IDP draws the GPC displays. (Hopefully someone will correct me if I'm wrong)

I also vote for ditching the Orbitersim MFDs, as long as we have a full implementation of the ADI displays (including the 8-ball). I think we need either Surface MFD or the MEDS equivalent.

I'm not sure if this is the right time, but at some point I'd like to move all the painting code from CRT MFD to the MDU class. CRT MFD would essentially be a wrapper which passes button presses and redraw requests from Orbitersim to the MDU.

If the only thing needs to be added is the mass (and the Centaur plumbing doesn't affect the rest of the simulation), the simplest idea might be to just add a mission file entry specifying the additional mass and the CoG of the added plumbing. In theory, we could have multiple entries to...

The ORBIT TGT software calculates the rendezvous burns. In SSU, the name of the target vessel is specified (in the scenario file), and it uses the orbiter and target state vectors to calculate the rendezvous burns. In real life, Mission Control uplinks the state vectors (and tracking data from...

What Urwumpe's suggesting (I think) is to update the scenarios in the trunk to handle the changes in the mps branch, but do the release without including the mps branch. Then, once the mps branch code is added to the trunk, the existing scenarios can be used without further changes.