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 offline   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
Old 12-03-2017, 11:38 PM   #463
martins
Orbiter Founder
Default SVN commit #72+#73

I just uploaded a new commit. This is nearly entirely concerned with the Lua script interface. It contains the initial step of a restructuring of the interface code, by separating the vessel class methods in a separate module file.

I've also unified the checks for input parameters. For example, all vessel class functions fail now if they don't provide a valid vessel object (rather than returning nil), and consistently check for input parameter types.

All the documentation in the vessel class file is now inline, and formatted for ldoc (Lua documenting system). The output of compiling the help files can be seen in Orbitersdk\doc\orbiter_lua.chm.

If you want to compile the help files yourself, you have to install ldoc. Note that I had to hack the ldoc code a bit to suppress the output of function parameters in the function list at the top of the help page (which made the list look really ugly).

There is a unit testing script for the Lua interface in Scenarios\Tests\unit_test.scn. It's very incomplete so far, but should give an idea of a test format for the interface functions.

This commit is mainly for the benefit of people working on the Lua interface (that is to say, kuddel ), to provide a framework for documentation.

I haven't incorporated kuddel's work on the interface yet, but I am planning to work on that next.
martins is offline   Reply With Quote
Old 12-04-2017, 02:58 PM   #464
kuddel
Donator
Default

Hi Martin,

Quote:
Originally Posted by martins View Post
 It contains the initial step of a restructuring of the interface code, by separating the vessel class methods in a separate module file.
That's nice. I love a clean structure. If you give me a little time, I'll "merge" my changes into the new file-structure...

Quote:
Originally Posted by martins View Post
 I've also unified the checks for input parameters. For example, all vessel class functions fail now if they don't provide a valid vessel object (rather than returning nil), and consistently check for input parameter types.
Yeah, a consistent behavior is another thing that Orbiter-Lua beginners might benefit from.

Quote:
Originally Posted by martins View Post
 All the documentation in the vessel class file is now inline, and formatted for ldoc (Lua documenting system). The output of compiling the help files can be seen in Orbitersdk\doc\orbiter_lua.chm.
O.K. One little note about the .chm file: If you click on a "basic" type link (e.g. 'string') you are lost in the Lua documentation, with no elements to navigate back. This might get annoying...Since you've already hacked the ldoc code, you might be able to fix this too.

Quote:
Originally Posted by martins View Post
 If you want to compile the help files yourself, you have to install ldoc. Note that I had to hack the ldoc code a bit to suppress the output of function parameters in the function list at the top of the help page (which made the list look really ugly).
For general "ldoc syntax verification", I think the "un-hacked" version will be enough, right?

Quote:
Originally Posted by martins View Post
 There is a unit testing script for the Lua interface in Scenarios\Tests\unit_test.scn. It's very incomplete so far, but should give an idea of a test format for the interface functions.
Great! I love unit- / regression-tests.
Not sure how to set up more complex tests, but the general "setup - assert - teardown" approach is very well suited for most of the functionality. Let's see if I add some tests, too.

Quote:
Originally Posted by martins View Post
 This commit is mainly for the benefit of people working on the Lua interface (that is to say, kuddel ), to provide a framework for documentation.
Yeah right, more work for Kuddel ...
No really: It's better that I can (try to) document the parts directly where I've coded it. Most of the vessel API methods documentation will be a copy of the Orbiter-APIs documentation, except for some needed additional information specific for the Lua interface.

Quote:
Originally Posted by martins View Post
 I haven't incorporated kuddel's work on the interface yet, but I am planning to work on that next.
As mentioned above: If you give me a little time, I'll "merge" my changes into the new file-structure. Although possibly not documented, but still more easy to incorporate then.

So to avoid "double work", I would like to merge my work on top of rev. 73 and upload that to the threads first post.
In case you've already started to do that, drop me a quick note.

/Kuddel

---------- Post added at 14:58 ---------- Previous post was at 09:14 ----------

Hi Martin,
it seems that proc.wait_sysdt() and proc.wait_simdt() are not (yet) available when I start the "Tests/unit_test" Scenario , right?
The "unit_test" script will not work well without them
I seems that oapi_init.lua is not working as expected anymore...
I get this error:
Script\oapi_init.lua:113: attempt to yield across C-call boundary

Last edited by kuddel; 12-04-2017 at 03:21 PM.
kuddel is offline   Reply With Quote
Old 12-04-2017, 04:16 PM   #465
martins
Orbiter Founder
Default

Quote:
Originally Posted by kuddel View Post
 [/COLOR]Hi Martin,
it seems that proc.wait_sysdt() and proc.wait_simdt() are not (yet) available when I start the "Tests/unit_test" Scenario , right?
The "unit_test" script will not work well without them
I seems that oapi_init.lua is not working as expected anymore...
I get this error:
Script\oapi_init.lua:113: attempt to yield across C-call boundary
Ah, ok. It did work for me, but admittedly that was from my development build, rather than the deployment build directory. Maybe something wasn't recompiled correctly. I'll check it out tonight.

Edit: I just checked out the latest commit to my PC at work, but didn't see the problem you describe. You do have to enable gravity gradient damping for the corresponding tests to pass, but other than that it seems to go through ok for me.

Did you check out a pristine version, or did you merge with your own edits? Is it possible that there could be a conflict with any of your modifications?
martins 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 01:58 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.