View topic - HPI version 3 diagram


All times are UTC + 1 hour


Post new topic Reply to topic  [ 57 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject:
PostPosted: 16 May 2005, 12:49 
User avatar

Joined: 15 Dec 2004, 20:53
Location: London
I'm not sure that i'm understanding properly what the HPI3 file is suposed to do but, couldn't code from OpenOffice.org be used?
After all, a units set seems to me like some form of spreadsheet (like in MsExcel). They are just fields like UnitName, UnitHP, etc and they're corresponding values.

OpenOffice.org is LGPL, is very solid, runs on many platforms, etc. We can add more than text into the spreadsheet's cells so, i don't think it would be hard to add the units textures, scripts, etc, fields into the spreadsheet file.
And it would be the OpenOffice.org's code to handle file access and storage.

And if the new file system for storing the units set was literally .scx (OpenOffice.org's spreadsheets format), it would be really easy to go edit stuff...
Like Subdino said, there is no need to not reuse code. Especially if it is code that is proven to be good.

What do you think?
Top
 Offline Profile  
 
 Post subject:
PostPosted: 16 May 2005, 15:38 

Joined: 26 Aug 2004, 07:11
Location: Virginia Tech
wouldn't call OO's code proven to be good :)

-- yet still has it installed, and curses quite often at it
Top
 Offline Profile  
 
 Post subject:
PostPosted: 16 May 2005, 16:16 

Joined: 15 May 2005, 07:44
Location: France
PauloMorfeo wrote:
on my Fat32 file system, it takes 119MBs out of my HDD


That's a FAT32 (and a windows) weakness.
And because of that weakness, you, coders, have to build your own workarounds, and somewhat reinvent the wheel beter than those microsoft big brains thought they had. Sadly you can't add a new filesystem support under windows as easily as it can be under linux (there are about 30 filesystems supported under linux, some - maybe most - read-only like ntfs, each designed for a special purpose, from interoperability to technical reasons ).

(The discution might be somewhat ideological now... I'll try to refrain myself from making that forum a unix-vs-others discution :-) )

To stick with the subject, I would say that (multiple file) archives are filesystems too, so they could also circumvent that FAT32 problem. For example TAR can be seen as a tape filesystem (Tape ARchiver), and ZIP multivolumes as a JBOD (Just A Bunch Of Drives, a way to use many HDDs as if they were one) & compressed filesystem - but those two are read only, modifying one file requires rebuilding the whole archive.
Top
 Offline Profile  
 
 Post subject:
PostPosted: 17 May 2005, 06:11 
User avatar

Joined: 29 Apr 2005, 06:46
Oh, this thread is SOOO not going to become a windows vs. the world flame war.

Good god all I did was post the HPI3 format!!

YES a new format is needed. The old format was 7 years old, used horrid compression and wasteful encryption. So I stepped up and finalized a format and am well on the way to completing the format.

Who gives a rats ass about what this compression does over that one. Everything is compressed. A 3do file is nothing but a series of vertices and faces in one file, you could store all those as separate files, just single one byte files for each vertex. But they're combined into a file format and compressed.

As for PNG and PCX. I thought I made it known I hate PCX. And, for the record, PNG uses LZ compression (Read: zlib). If we had more dev's on the project I'd request they work on including PNG support into Spring right now so when HPI3 is done the transition will be smooth.

-Buggi
Top
 Offline Profile  
 
 Post subject:
PostPosted: 12 Jun 2005, 11:09 
User avatar

Joined: 26 Apr 2005, 23:00
Location: The Netherlands
Just a stupid question of mine, but what's the advantage of the new HPI 3 header structure over just adding a LZMA (7zip's compression) (or other)compression flag and removing the encryption? IMHO that would make both conversion and 'upgrading' of current tools possible or a lot easier.
Top
 Offline Profile  
 
 Post subject:
PostPosted: 12 Jun 2005, 19:57 
User avatar

Joined: 29 Apr 2005, 06:46
The more I've thought and worked at it the more I think it would be a good idea to wrap a plain zip file (7z or zip, whatever) up as HPI3. Building and maintaining the "directory" has turned out to be a total nightmare. With the structures already built in opensource I see no benefit to re-inventing the wheel.

I thought back to Doom 3 files. All you needed to do was rename the extension to .zip and unzip them. So I figure, lets go for it.

The first two characters in the file tell you what format it is. "PK" for zip and "7z" for a 7zip etc. So all the loader would need to do is look at the first two letters and determine the type of archive it's looking at and treat it that way.

Half the battle was getting the existing HPI format to load, and I've already got that done. Saving it out as a single zip or 7zip shouldn't be too tough.

-Buggi
Top
 Offline Profile  
 
 Post subject:
PostPosted: 12 Jun 2005, 20:27 
User avatar

Joined: 26 Apr 2005, 23:00
Location: The Netherlands
That's also a good solution, would be nice if you could make it so that you indeed can just rename it and load it into your favorite zip / 7zip program.
Top
 Offline Profile  
 
 Post subject:
PostPosted: 12 Jun 2005, 20:35 

Joined: 01 May 2005, 22:09
Location: MI, USA
What about:
http://icculus.org/physfs/
?
(ps I am for zip files too)
Top
 Offline Profile  
 
 Post subject:
PostPosted: 13 Jun 2005, 02:30 
User avatar

Joined: 29 Apr 2005, 06:46
ICSharpCode and sourceforge provide all we need to access zip and seven zip archives.

Now it's time I write up the classes to support FBI, TDF, and Weapon files.

I want to change the extensions of the files to be more accurate to what they represent, I know they're all text files, but yikes, lets use file extensions.

Units before was FBI... anyone know what this stood for? IMHO it should be .unit

Weapons, download, features, and gamedata all use TDF... horrible!!
.wep
.menu
.feat
.gdata
respectivly

All text files could have an XML equivalant for further integration with new technology and those files can exist next to their old format with "x" appended onto the extension.

So for example, ARMFARK.unit and ARMFARK.unitx

Scripts can stay BOS and COB... Unitpicts should be PNG files, period. Gui's are fine, as are models. And since Spring doesn't support GAF files, we don't have to worry about them :D thank god!

For those people in outrage about XML, settle, text takes up about 2% of the actual HPI file, the rest goes to sound, models, and textures.

:-)

-Buggi
Top
 Offline Profile  
 
 Post subject:
PostPosted: 13 Jun 2005, 02:48 
User avatar

Joined: 16 Aug 2004, 03:36
Location: The Steward's Realm
We're not worried about the size of the XML files in terms of HD space, we are worried about its literal utility. Try having made units for the past six years, then have someone tell you that their way is better just because they said so, even though they have no experience actually using the format and such. Its somewhat aggravating to see you consistently misrepresent our position to yourself and others.

In short: Please no XML. And if you do make it XML, please be fully aware that either myself or someone will modify the source code or add some sort of additional layer to make units creatable in the old style, with the program handling the conversion to your XML format.
Top
 Offline Profile  
 
 Post subject:
PostPosted: 13 Jun 2005, 03:38 
User avatar

Joined: 29 Apr 2005, 06:46
You think I'm new to unit design? No way. I've been knee deep in TA since it was released. I've never taken the public face I've taken with Spring though.

The XML will be transparent to the user. It's just for the ability to transfer and combine information in the core program. The old format will still be supported. And I in no way intended for it to sound like the "better" way, just different and new.

And you never know, you may like it once your used to it. ;)

Then again, maybe not... :shock:

-Buggi
Top
 Offline Profile  
 
 Post subject:
PostPosted: 13 Jun 2005, 03:54 
User avatar

Joined: 16 Aug 2004, 03:36
Location: The Steward's Realm
Well, if its backwards compatible, that's cool.

And like i said, i have tried it... that DTD i made was quite thorough. When i sat down to actually write a new unit .fbi in that format, i quickly realized what a monumental waste of time that was... it was simply a timewasting, inefficient method.
Top
 Offline Profile  
 
 Post subject:
PostPosted: 13 Jun 2005, 10:31 
AI Coder
User avatar

Joined: 14 Sep 2004, 10:32
Location: Cookieland
I think that if xml is supported then why should a units data be spread across numerous files? Have a single file ending with something like .unt and then inside there'll be the unit data build menu stuff weapons etc.
Top
 Offline Profile  
 
 Post subject:
PostPosted: 13 Jun 2005, 15:47 

Joined: 13 Jun 2005, 15:37
Zip file with plain file structure inside, and xml files, it's the Java(tm) way! :)
That's exactly how Java .jar files work, and it's show to be a good idea ;)

I approve ^_^

The one thing I wonder (I don't know, and too lazy to check ;) ) is if there's any good (L)GPL libraries to read/write zip files, and if there is any patent/copyright/etc. on zip files.

Besides that, this really is a very practical and simple format, easy to work with (just use your favorite zip/unzip tool).

An advantage is it becomes a lot easier to make the game so it can easily switch between running directly from the filesystem (the contents of a zip, but unzipped, ideal for when you're creating a mod etc.), or running from a compressed data file.

my 5ct :)

Cheers.
Top
 Online Profile  
 
 Post subject:
PostPosted: 13 Jun 2005, 17:11 

Joined: 01 May 2005, 22:09
Location: MI, USA
cranphin wrote:
any good (L)GPL libraries to read/write zip files

Yes.
Top
 Offline Profile  
 
 Post subject:
PostPosted: 13 Jun 2005, 20:31 
User avatar

Joined: 29 Apr 2005, 06:46
Alantai Firestar wrote:
I think that if xml is supported then why should a units data be spread across numerous files? Have a single file ending with something like .unt and then inside there'll be the unit data build menu stuff weapons etc.


Wow, I actually agree with you on something @_@;;
Top
 Offline Profile  
 
 Post subject:
PostPosted: 13 Jun 2005, 20:41 
AI Coder
User avatar

Joined: 14 Sep 2004, 10:32
Location: Cookieland
=?

of course you could always try putting an entire mod in a file.

I wonder would it be possibl to add formulae as such to such a file as values so that newly built unit stats changed in different conditions as time goes on or depending on the map? Might be useful for some instances.Or the use of inheritance or deriving units from other unit definitions to save space
Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 57 posts ]  Go to page Previous  1, 2, 3

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Site layout created by Roflcopter et al.