OHM Spacecraft3 to DLL&C++ converter 141006

[Artlav]

clbkConsumeBufferedKey is not generated that's what I mean. Here's a complete package including the generated sources: http://dl.dropbox.com/u/24122088/Orbiter stuff/SSU_VAB_1990.zip

Sorry, i still don't understand.

SSU_VAB_1990.cpp in zip you provided, line 231:
int SSU_VAB_1990::clbkConsumeBufferedKey(DWORD key,bool down,char *kstate)

Even more, animations and their keys work both in compilation and in generated DLL.
Tried regenerating from provided ini, got almost the same cpp which compiles and works without modifications.

So, what exactly is wrong?

---------- Post added at 13:05 ---------- Previous post was at 13:04 ----------

All the features for SC3 are explained in the SC3 Doc.

These are details, and i have terrible attention to details.
To be added.

 

[DaveS]

Sorry, i still don't understand.

SSU_VAB_1990.cpp in zip you provided, line 231:
int SSU_VAB_1990::clbkConsumeBufferedKey(DWORD key,bool down,char *kstate)

Even more, animations and their keys work both in compilation and in generated DLL.
Tried regenerating from provided ini, got almost the same cpp which compiles and works without modifications.

So, what exactly is wrong?

The problem is that as there's no OAPI_KEY_ lines in the generated sources, the animations can't be controlled.

 

[Artlav]

The problem is that as there's no OAPI_KEY_ lines in the generated sources, the animations can't be controlled.

And yet, they can be.

I got your problem, however. The sources generated are a bit raw, so constants are not always specified, and their values are used instead.
OAPI_KEY_K is 37, OAPI_KEY_G is 34, etc.
Which are specified as parameter 5 of make_anim(...) calls.

To be improved.

 

[DaveS]

And yet, they can be.

I got your problem, however. The sources generated are a bit raw, so constants are not always specified, and their values are used instead.
OAPI_KEY_K is 37, OAPI_KEY_G is 34, etc.
Which are specified as parameter 5 of make_anim(...) calls.

To be improved.

I still can't get the animations to work. Nothing happens when I press the appropriate keys. I tried with both the generated module and compiling the generated sources with some modifications, nothing work.

 

[Artlav]

I still can't get the animations to work. Nothing happens when I press the appropriate keys. I tried with both the generated module and compiling the generated sources with some modifications, nothing work.

Okay, is the zip you posted earlier an example of this issue?
I compiled the sources and used the generated dll, and all 4 keys worked, opening the doors.

Anything special needed to reproduce that?
Do animations work in other inis?
Can you get them to work by changing something in the cpp or ini?
Do you use O2010P1?

 

[DaveS]

Okay, is the zip you posted earlier an example of this issue?
Anything special needed to reproduce that?
Do animations work in other inis?
Can you get them to work by changing something in the cpp or ini?
Do you use O2010P1?

The zip version shows the same problem.
Nothing special needed. I tried with a SC3 version of the DG and it worked fine.
They work nicely in the ini file but not the converted module.

 

[NukeET]

If it stops crashing, that's not a negative effect. Seriously though, I think they are obsolete features.

Well that is definitely a positive thing. Could you please explain why it is obsolete and what did it do? I thought that was important for Orbiter to calculate the center of gravity, or something like that.

When did moments of inertia and aerodynamic cross sections become obsolete?

 

[Artlav]

The zip version shows the same problem.

Can you reproduce it on a clean install?
It works fine for me, so it's likely something specific to your setup.

 

[DaveS]

Can you reproduce it on a clean install?
It works fine for me, so it's likely something specific to your setup.

Works on the clean install. I guess I need a new primary install to get away from these weired behaviors.

 

[Grover]

i have a request:

could you possibly make the source code generated, a little easier for the C++ illiterate to understand? i plan to use your tool to teach me the basics of spacecraft-module-writing, but the code seems very complex, far more complex than i have seen other code.

i refer mainly to the animation coding, i understand that SC3 is a little awkward in how it sets them up, but thats the main thing i have problems with is indeed coding animation through C++.

thanks for the awesome tool!

 

[N_Molson]

thats the main thing i have problems with is indeed coding animation through C++.

That's not the worse part. Look at the "HST" sample in Orbiter SDK, it should help you. I learned to code anims that way.

 

[Grover]

ah, i never thought of the HST, thanks man!

 

[Artlav]

(including PM) is this done for now ?

No, it's still very much alive.

could you possibly make the source code generated, a little easier for the C++ illiterate to understand?

Sorry, that's not something i can understand, so you should spell it out for me.
What exactly is not clear? Besides of few denominated constants the animation definitions are about as compact and clear as they can get.

 

[Grover]

ok, sorry:

i meant that i will use the source code, that your tool generates, to learn how to make a vessel in C++. this will let me make it more efficient than your tool can ever be (since it has such versatility), and it would be easier to work in things like UMMU (beyond simply adding crew members) and UGCO.

the problem at the moment is that the source code that gets generated is messy at best, and it is completley useless for me to learn from unless i already understood it...

i can learn using other ways, but this would be the best at the moment

thanks

 

[jgrillo2002]

I hate to say this but what am I suppose to do with the created zip files. because I converted the MRO, I extracted the files to the proper location and fired up orbiter. and it just crashes to the desktop. all I did is convert the MRO sc3 version to DLL using the GUI

 

[Izack]

Most SC-3 vessels just copy-paste the Delta-glider's cross-sections and principle moments of inertia anyway. I would like to know why the cross-section was needed for Orbiter, though.

 

[NukeET]

Most SC-3 vessels just copy-paste the Delta-glider's cross-sections and principle moments of inertia anyway. I would like to know why the cross-section was needed for Orbiter, though.

In order to calculate aerodynamic drag.

See here:

http://www.orbiter-forum.com/showthread.php?p=266299&postcount=147

 

[liber]

Most SC-3 vessels just copy-paste the Delta-glider's

Don't agree,you can easy get cross section for each craft with shipedit tool locate in Orbiter utility directory.
I think cross section effect flight performance for atmosphere flight.
Wider aircraft make different performance than thiner one...so putting same for each craft do not simulate "real" or desire flight performance...

 

[n0mad23]

Artlav - What a thing to come back into Orbiter to find! You have outdone yourself once again!

Is there a limitation to the number of groups that can be assigned to a single animation here? I've been trying to convert my derelict space station with SC3 Converter but find that 2 entire groups aren't working. I suspect this is the case, as there are close to 70 mesh groups contained in each animation line.

 

[astrosammy]

Just tested it with BSP4, it works perfectly! :tiphat:

Until we have a new version which supports trim, I've created an lua script to do that:

------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------
-- file "d:\program files (x86)\orbiter\rtap\script\addtrim.lua", created by Astrosammy on 2011-07-10
-- script adds trim to selected vessels
-- works perfectly with vessels created by artlavs spacecraft3 to dll&c++ converter 110509
-- to run this script, add "Script addtrim" to the environment block of the scenario
-- todo:
--			-animations
------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------

-- loop with all vessels in the simulation session
n = vessel.get_count()
for idx = 0,n-1 do
	hvessel = vessel.get_handle(idx)
  
	v = vessel.get_interface(idx)
	class = v:get_classname()
  
	if (class == 'gregburch\\bsp4\\bsp4j') then
		-- term.out('Trim added to a BSP4J.')	--debug
		elevatortrim0 =  v:create_controlsurface(AIRCTRL.ELEVATORTRIM,2,1.5,{x=0;y=0;z=-15})	-- values are from c++ source
    end
	
	-- same as above for another vessel class
	if (class == 'gregburch\\bsp4\\bsp4') then
		-- term.out('Trim added to a BSP4.')	--debug
	elevatortrim0 =  v:create_controlsurface(AIRCTRL.ELEVATORTRIM,2.5,1.5,{x=0;y=0;z=-15})
    end
end

(Easy, but I finally learned how to write lua scripts. It's great!)

A requests for the converter:
-support config file based vessels. I've seen SC3 add-ons that have their docking ports defined in there, and it would make adding UMMU support to some station modules easier.