Menu
▾
▴
flightgear-devel
|
From: <m.h...@gm...> - 2016-09-20 21:24:00
|
I have a git version of Februar 2016 where it is still working, but with current FG: Error message: savexml: writing to 'Path "/SDB2/dot-fgfs/runtime-jetways/19.xml"' denied (unauthorized directory - authorization no longer follows symlinks) I fixed it like this: I changed jetways.nas Line 442: var runtime_file_path = home ~ "/Export/" ~ runtime_file ~ ".xml"; because FG is allowed to write to the Export dir. 2nd issue: Incomplete pick animation in Models/Airport/Jetway/glass.xml here is a fixed version: http://media.lug-marl.de/flightgear/jetways/glass.xml 1st issue can be fixed in FGDATA 2nd issue: in terrasync's Models folder |
|
From: James T. <zak...@ma...> - 2016-09-21 08:24:37
|
> On 20 Sep 2016, at 22:24, m.h...@gm... wrote: > > I have a git version of Februar 2016 where it is still working, but > with current FG: > > Error message: > savexml: writing to 'Path "/SDB2/dot-fgfs/runtime-jetways/19.xml"' > denied (unauthorized directory - authorization no longer follows symlinks) > > I fixed it like this: > I changed jetways.nas > Line 442: > > var runtime_file_path = home ~ "/Export/" ~ runtime_file ~ ".xml"; > > because FG is allowed to write to the Export dir. > > > 2nd issue: > > Incomplete pick animation in Models/Airport/Jetway/glass.xml > here is a fixed version: > http://media.lug-marl.de/flightgear/jetways/glass.xml > > 1st issue can be fixed in FGDATA > 2nd issue: in terrasync's Models folder Thanks Martin, I’ll try to apply these tomorrow, remind me next week if I forget. Kind regards, James |
|
From: James T. <zak...@ma...> - 2016-09-26 09:31:46
|
> On 21 Sep 2016, at 09:24, James Turner <zak...@ma...> wrote: > > Thanks Martin, I’ll try to apply these tomorrow, remind me next week if I forget. I didn’t find the time over the weekend, and travelling for work this week. Please do remind me during the week, if I forget again. Kind regards, James |
|
From: James T. <zak...@ma...> - 2016-09-29 03:18:18
|
> On 20 Sep 2016, at 16:24, m.h...@gm... wrote: > > 2nd issue: > > Incomplete pick animation in Models/Airport/Jetway/glass.xml > here is a fixed version: > http://media.lug-marl.de/flightgear/jetways/glass.xml This part is merged to fgdata now: 36528e2f84b5fbba79e86e77c0b89aec748a4bf4 Torsten, what is needed to update the terrasync copy? For the first fix, I read the Nasal file and I’m not sure ‘exports’ is the correct place. But I also don’t really know the code well, so I would prefer either some explanation of what is truly needed - can we just disable the writing to disk completely? Kind regards, James |
|
From: Ryan A Y. <ra...@ut...> - 2016-09-29 14:25:38
|
Hi James, On Wed, Sep 28, 2016 at 10:18 PM, James Turner <zak...@ma...> > For the first fix, I read the Nasal file and I’m not sure ‘exports’ is the correct place. But I also don’t really know the code well, so I would prefer either some explanation of what is truly needed - can we just disable the writing to disk completely? As I'm the one responsible for this mess, I'll explain. The code works by writing a new XML model, with unique property paths, for each jetway. That's how it's able to maintain a separate identity for each one it spawns. A horrible kludge, but it was the only way I could see to do this from Nasal. Still working on that C++ rewrite, but I've been starved for time lately due to school picking back up. |
|
From: Torsten D. <to...@t3...> - 2016-09-29 14:31:48
|
> > > Torsten, what is needed to update the terrasync copy? > - Find the model in http://scenery.flightgear.org/ - Download the model - Extract tarball into a folder - replace old xml file by new one - Download thumbnail image into the folder - Click "update model" - upload all files - Click "upload" Your friendly scenery admin just did that for you :-) Regards Torsten |
|
From: <m.h...@gm...> - 2016-11-14 17:44:19
|
Am 29.09.2016 um 05:18 schrieb James Turner: > For the first fix, I read the Nasal file and I’m not sure ‘exports’ is the correct place. > But I also don’t really know the code well, so I would prefer either some explanation of what is truly needed - any folder where the nasal script is allowed to write to. > can we just disable the writing to disk completely? no. This is an easy to fix bug and it would be sad, if it stays unfixed in the upcoming release. Kind regards, Martin |
|
From: James T. <zak...@ma...> - 2016-11-14 18:54:36
|
> On 14 Nov 2016, at 18:44, m.h...@gm... wrote: > > Am 29.09.2016 um 05:18 schrieb James Turner: >> For the first fix, I read the Nasal file and I’m not sure ‘exports’ is the correct place. >> But I also don’t really know the code well, so I would prefer either some explanation of what is truly needed - > > any folder where the nasal script is allowed to write to. > >> can we just disable the writing to disk completely? > > no. > > This is an easy to fix bug and it would be sad, if it stays unfixed in > the upcoming release. > Hmm, this is not really good. There is no reason for something like jetways to modify anything on this disk. It would be much better to understand the fundamental issue and re-design the system to avoid needing disk-acess, then to simply hack the current code to write to a different location. If I’m misunderstanding and there really is some intrinsic reason why animating a jetway needs to modify files, I would like a clear description of why. If having them broken in the next release motivates someone to step up and properly fix the system to avoid the disk output entirely, I’d consider that a net win, especially compared to patching the current setup and this bad behaviour remaining until the next time we change Nasal IO setup. Kind regards, James |
|
From: <m.h...@gm...> - 2016-11-14 20:04:34
|
In the past, jetways.nas was writing his own files into his own folder: .fgfs/runtime-jetways/ that's all. we curently have ICAO.jetways.xml files for 260 airports. When a pilot reaches e.g. EDDF then jetways.nas reads EDDF.jetways.xml and creates one individual "animated model" xml file for each jetway entry in that EDDF.jetways.xml file. So, if we want to avoid the writing to disk then we have to find a way to create scenery models with animations and individual properties like /models/model[120]/jetway-position/hood-deg with Nasal in RAM. Is that possible ? |
|
From: James T. <zak...@ma...> - 2016-11-14 20:30:33
|
> On 14 Nov 2016, at 21:04, m.h...@gm... wrote: > > When a pilot reaches e.g. EDDF then jetways.nas reads EDDF.jetways.xml > and creates one individual "animated model" xml file for each jetway > entry in that EDDF.jetways.xml file. > > So, if we want to avoid the writing to disk then we have to find a way > to create scenery models with animations and individual properties like > > /models/model[120]/jetway-position/hood-deg > Is that possible ? Yes of course, using the AI system. It needs to make jetway a new AI object type which is no problem - actually they can be managed by the airport dynamics, which already tracks parking position occupancy. There’s zero need for anything to hit the disk in this process, or duplicate any XML files - but it needs some C++ coding, it can’t be done entirely from Nasal. So, we need a volunteer to port the jetways logic to some C++ to create the instances (the per-jetway logic can stay in Nasal as needed). I’m happy to coach / assist. Kind regards, James |
|
From: <wki...@gm...> - 2017-01-03 20:23:05
Attachments:
jetways.nas.patch
|
On 11/14/2016 03:27 PM, James Turner wrote:
> There’s zero need for anything to hit the disk in this process, or duplicate
> any XML files - but it needs some C++ coding, it can’t be done entirely from
> Nasal.
in the mean time, can we please get the attached patch applied so that the
animated jetways can be returned to working order until this porting work is
complete? if so, please apply it to fgdata/Nasal/jetways/jetways.nas :)
thanks!
--
NOTE: No off-list assistance is given without prior approval.
*Please keep mailing list traffic on the list* unless
private contact is specifically requested and granted.
|
|
From: <wki...@gm...> - 2017-01-03 21:48:11
Attachments:
jetways.nas.patch
|
On 01/03/2017 03:24 PM, wki...@gm... wrote:
> in the mean time, can we please get the attached patch applied so that the
> animated jetways can be returned to working order until this porting work is
> complete? if so, please apply it to fgdata/Nasal/jetways/jetways.nas :)
oops! i think maybe this is the proper patch attached... looks like two places
that need to be modified for the new path... one for the jetways defined in the
airports (eg: K/S/F/KSFO.jetways.xml) and the other for the models (which i
don't have an example of at the moment)...
plus my testing had problems that all .nas files were being loaded from the
directory and conflicting with each other... at least now i have the jetways
being drawn and animated again...
--
NOTE: No off-list assistance is given without prior approval.
*Please keep mailing list traffic on the list* unless
private contact is specifically requested and granted.
|
|
From: James T. <zak...@ma...> - 2017-01-05 15:09:58
|
> On 3 Jan 2017, at 20:24, wki...@gm... wrote: > > in the mean time, can we please get the attached patch applied so that the animated jetways can be returned to working order until this porting work is complete? if so, please apply it to fgdata/Nasal/jetways/jetways.nas :) Honestly my personal answer is no, but I’m okay with being overruled. My opinion is that the way this ‘worked’ before was at best a hack, and at worst something approach an abuse of the simulator / user’s file system. I get that end-users want this feature and the Nasal implementation is a great proof-of-concept but we should not have shipped it as a core feature in the previous state. I would rather we live without it until someone is willing to fix it properly. Jetways are a classic case of a repeated, animated model that occurs in large numbers close to the aircraft (baggage containers could be another) where poor handling could really impact frameworks at large airports. Someone needs to step up and get their hands dirty with the code, of course with some help / guidance but I really think that’s better for the long-term health of the simulator than the old solution. Again, I don’t mind being overruled, but I also don't believe there is no one out there willing to try giving a better solution a go. If we restore past hacks we will never find out. Kind regards, James |
|
From: James T. <zak...@ma...> - 2017-01-05 15:37:56
|
> On 5 Jan 2017, at 15:09, James Turner <zak...@ma...> wrote: > > frameworks ‘framerates’, oops. |
|
From: Torsten D. <to...@t3...> - 2017-01-05 17:31:16
|
+1 ! James Turner <zak...@ma...> schrieb am Do., 5. Jan. 2017 16:38: > > > On 5 Jan 2017, at 15:09, James Turner <zak...@ma...> wrote: > > > > frameworks > > ‘framerates’, oops. > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
Thanks for helping keep SourceForge clean.
X