OHM Spacecraft3 to DLL&C++ converter 141006

[liber]

Well, if it doesn't destroy the sc3 spacecraft if it's in the sc3.ini, than it's fine

So that would mean, that add-on developers just have to know which mesh groups are buttons and write that in the ini? I have no clue how VC MFD buttons usually work.

SC3 do not support button or anything else in VC,you can add hud,MFD and that is all...maybe author plan to add one day but don't know,Vinka did not update SC3 for a long time.

 

[Wishbone]

Suspect Artlav is about to elevate the cumulative awesomeness of his creations to a heretofore unknown level - it is a short way from the MeshMaker to VC maker with standardized buttons, gauges and displays...

 

[Artlav]

from the MeshMaker to VC maker

Actually, that meshmaker is a part in a larger AI research on integration of various systems through a common ontology. So, you type "make me a shuttle like craft 10 meters long with red top, black bottom, generic VC and a crew of 5", and out goes DeltaGlider.

No one is going to like it, though. It still takes some work to use it, and whoever don't want to work much won't want to work even little.

Also, great-mesh-artists are often allergic to command line tools.

 

[Wishbone]

Some of the ideas revolve around modularity; having a common library of components saves a huge amount of dev time and allows one to concentrate on higher-level considerations.

Anyway, thanks for this tool, am crawling back to work on Martian landing meshes

 

[victor]

Dude, you are one of the all time Master Jedi Orbiter addon gurus!

:rofl:

 

[Mandella]

Bigger problem is that there should be control elements in the meshes - groups for buttons, etc, that are lacking in most of the SC3 vessel meshes.

I'd be happy with a standard fixed six button to each side active control area off to the side of the MFDs in the VC, even without a corresponding set of modeled buttons. New modellers would know to add buttons there, and for old buttonless models we could just learn to click a bit off to the side of the MFD function. Or for the more industrious of us we could go in and edit in visual buttons into the VC model.

Or I just had a thought. Would it be possible to generate a "window within a window?" Use the available MFD space in the VC to show a smaller MFD with the side tabs shown in the MFD square?

 

[Artlav]

Update.
-Added manipulator arm support (needs testing!)
-Fixed potential crash with animations

Or I just had a thought. Would it be possible to generate a "window within a window?" Use the available MFD space in the VC to show a smaller MFD with the side tabs shown in the MFD square?

No, it does not work that way.

 

[DaveS]

No luck with attachment points connected robotic arm animations.

 

[Artlav]

No luck with attachment points connected robotic arm animations.

Details please.
There is an attachment point a the end of the arm. Are there supposed to be others?
What exactly does not work?

 

[DaveS]

Details please.
There is an attachment point a the end of the arm. Are there supposed to be others?
What exactly does not work?

1: Attachment point location is wrong.
2: When I press spacebar to activate the robotic arm mode, the screen go black as if the parent vessel is ejected somewhere and nothing is visible.

 

[liber]

When I press spacebar to activate the robotic arm mode, the screen go black as if the parent vessel is ejected somewhere and nothing is visible.

Don't know is this case at you,but attachment with SC3 module you need to have full config file for the mesh who you attach in order to work proper.
Like you would do for any other craft.
Of course no fuel,thrust...etc...but all other must be there,then attachment would be at position,but not shure for robotic arm,give a try.

 

[Artlav]

1: Attachment point location is wrong.
2: When I press spacebar to activate the robotic arm mode, the screen go black as if the parent vessel is ejected somewhere and nothing is visible.

Example please, then. I assume it works ok with SC, but fails when converted.

 

[DaveS]

Example please, then. I assume it works ok with SC, but fails when converted.

This is correct.

These two screenshots illustrate the problem:

SC3 version with robotic arm function activated:

Converted DLL version with robotic arm function activated:

Converted DLL misalignment bug:

I hope these screenshots is of use.

 

[Artlav]

I was hoping for an ini file and location for the meshes...
Plus reproduction instructions.

 

[DaveS]

I was hoping for an ini file and location for the meshes...
Plus reproduction instructions.

I have attached a package of the SC3 version to this post. And for the instructions, well they're very short:

http://dl.dropbox.com/u/24122088/Orbiter stuff/CentaurGPrime_CISS.zip

1. Convert the SC3 INI files to DLL
2. Replace the SC3 vessel entries in the scenario file with the DLL versions
3. Launch the scenario, misalignment should be obvious
4. Press spacebar to acivate the robotic arm mode, screen should go black

 

[Artlav]

Weirdness confirmed, investigating.

---------- Post added at 10:35 ---------- Previous post was at 09:54 ----------

Update 110427.
-Fixed arm location issues
-Fixed arm initial state issue
-Fixed arm range display
-Fixed arm normalizing (vanish bug)

DaveS, try it now.

---------- Post added at 11:56 ---------- Previous post was at 10:35 ----------

Oh, forgot to mention - there is a typo in CISS_CentaurG_Prime.ini,
in [ANIM_COMP_5] there is no ; before comment on TIP_3.
That throws the converter off a bit.

SC3 seems to swallow it, so to be fixed.

 

[DaveS]

Weirdness confirmed, investigating.

---------- Post added at 10:35 ---------- Previous post was at 09:54 ----------

Update 110427.
-Fixed arm location issues
-Fixed arm initial state issue
-Fixed arm range display
-Fixed arm normalizing (vanish bug)

DaveS, try it now.

---------- Post added at 11:56 ---------- Previous post was at 10:35 ----------

Oh, forgot to mention - there is a typo in CISS_CentaurG_Prime.ini,
in [ANIM_COMP_5] there is no ; before comment on TIP_3.
That throws the converter off a bit.

SC3 seems to swallow it, so to be fixed.

Confirmed that it is fixed now. Great job as usual tracking down and eliminating even the most non-obvious bugs.

BTW, is there a way to detach attached vessels yet?

 

[Artlav]

BTW, is there a way to detach attached vessels yet?

Not yet, but planned.

 

[DaveS]

Not yet, but planned.

Thanks for the reply. I'll be awaiting that as it's the only thing that keeps me from releasing my IUS/Centaur add-ons.

 

[Artlav]

Update 110428.
-Added attachment point handling (needs testing)
-Better C++ code generation (constants, enumerables, wrapping of repeats, etc)
-Fixed closest detection in grappling
-Fixed attachment/grapple points ranging
-Fixed parameter skip issues (size of Armdock vessel issue)
-Fixed lack-of-comment issue (CISS_CentaurG_Prime)
-Fixed compilation of C++ generated code without arm
-Removed attachment GS id limitation

I'll be awaiting that as it's the only thing that keeps me from releasing my IUS/Centaur add-ons.

Okay, done.

Anything else worth adding?