Request Base fix for Orbiter 2016?

ninjaturtle

New member
Joined
Jun 20, 2017
Messages
1
Reaction score
0
Points
0
Hi,
would anyone with technical know-how be able to create at very least a flatten area for each of the bases in Orbiter 2016? Since the elevation has come along most of the bases now have incredibly bumpy runways and landing pads at 45 degrees on the side of a mountain etc.. would be great if there was a fix to this - especially for emergency landings on a runway that is actually flat :D

Perhaps an update of:https://www.orbithangar.com/searchid.php?ID=6007 with a flatten?
 
Yeah it would be cool to upgrade all these bases to follow the terrain in Orbiter 2016 and also upgrade the texture tiles and terrain tiles around the bases to max resolution. It would be quite cool
 
There's no easy solution for this, the problem is with the new terrain system.
It's extremely awkward to edit surface textures or elevation maps.

I actually mentioned the bumpy runways as a bug when the first 2016 betas came out, and suggested an auto-flatten around bases.

For me a bumpy runway is not expected performance, since we have runway objects for bases. Those should be flat.
But Orbiter's creator thinks otherwise so... I'm using capsules and doing water landings ;)
 
But Orbiter's creator thinks otherwise so...

Does he really think so? I mean, is there a statement where Martin describes that the runway-objects should not be flat automatically?

I can see why - due to time-consuming tasks - such a feature did not make it into 2016, but you make it sound like it was an explicit decision to have bumpy runways.
 
So Not sure how detailed on could make elevation? I mean can you select a runway and 0 elevate it?

What about around the launchpads and cou make the hill and ramp up so a vessel can drive up to ramp.

I may need to figure out how to do this for the moon for MoonBAse Alpha
 
My bug bear is that it has to be done in 64bit os... which I dont have!
 
Sorry, I only have 64-bit Matlab, and I don't think the mcc compiler allows cross-compilation for other platforms. If anybody has a recent 32-bit Matlab including the corresponding mcc and is willing to compile my tileedit Matlab sources, I'd be happy to provide those. I can't guarantee that it will actually work correctly with 32-bit memory limitations though.

However tileedit is and remains a fairly quick and cheerful hack mostly written for my own needs at the time. Wasn't there a discussion about developing a tileedit replacement some time ago? Has anything happened on that yet?
 
However tileedit is and remains a fairly quick and cheerful hack mostly written for my own needs at the time. Wasn't there a discussion about developing a tileedit replacement some time ago? Has anything happened on that yet?
I think you're referring to face's Orbiter Texture Tree Tools (OT3), which so far is only a collection of command line interface tools right now, nothing to really replace tileedit's GUI. I would love to see something like Orbiter Base Maker but adapted for Orbiter 2016.
 
Ok. So I loaded MoonbaseAlpha1.cfg into Base maker. Got rid of mesh craters.
Got treeman to run but at a lost of what to do next.

Downloaded MCR_R2015a_win64_installer.exe for tile edit.
Then I get this while trying to run tileedit:
rwZAJo6.jpg
 
Last edited:
However tileedit is and remains a fairly quick and cheerful hack mostly written for my own needs at the time. Wasn't there a discussion about developing a tileedit replacement some time ago? Has anything happened on that yet?

The appropriate request was Loru's here, I think. As DaveS mentioned, OT3 is basically just a CLI tool collection, but there is the idea of a GUI tool to do what tileedit does at least in the navigation aspect.

However, interest in the project has quickly vanished as it seems, so I did not invest much time recently.
 
Does he really think so? I mean, is there a statement where Martin describes that the runway-objects should not be flat automatically?

I can see why - due to time-consuming tasks - such a feature did not make it into 2016, but you make it sound like it was an explicit decision to have bumpy runways.


No, there was no statement mentioning non flat runways.

Kind of proving my point that bumpiness in NOT the expected behavior :)
Therefore it's a major bug, since it prevents a default vessel (DG) from lifting off (from certain runways).

Unless we now consider lines to be curves, planes to be uneven surfaces, etc :lol: welcome to post truth in geometry :lol:


Let's be clear that I'm in no way criticizing Martins.
His project, his decisions, his free time, I'm happy with what I get for free :tiphat: no matter what.
 
So how to do it?
I couldn't get tileedit to run.

I think most are in agreement it needs to be able to do it. I have seen that some bases have been flatten.

---------- Post added at 07:38 AM ---------- Previous post was at 05:43 AM ----------

I reinstalled the MATLAB runtime files. And still get errors.

mzRGdJ6.jpg




I am running Windows 10, not sure it that is the issue.
 
Unless we now consider lines to be curves, planes to be uneven surfaces, etc :lol: welcome to post truth in geometry :lol:

Yeah. Alternative Orbiter Facts. :rofl: "It's not actually a run-'way', boy, it's more like some run-'alps'!"

Let's be clear that I'm in no way criticizing Martins.
His project, his decisions, his free time, I'm happy with what I get for free :tiphat: no matter what.

That wasn't my point, anyway, just that it seems to be about some statement he made - that I might have missed in the discussion - where he specifically said that runways need to follow terrain because <some_argument>. I would have been interested in <some_argument> in that case.

---------- Post added at 15:36 ---------- Previous post was at 15:28 ----------

So how to do it?
I couldn't get tileedit to run.

I think most are in agreement it needs to be able to do it. I have seen that some bases have been flatten.


If you can get the OT3 tools to run, you can:

  1. use treeman to extract elevation tiles from the archive,
  2. use ele2png to convert the tile to PNG,
  3. edit the PNG with some editor to have the same color in the pixels where the runway is,
  4. use ele2png to convert the PNG back to tile,
  5. activate Orbiter's default option to load cache tiles before archive tiles.
Right now it is not trivial to get the position of the tile of interest in the available tree. Perhaps some feature in treeman would help where you enter lat/lon and get a list of all available archive tiles that contain that coordinate?
 
If you can get the OT3 tools to run, you can:

  1. use treeman to extract elevation tiles from the archive,
  2. use ele2png to convert the tile to PNG,
  3. edit the PNG with some editor to have the same color in the pixels where the runway is,
  4. use ele2png to convert the PNG back to tile,
  5. activate Orbiter's default option to load cache tiles before archive tiles.
Right now it is not trivial to get the position of the tile of interest in the available tree. Perhaps some feature in treeman would help where you enter lat/lon and get a list of all available archive tiles that contain that coordinate?




Thanks.
So lets say I just wanted to flatten an area on the moon.

Code:
treeman C:\orbiter2016\textures\moon Surf
/01/000000/000000.dds
/02/000000/000000.dds


Not sure where they need to extract to?
Code:
treeman C:\orbiter2016\textures\moon Surf -b C:\orbiter2016\Config\Moon\Base\MoonBaseAlpha1.cfg
error: arguments invalid (5)
 
Thanks.
So lets say I just wanted to flatten an area on the moon.

Code:
treeman C:\orbiter2016\textures\moon Surf
/01/000000/000000.dds
/02/000000/000000.dds


Not sure where they need to extract to?
Code:
treeman C:\orbiter2016\textures\moon Surf -b C:\orbiter2016\Config\Moon\Base\MoonBaseAlpha1.cfg
error: arguments invalid (5)

The first call just listed the available tiles in the "Surf" archive of the moon. Something seems to be wrong there, because even the stock moon "Surf" archive has 2743 tiles in it.

The second call simply uses the wrong syntax, because the "-b" option takes 2 paths: the base configuration file (which you gave), followed by the source texture path (which you omitted). Keep in mind that "-b" is meant to convert old-style bases to the tree, not to do something with new-style base configurations. In particular, old-style configuration files contained "BEGIN_SURFTILELIST" blocks that referenced hires tiles. New-style bases don't have them anymore.
 
Sorry to hijack the thread, but has anyone had this problem?
 
Ok. so do I need to do the 1st step?

I misled you you there was a long list of the dds.
Code:
treeman C:\orbiter2016\textures\moon Surf -b C:\orbiter2016\Config\Moon\Base\MoonBaseAlpha1.cfg c:\orbiter2016\Textures2-y>surf.txt

But didn't see a surf.txt

So Should that get the tiles that are for the base listed?

But is the elevation a color rather a number?
 
Last edited:
Right now it is not trivial to get the position of the tile of interest in the available tree. Perhaps some feature in treeman would help where you enter lat/lon and get a list of all available archive tiles that contain that coordinate?

However, interest in the project has quickly vanished as it seems, so I did not invest much time recently.
I think the first quote pretty much explains why the interest has vanished, it's pretty hard to use. A GUI would eliminate some of that and eliminate the need to rely on cumbersome long command inputs. You do have a mouse right? Why not put it to good use instead of letting idle?
 
Back
Top