# UpdateDeepstar development

#### 80mileshigh

Donator
The Mars bases should look like this:

This image is Gusev on the left and Marineris on the right, stock textures on top and hires textures + surface microtextures at bottom:

The upper examples are in an installation which features only Orbiter 2016 + Orbiter Sound 5.0 + d3d9 4.11 (7-Sep-2020) + Deepstar 3.0.

Terrain flattening is enabled and 'linear interpolation' is set at the visual effects tab of the Orbiter launchpad. The specified config edits have been made and there are no other flat files in the Textures\Mars\Flat folder.

The lower examples are from my development installation which adds the Mars hi-res textures and micro textures, but with the same settings. I've noticed the pad meshes at Gusev don't quite sit flush with the ground with the stock textures despite the flat file, but as I've said in the documentation the bases are designed for use with the hi res textures.

Hope this helps narrow down the problem.

#### Face

Beta Tester
I think the terrain flattening issue is due to different texture packs. The system uses absolute values w.r.t. mean sphere radius, just as the terrain data itself does. It could be that hi-res packs change the height of various areas, so people with different height data see the absolute flats at different places w.r.t. the terrain.
It would be interesting to know what landed vessels show as height in the instruments. If it is the same everywhere, the terrain is what is different between users. In this case, I'd suggest to adjust the values until they fit for the appropriate texture packs, then distribute different flat files.
If the height display in the landed vessels is different, though, it could well be a bug in the flattening feature.

#### yoda1952

##### Donator
Donator
I haven't been able to get past the loading screen. Here is the log. I think I followed all the instructions.

#### Attachments

• Orbiter.txt
9 KB · Views: 5

I am currently working on converting all Deepstar vessels to C++ vessels. I almost finished the main Deepstar vessel.

For the attachment and cargo operation, would you like me to implement UCSO for that or you want the Orbiter and Spacecraft4 attachment procedures? I can do both.

If you choose UCSO, I will convert the space hab and probe to be UCSO cargoes. You might want to make the aerolander bay big enough to contain one cargo (1.5x1.5x1.5m), but it's not necessary.

I haven't been able to get past the loading screen. Here is the log. I think I followed all the instructions.
Have you executed the symbolic link step? You need to execute it after the installation even if you executed it before. This should solve the messing meshes issue.

#### lele

##### New member
hello i installed both on orbiter 2016, deepstar 3.0 and deppstar 2.1, and i noticed that 2.1 is much more flyable respect the 3.0 deepstar.
The 3.0 response of the nozzles is lower, and has a lot of drift, when i try to make some manuver e.g. prograde or retrograde or N+ and N- the ship is very slow to reach the final position (it goes back and forth continuously before to reach the point). Maybe there is something to fix?

#### predattak

##### Member
Alright boys i think i got it.
I tested it today and the "problem" is the 8.7Gb High Res Elevation file. (elev.tree)

I tested it at first on a brand new client and the bases worked fine.
When i added HD Mars pack the problem appeared again.
I know that people don't always download the full HD packs and sometimes only get the textures or elevation and they combine them with the standard ones.
So here's how it goes:
low res elev.tree + low res surf.tree = bases are fine.
low res elev.tree + HD surf.tree = bases are fine.
HD elev.tree + any of the surf.tree files = base problem is present.

It's the elev.tree from the HD mars pack. My logic is that because it's HD, the terrain is closer to reality and of course slightly different than the standard low res.
Someone needs to just adjust the bases for that and we are good to go.
It should be a separate file because if you gonna adjust the base coords and elevation for the HD pack, they won't be in the same place for people that use the standard low res.

I way be wrong and the problem may still be bigger than just this.

Last edited:

#### Pioneer

##### Active member
Alright boys i think i got it.
I tested it today and the "problem" is the 8.7Gb High Res Elevation file. (elev.tree)

I tested it at first on a brand new client and the bases worked fine.
When i added HD Mars pack the problem appeared again.
I know that people don't always download the full HD packs and sometimes only get the textures or elevation and they combine them with the standard ones.
So here's how it goes:
low res elev.tree + low res surf.tree = bases are fine.
low res elev.tree + HD surf.tree = bases are fine.
HD elev.tree + any of the surf.tree files = base problem is present.

It's the elev.tree from the HD mars pack. My logic is that because it's HD, the terrain is closer to reality and of course slightly different than the standard low res.
Someone needs to just adjust the bases for that and we are good to go.
It should be a separate file because if you gonna adjust the base coords and elevation for the HD pack, they won't be in the same place for people that use the standard low res.

I way be wrong and the problem may still be bigger than just this.
Also, there are additional installation instructions for the Mars Hi-Res textures that could play a factor into this:

Size of planet is modified along with minimum elevation.

#### predattak

##### Member
Ok, I modified the bases a bit, had to move them a few meters and of course the elevation. For me this fix method works see if it works for you too.

#### Attachments

• Mars Bases Fixed For Mars HD.zip
5.7 KB · Views: 12
Last edited:

#### Pioneer

##### Active member
Ok, I modified the bases a bit, had to move them a few meters and of course the elevation. For me this fix method works see if it works for you too.
Works great! The only thing is that the scenario files need to be modified. But that's easily fixable.

#### 4throck

##### Enthusiast !
Very nice to have this for 2016 ! Love it, specially the bases and depots.
Like a previous user, I too find the RCS underpowered, and the default autopilots (ex: prograde / retrograde) have a hard time working.
Another nitpick is that the landers have the wrong logical orientation for tail sitters.

But these are minor details that don't spoil the fun! Thanks for the update!

#### predattak

##### Member
Like a previous user, I too find the RCS underpowered, and the default autopilots (ex: prograde / retrograde) have a hard time working.
You can easily configure it. I did the same with the Aerolander's RCS and Hover engines.
Go to Orbiter\Config\Spacecraft\
click on the .ini file of the vessel you want to configure and modify parameters.
Ex: for aerolander's RCS you need to modify this line -> ATTITUDE_THRUST=5000
I changed mine to 100000 and it's good, works well with autopilots.

#### 80mileshigh

Donator
I haven't been able to get past the loading screen. Here is the log. I think I followed all the instructions.

As @Abdullah Radwan suggested above, this looks like you need to hit the 'Create symbolic links' button again. Does that solve it for you?

@predattak @Pioneer I can confirm I have both hi-res surf.tree (3,945,645kb) and hi-res elev.tree (2,566,011kb) installed.

I actually hadn't made those config changes listed on the hi-res installation page. I just read that and thought 'oh that's it.' But having made the changes now everything is still appearing correctly for me.

This is my Mars.cfg
Code:
; === Configuration file for planet Mars ===
Name = Mars
Module = Mars
Module_Atm = MarsAtm2006
ErrorLimit = 1e-5
SamplingInterval = 138         ; interpolation sampling interval [s]
; (interpolation error ~1m)
; === Physical Parameters ===
Mass = 6.418542e+23
Size =3.390e6
;Size = 3.38992e6                   ; mean radius
JCoeff = 0.001964                  ; J2 coefficient for gravitational potential

; === Rotation and precession parameters ===
PrecessionLAN = 4.005081124
PrecessionObliquity = 0.03224369545
PrecessionPeriod = -63346652.48
LAN = 0.6210531483
LAN_MJD = 51544.5
Obliquity = 0.4397415938
SidRotOffset = 5.469523488
SidRotPeriod = 88642.66435
;SidRotPeriod (days): 1.025956763
;SidRotPeriod (days - node to node): 1.025956748
;Precession Period (years): -173433.6824
;Obliquity (deg): 25.1953374
;Axis RMS Error (deg): 3.596520014e-006
;Lat/Lon RMS Error (deg): 0.000228792323

; === Atmospheric Parameters ===
AtmPressure0 = 0.61e3          ; pressure at zero altitude [Pa]
AtmDensity0 = 0.02             ; density at zero altitude [kg/m^3]
AtmGasConstant = 188.92        ; specific gas constant [J/(K kg)]
AtmGamma = 1.2941              ; specific heat ratio c_p/c_v
AtmAltLimit = 280e3            ; cutoff altitude
;AtmAltLimit = 230e3            ; cutoff altitude
;AtmColor0 = 0.65 0.52 0.40
;AtmHazeColor = 0.65 0.52 0.40
AtmColor0 = 0.42 0.35 0.27
AtmHazeColor = 0.42 0.35 0.27
AtmHazeDensity = 0.3
AtmFogParam = 1.5e-5 0.8e-5 5e3
AtmFogColor = 0.5 0.40 0.3

; === Visualisation Parameters ===
TileFormat = 2
AlbedoRGB = 0.52 0.36 0.16
MaxPatchResolution = 16          ; highest sphere patch level
;MaxPatchResolution = 14          ; highest sphere patch level
HorizonExcess = 0.035   ; prevent mountain tops beyond sphere horizon from disappearing
MinElevation = -22000

; === Surface Bases ===
; base directories in this list
BEGIN_SURFBASE
DIR Mars\Base
DIR Mars\Base\Deepstar3.0 CONTEXT Deepstar3.0
END_SURFBASE

@Face @predattak @Pioneer my instrument readings at the bases, stock low-res vs hi res with config changes =

Code:
GUSEV STOCK
PeR 7.260k
SURFACE MFD ALT -1.90km

GUSEV HI-RES
PeR 7.261k
SURFACE MFD ALT -1.89km

MARINERIS STOCK
PeR 7.689k
SURFACE MFD ALT 4.32km

MARINERIS HI-RES
PeR 7.690k
SURFACE MFD ALT 4.32km

Re: the autopilots @lele @4throck - this is due to changed PMI and CROSS_SECTION numbers in config\spacecraft\deepstar.ini. I believe this should be more realistic, assuming running a gazillion samples on shipedit gives a more realistic number.

I meant to add a tip in the documentation not to use the autopilots for achieving an orientation, but for maintaining it (within typical time acceleration constraints). A nudge on the thrusters in the right direction and a bit of time acceleration, then activating killrot and then the autopilot should work fine. If it's too annoying you can copy the 2.1 numbers back in (CROSS_SECTION=1586.7 2119.13 530.31 / PMI=(400,400,400).

I am currently working on converting all Deepstar vessels to C++ vessels. I almost finished the main Deepstar vessel.

For the attachment and cargo operation, would you like me to implement UCSO for that or you want the Orbiter and Spacecraft4 attachment procedures? I can do both.

If you choose UCSO, I will convert the space hab and probe to be UCSO cargoes. You might want to make the aerolander bay big enough to contain one cargo (1.5x1.5x1.5m), but it's not necessary.

Many thanks!! Let's go with UCSO but leave the payload bay dimensions for now. It will be easier for me to mesh new payloads than rework the aerolanders at this point. (happy to do payload requests).

By the way, the number of RCS thrusters on Deepstar exceeds the number spacecraft4.dll would permit. You might be able to extrapolate the positions from what I've done. Or you could leave it and no one will notice! But let me know if you need any position data.

Very nice to have this for 2016 ! Love it, specially the bases and depots.
Like a previous user, I too find the RCS underpowered, and the default autopilots (ex: prograde / retrograde) have a hard time working.
Another nitpick is that the landers have the wrong logical orientation for tail sitters.

But these are minor details that don't spoil the fun! Thanks for the update!

Thanks! I'm very glad to know it's working enough to be fun

Last edited:

#### predattak

##### Member
@predattak @Pioneer I can confirm I have both hi-res surf.tree (3,945,645kb) and hi-res elev.tree (2,566,011kb) installed.

I actually hadn't made those config changes listed on the hi-res installation page. I just read that and thought 'oh that's it.' But having made the changes now everything is still appearing correctly for me.

Are you sure you have official High Res Mars? It seems that you have the low res or some other HD file. ( mod maybe? ) because the size is really small.
My HD mars looks like this:
8,528,781 kb - 8.5+ gb size on disk
12,302,069 kb - 12+ gb size on disk

Go here and look under Mars -> http://orbit.medphys.ucl.ac.uk/mirrors/orbiter_radio/tex_mirror.html
For HD
Surface tree should be 12597318216 bytes (12+ gb)
Elevation tree should be 8733471735 bytes (8+ gb)

Your surface tree is 3.9 gb ( should be ~12+ ) you are missing 8+ gb of data
and your elev tree is 2.5 gb ( should be ~8+ ) you are missing 5+ gb of data
If we compare numbers you can see the problem.

Maybe you have the old HD? It has been updated in 2017 to what we have now, a much better version.

I'm very glad to know it's working enough to be fun
It's fun indeed. The bases are a blessing and i think i fell in love with that aerolander of yours. If the space shuttle and an F-35 would have a child ... it would look like the aerolander

Last edited:

#### 80mileshigh

Donator
Are you sure you have official High Res Mars? It seems that you have the low res or some other HD file. ( mod maybe? ) because the size is really small.

If the space shuttle and an F-35 would have a child ... it would look like the aerolander

Haha, that quote might have to go on the cover

#### predattak

##### Member
Oooo you gonna love it ... it's ..... GLORIOUS.

#### 80mileshigh

Donator
Oooo you gonna love it ... it's ..... GLORIOUS.

And the view from Phobos is something else:

So I've confirmed the issue was me using out of date Mars textures and your base files posted above are a perfect fix.

Those same files won't fit the stock textures of course. As much as I hate to make the install any more complicated I feel I have to provide both hi-res and low-res options in the next update.

Is it ok for me to include the Mars files you posted above, with credit, @predattak?

Many thanks!! Let's go with UCSO but leave the payload bay dimensions for now. It will be easier for me to mesh new payloads than rework the aerolanders at this point. (happy to do payload requests).

By the way, the number of RCS thrusters on Deepstar exceeds the number spacecraft4.dll would permit. You might be able to extrapolate the positions from what I've done. Or you could leave it and no one will notice! But let me know if you need any position data.
Alright. Deepstar vessel is now finished with UCSO except for the additional RCS thrusters and the MFD. I don't want to mess with that because it will be too complex to mess with the groups and exhaust textures (that took me ages!).

I am currently stuck at displaying the MFD buttons. It involves some work on mesh and texture, and I couldn't do that myself. Here is what you need to do (from API_Guide file in Orbitersdk\doc, page 43):
Next, you need to define the MFD control buttons. How you implement them is mostly up to you. Typically, you define each button as a rectangle and collect all rectangles into a single mesh group. Reserve space on a dynamic texture for drawing the button labels, and set the texture coordinates for the button rectangles accordingly.
It would be great if you could do this for the Deepstar vessel, lander, and the aerolander. Send me the new mesh and texture when finished so I can continue with the rest of the process.

EDIT: Can you also make a group for each elevon in the aerolander mesh? I need this to animate the elevons. I also need a rectangular group on the top and bottom side of the elevons to animate the airbrakes. See the XR-2 elevons and airbrakes.
And why the landing gear is skids? Since it's designed to land in atmospheric conditions, it makes sense only to make wheels.

For the aerodynamic model, I will use the DG model. I tried several times to make a custom model, but I always end up with weird flying characteristics.

Also, it would be great if you added an autopilot panel in each vessel to control the Orbiter autopilot. Just make a panel with a button for each AP mode (You don't need to make them a separate group or a dynamic texture like the MFD buttons).

Last edited:

#### yoda1952

##### Donator
Donator
Have you executed the symbolic link step? You need to execute it after the installation even if you executed it before. This should solve the messing meshes issue.
When I executed the symbolic link I get a message "Config: Ok, a non-empty config directory already exists". There are files in it.