2.2.3 is released!

[Buginator]

The developer staff brings you the release of Warzone 2100 2.2.3.

We have higher quality FMVs thanks to cybersphinx, squashed some more bugs, fixed 3D sound, and other numerous things.
For a complete list see the Changelog.

As always: Please report all bugs, without them, we can't fix them!
Since there is some confusion on how to handle bug reports, I have decided to post the bug reporting guidelines here:

Bug Reporting
Bugs are different kinds of errors and glitches that sometimes can even lead to crashes. Due to the limited resources of the Warzone 2100 Project not everything can be tested prior to release. In order to be able to fix those bugs we need you to report those bugs. For the bug reports to be the most helpful we put up this page as a guide to writing good bug reports.

How to report bugs

• Use the search to find out, if your bug has not been reported yet.
• If you did find it there and you have more information than was provided by the original reporter, add your information.
• If you did not find it, submit a new bug report
• Write something meaningful into the summary. Not just "I found a bug", but instead write "Crash when building units" (for example).
• Give a very detailed description of the bug and how to reproduce it. This is the most important information!
• If you are using the trunk version from Subversion, be sure to add the used revision, too.
• If you are using a version from a package repository, be sure to add information on the package.
• State which operating system and version of it you are running. This includes the service pack under Windows and the distribution on Linux.
• Information about the game options you chose and the drivers (video/audio) you use and your hardware is very useful to us.
• Additionally you could provide backtraces, logfiles, screenshots and other additional information you can get as an attachment. (Backtraces in pastebins ("nopaste") or on upload sites are NOT useful.)
• Savegames that can reproduce the issue are very much welcomed! Package the savegamename.gam, savegamename.es (if exists), and everything in the savegamename folder as well in a zip file.
• If you can, please attach the crash mini dump file to your bug report. If you are using an executable you compiled yourself, please attach the executable as well, so that the developers can use it to extract information from the dump file.
• On Windows, you can find stderr.txt & warzone2100.RPT (crash dump file) in the same directory as warzone2100.exe is in.
• On Linux, you can find the crash dump in /tmp.

Now that you know all this, use http://developer.wz2100.net/newticket to create a bug report!
Thanks!

As always, download from http://wz2100.net/download

Change Log

2009-09-13: Version 2.2.3
General:

• Fix: When ownership of a building changes while we are building it, tell our droids to stop building it. (ticket:895, r8125)
• Fix: Correct orientation of sound output in 3D (ticket:220, r8103)
• Fix: Some sounds were missing for super cyborgs (ticket:919, r8110, r8111)
• Fix: Some sounds were removed for baba screams (ticket:830, r8102)
• Fix: Do not sometimes crash due to integer underflow when picking up artifacts (ticket:373, r8084)
• Fix: Some building issues on BSD (r8116, r8133, ticket:817, ticket:823)

Multiplayer:

• Change: Add tileset dependent map preview colours (r8064)
• Fix: Crash if map preview during map download (r8079, ticket:756)
• Fix: Stop ability to bypass unit limits by hiding droids in transports (ticket:921, r8105)
• Fix: Cyborg transport being invincible while in the air (ticket:892, r8104)

Campaign:

• Fix: Assert failure on effect cleanup when entering third campaign (ticket:836, r8045)
• Fix: Infinite loop when transporting a sensor droid to offworld campaign map (ticket:852, ticket:853, r8062)
• Fix: Do not lower volume to zero when multiple videos queued up (ticket:670, r8106)

Graphics:

• Change: New skybox for urban maps, this one is licensed CC0, not CC-by 2.0 (ticket:922)

Scripting:

• Change: Added dummy version of function droidCanReach() that always returns true for backward compatibility (r8077)
• Fix: Do not crash in non-debug mode when calling allianceExists() with bad player ID (r8075)

[winsrp]

wow... finally fixed 3d sound... cool!!!
have you noticed the following

MIni map is one size when begining, then you make it bigger with mouse wheel, then you shrink it again, but it doesn't returns to the actual initial size... it stays 1 step bigger for the rest of the game, is this issue only with this new version?

[winsrp]

well I've already tested 3d sound, and seems to work great!!!.. great job.

And its also cool to see that newer version are coming faster!!!

[Kacen]

MIni map is one size when begining, then you make it bigger with mouse wheel, then you shrink it again, but it doesn't returns to the actual initial size... it stays 1 step bigger for the rest of the game, is this issue only with this new version?

I've had that issue before this version as well...don't remember when I didn't have the issue.

[Kreuvf]

Yay, new version :D

[A4tech]

Grim GFX seems to work perfectly with this version. Good job DEV's!

[whippersnapper]

Grim GFX seems to work perfectly with this version. Good job DEV's!

Actually, that's not how it works since "Grim's Mod" stopped being supported officially by the WRP a long while back and why I had to do what I did to make it compatible with the current sequence of binaries-data set releases.

That's not in any way to under value all the work the WRP devs have done to make this current release a success in a score of other areas that have nothing to do with "Grim Mod"...

That said, I can tell you EXACTLY what members of the WRP CAN DO in this sequence of future releases to continue keeping what I have done with "Grim Mod" compatible and it's very simple.

One of several things I did to make the mod compatible with the current dev sequence of binary-data sets is re-assign Grim's original custom texture page a new identity which I in turn followed thru consistently with changing the .wrfs accordingly.

The reason I had to do that is because Elio had used the same exact designation when he created his Naval Texture page and .wrfs

No biggie that really and here is the solution which I would guess mainly applies to Elio and possibly i-NoD since they are as of this time the only members of the WRP team likely to create / assign new texture pages in future releases.

Guys - don't use the same assignment identity I gave Grim's texture page. Simple. There's scores of unused identity assignments that can be used for any future texture pages you may creat / assign so it shouldn't be an issue to use one different than the one I assigned. That's it...... well .... until Gerard's new terrain renderer makes the mainstream release sequence. Then I don't know how that will exactly impact the custom tertile Mip-Maps I made that are also part of "Grim Mod". We'll cross that bridge when it arrives.

Regards, whip

.

[cybersphinx]

Guys - don't use the same assignment identity I gave Grim's texture page. Simple. There's scores of unused identity assignments that can be used for any future texture pages you may creat / assign so it shouldn't be an issue to use one different than the one I assigned.

Is that documented somewhere? If not, nobody knows which pages to avoid. The other way would be someone maintaining the mod following SVN, so when it breaks it is not "but it worked in 2.1", but "it broke in revision X", so finding the cause and fixing the mod will be much easier.

That's it...... well .... until Gerard's new terrain renderer makes the mainstream release sequence. Then I don't know how that will exactly impact the custom tertile Mip-Maps I made that are also part of "Grim Mod". We'll cross that bridge when it arrives.

Well, the main terrain uses new textures, so most of the tiles will not be used. At the moment, streets, craters etc. are still done with the old textures, and need to be "cut out" with transparency around them to look good on the new terrain.

[whippersnapper]

.

Guys - don't use the same assignment identity I gave Grim's texture page. Simple. There's scores of unused identity assignments that can be used for any future texture pages you may creat / assign so it shouldn't be an issue to use one different than the one I assigned.

Is that documented somewhere? If not, nobody knows which pages to avoid. The other way would be someone maintaining the mod following SVN, so when it breaks it is not "but it worked in 2.1", but "it broke in revision X", so finding the cause and fixing the mod will be much easier.

In the mod itself: pages 29 & 30. The last current page used by the WRP is page 28 for Elio's Naval Textures... so if you add entirely new texture pages... just with start with 31.... Actually one practical way of addressing this is to keep a wiki entry of ALL texture page numbers used - by the WRP as well as Modders. SVN for this is, IMHO, way over-kill and not practical in many respects... but then again, what the frack do i really know about any of this.

In any case, if that's too recondite or unmanageable then I know exactly how to fix the mod if it is broken because this is really the only way to break it save for the New Renderer already mentioned - re-assign page numbers that the WRP is not using...Simple, as already explained. I was just trying to be preemptively elegant which I define as avoiding known issues instead of creating them only to have to fix them - a strat useful to both Cathedral & Bazaar modus operandi I would think but then again that is all contingent on operant hegemony to be sure which applies as much to OSS projects as closed proprietary projects though most advocates of OSS would naively claim otherwise, I have no doubt.

That's it...... well .... until Gerard's new terrain renderer makes the mainstream release sequence. Then I don't know how that will exactly impact the custom tertile Mip-Maps I made that are also part of "Grim Mod". We'll cross that bridge when it arrives.

Well, the main terrain uses new textures, so most of the tiles will not be used. At the moment, streets, craters etc. are still done with the old textures, and need to be "cut out" with transparency around them to look good on the new terrain.

Ah I see. Thanks for explaining.. Basically 10 years of GPL licensed custom tertile assets have to be tossed in the proverbial dump heap or redone like so if you want anything beyond the 3 stock sets to use with the new renderer ..... That or create entirely new (or find appropriately licensed textures) to make additional custom tertile sets that can be used with the new renderer. Oh well, there are always pros and cons to be weighed in any major change advance in RL - this is no different and the pros I would say out-weigh the cons here, though I suspect there will only be the 3 official sets for many years to come.... but hopefully, I will be completely wrong in that guess.

Regards, whip

.

[Zarel]

Ah I see. Thanks for explaining.. Basically 10 years of GPL licensed custom tertile assets have to be tossed in the proverbial dump heap or redone like so if you want anything beyond the 3 stock sets to use with the new renderer ..... That or create entirely new (or find appropriately licensed textures) to make additional custom tertile sets that can be used with the new renderer. Oh well, there are always pros and cons to be weighed in any major change advance in RL - this is no different and the pros I would say out-weigh the cons here, though I suspect there will only be the 3 official sets for many years to come.... but hopefully, I will be completely wrong in that guess.

When Gerard first published his new terrain renderer, practically everyone loved it. But a few mappers realized that it would make it lots more difficult to make custom tilesets for maps.

This started a really huge argument, but the main idea was that the new tileset made all maps look lots better, and barely anyone made custom tilesets anyway, so yeah, pretty much the same conclusion you just came to.

[cybersphinx]

SVN for this is, IMHO, way over-kill and not practical in many respects... but then again, what the frack do i really know about any of this.

Hm, maybe I wasn't clear enough, I didn't mean to use SVN for the mod (though if I made a mod, I'd probably version-control it), but to test the mod not only against releases (since the changes between those usually are too large to find the exact cause easily), but to also check it frequently against the current SVN version of Warzone. I'm not sure how difficult that is to set up (I can do it in very little time on Linux, Windows looks like it takes quite a bit more), but it might be worth the effort for someone who is going to invest a significant amount of time into a mod. It might also help us developers better understand the problems of modders when we know exactly what kind of changes break things.

[whippersnapper]

SVN for this is, IMHO, way over-kill and not practical in many respects... but then again, what the frack do i really know about any of this.

Hm, maybe I wasn't clear enough, I didn't mean to use SVN for the mod (though if I made a mod, I'd probably version-control it), but to test the mod not only against releases (since the changes between those usually are too large to find the exact cause easily), but to also check it frequently against the current SVN version of Warzone. I'm not sure how difficult that is to set up (I can do it in very little time on Linux, Windows looks like it takes quite a bit more), but it might be worth the effort for someone who is going to invest a significant amount of time into a mod. It might also help us developers better understand the problems of modders when we know exactly what kind of changes break things.

Depends on the type of mod.

Grim Mod doesn't need that at all.

My WS mod absolutely does need that and I have been version controlling because it is the only way I myself can keep track of it's complex changes and relationship to the the binary / base.wz.....

AND, I am also making WS WRP "Break-Proof" which is why I decided NOT to introduce custom tertiles on the mapping side - that way it will even work with Gerard's new Terrain Renderer. The only way you will be able the break WS Map-Mod is if you break the WZ Campaign and if you do that you'll have to fix it in which case my WS Map-Mod will be back in business. Probably the only thing I'll have to do deal with sometime down the road is with converting my WZ scripting to LUA.

There are really only 4 basic ways to break a Mod as I see - understand it on all sides. And please tell me, anyone, if I am making some major oversight here.

1.) Conflicting texture page assignments as described in relation to the "Grim Mod" in my previous posts.

2.) Transitioning custom tertiles.... first from the .pcx originals to .png mip-maps and now to the new Terrain Renderer requirements... this we just covered too.

3.) WZ script to LUA.... this we haven't talked about but is really just using the converter you guys are gonna have to write if you are gonna keep the original campaign a part of the package moving forward not to mention extant skirmish A.I.s

4.) If and when you transition from .Pie to .Wzm - also not mentioned till just now but an obvious mod breaker to come.

That's it really and none of that requires SVNing on the modders end. Though, like I said in regards to my WS project, I'm version controlling to make it easier on myself to manage the complexity of what I'm doing and while that may be useful to other modders in understanding how results were achieved, I don't see it serving any practical end for the developers. Correct me if I am mistaken.

Again, it really comes down to those texture page assignments for new texture pages introduced by both the WRP artist mods and community artist mods. It's really just a matter of publishing what #'s are used by both so the same numbers are not used which is what breaks mods built around entirely original and new texture pages.

Assuming that moders know what they are doing their mods can only be broken in the above 4 ways.

Of course, if Mods are built to a current set of balance stats in the base.wz and do not include their own balance stat copies in their mod.wz then they can be obsolesced but NOT broken in the sense that they could still run in-game and not crash. Again the SVN here would serve the smart modder and not the developers. The smarter modder would include the stat files in his mod.wz in the first place to make it independent of any changes to base.wz so it couldn't be obsolesced, though it could lose it's popularity if the balance in base.wz is clearly superior in MP gaming.

I too hope this exchange here serves to make it better for all concerned and involved with making WZ a richer, more fun, expansive, immersive & stable gaming experience moving forward.

Regards, whip
.

.

[A4tech]

Get conclusion guys: grim.wz IS commpatible with v2.2.3 or NOT?

[whippersnapper]

Get conclusion guys: grim.wz IS commpatible with v2.2.3 or NOT?

Grim GFX seems to work perfectly with this version. Good job DEV's!

HUH ? Did I miss something or did you not already answer your own question BEFORE your first post. ?

There is no half-way working with Grim Mod - it's either / or. And I explained exactly why for those with a practical stake in these matters because they are active devs-creators.

This discussion has progressed to a broader context (with precise substance and specificity of related strats and tacs of creating-deving) in matters of concern to active modders-mappers-artists and developers, now and into the future. You don't have to belong to any of those active categories of participants in order to learn stuff of value however if you have NO interest in learning anything of substance and specificity as far as the nuts 'n bolts in deving WZ moving into the future, then I would suggest you move-on and have fun playing the game because you will get NOTHING out of this discussion unless you have that aforementioned commitment to learning... minimum.

Regards, whip
.

[edgatas]

when you will released 2.3 version because I'm working with speech translating, so I want to now if I have to hurry.