I am stuck in this Arctic blast so I checked my mail, and found replies! :)
(for 3+ hours now...grrrr...then you won't hear anything from me again for
awhile, which may be good news or bad, depending what you think of
what I say... lol)

On 11/25/05, RodZilla <[EMAIL PROTECTED]> wrote:
> Hi !
> > 1) There is one more file to convert to flex/bison, although this one
> > is more tricky.
> > 2) Converting all the less important pieces of file access code to 
> > physicsfs.
> > 3) Find a way to restore the software renderer.
> > 4) Try to fix all the bugs created so far.
> > 5) Make a new release (svn head with physfs + png code).
> One really important thing to do is to take advantage of physFS to
> make modding really easy. This would probably require to have
> a different organisation of the data directories (something really
> simple like a "sp" directory with everything from warzone.wz in it,
> an "mp" directory with all "01", "02" etc. dirs in it and the
> possibility to have a "data" dir in ~/.warzone (or equivalent
> under windows) to override all this.
> This way:
> - writing a mod = new "999_mymod" directory in mp.
> - modifying a mod/texture/model = use the user override directory.

This was more or less the plan, at least for me.  In MP.wz 01-11 (well I
 guess it should really be 10) are all in there, and to add something you
 just pick a higher number.  In theory it should work, but I never did get
a chance to incorporate Strata's latest patch to test it.  Parsing the name
of the file, or having a ID.txt (or whatever) in mymod.wz might be better,
though.  And then there is the dependency issue with some older mods
that I ran into.  I don't know if we even care about those though?

Note that SP stuff should not be modified really, since that can really
screw up the game balance / playability.  I mean stuff besides tilesets and
the annoying sounds. :)  To create a new mission /scenario though is

> And there's also :
> 6) fix the small bugs in the OpenGL rendering path (mostly add a
>     flag in PIE files to know if models cast shadows, and handle
>     correctly existing flags).
> >>I know in the past you said that a lack of communication is part of
> >> the problem,
> >
> >>but I haven't seen a post from you on the dev list explaining what you are 
> >>working
> >>on, or planning to do.
> >
> > Mostly because I have not done much lately, and maybe because I was
> > tired of talking to myself.
> Come on ! I read my emails too ! :)

Reading them is one thing, but replying is another! :D

You should turn on auto-reply, so people can at least know you (and the
others) are reading.... lol ;)

> >>1) FMVs.  What to do about them.  More about this in forums @ RTS.
> > I never saw the original videos. Are they really all that? Can't we
> > just drop the idea of having videos and just print some (more) text to
> > explain what is happening and what needs to be done to complete the
> > mission?
> Yes they are important. And I think it's important to make it possible
> to have FMVs in the game. Then contributors can slowly make new ones.

I was open to having static text with a backdrop, or FMVs.  It doesn't really
make a difference right now.   It just looks better if we keep it like
the original
FMVs though. We could start out with static text, since this would be the
easiest & fastest to implement.  Then we can add FMVs when they are
made available.  Something like check for mission1.fmv if not found, then
just do the static text with backdrops.

> >>2) Next official release.  We do not have a official release using the
> >>newer data package.  People are still using with .wdg.   We do NOT
> >>need bug reports that deal with that version, it is very old.  We DO need 
> >>bug
> >>reports for & the current stuff.
> > Personally I do not see much point in a a release. What we
> > need is a release with PNG code for artists to work with.
> Agreed.

The release was meant to be the last one with all the original
data.  Nothing more.  Well, that and to test for bugs.  As I have said,
nobody has gone from mission 1 all the way through the game on
.wz data files.  Better to find issues with this release than waiting for
who knows how long before the next release.
This will also please the die hards that didn't want ANY changes at
all in terms of tilesets (or anything else).  While we could make some sort
of option for the user to pick which tileset they want, this was gonna
 happen in :)

> >>5) GUI.  The way it is done now, is.. crap.  This would have to be
> >>fixed if we want to add some more features more easily, like a lobby and 
> >>what
> >>not.  While it can be done via what we have now, it is a huge PITA!
> > I have not looked at it. Can someone explain (or better, put in the
> > wiki) how the GUI system works now?
> The worst thing about that GUI stuff is that there is no packing
> code in it (all widgets have to be placed manually).
> I have code for this somewhere but I didn't look close enough
> at that part of warzone code to find a smooth way of integrating
> it.

There is also the issue of having to make modifications to the scripting
engine (well, text file)  to add entries.  It should be able to dynamically make
it.   My idea was just to add another GUI layer, to be able to handle this.
This would allow us to make for example a lobby type interface with
all the things we need to handle I/O, instead of the lame way it does it
now.  It would be like a new self contained package.

> >>6)Game play changes.  In short, NO.  Don't break anything, since it
> >>was balanced for the most part.
> > I agree.
> Yes.
> >>7) Mods.  Come up with a nicer way to handle these.
> > That is on my TODO list as well.
> That's the same topic as taking advantage of PhysFS.
> > The biggest problem is the map editor. Without a working map editor,
> > this project is dead, and working on anything else is pointless. And I
> > really do not feel like working on the map editor or a new map editor
> > on my own. I was really hoping that you would take care of the map
> > editor, and the news that all the work you put into it is lost and we
> > still just have the crap inherited from Pumpkin was a huge blow to my
> > enthusiasm.

Ack!  :(  Though it was still the same crap from Pumpkin, I just fixed the
hardcoded ways that they did for 16bit. We DO have the editor though.

> Qamly, how much time would it take for you to rewrite the updates you
> did to the map editor ? I guess it would be the first step. Second step
> would be making it run under Wine for Linux users so we don't have to
> hurry rewriting the whole tool.

It took me around 1 week to fix the old one, so it wasn't that hard to do.
Have you tried to see if it runs on wine now?  Coyote uploaded the last
working version of the Worldedit32 on wztoys site.

> And while there's no map editor, people could concentrate on creating
> new textures/models/sounds. That would make the game better.

There *IS* a editor, well, 3 of them. 2 from pumpkin, 1 that does wdgs
(EditWorld), and the other that dumps all data out to a directory (WorldEdit).
Then the modification that I did Worldedit32 which is basically WorldEdit
that runs on 32bit desktop (true color) with PNG support, and creates .wz
EditWorld could only do MP maps, though the code is almost identical to
WorldEdit, they played hide & seek with menu options, so you couldn't
create campaigns with it.
WorldEdit could do MP maps and campaigns.

> Best regards,
> Rod.

Later all...
Warzone-dev mailing list

Reply via email to