Project G42-200 StarLiner

[dgatsoulis]

For the external animations (landing gears and payload bay) these are the changes needed to work properly. (Group swaps in the G422_ext.msh)

The column on the left is the current order from the OH download and on the right the "correct" order for the animations to work properly.

|#|Label|#|Label
|55|Object1275|55|Object1275|
|56|Object1328|56|Object1328|
|57|Object1346|57|Object1346|
|58|bay_detail|58|BAY_DOOR_L|
|59|Cylinder007|59|RADIATOR_L|
|60|BAY_DOOR_L|60|bay_detail|
|61|RADIATOR_L|61|Cylinder007|
|62|WINGS|62|WINGS|
|63|RCS_DOOR_R|63|RCS_DOOR_R|
|64|RCS_THRUSTERS_R|64|RCS_THRUSTERS_R|
|65|Object1386|65|Object1386|
|66|RCS_DOOR_L|66|TAILWHEEL_DOOR_L|
|67|RCS_THRUSTERS_L|67|TAIL_WHEEL|
|68|TAILWHEEL_DOOR_L|68|TAILWHEEL_DOOR_R|
|69|TAIL_WHEEL|69|RCS_THRUSTERS_L|
|70|TAILWHEEL_DOOR_R|70|RCS_DOOR_L|
|71|VISOR_EXT_WINDOWS|71|VISOR_EXT_WINDOWS|

Visor, canards and wing position seem unaffected.

The main problem is with the VC. Most of the switch animations are incorrect and the MFDs don't show anything (MFD buttons seem ok though).

A big thanks to Face for providing the 2016 dll.

 

[Face]

For the external animations (landing gears and payload bay) these are the changes needed to work properly. (Group swaps in the G422_ext.msh)

The column on the left is the current order from the OH download and on the right the "correct" order for the animations to work properly.
<snip>
The main problem is with the VC. Most of the switch animations are incorrect and the MFDs don't show anything (MFD buttons seem ok though).

I could swap those numbers in the code, but there's this impression that we are missing some intermediate asset here. Switch animations could also be a problem of mesh groups.

 

[JMW]

there's this impression that we are missing some intermediate asset here

Only Moach knows I suppose............ :shifty::stirpot:

 

[Face]

After running a quick awksedgrep over the meshes like this:

grep LABEL G422_dvc.msh | sed "s/LABEL /#define MGID_/g" | awk '{printf "%s %d\n", $0, NR-1}'

I can say that the code at Github was done for different versions of G422_ext.msh and G422_dvc.msh than those available from the OHM download.

While the exterior mesh only missed the bay antenna dish - which I can compensate by means of keeping that out of the animation chain - the VC mesh misses the EICAS areas, so that feature would be lost completely .

Perhaps Moach can release the appropriate meshes that fit the code. BTW: what about the license for those assets? If that also would fit into MIT, would it be possible to simply check them into the Github repo?

In the meantime, this is the needed patch for the MFDs in the G422_dvc.msh:

diff --git a/Meshes/G422/G422_dvc.msh b/Meshes/G422/G422_dvc.msh
--- a/Meshes/G422/G422_dvc.msh
+++ b/Meshes/G422/G422_dvc.msh
@@ -3502,7 +3502,7 @@
 LABEL MFD_6~3
 MATERIAL 17
 TEXTURE 0
-FLAG 3
+FLAG 0
 GEOM 4 2 ; MFD_6~3
 -0.217989 2.41219 39.1401 -0.00170384 0.384724 -0.92303 0.9995 0.998428
 -0.218588 2.50923 39.1805 -0.00151818 0.38488 -0.922965 0.993774 0.00150812
@@ -3513,7 +3513,7 @@
 LABEL MFD_4~3
 MATERIAL 17
 TEXTURE 0
-FLAG 3
+FLAG 0
 GEOM 4 2 ; MFD_4~3
 0.291272 2.3788 39.1099 0.0 0.763902 -0.645333 0.00114524 0.000499487
 0.291206 2.30886 39.0262 -1.19391e-007 0.763902 -0.645333 0.000499487 0.9995
@@ -13438,7 +13438,7 @@
 LABEL MFD_1~3
 MATERIAL 17
 TEXTURE 0
-FLAG 3
+FLAG 0
 GEOM 4 2 ; MFD_1~3
 0.251312 2.50925 39.1808 0.000532727 0.4029 -0.932024 1.0 0.0
 0.149265 2.50935 39.1808 0.00133078 0.403546 -0.931767 0.0 0.0
@@ -13449,7 +13449,7 @@
 LABEL MFD_2~3
 MATERIAL 17
 TEXTURE 0
-FLAG 3
+FLAG 0
 GEOM 4 2 ; MFD_2~3
 0.537702 2.41026 39.1404 0.00197143 0.399691 -0.933286 0.9995 0.99328
 0.536846 2.50921 39.181 0.00121593 0.400315 -0.933043 0.991252 0.000589371
@@ -13460,7 +13460,7 @@
 LABEL MFD_3~3
 MATERIAL 17
 TEXTURE 0
-FLAG 3
+FLAG 0
 GEOM 4 2 ; MFD_3~3
 0.394458 2.50923 39.1809 0.00054879 0.401313 -0.932651 1.0 0.0
 0.289121 2.50925 39.1808 0.00121103 0.401868 -0.932432 0.0 0.0
@@ -17239,7 +17239,7 @@
 LABEL MFD_5~3
 MATERIAL 17
 TEXTURE 0
-FLAG 3
+FLAG 0
 GEOM 4 2 ; MFD_5~3
 -0.470854 2.50948 39.181 -0.00151955 0.384171 -0.923261 0.000499725 0.000499487
 -0.470154 2.41194 39.1405 -0.00170264 0.384325 -0.923196 0.00712109 0.9995

In essence the flags of the MFD mesh groups need to be zero instead of 3.

I've update the DLL posted before to reflect the changes. Animations and MFD should then work again.

Oh... what the hell is the windshield thingy ?

 

[dgatsoulis]

Animation fixes confirmed and also the VC switches now seem to be working ok. Not sure what was wrong before, so I re-downloaded the OH meshes.
Also changed the MFD groups flags to 0, so I can also confirm all 6 MFDs working properly. :thumbup:

Thank you very much Face!
I'll find the ops manual and try to take it for spin in a couple of hours.

 

[sphinxbot]

Thanks for bringing this one back to life! I have one problem though; after I start the engines the whole thing turns upside down and rests on the inverse of level. (contact points at ground level but inverted, whole ship under ground)

 

[Face]

Thanks for bringing this one back to life! I have one problem though; after I start the engines the whole thing turns upside down and rests on the inverse of level. (contact points at ground level but inverted, whole ship under ground)

Yes, I notice this too. It is due to the new touchdown points definition in 2016. In essence you have to calculate a springy suspension for the craft, and as of yet I was unable to come up with a proper solution. I've resorted to copying the DG definition, but that is not suitable for the huge propellant masses the G42 brings to the table. Just lowering the empty mass to what DG has is not doing the trick.

I think there is a bug somewhere in Orbiter causing huge masses to overreact, no matter what definition you apply. I have to check that hypothesis.

I really miss the easy plane definition of the old days .

---------- Post added at 22:08 ---------- Previous post was at 19:41 ----------

DLL is updated. After reading 2-3 hours into the touchdown points case and experimenting with the G42, I think Orbiter has a problem calculating the touchdown forces properly if huge masses are involved. The lower I get the overall masses, the better the behavior. If it is at DG level, it is perfect, if it gets into the realistic ranges, it is a mess.

Somehow the vessels skids sideways, no matter what lateral coefficient I give it. At least the suspension is better now, so the dreaded thing doesn't flip around as soon as a nanonewton thrust is applied :rofl:.

I guess I'll wait for the patch before I invest more time in this :shrug:.

 

[fred18]

Yes, I notice this too. It is due to the new touchdown points definition in 2016. In essence you have to calculate a springy suspension for the craft, and as of yet I was unable to come up with a proper solution. I've resorted to copying the DG definition, but that is not suitable for the huge propellant masses the G42 brings to the table. Just lowering the empty mass to what DG has is not doing the trick.

I think there is a bug somewhere in Orbiter causing huge masses to overreact, no matter what definition you apply. I have to check that hypothesis.

I really miss the easy plane definition of the old days .

---------- Post added at 22:08 ---------- Previous post was at 19:41 ----------

DLL is updated. After reading 2-3 hours into the touchdown points case and experimenting with the G42, I think Orbiter has a problem calculating the touchdown forces properly if huge masses are involved. The lower I get the overall masses, the better the behavior. If it is at DG level, it is perfect, if it gets into the realistic ranges, it is a mess.

Somehow the vessels skids sideways, no matter what lateral coefficient I give it. At least the suspension is better now, so the dreaded thing doesn't flip around as soon as a nanonewton thrust is applied :rofl:.

I guess I'll wait for the patch before I invest more time in this :shrug:.

I think I have some answers about this topics since I've studied them a lot in the last few months.

relevant to touchdown points Orbiter now simulates a mass, spring, damper system with each touchdown points. When a big force is applied, then the "spring" reacts strongly and this leads to numerical instability in orbiter integration. If the issue is just being upside down it should be enough to change the "verse" in which the first 3 touchdown points are defined: they define a plane with a normal which orbiter uses to get which side is up. If they are defined in the wrong "verse" then the normal is upside down and so the vessel.
Otherwise I came up with a solution that up to now is working quite ok with almost every vessel relevant to touchdown points parameters, made as suggested by martin with the integration of the mass spring damper system:

          double ro = ARBITRARYVALUESIMILARTOSIZE;
	  TOUCHDOWNVTX td[4];

	  double x_target = -0.5;
	  double stiffness = (-1)*(EmptyMass*9.80655) / (3 * x_target);
	  double damping = 0.9*(2 * sqrt(EmptyMass*stiffness));
	  for (int i = 0; i<4; i++)
	  {

		  td[i].damping = damping;
		  td[i].mu = 3;
		  td[i].mu_lng = 3;
		  td[i].stiffness = stiffness;
	  }
	  td[0].pos.x = cos(30 * RAD)*ro;
	  td[0].pos.y = -Height_From_Ground;
	  td[0].pos.z = -sin(30*RAD)*ro;
	  td[1].pos.x = 0;
	  td[1].pos.y = -Height_From_Ground;
	  td[1].pos.z = 1*ro;
	  td[2].pos.x = -cos(30 * RAD)*ro;
	  td[2].pos.y = -Height_From_Ground;
	  td[2].pos.z = -sin(30 * RAD)*ro;
	  td[3].pos.x = 0;
	  td[3].pos.y = 15 * ro;
	  td[3].pos.z = 0;


	  SetTouchdownPoints(td, 4);

9.80655 is G of course. it simply gets the equilibrium at spring compression equal to 0.5 meter, but slightly under dampered (that's the 0.9* in front of the damping equation) so numerical stability is a bit helped.

The other issue of the vessel moving sideway is due to it not finding the IDLE status, because of the new terrain model and the "hills". If the ground is not flat is very difficult to stay steady.

For this (and also for the point above) there is the solution of forcing the vessel landed. The code of GeneralVehicle relies on exactly that, if it may help give it a look (and ask if you need, I'm here!)

cheers
Fred

 

[Face]

I think I have some answers about this topics since I've studied them a lot in the last few months.

I'm sorry, fred18, but I tried all those suggestions already. Of course I've read especially your posts on that subject as well as martins.

Based on your sample code posted in those threads about touchdown-points, I eventually managed to give it a stable sitting regarding the spring simulation, but the sliding definitely has nothing to do with the idle state bug.

In the case of the G42 in the startup "launch to ISS" scenario, while speeding down the runway, you can see (with F9 forces visualization on) that the touchdown-point forces are messed up and cause the sliding.

The code you suggested incorporates a tetrahedron that defines the plane triangle with arbitrary radius around the COG. It can't be right that the real touchdown-points of the vehicle should be ignored in favor of some workaround to get the thing not sliding off the runway.

After all, it should simulate the real forces based on the position of the center of gravity, right? In the case of the G42, the center of gravity is not too far away from the main gears (of course slightly towards the front wheel, not the tail). I guess this together with the huge masses involved causes a bug (some numerical rounding errors perhaps?) to show. If I reduce the masses by factors of 10 (together with the stiffness and damping, of course), it gets better regarding sliding. If I increase them, it gets worse.

Thanks for your help, though. :tiphat:

 

[fred18]

I think that the sliding is due to some error in friction accounting. It happens because if the terrain is not super flat orbiter keeps the vessel going "downhill". Only solution is to force the landing status when you "set the parking breaks". That should work.

 

[Face]

I think that the sliding is due to some error in friction accounting. It happens because if the terrain is not super flat orbiter keeps the vessel going "downhill". Only solution is to force the landing status when you "set the parking breaks". That should work.

I already experimented with the friction coefficients. Both with the direct setter and the touchdown-point structure. Unfortunately to no avail.

Again, it is not the idle status problem that can be fixed with the shadow-save/load dance. It slides while accelerating down the runway. You don't set the parking breaks during lift-off :lol: .

I first thought that there might be a hidden AddForce or somesuch in Moach's code, but there is none. Also the forces visualization shows a clear thrust vector and no torque. Just the touchdown-point forces jitter wildly all around the place, and apparently have a resident sideways component.

 

[Ripley]

...Only solution is to force the landing status when you "set the parking breaks"...

Just as Dbeachy1 did for his XR fleet
https://www.orbiter-forum.com/showthread.php?p=542435&postcount=53

(I'm sure Face is aware of that hack).

 

[fred18]

. It slides while accelerating down the runway. You don't set the parking breaks during lift-off :lol: .

Ah! I didn't get this sorry! Now i understand. Oh for that, unless you want to simulate a vehicle landed up to liftoff there's no solution i can see, you're right!

 

[sphinxbot]

Does the delta-glider show the same bug when you beef up the weights to G42 values?
I would try it myself but I'm a coding illiterate...

 

[Face]

Does the delta-glider show the same bug when you beef up the weights to G42 values?
I would try it myself but I'm a coding illiterate...

That's what my next test will be: create a test-case with the stock DG that everybody can reproduce.

 

[dbeachy1]

Just as Dbeachy1 did for his XR fleet
https://www.orbiter-forum.com/showthread.php?p=542435&postcount=53

(I'm sure Face is aware of that hack).

FWIW, that was ugly hack that I quite disliked adding, and I very much hope that Martin fixes the Orbiter core bug as some point so not everyone will have to implement that gruesome hack in all their vessels.

Anyway, as you can tell, that core bug irks me a bit.

 

[fred18]

FWIW, that was ugly hack that I quite disliked adding, and I very much hope that Martin fixes the Orbiter core bug as some point so not everyone will have to implement that gruesome hack in all their vessels.

Anyway, as you can tell, that core bug irks me a bit.

The ugly hack i suggested you has been now replaced by proper coding that solves many issues of landed vessels. It is used in generalvehicle code, let me know if you want to update your code and you need a hand on that

 

[Moach]

I have noticed that the code on github is indeed built for a version of the model that is a few steps ahead of the one published on the addons site.

this is unfortunate, since the latest models are not where I last remember seeing them in my computer... truth be told, last I saw them was some 2 or three dead hard drives ago

but I do have a habit of keeping backups of such important things in beautifully assembled, uh... piles

so it's gotta be around here somewhere... in one of my flash drives... in one of my piles

I'll find it eventually - then I'll upload the very latest everything that goes with it


not sure if that would solve the suspension issues I just read about... those sound like new stuff for me... haven't tried to rebuild the '42 in a while

but - if the older model has already compiled with the new code, it's probably safe to ignore this slightly-more-up-to-date version anyways... it wasn't really THAT far ahead really


cheers

---------- Post added at 20:09 ---------- Previous post was at 20:06 ----------

oh, that was easy...

it was all on dropbox - d'oh!


hang on while I zip it up for upload

---------- Post added at 20:20 ---------- Previous post was at 20:09 ----------

so well - rather than risk inadvertently deleting anything needed, I just zipped up the entire project folder into a 260-ish megabyte blob...

long gone is the day then that file size would justify actually bothering to remove non-essential files - packing everything without exception should ensure that this zip contains the very same state of the project as I had when I last left it there

and here it is: https://drive.google.com/open?id=0B8JknrBkizVCSkl2QUFxWU5McU0

 

[Interceptor]

Hey Moach,do you remember any of the newest features that you had included in your last state version?,and,BTW nice to see you on OF forum once again:thumbup:.Thanks

 

[Moach]

Hey Moach,do you remember any of the newest features that you had included in your last state version?,and,BTW nice to see you on OF forum once again:thumbup:.Thanks

that I recall, the biggest addition was the full set of EICAS panels with all the display modes functioning (mind that only a few modes had any useful info drawn on them, but the others looked pretty cool anyways)

also, I had properly textured the cargo bay, whereas the last uploaded build still had it clad in "fugly gray"

I was also toying around with the code so that instead of the photoshop-drawn bmp lookup tables for speed and altitude, it based RAMCASTER performance values on a simpler curve interpolating over the operating range of dynamic pressures...
not sure if this was working alright though - so that's a good place to keep an eye out for quirks and bugs. I never really got around polishing it up before "real life" totally got in the way


there's probably a myriad little details I completely forgot about... it has been over four years and a whole different hemisphere when I last worked on it...

luckily for me - I no longer must suffer having to work with Flash for a living - now we use Unity! like civilized folks ought to. so I no longer feel like I must invent a new programming language just to have a tool I tolerate using (although that was actually coming along rather well...) - C# is still verbose as hell, but at least it doesn't spit in the face of good practices and rarely ever works actively against you as you go along...

...long story


anyways, I reckon that zip must be full of surprises - hopefully none bad