New Release Interplanetary Modular Spacecraft RC9

If its not too much of a bother, Im just going to post my configs and scenarios here so others can double-check for me. Maybe I've just done something stupid on my end...
Click to expand...

I will take a look on it later today once I get home from work :-)
 
Thank you all for your hard work. Hopefully I’ll be able to give a try to IMS RC3 next week.
:hailprobe: :cheers:

Michael_Chr said:
It appears that some MFD causes trouble in IMS ships. I have experienced that Pursuit MFD and IMS does not like each other either - presumably on account of the RCS handling that IMS does (the CTD occurs when activating the RCS in eng. screen).
Click to expand...
I had the same experience with IMS RC2.3

Michael_Chr said:
The detailed desciption is that the state of the rcs. (i.e. selected/not selected) is not saved with the scenario. At scenario start it always comes up as "not selected".
Click to expand...
Still with RC2.3, not all of the RCS are selected when opening a saved scenario. I’m used to reselect all of them everytime, as I'm a little manic, but I’m not sure this has an effect. I’ll check later on.
 
Ok, look guys, I'm kinda sorry about this, but I'll have to make a rule here:

Scenarios for Bugreporting in the future have to consist of default modules. It's getting way too much of a headache to track down all the things missing from the packages, and I don't have that kind of time.
Micheal_Chr's scenario, for example, does not only employ custom configs, but those configs also point to custom meshes, which were not provided with the package, and the package would also get somewhat large if it has to include a bunch of textures and meshes, not to mention that I need a clean orbiter install to test every one of them because otherwise I can't get rid of the files anymore.

So, in the future, if you have a bug, please reproduce it using standard modules in standard paths, otherwise it's really way too much trouble to get everything together just to run them. Not to mention that I have to verify the configs themselves for potential bugs.

Anyways, Micheal_Chr, I asked this once in the past, but it might have gone unnoticed. The package you sent me loads a finalised vessel (of which I first had to change the config name before I could go on to notice that I'm missing half the meshes): Does the described behavior with the RCS only happen with finalised vessels, or also with vessels under construction?
 
jedidia said:
Ok, look guys, I'm kinda sorry about this, but I'll have to make a rule here:

Scenarios for Bugreporting in the future have to consist of default modules. It's getting way too much of a headache to track down all the things missing from the packages, and I don't have that kind of time.
Micheal_Chr's scenario, for example, does not only employ custom configs, but those configs also point to custom meshes, which were not provided with the package, and the package would also get somewhat large if it has to include a bunch of textures and meshes, not to mention that I need a clean orbiter install to test every one of them because otherwise I can't get rid of the files anymore.

So, in the future, if you have a bug, please reproduce it using standard modules in standard paths, otherwise it's really way too much trouble to get everything together just to run them. Not to mention that I have to verify the configs themselves for potential bugs.

Anyways, Micheal_Chr, I asked this once in the past, but it might have gone unnoticed. The package you sent me loads a finalised vessel (of which I first had to change the config name before I could go on to notice that I'm missing half the meshes): Does the described behavior with the RCS only happen with finalised vessels, or also with vessels under construction?
Click to expand...

Fair enough. Do we have a decision about how configs will be grouped by default? I personally prefer configs to be grouped under the vessels/IMS folder in folders based on part types (radiators, engines, fuel tanks, batteries, etc...)

Can we agree on that as a standard, and can we update RC3 to reflect that?
 
Can we agree on that as a standard, and can we update RC3 to reflect that?
Click to expand...

No, sorry. That would break coompatibility for everyone that has used the default folder structure, and that wouldn't be fair.

I tried to run your scenario btw, but I'd have to delete so much out of it that I'm not sure the result would count for anything. Future scenarios please without XRs, UCGO cargoes, cars and in general nothing that isn't included in the default orbiter and IMS packages. It's just too time consuming to cut everything out to see what happens, and the results are also not representative.
 
jedidia said:
No, sorry. That would break coompatibility for everyone that has used the default folder structure, and that wouldn't be fair.
Click to expand...

Okay, how about this:

View attachment IMS RC3 Config.zip

Its just that the one thing me & PeterRoss agreed on was that dumping all of the configs into one folder didn't work. It doesnt matter to me how we organize configs in the scenario editor, so long as we do organize them some way...


jedidia said:
I tried to run your scenario btw, but I'd have to delete so much out of it that I'm not sure the result would count for anything. Future scenarios please without XRs, UCGO cargoes, cars and in general nothing that isn't included in the default orbiter and IMS packages. It's just too time consuming to cut everything out to see what happens, and the results are also not representative.
Click to expand...

One sec (sorry about that)

Code: 
BEGIN_DESC

END_DESC

BEGIN_ENVIRONMENT
  System Upsilon Andromedae system
  Date MJD 56472.5823262172
END_ENVIRONMENT

BEGIN_FOCUS
  Ship Intrepid
END_FOCUS

BEGIN_CAMERA
  TARGET Intrepid
  MODE Cockpit
  FOV 45.97
END_CAMERA

BEGIN_HUD
  TYPE Surface
END_HUD

BEGIN_PANEL
END_PANEL

BEGIN_SHIPS
Horizon_Station:IMS\Command_Modules\BM001_CONTROL_MODULE
  STATUS Orbiting Ups And d I
  RPOS 5253481.39 -1659363.42 -4552243.10
  RVEL 5608.215 1352.448 5979.482
  AROT -26.66 3.20 -137.33
  VROT -0.05 0.02 -0.08
  AFCMODE 7
  PRPLEVEL 0:1.000000 1:1.000000 2:1.000000
  DOCKINFO 0:8,Intrepid
  NAVFREQ 0 0
  COMMAND 0 0
  MODULE Docking_Ports\DADG_Docking_Adapter 0,0,2.3756 0,0,1 1,0,0 0
  MODULE Life_Support\BM012_Lifesupport 0,0,-4.7512 0,0,1 0,1,0 0
  MODULE Life_Support\BM216_Hydroponics 0,0,-12.2029 0,0,1 0,1,0 0
  MODULE Modules\BM110_Habitat 0,0,-22.355 0,0,1 0,1,0 0
  MODULE Power_Generation\SolarArrayRect 0,0,-27.931 0,0,-1 1,0,0 0
  MODULE Power_Generation\SolarArrayRect 0,0,-35.531 0,0,-1 1,0,0 0
  MODULE Power_Generation\SolarArrayRect 0,0,-43.131 0,0,-1 1,0,0 0
  MODULE Power_Generation\SolarArrayRect 0,0,-50.731 0,0,-1 1,0,0 0
  MODULE Batteries\BG201_Battery_SContainer 0,0,-59.0994 1,0,0 0,0,1 0
  TDPOINT 0,0,0 0,0,0 0,0,0
  DELETEPOINT 2
  DELETEPOINT 1
  ATTPOINT IM 0,0,-60.3678 0,0,-1 1,0,0
  DELETEPORT 1
  DELETEPORT 0
  DOCKPORT 0,0,2.7756 0,0,1 1,0,0
  CONSTRUCTIONPORT 0,0,-60.3678 0,0,-1 1,0,0
  EMPTYMASS 43250.000000
  MASSCENTER 0.000000 0.000000 -20.145872
  PMI 91.340000 92.000000 12.640000
  ANIM 4 Power_Generation\SolarArrayRect 1 1
  ANIM 5 Power_Generation\SolarArrayRect 1 1
  ANIM 6 Power_Generation\SolarArrayRect 1 1
  ANIM 7 Power_Generation\SolarArrayRect 1 1
  CONSUMABLES 0.0001 0.0001 32 0.0001 0.0001 32 0.0001 0.0001 10
  TEMPERATURES -1:292.56:219.61 1:272.37:219.61 2:252.92:223.30 3:250.80:223.30 4:199.44:330.00 5:199.44:330.00 6:199.44:330.00 

7:199.44:330.00 8:255.50:226.13
  HEATING no
  THGROUPLEVELS 0 0 0 0 
  CREW 5 0
  ENERGY 241895098.331060
  SOLARARRAY 4 1 0 0.261550 0.261550 0.341092 0.341092
  SOLARARRAY 5 1 0 0.261550 0.261550 0.341092 0.341092
  SOLARARRAY 6 1 0 0.261550 0.261550 0.341092 0.341092
  SOLARARRAY 7 1 0 0.261550 0.261550 0.341092 0.341092
  FAILURES 2:3 3:3 1:3 8:5 
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 1 0 8 0 -1 0 -1
  MFC 1 0 7 0 0 0 -1
  MFC 1 0 5 -1 -1 -1 -1
END
Intrepid:IMS\Command_Modules\BM112_CONTROL_MODULE
  STATUS Orbiting Ups And d I
  RPOS 5253478.11 -1659389.74 -4552190.67
  RVEL 5608.215 1352.448 5979.482
  AROT 153.34 -3.20 137.33
  VROT -0.05 -0.02 0.08
  AFCMODE 7
  PRPLEVEL 0:0.999091 1:1.000000 2:1.000000 4:0.000338
  DOCKINFO 8:0,Horizon_Station
  NAVFREQ 27 27
  COMMAND 1 0
  MODULE Nodes\BN200_Big_Node 0,0,-7.2761 0,1,0 0,0,-1 0
  MODULE Life_Support\BG101_Lifesupport_Container -3.4684,0,-7.276 0,0,-1 1,0,0 1
  MODULE Consumables\BG104_Food_Container 3.4684,0,-7.276 0,0,-1 -1,0,0 0
  MODULE Life_Support\BM013_CoolingSystem 0,0,-11.8517 0,0,1 0,1,0 0
  MODULE Modules\BM010_Habitat 0,0,-16.6029 0,0,1 0,1,0 1
  MODULE Modules\BM010_Habitat 0,0,-21.3541 0,0,1 0,1,0 0
  MODULE Nodes\BN200_Big_Node 0,0,-25.9297 0,1,0 0,0,-1 0
  MODULE Fuel_Tankage\BTank101_LH2_LFuelTank 4.4405,0,-25.9297 0,0,-1 0,1,0 0
  MODULE Fuel_Tankage\BTank101_LH2_LFuelTank -4.4405,0,-25.9297 0,0,-1 0,-1,0 0
  MODULE Power_Generation\BM003_ASTG_Array 0,0,-30.5053 0,0,1 0,1,0 0
  MODULE Fuel_Tankage\BTank101_LH2_LFuelTank 0,4.4405,-25.9297 0,0,-1 -1,0,0 0
  MODULE Fuel_Tankage\BTank101_LH2_LFuelTank 0,-4.4405,-25.9297 0,0,1 -1,0,0 0
  MODULE Fuel_Tankage\BTank201_LH2_SFuelTank 0,0,-33.9888 0,0,1 0,1,0 0
  MODULE Propulsion\BNTR_GasCore_ClosedCycle_Nuclear_Engine 0,0,-41.9756 0,0,1 0.71,0.71,0 0
  MODULE Fuel_Tankage\BTank202_LOX_LH2_SFuelTank 0,-3.3078,-7.2761 0,1,0 0,0,-1 0
  MODULE Fuel_Tankage\BTank202_LOX_LH2_SFuelTank 0,3.3078,-7.2761 0,-1,0 0,0,1 0
  MODULE Radiators\BR020_Radiator 2.2405,4.4405,-25.9297 1,0,0 0,1,0 0
  MODULE Radiators\BR020_Radiator -2.2405,-4.4405,-25.9297 -1,0,0 0,1,0 0
  MODULE Radiators\BR020_Radiator -2.2405,4.4405,-25.9297 -1,0,0 0,-1,0 0
  MODULE Radiators\BR020_Radiator 2.2405,-4.4405,-25.9297 1,0,0 0,-1,0 0
  MODULE Propulsion\BRCS2_ReactionControlSystem_Engine 0,-7.228,-25.9297 0,-1,0 0,0,1 0
  MODULE Propulsion\BRCS2_ReactionControlSystem_Engine 0,7.228,-25.9297 0,1,0 0,0,-1 0
  MODULE Propulsion\BRCS2_ReactionControlSystem_Engine -7.228,0,-25.9297 -1,0,0 0,0,-1 0
  MODULE Propulsion\BRCS2_ReactionControlSystem_Engine 7.228,0,-25.9297 1,0,0 0,0,-1 0
  MODULE Docking_Ports\Docking_Adapter_DG 0,0,6.0261 0,0,1 1,0,0 0
  TDPOINT 0,0,0 0,0,0 0,0,0
  DELETEPOINT 2
  DELETEPOINT 1
  ATTPOINT IM -4.7368,0,-7.276 -1,0,0 0,0,-1
  ATTPOINT IM 4.7368,0,-7.276 1,0,0 0,0,-1
  ATTPOINT IM 4.4405,2.2405,-25.9297 0,1,0 0,0,-1
  ATTPOINT IM 4.4405,-2.2405,-25.9297 0,-1,0 0,0,-1
  ATTPOINT IM -4.4405,-2.2405,-25.9297 0,-1,0 0,0,-1
  ATTPOINT IM -4.4405,2.2405,-25.9297 0,1,0 0,0,-1
  ATTPOINT IM 0,-4.4157,-7.2761 0,-1,0 1,0,0
  ATTPOINT IM 0,4.4157,-7.2761 0,1,0 1,0,0
  DELETEPORT 1
  DELETEPORT 0
  CONSTRUCTIONPORT -4.7368,0,-7.276 -1,0,0 0,0,-1
  CONSTRUCTIONPORT 4.7368,0,-7.276 1,0,0 0,0,-1
  CONSTRUCTIONPORT 4.4405,2.2405,-25.9297 0,1,0 0,0,-1
  CONSTRUCTIONPORT 4.4405,-2.2405,-25.9297 0,-1,0 0,0,-1
  CONSTRUCTIONPORT -4.4405,-2.2405,-25.9297 0,-1,0 0,0,-1
  CONSTRUCTIONPORT -4.4405,2.2405,-25.9297 0,1,0 0,0,-1
  CONSTRUCTIONPORT 0,-4.4157,-7.2761 0,-1,0 1,0,0
  CONSTRUCTIONPORT 0,4.4157,-7.2761 0,1,0 1,0,0
  DOCKPORT 0,0,6.9561 0,0,1 1,0,0
  EMPTYMASS 104500.000000
  MASSCENTER -0.001958 0.000000 -28.878147
  PMI 111.140000 93.890000 43.120000
  PROP LOX_LH2 11360 0
  PROP LH2 39324 13.2938
  ENGINE 13 0 0
  RCSBLOCK 4 4000 4099 0,-7.228,-25.9297 5 0,0,1 1,0,0 0,0,-1 -1,0,0 0,1,0 1
  RCSBLOCK 4 4000 4099 0,7.228,-25.9297 5 0,0,-1 1,0,0 0,0,1 -1,0,0 0,-1,0 1
  RCSBLOCK 4 4000 4099 -7.228,0,-25.9297 5 0,0,-1 0,1,0 0,0,1 0,-1,0 1,0,0 1
  RCSBLOCK 4 4000 4099 7.228,0,-25.9297 5 0,0,-1 0,-1,0 0,0,1 0,1,0 -1,0,0 1
  ANIM 16 Radiators\BR020_Radiator 1 1
  ANIM 17 Radiators\BR020_Radiator 1 1
  ANIM 18 Radiators\BR020_Radiator 1 1
  ANIM 19 Radiators\BR020_Radiator 1 1
  CONSUMABLES 0.0001 0.0001 112 0.0001 0.0001 112 3000 2997.27 0
  TEMPERATURES -1:314.04:226.42 1:311.15:226.13 2:279.51:214.63 3:273.07:219.61 4:308.29:219.61 5:309.59:219.61 9:1013.51:219.61 

13:1299.97:219.61
  RADIATOR 16 267.481 1 0 0 4 5
  RADIATOR 17 190.403 -1 0 0 9 13
  RADIATOR 18 157.934 -1 0 0 2 3 1
  RADIATOR 19 185.972 1 0 0 -1
  HEATING 13 3 9
  THGROUPLEVELS 0 0 0 0 
  CREW 4 2
  UMMUCREW Doc-Laan_Malcen-26-70-71
  UMMUCREW Capt-Kere_Virren-28-70-70
  ENERGY 766236140.768291
  GENERATORSOFF 9 
  EXTPOWER Horizon_Station:
  FAILURES 3:3 9:3 3:5 
  MFC 0 1 5 -1 -1 -1 -1
  MFC 0 1 8 8 -1 0 -1
  MFC 1 0 3 0 -1 -1 -1
  MFC 1 0 1 0 0 -1 -1
  MFC 1 0 5 -1 -1 -1 -1
  MFC 1 0 2 -1 -1 -1 -1
  MFC 1 0 5 -1 -1 -1 -1
  MFC 1 0 6 0 0 10 -1
  MFC 1 0 3 0 -1 -1 -1
  MFC 1 1 0 -1 -1 -1 -1
  MFC 1 1 0 -1 -1 -1 -1
  MFC 1 0 8 8 -1 0 -1
  MFC 1 0 2 -1 -1 -1 -1
  MFC 1 0 3 0 -1 -1 -1
END
END_SHIPS

BEGIN_ExtMFD
END
 
Last edited:
Copy all...
Im sorry for the mesh file (just checked it and im kicking my self in a very private place for letting that go unnoticed). So...Only default configs else it gets out of hand. As Bruce say...thats fair.
The RCS selection problem only occurs if and when loaded from an already finalized Vessel. IMS saves and restores RCS state all right from "un-finalized" state. I just thought that operating IMS vessels from a finalized state was the "approved" way of operating it.

Anyway...its not that big a deal with the RCS thing. Compared to what IMS otherwise offers this is something that you can easily live with :-)

@Bruce - I did try to load the scenario but I did not have the Upsilon Andromedae system download (as of yet anyway) So I wasnt able to test it.
 
Michael_Chr said:
Copy all...
Im sorry for the mesh file (just checked it and im kicking my self in a very private place for letting that go unnoticed). So...Only default configs else it gets out of hand. As Bruce say...thats fair.
The RCS selection problem only occurs if and when loaded from an already finalized Vessel. IMS saves and restores RCS state all right from "un-finalized" state. I just thought that operating IMS vessels from a finalized state was the "approved" way of operating it.

Anyway...its not that big a deal with the RCS thing. Compared to what IMS otherwise offers this is something that you can easily live with :-)

@Bruce - I did try to load the scenario but I did not have the Upsilon Andromedae system download (as of yet anyway) So I wasnt able to test it.
Click to expand...

Could we get a general vote as to who is for/against moving to a new config organization? The final say will of course be up to Jedidia, but I would like to get some feedback on this. My personal feeling has been that the most effective way to organize cfg files going forward, will be by type; ie radiators go in a radiator folder, engines & RCS go in a propulsion folder, and so on. We had also experimented with "company folders", subdividing part sets further, but that generally just added another useless layer of folders to click through in practice.

My compromise with the older way of doing things is to include a zip file with that structure along with any newer releases. That way, if a user wants to fly a ship made before the current changes, they just need to unzip the configs within and copy them over to their install.

Any thoughts?

@Michael Chr: no worries about the Upsilon Andromedae thing. Its a big file to download, I know.
 
I just thought that operating IMS vessels from a finalized state was the "approved" way of operating it.
Click to expand...

It's supposed to be, but it's also the least tested and uses its own parsers... Let's see... Yes, that would make sense. Tell me, are the RCS thrusters activated before finalisation, or do you only assign them after finalisation? Because that would in fact not get stored... It's part of the hard-wired stuff that gets written to the config, not to the scenario, exactly for the purpose that a config loaded vessel comes properly configured even when not loaded from a scenario (and also because it's simpler, but I think I could sneak the assignement back into the scenario).

ts just that the one thing me & PeterRoss agreed on was that dumping all of the configs into one folder didn't work. It doesnt matter to me how we organize configs in the scenario editor, so long as we do organize them some way...
Click to expand...

SSBB4.1rev2 looks quite organised to me.

One sec (sorry about that)
Click to expand...

Scenario works for me... (after taking out the empty lines that somehow crawled into that code block you posted, of course).
 
Last edited:
jedidia said:
SSBB4.1rev2 looks quite organised to me.
Click to expand...

Exactly. The SSBB parts are now easy enough to sort through, but our IMS native ones are still disorganized. Why not group together all of the parts based on their type/use?

jedidia said:
Scenario works for me... (after taking out the empty lines that somehow crawled into that code block you posted, of course).
Click to expand...

Hmmm, double checking on my end. (you did test it in Upsilon Andromedae, right?)

What empty lines are you talking about?
 
Last edited:
Exactly. The SSBB parts are now easy enough to sort through, but our IMS native ones are still disorganized. Why not group together all of the parts based on their type/use?
Click to expand...

Yeah, ok, I guess we can do that (they would be simple enough to move around for restoring backwards compatibility for the user too...)

(you did test it in Upsilon Andromedae, right?)
Click to expand...

It's not like I feel like switching out all the references in the scenario, so yes... ;)
 
jedidia said:
Yeah, ok, I guess we can do that (they would be simple enough to move around for restoring backwards compatibility for the user too...)



It's not like I feel like switching out all the references in the scenario, so yes... ;)
Click to expand...

Can you post exactly the contents of whatever scenario you used to run it here? I still cant get it to work on my install.

@Jedidia: Is any error checking done on the EPP inputs? Maybe I screwed that up somewhere...

Edit: Okay, Jedidia, I can confirm that nothing is reloading properly in RC3 for me, regardless of whether it is created with the RC3 dll installed. I still need to check whether this applies to sol system though.

Edit: Yep, I believe I can confirm it. I added a single IMS command module to the stock quickstart scenario, saved it, and this is what I get on reload:

Code: 
**** Orbiter.log
Build Aug 30 2010 [v.100830]
Timer precision: 4.05195e-007 sec
Found 0 joystick(s)
Devices enumerated: 4
Devices accepted: 3
==> RGB Emulation
==> Direct3D HAL
==> Direct3D HAL (Intel(R) HD Graphics)
Module AtlantisConfig.dll .... [Build 100830, API 100830]
Module AtmConfig.dll ......... [Build 100830, API 100830]
Module DGConfig.dll .......... [Build ******, API 060425]
Module DGConfigurator.dll .... [Build 100830, API 100830]
Module ScnEditor.dll ......... [Build 100830, API 100830]
Module OrbiterSound.dll ...... [Build 121120, API 100830]
Module transx.dll ............ [Build 100824, API 100823]
Module VesselParametersMFD.dll  [Build ******, API 060425]
---------------------------------------------------------------
>>> WARNING: Obsolete API function used: oapiRegisterMFDMode
At least one active module is accessing an obsolete interface function.
Addons which rely on obsolete functions may not be compatible with
future versions of Orbiter.
---------------------------------------------------------------
Module CSSC_Spawner.dll ...... [Build 120331, API 100830]
Module LagrangeMFD.dll ....... [Build ******, API 060425]
Module Lagrange.dll .......... [Build ******, API 060425]

**** Creating simulation session
DirectDraw interface OK
Direct3D interface OK
Graphics: Viewport: Window 1594 x 872 x 32
Graphics: Hardware T&L capability: No
Graphics: Z-buffer depth: 32 bit
Graphics: Active lights supported: -1
Loading 40780 records from star database
Module Sun.dll ............... [Build 100830, API 100830]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
Module Mercury.dll ........... [Build 100830, API 100830]
VSOP87(B) Mercury: Precision 1e-005, Terms 167/7123
Module Venus.dll ............. [Build 100830, API 100830]
Module VenusAtm2006.dll ...... [Build 100830, API 100830]
VSOP87(B) Venus: Precision 1e-005, Terms 79/1710
Module Earth.dll ............. [Build 100830, API 100830]
Module EarthAtmJ71G.dll ...... [Build 100830, API 100830]
VSOP87(B) Earth: Precision 1e-008, Terms 2564/2564
---------------------------------------------------------------
>>> ERROR: Missing texture: KeSpCe\K3\toit4.dds
>>> [TextureManager::AcquireTexture | .\Texture.cpp | 750]
---------------------------------------------------------------
Module Moon.dll .............. [Build 100830, API 100830]
ELP82: Precision 1e-005, Terms 116/829
Module Mars.dll .............. [Build 100830, API 100830]
Module MarsAtm2006.dll ....... [Build 100830, API 100830]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
**** WARNING: Mesh not found: .\Meshes\NanediVallis.msh
BaseObject: Parse error 1
Module Phobos.dll ............ [Build ******, API 060425]
Module Deimos.dll ............ [Build ******, API 060425]
Module Galsat.dll ............ [Build 100217, API 100215]
Module Jupiter.dll ........... [Build 100830, API 100830]
VSOP87(B) Jupiter: Precision 1e-006, Terms 1624/3625
Transparency texture mask file too short: Jupiter_lmask.tex
Disabling specular reflection for this planet
Module Io.dll ................ [Build 100217, API 100215]
Module Europa.dll ............ [Build 100217, API 100215]
Module Ganymede.dll .......... [Build 100217, API 100215]
Module Callisto.dll .......... [Build 100217, API 100215]
Module Satsat.dll ............ [Build 100215, API 100212]
Module Saturn.dll ............ [Build 100830, API 100830]
VSOP87(B) Saturn: Precision 1e-008, Terms 6365/6365
Module Mimas.dll ............. [Build 100215, API 100212]
SATSAT Mimas: Terms 113
Module Enceladus.dll ......... [Build 100215, API 100212]
SATSAT Enceladus: Terms 33
Module Tethys.dll ............ [Build 100215, API 100212]
SATSAT Tethys: Terms 101
Module Dione.dll ............. [Build 100215, API 100212]
SATSAT Dione: Terms 59
Module Rhea.dll .............. [Build 100215, API 100212]
SATSAT Rhea: Terms 68
Module Titan.dll ............. [Build 100215, API 100212]
SATSAT Titan: Terms 100
Module Iapetus.dll ........... [Build 100215, API 100212]
SATSAT Iapetus: Terms 605
Module Janus.dll ............. [Build ******, API 060425]
Module Epimetheus.dll ........ [Build ******, API 060425]
Module Helene.dll ............ [Build ******, API 060425]
Module Telesto.dll ........... [Build ******, API 060425]
Module Calypso.dll ........... [Build ******, API 060425]
Module Uranus.dll ............ [Build 100830, API 100830]
VSOP87(B) Uranus: Precision 1e-008, Terms 5269/5269
Module Miranda.dll ........... [Build ******, API 060425]
Module Ariel.dll ............. [Build ******, API 060425]
Module Umbriel.dll ........... [Build ******, API 060425]
Module Titania.dll ........... [Build ******, API 060425]
Module Oberon.dll ............ [Build ******, API 060425]
Module Neptune.dll ........... [Build 100830, API 100830]
VSOP87(B) Neptune: Precision 1e-008, Terms 2024/2024
Finished initialising world
Module DeltaGlider.dll ....... [Build ******, API 060425]
Module ShuttleA.dll .......... [Build 100830, API 100830]
Module ShuttlePB.dll ......... [Build 100830, API 100830]
Module Train.dll ............. [Build 120522, API 100830]
Module XR5Crane.dll .......... [Build 120519, API 100830]
Module ThemLPad.dll .......... [Build 120519, API 100830]
Module RadarDish.dll ......... [Build 120519, API 100830]
Module BigPad.dll ............ [Build 120519, API 100830]
Module IMS.dll ............... [Build 130923, API 100830]

I believe I've pinpointed the issue: IMS needs the relevant EPP file to load properly. I'm going to check again in Upsilon Andromedae, I think I must have done something wrong when I created the EPP for Upsilon Andromedae.

Edit: One last time, whew

The EPP file for the system needs to be in config/EPP, and it needs to be named the same as the solar system. My Upsilon Andromedae config was named "Upsilon Andromedae", it needed to be named "Upsilon Andromedae system". Note to Jedidia, it would be much better if there could be a safeguard that instructs IMS to use some default parameters when the file cannot be found.
 
Last edited:
OK...now I'm even a more embarresed.
It works exeactly as advertised ie. If a vessel is finalized with RCS activated then the correspondingly spawned Vessel inherets that RCS state. Excellent :-)
For some reason I had always thought it to be the best way not to break the transport seal until as late as possible in the process - which had even let me further into the process of finalizing vessels with the seal on. No more of that...
And come to think if it it even makes more sense doing it this way...just had never thought it worked like that.
Anyhew...thanks for clarifying that for me and Again...sorry for the inconvinience.
 
believe I've pinpointed the issue: IMS needs the relevant EPP file to load properly. I'm going to check again in Upsilon Andromedae, I think I must have done something wrong when I created the EPP for Upsilon Andromedae.
Click to expand...

Negative. Tested with and without .epp file. The only thing I noticed is that it actually doesn't load, because the system in orbiter is called "Upsilon Andromedae System", so the file name of the .epp has to be the same. But the scenario works regardless, if epp doesn't find a file it just assumes it is in sol and creates a star with luminosity 1.

Code: 
---------------------------------------------------------------
>>> ERROR: Missing texture: KeSpCe\K3\toit4.dds
>>> [TextureManager::AcquireTexture | .\Texture.cpp | 750]
---------------------------------------------------------------

WTF is that??

Can anybody confirm Bruce's observations? anybody else having trouble with reloading a scenario? There is a possibility of a corrupted file in the download, after all...

Can you post exactly the contents of whatever scenario you used to run it here?
Click to expand...

Exactly what you posted above, minus the two empty lines.

And while we're at it, have you worked with Module VesselParametersMFD.dll [Build ******, API 060425] before, and have you tried running without it? That seems just like the kind of thing that doesn't like IMS at all, what with all the handles changing all the time.
 
Last edited:
jedidia said:
Negative. Tested with and without .epp file. The only thing I noticed is that it actually doesn't load, because the system in orbiter is called "Upsilon Andromedae System", so the file name of the .epp has to be the same. But the scenario works regardless, if epp doesn't find a file it just assumes it is in sol and creates a star with luminosity 1.
Click to expand...

Thats odd. I appear to be getting the opposite result here. The scenario wont load properly if the EPP file is absent. Dunno what I can say, but thats what I'm seeing.

jedidia said:
Code: 
---------------------------------------------------------------
>>> ERROR: Missing texture: KeSpCe\K3\toit4.dds
>>> [TextureManager::AcquireTexture | .\Texture.cpp | 750]
---------------------------------------------------------------

WTF is that??
Click to expand...

Beats me. I believe that shows up a lot in my Orbiter installs, but I don't recall what it is. I'm pretty sure its never caused any problems before, just a blank mesh somewhere.
 
Thats odd. I appear to be getting the opposite result here. The scenario wont load properly if the EPP file is absent. Dunno what I can say, but thats what I'm seeing.
Click to expand...

What's it named like?

Also, check my latest edit above.
 
jedidia said:
Can anybody confirm Bruce's observations? anybody else having trouble with reloading a scenario? There is a possibility of a corrupted file in the download, after all...
Click to expand...

I'm beginning to wonder that myself. The crashes that we're seeing are so odd...

But maybe its just something that you have set up by default on your Orbiter install from working with EPP & IMS often? Are you sure that the RC3 package contains the latest build? Maybe you compiled it, but forgot to copy it over when you uploaded...

jedidia said:
And while we're at it, have you worked with Module VesselParametersMFD.dll [Build ******, API 060425] before, and have you tried running without it? That seems just like the kind of thing that doesn't like IMS at all, what with all the handles changing all the time.
Click to expand...

Actually I don't have that installed right now, so we can rule that out. Just for the record, I cannot recall ever having problems between the two, but it isnt hard to imagine IMS and VesselParameters getting into a dogfight.

jedidia said:
What's it named like?

Also, check my latest edit above.
Click to expand...

IMS RC3 is now working when it has an EPP file with the same name as the solar system config name in config/EPP. For example, Upsilon Andromedae uses the name

"Upsilon Andromedae system"

Which is what a scenario file records for SYSTEM parameter, and what the EPP for it needs to be called. But

"Upsilon Andromedae"

Will not work in this case.
 
Last edited:
Actually I don't have that installed right now, so we can rule that out.
Click to expand...

Yes you do. I can see it loading in that log!


IMS RC3 is now working when it has an EPP file with the same name as the solar system config name in config/EPP. For example, Upsilon Andromedae uses the name

"Upsilon Andromedae system"

Which is what a scenario file records for SYSTEM parameter, and what the EPP for it needs to be called. But

"Upsilon Andromedae"

Will not work in this case.
Click to expand...

Ok, now this is strange. I'm having no trouble either with or without a valid .epp file... Maybe my behavior is undefined somewhere when no file is found, although the function should really just return NULL. I'll have to take a look at it.
 
I just integrated the Emergency Transfer Vehicle under RC3.

Took me a few trys as I had 4 CTD's during the integration of the 160 or so modules that make up the Emergency Transfer Vehicle (ETV). All due to me not waiting long enough between module integrations I think. Sound was turned off so that wasn't the issue. Once it was integrated, looking at it from the outside was smooth at 60 FPS. ;)

Anyway, The ETV is intended to be an unmanned cargo carrier capable of transporting a full XR5 load of modules (36 full size BG modules) to anywhere in the solar system in a SHORT period of time. It has around 28 Mm/s of delta V w/out payload (and probably well over 20 Mm/s fully loaded). Using TransX, I calculated the Trans Pluto Transfer (TPT) burn and the Pluto Orbit Insertion (POI) burns for a flight time of 162.6501 days. The TPT is about 288.1km/s and the POI is about 320.2km/s. Well within the 20Mm/s delta V capability of the ETV.

What does this mean?

Well, the manned Solar System Transport Vehicle (SSTV) should end up with about 12-15 Mm/s of delta V when it's fully loaded with over 700 BG modules and 2 fully loaded XR5s docked to it.

Which means a 100 day mission from Low Earth Orbit (LEO) to Pluto Orbit (PO) should be within the capabilities of the SSTV.

It might even be able to do it in 30 days!

Anyone up for a flight to Pluto that only takes 1 month (:OMG:) to get there? ;)

For those of you who didn't see any of my earlier posts, the SSTV is capable of transporting:
  • 718 full size BG modules (from the SSBB 4.1B pack)
  • 2 fully loaded and fueled XR5s
  • habitation in gravity rings for 40 humans
  • hydroponics modules for food for 40 humans
  • life support modules for O2 and water for a total of 40 humans

The SSTV and ETV are both definitely NOT JAETMS (Just Another Earth To Mars Ship). :)

Dantassii
HUMONGOUS IMS shipbuilder
 
You must log in or register to reply here.

Similar threads

llarian
Software How to setup and name mesh groups in Blender for use in Vinka's Spacecraft ...
Replies
6
Views
1K
gattispilot
gattispilot
N
Problem SSV not loading in Orbiter 2024
Replies
5
Views
1K
CuriousDude?_
C
J
Problem D3D9 not working with orbiter 2024
2
Replies
34
Views
6K
Banshii59
B
n72.75
  • Poll Poll
Ease of changing simulation paramteters.
Replies
1
Views
1K
misha.physics
misha.physics
Tiny_Bob
SDK Question New to addon creation, looking for a good place to start
Replies
10
Views
2K
Matias Saibene
Matias Saibene
Back
Top