Recoding old stuff...

Buggi · Post by **Buggi** » 01 May 2005, 02:46

Okay, I'm tired of all the HPI utilities out there that install "for windows 98"... OY! This crap has to be updated.

SO! As a coder and one who loves this sort of crap I'm going to make an effort to re-code as much as possible (using C# and XML config files). That includes HPI packers, viewers, and editors, GAF editors, FBI editors, and BOS files. Currently not planning the 3do overhaul yet because that's a major project and the one that's available installed fine on my XP machine...

FAR to much VBness for my nerves to handle. *twitches*

I would appreciate it if others out there could HELP me by finding and posting or emailing me SPEC's of files, HPI specs to start :)

Why aren't any of the existing programs open source? ├é┬¼_├é┬¼

I emailed the dude that did the Conflict Crusher, but haven't heard a peep yet. :-/

-Buggi
(on a mission)

PauloMorfeo · Post by **PauloMorfeo** » 01 May 2005, 03:10

Buggi wrote:... (using C# and XML config files) ...

That is not very other-OSs-friendly...
MacOS X doesn't have any compiler for C# that i know of and Linux has a C# compiler but the .NET framework is mostly not done yet...

Dave · Post by **Dave** » 01 May 2005, 03:59

As I'm currently attempting a port of TAspring to linux, I'm strongly opposed to your language choice. C# will make the project depend on a proprietary technology that is only partially available outside of windows systems. The TAspring client is already in C#, and I'm probably going to have to rewrite it to get something running in linux. If any more core parts of the project start using this language, I'll probably drop the idea of getting a working port running.

Other than that though, I'm all for rewrites. The HPI Utility library we're going to have to rewrite in a portable fashion anyway, and there are some other sections of the code that'll need that too. So rewriting this as a part of the general development, if done portably, will actually help making taspring cross platform.

Buggi · Post by **Buggi** » 01 May 2005, 04:16

For linux and .NET... see the Mono project. For mac's... get a PC

What did you all do with all the existing utils? They all use some flavor of VB (like the 3dobuilder)

Don't start yelling about portablity now, especially when the dev-base is so small. I write what I know.

C# is a fantastic language and there are plenty of open source items out there. http://www.icsharpcode.net/ for example :)

Dave · Post by **Dave** » 01 May 2005, 04:32

Buggi wrote:For linux and .NET... see the Mono project. For mac's... get a PC

Mono has a C#1.0 compiler working. The C#2.0 compiler is still under development, and I reckon performance is greatly suboptimal compared to what C#.Net in windows can do. Also, note that while the C#1.0 compiler is up, the .Net framework (if you intend on using it that is) is largely incomplete, and that some parts of it will remain windows-only because of software patents that microsoft has that hinder proper cross-platform support.

Don't start yelling about portablity now, especially when the dev-base is so small. I write what I know.

So do I. Do you feel I'm wrong yelling about portability, when I offered to attempt a linux port only a few days ago? If I have to rewrite half the codebase to get anything working, and that most of the remaining code has awful performance because the only tools capable of getting good performance are for windows, I might as well drop the idea right now.

C# is a fantastic language and there are plenty of open source items out there. http://www.icsharpcode.net/ for example :)

I don't want to get into a language holy war. My objections to C# are based on its current portability state (which is not as good as it could be), not on any language-specific merits. If C# is more convenient for the dev team, and that I'm in a minority, then so be it, I'll just have to wait for complete language support in linux (or let someone more able than me at C# do the port) before playing TAspring.

Dave · Post by **Dave** » 01 May 2005, 04:39

Oh, and regarding your question about HPI: I did find the released source code for HPIutil, the utility library that allows reading HPI files. It's a little convoluted, but you could probably extract some sort of spec from that code.

http://www.tauniverse.com/joed/

[K.B.] Napalm Cobra · Post by **[K.B.] Napalm Cobra** » 01 May 2005, 04:40

I say C++.

AF · Post by AF » 01 May 2005, 04:42

I see an easy solution to HAPI archive traversal, instead of havign the 2 utilities hpiview and hpipack or the recent HPIReplace, why not have somethign along the liens of a WinRAR dll? You ahve the interface built for you and its used for numerous other archive formats, and it's already wide spread, just drop a dll in and assign file extensions to winrar or whatever archive package you use.

As for other tools, perhaps if you bundled the lot of them into a single program, somethign like Spring Dev Studio, I can just see somethign with an interface like a macromedia product with a GAF viewer/editer 3D0 builder replacement and a map editor all integrated into eachover, run a script on a model while your building it, test the model on a map you're making, change textures and mix and match!

whoa I've gotten carried away.

But dont do it in C# or vb.net.

Aside from the fact a lot of people dont know what the .Net framework is and cba downlaoding and installing no matter how easy ti is. Not to mention how annoying ti si for those who've just downlaoded this thign to fidn they need to downlaod soemthign else.

Tryusing C++ or better yet make it a personal project to venture into x86 asm.

Buggi · Post by **Buggi** » 01 May 2005, 05:21

Alantai:
Before I take your advice, please start proof-reading your posts.

The more readable they are the more merit I put on your opinion.

Dave:
I found that page after a little digging, unfortunatally in his hpiutil source he includes hpiutil.dll, yet another layer that wasn't sourced out. Now I found version 1.4 of the hpi file format document and am currently combing over it for help with the conversion.

Needless to say, it's much easier converting C# code to a linux based system than it is machine code :D And C# code can be reflected to MC++ code using Lutz's reflector.

[K.B.] Napalm Cobra · Post by **[K.B.] Napalm Cobra** » 01 May 2005, 05:40

Before I take your advice, please start proof-reading your posts.
The more readable they are the more merit I put on your opinion.

Ahh, asking alantai to proof read his posts, the unmistakable sign of a spring forum n00b.

AF · Post by AF » 01 May 2005, 05:40

meh, It takes me ages to type the posts and then when I do proof read them i get told to proofread and then my time runs out, pfft...

Ace07 · Post by **Ace07** » 01 May 2005, 06:50

I say C++ simply because its easily portable. I am all for portability. (if you want to get more people from the open source community into this, you need Linux/Mac versions of the game)

Post by SJ » 01 May 2005, 08:42

Why bother with the whole HPI bussiness at all, we mostly choose to include it for easier compatibility with older mods. If someone integrate 7zip into the filehandler beside hpiutil we will migrate our files to that for the next version and mod authors can choose whatever format they like.

Buggi · Post by **Buggi** » 01 May 2005, 08:59

Good point

Filehandler?
<.<

Someone else *pokes Dave* can handle the C++ portion of it, the SDK should be easy enough to port.

I'll work on a front-end using the sweet C# SDK they released. :D

zwzsg · Post by **zwzsg** » 01 May 2005, 14:16

You may be interested by this page:
http://visualta.tauniverse.com/HTML/Formats.html

Contains all technicals info on most TA files format.

Dave · Post by **Dave** » 01 May 2005, 14:34

Fair enough, 7zip it is then.

Buggi · Post by **Buggi** » 01 May 2005, 17:41

*high fives Dave*

Alright :D

I've already started on a 7zip front end. My FIRST goal is to load files and crush conflicts :)

I was thinking of appending a 7 on the regular extensions.
Like bigname.ufo7 or superspring.ccx7

Thoughts?

Dave · Post by **Dave** » 01 May 2005, 18:05

Right now I'm more in the process of ripping out all the MSVC specific pragmas and declarations from the code and getting some form of compiler/platform detection (and corresponding strangeness declaration in MSVC's case). I won't be in a position to do anything on the HPI utilities before I've finished getting TAspring to compile in MingW (gcc for windows), which is, like, a long way away, seeing how I have to alter each and every .h and .cpp file to remove anything MSVC specific

As for the extensions, don't 7zip define any extensions for the format? If they do, why not use those? It'll make any archiver capable of reading the format recognize it, and avoid introducing Yet Another File Extension(tm).

If they don't define any extensions, I don't really mind which extension is used, it should be an easy variable if we do make the wrong choice.

Oh, btw, just to set things straight in case they aren't: I'm not in the official dev. team, I just volunteered to port the stuff to linux. So while you *will* see me shout whenever you're trying to do something difficult to port

, I don't have any authority to decide things for the project.

*goes back to hacking taspring-linux* Only sth like 400 files left in rts alone

zwzsg · Post by **zwzsg** » 01 May 2005, 18:24

I still think that coding something to make Spring able to handle .gaf would be very useful. It would make any mod or unit with custom textures work straight away. Thousands of units and countless mods to tap in. The current method of having to extract .gaf into correctly named .bmp is too much work for the average joe that just want to play with new units d/led from dead TA sites.

Ace07 · Post by **Ace07** » 01 May 2005, 18:28

I kind of agree with Dave on this one. Maybe its time we finally make just one file extension for TA Spring? Or two to distinguish maps from file packages.

*.sp7 (Spring7) would store files in the 7zip format. *.spm (Spring Map) would be for maps. I kind of like that better than the multitudes of formats that the older TA engine uses.

Spring RTS Engine

Recoding old stuff...

Recoding old stuff...

Re: Recoding old stuff...