Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Beta
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter Beta Topics related to Beta releases of Orbiter and Orbiter development.

Reply
 
Thread Tools
Old 10-17-2017, 08:23 AM   #451
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by kuddel View Post
 Sorry to rain on your parade here, but that has nothing to do with LUA per se!
Lua? I mean Python! Defining scopes by indentation alone sounds nice at first, but turns out terribly error prone in larger projects.
Urwumpe is offline   Reply With Quote
Old 10-17-2017, 09:14 AM   #452
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
as somebody who is constantly confronted with Python: A more user friendly syntax.
I must confess this surprises me. I have found LUA synthax to be a bit tiresome, while python is built on a "write as you think"-paradigm. But I have never worked in python for prolonged periods, so I really can't judge how that worked out. The only thing I use it for is when a helper script gets too complicated to comfortably write in bash (which basically means as soon as it needs function calls... )
jedidia is online now   Reply With Quote
Old 10-17-2017, 10:40 AM   #453
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by jedidia View Post
 I must confess this surprises me. I have found LUA synthax to be a bit tiresome, while python is built on a "write as you think"-paradigm. But I have never worked in python for prolonged periods, so I really can't judge how that worked out. The only thing I use it for is when a helper script gets too complicated to comfortably write in bash (which basically means as soon as it needs function calls... )
I have it right now as pyQt implementation of a GUI client and used it in the past for scripting CFD data post processors... in both cases, it was great to get started and suicidal to edit.
Urwumpe is offline   Reply With Quote
Thanked by:
Old 10-17-2017, 11:37 AM   #454
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by Urwumpe View Post
 in both cases, it was great to get started and suicidal to edit.
I can second that. Even in a well-designed Python-project like Mercurial, that statement above holds true for me. But I guess this is something many weakly-typed languages have in common.
Face is offline   Reply With Quote
Thanked by:
Old 10-17-2017, 01:23 PM   #455
4throck
Enthusiast !
 
4throck's Avatar
Default

Orbiter Lua sub-forum would be great.
Currently we can only add a LUA prefix to a threat inside "SDK".
4throck is offline   Reply With Quote
Thanked by:
Old 10-17-2017, 09:22 PM   #456
kuddel
Donator
Default

Hi,
the LUA enhancement discussion will continue here

To the moderator(s): It might be nice if the last X posts regarding LUA might get moved there. (...and the Python vs. C vs. Lua rant might go to the basement )
kuddel is offline   Reply With Quote
Old 10-29-2017, 06:31 PM   #457
GLS
Addon Developer
 
GLS's Avatar
Default

I've started to look at the terrain editing in SSU again, and noticed some potential conflicts with the "Elev_mod method" of changing the terrain elevation. Let's say in SSU we level a runway area somewhere, and then another addon has, for example a pyramid , somewhat far away. If the terrain editing is done correctly, both changes are propagated up, and eventually they will be on the same time tile... which I guess would make the addons incompatible.

Wild idea (not claiming it to be original): why not extend the surface base "Context" scheme to the edited tiles, so that different addons with different tile edits could co-exist? Adding this to the existing Elev_mod architecture probably won't be easy.

Another wild idea* (also might not be original): in addition to the "Elev_mod method", why not allow something like a "Elev_patch method"? The user would create a sort of mask of the changes, thus making those changes impervious to future base tile changes.
I could create my pyramid, and instead of the rest of my edited tile keeping the base terrain, it would have a sort of "NULL value" meaning those areas are unchanged. This could also work in conjunction the previous idea.

*) assumes tile architecture won't change
GLS is offline   Reply With Quote
Old 11-08-2017, 04:45 PM   #458
martins
Orbiter Founder
Default

Quote:
Originally Posted by GLS View Post
 Another wild idea* (also might not be original): in addition to the "Elev_mod method", why not allow something like a "Elev_patch method"? The user would create a sort of mask of the changes, thus making those changes impervious to future base tile changes.
I could create my pyramid, and instead of the rest of my edited tile keeping the base terrain, it would have a sort of "NULL value" meaning those areas are unchanged. This could also work in conjunction the previous idea.
This method may already be possible with the current elevation tile format.
The "Elev_mod" layer does support a mask flag in the elevation tiles. Any pixel containing a mask flag is ignored, and the original value from the "Elev" layer is used instead.

So if you have two separate edits that eventually end up on the same downsampled tile, these could be resolved without conflict by merging the tiles so that a non-mask value always takes precedence over a mask flag. Conflicts would only arise when trying to merge two non-mask pixels.

I'm not quite up to date as to the current status of tree-merging tools, if any (treeman?) It would be up to the merging tool to correctly merge masked tiles.

This only applies to elevation trees. For texture trees there currently isn't a mod layer with mask support.
martins is offline   Reply With Quote
Thanked by:
Old 11-08-2017, 06:08 PM   #459
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by martins View Post
 So if you have two separate edits that eventually end up on the same downsampled tile, these could be resolved without conflict by merging the tiles so that a non-mask value always takes precedence over a mask flag. Conflicts would only arise when trying to merge two non-mask pixels.
From the user point of view this isn't very friendly, as one would have to list the tile conflicts and merge each pair when a new addon is installed. A system that could isolate each addon's changes would be much easier for the user to handle. Maybe something like this:

Earth\
----Elev_mod\
--------15\ << (existing) default mod, overwritten by any loaded context mod
------------000582\
----------------001739.elv
--------SSU\ << SSU context mod, loaded only when Context SSU is present in the scenario
------------15\
----------------000582\
--------------------001739.elv
--------NASSP\ << NASSP context mod, loaded only when Context NASSP is present in the scenario
------------15\
----------------000582\
--------------------001739.elv


This would also apply to surface textures.

About the mask bits in Elev_mod, tileedit doesn't do that, right?
GLS is offline   Reply With Quote
Old 11-09-2017, 05:50 AM   #460
martins
Orbiter Founder
Default

Quote:
Originally Posted by GLS View Post
 About the mask bits in Elev_mod, tileedit doesn't do that, right?
I thought it does. When you start modifying an elevation tile, tileedit would start with an Elev_mod tile completely masked out. Only the pixels that are overwritten have their mask flag replaced by an explicit value, and only if it differs from the original value.
martins is offline   Reply With Quote
Thanked by:
Old 11-09-2017, 05:56 AM   #461
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by martins View Post
 I'm not quite up to date as to the current status of tree-merging tools, if any (treeman?)
"treeman" doesn't support merging yet.
Face is offline   Reply With Quote
Thanked by:
Old 11-09-2017, 09:54 AM   #462
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by martins View Post
 I thought it does. When you start modifying an elevation tile, tileedit would start with an Elev_mod tile completely masked out. Only the pixels that are overwritten have their mask flag replaced by an explicit value, and only if it differs from the original value.
For some reason I thought it made a copy of the tile and played with it.
Thanks!
GLS is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Beta


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 09:22 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.