[warzone2100-dev] Change of email address / verandering van mailadres (ger...@gerardkrol.nl)

[Gerard Krol]

Hi contact from my address book,

I'd like to inform you that I obtained my MSc in Chemical Engineering 
and that I won't be able to read mail sent to this address anymore. 
Please send any further email to:


ger...@gerardkrol.nl

Thanks to everyone who made it possible for me to finish my study!

If you have received this message multiple times or on a different mail 
address from which you prefer receiving mail from me please send me a 
message from your preferred address.


Regards,

Gerard Krol

==

Hallo contact uit mijn adresboek,

Het is zover, afgestudeerd. Dit mailadres houdt er dus mee op, gelieve 
email vanaf nu te versturen naar:


ger...@gerardkrol.nl

Groeten,

Gerard


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Project rename, website changes

[Gerard Krol]

Zarel wrote:
> 
Fine with me.

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7192] branches/lua2/data/mods/global

[Gerard Krol]

Kreuvf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dennis Schridde wrote:
>   
>> Explanation of the acronym "TD" and a short summary of the contents would be 
>> nice.
>> 
> I figured out that "TD" stands for "Tower Defense" which reminds me of the
> Starcraft defense maps.
>
> But I am curious what this is about as well ;)
>   
Correct, it stands for "Tower Defense". For those who have never played 
one here is a short description:
* You have a certain amount of lives (say 20)
* Enemy units appear somewhere, and try to reach a destination
* To stop them, you build towers which shoot at them and sometimes force 
them to travel through an elaborate maze of towers
* For every unit killed you get a small amount of money (power), which 
you can use to build more towers
* If some get through, you lose lives
* After the first group, a stronger/faster group of units appears, and 
the cycle repeats.

The lua2 branch now has a tower defense mod, which can be activated 
using --mod=td. It has one 4 player map where the enemies start at 2 
points at the top of the map and try to reach the bottom. You have to 
work together to stop them all.

Regards,

Gerard


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Source code formatting

[Gerard Krol]

bugs buggy wrote:
> I think we should start converting the source code, on a file by file
> basis, starting with the libs, and working our way to src.
>   
You have ANY idea how badly this will mess up all branches? Please 
please don't

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Question on maps

[Gerard Krol]

Florian Schanda wrote:
> Our eventual aim is to write a random map generator for warzone
Nice. I already have a start of that, but it is far from finished. Take 
a look at the "random_map" branch in the 
git://gitorious.org/warzone2100/gerard_.git repository. What I have 
currently got working is a relatively open map in different "themes" 
(arizona, rockies, urban). The urban setting looks really weird, as it 
is not flat enough to be a real city. To start a random map select one 
of the Rnd-* maps from the skirmish menu.

What does not work yet is saving/loading (due to the fact that it uses 
the new terrain renderer) and network play. Both probably need support 
for a new map format. The code is in src/randommap.c.

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] [Warzone-commits] r6929 - /trunk/lib/netplay/netlog.c

[Gerard Krol]

Per Inge Mathisen wrote:
> On Mon, Mar 30, 2009 at 4:14 PM, Git SVN Gateway
>  wrote:
>   
>> Fix ticket #293: Crashes in netlog code.
>> 
>
> Did you find the same fix hidden in my 2.2 branch, too? ;-)
>
>   
I didn't, thanks for reminding me. I guess I'll have to set up a script 
that will scan for changes...

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Mods considered harmful considered harmful

[Gerard Krol]

Per Inge Mathisen wrote:
> Popular suggested or created modifications
> to the game rules quickly become integrated into the core rules,
> draining the pool of mods available for players.
>   
True, but if the mods would not have been there, would the same changes 
have been included in the game? Mods mostly concern changes like 
graphics, balancing and new game modes. Hardcore developers love too 
look at the code too much to bother with that. (I probably won't be 
touching the terrain textures again for example)
> The problem was that a generalized code engine that supports all kinds
> of strange rules is inherently more difficult to maintain, and very
> much more difficult to write an actual, fun game on top of.
I agree that we should be careful not to become a victim of the "Inner 
platform effect" [1]. People do not want all those choices, they just 
want something that's simple, fast, and intuitive. If they really want 
to do complicated stuff there is always the source.
I would really like to have something akin to the Warcraft 3 map editor. 
(the unreal tournament map editor was also way too much fun) Just make a 
map, place units and buildings, do some modifications to the tech tree 
and perhaps use a few predefined triggers to do a few predefined actions 
(suggested set: the minimum required to make a tower defense).

Dennis Schridde wrote:
> Multiple mods:
> Morrowind and Oblivion (sorry, again...) have some mods which are rather 
> "metamods". They combine several others into one. 
I think it is good to limit the game to load just one mod. Like you 
said, if people want to run multiple mods, they will have to create a 
new mod for that, or devise some sort of package management system. Oh, 
and mods should ONLY work in "vanilla" (no custom scripts/tech tree 
mods) multiplayer and skirmish games.

We DO need to add support for network games with mods however. The game 
needs to make sure everyone has the same mod. (by checking the md5 of 
the .wz?)

Also mods should just plain be in the "mods" directory. By the way, does 
anyone else think we've got a really messed up directory structure for 
the data as well?

Zarel wrote:
> I do think we should merge mp.wz and warzone.wz
> back together.
+1
I think it is really annoying for people when they have finished the 
campaign they will have to learn an almost completely different game. 
And it complicates stuff for us.

- Gerard

[1] http://en.wikipedia.org/wiki/Inner-Platform_Effect

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Git <-> SVN Gateway up and running

[Gerard Krol]

Hello everyone,

I'm still a little sad that we didn't switch to Git. However, I made it 
possible to use both Git and SVN.

Anyone who wants to crawl out of the SVN pit is welcome to clone 
git://gitorious.org/warzone2100/mainline.git
If you have any interesting commits in your public repository I will 
pull from you and commit them to SVN, where they will end up as being 
committed by mr. Git SVN Gateway. A From: line at the bottom will show 
the original author.

Any commits from SVN will also show up in the mainline repository, so 
you can pull/fetch from there to keep up to date with the work being 
done in SVN. Keep in mind that it is a manual process (I have to be able 
to resolve any merge conflicts) so it might lag behind a day or two.

One of the problems is that I'm the only one that can operate the 
gateway (as you can't clone a git-svn repository). This could be solving 
by hosting the repository on a server somewhere, where developers could 
login to run the script and fix merges.

Regards,

Gerard

P.S. For those interested, the latest version of the script can be found 
at 
http://gitorious.org/projects/warzone2100/repos/mainline/blobs/master/tools/gitsvngateway/gitsvngateway
Any suggestions about shell scripting (it's my first !) or better uses 
of Git are welcome of course.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Ready for the switch to git?

[Gerard Krol]

Hi all,

I'm glad the "Ready for the switch to git?" email spawned a lively 
discussion, and that a lot of people tried to actually use git. Below 
are replies to different people, bundled together to prevent me from 
repeating myself:

Zarel wrote:
> 2009/3/13 Stephen Swaney 
>   
>> The ability to branch freely is great but without a primary location
>> for the source keeping track of who is 'it' sounds difficult. How do
>> we keep all the package maintainers connected to what is going on?
>> 
> I echo this. Having a single repository makes sure conflicts get
> resolved quickly. If we don't have that, then what do we have? Several
> versions of Warzone, each incompatible with each other, and no way to
> easily merge them?
>   
That's the best part, we *do* have a way to easily merge them. Git is 
designed to make this easy.
> I mean, I wouldn't mind having my local copy as a separate repo, but
> it should be merged with trunk fairly quickly. In short, I prefer the
> current way.
>   
I think all active developers will fetch from everyone daily so we will 
have a smooth flow of commits. Despite everyone telling that it works 
I'm really curious myself how well it does. The central repository is a 
good fallback if it turns out not to.
> In addition, Git doesn't have anywhere near as good a Windows GUI as
> TortoiseSVN. I like being able to diff/blame/make-patch in around two
> clicks. Committing is two clicks. Unless you only want to commit some
> files, in which case it gives a list with a bunch of checkboxes. All
> versioned files are checked by default, and there are buttons to check
> all, none, or versioned only.
>   
You definitely did not try git gui and gitk. You won't have to go to the 
commandline for your everyday tasks.
- Right click on the folder with your repository -> git gui
- Make some changes, click Rescan.
- Click the icon in front of the changed files you want to commit, or 
click "Stage Changed" to add them all
- Write a commit message in the textbox
- Click commit

When you want to push your commits:
- Remote -> Push
- Push

For the blame:
- Repository -> browse * files
- Click a file

I never used git gui, and I was able to figure it out quickly. Give it a 
try. Don't be afraid to ask, either in #warzone2100-dev or #git. 
(helpful people over there)

Elio Gubser wrote:
> I'd like to stick with svn. The only _really_ issue is buggy's
> connection problems. We should only tackle this problem and not create
> new ones with introducing a completely different vcs.
> At least I am very happy with svn (and gna)
>   
I really feel restricted by svn. (I probably already told everyone a few 
times). It feels like being stuck on windows when you are used to linux, 
like being stuck on ice without ice skates, like programming in Visual 
Basic, like eating soup without a spoon. (no offense to the people who 
regularly do these things, especially to the ones without a spoon)

You might not yet feel the restrictions (yet), but in my opinion it is 
best to use the most powerful tool/language/vcs from the start, rather 
than waiting until you need it. It might take some time getting used to 
it, but when you need the complicated features at least you are ready 
for it.

bugs buggy wrote:
> Another Q, what are these (core.autocrlf & core.safecrlf ) supposed to
> be set at?   Svn tracks what they are (either CR or CR+LF),  git don't
> have this, so how do we know what to set these values at ?  What
> happens if some are CR and some are CR+LF?  Or did Gerard fix this on
> the initial repo dump?
>   
I believe git internally uses LF, and you can ask it to convert it to 
another format when you checkout. It seems to work but you might have to 
do a git reset --hard (it's a scary name for a simple command) if git 
diff shows changes on all lines of all files.

Regards,

Gerard



___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Ready for the switch to git?

[Gerard Krol]

Per Inge Mathisen wrote:
> Personally I am scared by things like this:
>
> On Fri, Mar 13, 2009 at 11:49 AM, Dennis Schridde  wrote:
>   
>>> Devurandom has convinced me that a shared repository (with multiple
>>> people pushing to) does not work well with git.
>>>   
The wording is perhaps a bit unfortunate ;)
Having one shared repository does work, but you would be using git just 
as a complicated svn clone.
The nice thing about git is that it does not enforce any workflow. I 
think we should start out with the official git way, and see how we like it.
>
> So let's not rush wildly into the unknown, even if Buginator is
> hurting and git looks like the next coming of revision control right
> now... ;-)
As long as nobody gets hurt it will all be fun and games right?

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] History surgery performed on mainline

[Gerard Krol]

Hi all,

Devurandom noticed that the last 3 commits I pushed did not have the 
correct author set, so I fixed that. This means that if you have cloned 
from
git://gitorious.org/warzone2100/mainline.git you need to take care. The 
branches affected are master and 2.2. Any checked out copies of those 
can best be removed and checked out again. I'm also recreating the 
gerard_ repository.

Regards,

Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Ready for the switch to git?

[Gerard Krol]

Freddie Witherden wrote:
> +1 on sticking with SVN.
Could you tell us your reasons for wanting to stick with svn?

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Ready for the switch to git?

[Gerard Krol]

Hello everyone,

I have set up a project at at http://gitorious.org/projects/warzone2100
the "mainline" repository[1] is a mirror of svn and the "gerard_" 
repository[2] is to be my public repository where my bugs will appear 
(and hopefully some features). Trunk is now called master. Note that if 
you are not happy with my choice of Gitorious, nothing will prevent you 
from hosting your repository elsewhere and some day we might use that 
one as "mainline". Ah, the freedom.

Please test if cloning the repository works for you. If you like, you 
can clone the mainline repository on Gitorious (one click+entering a 
name) and use that as your public repository (push to it), any changes 
can be pulled into the mainline repository when we switch.

Finally, we need to decide what to do with the "mainline" repository. 
Devurandom has convinced me that a shared repository (with multiple 
people pushing to) does not work well with git. We thus need someone who 
regularly (at least once a week, but preferable every few days) pulls 
from the developers repositories, tests the result, and pushes to 
mainline. That way we still have an "official" development version. I 
can do this for maybe a few weeks, but I'm really not the man for the 
job as I could have one of my "few month breaks" at any time.

Anyone who has strong objections against switching to git, please speak 
up now! If everyone agrees I will ask Devurandom to set the svn 
repository to read only and we will see how it goes from there. Any 
advice is welcome, as I don't have any experience with using git for a 
project like this.

Regards,

Gerard

PS. Devurandom: Gitorious wasn't slow, it was just my ADSL connection 
that decided to switch to a lower bitrate.

[1] mainline: git://gitorious.org/warzone2100/mainline.git
[2] gerard_: git://gitorious.org/warzone2100/gerard_.git
||

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] SVN -> Git?

[Gerard Krol]

Hello everyone,

Due to:
- GNA being unable to provide reliable SVN access to everyone 
(especially to Buginator)
- Terrible support for branches in SVN
- Devu, Giel and me using it already

I would like to propose we switch to Git (http://git-scm.com/) for our 
version control needs.

Advantages:
- Cheap local branches (try it once and you're addicted)
- Good merge support
- Speed (a diff between two random revisions is almost instant)
- git checkout prevents the need to have different directories with 
different branches

Disadvantages:
- People have to learn to use Git (took me two days)
- Less supported (it will take a year before there are git plugins for 
everything)

Q: Why Git? Why not Bzr, Hg?
A: Better to get used to the power tool now rather than to be stuck with 
DVCS Basic.
Q: Wouldn't this leave windows users out in the cold?
A: I tried msysgit 1.6.1-preview20081227 (from 
http://code.google.com/p/msysgit/) and it worked great in my XP vm. Not 
even a need to get to the command line with (the included) git-gui.
Q: What if we later decide Git wasn't the right choice?
A: We just commit everything to SVN again and continue to use that.

For some Git propaganda see: DVCS Comparision 
http://vcscompare.blogspot.com/

I would ask you to check out Git, and tell me what you think. It might 
be best to find a small Git repo somewhere 
(http://gitorious.org/projects) to experiment with. You won't be able to 
push (the svn commit) of course, but it's enough to get a feel for it. 
Things to try are: cloning the repo, creating a local branch, committing 
to the branch, rebasing the branch, merging the branch, cherry picking a 
change and checking out some random point in history. Use gitk to keep 
track of where you are in the history tree.

- Gerard



___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] 2.2 branch

[Gerard Krol]

Freddie Witherden wrote:
> Hi all,
>
> On 31 Jan 2009, at 09:05, Dennis Schridde wrote:
>   
>> Nope, not much holding back 2.2.
>> 
>
> I would like to see the new lobby protocol which Gerard was working on  
> make it into 2.2. Will simplify things in the future.
>   

I did slightly more work on it, and was not satisfied with the end 
result. It just didn't feel right (oooh). I think we should completely 
rewrite the joining/hosting code. Also, JSON is quite OK, but a way to 
send lua objects safely would be even better. We would have one 
dependency (+one interface) less.

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] A plan to refactor and clean up the warzone code base

[Gerard Krol]

Per Inge Mathisen wrote:
> I would like to suggest that we start refactoring the Warzone codebase
> so that it can more easily be unit tested aggressively. 
>   
Would it be an idea to wait for the merge from the terrain and the lua 
branch? That's going to be one hell of a job after we refactor the code. 
I might be repeating myself, but I'd like to branch and release asap, 
and merge the terrain and lua branches in. We can then to all the nice 
refactoring we want.

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Branching for 2.2

[Gerard Krol]

Dennis Schridde wrote:
> Am Donnerstag, 25. Dezember 2008 15:51:16 schrieb Gerard Krol:
>   
>> Hi everyone,
>>
>> Merry Christmas! We have only just released 2.1, but I think we should
>> be deciding on the next release already.
>> 
> Generally I agree.
>
> But what are the new features of current trunk?
>
> 
>
> Is that *all*? Even compared to the late 2.1 betas that's *nothing*...
I think the main point of this is that we should be updating the 
changelog. It has now been 7 months since we branched 2.1. This was 
revision 4789 (compared with almost 6500 we are now). I don't think 7 
months between branching different releases is too short. Checking the 
SVN log shows enough changes. I don't know how many of those were 
backported of course. I don't feel like updating the changelog now, but 
I'll check it out somewhere this week.

> Forgot something: Before we do any release, I'd like to finish my work on the 
> projectiles, which will likely not happen before end of January (other work 
> takes priority...)
> I already have a replacement for the current projectile system, but the more 
> advanced aiming functionality takes a bit more time to implement. At least 
> more than the 10 minutes of spare time I (should) have.
The big question is, would this be a reason to delay the branching + 
release for a month or two? Does it fix any bugs? Especially if you 
don't know if you will have time to finish it soon, I don't think we 
should wait for it.

I agree with Per that 2.2 would be a nice target for long term support. 
I only hope that it doesn't become as much of a pain as 2.0.

Regards,

Gerard


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Branching for 2.2

[Gerard Krol]

Hi everyone,

Merry Christmas! We have only just released 2.1, but I think we should 
be deciding on the next release already.

The two points to consider are:
* what do we want to include?
* when do we want to do the release.?

We currently have a really stable trunk. (when was the last time it 
crashed for you?) I think we should not waste this by adding a lot of 
stuff (like the new terrain renderer) before doing a release with it.

My proposal would be to branch off for 2.2 within a few weeks. We then 
push out some beta's to quickly iron out all bugs and we can release 2.2 
in a few months. That is, if Giel is willing to manage another release 
after so little time has passed. (great job on 2.1 by the way)

What do you think about this? I'd really like to have the new terrain in 
trunk, so I'd like the branch to be as soon as possible.

Regards,

Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Upgrade to Subversion 1.5?

[Gerard Krol]

Hi all,

We are using a lot of branches lately, and it would be nice to be able 
to use the new merge tracking features which are available in svn 1.5. 
As far as I know upgrading would not have any disadvantages (after 
rebuilding the index). See 
http://subversion.tigris.org/svn_1.5_releasenotes.html for more information.

What's your opinion about this? If nobody objects I'll open a ticket at 
Gna! and ask them to upgrade.

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] File Association For Mods

[Gerard Krol]

Per Inge Mathisen wrote:
> On Sat, Nov 29, 2008 at 6:13 PM, Dennis Schridde <[EMAIL PROTECTED]> wrote:
>   
>>> Mixing and matching mods is never a good idea. If we encouraged it
>>> then it would just lead to more useless bug reports.
>>>   
>> That's all the fun. ;) Multiple mods. Of course there'd be incompatibilities,
>> but that should not concern us, as long as we are not causing them.
>> 
>
> Do you really think users will understand that what the cause of the
> bug is? It sure will not be obvious, eg they could play a long time
> before the effect becomes apparent, perhaps forget that they used
> mods, and it may show itself in really strange glitches.
>
> If multiple mods is made easy, we will spend a lot of time going over
> vague bug reports due to it. Sure we can just close them when (if) we
> realize that the cause behind the bug report is conflicting mods, but
> wasting time on *bogus* bug reports is far more annoying than spending
> time tracking real bugs.
>
>   
I think multiple small mods would be a cool feature. You know the unreal 
tournament options like "large heads" etc.? I think it would be really 
cool to be able to have both a "extended research" mod and a "large 
turrets" mod for example.

Perhaps we should integrate the tiny mods in the game (and make them 
inter-operate well), and then only allow one external mod active at a time.

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Games mailing list

[Gerard Krol]

Hi everyone,

This was brought to my attention by pabs3:

[Games] Turning on the engine
http://lists.freedesktop.org/archives/games/2008-November/06.html

It is a mailing list for game packagers/developers from different 
distributions. There might be some useful information passing by.

Regards,

Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] New Terrain Renderer

[Gerard Krol]

Kreuvf wrote:
> How is the performance affected?
>
Try it out yourself (branches/terrain) and report the framerate you get. 
For me it drops the framerate by 50% currently. But this is with 7 
terrain layers and no optimisations. Most levels look fine with only 4 
layers. I guess we can reduce it to a framerate drop of 20% with the 
knowledge we currently have. If we were to study some opengl, or a guru 
passes by, it can probably be 2x faster than what we have now.

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] New Terrain Renderer

[Gerard Krol]

Hi all,

Please check out 
http://forums.wz2100.net/viewtopic.php?f=6&t=2379&p=23075#p23075 and 
tell me what you think.

Regards,

Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] How not to use a version control system

[Gerard Krol]

Zarel wrote:
> 2008/11/16 Gerard Krol <[EMAIL PROTECTED]>:
>   
>> The untested commit: after a careful reading of the code you conclude
>> that there possibly can't be any bugs left. Unfortunately a trivial bug
>> renders the entire program unusable. Better stay available to do
>> emergency fix-ups.
>>
>> (coloured cursors anyone?)
>>
>> 
>
> Hey, the patch that broke cursors wasn't the colored cursor patch; it
> was a different cursor-hiding patch...
>   
Yeah, by me ;)
I still don't understand why the colored cursor was visible before, as 
it wasn't drawn in the main menu loop. Probably it used the hardware 
cursor in the menu or something like that.

- Gerard


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] How not to use a version control system

[Gerard Krol]

The untested commit: after a careful reading of the code you conclude 
that there possibly can't be any bugs left. Unfortunately a trivial bug 
renders the entire program unusable. Better stay available to do 
emergency fix-ups.

(coloured cursors anyone?)

Nice list. Now how to make sure people read it

- Gerard

Per Inge Mathisen wrote:
> There are various ways you should not commit things into a version
> control system. Let's go through some of them:
>
> The commit & run: "I have to go now or I'll be late for...", then you
> commit today's work and bolt out the door. A sure way to see to that
> your colleagues sit late or go home early, depending on how close to
> deadline they are.
>
> The blind commit: "I committed *what*?" Always check what changes are
> lurking in your working copy before doing a commit.
>
> The sweet relief commit: After painstakingly long hours of debugging,
> it finally works, and you wrap it up with a commit. It feels good to
> be done. Except you also committed tons of debug code, snarky comments
> and commented out parts, making sure that the next session will be
> even more painstaking. Always read over the whole diff again before
> committing.
>
> The superhuman commit: A truly massive amount of improvements and
> fixes in a single commit, usually signed with a suitably heroic
> one-liner commit message for punch-line. Since it contains so much
> good stuff, nobody has the heart to revert it when they find
> regressions, and due to its massive size, nobody else can bisect it to
> find errors.
>
> The commit flood: Having been bitten by the superhuman commit, you
> split your work instead into dozens if not hundreds of separate
> commits. Guaranteed to make anyone who tries to follow the commit log
> give up in despair, and makes the whole work impossible commit when
> done.
>
> The stroke of genius commit: "Why didn't anyone think of this before?"
> There is usually a good reason. Always sleep on a good idea. It may
> not seem so bright the next morning.
>
> The late night commit: Having *finally* fixed all the bugs and cleaned
> up the code, you write a long and informative commit message, squint
> at the rising sun, and go to bed. Except that your brain is so full of
> diet coke that you have no idea what you were doing, and committed
> from the wrong working copy. Just never commit anything after
> midnight.
>
> The search & replace commit: You find an annoying but unimportant
> frequent mistake in the source code, and fix it by search and replace
> on all occurrances then committing the improvement. As a result, every
> other working copy get conflicts and nothing can be reverted or merged
> past this point.
>
>   - Per
>
> ___
> Warzone-dev mailing list
> Warzone-dev@gna.org
> https://mail.gna.org/listinfo/warzone-dev
>
>   


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] [patch #1111] Fade out the edges of the visible map to prevent popping mountains

[Gerard Krol]

URL:
  

 Summary: Fade out the edges of the visible map to prevent
popping mountains
 Project: Warzone Resurrection Project
Submitted by: gerard_
Submitted on: Saturday 11/08/2008 at 21:27
Category: Feature
Priority: 3 - Low
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None

___

Details:

When looking at the horizon and scrolling over the map with fog of war
enabled shows mountain ranges popping up when they enter the part of the map
that is drawn. By fading the edges to transparency instead of black, they
fade in beautifully.

Possible problems:
* Drawing order: If a droid or projectile is behind the mountain that is
partially faded, it will show up as being in front of it. This was not
tested. Droids only seem to be drawn for the visible part of the map
however.
* Performance: All map tiles are now drawn with transparency enabled. This
could have an influence on the perfomance, but this was not observed.



___

File Attachments:


---
Date: Saturday 11/08/2008 at 21:27  Name: fade_edges.patch  Size: 4kB   By:
gerard_



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] [Warzone-commits] r3712 - /trunk/src/intelmap.c

[Gerard Krol]

Dennis Schridde wrote:
> Am Donnerstag, 7. Februar 2008 20:19:17 schrieb Gerard Krol:
>   
>> Author: gerard_
>> Date: Thu Feb  7 20:19:15 2008
>> New Revision: 3712
>>
>> URL: http://svn.gna.org/viewcvs/warzone?rev=3712&view=rev
>> Log:
>> Make sure that long lines of text are correctly drawn and wrapped for the
>> intelligence display. This also works for larger fonts. This fixes bug
>> #10913, and makes patch #965 obsolete.
>>
>> Modified:
>> trunk/src/intelmap.c
>> 
> - Form->width, Form->height,
> + Form->width-40, Form->height,
>
> Magic value?
>   
Yep, oops... In fact, we need some magic value magician to dispel the 
entire file.

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] [bug #10995] --nosound broken

[Gerard Krol]

The sound data that would be stored is the current track playing. 
Scripts can set this and expect to be able to query which one is 
playing. If the scripts select a piece of music with a certain theme and 
feeling, we want that track to play again when the game is loaded, 
preferably even at the point where it left off. A solution would be to 
explicitly notify the script that it is being loaded, so that it can 
restart the music.

Also, the trouble is that it is much more difficult to keep the games 
internal state correct when some pieces of code are sometimes executed, 
and sometimes not. Minimising the amount of conditional code is a good 
thing I think.

- Gerard

Kevin Gillette wrote:
> the correct way to do it *is* to skip past all sound specific stuff 
> from the game loop when --nosound is used. frankly, there's no reason 
> at all to store any sound-related data in a savegame -- all you lose 
> is about a second's worth of sounds that were initiated just before 
> the save point, just as there is no noticable benefit to storing the 
> animation frame index for cyborgs in a game like this. the benefit by 
> not running all the sound specific stuff is that you save ticks, and 
> not necessarily bring system requirements down, but along with other 
> optimizations, keep them from skyrocketing upwards.
>
> On Feb 5, 2008 2:26 PM, Gerard Krol <[EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>
> URL:
>  <http://gna.org/bugs/?10995>
>
> Summary: --nosound broken
> Project: Warzone Resurrection Project
>Submitted by: gerard_
>Submitted on: Tuesday 02/05/2008 at 22:26
>Category: Engine: Sound
>Severity: 3 - Normal
>Priority: 5 - Normal
>  Status: None
> Assigned to: None
>Originator Email:
> Open/Closed: Open
> Discussion Lock: Any
> Release: svn/trunk
>Operating System: GNU/Linux
> Planned Release: None
>
>___
>
> Details:
>
> The --nosound command line option is broken, using it causes an
> assert:
>
> never   : directory: script/binary
> never   : directory: script/data
> never   : file: SCRIPTVAL cam1a.vlo
> wz  : Loading script data cam1a.vlo
> script  : allocated space for 27 events
> error   : resGetDataFromHash: Unknown ID: 66d7b27 Type: WAV
> error   : Assert in Warzone: frameresource.c:579 :
> resGetDataFromHash (psRes
> != NULL), last script event: ''
> warzone2100: frameresource.c:579: resGetDataFromHash: Assertion
> `psRes !=
> ((void *)0)' failed.
>
> The way --nosound is implemented is wrong, it is better to act like
> --dry-run, and perform all operations except the actual openall
> calls. This
> makes it that you can start a game with --nosound, save, start
> with --sound,
> and continue (with the sound playing as it would have been).
>
>
> 
>
> ___
> Warzone-dev mailing list
> Warzone-dev@gna.org
> https://mail.gna.org/listinfo/warzone-dev
>   


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] [bug #10995] --nosound broken

[Gerard Krol]

URL:
  

 Summary: --nosound broken
 Project: Warzone Resurrection Project
Submitted by: gerard_
Submitted on: Tuesday 02/05/2008 at 22:26
Category: Engine: Sound
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: svn/trunk
Operating System: GNU/Linux
 Planned Release: None

___

Details:

The --nosound command line option is broken, using it causes an assert:

never   : directory: script/binary
never   : directory: script/data
never   : file: SCRIPTVAL cam1a.vlo
wz  : Loading script data cam1a.vlo
script  : allocated space for 27 events
error   : resGetDataFromHash: Unknown ID: 66d7b27 Type: WAV
error   : Assert in Warzone: frameresource.c:579 : resGetDataFromHash (psRes
!= NULL), last script event: ''
warzone2100: frameresource.c:579: resGetDataFromHash: Assertion `psRes !=
((void *)0)' failed.

The way --nosound is implemented is wrong, it is better to act like
--dry-run, and perform all operations except the actual openall calls. This
makes it that you can start a game with --nosound, save, start with --sound,
and continue (with the sound playing as it would have been).




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] [bug #10972] QuesoGLC can't find the Bold style for DejaVu Sans Mono

[Gerard Krol]

URL:
  

 Summary: QuesoGLC can't find the Bold style for DejaVu Sans
Mono 
 Project: Warzone Resurrection Project
Submitted by: gerard_
Submitted on: Saturday 02/02/2008 at 22:04
Category: Engine: Graphics
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: svn/trunk
Operating System: GNU/Linux
 Planned Release: None

___

Details:

When starting Warzone, I get the following warning:
warning : iV_initializeGLC: Failed to select the "Bold" font face of font
family DejaVu Sans Mono

When iterating over all known families and their faces (like in the glclogo.c
example from the QuesoGLC distribution), the output is this:

family: Verdana
 face: Bold Italic
 face: Regular
 face: Bold
 face: Italic
family: Georgia
 face: Bold Italic
 face: Regular
 face: Bold
 face: Italic
family: DejaVu Serif
 face: Condensed Italic
 face: Italic
family: AntsyPants
 face: Regular
family: DejaVu Sans Mono
 face: Oblique
 face: Book
family: Webdings
 face: Regular
family: DejaVu Serif
 face: Condensed
 face: Book
family: Century Schoolbook L
 face: Roman
 face: Bold Italic
 face: Bold
 face: Italic
family: Nimbus Sans L
 face: Bold Condensed Italic
 face: Regular
 face: Regular Condensed Italic
 face: Bold Condensed
 face: Regular Italic
 face: Bold Italic
 face: Regular Condensed
 face: Bold
family: Standard Symbols L
 face: Regular
family: DejaVu Sans
 face: ExtraLight
family: Arial
 face: Regular
 face: Bold
 face: Bold Italic
 face: Italic
family: Courier 10 Pitch
 face: Regular
 face: Bold Italic
 face: Bold
 face: Italic
family: DejaVu Serif
 face: Condensed
family: DejaVu Sans Mono
 face: Book
family: DejaVu Serif
 face: Condensed Italic
family: Impact
 face: Regular
family: Andale Mono
 face: Regular
family: Arial Black
 face: Regular
family: URW Chancery L
 face: Medium Italic
family: Arial
 face: Regular
 face: Bold
family: URW Palladio L
 face: Roman
family: Courier New
 face: Regular
 face: Bold
family: Bitstream Charter
 face: Regular
 face: Bold Italic
 face: Bold
 face: Italic
family: DejaVu Sans
 face: Condensed
 face: Condensed Book
family: OpenSymbol
 face: Regular
family: URW Gothic L
 face: Demi
 face: Demi Oblique
 face: Book Oblique
 face: Book
family: Trebuchet MS
 face: Bold Italic
 face: Regular
 face: Bold
 face: Italic
family: URW Bookman L
 face: Demi Bold
 face: Light
family: DejaVu Sans
 face: Condensed
family: Times New Roman
 face: Regular
 face: Bold
family: DejaVu Sans
 face: Condensed
 face: Condensed Bold
family: Dingbats
 face: Regular
family: DejaVu Sans
 face: Condensed
 face: Book
family: Courier New
 face: Bold Italic
 face: Regular
 face: Bold
 face: Italic
family: Nimbus Mono L
 face: Regular Oblique
 face: Regular
family: Nimbus Mono L
 face: Regular Oblique
 face: Regular
 face: Bold Oblique
 face: Bold
family: DejaVu Sans
 face: Condensed
 face: Condensed Bold
 face: Bold
 face: Book
family: DejaVu Sans
 face: Condensed Bold
 face: Bold Oblique
family: Times New Roman
 face: Regular
 face: Bold
 face: Bold Italic
 face: Italic
family: Nimbus Roman No9 L
 face: Regular
 face: Medium
family: Comic Sans MS
 face: Regular
 face: Bold
family: Bitstream Vera Serif
 face: Roman
 face: Bold
family: Bitstream Vera Sans
 face: Roman
 face: Oblique
 face: Bold Oblique
 face: Bold
family: Bitstream Vera Sans Mono
 face: Roman
 face: Oblique
 face: Bold Oblique
 face: Bold

Only the Book face is reported for "DejaVu Sans Mono".

fc-match from FontConfig can find the font:

$ fc-match "DejaVu Sans Mono:style=bold"
DejaVuSansMono-Bold.ttf: "DejaVu Sans Mono" "Bold"

When downloading the latest release of Bitstream Vera, and placing the files
in the directory the executable is in (and adding glcAppendCatalog("./");),
All faces are found (as can be seen above). When downloading the latest
DejaVu, only "Book" shows up.

If a QuesoGLC developer reads this: Please make it output error messages
instead of one of the three error codes.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] [bug #10813] Tutorial broken

[Gerard Krol]

URL:
  

 Summary: Tutorial broken
 Project: Warzone Resurrection Project
Submitted by: gerard_
Submitted on: Friday 01/18/2008 at 21:22
Category: Campaign
Severity: 3 - Normal
Priority: 7 - High
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: svn/trunk
Operating System: GNU/Linux
 Planned Release: None

___

Details:

When following the tutorial, the text that is supposed to tell you to build a
power generator is missing, and you can't build the power generator as the
build menu is empty.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Doxygen errors

[Gerard Krol]

Giel van Schijndel wrote:
> Some possibly interesting Doxygen errors, courtesy, my cron daemon.
>   
1. For the unsupported tags: check if you are running the latest version 
of Doxygen
2. For the error missing dot: install graphviz to generate nice diagrams
3, For the warnings about parameters, we should fix the doxygen comments.

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] PIE 6

[Gerard Krol]

Per Inge Mathisen wrote:
> Please take a look at http://wiki.wz2100.net/PIE_format and give some
> comments on the suggestions for a PIE 6 format. I am working on a tool
> to convert the old PIE files.
>   
What would be the difference with the currently existing PIE5 format, 
and why not convert everything to PIE5?

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] [Warzone-commits] r3409 - in /branches/lua/tools/conversion_tools/wz2lua: ./ spark.py wz2lua.py

[Gerard Krol]

Per Inge Mathisen wrote:
> On Jan 8, 2008 4:04 PM, Gerard Krol <[EMAIL PROTECTED]> wrote:
>   
>> Import the wz2lua conversion tool to convert wzscript to Lua.
>> 
>
> I hope you are not planning to do this for 2.1?
>   
No, it's for the lua branch.

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Attached fix for VPATH builds (VERSION 2)

[Gerard Krol]

Kelly Anderson wrote:
> Hmmm, amazing, as soon as I saw the patch on the mailing list I 
> realized I could use a variable that's already set by 
> autoconf/automake instead of the PWD thing. :-D
>
> Here's the version that properly embraces autoconf/automake.
>
Seems to work fine here. Committed in r3406. Thanks for the patch!

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] New scripting language summary

[Gerard Krol]

Per Inge Mathisen wrote:
> On Dec 28, 2007 5:53 PM, Gerard Krol <[EMAIL PROTECTED]> wrote:
>   
>> Summary of opinions about replacing the scripting language:
>> Ari: Worthwile, python too heavy weight
>> Dennis: We should ask Troman
>> Troman: Likes the current scripting engine (+ its syntax), does not want
>> to sacrifice functionality
>> Freddy: We should have an automatic converter, would like a branch
>> Kevin: Would like to keep the old scripting language along with the new one.
>> 
>
> You forgot me?
>   
Oops, yes I did. Sorry about that. Well, it's not too late:

Per: Likes the idea but thinks the code is too unstable right now.
>   
>> I think we should switch to Lua as a scripting language. The switch
>> should be 100% so that the old wzscript can retire and we don't need to
>> maintain it anymore. I disagree with Kevin on this point. We need an
>> automatic converter that can convert all existing scripts. I'll create a
>> branch this weekend, and we'll see how it turns out.
>> 
>
> I'm fine with a branch, but, like with the sound branch, expect the
> result to be subject to some debate before merging is possible.
>   
Yeah, I'll keep that in mind.

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] New scripting language summary

[Gerard Krol]

Summary of opinions about replacing the scripting language:
Ari: Worthwile, python too heavy weight
Dennis: We should ask Troman
Troman: Likes the current scripting engine (+ its syntax), does not want 
to sacrifice functionality
Freddy: We should have an automatic converter, would like a branch
Kevin: Would like to keep the old scripting language along with the new one.

I think we should switch to Lua as a scripting language. The switch 
should be 100% so that the old wzscript can retire and we don't need to 
maintain it anymore. I disagree with Kevin on this point. We need an 
automatic converter that can convert all existing scripts. I'll create a 
branch this weekend, and we'll see how it turns out.

- Gerard



___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Replacing the scripting language?

[Gerard Krol]

Hi everybody,

You all know we are in the possession of our very own scripting 
language. From time to time the question has been raised if we'd want to 
replace the home grown language with something more standard. The 
advantages would be:

* We don't need to maintain the old scripting language anymore
* We would gain extra flexibility in the scripts

The main disadvantage is however that we would need to convert all 
existing scripts to the new format. I believe this is possible using a 
modified version of the script parser that is used in Warzone.

For the new scripting language to use the only competition was between 
Lua and Python. I am fan of Python as a language, but the ease of which 
Lua can be embedded amazed me. If we are going to switch I'd definitely 
recommend Lua. I'm currently writing a new sequence system using Lua, 
and I'm really pleased by the ease of working with Lua & the C API.

Please tell me what you think about switching to Lua as our scripting 
language.

Regards,

Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] [patch #908] New sequence code preview

[Gerard Krol]

URL:
  

 Summary: New sequence code preview
 Project: Warzone Resurrection Project
Submitted by: gerard_
Submitted on: Wednesday 12/26/2007 at 11:42
Category: Feature
Priority: 5 - Normal
  Status: In Progress
 Privacy: Public
 Assigned to: gerard_
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Work in progess!

data/test.lua is the script for the movie.



___

File Attachments:


---
Date: Wednesday 12/26/2007 at 11:42  Name: newseq.patch  Size: 511kB   By:
gerard_



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] [patch #900] Clean up of the RPL/sequence code

[Gerard Krol]

URL:
  

 Summary: Clean up of the RPL/sequence code
 Project: Warzone Resurrection Project
Submitted by: gerard_
Submitted on: Monday 12/24/2007 at 16:07
Category: None
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

This will make the integration of the new sequence (and the ogg/theora) code
a breeze.



___

File Attachments:


---
Date: Monday 12/24/2007 at 16:07  Name: sequencecleanup.patch  Size: 49kB  
By: gerard_



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] [patch #892] Add a timeout of 5 s when trying to join a game

[Gerard Krol]

URL:
  

 Summary: Add a timeout of 5 s when trying to join a game
 Project: Warzone Resurrection Project
Submitted by: gerard_
Submitted on: Friday 12/21/2007 at 20:15
Category: Fix
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

SDL has no functions for this, so this tries to open the connection in a
separate thread. Beware of the hard reset of SDL_net!



___

File Attachments:


---
Date: Friday 12/21/2007 at 20:15  Name: timeout.patch  Size: 5kB   By:
gerard_



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Stomping the new netcode into WZ

[Gerard Krol]

My experience is that just committing something to trunk is the easiest and 
quickest way to test changes.
Why not commit the entire patch this weekeind and have every developer run the 
game in a debugger and play a few games? I suppose we can catch all bugs in a 
few hours then. We can always revert if it does not work out.
 
- Gerard



Van: [EMAIL PROTECTED] namens Per Inge Mathisen
Verzonden: di 18-12-2007 11:46
Aan: Development list
Onderwerp: Re: [Warzone-dev] Stomping the new netcode into WZ



On 12/18/07, Dennis Schridde <[EMAIL PROTECTED]> wrote:
> Ok...
> This seems to be a very actively discussed topic, which is interesting to lots
> of people it seems...
> [/irony]

Perhaps it was a mistake to make a separate branch for it, and we
should instead commit it piece by piece into trunk? Then let people
have a few days of pain^H^H^Hdiligent testing for each piece?

  - Per

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] [patch] Enable Fireworks when win again!

[Gerard Krol]

I just love breaking things ;)

If I remember correctly I wanted to display the statistics about the game 
(kills etc.) at the end of a multiplayer game.
It should be possible to enable fireworks again without removing this 
functionality.

The intRemoveMissionResultNoAnim might have something to do with an empty blue 
intelligence box appearing at the bottom of the screen when you were defeated, 
but I'm not sure about that.

- Gerard


-Original Message-
From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]
Sent: Wed 27-6-2007 8:55
To: warzone-dev@gna.org
Subject: [Warzone-dev] [patch] Enable Fireworks when win again!
 
I see pattern.  Gerard breaks, I fix. ;)

In mission.c, compare to original source code.  They had comment 
out.  Unknown why it was enabled.  Did no seem to do anything when 
enabled.
Test in both SP & skirmish.

In wrappers.c, yes, just one line comment out (or just remove).
Again, unknown why he do this, I just know it broke fireworks @ end.
The SDL_Delay call I had add as berlios version, for reason state 
before, no real good reason why not to use.  It only does that when 
menu calls are up.  I see no way to 'skip' when create patch.

notes, there is bug someplace else also about fireworks.  For now, 
it seem to work fine for players >=3.  I only test skirmish.  So 
please reports if you see fireworks when win in MP or skirmish 
games now.





Index: src/mission.c
===
--- src/mission.c   (revision 1626)
+++ src/mission.c   (working copy)
@@ -3535,11 +3535,11 @@
intRemoveMissionResultNoAnim();
}*/
 // intRemoveMissionResultNoAnim();
-
-if (bMultiPlayer)
-{
-intRemoveMissionResultNoAnim();
-}
+//Unknown why below was needed??
+//if (bMultiPlayer)
+//{
+//intRemoveMissionResultNoAnim();
+//}
 }
 
 void intProcessMissionResult(UDWORD id)
Index: src/wrappers.c
===
--- src/wrappers.c  (revision 1626)
+++ src/wrappers.c  (working copy)
@@ -268,6 +268,7 @@
&& keyPressed(KEY_RETURN)) {
screenToggleMode();
}
+   SDL_Delay(30);  //To release CPU when menu are up.
return RetCode;
 }
 
@@ -412,7 +413,7 @@
 
// this bit decides whether to auto quit to front end.
//if(!getDebugMappingStatus())
-   if(!bMultiPlayer)
+// if(!bMultiPlayer)
{
if(bDidit)
{

--
Click to find great rates on life insurance, save big, shop here
http://tagline.hushmail.com/fc/Ioyw6h4d8MKqJxS6q0gTDzFqQW4MFnETYpwFhtFmFe7QvFs1lLmJCO/



___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] [Warzone-commits] r1482 - in /trunk/tools/blender: ./ COPYING pie_export.py pie_import.py

[Gerard Krol]

Dennis Schridde wrote:
> Am Freitag, 8. Juni 2007 schrieb Gerard Krol:
>   
>> Author: gerard_
>> Date: Fri Jun  8 20:05:16 2007
>> New Revision: 1482
>>
>> URL: http://svn.gna.org/viewcvs/warzone?rev=1482&view=rev
>> Log:
>> PIE import and export scripts. The import script is adapted from Rodzilla.
>> Place these in your ~/.blender/scripts folder and enjoy. Supported:
>> connectors, team colors (using a second UV layer). Not supported:
>> animations of any kind.
>> 
> Are float vertex-/uv-data supported? From looking at the sourcecode this 
> seems 
> not to be the case.
>   
It doesn't support them, which has as an advantage that it can be used 
to create models for the 2.0 releases.
Adding float support should be a matter of minutes.

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Oil anim fix patch

[Gerard Krol]

My intention was "Now only transparent objects are rendered by the bucket 
sort". (as it doesn't have any benefit for solid ones)
The moving health bar was a side effect which I didn't notice. Again rendering 
animated components using the bucket sort is not what we want.

I would suggest fixing renderAnimComponent so that it doesn't have this 
side-effect.
(maybe pushing/popping the transform matrix)

- Gerard

PS. I'm quite busy at the moment, so please don't expect too much input from me.

-Original Message-
From: [EMAIL PROTECTED] on behalf of Per Inge Mathisen
Sent: Sat 2-6-2007 22:31
To: Development list
Subject: Re: [Warzone-dev] Oil anim fix patch
 
On 6/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> So patch good or not?

I am curious as to why it is correct, and what else might break, not
just whether it fixes the bug. I see that gerard changed it in r1007:


r1007 | gerard_ | 2007-04-05 17:24:03 +0200 (Thu, 05 Apr 2007) | 2 lines

1. Now only transparent objects are rendered by the bucket sort. 2.
Added some asserts to check if droids stay on the map.

@@ -1891,7 +1851,7 @@
psComp->orientation.y = vecRot.y;
psComp->orientation.z = vecRot.z;

-   bucketAddTypeToList( RENDER_ANIMATION, psComp );
+   renderAnimComponent( psComp );
}
}
 }

Gerard, any comment on how this should be fixed?

  - Per

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] [Warzone-commits] r1164 -/trunk/lib/ivis_opengl/screen.c

[Gerard Krol]

This is interesting, in C++ mode MSVC seems to be almost C99 compatible:

http://groups.google.nl/group/comp.lang.c/browse_thread/thread/dbb0628227294c59/231a8816e8e87e3e

Could someone test this?

- Gerard

-Original Message-
From: [EMAIL PROTECTED] on behalf of Per Inge Mathisen
Sent: Mon 23-4-2007 21:57
To: Development list
Subject: Re: [Warzone-dev] [Warzone-commits] r1164 
-/trunk/lib/ivis_opengl/screen.c
 
In 4/23/07, Giel van Schijndel <[EMAIL PROTECTED]> wrote:
> Well a very good reason: readability and ease of maintenance.

Ease of maintenance also means making it easy for people to use tools
they are used to. For good or bad (as you see it), MSVC is in active
use, and so should not be broken by patches.

  - Per

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] BSPIMD and PIETOOL

[Gerard Krol]

The BSP's are not used anywhere in the actual rendering code, so any change in 
fps should be impossible.

The PIETOOL defines can be dropped.

- Gerard

-Original Message-
From: [EMAIL PROTECTED] on behalf of Per Inge Mathisen
Sent: Mon 23-4-2007 20:08
To: Development list
Subject: [Warzone-dev] BSPIMD and PIETOOL
 
I would like to dump support for the BSP part of IMDs. It was
introduced to speed up Warzone on the PSX, as far as I can tell, and
it does nothing to speed things up on my box. Try it yourself by
commenting out the #define BSPIMD line in lib/ivis_common/ivisdef.h
header. By removing it, we can simplify the PIE format, and work
towards the goal of making it more easy to use with 3D hardware
acceleration.

I would also like to dump the PIETOOL defines. I think this was only
used by the pie tools, whose primary function was, as far as I can
tell, to generate the BSP tables for PIE files.

Any objections?

  - Per

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] [Fwd: Compilation error at generated resource_parser.tab.h]

[Gerard Krol]

Kamaze wrote:
>  Original-Nachricht 
> From: - Mon Apr 09 13:31:27 2007
> Date: Sun, 8 Apr 2007 21:50:33 -0300
> From: Alejandro Pulver <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Compilation error at generated resource_parser.tab.h
> Mime-Version: 1.0
> Content-Type: multipart/signed; 
> boundary="Sig_fuYRTC9U2JBLiKWwDVejF=n"; 
> protocol="application/pgp-signature"; micalg=PGP-SHA1
>
> Hello.
>
> I maintain the FreeBSD port (it's like a Gentoo .ebuild) of Warzone
> 2100, and when I was updating it to the 2.0.6 version I got an error.
>
> The configure/make output and generated resource_parser.tab.h are
> attached.
>
> If you need more information I will provide it.
>
> Do you know how to solve this?
You need to use a more recent version of Bison. It seems that at least 
version 2 is needed.
Double check that you are invoking the correct version of Bison.
Take a look at: http://wz2100.net/wiki/development:compile_guide_freebsd

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] [Warzone-commits] r1032 - in /trunk: lib/framework/ lib/netplay/ lib/sound/ src/

[Gerard Krol]

Giel van Schijndel wrote:
> Gerard Krol schreef:
>   
>> Author: gerard_
>> Date: Sat Apr  7 15:23:14 2007
>> New Revision: 1032
>>
>> ...
>> 4. Commented out some unused sound code. I just love Valgrind :)
>> 
> There's no need to comment out code, in fact it probably is better to
> simply remove it. If we or anyone ever need that code back, then
> Subversion can retrieve it.
>
> Reverse difference merging of a revision can do it for example: `svn
> merge -r500:499` will reverse all changes made in revision 500 and apply
> them to your local working copy. So as long as you make a note of what
> it is you removed in your commit log it should be fine.
>
> Cluttering the codebase with commented out code probably is worse than
> ever needing to track down a revision in which some part of code was
> removed.
>   
Fine, I'll remove it then.
> Plus your way of commenting out code (#if 0;#endif) isn't very easy to
> spot and recognize as disabled code.
>   
This is the recommended way to comment out code though. /* */ don't 
properly nest.

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Video support

[Gerard Krol]

Constantine Pokrovsky wrote:

Hi. I have reversed the video decompressor. Please, give me some
information how to implement the rendering mechanism in the best way.
I suppose you mean the decoder for the RPL format? That's quite an 
achievement, but I'm afraid that does not help us in any way. The 
original video's were not released under the GPL, and we will thus not 
be adding any support for them.


This does not mean we will do entirely without FMV's however, as I am 
working on a new sequence system that already supports OGG/Theora. This 
will however only be used to play "free" (as in freedom) movies.


For more information about the FMV's I suggest to take a look at this 
forum thread: http://wz2100.net/forum/index.php?topic=458.0


- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] rev 970 breaks at end of mission 1 (crash)

[Gerard Krol]

I had this too, but not anymore with the old memory system ripped out.
Could you try current svn trunk and see if the crash still occurs?

- Gerard

The Watermelon wrote:
On 4/2/07, [EMAIL PROTECTED] * 
<[EMAIL PROTECTED] > wrote:


On Mon, 02 Apr 2007 04:26:39 -0400 The Watermelon
<[EMAIL PROTECTED] > wrote:
>this problem usually happens when objects are incompatible with
>each
>other,try doing a cleanup and full-recompile and see if this cures
>the
>problem.It might be a bug if cleanup and full-recompile dont fix
>it...

Did a clean, then recompile, same thing.

Warzone2100-Dbg.exe!memBlockCmp(void * key1=0x0013ede4, void *
key2=0x0013)  Line 143 + 0x3 bytes  C
   Warzone2100-Dbg.exe!treapFindRec(_treap_node *
psRoot=0x0343a468,
void * key=0x0013ede4, int (void *, void *)* cmp=0x0054a579)  Line
314 + 0xf bytes C
   Warzone2100-Dbg.exe!blkPointerValid(_block_heap *
psHeap=0x01659750, void * pData=0x031307ec, int size=872)  Line 587
+ 0x15 bytesC
   Warzone2100-Dbg.exe!blkPointerValidAll(void * pData=0x031307ec,
int size=872)  Line 612 + 0x11 bytesC
   Warzone2100-Dbg.exe!memPointerValid(void * pPtr=0x031307ec,
unsigned int size=872)  Line 385 + 0xd bytesC
   Warzone2100-Dbg.exe!droidUnderRepair(_droid *
psDroid=0x031307ec)
Line 5943 + 0xe bytes  C
   Warzone2100-Dbg.exe!drawDroidSelections()  Line 3636 + 0x35
bytes
C
   Warzone2100-Dbg.exe!draw3DScene ()  Line 416 C
   Warzone2100-Dbg.exe!displayWorld()  Line 1628   C
   Warzone2100-Dbg.exe!addIntelScreen()  Line 6904 C
   Warzone2100-Dbg.exe!displayImmediateMessage(_message *
psMessage=0x083dfb60)  Line 2143C
   Warzone2100-Dbg.exe!scrAddMessage()  Line 1380 + 0x9
bytes  C
   Warzone2100-Dbg.exe!interpRunScript(_script_context *
psContext=0x031ad250, _interp_runtype runType=IRT_EVENT, unsigned
int index=3, unsigned int offset=0)  Line 780 + 0x8 bytes   C
   Warzone2100-Dbg.exe!eventFireCallbackTrigger(_trigger_type
callback=TR_CALLBACKSTART)  Line 1077 + 0x1e bytes  C
   Warzone2100-Dbg.exe!stageThreeInitialise()  Line 1839 + 0x7
bytes
C
   Warzone2100-Dbg.exe!levLoadData(char * pName=0x00e21180, char *
pSaveName=0x, int saveType=0)  Line 1137 + 0x5 bytesC
   Warzone2100-Dbg.exe!SDL_main(int argc=2, char * *
argv=0x0013fdb8)  Line 577 + 0xe bytes  C
   Warzone2100-Dbg.exe!_main()  + 0xd1 bytes   C
   [EMAIL PROTECTED]()  + 0x1ed bytesC
   Warzone2100-Dbg.exe!__tmainCRTStartup()  Line 589 + 0x35
bytes  C
   Warzone2100-Dbg.exe!WinMainCRTStartup ()  Line 414   C
   kernel32.dll!7c816fd7()
   [Frames below may be incorrect and/or missing, no symbols
loaded
for kernel32.dll]

 
weird,does it crash at the start of the game or after loading a 
save?seems the callstack is pointing to droid selection event function




___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] patch 835 is not right?

[Gerard Krol]

[EMAIL PROTECTED] wrote:
On Sun, 04 Mar 2007 05:26:09 -0500 Gerard Krol 
<[EMAIL PROTECTED]> wrote:
  

[EMAIL PROTECTED] wrote:


The patch in 835 which is (i think),
pimemode.c:void pie_ScreenFlip(CLEAR_MODE clearMode)
	if (screen_GetBackDrop()) { screen_Upload(NULL);} 


Is wrong.
  
  

I don't hope so, that was my first commit ;)

This breaks shadows & backdrops.  You can tell instant at 
  

CAM_3A.

  
  
Breaks shadows? That would be most unlikely. I noticed that the 
transporters shadows were not exactly right (they do not reach all 
the 
way to the ground at first), but that was already so in 834.

What backdrops are broken? Could you post a screenshot?

Note: I tested this using --game CAM_3A

I can not check if loop.c is wrong, GNA is too busy and can not 
  
do 


diff!
:(
  
  
I'm having no problems with GNA here, but maybe they are already 
over. 
The only modifications in loop.c are in the videoloop, so they 
"should" 
have no effect on other parts of the game. (sadly, with the 
current code 
this is not always the case)


- Gerard



Here is shot.

http://img460.imageshack.us/my.php?image=wz2100shot005vu8.jpg

Look at shadows in relation of object.  Then background bleed 
through.
  
Are you sure this wasn't so before? I checked it again and shadows look 
fine here.

Could you try "svn update -r834" to check it?

Reason is that callsglDisable(GL_DEPTH_TEST), and   
glDepthMask(GL_FALSE)
  

I doubt that

So you need to make new function to leave on those.
  
Please try the attached patch, it fixes the only thing I can think of 
that may cause the difference.


- Gerard
Index: lib/ivis_opengl/piemode.c
===
--- lib/ivis_opengl/piemode.c	(revision 844)
+++ lib/ivis_opengl/piemode.c	(working copy)
@@ -135,7 +135,7 @@
 			break;
 		case CLEAR_BLACK:
 			glDepthMask(GL_TRUE);
-			glClearColor(0.0f,0.0f,0.0f,0.0f);
+			glClearColor(0.0f,0.0f,0.0f,1.0f);
 			glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
 			break;
 		default:
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] patch 835 is not right?

[Gerard Krol]

[EMAIL PROTECTED] wrote:

The patch in 835 which is (i think),
pimemode.c:void pie_ScreenFlip(CLEAR_MODE clearMode)
	if (screen_GetBackDrop()) { screen_Upload(NULL);} 


Is wrong.
  

I don't hope so, that was my first commit ;)

This breaks shadows & backdrops.  You can tell instant at CAM_3A.
  
Breaks shadows? That would be most unlikely. I noticed that the 
transporters shadows were not exactly right (they do not reach all the 
way to the ground at first), but that was already so in 834.

What backdrops are broken? Could you post a screenshot?

Note: I tested this using --game CAM_3A
I can not check if loop.c is wrong, GNA is too busy and can not do 
diff!

:(
  
I'm having no problems with GNA here, but maybe they are already over. 
The only modifications in loop.c are in the videoloop, so they "should" 
have no effect on other parts of the game. (sadly, with the current code 
this is not always the case)


- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] New developer with svn access

[Gerard Krol]

Kamaze wrote:

Gerard, are you "gerard_" in the forums?
If yes, can/should i rename your account to "Gerard"? :)
  
Thanks, but gerard_ is fine. I try to keep the amount of usernames I 
need to remember to a minimum, and my Gna account is also gerard_.


- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] [patch #687] TRUNK (r828) build broken

[Gerard Krol]

URL:
  

 Summary: TRUNK (r828) build broken
 Project: Warzone Resurrection Project
Submitted by: gerard_
Submitted on: Tuesday 02/27/2007 at 20:37
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The current trunk (r828) build complains about unresolved PhysFS symbols.
This is caused by the -lphysfs parameter not being passed to the linker, and
the problem originates in the autoconf script.

/blame devurandom



___

File Attachments:


---
Date: Tuesday 02/27/2007 at 20:37  Name: libs.patch  Size: 441B   By: gerard_



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] [patch #686] Improved mission briefing "movie"

[Gerard Krol]

Maybe we can set up some automatic forwarding to the mailing list?

- Gerard

URL:
 

Summary: Improved mission briefing "movie"
Project: Warzone Resurrection Project
   Submitted by: gerard_
   Submitted on: Monday 02/26/2007 at 00:05
   Category: None
   Priority: 5 - Normal
 Status: None
Privacy: Public
Assigned to: None
   Originator Email: 
Open/Closed: Open

Discussion Lock: Any

   ___

Details:

After this patch warzone just plays the text, without large pauses between
where something happens in the movie. This makes it a lot less boring.

The mission 1 movie now also shows a "mission briefing" at the end, which was
previously not shown.

I also removed:
/*Initialise the video playback buffer*/
if (!seq_SetupVideoBuffers()) { ... }
to shave off 1.5 seconds of the mission loading time. The function is not
needed anyway.

- Gerard



   ___

File Attachments:


---
Date: Monday 02/26/2007 at 00:05  Name: briefing.patch  Size: 5kB   By:
gerard_



   ___

Reply to this item at:

 

___
 Message sent via/by Gna!
 http://gna.org/



___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] [Fwd: warzone2100-2.0.5 fails to compileon Gentoo/amd64]

[Gerard Krol]

Dennis Schridde wrote:

Am Montag, 26. Februar 2007 schrieb Giel van Schijndel:
  
On Mon, 26 Feb 2007 11:37:13 +0100, Gerard Krol 


<[EMAIL PROTECTED]> wrote:
  

Kamaze wrote:
  

 Original-Nachricht 
Betreff: warzone2100-2.0.5 fails to compile on Gentoo/amd64
Datum: Mon, 26 Feb 2007 00:34:24 +0300
Von: Dmitrij Czarkoff <[EMAIL PROTECTED]>
An: [EMAIL PROTECTED]

Tried to compile warzone2100 on my amd64 machine (both via portage and
manually). After autogen.sh and configure run OK it fails to make. See
the log (make -dk --warn-undefined-variables &> ../warzone2100.log)
attached.

About my computer:
CPU: Turion64 MT28
Chipset: ATi RX480M + ATi SB400
RAM: 1Gb (I don't know vendor, but no bugs were discovered)
OS: Gentoo

I've got all the demands (as listed in COMPILE instruction) met. As
You don't name the versions of software needed, I'm reporting mines
(output of emerge -pv):

[ebuild   R   ] sys-devel/autoconf-2.61  USE="-emacs" 0 kB
[ebuild   R   ] sys-devel/gcc-4.1.2  USE="gtk nls (-altivec)
-bootstrap -build -doc -fortran -gcj (-hardened) -ip28 -ip32r10k
-mudflap (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++
-objc-gc -test -vanilla" 0 kB
[ebuild   R   ] sys-devel/make-3.81  USE="nls -static" 0 kB
[ebuild   R   ] media-libs/libsdl-1.2.11-r1  USE="X aalib alsa opengl
xv -arts -dga -directfb -esd -fbcon -ggi -libcaca -nas -noaudio
-noflagstrip -nojoystick -novideo -oss (-svga) -xinerama" 0 kB
[ebuild   R   ] media-libs/sdl-net-1.2.6  0 kB
[ebuild   R   ] media-libs/libvorbis-1.1.2  USE="-aotuv" 0 kB
[ebuild   R   ] media-libs/libmad-0.15.1b-r2  USE="-debug" 0 kB
[ebuild   R   ] sys-libs/zlib-1.2.3-r1  USE="-build" 0 kB
[ebuild   R   ] dev-games/physfs-1.0.1  0 kB
[ebuild   R   ] media-libs/openal-0.0.8-r1  USE="alsa mp3 sdl vorbis
-arts -debug -esd" 0 kB
[ebuild   R   ] media-libs/libpng-1.2.16  USE="-doc" 0 kB
[ebuild   R   ] media-libs/jpeg-6b-r8  0 kB

What could be the problem here?


Your link command line:

gcc  -g -O2  -DNDEBUG -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT
-I/usr/X11R6/include/SDL -m32 -DYY_STATIC
-DDEFAULT_DATADIR=\"/usr/local/share/warzone2100\"   

Notice the -m32? You are compiling warzone to a 32 bit executable. Now

look at this:
  

/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/b
in/ld: skipping incompatible /usr/X11R6/lib/libphysfs.so when searching
for -lphysfs
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/b
in/ld: skipping incompatible /usr/X11R6/lib/libphysfs.a when searching
for -lphysfs
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/b
in/ld: skipping incompatible
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../libphysfs.so when
searching for -lphysfs
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/b
in/ld: skipping incompatible
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../libphysfs.a when
searching for -lphysfs
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/b
in/ld: skipping incompatible /usr/lib/libphysfs.so when searching for
-lphysfs
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/b
in/ld: skipping incompatible /usr/lib/libphysfs.a when searching for
-lphysfs
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/b
in/ld: cannot find -lphysfs


You seem to have the 64 bit lib of physfs.

I suggest you just compile warzone for 64 bit (so without the -m32),
works fine for me (amd64, Debian).
  

Also keep in mind that the linker commandline isn't the only one containing
-m32, every single source file is compiled with that.



Also keep in mind that Warzone 2.0 can not be compiled for 64bit. Even a 
binary compiled from current svn will crash at some point, afaik.
If you want to play it and not go into fixing 64bit bugs, the best is probably 
to create a 32bit system. I thought Gentoo did that automatically on 
x86_64...
  
FYI, Warzone works fine on 64 bit. There are commercial games that crash 
more often.


- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] [Fwd: warzone2100-2.0.5 fails to compile on Gentoo/amd64]

[Gerard Krol]

Kamaze wrote:

 Original-Nachricht 
Betreff: warzone2100-2.0.5 fails to compile on Gentoo/amd64
Datum: Mon, 26 Feb 2007 00:34:24 +0300
Von: Dmitrij Czarkoff <[EMAIL PROTECTED]>
An: [EMAIL PROTECTED]

Tried to compile warzone2100 on my amd64 machine (both via portage and
manually). After autogen.sh and configure run OK it fails to make. See
the log (make -dk --warn-undefined-variables &> ../warzone2100.log)
attached.

About my computer:
CPU: Turion64 MT28
Chipset: ATi RX480M + ATi SB400
RAM: 1Gb (I don't know vendor, but no bugs were discovered)
OS: Gentoo

I've got all the demands (as listed in COMPILE instruction) met. As
You don't name the versions of software needed, I'm reporting mines
(output of emerge -pv):

[ebuild   R   ] sys-devel/autoconf-2.61  USE="-emacs" 0 kB
[ebuild   R   ] sys-devel/gcc-4.1.2  USE="gtk nls (-altivec)
-bootstrap -build -doc -fortran -gcj (-hardened) -ip28 -ip32r10k
-mudflap (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++
-objc-gc -test -vanilla" 0 kB
[ebuild   R   ] sys-devel/make-3.81  USE="nls -static" 0 kB
[ebuild   R   ] media-libs/libsdl-1.2.11-r1  USE="X aalib alsa opengl
xv -arts -dga -directfb -esd -fbcon -ggi -libcaca -nas -noaudio
-noflagstrip -nojoystick -novideo -oss (-svga) -xinerama" 0 kB
[ebuild   R   ] media-libs/sdl-net-1.2.6  0 kB
[ebuild   R   ] media-libs/libvorbis-1.1.2  USE="-aotuv" 0 kB
[ebuild   R   ] media-libs/libmad-0.15.1b-r2  USE="-debug" 0 kB
[ebuild   R   ] sys-libs/zlib-1.2.3-r1  USE="-build" 0 kB
[ebuild   R   ] dev-games/physfs-1.0.1  0 kB
[ebuild   R   ] media-libs/openal-0.0.8-r1  USE="alsa mp3 sdl vorbis
-arts -debug -esd" 0 kB
[ebuild   R   ] media-libs/libpng-1.2.16  USE="-doc" 0 kB
[ebuild   R   ] media-libs/jpeg-6b-r8  0 kB

What could be the problem here?

  

Your link command line:

gcc  -g -O2  -DNDEBUG -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT 
-I/usr/X11R6/include/SDL -m32 -DYY_STATIC 
-DDEFAULT_DATADIR=\"/usr/local/share/warzone2100\"   


Notice the -m32? You are compiling warzone to a 32 bit executable. Now 
look at this:


/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: 
skipping incompatible /usr/X11R6/lib/libphysfs.so when searching for 
-lphysfs
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: 
skipping incompatible /usr/X11R6/lib/libphysfs.a when searching for -lphysfs
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: 
skipping incompatible 
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../libphysfs.so when 
searching for -lphysfs
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: 
skipping incompatible 
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../libphysfs.a when 
searching for -lphysfs
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: 
skipping incompatible /usr/lib/libphysfs.so when searching for -lphysfs
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: 
skipping incompatible /usr/lib/libphysfs.a when searching for -lphysfs
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: 
cannot find -lphysfs


You seem to have the 64 bit lib of physfs.

I suggest you just compile warzone for 64 bit (so without the -m32), 
works fine for me (amd64, Debian).


- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Linux crashdumps

[Gerard Krol]

Per Inge Mathisen wrote:

On 2/22/07, Dennis Schridde <[EMAIL PROTECTED]> wrote:
[ lots of talking to himself ]

Using backtrace_symbols() gives you some more information, but it is
still very hard to read. It is nothing compared to the output given by
gdb. Anyway, you can see if by pasting this into your gdmp.c:

   char **result = backtrace_symbols(btBuffer, btSize);

   if (result != NULL) {
   int i;

   fprintf(stdout, "Backtrace with symbols:\n");
   for (i = 0; i < btSize; i++) {
   fprintf(stdout, "%i: %s\n", i, result[i]);
   }
   } else {
   fprintf(stderr, "backtrace_symbols failed");
   }

backtrace_symbols_fd() is safer, though. You must compile with -rdynamic

Also see "info Backtrace glibc". The best would be to automatically
connect gdb to the program and give a "bt full" dump. If you
automatically emailed that back to us, it would be an invaluable debug
aid, and a massive privacy violation ;-)

We could just ask the user if we can do that ;)
I once had an ASSERT macro that fired up GDB automagically, but I seem 
to have lost it. I searched my hard drive for invocations of GDB and 
noticed that the QT toolkit has a whole file with GDB calls. That might 
be usefull to look at.


http://www.google.com/codesearch?q=qcrashhandler.cpp
The original is written by Bjorn Reese:
http://www.google.com/codesearch?q=stacktrace.c+Bjorn+Reese

A Google code search for gdb+getpid also yields some interesting results:
http://www.google.com/codesearch?q=gdb+getpid

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Patch: removal of duplicate code

[Gerard Krol]

Per Inge Mathisen wrote:

On 2/17/07, Gerard Krol <[EMAIL PROTECTED]> wrote:

I went duplicate code hunting, and fixed these occurrences of
copy&paste. There are quite some more, but I leave those for another 
time.


I have been working on this, and committed parts of it, but it is a
real pain to check it for correctness.

Yeah, it is. Struggled with that myself too.

I see that the two functions
merged in src/display3d.c have differences, though, where one function
used buildingBrightness and another brightness, which are calculated
differently, while in the merged function, buildingBrightness only is
used.
Calculated differently? I just took another look at the code, and this 
does not seem to be the case. The value buildingBrightness is just 
abandoned at some point, and brightness is used.


It would be nice to know if such changes are intentional or not.
In principle the code should behave exactly as before. The only change I 
remember is that some value that has something to do with the muzzle 
flash that was different for the normal buildings and the defensive 
buildings. I supposed the value on the defensive buildings was updated 
at some time, and the value for the normal buildings was forgotten, so I 
made both normal and defensive buildings use the muzzle flash parameter 
from the defensive buildings.


- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Re: [Warzone-commits] r792 - in /trunk: lib/sound/track.c lib/sound/track.h src/data.c

[Gerard Krol]

Giel van Schijndel wrote:

Author: muggenhor
Date: Mon Feb 19 22:52:27 2007
New Revision: 792

URL: http://svn.gna.org/viewcvs/warzone?rev=792&view=rev
Log:
 * removed some redundant code from src/data.c:
  - the function dataAudioLoad first checked whether the audio system is 
disabled and if it is sets return buffer (*ppData) to NULL, even though this 
functionality is already performed by the function it calls 
(audio_LoadTrackFromBuffer)
  
Well, you made a little mistake there. The function is supposed to 
return FALSE ONLY when an error occurs. Returning FALSE causes for me:


error:  resLoad: failed to parse wrf/frontend.wrf
error:  Shutting down after failure

And you also made it return FALSE when sound is disabled. The attached 
patch corrects this, and also removes the redundant function 
audio_LoadTrackFromBuffer which was only a very thin wrapper for 
sound_LoadTrackFromBuffer. The check if sound is enabled is again in 
dataAudioLoad.


- Gerard
Index: src/data.c
===
--- src/data.c	(revision 792)
+++ src/data.c	(working copy)
@@ -989,13 +989,16 @@
 /* Load an audio file */
 BOOL dataAudioLoad(char *pBuffer, UDWORD size, void **ppData)
 {
-	// If audio is disabled or a track can't be constructed the return value will be NULL
-	*ppData = audio_LoadTrackFromBuffer( pBuffer, size );
+	if ( audio_Disabled() == TRUE )
+	{
+		*ppData = NULL;
+		// No error occurred (sound is just disabled), so we return TRUE
+		return TRUE;
+	}
+// Load the track from a file
+	*ppData = sound_LoadTrackFromBuffer( pBuffer, size );
 
-	if (*ppData == NULL)
-		return FALSE;
-
-	return TRUE;
+	return *ppData != NULL;
 }
 
 void dataAudioRelease( void *pData )
Index: lib/sound/audio.c
===
--- lib/sound/audio.c	(revision 792)
+++ lib/sound/audio.c	(working copy)
@@ -614,23 +614,8 @@
 }
 
 //*
-// ===
-// ===
 //
-TRACK *audio_LoadTrackFromBuffer(char *pBuffer, UDWORD udwSize)
-{
-	// if audio not enabled return TRUE to carry on game without audio
-	if ( g_bAudioEnabled == FALSE )
-	{
-		return NULL;
-	}
 
-	return sound_LoadTrackFromBuffer( pBuffer, udwSize );
-}
-
-//*
-//
-
 // Routine to convert wav filename into a track number
 // ... This is really not going to be practical on the PSX is it?
 //
Index: lib/sound/audio.h
===
--- lib/sound/audio.h	(revision 792)
+++ lib/sound/audio.h	(working copy)
@@ -36,7 +36,6 @@
 extern BOOL		audio_Disabled( void );
 
 extern BOOL		audio_LoadTrackFromFile( char szFileName[] );
-extern TRACK *	audio_LoadTrackFromBuffer(char *pBuffer, UDWORD udwSize);
 extern BOOL		audio_SetTrackVals( char szFileName[], BOOL bLoop, int *piID,
 	int iVol, int iPriority, int iAudibleRadius );
 extern BOOL		audio_SetTrackValsHashName( UDWORD hash, BOOL bLoop, int iTrack, int iVol,
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

RE: [Warzone-dev] Evaluate AngelScript as an alternative to lua?

[Gerard Krol]

I'd say we'd better use a more mature alternative, as Lua or Python.

A little comparison:

Anglescript, call script function from C:
http://www.angelcode.com/angelscript/sdk/docs/manual/pages/man_callscriptfunc.html
Anglescript, call C function from script:
no clear example found

Python, call script function from C:
http://docs.python.org/ext/pure-embedding.html
Needs quite some code. (but the example is quite complete)
Python, call C function from script:
http://docs.python.org/ext/extending-with-embedding.html
Really easy

Lua, call script function from C:
http://www.lua.org/manual/2.1/subsection3_7_6.html
Clear
Lua, call C function from script:
http://www.lua.org/pil/26.1.html
Clear

Please judge for yourself, but Python has my preference, as I have quite a lot 
of experience with the language.

- Gerard



-Original Message-
From: [EMAIL PROTECTED] on behalf of Kamaze
Sent: Wed 21-2-2007 0:11
To: Development list
Subject: [Warzone-dev] Evaluate AngelScript as an alternative to lua?
 
Website:
http://www.angelcode.com/angelscript/

Infos:
http://www.angelcode.com/angelscript/features.asp

I read a bit about it and played a bit around with it.
It looks clean, fast, small and stable. And has a c/c++ syntax.
Binding of functions and vars seems to be very easy.

Maybe you/we should make a closer look to it :)

- Kamaze

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

<>___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Patch: Nicer water

[Gerard Krol]

Dennis Schridde wrote:

Am Samstag, 17. Februar 2007 schrieb Gerard Krol:
  

By tweaking 2 lines the water really improves a lot!
4p-Sk-FishNets is a good map to test.

- Gerard



I applied it in my local copy...
Nice in general, but the alpha change should be done to the texture and not in 
the code, IMO... Eg. Grim's textures have a good alpha setting for water, 
which makes them look ugly with these changes...
  
I agree that doing the alpha in the textures is better, much more 
flexibility that way.
Maybe you could only apply the second change? That improves the 
riverbeds alot in my opinion. The alpha in the texture pages can then 
come some later time.


By the way, why aren't grims textures in svn? I might want to improve on 
some textures too, and it would nice to be able to continue from his work.


- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Patch: (well sort of) tertiles texture pages

[Gerard Krol]

Hi,

The data/texpages/tertiles* texture pages were messed up because someone 
just enlarged the whole image. This caused tiles to bleed into adjacent 
ones. I retrieved the original files from the Berlios repository and 
scaled those tile by tile using a self written Python script. If any 
other texturepages need resizing I can do those easily as well.


The new texpages can be found at 
http://www.uploadtemple.com/view.php/1171751085.gz

(8.7 MB)

Regards,

Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Patch: removal of duplicate code

[Gerard Krol]

Hi,

I went duplicate code hunting, and fixed these occurrences of 
copy&paste. There are quite some more, but I leave those for another time.


- Gerard

PS. Patches pending commit: fog.patch (2007-2-10)


duplicates.patch.gz
Description: GNU Zip compressed data
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Patch: Nicer water

[Gerard Krol]

By tweaking 2 lines the water really improves a lot!
4p-Sk-FishNets is a good map to test.

- Gerard
Index: src/display3d.c
===
--- src/display3d.c	(revision 774)
+++ src/display3d.c	(working copy)
@@ -120,10 +120,10 @@
 
 #define WATER_TILE 17			// ID of water tile.
 #define BED_TILE 5// ID of river bed tile.
-#define WATER_ALPHA_LEVEL 255 //was 164	// Amount to alpha blend water.
+#define WATER_ALPHA_LEVEL 164 // Amount to alpha blend water.
 #define WATER_ZOFFSET 32		// Sorting offset for main water tile.
 #define WATER_EDGE_ZOFFSET 64	// Sorting offset for water edge tiles.
-#define WATER_DEPTH	127			// Amount to push terrain below water.
+#define WATER_DEPTH	60			// Amount to push terrain below water.
 
 /  Prototypes  /
 // TODO: Declare as many static as possible.
@@ -891,7 +891,7 @@
 	{
 		// Push the terrain down for the river bed.
 		PushedDown = TRUE;
-	 	shiftVal = WATER_DEPTH + ((3*environGetData(playerXTile+j,playerZTile+i))/2);
+	 	shiftVal = WATER_DEPTH + ((environGetData(playerXTile+j,playerZTile+i))/4);
 		altVal = 0;//environGetValue(playerXTile+j,playerZTile+i);
 		tileScreenInfo[i][j].y -= (shiftVal+altVal);
 		// And darken it.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Please apply this patch

[Gerard Krol]

Giel van Schijndel wrote:

Giel van Schijndel schreef:
  

Gerard Krol schreef:
  


I know I only posted it only 4 days ago, but I really sleep better
when I know my patches have been applied. Could someone apply this
patch? I even polished it a little bit more.

This patch prevents a segfault when designing a droid on amd64.
Reproduce: on amd64, go to the droid design screen and design a
construction droid. Then hover your mouse over another system, like
sensor or command.

Regards,

Gerard

  

Applied in r750.

Hope you did sleep well enough those 4 days? Anyway I'm hoping you'll
sleep better now again  ;-) .


Sorry, I haven't looked at your latest patch until after committing the
previous one.

Anyway your latest version looks a bit ugly to me. There's an awfully
large amount of casts in there, not to mention that your insertion of
that switch statement uses the variable `type` which at that point isn't
yet initialized => undefined behaviour.
  

Oops, I guess that must be a copy-paste error.

Plus I'm not quite sure what the difference is between the first and
second patch. Not meaning to offend you though.
  
I just noticed that my patch created a lot of warnings (16) about 
'warning: initialization from incompatible pointer type'. The second 
patch was a quick attempt to solve that problem. A little too quick as 
it seems.


I tought about it a little and the attached patch avoids the casting 
problem and also doesn't give the warnings.


- Gerard
Index: src/design.c
===
--- src/design.c	(revision 762)
+++ src/design.c	(working copy)
@@ -3615,14 +3615,14 @@
 	UDWORDpower, i;
 
 	if (psStats != NULL) {
-COMP_BASE_STATS* bodyStats = asBodyStats + sCurrDesign.asParts[COMP_BODY];
-COMP_BASE_STATS* brainStats = asBrainStats + sCurrDesign.asParts[COMP_BRAIN];
-COMP_BASE_STATS* sensorStats = asSensorStats + sCurrDesign.asParts[COMP_SENSOR];
-COMP_BASE_STATS* ECMStats = asECMStats + sCurrDesign.asParts[COMP_ECM];
-COMP_BASE_STATS* repairStats = asRepairStats + sCurrDesign.asParts[COMP_REPAIRUNIT];
-COMP_BASE_STATS* constructStats = asConstructStats + sCurrDesign.asParts[COMP_CONSTRUCT];
-COMP_BASE_STATS* propulsionStats = asPropulsionStats + sCurrDesign.asParts[COMP_PROPULSION];
-COMP_BASE_STATS* weaponStats = asWeaponStats + sCurrDesign.asWeaps[0];
+UDWORD bodyPower= (asBodyStats + sCurrDesign.asParts[COMP_BODY])->buildPower;
+UDWORD brainPower   = (asBrainStats + sCurrDesign.asParts[COMP_BRAIN])->buildPower;
+UDWORD sensorPower  = (asSensorStats + sCurrDesign.asParts[COMP_SENSOR])->buildPower;
+UDWORD ECMPower = (asECMStats + sCurrDesign.asParts[COMP_ECM])->buildPower;
+UDWORD repairPower  = (asRepairStats + sCurrDesign.asParts[COMP_REPAIRUNIT])->buildPower;
+UDWORD constructPower   = (asConstructStats + sCurrDesign.asParts[COMP_CONSTRUCT])->buildPower;
+UDWORD propulsionPower  = (asPropulsionStats + sCurrDesign.asParts[COMP_PROPULSION])->buildPower;
+UDWORD weaponPower  = (asWeaponStats + sCurrDesign.asWeaps[0])->buildPower;
 
 
 		type = statType(psStats->ref);
@@ -3662,25 +3662,25 @@
 		switch (type)
 		{
 		case COMP_BODY:
-			bodyStats = psStats;
+			bodyPower = psStats->buildPower;
 			break;
 		case COMP_PROPULSION:
-			propulsionStats = psStats;
+			propulsionPower = psStats->buildPower;
 			break;
 		case COMP_ECM:
-			ECMStats = psStats;
+			ECMPower = psStats->buildPower;
 			break;
 		case COMP_SENSOR:
-			sensorStats = psStats;
+			sensorPower = psStats->buildPower;
 			break;
 		case COMP_CONSTRUCT:
-			constructStats = psStats;
+			constructPower = psStats->buildPower;
 			break;
 		case COMP_REPAIRUNIT:
-			repairStats = psStats;
+			repairPower = psStats->buildPower;
 			break;
 		case COMP_WEAPON:
-			weaponStats = psStats;
+			weaponPower = psStats->buildPower;
 			break;
 		//default:
 			//don't want to draw for unknown comp
@@ -3689,15 +3689,15 @@
 		// this code is from calcTemplatePower
 
 	//get the component power
-	power = bodyStats->buildPower + brainStats->buildPower + sensorStats->buildPower + ECMStats->buildPower + repairStats->buildPower + constructStats->buildPower;
+	power = bodyPower + brainPower + sensorPower + ECMPower + repairPower + constructPower;
 
 	/* propulsion power points are a percentage of the bodys' power points */
-	power += (propulsionStats->buildPower *
-		bodyStats->buildPower) / 100;
+	power += (propulsionPower *
+		bodyPower) / 100;
 		
  	//add weapon power
 // FIXME: Only takes first weapon into account
-power += weaponStats->buildPower;
+power += weaponPower;
 	for(i=1; ibuildPower;
@@ -3727,14 +3727,14

[Warzone-dev] Please apply this patch

[Gerard Krol]

I know I only posted it only 4 days ago, but I really sleep better when 
I know my patches have been applied. Could someone apply this patch? I 
even polished it a little bit more.


This patch prevents a segfault when designing a droid on amd64.
Reproduce: on amd64, go to the droid design screen and design a 
construction droid. Then hover your mouse over another system, like 
sensor or command.


Regards,

Gerard
Index: src/design.c
===
--- src/design.c	(revision 747)
+++ src/design.c	(working copy)
@@ -3612,13 +3612,43 @@
 static void intSetTemplatePowerShadowStats(COMP_BASE_STATS *psStats)
 {
 	UDWORDtype;
-	//SDWORDAvail, Used, Total;
-	DROID_TEMPLATE		compTempl;
 
-	if (&sCurrDesign != NULL && psStats != NULL)
-	{
-		//create the comparison Template
-		memcpy(&compTempl, &sCurrDesign, sizeof(DROID_TEMPLATE));
+	if (psStats != NULL) {
+BODY_STATS* bodyStats = asBodyStats + sCurrDesign.asParts[COMP_BODY];
+BRAIN_STATS* brainStats = asBrainStats + sCurrDesign.asParts[COMP_BRAIN];
+SENSOR_STATS* sensorStats = asSensorStats + sCurrDesign.asParts[COMP_SENSOR];
+ECM_STATS* ECMStats = asECMStats + sCurrDesign.asParts[COMP_ECM];
+REPAIR_STATS* repairStats = asRepairStats + sCurrDesign.asParts[COMP_REPAIRUNIT];
+CONSTRUCT_STATS* constructStats = asConstructStats + sCurrDesign.asParts[COMP_CONSTRUCT];
+PROPULSION_STATS* propulsionStats = asPropulsionStats + sCurrDesign.asParts[COMP_PROPULSION];
+WEAPON_STATS* weaponStats = asWeaponStats + sCurrDesign.asWeaps[0];
+		switch (type)
+		{
+		case COMP_BODY:
+			bodyStats = (BODY_STATS*)psStats;
+			break;
+		case COMP_PROPULSION:
+			propulsionStats = (PROPULSION_STATS*)psStats;
+			break;
+		case COMP_ECM:
+			ECMStats = (ECM_STATS*)psStats;
+			break;
+		case COMP_SENSOR:
+			sensorStats = (SENSOR_STATS*)psStats;
+			break;
+		case COMP_CONSTRUCT:
+			constructStats = (CONSTRUCT_STATS*)psStats;
+			break;
+		case COMP_REPAIRUNIT:
+			repairStats = (REPAIR_STATS*)psStats;
+			break;
+		case COMP_WEAPON:
+			weaponStats = (WEAPON_STATS*)psStats;
+			break;
+		//default:
+			//don't want to draw for unknown comp
+		}
+
 		type = statType(psStats->ref);
 		/*if type = BODY or PROPULSION can do a straight comparison but if the new stat is
 		a 'system' stat then need to find out which 'system' is currently in place so the
@@ -3648,43 +3678,56 @@
 			}
 			else
 			{
-type = COMP_UNKNOWN;
+			// compare it with the current weapon
+type = COMP_WEAPON;
 			}
 		}
 
 		switch (type)
 		{
 		case COMP_BODY:
-			compTempl.asParts[COMP_BODY] = (BODY_STATS *)psStats - asBodyStats;
+			bodyStats = (BODY_STATS*)psStats;
 			break;
 		case COMP_PROPULSION:
-			compTempl.asParts[COMP_PROPULSION] = (PROPULSION_STATS *)psStats -
-asPropulsionStats;
+			propulsionStats = (PROPULSION_STATS*)psStats;
 			break;
 		case COMP_ECM:
-			compTempl.asParts[COMP_ECM] = (ECM_STATS *)psStats - asECMStats;
+			ECMStats = (ECM_STATS*)psStats;
 			break;
 		case COMP_SENSOR:
-			compTempl.asParts[COMP_SENSOR] = (SENSOR_STATS *)psStats -
-asSensorStats;
+			sensorStats = (SENSOR_STATS*)psStats;
 			break;
 		case COMP_CONSTRUCT:
-			compTempl.asParts[COMP_CONSTRUCT] = (CONSTRUCT_STATS *)psStats -
-asConstructStats;
+			constructStats = (CONSTRUCT_STATS*)psStats;
 			break;
 		case COMP_REPAIRUNIT:
-			compTempl.asParts[COMP_REPAIRUNIT] = (REPAIR_STATS *)psStats -
-asRepairStats;
+			repairStats = (REPAIR_STATS*)psStats;
 			break;
 		case COMP_WEAPON:
-			compTempl.asWeaps[0] = (WEAPON_STATS *)psStats - asWeaponStats;
+			weaponStats = (WEAPON_STATS*)psStats;
 			break;
 		//default:
 			//don't want to draw for unknown comp
 		}
+		// this code is from calcTemplatePower
+	UDWORD power, i;
 
-		widgSetMinorBarSize( psWScreen, IDDES_POWERBAR,
-calcTemplatePower(&compTempl));
+	//get the component power
+	power = bodyStats->buildPower + brainStats->buildPower + sensorStats->buildPower + ECMStats->buildPower + repairStats->buildPower + constructStats->buildPower;
+
+	/* propulsion power points are a percentage of the bodys' power points */
+	power += (propulsionStats->buildPower *
+		bodyStats->buildPower) / 100;
+		
+ 	//add weapon power
+// FIXME: Only takes first weapon into account
+power += weaponStats->buildPower;
+	for(i=1; ibuildPower;
+	}
+   		widgSetMinorBarSize( psWScreen, IDDES_POWERBAR,
+power);
 	}
 	else
 	{
@@ -3705,12 +3748,18 @@
 static void intSetTemplateBodyShadowStats(COMP_BASE_STATS *psStats)
 {
 	UDWORDtype;
-	DROID_TEMPLATE		compTempl;
 
-	if (&sCurrDesign != NULL && psStats != NULL)
-	{
-		//create the comparison Template
-		memcpy(&compTempl, &sCurrDesign, sizeof(DROID_TEMPLATE));
+	if (psStats != NULL) {
+BODY_STATS* bodyStats = asBodyStats + sCurrDesign.asParts[COMP_BODY];
+BRAIN_STATS* brainStats = asBrainStats + sCurrDe

Re: [Warzone-dev] Patch: Severe pointer abuse in design.c (Finally a x86_64 bug! )

[Gerard Krol]

The Watermelon wrote:



On 2/10/07, *Gerard Krol* <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:


Hi all,

As some of you may know, power required and hit points of droid parts
are stored in central arrays. Individual body types are an index into
this array and are used like this:
(asBodyStats + psTemplate->asParts[COMP_BODY])->buildPower

The code in intSetTemplatePowerShadowStats and
intSetTemplateBodyShadowStats did store a pointer in this index by
using
the difference with the asBodyStats address, so that after this
addition
the correct address would magically reappear. Guilty code looks
like this:

compTempl.asParts[COMP_BODY] = (BODY_STATS *)psStats - asBodyStats;

Funny thing is: on 64bit: sizeof(SDWORD) < sizeof(void*)

In the attached patch, the calls to calcTemplatePower and
calcTemplateBody were removed, and the (simple) formula's used for
calculation were directly included in the two modified functions.

- Gerard

I think that kind of stuff is everywhere in the source,at least I saw 
multiple instances of 'weapId = psStats - asWeaponStats' or 'psStats = 
asWeaponStats + weaponId'.
In most of the case psStats points to an member of the array 
asWeaponStats. In that case weaponId is a small integer (0 to about a 
max of 40) and the code is correct.


The bug is by the way exposed if you design a new droid, put a system on 
it (sensor for example) and then hover your mouse over another system 
(like the construction unit). The game then segfaults.


- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Patch: Severe pointer abuse in design.c (Finally a x86_64 bug! )

[Gerard Krol]

Hi all,

As some of you may know, power required and hit points of droid parts 
are stored in central arrays. Individual body types are an index into 
this array and are used like this:

(asBodyStats + psTemplate->asParts[COMP_BODY])->buildPower

The code in intSetTemplatePowerShadowStats and 
intSetTemplateBodyShadowStats did store a pointer in this index by using 
the difference with the asBodyStats address, so that after this addition 
the correct address would magically reappear. Guilty code looks like this:


compTempl.asParts[COMP_BODY] = (BODY_STATS *)psStats - asBodyStats;

Funny thing is: on 64bit: sizeof(SDWORD) < sizeof(void*)

In the attached patch, the calls to calcTemplatePower and 
calcTemplateBody were removed, and the (simple) formula's used for 
calculation were directly included in the two modified functions.


- Gerard

Index: src/design.c
===
--- src/design.c	(revision 731)
+++ src/design.c	(working copy)
@@ -3612,13 +3612,18 @@
 static void intSetTemplatePowerShadowStats(COMP_BASE_STATS *psStats)
 {
 	UDWORDtype;
-	//SDWORDAvail, Used, Total;
-	DROID_TEMPLATE		compTempl;
 
-	if (&sCurrDesign != NULL && psStats != NULL)
-	{
-		//create the comparison Template
-		memcpy(&compTempl, &sCurrDesign, sizeof(DROID_TEMPLATE));
+	if (psStats != NULL) {
+COMP_BASE_STATS* bodyStats = asBodyStats + sCurrDesign.asParts[COMP_BODY];
+COMP_BASE_STATS* brainStats = asBrainStats + sCurrDesign.asParts[COMP_BRAIN];
+COMP_BASE_STATS* sensorStats = asSensorStats + sCurrDesign.asParts[COMP_SENSOR];
+COMP_BASE_STATS* ECMStats = asECMStats + sCurrDesign.asParts[COMP_ECM];
+COMP_BASE_STATS* repairStats = asRepairStats + sCurrDesign.asParts[COMP_REPAIRUNIT];
+COMP_BASE_STATS* constructStats = asConstructStats + sCurrDesign.asParts[COMP_CONSTRUCT];
+COMP_BASE_STATS* propulsionStats = asPropulsionStats + sCurrDesign.asParts[COMP_PROPULSION];
+COMP_BASE_STATS* weaponStats = asWeaponStats + sCurrDesign.asWeaps[0];
+
+
 		type = statType(psStats->ref);
 		/*if type = BODY or PROPULSION can do a straight comparison but if the new stat is
 		a 'system' stat then need to find out which 'system' is currently in place so the
@@ -3648,43 +3653,56 @@
 			}
 			else
 			{
-type = COMP_UNKNOWN;
+			// compare it with the current weapon
+type = COMP_WEAPON;
 			}
 		}
 
 		switch (type)
 		{
 		case COMP_BODY:
-			compTempl.asParts[COMP_BODY] = (BODY_STATS *)psStats - asBodyStats;
+			bodyStats = psStats;
 			break;
 		case COMP_PROPULSION:
-			compTempl.asParts[COMP_PROPULSION] = (PROPULSION_STATS *)psStats -
-asPropulsionStats;
+			propulsionStats = psStats;
 			break;
 		case COMP_ECM:
-			compTempl.asParts[COMP_ECM] = (ECM_STATS *)psStats - asECMStats;
+			ECMStats = psStats;
 			break;
 		case COMP_SENSOR:
-			compTempl.asParts[COMP_SENSOR] = (SENSOR_STATS *)psStats -
-asSensorStats;
+			sensorStats = psStats;
 			break;
 		case COMP_CONSTRUCT:
-			compTempl.asParts[COMP_CONSTRUCT] = (CONSTRUCT_STATS *)psStats -
-asConstructStats;
+			constructStats = psStats;
 			break;
 		case COMP_REPAIRUNIT:
-			compTempl.asParts[COMP_REPAIRUNIT] = (REPAIR_STATS *)psStats -
-asRepairStats;
+			repairStats = psStats;
 			break;
 		case COMP_WEAPON:
-			compTempl.asWeaps[0] = (WEAPON_STATS *)psStats - asWeaponStats;
+			weaponStats = psStats;
 			break;
 		//default:
 			//don't want to draw for unknown comp
 		}
+		// this code is from calcTemplatePower
+	UDWORD power, i;
 
-		widgSetMinorBarSize( psWScreen, IDDES_POWERBAR,
-calcTemplatePower(&compTempl));
+	//get the component power
+	power = bodyStats->buildPower + brainStats->buildPower + sensorStats->buildPower + ECMStats->buildPower + repairStats->buildPower + constructStats->buildPower;
+
+	/* propulsion power points are a percentage of the bodys' power points */
+	power += (propulsionStats->buildPower *
+		bodyStats->buildPower) / 100;
+		
+ 	//add weapon power
+// FIXME: Only takes first weapon into account
+power += weaponStats->buildPower;
+	for(i=1; ibuildPower;
+	}
+   		widgSetMinorBarSize( psWScreen, IDDES_POWERBAR,
+power);
 	}
 	else
 	{
@@ -3705,12 +3723,18 @@
 static void intSetTemplateBodyShadowStats(COMP_BASE_STATS *psStats)
 {
 	UDWORDtype;
-	DROID_TEMPLATE		compTempl;
 
-	if (&sCurrDesign != NULL && psStats != NULL)
-	{
-		//create the comparison Template
-		memcpy(&compTempl, &sCurrDesign, sizeof(DROID_TEMPLATE));
+	if (psStats != NULL) {
+COMP_BASE_STATS* bodyStats = asBodyStats + sCurrDesign.asParts[COMP_BODY];
+COMP_BASE_STATS* brainStats = asBrainStats + sCurrDesign.asParts[COMP_BRAIN];
+COMP_BASE_STATS* sensorStats = asSensorStats + sCurrDesign.asParts[COMP_SENSOR];
+COMP_BASE_STATS* ECMStats = asECMStats + sCurrDesign.asParts[COMP_ECM];
+COMP_BASE_STATS* repairStats = asRepairStats

[Warzone-dev] Patch: Fog of War / Mist

[Gerard Krol]

Fog of War seems to be broken in that it renders a "foggy" sky instead 
of a black background. Fixed that.


- Gerard
Index: src/loop.c
===
--- src/loop.c	(revision 726)
+++ src/loop.c	(working copy)
@@ -183,8 +183,9 @@
 #endif
 
 //JPS 24 feb???
-	if (fogStatus & FOG_BACKGROUND)
+	if (war_GetFog())
 	{
+// Mist
 		clearMode = CLEAR_FOG;//screen clear to fog colour D3D
 		if (loopMissionState == LMS_SAVECONTINUE)
 		{
@@ -194,6 +195,7 @@
 	}
 	else
 	{
+// Fog of War
 		clearMode = CLEAR_BLACK;//force to black 3DFX
 	}
 	pie_ScreenFlip(clearMode);//gameloopflip
Index: src/multiint.c
===
--- src/multiint.c	(revision 726)
+++ src/multiint.c	(working copy)
@@ -1989,6 +1989,7 @@
 			widgSetButtonState(psWScreen, MULTIOP_FOG_ON,WBUT_LOCK);
 			widgSetButtonState(psWScreen, MULTIOP_FOG_OFF,0);
 			game.fog = TRUE;
+war_SetFog(FALSE); // FIXME: multiplayer FOG_ON means fog of war active
 			if(bHosted)
 			{
 sendOptions(0,0);
@@ -1999,6 +2000,7 @@
 			widgSetButtonState(psWScreen, MULTIOP_FOG_ON,0);
 			widgSetButtonState(psWScreen, MULTIOP_FOG_OFF,WBUT_LOCK);
 			game.fog = FALSE;
+war_SetFog(TRUE);
 			if(bHosted)
 			{
 sendOptions(0,0);
Index: lib/ivis_opengl/piemode.c
===
--- lib/ivis_opengl/piemode.c	(revision 726)
+++ lib/ivis_opengl/piemode.c	(working copy)
@@ -134,6 +134,10 @@
 		case CLEAR_OFF_AND_NO_BUFFER_DOWNLOAD:
 			break;
 		case CLEAR_BLACK:
+			glDepthMask(GL_TRUE);
+			glClearColor(0.0f,0.0f,0.0f,0.0f);
+			glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
+			break;
 		default:
 			glDepthMask(GL_TRUE);
 			fog_colour.argb = pie_GetFogColour();
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Patch for 'error: Error during jpg decompression of "texpages/bdrops/wzlogo_4.png"!'

[Gerard Krol]

The current backdrop code is quite crude in that it first just tries to 
open an image as jpg, and if that fails tries to open it as png.  The 
attached patch determines the type by the extension, and then opens it 
as the correct type right away.


- Gerard
Index: lib/ivis_opengl/screen.c
===
--- lib/ivis_opengl/screen.c	(revision 722)
+++ lib/ivis_opengl/screen.c	(working copy)
@@ -399,55 +399,67 @@
 {
 	pie_image image;
 	iSprite imagePNG;
-	BOOL imageLoaded = FALSE;
 	char * buffer = NULL;
 	unsigned int dummy = 0;
+char *extension;
 
-	image_init(&image);
+// determine the filetype
+extension = strrchr(filename, '.');
+if(extension) {
+extension++;
+} else {
+debug(LOG_ERROR, "Image without extension: \"%s\"!", filename);
+return; // filename without extension... don't bother
+}
 
-	if (!imageLoaded && !image_load_from_jpg(&image, filename)) {
-		if (~backDropTexture == 0) {
-			glGenTextures(1, &backDropTexture);
-		}
+if(strcmp(extension,"jpg") == 0 || strcmp(extension,"jpeg") == 0) { 
+	image_init(&image);
 
-		glBindTexture(GL_TEXTURE_2D, backDropTexture);
-		glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB,
-			 image.width, image.height,
-			 0, GL_RGB, GL_UNSIGNED_BYTE, image.data);
-		glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
-		glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
-		glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
-		glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
-		glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
+	if (!image_load_from_jpg(&image, filename)) {
+		if (~backDropTexture == 0) {
+			glGenTextures(1, &backDropTexture);
+		}
+
+		glBindTexture(GL_TEXTURE_2D, backDropTexture);
+		glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB,
+			 image.width, image.height,
+			 0, GL_RGB, GL_UNSIGNED_BYTE, image.data);
+		glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
+		glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
+		glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
+		glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
+		glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
+	}
 
-		imageLoaded = TRUE;
-	}
+	image_delete(&image);
+return;
+}
 
-	image_delete(&image);
-
-	// HACK : We should use a resource handler here!
-	if ( !imageLoaded && loadFile( filename, &buffer, &dummy ) && pie_PNGLoadMem( buffer, &imagePNG ) )
-	{
-		FREE(buffer);
-
-		if (~backDropTexture == 0) {
-			glGenTextures(1, &backDropTexture);
-		}
-
-		glBindTexture(GL_TEXTURE_2D, backDropTexture);
-		glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA,
-			 imagePNG.width, imagePNG.height,
-			 0, GL_RGBA, GL_UNSIGNED_BYTE, imagePNG.bmp);
-		glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
-		glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
-		glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
-		glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
-		glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
-
-		free(imagePNG.bmp);
-
-		imageLoaded = TRUE;
-	}
+if(strcmp(extension,"png")==0) {
+	// HACK : We should use a resource handler here!
+	if (loadFile( filename, &buffer, &dummy ) && pie_PNGLoadMem( buffer, &imagePNG ) )
+	{
+		FREE(buffer);
+
+		if (~backDropTexture == 0) {
+			glGenTextures(1, &backDropTexture);
+		}
+
+		glBindTexture(GL_TEXTURE_2D, backDropTexture);
+		glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA,
+			 imagePNG.width, imagePNG.height,
+			 0, GL_RGBA, GL_UNSIGNED_BYTE, imagePNG.bmp);
+		glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
+		glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
+		glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
+		glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
+		glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
+
+		free(imagePNG.bmp);
+	}
+return;
+}
+debug(LOG_ERROR, "Unknown extension \"%s\" for image \"%s\"!", extension, filename);
 }
 //===
 
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Patch for preventing segfault in skirmish

[Gerard Krol]

Hi,

I'm pleased to say that Warzone seems to run fine on AMD64, that is, 
after applying the attached patch.


For a return type of "bool" (integer value 0) the array gets accessed 
with a negative index of -11. This just goes unnoticed most of the time 
I guess, but I was lucky to experience a segfault.


- Gerard
Index: lib/script/script_lexer.l
===
--- lib/script/script_lexer.l	(revision 722)
+++ lib/script/script_lexer.l	(working copy)
@@ -257,7 +257,14 @@
 	BOOL	object;
 
 	// See if this is an object pointer
-	object = asScrTypeTab[psFunc->retType - VAL_USERTYPESTART].accessType == AT_OBJECT;
+	if (!asScrTypeTab || psFunc->retType < VAL_USERTYPESTART)
+	{
+		object = FALSE;
+	}
+	else
+	{
+		object = asScrTypeTab[psFunc->retType - VAL_USERTYPESTART].accessType == AT_OBJECT;
+	}
 
 	if (object)
 	{
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

RE: [Warzone-dev] Patch for removing the AND and OR macro's

[Gerard Krol]

Sorry for using a MS product ;), I will set up thunderbird (icedove) 
tomorrow... for now, apt-get install tnef?

- Gerard

-Original Message-
From: [EMAIL PROTECTED] on behalf of Giel van Schijndel
Sent: Fri 26-1-2007 23:27
To: Development list
Subject: Re: [Warzone-dev] Patch for removing the AND and OR macro's
 
Gerard Krol schreef:
> Hi all,
>
> The AND and OR macro's annoyed me, so I decided to remove them in flavor of 
> the native && and ||.
>
> - Gerard
>   
Erm, maybe try another mail client than MS outlook, because all
attachments I see is winmail.dat (oulook is known for that kind of
stupidity, just google winmail.dat).

-- 
Giel


<>___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

RE: [Warzone-dev] 500KB patch...

[Gerard Krol]

A little review based on only reading wz28b.patch, not applying it:

## line 59: MAX_OAINFO_OBJS is a strange name, whether you added it or it was 
already in, this needs to be clear. Example:
-   BASE_OBJECT *psObj[DROID_MAXWEAPS];
+   BASE_OBJECT *psObj[MAX_OAINFO_OBJS];

## PRI_SLOT could just as easily be called PRIMARY_SLOT

## line 135: Can someone explain how you can get a reminder after devision by 
1? (should be %2)
+   //Random direction(left or right 30 degree's)
+   if (rand()%1 == 0)
+   {
+   angle += 30;
+   if (angle >= 360)
+   {
+   angle -= 360;
+   }
+   }
+   else
+   {
+   angle -= 30;
+   if (angle < 0)
+   {
+   angle += 360;
+   }
+   }

Also, why not write: angle = (angle-30)%360;

## line 184 + 285 + 989
+   /* Watermelon:if I am a multi-turret droid */
Just use the for loop, will act the same as the if when psDroid->numWeaps==1

## line 334: another scary name
+   DROID_OACTION_INFO oaInfo = {{NULL}};

## line 613: no need to add more commented out code to svn

## line 1748: why is it a factory anyway?
+   //skips rearm field,since it 
doesnt have assembly point

## line 2306: this is getting out of hand... anyone got a better idea?
+   //Watermelon orderX3,orderY3 for more complicated order...

## line 2541 + 5737: OMG... there has to be a better way...

## line 2665: I suggest we stop supporting compilers that don't support 
slotsX[MAX_REARM_SLOTS]
+   //Watermelon: 8 = MAX_REARM_SLOTS
+   UWORD   slotsX[8];

## line 2693: make that ~0
+   SDWORD  numMags; //Watermelon:number of 
magzines negative 1(-1) = infinite

## line 2701: You need to add a GAME_SAVE_V35 I'm afraid
+// Watermelon:added aDefaultRearm
 #define GAME_SAVE_V34 

## line 2742: ??? It's probably how pumpkin did it, but isn't there a better 
way?
+#define STRUCTURE_SAVE_V24 \
+   OBJECT_SAVE_V20; \

## line 3154: please explain the necessity of [i*5+4]
+   
psSaveStruct->RunwaysInfo[i*5+4] = psRearmField->runways[i].facing;

## line 3366: call it like this?: #define ONLY_SAME_TYPE_FACTORY_IN_LIST TRUE
+#define SEPARATE_LIST_TEST 1

## line 4237: Happy with being included in WZ?
+BOOL recvHappyJet(NETMSG *pMsg)

Looks like a lot of hard work, good job.

- Gerard



-Original Message-
From: [EMAIL PROTECTED] on behalf of The Watermelon
Sent: Mon 22-1-2007 21:47
To: Development list
Subject: [Warzone-dev] 500KB patch...
 
Couldnt separate them into smaller patches because the changes 'twisted'
alot...sorry for the huge patch.

Changes:(wz28b.patch)
1.Added 3 new propulsions that can be defined in propulsions.txt
(jet,helix,navy)
2.Added new structures:
rearmCentre(auto-rearm all units within its 'rearmRadius')
rearmField(a hybrid of rearm pad and factory,can build/support up to 8 'jet'
droids at one time)
3.Limited ammo and rearm.txt and added component ZNULLREARM to all templates
in templates.txt
note:1,2,3 might be partly unfinished/untested because they require a mod to
test and they dont affect the 'stock' wz
4.Fixed a bug which prevents the droids from removing 'died' targets for
auxiliary weapons.
5.Fixed some net message size count problems with vtol I made when adding
multiple weapons to vtol
6.Changed sinf/cosf to trig sin/cos lookup access functions trigSin and
trigCos for better performance
7.Changed vectorToAngle in move.c a bit to improve its efficiency('+= 360/4'
is weird and 'somevalue/180/2' is pointless too imo...)
8.Changed establishTargetHeight in projectile.c to use pIMD rather than
displayImd for structures to fix some weird height problems(hopefully)
9.Added a new function combFireLoc in combat.c,the function is used to
'attack location with x,y,z specified' without psTarget(like carpet bombing)
10.Added experimental test of a separate list in 'manufacture'
interface('#define SEPARATE_LIST_TEST' in hci.c,default on,comment it out to
use 'old' manufacture list)
old:when you click on a factory,it lists all of your factories in the
interface(cyborg,factory,vtol factory),which is odd...
test:when you click on a factory,it only lists all of your factories of the
same type you selected.
11.Added a hitbox bonus for indirect weapon's intended target.

Changes(wz28bData.patch)
1.Added rearm.txt(ZNULLREARM)
2.Added ZNULLREARM to all templates in templates.txt
3.Changed 'NULL' component to wz null entry style 'ZNULLSOMECOMP'
4.Added functions for rearmCentre and rearmField in functions.txt
5.Added dummy rearmfield and rearmcentre to structures.txt(because wz
a function depends on a structure...)
6.Changed wrf to deal with those changes.

<>___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gn

[Warzone-dev] Java applet for IRC

[Gerard Krol]

Hi,

How about putting a link to 
http://java.freenode.net/index.php?channel=warzone on the page 
http://www.wz2100.net/irc-chat.html,
or even the applet itself like described at: 
http://java.freenode.net/howto.php ?


Regards,

Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Ari: Still valid? Workaround for MacOS gcc 4.0.0 bug

[Gerard Krol]

Ari Johnson wrote:

Yes, the bug is still there.

On 12/8/06, Dennis Schridde <[EMAIL PROTECTED]> wrote:

Is the bug in this code still present? Or can we remove the tmp int?

lib/ivis_common/bitimage.c:92:
// Load the texture pages.
for (i = 0; i < Header->NumTPages; i++) {
int tmp;/* Workaround for MacOS gcc 4.0.0 
bug. */
Just rename tmp to pageID. Then there's no problem with leaving it in 
(for me, at least).
It's maybe even more readable, and the compiler will optimize it away 
anyhow.


- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Re: [Warzone-commits] r510 - in/trunk:data/mp/stats/weapons.txt data/stats/weapons.txtsrc/combat.csrc/order.c src/projectile.c src/stats.c src/statsdef.h

[Gerard Krol]

zz zz wrote:

Ain't it possible to hand psStats->penetrate directly over to scanf?
And: The other flags use a "compareYes" function. Why is this not 
used for

penetrate?

--Dennis


Sorry I don't know about this, I hope Watermelon is reading this.

As a long term goal we should consider converting txt files into a 
more user friendly format, this could also bring more people into 
modding. Since some lines consist of more than 20 entries of 
different types having tags or some other value descriptors will be 
helpfull (especially for files like structures.txt or weapons.txt). 
Naturally 'xml' comes to my mind.


Troman


the last value of that super long scanf cant be a string,or the entire 
line of pDataBuffer is screwed...(the last value of all .txt in stats 
is an int value iirc)


I agree that the format should be changed to be more user 
friendly,that 30 values or so per line delimited by ',' is very hard 
to read and it's impossible to tell which value is for what without 
looking at the stats.c.


reply to other emails all in one because of my laziness:
lua is probably too slow for data ,it's optimal for network info 
generation/configuration.


xml should be ok as long as you dont read them in 'run-time'.

sql I really dislike using sql on anything other than web 
stuff:slow,inflexible,too l33t to modify etc =)


probably the best solution is plain text with some 'describers' like 
'[name]','[damage]' etc.
I vote for XML. It is really easy to get a good parser from somewhere, 
and writing your own "language" always turns out to be far more work 
than you expected.


- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Changing the game name...

[Gerard Krol]

Fearthecute wrote:

Hi,
the following:

I would suggest to change the actual game name to something different
than "Warzone2100". (I have a bad feeling with this name...)

Due Warzone2100 was/is a full price game
and the name can/is still be owned by the Eidos Interactive group.
  
I guess they technically still own the name. They however released the 
source for the game under the GPL, without explicitly restricting the 
use of the name. They also don't seem to have any interest in making a 
sequel or any other use of the concept/story.


It is in fact the same question as about the graphics and 3d models: Is 
only the source released under the GPL or also all accompanying materials?


If it turns out the data is also GPL and as the data contains explicit 
references to the name "Warzone" (title screens and such), I think it 
can be assumed we are allowed to use the name for future development.
This would be a bit strange: "I grant you the right to modify and 
distribute this file, which contains the name Warzone. You are, however, 
not allowed to use the name Warzone"

Maybe just "WZ 2100" which intends a bit to warzone 2100.
Or whatever... This would be may a 'safer side' :)
  
We can always do that when they start to complain. I don't think we need 
the safety now.


- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Automatic dependencies

[Gerard Krol]

Dennis Schridde wrote:

Am Montag, 13. November 2006 19:54 schrieb Per Inge Mathisen:
  

Most of the sed code is just magic that I copied from somewhere else,
probably  http://make.paulandlesley.org/autodep.html which is a
must-read.



Does that code run always before the %.o: %.c rule is applied to any
file?
  

Yes.



if we want Makefile.raw to be able to run from within a dos shell (no sed
for example).
  

No sed is just the beginning. Does anything of any complexity really
run in a DOS shell? I would guess even just make would struggle, with
different path delimiters and all that. For those who do not want to
run mingw/msys/cygwin, surely just using VS is a better choice.

It worked _pretty_ well till now (after I rewrote the Makefile.raws and 
striped any SHianisms)...
I did the last releases with only cmd.exe and a MinGW 3.4.5 installation, 
without any extras like MSys or CygWin...
I don't really know, I'm using MSys AND Cygwin for developement. Anyone 
just using DOS?


- Gerard

PS. Why not join irc.freenode.net #warzone? Quite busy there ;)

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Automatic dependencies

[Gerard Krol]

Per Inge Mathisen wrote:

On 11/13/06, Gerard Krol <[EMAIL PROTECTED]> wrote:

And it is not that every user needs to run "make depend", it just needs
to be done when there are changes to the includes. I believe there 
are switches to make

gcc do the same as makedepend, but a lot slower.


I do not know about slower, but there is no need to add dependencies
to files that are checked in, at least not if you use gcc -M.
You mean that the dependency information is already there (in the .c 
files) so we should not commit it to SVN another time?
The standard way to do this is, it seems, to create new, hidden files 
with

dependency information for each .c file. In autohell, those are added
as .Po files in a separate .deps directory. One advantage of this is
that you do not need to check in changes to dependencies to the
repository.
This is a bit of a problem if we want Makefile.raw to be able to run 
from within a dos shell (no sed for example).

I had some fun with gnu make and gcc -M a few months ago, and created
a very generalized build system with only those two components,
including configuration checking, 'make dist' and dependency
generation. You can see it at
http://svn.gna.org/viewcvs/buckyball/trunk/ if you are interested. I
do not know how well something like that would scale.
I think it would scale the same way makedepend does, it just is O(n) on 
.c files, just with a higher constant I guess.


- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Automatic dependencies

[Gerard Krol]

Dennis Schridde wrote:

Am Montag, 13. November 2006 00:04 schrieb Gerard Krol:
  

Dennis Schridde wrote:


Am Freitag, 10. November 2006 16:54 schrieb Gerard Krol:
  

Hi,

The complete lack of dependencies somewhat bothers me, so I ran (X11)
makedepend. Attached are changes for the Makefile.raw's.
Now you don't have to run "make clean" all the time anymore.
Could someone with access to automake also incorporate the changes into
the Makefile.am's?


Is the makedepend exe included in MinGW?
Because I rewrote the Makefile.raw s to run with just a plain MinGW
installation (without MSys). Would be ugly if we now required a non
standard exe for a task like dependency checking...
  

Eh, no, makedepend is part of the linux/cygwin x11-bin package, I ran
the cygwin version.
And it is not that every user needs to run "make depend", it just needs
to be done when
there are changes to the includes. I believe there are switches to make
gcc do the same as
makedepend, but a lot slower.


But in the Makefile I found ".PHONY depend"...
Would mean that he does "depend" on every run, or am I wrong?
No, ".PHONY" is a flag that signals make that the targets do not produce 
a file (such as an .o or .exe), see

http://theory.uwinnipeg.ca/gnu/make/make_33.html

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Automatic dependencies

[Gerard Krol]

Dennis Schridde wrote:

Am Freitag, 10. November 2006 16:54 schrieb Gerard Krol:
  

Hi,

The complete lack of dependencies somewhat bothers me, so I ran (X11)
makedepend. Attached are changes for the Makefile.raw's.
Now you don't have to run "make clean" all the time anymore.
Could someone with access to automake also incorporate the changes into
the Makefile.am's?


Is the makedepend exe included in MinGW?
Because I rewrote the Makefile.raw s to run with just a plain MinGW 
installation (without MSys). Would be ugly if we now required a non standard 
exe for a task like dependency checking...
  


Eh, no, makedepend is part of the linux/cygwin x11-bin package, I ran 
the cygwin version.
And it is not that every user needs to run "make depend", it just needs 
to be done when
there are changes to the includes. I believe there are switches to make 
gcc do the same as

makedepend, but a lot slower.

I think we really need those dependencies, it is, after all, quite 
annoying to do a "find -name "*.o" | xargs rm", alias "make clean",  
after a change in the header files.


- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Clipping bug + fix

[Gerard Krol]

Dennis Schridde wrote:

Am Samstag, 11. November 2006 18:40 schrieb Gerard Krol:
  

The clipping in src/bucket3d.c doesn't seem to work for me, as droids
and buildings disappear when they are not entirely off screen.
Anyone else has this problem?

Yes, this problem exists since long. It's just that nobody yet has bothered to 
fix it...
  

I hacked a *7 into the radius calculation and everything seems to work
fine, and I guess it is not a big problem nowadays when we draw 3 droids
and a building too much.


Why *7 ? Any specific reasons or found by trial and error?
What is FP12_MULTIPLIER ?
  

FP12_MULTIPLIER is (1<<12) but I don't have a clue what it stands for.
The 7 was just trial and error.

Someone with some experience with 3D viewports should write a new 
equation for the size of a circle on screen, and we can use that.
For now I suggest adding it to the TODO list (or a to be created HACK 
list (on the Wiki?)) so we don't forget about it.


- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Clipping bug + fix

[Gerard Krol]

The clipping in src/bucket3d.c doesn't seem to work for me, as droids 
and buildings disappear when they are not entirely off screen.

Anyone else has this problem?
I hacked a *7 into the radius calculation and everything seems to work 
fine, and I guess it is not a big problem nowadays when we draw 3 droids 
and a building too much.


- Gerard
Index: src/bucket3d.c
===
--- src/bucket3d.c  (revision 469)
+++ src/bucket3d.c  (working copy)
@@ -31,12 +31,14 @@
 #define BUCKET_RANGE   32000
 
 #define BUCKET_CLIP
-#define CLIP_LEFT  (0)
+#define CLIP_LEFT  ((SDWORD)0)
 #define CLIP_RIGHT ((SDWORD)DISP_WIDTH)
-#define CLIP_TOP   (0)
+#define CLIP_TOP   ((SDWORD)0)
 #define CLIP_BOTTOM ((SDWORD)DISP_HEIGHT)
 //scale depth = 1<>STRETCHED_Z_SHIFTsDisplay.imd->radius) * 2;//other building clipping not 
so close
+   radius = 
(((STRUCTURE*)pObject)->sDisplay.imd->radius);
 #endif
}
 
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Patch by Watermelon: bug fixes

[Gerard Krol]

Gerard Krol wrote:

I think this is what Watermelon intended to send:

sensorcrash.patch: fixes a crash when repairing a not damaged command 
center, corrects the mouse cursor (change by me)

penetrate.patch: adds penetration for certain weapon types


Penetrate contained to different patches, splitted it up into:

penetrate.patch: adds penetration for certain weapon types
prediction.patch: improves the prediction for bullets

- Gerard
Index: src/combat.c
===
--- src/combat.c(revision 469)
+++ src/combat.c(working copy)
@@ -104,9 +104,15 @@
//Watermelon:predicted X,Y offset per sec
SDWORD  predictX;
SDWORD  predictY;
-   //Watermelon:dirty dist
+   //Watermelon:sqrt dist
SDWORD  dist;
+   //Watermelon:vtolDist
+   SDWORD  vtolDist;
+   SDWORD  zDiff;
+   BOOLbFlyingVTOL;
 
+   bFlyingVTOL = FALSE;
+
ASSERT( PTRVALID(psWeap, sizeof(WEAPON)),
"combFire: Invalid weapon pointer" );
ASSERT( PTRVALID(psAttacker, sizeof(BASE_OBJECT)),
@@ -343,8 +349,20 @@
xDiff = abs(psAttacker->x - psTarget->x);
yDiff = abs(psAttacker->y - psTarget->y);
distSquared = xDiff*xDiff + yDiff*yDiff;
-   //Watermelon:dirty dist
-   dist = dirtySqrt(psAttacker->x,psAttacker->y,psTarget->x,psTarget->y);
+   //Watermelon:actual dist
+   dist = sqrt(distSquared);
+
+   //Watermelon:need to calculate the vtol actual distance(affected by 
vector z)
+   if (psTarget->type == OBJ_DROID)
+   {
+   if (vtolDroid((DROID *)psTarget) && !(((DROID 
*)psTarget)->sMove.Status == MOVEINACTIVE))
+   {
+   zDiff = abs(psAttacker->z - psTarget->z);
+   vtolDist = (SDWORD)(sqrt(dist*dist + zDiff*zDiff));
+   bFlyingVTOL = TRUE;
+   }
+   }
+
longRange = proj_GetLongRange(psStats, 
(SDWORD)psAttacker->z-(SDWORD)psTarget->z);
if (distSquared <= (psStats->shortRange * psStats->shortRange) AND
distSquared >= (psStats->minRange * psStats->minRange))
@@ -367,13 +385,24 @@
{
/* Kerrrbaaang ! a hit */
//Watermelon:Target prediction
-   if(psTarget->type == OBJ_DROID)
+   if (psTarget->type == OBJ_DROID)
{
-   predictX = (cos(((DROID *)psTarget)->sMove.dir) 
* ((DROID *)psTarget)->sMove.speed * sqrt(distSquared)) /psStats->flightSpeed;
+   //Watermelon:If it's a flying VTOL use vtolDist
+   if (bFlyingVTOL)
+   {
+   predictX = (SDWORD)((sin(((DROID 
*)psTarget)->sMove.dir) * ((DROID *)psTarget)->sMove.speed * vtolDist) 
/psStats->flightSpeed);
+   predictX += psTarget->x;
+   predictY = (SDWORD)((cos(((DROID 
*)psTarget)->sMove.dir) * ((DROID *)psTarget)->sMove.speed * vtolDist) 
/psStats->flightSpeed);
+   predictY += psTarget->y;
+   }
+   else
+   {
+   predictX = (SDWORD)((sin(((DROID 
*)psTarget)->sMove.dir) * ((DROID *)psTarget)->sMove.speed * dist) 
/psStats->flightSpeed);
predictX += psTarget->x;
-   predictY = (sin(((DROID *)psTarget)->sMove.dir) 
* ((DROID *)psTarget)->sMove.speed * sqrt(distSquared)) /psStats->flightSpeed;
+   predictY = (SDWORD)((cos(((DROID 
*)psTarget)->sMove.dir) * ((DROID *)psTarget)->sMove.speed * dist) 
/psStats->flightSpeed);
predictY += psTarget->y;
}
+   }
else
{
predictX = psTarget->x;
@@ -418,17 +447,20 @@
{
/* Kerrrbaaang ! a hit */
//Watermelon:Target prediction
-   if(psTarget->type == OBJ_DROID)
+   //Watermelon:If it's a flying VTOL use vtolDist
+   if (bFlyingVTOL)
{
-   predictX = (cos(((DROID *)psTarget)->sMove.dir) 
* ((DROID *)psTarget)->sMove.speed * sqrt(distSquared)) /psStats->flightSpeed;
+   predictX = (SDWORD)((sin(((DROID 
*)psTarget)->sM

Re: [Warzone-dev] Patch by Watermelon: bug fixes

[Gerard Krol]

I think this is what Watermelon intended to send:

sensorcrash.patch: fixes a crash when repairing a not damaged command 
center, corrects the mouse cursor (change by me)

penetrate.patch: adds penetration for certain weapon types

- Gerard
Index: src/display.c
===
--- src/display.c   (revision 469)
+++ src/display.c   (working copy)
@@ -3242,11 +3242,11 @@
{
if(buildingDamaged(psStructure))
{
-   retVal = MT_SENSORSTRUCT;
+   retVal = MT_SENSORSTRUCTDAM;
}
else
{
-   retVal = MT_SENSORSTRUCTDAM;
+   retVal = MT_SENSORSTRUCT;
}
}
 
Index: src/structure.c
===
--- src/structure.c (revision 469)
+++ src/structure.c (working copy)
@@ -9137,6 +9137,10 @@
 {
//Standard Sensor Tower + indirect weapon droid (non VTOL)
//else if (structStandardSensor(psStruct) AND (psDroid->numWeaps AND
+   //Watermelon:another crash when nStat is marked as 0xcd...
+   //Added a safety check
+   if (psDroid->numWeaps > 0)
+   {
 if (structStandardSensor(psStruct) AND (psDroid->asWeaps[0].nStat > 0 AND
!proj_Direct(asWeaponStats + psDroid->asWeaps[0].nStat)) AND
!vtolDroid(psDroid))
@@ -9164,6 +9168,7 @@
vtolDroid(psDroid))
{
return TRUE;
+   }
}
 
//case not matched
Index: src/scriptfuncs.c
===
--- src/scriptfuncs.c   (revision 469)
+++ src/scriptfuncs.c   (working copy)
@@ -6173,7 +6173,7 @@
sWeapon.nStat = wIndex;
 
// send the projectile using the selectedPlayer so that it can always 
be seen
-   proj_SendProjectile(&sWeapon, NULL, selectedPlayer, 
psTarget->x,psTarget->y,psTarget->z, psTarget, TRUE);
+   proj_SendProjectile(&sWeapon, NULL, selectedPlayer, 
psTarget->x,psTarget->y,psTarget->z, psTarget, TRUE, FALSE);
 
return TRUE;
 }
@@ -6193,7 +6193,7 @@
sWeapon.nStat = wIndex;
 
// send the projectile using the selectedPlayer so that it can always 
be seen
-   proj_SendProjectile(&sWeapon, NULL, selectedPlayer, 
x,y,map_Height(x,y), NULL, TRUE);
+   proj_SendProjectile(&sWeapon, NULL, selectedPlayer, 
x,y,map_Height(x,y), NULL, TRUE, FALSE);
 
return TRUE;
 }
Index: src/droid.c
===
--- src/droid.c (revision 469)
+++ src/droid.c (working copy)
@@ -4458,7 +4458,7 @@
{
//psDroid->armour[inc] = (asBodyStats + 
pTemplate->asParts[COMP_BODY])->armourValue[inc];
psDroid->armour[inc] = bodyArmour(asBodyStats + 
pTemplate->
-   asParts[COMP_BODY], (UBYTE)player, 
CYBORG_BODY_UPGRADE, (WEAPON_CLASS)inc);
+   asParts[COMP_BODY], (UBYTE)player, 
CYBORG_BODY_UPGRADE, inc);
}
}
else
@@ -4466,7 +4466,7 @@
for (inc = 0; inc < NUM_WEAPON_CLASS; inc++)
{
psDroid->armour[inc] = bodyArmour(asBodyStats + 
pTemplate->
-   asParts[COMP_BODY], (UBYTE)player, 
DROID_BODY_UPGRADE, (WEAPON_CLASS)inc);
+   asParts[COMP_BODY], (UBYTE)player, 
DROID_BODY_UPGRADE, inc);
}
}
 
Index: src/combat.c
===
--- src/combat.c(revision 469)
+++ src/combat.c(working copy)
@@ -104,8 +104,14 @@
//Watermelon:predicted X,Y offset per sec
SDWORD  predictX;
SDWORD  predictY;
-   //Watermelon:dirty dist
+   //Watermelon:sqrt dist
SDWORD  dist;
+   //Watermelon:vtolDist
+   SDWORD  vtolDist;
+   SDWORD  zDiff;
+   BOOLbFlyingVTOL;
+
+   bFlyingVTOL = FALSE;
 
ASSERT( PTRVALID(psWeap, sizeof(WEAPON)),
"combFire: Invalid weapon pointer" );
@@ -343,8 +349,20 @@
xDiff = abs(psAttacker->x - psTarget->x);
yDiff = abs(psAttacker->y - psTarget->y);
distSquared = xDiff*xDiff + yDiff*yDiff;
-   //Watermelon:dirty dist
-   dist = dirtySqrt(psAttacker->x,psAttacker->y,psTarget->x,psTarget->y);
+   //Watermelon:actual dist
+   dist = sqrt(distSquared);
+
+   //W

Re: [Warzone-dev] BOOL used to store pointers?

[Gerard Krol]

Watch out for the:

#ifndef WZ_OS_WIN

I guess it's better to have the same data types on all platforms. (On MinGW 
BOOL is defined as int)
And as memory usage is not really an issue, why not leave BOOL == int? We just 
need to make sure it is saved
to disk consistently, and int is the native (fast) data type.

- Gerard




___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Compiling SVN; Removal of macro; PHYSFS_fileLength

[Gerard Krol]

Hi,

compile.patch:
The changes I had to make to compile rev 465.

bintree_stuff.patch:
Replaced the 2 occurrences of a strange macro with its definition

openal_filesize.patch:
lib/sound/openal_track.c:// FIXME Ugly hack because PhysFS doesn't 
support reporting the filesize, nor seeking to the end
Well, it does support reporting the filesize, so I replaced the hack 
with PHYSFS_fileLength


- Gerard
Index: lib/sound/openal_track.c
===
--- lib/sound/openal_track.c(revision 445)
+++ lib/sound/openal_track.c(working copy)
@@ -387,10 +387,8 @@
 
if (f == NULL) return FALSE;
 
-   // FIXME Ugly hack because PhysFS doesn't support reporting the 
filesize, nor seeking to the end
-   while( PHYSFS_read( f, seekbuf, 1, 1 ) );
-   size = PHYSFS_tell( f );
-   PHYSFS_seek( f, 0 );
+   size = PHYSFS_fileLength(f);
+   assert( size > -1 );
 
if (size > buffer_size) {
if (buffer != NULL) free(buffer);
Index: lib/ivis_common/bspimd.h
===
--- lib/ivis_common/bspimd.h(revision 449)
+++ lib/ivis_common/bspimd.h(working copy)
@@ -48,13 +48,9 @@
 #defineLEFT1
 #defineRIGHT   0
 
-
-#define BINTREE_STUFF(x)   struct x  *link[2] 
-
-
 typedef struct BNODE
 {
-   BINTREE_STUFF(BNODE);
+   struct BNODE *link[2];
 }
 BNODE, *PSBNODE;
 /***/
@@ -110,7 +106,7 @@
 
 typedef struct BSPTREENODE
 {
-   BINTREE_STUFF( BSPTREENODE );
+   struct BSPTREENODE *link[2];
 
PLANE   Plane;
// points to first polygon in the BSP tree entry ... BSP_NextPoly in 
the iIMDPoly structure will point to the next entry
Index: src/game.c
===
--- src/game.c  (revision 465)
+++ src/game.c  (working copy)
@@ -5922,8 +5922,8 @@
}
else
{
-   endian_uword(&psSaveDroid->turretRotation);
-   endian_uword(&psSaveDroid->turretPitch);
+   endian_uword(&psSaveDroid->turretRotation[0]);
+   endian_uword(&psSaveDroid->turretPitch[0]);
}
endian_sdword(&psSaveDroid->order);
endian_uword(&psSaveDroid->orderX);
Index: src/projectile.c
===
--- src/projectile.c(revision 465)
+++ src/projectile.c(working copy)
@@ -1837,7 +1837,7 @@
//if(psObj->psWStats->weaponSubClass == WSC_ROCKET OR 
psObj->psWStats->weaponSubClass == WSC_MISSILE OR
//psObj->psWStats->weaponSubClass == WSC_SLOWROCKET OR 
psObj->psWStats->weaponSubClass == WSC_SLOWMISSILE)
//{
-   projGetNaybors((BASE_OBJECT *)psObj);
+   projGetNaybors((PROJ_OBJECT *)psObj);
//}
 
switch (psObj->state)
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] SVN broken

[Gerard Krol]

This change:

Revision 450  - (view) (download) (as text) - [select for diffs]
Modified Sat Nov 4 02:11:26 2006 CET (15 hours, 53 minutes ago) by devurandom
File length: 9752 byte(s)
Diff to previous 389

- Droped a lot of (nearly) unused types from lib/framework/types.h
- Remove lots of unused functions (Windows/DDraw related)
- Now store the used bitdepth in the config and thus make it configurable 
without having to modify the sourcecode

Contains (this is an excerpt):

--- trunk/src/clparse.c 2006/09/23 14:56:18 389
+++ trunk/src/clparse.c 2006/11/04 01:11:26 450
@@ -250,13 +270,13 @@
else if ( strcasecmp( tokenType, "--shadows" ) == 0 )
{
// FIXME Should setDrawShadows go into warzoneconfig? 
Or how should config values be handled in general? By the system using it? Or 
by warzoneconfig? Or by config keys only?
-   //setDrawShadows( TRUE );
-   setWarzoneKeyNumeric( "shadows", TRUE );
+   setDrawShadows( TRUE );
+// setWarzoneKeyNumeric( "shadows", TRUE );
}
else if ( strcasecmp( tokenType, "--noshadows" ) == 0 )
{
-   //setDrawShadows( FALSE );
-   setWarzoneKeyNumeric( "shadows", FALSE );
+   setDrawShadows( FALSE );
+// setWarzoneKeyNumeric( "shadows", FALSE );
}
else if ( strcasecmp( tokenType, "--sound" ) == 0 )
{

Which gives an error while compiling:

g++ -m32 -DVERSION=\"2.0.5\" -DYY_STATIC -I.. -I../.. 
-I/home/Gerard/Warzone-DevPkg/include -fpermissive -Wall -O0 -g3 -DDEBUG -mwindows 
-DWIN32 -c -oclparse.o clparse.c
clparse.c: In function `BOOL ParseCommandLine(int, char**)':
clparse.c:273: error: `setDrawShadows' undeclared (first use this function)
clparse.c:273: error: (Each undeclared identifier is reported only once for 
each function it appears in.)
make[1]: *** [clparse.o] Error 1

- Gerard




___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] More patches for warnings

[Gerard Krol]

Dennis Schridde wrote:

Am Donnerstag, 2. November 2006 22:27 schrieb Troman:
  

- Original Message -
From: "Dennis Schridde" <[EMAIL PROTECTED]>
To: "Development list" 
Sent: Wednesday, November 01, 2006 11:50 PM
Subject: Re: [Warzone-dev] More patches for warnings
Am Mittwoch, 1. November 2006 23:03 schrieb Gerard Krol:
  

Hi,

This evenings work ;)

new.patch contains the addition of two macro's, and the use of them to
replace MALLOC


MALLOC itself is a macro around some custom wrapper around malloc...
So perhaps we should also check if we (additionally to using this NEW
wrapper)
could drop that MALLOC malloc wrapper...
(I don't really know what exact functionality MALLOC and FREE provide,
besides
that FREE checks for NULL pointers, what is useless as free() is defined
by the C std to do nothing in that case.)

--Dennis

PS: Idea seems good, didn't look at the patch.
  

It is a cleaner approach, but for me it is more intuitively to use MALLOC
since already the name implies that malloc functionality will be used at
some point. And these 2 new macros will not replace all occurances of
MALLOC, so we are just introducing more macros for the same functionality.

But anyway, I will be an impartial executor of a collective opinion. To
make it painless for everyone if no objections will be raised until
tomorrow evening I will just go on and apply the patch.


Well, then make it MALLOC instead. NEW is also more C++ style...
I'd be ok with it, but it doesn't bring much real benefit, though you could 
even don't use NEW. Also most ppl would probably not use NEW anyway as they 
are used to MALLOC/malloc and that's what's used in most of the code.
You are right YaWM (Yet another Wrapper Macro) is probably not needed and 
would clutter the code even more.
  
I have a lot more experience using the C++ new than the C malloc, as you 
guessed, so the new seems more natural to me.
And how about calling it "MALLOC_NEW"? It is indeed YaWM, but it saves a 
cast and a sizeof.
And I find (SOME_LONG_TYPENAME*)MALLOC(sizeof(SOME_LONG_TYPENAME)*a*b) 
not so nice to look at as

MALLOC_NEW_ARRAY(SOME_LONG_TYPENAME, a*b)
But I guess the former is more "C".
If someone wonders what this macro does, he can take an easy look at mem.h
Shall I try to completely remove all MALLOC calls and replace them with 
MALLOC_NEW?
The MALLOC calls left are for strings and texture pages and such, but 
they can then be replaced with:

MALLOC_NEW_ARRAY(char, size)

The alternative is that I add casts to all MALLOC's that not yet have 
them, this would fix a lot of warnings too.


- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Patches for removing some warnings

[Gerard Krol]

Hi all,

Attached are 2 sets of changes to remove some warnings. Those in 
warnings_casts.patch cast variables back to what they were before the 
binary operations, for example:


-sVal.type = (*InstrPointer) & OPCODE_DATAMASK;
+sVal.type = (INTERP_TYPE)((*InstrPointer) & 
OPCODE_DATAMASK);


I think this is quite harmless.
warnings_changes.patch changes the types of some variables and adds 
calls to keyCodeToSDLKey in some assert statements.


I hope those will be of any use, and if they are not in the right 
direction I'd be glad to hear what you would expect.


Regards,

Gerard

Index: src/fpath.c
===
--- src/fpath.c (revision 440)
+++ src/fpath.c (working copy)
@@ -1046,13 +1046,14 @@
 }
 
 // create a final route from a gateway route
-static SDWORD fpathGatewayRoute(BASE_OBJECT *psObj, SDWORD routeMode, SDWORD 
GWTerrain,
+static FPATH_RETVAL fpathGatewayRoute(BASE_OBJECT *psObj, SDWORD routeMode, 
SDWORD GWTerrain,
 SDWORD sx, SDWORD sy, SDWORD 
fx, SDWORD fy,
 MOVE_CONTROL *psMoveCntl)
 {
static SDWORD   linkx, linky, gwx, gwy, asret, matchPoints;
static ASTAR_ROUTE  sAStarRoute;
-   SDWORD  retval = FPR_OK, gwRet, zone;
+   FPATH_RETVALretval = FPR_OK;
+   SDWORD gwRet, zone;
static GATEWAY  *psCurrRoute, *psGWRoute, *psLastGW;
BOOLbRouting, bFinished;
static BOOL bFirstRoute;
Index: lib/framework/input.c
===
--- lib/framework/input.c   (revision 440)
+++ lib/framework/input.c   (working copy)
@@ -83,7 +83,7 @@
strcpy(ascii,"???");
return;
}
-   ASSERT( (code >= 0) && (code <= KEY_MAXSCAN), "Invalid key code: %d", 
code );
+   ASSERT( (code >= 0) && (keyCodeToSDLKey(code) <= KEY_MAXSCAN), "Invalid 
key code: %d", code );
 #ifndef _MSC_VER
snprintf(ascii, maxStringSize, "%s", 
SDL_GetKeyName(keyCodeToSDLKey(code)));
 #else
@@ -399,21 +399,21 @@
 /* This returns true if the key is currently depressed */
 BOOL keyDown(KEY_CODE code)
 {
-   ASSERT( (code >= 0) && (code < KEY_MAXSCAN), "Invalid key code: %d", 
code );
+   ASSERT( (code >= 0) && (keyCodeToSDLKey(code) < KEY_MAXSCAN), "Invalid 
key code: %d", code );
return (aKeyState[code] != KEY_UP);
 }
 
 /* This returns true if the key went from being up to being down this frame */
 BOOL keyPressed(KEY_CODE code)
 {
-   ASSERT( (code >= 0) && (code < KEY_MAXSCAN), "Invalid key code: %d", 
code );
+   ASSERT( (code >= 0) && (keyCodeToSDLKey(code) < KEY_MAXSCAN), "Invalid 
key code: %d", code );
return ((aKeyState[code] == KEY_PRESSED) || (aKeyState[code] == 
KEY_PRESSRELEASE));
 }
 
 /* This returns true if the key went from being down to being up this frame */
 BOOL keyReleased(KEY_CODE code)
 {
-   ASSERT( (code >= 0) && (code < KEY_MAXSCAN), "Invalid key code: %d", 
code );
+   ASSERT( (code >= 0) && (keyCodeToSDLKey(code) < KEY_MAXSCAN), "Invalid 
key code: %d", code );
return ((aKeyState[code] == KEY_RELEASED) || (aKeyState[code] == 
KEY_PRESSRELEASE));
 }
 
@@ -479,7 +479,7 @@
static int mousewarp = -1;
 
if (mousewarp == -1) {
-   int val;
+   DWORD val;
 
mousewarp = 1;
if (getWarzoneKeyNumeric("nomousewarp", &val)) {
Index: lib/framework/frame.c
===
--- lib/framework/frame.c   (revision 440)
+++ lib/framework/frame.c   (working copy)
@@ -446,7 +446,7 @@
 
   If hard_fail is true, we will assert and report on failures.
 ***/
-static BOOL loadFile2(char *pFileName, char **ppFileData, UDWORD *pFileSize,
+static BOOL loadFile2(const char *pFileName, char **ppFileData, UDWORD 
*pFileSize,
   BOOL AllocateMem, BOOL hard_fail)
 {
PHYSFS_file *pfile;

Index: src/cmddroid.c
===
--- src/cmddroid.c  (revision 440)
+++ src/cmddroid.c  (working copy)
@@ -80,10 +80,10 @@
psDroid->group = UBYTE_MAX;
 
// set the secondary states for the unit
-   secondarySetState(psDroid, DSO_ATTACK_RANGE, 
psCommander->secondaryOrder & DSS_ARANGE_MASK);
-   secondarySetState(psDroid, DSO_REPAIR_LEVEL, 
psCommander->secondaryOrder & DSS_REPLEV_MASK);
-   secondarySetState(psDroid, DSO_ATTACK_LEVEL, 
psCommander->secondaryOrder & DSS_ALEV_MASK);
-   secondarySetState(psDroid, DSO_HALTTYPE, 
psCommander->secondaryOrder & DSS_HALT_MASK);
+   secondarySetState(psDroid, DSO_ATTACK_RANGE,