Re: [warzone2100-dev] X axis rotation direction
On Sun, Jun 19, 2011 at 12:55:35PM +, Safety0ff wrote: Basically I see two ways of proceeding, either change the existing code so that assumes anticlockwise X axis rotations, or improve / fix any documentation about the rotations. Having all the rotations anticlockwise would mean that they wouldn't require negation in the rendering code. Fixing the code to be consistent is good. One less thing to remember, one less thing to document, one less thing to get wrong. Go for it! -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone 2100 Trac] #2610: Fix map-mod support
On Sat, Apr 02, 2011 at 11:22:29PM -, Warzone 2100 Trac wrote: #2610: Fix map-mod support In short: * If you have a map-mod, it is impossible to play a skirmish game without the mod, unless you uninstall the map-mod. * If you have a map-mod, it is impossible to play a multiplayer game on a map other than the map-mod. Maps can be installed automatically by joining a game hosted with it, so simply clicking on a game in the lobby is enough to prevent you from playing all other multiplayer games unless you know how to uninstall a map. This patch fixes both these problems. Would you like to tell us how exactly? -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 402454: Disable spammy TODO.
On Mon, Jan 10, 2011 at 07:01:21AM -0800, nore...@github.com wrote: Branch: refs/heads/master Author: Cyp c...@wz2100.net Log Message: --- Disable spammy TODO. LOG_ERROR is apparently now spammed to the in-game console, making it less practical to put TODO comments in LOG_ERROR. Is putting ToDo comments in the error log really such a good idea? -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [SF-Git]Warzone 2100 Project. branch, master, updated. a31521f75eb1ec4a27d04667ab46d06488437381
On Sat, Oct 16, 2010 at 03:39:11AM +, dak180 wrote: This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project Warzone 2100 Project.. The branch, master has been updated discards 8466fddc190966dd2bd053e74fea318a75916047 (commit) ... This update discarded existing revisions and left the branch pointing at a previous point in the repository history. * -- * -- N (a31521f75eb1ec4a27d04667ab46d06488437381) \ O -- O -- O (8466fddc190966dd2bd053e74fea318a75916047) The removed revisions are not necessarilly gone - if another reference still refers to them they will stay in the repository. No new revisions were added by this update. ... Like Per, I am having trouble extracting useful information from this storm of commit msgs. However, this one seems to suggest the SF repo has just been hosed. Corrections (to me) are welcome if I am mistaken. Corrections (to the repo) are welcome if I am not. S. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.5 RC ETA in 1-2 days?
On Fri, Sep 03, 2010 at 12:33:14PM -0500, Guangcong Luo wrote: On Thu, Sep 2, 2010 at 8:45 AM, Stephen Swaney sswa...@centurytel.net wrote: Personal ego is no justification for slowing down the process. Personal ego is a serious accusation, and to equate it with a desire not to fracture the community is dangerous. We all seek to do what is best for the users, and though we may disagree on the specifics, I thought we at least understood that premise. You may disagree with whether or not it is worth delaying the releases in two platforms to ensure that all players have access to the same version and thus can easily play multiplayer with each other, but do not accuse me of ego for my belief that it is. -Zarel Look, we all know you are a drama queen who thrives on being at the center of manufactured controversy. And this is not the first time you have gone into a tailspin over imagined insults to your beloved platform. However, I am willing to concede this is not just another reflex zarelesque objection to someone else's proposal. But you are still wrong for a whole slew of reasons. Namely: Resources In an open source project, things get done when they get done. It may sound like a tautology, but it means someone has to do the work. No someone, no work. OSX development resources are a bottleneck for our project. Other than imagined slights, there is no reason to constrain ourselves based on our least-supported platform. It is worth noting that a mac user on the forums has offered to step up and do mac builds. Woo woo! More resources for our project. If we can keep from driving them away. Software development We know historically that for software in general and WZ in particular any new release has bugs. (see this morning's IRC discussion about build and research problems with the newly added AA stuff if you need an example). The sooner in the development process we find these bugs, the cheaper they are to fix. Why wait to build all of our platforms only to have to do it all over again right away? Ecology Certain organisms like 17 year cicadas and some bamboos emerge or bloom synchronously in order to overwhelm predators with more food than they can possibly eat. This simply does not apply here. The more platforms we release for, the more happy (or disgruntled!) users we have. Waiting does not buy us anything. Pragmatism How about an appeal to The Greater Good? Having some users play (and test!) our software is better than having none. Would you deny someone the pleasure and joy of Warzone merely because someone else has to wait a day or two for the same thrill? Time scale If you stand back and take a wider view, the latest WZ was released the 1st week of September. (assuming we can get someone to do OSX). Some of the packages may have been uploaded to the server before others, but that does not imply we are marginalizing a particular platform. It merely reflects our available resources. Bottom line: We gain no advantage by waiting and have something to gain by actually releasing some software. Let's hitch up the wagons and get on down the road! -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.5 RC ETA in 1-2 days?
On Thu, Sep 02, 2010 at 12:03:19AM -0500, Guangcong Luo wrote: And in case someone is entertaining the possibility, I object to the idea of releasing a Windows and Linux build before a Mac build. This is just silly, especially in light of OSX being such a minor platform. We are trying to get a release candidate build out into the community for testing. Personal ego is no justification for slowing down the process. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Release 2.3.2a or 2.3.2.1 or 2.3.3?
On Tue, Jul 27, 2010 at 02:51:44PM -0500, Guangcong Luo wrote: To be fair, it only breaks loading maps in T1 for some maps, and Rush, the map I usually test with, worked just fine. Anyway, I've fixed that too, now. Just one more example of why programmers are the worst people to test their own code. And why I tested it! is a terrible reason to allow anyone to add brand new code to a release at the last minute. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Renaming sequences.wz
On Sat, Jul 24, 2010 at 01:05:28PM -0500, Guangcong Luo wrote: It's just that videos-standard.wz and videos-lowquality.wz seemed a bit long as filenames go. Are you repeatedly typing them in by hand? Readability and meaning seem more important than brevity here. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] wzlobbybot
I quieted the wzlobbybot in #warzone2100-games the other day since it was spamming the channel with spurious game closed msgs. It would be nice if we a) could restart the bot as needed. Whether this means access to the server it is running or a command port or b) had the same code in svn that the bot is running. The svn version throws pyhon exceptions on startup, hangs and eventually crashes. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] forum content
Perhaps someone can explain this to me: http://forums.wz2100.net/viewtopic.php?f=8t=5526 After some discussion with the staff, we are locking this as a violation of rule #6 (sexual content). If something is offensive, why would we keep it around rather than deleting it? S. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Qt branch - final call
On Tue, May 25, 2010 at 12:24:12PM -0400, Gilles J. Seguin wrote: On Mon, 2010-05-24 at 10:19 +0200, Per Inge Mathisen wrote: I put the Quesoglc text renderer back in again in the Qt branch,... It would not be accepted on peer review without documentation. My point of view is a no go. Really, even not a line. Not impress by the low level of professionalism. We are rolling back to a previously undocumented state, so it is not a new state of non-documentation but the old, pre-existing one. And yes, it seems like a good thing to do. It lets us go forward, and gives the Qt boys time to work on their OpenGL support. Thumbs up. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone documentation
On Wed, May 19, 2010 at 05:57:03PM +0200, Christian Ohm wrote: First, personally I don't like hardcoded HTML tables and stuff, I'd prefer some light markup from which both HTML and PDF can be generated for maintainability. But then, who does the work decides on the tools. Having source we can generate PDF and HTML from is really the way to go. PDF does not suffer from the layout issues HTML has. -- Stephen Swaney sswa...@centurytel.net 231-271-7371 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] team colors for old models
On Fri, May 14, 2010 at 10:18:45AM +0200, Per Inge Mathisen wrote: I'm fine with the idea. Are the new PNGs much larger now? Berg added some new files for the masks and scaled up some of the tex pages he used to 512x512. Difference between new files and old files is about 4 MB. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] team colors for old models
On Thu, May 13, 2010 at 08:43:45PM -0400, buginator wrote: Anyone have any objections to this patch: http://developer.wz2100.net/ticket/1757 ? I say apply it. Team colors is the direction we are heading in. The other alternative would be a team color branch if this interfers with Per's Roadmap. -- Stephen Swaney sswa...@centurytel.net 231-271-7371 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] lobby bot
I kicked the lobby bot in #warzone2100-games since it was spamming closed game msgs again. Last time I played with the bot I noticed it was throwing python python exceptions - something about host not being an attribute of the Game class or such. Then it would hang and die. This suggests to me that the bot code in svn is NOT the same code being run as wzlobbybot. But no one who has been around lately has any idea about this. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[10762] branches/2.3/data/mods/multiplay/ntw/stats
On Sun, May 02, 2010 at 01:11:20PM +, delphi...@users.sourceforge.net wrote: Revision: 10762 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=10762view=rev Author: Delphinio Date: 2010-05-02 13:11:20 + (Sun, 02 May 2010) Log Message: --- Modified Paths: It would be nice if there were log messages for these commits. They come in quite handy when the time comes to make the Change Log. And it lets the rest of us know what is going on. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Proposed patches for tags/2.3.0
On Fri, Apr 23, 2010 at 10:51:41AM +0200, Per Inge Mathisen wrote: A release candidate should either be dropped back into beta, or stay in code freeze, which means nothing but build fixes, documentation changes or translations go in. Let's maintain some self-discipline now and ship this thing without further fixes. Then we can focus on making 2.3.1 and trunk great. Yeah, what he said. Code freeze, nothing but build fixes, doc changes or translations. I think all but one of us has had enough of the endless series of betas. It is not like this will be Last Release of WZ Ever. The sooner we do this one, the sooner we can do the next. Let's try to do it right for once, just for the novelty of it. S. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] getting user art in the game
Looking at the forums, I see we are getting some nice user art for WZ. This one, to choose just one example, has a nice sense of swarming menace and the look of an old sci-fi magazine cover http://forums.wz2100.net/viewtopic.php?f=10t=4006start=30#p53370 It would be good to get some of this art into the game, both because it simply looks cool and to increase a sense of community involvement in the project. Over in Blender land, everytime they do a new release, they have a contest to choose the new splash screen (the screen Blender displays briefly as it starts up). Three judges are appointed who then choose among the user submissions. It is quite a popular event. An idea worth stealing? -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] getting user art in the game
On Tue, Apr 20, 2010 at 11:40:42PM +0200, Per Inge Mathisen wrote: On Tue, Apr 20, 2010 at 11:36 PM, Stephen Swaney sswa...@centurytel.net wrote: An idea worth stealing? Indeed. Note that such images should not have the logo written into the image itself, as we draw it over the image anyway. Nor we need to pretend Pumpkin Studios has anything to do with this game anymore. For the Blender splash screen, they supply a template file in .xcf or .psd format so there is no question about image size. For branding, one layer has a logo and text for the release in the appropriate font. And yes, despite repeated threats and warnings, some great images get rejected for not using the template. For our purposes, all we need is a .png of the appropriate size? Cybersphinx said something on the forums: To be a bit more specific: It's a 4:3 image scaled to 1024x1024 (the game will stretch it to 4:3 again). -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Branching 2.3.1
On Wed, Apr 07, 2010 at 02:25:06PM -0500, Guangcong Luo wrote: Hey, guys. There's been a lot of drama surrounding what should and shouldn't be committed to 2.3-branch. The things we are postponing to 2.3.1 are things that deserve testing, and I believe the sooner we get them tested, the better. I think there's a simple solution we should consider: I propose we create 2.3.1-branch now. On the off-chance that you are actually serious about this and are going to take the lack of comment as agreement, No. If this is a joke, then I am, indeed, laughing. Hah! -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Ticket #1746
http://developer.wz2100.net/ticket/1746 It seemed easier to continue this discussion via the ML rather than in the comments of the ticket. = Changed 10 hours ago by Zarel Replying to stiv: We don't want to have any more betas. The fact that we are approaching 15 is simply appalling and a sign of a software development process that is out of control. NO MORE NEW FEATURES DURING THE BETA! Well, then, perhaps you guys should fix your development process, then, but I don't see what that has to do with my patch. That is exactly what we are trying to do - fix *our* development process. The reason your patch comes into it is because it adds an untested feature to an extremely brittle code base in the midst of a beta period that has gone on far, far too long. We need to stop doing this if we want to have a 2.3 release. This is why fixing the mod system is a target for 2.3.1. New features go into trunk. If we can actually get a release of 2.3 out the door, 2.3.1 can follow soon after. So you propose releasing a feature with practically no testing (I presume that's what you mean by soon after), instead of the testing I my proposal would do? You are putting words in my mouth. I can always tell when you feel your case is lost because you start creating strawmen and spurious objections. One of the principles of Open Source software development is Release early, release often. The way we do that is by controlling what goes into each release. That is what I mean by 'soon after'. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
On Sun, Apr 04, 2010 at 05:52:15PM -0700, Guangcong Luo wrote: The autoload of mods. This is still causing issues, as can be seen by trac tickets where people forget about mods that are in that directory. That was one of the main reasons why we disabled it in the first place. If we want a stable 2.3, then we should either disable that again, or someone needs to fix it. When Buginator removed the autoload feature in the 2.2 betas, I was under the impression that he would fix it and restore it. Now, a year later, I've seen nothing from him to that end. Though I haven't completely fixed the mod system, I've improved it a bit, and I was under the impression that when I committed the autoload feature, everyone agreed it was solidly into the net benefit side of the benefit/harm spectrum. It was removed because it was causing problems. I don't recall him ever declaring intent to rewrite the mod system. As for 'improving it a bit', what we have now just breaks in different and hard to find ways. Now. I propose a simple solution: 1. Fix the mod loading system. This is a great idea and a much better approach than trying to hack something together piecemeal. Since we are already wy too far into betas for 2.3, I suggest it be a goal for 2.3.1. A some requirements for a working mod loading system: Saved games need to know what mods they were running with so they can be loaded. An actual user interface to control what mods are being loaded - either an in-game interface to effectively take the place of the command line or perhaps a separate application to manage the autoload folder if we are retaining that. for multi-player, it would be ideal if the host could communicate what mods need to be loaded. At the very least, clients without the necessary mods would be rejected. In the meantime, the easiest fix is to turn off autoloading and end the problems it causes. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] More png Crushing
On Wed, Mar 24, 2010 at 01:14:59AM -0500, Guangcong Luo wrote: On Wed, Mar 24, 2010 at 1:12 AM, Per Inge Mathisen No, do not commit this. There is no reason to make life hell for people who try to bisect their way to a bug for a lousy 100kb hdd savings. Hdd is cheap, life is short. I think it would merit a one time crunch right when 2.4.0 or 3.0.0 is released, but to do it more than once seems a bit unnecessary. Nine hours work to reclaim 100kb of disk space hardly seems like a good idea ever. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone 2100 Trac] #1678: Floating point support for texture coordinates in PIEs
On Fri, Mar 12, 2010 at 01:59:45AM -, Warzone 2100 Trac wrote: #1678: Floating point support for texture coordinates in PIEs Another small step towards WZM format. Adds support for floating points in texture coordinates without integer proxy value. Proxy value was removed from texture matrix and is retained for GUI textures (where it's easier to use integer values) only. Considering the fact that all future models will use TCMask and will not use ANIDATA structure (AFAIK we don't have any useful editor for that and we will not use it except for a few animated effects) and that all current models are integer-based I suppose that we should use PIE2 integer format for all current models (double-sided polygons should be fixed with simplipie), plus this will not force people to drop PieSlicer... A quick grep thru trunk says most of the models are PIE 3 ( 597 vs 49) -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone 2100 Trac] #340: Sensors and Jammers
On Tue, Mar 09, 2010 at 09:39:27PM -, Warzone 2100 Trac wrote: #340: Sensors and Jammers Jammers add a new tactical dimension to the game. They allow units to hide from artillery, and sneaking units up on turtle bases, as the defender has to come out to 'see' and destroy the jammer(s) before the defending structures can utilize their range properly. It is also, in my opinion, extremely cool to suddenly see the vision bubble of your base suddenly start to shrink as an enemy jammer droid is approaching... All you see is a radar blip closing in on you, and you have no idea what other units it is bringing along with it... Woo woo! I got excited just reading the description. One thing this feature cries out for is airborne sensors jammers. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone 2100 Trac] #1647: Declaration / include cleanup
On Sun, Feb 28, 2010 at 06:24:23PM -, Warzone 2100 Trac wrote: #1647: Declaration / include cleanup -+-- Reporter: cybersphinx | Owner: Type: to-do| Status: new Priority: major| Milestone: unspecified Component: other|Version: svn/trunk Keywords: | Operating_system: All/Non-Specific Blockedby: | Blocking: -+-- As Cyp recently mentioned, stuff is sometimes declared in several places (and it's not always the same...). So some cleanup there could be very helpful. I've attached a patch that does some of this as example. It mainly touches declarations and includes, though it also removes some unused variables. Any objections to this kind of cleanup? Cleaning this stuff up is good. Sprinkling the code with declarations like this is an evil practice and while it is quick in the short term, eventually causes maintenance headaches. Anyone doing it now should be spanked. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] wz blender plugins
Lately, I've been updating the Blender PIE import/export plugins so they can handle PIE 3 and not choke on polys other than tris and quads. Next on the list: a function to load all the pies that make up a droid like Viper Light Cannon Wheels. Thanks to find and grep, the programmers friends, I have the various files and fields worked out to load all the pies. I still need to work out the relationship between the Connector points and the pies that attach to them. Unsure whether this is specified in the stats files or hard-coded. Any hints? -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Remove armour hit sides
There is no question that different armor values for front/side/rear hits more closely models the real world. And it would certainly add to the tactical nuances of the game. Good things, IMHO. HOWEVER: Right now the movement code makes a droid circle and expose what would be its most vulnerable sides instead of retreating backwards. Until this is changed, side values are a defect. People are arguing we can fix this and that and add some more code and all is well. No, we can't. Manpower is limited. The two biggest problem areas are the netcode and movement/orders. Better to focus our attention on refactoring those areas than make promises for future features. If you want to work on this, make a branch. This is a prime example of what branches are for. We look forward to your work. Bottom line: simple is better. Take it out. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] *If* we move to a new SVN server, then these restrictions apply
On Fri, Feb 05, 2010 at 09:33:11PM -0500, buginator wrote: = Note that this new environment has the following up-front limitations: * No integration with the trac hosted app * No stats tracking -- changes that occur while this is in test stage may not ever get reflected in the site stats. * Links on the site won't reference the instance (though the permissions in the project admin pages are still applied) * Hooks configured via the site admin interface will not be applied to this test instance (you can manually configure them via the direct shell access) * Developer access will be via svn+ssh:// protocol * Anonymous access will be via svn:// protocol * URLs and file paths will be different * Multiple repositories per project will be supported * Direct repository access will be provided via the shell service (adminrepo will not be needed) * The web interface is WebSVN The lack of Trac integration would seem to be a stumbling block. The configurations issues are an annoyance - at least for the administrator. The rest is not a problem. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] *If* we move to a new SVN server, then these restrictions apply
On Thu, Feb 11, 2010 at 11:03:44PM -0500, dak180 wrote: We do not actually use the hosted trac on SF. Good point! I am more concerned about svn+ssh, looking at the svn manual they do not recommend using it. For full encryption they recommend svnserve with SASL encryption instead. http://svnbook.red-bean.com/nightly/en/svn.serverconfig.choosing.html#svn.serverconfig.choosing.recommendations I interpret that as svn+ssh is not the prefered solution for encrypted communications, which is not the same as recomending against using it. Do we really care that much about encryption? -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Want to commit gates to trunk
On Thu, Feb 04, 2010 at 04:47:40PM +0100, Per Inge Mathisen wrote: I would like to commit my support code for gates to trunk, so that artists can start working on models, and others can give feedback on behaviour. I only intend to commit the source changes, which are quite specific to that structure, so should not have any impact on any other code. See http://developer.wz2100.net/ticket/1179 for more information. Let me know if there are any objections. I played with the earlier patch some and thought it was pretty cool. No objections here. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Mod List Patch
I notice on the forums, there is a request for a command line switch to turn autoload off. Obviously a necessary and desirable feature, but now we are back to command line switches again. (renaming the autoload dir is a workaround, but lame) A cross-platform WZ launcher sounds like the real solution to the problem. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] About tagging Beta 7
On Sat, Jan 09, 2010 at 05:13:13PM +0100, Christian Ohm wrote: On Friday, 8 January 2010 at 0:03, Per Inge Mathisen wrote: I think we should try to push out a beta7 in the weekend, So, regarding the earlier discussion, I'd like to tag beta7 in ~6 hours, and release 24 hours after that. Tagging coud be done a bit later, release not really (if I do tarballs and Windows installer). Any objections? Go for it! -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Beta 7
On Fri, Jan 08, 2010 at 03:59:17AM -0600, Guangcong Luo wrote: On Fri, Jan 8, 2010 at 3:48 AM, Per Inge Mathisen per.mathi...@gmail.com wrote: Easy mod support is not that important. There may be vocal forum users that want it, but they are rarely a good representative sample of our users. In my experience, the overwhelming majority of users will never touch a mod and just play the core game. Forum activity has gone down significantly, and I miss many formerly active members. I can think of at least 3 people who have stopped participating in the last couple months due to what they perceived as hostility on the forums. No mention of autoloading. Good mod support is key to an active community, and I fear our current mod loading situation may have something to do with it. I would not have released Rebalance Mod and eventually become a developer if not for the ease of autoload folders. Mod support is a nice thing to have, but a working game that does not crash is even more important. It should be embarrassing that we are up to Beta 7. The techniques for producing working software are not rocket science. All it requires is a little bit of process and some personal discipline. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Beta 7
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. Well, other than my mod loading patch, which I am planning on modifying and committing, I'm fine with that: http://developer.wz2100.net/ticket/688 This should not be committed to 2.3 for the reasons given above. Also, you will need to do something more clever than simply using the mod name in order to make sure the mods are actually the same thing. Congrats on writing an actual description of the patch, btw. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Beta 7
On Thu, Jan 07, 2010 at 06:32:29PM -0600, Guangcong Luo wrote: 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. You are missing the point. Do it in trunk. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Trac categories
On Tue, Jan 05, 2010 at 05:10:26PM +0100, Christian Ohm wrote: Since we use trac tickets mostly for bugs, should we remove the enhancement and task categories? Or can we limit those to devs only? I was just thinking about this while looking at the latest tickets. Maybe 'enhancement' could be changed to 'patch' to keep it from being mistaken for a feature request. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Trac categories
On Tue, Jan 05, 2010 at 03:42:30PM -0600, Guangcong Luo wrote: I'd say it's the guidelines that need to be changed. I mean, seriously, rooting out bugs is what betas are for. ;) And the bug tracker is for bug reports. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Splitting out original campaign
Per makes a strong case, especially given the long term plan for moving to lua scripting, the continuing divergence between campaign and skirmish and the difficulty of testing the campaign. I think it is worth doing. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[8863] branches/2.3/src
On Wed, Dec 30, 2009 at 02:11:18PM -0600, Guangcong Luo wrote: On Wed, Dec 30, 2009 at 6:20 AM, Per Inge Mathisen per.mathi...@gmail.com wrote: On Wed, Dec 30, 2009 at 6:07 AM, zare...@users.sourceforge.net wrote: 2.3: Make VTOLs finish patrolling/scouting before returning to rearm. Perhaps try to compile your commits before you do them? I use Mac OS X and Windows. On Mac OS X and Windows, we do not compile with -Werror by default, and we can't since our libraries (and Xcode's 10.4 SDK itself; Apple doesn't support old versions of their OS very well) generate warnings. So most of my commits have been tested and compile just fine on my machine, and the number of warnings vary depending on the conditions in which builds are compiles, so it can be difficult to tell if my changes add warnings. If you have any advice along those lines, I'd be willing to listen, of course. Some suggestions: Compilers have facilities to turn warnings on and off. Except for the times when your code is actually broken, most of the problems seem to be warnings like unused variables. You can add specific warning flags if the defaults are not displaying them. Your compiler docs are your friend here. Grep thru the compiler output to filter out noise. Use a chain of filters to reduce noise and/or look for specific warnings. If the above are too difficult, you could submit patches and let others test them for you. Or perhaps, simply not commit stuff after 2300 local time. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[8594] trunk/data/base/images/frontend4.png
On Sat, Dec 05, 2009 at 02:06:29AM -0600, Zarel wrote: Are there any other concerns you have about the text? If you do have further valid concerns, I'd still be happy to remove the text, it's just that I currently no longer see any reason to do so. The fact that the text is almost unreadable? It may look OK on your 800x600 screen but on a hi-res monitor it is mouse print. You might want to read the forum thread again and think about the word 'Go'. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[8594] trunk/data/base/images/frontend4.png
On Fri, Dec 04, 2009 at 02:30:58PM -0600, Zarel wrote: On Fri, Dec 4, 2009 at 2:22 PM, Kreuvf kre...@warzone2100.de wrote: zare...@users.sourceforge.net wrote: Revision: 8594 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=8594view=rev Author: zarelsl Better ready? checkbox. It's only better if you know enough English to understand READY?. If not, you are more screwed than before IMHO. :( At worst, you're just as screwed as before, and you have to consider that most people, even if they don't speak English, should know Ready? if they play games online. It is inconsistent with the rest of the interface. If you are going to put a word there, it should be a translatable string. Note that the button already has a tooltip which is translated. Also it does not look that good. The text is very small. Thumbs down. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[8594] trunk/data/base/images/frontend4.png
On Fri, Dec 04, 2009 at 05:21:40PM -0600, Zarel wrote: On Fri, Dec 4, 2009 at 4:28 PM, Dennis Schridde devuran...@gmx.net wrote: 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. Are you arguing that there is not a single user who understands what Ready? means, not even English speakers? Otherwise, it is a valid assumption, since it helps comprehension for at least a portion of the userbase, and leaves the rest of the userbase no worse off. This is totally beside the point. Your love of argument is showing. On Fri, Dec 4, 2009 at 4:04 PM, Stephen Swaney sswa...@centurytel.net wrote: It is inconsistent with the rest of the interface. If you are going to put a word there, it should be a translatable string. Note that the button already has a tooltip which is translated. Also it does not look that good. The text is very small. Once we get a readable font at that size/resolution (and I'm planning on eventually making one), I'll make it a translatable string. Until then, this is better than nothing. Especially if it already has a tooltip that can be translated - whoever can't understand the word Ready? can read the tooltip. While I agree with your implicit argument that people should speak English like everyone else, the button does not look better than it did before. 'Better than nothing' might be a valid argument if there *was* nothing there before, but we *did* have a usable button with a (translated) tooltip. This is simply not better. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[8584] trunk/lib/ivis_common/tex.h
On Mon, Nov 30, 2009 at 01:42:44AM +, zare...@users.sourceforge.net wrote:
Revision: 8584
http://warzone2100.svn.sourceforge.net/warzone2100/?rev=8584view=rev
Author: zarelsl
Date: 2009-11-30 01:42:38 + (Mon, 30 Nov 2009)
Log Message:
---
Fix a bug where a long was dereferenced from an int pointer.
Modified Paths:
--
trunk/lib/ivis_common/tex.h
I'm curious what bug this was meant to fix.
The changeset diff looks like this:
--- lib/ivis_common/tex.h (revision 8583)
+++ lib/ivis_common/tex.h (revision 8584)
@@ -37,7 +37,7 @@
typedef struct
{
char name[iV_TEXNAME_MAX];
- unsigned int id;
+ unsigned long id;
} iTexPage;
I suspect that id member should be a GLuint. It seems to be used that
way in the code and this would get around all those problems Zarel had
trying to coerce some platform specific type into a GLuint.
If not, we probably have some deep issues here with word size since that
unsigned long is going to be 64 bits on some platforms and 32 bits on others.
--
Stephen Swaney
sswa...@centurytel.net
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[8584] trunk/lib/ivis_common/tex.h
On Fri, Dec 04, 2009 at 07:05:54PM -0500, Steve wrote: I suspect that id member should be a GLuint. It seems to be used that way in the code and this would get around all those problems Zarel had trying to coerce some platform specific type into a GLuint. A patch. http://developer.wz2100.net/ticket/1148 -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[8154] branches/2.2/src/action.c
On Sat, Sep 19, 2009 at 12:28:53AM +0400, i-NoD wrote: Stephen Swaney wrote: Is this just a random small change in actionUpdateDroid() or does it affect something specific? It's a small simplification, nothing serious. The whole DACTION_MOVEFIRE case is a one big mess IMO. Sorry for not being more clear. It was a comment on the uselessness of the commit message rather than what was commited. We know it was a change. The commit msg should provide a brief description of what was done. Think of the poor person doing the Change Log! Having meaningful commit messages also helps to track down problems, like commanders currently being broken in trunk, for instance. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[8154] branches/2.2/src/action.c
On Wed, Sep 16, 2009 at 06:22:53PM +, i-...@users.sourceforge.net wrote: Revision: 8154 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=8154view=rev Author: i-nod Date: 2009-09-16 18:22:52 + (Wed, 16 Sep 2009) Log Message: --- 2.2: Additional check for NULL target in actionTargetTurret (#933), plus a small change in actionUpdateDroid (multi weapons targeting code). Is this just a random small change in actionUpdateDroid() or does it affect something specific? -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone-dev] Changelog changes?
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. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] SF svn repo upgrade to 1.6.4?
On 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! -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Making trac friendlier?
On Fri, Aug 21, 2009 at 06:29:03PM -0400, bugs buggy wrote: ... Mainly, the issue is, if a user has some kind of feature request, then what should be done with it? If we close it as invalid, that could be conscrewed as us telling them to bugger off... If we don't close it, then it clogs up the pipeline so to speak. The same with other tickets that are more or less useless. We tried to fix some problems with the need info resolution, and that is what I mostly use, but, trac still says Closed, which can confuse some people. 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. One way is simply to have a separate tracker for feature requests. However, as cybersphinx points out in IRC, having everything in one database has certain advantages. If we had a separate 'feature request' type, it would solve that problem. Closing bugs that are in the 'need more info' state is misleading. Need info is *not* a resolution but a pending state or status. Can we create a Status of 'need more info' to go along with our accepted, assigned, closed, new and reopened values? -- Stephen Swaney sswa...@centurytel.net 231-271-7371 ___ 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/exceptionhandler/exceptionhandler. c
On Fri, Aug 14, 2009 at 05:03:18PM +0200, Dennis Schridde wrote: Am Freitag, 14. August 2009 15:02:00 schrieb Christian Ohm: On Friday, 14 August 2009 at 11:52, the_cybersph...@users.sourceforge.net wrote: Revision: 7968 Was broken in r7850 (#716). I reverted r7850 and then fixed the -Wdeclaration-after-statement warnings instead of poking around trying to find the problem. The question is, why do we need to be C90 compliant in unix-only code at all? No clue, but I support that question. To my knowledge you cannot compile the unix crashdump code with bad compilers The problem, as stated in #716 was Running default ./configure gives a bunch of mixed declaration code errors in exceptionhandler.c. gcc 4.3.2 openSUSE linux 11.2 Gcc 4.3.2 hardly fits the 'bad compiler' label, IMHO. (feel free to add your own snarky remarks) It *is* more strict than previous versions. In response to Christian's did you test it?, the answer is apparently, not enough. Zarel is excused because he is a Windozer. Glancing at the code again with fresh eyes and knowlege that something is broken, it looks like the crashdump filename creation got b0rked - a couple of lines and easy to fix. As for The question is, why do we need to be C90 compliant in unix-only code at all? Good question. You tell me. In any case, you should be able to compile WZ on a mainstream linux platform with the default settings. -- Stephen Swaney sswa...@centurytel.net ___ 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/exceptionhandler/exceptionhandler. c
On Fri, Aug 14, 2009 at 10:05:41PM +0200, Christian Ohm wrote: On Friday, 14 August 2009 at 15:46, Stephen Swaney wrote: gcc -std=gnu99 ... -O0 -g -Wall -Werror -Wno-unused-label -Wno-pointer-to-int-cast -Wmissing-field-initializers -Wcast-align -Wwrite-strings -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wno-format-security -Wdeclaration-after-statement ... The -Wdeclaration-after-statement and -Werror seem to be the significant parts for this discussion. I suspect the They are. The question is, where does -Wdeclaration-after-statement come from? It's not in the repo, says git grep. Don't know where it comes from. My first thought was it maybe it gets turned on by -Wall, but browsing the gcc docs says no. I had been compiling trunk with --enable-debug=relaxed, but someone on IRC with another linux distro complained about being unable to build with the default ./configure, something that should be possible, so I looked into the problem and here we are! Personally, I like being able to sprinkle declarations around near where they are needed ala C++/C99. If we drop support for MSVC this all goes away! -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Project Status?
On Sun, Jul 26, 2009 at 01:59:31PM -0500, Zarel wrote: On Sun, Jul 26, 2009 at 12:53 PM, Christian Ohmchr@gmx.net wrote: I object. Let me put untested stuff in and tag immediately afterwards doesn't exactly sound like good quality-control. It'd actually be rather well-tested, overall. I mean, I've been testing it myself, and the code logic is simple enough that it's doubtful anything would break. Has it been tested by anyone besides yourself? Not directed at you personally, but the standard excuse for commiting broken code is But I tested it myself!. It ought to be the punch line of a joke. Programmers are the worst people to test their own code. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] es translation
On Sun, Jul 12, 2009 at 02:20:00PM +0200, Dennis Schridde wrote: 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. Putting patches in the tracker helps keep them from getting lost or overlooked. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] List of things that are being removed for the 2.2 release
On Wed, May 27, 2009 at 09:56:40PM -0400, bugs buggy wrote: Does this sound good to everyone? It all works for me. Any thoughts on what could be used for the external music player? -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Savegame incompatibility rc1-rc2
On 5/27/09, Per Inge Mathisen per.mathi...@gmail.com wrote: Due to a small change in scripts that change the behaviour that the AI copied whatever truck the human player had, skirmish savegames (only) are incompatible between rc1 and upcoming rc2. Should we revert the change or let it be? Breaking the savegame format in the middle of RC* is ungood, especially since this appears to be a minor issue. Given the upcoming Lua integration with the changes and possibilities that brings, it is better to wait and break things all at once. At that time, we can add fixes and features like version identifiers. Better to revert for now. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Handling GIGO (Garbage in, Garbage out)
On Fri, May 22, 2009 at 02:25:33PM +0200, Christian Ohm wrote: Equally obvious should be that slow but working is better than fast but crashing. Performance can later be achieved by profiling and optimizing the bottlenecks. As I recently added to ticket #225, I did an oprofile run on Warzone, and OpenAL topped the list at 40% CPU time. Interesting. Was this with Creative's OpenAL or OpenAL-soft? -- Stephen Swaney sswa...@centurytel.net ___ 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
On Sun, May 10, 2009 at 09:43:43AM -0500, Zarel wrote: Let's just release 2.1.4. Seriously, I've never heard of dropping support for the current release branch just because you want everyone else playing the development branch, no matter how close the development branch is to release (and, again, I don't consider three weeks if we're lucky and nothing goes wrong to be close). Ah, the impatience of youth! What fraction of our development cycle is 3 weeks? If you are going to release another 2.1, do it. Just don't do it at the same time as 2.2 RC1. It's bad marketing. It dilutes both the impact and user testing of the RC release. -- Stephen Swaney sswa...@centurytel.net ___ 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
On Thu, May 07, 2009 at 11:30:47PM -0500, Zarel wrote: By the way, guys, is it okay if we release 2.1.4 concurrently with 2.2 RC1? Buggy and stiv seem to be very against the idea, Cybersphinx sounds neutral, Per sounds for it. [16:28] per it is hardly effortless [16:28] per and when looking more closely at the bugs fixed since 2.1.3, i'm not so sure anymore Here's why I think releasing 2.1.4 is a good idea: - As mentioned earlier in the 2.2 RC1 thread, it's not as stable as 2.1 yet. Compile 2.2 RC1 with the asserts off. That seemed to be the issue, judging from the IRC conversation. - 2.1.4 has one of the most requested bugfixes - namely, how the interface hides itself whenever someone changes color/team/position/etc in multiplayer game staging I concede to your claim that this is the most important bugfix in the history of software development, but isn't it also in 2.2? - We're not going to be releasing a 2.2 stable for at least another three weeks - people should get an interim stable release. 3 Weeks - that's like 21 days? - It theoretically shouldn't be more work than just making a release. I mean, it sounds like we're dropping support for 2.1 either way. Aren't we? And if we are, why not get on with 2.2? I can handle most of the work - I just need people to compile and upload source tarballs, Windows binaries, and Mac binaries. Giel? EvilGuru? If we do it at the same time as 2.2 RC2, it shouldn't be too much more work, right? Actually, releasing two versions should be approximately twice as much work. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
On Fri, Mar 13, 2009 at 12:01:19PM +0100, Per Inge Mathisen wrote: Let's all test the new git repositories a bit before moving the official repository to it. Personally I am scared by things like this: On Fri, Mar 13, 2009 at 11:49 AM, Dennis Schridde devuran...@gmx.net wrote: Devurandom has convinced me that a shared repository (with multiple people pushing to) does not work well with git. So let's not rush wildly into the unknown, even if Buginator is hurting and git looks like the next coming of revision control right now... ;-) 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. Color me not totally convinced. S. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] FMV delivery and installer thingys
On Thu, Mar 05, 2009 at 09:19:05AM +0100, Per Inge Mathisen wrote: I have nothing much to add to the general discussion, except that I think we should look for people who can make distro-specific packages that we put on our web page. I can make them for the latest Fedora version, for example. WZ version 2.1.1 is available for openSUSE via the openSUSE Build Server Game repository. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
