Discussion Developing Addons for different Orbiter Versions

[Face]

what if I want a base to be there in one scenario and not be there in another? like a moon landing site. shall we patch the tiles each time? it's dangerous: tiles are some tons of GB of data, really difficult to touch, you miss something and you'll have to redownload everything

To be fair, a tile in the sense of the quad-tree is just some kBs. It is the whole archive format that takes up GBs, but you don't necessarily have to edit this every time.

---------- Post added at 17:07 ---------- Previous post was at 17:03 ----------

That's how it is officially right now, with those "terrain patch files" stored in a special "Elev_mods" subfolder.

Unfortunately, you also need standard tiles of the same level before they have any effect IIRC. So an add-on could not just drop in some elev_mods, but there needs to be a system that also "merges" it into the installed tile tree.

 

[Donamy]

Can vessel bases and runways, be made to land on ?

 

[Face]

Can vessel bases and runways, be made to land on ?

You mean vessel-to-vessel collision? Artlav already demonstrated this with his Shukra-Venus base, so yes: https://github.com/artlav/venus_balloon_station

 

[fred18]

Can vessel bases and runways, be made to land on ?

You mean vessel-to-vessel collision? Artlav already demonstrated this with his Shukra-Venus base, so yes: https://github.com/artlav/venus_balloon_station

IIRC it uses an attachment system to simulate this. Of course in that way it is possible but it's a big "fake", IMO not what is intended here.

 

[Face]

IIRC it uses an attachment system to simulate this. Of course in that way it is possible but it's a big "fake", IMO not what is intended here.

Ah... but isn't the way GeneralVehicle works also a kind of fake, then?

 

[Urwumpe]

That's how it is officially right now, with those "terrain patch files" stored in a special "Elev_mods" subfolder.

But those replace complete tiles of the terrain, right?

So, there would still be a need to produce those Elev_mods more easily.

(But that could be included into a base editor tool then)

 

[Face]

But those replace complete tiles of the terrain, right?

Not exactly... they patch them. There is a "transparency" value defined which will make pixels not override the underlying original value. But you have to have the standard tile at the appropriate level in your tree.

 

[fred18]

Ah... but isn't the way GeneralVehicle works also a kind of fake, then?

GV forces the vessel status definition, bypassing orbiter, doing the calculations by itself and applying the result to the vessel. The good part of it is that nothing that the core shall consider, first of all the landed and not flying status of the vessel, is altered. And the difference I see more is interaction: a base shall interact with all the other vessels, so the use of a "fake" system is always possible but would also be difficult. GV only applies the status to itself.

Of course I could make a plane that is landing attached to the runway and then move the attachment point to "fake" the landing, but how many parameters shall I consider then? and what if the planes itself uses other variables (for example the ground contact to simulate the wheels turning)? everything is much more difficult there.

I still believe that if it was possible to set a cfg that says flat center coordinates, flat size and flat altitude, and then I find in the sim a nice flat square a lot (a lot!) of bases compatibility and relevant issues would be solved. That's my very strong belief...

EDIT: adding also a "shape factor" could allow to have rectangular flat areas, that would easily flatten runways just getting the right coordinates

 

[Donamy]

I made this some time back. It would be awesome if you could land on it, and have vehicles drive around.

 

[Face]

Of course I could make a plane that is landing attached to the runway and then move the attachment point to "fake" the landing, but how many parameters shall I consider then? and what if the planes itself uses other variables (for example the ground contact to simulate the wheels turning)? everything is much more difficult there.

In the end it is some software that simulates certain physics aspects. Where it is implemented, doesn't really matter. Therefore I wouldn't call anything fake in this regards. :shrug:

I still believe that if it was possible to set a cfg that says flat center coordinates, flat size and flat altitude, and then I find in the sim a nice flat square a lot (a lot!) of bases compatibility and relevant issues would be solved. That's my very strong belief...

I think that it would ease the problem at hand a bit: a split ecosystem where developers shy away from the newer - more complex - environment. But you'll have to demonstrate it first, I guess nobody else will invest too much time on this. Asking the D3D9 folks might be worth a try, though.

 

[4throck]

I still believe that if it was possible to set a cfg that says flat center coordinates, flat size and flat altitude...

Even simpler that that, let's consider Pads only and flatten the ground below them. That should be default behavior in the first place.
Radius comes from the radius of the pad. Altitude is the maximum original altitude point below the pad. No extra parameters needed.

No need to confuse things with tunnels and driving around. Those are separate special cases. A simple flat pad will do.

 

[gattispilot]

I made this some time back. It would be awesome if you could land on it, and have vehicles drive around.

Was this 2010 or 2016

---------- Post added at 11:19 AM ---------- Previous post was at 11:18 AM ----------

Even simpler that that, let's consider Pads only and flatten the ground below them. That should be default behavior in the first place.
Radius comes from the radius of the pad. Altitude is the maximum original altitude point below the pad. No extra parameters needed.

No need to confuse things with tunnels and driving around. Those are separate special cases. A simple flat pad will do.

That would be great.

 

[fred18]

Even simpler that that, let's consider Pads only and flatten the ground below them. That should be default behavior in the first place.
Radius comes from the radius of the pad. Altitude is the maximum original altitude point below the pad. No extra parameters needed.

No need to confuse things with tunnels and driving around. Those are separate special cases. A simple flat pad will do.

can I say pad and runways? anyway once you code a function that flats a certain area, it should be a no brainer to have also a custom flat area.

 

[Donamy]

Was this 2010 or 2016

It's 2010, along with a few more. Corn Ranch, Wallops Island and a couple Sci-Fi ones.

 

[4throck]

can I say pad and runways? anyway once you code a function that flats a certain area, it should be a no brainer to have also a custom flat area.

Sure, but people were asking for a simple test case.
Makes sense from a programming POV to ask for something simple.

So let's keep the requested feature list simple, and down to a single feature:
- Defining a pad on a base should flatten the terrain below it by default.


For you and me this is obvious (including for runways), but not so for others. So let's keep it simple and focused to avoid miss communication.

 

[fred18]

Hi Face,

if you have 2 minutes can I ask a couple of question relevant to planetary elevation?

I was giving a look at the planet texture files and the explanation in the pdf provided by Martin but some things are not clear, since it is the first time I approach it. How do you get the data? you have to deflate the .tree file, right? do you use oapideflate or the z lib is needed?

and how do you get the actual data then?

thanks in advance for your time!
Fred

 

[Face]

Hi Face,

if you have 2 minutes can I ask a couple of question relevant to planetary elevation?

I was giving a look at the planet texture files and the explanation in the pdf provided by Martin but some things are not clear, since it is the first time I approach it. How do you get the data? you have to deflate the .tree file, right? do you use oapideflate or the z lib is needed?

and how do you get the actual data then?

thanks in advance for your time!
Fred

This question is not easily answered in forum posts, especially because I'd need some more context from you, which could be better done in something like Discord. Do you have access to the Orbiter Discord channel? Perhaps we can meet there and get to it more focused instead of spamming the thread here with short back and forth posts. I'm online ATM.

 

[fred18]

This question is not easily answered in forum posts, especially because I'd need some more context from you, which could be better done in something like Discord. Do you have access to the Orbiter Discord channel? Perhaps we can meet there and get to it more focused instead of spamming the thread here with short back and forth posts. I'm online ATM.

what is Orbiter Discord Channel? :shrug:

 

[Face]

what is Orbiter Discord Channel? :shrug:

Practically a replacement for the IRC channel: https://www.orbiter-forum.com/showthread.php?t=39026

 

[martins]

Regarding terrain flattening, a few things to consider:

* currently, the vertical elevation resolution is quite low (1 meter in 2016, potentially finer in the beta, but only globally, and only if the total global elevation range can be encoded in 16bits).

This means that smooth gradients can't be implemented yet and always come out as a staircase effect, in particular for the high (horizontal) resolution tiles. This means that terrain flattening at the moment always means constant elevation (0-th order flattening, if you like)

In the future I want to implement support for local variations for the vertical resolution that would allow much finer elevation steps locally. This should allow to implement smooth gradients, and thus 1-st order flattening. I can't promise when and how this will happen, but maybe something to keep in mind for elevation flattening tools being developed.

* In the long run, I want to move away from the concept of bases, and instead implement surface structures as an additional quadtree layer. In that context, a base wouldn't be a physical entity, but just happen to be a place containing an assembly of buildings and runways/pads. (the latter possibly not defined as a structure, but just as part of the surface textures).

There may still be a list containing the location of bases for the purposes of navigation tools and map markers, but I don't know if this will be sufficient for an automatic surface flattening implementation.


Anyway, all this is not yet relevant, just an early rumination for my ideas of future directions, meant as food for thought for any future direction for elevation adjustment tools.