Project Multistage2015 - Development Thread

1) I just thought about launch effects... " space shuttle" has two sources of steam/smoke clouds, when orbiter starts engines - 6 secs before liftoff - in the front direction, and 1 sec before liftoff - from SRB's - in the opposite deflecting direction. Maybe some option with "time shift" is possible?
I'd like to keep it as simple as possible. I'll think about it to see if there is a simple way to do it other than add fake boosters or something like that.

2) MS_CAMERA exhibits Orbiter graphic client's problem - heavy flickering (z-buffer fight?), when zoomed in from a distance... not a multistage problem though...

noticed that too, but can't do much about it :shrug:

P.S. Also (but it also is not a direct multistage problem) I still think how to improve these launch smoke clouds, because they have blurry edges when grown up (because of "growth factor")... in real life they have sharper edges. One solution would be - not make this "growing up", but then they stay low above the ground, no high "clouds".
Another - another texture "contrailxx.dds" with very sharp edges, and after defining in pstream2, so when even after "growing up" it still has sharp edges?

proper combination of texture and parameters could be the solution, but I think this is totally up to the single users of Multistage

P.S. 2 - I noticed that after ~1 min after launch, clipping effect happens, ground is clipped - black (if <300 m above) , also launch smoke's underground part becomes visible as well. That is when I do not follow rocket in Orbiter's ground camera mode, but look at launch pad.

you're right about this. I think it's related to the camera position of the launchpad (which is right on the ground) for some reason that I cannot know because it's inside orbiter. I'll try to change this and see if we get rid of the effect.

I think point 5 should be skiped for the moment. You are probably very close to release and trying to fix point 5 could lead you to unexpected guidance errors.

Point is that the way heading is calculated is a bit of heavy math, but pure trigonometry and not vector calculation. If I can rework the equations with the vectors (especially with the cross product of velocity and position) then everything will be solved, but it's not easy so I'll see about this at the very end and if it becomes "dangerous" I'll leave it as it is.

Thanks for your feedbacks guys! :cheers:

---------- Post added at 23:24 ---------- Previous post was at 21:52 ----------

I was building the GravTurn command and I realized that there is already the AOA command. Shouldn'it be fine?

---------- Post added at 23:32 ---------- Previous post was at 23:24 ----------

same link updated:
http://www.intech-srl.eu/MS2015WIP.zip

to sum, what should work here:
1) CTD on updating when in Hangar - SOLVED
2) Camera issues - Should be SOLVED
3) Check all the angles between reading and writing from and to the ini file - Should be OK
4) Add a GravTurn Call to the guidance program - to be started, should not be too difficult - NOT NEEDED; USE AOA CALL
5) Try to solve the orbit guidance program issue when the velocity passes from northward to southward or the opposite - WILL BE TRIED
6) having a pad blow up - Should be SOLVED
7) scenarios with pad issues - I don't know if there are issues with scenario setup, i don't have any
 
Edit: all following comments refer to the version BEFOR the one just posted an hour ago. I'll test that later.

I've been working with adding different payloads in DMD mode and here are my issues:

1) If you delete a payload, there is no way to save the change to the ini file. The payload reappears as soon as I update. This might be true for other items as well.

2) If I choose hide the fairing or hide half fairing, an update causes the fairing to be re-displayed. This is very annoying because I have to go back to the fairing section and reselect the option. The purpose of hiding the fairing is so that I can nudge my payload around and see the change as quickly as possible right? So just be sure that the fairing options are respected upon update.

Is there any way to position the camera vessel before the scenario starts? Where is it being placed relative to the rocket?

The camera still does not appear when there is a hangar/crawler also in the scenario.

Regarding the scenario pad issues...

The new features tend to work as advertised in YOUR very "clean" test scenarios. However, I see a lot more problems in MY test scenario that was produced by a quicksave. It seems that scenarios generated by quicksave are a lot "dirtier" and include new pad vessels and attachments and so on. There seems to be more problems in these dirty scenarios. For example, a CAMERA in my test scenario causes a CTD on scenario load.

Perhaps you could just document what lines or vessels should be deleted from a quicksave scenario file to ensure compatibility?

What is the RAMP keyword?
 
Last edited:
Thank you very much for the feedbacks

1) If you delete a payload, there is no way to save the change to the ini file. The payload reappears as soon as I update. This might be true for other items as well.

Correct, I'll see if I can add a general "save" button for keeping memory of deleted items. There might be numerical issues if a sequence is broken (i.e. if you delete payload 1 and keep payload 2) but I'll see if that's avoidable. In the meantime there's also the ini "live" editor if you want to work without waiting this update.

2) If I choose hide the fairing or hide half fairing, an update causes the fairing to be re-displayed. This is very annoying because I have to go back to the fairing section and reselect the option. The purpose of hiding the fairing is so that I can nudge my payload around and see the change as quickly as possible right? So just be sure that the fairing options are respected upon update.

Yep, it's more than reasonable to ask for this. I think it shouldn't be too messy to do it

Is there any way to position the camera vessel before the scenario starts? Where is it being placed relative to the rocket?

by now it's positioned 0.01 Deg latitude North and 0.03 Deg longitude East of the rocket. It is possible to move it and save through scenario editor though. Maybe I can make the camera call in the scenario file something like "CAMERA 0.01 0.03" in order to set directly it's position, would that be ok?

The camera still does not appear when there is a hangar/crawler also in the scenario.
Correct, the routine that creates it is not called if in hangar mode... I have to say that I can't remember if there was a reason for this :lol:, but I think it was just because I didn't thought about having the camera and the hangar together, I'll fix this easily.

Regarding the scenario pad issues...

The new features tend to work as advertised in YOUR very "clean" test scenarios. However, I see a lot more problems in MY test scenario that was produced by a quicksave. It seems that scenarios generated by quicksave are a lot "dirtier" and include new pad vessels and attachments and so on. There seems to be more problems in these dirty scenarios. For example, a CAMERA in my test scenario causes a CTD on scenario load.

Perhaps you could just document what lines or vessels should be deleted from a quicksave scenario file to ensure compatibility?
The "Philosophy" is basically this: if you want to build up your own scenario from scratch, you will need just a few lines, then the module will do its work by itself. But there's a lot to do and to save in order to ensure correct reloading that's why you see all those values. Also Vinka's multistage was doing something like this, even if it needed more default parameters.

There might be issues with this, but unfortunately we have to go through each one to see where are the mistakes. I hope the camera fix will sort out the issues about it. If the camera creates more issues than up sides I also can discard it from the final release

Anyway I can write down the full set of what's saved and explain what is automatically saved and what is mandatory input from users, in the meantime use my scenario as first reference to build up yours. This thing of a clean and simple start scenario was created to help users to prepare everything in few clicks. Basically when you're happy with the location, the height on ground etc you can quicksave, reopen and delete everything not needed like in the ones I posted. Hope this helps a bit

What is the RAMP keyword?

When loaded on ground (configuration 0) MS2015 creates its own launchpad on site and attaches itself to it, ready for launch. If you close and reopen the simulation it must know if the ramp is already there or not, otherwise it will create another one, that's why the word ramp is there, to let him know that it has already a ramp and it doesn't need to create a new one.


I really appreaciate your help guys. i'm sure it's a bit frustrating to work without full documentation so with a lot of unknowns, but it's an endless chase between work and docs until the work is over.

:tiphat:

---------- Post added at 02:02 ---------- Previous post was at 01:14 ----------

Since I was working on it I updated at the same link the updated version with the following requested bug fix:
- Hide Fairing / Hide half Fairing should now be kept even if the vehicle is reset
- camera appears now also in scenarios with hangar
- you can choose camera position in scenario file by putting
Code:
CAMERA xxx yyy         ; xxx is the Delta Latitude and yyy is the Delta Longitude compared to the vessel position. If you don't put anything (or if you put 0 0) the default values are 0.01 and 0.03

cheers
 
Correct, I'll see if I can add a general "save" button for keeping memory of deleted items. There might be numerical issues if a sequence is broken (i.e. if you delete payload 1 and keep payload 2) but I'll see if that's avoidable. In the meantime there's also the ini "live" editor if you want to work without waiting this update.

My main concern is that the delete button is deceptive, it does not really delete in the ini where it matters. This will cause much confusion.

Perhaps just get rid of useless delete buttons and explain in the documentation how to properly use ini "live" editor to delete and renumber things?


Maybe I can make the camera call in the scenario file something like "CAMERA 0.01 0.03" in order to set directly it's position, would that be ok?

Good idea.
 
It is possible to make linear RCS to have same ISP as the stage and not ISP*10 ?
 
CAMERA is extremely useful, even with flickering or some other issues! Absolutely a must have. Real launch... (except for annoying thing that OrbiterSound does not give sound, when not focused on launching vehicle).
 
It is possible to make linear RCS to have same ISP as the stage and not ISP*10 ?

I'll see. But I don't completely understand this request: your basically requesting to have linear thrusters that consume fuel as the stage thrusters, but if the power is different then the the consuming will be different anyway... and if the power is the same it means you are using the stage thrusters. So I'm puzzled about the needing of this :idk:


CAMERA is extremely useful, even with flickering or some other issues! Absolutely a must have. Real launch... (except for annoying thing that OrbiterSound does not give sound, when not focused on launching vehicle).

I'm glad it's appreciated!
Relevant to OrbiterSound at the moment I'm not adding the full support, since the definitive version of OrbiterSound for Orbiter2016 is not out yet. I'll add it when the OrbiterSound library will be out.

in the last updated I put online yesterday there is also another possibility that I think will be very useful to developers: in the misc section you can now add the item "Pad_Module = xxxx" and instead of using the empty launchpad module used by default users can use their own launchpad modules.
On top of that I added a couple of responses accessible through "clbkGeneric" that will allow other modules (including pads) to know live MET and if autopilot is active or not. So developers will be able to build their own pads dlls and trigger certain animations or certain fire effects from them (even sound suppression system etc) at certain moments of the countdown.
 
I'll see. But I don't completely understand this request: your basically requesting to have linear thrusters that consume fuel as the stage thrusters, but if the power is different then the the consuming will be different anyway... and if the power is the same it means you are using the stage thrusters. So I'm puzzled about the needing of this :idk:

For rotational thrusters you have to define the thrust as it is at 1 meter of COG. When you have a stage bigger than 1 meter you will have to multiply that value. So as a workaround you will have to multiply 10x, 100x the ISP otherwise you will empty your tank very soon. (This is what I think is implemented for rotational thruster; high ISP to cover high thrust; this is necessary to keep compatibility with vinka's old multistage)

Linear thrusters (at least forward and backward) could be used for small orbit adjustments. Also when you have high ISP (10x,100x), using these thrusters, you will have unrealistic very high delta-v. These thrusters are new (not implemented in vinka's multistage), so it should not be any compatibility problem.

This is not an issue, so if it is to complex to change or it is not clear what I mean, skip this request :)
 
http://imgur.com/a/3nbt8

https://en.wikipedia.org/wiki/Space_Launch_System#/media/File:Orange_tank_SLS_-_Post-CDR.jpg

I've updated the SLS Fred. I've made it so it closely resembles the latest renderings of NASA. Updated the core stage with HD textures, removed one engine, reworked the meshes, added details to the boosters and core stage. Oh, and a pretty nice booster contrail. It uses the EUS from another SLS project. I'm not sure if you can add it in your add-on, this is my first attempt at making something in orbiter and I don't know the etiquettes when using other peoples work. Although I've tweaked the EUS too.:)

I'll have to organise it in a downloadable package. Soon to be downloaded.
 
Last edited:
Hey Longjap,I am curious to know what are those two control panels on the left hand side of your imgur pics?BTW nice job on the SLS.Thanks
 
Hey Longjap,I am curious to know what are those two control panels on the left hand side of your imgur pics?BTW nice job on the SLS.Thanks
Top: Orbiter Camera dialog
Bottom: Windows Screen Keyboard
 
@crisbeta: I'll try to add a specific parameter, maybe usable only through the .ini file and not in the DMD, since it's a minor point.

@Longjap: I think that your work is amazing and that you deserve the whole credit for it, so once finished you should upload it directly to orbithangar. You can ask here help, i'll be glad to help you through the addon package preparation. In case you prefer having it inside the multistage package of course i can add it to it with full credits to you. But i think you deserve your own page on OH to post this :cheers:
 
I rather like the Saturn V- looking SLS with the more powerful upper stage. :)
 
@Longjap: I think that your work is amazing and that you deserve the whole credit for it, so once finished you should upload it directly to orbithangar. You can ask here help, i'll be glad to help you through the addon package preparation. In case you prefer having it inside the multistage package of course i can add it to it with full credits to you. But i think you deserve your own page on OH to post this :cheers:

Thanks Fred18, I'll do that. I'll add it to OH when I'm done with the whole family of SLS and I'm almost done with that. I certainly need some help packaging it. But I don't want to hijack your thread. I think I should create a new thread for that. I'll be honoured if you add the IB cargo in your add-on next to your own. After learning your add-on and vinka's I can contribute something of my own after decades of leeching and not willing to get into coding. :)

I have a question though. For the 1a block with Orion I'm struggling a bit with the LES. I presume the LES added in Multistage isn't capable of actually launch the payload in case of an emergency or am I wrong? So when I make Orion a live payload, and add the LES/LAS of this module to the vehicle it works to a degree, but when I try to launch it the Orion keeps being attached to the SLS. It loses it's service module but the Orion keeps being stuck and attached. Is there any work around so I can make it work?

BTW a small bug report; some values in the DM are not updated in the .ini file. I noticed that the engine values of a stage are not updated in the .ini when changed and saved. So you have to do it and save it within the .ini itself. Also when I've worked inside the DM Orbiter refuses to close and go back to the launchpad interface. When I do not there is no problem.

Hey Longjap,I am curious to know what are those two control panels on the left hand side of your imgur pics?BTW nice job on the SLS.Thanks

Yeah, I'm working on a mac with bootcamp. I don't have a printscreen key so I use the on-screen keyboard. Nothing fancy. ;)
 
Thanks Fred18, I'll do that. I'll add it to OH when I'm done with the whole family of SLS and I'm almost done with that. I certainly need some help packaging it. But I don't want to hijack your thread. I think I should create a new thread for that. I'll be honoured if you add the IB cargo in your add-on next to your own. After learning your add-on and vinka's I can contribute something of my own after decades of leeching and not willing to get into coding. :)

:thumbup: that's what Multistage is built for :)

I have a question though. For the 1a block with Orion I'm struggling a bit with the LES. I presume the LES added in Multistage isn't capable of actually launch the payload in case of an emergency or am I wrong? So when I make Orion a live payload, and add the LES/LAS of this module to the vehicle it works to a degree, but when I try to launch it the Orion keeps being attached to the SLS. It loses it's service module but the Orion keeps being stuck and attached. Is there any work around so I can make it work?

I see. The les module was meant to become "real" once jettisoned using the "module" call, and that was the idea of doing the trick. But in your case with a live payload it's totally different. I assume you're not getting into the code of it, and that's the hard part because a workaround without touching the code is not easy... I'll think about it a bit and let you know. Can you post a screenshot of it?

BTW a small bug report; some values in the DM are not updated in the .ini file. I noticed that the engine values of a stage are not updated in the .ini when changed and saved. So you have to do it and save it within the .ini itself.
About the values: do you press "save values" before updating? it's crucial, is there in order to assure that you are willing to update the values and not by mistake. If you press "save values" before updating then I'll go to make sure that everything is written correctly, but at the moment to me it appears to work as it should.

Also when I've worked inside the DM Orbiter refuses to close and go back to the launchpad interface. When I do not there is no problem.
Really? that's a first for this, you mean by pressing CTRL+Q or clicking on exit?


In the meantime i'm struggling a bit to make the "delete" function in the DMD for payloads, particles, stages, etc consistent and working correctly but it's a bit more complicated than I thought... :coffee:

---------- Post added 27th Sep 2016 at 18:54 ---------- Previous post was 26th Sep 2016 at 23:37 ----------

Hi all,

I spent half of the day implementing a delete function that works properly and now I was about to publish the update, but I just realized that there is a quicker and more efficient way to do it :facepalm: so... I'll be back soon :lol:

PS: in the meantime I corrected some bugs here and there of the DMD, so it was not useless!
 
:thumbup: that's what Multistage is built for :)
I spent half of the day implementing a delete function that works properly and now I was about to publish the update, but I just realized that there is a quicker and more efficient way to do it :facepalm: so... I'll be back soon :lol:

take a little rest ....:coffee:
 
Thanks for your replies.

I see. The les module was meant to become "real" once jettisoned using the "module" call, and that was the idea of doing the trick. But in your case with a live payload it's totally different. I assume you're not getting into the code of it, and that's the hard part because a workaround without touching the code is not easy... I'll think about it a bit and let you know. Can you post a screenshot of it?

http://imgur.com/a/5u0GM

It keeps firing until fuel runs out but it doesn't move. To be clear this is the LES embedded in the module. You can put a "MODE 10" line in the Orion ship section of the scenario to add the LES to the module.
The scenario after firing the LES:
Code:
BEGIN_DESC

END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 58449.5381555025
  Help CurrentState_img
END_ENVIRONMENT

BEGIN_FOCUS
  Ship Orion
END_FOCUS

BEGIN_CAMERA
  TARGET Orion
  MODE Extern
  POS 11.148998 -58.041488 21.054965
  TRACKMODE Ground Earth
  GROUNDLOCATION -80.60290 28.60666 108.99
  FOV 30.00
END_CAMERA

BEGIN_MFD Right
  TYPE User
  MODE Multistage2015_MFD
END_MFD

BEGIN_SHIPS
SLS:Multistage2015
  STATUS Landed Earth
  POS -80.6040070 28.6083600
  HEADING 0.00
  ALT 56.860
  AROT 151.065 -8.240 4.530
  ATTACHED 0:0,MS_LaunchPad_SLS
  AFCMODE 7
  PRPLEVEL 0:1.000000 1:1.000000 2:1.000000 3:1.000000 4:1.000000
  NAVFREQ 0 0 0 0
  XPDR 0
  CONFIG_FILE Config\Multistage2015\SLS_BLOCKIAORION_LES_day.ini
  GUIDANCE_FILE Config\Multistage2015\Guidance\SLS_EM1_Orion_GNC.txt
  CONFIGURATION 0
  COMPLEX 
  CURRENT_BOOSTER 1
  CURRENT_STAGE 1
  CURRENT_INTERSTAGE 1
  CURRENT_PAYLOAD 1
  FAIRING 1
  MET -10.000
  BATTERY 5400.000000
  GROWING_PARTICLES 
  STAGE_IGNITION_TIME 0.000000
  STAGE_STATE 1
  TELEMETRY_FILE Config\Multistage2015\Telemetry\SLS_EM1_Orion_GNC.txt
  ALT_STEPS 200.0,350.0,1400.0,35000.0
  PEG_PITCH_LIMIT 35.000
  PEG_MC_INTERVAL 0.100
  RAMP 
END
SLSTOWER2:SLS\SLSTOWER2
  ARM_STATUS 0.7191 0.0000 0.0000 1.0000 0.0000 0.5705 0.0000 0.0000 0.0000 0.9815 0.0000 0.0000 0.0830 0.0000 0.0000 0.0000 0.0000 0.4759
  ARM2_STATUS 0.0034 0.0000 0.1682 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 
  POST 1 
  TOUCH -74.0430 
  STATUS Landed Earth
  POS -80.6040070 28.6084440
  HEADING 180.57
  ALT 73.857
  AROT -118.018 -3.869 171.717
  AFCMODE 7
  NAVFREQ 0 0
  XPDR 0
END
WATERTOWER:SLS\WATERTOWER
  STATUS Landed Earth
  POS -80.6025360 28.6096140
  HEADING 0.00
  ALT 2.000
  AROT 61.715 4.484 8.267
  AFCMODE 7
  NAVFREQ 0 0
END
LIGHTNING1:SLS\LIGHTNINGTOWER
  STATUS Landed Earth
  POS -80.6029860 28.6086140
  HEADING 0.00
  ALT -0.194
  AROT 61.328 4.540 8.236
  AFCMODE 7
  NAVFREQ 0 0
  XPDR 0
END
LIGHTNING2:SLS\LIGHTNINGTOWER
  STATUS Landed Earth
  POS -80.6050760 28.6098640
  HEADING 0.00
  ALT -0.194
  AROT 61.326 4.539 8.234
  AFCMODE 7
  NAVFREQ 0 0
  XPDR 0
END
LIGHTNING3:SLS\LIGHTNINGTOWER
  STATUS Landed Earth
  POS -80.6052660 28.6076340
  HEADING 0.00
  ALT -0.194
  AROT 61.329 4.539 8.234
  AFCMODE 7
  NAVFREQ 0 0
  XPDR 0
END
LP39:SLS\LP39PAD
  STATUS Landed Earth
  POS -80.6035360 28.6080240
  HEADING 0.00
  ALT 2.000
  AROT 61.716 4.484 8.266
  AFCMODE 7
  NAVFREQ 0 0
END
SPOTLIGHT1:spotlight2
  STATUS Landed Earth
  POS -29.1959147 2.4561787
  HEADING 66.68
  ALT 0.186
  AROT 25.070 -22.265 75.772
  ATTACHED 0:0,LP39
  AFCMODE 7
  NAVFREQ 0 0
  SPT 0 300.0000 1.0472
  PAT 2.0000 36.5000 95.2500 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000
  GBL 0.47846 0.60696
END
SPOTLIGHT2:spotlight2
  STATUS Landed Earth
  POS -29.3783550 2.4074486
  HEADING 66.68
  ALT 0.186
  AROT 25.110 -22.449 75.730
  ATTACHED 0:1,LP39
  AFCMODE 7
  NAVFREQ 0 0
  SPT 0 300.0000 1.0472
  PAT 3.2000 37.5000 -6.1000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000
  GBL 0.70929 0.86793
END
SPOTLIGHT3:spotlight2
  STATUS Landed Earth
  POS -29.8439529 2.2257810
  HEADING 66.66
  ALT 0.186
  AROT 25.244 -22.932 75.661
  ATTACHED 0:2,LP39
  AFCMODE 7
  NAVFREQ 0 0
  SPT 0 300.0000 1.5708
  PAT -111.0000 38.0000 -7.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000
  GBL 0.61562 0.15286
END
SPOTLIGHT4:spotlight2
  STATUS Landed Earth
  POS -30.5357169 1.9577504
  HEADING 66.64
  ALT 0.186
  AROT 25.437 -23.652 75.557
  ATTACHED 0:3,LP39
  AFCMODE 7
  NAVFREQ 0 0
  SPT 0 300.0000 1.0472
  PAT -104.0000 38.5000 95.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000
  GBL 0.60889 0.37186
END
SPOTLIGHT5:spotlight2
  STATUS Landed Earth
  POS -35.1000667 0.9537060
  HEADING 66.58
  ALT 0.186
  AROT 26.650 -28.108 74.141
  ATTACHED 0:4,LP39
  AFCMODE 7
  NAVFREQ 0 0
  SPT 0 300.0000 0.3491
  PAT -101.5000 23.0000 29.7000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000
  GBL 0.82165 0.23533
END
SPOTLIGHT6:spotlight2
  STATUS Landed Earth
  POS -36.6896990 0.5215900
  HEADING 66.57
  ALT 0.186
  AROT 27.139 -29.681 73.670
  ATTACHED 0:5,LP39
  AFCMODE 7
  NAVFREQ 0 0
  SPT 0 300.0000 1.0472
  PAT 2.5000 23.0000 57.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000
  GBL 0.82956 0.68404
END
Orion:Orion-MPCV\Orion-MPCV
  STATUS Landed Earth
  POS -80.6040070 28.6083600
  HEADING 0.00
  ALT 104.960
  AROT 6.296 14.888 -171.528
  ATTACHED 1:0,SLS
  AFCMODE 7
  NAVFREQ 0 0
  XPDR 468
  MODE 12
  WATER 0
END
MS_LaunchPad_SLS:EmptyModule
  STATUS Landed Earth
  POS -80.6040070 28.6083600
  HEADING 0.00
  ALT -0.011
  AROT 151.065 -8.240 4.530
  AFCMODE 7
  NAVFREQ 0 0
END
Orion-SM:Orion-MPCV\Orion-SM
  STATUS Landed Earth
  POS -80.6040078 28.6083327
  HEADING 0.11
  ALT 1.984
  AROT 61.699 4.372 8.264
  AFCMODE 7
  NAVFREQ 0 0
END
Orion-fair1:Orion-MPCV\Orion-MPCV-fair1
  STATUS Orbiting Sun
  RPOS 221601493512.173 -2563714349.772 6305456475.217
  RVEL 1465973006.6333 -23447294.8491 -1174086296.2824
  AROT -142.977 -66.024 -96.193
  VROT -2113.3118 -3468.9690 -135.0506
  AFCMODE 7
  NAVFREQ 0 0
END
Orion-fair2:Orion-MPCV\Orion-MPCV-fair2
  STATUS Orbiting Sun
  RPOS -542235380479.967 323738832832.818 217102971541.496
  RVEL -5575254167.3378 2984861183.5839 768608340.8548
  AROT 158.320 25.763 -72.889
  VROT 6939.4471 2493.7871 40.4623
  AFCMODE 7
  NAVFREQ 0 0
END
Orion-fair3:Orion-MPCV\Orion-MPCV-fair3
  STATUS Orbiting Sun
  RPOS -57844117430.550 59184091984.255 162961397391.528
  RVEL -1109535756.0462 545855102.7703 269495545.7945
  AROT -49.305 10.815 -41.691
  VROT 17348.0069 -4800.6330 24.0967
  AFCMODE 7
  NAVFREQ 0 0
END
END_SHIPS

About the values: do you press "save values" before updating? it's crucial, is there in order to assure that you are willing to update the values and not by mistake. If you press "save values" before updating then I'll go to make sure that everything is written correctly, but at the moment to me it appears to work as it should.

Yep, I do. It only happens in the stages section. The boosters engine values work fine for me.

Really? that's a first for this, you mean by pressing CTRL+Q or clicking on exit?

Correct, after clicking exit. I've uploaded some scenario's to the SLS project. If you have some extra time maybe you can see if you have the same problem. I've seen this behaviour before with other add-ons. Maybe its my computer. :)

:tiphat:
 
Limitation of height for single stage config

I tried to make a config file for a single stage amateur rocket motor. The sizes for this kind of engine are very small.

When I set height lower than 12 the mesh will not show. Looks like the issue is a limit in calculation of the distance of the camera position.

Code:
[MISC]
cog=0.1

[STAGE_1]
MeshName="SLS\core"
Height=1
Diameter=0.054
EmptyMass=0.457
FuelMass=0.350
Thrust=98.96
BurnTime=6.2
off=(0.,0,0.)
ENG_1=(0,0,-15.7)
ENG_diameter=0.7
speed=(0,0,-3)
 
I tried to make a config file for a single stage amateur rocket motor. The sizes for this kind of engine are very small.

When I set height lower than 12 the mesh will not show. Looks like the issue is a limit in calculation of the distance of the camera position.

Code:
[MISC]
cog=0.1

[STAGE_1]
MeshName="SLS\core"
Height=1
Diameter=0.054
EmptyMass=0.457
FuelMass=0.350
Thrust=98.96
BurnTime=6.2
off=(0.,0,0.)
ENG_1=(0,0,-15.7)
ENG_diameter=0.7
speed=(0,0,-3)

do you mean that if you change the parameter "height" from 12 to 11 the mesh does not show?

---------- Post added at 23:41 ---------- Previous post was at 23:20 ----------

Thanks for your replies.



http://imgur.com/a/5u0GM

It keeps firing until fuel runs out but it doesn't move. To be clear this is the LES embedded in the module. You can put a "MODE 10" line in the Orion ship section of the scenario to add the LES to the module.
The scenario after firing the LES:

the issue here is the following: to create a live payload MS2015 simply creates on the payload and on itself attachment points and then connects one to each other. When Orion is firing the LES no one is telling neither to Orion nor to the MS2015 to cut the attachment and that's why they remain connected. The problem is that without changing the code of the orion (saying for example that if the les is fired it has to cut all the attachments) I don't know how to tell to Orion or to MS2015 to cut the connection... I'm thinking about it, but still can't find a solution.

Yep, I do. It only happens in the stages section. The boosters engine values work fine for me.
You're right, I found the error, it will be ok in the next release, Thank you!

Correct, after clicking exit. I've uploaded some scenario's to the SLS project. If you have some extra time maybe you can see if you have the same problem. I've seen this behaviour before with other add-ons. Maybe its my computer. :)

:tiphat:

Do you do in your orbiter shutdown options (extra->Debugging options -> orbiter shutdown options) the terminate orbiter process or respawn orbiter process? it should be one of these two to be safe, even though MS2015 actually doesn't use any global variable
 
Back
Top