Re: [warzone2100-dev] 2.3 RC1 ETA Sunday, Dec. 20
On 12/19/09, Per Inge Mathisen per.x...@xx.com wrote: On Sat, Dec 19, 2009 at 2:04 AM, bugs buggy buginxx...@x.com wrote: The plan is to do a RC1 release this Sunday. IIRC there are some showstopper bugs in the new MP pre-game dialog code. See tickets 1241 and 1230. - Per There really isn't anything we can do about 1241, unless we say it is OK to switch positions *anytime* you want... (as in, always allow people to pick whatever map choice they want, and it will always swap positions...) Or perhaps make the host pick whatever teams / positions? For 1230, I wouldn't call that a showstopper, annoying, yes, but not a showstopper. AFAIK, that has to do with when the game updates. Will look at it. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.3 RC1 ETA Sunday, Dec. 20
The plan is to do a RC1 release this Sunday. If you can, get the stuff that needs to be done committed ASAP, and *hopefully* we can use the new xcode framework for Mac builds as well. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Warzone 2.3 Beta 4 is now out!
Warzone 2.3 Beta 4 is now out! Try it, and give us feedback! 2009-12-13: Version 2.3.0 beta 4 * General: * New: For windows people only, show a popup window for errors. (r8652) * New: Add config variable 'UPnP' to enable/disable UPnP detection / routines. 1=on, 0=off, default is ON. (r8651) * Change: Don't add UPnP redirects in singe player skirmish (r8649) * Fix: Loading savegames would sometimes make you the wrong player - this breaks all skirmish savegames - campaign savegames are fine (r8626) * Fix: Fixed endianness issues - PowerPC Macs can now play with others (r8593) * Fix: Hardware-accelerated cursors work correctly in Mac OS X (r8611) * Fix: Some crashes (r8596, r8636, r8677) * Multiplayer: * New: .message sends message to allies (r8640) * Change: 5message appears as (private to Blue) message instead of (private) 5message (r8640) * Fix: 5message now sends message to player in position 5 instead of ID 5 (r8640) * Fix: Game setup screen updates now happen instantly, instead of every 2 seconds (r8603) * Fix: AI difficulty slider can now be dragged continuously (r8601) * Fix: Map download progress doesn't clear chat screen anymore (r8603) * Fix: Map transfers should no longer crash. r8667 * Gameplay: * New: Multiplayer alliances menu now appears in Intelligence screen (r8638) * Change: Show proximity blips again for oil resources, but they do not blink on map (r8587) * Fix: Multiplayer alliances menu sorted by position again (r8638) * Fix: Bug that caused transporter not to disembark when auto-repairing and allow order to be queued (r8624) * Fix: Don't allow players to control the transport in single-player campaign. (r8666, r8670) * Scripting: * New: Function droidCanReach() allows checking if droid destinations are possible (r8644) * AI: * Change: AI will set all its droids to 'do or die' and no longer build repair centers (r8681) * Fix: Make AIs go for closest oil first (ticket:1166, r8632) * Graphics: * Change: New wall models for the player in campaign and in multiplay (r8665) * Translations: * Updated: French (r8614), Italian (r8661), German (r8662) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[8606] trunk/src/game.c
On 12/5/09, Per Inge Mathisen per....@xxx.com wrote: On Sat, Dec 5, 2009 at 7:48 AM, bugxxx...@xxx.net wrote: Revision: 8606 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=8606view=rev Author: buginator Date: 2009-12-05 06:48:18 + (Sat, 05 Dec 2009) Log Message: --- Skirmish game fix: Don't RemapPlayerNumber() for droids, they are a different kind of a beast. This maps the droids correctly now. Fixes ticket:1119 My mind refuses to parse this patch. Can you explain a bit what it is doing? Changing selectedPlayer like that seems... not sane. What, explain this? Who do you think I am... I plead the 5th! ;) Anyway, the issue with the droids is, that when we save out the droids, the list is in order by player. If we use RemapPlayerNumber() then we swap the player's numbers, but everything else still tied to the droid is still for that old player.The original code (pre dpid) just returned the same player number for that. For the productionPlayer = selectedPlayer = saveGameData.savePlayer; While we don't allow it at this time, in our case, this is always player 0. If we ever allow MP save games, then we can save each player this way. This is also a failsafe, just being sure that this is always set to the correct player. I also wanted to use the old dpid array (sPlayer2dpid[]) , that you have named sPlayerIndex[] to store the player's position, NetPlay.players[i].position for future use as well. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Current status of 2.3
On 12/5/09, Zarel zarel...@xx.com wrote: On Fri, Dec 4, 2009 at 11:08 PM, bugs buggy bugx...@xxx wrote: Just a heads up, I am leaning toward the next release to be 2.3 RC1. I'm fine with this. Working on some tickets that were reported for B3 now, but I don't see any real showstoppers yet. There's some guy on the forums who can't run 2.3b3 but is fine on 2.2.4. Go talk to him. I think his username is SCAVANGER or something? If you mean: http://forums.wz2100.net/viewtopic.php?f=4t=4239 if people don't read up on what they should post, then how can we help them? It gets highly annoying to see posts / trac tickets with basically no real information in them. With the release of 2.3, we will turn off the lobby server for 2.2. 2.0, and 2.1 have already been disabled. Per our IRC conversation, I feel that one or two weeks is too short. I'm thinking something like six months. The lobby server should be yelling at them to upgrade the whole time. It will spit back a message about updating, but 6 months is *way* too long. There really is no reason NOT to upgrade. Most large projects support versions far older than six months. While we don't have the manpower to do that, we also shouldn't intentionally refuse to do something as simple as leaving the lobby on. Remember, the latest version of Ubuntu will have no version of Warzone later than 2.2.2 until April 2010. You wouldn't believe how many 2.0 and 2.1 people still hosted (or tried to host) games! All the more reason not to retire the 2.2 server so early. No, that is the exact reason why to retire it ASAP. We want everyone to use the same version of the game. This will make a bigger userbase that all has the same version of the game, and will make it much easier to find games online. Let me clarify a bit, when I say turn off 2.2 server, I mean, it will still spit back the MOTD message, which will be something like. You are using a unsupported version of the game. Please update today! http://wz2100.net; or whatever... The addg will be disabled, the list will still show games, but it will show the X on the games, because of wrong version. Make sense? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.3.0 RC1 this weekend?
I forgot to mention, that since skirmish was broken, I think we need to push out a new build this weekend. (Only loading of skirmish games was broken) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[8606] trunk/src/game.c
On 12/5/09, bugs buggy bugx...@x.com wrote: On 12/5/09, Per Inge Mathisen per....@xxx.com wrote: On Sat, Dec 5, 2009 at 7:48 AM, bugxxx...@xxx.net wrote: Revision: 8606 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=8606view=rev Author: buginator Date: 2009-12-05 06:48:18 + (Sat, 05 Dec 2009) Log Message: --- Skirmish game fix: Don't RemapPlayerNumber() for droids, they are a different kind of a beast. This maps the droids correctly now. Fixes ticket:1119 My mind refuses to parse this patch. Can you explain a bit what it is doing? Changing selectedPlayer like that seems... not sane. What, explain this? Who do you think I am... I plead the 5th! ;) Anyway, the issue with the droids is, that when we save out the droids, the list is in order by player. If we use RemapPlayerNumber() then we swap the player's numbers, but everything else still tied to the droid is still for that old player.The original code (pre dpid) just returned the same player number for that. For the productionPlayer = selectedPlayer = saveGameData.savePlayer; While we don't allow it at this time, in our case, this is always player 0. If we ever allow MP save games, then we can save each player this way. This is also a failsafe, just being sure that this is always set to the correct player. I also wanted to use the old dpid array (sPlayer2dpid[]) , that you have named sPlayerIndex[] to store the player's position, NetPlay.players[i].position for future use as well. Hmm, looks like we still have issues with this. That fix only works sometimes. If we use the RemapPlayerNumber() for v7 game loads (ie, new skirmish games), then it works. If we use RemapPlayerNumber() on v36 games loads (new skirmish save games) then we get incorrect mapping done. I smell dpid voodoo going on... still working on a fix that works. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[8584] trunk/lib/ivis_common/tex.h
On 12/4/09, Zarel zarel...@xx.com wrote:
On Fri, Dec 4, 2009 at 6:05 PM, Stephen Swaney sswaxx...@.net wrote:
I'm curious what bug this was meant to fix.
The changeset diff looks like this:
--- lib/ivis_common/tex.h (revision 8583)
+++ lib/ivis_common/tex.h (revision 8584)
@@ -37,7 +37,7 @@
typedef struct
{
char name[iV_TEXNAME_MAX];
- unsigned int id;
+ unsigned long id;
} iTexPage;
I suspect that id member should be a GLuint. It seems to be used that
way in the code and this would get around all those problems Zarel had
trying to coerce some platform specific type into a GLuint.
If not, we probably have some deep issues here with word size since that
unsigned long is going to be 64 bits on some platforms and 32 bits on
others.
Basically, it's supposed to be GLuint id - using unsigned int
generates an Xcode compile warning, since GLuint is defined as an
unsigned long in Mac OS X. But for some reason, actually using
GLuint results in weird compile errors (even when I include the
relevant headers). I noticed that the warnings disappeared when I
changed the int to long, and another dev (I think it may have been
cybersphinx?) said something like if it gets rid of the warning,
commit it, and you know the rest of the story.
O_o ... so why not change it to what it should be? GLuint?
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[8594] trunk/data/base/images/frontend4.png
On 12/4/09, Zarel zarel...@ wrote: On Fri, Dec 4, 2009 at 2:22 PM, Kreuvf kreuvx...@warzonxx wrote: zare...@users.sourceforge.net wrote: Revision: 8594 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=8594view=rev Author: zarelsl Better ready? checkbox. It's only better if you know enough English to understand READY?. If not, you are more screwed than before IMHO. :( At worst, you're just as screwed as before, and you have to consider that most people, even if they don't speak English, should know Ready? if they play games online. This is the exact same problem I had with the generic 'square' that we use now...about a year ago. http://forums.wz2100.net/viewtopic.php?f=6t=1608 I think that about sums it up. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Current status of 2.3
Just a heads up, I am leaning toward the next release to be 2.3 RC1. Working on some tickets that were reported for B3 now, but I don't see any real showstoppers yet. With every new release we do, it is more stable than the last 'stable' release anyway, that is just how this project works, with the current lack of manpower. With the release of 2.3, we will turn off the lobby server for 2.2. 2.0, and 2.1 have already been disabled. This allows us to move our already small userbase to all be using the same version of the game, and that will hopefully get more people playing, and thus make it much easier to find games. You wouldn't believe how many 2.0 and 2.1 people still hosted (or tried to host) games! ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.3 Beta 3 is released!
Everyone get it now, and test it! :) Changelog: 2009-11-29: Version 2.3.0 beta 3 * General: * Change: Windows installer updated, and allows user to choose video to download (r8561, ticket:) * Fix: Make Warzone work correctly in Mac OS X again. (r8469, r8481) * Fix: Some crashes. (r8478, r8498, ticket:1099) * Gameplay: * Fix: Friendly fire wasn't working correctly. (r8496) * Fix: REALLY REALLY make sure AIs can't build on burning oil resources. (r8493) * Multiplayer: * Change: Put UPnP device detection into a background thread. (r8563) * Change: Multiplayer game setup screen changes including sort by position and show info for AIs (r8559) * Fix: Games with exactly 5 players no longer have template issues. (r8500) * Fix: Map transfers improved. (r8533, ticket:1104) * Fix: When host drops a game, broadcast a dropped message. (r8538) * Fix: Player count in lobby. (r8538) * Campaign: * Fix: Transport works correctly in campaign now. (r8540) * Graphics: * Change: Backport building blueprints from trunk. (r8562) * Change: Make use of the new scavenger icons (ticket:1093, r8488) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.3 BETA 3 set for release on 11-29-09
Since the Mac build has issues and wasn't released, and some other bugs were squashed, guess we should throw up a new BETA 3 release. The plan is for the new builds to go online on 11-29-09. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Warzone 2100 2.3 Beta 2 is now out!
Testing continues with this new release. Please Test! NOTE for packagers, do NOT use physfs2.0, since it will not work with our codebase until we get unicode support. Check our sourceforge site for the files http://sourceforge.net/projects/warzone2100/files/ 2009-11-21: Version 2.3.0 beta 2 * General: * Change: Allow either the normal return/enter key or the numpad enter key to terminate strings. (r8425, ticket:1055) * Change: Alt+click now works in Mac OS X. (r8432, ticket:1084) * Change: New and improved HP bars! Now 2 pixels high! (r8428) * Change: New game mode - challenges. See who can complete a fixed game setup the quickest! (ticket:778) * Fix: Assorted bug fixes (r8399, 8400, * Gameplay: * Change: You can now repair/rearm/upgrade/guard allied units and structures. (r8432, ticket:1084) * Change: Cursors should now more accurately represent what happens when you click there. (r8432, ticket:1084) * Change: Cyborg transports can be unloaded with Alt+click. (r8421, ticket:1084) * Change: VTOLs will scout with Alt+click. (r8432, ticket:1084) * Change: Repair turrets are more reliable now, and don't fidget before repairing. (r8421, ticket:1084) * Change: You can damage your own units/structures with Alt+click again. Allies are still immune. (r8432, ticket:1084) * Change: Cyborg transports should fly at a lower height now - so they shouldn't take so long to descend. (r8430) * Multiplayer: * Change: Add UPnP support to automatically forward the needed ports on supported routers (r8445, r8446, r8447, r8449, ticket:1073) * Change: In skirmish always show position of and do not show proximity messages for oil wells (r8444, ticket:1087) * Fix: Set AI colors (r8409, ticket:1070) * Fix: Enable/disable AIs (r8409, ticket:1065) * Fix: Send team position (r8409, ticket:1075) * Fix: Add missing wrf files for limiter screen. (r8408) * Graphics: * Fix: Corrected cyborg transport model (r8404) * Fix: Correct menu captions (r8414) * Translations: * Updated: German (r8452), Dutch (r8412) * Mods: * NTW: Cannons and Cyborgs balance update (r8395) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Dropping online support for all but the latest versions of warzone?
Is there any good reason why we still have 2.0 2.1 lobby support online? The lobby server shouldn't be made to support those versions, since people never upgrade. Those versions can't be told via a MOTD that a new version is waiting, so I think it is best if we turned off the lobby server for those versions. It is splitting our userbase, and makes it that much harder if everyone is using different versions. Comments? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3 Beta 2 release ETA 11-21-09
On 11/19/09, Dennis Schridde devuran...@xxx.net wrote: Am Donnerstag, 19. November 2009 08:43:06 schrieb Dennis Schridde: Hello! Am Mittwoch, 18. November 2009 22:18:40 schrieb bugs buggy: All known fixable *REPORTED* bugs for 2.3b1 have been squashed, so we need another beta release to keep our testing pool testing. :) The plan is to have another release this Saturday, the 21st. In response to the recent discussion, I'd add that now everyone with time and interest could try to build and test $svn/branches/2.3 (assuming there are no changes about to happen on it anymore), so that the release builds can be created quickly after the tag. I thought that is what we basically do now... P.S: Maybe WZP would like to get an ACK (+ eventual time constraints) from everyone involved in release-critical performances, e.g. package creation, so Buginator can see how to best rollout the release. That could be Zarel for MacOS packaging and is there someone creating Linux installers? Maybe coordination/information of distros would be worth a try, i.e. pabs for Debian, nyhm / mr_bones for Gentoo, and possibly others. --devu Let me add, I am pushing out BETAs far faster than we have ever done before, and the main reason for this is, we need feedback testers. This is in response to what pabs said for when we need to get the next 'stable' build to debian (ubuntu) by the end of Dec. That doesn't leave us much time, so I feel having weekly (or bi-weekly) BETA releases is the way to go. For building, I do windows + the linux tarball, and Per also does linux tarballs and fedora releases when he can. Zarel does the Mac builds (for the last three releases I think it is). ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3 Beta 2 release ETA 11-21-09
On 11/19/09, Zarel zarelxxx...@.com wrote: In response to the recent discussion, I'd add that no one should under any circumstances announce the release on the forums or ML, or edit the homepage or downloads page, unless either at least 24 hours have passed since the tagging, or a Mac build is available. Um, I think not. We *need* feedback testers ASAP. Our userbase is mostly all windows and linux users. In order to get as much feedback and testing done on the BETAs, then it is imperative to releases as quickly as we can. It just doesn't make any sense at all to hold up releases, thus holding up feedback testing that we so desperately need, just because you think that Coming soon! is akin to the end of the world. 24 hours can mean all the difference between getting that much more feedback / testing / bug reports being done. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Mac builds!
The main problem that we have is that the Mac build system is far more complex than it needs to be, and is causing our Mac builder grief. It is very hard to change (update) libs with the current Xcode project file. The old maintainer who made the Xcode project file (Ari?) hasn't been around for many moons. Thus, I suggest we scrap the current Xcode project file, and simplfy it. There really is no reason why the Xcode project file needs to download all the external libs we need, and build everything that way. All that needs to be done is build our sources, and then we can link externally like the way it is done on windows linux builds. This will allow us to make Mac builds much faster than the current situation that we have now. Evilguru, perhaps you can lend your expertise in the Mac area to help us fix the issues we have with the build process for the macs? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3 Beta 2 release ETA 11-21-09
On 11/20/09, Zarel zarel...@xxcom wrote: On Fri, Nov 20, 2009 at 9:41 PM, bugs buggy buginxx...@xx.com wrote: Um, I think not. We *need* feedback testers ASAP. Our userbase is mostly all windows and linux users. In order to get as much feedback and testing done on the BETAs, then it is imperative to releases as quickly as we can. It just doesn't make any sense at all to hold up releases, thus holding up feedback testing that we so desperately need, just because you think that Coming soon! is akin to the end of the world. 24 hours can mean all the difference between getting that much more feedback / testing / bug reports being done. 1. What about for stable builds? I'd be fine if you just waited 24 hours for stable builds. Ok, will do that for stable builds. Though, we still need to announce it on the ML, so everyone knows to build whatever. 2. What about leaving the old download links up there, while the new download links aren't available? I'd be fine with that approach, too. If we do 1), then 2) isn't a issue... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Changelog
Guys, if you don't mind, can you also update the Changelog for whatever you have done? I am unsure what to enter for a few of the patches that were committed after B1. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 1 hour left before the tagging of 2.3 B1 (also a comment about branches/2.2)
On 11/15/09, Zarel zarex...@x.com wrote: On Sat, Nov 14, 2009 at 12:10 PM, bugs buggy buginxx...@x.com wrote: About 1 hour left before I need to tag and build everything. This really is your last chance to get anything you wanted in 2.3B1. On Sat, Nov 14, 2009 at 2:53 PM, bugs buggy buginx...@x.com wrote: Warzone 2100 2.3 Beta 1 has now been released! But this isn't nearly as frustrating to me as the way you do it. Not nearly so bad this time, since the old version is still on the Download page since this is a beta. But usually, you just remove all other downloads from the download page, so for a short period of time, no one other than Windows users (and people who compile from source) can download Warzone. And for some reason, you see nothing wrong with this. Because there is nothing wrong with it? Seriously, when we do a new release, whatever the release is, then we want people to get the new release. The old versions go in the unsupported bin as far as I am concerned. We don't have the manpower to handle everything... Not even because I'm delaying the release, either. I usually get Mac builds up within 24 hours. It's been around 15 since tagging as of right now, and I have Mac builds up. That's shorter than the few days we're supposed to wait between tagging and announcing to release publicly. I've given up trying to convince you to leave old versions on the download page while the new versions haven't been built yet. But could you at least wait 24 hours for me? That's all I ask. I don't understand what the issue is time is short. I do as much as I can in the little amount of free time I have. I have no idea when or even if any other builds except the ones I make will (ever) be released. I have no clue if any of the other devs can or will do anything from the period I am off, to the period I get back. I don't know my schedule in advance, so that could be a few days or weeks or more. That is why, as soon as I finish the uploads, I throw them up, and have the Coming soon! tag for the missing versions. If I could make all builds I would, but unless Jobs sends me a mac, that isn't going to happen. When another dev can make the build they just edit the page... that isn't asking too much, and I am sure users understand that Coming soon! means just that... whenever someone has time to make it, they will. Time is the enemy here. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 1 hour left before the tagging of 2.3 B1 (also a comment about branches/2.2)
On 11/15/09, Dennis Schridde devurx...@xx.net wrote: A strict code-freeze for, say, a week, including the thorough testing on all OSes/arches as mentioned above, with the final builds being created right after the tag, might work just as well. Again, only provided that it is guaranteed that everything actually happens as planned and everyone starts working during that freeze already. Experience and this thing being a game, run in spare time, make me sceptic. But why not try something new, if you feel that suits you better. I (and thus the release-checklist) certainly do not want to stay in the way of advancement, but rather explain why some rules were invented. If there are better solutions to old problems, that is certainly a good thing. That would never work with the limited manpower time constraints many of us have. In a perfect world, with enough people to do everything on the release checklist, sure, but as it is now, that just is not possible and very impractical. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Mac builds for 2.3.0 B1 should update the external libs we use
On 11/14/09, Zarel zarel...@xx.com wrote: On Fri, Nov 13, 2009 at 11:24 PM, bugs buggy bugixxx...@x.com wrote: SDL 1.2.14 is out, and if fixes numerous bugs for OS X. libogg 1.1.4, libvorbis 1.2.3 and libtheora 1.1.1 libs also have bug fixes. Does anyone know what the current libs our OS X builds use? SDL 1.2.13, libogg 1.1.3, libvorbis 1.2.0, libtheora 1.0beta3. SDL 1.2.14 hasn't been released for Mac OS X yet, as far as I can tell (the downloads only have SDL runtimes and SDL-devel-extras, no SDL-devel). -Zarel I guess you would have to compile from sources if you want the latest versions. The libogg/vorbis stuff was a priority since those PPC guys had issues with music, and those newer versions fix a bug that had to do with that. The SDL update fixed mouse cursor trapping issues, among other things. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 1 hour left before the tagging of 2.3 B1 (also a comment about branches/2.2)
About 1 hour left before I need to tag and build everything. This really is your last chance to get anything you wanted in 2.3B1. Commit to 2.2_net! For branches/2.2, I will not be doing anymore comits to that, since I don't see a real need for it. 2.2_net will be where all (my) work will be done, since I just don't have time to backport everything. Also, with the anti-dpid stuff, things start to break very quickly for the multi*.c and netcode changes. Which means, there is no easy 1:1 porting from 2.2_net back to 2.2. Yes, I plan on porting the patches from 2.2_net back to trunk, when I get back. :) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Warzone 2100 2.3 Beta 1 has now been released!
Warzone 2100 2.3 Beta 1 has now been released! We need everyone to test this ASAP, it has many changes in it and we await your feedback! Thanks! === Changelog === 2009-11-14: Version 2.3.0 beta 1 * General: * Fix: Use Enable GLC_AUTO_FONT to enable it to fallback to different fonts if the default font doesn't contain the needed font. (r8365) * Change: Try to display dialog box when a internal game error causes game to crash on Windows (r8307) * Fix: Reduce the time it takes to rebuild font cache on Vista and Windows 7 (ticket:1013, r8322) * Fix: Collection of smaller bugfixes (ticket:997, ticket:1018, ticket:1021, ticket:1006) * Change: Switched fontconfig question from scary pop-up message to NLS sub-feature (r8359, ticket:1034). * Fix: make distcheck should now work after initial make (to generate yacc/lex files) (r8360) * Add: add new debug flag of input used for debug messages for input issues (keyboard/mouse) (r8376) * Change: Add modifier to the keymap editor to show which keys are set to the numpad (r8376) * Change: Warzone 2100 -2.3 is the new (default) config direcotry (r8387) * Change: NTW Research Balance Update, Cannons, Missiles Rockets (r8385) * Multiplayer: * Change: Drop SDL_NET in favor of using BSD sockets (same as trunk code) (r8342, ticket:1038) * Change: Try to mitigate turnOffMultiMsg() via setting isMPDirtyBit when needed. (r8369) * Change: Max unit count is down from 300 to 150 to mitigate bandwidth issues. (r8369) * Change: Sync code is now run when isMPDirtyBit is set or 315ms has expired for droids / 630ms for power / 450 ms for structures (r8383) * Change: Ping (in game, not lobby!) Score is now sent more frequently (r8369) * Change: MAX_BYTESPERSEC bump up to 7K from ~3.3K to mitigate when we can sync. (r8369) * Change: When we have reached MAX_BYTESPERSEC limit, inform of this event in the logs **FOR THIS BETA ONLY** (r8369) * Change: Only tally up outgoing bytes instead of both incoming and outgoing bytes when checking for max packet size. (8386) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] LAST CALL! 2.3.0 beta 1 about to be released Sat. Nov 14
Hope everyone has everything they wanted to stick into 2.3.0 beta 1. The plan is to make a release around UTC Saturday, November 14, 2009 at 20:00:00 Give or take a hour. :) Should the config directory be renamed to warzone 2100 2.3 as follows ? # define WZ_WRITEDIR Warzone 2100 2.3 #elif defined(WZ_OS_MAC) ... # define WZ_WRITEDIR Warzone 2100 2.3 #else # define WZ_WRITEDIR .warzone2100-2.3 BTW, all keymaps need to be reset since of the slight name change of one of the options. = Latest Changelog is now: 2009-11-14: Version 2.3.0 beta 1 * General: * Fix: Use Enable GLC_AUTO_FONT to enable it to fallback to different fonts if the default font doesn't contain the needed font. (r8365) * Change: Try to display dialog box when a internal game error causes game to crash on Windows (r8307) * Fix: Reduce the time it takes to rebuild font cache on Vista and Windows 7 (ticket:1013, r8322) * Fix: Collection of smaller bugfixes (ticket:997, ticket:1018, ticket:1021, ticket:1006) * Change: Switched fontconfig question from scary pop-up message to NLS sub-feature (r8359, ticket:1034). * Fix: make distcheck should now work after initial make (to generate yacc/lex files) (r8360) * Add: add new debug flag of input used for debug messages for input issues (keyboard/mouse) (r8376) * Change: Add modifier to the keymap editor to show which keys are set to the numpad (r8376) *NOTE*: Please reset your keymap! (Click on the trashcan icon a few times) *Multiplayer: * Change: Drop SDL_NET in favor of using BSD sockets (same as trunk code) (r8342, ticket:1038) * Change: Try to mitigate turnOffMultiMsg() via setting isMPDirtyBit when needed. (r8369) * Change: Max unit count is down from 300 to 150 to mitigate bandwidth issues. (r8369) * Change: Sync code is now run when isMPDirtyBit is set or 135ms has expired for droids / power / structures (45ms per frame (locked) so ~ every 3 iterations ) (r8369) * Change: Ping (in game, not lobby!) is now sent every 4 iterations and Score is sent every 5 (r8369) * Change: MAX_BYTESPERSEC bump up to 7K from ~3.3K to mitigate when we can sync. (r8369) * Change: When we have reached MAX_BYTESPERSEC limit, inform of this event in the logs **FOR THIS BETA ONLY** (r8369) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Remove SQL from 2.2 trunk
On 11/8/09, Zarel zarelxx...@xx.com wrote: On Thu, Oct 29, 2009 at 7:29 PM, bugs buggy buginxx...@xx.com wrote: The CSV format is much more easier to troubleshoot (old code worked fine before), and as a added plus, it appears we are getting more editors made for modifying this stuff. Hopefully, they will do a QT port of it. (Yes, I know we could export sql to csv...) Can we rename the files from .txt to .csv? That might make modding easier. -Zarel Not really for it, I don't like renaming files, would mean we must revert all those files if we need to hunt for bugs, and that is such a PITA with svn. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Mac builds for 2.3.0 B1 should update the external libs we use
SDL 1.2.14 is out, and if fixes numerous bugs for OS X. libogg 1.1.4, libvorbis 1.2.3 and libtheora 1.1.1 libs also have bug fixes. Does anyone know what the current libs our OS X builds use? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Final call for 2.3.0 beta 1 (ETA to release Sat, Nov 14, sometime after 6PM)
For those of you that want to get whatever in this BETA release, please do so ASAP. For the netcode, this is pretty much trunk's netcode plus some modifications to a few defines to get it to sync up more often, and to spit out info when we can't sync since the packet would be too big. I also lowered max units from 300 to 150. Other than that, I haven't really touched it. And the reason for the release on Sat, is because I will not be here Sunday--and I won't return until the 21st (I think) We need to have a 'stable' release by the end of Dec. == This is the current Change log: 2009-11-14: Version 2.3.0 beta 1 * General: * Fix: Use Enable GLC_AUTO_FONT to enable it to fallback to different fonts if the default font doesn't contain the needed font. (r8365) * Change: Try to display dialog box when a internal game error causes game to crash on Windows (r8307) * Fix: Reduce the time it takes to rebuild font cache on Vista and Windows 7 (ticket:1013, r8322) * Fix: Collection of smaller bugfixes (ticket:997, ticket:1018, ticket:1021, ticket:1006) * Change: Switched fontconfig question from scary pop-up message to NLS sub-feature (r8359, ticket:1034). * Fix: make distcheck should now work after initial make (to generate yacc/lex files) (r8360) *Multiplayer: * Change: Drop SDL_NET in favor of using BSD sockets (same as trunk code) (r8342, ticket:1038) * Change: Try to mitigate turnOffMultiMsg() via setting isMPDirtyBit when needed. (r8369) * Change: Max unit count is down from 300 to 150 to mitigate bandwidth issues. (r8369) * Change: Sync code is now run when isMPDirtyBit is set or 135ms has expired for droids / power / structures (45ms per frame (locked) so ~ every 3 iterations) (r8369) * Change: Ping (in game, not lobby!) is now sent every 4 iterations and Score is sent every 5 (r8369) * Change: MAX_BYTESPERSEC bump up to 7K from ~3.3K to mitigate when we can sync. (r8369) * Change: When we have reached MAX_BYTESPERSEC limit, inform of this event in the logs **FOR THIS BETA ONLY** (r8369) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Pushing out 2.2.5 b 1 (or 2.3.0 b 1)
On 11/8/09, Christian Ohm chr.xx...@x.net wrote: On Sunday, 8 November 2009 at 13:50, Per Inge Mathisen wrote: On Sat, Nov 7, 2009 at 7:09 PM, Christian Ohm chr.x...@.net wrote: Hey, I didn't decide that exactly. I'd branch 2.3 off from 2.2, and merge 2.2_net into it. Then we release 2.3 betas/rcs from that, and keep 2.2 and 2.3 in sync (apart from the netcode) until 2.3.0, accompanied by one last 2.2 release. Sounds like a lot of work... but I won't stand in the way if you want to do it. Well, that's what I would do, but I can't do the actual release builds etc. Not sure if anyone else wants to keep 2.2 around. But I don't think the 2.3 beta cycle should be very long, since most people will wait for a real release anyway, so the parallel 2.2/2.3 phase shouldn't be that much work. Sorry guys, can't get the newer dev package to work correctly, and I am out of time for doing a release today. Thus, it is postponed, until I get back next week. :( BTW, we would have 2.2_net, 2.2, 2.3.0 b1 (tag made from 2.2_net) and trunk...right? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Pushing out 2.2.5 b 1 (or 2.3.0 b 1)
It is pretty obvious that we don't really have enough active developers to test everything ourselves and I think it would be best for us (and the project overall) if we start the ball rolling with a new release. 2.2_net is 2.2's code + trunk's netcode which means, people can play 8p games again... However, there could have been some other issues that crept in during the merge, and so, we need lots more people to test things. Should we release 2.2.5 b1, or just release it 2.3.0 b1 or what? The plan is to push out something by Sunday night to get the testing pool started. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[8323] trunk/src/multiplay.h
On 11/1/09, Kreuxxxkre...@xx.de wrote: buginxxx...@xx.net wrote: Revision: 8323 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=8323view=rev Author: buginator Date: 2009-10-31 04:43:31 + (Sat, 31 Oct 2009) Log Message: --- Change ping 'traffic light' detectors to more realistic values that more accurately show what kind of a connection they have compared to you. low pings (green light) is from 0-200 (was 0-600!) medium pings (yellow light) is from 400-1000 (was 600-1200!) high pings (red light) is from 1000-2000. (was 1200-2000) According to the code-changes it looks more like the new values are: low/green: 0 ms to 200 ms med/yellow: 200 ms to 400 ms high/red: 400 ms to 1000 ms - Kreuvf Yeah.. I noticed that after the commit. Too bad we can't edit logs. Oh well. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Remove SQL from 2.2 trunk
On 10/30/09, Per Inge Mathisen per.xxx...@com wrote: On Fri, Oct 30, 2009 at 2:29 AM, bugs buggy bugxxx...@x.com wrote: Thus, I wish to revert all SQL changes in 2.2 (yes, it still has sql stuff in it) and trunk. I support this. - Per Done. Everyone can now test :) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[8307] branches/2.2
On 10/30/09, Per Inge Mathisen per.xxx...@xxx.com wrote: On Fri, Oct 30, 2009 at 1:49 AM, bugxx...@xx.net wrote: Add a new debug flag type, LOG_FATAL. Neat. I would like to see a new macro for this, say, for example, ASSERT_OR_DIE(). Seeing all those abort() calls in the codebase really feels wrong. I suppose you will commit this to trunk as well? ;-) You and your backports.. err frontports... whatever ;) More like a FATAL() macro, since we don't really assert at all on those nor should we, since if someone does --noassert the machine will still go down in flames. Anyway, I just had some conflicts to take care of first, that is why I didn't patch trunk then. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Remove SQL from 2.2 trunk
As was previously discussed numerous times, I would like to actually do it now while I have some time to do this. While the original intent of using SQL was good in theory, in practice, it adds another layer of complexity and another area of speciality that we could do without. The meta language is another sore point that we don't really need either. It currently is very tedious to add / change / fix things. Debugging this stuff is almost as bad as debugging scripts--and requires working knowledge of SQL and the meta language. The CSV format is much more easier to troubleshoot (old code worked fine before), and as a added plus, it appears we are getting more editors made for modifying this stuff. Hopefully, they will do a QT port of it. (Yes, I know we could export sql to csv...) Thus, I wish to revert all SQL changes in 2.2 (yes, it still has sql stuff in it) and trunk. Plan is to do this by Friday night / Sat morning if no objections are heard. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] devpkg
On 10/28/09, Zarel zarexxx...@xcom wrote: 2009/10/28 i-NoD i-...@xxxcom: Hello Zarel, I've an updated devpkg for MSVC but I don't to stack it inside devs wiki. Could you please hint me a person who is in charge of http://download.gna.org/warzone/development/devpkg/ repo? Thanks, i-NoD No one, specifically. All you need is a Gna account. Also: Why not use the mailing list? Last time I checked, Devurandom was doing some updates for mingw, and I did some updates for MSVC. AFAIK, the only thing that changed was the library name for theora.lib to theora-static.lib, and I mentioned the changes in the svn log. :) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] next debian freeze
On 10/19/09, Kreuvf kreuxx...@xx.de wrote: Giel van Schijndel wrote: Got this message from Paul Wise on IRC: 16:36 pabs3 Giel: Debian freezes in March 2100, would be good if WRP folks could think about which version they want in stable. http://lists.debian.org/debian-devel-announce/2009/10/msg2.html What a Freudian slip: March 2100 Really made me laugh, thanks ^_^ And to have at least the minimum of useful content I can come up with picky stuff: The project has been renamed to WZP (Warzone 2100 Project). What slip, March 2100 sounds about right too me! ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.2.4 is tagged, and headed for release
All 2.2.4 builds will be uploaded as soon as we can make them. Thanks to everyone for their hard work! Changelog: 2009-10-11: Version 2.2.4 * General: * Fix: Indirect fire weapons can no longer use sensors to fire at targets the sensor cannot see. (r8177) * Fix: Improved error handling in some cases - try to avoid crashing (ticket:962) * Fix: Bug in map renderer that would cause non-power of two maps to display wrongly. (r8208) * Fix: Added support for ATI-specific two-sided stencil extension. Will decrease CPU usage on ATI cards. (r8185) * Fix: Correctly handle savegame names (ticket:981, r8227, r8246) * Campaign: * Fix: Improve anti-air and make it more like the original by making AA shots homing like in skirmish (r8258) * Multiplayer: * Change: Data integrity check is added. This will break network connectivity with 2.2.3. (r8205, ticket:961) * Balancing - skirmish (r8262): * Most projectiles 1.5x faster to reduce sync problems * Mini-Rocket Artillery renamed Mini-Rocket Array * MRL Emplacement renamed Mini-Rocket Battery * Angel Missile renamed Seraph Missile Array * Angel Missile Battery renamed Short-Range Missile Battery * Hurricane splash increased 10 - 30 * Cyclone splash increased 40 - 60 * Whirlwind splash increased 30 - 50 * Avenger and Vindicator damage increased 320 - 350, accuracy increased 60%-70% - 70%-80% * Stormbringer damage increased 140 - 180 * All lasers now have 80%-80% accuracy * Plasmite Bomb weight increased 8000 - 12000 * Mini-pod can hit air targets * Decrease Pulse Laser and Heavy Laser ROF, increase corresponding damage * Decrease VTOL MG damage, increase VTOL MG shots-per-rearm * Artillery to hover multiplier decreased from 110% to 100% * Artillery to tracks multiplier decreased from 65% to 50% * Artillery to half-tracks multiplier decreased from 80% to 70% * Artillery to wheels multiplier decreased from 95% to 90% * Anti-tank to hover multiplier decreased from 100% to 90% * AP to hard multiplier increased from 45% to 50% * Seraph Missile Array range increased from 5-11 to 5-14 * Command Center must be built before MG tower can be researched * Truck HP decreased 50 - 25 * Truck weight increased 600 - 800 * Inferno bunker research price 150 - 125 * Plasmite bunker research price 150 - 125 * Plasma Cannon radius increased from 1 to 3.5 and range from 5.5 to 6 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend
On 10/10/09, Per Inge Mathisen perxxx...@ wrote: I think the network incompatible story is a red herring. People should NEVER play with different versions of the game, period. This is asking for trouble, unless all the changes between the two versions are purely cosmetic or crash fixes. Since the game is based on peer to peer algorithms, playing with different versions/features will lead to off-sync. Most releases IIRC add some things are not pure crash fixes, yet we do not bump the minor version number. What we should do is make all releases network incompatible, like almost all other RTS games do it. The minor version number should be reserved for savegame incompatibility. The major version number should be reserved for mod/map incompatibility. This means, 2.2.4 should go forward, and trunk should become 2.3. IMHO. I couldn't have said it better. I still plan to release 2.2.4 this weekend, unless someone can come up with a very good reason not to. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend
On 10/10/09, Zarel zarelxxx...@xxx wrote: On Fri, Oct 9, 2009 at 11:23 PM, bugs buggy bugxxx...@x wrote: It's not so much about saving people 3 characters, as about not having to guess when to use .wz and when not to. Meh, why are we even arguing this? I'm applying part of my patch, it doesn't hurt anything, and I doubt you'd be so malicious as to revert it. I never said I would revert it, I just don't see a need for it. [...] I rather stick with 2.2.4 and so on, [...] Here's some more stuff on why we shouldn't release 2.2.4: while I don't really know who mordante is, let me just say this... [14:36] mordante stable is bugfix only [14:36] mordante as it should be (tm) [14:37] mordante or you need to state your policy that every patch release is incompatible, how often do you release patch versions The whole point of the DI routines *was* to make it _more_ stable. Right now, people would crash or have other weird behavior because we couldn't check the data before. In this sense, it IS a bugfix. It just happens to require everyone to upgrade, which is not unreasonable or bad practice IMO. We should revert your commit to 2.2, if you don't want to release 2.3.0 yet. Not. See above for the why. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend
On 10/10/09, Zarel zarelxxx...@xx wrote: I guess that it's not _that_ big of a deal to make minor versions netcode incompatible (biggest consideration is probably that people using the version from Ubuntu repositories won't be able to play with people on other platforms, since Ubuntu never updates stable repositories, but then again, that's usually true either way...). But then we would need one copy of the lobby for each minor version, which would get kind of extreme... Also, updating requires downloading at _least_ a 50 MB file, which is a disincentive for many people to update. Eh? How does the lobby play a role in this? It would still use the same lobby, and in fact, it does. That code has *not* changed. The only change is a new message packet, and old clients wouldn't know what to do with it, so it would ignore it. The host will wait X amount of time (while in game) for the packet, and if nothing is received, then it will auto-kick them. 50MB isn't that big, most driver packages are pretty close to that. On Sat, Oct 10, 2009 at 10:58 AM, bugs wrote I still plan to release 2.2.4 this weekend, unless someone can come up with a very good reason not to. I have balance changes I need to commit! Give me time! I hope it is quick, since otherwise, I most likely will not be around until the end of the month. Which is why I have been saying get all the patches in ASAP since before I left last week. As long as we make it _very_ clear to everyone that it's netcode-incompatible. You make it sound like this is a big deal, but 99% of our user base upgrades when a new release is out... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Old School Mod (1.10) for the SVN?
On 9/16/09, jurgf...@ jurgf...@xxx wrote: Hi all : ), i would like to do a Old School Mod with the v1.10 stats folder only. And now i wanna ask for the SVN permission (i got SVN access). There are many Players outside which dont like the new balance... ... whatever the reason is, but i know that : ). So, what do you think about it? Its a good idea for sure ; ). -- Delphinio Delphinio, the mod's banner is too big, and also could be a (c) violation. I do not think it will be allowed in Debian, so that pretty much means we need to change the file ASAP or remove the mod. http://warzone2100.svn.sourceforge.net/viewvc/warzone2100/branches/2.2/data/mods/multiplay/original/images/frontend0.png?revision=8184view=markup Also, when you brand the mods, you write made by... and not packaged by... There is a difference. There is no real need to do this, you have your name in the AUTHORS file, like everyone else, and if need be, we could throw up a 'credits button' one of these days. For the NTW mod, you changed the AI to BP, and this screws up debug builds of the game. It asserts pretty much as soon as you start playing a game. Also, care to explain what is going on here: http://warzone2100.svn.sourceforge.net/viewvc/warzone2100/branches/2.2/data/mods/multiplay/ntw/images/frontend0.png?revision=8058view=markup I have no idea what that logo is, and I don't mean to offend you, but it looks pretty bad compared to what we are using now. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Old School Mod (1.10) for the SVN?
On 10/10/09, bugs buggy buginxx...@x wrote:
On 9/16/09, jurgf...@ jurgf...@xxx wrote:
Hi all : ),
i would like to do a Old School Mod with the v1.10 stats folder only.
And now i wanna ask for the SVN permission (i got SVN access).
There are many Players outside which dont like the new balance...
... whatever the reason is, but i know that : ).
So, what do you think about it?
Its a good idea for sure ; ).
-- Delphinio
Delphinio, the mod's banner is too big, and also could be a (c)
violation. I do not think it will be allowed in Debian, so that
pretty much means we need to change the file ASAP or remove the mod.
http://warzone2100.svn.sourceforge.net/viewvc/warzone2100/branches/2.2/data/mods/multiplay/original/images/frontend0.png?revision=8184view=markup
Also, when you brand the mods, you write made by... and not
packaged by... There is a difference.
Note, Zarel fixed the above issue.
http://warzone2100.svn.sourceforge.net/viewvc/warzone2100/branches/2.2/data/mods/multiplay/original/images/frontend0.png?revision=8255view=markup
We need these strings in LANG_DUTCH, and LANG_GERMAN for the NSIS script.
LangString TEXT_SecOriginalMod ${LANG_ENGLISH} Original 1.10 balance
LangString DESC_SecOriginalMod ${LANG_ENGLISH} Play the game with
the original 1.10 version balance stats.
There is no real need to do this, you have your name in the AUTHORS
file, like everyone else, and if need be, we could throw up a 'credits
button' one of these days.
For the NTW mod, you changed the AI to BP, and this screws up debug
builds of the game. It asserts pretty much as soon as you start
playing a game.
Also, care to explain what is going on here:
http://warzone2100.svn.sourceforge.net/viewvc/warzone2100/branches/2.2/data/mods/multiplay/ntw/images/frontend0.png?revision=8058view=markup
I have no idea what that logo is, and I don't mean to offend you, but
it looks pretty bad compared to what we are using now.
Still needs to be fixed.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone-dev] Changing the version of 2.3 to 3.0?
On 9/13/09, Christian Ohm chr.xx...@ wrote: On Sunday, 13 September 2009 at 13:28, Per Inge Mathisen wrote: IMHO, 3.0 should be the first release with new savegame and scripting formats, because this will be a tough break with the past. Whether the first release from trunk will have these two things is still an open question, I think. Personally I think it doesn't make much sense to target a specific version number when you don't know how much steps are necessary to reach that version. And I guess once trunk gets into a releasable state, it warrants the 3.0 version (but the KDE team used similar reasoning and got bitten...) Anyway, regardless of the specifics for trunk, can we agree that 2.3 will _not_ be a trunk release, but the continuation of 2.2? Looking at the roadmap, and everything else (trac...) it looks like branch/2.2 will be re-branched to 2.3. I still think that just the improved gfx alone in trunk is probably the most major change that we have, that will have the biggest effect on our userbase. Current trunk could be 3.x, the next gen stuff 4.x. New savegame format for 3.1, lua 3.2, ... and so on. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend
On 10/5/09, Zarel zarelxxx...@xxcom wrote: On Sun, Oct 4, 2009 at 9:57 PM, bugs buggy buginx...@.com wrote: see below about 2.2.4 / 2.3.0 In case everyone is confused on how this works, if host starts a game with ntw mod, they would do --mod_mp ntw (if from source) or --mod_mp ntw.wz then that loads the ntw mod. Now when they host, all players *must* also have --mod_mp ntw or --mod_mp ntw.wz (depending if they are running from source or not) and then, once in game, it checks the data, and kicks everyone who doesn't have matching data. Can we just implement the part of my mod loading patch that lets you leave off the .wz? So we don't need to guess when we need the .wz and when we don't? What will that solve? It will save people 3 characters... not exactly worth it IMO. It isn't confusing, since 99% of our userbase uses .wz, the ones that run from source, pretty much know that they don't need '.wz' ending. Re-read my ticket, I said this is only the *start* of fixing the mods, there remains a heck of allot of work to be done, and I can pretty much guarantee that we will break netcode compatibility again when it is all done. If host just starts a normal game with no mods, and a player is using a mod, the data check will see this, and kick the player(s). Can't we send them like maps? And enable/disable them like maps? Nope! A) the maps code sucks, and has many issues by itself. B) the checks that I have reimplemented are done *in game*, not the lobby. C) it can't be done in the lobby yet, that is for the future, we still have to come up with a way to read in the mod, know where it came from, and then make a hash out of that, then transmit this info to everyone, which is why the lobby code has all those extra fields that we can use--I am not sure the best way to handle this. Having a poor GUI doesn't help either. Especially if we're going to be breaking netcode compatibility. We should probably work out a scheme for sending them like maps before we release a new version. I'm fine with releasing 2.3 beta 1 next week, but definitely not a final. Didn't we have a argument like this for 2.2.0? Anyway, as I said, we are going to break netcode compatibility again, there are no ways around it. I was thinking the map + mod stuff will end up using the same routines and they will handle any type of file. (the current DPID BS blows in 2.x!!) I still think a 2.x.x* release should be done this weekend. I see no real reason to label it 'beta', and no reason not to do a final release. ... 2.3.0 will be re-branched from branch/2.2 ? I did have reasons for wanting to stick with 2.2.4, namely, that the netcode will be broken again, and so the next version after 2.3.0 will be 2.4.0 and if something changes, we can go up to 2.9.x? I rather stick with 2.2.4 and so on, until we finally get the netcode under control, and THEN we can do a 2.3.0 or by that time, 3.0 (current trunk) will be in good shape, and I can say DIE 2.x DIE! Heck, I very close to saying screw 2.x, and put all my efforts into 3.0-- I see little reason it maintaining 2.x longer than we absolutely have to. Unless we get a sudden influx of devs to help I do not see a good solution, as they say, talk is cheap. The netcode in trunk is very different than 2.x, and just not easy to maintain both versions. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Version scheme (again)
On 10/4/09, Per Inge Mathisen per.xx...@gmail.com wrote: After a quick discussion on IRC, I would like to propose a different versioning. I'd like to see a trunk alpha soon. However, since trunk does not yet contain the big incompatibilities that we foresaw for 3.0 (new savegame format, lua port), we should wait with the major version bump. So we should call the next big release 2.4. Then we reserve the 2.3 number space for a possible 2.2+incompatible net changes version in the future. Once we've done some MP test games among the developers, I would like to branch off and start making the first release from trunk as 2.4-alpha1. Opinions? Works for me (tm) Oh how I look forward to uploading 100+MB with my slow bandwidth :P ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend
Hey all, the current plan is to release 2.2.4 (or 2.3.0--which ever version # wins) next weekend, most likely Saturday night/ Sunday morning. If you have fixes/changes, then please get them in now, or wait for the next release. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend
On 10/4/09, Zarel zarexx...@gmail.com wrote: On Sun, Oct 4, 2009 at 5:44 PM, bugs buggy buginato...@gmail.com wrote: Hey all, the current plan is to release 2.2.4 (or 2.3.0--which ever version # wins) next weekend, most likely Saturday night/ Sunday morning. If you have fixes/changes, then please get them in now, or wait for the next release. D: D: D: BLOCK We are not rushing out a netcode-imcompatible release that soon, no no no! Why? Look at the code, it isn't that complex in what it does, and now that it is in both trunk branch/2.2, we can have plenty of testing before the release of the next version next week... Hear that testers? We need your help :) In case everyone is confused on how this works, if host starts a game with ntw mod, they would do --mod_mp ntw (if from source) or --mod_mp ntw.wz then that loads the ntw mod. Now when they host, all players *must* also have --mod_mp ntw or --mod_mp ntw.wz (depending if they are running from source or not) and then, once in game, it checks the data, and kicks everyone who doesn't have matching data. If host just starts a normal game with no mods, and a player is using a mod, the data check will see this, and kick the player(s). Like I said, this isn't really that complicated, and it was in Pumpkin's original codebase + a few changes so it runs on all platforms. Anyway, I will be back next week. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend
On 10/4/09, bugs buggy buginxxx...@gmail.com wrote: ... now that it is in both trunk branch/2.2, we can have plenty of testing before the release of the next version next week... Hear that testers? We need your help :) I uploaded both 2.2 trunk versions (.exe ONLY) as of this e-mail to the forums here: http://forums.wz2100.net/viewtopic.php?f=6t=3895start=0 Feel free to tell people to test it. Anyway, I will be back next week. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] OpenGL requirements for trunk
On 9/26/09, Per Inge Mathisen perxx...@gmail.com wrote: I have been working with OpenGL 2.0+ features lately, and I think I could have a good shot at making the current model drawing code much faster by using such features. However, this would require working support for VBOs and GLSL shaders. It probably means bye-bye Intel integrated graphics hardware (at least until they manage to get the drivers up to speed on the more modern of their hardware). The trunk branch was supposed to be for modern graphics hardware, and the way graphics development is going, the OpenGL 1.x way of doing things is more and more a thing of the past. On the other hand, Intel integrated chipsets have bigger market share than either ATI or Nvidia (at 40%, 27% and 20% respectively in one article I read). So perhaps we should do a 2.3 branch of the current trunk before any such changes, and hope that Intel users can use that? From what I have heard, at least some Intel users have been running trunk successfully. Of course, once we start using shaders and VBOs, a lot of new interesting possibilities open up in the graphics department. So it is not just to increase the speed of model drawing we would be adding this requirement. Because of the intrusive changes needed, maintaining two drawing paths would not be feasible. Let me know what you think. Are you insane? How can I play this game on my 5+ year old machine then!?!?!? ;) All kidding aside, I am fine with almost all of this. GSSL will be nice, but I worry about the support, and if we need to have fallback routines or not. We just don't have the manpower to have fallback routines. The part I do not agree is about the version. I much rather we have the current trunk as 3.0. Then the new trunk (with shaders / GLSL+ whatever else) should be 3.5 or maybe even 4.0. This leaves us with 2.2 branch to move up to 2.9 for room to grow, instead of doing 2.2.11 :) In case we want to backport stuff from trunk to the 2.x line. I have more comments on 2.2+ shortly. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Version scheme (again)
First off, I really think we need room to grow for the 2.2 branch. If we start to backport some changes from trunk to the current 2.2 it can/will break things, and saying 2.2.5 won't work with 2.2.4 because of XYZ isn't really a good way to handle it. Minor improvements and or bug fixes are for minor bumps in the version, but something more major really needs a major bump in the revision numbers. For example, the net code. As we all know, it is pretty different in trunk and branch, and it is much harder for us to maintain two versions of netcode. If we backport that from trunk to 2.2, it should be 2.3.0 not 2.2.5 (or whatever). Some of the other stuff would be the new savegame format and whatever else. Last topic of this nature was pretty much everyone said it was OK to make the current trunk 3.0. Can we all, finally agree how to handle this? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.2.3a for Macs?
Nice of someone to notice that we were stripping the mac exe, so the crash dumps are more or less useless. I think the mac builds need to be redone ASAP, so we can have half-way decent crash dumps from the mac people. I do NOT think we should tag a 2.2.3a, just commit the xcode changes to 2.2.3, and do another mac release from that, and make it known on the frontpage /download page that it is updated. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.2.3 NSIS issue
Looks like doing mutually exclusive stuff is not in the picture right
now, so the question becomes, should we use the Hi-res version or the
low-res version of the FMVs as a download option?
I have:
LangString DESC_SecFMVs ${LANG_ENGLISH} Download and install Hi-res
videos (in-game cutscenes). 545 MB! A Low-res version is available
at http://wz2100.net/download;
If we go with the above, then I also need the correct string of what
that says for:
LangString DESC_SecFMVs ${LANG_DUTCH} FMV downloaden en
installeren. 545 MB!
and
LangString DESC_SecFMVs ${LANG_GERMAN} FMV herunterladen und
installieren. 545MB!
Or we could default to lo-res, makes no real difference to me.
The main issue is, I don't know NSIS well enough to handle mutually
exclusive radio buttons (or sections), and since time is short, I will
mess with this the next time I play with NSIS scripting.
And of course, the FMV link need to be switched (or not) from the
previous message I sent, I need that bit of info as well.
Right now, it is doing:
NSISdl::download
http://download.gna.org/warzone/videos/warzone2100-sequences-latest.wz;
sequences.wz
Which means, it is getting the low-res version.
Other than this, we are ready to tag 2.2.3
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.2.3 is now released
http://forums.wz2100.net/viewtopic.php?f=1t=3757p=36733#p36733 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! 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: Use all three baba scream sounds again (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 (ticket:817, ticket:823, r8116, r8133, r8138, r8139) * 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) * Graphics: * Change: New skybox for urban maps, this one is licensed CC0, not CC-by 2.0 (ticket:922) * Video: * Fix: Do not lower volume to zero when multiple videos queued up (ticket:670, r8106) * Translations: * Fix: Make some more strings translateable (r8121, r8129, ticket:906, ticket:907) * Fix: Updated German translation (r8092, r8131) * 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) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] The download page
On 8/24/09, Cheny Luo chenxx...@xx.com wrote: Hey, Warzone people! This is targeted mostly at Buginator, because he's been handling the download page for new releases. You seem to be getting rid of old the download links right before a new release, even before a new download is available. This is a very bad idea, because during the interim, people on those platforms cannot easily download Warzone. I've again added the downloads back: http://wz2100.net/download In the future, could you do this yourself? Nope. I don't see the point of it. We want people to get *NEW* releases, not download old crap that we don't really care about. If they want old versions, then that is why we have the mirror links. We should only have the latest version of the game listed. The place holders are there for a reason, and people should check back for when the newest version of the game is available for that platform. I don't got a mac, so I can't make those. I don't have Fedora, so can't do that either. I can only do windows + the tarball, and when the other members get time, they upload the version, and update the page. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] New developer
On 8/31/09, Per Inge Mathisen per...@x.com wrote: Hello, This is to say welcome to the newest developer with svn commit access - i-NoD. He has been writing some quality patches lately and we figured we could use some extra manpower :-) - Per Welcome to the team i-NoD. What platform do you mainly use to code with, and what kind of a machine you have? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.2.3 release?
Looks like we have quite a few bugs that squeaked by, and infected 2.2.2, pretty much breaking the SP game from reading the forum comments. Since I assume those are all fixed now, and the new bug fixes, how about a quick 2.2.3 release late Saturday or early this Sunday? Only issue is, I could only make the windows build this time, since my linux box is suffering from ichabod craneitus. Or, should I do a quick 2.2.3 beta release for windows only, and throw that up ? After Sunday, I am not sure of my next ETA to do another release... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Changing the version of 2.3 to 3.0?
For trunk, we have allot of changes, and most of those are not really trivial. I think when we tag trunk for a Alpha release, it should be 3.0, and not 2.3. To me, 2.3 would be minor changes, and that don't bode well with what has been done to trunk. Any objections from changing the 2.3 milestone to be 3.0 instead? 2.2.x will be the last series that supports low end machines. 3.x will be the future, and work on mid range to higher end machines. At least, that is how I see it. :) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Changing the version of 2.3 to 3.0?
On 8/23/09, Zarel zarelxxx...@xx wrote: On Sun, Aug 23, 2009 at 1:26 AM, bugs buggybuginatorx...@x wrote: For trunk, we have allot of changes, and most of those are not really trivial. What sort of changes? The only things I can think of are the terrain renderer, a new power system, and a refactor of some netcode. Regardless, I would indeed like a 3.0, mainly so we can backport other important changes to a 2.3 release, for people without good renderers. Both lua the new widget engine are also slated for that release, as well as some other things. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Changelog changes?
It is apparent that the current way we do Changelogs isn't the best way, since it is way more time consuming than it should be. We could just drop the revision number, and stick with tickets, or we could use svn2cl to produce the changelog for us. http://arthurdejong.org/svn2cl/ Your input is welcomed. :) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] SF svn repo upgrade to 1.6.4?
On 8/22/09, Stephen Swaney sswa...@centurytel.net wrote: On Fri, Aug 21, 2009 at 07:06:59PM -0400, bugs buggy wrote: *After* the 2.2.2 release, I was thinking we should upgrade our SVN repo( svnadmin upgrade) to svn version 1.6.4. Any objections to this? It makes quite a few things easier on us (merges), see the release notes here: Looks worthwhile. Let's do it! This is put on HOLD, since I don't full access to my linux machine, I can't make a recommended backup of our repository. rsync -av PROJECTNAME.svn.sourceforge.net::svn/PROJECTNAME/* . Then after the backup, we just need to do a svnadmin upgrade Simple ;) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] 2.2.2 is now released!
The developer staff brings you the release of Warzone 2100 2.2.2. The most noticeable fix in this release is that people should have significantly fewer crashes, as well as less problems with sounds and numerous other fixes in this release as well. For a complete list see the Changelog. NOTE to builders, we need Fedora Mac builds please. :) ChangeLog: 2009-08-23: Version 2.2.2 * General: * Change: Add the ability of allied players to share sensors (ticket:636, r7900) * Change: Stop rotation when Continue is pressed after winning a multiplayer/skirmish game (r7887) * Change: Show when a game was saved in a tooltip on the loading screen. (r7864, ticket:682) * Fix: Cannot display more than one game from lobby. Also fix a lobby display issue. (r7839, ticket:691) * Fix: Various checks and workarounds to make game run more stable (r7836, r7894, r7889, r7883, r7881, r7851, r7847, r7842, r7822, r7910 / ticket:759) * Fix: Crash due to path length overflow (r7916, ticket:738, ticket:765) * Fix: Bug that caused some keyboard shortcuts to be unusable in multiplayer since they were considered cheats (r7856) * Fix: Verify that our target is still around before doing fire support with it. (r7910, ticket:759) * Fix: Fix crash length overflow by capping path lengths to max 255 nodes. (r7916, ticket:738) * Fix: Fix a typo, we wanted to display ??? when ping is =2000 (r7922) * Fix: Fix camera bug in warcam code. Patch by i-NoD (r7924, ticket:757) * Fix: General order/action code cleanup (r7926) * Fix: Fix segfault when trying to read target of droid with no target in aiUpdateStructure (r7928) * Fix: Use _NSIG in the exceptionhandler if available for *BSD compatibility. (r7972, ticket:818) * Fix: Add correct linker flags for openbsd to configure. (r7974, ticket:819) * Fix: Disable locales without translation. (r7969, ticket:813) * Fix: NTW updated to 1.8.7 (r7998 - r8009) * Fix: When babas are burning, we always play the scream now. (r8025, ticket:830) * Fix: Make sure we have a valid color choice for our SP game, when we are coming from a MP game. (r8032) * Translations: * Fix: Commit Portuguese translation. (r7943, ticket:783) * Fix: Updated translations (r7880, r7877, r7875, r7871, r7868, r7863, r7861) * Graphics: * Fix: Increase video buffer size from 4K to 256K. This fixes playback of videos with a bitrate larger than ~2000kbps. (r7981) * Change: Add a north pointer for the rotating radar. (r8013, ticket:769) * Sound: * Fix: Fixes the removal of unused (sound) sources. (r8012, r8026, ticket:770) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Last call for 2.2.2 commits!
Unless someone throws a fit, I plan to make a 2.2.2 release this weekend. Most likely on Sunday. I will do the windows linux tarball, so we just need the Mac release as well. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Making trac friendlier?
It has come up that some of the resolutions we currently use for trac can seem to be a bit harsh in tone. Mainly, the issue is, if a user has some kind of feature request, then what should be done with it? If we close it as invalid, that could be conscrewed as us telling them to bugger off... If we don't close it, then it clogs up the pipeline so to speak. The same with other tickets that are more or less useless. We tried to fix some problems with the need info resolution, and that is what I mostly use, but, trac still says Closed, which can confuse some people. Any ideas on how we can create a more friendlier trac? There are some suggestions that we should add more resolutions, and add more types. We now have task, defect, and enhancement. Should we have a feature request (which would be something that has no patches included), and would be closed with a resolution of One of these days... or whatever we come up with? Or do we just do what we have been doing? Any thoughts on this? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] SF svn repo upgrade to 1.6.4?
*After* the 2.2.2 release, I was thinking we should upgrade our SVN repo( svnadmin upgrade) to svn version 1.6.4. Any objections to this? It makes quite a few things easier on us (merges), see the release notes here: http://sourceforge.net/apps/wordpress/sourceforge/2009/08/07/subversion-upgraded-to-1-6-4/ And info about 1.6.4 here: http://subversion.tigris.org/svn_1.6_releasenotes.html ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Making trac friendlier?
On 8/21/09, Stephen Swaney sswa...@xxx wrote: One way is simply to have a separate tracker for feature requests. However, as cybersphinx points out in IRC, having everything in one database has certain advantages. If we had a separate 'feature request' type, it would solve that problem. Then again, the default search options available don't seem to support anything but the bare minimum. Closing bugs that are in the 'need more info' state is misleading. Need info is *not* a resolution but a pending state or status. Yeah, I agree... Can we create a Status of 'need more info' to go along with our accepted, assigned, closed, new and reopened values? I don't think we can do that, without modifying the source code. I think Giel would know what can / can't be done the best, he seems to know more about trac than the other devs. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Making trac friendlier?
On 8/22/09, bugs buggy buginatorxx...@xxx.com wrote: I don't think we can do that, without modifying the source code. I think Giel would know what can / can't be done the best, he seems to know more about trac than the other devs. I just found this, this looks like it would be a nice enhancement for us. http://trac-hacks.org/wiki/PendingTicketPlugin Basically, after X days, it will autoclose the ticket. Just what we were looking for. :) There are quite a few others that look like we could use as well: http://trac-hacks.org/wiki ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Update the SF site or not?
In case anyone has some free time, we could make our SF site look *much* better... They also have added quite a few things, and they support trac as well. (Perhaps we can use this as a backup?) Lots of them are improving their sites over the bland version that is our default. Here are some samples: http://tuxracer.sourceforge.net/ http://audacity.sourceforge.net/ We also got the option for MediaWiki. Opinions? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Update to QuesoGLC .7.2 before 2.2.2 release?
Just a quick word, I noticed that QuesoGLC has been updated to .7.2, and in the release notes, they have: http://sourceforge.net/project/shownotes.php?release_id=672506 - Fixed bug #2019450 (added a workaround for open source drivers of the Intel chipsets : a bug in the drivers prevent a character to be displayed). Seems like we have quite a few intel people with that issue, so we may want to bump the requirements for the linux folks. I don't think that happens with intel people on windows or macs. See ya in a few weeks. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Project Status?
Just curious as to where we are at? I know that most of the devs are away/busy, so things have slowed down tremendously. For a alpha 2.3 release, the major blockers/issues with that are power code, skybox, and what else? Zarel is pushing for a 2.2.2 relatively soon, what is the status of this? I have been out of the loop, so I am not sure what still needs to be done, what is being worked on, or if it is even possible to do a 2.2.2 release with so few people available to make builds. About the only thing I know is, that the mod code won't be done in time for a 2.2.2 release anytime soon. I have noticed allot of bug reports, but sadly, most of them are still useless. The additional code for the crash dump helps, but we have to come up with a way to have the same info for the mac crash dumps. Ideas? Gerard, if you are still reading the ML, people have been griping about the lack of a git sync, so we need to come up with a solution to this as well. Perhaps we move the git repo to sf, then have whatever script run on that ? Anything else anybody want to share? It is getting lonely on the ML. :S ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Just a few comments about a few commits
On 7/26/09, Dennis Schridde devurxx...@gmx.net wrote: Am Sonntag, 26. Juli 2009 05:11:55 schrieb bugs buggy: Revision: 7891 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7891view=rev Author: zarelsl Date: 2009-07-22 22:12:41 + (Wed, 22 Jul 2009) Index terrain textures (~68 MB - ~22 MB); idea suggested by i-NoD. ... I thought any big data changes should be brought to the attention of the ML for comments. True, in this case, since most everyone is away, it wouldn't have made a difference, Who is away? Speaking at least for me: I am still watching, even if you do not see much of me. The better question is, who isn't away? AFAIK, only Per Zarel Cybersphinx (Christian) are fairly active looking at the commit list this past month. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Just a few comments about a few commits
Revision: 7842
http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7842view=rev
Author: zarelsl
Date: 2009-07-13 21:10:49 + (Mon, 13 Jul 2009)
2.2: Fix possible buffer overflow in missionFlyTransportersIn and
getLandingX/Y.
How does this fix anything?
These should be asserts (so we can find the real cause), and this code
fragment in getLandingX() and getLandingY() is just wrong:
if ((unsigned int) iPlayer 8)
{
iPlayer = 8;
}
You can't make that assumption, and you are possibly introducing more
bugs with that.
Revision: 7887
http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7887view=rev
Author: zarelsl
Date: 2009-07-19 22:26:54 + (Sun, 19 Jul 2009)
2.2: Stop rotation when Continue is pressed after winning a
multiplayer/skirmish game.
IIRC, the whole reason behind this, was so you can't 'continue' the
game as normal, ie, it is mainly to fire the fireworks, to show you,
you won, or lost. This could introduce more bugs, since your screwing
with the original design, and you haven't modified any of the scripts
for the win/loss stuff.
Which means, that in the least, I would add a info(Game has ended),
or perhaps a addDumpInfo(Game has ended), so we can weed out crash
reports when people continue after a win/loss.
Revision: 7891
http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7891view=rev
Author: zarelsl
Date: 2009-07-22 22:12:41 + (Wed, 22 Jul 2009)
Index terrain textures (~68 MB - ~22 MB); idea suggested by i-NoD.
... I thought any big data changes should be brought to the attention
of the ML for comments. True, in this case, since most everyone is
away, it wouldn't have made a difference, but it would have been nice.
I also don't think this was required per se, perhaps when we would
have branched 2.3...
This is just the commits that caught my attention so far...
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] 2.2.1 has been released
The windows installer, and the source tarball (.bz2) have been created. Fedora Mac builds are still needed. Thanks again to everyone who made this release possible. Here is the changelog. 2009-06-21: Version 2.2.1 * General: * Change: No longer require space between rearm pads, allow dragging pad production with mouse, and droids may drive over inactive rearm pads (r7701, ticket:569) * Fix: Various crashes related to failing orders (r7699) * Fix: Show translations for finished research display (r7730) * Change: Add more information to the crash dump file (r7740, 7745) * Fix: Mac users can read in .wz files (r7754) * Fix: Experience speed adjustment happens after max speed limit; fix bug with speed calculation. (r7761) * Fix: Numerous issues with NTW mod (r7676-7677, r7713-7716) * Fix: fix to *never* control the transport in SP games. (really this time!) (r7776, ticket:568) * Change: Allow droids to grab artifacts and oil drums from up to 1 tile away (r7779) * Change: Bump up MAX_RESEARCH to 500 from 450. (r7774, ticket:599) * Fix: Make sure we take xOffset into account, we don't always start at 0 for the FMV text. (r7780, ticket:625) * Change: When host drops from the lobby, abort the game. (r7787 ticket:583) * Fix: Make sure either parameter isn't below the minimum screen res. that we support. (r7786) * Fix: Make sure we take xOffset into account, we don't always start at 0 for the FMV text. (r7780, ticket:625) * Fix: Clear the keyboard/mouse input on lost focus correctly. (r7797, ticket:515) * AI: * Fix: Resolve AI droid traffic jams by clearing orders and make jammed droids stop going for repair (r7700, ticket:597) * Campaign: * Fix: Flashing box around mission timer was too small, resulting in a graphics glitch. (r7672, ticket:596) * Translations: * Fix: Italian and Slovakian translations updated (r7769, ticket:621, r7772, ticket:615) * Build system: * Fix: Various build system issues (r7669, r7664, r7663, r7661, r7655, r7642, r7640) * Graphics: * Fix: No more ugly texture seams (r7718, r7724, r7757) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Reencoding the videos
On 6/18/09, Christian Ohm chrxx...@gmx.net wrote: Hello, I've recently encoded the German RPLs into the Theora format for use with Warzone. Before that I believed those who claimed the loss in quality wasn't significant, but actually comparing original and encoded file this is definitely _not_ the case. The videos we currently offer are _ugly_ (and that's compared to the originals' ugly). I agree... http://www.filefactory.com/file/ag6g6hb/n/eidos-logo_7z contains three sample files, the original uncompressed AVI, the current WRP encode and my new encode. As I said, the videos we currently offer are quite crappy, maybe we can offer reencoded ones for 2.2.1 (with fixed seams _and_ good-looking videos!). I could do the encoding, though uploading takes several hours. I'm not sure about the Windows installer, offer two video options small and crappy and large and good? The ones you did do look better, but, if you do re-encode them all, would we be allowed to stick the German ones on GNA as well, or is that still a gray area? For the windows installer, I was thinking if we could use a softlink for the files, and then we can always point them to the newest version, on gna, to download (if that is possible?) Adding another entry is trivial. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7757] branches/2.2/src
On 6/17/09, Christian Ohm chrxxx...@gmx.net wrote: On Wednesday, 17 June 2009 at 5:00, buginaxxx...@users.sourceforge.net wrote: Don't try to pretend that we have textures 128 in this branch. But, ehm, we do have textures larger than 128x128. Like _every_ _single_ _PIE_ _texture_ _page_. The default texture size is 256 (and old configs can contain larger values). This is large enough for the (original) PIE textures, and so it looks good (as good as the textures look, anyway). But once a user changes the texture size, they cannot restore the default, and get scaled down ugly looking unit/building textures. What exactly was this supposed to solve? Whoops! I was stuck in terrain tile mode. I forgot all about the other textures. :o Will fix. As for what it solves, is there any reason to offer a range above what we currently have the textures ? I just think it will be confusing to the end users, if we offer a size of 2048, yet no texture in 2.2 will ever have that size (at least, for the foreseeable future). If you are thinking for testing, I didn't limit the texturesize specified in the config file, I just made it so we cap the max texture option in the menu option. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Project rename, website changes
On 6/16/09, Zarel zarelxx...@gmail.com wrote: - The site logo - The Development tab should be removed, and the Trac tab should be renamed Development. - It might help to add a Download tab between FAQ and User Guide. - The Blog _really_ isn't updated enough for its entire own tab. works for me-- but you have to convince Kamaze, since, I think he is the only one that can make the changes. - I believe the Warzone Guide is complete enough that it can directly replace the User Guide tab (so that the tab button takes users directly there). If there's a thematic issue, I can re-layout the Guide to match the current Warzone site. I can also add whatever information currently on the User Guide page to the Guide, if requested. I don't really mind one way or the other, if you redo it, it would fit in with the theme, but if the theme changes again, then what? Let's rename our project from Warzone 2100 Resurrection Project to Warzone 2100 Project (and the abbreviation from WRP to WZP). Reasons include: I don't need reasons, I never liked 'WRP', and have expressed my feelings on this subject many times over my tenure of being associated with this project. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] 2.2.1 to be released on the 21st?
I feel that a 2.2.1 release on June 21st is a good target date. Besides the usual bug fixes, the biggest fix (most noticeable) is the seam fix, and the biggest thing that will help *us* is the improved crash dump file (on windows linux), which will now give us much more info than we ever had before, and hopefully help us fix things faster. Debian has not uploaded 2.2.0 yet either, so 2.2.1 should propagate rather easily. Oh, 2.2.1 will (should) also have working Mac .wz support (untested), see http://developer.wz2100.net/changeset/7754 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] What additional information do we need to add to the crash handler dump file ?
On 6/15/09, Christian Ohm chr.x...@gmx.net wrote: On Monday, 15 June 2009 at 0:40, bugs buggy wrote: In order to alleviate this as much as possible, I have modified the crash handler dump file to spit out the openAL openGL vendor/version strings. Though I'd put the OpenXX strings right after the first info block, without any separators (and minus a few newlines after the machine line). Everything above the PhysicsFS version info, is done before we hit almost all init routines. All these things can't be added to the crash dump file with the addDumpInfo(), since that will remember the last settings as well, (as in, they play X map, we store X map, they play Y map, we have X map and Y map in stream...) will have to have another section, and clear the stream first, then add everything again, unless someone can think of another way? Just keep everything? Sometimes a crash happens because of remaining crap from an old map. Gives at least some of the history, and not only the momentary snapshot we get now. Ok, that is how we will handle it. Oh, and sadly, this information will not be in the mac crash dump file...for the reasons stated before. :( What exactly are those reasons? On the mac, we don't use the same handler, and I am not in a position to experiment to fix this. This is what ours looks like now: Program: ./src/warzone2100(warzone2100) Command line: ./src/warzone2100 --window Version: Version TRUNK r7742 (modified locally) - Built Jun 15 2009 - DEBUG Distributor: UNKNOWN Compiled on: Jun 15 2009 22:42:34 Compiled by: GCC 4.3.2 Executed on: Mon Jun 15 23:00:56 2009 Operating system: Linux Node name: XyZ Release: 2.6.26-2-486 Version: #1 Thu Mar 26 00:13:41 UTC 2009 Machine: i686 Pointers: 32bit Compiled against PhysicsFS version: 1.1.1 Running with PhysicsFS version: 1.1.1 Misc Data: [11:00:57]OpenGL Vendor : ATI Technologies Inc. [11:00:57]OpenGL Renderer : ATI RADEON 9600 Series [11:00:57]OpenGL Version : 2.1.8543 Release [11:00:57]OpenAL Vendor: OpenAL Community [11:00:57]OpenAL Version: 1.1 [11:00:57]OpenAL Renderer: OpenAL Soft [11:00:57]Using language: English [11:01:06]Current Level/map is CAM_1A [11:01:22]User has used cheat code let me win [11:01:30]Current Level/map is CAM_1B [11:01:36]User has used cheat code let me win [11:01:41]Current Level/map is SUB_1_1S [11:01:45]User has used cheat code double up [11:01:53]User has used cheat code biffer baker [11:02:02]User has used cheat code let me win [11:02:42]Current Level/map is Sk-Basingstoke-T2 [11:05:10]Current Level/map is CAM_1A [11:05:31]User has used cheat code let me win [11:05:38]Current Level/map is CAM_1B [11:07:08]User has used cheat code showorders [11:09:05]User has used cheat code give all [11:10:09]User has used cheat code let me win [11:10:14]Current Level/map is SUB_1_1S [11:10:20]User has used cheat code let me win [11:10:26]User has used cheat code let me win [11:10:37]User has used cheat code let me win [11:10:55]Current Level/map is SUB_1_1 [11:11:14]User has used cheat code let me win [11:11:19]Current Level/map is SUB_1_2S [11:11:28]Current Level/map is SUB_1_2 [11:11:35]User has used cheat code let me win [11:11:40]Current Level/map is SUB_1_3S [11:11:53]Current Level/map is SUB_1_3 Dump caused by signal: SIGSEGV: Invalid memory reference: Address not mapped to object ... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] What additional information do we need to add to the crash handler dump file ?
For those of us that read the tickets, they suffer for a severe case of 'need info'. In order to alleviate this as much as possible, I have modified the crash handler dump file to spit out the openAL openGL vendor/version strings. I also plan to add map name, if cheats were used, and texture size (what the user has it set to), and I am wanting to add what language wz is set to, by using getLanguage() --which I think should work. All these things can't be added to the crash dump file with the addDumpInfo(), since that will remember the last settings as well, (as in, they play X map, we store X map, they play Y map, we have X map and Y map in stream...) will have to have another section, and clear the stream first, then add everything again, unless someone can think of another way? Is there anything else that we need to be in the report? WZ has plenty of globals... ;) Oh, and sadly, this information will not be in the mac crash dump file...for the reasons stated before. :( ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2.1 release date / 2.3 beta release date?
On 6/12/09, Christian Ohm chr.xxx...@gmx.net wrote: On Thursday, 11 June 2009 at 23:56, bugs buggy wrote: Ok, found the problem. It isn't a driver issue, it is more of a oversight. It turns out, that if you set the texture size to something higher than the texture size of the tiles (which is a max of 128x128), then you get seams. Makes sense, when you think about what is going on. Well, of course that'll fix the seams as well. But it defeats the whole purpose of having texture pages at all, which was to prevent the performance impact of frequent OpenGL state changes due to every tile having its own texture. Though prhaps this isn't an issue anymore, some short testing showed no significant difference, and the new version even seemed a bit faster. Hmm? I don't think we are on the same page here. We load each texture tile onto a texture page. We have 4 (or more) texture pages. (1(or more) page for each of the tile resolutions we have, 16, 32, 64, and 128) The texture size can be currently set to 32 - 2048. If user has it set to 2048, then the texture coordinates are set for 2048, and not the actual tile of 128 (or 64...). We do not upscale the 128x128 textures to 2048x2048, and if we did, it would look hideous. And with that, I guess you can revert your half-pixel border hack. For now, I am forcing the texsize to 128.0 from getTextureSize(). (see r7723 r7724) Note, we will fix this another way, this is only a temp fix, since I am wondering why do we offer anything higher than 128 in the first place (for 2.2)? As I said, less texture changes is supposed to be faster. Though at least my driver/hardware doesn't heed that, it seems it likes lots of smaller textures a bit better than few large ones. I am not modifying the loading routines at all, so it still is a texture page. I just modify the coordinates for the texture tile that we are currently blitting. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2.1 release date / 2.3 beta release date?
On 6/11/09, Christian Ohm chr@gmx.net wrote: On Thursday, 11 June 2009 at 0:27, bugs buggy wrote: In case you haven't noticed, in r7717 (trunk) r7718(2.2), I fixed the blasted seam issue. While I am still unclear why it wasn't fixed like this before, Because it doesn't work (and I think we already tried it). See http://xs140.xs.to/xs140/09244/fixed-2.2983.jpg and http://xs140.xs.to/xs140/09244/fixed-trunk373.jpg. You need more than half a pixel border to prevent the seams. It's enough to make them a lot less noticable in trunk, but very much insufficient for the snow in 2.2. Something isn't right here then... no matter what angle, and no matter what zoom level, I do not have any seams anymore. http://imagebin.ca/view/DIlhZS_q.html Without the seam fix, I get : http://imagebin.ca/view/AlyUET.html With the seam fix, I get : http://imagebin.ca/view/PpYuPg.html http://imagebin.ca/view/YqN5gdTO.html http://imagebin.ca/view/36kws52.html http://imagebin.ca/view/mGPtyq.html http://imagebin.ca/view/MB90xU.html http://imagebin.ca/view/JRLgZK9P.html ... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2.1 release date / 2.3 beta release date?
On 6/11/09, Per Inge Mathisen per.maxxx...@gmail.com wrote: On Thu, Jun 11, 2009 at 6:27 AM, bugs buggybuginxxx...@gmail.com wrote: In case you haven't noticed, in r7717 (trunk) r7718(2.2), I fixed the blasted seam issue. While I am still unclear why it wasn't fixed like this before Can you try to explain in words what stroke of genius it is that you implemented? All I did was move the texture coordinates like so. Take, texture size -1 / texture size then add the texture coordinates of the center of the tile. If tile texture size is 64, then it is 63/64 (= 0.984375). We then take the tile we need, * by 0.984375, and then add in .5/64 (=0.0078125) to produce the correct texture offset. We have tried a lot of approaches in the past, and whenever someone said I've fixed it! someone else found a problem with it or the seams were just harder to spot on some maps. I tested this on 2 platforms, and with all the camera angles I could do, both on a radeon 9600 a Nvidia 8800 ... what can I say, other than I don't got seams anymore. Not for trunk, not for 2.2. *shrug* What does everyone think of a simultaneous release of 2.2.1 and beta 2.3? There are several more bugs in trunk that need to be fixed before we can release even an alpha Some came in with the netplay branch merge, some are older. Several are definitely blockers. I would encourage everyone to start looking more closely at the bug tracker, and fix bugs for a while. Then we can branch and start some more systematic testing. I thought that is what everyone was doing anyway? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2.1 release date / 2.3 beta release date?
On 6/11/09, Christian Ohm chr.xxx...@gmx.net wrote: On Thursday, 11 June 2009 at 13:01, bugs buggy wrote: Something isn't right here then... no matter what angle, and no matter what zoom level, I do not have any seams anymore. Does your card/driver support anisotropic filtering? If it doesn't (or you have disabled it in the driver), your fix might work. But with anisotropic filtering (which Warzone enables if available), OpenGL takes more of the surrounding texels, so a half-pixel border won't be enough. It does, I forced it on to 16x, and didn't see seams, and then tried AA set to 16xQ, and no seams. On linux for the 9600 card...tried anisotropic filter to 2x 16x, no seams. AA set to 6x (max it goes) no seams. I am guessing it has to do with your mesa drivers? Has anyone else did any tests yet? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2.1 release date / 2.3 beta release date?
On 6/11/09, Christian Ohm chr.xx...@gmx.net wrote: On Thursday, 11 June 2009 at 13:40, bugs buggy wrote: Does your card/driver support anisotropic filtering? If it doesn't (or you have It does, I forced it on to 16x, and didn't see seams, and then tried AA set to 16xQ, and no seams. On linux for the 9600 card...tried anisotropic filter to 2x 16x, no seams. AA set to 6x (max it goes) no seams. Seems like something else going on. I tried with and without anisotropic filtering, and always got seams. I am guessing it has to do with your mesa drivers? Has anyone else did any tests yet? May be. More testing would be nice. Ok, found the problem. It isn't a driver issue, it is more of a oversight. It turns out, that if you set the texture size to something higher than the texture size of the tiles (which is a max of 128x128), then you get seams. Makes sense, when you think about what is going on. For now, I am forcing the texsize to 128.0 from getTextureSize(). (see r7723 r7724) Note, we will fix this another way, this is only a temp fix, since I am wondering why do we offer anything higher than 128 in the first place (for 2.2)? Once we can all agree that the seam issue is fixed now, I will proceed to the next step, which would be something like this: For 2.2: tileset should be capped to 128 max. (covers terrain + decals) and then we have the interface... I guess 128 max is more than enough for that? Backdrops max is 1024. For trunk, we have terrain max at 2048, decal max is 128, and interface max is 128(?), and backdrops max is 1024. Opinions on what the max texture size that we should allow for 2.2 trunk? I am thinking of offering a max / normal / low options in the main menu, instead of 32/64/../2048, that way, we can always use the best setting for each case? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2.1 release date / 2.3 beta release date?
On 6/11/09, Dennis Schridde devurxx...@gmx.net wrote: Am Donnerstag, 11. Juni 2009 10:15:01 schrieb Per Inge Mathisen: We have tried a lot of approaches in the past, and whenever someone said I've fixed it! someone else found a problem with it or the seams were just harder to spot on some maps. I've fixed it! - http://gitorious.org/warzone2100/mainline/merge_requests/642 Error 503 Service Unavailable Service Unavailable Guru Meditation: XID: 352779282 Varnish I would look, but it seems they are having issues... It is kinda hard to see what everyone is doing @ gitorious, trac / CIA don't currently monitor that repo... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7707] trunk/src/structure.c
On 6/10/09, Per Inge Mathisen per.mathxx...@gmail.com wrote: On Wed, Jun 10, 2009 at 7:50 PM, sendxx...@users.sourceforge.net wrote: Revision: 7707 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7707view=rev Author: sendai Date: 2009-06-10 17:50:14 + (Wed, 10 Jun 2009) Log Message: --- Do not bother to process visibility for off-world mission structures, since this leads us to iterate over tiles on the wrong map. This closes ticket:503. I want to add that this is the second bug introduced by r7097 today. Please be extremely careful when making logical changes to how objects are iterated. Due to the insane way that map data is swapped between missions, it is very easy to make very hard to trace bugs in this code. The main issue I see, is that we don't have enough testers--which is why I think we should release often, and, I don't think we test things on skirmish mp campaign. This is why we should have at least 3-4 savegames that we can use to do quick tests. For SP game, we need savegames that involve all the transition types (expand, limbo..etc) the games does. For skirmish MP games, I guess the best thing to do is use 'autogame', and while not perfect, I think it is the best we are going to have, short of having to play the game ourselves. (Though, this don't find the issues that involve more than 2-3 MP players...) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] More info for the exception handler
On 6/5/09, Christian Ohm chr@gmx.net wrote: As we often get too little information in bugreports, I added the OpenGl vendor, renderer and version strings to the crashdump output. That should at least tell us something about people's graphics hardware. The attached patch is for proof-of-concept mainly, I just put the stuff where it worked. Someone more familiar with the exception handler could perhaps point to a more adequate way of handling this. It'll also probably work only on Linux, as I can't test on other systems. Thinking about other things we might want to include, and how to handle the messages better than my ssprintf into a static, hopefully large enough buffer, led to the idea of a general message buffer for crashdumps: add a crashlog() function similar to debug() that adds text to the crashdump info, and e.g. put all LOG_ERROR messages automatically into it. Does that sound useful? It does, I would also add the openAL vendor/version reporting , like when we do PrintOpenALVersion(LOG_SOUND); It would also be nice if we could record the last X things the user did...but, that can get a bit complex. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Trunk's GLee hack, revert?
The problem with this hack is, that if we keep this in, then this hack is enabled for *all* people on linux, if they need it or not. AFAIK, we can't detect what drivers people are using, so the below error message is spit out for everyone on linux. If people don't report about the problem to the driver guys, then it don't get fixed. This is bad. I am thinking we should revert the hack altogether. Opinions? Index: lib/ivis_opengl/GLee.c === --- lib/ivis_opengl/GLee.c (revision 7656) +++ lib/ivis_opengl/GLee.c (working copy) @@ -12002,7 +12002,8 @@ // NOTE: this hack causes issues with MAC OS // HACK: work around for drivers that report VBO, but don't have full openGL 1.5 implementation. - #if defined(WZ_OS_UNIX) !defined(WZ_OS_MAC) + #if !defined (_WIN32) || !defined (__APPLE__) || !defined (__APPLE_CC__) + fprintf(stderr, GLee hack is enabled. Work around for video drivers that report VBO, but don't have full openGL 1.5 implementation--please report the issue to the driver maker.); GLeeFuncPtr_glBindBuffer = GLeeFuncPtr_glBindBufferARB; GLeeFuncPtr_glDeleteBuffers = GLeeFuncPtr_glDeleteBuffersARB; GLeeFuncPtr_glGenBuffers = GLeeFuncPtr_glGenBuffersARB; ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7655] branches/2.2/src
On 6/4/09, Dennis Schridde devuran...@gmx.net wrote: Am Donnerstag, 4. Juni 2009 19:33:00 schrieb bugina...@users.sourceforge.net: Revision: 7655 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7655view=rev Author: buginator Date: 2009-06-04 17:32:59 + (Thu, 04 Jun 2009) Log Message: --- Adding crash handler testing code. (to test crash dump reports) enable it by --crash on the command line. Why do you hide a crashing path to display3d.c? A simple *(char*)0=0; inside clparse.c would have worked, wouldn't it? Or if that is for some reason not possible, add a dedicated function (with significant name), which is called from an obvious location in main.c. (I.e. if you need to initialise the game, then make --crash initiate that and place the call after all init functions are passed and before the mainloop is being started.) Actually, that is by design, the 'bad ' crash report dumps are limited to one or two lines (if at all) of the call stack, instead of having a more deep call stack. If we would crash right away, then it hasn't hit the main game loop or anything of that nature. So, no, I am not hiding it. I just want it in a area, that is deep enough in the codebase, so we can have several layers of the call stack being shown. This whole thing came about since we currently having no way to easily verify which mingw setups work correctly, and which ones don't. This was the issue of a release we had in the past, where the crash dump was worthless. Some of the trunk nightly builds also have the worthless crash dumps. This is a attempt for the packager to verify they can produce builds that have proper crash dump support in them. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7660] trunk
On 6/4/09, Dennis Schridde devuran...@gmx.net wrote: Am Donnerstag, 4. Juni 2009 19:57:03 schrieb bugina...@users.sourceforge.net: Revision: 7660 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7660view=rev Author: buginator Date: 2009-06-04 17:56:56 + (Thu, 04 Jun 2009) Log Message: --- Slight cleanup of glOrtho parameters that should be double floats. glOrtho wants doubles for all parameters, not just for 2 and 3. This means that 1,4,5,6 should not be floats. Erm, I meant, before we only used double casts for 2 or 3 parameters, instead of using doubles for all parameters... void glOrtho( GLdoubleleft, GLdoubleright, GLdoublebottom, GLdoubletop, GLdoublenearVal, GLdoublefarVal); ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Proposed Roadmap
On 6/2/09, Per Inge Mathisen per.mathxxx...@gmail.com wrote: On Mon, Jun 1, 2009 at 9:40 PM, bugs buggy buginxx...@gmail.com wrote: Now with 2.2 out of the way, I was thinking that our new roadmap would look something like this: 2.3 new terrain (with netplay integration?) 2.4 lua integration 2.5 'betawidget' integration Of course, things can change, as we get more help. I also think that we should be releasing 2.3 beta candidates pretty soon, so at least we can get more feedback on this important release, and get the ball rolling. 2.3 needs to get the final terrain graphics done before we can consider a release or even beta from that tree. We should also consider increasing max zoom out before doing 2.3. I am not so sure about that. AFAIK, we don't have anyone working on terrain gfx at all. I was hoping, if we put out a beta, people would see the issue, and it will motivate them to fix the decals. 2.4 may also be a good release for Qt integration, if we decide to go for this. (For those who haven't been following the irc debates, I have a git tree where Warzone runs out of a Qt mainloop, replacing the need for SDL, and bonus features includes hardware accelerated coloured cursors, more flexible fullscreen support, and dropping the ball on a long list of build requirements.) The 2.4 release could be a good candidate for changing the map/savegame format. Oh, I almost forgot about that. If we do go the Qt route, then we wouldn't actually need 'betawidgets' would we? Qt supports svg as well, so no content that has been done will be lost. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7587] branches/2.2/data/mods
On 5/31/09, Per Inge Mathisen per.mathi...@gmail.com wrote: On Fri, May 29, 2009 at 9:25 PM, bugina...@users.sourceforge.net wrote: Revision: 7587 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7587view=rev Author: buginator Date: 2009-05-29 19:25:03 + (Fri, 29 May 2009) Log Message: --- Move aivolution from globals to multiplay, as this mod is only for multiplay use. Fix the makefile.am and makefile.win32 (untested) as well. The NSIS script also needs to be updated. It now creates a desktop link that uses the wrong parameter. Nice catch. Fixed. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7600] branches/2.2
On 5/31/09, Christian Ohm chr@gmx.net wrote: On Sunday, 31 May 2009 at 2:47, bugina...@users.sourceforge.net wrote: Revision: 7600 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7600view=rev Author: buginator Date: 2009-05-31 02:47:27 + (Sun, 31 May 2009) Log Message: --- Update Changelog NSIS script again Modified Paths: -- branches/2.2/ChangeLog branches/2.2/pkg/nsis/warzone2100.nsi Your modified question is not quite correct, DejaVu Sans supports far more than English, French and German (I think all our languages except Chinese). Performance impact is also not quite right, it's rather long startup time on the first run after a reboot. OK, so change it to: If you want to use a custom font, or need a Chinese font, then you should answer yes, all others should answer no. NOTE: on vista, reading the windows font directory can take a very long time, so the initial run of the program will be delayed, until that process is done. I'm not sure what exactly the issue is (and I have no Vista+ machines handy to find out), but if I understood it correctly, the font cache gets deleted when restarting because its in a temp dir. Then removing the cachedirWINDOWSTEMPDIR_FONTCONFIG_CACHE/cachedir line from fonts.conf should help there (so the delay is _only_ on the first run). If that line is removed, then it goes to cachedir~/.fontconfig/cachedir I have no idea where that will put the cache file then. The fontcache file isn't deleted from the temp directory after reboot/shutdown, at least, not on my system, but I have no way of knowing what it does on vista. The issue is, that if we allow fontconfig to read the windows font directory, and this is on vista, then it takes a very long time to create said cache. The only time we need to read the windows font directory is when we run into a language that DejaVu font don't support, or, people want to override the font that we are currently defaulting to. Anyway, how about shipping one config file with good substitutions, and having a Install Chinese font option (and others if we need more later), which downloads e.g. WenQuanYi and puts it into our font dir? And having all the installer actions documented so people can download/install stuff themselves would be nice as well. As would be a wiki page where the _exact_ file locations (for data, mods, savegames, screenshots, config file etc.) for the different systems are mentioned. I have no problem with packaging more fonts, I just can't test it. I tend to agree for the addition to the wiki about this info. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] 2.2 has been released!
We have released 2.2. We have the source tarball, the Fedora rpm, and the windows installer all available on our SourceForge project page. Just need the Mac builds. http://sourceforge.net/projects/warzone2100/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Drag rearm pad building
On 5/31/09, Per Inge Mathisen per.mathixxx...@gmail.com wrote: This small patch makes it possible to drag a line of rearm pad production similar to how walls and defenses can be built by dragging the production with the mouse. It also removes the obligatory empty tile between rearm pads. The reason should be obvious - it is currently very tedious to build massive VTOL rearm fields. Posted here since wz2100.net is down. I like the idea of being able to build *anything* via the 'drag a line' approach. I thought that anything but the walls had spaces, so that the AI can find a path around it? I don't think units can drive over the rearm pads? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Broken PhysFS zip support for Macs?
When the forums were up, there was talk that a few users couldn't load .wz files. After looking a bit, I found this thread on the ML, https://mail.gna.org/public/warzone-dev/2007-12/msg00129.html It seems it was never really fixed? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Final checklist for 2.2 (Final) -- ETA of release is 5/31/09
Just a heads up, that most everything is done, here is the final checklist. http://developer.wz2100.net/ticket/566 Just waiting on some windows icons, and then we can tag it, and then make the builds. I would like to thank everyone (in advance) for their help in releasing this build. :) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] List of things that are being removed for the 2.2 release
On 5/28/09, Kreuvf kre...@warzone2100.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 bugs buggy wrote: Since nobody has had time to update the docs/* to make them current, I think we should just scrub that directory, and instead have links to our web site wiki FAQ. Those are mostly up to date, and we wouldn't really need to do anything. Did you take a look at the current state of the docs? Last time I talked to you about it (~week ago?) the only thing mentioned was that some paths are not correct anymore. New command line options, cheat warning, paths, default values for the new entries in the config file, and so on... So, if those files are about to be excluded from distribution then at least make sure that all the information contained in them right now is available online as well. All that information is on the wiki FAQ is it not? Additionally I strongly dislike the idea of not having offline help resources anymore. True, but this is only temporary, until we get a chance to update the docs. For what it is worth, I did take a crack at it, but I can only handle the English readme.en, the German xhtml versions still need fixing. It still is missing lots of the new command line / config options, and I don't got the time to fix it as it should be fixed. This is even worse considering that wz2100.net to the best of my knowledge is the only mirror for the aforementioned resources and down-times happen. So I propose adding the following to the doc-files instead of excluding them: This file has not been updated since the release of 2.1. Some information may not be correct any more. For current information visit the homepage of the Warzone 2100 Resurrection Project. - - Kreuvf I guess the disclaimer can work as well... either or works for me. And we always have google cache ;) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Savegame incompatibility rc1-rc2
On 5/28/09, Zarel zarelxx...@gmail.com wrote: 2009/5/27 bugs buggy buginatxx...@gmail.com: That is why we should revert, and fix this error another way, like I explained before. Do you have a good way of fixing the error? If you do, I welcome it. Otherwise, I think this bugfix is more important than skirmish savegame compatibility (campaign savegames are fine). Another idea - when the script loader breaks like it does here, just restart the AIs? I still don't think you understand the issue, if we have 2 members for each struct, x1=10, x2=20, y1=5, y2 = 6, then it is fine. If one of the structs now has 3 entries, it doesn't match the data, so the first struct will now have 10,20,5 and the other struct will have 5,(whatever the next value is), and so on. We would have to reset all values, and that would mean the savegame is nothing like it was before. Not to mention actually coding that would be difficult, since as you may have noticed, the scripts aren't exactly easy to debug, to see what went wrong. I still think the bugfix is *very* minor, and isn't worth breaking the savegames at this point. Lots of the old savegames are used to debug issues as well. I know I have at least 30+ that I use for testing various things in the engine... Reverting is the correct choice, IMO, and it will save us from the numerous 'bug' reports and other issues involved with breaking a savegame. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7565] trunk/po
On 5/27/09, Christian Ohm chr.ohmxx...@gmx.net wrote: On Wednesday, 27 May 2009 at 14:44, Per Inge Mathisen wrote: Run update-po Why are you committing this over and over? Because Buginator can't do it on Windows and tells me to. Well, sometimes at least. Yeah... sorry for the inconvenience. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Savegame incompatibility rc1-rc2
On 5/27/09, Per Inge Mathisen per.mathi...@gmail.com wrote: Due to a small change in scripts that change the behaviour that the AI copied whatever truck the human player had, skirmish savegames (only) are incompatible between rc1 and upcoming rc2. Should we revert the change or let it be? I meant to comment on this before, I just forgot. Anyway, if you see a error like: error |01:21:11: [eventLoadContext] Context 1 of 6: Number of context variables (946) does not match the script code (945) The addition of aiconstructor is the root cause, and I don't think we could fix it in the savegame file. It just is, the old AI code had 945 variables, and the new AI code has 946. The change in the script does fix a issue that could be abused, and it is semi rare. We would get allot of flak over not being able to load 2.1.x, since people do make collections of savegame files, and we have tried hard in the past to not break savegames, with the exception of a certain 2.1 beta ... I am thinking it is better to revert, and rethink how we can fix this in the future. It would require a new savegame format + a way to detect which version of the scripts we are using. Then based on that, we can use the correct scripts. (Still a huge PITA) Which also means that when trunk goes to LUA, 2.3 and 2.2 will start to drift farther farther apart... and upkeep on 2.2 will start to lagger ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
