Merging shaped_arenas into HEAD (complete)

[Luke-Jr]

About the DTD: it does work OK for the hexatron map; the DTD reference there seems to point to the web ( but nevertheless, it's not downloaded, I can't find it on my harddisk ).

I wonder if I should add a config setting determining the default path used for finding DTDs w/o paths specified... Oh, and it was downloaded. Just not cached... I wonder if there's a way to intercept (and cache) libxml2's fetching...

Anyway, some default files ( original.xml ) need to be included in the base distribution anyway,

And the DTDs it uses.

becasue AA should run on boxes without internet connection,

exactly.

and because the automatic download service should be optional in the end ( for people with paranoia ).

Maps are just one resource, so manual fetching may be possible. However, as we add resources, it would soon become unmanageable. Hence why I'm moving toward having the cache be similar to a web browser cache-- not meant to be touched by users.

I think original.xml and the dtd should be in CVS.

I think they should be included with the distribution, which doesn't necesarily mean in CVS... Perhaps I should find a way to tag a version onto format-cvs.dtd or something...

[philippeqc]

and because the automatic download service should be optional in the end ( for people with paranoia ).

Maps are just one resource, so manual fetching may be possible. However, as we add resources, it would soon become unmanageable. Hence why I'm moving toward having the cache be similar to a web browser cache-- not meant to be touched by users.

And on that point I dissagree from Luke's view. I think user will like to know what files they have, and download the latest maps on their own for local play. So it should be a "browser cache" but a "ressource repository with automatic fecthing capacity". IIRC, thats how Quake, Quake 2 and Half-Life worked. (or maybe only one of them...)

-ph

[Luke-Jr]

and because the automatic download service should be optional in the end ( for people with paranoia ).

Maps are just one resource, so manual fetching may be possible. However, as we add resources, it would soon become unmanageable. Hence why I'm moving toward having the cache be similar to a web browser cache-- not meant to be touched by users.

And on that point I dissagree from Luke's view. I think user will like to know what files they have, and download the latest maps on their own for local play. So it should be a "browser cache" but a "ressource repository with automatic fecthing capacity".

I see your point when you bring up local play this time... maybe there are no servers with it loaded
I'll ponder a good way to do this w/o compromising the existing features/setup.

IIRC, thats how Quake, Quake 2 and Half-Life worked. (or maybe only one of them...)

WTF? lol
I actually play Quake. It just has a ZIP with all the data in it renamed to pak0.pak (basic data) and pak1.pak (registered data)...

[philippeqc]

IIRC, thats how Quake, Quake 2 and Half-Life worked. (or maybe only one of them...)

WTF? lol
I actually play Quake. It just has a ZIP with all the data in it renamed to pak0.pak (basic data) and pak1.pak (registered data)...

no no, all the skins and models extras. Not the core data.

-ph

[Z-Man]

IIRC, thats how Quake, Quake 2 and Half-Life worked. (or maybe only one of them...)

WTF? lol
I actually play Quake. It just has a ZIP with all the data in it renamed to pak0.pak (basic data) and pak1.pak (registered data)...

Yes, and if you want to install a mod/extension, it also comes as a .pak file you just drop into the folder and delete when you no longer want it. You could also unzip the .pak files and have their contents directly on the HD. Additional content, like maps and skins, when automatically downloaded, would just be put somewhere on your harddisk with its original filenames, and you had full control over it ( deleting what you no longer wanted, adding new stuff, ... ). At least, that's how Q2 worked, the only game of the three mentioned that I played extensively enough to get in touch with mechanisms of this kind.

What's the deal with the DTDs anyway? Won't each version of AA have a finite set of supported DTDs we can include in the distribution? Users and mappers are not supposed to change them, right? ( Note that I'm a complete noob when it comes to XML. ) From what I gather by one of Luke's posts, libxml fetches stuff from the net all on its own. Do we want that?

[Luke-Jr]

IIRC, thats how Quake, Quake 2 and Half-Life worked. (or maybe only one of them...)

WTF? lol
I actually play Quake. It just has a ZIP with all the data in it renamed to pak0.pak (basic data) and pak1.pak (registered data)...

no no, all the skins and models extras. Not the core data.

There are no "extras". Quake has fixed data.

[Lucifer]

What's the deal with the DTDs anyway? Won't each version of AA have a finite set of supported DTDs we can include in the distribution? Users and mappers are not supposed to change them, right? ( Note that I'm a complete noob when it comes to XML. ) From what I gather by one of Luke's posts, libxml fetches stuff from the net all on its own. Do we want that?

What you'll probly want is what Mozilla did. They released the DTD for XUL with the application and gave it a URI that the program just understood it had to search a local path to find.

DTD's are only useful for a validating xml parser. If you don't need validation, you don't need a DTD. I haven't been watching that carefully, but it doesn't look like we need a DTD, unless ph's got something up his sleeve he hasn't mentioned (possible, he's flaky sometimes ).

Anyway, all the DTD does is tell the parser what tags are supported, what attributes each tag supports, and what the tags should contain, for whatever revision of the DTD you're using for your document. That's how browsers know how to deal with the tags you use, for example. There's a standard way a browser is expected to behave with each tag, for each revision, and the way may change with each revision. That's why it's so much harder to make a webpage without specifying a doctype, because each browser deals with the page differently than otherwise. The HTML doctype is a specific type of DTD, for xml the DTD is more general in nature.

[Luke-Jr]

What's the deal with the DTDs anyway? Won't each version of AA have a finite set of supported DTDs we can include in the distribution?

Yep. But if not all the functionality is "wanted", we can have a DTD for *supported* functionality and let people add unsupported stuff to custom DTDs... For example, the current code will support <line startx= starty= endx= endy= /> and <rectangle ... />, but last I talked to ph, he didn't want such things officially, so they might require an unofficial DTD to access/use.

Users and mappers are not supposed to change them, right? ( Note that I'm a complete noob when it comes to XML. )

Generally, right...

From what I gather by one of Luke's posts, libxml fetches stuff from the net all on its own. Do we want that?

The question is more of: *can* we override that?

[Z-Man]

Thanks, Luci. That's what I was aiming for.

Luke: Then we'd distribute two DTDs, one official and one that allows the stuff that works, but is experimental or transitional.

Libxml should have an option somewhere that tells it "no matter what you do, don't fetch any files from the net". We don't want to have maps or any other content that "phones home" or downloads possibly illegal material to the user's PC anyway, right? So this would be a good option to activate independently of the DTD issue.

[Luke-Jr]

Luke: Then we'd distribute two DTDs, one official and one that allows the stuff that works, but is experimental or transitional.

All the stuff *works*... ph just doesn't like it =p

Libxml should have an option somewhere that tells it "no matter what you do, don't fetch any files from the net".

... and give up? I'd rather it fetch the files.

We don't want to have maps or any other content that "phones home" or downloads possibly illegal material to the user's PC anyway, right?

The server can already do that by fetching the map... I would hope server admin checked the map to be sure it's ok first

So this would be a good option to activate independently of the DTD issue.

No, because we want to fetch the stuff anyway. We just want to cache it also.

[philippeqc]

Fixed more of my local copy of the code tonight. Many periferical items still missing.Havent had time to check the latest commit .ETA this weekend or next week. Status: Do NOT merge!

-ph

[Z-Man]

Luke: Then we'd distribute two DTDs, one official and one that allows the stuff that works, but is experimental or transitional.

All the stuff *works*... ph just doesn't like it =p

A small misunderstanding. I'll rephrase slightly:
Then we'd distribute two DTDs, one official ( allowing the stuff ph likes ) and one inofficilal ( that allows the stuff that works, but is experimental or transitional or is disliked bt ph for some other reason ).

... and give up? I'd rather it fetch the files.

How would that have any chance of success? I don't understand. Please point out the flaw in the following logic ( add "probably" or "likely" before every sentence since the reasoning is only heuristic and not 100% conclusive )
1. DTDs describe what the source code is able to parse and are used for validation
2. We'll have DTDs in the distribution for all document types the version is able to parse
3. Assume we downloaded a map file that uses a DTD not available locally
4. because of 2, that means the map ( assuming the mapper did not use a more complex DTD than required ) can't be parsed by the running source
5. the map file won't work.

I'd consider trying to use a map file with an unsupported DTD an error just like a parsing error. You certainly would not suggest to continue on a syntax error.

Of course, 2. is an assumption. I think we definitely want to control the DTDs, because the DTDs are a part of AA. Who, if not the developers, knows how a DTD should look? An alternative to putting everything into the distribution would be to make all DTDs available for download on some place we control, and tell libxml to only fetch them from there.

At least, additional downloads by libxml should be a user controllable option. My vote would go to turn it off by default.

I would hope server admin checked the map to be sure it's ok first

Assume the map is OK, but it triggers another download within libxml ( It appears only DTDs are fetched ). At the time the admin checks that, it is OK too. Later however, it gets changed to something else that is either illegal or exploits a ( hypothetical ) security hole of libxml or AA. ( The map and its hash stay unchanged. ) If we generally allow automatic downloads by libxml, we're prone to this attack.

No, because we want to fetch the stuff anyway. We just want to cache it also.

You want that. We haven't decided this yet.

[philippeqc]

Hi,

quick status

Your-mom and Luke-jr principally, but everybody else:
I just corrected some small mistakes in the dtd. The principal being Axis elements in the Axes elements. More descriptive than the Point element that was there, and support also "angle" rather than only x and y. But Point will still work for a while.

Luke-jr:
About the ressource management, I might have damaged it a bit with my clumsy fingers while relocating bits that really annoyed me. Sorry. Can you have a quick sanity check on it.
O and move cachedGet and createFolder in a to be created src/tools/tRessourceManagement.cpp.

all:
Still need to have the makefile set up dtd in the ressource folder. But will all the talks about restructuring the ressource bit, I dont know anymore where to put it. So directly under ressource until a concensus is reached (and it wont happen on this branch anyway). That and the validator like to have it in "./" :(

There will be 2 dtd. One core, one "transitional/experimental". I was thinking map-format.0.1.dtd and map-format.0.1-exp.dtd. Post your objections. I'll have to fix up some maps (your-mom, luke and mine) for this change in the dtd name, but the lack of description of "format.0.1.dtd" has been raised a bit too often, so be prompt about your objections to the new names.

Are degrees clockwise or counterclockwise? I think I just "patched" the code so they are clockwise.

Once that is completed, my expectations will be acheived and you will have my automatic go for merge. Anyone else who has some stakes in this should advertise them, Luke is itching to merge!

-ph

edit:oups, edited a lot. sorry

[Luke-Jr]

About the ressource management, I might have damaged it a bit with my clumsy fingers while relocating bits that really annoyed me. Sorry. Can you have a quick sanity check on it.
O and move cachedGet and createFolder in a to be created src/tools/tRessourceManagement.cpp.

ok, so this is probably my fault for being totally weird and all... but *please* at least spellcheck filenames XD

Are degrees clockwise or counterclockwise? I think I just "patched" the code so they are clockwise.

They are based on rotating clockwise from x=1 y=0. This seems logical from a mathematical standpoint, but I don't have any objections if the consensus thinks they should start at x=0 y=-1 or something...

Once that is completed, my expectations will be acheived and you will have my automatic go for merge. Anyone else who has some stakes in this should advertise them, Luke is itching to merge!

I'm also waiting on a 'autoconf;./configure;make' being OK to a running setup.

[Z-Man]

Actually, mathematicians usually measure angles counterclockwise. But its important here what the users prefer, so clockwise is allright. If I remember correctly, gCycle::Turn(1) would turn the cycle clockwise, so even internally, I don't follow mathematic conventions.