Activity for Mariusz Matuszek
-
Mariusz Matuszek posted a comment on ticket #2719
... and this one was me adjusting LOD ranges in flight. It happened right after closing the LOD adjustment menu.
-
Maybe I'll add two recent backtraces then. The first one happened when 'just flying', during a turn, when some new scenery had to be shown.
-
Testing... Edit: command ../fgmeta/download_and_compile.sh -s --cleanup -pn -j8 --cmake-arg ALL=-DCMAKE_EXPORT_COMPILE_COMMANDS=YES FGFS OSG SIMGEAR worked as expected. All compile_commands.json files were created as requested. Thank you very much again.
-
Testing...
-
I agree about the order, so component-specific options can override the global ones. The option to aggregate multiple cmake arguments in a single --cmake-args option seems interesting too, although I personally do not set that many options, so to me the current method (augmented with the 'ALL' option) would be sufficient. Could a comma be used as an argument list separator, instead of a space? I do not recall any cmake arguments using commas off the top of my head.. As for deciding between: --cmake_arg...
-
I agree about the order, so component-specific options can override the global ones. The option to aggregate multiple cmake arguments in a single --cmake-args option seems interesting too, although I personally do not set that many options, so to me the current method (augmented with the 'ALL' option) would be sufficient. Could a comma be used as an argument list separator, instead of a space? I do not recall any cmake arguments using commas off the top of my head.. As for deciding between: --cmake_arg...
-
Looking at the way you modified the d_and_c I was thinking about adding a phony component ALL to the CMAKE_BASED_COMPONENTS list and then, in every component-specific cmake invocation, like, for example $extra "${FGFS_CMAKE_ARGS[@]}" \ append $extra "${ALL_CMAKE_ARGS[@]}" So together that part of cmake call would look like this (fgfs in example): ... $extra "${FGFS_CMAKE_ARGS[@]}" \ $extra "${ALL_CMAKE_ARGS[@]}" \ ../../flightgear 2>&1 | _logOutput Would this make sense? It looks like your logic...
-
Arrgh! gotta love it, when editor 'knows better' and there is no edit option :( Anyway, example use was meant to look like d_and_c "other options" --cmake-option=ALL="some cmake option" "components to build" Sorry for the noise.
-
d_and_c --cmake-option
-
Like this?
-
OK :-)) With refactoring in mind, could we have these additional functions in strutils?
-
Yes, your fix of stripping left and right is better. What do you think of pushing it to next too, so it doesn't get lost? Then a better clean-up can be attempted later?
-
ah, in that case: diff --git a/src/Main/options.cxx b/src/Main/options.cxx index 5c2fbd8b8..c119e5490 100644 --- a/src/Main/options.cxx +++ b/src/Main/options.cxx @@ -2716,7 +2716,8 @@ void Options::readConfig(const SGPath& path) continue; } simgear::optional<std::string> value;</std::string> //simgear::optional<std::string> value;</std::string> string value; const size_t space = line.find(' '); const size_t equal = line.find('='); if (space != string::npos && space < equal) { @@ -2727,6 +2728,10...
-
ah, in that case: diff --git a/src/Main/options.cxx b/src/Main/options.cxx index 5c2fbd8b8..c119e5490 100644 --- a/src/Main/options.cxx +++ b/src/Main/options.cxx @@ -2716,7 +2716,8 @@ void Options::readConfig(const SGPath& path) continue; } simgear::optional<std::string> value;</std::string> //simgear::optional<std::string> value;</std::string> string value; const size_t space = line.find(' '); const size_t equal = line.find('='); if (space != string::npos && space < equal) { @@ -2727,6 +2728,10...
-
Confirmed here. Adding a patch against current 'stable' (could not test with 'next' as it does not currently go beyond a black screen on my system). This fixes .fgfsrc entries. Note that the same problem happens with trailing spaces in command line options, i.e. fgfs --aircraft="someAircraft " will also be misunderstood. Attached patch does not address the cmd line case.
-
You are welcome :) Btw, please have a look at ticket #2934, as it may be about exact same issue and perhaps could be closed too.
-
Cross referencing ticket #2936, as a patch is included there. Sorry for duplicating the issue.
-
Oops, I think I duplicated #2934. Anyway, a fix is attached.
-
Some fgdata textures are not found (in 2024.1)
-
$ cd dnc_managed/flightgear (or wherever you have the downloaded FG sources) run 'git status' (output you will get will be similar to the one below) $ git status On branch next Your branch is behind 'origin/next' by 21 commits, and can be fast-forwarded. (use "git pull" to update your local branch) $ git pull remote: Enumerating objects: 9, done. remote: Counting objects: 100% (9/9), done. remote: Compressing objects: 100% (5/5), done. remote: Total 5 (delta 4), reused 0 (delta 0) Unpacking objects:...
-
Actually I ran across this yesterday and also patched this, at an earlier processing stage. Please consider. --- a/src/Main/options.cxx +++ b/src/Main/options.cxx @@ -2714,6 +2714,14 @@ void Options::readConfig(const SGPath& path) break; line = line.substr( 0, i ); + // do not bother parser with empty lines + if (line.length() == 0) { + in >> skipcomment; + continue; + } + + SG_LOG( SG_GENERAL, SG_DEBUG, "Processing .fgfsrc line: " << line ); + simgear::optional<std::string> value; const size_t space...
-
Actually I ran across this yesterday and also patched this, at an earlier stage. Please consider.
-
That sounds very good to me. We could also consider having CustomWaypoint volatile, i.e. not stored permanently at all. So if, for example, a set of CWs would be defined by some add-on on init, it would be gone when FG exits (or crashes).
-
James, I don't know if it is even possible to define all possible use cases in advance. On the forum a 'VRP' use case was presented, but there could be others, like (I think already mentioned) parking positions, or gliding competition waypoints, etc. I understand your dislike of having the type (use case) embedded in the name, but since this would be a new feature, we don't know in advance how it would be used and by whom. These POIs could be very dynamic and short lived by their very nature, so...
-
You are right. I think I missed the 'opt-in' idea. Sorry for making noise in this thread.
-
Researching NDB's I came across this discussion.. Would an acceptable solution be to keep the original interface intact (i.e. the frequency property remains an int) and add second property (like int frequency_fraction) to the instrument? This additional property would default to zero, so all existing ADF instruments would simply continue to work as if nothing had changed.
-
I was baffled enough by them that I wanted a confirmation, that they are indeed unused. That is why I only commented them out. ~~Will try to send a correct merge request.~~ Edit: commits refreshed. As for updating to AbstractInstrument, I wouldn't want to step on Benedikt's toes..
-
I was baffled enough by them that I wanted a confirmation, that they are indeed unused. That is why I only commented them out. Will try to send a correct merge request. As for updating to AbstractInstrument, I wouldn't want to step on Benedikt's toes.. Edit: commits refreshed.
-
I was baffled enough by them that I wanted a confirmation, that they are indeed unused. That is why I only commented them out. Will try to send a correct merge request. As for updating to AbstractInstrument, I wouldn't want to step on Benedikt's toes..
-
Clean up gsdi.hxx to match code in cxx
-
Fix an Aitopilot error message
-
Fix an Aitopilot error message
-
Fix an Aitopilot error message
-
Page Broken (500): https://sourceforge.net/u/mrmm/flightgear/ci/d3a1cd592347ec5ba89a6479f1c8f6593c870150/
-
Yesterday, during our MP event I had a deja'vu feeling. Either there is a regression, or there is another issue with the model, showing the same behaviour. Screenshots and version details are in a forum post here https://forum.flightgear.org/viewtopic.php?f=10&t=39025&p=411663#p411663
-
Just a comment on the idea. Perhaps Alt+NumKeypad5 (if available) would be a better choice? As the NumKeypad5 is used to center controls, it somehow looks more naturally connected to enabling auto-coordination.
-
Just a comment on the idea. Perhaps <alt>+<numkeypad5> (if available) would be a better choice? As the <numkeypad5> is used to center controls, it somehow looks more naturally connected to enabling auto-coordination.</numkeypad5></numkeypad5></alt>
-
Either that, or cross-linking in documents. That is, mentioning one in the other. For example in local docs including, at the beginning, a statement "this document describes technical details of the Weather System. For more user oriented perspective please look at this Wiki entry: URL Likewise, in the Wiki mention the local docs as a source for more technical knowledge.
-
I think the local doc would be preferred, as it is always present and available. That was my first try. However I would suggest to include a reference to the wiki entry at the beginning of the local documentation file, with a comment, that additional/more recent information may be found there.
-
On closer verification it turned out to be a user error (wrong wind model used). Since advanced weather engine is complex and full of (sometimes obscure) interrelated features I propose to add a help reference to weather dialog, with this patch: diff --git a/gui/dialogs/weather.xml b/gui/dialogs/weather.xml index 920103cc9..f6609693a 100644 --- a/gui/dialogs/weather.xml +++ b/gui/dialogs/weather.xml @@ -505,11 +505,16 @@ <label> </label> </text> - <empty> + <button> <row>0</row> <col>2</col> - <stretch>true</stretch>...
-
On closer verification it turned out to be a user error (wrong wind model used). Since advanced weather engine is complex and full of (sometimes obscure) interrelated features I propose to add a help reference to weather dialog, with this patch: diff --git a/gui/dialogs/weather.xml b/gui/dialogs/weather.xml index 920103cc9..f6609693a 100644 --- a/gui/dialogs/weather.xml +++ b/gui/dialogs/weather.xml @@ -505,11 +505,16 @@ <label> </label> <empty></empty> <button> <row>0</row> 2</button> <stretch>true</stretch>...
-
Great. There is a similar issue (not printing the offending file name) with detected incorrect RGB profiles. Not sure if it merits a separate ticket, as it seems very similar to this one, so I'll just mention it here. [WARN]:OSG /fg_next/install/simgear/include/simgear/debug/OsgIoCapture.hxx:37: PNG lib warning : iCCP: known incorrect sRGB profile
-
METAR does not update wind direction
-
One more modification, as spaces in directory names also resulted in false positives. if int((line.strip()[line.index("MATERIAL"):]).split()[19]) > 128: I think it may come handy for bulk inspection of whole directories, be it fgdata or Aircraft. Maybe even some sort of automated check? James, if you want to add it to fgmeta I am more than happy.
-
Additional modification, replacing the test with if int(line.strip().split()[19]) > 128: will catch (as parse errors) shininess specified as non integer values
-
Just tried a quick workaround. 1st step (using fgdata as an example): $ cd /path/to/fgdata $ grep -R MATERIAL . > /tmp/materials.txt 2nd step (quick and dirty Python script): with open("materials.txt", "r") as f: for line in f: try: if float(line.strip().split()[19]) > 128.0: print(line.strip()) except: print("PARSE ERROR:", line.strip()) This script will print an error on some unusual material definitions, like e.g. material name having spaces in it, but should otherwise be useful.
-
Just tried a quick workaround. 1st step (using fgdata as an example): $ cd /path/to/fgdata $ grep -R MATERIAL . > /tmp/materials.txt 2nd step (quick and dirty Python script): with open("materials.txt", "r") as f: for line in f: try: if float(line.strip().split()[19]) > 128.0: print(line.strip()) except: print("ERROR:", line.strip()) This script will print an error on some unusual material definitions, like e.g. material name having spaces in it, but should otherwise be useful.
-
Just tried a quick workaround. 1st step (using fgdata as an example): $ cd /path/to/fgdata $ grep -R MATERIAL . > /tmp/materials.txt 2nd step (quick and dirty Python script): with open("materials.txt", "r") as f: for line in f: try: if float(line.strip().split()[19]) > 128.0: print(line.strip()) except: print("ERROR:", line.strip()) This script will an error on some unusual material definitions, like e.g. material name having spaces in it, but should otherwise be useful.
-
Small fix - added missing file
1
