[Flightgear-devel] Nasal: Creating a new node
Good day,
I am attempting to create a new node via nasal
I will like to call the node as "TempNode" with a int value of 50 and i
will like to create it at /sim[0]/temp/.
If the node was created, it will look like /sim[0]/temp/TempNode with a
value of 50
I am very much confused with nasal and i was wondering how do i create
such a node.
props.Node.new("/sim[0]/temp/TempNode",50); ???
Thank you all for your valuable guidance
cheers
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download /built-interrasync
Torsten wrote, > > > > I also know that quoting white-space paths works well in "command.com" > > Windows shells. But apparently it didn't work when terrasync called the > > "system" function to call "svn". Unfortunately I have no means to test > > any of this on Windows. > The following patch seem to do the trick for me, it allow whitespace in > the command and in the local path name. > It simply wraps the entire system() command in "" and uses backslash > instead of forward slash for the path > separator in the local path. > > Please check, if it works for you. > Nope. I added a few extra alerts, and got this: svn: 'D:/terrasync' does not appear to be a URL Failed to synchronize directory ext'Objects/w130n30/w122n37', error code= 1 sync command ext '"svn checkout -q http://terrascenery.googlecode.com/svn/trunk/ data/Scenery/Terrain/w130n30/w122n37 D:/terrasync test\Terrain/w130n30/w122n37"' Looks to me as if the command has to include no white space, and that's it. Perhaps we should accept it, make sure the user is aware of it, and leave it at that. It's a pooh trap because all sorts of directories with spaces are created automatically by Windows - "Program Files" is only one such. Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download /built-interrasync
Am 24.06.11 11:09, schrieb Vivian Meazza: > Looks to me as if the command has to include no white space, and that's it. No, it may contain white space. It's just that we mix backslash and forward slash in the local path. This: D:/terrasync test\Terrain/w130n30/w122n37 Is a complete mess (from Windows point of view). I'll work on a solution later, probably today. Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal: Creating a new node
Am 24.06.11 09:22, schrieb xsaint:
> Good day,
>
> I am attempting to create a new node via nasal
> I will like to call the node as "TempNode" with a int value of 50 and i
> will like to create it at /sim[0]/temp/.
>
> If the node was created, it will look like /sim[0]/temp/TempNode with a
> value of 50
>
> I am very much confused with nasal and i was wondering how do i create
> such a node.
>
> props.Node.new("/sim[0]/temp/TempNode",50); ???
>
>
if you want to access TempNode often in your nasal, use
var myTempNode = props.globals.getNode("/sim/temp/TempNode", 1);
myTempNode.setIntValue( 50 );
or if you just set the node's value once:
setprop( "/sim/temp/TempNode", 50 );
Torsten
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Proposal: Move airplanes to an SVN repository
Ok, before I get flamed to a crisp, let me explain what is my reasoning behind this. Right now the fgdata repository is about 9 GB. This makes it really, really difficult to obtain an initial checkout of the fgdata folder, expecially for people that do not have a very good connection. at the same time it is not possible, to my knowledge, to only grab part of the repository. And most people don't really need he entire repository anyway. GIT is fantastic to handle code with many contributors, but I think it is really overkill for airplanes, where usually the number of people contributing to a single plane is fairly small and is unlikely that two people should work on the same file at the same time. Also, using SVN for planes the same way that is being used for scenery would allow individual planes to be pulled by a frontend, much like scenery is. Or even to be pulled by FGFS itself, though that's probably science fiction at this moment in time. So, is this something that could be implemented in the future? Am I barking up the wrong tree? I can foresee some issues, like, where should the repository be hosted, any other thing I have overlooked? Waiting for comments, flames and people asking "who is this guy?", yours sincerely, Alessandro Garosi (aka Brandano on IRC) -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Fri, 2011-06-24 at 10:48 +, TDO_Brandano - wrote: > Ok, before I get flamed to a crisp, let me explain what is my > reasoning behind this. Right now the fgdata repository is about 9 GB. > This makes it really, really difficult to obtain an initial checkout > of the fgdata folder, expecially for people that do not have a very > good connection. at the same time it is not possible, to my knowledge, > to only grab part of the repository. And most people don't really need > he entire repository anyway. GIT is fantastic to handle code with many > contributors, but I think it is really overkill for airplanes, where > usually the number of people contributing to a single plane is fairly > small and is unlikely that two people should work on the same file at > the same time. Also, using SVN for planes the same way that is being > used for scenery would allow individual planes to be pulled by a > frontend, much like scenery is. Or even to be pulled by FGFS itself, > though that's probably science fiction at this moment in time. So, is > this something that could be implemented in the future? Am I barking > up the wrong tree? I can foresee some issues, like, where should the > repository be hosted, any other thing I have overlooked? It has been proposed before and I believe it's the way to go. It's just a matter of someone stepping up for the task. Erik -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal: Creating a new node
Thank you Torsten,
I guess that is bringing me closer to what i am trying to code
Now i am trying to copy the value of
"instrumentation[0]/altimeter/indicated-altitude-ft" into
"/sim/temp/TempNode"
and below the code i have but it gives me nasal error as
"Nasal runtime error: setprop() value is not string or number
at /usr/share/games/FlightGear/Aircraft/SSJ/Nasal/systems.nas, line 445"
The code i am using
var myTempNode = props.globals.getNode("/sim/temp/TempNode", 1,);
myTempNode.setIntValue( 50 );
setprop("/sim/temp/TempNode",getprop("instrumentation[0]/altimeter/indicated-altitude-ft"));
Could you please guide me on where i am going wrong please?
Thank you
On Friday 24,June,2011 05:23 PM, Torsten Dreyer wrote:
> Am 24.06.11 09:22, schrieb xsaint:
>> Good day,
>>
>> I am attempting to create a new node via nasal
>> I will like to call the node as "TempNode" with a int value of 50 and i
>> will like to create it at /sim[0]/temp/.
>>
>> If the node was created, it will look like /sim[0]/temp/TempNode with a
>> value of 50
>>
>> I am very much confused with nasal and i was wondering how do i create
>> such a node.
>>
>> props.Node.new("/sim[0]/temp/TempNode",50); ???
>>
>>
> if you want to access TempNode often in your nasal, use
>
> var myTempNode = props.globals.getNode("/sim/temp/TempNode", 1);
> myTempNode.setIntValue( 50 );
>
>
> or if you just set the node's value once:
>
> setprop( "/sim/temp/TempNode", 50 );
>
> Torsten
>
> --
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense..
> http://p.sf.net/sfu/splunk-d2d-c1
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Erik wrote > On Fri, 2011-06-24 at 10:48 +, TDO_Brandano - wrote: > > Ok, before I get flamed to a crisp, let me explain what is my > > reasoning behind this. Right now the fgdata repository is about 9 GB. > > This makes it really, really difficult to obtain an initial checkout > > of the fgdata folder, expecially for people that do not have a very > > good connection. at the same time it is not possible, to my knowledge, > > to only grab part of the repository. And most people don't really need > > he entire repository anyway. GIT is fantastic to handle code with many > > contributors, but I think it is really overkill for airplanes, where > > usually the number of people contributing to a single plane is fairly > > small and is unlikely that two people should work on the same file at > > the same time. Also, using SVN for planes the same way that is being > > used for scenery would allow individual planes to be pulled by a > > frontend, much like scenery is. Or even to be pulled by FGFS itself, > > though that's probably science fiction at this moment in time. So, is > > this something that could be implemented in the future? Am I barking > > up the wrong tree? I can foresee some issues, like, where should the > > repository be hosted, any other thing I have overlooked? > > It has been proposed before and I believe it's the way to go. It's just > a matter of someone stepping up for the task. > Something must be done, this is something, therefore it should be done :-). Seriously, Git has never been right for the data. We were promised a fix, which has never materialized. SVN can be no worse, and it might be better. Terrasync indicates that it might well be better, and might give us the ability to pull aircraft down for MP on the fly. I agree with Erik. Perhaps Alessandro would take this forward with some more concrete proposals that we could consider. Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
2011/6/24 TDO_Brandano - > Ok, before I get flamed to a crisp, let me explain what is my reasoning > behind this. Right now the fgdata repository is about 9 GB. [...] > I agree with Brandano, airplanes data is way too big for git, and the problem will only get worst with time. I would keep in git only a maximum of 3 aircrafts + UFO for scenery building. The rest should be kept away (I have no good idea right now). Can't the repository be hosted on the same server of the fgdata ? Cheers Francesco > Waiting for comments, flames and people asking "who is this guy?", yours > sincerely, > > Alessandro Garosi (aka Brandano on IRC) > > > -- > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense.. > http://p.sf.net/sfu/splunk-d2d-c1 > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal: Creating a new node
Try this:
var myTempNode = props.globals.initNode("/sim/temp/TempNode", 50,"INT");
myTempNode.setValue(getprop("instrumentation[0]/altimeter/indicated-altitude-ft"));
> The code i am using
> var myTempNode = props.globals.getNode("/sim/temp/TempNode", 1,);
remove comma at the end.
> myTempNode.setIntValue( 50 );
> setprop("/sim/temp/TempNode",getprop("instrumentation[0]/altimeter/indicated-altitude-ft"));
>
>
> Could you please guide me on where i am going wrong please?
>
>
> Thank you
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Fri, Jun 24, 2011 at 1:13 PM, Vivian Meazza wrote: > > Seriously, Git has never been right for the data. We were promised a fix, > which has never materialized. SVN can be no worse, and it might be better. > Terrasync indicates that it might well be better, and might give us the > ability to pull aircraft down for MP on the fly. Ok, here is my usual negative comment (only by request :P) Could we please forget SVN forever? Thank you. Applies to scenery too, although I have been told its use was introduced to get free hosting from google and not for technical merit. Using SVN so you can download stuff on the fly is ridiculous, that's not the task of a revision control system (and built scenery probably doesn't need a revision control anyway). For all development tasks SVN is clearly worse than GIT (branches, local changes, merge requests, client side history, backups, etc.), and it isn't particularly good at the download part either. Also, an eventual automated aircraft download system should allow for 3rd party hangars too (would be the most important benefit, if you ask me), and not force SVN upon everybody. We should keep it simple, and probably just use regular snapshots from the revision control system made available via http. To summarize: if we want to split fgdata or allow automatic aircraft (model) downloads, that's fine with me, but I don't think SVN is the right tool for the task(s). -- Csaba/Jester -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Fri, 2011-06-24 at 15:20 +0200, Csaba Halász wrote: > On Fri, Jun 24, 2011 at 1:13 PM, Vivian Meazza > wrote: > > > > Seriously, Git has never been right for the data. We were promised a fix, > > which has never materialized. SVN can be no worse, and it might be better. > > Terrasync indicates that it might well be better, and might give us the > > ability to pull aircraft down for MP on the fly. > > Ok, here is my usual negative comment (only by request :P) > Could we please forget SVN forever? Thank you. Applies to scenery too, > although I have been told its use was introduced to get free hosting > from google and not for technical merit. > > Using SVN so you can download stuff on the fly is ridiculous, that's > not the task of a revision control system (and built scenery probably > doesn't need a revision control anyway). For all development tasks SVN > is clearly worse than GIT (branches, local changes, merge requests, > client side history, backups, etc.), and it isn't particularly good at > the download part either. Also, an eventual automated aircraft > download system should allow for 3rd party hangars too (would be the > most important benefit, if you ask me), and not force SVN upon > everybody. We should keep it simple, and probably just use regular > snapshots from the revision control system made available via http. > > To summarize: if we want to split fgdata or allow automatic aircraft > (model) downloads, that's fine with me, but I don't think SVN is the > right tool for the task(s). > I agree (FWIW). We don't use the fgdata like a normal code revision repository. It's a bit like the analogy "to guy with a hammer, ever problem can be fixed by hitting it" So there probably needs to be some discussion of what we really need first; Each aircraft developer can have their own code repository somewhere (Git, SVN, whatever), It needs a way to package that aircraft so it can be deployed easily to the FG Install directory, something along the lines of a Java Enterprise Archive or a RedHat RPM file. Something that allows FG to track the installed version, and enforce minimum dependencies. Something that is transport agnostic (HTTP, FTP, SVN, SSH) Something that allows the install to be relocatable in the file tree (so you can deploy a development release and not mess up your live version, like --fg-aircraft) S. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Csaba wrote > On Fri, Jun 24, 2011 at 1:13 PM, Vivian Meazza > wrote: > > > > Seriously, Git has never been right for the data. We were promised a > fix, > > which has never materialized. SVN can be no worse, and it might be > better. > > Terrasync indicates that it might well be better, and might give us the > > ability to pull aircraft down for MP on the fly. > > Ok, here is my usual negative comment (only by request :P) > Could we please forget SVN forever? Thank you. Applies to scenery too, > although I have been told its use was introduced to get free hosting > from google and not for technical merit. > > Using SVN so you can download stuff on the fly is ridiculous, that's > not the task of a revision control system (and built scenery probably > doesn't need a revision control anyway). For all development tasks SVN > is clearly worse than GIT (branches, local changes, merge requests, > client side history, backups, etc.), and it isn't particularly good at > the download part either. Also, an eventual automated aircraft > download system should allow for 3rd party hangars too (would be the > most important benefit, if you ask me), and not force SVN upon > everybody. We should keep it simple, and probably just use regular > snapshots from the revision control system made available via http. > > To summarize: if we want to split fgdata or allow automatic aircraft > (model) downloads, that's fine with me, but I don't think SVN is the > right tool for the task(s). > All good stuff - but when are we likely to see this hypothetical improved system? So what is the right tool? Our Git repo is clearly not fit for purpose as it stands, and I'm really fed up with doing battle with it with inadequate weapons. Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Friday, June 24, 2011 05:19:58 AM Francesco Angelo Brisa wrote: > 2011/6/24 TDO_Brandano - > > > Ok, before I get flamed to a crisp, let me explain what is my reasoning > > > > behind this. Right now the fgdata repository is about 9 GB. [...] > > I agree with Brandano, airplanes data is way too big for git, and the > problem will only get worst with time. > I would keep in git only a maximum of 3 aircrafts + UFO for scenery > building. > The rest should be kept away (I have no good idea right now). Can't the > repository be hosted on the same server of the fgdata ? > > Cheers > Francesco 1. GIT is not the real issue as it is a powerful version control tool that can handle as much as any other tool out there. 2. The real issue is that fgdata is too big resulting in huge downloads and developers getting all kinds of stuff that they don't need. That is most of the work in fgdata is aircraft work and most aircraft devs only touch one or two of the hundreds of aircraft in the repository. 3. Regardless of what source code control system is used #2 is still an issue unless fgdata/Aircraft is somehow decomposed into seperate repositories for each aircraft. 4. I think #3 applies to all aircraft including the UFO and any other "core" aircraft. That is all aircraft should have code managed in the same way. 5. Having seperate aircraft repositories implies that there will be an "fgdata build" that can create a fully functional fgdata directory with some set of aircraft. 5a. Perhaps this "build" can be configured by the user to use the aircraft status as a way to filter which aircraft are included in the "build" and perhaps there should be a small default set of aircraft that are always part of the "build". 5b. For those following GIT who need to do regualr updates to fgdata to keep it in sync with fgfs GIT this will make that process faster and less bandwidth hungery. 6. Because we now have a functioning --fg-aircraft configuration using seperate repositories should be easy for aircraft devs to setup even if they are working on more than one aircraft. 7. Having seperate repositories for each aircraft would also facilitate managing who has commit and review privilages for each aircraft and allow for more fine grained security. 8. There are a lot of details that need to be sorted out to make this work. Hal > > > Waiting for comments, flames and people asking "who is this guy?", yours > > sincerely, > > > > Alessandro Garosi (aka Brandano on IRC) > > > > > > - > > - All the data continuously generated in your IT infrastructure > > contains a definitive record of customers, application performance, > > security threats, fraudulent activity and more. Splunk takes this data > > and makes sense of it. Business sense. IT sense. Common sense.. > > http://p.sf.net/sfu/splunk-d2d-c1 > > ___ > > Flightgear-devel mailing list > > Flightgear-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Am 24.06.11 12:55, schrieb Erik Hofman: > On Fri, 2011-06-24 at 10:48 +, TDO_Brandano - wrote: >> Ok, before I get flamed to a crisp, let me explain what is my >> reasoning behind this. Right now the fgdata repository is about 9 GB. > > It has been proposed before and I believe it's the way to go. It's just > a matter of someone stepping up for the task. > > Erik > Everyone is free to build a own "hangar" on gitorious, everyone is free to develop, exchange, merge in, push, to discuss and bring different aircrafts together in his own hangar. No hierarchical centralized system is needed with git and gitorious/github, you merge in or push whatever you want. People can clone, pull, merge, push, watch, organize, whatever they want. No one will ask. You collaborate or not, you build your own hangar, it is your choice, YOU set permissions, YOU give access, YOU share permissions or not. You give people links here and there to provide "your" aircrafts or aircrafts of "canadian group of most serious aircrafts" or whatelse. An educational hangar, a polar ice hangar, a chopper hangar, a historical hangar ... I really don’t know why most people here use gitorious and git like a hierarchical system of the romans with asking for permissions, sending merge requests to some development sub-kings, waiting for this and that. It is not necessary, just see the freedom, use git as it is probably thought, and open your own personal-number-one-hangar, show your work, and "git reset --hard" yourself when necessary ;-) And meantime fgdata core developers try to find consensus about 10 or 15 aircrafts remaining in basic fgdata (Arghh! Consensus!). That is what was requested here some months ago (hey, fgdata core developers, with all my respect, don’t fear to say which are the best aircrafts we have!, and please do not wait for Tim, I guess he will not do that job for you). Of course, this are my very very personal thoughts, please do not blame me for that, it is not necessary. I have to say we will introduce something new in the new FlightGear Launcher FGx the next months: You can choose a hangar and update your aircrafts by DIFFERENT hangars. Unfortunately we can’t do it with git directly, but I am sure we will find something like a "general hangar protocol" ;-) a xml file or something on top of every hangar with short aircraft description or whatever, which can be set up and provided by EVERYONE in the world with some space left on a server. The rest will be done by FGx and a built-in installer. Only restriction: all must be free and open source. And what a chaos you will say, everyone uses different aircrafts. But this is what some users want -> no kings and no 9 GB downloads. Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download /built-interrasync
Torsten wrote > > Am 24.06.11 11:09, schrieb Vivian Meazza: > > Looks to me as if the command has to include no white space, and that's > it. > No, it may contain white space. It's just that we mix backslash and > forward slash in the local path. > > This: > D:/terrasync test\Terrain/w130n30/w122n37 > Is a complete mess (from Windows point of view). > I'll work on a solution later, probably today. > Is this built-in function: svn_path_uri_encode() any help? -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Ok, let me sum up a few of the day's IRC discussions. The size of the GIT repository is a real issue, and I am not the only one that perceives it as such. At the same time, SVN suffers from several disadvantages compared to GIT, even from the point of view of reliability. Even the map data should not really be hosted on SVN, but it's mainly hosted there because we get that hosting for free from Google. Everyone agrees that the Aircraft data would be better off split aside from the rest of fgdata now that FGFS can load them from a separate folder. Several people find the idea of loading single planes at launch time or at runtime interesting. SVN is not really required to do this, the planes could be hosted on a separate server as archives and either installed, or, in the far future, loaded as compressed archives. To do this there must be some sort of structure keeping track of dependencies for single planes, version compatibility and available planes so that download packages can be generated automatically and developers can download the entire thing via a script or something similar if they want to. The ideal situation would have a repository for each aircraft or for each author, to allow individual authors GIT access for their own planes. There's planes where the author is unknown or is long missing, and those will need anyway to be kept under version control since changes to FGFS might break compatibility in the future. Also, fragmenting the repository might mean that some author could choose to use a different or more recent license for her plane, so we need to keep track of this info as well. At the very least an automatic downloader should either filter the downloads based on license or prompt the user for approval. Someone on IRC has volunteered to do this work, but I won't name names until I am sure he is being serious and that he is reliable, since I think he would need some pretty powerful rights on the repository to do this. Am I missing anything else? Alessandro (Brandano) > Date: Fri, 24 Jun 2011 17:41:36 +0200 > From: flightg...@sablonier.ch > To: flightgear-devel@lists.sourceforge.net > Subject: Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository > > Am 24.06.11 12:55, schrieb Erik Hofman: > > On Fri, 2011-06-24 at 10:48 +, TDO_Brandano - wrote: > >> Ok, before I get flamed to a crisp, let me explain what is my > >> reasoning behind this. Right now the fgdata repository is about 9 GB. > > > > It has been proposed before and I believe it's the way to go. It's just > > a matter of someone stepping up for the task. > > > > Erik > > > > Everyone is free to build a own "hangar" on gitorious, everyone is free > to develop, exchange, merge in, push, to discuss and bring different > aircrafts together in his own hangar. No hierarchical centralized system > is needed with git and gitorious/github, you merge in or push whatever > you want. People can clone, pull, merge, push, watch, organize, whatever > they want. No one will ask. You collaborate or not, you build your own > hangar, it is your choice, YOU set permissions, YOU give access, YOU > share permissions or not. You give people links here and there to > provide "your" aircrafts or aircrafts of "canadian group of most serious > aircrafts" or whatelse. An educational hangar, a polar ice hangar, a > chopper hangar, a historical hangar ... > > I really don’t know why most people here use gitorious and git like a > hierarchical system of the romans with asking for permissions, sending > merge requests to some development sub-kings, waiting for this and that. > It is not necessary, just see the freedom, use git as it is probably > thought, and open your own personal-number-one-hangar, show your work, > and "git reset --hard" yourself when necessary ;-) > > And meantime fgdata core developers try to find consensus about 10 or 15 > aircrafts remaining in basic fgdata (Arghh! Consensus!). That is what > was requested here some months ago (hey, fgdata core developers, with > all my respect, don’t fear to say which are the best aircrafts we have!, > and please do not wait for Tim, I guess he will not do that job for you). > > Of course, this are my very very personal thoughts, please do not blame > me for that, it is not necessary. I have to say we will introduce > something new in the new FlightGear Launcher FGx the next months: You > can choose a hangar and update your aircrafts by DIFFERENT hangars. > Unfortunately we can’t do it with git directly, but I am sure we will > find something like a "general hangar protocol" ;-) a xml file or > something on top of every hangar with short aircraft description or > whatever, which can be set up and provided by EVERYONE in the world with > some space left on a server. The rest will be done by FGx and a built-in > installer. Only restriction: all must be free and open source. And what > a chaos you will say, everyone uses different
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Alessandro, Seems like good summary to me. You mean that I've been working on terrasync/svn for nearly 2 weeks, and it's unnecessary? As I recall it, at least part of the choice of SVN for the scenery repo was that Windows didn't have a native rsync utility, and SVN represented a fairly ready-made alternative. The choice of Google might well have been influenced by the cost. Why don't you just do it? You don't need full access to Gitorious data repo to produce a proof-of-principle repo using the proposed structure. If it works, and the bugs have been ironed, then all the data could be migrated to it. And in any case we shouldn't abandon the old until the new is up and running. Vivian -Original Message- From: TDO_Brandano - [mailto:tdo_brand...@hotmail.com] Sent: 24 June 2011 18:46 To: Flightgear Devel List Subject: Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository Ok, let me sum up a few of the day's IRC discussions. The size of the GIT repository is a real issue, and I am not the only one that perceives it as such. At the same time, SVN suffers from several disadvantages compared to GIT, even from the point of view of reliability. Even the map data should not really be hosted on SVN, but it's mainly hosted there because we get that hosting for free from Google. Everyone agrees that the Aircraft data would be better off split aside from the rest of fgdata now that FGFS can load them from a separate folder. Several people find the idea of loading single planes at launch time or at runtime interesting. SVN is not really required to do this, the planes could be hosted on a separate server as archives and either installed, or, in the far future, loaded as compressed archives. To do this there must be some sort of structure keeping track of dependencies for single planes, version compatibility and available planes so that download packages can be generated automatically and developers can download the entire thing via a script or something similar if they want to. The ideal situation would have a repository for each aircraft or for each author, to allow individual authors GIT access for their own planes. There's planes where the author is unknown or is long missing, and those will need anyway to be kept under version control since changes to FGFS might break compatibility in the future. Also, fragmenting the repository might mean that some author could choose to use a different or more recent license for her plane, so we need to keep track of this info as well. At the very least an automatic downloader should either filter the downloads based on license or prompt the user for approval. Someone on IRC has volunteered to do this work, but I won't name names until I am sure he is being serious and that he is reliable, since I think he would need some pretty powerful rights on the repository to do this. Am I missing anything else? Alessandro (Brandano) > Date: Fri, 24 Jun 2011 17:41:36 +0200 > From: flightg...@sablonier.ch > To: flightgear-devel@lists.sourceforge.net > Subject: Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository > > Am 24.06.11 12:55, schrieb Erik Hofman: > > On Fri, 2011-06-24 at 10:48 +, TDO_Brandano - wrote: > >> Ok, before I get flamed to a crisp, let me explain what is my > >> reasoning behind this. Right now the fgdata repository is about 9 GB. > > > > It has been proposed before and I believe it's the way to go. It's just > > a matter of someone stepping up for the task. > > > > Erik > > > > Everyone is free to build a own "hangar" on gitorious, everyone is free > to develop, exchange, merge in, push, to discuss and bring different > aircrafts together in his own hangar. No hierarchical centralized system > is needed with git and gitorious/github, you merge in or push whatever > you want. People can clone, pull, merge, push, watch, organize, whatever > they want. No one will ask. You collaborate or not, you build your own > hangar, it is your choice, YOU set permissions, YOU give access, YOU > share permissions or not. You give people links here and there to > provide "your" aircrafts or aircrafts of "canadian group of most serious > aircrafts" or whatelse. An educational hangar, a polar ice hangar, a > chopper hangar, a historical hangar ... > > I really don't know why most people here use gitorious and git like a > hierarchical system of the romans with asking for permissions, sending > merge requests to some development sub-kings, waiting for this and that. > It is not necessary, just see the freedom, use git as it is probably > thought, and open your own personal-number-one-hangar, show your work, > and "git reset --hard" yourself when necessary ;-) > > And meantime fgdata core developers try to find consensus about 10 or 15 > aircrafts remaining in basic fgdata (Arghh! Consensus!). That is what > was requested here some months ago (hey, fgdata core developers, with > all my respect, don't f
Re: [Flightgear-devel] Heads up: scenery download /built-interrasync
I wrote: > -Original Message- > From: Vivian Meazza [mailto:vivian.mea...@lineone.net] > Sent: 24 June 2011 18:45 > To: 'FlightGear developers discussions' > Subject: Re: [Flightgear-devel] Heads up: scenery download /built- > interrasync > > Torsten wrote > > > > > Am 24.06.11 11:09, schrieb Vivian Meazza: > > > Looks to me as if the command has to include no white space, and > that's > > it. > > No, it may contain white space. It's just that we mix backslash and > > forward slash in the local path. > > > > This: > > D:/terrasync test\Terrain/w130n30/w122n37 > > Is a complete mess (from Windows point of view). > > I'll work on a solution later, probably today. > > > > Is this built-in function: > > svn_path_uri_encode() > > any help? > Yup, does the trick - no need for fancy formatting. I'll see if I can do a damned merge request this side of Monday. Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download /built-interrasync
>> Is this built-in function: >> >> svn_path_uri_encode() >> >> any help? >> > Yup, does the trick - no need for fancy formatting. > > I'll see if I can do a damned merge request this side of Monday. > > Vivian > > But isn't this a function of libsvn and we are talking about external svn and libsvn not present? I'm currently testing another fix without libsvn functions. Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download /built-interrasync
Am 24.06.11 23:59, schrieb Torsten Dreyer: >>> Is this built-in function: >>> >>> svn_path_uri_encode() >>> >>> any help? >>> >> Yup, does the trick - no need for fancy formatting. >> >> I'll see if I can do a damned merge request this side of Monday. >> >> Vivian >> >> > But isn't this a function of libsvn and we are talking about external > svn and libsvn not present? > > I'm currently testing another fix without libsvn functions. > > Torsten Here you go: simgear commit d36170879c9394064b37fc9acb3d12d451f2be82 makes whitespaces in the command _and_ the target directory work for me. Tested on Linux, MacOS and WinXP/VS2008. Please pull simgear and rebuild simgear+flightgear and test if it works for you. Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download /built-interrasync
Torsten > > >> Is this built-in function: > >> > >> svn_path_uri_encode() > >> > >> any help? > >> > > Yup, does the trick - no need for fancy formatting. > > > > I'll see if I can do a damned merge request this side of Monday. > > > > Vivian > > > > > But isn't this a function of libsvn and we are talking about external > svn and libsvn not present? > > I'm currently testing another fix without libsvn functions. > This is true. But using Fred's MSVC9 solution files as provided it is not possible to switch off the libsvn stuff AFAIKS. As I said way back - we seem to have at least 3 overlapping scenery download methods. I'm not entirely clear on the relative merits of the internal and external svn options. I think we also need svn_path_uri_encode() in the internal path to allow download directories paths to have spaces. A space in the directory path is almost bound to happen, because the default terrasync directory is C:/Program Files/FlightGear/terrasyncdir. Nevertheless, a non-libsvn solution must be good. If it can be done in svn_path_uri_encode(), it must be doable locally. Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
