Meadville Space Center
Welcome, Guest. Please login or register.
September 20, 2017, 08:44:06 PM

Login with username, password and session length
Search:     Advanced search
Gemini 060615 released!
24443 Posts in 2077 Topics by 2260 Members
Latest Member: lricca
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Mercury
| |-+  Development
| | |-+  Programming
| | | |-+  Updating to VESSELX
« previous next »
Pages: [1] Print
Author Topic: Updating to VESSELX  (Read 18466 times)
robertsconley65
Administrator
Full Member
*****
Posts: 149


View Profile Email
« on: March 12, 2011, 05:44:47 PM »

Quote
Bibi Uncle wrote:
It's a real pleasure to meet you Mr. Conley ! I am very glab to share my work with you. Check in your GMail inbox, my email is coming. However, I never developped on SourceForge (it's my first open source project), but I am pretty sure that the site is easy to understand.

I sent an email to start the process to get you going on sourceforge. The first thing is to get you rights so you have a place to upload files and update the source code tree.

Quote
Also, I have a dilemma. Right now, I create a VESSEL2 class, which is the vessel class used in Orbiter 2006 (and maybe older releases, I don't know). However, the new Orbiter 2010 has a VESSEL3 class and I find it very useful. The new panel interface works much better and, when used wisely, can gain a lot of framerate. But, this new class change about every functions of the 2D panel if we want to use the latest innovations. We would also need to create a DDS texture with all the buttons, gauges, etc. A lot of work, but much more better performance. Also, the transparency could be well render (I'm talking about the periscope). In the other hand, the VESSEL2 class does not need any hard work, but does not use the latest innovations of Orbiter 2010.

First, I haven't studied the VESSEL3 interface so I won't be able to answer many questions on that. I do know that I used a lot of GDI calls to get the panels to look right. So it going to take careful work to figure out what works with VESSEL3. But I am in agreement that ultimately everything should be shifted over to VESSEL3.

I think to keep you sane  Very Happy that I recommend getting everything over to VESSEL2.  As you probably already know I use common_addon.h as the parent for all my vessel classes. The reason for this is that I can exchange message between two different vessels (or vessel and addon like MCC) through a common interface. So COMMON_VESSEL inherits from VESSEL (which I understand you changed to VESSEL2).

Then I created a class called Multi-Stage. What it is is a State machine machine which each state is a complete vessel setup. In addition is also holds a ControlPanel using the IControl_Panel interface. The idea that a single type of vessel may have multiple stages and configurations but you the operator only sitting in "one place" so to speak.

Each stage is a class defined with the IStage Interface. The transition from one stage to the next generally happens in timestep and involves creating a new instance of the next stage and using SetStage to make it the current stage. Everything about the vessel is destroyed and recreated with the new stage during the next time step.  In timestep the ControlPanel can be queried for switch status and updated dials and indicators.

Both Mercury_Atlas and Mercury_Redstone are two stage vessels programming wise.  The Rocket stage and the capsule stage.

The Mercury Control Panel has a pointer to a Mercury_system which models the hydraulics, life support, and electrical system. It basically uses a pipe and socket model.

The biggest source of issue in converting to VESSEL3 is the Control Panel. What you could do, after getting it to work on VESSEL2, is just create a dummy class that implements IControlPanel and does nothing.  Focus on getting the rocket and capsule stage over and working and then figure out how to do the control panel. One big gotha is the ADI ball and the Earth Globe. it uses Open GL to render a sphere to a Device Context.  It highly windows GDI specific and I have no clue how it could be done with VESSEL3.








Quote
Once again, I'm very glad to work with you !

I am glad something stepping up. The point of Project Mercury for Orbiter was never to make it Rob Conley's Mercury. The add-on, the models, the code and documentation are for everybody in the Orbiter Community.

I would also recommend checking out this thread on the Orbiter Forum. If there enough interest I can move this over there.
Logged
Bibi Uncle
Full Member
***
Posts: 15


Project Mercury Developer


View Profile
« Reply #1 on: March 13, 2011, 12:55:31 PM »

I understood a bit of the code before (a lot of OOP, I like it  Thumbs Up ), but your explanations helped me a lot.

Now, it's my turn to learn you some tricks for Orbiter  Wink

First of all, you were right for the inherits of COMMON_VESSEL. Now, it inherits from VESSEL2. However, it was not that easy... In the old versions of Orbiter (with VESSEL), Orbiter was calling DLLCLBK for all Orbiter callbacks. Now, it creates a class during the DLLCLBK VESSEL *ovcInit(OBJHANDLE hvessel, int flightmodel). Then, Orbiter calls virtual functions of your class instead of pure DLLCLBK. So, I changed every DLLCLBK by functions of Multi_Stage.

Also, with the new VESSEL3, the panel is now a 2D mesh (yeah, with vertices and triangles). So, it is very easy to create, for example, needles. You define 2 triangles that forms a rectangle. This rectangle will have texture coordinates with a needle texture. Then, you can rotate the vertices to move the needle. Very easy, and very framerate efficient. For 3D elements, we'll have to use OpenGL or DirectX. I don't think that you can define 3D meshes for panels. I have a little experience with OpenGL and DirectX (I made a OpenGL Orbiter Mesh Viewer, available at OrbiterHangar).

I'll create a SourceForge account right after I post this message.

(By the way, I love this Spell Check button  ROTFL )

EDIT:
I work a bit on Mercury and the Tower is now working.
« Last Edit: March 13, 2011, 02:17:44 PM by Bibi Uncle » Logged

"We watched the tragedy unfold, we did as we were told, we bought and sold." - Roger Waters, Amused to Death
robertsconley65
Administrator
Full Member
*****
Posts: 149


View Profile Email
« Reply #2 on: March 13, 2011, 08:00:45 PM »

Email your sourceforge name so I can add your to the developer's roster.
Logged
Bibi Uncle
Full Member
***
Posts: 15


Project Mercury Developer


View Profile
« Reply #3 on: March 14, 2011, 10:08:35 AM »

My email is sent, and I just compiled the Redstone (with some modifications) and it works like a charm (I don't see any bugs right now, that was not the case of Atlas...) Excited!

EDIT:
The abort tower is now working (very resembling to the standard tower). I checked the mercury_drogue.dll (called Mercury_Antenna.cfg in the config files... strange naming issue...) and it is already a VESSEL2 class. I also checked the beacon. I corrected it, but when I debug it, VC++ always say that the module isn't loaded. I looked in the Atlas and the Redstone code, I found a JettisonBeacon function, a bJettisonBeacon boolean and a reference to it in clbkConsumeBufferedKey. However, the boolean is not called elsewhere and the JettisonBeacon isn't call too. So, we have unused code and mesh.
« Last Edit: March 14, 2011, 08:09:09 PM by Bibi Uncle » Logged

"We watched the tragedy unfold, we did as we were told, we bought and sold." - Roger Waters, Amused to Death
Bibi Uncle
Full Member
***
Posts: 15


Project Mercury Developer


View Profile
« Reply #4 on: March 18, 2011, 04:44:33 PM »

I work on the new panel, but I'm hitting a wall  Bangs Head

I can't create a panel with the new interface ! I always have a #5 VC++ error at debugging (try to write on an deny data, or something like that). However, when I do not add any group to the panel mesh, everything works (but the panel is empty). I can add a group to the mesh, but I can't initialize the panel (with SetPanelBackground()). I can't find why. The exception is always at the exterior of my code, so I just can see some ASM for the debugging...
Logged

"We watched the tragedy unfold, we did as we were told, we bought and sold." - Roger Waters, Amused to Death
Bibi Uncle
Full Member
***
Posts: 15


Project Mercury Developer


View Profile
« Reply #5 on: March 30, 2011, 12:52:26 PM »

OK, it finally works (with the help of orb). I have the main and the right panel working (with no instruments yet).
Logged

"We watched the tragedy unfold, we did as we were told, we bought and sold." - Roger Waters, Amused to Death
Bibi Uncle
Full Member
***
Posts: 15


Project Mercury Developer


View Profile
« Reply #6 on: June 13, 2011, 06:30:12 PM »

OK, I go back to work after a long period.

I was looking to the code and I think that it is not very easy to develop using it. Everything is in huge functions, hard to find. The code is not separated nor divided in small classes. So, I think that we should work on a new C++ organisation, and this is what I thought about.

We have our principal class, called Atlas or Redstone. This one inherits from VESSEL3, as usual and has every Orbiter callbacks. However, this main class do not has any other functions except for the callbacks, constructor/destructor and DLL callbacks. It only contains pointers small classes (for example, Mesh handling, sequencer, panel instruments, etc.). These small classes all inherits from a class called AtlasComponent (or something like that). This class contains only an Atlas pointer which is created in the constructor (using a this). So, every classes can communicate between them using the pointer and future developers could easily find where the desire code is and create new classes to extend our Mercury simulation.

I am currently working on somekind of framework, you can see my progress in the 6.0 branch of Mercury in the SVN database.

EDIT:
The new interface is ready. I included a little text file to guide you. It should be easy to use. Download the 6.0 branch to see it.
« Last Edit: June 13, 2011, 07:44:39 PM by Bibi Uncle » Logged

"We watched the tragedy unfold, we did as we were told, we bought and sold." - Roger Waters, Amused to Death
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!