Am Mittwoch, 29. November 2006 11:42 schrieb Giel van Schijndel:
> Fearthecute schreef:
> > Per Inge Mathisen schrieb:
> >> On 11/28/06, Fearthecute <[EMAIL PROTECTED]> wrote:
> >>>
> >>> >>> />
> >>> >>> x="4" y="1" textureID="19" textureAlign="2" height="129" />
> >>
> >> ...
Am Mittwoch, 29. November 2006 14:58 schrieb Giel van Schijndel:
> Christian Vest Hansen schreef:
> > I doubt that the size of the XML files is any issue. I think you'll
> > find that once stored in the zip-compressed .wz format, the XML files
> > will be reduced to half-size or less.
>
> Size will
2006/11/29, Giel van Schijndel <[EMAIL PROTECTED]>:
The only comment I've got on your XML-file is the inconsistency in
notation of . Both ZNULLREPAIR and LightRepair1 are of
level ALL, for the first you simply write it down as ALL, for the last
you use the number -1. I'd use numbers for all of th
Christian Vest Hansen schreef:
> If we decide on XML, at least do it right ;)
>
> I've attached a version of repair.xml that have been refactored to the
> way *I* think it should be structured. What's not visible is the link
> to the XSD Schema that defines the structure of this particular XML
> fo
PS.
I doubt that the size of the XML files is any issue. I think you'll
find that once stored in the zip-compressed .wz format, the XML files
will be reduced to half-size or less.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/li
If we decide on XML, at least do it right ;)
I've attached a version of repair.xml that have been refactored to the
way *I* think it should be structured. What's not visible is the link
to the XSD Schema that defines the structure of this particular XML
format: the tree-structure, including the v
Fearthecute schreef:
> Per Inge Mathisen schrieb:
>
>> On 11/28/06, Fearthecute <[EMAIL PROTECTED]> wrote:
>>
>>>
>>>
>>>
>>>
>>>
>>>
>> ...
>>
>>> This produces MUCH overhead and will increase the filesize by n^4 or
>>> whatever...
>
Binary isn't bad.
Why not create a ASCII (or even xml... ... ... "...") for uncompiled
maps. Which can be edited.
And then create a small compiler which can compile this maps to a binary
format?
Regards, Kamaze
Per Inge Mathisen schrieb:
> On 11/28/06, Fearthecute <[EMAIL PROTECTED]> wrote:
>>
>
On 11/28/06, Fearthecute <[EMAIL PROTECTED]> wrote:
...
This produces MUCH overhead and will increase the filesize by n^4 or
whatever...
Incidentially, I made a patch to save map files in the LND format, and
file sizes for maps increased to 300k fo
Fearthecute schreef:
> Giel van Schijndel schrieb:
>> I wouldn't mind seeing special purpose scripts written in Lua. Whenever
>> your just storing data and describing object properties (which is just
>> about all that is being done in data/stats/*.txt AFAIK) though I think
>> XML is much more intu
>
>
> 1 1 17 2 128
> 2 1 16 1 128
> 3 1 12 1 128
> 4 1 19 2 129
> ...
>
>
http://thedailywtf.com/forums/thread/102936.aspx
*g*
pgp1gLLlK5ubS.pgp
Description: PGP signature
___
Fearthecute schreef:
> Giel van Schijndel schrieb:
>> I wouldn't mind seeing special purpose scripts written in Lua. Whenever
>> your just storing data and describing object properties (which is just
>> about all that is being done in data/stats/*.txt AFAIK) though I think
>> XML is much more intui
Because XML is a buzzword, xml is NOT good for everything.
Its a markup language for a static tree-like definition list.
And not for data storage...
And where do we have a tree-like static definition?
How do you want to use it?
~
...
~
This
Dennis Schridde schreef:
> Am Dienstag, 28. November 2006 13:22 schrieb Giel van Schijndel:
>
>> Gerard Krol schreef:
>>
>>> I vote for XML. It is really easy to get a good parser from somewhere,
>>> and writing your own "language" always turns out to be far more work
>>> than you expected.
14 matches
Mail list logo