Re: [Flightgear-devel] wiki spammer
Hi Guys, We had to put logins onto the X-Plane SDK wiki - we got spammed pretty hard. Since the auth was put in we've had no problems. *cheers* Ben Melchior FRANZ wrote: Looks like our wiki is the target of a pr0n spam bot. It obviously uses zombies, and there's no reasonable way to block it other than with making logging in mandatory. Blocking IP addresses is pointless and will lead nowhere. I don't even consider mandatory login a bad thing -- why would we want anonymous people to edit FlightGear content? These pages are very visible to the public, and content found there is linked to the project. (BTW: I also find it undesirable that people use nicks in the Wiki. I prefer to see who edited what, and being able to contact him/her via email. How would I contact FlightZilla?) m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] wiki spammer
We did okay without captchas, but we are not using MediaWiki, rather phpWiki...it's conceivable that MediaWiki has smarter bots written for it although I do not know. Simon Hollier wrote: On 7/18/06, Vassilii Khachaturov [EMAIL PROTECTED] wrote: Hi Guys, We had to put logins onto the X-Plane SDK wiki - we got spammed pretty hard. Since the auth was put in we've had no problems. *cheers* I think that this means we could also try to do w/o the captchas first. V It turns out that required email confirmation on user accounts before editing does indeed work and I've turned it on. This should solve the problem without resorting to blacklists or captchas. Simon - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Guys, I've been operating under the assumption that load performance for FG is not a requirement for apt.dat because you guys are already pre-processing the file to make scenery, and could thus convert the apt.dat file to something faster to read _if_ you wanted to trade load time for the benefits of text. *cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Preclipped or overlapping layouts for apt.dat
Hi Y'all, One of the things that's come up in the apt.dat discussions is whether the taxiway layouts should be pre-clipped (meaning there are no overlapping polygons) or overlapped (meaning polygons can overlap and there is a well-defined draw order that makes one appear on top of another). (I think we have to pick one - having overlapping polygons with random draw order doesn't help authors make layouts.) I'm looking for pros and cons of each technique...here's some thoughts I've had: - I'm not sure about FG's scenery distro model, but pre-clipped polygons means that more work has been done to a layout before it becomes an apt.dat file, which would make on-the-fly loading of add-on scenery faster. - Any app will have to do clipping or draw order control - clipping can happen before or during app run. So a clipping model gives us a chance to keep work out of sim-run-time, but an overlapped model allows us to do work in the sim (e.g. avoid the need for preprocessing). I think FG is pretty strongly in the preprocessing camp right now. - Pre-clipping puts more burdon on content creation tools (by requiring them to have robust clipping to save the data) whereas not requiring pre-clipping puts more work on data consumers. - Personally I like pre-clipping because I've always found overlapping runway data to be...messy. I always wonder if there isn't some polygon buried under another one, totally invisible to the user. So I tend to think pre-clipping makes a better editing environment. But this last point is probably not appropos to the discussion. Thoughts? Ben ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Preclipped or overlapping layouts for apt.dat
Hi Paul, For what it's worth, I'm leaning more and more toward overlapping, both because of your arguments, stuff Curt's said, and just tossing the ideas around...so this is a bit of a devil's advocate argument... Paul Surgeon wrote: Where are you thinking of saving the clipped data? Back into apt.dat (heaven forbid!) or straight to a scenery format? Yes - back into the apt.dat format. If we had to store the clipped data to apt.dat file the file will become massive and the editor tools would have to be very complex to handle the data. In essense TaxiDraw would become a 3D modeler for airports. Yes. Saving overlapping layouts is going to be a lot cleaner. I'd rather see the clipping done at scenery build time or simulator run time much like the way it's handled at the moment. I'm not sure I would say overlapping is 'cleaner'...it's definitely simpler from a data format and validation standpoint, simpler for an editor, but perhaps more complex for a viewer. Whether it's a truer representation I think depends on the intent of the author. In my original RFC I described the apt.dat format as a distribution format because the output of editors like Taxidraw goes into the database for distribution. But this isn't really tool, because we'd like to be able to put the layouts back into TaxiDraw (or another editor) and work on them more. Also apt.dat's roll as a high-level format shared between two sims implies it shouldn't be gunked up with distribution-level optimizatinos. So both these things have been moving me back toward overlapping and away from clipping. *cheers* ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Guys, First I must say I have not read the past FG-dev discussion on this ... if someone can point me to a thread title name or date range I will catch up. The 850 apt.dat format came out of about 3 years of banging our head on the problem inside LR, but I suspect that the things we've struggled with are similar to some of the approaches described here. To try to answer some questions: X-Plane has ended up more and more using a 'compiler' approach to our scenery, where we view the process of making scenery as a series of transformations on data. The final transformation is into some kind of distribution format, the assembly code of our scenery, where the format is meant to be fast to read, compact, and things the sim doesn't care about but tools do have been thrown out. Overall this has worked well for us, and I think is appearing a bit in apt.dat 850. In particular, really the apt.dat 850 taxiway layouts should be thought of as a planar map of bezier curves, but X-plane doesn't care, so 850 apt.dat is more of a derivative product of which a planar map is one of multiple possible sources. A topological network that has been 'extruded' into a taxiway set could also be the source. One of the advantages of a compiler approach is that different tools can create simcompatible layout without accepting the same abstractions. With that in mind, apt.dat 850 is low level...if you guys can get an SVG editor to output the kind of format you need, then that's great ! I just recommend that you consider the process a transform and not insist that the intermediate and final formats be the same...the design needs of the sim and the editing tools may be very different. (I should also say, for us they are different because X-plane is a commercial sim, so it's possible that FG can use the editing format as the distribution format where other sims can't. But I think having the two decoupled is useful for backward compatibility, if this is a goal.) ATC and Logical Layout: apt.dat 850 is a total punt - it makes no attempt to provide logical layout, machine-ready analysis of the layout, or things an ATC or AI implementation would need. This came out of pragmatism...we couldn't find a format that enforced these high level constructs, was still expressive enough to do all of the special-case things that authors would want to model real life, and would still be practical to implement. Based on the compiler model, a logical layout could be compiled into an apt.dat layout, but an apt.dat 850 layout might not be decompilable. Our assumption was that given higher level layouts, we would separately compile ATC/AI data if/when we need it. I see comments that something is better than nothing and also that this isn't a step in the right long-term direction. I will only say: right now we have _no_ higher level metadata defined in layouts and frankly the way that even the outline of the layout is expressed is a bit kludgy. So to me going to bezier curves is a step away from the wrong direction, even if it isn't a step in the right direction. (Did that make any sense?) I guess what I'm trying to say is: I wouldn't suggest sticking with overlapping quads because bezier curves don't have logical layout. If you can make a logical layout system work, then that's great, but at LR we saw that as out of our current scope. Border Lights: two thoughts...the apt.dat 850 spec specifically defines layouts as made entirely of old or new records...one of the things this implies is that FG or X-plane or any sim only has to generate 'clipped' taxiway lights for an old layout. That code can be skipped for a new layout, where all lights are explicitly placed. The problem of inset/non-inset lights is a tricky one...we're still going up and back on how much of these kinds of effects should be automatic vs explicit. For example, it seemed logical that x-plane would choose inset vs non-inset approach lights by looking at the presence of crossing taxiways, displaced threshholds, etc. On the other hand, we didn't think we could change a taxi line to have/not-have a black stripe based on the underlying terrain pavement. So I'm not sure what's best here...basically anything that could have a logical ruling but is considered too much of a PITA for the sim ends up pushed off to the tools...for our current code base the tools do a lot of work to make scenery pre-digestible and by choosing a similar strategy for airports we risk the same thing happening. But then it's all code that has to get written, whether it's in a tool or the sim's code base. In the end of the day I suppose it's a question of whether inset taxi lights are fundamentally different from non-inset ones or whether they represent two variations of the same concept. *Cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK:
Re: [Flightgear-devel] apt.dat changes ?
Hi Ralf, Ralf Gerlich wrote: As it seems, the X-Plane authors are not keen to go away from the apt.dat format, so if FlightGear would go away from bidirectional compatibility with apt.dat, this would result in a clear split of the databases and in ceasing the up to now fruitful exchange of data between FlightGear and X-Plane. Keep this in mind when assessing the advantages of a new, totally different format. I'm not 100% what you mean by this...we are supporting older apt.dat formats in x-plane ... we have to - in X-plane apt.dat can be embedded in custom scenery packas, so users can add old-format data to the sim in-field. So X-Plane will continue to read and show old-format data but without any new features. ...and that's why that is to change in the new apt.dat-format. They have both polygonal pavement sections, but also polyline sections, by which rows of lights, markings, etc., can be placed accurately. Accurately and arbitrarily! And this is one of our design choices. Given a choice between come up with a logical model that explains every possible combination of pavement and taxiway line markings and let the user put the paint where it is in real life we ended up at the second, after trying some schemes for the first and just spiraling totally out of control. We considered 'total realism' to be the goal, e.g. it would be unacceptable to have the wrong pavement markings (by real life standings) because the algorithm to generate them couldn't be expressed by our logic model. Of course, such an expressive logic model would be valuable for a number of things, so it might make sense to develop one for FG...in the case of X-Plane it didn't fit with our development roadmap. However, given proper tools - which is what TaxiDraw is going for - we can make the tool support the user, by, e.g., automatically placing lines of borderlights around any new pavement polygon and allow the user to edit them or remove them as they wish. The 850 format also supports the tagging of the bezier edges with light codes, so to some extent the procedure of wrapping lights around pavement is made a little bit simpler, or at least the data file a little smaller. *Cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Ralf, Ralf Gerlich wrote: There was criticism of the physical storage model of apt.dat, as it has been and probably will continue to be in version 850. I just wanted to say that, if the FlightGear project were to invent its own format - let's call it FGAPT for simplicity - and would then not be able to convert from APT to FGAPT _and_ backwards, we would lose the possibility of properly interchanging data with X-Plane and Robin Peel's database. We might not lose the possibility in total, but at least in part. Ah...well, it's that translatability that's most important I think ... there's really no reason why FG should be stuck with an X-Plane container model. Some time ago (it might be already a year ago) I had a discussion with Dave Luff on the topic of making TaxiDraw a bit more useable. At that time I had started customising scenery for my local area and found the way of working with single rectangles in TaxiDraw very awkward and time-consuming, in contrast to, e.g., just clicking along the centerline of a taxiway and having TaxiDraw generate the rectangles from that. This is where the compiler model works...it doesn't dictate a higher level abstraction, so it leaves authors like you and David to make the best internal model for TaxiDraw that you can come up with, one that plays to TaxiDraw's strengths and doesn't saddle you with implementing things you don't need. We had Christian Franz trying to take X-plane's final modeling format (OBJ) and stick extensions into it to make it into an editing format...this ended in repeated failure; by comparison, exporting from Blender works well. I also like the mindset of interpreting apt.dat as some kind of intermediate format of a compiler. However, as decompilation into a higher-level format is not possible, apt.dat even in its new form does not seem to be a good format for keeping in a central database based on which updates to the airport layouts are made. Such a format needs to keep the top-level information modellers see in their editor, so that the next one can simply import that top-level model from the database and go on where his/her predecessor left. This is exactly the reason why we have sourcecode in our CVS and not the intermediate register transfer language (RTL) of the GNU C/C++ compiler suite ;-) Well, there is the problem: if you want to database the highest level layout info, you need to standardize the high level model. I'm not against doing that...but to some extent it's beyond the scope of apt.dat 850...to some extent apt.dat 850 says what data x-plane will eat, but nothing about where it comes from. The intention is that the programs that create that data will have a more descriptive format that makes editing practical. *Cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Ralf, Ralf Gerlich wrote: Well, there is the problem: if you want to database the highest level layout info, you need to standardize the high level model. Then that's where we need to work with you and Robin Peel regarding the next generation database ;-) Just to play devil's advocate: 1. How hard would it be to reconstruct a layout from the low-level apt.dat layout? I'm imagining a layout started in WorldEditor and then modified in TaxiDraw. Would you and I have to agree on a high-level interchange format, or could we reconstitute the info we need from the low level format? (I suppose this is a question about the editors - for an editor that truly built layouts from centerlines, there would I think be no way to reconstitute a layout. Because WED will be area-focused, it could probably rebuild a layout from its export, with the risk that some layouts would be invalid within WED.) 2. What if we databased the last author of a layout...the implication being that if you want to edit a layout in the DB and cannot work with the final apt.dat data, you contact the author and resolve the problem directly? Without this, it becomes necessary for all editors to agree on a high level format that is in the DB and thus is involved in lockstep. So I'm looking for a practical solution that would decouple this dependency. *cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
Hi, Sorry to barge in again, but I work with the VATSIM guys and can tell you: you may have licensing issues...email Lefteris to find out about such a thing, but you may want to find out up-front if the licensing on the VATSIM VoIP stuff is compatible with FG (either legally or philosophically). *CHeers* Ben Justin Smithies wrote: Is anyone working on a plugin / client to enable us FG users to use the vatsim network with voice too ? I myself can't find anything at all , maybe some of us could get together and start such a project ? Regards, Justin Smithies ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vatsim
Hi Y'all, GWMobile wrote: Why not just duplicate vatsim with independent GPL programming? I think the point of VATSIM (and IVAO) is that they are existing communities with user bases that show up on a regular basis. If you wrote a pilot client for FG you could then go fly online on any given night and be pretty sure you'd have live ATC, without convincing anyone else to get involved, because you'd be joining an existing community. That's a double-edged sword...if you don't like VATSIM's admin/moderator policy or its management or dev policy, well, it already exists so you wouldn't have the kind of influence that you get from starting things on the ground floor. On the other hand, it's a lot less work to write a client for FG than to write a client, server, ATC client, possibly write clients for other flight sims to get higher user numbers, write the protocols, find a VoIP lib, and also get the servers and donated bandwidth and then convince a few thousand people to use the service on a regular basis. So I think you guys have to decide your goals before you can evaluate an approach! *Cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
