WZ Redemption fork, question for the admin

[vexed]

DirectX

With limited manpower I can see why this project decided to take out DX and go OpenGL only, but I want to (eventually) run both. Plus there are directions I want to go that this project would not be able to or want to follow. First off is changes to the scripting engine. I want to rip out the old engine and put in something like that used in Neverwinter Nights. Another item I want to explore is skinable GUI as well as deformable terrain (partially there in retail, but mostly only for leveling terrain during structure building).

No, that was not the reason.
The project went to openGL since it was cross-platform, and DX isn't.
Taking a quick look at SF, I see you are going the LUA route. Nice choice.
Deformable terrain will be quite difficult if you want to do it correctly.

Recently I found an MPQ clone (StormLib) that I would also like to explore as a variation to use instead of WDG (retail) or WZ (this project). Besides, as a primarily windows build perhaps it will bring back some of the community lost when it was originally decided to go cross platform. And as stated, maybe there will be some good ideas that can be brought into the wz2100.net fork, in addition to my eventual work of getting DX into the fork for those poor intel folks who will probably never see a proper OpenGL driver.

I don't understand this move at all. Why would you not want to use wz (aka zip files) ?
I also fail to understand why you wouldn't pick up from where Chojun's codebase was left at (or are you?). I don't even know why the source wasn't released 'as is', it has been a very long time with no activity at the SF site.

As for the other part...

Anyway, forks are healthy in the FOSS lifecycle as they provide alternate ideas that can be incorporated into any/all other forks.

It is only healthy if it is managed correctly. Otherwise, it is wasted resources.

Anyway, besides what the others have said, the game needs to be made 64bit clean again, deterministic, redo network code (client/server), and on and on... which is fine if you have motivated people helping out, but if you don't have enough people, then it becomes quite tedious and boring as well.

I am trying to get the code up on git/svn using 2010 but may have to settle for 2008 as 2010 does not like the lex/yacc codes so far and I haven't had a chance to see why after adding in the flexbison.targets from this projects devpkg it keeps giving me "exited with code -1" But, everything in due time.

Attach the build logs, it should tell you why.

BTW, MS now is going to release a C++ compiler for VS2012, so all the bad feedback they got worked.

[Lord Apocalypse]

DirectX *snip*

No, that was not the reason.
The project went to openGL since it was cross-platform, and DX isn't.
Taking a quick look at SF, I see you are going the LUA route. Nice choice.
Deformable terrain will be quite difficult if you want to do it correctly.

I know that, but no manpower to keep both running up to date (as I have sadly told myself I will do)

Recently I found an MPQ clone (StormLib) that I *snip*

I don't understand this move at all. Why would you not want to use wz (aka zip files) ?

I have possible uses for it or something like it for Vega Strike. Plus the following...

Requirements

Fast access. It was necessary to access archived data as fast as possible, in realtime.
Compression. Blizzard decided to store sound files, including music, in the WAV format. Uncompressed size of these files is very large and archive must support a compression. Several compression methods are used to store data files within MPQ archives (PKWARE Data Compression Library, ZLIB, BZIP2, LZMA and SPARSE compression), together with Huffman and IMA ADPCM compression methods used for storing WAV files.

Expandability. Archive format must support later changes of the way how the files are stored in the archive. With new games released, the MPQ format is being extended. All the later changes are backward-compatible with older versions.

Multilanguage. Blizzard planned to release its games worldwide, in various language versions. The archive format must support storing multiple files with different languages.

MPQ archives can either be a standalone file, or can be appended to the end of another file, like an EXE file. Game patches are self-extracting MPQ archives. For more information about format of MPQ archives, see MPQ Format.

From a data standpoint the format (and from what I've browsed of WoW files) looks rather nice. Its worth learning IMO even if it doesn't actually get used (sticking to wdg or going wz). If you don't know anything about stormlib check it out. Can't hurt to learn something new

I also fail to understand why you wouldn't pick up from where Chojun's codebase was left at (or are you?). I don't even know why the source wasn't released 'as is', it has been a very long time with no activity at the SF site.

As for the other part...

I asked chojun about this and he says he will release it but didn't make any promises on how soon that would be. RL is a real kikcer

Anyway, besides what the others have said, the game needs to be made 64bit clean again, deterministic, redo network code (client/server), and on and on... which is fine if you have motivated people helping out, but if you don't have enough people, then it becomes quite tedious and boring as well.

So far? Just me and my overly ambitious dreams, though maybe if I'm lucky a few of the old timers will come back to help (we got strata back for what ever limited time he has for the old tools).

I am trying to get the code up on git/svn using 2010 but may have to settle for 2008 as 2010 does not like the lex/yacc codes so far and I haven't had a chance to see why after adding in the flexbison.targets from this projects devpkg it keeps giving me "exited with code -1" But, everything in due time.

Attach the build logs, it should tell you why.

Its the lex/yacc code not VC10. It complains about a section of parser.y found here:

Code: Select all

	/* value tokens */
%token <fval> FLOAT
%token <ival> INTEGER
%token <sval> TEXT
%token <sval> text
%token <sval> QTEXT			/* Text with double quotes surrounding it */
%token <ival> LOOP
%token <ival> ONESHOT

	/* types */
%type <sval> text

For reasons unknown to me (never used lex/yacc) with text defined under tokens it keeps spitting an error on %type text.

Code: Select all

E:\wztmp\Game\LIB\Gamelib>bison.exe -d -b parser -o parser.c -p parser  parser.y

parser.y:36.7-12: %type redeclaration for text
parser.y:30.15-18: previous declaration

Not sure what to think of it.. any ideas? I think if I remove all yacc references from parser_l.c I can compile w/o issue as I did in VC9.

BTW, MS now is going to release a C++ compiler for VS2012, so all the bad feedback they got worked.

Yeah I heard on the vegastrike forums. Looks like MS won't be able to shaft the little guy this time around .

As far as terrain goes.. WZ already has some terrain deformation when it flattens the ground for structure placement. It may be possible to expand on this for use with large bore artillery, mortars, and bombs to create some cratering and depending on how each tile stores its tileset information replacing it with a crater tertile texture or a decal. Still need to dig deep into the code to find out though.

There is a lot I would really like to see done in either rendition of WZ such as learning from Doom3 on setting up a good gui system sans SDL. At least I think there was no sdl there.. On the cross-platform front, it may be awhile be Redemption will run on anything other than windows. Guess it will really depend on how much of the work by this project I can cut n paste over and expect it to run with any major modifications (based on early 2.x work that it). I am still going over the early SVN commits at sourceforge so its too soon to tell.

On a side note, there is a movement to get the source code for NeverWinter Nights 2 released. Rman I think they might need your help! http://social.bioware.com/forum/1/topic ... /8126417/1

[aubergine]

Regarding terrain deformations, in debug mode you can press W or A to change height of the tile under the mouse cursor - tried it the other day in 3.1 branch and works fine. So if you can track down the code to handle those "cheat codes" then you'll be on your way to finding where the current deformation code is.

One other thing about a fork, it's not just the work to get that first release out... it's the ongoing work to keep new releases coming out on a regular basis that will make or break it. I recently started compiling a list of all WZ releases since 1999 and if you look at the number of releases by the WZP you'll see it's a staggering and ongoing achievement. Including master snapshots, WZP have made approx. 100 releases since August 2006.

[Rman Virgil]

.

Generally speaking I believe in Sturgeon's Law which states: "90% of anything is crap." But I do believe crap has value to the extent that you make a point of learning from it, gleaning valuable insights that are then applied pragmatically.

There are also exceptions to Sturgeon's Law - like da Vinci's body of work or, closer to home, Pumpkin's 11 releases in 5 months.

@ LA: NWNs would be 4nE's "baby".

@ vexed: Been talking to Cho about just that already.

.

[Rman Virgil]

.

It's a definite go. Source transfer details to be worked out soon.

In the interim I've given Chojun links to this thread and Strata's Tools thread so he can come up to speed on these proceedings.

Chojun worked on the source for years single-handed outta love for the game and deep conviction for its robust future. His career and growing family take up most his time but it is his hope that others will find value in this work going foward and continuing the journey of WZ's on-going development evolution.

That said, I will not presume to speak for him. He is more than capable of expressing his thoughts and convictions, in due course.

- Regards, Rman.
.

[vexed]

I have possible uses for it or something like it for Vega Strike. Plus the following...

Requirements

Fast access. It was necessary to access archived data as fast as possible, in realtime.
Compression. Blizzard decided to store sound files, including music, in the WAV format. Uncompressed size of these files is very large and archive must support a compression. Several compression methods are used to store data files within MPQ archives (PKWARE Data Compression Library, ZLIB, BZIP2, LZMA and SPARSE compression), together with Huffman and IMA ADPCM compression methods used for storing WAV files.

Expandability. Archive format must support later changes of the way how the files are stored in the archive. With new games released, the MPQ format is being extended. All the later changes are backward-compatible with older versions.

Multilanguage. Blizzard planned to release its games worldwide, in various language versions. The archive format must support storing multiple files with different languages.

MPQ archives can either be a standalone file, or can be appended to the end of another file, like an EXE file. Game patches are self-extracting MPQ archives. For more information about format of MPQ archives, see MPQ Format.

From a data standpoint the format (and from what I've browsed of WoW files) looks rather nice. Its worth learning IMO even if it doesn't actually get used (sticking to wdg or going wz). If you don't know anything about stormlib check it out. Can't hurt to learn something new

Speed isn't really a issue for wz, most files are quite small. I don't really see a need for a new proprietary format.

I am trying to get the code up on git/svn using 2010 but may have to settle for 2008 as 2010 does not like the lex/yacc codes so far and I haven't had a chance to see why after adding in the flexbison.targets from this projects devpkg it keeps giving me "exited with code -1" But, everything in due time.

Attach the build logs, it should tell you why.

Its the lex/yacc code not VC10. It complains about a section of parser.y found here:

Code: Select all

	/* value tokens */
%token <fval> FLOAT
%token <ival> INTEGER
%token <sval> TEXT
%token <sval> text
%token <sval> QTEXT			/* Text with double quotes surrounding it */
%token <ival> LOOP
%token <ival> ONESHOT

	/* types */
%type <sval> text

For reasons unknown to me (never used lex/yacc) with text defined under tokens it keeps spitting an error on %type text.

Code: Select all

E:\wztmp\Game\LIB\Gamelib>bison.exe -d -b parser -o parser.c -p parser  parser.y

parser.y:36.7-12: %type redeclaration for text
parser.y:30.15-18: previous declaration

Not sure what to think of it.. any ideas? I think if I remove all yacc references from parser_l.c I can compile w/o issue as I did in VC9.

What version of bison & flex are you using ?

As far as terrain goes.. WZ already has some terrain deformation when it flattens the ground for structure placement. It may be possible to expand on this for use with large bore artillery, mortars, and bombs to create some cratering and depending on how each tile stores its tileset information replacing it with a crater tertile texture or a decal. Still need to dig deep into the code to find out though.

Yeah, I know that, but one of the problems is, it has to be done on all clients as well...unless you aren't doing a network game ?

There is a lot I would really like to see done in either rendition of WZ such as learning from Doom3 on setting up a good gui system sans SDL. At least I think there was no sdl there.. On the cross-platform front, it may be awhile be Redemption will run on anything other than windows. Guess it will really depend on how much of the work by this project I can cut n paste over and expect it to run with any major modifications (based on early 2.x work that it). I am still going over the early SVN commits at sourceforge so its too soon to tell.

Hmm ? SDL has nothing to do with a GUI, besides at the very low level of keyboard / mouse input.
WZ's GUI is just a PITA to work with, and while they made many OO elements to it, it is missing basic things from it, that would make our life much easier.

On a side note, there is a movement to get the source code for NeverWinter Nights 2 released. Rman I think they might need your help! http://social.bioware.com/forum/1/topic ... /8126417/1

Now, that would be really nice, highly doubtful, but nice.

[aubergine]

Reading between the lines, I guess the proprietary format to replace .wz is more because of the ability to encrypt files, and ensure Redemption mods are incompatible with WZP's version of WZ, than anything to do with speed.

[Rman Virgil]

.

Just wanna be absolutely clear here.

Neither Chojun or myself have any interest whatsoever in commercializing WZ.

Chojun's work will be made public in a manner that would be best suited for the games on going evolution and we look foward to this project team giving us guidance in how exactly to that within the next couple weeks.

Thanks all for your consideration.

- Regards, Rman.

.

[Lord Apocalypse]

No, not for encryption. Everything will have a tool, same as the what we used makewdg for oh so long ago. Also its not about incompatibility, that is a given no matter what data format you use. To start with the scripting systems will be completely different. No javascript api for redemption, pure c like scripting. Though one main difference between retail wz script and mine will be that mine will be easier to use, closer to learning basic php (which is also c like). Simple to learn yet highly complex.

Hmm ? SDL has nothing to do with a GUI, besides at the very low level of keyboard / mouse input.

I thought it handled more than just mouse/keyboard. Not a full blown gui, but some elements to help build one. Maybe I was thinking of something else then...

latest flex and bison.

Yeah, I know that, but one of the problems is, it has to be done on all clients as well...unless you aren't doing a network game ?

Not too much info to send, or shouldn't be.

Speed isn't really a issue for wz, most files are quite small. I don't really see a need for a new proprietary format.

True enough, the videos are the largest files in warzone becides the binary (at least under windows). Thing is.. WRP went with PNG, I plan on using TGA (more than likely) or maybe DDS (As far as DX is concerned it can load png, bmp, jpg, dds, tga, and a few others). Once I get some of the build issues out of the way and swap over the texture format I want to build up some of the models to see how much work will need to be done on the rendering engine. Start small with maybe 1-2k triangle models and having a few hundred of them, maybe add some spotlights(headlights) to the units (if the day/night code is still there and useable) and see what breaks.

There are a lot of different directions to go just toying with how or why certain things work. Its all just crash and learn.

[vexed]

latest flex and bison.

And that is what exactly ? Do flex --version and bison --version on the command line.

Thing is.. WRP went with PNG, I plan on using TGA (more than likely) or maybe DDS (As far as DX is concerned it can load png, bmp, jpg, dds, tga, and a few others). Once I get some of the build issues out of the way and swap over the texture format I want to build up some of the models to see how much work will need to be done on the rendering engine. Start small with maybe 1-2k triangle models and having a few hundred of them, maybe add some spotlights(headlights) to the units (if the day/night code is still there and useable) and see what breaks.

There are a lot of different directions to go just toying with how or why certain things work. Its all just crash and learn.

TGA has bigger files than png, and dds wasn't used since there was a question on patents I think it was, but this was a long time ago. Dunno if this is still a issue or not.
You thinking of point lights, or simulated lights for headlights ?
When I did my tests many moons ago, it got pretty darn slow going the realistic route.

[Lord Apocalypse]

tga is uncompressed I believe and a format I am used to and have used in the past for modeling work. Other than that I don't have any other reason to use it. DDS I know has a nice photoshop plugin but haven't heard about patent issues, time to google it I guess.

On to lights... simulated would be nice but I know it does take a lot of every power to do. Point lights.. would probably look funny doing the lightbulb effect. Wish I knew what simcity 4 used as all the cars had headlights, lamps had lighting (cone, so probably some type of spot light).

Bison: 2.4.1
Flex: 2.54
Linux using the same version or something higher?

[vexed]

Try Bison 2.1, that is what I am using.
They got some bugs in other versions of it.