Activity for eatdirt
-
eatdirt created merge request #67 on Code
Saving the flag needed for displaying either GMT or MET on PFD
-
Clamp argument to prevent nasal error at TAEM when errors are large
-
Fix some corrupted coordinates and deprecation in PFD.svg
-
Thanks Kaz. I've tried to actually fill a ticket on Forge.a-lec, but new users are actually banned. I've seen the warnings about disabling all new accounts by default. Hence, I decided to fill the ticket here... Thanks to forward it!
-
Control configuration is broken with joysticks and mouse plugged
-
SRB flames and smoke for multiplayer sessions
-
Let me reject this merge request, I have changed my mind and I am currently coding an addon with just that exact view. It won't do much better than the Fly-By held, but I'll add menubox to set the height of the pilot, distance to plane, etc... Much more flexible at the end. I might also avoid collision with plane's view using addon hints, let's see. Of course, much more coding time than the checkbox indeed!
-
For the record it is now there: https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Addons/RCView/ Certainly needs some tuning on view-number collision and position within the view menu. Cheers, chris.
-
Adding RCView addon (remote control view)
-
Add a display option allowing to hold the viewer position in Fly-By view
-
Let me reject this merge request, I have changed my mind and I am currently coding an addon with just that exact view. It won't do much better than the Fly-By held, but I'll add menubox to set the height of the pilot, distance to plane, etc... Much more flexible at the end. I might also avoid collision with plane's view using addon hints, let's see. Of course, much more coding time that the checkbox indeed!
-
Fixing ground sinking with structual points and tuned bogeys coeffients
-
I have been thinking, may a fg-addon be only a new view? Would it make sense? How to be sure it won't collide with planes' views? It could be loaded for all planes, rc or not rc I could start from the fly-by view and built on it, allowing rotation around the plane instead of random pick-up etc...
-
All right, I've coded it within the Rascal. I've converted it into a function that must be called after the fdm is initialized (otherwise the geo.* are not yet set). setprop("/sim/tower/auto-position", 0); var set_rcview = func (OFFSET_DEG,DISTANCE_M,HEIGHT_M) { var pos = geo.aircraft_position(); var heading = getprop("/orientation/heading-deg") + OFFSET_DEG; pos.apply_course_distance(heading, DISTANCE_M); pos.set_alt(pos.alt() + HEIGHT_M); setprop("/sim/tower/airport-id", "RC View"); setprop("/sim/tower/altitude-ft",...
-
Thanks for the code, I'll give it a try with the rascal and let you know what I feel. But, I can anticipate already some limitations such as not allowing remote controlling real planes (which is quite cool too) nor starting again the view nearby the plane when you land too far! A better solution plane-side could be to copy-paste the fly-by view with held position as an RC view for RC planes, but that would not address RCing real planes. Now copy-pasting the same code for all RC planes and all real...
-
Thanks for the code, I'll give it a try with the rascal and let you know what I feel. But, I can anticipate already some limitations such as not allowing remote controlling real planes (which is quite cool too) nor starting again the view nearby the plane when you land too far! (as it happened in the videos actually). A better solution plane-side could be to copy-paste the fly-by view with held position as an RC view for RC planes, but that would not address RCing real planes. Now copy-pasting the...
-
Here we go, a fly test with the Tower View. Look how the fov is wrong (compared to what a RC pilot would actually see), the auto-zoom is not adequate neither, it makes the view too easy and you can never loose sight of the plane (which may happen in real RC). Also, it is almost impossible to guess distances and parallax. I am even missing the runway while trying to land. tower_view_vp9_1080p.webm Now, with the Fly-by view, plus the hold switch on. I am first switching view from fly-by to fly-by to...
-
Here we go, a fly test with the Tower View. Look how the fov is wrong (compared to what a RC pilot would actually see), the auto-zoom is not adequate neither, it makes the view too easy and you can never loss sight of the plane (which may happen in real RC). Also, it is almost impossible to guess distances and parallax. I am even missing the runway while trying to land. tower_view_vp9_1080p.webm Now, with the Fly-by view, plus the hold switch on. I am first switching view from fly-by to fly-by to...
-
Here we go, a fly test with the Tower View. Look how the fov is wrong (compared to what a RC pilot would actually see), the auto-zoom is not adequate neither, and it is impossible to guess distances and parallax. I am even missing the runway while trying to land. tower_view_vp9_1080p.webm Now, with the Fly-by view, plus the hold switch on. I am first switching view from fly-by to fly-by to find a position that suits to me, and then fly and land. This is quite realistic and nothing more is needed...
-
Hi Stuart, I've spent quite some times testing many things and I disagree. I'll add a video to show why this works, and why the Tower view does not. None of the tower views provide suitable RC views. They're too far, too high and never close to the RC plane. Notice that it is not a new view, just a switch holding the fly-by position, so I don't see any issue in that. Plus, one fantastic, and wanted side-effect, is that if the switch is on (viewer hold still), switching the view from fly-by to fly-by,...
-
Hi Stuart, I've spent quite some times testing many things and I disagree. I'll add a video to show why this works, and why the Tower view does not. None of the tower views provide suitable RC views. They're too far, too high and never close to the RC plane. Notice that it is not a new view, just a switch holding the fly-by position, so I don't see any issue in that. Plus, one fantastic, and wanted side-effect, is that if the switch is on (viewer hold still), switching the view from fly-by to fly-by,...
-
Add a display option allowing to hold the viewer position in Fly-By view
-
Rename gui into p51gui to fix namespace conflicts
-
A video showing it. Checking environment variables, it looks like this the wind direction which is discontinuous, it happens 2 times, at altitude 70kft and 50 kft (again the kick could be at tiles transition, i don't know). windkick-SpaceShuttle-TAEM-20230122-233929.webm Edit: My two comments may not be related to this ticket about wind direction, but that could have interfered: https://sourceforge.net/p/flightgear/fgdata/merge-requests/308/
-
Revert commit auto-enabling wind interpolator in case of invalid METAR
-
A video showing it. Checking environment variables, it looks like this the wind direction which is discontinuous, it happens 2 times, at altitude 70kft and 50 kft (again the kick could be at tiles transition, i don't know). windkick-SpaceShuttle-TAEM-20230122-233929.webm
-
A video showing it. Checking environment variables, it looks like the direction is discontinuous, it happens 2 times, at altitude 70kft and 50 kft (again the kick could be at tiles transition, i don't know). windkick-SpaceShuttle-TAEM-20230122-233929.webm
-
A video showing it. Checking environment variables, it looks like the direction is discontinuous, it happens 2 times, at altitude 70kft and 55 kft (again the kick could be at tiles transition, i don't know). windkick-SpaceShuttle-TAEM-20230122-233929.webm
-
A video showing it. Checking environment variables, it looks like the direction is discontinuous, it happens 2 times, at altitude 70kft and 55 kft (again the kick could be at tiles transition, i don't know). https://curl.irmp.ucl.ac.be/~chris/upload/fg/tmp/windkick-SpaceShuttle-TAEM-20230122-233929.webm
-
Hi there, I am landing here from https://forum.flightgear.org/viewtopic.php?f=69&t=40711&start=30#p404760. On 2020.4 (and not on 2020.3), when we have live weather enable, all the rest being the default (wind constant), arriving from space we get a huge wind kick at high altitude (80000ft or so). That triggers a lot of problems, the dynamical pressure being low, the Space Shuttle suffers from undamped strong oscillations that challenge the flight. Something changed in the way the winds are dealt...
-
In case this is linked: https://sourceforge.net/p/flightgear/codetickets/2537/ I'll investigate!
-
My contribution :) On Linux, when you are closing FG in full-screen mode, the next session does not start in full screen mode but in a windowed mode having the size of the full screen. On the other hand, stopping flightgear in windowed mode, the next session starts fine, in windowed mode with the same previous resolution. So, yep, we have problems when stopping/starting flightgear in full screen :)
-
Hi there, I am landing here from https://forum.flightgear.org/viewtopic.php?f=69&t=40711&start=30#p404760. On 2020.4 (and not on 2018.4), when we have live weather enable, all the rest being the default (wind constant), arriving from space we get a huge wind kick at high altitude (80000ft or so). That triggers a lot of problems, the dynamical pressure being low, the Space Shuttle suffers from undamped strong oscillations that challenge the flight. Something changed in the way the winds are dealt...
-
Hi there, I am landing here from https://forum.flightgear.org/viewtopic.php?f=69&t=40711&start=30#p404760. On 2020.4 (and not on 2018.4), when we have live weather enable, all the rest being the default (wind constant), arriving from space we get a huge wind kick at high altitude (80000ft or so). That triggers a lot of problems, the dynamical pressure being low, the Space Shuttle suffers from undamped strong oscillations that challenge the flight. Something change in the way the winds are dealt in...
-
Hi there, I am landing here from https://forum.flightgear.org/viewtopic.php?f=69&t=40711&start=30#p404760. On 2020.4 (and not on 2018.4), when we have live weather enable, all the rest being the default (wind constant), arriving from space we get a huge wind kick at high altitude (80000ft or so). That triggers a lot of problem, the dynamical pressure being low, the Space Shuttle suffers from strong oscillations that challenge the flight. Something change in the way the winds are dealt in 2020.4,...
-
Fix handovers between the rel_orbital and payload_manager's provider of proximity coordinates
-
I did not really fix the race conditions by moving computing_proximity() before as both calculations are done in different loops. We need a lock to deactivate one while the other works. Let me fix that in a proper way.
-
Fix racing between the two proximity calculators within the proximity zone
-
Fix racing between the two proximity calculators within the proximity zone
-
Well found! I remember some loading of a binary file in the code, maybe it misses data (timezone16.bin), but that would require some work to check all this (FGDATA/Timezone has some info though).
-
Fix multiple entering of targets within the proximity zone
-
Here we go, maybe the Shuttle being fast it just has a highest probability to explore a region where the timezone has a bug? It is really only this, no error after passing this zone, no error before! 190.00 [ALRT]:environment SGTime::updateLocal: Timezone not found for location: lon = -69.3416deg, lat = 12.325deg, elev = 532016m 190.18 [ALRT]:environment SGTime::updateLocal: Timezone not found for location: lon = -69.3269deg, lat = 12.3174deg, elev = 532015m 190.46 [ALRT]:environment SGTime::updateLocal:...
-
I've checked a hard bailout: if (nearestTz) { description = nearestTz->getDescription(); } else { std::cout << " location " << location << " alocaltion " << aLocation; return; } and that is very rarely happening. So, if you want to skip the whole updatelocal above a certain altitude, UTC would be the choice (notice however that all the other functions like sidereal time etc.. are required for space flight). But if the idea is to bailout only when that pointer is null, I would let the local time,...
-
You're right, as usual :) I am having it under gdb, and location and alocation are perfectly fine indeed. And indeed, nearestTz is null as equalized to that guy: print static_tzContainer->getNearest(location) $5 = (SGTimeZone *) 0x0 It's interesting, there is a conditional in the SGTime::init() before trying to getDescription(), but not in updateLocal().
-
You're right, as usual :) I am having it under gdb, and location and alocation are perfectly fine indeed. And indeed, nearestTz is null as equalized to that guy: print static_tzContainer->getNearest(location) $5 = (SGTimeZone *) 0x0
-
In math/SGGeod.hxx, a comment says that a new SGGeod() object is by default created to be invalid for historical reasons. So these lines suggest that when aLocation is invalid there is a pb, but if the problem is to be invalid, having a new object "location" is not going to help! Edit: That seems to be fine, the constructor set invalid to true but reset lon/lat/evel to 0. However, isValid is not checking NaN on elevation, that might be the culprit. I am having this bug in Space, so may be elevation...
-
SGGeod location(aLocation); if (!aLocation.isValid()) { location = SGGeod(); } SGTimeZone* nearestTz = static_tzContainer->getNearest(location);
-
SGGeod location(aLocation); if (!aLocation.isValid()) { location = SGGeod(); } SGTimeZone* nearestTz = static_tzContainer->getNearest(location); huu? In math/SGGeod.hxx, a comment says that a new SGGeod() object is by default created to be invalid for historical reasons. So these lines suggest that when aLocation is invalid there is a pb, but if the problem is to be invalid, having a new object "location" is not going to help! Edit: That seems to be fine, the constructor set invalid to true but reset...
-
SGGeod location(aLocation); if (!aLocation.isValid()) { location = SGGeod(); } SGTimeZone* nearestTz = static_tzContainer->getNearest(location); huu? In math/SGGeod.hxx, a comment says that a new SGGeod() object is by default created to be invalid for historical reasons. So these lines suggest that when aLocation is invalid there is a pb, but if the problem is to be invalid, having a new object "location" is not going to help! I am having this bug in Space, so may be that's the trigger for having...
-
SGGeod location(aLocation); if (!aLocation.isValid()) { location = SGGeod(); } SGTimeZone* nearestTz = static_tzContainer->getNearest(location); huu? In math/SGGeod.hxx, a comment says that a new SGGeod() object is by default created to be invalid for historical reasons. So these lines suggest that when aLocation is invalid there is a pb, but if the problem is to be invalid, having a new object "location" is not going to help! I am having this bug in Space, so may be that's the trigger for having...
-
Mmmm, if SGGeod is returning junk, that could trigger the pb. Might be related to? https://sourceforge.net/p/flightgear/codetickets/2764/
-
Another run (2020.4.0, forgot to say), the same segfault with slightly more info: Thread 1 "fgfs" received signal SIGSEGV, Segmentation fault. SGTime::updateLocal (this=this@entry=0x4c93b70, aLocation=..., root=...) at /usr/src/debug/simgear-2020.4.0-17.mga8.x86_64/simgear/timing/sg_time.cxx:241 241 description = nearestTz->getDescription(); (gdb) bt #0 SGTime::updateLocal (this=this@entry=0x4c93b70, aLocation=..., root=...) at /usr/src/debug/simgear-2020.4.0-17.mga8.x86_64/simgear/timing/sg_time.cxx:241...
-
segfault in updateLocal
-
Remove an always unsatisfied predicate to a now unset property
-
Spare effect files including shadows' shaders for next
-
Fix default shaders/model value to match gui default setting
-
Check this out too: https://sourceforge.net/p/flightgear/codetickets/2767/ When you're reposition on the carrier, another scenario is created as well. I had the same understanding at first, removed the eisenhower entry from the nimitz_demo, but still have a multiplication of scenarios using the Aircraft repositioning launcher.
-
Yes, sure, sorry to not have squashed them myself, just figured out that the pb was also on other carriers after fixing the first!
-
AI carriers issues when loaded from menu and repositionning
-
Fix various nasal errors in AI carriers
-
I am into carriers these days, coming back to the original issue of that ticket, I don't know how I did not check this out first,: This is happening when the carrier crosses heading=360 degrees while changing course :) PS: I'll dig into that.
-
Yes, 25kts is reasonable, but I've found the gust direction slider to be set at 180 degrees. If I touch it, the maximal scale goes back to 45. I should have a look at the code to see what 180 degrees gust implies.
-
concerning my PS: It seems that the gust setting are sometime very strong, and I see in the docs that they can be automatically set by METAR. If we have a pb with METAR parsing, maybe crazy values land in the gusts setting and that might explain the "shocks"
-
SEGFAULT with live weather
-
Hi there, "internal compiler error" would suggest the compiler is faulty, and a compiler upgrade could fix it. But from past experience, it could also be memory related, you could try a make -j1 to force using only one thread to minimize memory usage. It might also be some hardware memory issue, compiling is doing a good job in stressing memory :) Good luck!
-
SIGSEGV in SGGeod from FGAIAircraft
-
Might be, but I don't reproduce this issue. When the 3 joysticks are plugged, I can configure one, but only one. I've rebuilt with the patch mentioned in that ticket, no change!
-
multiple joysticks under linux
-
I do see some nasty things in the logs: <attstr name="message0" val="FAILED to login in as eatspeed Wrong username or password"/> It looks like the keyboard input some junks when I type,, see some "$#10" around "eatspeed"!
-
newcomer master server registering broken?
-
I have a similar pb, hangs at the end of each race when pressing on "continue". Also disappears if I disable music. OpenAL is 1.21, speed-dreams 2.2.3. Let me know if this deserves a new ticket. cheers.
-
Note that latching seems to go wrong if one pauses flightgear or replays then resumes. All right , I did no have the "always latch" option activated, but, you're right, I did a resume after a replay (trigger the replay by accident). I also did a resume of a session in which I crashed in the water by just repositioning the aircraft onto the carrier It happens that I've found the logs of that session, and that is indeed nasty: 1389.31 [INFO]:nasal Initializing F-14 Systems 1389.69 [INFO]:nasal Initializing...
-
All right, woo! That works quite fine actually!! Well done! I've noticed only minor things, happy to help fixing if I can: - the MP radar display is no really clickable anymore, to set course recovery for instance. Still doable from the AI menu though. - Something weird, my radar (on board F-14b) was still showing Vinson at 1.9 nm away, always. I mean, I tried to see what was there, but that virtual Vinson was moving with me, ahead of me. - A slightly less minor issue, I did not manage to get the...
-
Damned... Copy paste of the old command line, you certainly right, I was calling the old carrier MP from my local folder... What a fool... fgfs --fg-aircraft=/home/chris/.Aircraft:/home/chris/.fgfs/Aircraft/org.flightgear.fgaddon.stable_2020/Aircraft --ai-scenario=vinson_demo --aircraft=vinson --callsign=SEADIRT --multiplay=in,30,,5010 --multiplay=out,30,mpserver01.flightgear.org,5000 Tonight, I am redoing a full range of tests with proper arguments!
-
Damned... Copy paste of the old command line, you certainly right, I was calling the old carrier MP from my local folder... What a fool... fgfs --fg-aircraft=/home/chris/.Aircraft:/home/chris/.fgfs/Aircraft/org.flightgear.fgaddon.stable_2020/Aircraft --ai-scenario=vinson_demo --aircraft=vinson --callsign=SEADIRT --multiplay=in,30,,5010 --multiplay=out,30,mpserver01.flightgear.org,5000 Tonight, I am redoing a full range of test with proper arguments!
-
Hi there, I have been off from carrier landing since a while. But I went watching top gun 2 at the cinema, then I could not resist to do some carrier landings again :) All that to say that I gave a try on 2020.4.0 to set an MP-carrier, in vain. The infamous blue plane is there, but the model never gets loaded. I've tried all combination of the new options in the menu (latch, automatically enable AI etc...), toyed the LOD, tried High definition only, no joy :) The MP session runs fine, I do see the...
-
Hi there, I have been off from carrier landing since a while. But I went watching top gun 2 at the cinema, then I could not resist to do some carrier landings again :) All that to say that I gave a try on 2020.4.0 to set an MP-carrier, in vain. The infamous blue plane is there, but the model never gets loaded. I've tried all combination of the new options in the menu (latch, automatically enable AI etc...), toyed the LOD, tried High definition only, no joy :) The MP session runs fine, I do see the...
-
Hi there, I have been off from carrier landing since a while. But I went watching top gun 2 at the cinema, then I could not resist to do some carrier landings again :) All that to say that I gave a try on 2020.4.0 to set an MP-carrier, in vain. The infamous blue plane is there, but the model never gets loaded. I've tried all combination of the new options in the menu (latch, automatically enable AI etc...), toyed the LOD, tried High definition only, no joy :) The MP session runs fine, I do see the...
-
Yea, bug is closed. Thanks for the fixes!
-
Hello there, I've played with the new options. Concerning /sim/thread-cpu-affinity set to 'none' or 'osg' does the same for me, it has, as before, one thread locked onto core 2 (see previous posts). However, resetting the affinity in sim with /sim/affinity-control=clear works, this affinity to core 2 disappears. Setting "revert" also works, affinity to core 2 comes back. Starting with default OSG affinity settings in which all threads are on core 1 & 2, this affinity-control prop works as expected....
-
Seems to be an old story, long to read, but that's exactly what we are facing. https://osg-users.openscenegraph.narkive.com/685ht2bm/singlethreaded-leading-to-whole-application-just-running-on-one-core
-
Seems to be an old story: https://osg-users.openscenegraph.narkive.com/685ht2bm/singlethreaded-leading-to-whole-application-just-running-on-one-core
-
Ok, that definitely unlocked things. I'll start with the sure thing: This guy unset: --prop:/sim/rendering/multithreading-mode with this: --prop:bool:/sim/thread-cpu-affinity=false for the UFO. Not encoding: 881150 chris 20 0 6428048 5.0g 132140 R 98.3 10.7 1:45.99 fgfs 881278 chris 20 0 6428048 5.0g 132140 S 0.7 10.7 0:00.62 fgfs 881153 chris 20 0 6428048 5.0g 132140 S 0.0 10.7 0:00.01 QXcbEventQueue 881269 chris 20 0 6428048 5.0g 132140 S 0.0 10.7 0:00.00 fgfs 881272 chris 20 0 6428048 5.0g 132140...
-
Just wanted to add that I suspect it is dramatic for me alone due to the resolution. For instance, even with 1 thread, when I resized the window to 800x600, the fps goes down but remain usable, like 20 fps. But full screen, that is a down to 4-5. Since the bandwitdh required scales as the square of the resolution, that goes down fast with high res!
-
Ok, here we go without running the video encoding: pid 669079's current affinity mask: 1 pid 669082's current affinity mask: ffffff pid 669094's current affinity mask: 1 pid 669095's current affinity mask: 1 pid 669096's current affinity mask: 1 pid 669097's current affinity mask: 1 pid 669098's current affinity mask: 2 pid 669100's current affinity mask: 1 pid 669101's current affinity mask: 1 pid 669102's current affinity mask: 1 pid 669103's current affinity mask: 1 pid 669113's current affinity...
-
All right, thanks for the feedback, I did the test and property locking is not the cause, the fps drops is about the same when I switch on video recording (or when that nasal space shuttle (STS) thread runs). I have not been able to test the nightly appimage, it segfaults when I start it, in dbus. That's most probably some incompatible dbus library versionning between the nightly build and my system, so nothing fancy there. Looking for ressources, I've tried the FG system monitor, but that looks...
-
I've noticed something weird with 2020.4.0, that could be related. One of the nasal module for the SpaceShuttle uses an extra-thread to do some calculations. With 2020.4.0, I have a huge fps drop when this thread is running. The problem may not be in ffmpeg but the way these threads are implemented? Did something change in our threading implementation, like some extra locking?
-
I've just built and tested recordmydesktop, I did not know this one. It takes at most 1% of CPU during the recording, then 100% after pressing CTRL+C when dumping the ogv file. For ffmpeg, I've never tested calling the libs, but I'am using regularly the ffmpeg binary for encoding 4K images into 4K lossless films (x264). All the 24 cores are full steam when doing so. I can also have a look to the simgear code, maybe that would give me some clue on what could be wrong with my ffmpeg install, if any....
-
I've just build and tested recordmydesktop, I did not know this one. It takes at most 1% of CPU during the recording, then 100% after pressing CTRL+C when dumping the ogv file. For ffmpeg, I've never tested calling the libs, but I'am using regularly the ffmpeg binary for encoding 4K images into 4K lossless films (x264). All the 24 cores are full steam when doing so. I can also have a look to the simgear code, maybe that would give me some clue on what could be wrong with my ffmpeg install, if any....
-
But i'm a little suspicious of your setup here It is built with hardened compilation options, namely not higher than -O2 and sse2, threads enable, to be distributed under Mageia linux. So, it indeed may differ from the nightly build, but it is certainly closer to what distros will be distributing. If you have a suspicion of a bug related to built options, I can provide full details of the cmake command use to do the build (simgear and/or flightgear)? Another thing I've noted is that the default CRF...
-
But i'm a little suspicious of your setup here It is built with hardened compilation options, namely not higher than -O2 and sse2, to be distributed under Mageia linux. So, it indeed may differ from the nightly build, but it certainly is closer to what distro will be distributing. If you have a suspicion of a bug related to built options, I can provide full details of the cmake command use to do the build (simgear and/or flightgear)?
-
Video encoding FPS problems
-
ffmpeg-5 and its API breaks
-
Here we go, a new ffmpeg-5 is around and various missing symbols pop up while trying to build wxsvg-1.5.13. Just a head-up if some devs could have a look at it! thanks, cheers, chris.
-
Implement CCTV overlay for the SRMS view with canvas
-
Minor ALS filters fixes
-
Add a CCTV-like overlay to the set of ALS filters
-
This one won't make it as per decided on the mailing list, too bad :-/
-
Add a CCTV-like overlay to the set of ALS filters
-
Fantastic, thanks !! I'll resume works on a new ALS filter for CCTV and will update then the fgdata/Thanks file with due credits to Gaia for the usage of their data!
1 >
