Search results

I don't think there's a big difference between opening the scenario file and opening a file in the Doc folder, but it might be less confusing for some people to put this in the Doc folder. DaveS, can you add the scenario guide?

I think it might be a better idea to add this information in the scenario description, instead of putting it in a separate file. I'm thinking the description should look something like this (using made up numbers): STS-120: Scenario begins 10 minutes before launch. This mission delivered the...

Can you explain a bit more what you want to see in the manual?

I think we should be ready for a release; the new mesh branch has been merged in, and I don't think there any any outstanding changes required. I was thinking we could spend a few days testing the latest version of the code to make sure there aren't any bugs, and then we should be able to have...

I've merged the new mesh branch into the trunk.

The D3D9 config file (Config/GC/SpaceShuttleUltra.cfg) needs to be updated to work with the new mesh. At the moment, the exterior of the shuttle is reflective, which looks really weird.

Is there anything that still needs to be fixed regarding the new mesh? If not, I'll merge the new mesh branch into the trunk tomorrow.

The number in the message indicates the rotation error, so you're off by about 90 degrees. You should be able to use the grapple target to get the wrist roll correct. Like DaveS said, it looks like there's a problem with the settings for that particular grapple fixture, which is why you're...

There's an error in the wrist roll angle. That's where the "Unable to grapple: Rotation Error: 90.39" comes from.

See this thread to fix the afxres problem. The other errors come from the libUltraTests project. This project only runs unit tests, so you don't actually need to compile it. If you want to run the unit tests, there are instructions in Doc/Space Shuttle Ultra/Compiling SSU.txt

Is anyone working on updating the various textures to work with the new mesh? As thing stand, only the default Orbiter_blank.dds works.

I've checked in the new mesh from Donamy to the NewOrbiter-FromTrunk branch. I've also checked fixes for all the animations. The new mesh also includes both versions of the vertical stabilizer, so a "HasDragChute" option has been added to the mission file.

I don't think we're replacing any textures in code. I think Donamy wants to display the cavities in the texture only for the moment, and in a later revision the mesh can be edited to include the cavities.

Wrong. The number keeps changing because it's generating a new (random) number each timestep. This makes debugging easier, because it's easy to see when the object moves out of the RTL range (the numbers stop updating).

The debug string has nothing to do with the GOX vent offset; it just indicates the state of the Ready-To-Latch flag. I'll go through the code and get rid of all the debug strings.

From Doc/3DModel.pdf: According to the doc, using 0x00000002 as the flag means 'Do not render this group'.

How close are we to a release? I had the impression we wanted to create a new release soon, without adding new features. In that case, I'm not sure this is the best time to be rewriting the SimpleGPCSystem.

Still doesn't work. The last line in Orbiter.log is (SpaceShuttleUltra) [INFO] Loading MDM configuration Since I can reproduce the issue, I'll try debugging the code and see what's happening. ---------- Post added at 01:25 PM ---------- Previous post was at 01:02 PM ---------- I think I...

Orbitersim crashes when loading any SSU scenario. I think it's related to the MDM code; everything works if I use the previous revision.

Columbia had the SILTS pod both before and after the drag chute was added, so we'll actually need 4 meshes; normal, without drag chute, normal with SILTS pod and SILTS pod without drag chute. If this is possible, it might be simpler to have a single vertical stabilizer mesh and additional...