Activity for Huntley Palmer
-
Huntley Palmer created ticket #2951
Segfault if loglevel debug in environment_mgr
-
s'OK I found the details, dnf removed plib and plib-devel and did make/make install on the fteched svn version. the result is the same, can cause the segfault.
-
I'm still lost. Does that mean I have to get a specific version of PLIB from their site, in which case how do I tell the flightgear build to use the one I make externally or does it mean I must modify flightgear build ( ccmake ?? ) somehow to cause the flightgear build to make a different version of PLIB ? Tks.
-
The original bug report is here: the best decription I could come up with is: .. In this case, when the High Detail slider is clicked, the pointer for the name of the parent dialog is invalid. This happens if both MP server is not connected and AI traffic is not enabled ( at least here ) ; if either MP or AI are active the Parent Dialog has a name, 'static-lod'. Perhaps an AI/MP dialog shouldn't be accessible if AI and MP are inactive, perhaps those menu entries shouldn't be clicked.
-
Yes, Linux here. I can download and build PLib 1.8.5, what sould I adjust in the Flightgear build to prevent using the supplied package ? Tks
-
0 0x000000000076db63 in fgPopup::checkHit(int, int, int, int) () No symbol table info available. 1 0x00007ffff784d4c8 in puGroup::checkHit(int, int, int, int) () from /lib64/libplibpu.so.1.8.5 No symbol table info available. 2 0x00007ffff7851186 in puMouse(int, int, int, int) () from /lib64/libplibpu.so.1.8.5 No symbol table info available. 3 0x0000000000d50dbc in PUIEventHandler::handle(osgGA::GUIEventAdapter const&, osgGA::GUIActionAdapter&, osg::Object, osg::NodeVisitor) () No symbol table info...
-
Per your post today, 10Dec, "It's still doin it " ( That would be after a full 2024.1 fetch and build with gitlab-2024-build as of yesterday )
-
Per your post today, 10Dec, "It's still doin it "
-
Trailing blank in specified airport forces relocation
-
Trailing blank in specified airport forces relocation
-
OK Thanks !
-
Hi ! These errors are still showing as Alert level console messages on 2024.1 fgdata c172p. Can the default aircraft be updated to this fix ?
-
Local building textures wrong folder call
-
simgear 811f06 Add SPDX headers drops #ifndef
-
A blank line in .fgfsrc causes 'next' to terminate
-
A blank line in .fgfsrc causes 'next' to terminate
-
Hi ranguli, The test_navradio,cxx code I appended 01-23 looks to be present in ubit tests' source tree so I'd say go ahead and mark this ticket, fixed. Tks for attending to this !
-
Close then as ‘invalid’ with a pointer to the correct place, eg if the aircraft / add-on / scenery has a maintainer or bug tracker.
-
Thank You !
-
This error is once again present, now in Objects/w080n40/w072n42/1777939.stg at lines 2185 ff Models/Maritime/Misc/craneblue.ac and cranewhite2.ac must be removed for the console flood to go away. Running osgviewer on the .ac models will also show the continuous error flood. Edit, I've submitted both models, without 'Light' entries to the scenery database.
-
This error is once again present, now in Objects/w080n40/w072n42/1777939.stg at lines 2185 ff Models/Maritime/Misc/craneblue.ac and cranewhite2.ac must be removed for the console flood to go away. Running osgviewer on the .ac models will also show the continuous error flood.
-
Close it, thanks. That message isn't appearing near KBOS at the moment.
-
AIAircraft.cxx 'outOFSight' : bool outOfSight = false; 197 updatePrimaryTargetValues(dt, flightplanActive, outOfSight); // target hdg, alt, speed 198 if (outOfSight) { and : void FGAIAircraft::updatePrimaryTargetValues(double dt, bool& flightplanActive, bool& aiOutOfSight) 1162 { Does this work, not passing the boolean's address ? I had the impression outOfSight was not getting correctly set.
-
The new tests in AIAircraft.cxx seem overly restrictive for an AI Scenario with a plane moving between a runway endpoint and its parallel taxiway: the right-angle turns fail at line 988: if (abs(headingDiffCurrent) > 80 && speed > 0) { and after that test is patched to if (abs(headingDiffCurrent) > 90 && speed > 20) { the test at 1245: if (stuckCounter > AI_STUCK_LIMIT) { SG_LOG(SG_AI, SG_WARN, "Stuck flight " << _callsign << " killed on leg " << fp->getLeg() << " because point behind"); setDie(true);...
-
AIAircraft.cxx leadPointReached() logging causes segfault
-
AIAircraft.cxx leadPointReached() logging causes segfault
-
AIAircraft.cxx leadPointReached() logging causes segfault
-
Tested on Lancair 235 and Ryan Navion, the fix looks great, thanks. Without the fix props engine/egt-degf and engine/egt-degC stay fixed at ambinet; after the fix is applied egt temperatures respond to both throttle and mixture controls with a drop-off on both rich and lean of peak. Tks again !
-
I think so: the addition to compare egt to temp was made without any comment , I'm guessing as a fix to an erroneously low egt. To my mind the code ought to read: .... // 10% should do it. float massFlow = _fuelFlow + (rho * 0.5f * _displacement * speed); float specHeat = 1300; float corr = 1.0f/(Math::pow(_compression, 0.4f) - 1.0f); _egt = corr * (power * 1.1f) / (massFlow * specHeat); _egt += temp; // Oil temperature. ..... Thanks !
-
After looking at the above link, I think it's a case of adding ambient ( K ) to _egt variable, not converting to Kelvin: From https://www.grc.nasa.gov/WWW/K-12/airplane/ottoa.html Gamma, ratio of specific heats Cp / Cv is written as '%' percent sign (1) Compression Stroke: T3 / T2 = r ^ ( % - 1 ) (2) Combustion: T4 = T3 + fQ /cv (3) Power Stroke: T5 / T4 = r ^ ( 1 - % ) (4) Bottom Line Wk done: W = cv * [(T4 - T3) - (T5 - T2)] To find EGT above ambient: ( T5 - T2 ) : from (3) T4 = T5 / ( r ^ 1 -...
-
OK, many thanks for attending to this.
-
Yerp, it's like proof by induction, first you don't believe, then you do, etc. I just googled 'thermodynamics exhaust gas temperature work done" and got this page: egt: Working back from the bottom line seems to match what the comments in pistonEngine.cpp say about EGT.
-
If you have a sealed, zero heat loss cylinder with a friction-free piston then, doing work on pushing the piston to compress the gas inside, you'd expect the same temperature 'change' regardless of whether the gas started at 0 Celsius or 200 Celsius: the change in temperature would relate to the work done. Likewise, if you knew the work done then you could figure the rise ( change ) in temperature over the starting point. It wouldn't be an absolute : work done == change in "momentum" .
-
( A - level ) Me Too ! Reading through the comments, EGT is derived by re-arranging the equation for power gained from the change in temperature of an expanding gas. Since it's a temerature difference, not the absolute value, the result is the same Celsius or Kelvin: temperature change between 0 and 1 Celsius is the same as between 273 and 274 Kelvin. so the code line: `_egt = corr * (power * 1.1) / (massFlow * specHeat)` yields a value for temperature _change _ presumably over ambient. The next...
-
If I understand your comment, a Kelvin degree equals a Centigrade degree, the difference between degrees Kelvin and degrees Centigrade is in the zero origin rather than in the scale factor. Specific heat refers to energy to move temperature over a unit change, the same for Centigrade and Kelvin.
-
After fetch & pull 26Jun with changes to treebin:
-
I'm running with no multithreading selected and when I've tried setting database-pager-threads to 1 : the sim runs slower but for much longer without error. Fgfs log shows many errors viz: /fgfs/simgear/simgear/scene/tgdb/TreeBin.cxx:507: Error parsing tree entry in: Path "/fgScen/tsyn/Trees/w090n40/w086n45/w090n40_w086n45_1548792_SubUrban_trees_shader.txt" line: "" Attached is a screen grab of the backtrace:
-
Also on Fedora 39, Ryzen 16GBy Nvidia 750Ti on a build fetched less than 5 days ago. Running with a debugger shows various endpoints on backtraces but often during object deleting. Running fgfs with Auto Generated Scenery with 'top' in a separate terminal shows fgfs memory consumption steadily increasing until swapping starts. When the swapfile is approximately half full the kswap0d daemon bcomes the dominant cpu load and fgfs stops with a segfault . Departing westward from KGRR, Grand Rapids at...
-
The patch above could use a little help: the init function is still forcing the name of the instrument. Suggest adding this to the above patch: Thanks !
-
The patch above could use a little help: the init function is still forcing the name of the instrument. Suggest adding this to the above patch:
-
Can this fix be applied please ? I've patched it into local builds since submitting and verified on quite a number of Yasim models: EGT guage is inop without it and operates properly with the patch, it seems edvident reading the source code there's a mistake. Thanks !
-
Thank You for doing this.
-
These patches to fgdata/gui/dialogs/view.xml and fgdata/Nasal/markerpins.nas make Visual Reference Points, added as Type 1000, to fgdata/Navaids/poi.dat.gz selectable and visible as desired, Thanks ! Is there "any chance" poi.dat.gz can be added to the navaids that can be appended / overridden by including poi.dat in a custom scenery NavData/poi folder ? That would make sharing markers so much simpler, Extra Thanks !
-
These patches to fgdata/gui/dialogs/view.xml and fgdata/Nasal/markerpins.nas make Visual Reference Points, added as Type 1000, to fgdata/Navaids/poi.dat.gz selectable and visible as desired, Thanks ! Is there "any chance" poi.dat.gz can be added to the navaids that can be appended / overridden by including poi.dat in a custom scenery NavData/poi folder ? That would make sharing markers so much simpler, Extra Thanks !
-
These patches to fgdata/gui/dialogs/view.xml and fgdata/Nasal/markerpins.nas make Visual Reference Points, added as Type 1000, to fgdata/Navaids/poi.dat.gz selectable and visible as desired, Thanks ! Is there "any chance" poi.dat.gz can be added to the navaids that can be appended / overridden by including poi.dat in a custom scenery NavData/poi folder ? That would make sharing markers so much simpler, Extra Thanks !
-
Looking at this, the fg-americas scenery ( second in my custom overlay order ) properly has KBTL/threshold.xml showing 05L/23R but does not have the updated ( renamed ) runways for KABY so I'm guessing this error is thrown because fg-americas btg files don't have the new names; therefore not a flightgear problem. Thanks again.
-
KABY custom threshold.xml:
-
airport.cxx @673 : Error for renamed runway in custom threshold.xml
-
airport.cxx @673 : Error for renamed runway in custom threshold.xml
-
Since this topic has been picked up and resolved in the -devel list the ticket can be marked 'invalid' or 'won't fix'. It's just a pity the command option isn't named '--extra-fg-scenery' ! Thanks for looking at this.
-
at NavDataCache.cxx @1452 ff the coments say: // All $scenery_path/NavData/{nav,fix}/*.dat[.gz] files found inside scenery 1453 // paths, plus $FG_ROOT/Navaids/{nav,fix}.dat.gz (order matters). terrasync folder doesn't have a NavData subfolder but fgfs-americas does, terrasync data for the ILS is in its Airports folder. Does that cause the issue ?
-
I've also checked that erasing navdata_2020_4.cache before starting has no effect, the error persists.
-
Yes, As noted: Using command line scenery search order: ----fg-scenery=/fgScen/tsyn ( my terrasync folder ) at startup ,Ctrl-M. map in-cockpit shows the ILS guidelines and NAV1. 109.70 is active.
-
Possible error in navdb scenery search order
-
fbrun -text issues after Fedora upgrade to 39
-
@Gijs: Please don't close this out yet, I'm consistently getting a segfault now, on 2020-4, and I'm unable to change the drop-down from 'Low Detail' to 'Select Ranges' It may be a local issue, I'm injecting real ADSB data into a local mpserver so I'll run a debug build and try to get a better idea of what's happening.
-
Thank You for the patch, both Lancair-235 and NavionB with the new KAP140 start properly; the unit test for turn indicator new passes OK. Thanks again !
-
You lost me at 'tell the compiler to inherit from it' I've put a copy of flightgear, with the ubit test for turn-instrument/operable here
-
Sadly it it doesn't solve the issue, as far as I can see: In 2020-3 flightgear/src/Instrumentation/turn_indicator.hxx I replaced #include <simgear/props/props.hxx> #include <simgear/structure/subsystem_mgr.hxx> with #include <Instrumentation/AbstractInstrument.hxx> and rebuilt 2020-3 Still, the Lancair with resizner's KAP140 still fails after PFT 3, properties instrumentation/turn-indicator/operable is not set to anything, resulting in KAP140 failure. It seems, to me, an obvious fix is to have the...
-
Yes, restart fgfs so as to ensure High + Low detail are at slider LHS end at startup. I've just confirmed the segfault according to the instructions above ( /Rabges/Ranges !! ) It's a somewhat esoteric fault condition depending on mplayer and initial slider state, ticket was raised in response to a report on the forum; with all that's going on with menus, maybe 'won't fix' is the way to go. Thanks for looking at this.
-
Thanks, @Gijs, this forum thread links to the wiki, it is simply necessary to use <input> <keyboard> tags in the custom file to characterise it as a keyboard file, this ticket can be marked fixed / invalid Thanks ! </keyboard>
-
2020-3 build looks good with Fedora 39. Thank You !
-
When I first created these scenarios, quite a while ago, it was necessary to include the Lat/Lon in the 'End' waypoint or else the scenario failed. No big deal, it was a long time ago.
-
The build error for 2020.3 unit tests was due to some tests being missing in 2020.3. Corrected CmakeLists.txt and TestSuite.cxx attached:
-
The build error for 2020.3 unit tests was due to some tests being missing in 2020.3. Corrected CmakeLists.txt and testSuite.cxx attached:
-
I've run these models under both 'next' and '2020-3' : pa32, c150, pup150, pc6-b2h4 Under 2020-3 for all those models Instrumentation/turn-indicator/operable node is not created. Under 'next', for all those models the node is created, only pa32 sets the node operable to true, for the rest the node is false. I conclude the node isn't created for 2020-3, making the new KAP140 inoperative; for 2020-4 the node is created but likely needs a certain power setup for operable to indicate the KAP140 is u...
-
I made up a unit test, files below should be placed in flightgear/test_suite/unit_test/Instrumentation On 'next' the unit tests run OK, unfortunately for 2020-3 make test_suite fails with this output: /blds/fg/2020-3/tsts<=>make test_suite [ 11%] Built target CppUnitLib -- Found Git: /bin/git (found version "2.43.0") -- Git revision is b5e65d43be4beeaf9e15b95d1a05b29f51206104 [ 11%] Built target buildId [ 13%] Built target fgsqlite3 [ 33%] Built target iaxclient_lib [ 47%] Built target flite_hts...
-
Switching to 'next' : instrumentation/turn-indicator/operable is set and shoes bool true
-
/instrumentation/turn-indicator/operable is unset, i.e a blank field in the properties browser ( firefox) the 'serviceable' field is set to bool true.
-
Sorry, I'm still going around in circles, I have set in instrumentation.xml : ~~~ <turn-indicator> <name>turn-indicator</name> <number>0</number> <power-supply>/systems/electrical/outputs/turn-coordinator</power-supply> <minimum-supply-volts>24</minimum-supply-volts> </turn-indicator> ~~~turn-indicator And I can see, in the properties tree systems/electrical/outputs/turn-coordinator is 24.6xx volts But KAP140/sensors/turn-indicator-operable shows false so KAP140 doesn't start. I've no idea if, in...
-
OK, many thanks for that summary. I think it's true that, for the turn indicator in this model, an explicit power source is not configured; as it's written the model's KAP140 starts up for next, 2020.4 but not in 2020-3. Will setting an explicit path for the power source allow the one model to work for both builds ? Thanks !
-
I'll have to dig further but it's clear the KAP140 works OK using 2020.4 and fails to startup if solely the build is changed to 2020-3 using exactly the same model, e.g It's possible a change to AbstractInstrument between 2020-3 and 2020.4 is related: 40 if (_powerSupplyPath.empty()) { _powerSupplyPath = "/systems/electrical/outputs/" + defaultName + "[" + std::to_string(_index) + "]"; }
-
turn_indicator.cxx name change causes failure
-
This is still stopping a 2020-3 build here, was the information suffucient ?
-
It's detailed in the referenced forum post. [ 54%] Built target SimGearCore [ 54%] Building CXX object simgear/CMakeFiles/SimGearScene.dir/scene/viewer/Compositor.cxx.o In file included from /fgfs/simgear/simgear/scene/viewer/Compositor.cxx:17: /fgfs/simgear/simgear/scene/viewer/Compositor.hxx:137:34: error: field '_uniforms' has incomplete type 'simgear::compositor::Compositor::BuiltinUniforms' {aka 'std::array<osg::ref_ptr\<osg::uniform>, 14>'} 137 | BuiltinUniforms _uniforms; | ^~~~~~~~~ In file...
-
CMakeLists.txt Need to set c++ 17 Standard for gcc 13.2.1
-
CMakeLists.txt Need to set c++ 17 Standard for gcc 13.2.1
-
I've bounced this off the forum. It seems to me your Nasal API above covers all the needs, even VRP's could be handled this way without cluttering the Nav data files: for instance a group of reference points could just as easily be shared as a script rather than as a modified poi.dat. From the forum comments 'dynamic' would be useful, as in 'team leader' / 'pathfinder' marker and also as 'here be a thermal' for group gliding sessions. Thanks !
-
It certainly changes the effect if terrain quality is altered, it looks as if the marker lines are displayed doubled, with a moire effect, white lines traversing laterally as the plane moves.
-
Well, it's still an issue, I just verified on today's 'next' build. In View-Rendering-Advanced Graphics Options the yellow Runway-Entrance markers show if 'low Specifications button is active, if Atmospheroc Light Scattering is selected, the marker lines all but disappear, just a faint white hatching at runway edge:
-
Just that 'dynamic' doesn't work for me in this context; I understand it to mean 'in motion' , the opposite of marking a fixed position. Temporary ?
-
Any name is fine with me, 'user' occurred to me too. Points-Of-Interest has the advantage of a simpler format: just Lat, Lon and Text description. On the downside it looks as if POI data cannot be extended by the user adding a local file, the way datapoints for nav data can be over-ridden. Conceivably these flags could be used for more than navigation Visual reference Points e.g ad hoc assembly points during MP get-togethers, they are identified as official VRPs only by the text label. Would 'User-Added'...
-
Patches to add 'Custom' category to poi.dat and Marker Pins
-
Patches to add 'Custom' category to poi.dat and Marker Pins
-
Patches to add 'Custom' category to poi.dat and Marker Pins
-
Suggested patch to Nasal/gui.nas to support YASim CoG on MAC
-
Sorry, I didn't see any reference to FGPuiDialog in your traces. That's "Autogenerated Vegetation" drop-down, correct ? ( the only 'Random' I have is Random Scenery Objects.) This is the console log I see with Autogenerated Vegetation disabled: Error: caught signal 11: /lib64/libc.so.6 : ()+0x3ea00 fgfs() [0x743ec1] /lib64/libplibpu.so.1.8.5 : puGroup::checkHit(int, int, int, int)+0x10f /lib64/libplibpu.so.1.8.5 : puMouse(int, int, int, int)+0x98 fgfs() [0xdf5a2c] /usr/local/lib/libosgGA.so.161 :...
-
I've tried starting at LIPA and this segfault is not affected by Random Vegetaion Disabled. The full backtrace text, above , indicates a segfault in FGPuiDialog rather than in scenery handling, I think, Thanks !
-
For the segfault to happen F10-AI-Traaffics and Scenario Settings must have 'Enable AI Traffic' unchecked, as well as MP server disconnected so it's not unreasonable that adjusting the View-LOD menu's section: 'AI/MP Settings' should have unintended consequences, it looks as if rendering/static-lod settings are done in either MP or AIBase init functions. Would it be possible to grey-out this menu section if neither MP nor AI Traffic is enabled ? If it's worth it, of course !
-
Also, I set a breakpoint at FGPUDialog,cxx 334 and, immediately before clicking on 'High Detail' slider ( which causes the segfault ) I started MP Server Connection. Then, on clicking the slider , there is no segfault and inspecting local variables shows the parentDialog._name is "static-lod" and _font is puFont.
-
Attached, a screengrab of the local variables for usr/src/debug/plib-1.8.5-30.fc36.x86_64/src/pui/puGroup.cxx puGroup::checkHit , (I used dnf debuginfo-install plib ) It looks as if parentDialog font and name are invalid: at flightgear/src/GUI/FGPUDialog.cxx 334 is: propCurrentDialog->setStringValue(parentDialog->getName());
-
Segfault in PUI Menu View-Adjust LOD
-
Attached, a screengrab of the local variables for usr/src/debug/plib-1.8.5-30.fc36.x86_64/src/pui/puGroup.cxx puGroup::checkHit , (I used dnf debuginfo-install plib ) It looks as if parentDialog font and name are invalid: at flightgear/src/GUI/FGPUDialog.cxx 334 is: propCurrentDialog->setStringValue(parentDialog->getName());
-
Segfault in PUI Menu View-Adjust LOD
-
Segfault in PUI Menu View-Adjust LOD
-
I was mistaken, sorry. The segfault seen, at FGOUIDialog.cxx 334, is not affected by the above patch which relates to Canvas. If I can get any better info about the original error I will open another ticket, Thanks.
-
You're right, it's more complicated than I originally thought and there are many threads referenced. Here's the 'patch' as described : go to $SG_SRC/canvas/elements/CanvasPath.cxx navigate to/search the line containing static const VGubyte shCoordsPerCommand[] prepend/insert a new line before that onecontaining: static OpenThreads::Mutex _mutex; next, navigate to the line containing osg::State* state = renderInfo.getState(); prepend/insert a new line containing OpenThreads::ScopedLock<OpenThreads::Mutex>...
-
Segfault when MP LOD adjusted with MP server disconnected
-
Segfault when MP LOD adjusted with MP server disconnected
-
Added *include <functional>" in Scripting/NasalCondition.hxx fixed the build. Tested set, setb, setd, setf, seti with good and bad arguments, telnet, all looks good, Thanks ! </functional>
1 >
