Re: [warzone2100-dev] Usage of Unicode MINUS SIGN (U+2212)
Am Mittwoch, 3. Februar 2010 20:52:51 schrieb Guangcong Luo: On Wed, Feb 3, 2010 at 10:26 AM, Kreuvf kre...@warzone2100.de wrote: We are currently using a normal hyphen (-) instead of the minus sign (-) to display negative values in-game. I suggest the replacement of hyphens with the minus sign whenever appropriate. Are we sure that all the libraries we use, including SDL and Qt, support Unicode? Utf-8 is cstring compatible. Thus SDL shouldnt cause issues. Qt is surely Unicode capable. --devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Usage of Unicode MINUS SIGN (U+2212)
Am Mittwoch, 3. Februar 2010 22:00:34 schrieb Guangcong Luo: On Wed, Feb 3, 2010 at 2:48 PM, Dennis Schridde devuran...@gmx.net wrote: Utf-8 is cstring compatible. Thus SDL shouldnt cause issues. C-string compatibility doesn't necessary imply that they'll be rendered correctly, just that they won't cause buffer problems. ;) Afaik we do not use SDL to render anything. I could be mistaken of course, given that I haven't had contact to the sourcecode for quite some time. --devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] dev.wz2100.net broken
Hi! There's been a time when http://dev.wz2100.net redirected to http://developer.wz2100.net. This redirection seems to be broken now. --devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Mod List Patch
Am Samstag, 30. Januar 2010 15:09:07 schrieb Per Inge Mathisen: I rather like the concept that a _is_ a mod much better Supporting that. This was the initial idea when creating base.wz, but sadly it was never finished entirely. --devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Planning to commit unicode, r aytrace, retarget - 2.3, and pointtree - trunk
Hi Cyp! Am Samstag, 16. Januar 2010 20:59:17 schrieb C yp: Hi, I was told big commits should go on this mailing list before being committed. And apparently a quick rewrite of a few files is considered a big commit. *trunk*: If noone complains, I intend to commit the PointTree to trunk. The PointTree replaces the previous grid system and all naybor stuff, without all the weird hacks. To see how it works, run make check and look at the random resulting tests/pointtree.ppm (an image file). No complaints against this for trunk. *2.3*: Also, if noone complains, I intend to commit unicode, raytrace and retarget to 2.3. Unicode does what you would expect. (You can write in whatever language you want, in-game.) Raytrace makes projectiles have better collision detection, which is less dependent on who has the best graphics card. Retarget makes things look for new targets when a target is doomed, instead of only once the target is dead. We haven't had unicode support since 1.0, one version will not make a difference. Non-raytraced projectiles might be inaccurate for some people, but definitely better than raytraced ones which do not work at all due to a subtle bug. Retargeting droids is nice, but not exactly necessary in the stable branch. Thus a No from me for the stable branch. The features are nice though, so please add it to trunk. You can then get 2.3 out quickly and start the 2.4 beta phase, to bring it to the people. Kind regards, devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Beta 7
Am Freitag, 8. Januar 2010 01:27:51 schrieb Stephen Swaney: On Thu, Jan 07, 2010 at 05:54:10PM -0600, Guangcong Luo wrote: On Thu, Jan 7, 2010 at 5:03 PM, Per Inge Mathisen per.mathi...@gmail.com wrote: Other than that, I would strongly recommend not pushing any further features into the release branch. The whole point of consecutive beta releases is to squeeze out the last remaining bugs in preparation for an actual released version. Every time you add a new feature, you create the possibility of new bugs. (see the last couple betas for an example) Adding a new feature essentially resets the Beta counter back to one. Not a good way to make progress. +1 --devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Beta 7
Hello! Am Freitag, 8. Januar 2010 01:32:29 schrieb Guangcong Luo: On Thu, Jan 7, 2010 at 6:27 PM, Stephen Swaney sswa...@centurytel.net wrote: The whole point of consecutive beta releases is to squeeze out the last remaining bugs in preparation for an actual released version. Every time you add a new feature, you create the possibility of new bugs. (see the last couple betas for an example) Adding a new feature essentially resets the Beta counter back to one. Not a good way to make progress. Fine, I'll write a simpler version of my mod loading patch for the 2.3 release. _Something_ about it needs to change. I consider the current mod loading system a bug in its own right. If you are so eager to integrate new features: Get 2.3 tested and stable quickly, integrate your features into trunk meanwhile and then start pusing out 2.4. --devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone 2100 Trac] #1360: 2.3 beta 6 network code is worse than beta 4
On Wednesday 06 Jan 2010 09:48:13 Per Inge Mathisen wrote: On Wed, Jan 6, 2010 at 7:35 AM, Warzone 2100 Trac i...@developer.wz2100.net wrote: #1360: 2.3 beta 6 network code is worse than beta 4 ... The changelog says Fix: Sync improvements. (r8975). Is that the issue? I must say that am a little annoyed that this fix was committed to trunk without review and without discussion, and then backported to a release branch without discussion, even though it clearly had the potential to destabilize the fragile net code. I would also have liked at least a notice on the mailing list about beta6 before seeing a surprise announcement on the forum. I very vaguely remember a discussion in mid-November... /irony The 1h to release was bad, but -inf h is just plain ugly... Maybe some parts of the project are developing their very own drift? --devu ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone 2100 Trac] #1360: 2.3 beta 6 network code is worse than beta 4
Hi Zarel, hi list! Am Mittwoch, 6. Januar 2010 23:44:51 schrieb Guangcong Luo: Hey, are we talking about the lack of an announcement on the ML, or are we talking about the lack of declaring an intention to tag ahead of time? Because I don't remember hearing about beta 5 until _after_ I saw tagging beta 5 on the commits list... I just found it odd that not 2 months ago we had a complaint so much similar to this one that it could appear I had jumped in time. Unlike beta 5, we had a good reason to rush out beta 6 That may be me, but rushing almost never seems like a good option. (RTS games being an exception...) tags: Christian is right, with svn's concept of tags = branches-with-special-name there is not much difference between announcing *to* tag and waiting until release, and announcing *the* tag and waiting until release. The last might even be required for some OS to test (don't know about the current state of OSX). In any case it would have been nice to know in advance that you are preparing a release. Even a beta5 was borked, we are working on fixes to release beta6 within the next day would have been better than this (nothing). (And if beta5 was not broken/the reason for beta6, then there imo was not much reason to run that quickly for beta6 anyway. A few days wouldn't make a working version any worse.) It could just appear (not saying that was your intention) that you were ignoring other people's concerns, as soon as you have none yourself, which would not be exactly nice. Regards, devurandom signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Trac categories
Am Dienstag, 5. Januar 2010 21:06:20 schrieb Christian Ohm: On Tuesday, 5 January 2010 at 12:16, Stephen Swaney wrote: Maybe 'enhancement' could be changed to 'patch' to keep it from being mistaken for a feature request. Sounds good to me. Objections? None. --devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] A question of wikis
Hello! Am Samstag, 2. Januar 2010 18:07:36 schrieb Daniel Kliman: So my next question is (Zarel suggested I ask it on the list), why not use the Hosted Apps service that SourceForge has? It would mean that they take care of the upkeep so we would not have to; Kamaze likes to maintain a server and provide us with hosting. (At least last time I talked to him.) Now, what's the catch you ask? (No, not ads.) Direct filesystem and database access to Hosted Apps is not provided; so i would not recommend putting trac there but we might be able to get by with a wiki. Sounds like a case of lock-in. Thus I would not want to use it. Regards, Devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[8906] branches/2.3
Am Freitag, 1. Januar 2010 17:01:58 schrieb muggen...@users.sourceforge.net: Revision: 8906 Property Changed: branches/2.3/ branches/2.3/data/mods/multiplay/original/ branches/2.3/src/frontend.c You are changing unrelated files randomly as it seems. --devu signature.asc Description: This is a digitally signed message part. ___ 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
Am Freitag, 4. Dezember 2009 21:30:58 schrieb Zarel: [...] you have to consider that most people, even if they don't speak English, should know Ready? if they play games online. That is not a valid assumption. --devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone 2100 2.3 Beta 2 is now out!
Am Sonntag, 22. November 2009 15:28:34 schrieb Per Inge Mathisen: On Sun, Nov 22, 2009 at 2:31 AM, Zarel zare...@gmail.com wrote: Incompatible with Mac OS X. It compiles, but doesn't run (quits with no errors). I see you fixed it a bit later. Could you build a 2.3_beta2.1 for MacOSX? Please do not forget to tag in case you do. signature.asc Description: This is a digitally signed message part. ___ 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
Am Samstag, 21. November 2009 05:53:46 schrieb Zarel: On Fri, Nov 20, 2009 at 10:12 PM, bugs buggy buginato...@gmail.com wrote: Ok, will do that for stable builds. Though, we still need to announce it on the ML, so everyone knows to build whatever. Yeah, well, make sure to announce the tag, not the release. :/ Something of the more random sort, which I just noticed: http://techbase.kde.org/Schedules/KDE4/4.4_Release_Schedule Look at the distinction between tag and release. --devu signature.asc Description: This is a digitally signed message part. ___ 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
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. 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 signature.asc Description: This is a digitally signed message part. ___ 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
Am Donnerstag, 19. November 2009 12:26:20 schrieb Christian Ohm: On Thursday, 19 November 2009 at 2:00, Zarel wrote: 2.3 still can't be built on Mac; something about libpng failing an MD5 hash check. See the end of this message for a detailed error report. Looks easy enough to fix, just change the SOURCE for libpng to http://sourceforge.net/projects/libpng/files/libpng-stable/1.2.16/libpng-1. 2.16.tar.gz/download in the xcode project. Is that what's used for official builds? It is using a very... antiquated looking URL for libpng, and that's not the only thing... libpng 1.2.16 while 1.2.40 seems current? libtheora1.0beta3? QuesoGLC svn revision 835? And I recall some cursor problems, so an update to SDL 1.2.14 might help there... If you go that route, do not forget to test *everything* thoroughly. That is an example for a change which caused bugs slipping into a release earlier. --devu signature.asc Description: This is a digitally signed message part. ___ 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
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. --devurandom signature.asc Description: This is a digitally signed message part. ___ 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)
Hello everyone. Am Sonntag, 15. November 2009 20:43:50 schrieb Christian Ohm: On Sunday, 15 November 2009 at 4:23, Zarel wrote: Wait a few days between tagging and actually announcing the release publicly Isn't that rule kind of stupid anyway? I thought tags should be touched as little as possible after tagging, so the waiting period should be before, not after the tag. And Buginator announced his intention to tag 24 hours before, so there was some time to test/commit pending stuff/whatever. I do not think that this rule is stupid. But then I wrote it originally, so I may be biased. It is based on lots of bad experience, and I can also tell you that the few days in that sentence certainly has a purpose. What we had once, was tag, push out src tarball, then the Windows guy would come and try to build, oh it does not, fix, push out windows build. A little while later someone is building for Mac: try to build, oh it does not, fix, push out the mac build. Then someone actually tried to run the game on, say, Windows. Oups, it crashes in level 17 of campaign 40 now, and it is talking about some wrong filename - fix, push out a new build. What we had in the end was 1 tag, 1 tarball, and 3 builds from revisions (or not even that) no one was able to figure out later on. Saying we are going to tag next week, please build and test did not help a bit. Announcing the release on the website along with uploading the tarballs made the stuff just worse, because ppl actually downloaded that stuff (who can blame them), and, in case the release contained critical errors and thus had to be retagged, the confusion increased. Thus the rule: wait a few days between tagging and releasing. I am very sceptic that quality will not suffer if you rely on ppl testing after someone writes an email to the list that he is about to tag 24h later. Not only are not many ppl reading this, they are also too lazy to actually test, especially not quickly, and the actual workers have full time schedules, which do not permit them to throw away whatever they were doing at that moment and just jump into WZ QA instead. 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) And people who can read and find the SF/GNA links. But no users. Since users usually do not dig into any devstuff sites for links. On Sunday, 15 November 2009 at 4:44, Zarel wrote: Well, there's no reason why Buggy has to handle the entire release, Do we have someone else who can make (good) Windows builds? I thought there were some problems with the crashdumps or something if you don't have exactly the right setup. There are issues (but they are fixable - don't look at me, I don't have time). If Buginator creates the Windows builds, that would be a nice task already. I think what Zarel means is that he does not also have to carry out the tagging, tarballing, announcements, etc, if that would mean that others cannot get stuff to build and test in time. Regards, devurandom signature.asc Description: This is a digitally signed message part. ___ 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)
Am Sonntag, 15. November 2009 22:23:34 schrieb Christian Ohm: On Sunday, 15 November 2009 at 21:11, Dennis Schridde wrote: Then someone actually tried to run the game on, say, Windows. Oups, it crashes in level 17 of campaign 40 now, and it is talking about some wrong filename - fix, push out a new build. That doesn't sound like a bug that would be detected in a few days, since we don't have any dedicated testers for every release... Exactly. But there are these users which actually happen to be playing at that level right now, and they will find such issues in the build system / a mod / a new file / ... right when they install the new version. Admitting that my example was a bit far fetched, several times situations occurred, where quick users, using the tarball right when it was announced, found issues which we missed before. That even happened just hours after the announcement, so in just a few hours there were several versions floating around. Resulting in different OSes, arches or distros having different bugs to fight with. It was annoying to work with: Crashdumps did not match the actual code, bugs appeared which should not happen, tarball-checksums for distros like Gentoo failed, other distros did not notice the replaced tarballs at all, etc. Thus it seemed better to wait a bit longer before making the final tag public, to catch such situations. (Eager users are still downloading tarballs right when the ML says its uploaded, or even download from SVN. And they also can cope with we retagged, download again. At least that's how it was back then.) If it could be guaranteed that every OS/arch/distro is being built for and tested thoroughly immediately after the tag happened (and not before, since that calls for inconsistency), then I agree that this could work, too. As a safety measure the forced slowdown seemed appropriate. 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. Regards, devurandom signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.2.3a for Macs?
Am Sonntag, 27. September 2009 23:06:13 schrieb bugs buggy: I do NOT think we should tag a 2.2.3a Every release shall be tagged, for reasons of tracing. It will not cost any diskspace, thus I see no issue. signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Give Cathuria and Neuralize the title of artist?
Am Montag, 31. August 2009 22:24:54 schrieb Per Inge Mathisen: On Mon, Aug 31, 2009 at 9:17 PM, Elio Gubserelio.o...@gmail.com wrote: there are people around which also spend much time on warzone (e.g. mod creators) perhaps we should give some of them a label. (delphinio, black project) The danger I foresee is that if labels are being handed out like candy with no clear rules, then anyone who does not get it will feel left out or offended. The rules for the 'developer' label is very clear - either you have svn commit access or not. I wish we could have something equally clear for the other labels. Only artists with commit access? --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Give Cathuria and Neuralize the title of artist?
Am Montag, 31. August 2009 22:31:43 schrieb Zarel: We could fix this situation right up by using the same have commit access bar, and give Mysteryem commit access. ;) I saw the ;) and I do not want to be rude, but giving someone commit access in order to allow them to get some fancy forum label sounds like the totally wrong way to approach this. --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone-dev] Making trac friendlier?
Hello again, and please excuse me digging in old mud! Am Samstag, 22. August 2009 00:58:13 schrieb Dennis Schridde: Am Samstag, 22. August 2009 00:29:03 schrieb bugs buggy: 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. Trac has (had?) some powerful filtering possibilities. Maybe they could be of use? In earlier versions, the most powerful variant were direct SQL queries, which could be saved and made available to regular users. It was considered to implement an easier report generator wizard, but I do not know whether they already implemented that in current versions. If not, maybe that feature could be made available to commiters/developers? It should then be able to filter based on type, state, tags, assignee, etc. in various ways. I would not generally forbid users to submit feature requests. Bad/stupid/insane requests can be closed, and good and reasonable tickets can gather ideas/opinions until someone finds the time to do them. Finaly, small requests can be implemented during lunchbreak, or whenever someone feels like doing just a little bit to push Warzone forward. (Also popular for spare time wz devs?) [...] About the additional resolution: You should use later instead. That is quite standard among most bugtrackers and usually means not now, but we will reconsider it. Do we have any final decision on this from the active team? It does not seem as if feature requests are stopping, and they do not get less interesting either... --Devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] The download page
Am Dienstag, 25. August 2009 02:41:43 schrieb Cheny Luo: 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. On the download page there is a link to the download archive, which contains descriptions of all previous versions including download links. I assume the should be sufficient? --Devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone-dev] Changelog changes?
Am Montag, 24. August 2009 02:55:14 schrieb Stephen Swaney: On Mon, Aug 24, 2009 at 12:40:56AM +0200, Christian Ohm wrote: On Sunday, 23 August 2009 at 23:40, Per Inge Mathisen wrote: I like current format. It gives superb traceability of everything in the changelog, and looks really correct. If it is a PITA to maintain for people, I am willing to do it. If you want to use the ChangeLog in official postings, just sed remove everything inside parentheses first to make it look better. I agree with Dennis that the Changelog should give a good overview of the user-relevant changes, and the current copy the svn log the day before a release approach doesn't do a good job of that. The Changelog should be detailed information for developers - exactly what is different in the code from before. Users only care about visible changes. For them, something like GNU's NEWS or Release Notes describes items of interest. The Changelog and Release Notes serve two separate functions and have different audiences. The current Changelog seems fine to me. We never had a changelog-for-developers. Our ChangeLog always was meant to be a changelog-for-users. It was meant to contain user visible changes, with the definition of user partly containing mod authors, too. I never saw sense in having two changelogs, one for the users and one for developers. The latter can look into the svn/git log, and if they cannot, then a svn2cl generated log does not really help them either, without the diffs. --Devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone-dev] Changelog changes?
Am Montag, 24. August 2009 00:40:56 schrieb Christian Ohm: I agree with Dennis that the Changelog should give a good overview of the user-relevant changes, and the current copy the svn log the day before a release approach doesn't do a good job of that. Perhaps we could make it a policy to include a changelog entry for commits (for user info, as opposed to develper info in the svn log), and then Per or others who want revisions included can add them later. It sounds like a good idea. However, we already tried this, but since it was never enforced, it did not last long. --Devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone-dev] Changelog changes?
Am Sonntag, 23. August 2009 21:23:25 schrieb bugs buggy: 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. It should present the user a good overview about new features, which existing things important to him have been changed or bugfixed. That is a kind of service and thus implies to take some time. Whether it is more or less than it should be depends on how userfriendly someone is, and how many detail users and distributors want. We could just drop the revision number, and stick with tickets, Sounds reasonable. Especially since the revisions are mentioned in the tickets and also of no importance to the average user. Further they are different for trunk and branches and thus backports will create a mess. or we could use svn2cl to produce the changelog for us. In that case we need to move the current ChangeLog to NEWS (GNU style). Replacing current ChangeLog with an svn2cl generated ChangeLog is definitely not an option to me. The changelog shall be user readable, and also only contain things interesting to the user. It shall be grouped by topics and arranged by importance and significance. That is not possible for a machine to do. Regards, Devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone-dev] SF svn repo upgrade to 1.6.4?
Am Sonntag, 23. August 2009 21:56:22 schrieb bugs buggy: 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 I've got an svnsync mirror, in case that qualifies as a backup. signature.asc Description: This is a digitally signed message part. ___ 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?
Am Sonntag, 23. August 2009 21:18:35 schrieb bugs buggy: 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. Has someone seen Gerard lately? Has someone seen progress in BetaWidget? I do not want to spoil the party, but it just does not seem to be realistic to have a release containing both of them soon. Regards, Devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Making trac friendlier?
Am Samstag, 22. August 2009 14:50:46 schrieb Christian Ohm: On Friday, 21 August 2009 at 23:11, Zarel wrote: On Fri, Aug 21, 2009 at 9:16 PM, Stephen Swaney sswa...@centurytel.net wrote: Right now, we overload 'enhancement' to mean both patches and feature requests. Ideally, we want to be able to separate the bugs and patches from feature requests which are often useless. The last time I brought this up, the reply was to add [patch] to the subject line. [...] Seems to work well enough like that. Except that filtering for that is harder. A direct trac type would be nice. Basically if we want non-bugs in trac, we need an easy way to get a list of outstanding issues without the noise (and the contrary things to waste time on when bored list). That was my intention when I suggested making needinfo a priority (maybe not the best solution, but easy to do without plugins), you can just filter it out while keeping the bug open (autoclosing with the pending plugin might be nice, though). I think Trac allows tagging with custom keywords. If we allow only devs to do that, we could use it for this purpose, too. (See my last mail on the subject.) signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Making trac friendlier?
Hi! Am Samstag, 22. August 2009 00:29:03 schrieb bugs buggy: 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. Trac has (had?) some powerful filtering possibilities. Maybe they could be of use? In earlier versions, the most powerful variant were direct SQL queries, which could be saved and made available to regular users. It was considered to implement an easier report generator wizard, but I do not know whether they already implemented that in current versions. If not, maybe that feature could be made available to commiters/developers? It should then be able to filter based on type, state, tags, assignee, etc. in various ways. I would not generally forbid users to submit feature requests. Bad/stupid/insane requests can be closed, and good and reasonable tickets can gather ideas/opinions until someone finds the time to do them. Finaly, small requests can be implemented during lunchbreak, or whenever someone feels like doing just a little bit to push Warzone forward. (Also popular for spare time wz devs?) 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. Ideally needinfo would start a countdown, which would closed/needinfo the ticket after X days. I would not be surprised if such a Trac plugin exists. 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? You could try working more with keywords/tags. Remove the users ability to change them, and use it to track the state of the ticket. I.e. needinfo (like the resolution, just for not-yet-closed tickets), needtesting, needreview, ... This is just an idea for an experiment. I have no experience yet with whether and how well it works. About the additional resolution: You should use later instead. That is quite standard among most bugtrackers and usually means not now, but we will reconsider it. --Devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7968] trunk/lib/exceptionhand ler/exceptionhandler. c
Am Freitag, 14. August 2009 17:52:01 schrieb Kreuvf: Dennis Schridde wrote: No clue, but I support that question. To my knowledge you cannot compile the unix crashdump code with bad compilers anyway. Bad compilers? msvc signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Update to QuesoGLC .7.2 before 2.2.2 release?
Am Sonntag, 2. August 2009 20:48:21 schrieb bugs buggy: 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. +1 signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Test
Am Dienstag, 4. August 2009 16:04:35 schrieb Per Inge Mathisen: Does the mailing list work? It does. signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7902] trunk
Am Montag, 27. Juli 2009 18:14:37 schrieb Per Inge Mathisen: On Sun, Jul 26, 2009 at 9:55 PM, Dennis Schriddedevuran...@gmx.net wrote: Am Sonntag, 26. Juli 2009 20:07:13 schrieb Per Inge Mathisen: On Sun, Jul 26, 2009 at 7:46 PM, Dennis Schriddedevuran...@gmx.net wrote: Add INI file parser (iniParser -- version 3.0b (beta) by N.Devillard) Please add the possibility of --with-iniparser=system to configure. Don't see why, as I don't think any distros package it. http://gentoo-portage.com/dev-libs/iniparser In any case, we are going to have to do some custom surgery on this code in order to interface it to physfs. In that case: Giel already created patches against stock sqlite. I would prefer to have that for iniparser as well. --Devu ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7902] trunk
Am Sonntag, 26. Juli 2009 16:57:03 schrieb sen...@users.sourceforge.net: Revision: 7902 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7902view=rev Author: sendai Date: 2009-07-26 14:57:03 + (Sun, 26 Jul 2009) Log Message: --- Add INI file parser (iniParser -- version 3.0b (beta) by N.Devillard) Please add the possibility of --with-iniparser=system to configure. ___ 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
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. --devu ___ 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
Am Sonntag, 26. Juli 2009 20:05:20 schrieb bugs buggy: 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. True. I am just actively looking at the commit list. ;) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7902] trunk
Am Sonntag, 26. Juli 2009 20:07:13 schrieb Per Inge Mathisen: On Sun, Jul 26, 2009 at 7:46 PM, Dennis Schriddedevuran...@gmx.net wrote: Add INI file parser (iniParser -- version 3.0b (beta) by N.Devillard) Please add the possibility of --with-iniparser=system to configure. Don't see why, as I don't think any distros package it. http://gentoo-portage.com/dev-libs/iniparser ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] es translation
Am Sonntag, 12. Juli 2009 13:46:52 schrieb Kreuvf: Gustavo Vivas wrote: hello, i send here a little work of translation to Spanish. hope it helps. :) Not sure, but aren't translations handled on the forums or trac? Not necessarily. If someone reads the mail he can just as well import it from here. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7807] trunk/data
Am Montag, 22. Juni 2009 23:13:46 schrieb zare...@users.sourceforge.net: Revision: 7807 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7807view=rev Author: zarelsl Date: 2009-06-22 21:13:45 + (Mon, 22 Jun 2009) Log Message: --- Also get rid of useless multiplayer folder in base.wz. Removed Paths: - trunk/data/base/stats/research/multiplayer/ Are you sure this is exactly what you wanted? base.wz was meant to contain (almost) all files, and mp.wz should contain the minimum necessary to be replaced for a multiplayer game. (That part for which WZ has no way to distinguish between sp and mp, like special stats.) That is the reason why base.wz's string files contain strings only found in multiplayer games, why it contains textures and icons not necessary for singleplayer games, etc. The final goal was to have just one wz file for the unmodified warzone2100 base game one day. --DevU ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Reencoding the videos
Am Freitag, 19. Juni 2009 08:02:57 schrieb bugs buggy: On 6/18/09, Christian Ohm chrxx...@gmx.net wrote: 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? I will have a read in the readme on the weekend and tell you afterwards. Till then you can start to upload reencoded english cutscenes. ;) 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?) warzone2100-sequences-latest.wz? Sounds good. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Project rename, website changes
Hi Zarel, hi list! Am Mittwoch, 17. Juni 2009 02:08:15 schrieb Zarel: - The site logo in the upper left should be updated to be inline with the new Warzone logo. [...] Agreed. - The Development tab should be removed, and the Trac tab should be renamed Development. [...] http://developer.wz2100.net/ starts with bug reports. For a general development introductory page this might not be the best choice. I would put it more towards Programming, and maybe even dedicate an own page to it. - Reason: The introductory page should direct to the right documentation. The chunk of text at the beginning draws more attention than necessary. Apart from that: Agreed. PS: Is it possible to improve the CSS of http://developer.wz2100.net/? I like the one of http://wz2100.net/ a lot more, if we are going to use the site not exclusively for technical documentation. - 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. [...] Agreed. - I believe the Warzone Guide is complete enough that it can directly replace the User Guide tab. I would prefer to have such stuff in the Wiki. - Reason: Ease of editing. If that's infeasible, at least make sure it's on the same server (make wz2100.net a mirror using rsync, for example) and stays in line with the current layout/style. (Use the same (links, not copies) CSS files.) - Reason1: I would not want to loose any content if someone of us gets lost. Thus a server which is kind of sure not to vanish, and where multiple persons can get backups in emergency cases. - Reason2: One style for the page just looks better. In addition http://guide.wz2100.net/ is not an introductory page like http://wz2100.net/user-guide is. http://guide.wz2100.net/intro comes closes, though it is not the frontpage. It also has style issues: - Starts with a *huge* flash box, which makes the page look almost empty on first sight for me. - The Introduction section should be merged into the http://wz2100.net/ frontpage if necessary. In this location it seems like duplication. - Installing mentions compilation instructions. I'd prefer a link to the Wiki instead. - The Documents Project finds no mention at all. - There is no hint to the Development section. - Contact information (better: a link to them) is lacking. - The navigation panel on the right is not immediately noticed as such. In general I would prefer a more textual page with less markup. (Markup is like makeup: Best effects are achieved if applied decent.) Means: In-text links, headings should not detract from the content, not too much colour which could draw attention from the important parts, etc. And get that flash thing away from the start of the page. That said, http://wz2100.net/user-guide also has suboptimal style. The opening paragraph mentions the FAQ, which is never mentioned later. The opening paragraph should just be an introduction and summary, while the important questions should be placed more prominently in the subsections. Let's rename our project from Warzone 2100 Resurrection Project to Warzone 2100 Project (and the abbreviation from WRP to WZP). Even though I do not like name changes, those 6 reasons got me convinced. Kind regards, Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Project rename, website changes
Am Mittwoch, 17. Juni 2009 11:08:32 schrieb Zarel: On Wed, Jun 17, 2009 at 3:21 AM, Dennis Schridde wrote: http://developer.wz2100.net/ starts with bug reports. For a general development introductory page this might not be the best choice. I would put it more towards Programming, and maybe even dedicate an own page to it. - Reason: The introductory page should direct to the right documentation. The chunk of text at the beginning draws more attention than necessary. Apart from that: Agreed. I agree that it's not perfect, but I'm at a loss for further improvement, and I feel like I'd lose information from it if I rewrote it entirely. Feel free to make whatever changes you see fit (it is a wiki, after all). As I said: Put the bug-reporting part a little bit more down (maybe also link to another page) and it is perfect. PS: Is it possible to improve the CSS of http://developer.wz2100.net/? I like the one of http://wz2100.net/ a lot more, if we are going to use the site not exclusively for technical documentation. [...] Overall, it's missing a lot of CSS that's probably used in the wiki. While I agree that what it does implement, it implements better, but we should probably duplicate all the features of the current CSS file first. (see below) If that's infeasible, at least make sure it's on the same server (make wz2100.net a mirror using rsync, for example) and stays in line with the current layout/style. (Use the same (links, not copies) CSS files.) Ever since it's been moved to guide.wz2100.net, it's been on the same server. Sorry, I was misinformed. I still remembered the days when it was on an own site, so I assumed just the guide.wz2100.net alias is new. I would allow any user to edit the Guide pages, however Kamaze isn't letting me access the user database, so I can't identify users to allow them access. Understandable. If understood Kamaze right his main concern is that no one should be able to read the DB, which would not happen with an auth-service. So: Does wz2100.net have no kind of authentication/authorisation service? (I am not speaking of Kerberos here... LDAP can afaik provide authentication, then there is saslauthd, dovecot-auth, and whatnot. Thus I would assume there is something that all of phpbb, Trac and whatever you are using support.) Currently I just give access to nearly any user who asks for it. Using the current layout/style is a bit more complicated. I can duplicate the _current_ style, and use its stylesheet in addition to my own, but I can't guarantee that it would be updated when the main site's layout is updated (that would be up to Kamaze). I was more thinking of a collaboration. ;) I assume that the Trac stylesheet provides formatting which is not relevant to your page, and you might need some rules in addition to that. The trick is to take the CSS, enhance it, and put it back on (dev.)wz2100.net. In addition http://guide.wz2100.net/ is not an introductory page like http://wz2100.net/user-guide is. http://guide.wz2100.net/intro comes closes, though it is not the frontpage. Well, I'm not sure an intro page would make a good home page. A contents index with quick links to major sections makes the most sense to me. More suggestions along these lines would be nice. Point is that if the page becomes the new User Guide section of the website, it is no longer a home page, but a sub page. Further the User Guide page on w.n was meant to give the user an overview over the user-relevant aspect of the website. The explanatory and introducing part gets entirely lost in a link list as http://guide.wz2100.net/ is. It also has style issues: - Starts with a *huge* flash box, which makes the page look almost empty on first sight for me. Well, the video _is_ a good introduction. And it's only 640x480. If you take desktop-panel, window-decorations, menubar, toolbar, addressbar, bookmarkbar, statusbar, your main-navigation, the headings and that flash blob together, this leaves about 2cm for actual text, of which 100% is the standard 1000-times-read Warzone 2100 description. I do not say you shall remove that video. But put it into a place where it does not distract so much from the actual content. XHTML+CSS and Web 2.0 techniques i.e. allow for an expand or tell me the story button. And if you dislike that, the flash monster is still better placed below the actual introduction. What I like about http://wz2100.net/user-guide is that on one screen and in one sight you get a quick overview in very short texts over all the relevant section of the website. - Installing mentions compilation instructions. I'd prefer a link to the Wiki instead. It _does_ link to the wiki. It just also provides basic compilation instructions. I noticed that it does. But the commandline code would tell me at first: Ough, skip over this section, it's not what I want. My point is: Most people view (especially) websites
Re: [Warzone-dev] 2.2.1 release date / 2.3 beta release date?
Am Donnerstag, 11. Juni 2009 10:15:01 schrieb Per Inge Mathisen: On Thu, Jun 11, 2009 at 6:27 AM, bugs buggybuginato...@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? I would like to know that too. 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 In fact I am not sure what stroke of a genius it was that I implemented before... Now the border should be actually one pixel and not some random fraction of one. 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 I am for releasing 2.2.1 earlier than the release of 2.3_alpha1. --DevU signature.asc Description: This is a digitally signed message part. ___ 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?
Am Donnerstag, 11. Juni 2009 18:22:39 schrieb Christian Ohm: On Thursday, 11 June 2009 at 11:35, Dennis Schridde wrote: I've fixed it! - http://gitorious.org/warzone2100/mainline/merge_requests/642 Nope, sorry. You mean that's broken, too? Looked fine on first sight, but it was hard for me to find a map where I could see a difference anyway. Which map do you test with? --DevU signature.asc Description: This is a digitally signed message part. ___ 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?
Am Donnerstag, 11. Juni 2009 22:12:54 schrieb Christian Ohm: On Thursday, 11 June 2009 at 22:00, Dennis Schridde wrote: Am Donnerstag, 11. Juni 2009 18:22:39 schrieb Christian Ohm: Nope, sorry. You mean that's broken, too? Yes. It looked similar to Buginator's solution At least this is a lot simpler... Looked fine on first sight, but it was hard for me to find a map where I could see a difference anyway. Which map do you test with? That's the first campaign, but any longer road should work (just look at it like in the above screenshot, and with a low resolution at fullscreen it's most obvious). Will try again next time using that map, thanks. --DevU signature.asc Description: This is a digitally signed message part. ___ 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
Am Freitag, 5. Juni 2009 04:19:34 schrieb bugs buggy: 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. Understood. But still I would prefer the *(char*)0=0; to be in one function which purpose can be easily identified. --DevU signature.asc Description: This is a digitally signed message part. ___ 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
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.) --DevU signature.asc Description: This is a digitally signed message part. ___ 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
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. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Trunk's GLee hack, revert?
Am Freitag, 5. Juni 2009 00:21:24 schrieb Christian Ohm: This is bad. I am thinking we should revert the hack altogether. Opinions? Actually there is no need to do the hack in GLee.c, so we can move it somewhere we can check the GL_RENDERER string. See patch. I think checking for specific drivers and applying hacks in that case is a bad behaviour. Can we not run a behavioural check instead? I.e. supports VBOs, but not GL 1.5 - likely to be broken? If you think that could cause havok on the wrong drivers, you could still check for renderer=mesa as a precondition to that, if it really need be. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Proposed Roadmap
Am Dienstag, 2. Juni 2009 20:18:11 schrieb bugs buggy: On 6/2/09, Per Inge Mathisen per.mathxxx...@gmail.com wrote: 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. Keyword: WolfenQt [1] --DevU [1] http://labs.trolltech.com/blogs/2008/12/02/widgets-enter-the-third- dimension-wolfenqt/ signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2 has been released!
Am Montag, 1. Juni 2009 04:38:35 schrieb bugs buggy: We have released 2.2. Congratulations to everyone involved, especially Buginator! You are doing a marvellous job in keeping this running! Greetings, DevUrandom P.S. I uploaded the Windows installer and the source tarball to Gna and fixed the version numbers. Filename of the installer was corrected, and I rebuilt the tarball. signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2 has been released!
Am Montag, 1. Juni 2009 19:12:22 schrieb bugs buggy: On 6/1/09, Dennis Schridde devuran...@gmx.net wrote: P.S. I uploaded the Windows installer and the source tarball to Gna and fixed the version numbers. Filename of the installer was corrected, and I rebuilt the tarball. I noticed that on both linux my VM (for building windows installer), that it only sets the name as 2.2 and the same goes for the version string in the game itself. I take it this is a script error someplace, or perhaps it is seeing 2.2.0 as 2.2 ? Nope, configure.ac has this issue included. signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7539] trunk/lib/exceptionhand ler/exceptionhandler. c
Am Samstag, 30. Mai 2009 15:23:18 schrieb Giel van Schijndel: Exceptionhandler: Remove signal descriptions for signals that are either non fatal or simply not handled by our signal handler As for a generic signal-to-string method If follows SuSv3, iirc. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7568] branches/2.2/pkg/nsis/warzone2100.nsi
Am Donnerstag, 28. Mai 2009 04:24:35 schrieb bugina...@users.sourceforge.net: **NOTE** the dev-package must be changed. There are two new files, one is called font.conf.wd_enabled and the other is called font.conf.wd_disabled. The only difference between the file is we either have WINDOWSFONTDIR enabled or disabled. They belong in the same directory as the old font.conf file. The installer will rename the file based on the user's choice. Idea: sed (I guess NSIS has an equivalent) the font.conf file to insert/remove !-- -- around the WINDOWSFONTDIR setting. signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Adding mods/music change for 2.2?
Hi Buggy! Am Dienstag, 26. Mai 2009 20:53:37 schrieb bugs buggy: The file on GNA http://download.gna.org/warzone/releases/mods/community-music_1.0.wz isn't in the correct format for 2.2. Since the playlist code has been neutered, that file won't work as is. Do we repackage it, and bump the version number, or do we remove it from the installer option to download it? Repackage, bump version number. (Btw: Someone recently wanted to publish something without a version number. Here you have a reason why this would have been a bad idea.) I am also adding: mods/music for people to stick in 'music mods' in. This will allow for drop in of the new file so we can get new music into the game easier. +1 --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7539] trunk/lib/exceptionhandler/exceptionhandler. c
Am Sonntag, 24. Mai 2009 23:40:41 schrieb muggen...@users.sourceforge.net: Revision: 7539 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7539view=rev Author: muggenhor Date: 2009-05-24 21:40:41 + (Sun, 24 May 2009) Log Message: --- Exceptionhandler: Remove signal descriptions for signals that are either non fatal or simply not handled by our signal handler Are you trying to save size in the executable? In other words: What is the sense of this? Did those strings harm someone? Is it bad to have a generic signal-to-string method? Suggestion: Revert --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Mac exception handler?
Am Donnerstag, 21. Mai 2009 07:09:37 schrieb bugs buggy: Is there a reason why the mac exception handler is different than the rest? I don't see the source for it anyplace? The reason is, I wish to make it dump out more information that what it does now, to make it more like the windows linux dumps. MacOSX exception handler is a little bit like the Windows exception handler: It uses operating system methods to create a debug file. This is done automatically by MacOSX for all applications, iirc. So the user just needs to send us that file. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Mac exception handler?
Am Donnerstag, 21. Mai 2009 20:07:32 schrieb bugs buggy: On 5/21/09, Dennis Schridde devuran...@gmx.net wrote: Am Donnerstag, 21. Mai 2009 07:09:37 schrieb bugs buggy: Is there a reason why the mac exception handler is different than the rest? I don't see the source for it anyplace? The reason is, I wish to make it dump out more information that what it does now, to make it more like the windows linux dumps. MacOSX exception handler is a little bit like the Windows exception handler: It uses operating system methods to create a debug file. This is done automatically by MacOSX for all applications, iirc. So the user just needs to send us that file. So there is no way for us to pass arguments to the mac exception handler, for us to print extra information? I was hoping for version, build, and command line... There may be, but you probably would have to read MacOSX API docs for that. And the last report I recall had endless sheets of stacktraces, loaded libraries, register dumps, ... So maybe there is just something broken in the way we compile. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7465] branches/2.2/src/action.c
Am Dienstag, 19. Mai 2009 04:48:10 schrieben Sie: Log Message: --- Bug discovered by our very own and very incredibly awesome developer Buginator and all the hard work he has contributed to our project. Maybe you should leave such jokes out of commit messages... ;) --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2 RC1 scheduled for release this weekend
Am Sonntag, 10. Mai 2009 16:43:43 schrieb Zarel: 2009/5/9 Christian Ohm chr@gmx.net: I don't think releasing 2.1.4 will result in much less _useful_ testing for 2.2. Yes, you might get more people to try 2.2, but if they are tricked into using it they'll just see it's unstable yet, and go back to 2.1 (if 2.1 isn't too unstable for them either) instead of giving useful bugreports. But with a 2.1.4 release those who don't want to test 2.2 get a better 2.1. What is it now? Devu, Christian, Kreuf, Per, me in support cybersphinx neutral Buggy, stiv against And while all that talking was going on, one could have created a hundred builds... signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Final call for 2.2 changes
Am Samstag, 9. Mai 2009 12:20:56 schrieb Zarel: We could put our different video.wz files under a corresponding directory at Gna. Heck, put a COPYING file in each of those directories, too, for good measure. Or do the simple and put COPYING into the file itself... --DevU P.S: 1. Read the GPL again, carefully. 2. If you don't notice anything, return to 1. signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2 RC1 scheduled for release this weekend
Am Freitag, 8. Mai 2009 07:13:48 schrieb Stephen Swaney: Actually, releasing two versions should be approximately twice as much work. Build scripts are written and if no one broke them, then they will still work. Upload takes under an hour (depending on your connection). Why did we backport bugfixes to 2.1 at all, if we are so very determined to never release them? In fact, why do we backport any bugfixes? If we are so much against maintaining older branches, why don't we just release a 2.2 final, and continue with the 2.3 alphas/betas/rcs, to start 2.4 immediately after 2.3 final? Actually not all of the above is pure sarcasm. It has some valid point, imo. If attention is split so badly, and that is hurting us so much, we could as well not draw any attention from our latest efforts to something legacy. On the other hand, if we want to support legacy versions, the statement that they prevent testing of the next generation looks somewhat against the policy. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Getting rid of third-party mods
Am Donnerstag, 7. Mai 2009 21:11:00 schrieb bugs buggy: And note, AIV is *not* a 3rd party mod IMO, that should stay for now. Why dont we remove 1.10-ai and replace it with aiv? Are there issues with the latter? (1.10-ai could stay as a mod if someone desires.) --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2 Beta 3 scheduled for release this weekend?
Am Mittwoch, 6. Mai 2009 21:57:48 schrieb bugs buggy: Was planning on a 2.2 Beta 3 scheduled for release this weekend. Nice, appreciated. Major fixes are Lobby server code (and client side) improvements, and more bug fixes. I hope the ChangeLog is more extensive... ;) We also still have a large number of .po files that need to be straightened out. Multiple versions of the same language (3 for Russian, 2 for Chinese(?) and a few others as well). I can see only one ru.po and just one zh_CN.po... Is everyone OK with this? I assume ok with the release, not with the PO files? Yes. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Install OpenAL silently
Am Dienstag, 5. Mai 2009 04:53:13 schrieb bugs buggy: On 5/4/09, Zarel zare...@gmail.com wrote: Hey, guys. Having to click OK twice in the middle of an installation (to install OpenAL) is kind of annoying. Also, having the OpenAL installer pop up when the Warzone installer is in silent mode is not only annoying, but defeats the purpose of silent mode. Apparently, the reason it's currently not silent is because we supposedly can't agree to the license for the users. I don't even know why we are using Creative's openAL anyway, we should be using openALsoft version, and just drop it in warzone's directory. If we do stick with Creative's, then I found this: http://opensource.creative.com/pipermail/openal-devel/2006-August/004542.ht ml He was one of the devs, so I would think if he says we can do a /s install, then why not? Do that for now. Do experiments with OpenAL Soft later, and just ship it in a release when you know it will work. In addition to the installer, we currently have some issues with the reference OpenAL implementation, and it reports several errors in our audio code. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Why do we allow changing of ports on releases?
Am Sonntag, 3. Mai 2009 22:56:09 schrieb bugs buggy: Is there any valid reason why we allow the masterserver port and the gameserver port to be changed via the config file? I can understand the masterserver name, since that could change, but the ports shouldn't be able to be switched to something else IMO. If no objections, I plan to disable that for 2.2. OBJECTION! There are various valid reasons to use different hosts and ports, incl. firewalls, tunnels, forwards, private games and possibly others. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r6969 - in /trunk/data/mods/multiplay: ./ audio/ audio/coltive/ audio/multi/ audio/nexus/ audio/sfx/ audio/sfx/building/ audio/sfx/explons/ audio/sfx/vehicle/ audio
Am Montag, 4. Mai 2009 20:24:23 schrieb Per Inge Mathisen: On Mon, May 4, 2009 at 8:12 PM, Delphi jurgf...@aol.com wrote: NTW Mod Update + fix for trunk Added: trunk/data/mods/multiplay/addon.lev trunk/data/mods/multiplay/audio/ trunk/data/mods/multiplay/audio/coltive/ ... I think you just committed that to the wrong directory. And to the wrong repository... (The latter is is fixed now and does not allow any further commits.) --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7245] branches/2.2/tools/
Am Mittwoch, 29. April 2009 21:54:31 schrieb muggen...@users.sourceforge.net: Revision: 7245 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7245view=rev Author: muggenhor Date: 2009-04-29 19:54:31 + (Wed, 29 Apr 2009) Log Message: --- Lets not distribute the tools directory along with Warzone Erm... Why? I cannot remember it being so big that it would make any difference. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] New defaults for 2.2?
Am Freitag, 24. April 2009 04:20:51 schrieb Christian Ohm: On Thursday, 23 April 2009 at 20:00, Zarel wrote: By the way, when can we fix the problem of Warzone attempting to scan the entire Windows font directory on startup? It's causing start-up take as long as half an hour on some computers. I think that's fontconfig's doing. I don't know how that works on Windows, but it should be possible to use a private font directory (but then you don't have fallback fonts, and the included font(s) have to provide all needed glyphs). Try adapting fonts/fonts.conf to not scan the Windows directory. Might help already. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Neglecting trac tickets
Am Freitag, 24. April 2009 15:52:49 schrieb Christian Ohm: As for general tickets: I don't like web trackers, because the clicking needed annoys me. Now I don't suggest to get rid of trac, but would it be possible to create a mailing list for ticket action? (I think at least ticket creation was once forwarded to this list, but not anymore). So every new ticket, new comment with its attachments gets mailed to a warzone-tickets list. At least I would look at a lot more tickets that way. It is just broken and unfixed since weeks, that's all. The people in charge have no clue what's going on there (correct me if I am wrong) and no one else has time or interest to investigate. - Volunteers welcome --DevU P.S: As we are at it: Debian has its bugtracker apparently entirely handled by email. Can Trac do that, too? signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] New repository open for business
Am Mittwoch, 8. April 2009 04:42:29 schrieb bugs buggy: I guess svn+ssh:// does something different? It opens a ssh session and operates locally afterwards. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] New repository open for business
Am Dienstag, 7. April 2009 00:18:22 schrieb Per Inge Mathisen: *) You need to check out all your working copies again. I am led to understand that this has something to do with gna.org screwing with the repository UUIDs. I am very sorry for the inconvenience. Would be my fault only, not Gna's in general. Might have happened when editing the dumps. I remember having some issues with the UUIDs after reloading the repos back then. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Changing subversion hosting
Am Samstag, 4. April 2009 23:34:25 schrieb Per Inge Mathisen: On Sat, Apr 4, 2009 at 11:14 PM, Dennis Schridde devuran...@gmx.net wrote: Am Samstag, 4. April 2009 22:40:16 schrieb Per Inge Mathisen: So I would like to propose that we use sf.net for (only!) svn service, about which I have heard no complaints as regards uptime or access. Ads... Sure, but since we would only use sf.net for svn hosting, it is not like you would see a lot of them during ordinary work. We even have our own svn browser, so the only time you need to go to the (admittedly dreadful) sf.net web page is when you register your user account. Ok. You still have owner access to the old warzone2100 project? Steps which need to be done: 1. lock current svn db (can do that by removing write bits from the dirs) 2. dump it to a file and zip it up (I can do that if you tell me soon enough) 3. send that thing to SF admins and hope they are responsive enough 4. update links in wiki, forums, website, ... 5. add yours Since it seems that I will have to do a fair bit of the work, I would prefer if we could delay that for another 2 weeks for personal reasons. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Changing subversion hosting
Am Sonntag, 5. April 2009 12:12:02 schrieb Per Inge Mathisen: On Sun, Apr 5, 2009 at 11:38 AM, Dennis Schridde devuran...@gmx.net wrote: Steps which need to be done: 1. lock current svn db (can do that by removing write bits from the dirs) 2. dump it to a file and zip it up (I can do that if you tell me soon enough) 3. send that thing to SF admins and hope they are responsive enough 4. update links in wiki, forums, website, ... 5. add yours We can do an advisory lock (ie message on this list) Since it will have to last a while, I disagree that this is a good solution. (Unless you fully disable the svn repos without deleting it entirely.) and Buginator has convinced me that 2 can be done with svnsync Then you would just have to get the SF admins to run svnsync for you. As long as it works, I wont disagree. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Changing subversion hosting
Am Sonntag, 5. April 2009 12:13:05 schrieb Kreuvf: Per Inge Mathisen wrote: Any naysayers please register on the radar now. But be warned though that I have researched CB sensors that allow me to fire back the question so how do YOU propose we deal with this mess against you if you do. What about the commit-mails? SF can send them to Gna lists. signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Changing subversion hosting
Am Sonntag, 5. April 2009 12:22:05 schrieb Per Inge Mathisen: On Sun, Apr 5, 2009 at 12:13 PM, Kreuvf kre...@warzone2100.de wrote: What about the commit-mails? Either setup up a new list on sf.net, or write some post-commit script to send them to the old list. If I am to do it, I'll do the former. Shouldn't be too difficult for SF admins to make their script post to a different list. So I would prefer if the current setup could stay. Less hassle for everyone. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Changing subversion hosting
Am Samstag, 4. April 2009 22:40:16 schrieb Per Inge Mathisen: So I would like to propose that we use sf.net for (only!) svn service, about which I have heard no complaints as regards uptime or access. Ads... Any naysayers please register on the radar now. But be warned though that I have researched CB sensors that allow me to fire back the question so how do YOU propose we deal with this mess against you if you do. BerliOS? non-GNU? --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] last word before port change
Am Sonntag, 22. März 2009 06:34:55 schrieb bugs buggy: On 3/21/09, Zarel zare...@gmail.com wrote: 2009/3/21 bugs buggy buginato...@gmail.com: Any final objections? Apparently everyone wants gameserver_port to be 2100. masterserver_port is kind of irrelevant; it doesn't even need to be open on client machines. gameserver_port = 2100 masterserver_port = something other than 9997- ? 21000 ? 52677 ? (random number, 50k x 65k) Greetings, DevUrandom signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Mods considered harmful
Am Samstag, 21. März 2009 05:22:28 schrieb bugs buggy: On 3/18/09, Per Inge Mathisen per.mathi...@gmail.com wrote: So in order to get good support for user modifications, we should remove support for mods. Not sure 'remove' is the correct word, I tend to think we should make it so future mods follow the rules, and hopefully good things can come out of this, but I do think that we should get rid of the auto-load directory ASAP, and have people use the command line, for now, to add mods. At least then, when it crashes, we can tell what they were running via the crash dump, and the command line it dumps out in the dump file. You usually can see what mod they were using by looking at the searchpath (which is only dumped to stdout for --debug=something), so we should include that in the dumps. In case we cannot deliver that data in the crashdumps, maybe we want to set some TAINTED variable when a mod is loaded, so we know we are not dealing with an unmodified game. And how mods were dealt with in the GameSpy era: I think everyone had to have the exact same mod (not development version, not unpacked, etc), so that WZ could compare the checksums. Since that is already broken by linebreaks, I would still propose a simple versioning scheme. (One number, if number does not match, refuse to play.) --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
Am Donnerstag, 19. März 2009 01:59:12 schrieb Zarel: 2009/3/18 Dennis Schridde devuran...@gmx.net: Make it 10, at least. It could happen that the peer is under load, has some weird network setup which needs more time, or whatever. If the peer is _that_ under load, that peer isn't going to be able to play Warzone very well. Temporary load. I.e. if my hdds kick in at the wrong moment the system might hang for a second. Nvidia drivers were known for a bug where the system would occasionaly hang for a few. And I almost forgot, we are going with port 2100 right? I believe everyone agrees yes. Under one condition: That we never ever have to change ports again. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Mods considered harmful considered harmful
Am Donnerstag, 19. März 2009 11:13:10 schrieb Gerard Krol: Dennis Schridde wrote: Multiple mods: Morrowind and Oblivion (sorry, again...) have some mods which are rather metamods. They combine several others into one. I think it is good to limit the game to load just one mod. Like you said, if people want to run multiple mods, they will have to create a new mod for that, or devise some sort of package management system. Oh, and mods should ONLY work in vanilla (no custom scripts/tech tree mods) multiplayer and skirmish games. We DO need to add support for network games with mods however. The game needs to make sure everyone has the same mod. (by checking the md5 of the .wz?) Give each mod a version number. imo by far superior to any hashing. And we can just transfer the darn files inside the .wz archive. It is not at all necessary to introduce hacks to figure out which archive [...] Also mods should just plain be in the mods directory. By the way, does anyone else think we've got a really messed up directory structure for the data as well? Yes, but it always was like that... ;) Zarel wrote: I do think we should merge mp.wz and warzone.wz back together. +1 I think it is really annoying for people when they have finished the campaign they will have to learn an almost completely different game. And it complicates stuff for us. Glad everyone agrees. Maybe we can finally finish what I began a few years ago... Though it requires some decisions this time, as either campaign or mp will have to change on one way or the other. signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Mods considered harmful
Hi Per, hi WZ people! Am Mittwoch, 18. März 2009 22:06:03 schrieb Per Inge Mathisen: So in order to get good support for user modifications, we should remove support for mods. Interesting proposal, definitely. The first thing that becomes a problem here, is that multiplayer rules are stubbed on top of base.wz. I once tried to eliminate that and got quite far. (Lots of those changes could be merged.) What we see now is (as long as it got not worse than a few years ago), the rest, which cannot be easily merged. I am all for pushing the rest of mp.wz into base.wz and removing the (still, besides several tries of rewrites) crappy and complex (more than I would like it to be) mod loading code. We can then remove (read below) --mod, --mod_sp, --mod_mp. --datadir should gracefully be able to step in (for total conversions). Why remove? I would just hide the option, so expert users can still access it, but it is officially vanished. It might be of use later, i.e. when quickly testing before/after stuff, comparing two changesets, or something like that. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
Am Mittwoch, 18. März 2009 22:05:15 schrieb Zarel: 2009/3/18 bugs buggy buginato...@gmail.com: Well, it does that in the console via LOG_ERROR... doing that in the GUI... is not going to happen anytime soon. Oh, come on. So the user just gets kicked out, no explanation why? It _better_ go in the GUI. Ha! Ok, then 4 secs. ;) I thought Warzone's game code had 1/10 sec ticks? So the closest approximation would be 6.4 secs. Make it 10, at least. It could happen that the peer is under load, has some weird network setup which needs more time, or whatever. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Mods considered harmful
Am Mittwoch, 18. März 2009 23:58:43 schrieb Per Inge Mathisen: 2009/3/18 Dennis Schridde devuran...@gmx.net: Why remove? I would just hide the option, so expert users can still access it, but it is officially vanished. It might be of use later, i.e. when quickly testing before/after stuff, comparing two changesets, or something like that. Yes, that is what I was thinking. P.S. To confuse users, I propose naming the new old modding cl parameter -- overlay or --overlaydir, or similar. (similar to --data or --datadir, or whatever it is) Only one of those should be allowed. That will remove lots of logic handline mod stacking. So much that I think it is easier to just rip the old stuff out (init.c and main.c) and replacing it with something simple. signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Dissecting the NTW mod?
Am Samstag, 14. März 2009 10:31:38 schrieb Kreuvf: bugs buggy wrote: Also, I don't see any readme/authors file in that mod, so how can we contact the original creators of the parts that are in it? I don't see a changelog either, but I know it was updated? Delphinio has an account on my site, it's no problem for me to contact him. And afaik he has not that much experience using version control systems and is not used to the common way of doing things. I am quite sure that he will happily add the missing information once things have been explained to him. There once was quite some readme file in there... I guess it got lost in the delete-and-update session. I agree with Kreuvf that he will likely help and provide what is needed if we teach him what is necessary. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
Am Samstag, 14. März 2009 10:28:10 schrieb Kreuvf: bugs buggy wrote: Anyone have any opinions on what should be done? There comes something to my mind: If version checking is implemented in 2.1.3, it should be able to figure out that 2.1.2 (and prior) do not support a versioned network protocol. Thus it should be able to drop connections with people using that... It will be a little bit unexpected for those using 2.1.2, but if we explain this in the release notes, I think it will be less so. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
Am Samstag, 14. März 2009 13:51:33 schrieb Per Inge Mathisen: We need an official repository that everyone work up against, directly or indirectly, and unless I am mistaken, even the linux kernel has this. They used a shared repository? Do you have some docs on how they propose to deal with the merges co? --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
Am Samstag, 14. März 2009 16:53:21 schrieb bugs buggy: On 3/14/09, Dennis Schridde devuran...@gmx.net wrote: Am Samstag, 14. März 2009 10:28:10 schrieb Kreuvf: bugs buggy wrote: Anyone have any opinions on what should be done? There comes something to my mind: If version checking is implemented in 2.1.3, it should be able to figure out that 2.1.2 (and prior) do not support a versioned network protocol. Thus it should be able to drop connections with people using that... It will be a little bit unexpected for those using 2.1.2, but if we explain this in the release notes, I think it will be less so. Nope, it can't do that. 2.1.3 sends the 'version_check' message, but 2.1.2 has no idea what that messge is, and all we do is return false. No error or warning messages at all. :( The 2.1.3 client should figure out that it is talking to someone who does not understand what version_check means, shouldn't it? So the function could return a failed version check if it does not receive any answer at all. We could even signal to the user that client X does not support version_check and was thus removed from the game. Please tell me where the flaw is in that thought. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
Am Samstag, 14. März 2009 16:55:03 schrieb Per Inge Mathisen: On Sat, Mar 14, 2009 at 4:03 PM, Dennis Schridde devuran...@gmx.net wrote: Am Samstag, 14. März 2009 13:51:33 schrieb Per Inge Mathisen: We need an official repository that everyone work up against, directly or indirectly, and unless I am mistaken, even the linux kernel has this. They used a shared repository? Do you have some docs on how they propose to deal with the merges co? I am a little bit confused by this discussion. I am not aware of any lacking support in git for shared repositories. I thought that was what 'git push' was all about. It has the support, no doubt. But from my experience a shared repository creates an endless row of merge- commits, because everyone pulls, works, pulls again, merges, pushes. In a non- shared repository there would be a lot less merges, because you would pull more seldomly and only from a limited number of repositories. (It multiplicates when several people work on the same repository.) So while it is not impossible to work like that, it is more annoying. (And that is why it is not recommended either.) --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
Dump from IRC: Use a simple number (int), which we increment everytime we change the netcode in an incompatible way. Use a 2nd number in addition, which we increment if some compatible enhancement happens. (And reset when we increment the major version.) (That is in fact similar to what is done for shared objects on Linux.) Since we need to check game data and mods as well, strings seem better for that task. (Simply concat the version strings. Example: trunk:aiv:ntw) They could be seperated from the netcode version though. Proposed constants: NETCODE_VERSION_MAJOR=0, NETCODE_VERSION_MINOR=0, DATA_VERSION=2.2 (With the latter being the one used to concat mod version strings onto.) --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
Dear Git users! Am Freitag, 13. März 2009 11:16:30 schrieb Gerard Krol: Please test if cloning the repository works for you. If you like, you can clone the mainline repository on Gitorious (one click+entering a name) For those who do not immediately figure it out: http://www.gitorious.org/projects/warzone2100/repos/mainline On the right side is a button Clone repository. Finally, we need to decide what to do with the mainline repository. Devurandom has convinced me that a shared repository (with multiple people pushing to) does not work well with git. We thus need someone who regularly (at least once a week, but preferable every few days) pulls from the developers repositories, tests the result, and pushes to mainline. That way we still have an official development version. I can do this for maybe a few weeks, but I'm really not the man for the job as I could have one of my few month breaks at any time. We could rotate the job. ;) Whoever has the time is assigned to do it for a month and then it is passed to the next in the active-chain. Is someone used to the Signed-Off-By system and knows how it works? Maybe we could use that to assist QA a bit. Or get users to mark problematic revisions/repositories. (What I currently think about is, when Joe User experiences unexpected crashes in devurandom's repository, he marks it with a comment. Far from ideal and just a sketchup, but you get the idea.) What Gerard and I thought about was an even simpler system though: Let people dynamically decide where to fetch from. If they find my repository to be most stable and up-to-date (I doubt it...), they will fetch from me. If they think Per's is better, they will use his. For releases we will appoint a release maintainer, who will receive merge requests and prepare an official version. So while things based on master are pretty loose, you have one person/repository responsible for any release branch. That's exactly one place to send people to. I'd like to see your comments. --DevUrandom signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
Am Freitag, 13. März 2009 11:53:57 schrieb Elio Gubser: what should we do with the 'originals'? Er, yes... I told you that they will be lost in git-svn. Use an extra repos maybe? --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
Am Freitag, 13. März 2009 23:12:58 schrieb bugs buggy: On 3/13/09, Zarel zare...@gmail.com wrote: 2009/3/13 Stephen Swaney sswa...@centurytel.net Perhaps I'm becoming a neo-Luddite or perhaps I've been in this business too long, but I find the lack of a single shared repository disturbing. I do know a software development effort lives and dies on the basis of its source code management. The ability to branch freely is great but without a primary location for the source keeping track of who is 'it' sounds difficult. How do we keep all the package maintainers connected to what is going on? I'm betting they run build scripts to do a checkout from the 'official' repository when they go to build. I echo this. Having a single repository makes sure conflicts get resolved quickly. If we don't have that, then what do we have? Several versions of Warzone, each incompatible with each other, and no way to easily merge them? This is a good point. If we don't have a centralized repo, then I am not sure how we can 'control' (for the lack of a better word) what the distros ship out. IMO there is a little bit of misinformation here... Did someone actually read what I wrote in my last email? I never saw a distro (besides Ubuntu, but ...) ship a version directly from SVN, did you? So why would the VCS we are using make a difference here? I will repeat myself, and tell you again what the current proposals are: 1) Have a someone maintain the mainline repository on Gitorious and prepare releases from there. Or my favourite: 2) Assign a release maintainer (practically we already did that for 2.0 and 2.1), and he will fetch all the loose ends from the dev repos and for version X his repository will be what becomes the official version. 2 is my favourite, because it is the freemost variant, dead simple, not too much additional workload, we can easily shift the load around, ..., etc. If we had someone insane in the team, or someone being paid for it, 1 would probably be the first logical solution, since (s)he would devote their lifetime to the game anyway. But since we don't 2 looks a lot more promising to me. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
Hi Buggy! Am Samstag, 14. März 2009 01:30:39 schrieb bugs buggy: Sounds ok, I am just not sure how we can shift the load around, since we don't really have enough people to shift the load, and the same people end up doing it all the time, and when those people are away, then we are sorta stuck, until someone else picks up the slack. Giel was away. Per and I picked it up and released 2.1.2. Seems to work. And if we decide we are lazy and do not need QA, we can still simply merge everything that moves. But it seemed to me that it was desired to add a bit more QA, have patch reviews established and all that. It would come naturally if the primary repository was to be guarded by someone. I was told that it was not desired to have a version in VCS which does not compile or run, introduces new bugs, etc. If you make the releases (and their branches) guarded by someone who actually does QA, has the time to fetch changes from everyone every once in a while, then you get what was asked for. If you decide not to do any extra QA and just fetchmerge, then you get what you have already at not a lot of extra cost. Perhaps, doing it the 'git' way is a bit more complex to understand how to organize everything. Yes, it involves a bit getting used to. And it has a different form of organisation. It involves a little bit more communication, which is imo not a bad thing. Prevents everyone from doing their thing and just throwing it at SVN. What I expect is more review of commits, and possibly even of patches. AFAIK, we all need to make accounts with gitorious, then we do a clone to grab everything. Do we need to be assigned/attached to the project first, or can we do that after the clone? No, you do not need to signup at gitorious. All that you need is some way to make your work accessible to others. How you do it is entirely your choice. If you want to offer ssh accounts on your home machine? Fine! You have a webserver setup on your machine and it is always connected to the net? Fine! You have some spare webspace somewhere? Fine! You want to setup a git-daemon on your server? Fine! You send patches via Email? Fine! You send patches via Instant Messenger? Fine! You host your repository at GitHub? Fine! You want to host it at Gitorious? Fine! ... Once that is pulled down, we have our own copy of whatever is on gitorious, just like if we were to do a svn checkout. No, with svn you only have the last revision. Want to do svn-diff on non-head? Do it on the net! Want do switch the checked out revision? Do it on the net! Want to look at the log? Do it on the net! Want to svn-blame someone? Do it on the net! ... Needless to say this annoys me a little, especially if you are on a slow or unstable connection... Now, if we pulled down everything, do we do: git branch - lists all branches git branch 2.2 --I want to work in this one I think you want git checkout --track 2.2 here, but I am not exactly sure. git checkout 2.2 - set it to this one. Note that it is probably more like origin/2.2, which you checkout. (Or devurandom/2.2, buginator/2.2, etc.) now, how do we work with the files, since they are still in the main directory. I am not exactly sure what you are explaining here... I mean, I know how git handles it, but how do external programs handle this? Which external programs do you refer to? And which issue might they have? It looks like we must do a git clone some\new\directory, from the initial clone directory, then work in some\new\directory, and when your are done with that, you push the changes to the initial cloned stuff, and then push upstream correct? Actually I checkout whatever branch I want, work on it, maybe look at other branches (but I dont check them out), perhaps stash my changes to switch to a different branch or do some intermediate commits, maybe do some temporary commit to save my work or switch to another branch to continue my work on another day, etc. Lastly, about .gitignore. I assume we should add all the windows specific stuff to that ( *.obj, *.lib, *.exe, *.htm, *.pdb, *idb, *.ilk, *.res, *.manifest, most likely some others as well)... Feel free to add it ot a new section in that file. (But please keep it ordered and commented.) Some sidenote: Maybe you noticed it already: Even if Gitorious (or whatever is your host) suddenly goes broke, is shut of by your govn, becomes victim of a fire, or decides they dislike you: You can continue to work, commit, etc. You will have to find a different way of publishing your changes, yes. But there are enough channels of communication nowadays, that this should really be no issue. Greetings, DevU P.S. If Git does not feel like the ultimate solution to you, and you want to propose something else, I wont object against a test. I have been using Mtn for a while, which was quite good. Bzr was not bad either (it felt slow, but that was ages ago, maybe it is better now). I have been consuming Hg
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
Am Samstag, 14. März 2009 02:11:56 schrieb bugs buggy: I finally found the cause for people getting disconnected for no apparent reason (especially in longer games). I would go with releasing the fix in 2.2 and not in 2.1 then. And we finally need some version checking code to prevent such incompatibilities in the future. (But we still should not introduce incompatibilities in minor versions.) --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Effect memory pools
Am Samstag, 28. Februar 2009 20:42:00 schrieb Dennis Schridde: I played a bit with implementing a better memory pool for effects and this is what came out. Commited in r6807. --DevUrandom signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] FMV delivery and installer thingys
Am Samstag, 7. März 2009 02:35:12 schrieb bugs buggy: On 3/4/09, Kamaze fearthec...@gmail.com wrote: Also, I think there is a need to polish the windows installer a little bit. My opinion is, that we shouldn't deliver 3rd party mods with the default installer at all. (Excepting AIvolution) You know, I talked about this before, but we don't have a dedicated place to put the other mods, where people can rate them. Perhaps Zarel, or someone else can design a site specifically for mods/maps? Hosted on wz2100.net maybe? Sounds like a good idea. If someone does it... Till then I see no reason to stop shiping mods with the installer. Otherwise we might run into conflict that all people want to get their mod shipped with the installer. I think that we should outsource this into a dedicated application (something like a map/mod manager) which should be included with the game and takes care of installing, deleting and updating the installed mods and maps. This could be a stand alone application (Qt for cross platform?) or maybe integrated into the game later, when Betawidget is ready for use. Is that going to be the name for the new GUI code? 'Betawidget'? ;) Anyway, even with that code, it still is going to be a bear handling it, and of course, we need someone to write it, and last I looked, nobody has time to do anything like that. One issue is with Physfs, we have *one* write directory. And that is the config directory. That is it. It's a design choice, not a bug. There is the user directory where the application will write, and it shall not fiddle with the system installation (in a good secured system that will not be possible anyway). So what we would do is just write any user installed to the user's directory and load it from there. (Loading code is already in place since aeons, so you would just have to write code to receive a file over the net and write it with a specified name.) You could even do auto-conversions that way. Load an old mod from the system installation, convert it, push it through zlib and dump the result in the userdir. Anyway, I am all for a 3rdparty application, Warzone Starter, which does it as easy and simple as it worked for Morrowind or Oblivion (sorry to name them over and over again, but it's dead simple and still convenient). It should of course share code with Warzone, since we need the downloading-, etc code for the host-got-a-map-that-a-player-is-lacking situation as well. And automatic in-app conversion of old mods/maps/saves sounds like a good solution, too. --DevUrandom signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
