Re: [warzone2100-dev] Textures done, planning on a 'testing' build this weekend
On Fri, Oct 15, 2010 at 06:56:32PM +0200, Per Inge Mathisen wrote: I'm a bit out of the loop, I guess, on the git stuff. Are we now all using gitorious, or are some people still hanging out at sf.net? If gitorious is so horrible, perhaps we should try github? I use that for another project at work with rather large data files, and it seems snappy. I believe GitHub used to have a space limit, I don't think they've got one right now, though. In fact their website claims they don't have any hard storage limits, instead they're using soft limits. Depending on what they mean with soft limits I think using GitHub (instead of gitorious) is probably a good idea. So unless there are some other reasons to prefer GitHub above Gitorious which I'm unaware of I think moving to GitHub might be a good idea. -- Giel -- A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. -- Bill Bryson signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] git - gitorious - SF
On Fri, Oct 08, 2010 at 00:42:27 -0400, buginator wrote: Trying to upload to gitorious, I did: git status # On branch pre-3.0 # Your branch is ahead of 'origin/2.3' by 70 commits. git push... 'Everything up-to-date' This will create a new remote branch 'pre-3.0' and push your changes to them: $ git push origin pre-3.0 The reason that plain 'git push' didn't work is because you were trying to push a local branch that has no remote equivalent. -- Giel -- I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. -- Bjarne Stroustrup signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] A quick question about the project.
On Tue, Sep 28, 2010 at 11:17:27PM -0400, buginator wrote: On 9/28/10, Per Inge Mathisen wrote: On Tue, Sep 28, 2010 at 5:25 AM, buginator wrote: On 9/27/10, buginator wrote: It was said that it would be a good idea to get a CVE. http://cve.mitre.org/cve/obtain_id.html Anyone care to chime in on this one way or the other ? Since I was just a tad bit too terse... the reason for this is: So we can have some co-ordination with the security team of all the distros who are distributing wz. See their FAQ entry: http://cve.mitre.org/about/faqs.html#a4 I am confused. You have a security issue you are going to need to go public with? It would be for the buffer overflow issues that we fixed, though we didn't do this in the past, it is just a 'nicer'(?) way to handle these type of things. Sounds like overkill and a bureaucratic variant of featuritis to me. Please note that not every buffer overflow is a potential security risk, most buffer overflows only cause DoS (in the form of a segfault). Only when a *remote* user can inject code *and* cause it to be executed would I consider a buffer overflow to be a security risk. I.e. local privilege escalation can be disregarded as Warzone's purpose is *not* to sandbox local users. So if you've found a potential remote privilege escalation (i.e. somehow includes remote data in the execution stream) bug feel free to apply for a CVE then. And if I read that FAQ correctly there's no need to apply for some organisation or project-specific entry either. Thus you're only required to apply for *anything* with them when you have a security issue to begin with. -- Giel -- When all you have is a hammer, everything starts to look like a nail. -- Abraham Maslow signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] adding a linear algebra library
Hi all, I would like to propse to add a linear algebra library as a dependency to Warzone. One library I have in mind (and have had good experience with in the past) is Eigen [1]. Having a linear algebra library will eventually be required to be able to reimplement OpenGL's matrix math (which is ditched from the OpenGL 3.0 and ES 2.0 APIs). Additionally it will allow the easy and proper implementation of piematrix expressed in terms of this library's functionality. As for Eigen, it is a C++ header-only (completely template based) library. It's predefined vector types have the same names as our self-defined vector types and have the same memory layout on most systems (compiler-dependent of-course), this would allow (by means of type-punning), using those types in C++ with all added functionality, while retaining what we have in C. [1] http://eigen.tuxfamily.org/ -- Giel -- When all you have is a hammer, everything starts to look like a nail. -- Abraham Maslow signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11676] trunk/data/base/shaders/tcmask.vert
On Fri, Sep 17, 2010 at 22:38:54 -0400, buginator wrote: On 9/17/10, muggen...@users.sourceforge.net wrote: Revision: 11676 vertex shader: don't use deprecated ftransform() error |10:33:24: [loadShaders] Vertex shader compilation has failed [shaders/tcmask.vert] error |10:33:24: [printShaderInfoLog] Shader info log: 0(7) : error C: syntax error, unexpected ';' at token ; 0(7) : error C0501: type name expected at token ; 0(7) : warning C7022: unrecognized profile specifier gl_Position 0(7) : warning C7022: unrecognized profile specifier invariant info|10:33:24: [screenInitialise] Can't use shaders, switching back to fixed pipeline. This is with latest Nvidia (windows) drivers. What happens when you remove the invariant gl_Position; specification? Also do you know which version of GLSL your drivers are using? I'm guessing an #if __VERSION__, may be required. (ftransform() is deprecated in GLSL 1.30 and OpenGL ES's GLSL version simply doesn't implement it). -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11676] trunk/data/base/shaders/tcmask.vert
On Sat, Sep 18, 2010 at 11:44:28AM -0400, Safety0ff wrote: On 10-09-18 11:32 AM, Giel van Schijndel wrote: What happens when you remove the invariant gl_Position; specification? Also do you know which version of GLSL your drivers are using? I'm guessing an #if __VERSION__, may be required. (ftransform() is deprecated in GLSL 1.30 and OpenGL ES's GLSL version simply doesn't implement it). I had the same issue, adding #version 120 in the vertex shader seems to have fixed it for me, using 120 results in: 0(15) : warning C7533: global variable gl_Color is deprecated after version 120 0(18) : warning C7533: global variable gl_TexCoord is deprecated after version 120 0(18) : warning C7533: global variable gl_TextureMatrix is deprecated after version 120 0(18) : warning C7533: global variable gl_MultiTexCoord0 is deprecated after version 120 0(21) : warning C7533: global variable gl_ModelViewProjectionMatrix is deprecated after version 120 0(21) : warning C7533: global variable gl_Vertex is deprecated after version 120 Aye, those variables are part of the fixed function pipeline. GLSL versions after 120 (130, etc.) are intended for OpenGL ES 2.0 and OpenGL 3.0 which rip out the fixed function pipeline. From these versions and upwards global data (the matrices) should be passed as uniforms, while per-vertex data (including the vertex coordinate vector itself, gl_Vertex) should be passed as vertex-attribute data. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] require GLSL = 1.20
On Sat, Sep 18, 2010 at 11:44:28AM -0400, Safety0ff wrote: On 10-09-18 11:32 AM, Giel van Schijndel wrote: What happens when you remove the invariant gl_Position; specification? Also do you know which version of GLSL your drivers are using? I'm guessing an #if __VERSION__, may be required. (ftransform() is deprecated in GLSL 1.30 and OpenGL ES's GLSL version simply doesn't implement it). I had the same issue, adding #version 120 in the vertex shader seems to have fixed it for me, Right, after testing this on my laptop I discovered that even though my Intel driver claims to support GLSL 1.20, it doesn't. I.e. even treats a '#version' directive other than '#version 110' as a preprocessing error. So I think we should just require GLSL = 1.20 (add '#version 120' as the first line of shaders) and use the fixed pipeline (when available) for systems (like my laptop) that fail to compile the shader. For reference: * My laptop (Lenovo Thinkpad T500) claims GLSL 1.20 but appears to only support GLSL 1.10 * My desktop (GeForce GTX 260) claims GLSL 1.50 and at least supports the '#version 150' directive -- Giel -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.5 (final) release plan
On Thu, Sep 16, 2010 at 08:48:19PM -0400, buginator wrote: On 9/16/10, Giel van Schijndel wrote: On Wed, Sep 15, 2010 at 10:06:51PM -0400, buginator wrote: with novideo.ogg file (which has been in all the release candidates.) The files are pretty small anyway, and they won't add that much more to the final build. How small? Please give a number. It would be these. brfcom.ogg (the green spinning thing) res_com.ogg (intel) res_droid.ogg (intel) res_pow.ogg (intel) res_struttech.ogg (intel) res_systech.ogg (intel) res_weapons.ogg (intel) victory.ogg (when you win a mission / MP) end.ogg (when you suck, and die in either SP/MP) = 5.17 MB Total. (these are the std quality ones) I think it is well worth it, and makes Warzone have a better player experience than doing noVideo for everything. Looks good to me, you've got my vote. For what its worth, considering this ain't a democracy (rather a consensus-based community). -- Giel -- If debugging is the process of removing software bugs, then programming must be the process of putting them in. -- Edsger Dijkstra signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11671] trunk/lib/ivis_common/tex.h
On Thu, Sep 16, 2010 at 09:51:38AM +0200, Per Inge Mathisen wrote: On Wed, Sep 15, 2010 at 9:08 PM, muggen...@users.sourceforge.net wrote: Log Message: --- Replace #ifdef(APPLE) #include $path/gl.h sections with SDL_opengl.h which handles this already Please do not mess around too much with SDL related stuff, if you do not strictly need to, since it breaks Qt branch. Right, understood. The reason for that ^^ change was to get rid of the #ifdef APPLE-stuff when including gl.h and glu.h. This is already dealt with by SDL_opengl.h, thus my reason for using that header. Considering that most places we use SDL_opengl.h we only use it to properly include gl.h and glu.h we could probably take that part from SDL_opengl.h (which is independent of SDL) and move that into a wrapper header in lib/framework/ or lib/ivis_opengl/. That would additionally make porting to GLESv2 (OpenGL ES 2.0) slightly easier by requiring the addition of preprocessor conditionals to only that header. How would you feel about that approach? I'm reasonably sure it will even reduce the Qt branch's breakability with respect to the GL/SDL combination. -- Giel -- There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11570] branches/2.3/data
On Wed, Sep 15, 2010 at 03:17:17 -0500, Guangcong Luo wrote: On Wed, Sep 15, 2010 at 3:04 AM, Per Inge Mathisen wrote: On Thu, Sep 2, 2010 at 6:36 AM, Zarel wrote: Log Message: --- 2.3: Rebalance 0.8.1: - Removed Cyclone turret Did you check that Cyclone is never referenced by the AI(s)? I can't check right now (or for a few days, probably). My summaries are user-facing summaries, telling them they can no longer use Cyclones. I'd suggest changing the log message to reflact that fact: e.g. make research item X user inaccessible or something to that effect. -- Giel -- Computer Science is no more about computers than astronomy is about telescopes. -- Edsger Dijkstra signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11668] branches/2.3/lib/widget/editbox.c
On Mon, Sep 13, 2010 at 11:53:06PM +, bugina...@users.sourceforge.net wrote: Revision: 11668 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=11668view=rev Author: buginator Date: 2010-09-13 23:53:06 + (Mon, 13 Sep 2010) Log Message: --- Fix edit boxes so they correctly calculate the string's pixel borders. Motivation of this patch was because of some whiny guy on IRC. ;) Not to be whiny but, you didn't give the motivation of that patch there, only a vague reference to the source of that motivation. So please include the motivation (which you already did: fix X so it correctly does Y) or at the very least an *exact* source reference (e.g. IRC channel + timestamp of message). Yours whiningly, ;-) -- Giel -- It would seem that perfection is attained not when no more can be added, but when no more can be removed. -- Antoine de Saint Exupéry signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] OpenGL ES (2.0)
On Tue, Sep 14, 2010 at 12:30:48 -0400, buginator wrote: On 9/13/10, Giel van Schijndel wrote: This however, would require significant changes to the drawing code. Keep in mind that these changes would be required for *pure* OpenGL 3.0 as well, with pure meaning without the backward compatibility extensions. The two most significant changes are: * immediate-mode drawing would have to go (glBegin()/glEnd()), replacing it with either VAs or VBOs I am fine with this. - in OpenGL ES the matrix stacks don't exist anymore, so we would have to maintain this stack outside of the OpenGL API (relatively easy to do) This is also needed for proper support of LoD, occlusion culling, and some other things. I am also fine with this. - fixed pipeline rendering is mostly gone, so a shader performing the vertex transformation (multiplication with model-view and projection matrices) would have to be used. The only real concern I have is driver support, on all the platforms we support. Right, this is largely due to the complete removal of all matrix-related functions from the API. The only API function still handling matrices is glUniform. Thus the only way of getting matrix multiplication in OpenGL ES 2.0 is by means of reimplementing that part of the fixed function pipeline in GLSL. If done properly this shader probably wouldn't be required on systems that still have the fixed function pipeline. Please give me your thoughts on making these changes. Personally I don't think removing of immediate-mode rendering is a very big deal, nor is replacing gl(Push|Pop)Matrix with our own implementation. Completely shedding our dependence on the fixed rendering pipeline is something of an entirely different scale though. A rewrite of the gfx engine is need, since most of it is still done with the brute force approach. Getting rid of the fixed pipeline was on my long term TODO list anyway. :) Would this be done directly in trunk, or would a new branch be made for this ? Since I see you started working on the 'easier' stuff, did you have a timeframe when all this would be done ? Definitely trunk since I expect that most (hopefully all) changes can be done incrementally, and thus without disturbing trunk too much. As for a time frame, I haven't thought about that yet, my intention was just to code till completion. PS OpenGL ES 1.1 *does* support the fixed function pipeline but has no support for the programmable pipeline, so is IMO not a good option at all. -- Giel -- There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. -- Leon Bambrick signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] How to handle 2.3?
On Tue, Sep 14, 2010 at 12:56:53AM -0400, buginator wrote: On 9/13/10, Christian Ohm wrote: So how long would this bugfix 2.3 live? Until 2.5 is done, and then 2.4 is fixes only? By what criteria will the jump to 2.5 happen? I am not really sure what the new criteria will be required for a major version bump. Is it netcode ? Gfx ? Lobby code ? Other ? Dunno. Might I suggest a blasphemous approach? Only *officially* maintaining a single 2.X branch at a time, i.e. as soon as 2.4 is released support for 2.3 is dropped. I explicitly emphasised officially there to allow for the case that we have a very simple bugfix which someone is willing to backport. How about doing 2.3.5.x releases for bugfixes only instead? So for example we (finally) branch 2.3.5 now (and immediately push CorvusCorax's projectile fixes in 2.3 for 2.3.6), tag (hopefully no more) RCs from it, the release, and the 2.3.5.x fixes. I can live with this. I don't think we have enough manpower to maintain two release branches. (Well, and there's the question of how well the bugfix only thing will work out, I remember both the 2.2 and 2.3 jumps, and though both times there was some interest in keeping the old line alive in parallel for a while, in the end only the new version was released.) This is true as well, and since we always lack the manpower to do the upkeep that is required, it is possible the same thing will happen with the purposed 2.3.5.x branch. We are going to end up with 3 testing versions, one for trunk (new features + bug fixes), one for 2.X (new features + bug fixes), and one for 2.3.5.x (bug fixes). It might not always be possible to just do testing in 2.X, since the new feature might skew the results. Another radical suggestion: reducing 2.X branches to feature-frozen branches, i.e. the only time to add new features would be when creating a new 2.X branch. -- Giel -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. -- Rich Cook signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] How to handle 2.3?
On Tue, Sep 14, 2010 at 05:31:10PM +0200, Christian Ohm wrote: On Tuesday, 14 September 2010 at 11:31, Giel van Schijndel wrote: On Tue, Sep 14, 2010 at 12:56:53AM -0400, buginator wrote: On 9/13/10, Christian Ohm wrote: How about doing 2.3.5.x releases for bugfixes only instead? So for example we (finally) branch 2.3.5 now (and immediately push CorvusCorax's projectile fixes in 2.3 for 2.3.6), tag (hopefully no more) RCs from it, the release, and the 2.3.5.x fixes. I can live with this. I don't think we have enough manpower to maintain two release branches. (Well, and there's the question of how well the bugfix only thing will work out, I remember both the 2.2 and 2.3 jumps, and though both times there was some interest in keeping the old line alive in parallel for a while, in the end only the new version was released.) This is true as well, and since we always lack the manpower to do the upkeep that is required, it is possible the same thing will happen with the purposed 2.3.5.x branch. We are going to end up with 3 testing versions, one for trunk (new features + bug fixes), one for 2.X (new features + bug fixes), and one for 2.3.5.x (bug fixes). It might not always be possible to just do testing in 2.X, since the new feature might skew the results. Another radical suggestion: reducing 2.X branches to feature-frozen branches, i.e. the only time to add new features would be when creating a new 2.X branch. How's that different from what I proposed? Sounds about the same to me, except you use 2.x instead of 2.3.x. Erm, I read 2.3.5.x, which sounds a bit like overkill to me. -- Giel -- Good code is its own best documentation. As you're about to add a comment, ask yourself, 'How can I improve the code so that this comment isn't needed?' Improve the code and then document it to make it even clearer. -- Steve McConnell signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] OpenGL ES (2.0)
Hi all, Long time since I've actually written on this mailing list. I've been looking into modifying the rendering code in such a way that it can be used to render on OpenGL ES (ES 2.0+ considering that I only have hardware to test that version) enabled devices. This however, would require significant changes to the drawing code. Keep in mind that these changes would be required for *pure* OpenGL 3.0 as well, with pure meaning without the backward compatibility extensions. The two most significant changes are: * immediate-mode drawing would have to go (glBegin()/glEnd()), replacing it with either VAs or VBOs - which code-wise, are nearly the same thing, VBOs are just VAs cached in video memory. * we cannot use the matrix stack anymore - in OpenGL ES the matrix stacks don't exist anymore, so we would have to maintain this stack outside of the OpenGL API (relatively easy to do) - fixed pipeline rendering is mostly gone, so a shader performing the vertex transformation (multiplication with model-view and projection matrices) would have to be used. Please give me your thoughts on making these changes. Personally I don't think removing of immediate-mode rendering is a very big deal, nor is replacing gl(Push|Pop)Matrix with our own implementation. Completely shedding our dependence on the fixed rendering pipeline is something of an entirely different scale though. -- Giel -- There are 2 types of people in this world - those who like Chuck Norris and those who are dead. -- Jus12 signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[9641] branches/2.3/win32/__BUILD_SCRIPT
On Fri, Feb 05, 2010 at 11:59:56PM +, bugina...@users.sourceforge.net wrote:
Revision: 9641
http://warzone2100.svn.sourceforge.net/warzone2100/?rev=9641view=rev
Author: buginator
Date: 2010-02-05 23:59:55 + (Fri, 05 Feb 2010)
Log Message:
---
Change HOST_TRIPLET to be i586-mingw32msvc instead of mingw32 as the default
HOST_TRIPLET
Modified Paths:
--
branches/2.3/win32/__BUILD_SCRIPT
On Sun, Feb 07, 2010 at 05:27:55PM +, bugina...@users.sourceforge.net wrote:
Revision: 9722
http://warzone2100.svn.sourceforge.net/warzone2100/?rev=9722view=rev
Author: buginator
Date: 2010-02-07 17:27:54 + (Sun, 07 Feb 2010)
Log Message:
---
Update cross-compiler build script to make use of --with-distributor
Modified Paths:
--
branches/2.3/win32/__BUILD_SCRIPT
On Sun, Feb 07, 2010 at 05:35:54PM +, bugina...@users.sourceforge.net wrote:
Revision: 9723
http://warzone2100.svn.sourceforge.net/warzone2100/?rev=9723view=rev
Author: buginator
Date: 2010-02-07 17:35:44 + (Sun, 07 Feb 2010)
Log Message:
---
fix a typo from previous commit
Modified Paths:
--
branches/2.3/win32/__BUILD_SCRIPT
None of these ^^ commits are necessary.
Using another HOST_TRIPLET than mingw32 can be achieved by specifiying
HOST_TRIPLET=${whatever_you_want} as command line argument to
__BUILD_SCRIPT.
Using a non-default distributor (remember that configure.ac already
uses UNKNOWN as its default) can be accomplished by specifying
--with-distributor=$distributor as command line argument to
__BUILD_SCRIPT.
The build script will pass *all* its arguments to the ./configure
script, so no special hacks are required to pass paramters to
./configure. Furthermore all arguments of the form \w+=.* (e.g.
VAR=val) will cause environment variables of that name to be
overridden.
Thus rather than complicating the cross build script any further I
suggest to revert the above commits.
--
Giel
signature.asc
Description: Digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Please notify me next time, if the server shouldn't respond.
On Fri, Nov 20, 2009 at 04:13:19PM +0100, Kamaze wrote: I just saw that the server didn't respond, due to some Bind9 hangup. Regarding to munin, Bind9 freezed at 2AM CET. Can you _please_ write an e-mail to me next time you may notice such a hangup? This would result in somewhat smaller reaction times, since I check my e-mails more frequently than some website. Might I suggest using a monitoring system, e.g. Nagios to check for these kinds of errors? Nagios can easily be configured to automatically check different services (BIND9 included) once every few minutes and send e-mail notifications when a check fails. If you need help with this specifically mail me off-list. (We're using it for system administration at Interlink [1]). [1] http://www.il.fontys.nl/ -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] next debian freeze
Got this message from Paul Wise on IRC: 16:36 pabs3 Giel: Debian freezes in March 2100, would be good if WRP folks could think about which version they want in stable. http://lists.debian.org/debian-devel-announce/2009/10/msg2.html Quoted the release announcement here: Hi Release planning Proposing a new freeze date is not easy. Taking into account all of the feedback we have received, both online (by e-mail, IRC) as well as in person, and some challenging release goals we have set for ourselves, we propose freezing in March 2010. Request for help As in our previous update, we want to stress that the state of unstable and testing is not very good. We still have a large number of Release Critical bugs and problems ensuring the smooth transition of packages to testing. To get the number of RC bugs down, we will be more aggressively removing fringe packages from testing and request your help in fixing bugs, following the build status of your packages and organising bug squashing parties (BSPs [0][1][2]). In order to help ensure the smooth migration to testing of packages involved in library transitions, we ask you to try to avoid uploading packages when doing so would disturb an existing transition. Executing ``grep-excuses pkg'' (from the devscripts package) before uploading can help a lot. If you are interested in helping or joining the Release Team, please contact us (in private or public) and we'll see how to make it work. Please don't hesitate to contact us if you have any questions. - -- http://release.debian.org Debian Release Team [0] http://wiki.debian.org/BSP [1] http://wiki.debian.org/BSP2009/CambridgeNovember [2] http://wiki.debian.org/BSP2010/Moenchengladbach Thus, as Paul suggested, we'll need to think a bit about which Warzone version we'll want to have released by then. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Why don't we get rid of the text stats and use the db stats instead?
On Sun, Aug 16, 2009 at 12:55:12PM +0200, Per Inge Mathisen wrote: On Sun, Aug 16, 2009 at 12:42 PM, Elio Gubserelio.o...@gmail.com wrote: Afaik we're using the database for multiplayer stats and text stats for campaign. (correct me if i'm wrong) IIRC it is the other way around. It is the other way around. Campaign stats are, mostly (not entirely), contained in the database, multiplayer/skirmish stats are still found in the text files. Why don't we get rid of the text stats and use the db stats instead? Because the DB stats code isn't finished, which is a result of me having a serious time shortage. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Drag rearm pad building
On Mon, Jun 01, 2009 at 11:19:55AM +0200, Kreuvf wrote: Per Inge Mathisen wrote: I don't think units can drive over the rearm pads? I could change that. It makes sense. Hopefully those ground units don't shoo away the VTOLs then, especially during re-arming. Agreed, provided that regular ground units can drive over rearm pads and those units will circle around VTOLs instead of chasing them off I think this patch is a good one. Otherwise I think we should go with Zarel's suggestion. I.e. have the drag drop GUI option but still leave empty spaces between them. @Kreuvf: you might want to use something like PGP/MIME to sign your messages, I find that to be less intrusive. (Enigmail supports PGP/MIME. You'll find it in the OpenPGP Security part of your account's settings). -- Giel signature.asc Description: Digital signature ___ 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
On Mon, May 25, 2009 at 10:03:09AM +0200, Dennis Schridde wrote: 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 Some of those signals simply don't exist on some other systems, e.g. FreeBSD. In order to get it to compile on FreeBSD I would have had to add about 3 #ifdef statements. As for a generic signal-to-string method, considering that it's not platform agnostic the generic part goes out the window. In addition to that, we simply don't need a way of translating all signals to strings since we only use that translation method in the crash handler, and not all signals are fatal. -- Giel signature.asc Description: Digital signature ___ 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 Thu, May 28, 2009 at 01:08:08PM -0400, bugs buggy wrote: On 5/28/09, Kreuvf kre...@warzone2100.de wrote: This is even worse considering that wz2100.net to the best of my knowledge is the only mirror for the aforementioned resources and down-times happen. So I propose adding the following to the doc-files instead of excluding them: Technically wz2100.net isn't even a mirror. This file has not been updated since the release of 2.1. Some information may not be correct any more. For current information visit the homepage of the Warzone 2100 Resurrection Project. I guess the disclaimer can work as well... either or works for me. I prefer the disclaimer. And we always have google cache ;) ... is no substitute for an on-line website. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] sequences.wz
On Wed, May 27, 2009 at 10:43:35PM -0400, bugs buggy wrote: Can someone who doesn't suffer from GNAitus and has good upstream bandwidth, please add the GPL notice (COPYING file?), and a VERSION file (which I guess would be 1.0) inside sequences.wz? We may also want to include the full text from Updated GPL release readme http://forums.wz2100.net/viewtopic.php?f=3t=1818 to make the maintainer's job of packaging this a bit easier? The re-encoding of the videos will have to wait for a future release. On it. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] sequences.wz
On Sat, May 30, 2009 at 11:24:54PM +0200, Giel van Schijndel wrote: On Wed, May 27, 2009 at 10:43:35PM -0400, bugs buggy wrote: Can someone who doesn't suffer from GNAitus and has good upstream bandwidth, please add the GPL notice (COPYING file?), and a VERSION file (which I guess would be 1.0) inside sequences.wz? We may also want to include the full text from Updated GPL release readme http://forums.wz2100.net/viewtopic.php?f=3t=1818 to make the maintainer's job of packaging this a bit easier? The re-encoding of the videos will have to wait for a future release. On it. Uploaded as http://download.gna.org/warzone/videos/sequences-2.2.wz -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7027] trunk/data/mp/stats
On Tue, Apr 14, 2009 at 08:58:52PM +, zare...@users.sourceforge.net wrote: Revision: 7027 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7027view=rev Author: zarelsl Date: 2009-04-14 20:58:52 + (Tue, 14 Apr 2009) Log Message: --- Commit Rebalance 0.4.2: - Make Angel Missile into MRL replacement - separate rocket/missile from cannon/rail multipliers - make truck rushing harder - balance cyborgs and VTOLs- - remove requirements for basic cyborg weapon research For full details and changelog see http://guide.wz2100.net/new/ Please include the full changelog in your commit message. There's no size limit on it... I don't like dependencies like this on external sources. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] trunk 2.2 changes for ports/ server code/ config directory
On Wed, Apr 08, 2009 at 02:19:08PM +0200, Christian Ohm wrote: On Wednesday, 8 April 2009 at 11:46, Per Inge Mathisen wrote: But I'm not sure if the actual problem is in Mesa, or if Warzone is doing something strange with the VBOs. If someone knows some simple example programs using VBOs (complete with build system for Linux) to test, that'd be nice (I found one from http://www.songho.ca/opengl/gl_vbo.html that works here). Another project that works with VBOs, a lot of them, is fishtank [1] You can find its dependencies in the debian/control [2] file. I'll write up a small INSTALL when I've got the time. Also make sure that Eigen 2's include files are in the include path (CPPFLAGS=-I/usr/include/eigen2 on Debian). [1] http://svn2.il.fontys.nl/usersvn/fishtank/trac [2] http://svn2.il.fontys.nl/usersvn/fishtank/trac/browser/trunk/fishtank/debian/control -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2 alpha/beta changes
On Sun, Mar 15, 2009 at 08:09:19PM +0100, Dennis Schridde wrote: Am Sonntag, 15. März 2009 18:15:32 schrieb bugs buggy: Was wondering what port should we change 2.2 to use? 2.0.x was using: (do we still have a 2.0 lobby server?) gameserver_port: masterserver_port: 9998 2.1 is using: gameserver_port: masterserver_port: 9997 Do we switch to 1 for 2.2 trunk? We should use one of 49152 - 65535, the rest is registered by IANA. And till we get an own registered port, I think it might be a good idea to use a private port instead. How about an entirely different approach. I was thinking about using an approach similar to what a lot of P2P applications use. I.e. allow the user to specify a range or list of ranges (ddd-ddd,ddd,ddd,ddd-ddd,ddd), then start trying these ports until we get one for which the lobby server confirms it is reachable? Obviously we should exclude port 9998 and from that list by default. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] FMV delivery and installer thingys
On Fri, Mar 06, 2009 at 08:17:42PM -0500, bugs buggy wrote: On 3/5/09, Zarel zare...@gmail.com wrote: 2009/3/4 Zarel zare...@gmail.com: Just kidding. They're not going to sync intrepid. Apparently, once an Ubuntu version has been released, only critical bugfixes and security patches are allowed. 2.1-beta4 - 2.1.1 just doesn't fix critical enough bugs to qualify. :( I can try to convince them the 6-player limit is a big enough bug to justify 2.1.2... We *did* have a security issue with the dump files, does that count? Giel fixed it in trunk, though, I don't recall if it is in 2.1.x or not though. Just for the record, that security fix was done in 2.1_rc1 [1]. So it might warrant an upgrade from 2.1-beta4. [1] http://developer.wz2100.net/browser/tags/2.1_rc1/ChangeLog#L30 -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Nightly build of r6682 failed
On Sun, Feb 22, 2009 at 01:26:51PM +0100, Dennis Schridde wrote: Am Sonntag, 22. Februar 2009 05:44:03 schrieb Giel van Schijndel: Building of the nightly build failed for revision r6682 [1] when trying to build a debug executable. Attached is the full build output (both stdout and stderr) and configure's log. Both are gzip compressed. Attached files are broken. Strangely I didn't receive the buildbot notice through the mailing list. The one that didn't pass through the mailinglist is perfectly fine. Anyway, it seems that I've got a disk shortage again, I'm reasonably sure this is a direct result from merging the terrain branch into trunk. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r6695 - in /trunk/data/mp: messages/strings/ stats/ stats/research/multiplayer/
On Sun, Feb 22, 2009 at 07:49:30PM +0100, Per Inge Mathisen wrote: On Sun, Feb 22, 2009 at 7:06 PM, Guangcong Luo zare...@gmail.com wrote: Rebalance 0.2.4 - fixes many balance problems. Changes documented on Warzone Guide - currently available at http://guide.wz2100.net/new/ This will be interesting :-) But, you need to work on a better change description that we can put in the Changelog. - I'm not sure what's changed. Many of my latest changes aren't here (cf above URL) just won't do. Additionally I'd like to have the changes from a commit be reported in the commit's log message. Not on some external source that's prone to being changed. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] c::b build project going away... any objections?
On Thu, Feb 19, 2009 at 10:20:33PM +0100, Dennis Schridde wrote: Am Donnerstag, 19. Februar 2009 22:02:01 schrieb Per Inge Mathisen: Last updated 2008-10-08, seems like nobody is using it. I do not want to update it when nobody else is. And you know I hate dead code. Go for it. I think just Giel once used it when he was still working on EditWorldWX. Nope, for that I used tools/editworld/src/wxDialogs/EditWorld.cbp. As for Code::Blocks itself. I've used it for some time, but never really liked it (in fact I don't think I ever really liked IDEs). -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Map packs
On Sat, Feb 14, 2009 at 02:19:28PM +0100, Dennis Schridde wrote: Am Samstag, 14. Februar 2009 08:40:30 schrieb Kreuvf: bugs buggy wrote: Inside the .info file itself would be all the author's name, and whatever else info the map pack creator wants to put inside it. The game wouldn't ever read the contents of that file though. http://developer.wz2100.net/wiki/Organization_Proposal (it's a bit fucked up due to the move from mediawiki to tracwiki) There is an even older proposal which deals with that already. It involves a Lua file storing some basic information about a .wz file, like author, license, included maps, etc. I prefer using Lua instead of JSON syntax for the simple reason that the syntax is quite similar but for Lua we don't need to implement any parser ourselves. So the idea is not new, just no one came around to implement it yet. It's hardly new indeed, and from what I recall it seems to be that every time it was brought up we came to the conclusion that it's PhysicsFS' API that was the limiting factor in implementing such a proposal. So I suggest that this time we should be prepared to look past the limitations of PhysicsFS and if necessary should be prepared to extend PhysicsFS' API where required, obviously this should be done in coordination with the PhysicsFS developers. To conclude: we shouldn't let ourselves be limited by PhysicsFS' API. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Latest trend of NOT putting patches in trac?
On Thu, Feb 12, 2009 at 12:34:07AM -0500, bugs buggy wrote: Revision: 6634 -- [snip] - I don't think I screwed up start-at-block-declaration rules for MSVC, but given the size of these changes I can't be sure. [snip] Well you did. Though, at least nobody can say you aren't verbose enough in the logs to see what is going on. ;) The major reason for refactoring (r6634 was only a partial refactoring btw) actionUpdateDroid is because I got a segfault with actionUpdateDroid in the stack trace. That function's so horribly, badly, structured (although structured may be too strong an adjective) though that any kind of debugging becomes a David vs Goliath story (me being David without knowledge of Goliath's achilles heel). For that reason (and maintainability in general) that function's in need of refactoring. As for r6634 itself, I've looked over it multiple times to make damn sure that it would leave run-time behaviour unchanged. I just put less time in checking for C89 compatibility (I *did* check though, and did fix some of those var-decl-at-top-of-block errors *before* committing), causing some of those to slip through the cracks. I'm sorry for the inconvenience, but I just thought run-time behaviour to be more important than (easy to fix) compile time problems. I applied your patch to fix the C89 compatibility problems, although I would have been happy to fix them myself as well (e.g. with a copy-paste of the compiler output) if fixing that was too much of a problem or time-drain for you. /me back this weekend to here the flames against this post. :) One semi-flame: I'm sure you mean hear (the verb, not here the noun). ;-) -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Nightly build of r6617 failed
On Wed, Feb 11, 2009 at 05:34:37AM +0100, Giel van Schijndel wrote: Building of the nightly build failed for revision r6617 [1] when trying to build a non-debug executable. Broken by r6613. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] assert return macro
On Mon, Feb 02, 2009 at 08:58:11AM +0100, Per Inge Mathisen wrote: On Sun, Feb 1, 2009 at 11:55 PM, Giel van Schijndel m...@mortis.eu wrote: It is misleading, though, since it can also be ASSERT_AND_RETURN or just RETURN, depending on how the program is compiled and how gdb reacts to abort signals. So I would prefer to keep the slight ambiguity in the name. Then do I read this wrong? Assert that returns given return value on failure in non-debug builds. In debug builds you get both an assert and a return if the condition fails. You may not always get to the return, but it is there for those cases where you ignore the abort signal. Still, even in non-debug builds the expression is asserted to hold true, the action taken on failure to assert is just different. For debug builds it calls some implementation defined __assert_fail-like function. On non-debug builds only an error is logged. I'd say that's always equal to ASSERT_OR_RETURN Maybe. Maybe not. But ASSERT_RETURN is what I find used elsewhere. According to google it is somewhat frequent (26k pages), while it gives me exactly 3 pages for either of ASSERT_OR_RETURN as ASSERT_AND_RETURN. I'd rather base names for our functions and macros on legibility than on statistics. To me ASSERT_RETURN could mean any of ASSERT_OR_RETURN and ASSERT_AND_RETURN. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] assert return macro
On Sat, Jan 31, 2009 at 11:45:11PM +0100, Per Inge Mathisen wrote: No. There are in fact three places now that the expression result is checked: 1) Checking if we should log an error 2) The assert() 3) The return condition In my patch I only cache it in the first case for the last case, since the second case will be void in non-debug builds anyway. But we should consider just doing assert(false) since we log the expression and error better in the code right above it anyway. I'd rather not use assert(false) as on some systems assert() is used to produce a nice GUI message. E.g. on Windows you'll get a message like assertion $expression failed, abort, ignore, attach debugger?. Deciding which of those buttons to click becomes difficult if you don't get to see any sensible expression there. Perhaps as a fallback we could do something like this: #define ASSERT_XXX(expr, str_expr, ...) \ assert(!str_expr) Which for ASSERT(a b, ...) (sh|w)ould be equal to: assert(!a b); That would be false as well but would still retain the benefit of single evaluation. Additionally I think ASSERT_OR_RETURN is a slightly better name It is misleading, though, since it can also be ASSERT_AND_RETURN or just RETURN, depending on how the program is compiled and how gdb reacts to abort signals. So I would prefer to keep the slight ambiguity in the name. Then do I read this wrong? Assert that returns given return value on failure in non-debug builds. I interpret that as, when I do: ASSERT_RETURN(expr, retval, blabla); it'll return retval when expr yields false when evaluated. To me the above ASSERT_RETURN statement reads like this: * assert that expr holds true * failing to assert that expression, return retval I'd say that's always equal to ASSERT_OR_RETURN, I can't think of any case where it'd become ASSERT_AND_RETURN. Translating those two names to macros (vastly simplified and using invalid C syntax) I'd write this: #define ASSERT_OR_RETURN(expr, retval) \ (expr) || return(retval) #define ASSERT_AND_RETURN(expr, retval) \ (expr) return(retval) I think (taking shortcut behaviour into account), the former is what you want, not the latter. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] assert return macro
On Thu, Jan 29, 2009 at 08:49:39PM +0100, Per Inge Mathisen wrote: I want to define a new macro ASSERT_RETURN(expr, retval, ...) that asserts in debug builds, and returns with the given return value in non-debug builds. This to make it easier to do the right thing when coding, which is to first check an entry condition with an assert, and then check it again to return on failure. It also has the added benefit that it will only evaluate the expression once, unlike ASSERT(expr); if (!expr) ... code, since even in non-debug builds we evaluate the expression to output logging in case of error. An example: ASSERT_RETURN(false, 1, testing); This macro will test the expression 'false' and if it fails (always) it will assert, if asserts are enabled, and if not (or if continue from gdb is used) return 1. Since we have had quite a few rounds on the exact definition of the ASSERT macro, please have a close look at this patch. I like the general idea. About your patch, assert() itself performs string expansion on the given expression as well (for display purposes). Doesn't caching the expression's result cause assert() to see another string, i.e. just _wzeval? Additionally, I think we shouldn't have any code at all that depends on expressions inside of ASSERT()/assert()/etc. to have side effects. In fact I think expressions that with side effects (i.e. expressions for which multiple evaluation would be a problem) shouldn't be used at all as part of asserting expressions. E.g. I consider this to be bad code: int i = x; ... ASSERT(++i y, 'i' out of range); Instead something like this should be used IMO: int i = x; ... ++i; ASSERT(i y, 'i' out of range); So I suggest to rip the multiple evaluation-prevention code. Additionally I think ASSERT_OR_RETURN is a slightly better name, which IMHO captures the behaviour of that macro better. I.e. it either successfully asserts the expression to be successful or it returns the given value. Other than these points I like this proposal. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] buildbot failure in Warzone 2100: Resurrection Project on nightly_mingw32
On Thu, Jan 15, 2009 at 02:07:01AM +0100, buildbot+notif...@kynes.de wrote: The Buildbot has detected a new failure of nightly_mingw32 on Warzone 2100: Resurrection Project. Full details are available at: http://build.kynes.de/builders/nightly_mingw32/builds/111 Buildbot URL: http://build.kynes.de/ Buildslave for this Build: i386-debian-etch-2 Build Reason: The Nightly scheduler named 'nightly' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed compile shell_3 File exists. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Nightly builds disabled
On Mon, Jan 05, 2009 at 05:25:45PM +0100, Giel van Schijndel wrote: On Sun, Jan 04, 2009 at 04:32:07PM +, Freddie Witherden wrote: Most of these failures originate from having too few disk space. I think the size of trunk (in bytes) has increased causing this error. Considering that I don't have any more diskspace on this system I'll be disabling my nightly build script for now. Can you not delete some of the older builds (or get it to scp them to Gna! when done)? I already have it set up to automatically delete the builds of previous revisions. Unfortunately that doesn't yield me enough additional diskspace to build both the debug and non-debug builds. I'll look into freeing up some disk space later this week. PS I already re-enabled the nighlty builds last week. Apparently my local mirror of the warzone repository had increased with some 80~100 MB(!!), removing that mirror fixed the problem. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] 2.1.1 released
Hi all, After releasing 2.1 we soon discovered that a problem which popped up on Mac OSX some times was rather easy to fix. Hence this bug fix release. This release only fixes an issue where saved games wouldn't load properly on big endian systems (e.g. PowerPC a processor common in OSX systems). Additionally the Dutch translation has been updated and is now 49% completed. The list of changes since 2.1: * Fix: Double endian swapping bug that caused loading of save games to go wrong on big endian systems, e.g. PowerPC (ticket:96 [1], ticket:127 [2], ticket: 177 [3]) * Change: Updated Dutch translation (49%, ticket:202 [4]) For the full list of changes, see the change log [5]. Known Issues The known issues from 2.1 remain. The full list of known issues: * Switching languages through the menu, on Mac OSX can cause crashes (ticket:170). * Save games from the 2.0 series can *not* be loaded with this version. (NOTE: We do not intend to fix this, as we are breaking compatibility with the previous save game format.) * The multi player code has been improved since beta 2, but running out of sync is still possible. * The game in general still aborts quite often in debug builds due to failed assertions. * Save games from 2.1 beta 4 (that, and only that version), can *not* be loaded with this version. (NOTE: We cannot fix this because the beta 4 save games miss information we need.) Download The source code and all available binaries can be found, as usual, at the download page [6]. [1] http://developer.wz2100.net/ticket/96 [2] http://developer.wz2100.net/ticket/127 [3] http://developer.wz2100.net/ticket/177 [4] http://developer.wz2100.net/ticket/202 [5] http://svn.gna.org/svn/warzone/tags/2.1.1/ChangeLog [6] http://wz2100.net/download -- Best regards, Giel van Schijndel, The Warzone 2100 Resurrection Project signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] buildbot failure in Warzone 2100: Resurrection Project on nightly_mingw32
On Fri, Jan 09, 2009 at 02:00:01AM +0100, buildbot+notif...@kynes.de wrote: The Buildbot has detected a new failure of nightly_mingw32 on Warzone 2100: Resurrection Project. Full details are available at: http://build.kynes.de/builders/nightly_mingw32/builds/105 Buildbot URL: http://build.kynes.de/ Buildslave for this Build: i386-debian-etch-2 Build Reason: The Nightly scheduler named 'nightly' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed svn Dennis, to clean up space I had to remove /var/svn/warzone and instead depend on http://svn.gna.org/svn/warzone. If you could fix up the buildbot recipe to use that checkout URL instead that should fix that ^^ problem. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.1.1?
On Tue, Jan 06, 2009 at 08:52:33AM +, Freddie Witherden wrote: A week or so ago Giel committed some endian changes which fix several bugs on big-endian systems, namely loading and saving games. These fixes are very important for PowerPC users (mainly OS X, possibly a few Linux users). Therefore, it is my recommendation that we tag 2.1.1 as soon as possible. Agreed. I suggest releasing 2.1.1 this weekend. I am not sure what else is fixed, but I am sure there is the odd bug or two squished as well. Nope, in fact r6513 [1] is the only change to 2.1 since tagging 2.1.0. However, that other OSX bug with language selection might be nice to fix. I don't have the time to do that right now though, nor do I have the hardware to test it myself. So if someone else could fix it before the weekend I suggest to include it. If not just release 2.1.1 and use 2.1.2 instead for a next bugfix. (I think you all know what I think we should do with 2.2 as well, however, I am aware that it is slightly less practical to do so at the current time.) I don't think we should wait for 2.2 with releasing this bugfix... [1] http://developer.wz2100.net/changeset/6513 -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Nightly builds disabled
On Sun, Jan 04, 2009 at 04:32:07PM +, Freddie Witherden wrote: Most of these failures originate from having too few disk space. I think the size of trunk (in bytes) has increased causing this error. Considering that I don't have any more diskspace on this system I'll be disabling my nightly build script for now. Can you not delete some of the older builds (or get it to scp them to Gna! when done)? I already have it set up to automatically delete the builds of previous revisions. Unfortunately that doesn't yield me enough additional diskspace to build both the debug and non-debug builds. I'll look into freeing up some disk space later this week. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Project goals?
On Mon, Jan 05, 2009 at 08:55:18AM +0100, Per Inge Mathisen wrote: On Sun, Jan 4, 2009 at 10:54 PM, bugs buggy buginato...@gmail.com wrote: Other things I have noticed, is there any reason why we have both bug trackers active? I don't really bother to check GNA anymore, since trac is far superior IMO. The problem is that some bugs are only in gna.org, and if we close the bug tracker, we cannot read them anymore. So unless someone volunteers to port the bugs in gna.org over (or fix them all...), we can't close it yet. Can't we set Gna's trackers to read-only or disable the ability to create new items? (The latter would be preferrable). As for porting, Gna! provides the ability to export the entire content of a tracker as an XML dump. I figure this could be imported into Trac easily enough. A problem, however, would be that Gna! (Savannah actually) uses a different numbering scheme (i.e. site-wide and per tracker instead of project-wide only). Thus we would need to find a way to address that. One way to address that problem could be: 1. Hope that we don't have any colliding bug patch numbers on Gna! 2. Import all Gna! bugs, with ticket IDs equal to Gna! bug numbers, giving them a ticket-type of defect in Trac 3. Import all Gna! patch, with ticket IDs equal to Gna! patch numbers, giving them a ticket-type of enhancement in Trac 4. Rewrite all bug patch links in those tickets: s/(?:bug|patch)\s+(#\d+)/$1/g; 5. Am I missing something? Can we dump all the 3rd party files in a separate branch? (Though, I rather not have any 3rd party files in the svn to begin with, I still think it should be placed on GNA.) Which 3rd party files? IIRC there is the NTW mod and the extra tiles. The extra tiles could go on gna.org, since they are never changed, and are never used directly (AFAIK). I think it would be nice to host NTW, and any other third party mods, in a separate repository from our own. That is, separate base content from extension/additional content. Oh, and belated Happy New Years to everyone. :) To you and everyone else too. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Project goals?
On Mon, Jan 05, 2009 at 07:02:02PM +0100, Per Inge Mathisen wrote: 6. Ignore patches, import only bugs. The list of patches is much, much shorter, and the relevant ones more easily ported over by hand. Most of them can probably be closed outright. I'd rather import the closed ones as well, to maintain project history. Depending on the amount of trouble it will be to import those of course... -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [patch] No asserts cheat
On Thu, Jan 01, 2009 at 06:22:40PM +0100, Per Inge Mathisen wrote: On Thu, Jan 1, 2009 at 4:26 PM, Dennis Schridde devuran...@gmx.net wrote: Can you not just skip asserts in the debugger? Can you? Ever since the crash handler was added, I always end up in a non-skippable abort inside it when trying to skip an assert in the debugger. This disables passing of the abort signal to the program: handle SIGABRT nopass That allows you to just continue after having caught an abort signal in the debugger (the debugger will *always* receive the signal before the program does, except for SIGKILL...). -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Nightly build of r6527 failed
On Sun, Jan 04, 2009 at 05:42:33AM +0100, Giel van Schijndel wrote: Building of the nightly build failed for revision r6527 [1] when trying to build a debug executable. Most of these failures originate from having too few disk space. I think the size of trunk (in bytes) has increased causing this error. Considering that I don't have any more diskspace on this system I'll be disabling my nightly build script for now. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Nightly build of r6489 failed
On Thu, Dec 25, 2008 at 05:36:23AM +0100, Giel van Schijndel wrote: Building of the nightly build failed for revision r6489 [1] when trying to build a non-debug executable. Seems the changes to NTW caused this. make[3]: *** No rule to make target `../data/mods/multiplay/ntw/multiplay/script/AutoEnable.slo', needed by `warzone2100.pot-update'. Stop. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Nightly build of r6506 failed
On Fri, Dec 26, 2008 at 05:34:40AM +0100, Giel van Schijndel wrote: Building of the nightly build failed for revision r6506 [1] when trying to build a non-debug executable. Seems the changes to NTW caused this. make[3]: *** No rule to make target `../data/mods/multiplay/ntw/multiplay/script/AutoEnable.slo', needed by `warzone2100.pot-update'. Stop. -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Nightly build of r6506 failed
Giel van Schijndel schreef: On Fri, Dec 26, 2008 at 05:34:40AM +0100, Giel van Schijndel wrote: Building of the nightly build failed for revision r6506 [1] when trying to build a non-debug executable. Seems the changes to NTW caused this. make[3]: *** No rule to make target `../data/mods/multiplay/ntw/multiplay/script/AutoEnable.slo', needed by `warzone2100.pot-update'. Stop. Should be fixed by an invocation of po/update-po.sh in r6507. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] buildbot failure in Warzone 2100: Resurrection Project on nightly_mingw32
On Wed, Dec 24, 2008 at 02:08:07AM +0100, buildbot+notif...@kynes.de wrote: The Buildbot has detected a new failure of nightly_mingw32 on Warzone 2100: Resurrection Project. Full details are available at: http://build.kynes.de/builders/nightly_mingw32/builds/90 Buildbot URL: http://build.kynes.de/ Buildslave for this Build: i386-debian-etch-2 Build Reason: The Nightly scheduler named 'nightly' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed compile shell_3 output: gpg: signing failed: file exists program finished with exit code 2 Meaning: the build was already done for this revision. @Dennis: any chance you could look at preventing double builds when the first was succesfull? -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] 2.1.0 released
Hi all, After a lengthy release cycle, we now have a new stable release. It took slightly longer than initially planned for but it's finally there: Warzone 2100 2.1. This release adds very little to RC 2. This is intended because RC stands for release candidate and thus is intended to become the release itself. The short list (so short that it isn't even a real list) of changes since RC 2: * Fix a bug that caused the number of assigned units to a structure to be displayed wrongly (ticket:90 [1]) For the full list of changes, see the change log [2]. Known Issues The known issues from RC 2 remain. In addition we now know of an additional issue, which is the first one in the following list. The full list of known issues: * Switching languages through the menu, on Mac OSX can cause crashes. * Save games from the 2.0 series can /not/ be loaded with this version. (NOTE: We do not intend to fix this, as we are breaking compatibility with the previous save game format.) * The multi player code has been improved since beta 2, but running out of sync is still possible. * The game in general still aborts quite often in debug builds due to failed assertions. * Save games from 2.1 beta 4 (that, and only that version), can *not* be loaded with this version. (NOTE: We cannot fix this because the beta 4 save games miss information we need.) Download The source code and all available binaries can be found, as usual, at the download page [3]. [1] http://developer.wz2100.net/ticket/90 [2] http://svn.gna.org/svn/warzone/tags/2.1.0/ChangeLog [3] http://www.wz2100.net/download -- Best regards, Giel van Schijndel, The Warzone 2100 Resurrection Project signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.1.0 released
On Sun, Dec 21, 2008 at 09:30:42PM +0100, Giel van Schijndel wrote: * Switching languages through the menu, on Mac OSX can cause crashes. PS This is described in ticket:170 [1]. [1] http://developer.wz2100.net/ticket/170 -- Giel signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Nightly build of r6467 failed
Giel van Schijndel schreef: Building of the nightly build failed for revision r6467 [1] when trying to build a non-debug executable. Fixed. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Future distribution.
On Fri, Dec 05, 2008 at 09:29:43PM +0100, Kamaze wrote: Windows: * Minimal installer: Includes only the base files, with the ability to download the Music/Mods while installing, containing a guide where people can get (URL) the Music and FMV packages and where they have to put/copy them to make them work. * Full installer: Includes everything, Game, Music, FMVs and a zip file which contains the source of the release. (excepting the /data directory, there should be a small textfile, explaining that the data is already delivered in the warzone.wz and mp.wz which are simple zip files, so that we don't deliver it twice) The full installer is basically for redistribution on game magazines for example. Simple answer: no. Longer answer: this will introduce lots of complexity and will gain us next to nothing. Not to mention that I don't seen any users (e.g. on the forums) expressing a need for this. Also keep in mind that if you present this proposal as such on the forums with a poll do yo want this? yes/no, the answer will most likely be yes. Before implenting this I want it to gain *us* something, or have users themselves actively asking for it. Any other reason would, IMO, be a symptom of featuritis. Linux/Mac: * Split the game into 3 packages: warzone-base.deb, warzone-music.deb, warzone-fmv.deb for example. The base package should also deliver a shell/python script which can be executed to check for auto download the music.wz and fmv.wz. Or maybe merge the Music and FMV's into one package. if by 'warzone-base.deb' you mean all data except for music (and later videos) then you just described the current packaging state in Debian. You might want to talk with Paul Wise about this (pabs on IRC). Other than that I think we should impose our packaging wishes on distributors as little as possible. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] buildbot failure in Warzone 2100: Resurrection Project on nightly_mingw32
Dennis Schridde schreef: Am Freitag, 5. Dezember 2008 02:07:03 schrieb [EMAIL PROTECTED]: BUILD FAILED: failed compile warnings+1 +chat_parser.y:760: warning: unused parameter 'msg' Was that way before, except that it was hidden that the variable wasn't used. I.e. it was used to produce some internal string buffer, but that string buffer never got used. I just removed the intermediate string buffer (was a printf-like function) because the printf-features weren't ever used. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Warzone 2100 2.1 RC 2 has been released - and the mailinglist has no clue
Dennis Schridde schreef: To the packagers of this release: It would have been nice to inform the mailinglist of this event. I think it is even listed on the checklist... My fault. I sincerely apologise. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] buildbot failure in Warzone 2100: Resurrection Project on nightly_mingw32
Dennis Schridde schreef: Am Montag, 24. November 2008 02:06:06 schrieb [EMAIL PROTECTED]: The Buildbot has detected a new failure of nightly_mingw32 on Warzone 2100: Resurrection Project. Full details are available at: http://build.kynes.de/builders/nightly_mingw32/builds/60 Buildbot URL: http://build.kynes.de/ Buildslave for this Build: i386-debian-etch-2 Build Reason: The Nightly scheduler named 'nightly' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed compile Caused by recent buildsystem changes: make[3]: *** No rule to make target `../lib/betawidget/font.c', needed by `warzone2100.pot-update'. Stop. Fixed in r6376. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone 2100 Trac] #153: XTnvzutg
Warzone 2100 Trac schreef: #153: XTnvzutg -+-- Spam ticket here... -+-- I didn't appreciate the spam anymore, so I installed SpamFilter [1]. See #156 [2] for more details. In addition I deleted that ^^ ticket entirely (no need to reward the spammers by increasing their PageRank). [1] http://trac.edgewall.org/wiki/SpamFilter [2] http://developer.wz2100.net/ticket/156 -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Organization Proposals
Kamaze schreef: Kreuvf schrieb: And to me the syntax looks a bit crufty (but I guess it is like that because you have a parser at hand for that). Uhm, thats normal JSON-Syntax. That was something I had in my mind, because it supports various datatypes and nesting, as well as arrays. It is just less-bloated than XML, but for most of my proposals a simple *.ini could do the job as well, right. INI's would probably easier to handle for the users as well. I like the added versatility we get by using JSON. It's not that much more complex than an INI-style configuration file. In addition when using JSON we have the option of extending to executable config files later on (i.e. JavaScript). Although from that point of view using Lua is probably a better idea (which just happens to have a syntax more similar to INI for some cases). So considering that we're about to use Lua anyway I suggest to use that for config files instead of JSON. And what could be done about plagiarism? People taking mods of another person and then just rebranding it? I'd really like to have that problem addressed. I think this is impossible, unless we create some kind of DRM system. We have no direct influence over other people's actions, nor do we have responsibility for them. So I suggest that we don't take responsibility for this problem. As for DRM, that wouldn't work either, it would only make it slightly more difficult. I.e. we would have to set up a central authority to credit original authors. That authority would probably end up being us. So in the end it would only create a situation where those who are best at manipulating us will end up getting credit for works. I'd rather not go there. --- My own comments As for the directory structure: That structure simply won't work on GNU/Linux distros. Please take a look at the structure we currently use on GNU/Linux [1], [2], [3] and [4]. * All game data is moved into the /data folder. Music, Fonts, FMVs, Locales are in their own folders, since they aren't updated frequently. This folder is reserved only for official files, so no mods should drop something here. That's no change really, that's a description of the current situation. * Documents and documentation will be found in /docs instead of loose in the root directory. Aside from a few files like AUTHORS, COPYING, README, etc. that's the case already, and for these files I'd like to keep it that way. * The /mods folder stays the same, but gets an additional sub folder. Mods are categorized into 3 categories: Global for mods which are for both, single player and multi player. Single- or multi player/skirmish-only mods. The /mods/gametype/autoload folder is intended for mod packages which should be auto-loaded. However, Giel said that he wants to get rid of these folders, so there is a configuration file /mods/mods.cfg where auto loading can be defined or a certain loading order for mod-stacking. Yes, I think we should specify autoloading of mods in a configuration file. The /autoload/ directory is just a quick hack to achieve autoloading behaviour for non-standard (i.e. not base.wz or mp.wz) mods. Additionally I would actually like to get rid of the distinction between single and multi player mods. I'd rather have global mods and campaign mods (i.e. mods that add a new campaign or modify change the story of existing campaigns). * new folder called /tools. A reserved folder for tools (surprise!) which can/will be shipped with future releases. Like an launching app, scripts or a map editor. I don't think we should ship development tools in the same source tarball or binaries as Warzone itself. * The normal config file has been renamed to config.cfg ... snip ... Adding an extension is fine with me. * The multiplay folder has been renamed to cache. Since AIvolution stores some cache files there, this directory could be used as a caching-directory for all kind of mods. (Whats about customized SQLite databases as well, when the props-files are replaced?) You do realize that what AIvolution stores is *not* cache data right? And modified stats are *definitly* not cache. Cache is precalculated data that has been stored to speed up loading or skip a computation phase. * /multiplay/custommaps has been moved and renamed to /maps. A simple folder where people can drop custom map files. It could also be used as storage for automatic downloaded maps. (from other players, for example) Maps already reside in /maps... (Although /multiplay/custommaps exists as well, removal of that might be an option). * Added a /mods folder, which has exactly the same structure like in the application dir. This should be used for user- and automatically downloaded mods. In the case of conflicts, the mods in the user directory should always override the global mods. We currently have /mods/global which is not that much different. * /screendumps becomes
Re: [Warzone-dev] Nightly build of r6344 failed
Giel van Schijndel schreef: Building of the nightly build failed for revision r6344 [1] when trying to build a non-debug executable. Fixed in r6346. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Releasing 2.1.0
Hi all, Considering that we've got one release candidate out for 2.1 already (and a proposal for a second one by me) I'd like to set an (informal?) deadline for releasing 2.1.0. I propose to use 13/14 December 2008 for this purpose. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Trac ticket processing
Hi all,
After taking a close look at the Trac post commit hook I discovered it
had some missing linefeeds ('\n') causing syntax errors, and in turn
causing it not to work.
So I fixed these problems and now when you commit Trac parses the commit
message as follows (to add notices to tickets):
It searches commit messages for text in the form of:
command #1
command #1, #2
command #1 #2
command #1 and #2
Instead of the short-hand syntax #1, ticket:1 can be used as well, e.g.:
command ticket:1
command ticket:1, ticket:2
command ticket:1 ticket:2
command ticket:1 and ticket:2
In addition, the ':' character can be omitted and issue or bug can be used
instead of ticket.
You can have more then one command in a message. The following commands
are supported. There is more then one spelling for each command, to make
this as user-friendly as possible.
close, closed, closes, fix, fixed, fixes
The specified issue numbers are closed with the contents of this
commit message being added to it.
references, refs, addresses, re, see
The specified issue numbers are left in their current status, but
the contents of this commit message are added to their notes.
A fairly complicated example of what you can do is with a commit message
of:
Changed blah and foo to do this or that. Fixes #10 and #12, and refs #12.
This will close #10 and #12, and add a note to #12.
--
Giel
signature.asc
Description: OpenPGP digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Nightly build of r6246 failed
Giel van Schijndel schreef: Building of the nightly build failed for revision r6246 [1] when trying to build a non-debug executable. Fixed. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Pushing 2.1 out the door
Dennis Schridde schreef: Am Donnerstag, 23. Oktober 2008 07:23:06 schrieb bugs buggy: Also, I think we should do a Release Candidate of 2.1, just in case we missed something. Good idea. (This is just the current 2.1 branch, no need to create a new RC tag or anything right? ) Please do create a tag of everything you release. /tags/2.1_rc1 in this case. But Giel will take care of everything. :) If no one has any objections I intend to push out a release candidate this weekend. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Pushing 2.1 out the door
Zarel schreef: On Mon, Oct 20, 2008 at 3:26 AM, Dennis Schridde [EMAIL PROTECTED] wrote: Am Montag, 20. Oktober 2008 01:09:50 schrieb Zarel: On Sun, Oct 19, 2008 at 5:01 PM, Giel van Schijndel [EMAIL PROTECTED] wrote: The only reason for not including/enabling this would be that it looks bad right? If that's the case I'd say: add a config option to disable it and let people decide for themselves. No, ordering is also broken - half the time if you order a unit to attack, the primary turret will fire but the secondary will do nothing Ok, that is an issue. or attack another target. This is intended, if the 2nd turret is out of range. They're pulse lasers (range 16) attacking something in range 11. I'd say that's not intended. That being said, I think most users, given the choice between no multi-turrets at all, or half-decent working multi-turrets they'd probably go for the latter. So I say that we make it a configuration option in the skirmish/multiplayer setup screen and give the users a choice. Then we could always include a bugfix in a bugfix release (e.g. 2.1.1, 2.1.2, etc.) later on if we find one. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Nightly build of r6194 failed
Giel van Schijndel schreef: Building of the nightly build failed for revision r6194 [1] when trying to build a non-debug executable. Fixed. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Pushing 2.1 out the door
bugs buggy schreef: On 10/20/08, Per Inge Mathisen [EMAIL PROTECTED] wrote: On Mon, Oct 20, 2008 at 12:38 PM, Giel van Schijndel [EMAIL PROTECTED] wrote: and give the users a choice. Users only want a choice until given a choice, then they want it to work. Besides, in my experience, making it a user choice is a much too easy excuse not to fix problems. I do not want us to start accumulating half-dead (undead?) code this way. If we disable it, then maybe someone will step up to fix it. That pretty much is the reason. The code never was finished, and has too many issues for a 2.1 release. It is a nice thing to have, but I rather not deal with the additional bug reports over something that isn't finished yet. Look at the forums, and you will see how silly it can look, and the problems associated with this. Okay, so just remove multi-turret support from 2.1 altogether then? And redirect users to trunk (nightly builds for windows users) if they want multi-turret support? -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Pushing 2.1 out the door
Elio Gubser schreef: The issues that must be done still: *Disable multi-turret support. hmm, people (at least me) really love that feature and would hazard the consequences (imo and what i've read in the forums) The only reason for not including/enabling this would be that it looks bad right? If that's the case I'd say: add a config option to disable it and let people decide for themselves. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] buildbot failure in Warzone 2100: Resurrection Project on nightly_mingw32
Zarel schreef: 2008/10/12 Giel van Schijndel [EMAIL PROTECTED]: Erm Why does it report failure? The build clearly succeeded... (i.e. [1] and [2] are produced as a result of it). [1] http://warzone.mortis.eu/nightly-builds/warzone2100-trunk-r6140-debug.exe [2] http://warzone.mortis.eu/nightly-builds/warzone2100-trunk-r6140-debug.exe.sig It appears that the debug build succeeded but the non-debug build failed. That buildbot doesn't build non-debug builds -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] buildbot failure in Warzone 2100: Resurrection Project on nightly_mingw32
[EMAIL PROTECTED] schreef: The Buildbot has detected a new failure of nightly_mingw32 on Warzone 2100: Resurrection Project. Full details are available at: http://build.kynes.de/builders/nightly_mingw32/builds/12 Buildbot URL: http://build.kynes.de/ Buildslave for this Build: i386-debian-etch-2 Build Reason: The Nightly scheduler named 'nightly' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed configure Theora wasn't present yet in the devpkg. Fixed it. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Splitting the repository into source data sections?
Per Inge Mathisen schreef: On Mon, Oct 6, 2008 at 1:23 AM, Giel van Schijndel [EMAIL PROTECTED] wrote: Per Inge Mathisen schreef: BTW - what will happen to existing, checked out working copies if the current contents of trunk/ is moved? I don't want my existing working copies to die a sudden death. If you have any changes you in any of the directories (subdirectories included) that will be moved you'll find svn update to fail halfway (i.e. fail at anything 0% progress and 100% progress). In other words, pretty much all existing checked out working copies will stop working. I would prefer not doing the reorganization, then. Too much pain. Can we make a new directory videos/ side by side with originals/ and trunk/ to store the FMVs instead? Why do we even need the videos under revision control? Then we can reorganize once we get a better revision control tool (subversion 1.5 or git or whatever). Subversion 1.5 is released for quite a long time already and wouldn't solve the above problem it's only got some better merge tracking. As for Git, unlike Subversion, Git isn't capable of only cloning/checking out a subdirectory of the repository, it checks out the entire directory tree. Instead Git promotes the use of multiple repositories if you want different trees. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Splitting the repository into source data sections?
Per Inge Mathisen schreef: On Mon, Oct 6, 2008 at 10:41 AM, Giel van Schijndel [EMAIL PROTECTED] wrote: Why do we even need the videos under revision control? People asked the same question about the data/ stuff. It quickly became clear that not having data under version control invited to total chaos. Just image when someone updates one or more videos through better re-encoding, and we have multiple versions floating around. Or someone adds more subtitles, or whatever. IMHO, we need one, authoritative source for all our stuff, and I do not feel confident in anything short of a version controlled repository. A tarball on some FTP/HTTP server is just not the same. Ok, point taken. However I'd like to suggest that we use a *separate* repository for those videos. I would personally prefer a git repository. Because of its speed with cloning and checking out different revisions (even with large data sets). -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Check out my Facebook profile
Bruce Chidester schreef: I set up a Facebook profile where I can post my pictures, ... Shouldn't mail sent from non-subscribing mail-addresses be blocked for manual processing? If that ^^ mail address is subscribed I suggest to remove it right away... -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Splitting the repository into source data sections?
Per Inge Mathisen schreef: On Sun, Oct 5, 2008 at 7:50 AM, bugs buggy [EMAIL PROTECTED] wrote: With the upcoming release of the FMV patch in trunk, *before* we add the fmvs into the repo, I would like to confirm the data structure. trunk/data (only pumpkin official stuff, + derivatives of their work?) trunk/code or trunk/source trunk/FMVs (since it is optional?) trunk/tools (for editors, utilities, and whatever else) trunk/3rdparty (*If* we go this route. Though, I rather not.) I would prefer to have tools as part of the code/ directory, since they are (or should be) closely linked to the rest of the code. Agreed. I would also prefer to use source instead of code. trunk/FMVs - trunk/video ? Otherwise, I think this is a good idea, since they are so big. I agree on the video directory name, though I'm not sure if we should put the videos in the repository at all... trunk/3rdparty - trunk/mods ? I am in favour of putting the best and well-licensed mods in the repository, and giving their maintainers write access. This makes it easier for us to package them as well as keeping track of its history. The name 3rdparty makes it sound like a storage area for external code, or something. Perhaps we should just put the mods in another repository? That solves the issue of giving maintainers write access without having to give write access to the Warzone source as well... Thus I suggest we use this directory layout for our own repository: trunk/data trunk/pkg trunk/source trunk/source/build_tools trunk/source/doc trunk/source/icons trunk/source/lib trunk/source/m4 trunk/source/macosx trunk/source/makerules trunk/source/po trunk/source/src trunk/source/tools trunk/source/win32 Then use a layout like this for the mod repository: mod/branches mod/tags mod/trunk Then restrict access to the mod subdirectories to only allow maintainers of that mod to write to that part of the repo. E.g. I was thinking of setting up the mod repository in a similar fashion to how trac-hacks.org is set up. trac-hacks.org allows you to create a new project, it'll then automatically add the directory structure to the repository and grant the creating user write access. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Splitting the repository into source data sections?
Dennis Schridde schreef: Am Sonntag, 5. Oktober 2008 14:43:40 schrieb Giel van Schijndel: Thus I suggest we use this directory layout for our own repository: trunk/data trunk/pkg Why put pkg here? pkg will need to be have access to both the source and data... -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Splitting the repository into source data sections?
Per Inge Mathisen schreef: On Sun, Oct 5, 2008 at 2:43 PM, Giel van Schijndel [EMAIL PROTECTED] wrote: I would prefer to have tools as part of the code/ directory, since they are (or should be) closely linked to the rest of the code. Agreed. I would also prefer to use source instead of code. This is imprecise, because there are sources for other things than code, and this directory contains only code. Using the directory layout I proposed it'll also contain the translations (po), documentation (doc), icons (icons) and all build systems. I suppose you could interpret the build systems as being part of the code, I'm not sure how that'll apply to the other mentioned items though. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Splitting the repository into source data sections?
Christian Ohm schreef: On Sunday, 5 October 2008 at 1:50, bugs buggy wrote: With the upcoming release of the FMV patch in trunk, *before* we add the fmvs into the repo, I would like to confirm the data structure. Question: Why do you want to add those to SVN? I can understand the rest of the data (well, perhaps not the music, but that is not that large), but the FVMs? Those are large, won't really be modified and are not necessary for the game. I don't like the idea of adding the videos to our repo either... trunk/data (only pumpkin official stuff, + derivatives of their work?) trunk/code or trunk/source trunk/FMVs (since it is optional?) And even separated from the rest? What's the difference to just having a separate archive then? And when you don't have the movies in SVN, what exactly are the benefits of separating source and data? Packaging? Were there any complaints about that? The Debian packaging system easily allows the creation of separate packages from one source archive, and I'd imagine any other deserving that name does as well. Packaging by external parties is IMO a non-issue. If they have *real* issues with whatever directory layout we provide then *they* should bring that up on *this* mailing list. Considering that no such thing has been brought to this list I'd consider packaging a void argument. Redownloading changed textures? How often are those changed? I think Buginator complained about the bandwidth required comparing revisions before and after a big change. AFAIK that is the only reason. But if the src and data are separated, that won't magically make those old big changes go away, and introduce another one. No, it will definitely not solve the issues for, e.g., the PNG shrinkage revisions. It will indeed introduce a new problem (of larger scale) with the revision that performs the directory layout migration as boundary. The only advantage I can see is that, after said layout migration, huge changes to the data (such as aforementioned PNG shrinkage) will have a much less significant impact on the code when you need to jump between revisions. When put in that light changing the directory layout doesn't sound very appealing to me anymore. In fact it sounds like the wrong solution to this problem to me. IMO a better solution would be to require changes of large amounts of binary data to go through this mailing list first. Here changes would be defined as having svn status give one of these values in the first column: A, M or R. Whatever large means would have to be decided upon. And this problem seems easier solved by having the complete SVN history locally, with a tool like git-svn, hgsvn (for Mercurial) or SVK (I guess there are more, those are just the ones I know of). Yup, especially when using the history of the repo heavily I prefer a distributed solution (I'm mainly using git-svn myself). Those were the reasons listed in this thread, and both don't seem very convincing to me. Are there other advantages I have missed? The only one I know of is faster history browsing in light of large changes. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Splitting the repository into source data sections?
Per Inge Mathisen schreef: BTW - what will happen to existing, checked out working copies if the current contents of trunk/ is moved? I don't want my existing working copies to die a sudden death. If you have any changes you in any of the directories (subdirectories included) that will be moved you'll find svn update to fail halfway (i.e. fail at anything 0% progress and 100% progress). -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r6090 - /branches/2.1/ /branches/2.1/pkg/dpkg/changelog /tags/2.1_beta5/ /tags/2.1_beta5/autorevision.conf /tags/2.1_beta5/makerules/config.mk.tmpl /tags/2.1_beta5/
Dennis Schridde schreef: Am Sonntag, 28. September 2008 15:50:24 schrieb Giel van Schijndel: Tag of the `2.1 beta 5` release http://wiki.wz2100.net/Release_checklist Please follow all the steps listed there. (Missing translation import and bugtracker version increment made me notice you did not. Others may be missing as well, I did not check that.) AFAIK only project admins can do the bug tracker increment. As for translation import, honestly I haven't ever done anything with Launchpad, so I wouldn't know where to start (I saw there where only about 10ish newly translated strings though). As for the checklist, I followed it except for these two things: * Create an AutoPackage / MojoSetup * Announce the release (didn't announce through all channels yet) As for announcing, these are done: * forum/frontpage: has been done * dev mailinglist: I thought this should be done automatically by sending the forum/frontpage notice to the ML (though as of yet I didn't see anything) * IRC Channel: topic is changed, but I'm not going to spam a message constantly * ModDB: Done [1] [1] http://www.moddb.com/games/warzone-2100/news/warzone-2100-21-beta-5-released -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] buildbot failure in Warzone 2100: Resurrection Project on nightly_mingw32
Dennis Schridde schreef: Am Montag, 29. September 2008 02:07:12 schrieb [EMAIL PROTECTED]: The Buildbot has detected a new failure of nightly_mingw32 on Warzone 2100: Resurrection Project. Full details are available at: http://build.kynes.de/builders/nightly_mingw32/builds/2 Buildbot URL: http://build.kynes.de/ Buildslave for this Build: i386-debian-etch-2 Build Reason: The Nightly scheduler named 'nightly' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed compile warnings+100 This was a *desired* failure. (In reality we have 505 warnings during builds on the nightly node.) Since everything seemed to work I am removing the hardcoded warningscount and let it measure the warnings itself again. As interesting as these notices may be, could you please redirect these debug messages/mails to another e-mail address when you're just testing stuff out. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Website Status.
Dennis Schridde schreef:
Am Sonntag, 28. September 2008 01:03:31 schrieb Giel van Schijndel:
As a temporary read-only mirror: https://trac.mortis.eu/warzone/
Which gives 500 - Internal Server Error... :P
I found this traceback three times in my error log (using Trac 0.10, for
line numbers):
[Sun Sep 28 02:42:10 2008] [error] Traceback (most recent call last):
[Sun Sep 28 02:42:10 2008] [error] File
/usr/lib/python2.4/site-packages/mod_python/apache.py, line 299, in
HandlerDispatch\nresult = object(req)
[Sun Sep 28 02:42:10 2008] [error] File
/var/lib/python-support/python2.4/trac/web/modpython_frontend.py, line 87,
in handler\ngateway.run(dispatch_request)
[Sun Sep 28 02:42:10 2008] [error] File
/var/lib/python-support/python2.4/trac/web/wsgi.py, line 87, in run\n
response = application(self.environ, self._start_response)
[Sun Sep 28 02:42:10 2008] [error] File
/var/lib/python-support/python2.4/trac/web/main.py, line 331, in
dispatch_request\nraise ValueError('TracUriRoot set to %s but request URL
'
[Sun Sep 28 02:42:10 2008] [error] ValueError: TracUriRoot set to /warzone
but request URL is https://trac.mortis.eu/warzone/
I'm not sure why it says request URL is %s because looking at the code
I see it extracts that value from the environment variable REQUEST_URI
(a URI is the part of the URL that comes after the hostname). So I also
don't understand how a full URL could find its way into the REQUEST_URI
environment var.
--
Giel
signature.asc
Description: OpenPGP digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Website Status.
Kamaze schreef: In before I get bombed with questions about it: wz2100.net is currently down. A libc6-xen update yesterday doomed my whole DomU and the Xen-Deamon seems to be stuck with my DomU. I can't kill/pause/unpause/burn it. So, i have to restart the Dom0, which is a bit difficult because some other people will rape me when I do this without a prior notice and something goes wrong. So I have to wait that everyone is informed about the maintenance, then I can start to work on my DomU problem. In the worst-case I have to re-setup my whole machine, in best case there is a new update or I can undo the update by installing the prior libc6 package. Depending on how much work is approaching, it is possible that the website will be completely down until Tuesday, because I write an exam on Tuesday and that has a higher priority for me than the website. And in before Giel or someone else asks, I can't let the domain point to some other server, because the overall latency for requesting the A-Record will be commonly 2-3 days, *2 for changing back. I am very sorry for the inconvenience and will engage this as soon as possible. As a temporary read-only mirror: https://trac.mortis.eu/warzone/ -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Vote for what you think is best.
bugs buggy schreef: On 9/24/08, Giel van Schijndel [EMAIL PROTECTED] wrote: bugs buggy schreef: On 9/22/08, Freddie Witherden [EMAIL PROTECTED] wrote: This is not a good use of developer time -- which could be better spent on 2.2 -- ensuring that we never get into this situation again. This about sums it up. Developer time is short, so we need to do what will be best for developers. The whole predicament of not having a release for such a long period of time *IS* the problem. So we agree on the problem: we need a release soon. The difference is that I think we can get 2.1 out faster than we can get 2.2 out. I don't really know what you mean by getting 2.1 faster out the door than 2.2. We would have to do the same thing for 2.1 beta 5, or 2.2 alpha/beta 1. Just tag them, and compile it, and then have the build bot create it right? That takes care of windows. For 2.2 from trunk we'd have to get rid of several changes to keep those out of a release for now. E.g. the SQLite stuff as it's only half done, and I don't intend to maintain that stuff when it's only half finished. There may be more things that require ripping out before release. If you were thinking, to remove features from 2.2 for the release, then I see no (good) reason you should do that. We *want* to know all the issues involved with 2.2 (trunk). Allowing features to enter also means obligating ourselves to maintain them. Read above for SQLite... We do *not* want to have a repeat of beta 4 again, we do *not* want to wait many months to find out that someone made something worse, and then they have no time to fix the faulty patch now. We *do* want as many testers as possible. Agreed, but some code could be considered too experimental for release (but stable enough for trunk). I don't want to waste time on maintaining experimental code in a release. If it makes you feel better, we can do a multi-release. By that, I mean have a 2.1 beta 5, and have a 2.2 alpha/beta 1 release candidate. Sure, and AFAIK we can release 2.1_beta5 right now. I.e. take current 2.1 HEAD, tag it and release the tarballs (binaries would have to come in later). -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Vote for what you think is best.
Per Inge Mathisen schreef: Also, if we release something directly from trunk without creating a release branch for it, I think we should not call it a beta. Let's call it an alpha-1 release. (I do not think we want to maintain two release branches at the moment.) Actually I'd prefer not to release the current half finished state of the SQLite stats stuff, so it'd have to be removed before release. These kind of changes are easiest done in a release branch IMO. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] 2.1_beta5
Hi all, In the Vote for what you think is best thread we seemed to have reached some form of agreement on releasing both 2.1 beta5 alongside a 2.2 beta/alpha/thingy directly from trunk or a release branch otherwise. In any case, I'm starting this thread for one reason only. I think we should tag of 2.1_beta5 and start the release cycle for that ASAP (i.e. a tag and tarball should be available by the end of the weekend). Any objections or votes in favour? -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.1_beta5
Zarel schreef: 2008/9/25 Giel van Schijndel [EMAIL PROTECTED]: Hi all, In the Vote for what you think is best thread we seemed to have reached some form of agreement on releasing both 2.1 beta5 alongside a 2.2 beta/alpha/thingy directly from trunk or a release branch otherwise. In any case, I'm starting this thread for one reason only. I think we should tag of 2.1_beta5 and start the release cycle for that ASAP (i.e. a tag and tarball should be available by the end of the weekend). Any objections or votes in favour? So are we going to fix pathing in 2.1b5? Fixed already, at the cost of breaking savegames made with 2.1_beta4. (Which was the cause for this whole discussion.) Heck, why don't we just backport the threaded pathing from 2.2? That can't be worse than the other pathing fix. Backporting the threaded path finding proved next to impossible, which is the reason for the above fix which broke loading of 2.1_beta4 savegames. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Version numbering
Dennis Schridde schreef: I'd like to hear your opinions, ideas, insights. Maybe you've got a different/better idea how to prevent long times of silence between releases? Quick short: I'd rather release early and often (with some bugs) than less often with less frequent testing. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Vote for what you think is best.
Per Inge Mathisen schreef: On Mon, Sep 22, 2008 at 6:08 PM, Freddie Witherden [EMAIL PROTECTED] wrote: I still think that SQLite is the way to go, so far as future proofing goes. Going straight to tagfile makes it a lot harder to go to SQLite later on (two converters needed etc.). The advantages of a database are also numerous, firstly data abstraction and secondly in viewing/ using the data outside of Warzone (e.g for debugging purposes, as any SQLite viewer could be used). Perfection or progress - pick one. There ain't no such thing as perfection (i.e. not as an achievable goal). So if these are the options I pick the one that has the greatest chance at success: progress. I don't even see anyone working on the stats sqlite stuff for a long while. Time being the limiting factor. I'm currently drowning in school work, and honestly I don't expect that to change any sooner than several months from now. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Vote for what you think is best.
bugs buggy schreef: On 9/22/08, Freddie Witherden [EMAIL PROTECTED] wrote: This is not a good use of developer time -- which could be better spent on 2.2 -- ensuring that we never get into this situation again. This about sums it up. Developer time is short, so we need to do what will be best for developers. The whole predicament of not having a release for such a long period of time *IS* the problem. So we agree on the problem: we need a release soon. The difference is that I think we can get 2.1 out faster than we can get 2.2 out. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Nightly build of r6063 failed
Giel van Schijndel schreef: Building of the nightly build failed for revision r6063 [1] when trying to build a debug executable. Short of disk space: fixed. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] FMVs phase 2 complete
On Fri, Sep 19, 2008 at 01:44:28AM -0400, bugs buggy wrote: Phase 2 has been completed. FMVs are now working for the intel screen, as can be seen by that thread. I am using GL_TEXTURE_RECTANGLE_ARB to get around the NPOT textures. How about only using GL_TEXTURE_RECTANGLE_ARB when GL_ARB_texture_non_power_of_two isn't available? As GL_TEXTURE_RECTANGLE_ARB doesn't provide normalized texture coordinates. On another side note: I noticed that the YUV decoding is currently done in software. This is currently done by copying from one memory buffer (containing the image YUV or YCbCr encoded) and converting to RGB to another memory buffer. Not only will that probably take a lot of time, in addition it is quite likely that copying the RGB buffer after the YUV-RGB conversion will stall the pipeline. I have been looking into doing YUV-RGB conversion using a GL shader for school today and I think it might be a good idea to use that approach for Warzone as well. Falling back to the software approach if no shaders are available of course. Either way, I'll look further into this. The resolution is pretty low, and there isn't much that can be done about that, unless we do that scanline doubling that we talked about before. That helps a bit, but is no real substitution for higher-res FMVs. Phase 3 is code cleanup. I've taken a good look at that patch today. And I'll be happy to clean that patch up significantly. In fact, just to prevent going through withdrawal from my code cleanup addiction :-P , I already did some clean up to that patch this morning. Large parts of it are just throwing away of commented out and otherwise dead code. If any commented out code should not be removed I think the reason why it's commented out should be added as a comment as well. Otherwise I'll just throw it away. In either case, I'm using git to make these changes so that I can have a stacked patch (i.e. a patch against the patched FMV code) alongside the patch against Subversion HEAD. So I'll just attach both to the ticket when I've got some results. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] FMVs phase 2 complete
Kreuvf schreef: bugs buggy wrote: Would anyone object if I encoded the sound into the video? Or is it better to leave it as it is now?) Afaik sound and video were separated with the intention of distributing the same video material with different sound files (for every language). The original game came with translated videos and the new licence does not explicitly limit us to the English version of the videos. By doing it that way not only disk space would be saved, but also traffic (people need to download the video material only once and then small sound files for every language they want to play the game in). Ogg supports the notion of putting multiple (translated) audio streams in the same file. So the overhead of video duplication shouldn't exist there. Although for the purpose of editability I think it'll be easier if audio is separated from video. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r6054 - in /branches/2.1: ./ data/tagdefinitions/savegame/ src/ win32/
Giel van Schijndel schreef: Author: muggenhor Date: Sat Sep 20 14:37:22 2008 New Revision: 6054 URL: http://svn.gna.org/viewcvs/warzone?rev=6054view=rev Log: Fix bad pathfinding performance: * (Attempt to) fix the bad pathfinding by reverting r4637:4639 which removed the gateway zones and raycasting optimisations * Break loading of savegames made with 2.1_beta4 or trunk * Don't crash with 2.1_beta4/trunk savegames, dump an error message on LOG_ERROR and return false from the loading function (causing an exit(EXIT_FAILURE)) Added: branches/2.1/src/gatewayroute.c - copied unchanged from r4636, trunk/src/gatewayroute.c branches/2.1/src/gatewayroute.h - copied unchanged from r4636, trunk/src/gatewayroute.h The XCode project will require an update for this change. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Call for testing of pathfinding patch
Freddie Witherden schreef: From my point I think our options are: - Try *again* to backport the multi-threaded pathing. I've tried that *before* reverting r4637, and failed miserably. (Way too much API changes to do within 2 whole days). - Skip 2.1 and go straight to 2.2 with FMV support. How about providing an optional 2.1 release for those who wish to use that first? - Re-base 2.1 from trunk. No, IMO current trunk should become 2.2, definitly not 2.1 -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Call for testing of pathfinding patch
Per Inge Mathisen schreef: On Tue, Sep 16, 2008 at 10:09 PM, Giel van Schijndel [EMAIL PROTECTED] wrote: That area of memory is currently memset(0) before writing to disk right? We could try to take some fail gracefully approach and reject the savegame if that piece of memory is zero. Where fail gracefully means display some nice error message to the user explaining the problem. Unless someone has some other way to handle this. We are actually so lucky that the zone information is at the very end of the savegame, so we can check for EOF when done with everything else, and return false from the load functions if nothing is found. I updated the patch to check for the absence of zone information and return false if that's the case. What then happens next, I do not know, but I fear there are lots of asserts waiting in ambush... Nope, no asserts, several debug() calls yes, but no asserts. Also I've traced the calling tree down to one function: loadGameInit which'll return false whenever game loading fails. This function is only called by initSaveGameLoad (main.c) and startMission (mission.c), the latter being only used to load campaign missions (not savegames). Thus the only function that should be of a concern to us in this regards is initSaveGameLoad. Currently this function calls exit(EXIT_FAILURE) if loadGameInit fails. That's the place where the behaviour should probably be altered such that instead we display some in-GUI message to the user. (Especially for the non-terminal systems: Max Windows). -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Call for testing of pathfinding patch
Per Inge Mathisen schreef: Though, if this means we can finally release 2.1, I'm for breaking compatibility. However, *crashing* on current savegames is simply not an acceptable outcome. That area of memory is currently memset(0) before writing to disk right? We could try to take some fail gracefully approach and reject the savegame if that piece of memory is zero. Where fail gracefully means display some nice error message to the user explaining the problem. Unless someone has some other way to handle this. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Why does 'make' build .wz files now?
Per Inge Mathisen schreef: So I read http://developer.wz2100.net/ticket/62 and I do not understand what kind of problem this patch was supposed to solve. The complexity of the makefiles. It is not acceptable that we regenerate .wz files for every 'make'. We are far from guaranteed that the creation of .wz files are going to be a fast process in the future, when we start using pre-compressed textures, pre-compiled lua modules, and whatnot. Only the first make invocation should be slow. From that point onward updates should only occur when the timestamp of a file in data becomes more recent than that of the .wz file. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Moving the repository off gna.org
Dennis Schridde schreef: I do not know how it is after the addition of /originals (did someone ask the git-svn users before...?). The last time, when there were weird non-standard directories mixed with standard directories in a standard-layout-git-svn import, it messed up the repos quite nicely. Which was also the reason to refactor the svn history to correct those issues... But of course that could be corrected again. /originals is currently completely ignored by git-svn -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Moving the repository off gna.org
bugs buggy schreef: On 9/13/08, Per Inge Mathisen [EMAIL PROTECTED] wrote: Ok, I think we have given gna.org enough time to fix their problems. Can you people please indicate what _your_ preferred future direction for the repository is? 1) Wait more for gna.org to solve their problems. We have waited, and it is *highly* annoying to keep getting shut out of the svn server like it has been doing. Will this get fixed? Unknown, since they don't respond to questions in a timely matter, even though it is the highest priority. https://gna.org/support/index.php?2059 AFAIK, the only one that is really having a issue with them is me. :( Other members either don't have the issue at all, or it pops up now then, but goes away. Oh believe me, you're definitely *not* the only one. I'm having plenty Gna! troubles as well. The difference is that I'm not using a GUI client, but the command line client that can be scripted in a bash while-loop quite easily. 2) Use sf.net. All the projects that I pulled source from them, seemed to work fine. I really don't like sourceforge and their throw-it-full-with-banners approach at all. 6) Some other subversion hosting service with offsite backups (please name your preferred alternative). I have no idea of the + or - of these, I just did some searching. GoogleCode? http://code.google.com/ gforge? http://gforge.org/ alioth ? http://alioth.debian.org/ savannah ? http://savannah.gnu.org/ What about using multiple sites? I just wonder how to mirror all the changes on one host with the other? Savannah is only for GNU projects (which we're not). As for GoogleCode and GForge, I haven't got much experience with those. Alioth might be a good option though, never had any problems with that. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
