Space Shuttle Ultra 1.25 Revision B development
- Thread starter Urwumpe
- Start date
Actually not. My plan is to replace all the HRSI tiles since they're not accurate. As you can see, the real ones have no visible tile ID labels on them. The "rough" appearance of the current ones are supposed to be the ID labels but due to the resolution, they just make the tiles look poor.
Here's the source for tile texture 2: http://www-pao.ksc.nasa.gov/kscpao/images/large/2010-2831.jpg
I'm focusing on the contemporary versions of the orbiters for now. I have hit a bit of a dead end for Columbia, as I haven't found any good photos that I could use to make new upper wings chine textures from.
Is there any way you could use this photo of Columbia to make a usable texture?
If you can, put it in a layered psd file and send it my way.
---------- Post added 03-05-13 at 12:41 AM ---------- Previous post was 03-04-13 at 09:55 PM ----------
Here's a shot of the progress so far:
Still have some areas on the FRCS module, then I have the HRSI on the aft compartment sidewalls to deal with. Then I have to add the Columbia/Challenger specific T0 plates. Unlike the later orbiters, Columbia and Challenger's T0 plates were never covered with FRSI.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
How likely is a :hail: pre-MEDS Virtual Cockpit for 2013?
If we can't get two kinds of virtual cockpits into the same DLL (there are many good reasons why it could fail), we can still create two different branches of SSU or use conditional compilation for having different modules in the end.
If we can't get two kinds of virtual cockpits into the same DLL (there are many good reasons why it could fail), we can still create two different branches of SSU or use conditional compilation for having different modules in the end.
I have an important question for you: How should we handle drag chute/no drag chute? After alot of research, I have come to the conclusion that the drag chute compartment was not a "bolt-on" modification to the orbiter vertical tail as I had initially thought.
It required a reshaping of the lower fairing of the vertical tail in order to be fitted. This means for us, two different vertical tail meshes in order to be accurate.
It required a reshaping of the lower fairing of the vertical tail in order to be fitted. This means for us, two different vertical tail meshes in order to be accurate.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Tough question. While such tail meshes would be no problem to integrate and change during vessel creation, it would mean a lot of extra code being executed during the run time.
But I think it is easier then, than changing the full orbiter mesh and have a new set of animation definitions there.
Maybe we can solve such and similar problems by having an abstraction layer between the actual animation and the animation code, which handles which animations are really present and in which mesh of the visual they are present.
Last edited by a moderator:
Donamy
Addon Developer
When will we get a working release, that is locked ? I think this is more important than new changes. I get so many private messages where people are frustrated by not being able to use SSU, because it is too hard to acquire. I developed umpteen STS mission addons that are unusable in Orbiter because they don't work anymore. I can't even use sourceforge anymore to keep up with the ittybitty changes by DaveS everyother day. No other addon has this problem. I think it is time to do something about it. If no one else feels this way, I guess it will just stay the same.
Sorry for the rant, but I've done alot of work on this, as you all have too. I just wish it was usable by everyone. nough said.
Sorry for the rant, but I've done alot of work on this, as you all have too. I just wish it was usable by everyone. nough said.
Donamy, I'm sorry that you feel this way but SSU will be in this mode for long time to come. SSU is alpha software and will be until all systems have been implemented properly. And given just how complex the shuttle really is, this will take a long time.
A good example is the NASSP/Project Apollo add-on. They have been developing their add-on for nearly a decade and they're still not ready for a public release! They do periodic module releases, but you still have to use CVS to get the core stuff (meshes, configs, textures etc).
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Yes, I feel the same about the situation. It is too much featuritis and too little done...
Good news, I have my new notebook now and can resume SSU development soon. They announced a small snow storm for northern Germany for this weekend, should be more than enough time for me to configure it for some SSU work. :lol:
I will not implement ANY new features, before we have a stable beta release done. ANY. I know that the recent small changes had been done for testing, and I appreciate it, but we need to get ahead.
I think ODS and SSME stow are features that should get finished for release. The autopilot errors because of MECOCalc are annoying, but not critical now, they could wait for the second-next release.
---------- Post added at 08:50 PM ---------- Previous post was at 08:45 PM ----------
But we did not even get a stable beta release for more than a year. We can't do all subsystems in 5 years at the current pace, but we should at least have some more stable releases. Without, it will get harder and harder to have anything released at all.
How are we to calculate the MECO velocities then? That is a critical part of mission creation. As it is now, we have to burn alot of OMS propellant to correct for the serious miscalculations of MECOCalc.
---------- Post added at 08:53 PM ---------- Previous post was at 08:51 PM ----------
Once again, see NASSP. No stable release there either, just the occasional module release.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Yes, but since we have MANY missing subsystems, this is not a show stopper.
And they have IMHO the same problem. But for us it is worse, since we also have people who would like to release add-ons for our add-on.
I think those who creating add-ons for SSU would like to include the launch and start there on their missions.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
We have launch and start. We just have inaccuracies there.
Fixing MECOCalc would be annoying since MFC is obsolete now... we would need to start again. And I wanted to use Java and Netbeans RCP for that, since it means we could have a mission editor framework, that we can extend with modules overtime and permit additional modules for this editor to be programmed, if needed.
Last edited:
Yes, but the launch is key to a successful rendezvous. NASA usually refers to it as the "first rendezvous maneuver". For HST missions an accurate launch is of the uttermost importance since every drop of OMS propellant is already budgeted for (usually 50% for nominal rendezvous and 50% for de-orbit). Not much room for off nominal MECOs that overshoot their targets by 50-80 km!
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Yes. You could of course reduce the velocity target by the error value.
But a full correction to the needed accuracy would take a lot more work - how long should we wait?
