HPI version 3 diagram
Moderator: Moderators
- PauloMorfeo
- Posts: 2004
- Joined: 15 Dec 2004, 20:53
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?
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?
-
- Posts: 436
- Joined: 26 Aug 2004, 08:11
That's a FAT32 (and a windows) weakness.PauloMorfeo wrote:on my Fat32 file system, it takes 119MBs out of my HDD
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.
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
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
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
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
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
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
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.
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.
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...
-Buggi
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...
-Buggi
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.
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.
=?
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
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