General Question Spacecraft3.dll in Orbiter 2010

A couple things I'd like to see are multiple view angles and directions in the VC.
 
Honestly, I'm more in favor of a n easy implementation of a custom VC. But we could have a generic VC as an example script. So people could copy 30 lines of code to their new project and then change some parameters and/or the mesh.
 
Wait a minute... do you mean a generic 2D panel, or a 3D virtual cockpit?

I would suggest a 2d panel, reached by control-down like IMS. On it you can have a list of useful data readouts like delta-vee, an oxygen/electricity tank, and animations could be listed as anim-1, anim-2, etc.

On a side note, it would be really cool if users could overwrite the panel texture. Maybe if a VC was done with a single flat mesh... Anyone see where Im going?
 
This is how 2D panels are implemented currently (more or less.)

No, If we implement it as a 2d panel the texture will be set for all vessels using it.

But... If we were to do the panel as a VC which only contains a single flat mesh, we can assign button areas for animations, info displays, and maybe even add a throttle. Then when the user creates the config file they specify a copy of the original VC mesh provided as their vc mesh, then they can edit the mesh file to read their own texture. That way everyone can have a panel in their spacecraft & they can customize the panel texture to whatever they want.
 
Is there a way a panel could be built as a single panel with buttons, switches and dials. Then placed inside and positioned in a VC mesh. Then assign the animations to the switches and dials.and have the .dll read it from a file ?
 
Is there a way a panel could be built as a single panel with buttons, switches and dials. Then placed inside and positioned in a VC mesh. Then assign the animations to the switches and dials.and have the .dll read it from a file ?

That would probably require the ressurection of the Orbiter Shipyards. My idea would be simpler, but less flexible since the layout of the panel would be fixed from the start. Only textures could be changed to allow for individual panel styles.
 
Is there a way a panel could be built as a single panel with buttons, switches and dials.

Please elaborate on this. Do you mean composing a panel from a given set of elements? Like e.g. push-button, switch-button, swap-button, knob-dial, slider-gauge, clock-like gauge, MFD, ADI-ball, etc. etc.?

That would be interesting, but a whole lot of work. Certainly doable, though.
 
I'm catching up on this thread and see that lots of progress has been made.

May I suggest a different take on VC / working panel ?
Before thinking about any graphic solution, we need to simulate spacecraft systems. You can't have a panel with no systems (and their data) to simulate.

OK, from SC3 we have propulsion, gears and aerodynamics (air-brakes, etc), docking and a robotic arm.

So perhaps we could start by adding parameters for simulating spacecraft environment, power generation / consumption and telemetry / communication, lights, etc. A simple on/off key for each would do to start with.
I'd be satisfied in having this data on the HUD as simple text for a first implementation.

Of course, those systems will be defined in .cfg files compatible with sc3, by adding the relevant section.
For example, something like:

[Power]
panelarea=2
numpanels=2
fixed=1

[Communication]
antennagain=10
beamwidth =5
frequency=120000
fixed=1
xang=0
yang=0
zang=90




Besides this primary systems we could also have cameras (very generic implementation, simply move the default orbiter camera to the indicated coordinates and direction), for example.





---------- Post added at 01:50 ---------- Previous post was at 01:40 ----------

Good ideas. Is there an immediate connection to the topic at hand, though? Do you mean this is necessary to better deal with SC3 add-ons? Or is it just a general comment on making the "Orbiter ecosystem" (nice term, BTW :lol: ) better?

Regarding multiple authors per add-on on OH: really not sc3 specific, but it has to do with the notion of open collaborative development.
 
Last edited:
Please elaborate on this. Do you mean composing a panel from a given set of elements? Like e.g. push-button, switch-button, swap-button, knob-dial, slider-gauge, clock-like gauge, MFD, ADI-ball, etc. etc.?

That would be interesting, but a whole lot of work. Certainly doable, though.

Yes, one could construct the panel with instruments, then place the whole panel into the VC. Then it is quite easy to locate the xyz of each switch, dial, knob etc. and it's operating animations. Then it would be up to code for each instrument to operate it. I will post some examples of what I mean.
 
First, you would construct the panels in the graphics program, each switch/instrument numbered, named and specified as to its perimeters. Then placed in it's position in the VC to find it's vectors.

Switches : 2 or 3 position
Knobs : degree increments
Needles : spin or translate
Tape guages : wheel or rotate
 

Attachments

  • panel1.jpg
    panel1.jpg
    117.3 KB · Views: 21
  • panel2.jpg
    panel2.jpg
    60.7 KB · Views: 22
  • VC.jpg
    VC.jpg
    141.9 KB · Views: 27
Much more elaborate than what I was thinking of, but yes! Right about what I had in mind, I wasn't thinking too much about rotary switches, but pushbuttons.

Need a lever for landing gear (I assume the large black guarded buttons are for dock release?).
 
I've checked in a first draft of a replacement framework here: http://bitbucket.org/face/genericvessel/get/tip.zip

It creates a vessel DLL called "genericvessel" and modifies the standard spacecraft3.cfg to point to this module instead of SC3. ATM it only loads the mesh, but it could be used as boilerplate to load all configuration settings.

Additionally genericvessel supports the discussed ScriptVessel approach. It is demonstrated by means of the (copied) scenario "Generic Vessels/Animations" together with the sample class "/Config/Vessels/SampleGenericVessel.cfg" . This also means that generic vessels can be created by scenario editor.

regards,
Face
 
I've checked in a first draft of a replacement framework here: http://bitbucket.org/face/genericvessel/get/tip.zip

It creates a vessel DLL called "genericvessel" and modifies the standard spacecraft3.cfg to point to this module instead of SC3. ATM it only loads the mesh, but it could be used as boilerplate to load all configuration settings.

Additionally genericvessel supports the discussed ScriptVessel approach. It is demonstrated by means of the (copied) scenario "Generic Vessels/Animations" together with the sample class "/Config/Vessels/SampleGenericVessel.cfg" . This also means that generic vessels can be created by scenario editor.

regards,
Face
Tested the included scenario and it has a serious impact on my FPS. With SSU which has very high-detail and complicated meshes and textures, my FPS is V-synched to 60 FPS (it is 205 FPS without v-sync enabled). So something is seriously wrong.
 
Well, if you look at the source, there is not much going on in genericvessel ATM. It is a really bare-bone VESSEL3 with just one mesh added. It could well be that this minimum configuration is a problem, but since I can't reproduce a performance drop here, I can't really comment on that.

---------- Post added at 16:46 ---------- Previous post was at 16:42 ----------

EDIT: Just tested it, and I get 450+ FPS with the Animations scenario in Win7 on Orbiter 2010 P1. I did not test it in OVP clients, though. Maybe this is an issue?
 
Well, if you look at the source, there is not much going on in genericvessel ATM. It is a really bare-bone VESSEL3 with just one mesh added. It could well be that this minimum configuration is a problem, but since I can't reproduce a performance drop here, I can't really comment on that.

---------- Post added at 16:46 ---------- Previous post was at 16:42 ----------

EDIT: Just tested it, and I get 450+ FPS with the Animations scenario in Win7 on Orbiter 2010 P1. I did not test it in OVP clients, though. Maybe this is an issue?
No. There seems to be a compatibility between GenericVessel and OrbiterSound 4.0. Without OS enabled, the FPS is nominal but with it enabled, it drops to 30 fps. I have reproduced this twice now reliably.
 
260 FPS with d3d9 R7 client
Orbiter 2010 P1
Spawned in space from scenario editor with no problems
 
260 FPS with d3d9 client 2010 P1
About the same here, D3D9Client is not to blame for the severe FPS drop, that goes to OS 4.0.
 
I have Orbitersound 4.0 on, however with 3d sound disabled

---------- Post added at 06:04 PM ---------- Previous post was at 06:02 PM ----------

and forgot one thing - WinXP SP3
 
There seems to be a compatibility between GenericVessel and OrbiterSound 4.0.
I didn't test it, but I'm not sure what incompatibility with OrbiterSound there could be, as all the code is doing now is only adding the mesh listed in the INI file in clbkSetClassCaps, and nothing more. :shrug:

Code:
char line[1025];
GetPrivateProfileString("CONFIG", "MESHNAME", "", line, 1024, iniFile);
AddMesh(line);
 
Back
Top