Project genericvessel - spacecraft3 and multistage2 replacement project

there are a few that are needed.

1. [ame="http://www.orbithangar.com/searchid.php?ID=5442"]SpaceX launch vehicles and Dragon[/ame]

2. [ame="http://www.orbithangar.com/searchid.php?ID=5775"]Dragon Update[/ame]

3. [ame="http://www.orbithangar.com/searchid.php?ID=5871"]Dragon Update 2[/ame]

4. [ame="http://www.orbithangar.com/searchid.php?ID=6022"]SpaceX CRS-2 scenario[/ame]

5. [ame="http://www.orbithangar.com/searchid.php?ID=6020"]Heat Rejection Subsystem Grapple Fixture(HRSGF)[/ame]
 
there are a few that are needed.

So I guess I have to install them in that order, right? Thanks for the info, I'll see what I can do...
 
Last edited:
I've installed the 5 add-ons in a vanilla environment with plain old SC3 (of course the compatible one) and standard OS+UMMU/UCGO. Unfortunately, half the scenarios bail out due to missing configuration (one is PV_34 or something like that, another is UCargoDeck).

What scenario do you use to reproduce the problem, and how do I get it to run on a fresh install? Or maybe you could post a save-point for me to test the problem(s) in question?

regards,
Face
 
Face, may I ask a question? What is the latest Spacecraft3.dll version for the Modules folder in 2010p1.? I have checked Vinka,s website.
 
Thanks again Face. Looks like I have the latest version.
 
Here is a scenario that should work for you. It starts focused on the trunk. pressing "J" should jettison the nosecone, pressing "J" a second and third time, the two array covers.

Code:
BEGIN_DESC
saved state
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 56353.2291710520
  Context SSU
END_ENVIRONMENT

BEGIN_FOCUS
  Ship dragon/trunk
END_FOCUS

BEGIN_CAMERA
  TARGET dragon/trunk
  MODE Extern
  POS 4.40 -166.14 -173.47
  TRACKMODE AbsoluteDirection
  FOV 52.79
END_CAMERA

BEGIN_HUD
  TYPE Docking
  NAV 0
END_HUD

BEGIN_MFD Left
  TYPE Map
  REF Earth
  POS 0.00 0.00
END_MFD

BEGIN_SHIPS
dragoncapsule:Spacecraft\Spacecraft3
  STATUS Orbiting Earth
  RPOS 2731276.26 2401070.12 5531581.45
  RVEL -3776.103 -5298.469 4248.445
  AROT 33.57 50.91 1.79
  VROT 0.05 0.06 0.05
  AFCMODE 7
  PRPLEVEL 0:0.999245
  NAVFREQ 94 481
  RCS 1
  CTRL_SURFACE 1
  CONFIGURATION 0
  CURRENT_PAYLOAD 0
  SEQ 0 2 0.999859
  SEQ 1 -2 0.000000
  SEQ 2 -2 0.000000
  SEQ 3 -2 0.000000
  SEQ 4 -2 0.000000
END
dragon/trunk:spacecraft\spacecraft3
  STATUS Orbiting Earth
  RPOS 2731276.26 2401070.12 5531581.45
  RVEL -3776.103 -5298.469 4248.445
  AROT 33.57 50.91 1.79
  VROT 0.05 0.06 0.05
  ATTACHED 0:0,dragoncapsule
  AFCMODE 7
  NAVFREQ 0 0
  RCS 1
  CTRL_SURFACE 1
  CONFIGURATION 1
  CURRENT_PAYLOAD 0
  SEQ 0 -2 0.000000
END
END_SHIPS
 
Ok, I can reproduce it now, many thanks! Is this add-on also the one with the slower animations you mentioned earlier? If so, any specific scenario for that?
 
It doesn't seem to be a problem anymore.
 
The new tip now contains a genericvessel/xves combination that supports payloads: https://bitbucket.org/face/genericvessel/get/tip.zip .

This is also a first test for extending the system with the native GetPrivateProfileString instead of Artlav's parser.

At least the Dragon seems to work with it.
 
What do you mean by "new tip" ?

The payload release works with the Shenshou9 also. :thumbup:
 
What do you mean by "new tip" ?

It is the name of the topmost revision in the repository, also the reason why the link shows the name "tip.zip" instead of some hashcode.
 
Oh

Problem, the payloads detach, but animations don't work.

---------- Post added at 12:53 AM ---------- Previous post was at 12:46 AM ----------

OK, they work in the regular Orbiter, but not D3D9client.

---------- Post added at 01:25 AM ---------- Previous post was at 12:53 AM ----------

now it's working. strange. I must be losing it.:shrug:
 
Could it be that those animation artifacts come from the fact that genericvessel currently uses incompatible save/load tags for the animation states?

When I was working on the payload state saving, I've noticed that saved scenarios are different between SC3 and genericvessel in this regards.

This could well cause your observations if you start with a certain saved scenario, wonder why animations are not where they should be, then exit and reload again, and then wonder why they suddenly work.

Does anybody know if there is a description of the save tags used in SC3? I better RTFM myself ;) .

---------- Post added at 11:18 ---------- Previous post was at 09:16 ----------

It also looks like the animations show not even near the same behaviour. Take a look at the SC3-bundled "Animations" scenario:

  • Animation states are wrong at startup - that's clear because of the save/load tags I already mentioned.
  • Activation keys are not the same. In SC3 the numpad keys are activating it (somewhat awkward, TBH, as I have to toggle NUMLOCK here), in the genericvessel case the normal 0-9 keys are the only one that work.
  • Repeat definitions are ignored. Check the "antenna" animation (key 1) with both SC3 and genericvessel.
  • Pause definitions are ignored. Check the solar panel animation (key 2). In SC3, the panels only open with Shift+Ctrl+Numpad2, and they stop on pressing the key. In genericvessel, they just get toggled on Shift+0.
I'll take this up as issue.

---------- Post added at 11:22 ---------- Previous post was at 11:18 ----------

Here it is: https://bitbucket.org/face/genericvessel/issue/1/animations-not-sc3-compatible

Feel free to add whatever is missing.
 
Last edited:
Hi Face, Looking at your comments, I understand Left Shift and 0 doesn,t work with genericvessel. In the Eagle199-S3 you tested, the attach/detach PODS work as the instructions using both SC3 and Genericvessel.

With Numberlock off "Press A to Activate attach - detach module. Press Left Shift and 0 on the Numpad to Attach or Detach POD.."

Then I press A again, turn on Numberlock and you can then take off.
 
Hi Face, Looking at your comments, I understand Left Shift and 0 doesn,t work with genericvessel. In the Eagle199-S3 you tested, the attach/detach PODS work as the instructions using both SC3 and Genericvessel.

With Numberlock off "Press A to Activate attach - detach module. Press Left Shift and 0 on the Numpad to Attach or Detach POD.."

Then I press A again, turn on Numberlock and you can then take off.

I have to admit that I did not test the eagle's animations, seeing that Artlav immediately solved the issues there.

But I'm focusing at SC3's stock scenarios, where the difference between SC3 and genericvessel is pretty clear. Genericvessel is not accepting the numpad keys at all, just the regular digit line, while it is vice versa for SC3. In addition, genericvessel don't even need the Shift. At least this is how I have it here.

Maybe it is working with different keyboard layouts and/or custom Orbiter keymaps? I have the German layout and a vanilla install (except for OS/UMmu/UCGO and genericvessel/SC3/MS2, of course).
 
Last edited:
I use the standard Orbiter keymap and Eng/Us keyboard.
I have 2 identical Eagle installs, except for a name change, 1 using purely the Genericvessel module, the config which is headed (ClassName = Eagle1999 Module = genericvessel) is in the Vessels folder .
And 2 is the ordinary SC3 in the Spacecraft folder, and both work identically.
2 identical scenario folders, 1 for Eagle1999-S3:Spacecraft\ Spacecraft3 and the other for Eagle1999-S3: Eagle1999 (genericvessel name.)

I,m sorry to be a pain, just trying to point a few things out, but obviously you know more about this than I do.
 
Last edited:
I concure with all your assessments, Face.
 
Sounds like things are progressing quite well here, I'll be interested to see what gets implemented next, particularly what happens with crew simulation.

Since we moved this discussion from the old thread here

http://www.orbiter-forum.com/showthread.php?t=30250

I just wanted to put in a final word about SC3, putting things in perspective somewhat, even though this thread is more about development. It seems to me that the development methods for Orbiter add-ons has changed since 2006 or so, in that SC3 was originally better than the dlled method. In 2006-2007 UMMU was just appearing, UCGO was nonexistent, and many other libraries that make dlled vessels shine had not been created yet. As such, creating add-ons like the famous SSBB 4.1 in SC3 made more sense than Dlling them; it was more flexible, easier for users to edit, and a heck of a lot faster than coding them. So anyways, try to remember that when browsing through old add-ons on the Orbit Hangar. Even now, SC3 and its successor (Spacecraft4?) might never be as flashy or capable as a custom-made dll, but they'll always come in handy for a user who needs to make something quickly. Carry on gents :tiphat:
 
Last edited:
Back
Top