Thanks! Closing this issue then. Could you add some instructions for aircraft maintainers on how to switch to the new instrument to https://wiki.flightgear.org/Aircraft_maintenance#Instruments? Sure!
No, I think it is not yet. However, as much work has been done in the new instrument, I think we should leave this one here alone for backward compat reasons. Applying it has the side effect of rotating the knob slowly without the aircraft dev making adjustments. So i would say, keep the instrument as is, mark it as "legacy" or "simple" or so, and hint aircraft devs to use the more advanced HI instead.
C182: Synced to Github (master 44bdcee)
C182: Synced to Github (master bbdd1ef)
Great thanks!
Thank you :) But for bisecting over multiple repositorys, it is really helpful to be able to quickly checkout an arbitary moment in time. So such a script is in my opinion not "messy" but a great addition.
Thank you :) But for bisecting over multiple repositorys, it is really helpful to be able to quickly checkout an arbitary moment in time. So such a script is in my opinion not "messy" but a great addition. Am 2024-09-27 09:59, schrieb Florent Rougon: Should be better with fixup commit 942a8d294d [1]. Regarding checkoutAtDate.sh, I'm a bit reluctant to add little scripts to FGMeta all over (it's already a mess...). I can share my git-date.py which has a similar goal and supports arbitrary layouts...
Great thanks! Am 2024-09-27 00:53, schrieb Florent Rougon: Hi, Thanks for the patches. I believe that commits 00c68ddac7 [1] and 7d75b277735 [2] do what you want. There are more details in this message [3]. Regards [codetickets:#2878] [4] FGMeta: DNC could print git revisions into logfile after compilation Status: Started Milestone: 2020.4 Labels: FGMeta download_and_compile.sh Enhancement Created: Tue Apr 02, 2024 08:31 AM UTC by Benedikt Hallinger Last Updated: Wed Apr 17, 2024 01:12 PM UTC Owner:...
FGMeta: DNC could print git revisions into logfile after compilation
Great, thanks!
Enhanced https://wiki.flightgear.org/Instrumentation#Heading_Indicator_%28Directional_Gyro%29 Tested ok for me.
Enhanced https://wiki.flightgear.org/Instrumentation#Magnetic_Compass for the new config options and props. Tested good for me.
@jmturner Hi, did you found something, or is this mergeable now?
@jmturner I Think this should be ready.
Hi James, thanks. Would be cool if someone could look over this. Also no idea really, how to add unit tests; but this is a purely cosmetic change as by now.
I fixed that in my branch, and it looks good now, I think. The filter is tuned (can be changed at magnetic-compass config and runtime by setting the <fluid-viscosity type="double">8.2</fluid-viscosity> property. it is accepted at runtime at the instruments node, and at config time in instrumentation.xml. it defaults to 8.2 which I guesstimated to the vicsosity and expected damping of kerosine. As I'm no real pilot, we need to work with that, or someone can provide better numbers. But at least it...
And also the disc bounces around a little too much in my opinion. the idea of the filter is to simulate a damping fluid (lowpass is maybe a bad choice for that. Prior that I used exponential filters in XML space and that did the trick. Don't know how to code a exponential filter however. I think I'll ask in the list.
Added another commit to simulate damping due to fluid. However, the result of this PR still looks not good. Probably someone more capable should look over the math and logic. For example, with the current filter setting the disc has roll when the plane clearly is level when standing still on the ground (tested at EGGK rwy 08R)
Tried to reproduce. I got no crash, but also no turbulence, despite the box beeing ticket.
Added something to the wiki, is this correct now?
When was code changed or fixed no idea if any
FGCom doesn't handle COM failure
So.... four years later I finally think I got this implemented. Repo: https://beni.hallinger.org/git/flightgear.git Branch: SF-2256_FGCom-handleFailure
...Is it intentional this ticket is marked as "fixed" when the last comment still shows errors...?
MagnetiCompass: Expose roll and pitch of disc for animatoin
Thanks, redone my set and now I can test-load the C172. Will this now show other real C172?
Just as a note; I did not test Airliners or so. We were a bunch of small planes here, and I just have seen the glider. In my opinion, it would be good to see actual c172 planes out the window :instead of the gliders :) If I can do anything, please get in touch
I can reproduce this. But was it previously even possible to use user-flyable planes to render other planes? IIRC, this was never possible, but I could be wrong. From the comments I see that it was just AI planes. But, it would be very good to have them visible, even if there is an actual detailed user flyable version installed (as is the case for the 172 in every fgfs installation).
I can reproduce this. But was it previously even possible to use user-flyable planes to render other planes? IIRC, this was never possible, but I could be wrong. From the comments I see that it was just AI planes. But, it would be very good to have them visible, even if there is an actual detailed user flyable version installed (as is the case for the 172 in every fgfs installation).
Swift/Vatsim: blue glider instead of Cessna 172
Pushed another addition, implementing a (optional configurable) low pass filter. it defaults to 10 currently, which allowed me hard landings without tumbling. <heading-indicator-dg> ... <heading-source>/orientation/heading-deg-TEST</heading-source> <limits> <g-node>/accelerations/pilot-gdamped</g-node> <g-filter-time>10.0</g-filter-time> <yaw-rate-source>/orientation/yaw-rate-degps-TEST</yaw-rate-source> ... The g-filter-time is changeable at runtime (limits subtree of the instrument instance)
Pushed another addition, implementing a (configurable) low pass filter. <heading-indicator-dg> ... <heading-source>/orientation/heading-deg-TEST</heading-source> <limits> <g-node>/accelerations/pilot-gdamped</g-node> <g-filter-time>10.0</g-filter-time> <yaw-rate-source>/orientation/yaw-rate-degps-TEST</yaw-rate-source> ... The g-filter-time is changeable at runtime (limits subtree of the instrument instance)
Tested with the c182 (and its /accelerations/pilot-gdamped node, and that seems to work better. The alternative to this implementation is in my view to implement such a thing in c++ space. The best thing would be imho, if the instrument had an internal (configurable) filter in c++ space, but could also source the value from some external/custom property (like the patch adds currently).
Heading Indicator tumbling: make g-node configurable
Heading Indicator tumbling: make g-node configurable
While at it; I also added configurable heading-in and yaw-rate. Especially the heading source may be useful for easily switching heading sources in complex planes. And yaw-rate may be useful to implement custom aircraft error compensation technic. <heading-indicator-dg> ... <heading-source>/orientation/heading-deg-TEST</heading-source> <limits> <g-node>/accelerations/pilot-gdamped</g-node> <yaw-rate-source>/orientation/yaw-rate-degps-TEST</yaw-rate-source> ...
While at it; I also added configurable heading-in and yaw-rate <heading-indicator-dg> ... <heading-source>/orientation/heading-deg-TEST</heading-source> <limits> <g-node>/accelerations/pilot-gdamped</g-node> <yaw-rate-source>/orientation/yaw-rate-degps-TEST</yaw-rate-source> ...
While at it; I also added configurable heading-in and yaw-rate
Heading Indicator tumbling: make g-node configurable
Works, thanks :)
I noticed, the interactive web url accepts "airac=latest", so that might work. https://www.openflightmaps.org/wp-content/plugins/ofmTileMap/ofmTileMap_full.php?airac=latest&language=local&coverage&controls
I tried to patch my FGData myself, but this didn't work (the new entry did not show up in my layer selection box): diff --git a/Phi/topics/Map.js b/Phi/topics/Map.js index 65850a903..4332a5ffe 100644 --- a/Phi/topics/Map.js +++ b/Phi/topics/Map.js @@ -137,7 +137,7 @@ define([ "Navigation Data": L.navdbLayer(), "Other Traffic": L.aiLayer(), - "OpenFlightMaps (AIRAC 2207)": new L.TileLayer("https://nwy-tiles-api.prod.newaydata.com/tiles/{z}/{x}/{y}.png?path=2207/aero/latest", { + "OpenFlightMaps (AIRAC...
I tried to patch my FGData myself, but this didn't work: diff --git a/Phi/topics/Map.js b/Phi/topics/Map.js index 65850a903..4332a5ffe 100644 --- a/Phi/topics/Map.js +++ b/Phi/topics/Map.js @@ -137,7 +137,7 @@ define([ "Navigation Data": L.navdbLayer(), "Other Traffic": L.aiLayer(), - "OpenFlightMaps (AIRAC 2207)": new L.TileLayer("https://nwy-tiles-api.prod.newaydata.com/tiles/{z}/{x}/{y}.png?path=2207/aero/latest", { + "OpenFlightMaps (AIRAC 2405)": new L.TileLayer("https://nwy-tiles-api.prod.newaydata.com/tiles/{z}/{x}/{y}.png?path=2405/aero/latest",...
Phi Map: OpenFlightMap update
And regarding the newlines: I want explicitely have newlines for structuring the text. I really need paragraphs :)
What I also played first, but did not succeed, was a scheme to extend the "class" and just overwrite the values. That did not pan out, since the base class calls always the base class values, and not the one in the inheriting child. But maybe some kind of optional callback or so could be done. I'm not that into object oriented nasal, however.
What I also played first, but did not succeed, was a scheme to extend the "class" and just overwrite the values. That did not pan out, since the base class calls always the base class values, and not the one in the inheritance chain
But without TSAN, it looks somewhat better now as of: Compiled: 2024-05-24 21:21:53 fgmeta: 4c09a9c -/Ticket_2878 (local) flightgear: f854cef91 origin/next (https://git.code.sf.net/p/flightgear/flightgear) fgdata: b7c5dc404 origin/next (git://git.code.sf.net/p/flightgear/fgdata) simgear: 44d4eeba origin/next (https://git.code.sf.net/p/flightgear/simgear) With: --props:/sim/rendering/database-pager/threads=<p> Result p=1 5 tests OK (which was also good before) p=2 5 tests OK (which was broken before...
I try the TSAN thing Turns out I cant. This is overloading my system and the process runs oom. Maybe you have more luck?
Hey Stuart, detailed reproduction steps and also a very detailed analysis is in my github ticket: https://github.com/HHS81/c182s/issues/584#issuecomment-2063950321 - basicly launch a first instance with added commandline in your launcher: "--multiplay=in,10,127.0.0.1,5010 --multiplay=out,10,127.0.0.1,5011 --callsign=T-EST1 --airport=LOWI --parking-id=GA05" - and then a second one (separate shell), with "--multiplay=in,10,127.0.0.1,5011 --multiplay=out,10,127.0.0.1,5010 --callsign=T-EST2 --airport=LOWI...
If you mean the OSG pager threads option property (/sim/rendering/database-pager/threads), then yes...
(sorry, wrong ticket. This is still pending)
Merged, please check and let me know all is good. Works, thank you!
Works, thank you!
Confirmed, works good!
Add date formatting options
Merged
Version 1.10
Patch attached
Patch attched
Add date formatting options
Add date formatting options
Add date formatting options
Hi Stuart, thanks for investigating. Recompiled next with the patch applied as of: Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: src/Scripting/NasalModelData.cxx modified: src/Scripting/NasalModelData.hxx Compiled: 2024-05-02 15:13:32 fgmeta: 4c09a9c -/Ticket_2878 (local) flightgear: 941bc8dda origin/next (https://git.code.sf.net/p/flightgear/flightgear) fgdata: 71dcf80dd origin/next...
Sure Josh! diff --git a/gui/dialogs/autopilot.xml b/gui/dialogs/autopilot.xml index d08b80d6f..004f9c69e 100644 --- a/gui/dialogs/autopilot.xml +++ b/gui/dialogs/autopilot.xml @@ -182,6 +182,15 @@ <script>hdg.set("wing-leveler")</script> </binding> </radio> + <input> + <row>0</row> + <col>2</col> + <property>/autopilot/settings/target-roll-deg</property> + <live>true</live> + <binding> + <command>dialog-apply</command> + </binding> + </input> <text> <label>Heading Bug</label> <halign>right</hali...
Thank you!
I assume you already have a fgdata git clone; so git add remote beni https://beni.hallinger.org/git/fgdata.git and a git fetch beni should do the trick. Then you should be able to checkout via git checkout -t beni/GenericAP-WingsLevelConfigurable should do the trick.
I assume you already have a fgdata git clone; so git add remote beni <url> and a git fetch beni should do the trick. Then you should be able to checkout via git checkout -t beni/GenericAP-WingsLevelConfigurable should do the trick.
I assume you already have a fgaddon git clone; so git add remote beni <url> and a git fetch beni should do the trick. Then you should be able to checkout via git checkout -t beni/GenericAP-WingsLevelConfigurable should do the trick.
[Enhancement] Generic Autopilot: Added settings/target-roll-deg as text field to GUI
Canvas placing on AI/MP Model objects not working properly anymore
Multiplayer remote sound is broken on next
Also added a new checkoutAtDate.sh script to checkout flightgear/simgear/fgdata at a specificprevious day: flightgear-build$ ./checkoutAtDate.sh 2023-11-14 flightgear: e7466ddbc (Update metainfo file, 2023-10-27) fgdata: 53a6e3b8f (Add CG-MAC to weights dialog, 2023-11-11) simgear: 2bd97e43 (WS30: Tile loading - reduce intersections, 2023-11-12)
Also added a new checkoutAtDate.sh script to checkout flightgear/simgear/fgdata at a specific day: flightgear-build$ ./checkoutAtDate.sh 2023-11-14 flightgear: e7466ddbc (Update metainfo file, 2023-10-27) fgdata: 53a6e3b8f (Add CG-MAC to weights dialog, 2023-11-11) simgear: 2bd97e43 (WS30: Tile loading - reduce intersections, 2023-11-12)
I just added a new command line option: --gitver to show the versions. flightgear-build$ ./download_and_compile.sh --gitver GIT versions: fgmeta: b17287c -/Ticket_2878 (local) flightgear: 4b0bf1784 origin/next (https://git.code.sf.net/p/flightgear/flightgear) fgdata: d5927e5ee detached/head (local) simgear: 89c57738 detached/head (local)
I just added a new command line option: --gitver to show the versions.
FGMeta: DNC could print git revisions into logfile after compilation
Trim using mousewheel too coarse
Trim using mousewheel too coarse
Trim using mousewheel too coarse
The work-around for the newlines is pretty bad, can you give me a test case with just the regular text and I'll fix the centering? Sure, here it is: https://github.com/HHS81/c182s/blob/a2a84e2f7c0ddbf53e4f250ae4c41ad489cd0dfb/Nasal/c182s.nas#L1175-1194 # Show a welcome dialog for first time users canvas.MessageBox.information( "Welcome!\n", "We wish you alot of fun with your new Cessna 182!\n\n" ~ "If you step up from the C172, you will appreciate the bigger engine and the higher " ~ "power that...
… maybe I‘m also just riding the wrong horse for my usecase and are misusing the messagebox? Is maybe just creating my own canvas window the more correct approach? (Just thinking loud)
<meta http-equiv="content-type" content="text/html; charset=utf-8">The work-around for the newlines is pretty bad, can you give me a test case with just the regular text and I'll fix the centering? <link itemprop="url" href="https://sourceforge.net/p/flightgear/codetickets/2879/"> <meta itemprop="name" content="View"> <meta itemprop="description" content="View"> Sure, here it is:https://github.com/HHS81/c182s/blob/a2a84e2f7c0ddbf53e4f250ae4c41ad489cd0dfb/Nasal/c182s.nas#L1175-1194’’’ # Show a welcome...
One thing is, that the label does not seem to respond with the proper height if text gets wrapped. Or, like said, newlied. I could not find, where that calculation is taking place.
On thing is, that the label does not seem to respond with the proper height if text gets wrapped. Or, like said, newlied. I could not find, where that calculation is taking place.
@jmturner I think you can review this. The problem I faced was, that the height-for-width feature does not work properly here, because of the newlines. But splitting that up now works out of the box: the label itself adjusts already correctly.
@jmturner I think you can review this. The problem I faced was, that the height-for-width feature does not work properly here, because of the newlines. But splitting that up now works out of the box: the label itself adjusts already correctly based on wrapped text length.
@jmturner I think you can review this. The problem I faced was, that the height-for-width feature does not work properly here, because of the newlines. But splitting that up now works out of the box.
Probably the newlines are messing with the Label's styling / center code. I figured it out. The label can't deal very well with newlines and height calculation, so the text is placed "centered" and thus too low for the resulting height. An easy fix is to make MessageBox aware of "\n" delimited text. I added and pushed to my own repo (see above) a commit now that splits the text and adds each line as separate label; that makes the calculation of the box working out of the box. Screenshot attached:...
Canvas MessageBox: make sizeable / newline support
heading_indicator_dg.cxx: Error code modelling
heading_indicator_dg.cxx: Error code modelling
so when merging #2839 this Ticket here can be closed as fixed. It is fixed, closing this one.
Demo is here: https://github.com/HHS81/c182s/pull/586 What I still struggle with is, how i can prevent those big margins at the top and bottom of the text. If I make the height value smaller, top margin will remain, and text overflows into the buttons (and behind the border of the dialog, if too small). Any ideas for that? Probably the newlines are messing with the Label's styling / center code. I digged into FGData, but could not find the place where this is defined.
Demo is here: https://github.com/HHS81/c182s/pull/586 What I still struggle with is, how i can prevent those big margins at the top and bottom of the text. If I make the height value smaller, top margin will remain, and text overflows into the buttons (and behind the border of the dialog, if too small). Any ideas for that?