OHM The Vessels of 2001 and 2010

[jedidia]

You do know that oapiEditMeshGroup does not perform the same function as MeshgroupTransform?

Using oapiEditMeshGroup and a custom transformation function to just roatete the vertices of the mesh is indeed the best way to duplicate the functionality of MeshgroupTransform in graphic clients. It's a proven and efficient way, implemented by UCGO, HlynkaCGs add-ons, and IMS. Plus, it also works flawlessly in inline, so you don't need a double implementation (in Inline, you just have to remember that the procedure has to be repeated when the vessels visuals are destroyed and recreated...)

 

[Urwumpe]

Using oapiEditMeshGroup and a custom transformation function to just roatete the vertices of the mesh is indeed the best way to duplicate the functionality of MeshgroupTransform in graphic clients. It's a proven and efficient way, implemented by UCGO, HlynkaCGs add-ons, and IMS. Plus, it also works flawlessly in inline, so you don't need a double implementation (in Inline, you just have to remember that the procedure has to be repeated when the vessels visuals are destroyed and recreated...)

It depends on the problem that you want to solve: I wouldn't do that in the current situation because it completely bursts the original requirements in bloat. It does not make the add-on module simpler - it makes it way more complicated - even if I add a lot of infrastructure code there that only helps in debugging the feature, my solution would be 30% of the SLOC that is advertised as "efficient" and "best solution to refactor away from attachments" here.

And as you say: You have to remember. Its not the solution of the least surprise at all. You have to handle everything yourself and not let the SDK do the work for you. And if you do something slightly wrong, you have in the worst case multiple specialist implementations of modified copy and paste code with the same bug.

Also the examples I have found in the forum deploy a completely bug-attractive way of defining rotations, despite better and proven functions already exist in the Orbiter API. That is NOT efficient at all. That's stupid.

Its a typical example of "If you are a hammer, every problem starts to look like a nail".

I can understand why IMS does need it. I would use it as well for such a problem to solve under the constraints of the add-on. But these constraints do not apply here.

 

[BenSisko]

We had hit a wall in the ballute animation and jettison. Face bailed us out. His help allowed us to release this add-on and we're grateful for his help. Enough said!

Ben

 

[Face]

It depends on the problem that you want to solve: I wouldn't do that in the current situation because it completely bursts the original requirements in bloat. It does not make the add-on module simpler - it makes it way more complicated - even if I add a lot of infrastructure code there that only helps in debugging the feature, my solution would be 30% of the SLOC that is advertised as "efficient" and "best solution to refactor away from attachments" here.

In the current situation, compared to the previous code, it made the addon much simpler to implement and maintain. If you think your solution is better, take a stab at the code for the Leonov and show it to underline your point.

Until then I disagree with you.

 

[Urwumpe]

Until then I disagree with you.

As if I ever had you agree with anything I do. But I will do it anyway.

 

[Face]

As if I ever had you agree with anything I do. But I will do it anyway.

Oh, I agreed several times with you. In this case however, especially because I never generalized it as you do, I disagree.

And I am sure the dev team for this addon will welcome your contribution, just as they welcomed mine.

 

[Urwumpe]

Oh, I agreed several times with you. In this case however, especially because I never generalized it as you do, I disagree.

Must have been some time in the past. Like last Tuesday or so. :lol:

And I am sure the dev team for this addon will welcome your contribution, just as they welcomed mine.

We will see :lol:

 

[gattispilot]

I will upload later today what we had from the 2006 version and what Face did. Like Ben said said we are grateful to Face to solved the issue.

 

[Urwumpe]

I will upload later today what we had from the 2006 version and what Face did. Like Ben said said we are grateful to Face to solved the issue.

Just grabbed the current one for reference and possible cleansheeting. Don't make it too much later, even I need some sleep. :lol:

EDIT: BTW, you have included Ummu.cfg in your add-on, was that intentional?

 

[gattispilot]

Just grabbed the current one for reference and possible cleansheeting. Don't make it too much later, even I need some sleep. :lol:

EDIT: BTW, you have included Ummu.cfg in your add-on, was that intentional?

Will it be later tonight as I am at work.

What did you mean the Ummu.cfg? I know we orginally were using Ummu 2.5 and the suits in the Leonov are based off that. But the 3.0 guy is different

 

[ATymeson]

Atymeson,
When in the Discovery, keypad "9/0" toggles the site to be opened, be it Airlock, Pad A, Pad B, Pad C, or the Pod Bay workstation. Make sure you've selected the Airlock by first toggling "9/0". Airlock should be indicated in the annunciator at the upper left of your screen. Keypad "1/2" selects the crewmember for EVA and pressing "`" would release the UMmu in the airlock. If "Work Station selected" appears in the annunciator then the UMmu will be released in front of HAL in the Pod Bay when you press "`".

Ben

I gave it a try. I selected Discovery and pressed "V" to focus on the pod bay. I pressed "9/0" until the airlock was selected and pressed "1/2" until Dave Bowman was selected. I then pressed "`" and then pressed "E". It keeps telling me "the airlock is closed unable to EVA." I'm sure it is something stupid I'm missing but I can't for the life of me figure it out. I also noticed the "\" key activates the "orbit antinormal" autopilot instead of activating the selected Pad. I am running Orbiter 2010 v 100830 on Windows Vista 64-bit service pack 2. I'm sorry to keep bugging you about this. Thanks.

 

[BenSisko]

Urwumpe,
Just to be clear. Face helped us with a problem. I realize his solution was not what you would have done, but the issue is resolved. The add-on has been released and seems successful thusfar. We'll work the bugs as they show up. We're all here because we have some skills and love spaceflight. None of us are making money at this. Gattispilot and I appreciate your interest and look forward to your suggestions but please keep it light.

Ben

---------- Post added at 08:25 PM ---------- Previous post was at 08:09 PM ----------

ATymeson,
I'm unable to reproduce your problem in my test installation. Regardless of whether I start from Discovery's cockpit or Pod Bay Toggling "9/0" to select EVA site, then "1/2" selects the crewmember. Pressing "`" to open the airlock should result in the annunciator showing "Airlock is now open". Pressing "E" populates the UMmu to the airlock or whatever site you've chosen for EVA. Also, " ' " is the anti-normal key command, "\" switches the active Pod/pad in the Discovery's Pod Bay. I don't know what else to suggest other than trying another clean install. Gattispilot, can you think of anything I missed?

Ben

 

[gattispilot]

Here is Face's cpp and h's.
https://dl.dropboxusercontent.com/u/71242599/Leonovface.zip

 

[Urwumpe]

Urwumpe,
Just to be clear. Face helped us with a problem. I realize his solution was not what you would have done, but the issue is resolved. The add-on has been released and seems successful thusfar. We'll work the bugs as they show up. We're all here because we have some skills and love spaceflight. None of us are making money at this. Gattispilot and I appreciate your interest and look forward to your suggestions but please keep it light.

No deal, just doing it for science. :lol:

Had only used the evening after the world cup yesterday for setting up the project, creating the standard source code structure of mine and implementing the skeleton of the add-on. And then waited for the sources to get the animation and camera position references, before I have to start measuring them myself. Will try to stick to the features as implemented in your add-on for making both comparable, if you don't mind.

 

[gattispilot]

Sure. Whatever helps Orbiter

 

[Face]

Here is Face's cpp and h's.
https://dl.dropboxusercontent.com/u/71242599/Leonovface.zip

Just to clarify: this is NOT my version, it is my last sent plus your changes. You've added some things (beacons, HUD-text), and changed animation parameters.

I'll incorporate them into my repo.

 

[gattispilot]

ok. On the airlock issue.

This are screenshots.
9/0 selects which airlock/location. Here the airlock is selected

1/2 selects which person for eva. Here the David Bowman is selected

` Opens airlock. Here the airlock is open

E and Bowman is now in the airlock of the Discovery

 

[BenSisko]

We have found two issues in the initial release of the Vessels of 2001 and 2010 which include:

•Leonov ballute rendering issues in the D3D9 client
•UCGO error message on Leoprobe release

A patch to address these issues has been uploaded to Orbit Hangar Mods and the Vessels of 2001 and 2010 package has been updated. If you have already downloaded the Vessels of 2001 and 2010, installing the patch will resolve these issues.

To install, unzip the Vessels of 2001 and 2010 Patch to the location of your Orbiter 100830 P1 folder. Be sure to preserve the directory structure of the package (for example, in WinZip this re-quires activating the “Use Folder Names” option).

Gattispilot
BenSisko

 

[BenSisko]

We have found a rendering issue in the release of the Vessels of 2001 and 2010 and it's Patch involving the detail of the sidebar in the Leonov's ballute section.

A second patch to address this has been uploaded to Orbit Hangar Mods and the Vessels of 2001 and 2010 package has been updated. If you have already downloaded the Vessels of 2001 and 2010, install this patch after installing the first patch to resolve the issue.

To install, unzip the Vessels of 2001 and 2010 Patch II to the location of your Orbiter 100830 P1 folder. Be sure to preserve the directory structure of the package (for example, in WinZip this re-quires activating the “Use Folder Names” option).

Gattispilot
BenSisko