On Sun, Aug 24, 2008 at 5:42 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote:
> * Change an ASSERT that checks calloc's return value into an if() block (we
> can also run out of memory on non-debug builds...)
I am also rather mystified by this. When we fail to allocate memory
and do not handle
On Sun, Aug 24, 2008 at 11:12 PM, Dennis Schridde <[EMAIL PROTECTED]> wrote:
> Aside of that I think we could add a out-of-memory "handler", or some more
> generic way of handling the most common errors.
> Why? So we can inform the user in a nicer manner than "application X was
> terminated in an u
On Mon, Aug 25, 2008 at 2:41 AM, Giel van Schijndel <[EMAIL PROTECTED]> wrote:
> Then lets discuss it now. Unfortunately I'm not too good at estimating
> what kind of changes you would like to discuss before committing and
> which not.
Then try to err on the side of caution.
>> So my most pertine
On Mon, Aug 25, 2008 at 2:29 AM, Giel van Schijndel <[EMAIL PROTECTED]> wrote:
> Hmm, the "program defefensively" I've learned to know means "try to
> *detect* and handle every/most errors" it doesn't mean recovering from
> them. That's just a terminology issue though, so don't interpret that
> las
On Mon, Aug 25, 2008 at 5:03 AM, bugs buggy <[EMAIL PROTECTED]> wrote:
> About these guidelines, take this:
>
> " Patches as a rule go into the patch tracker. Give a quick run down of what
> it does and what it changes."
>
> Does it matter which tracker?
No. But if the tracker doesn't email the li
On Mon, Aug 25, 2008 at 12:40 PM, Freddie Witherden
<[EMAIL PROTECTED]> wrote:
> The patch can be found here: http://developer.wz2100.net/ticket/38
>
> I believe, if deemed suitable for trunk that it should be a candidate for
> backporting to 2.1 (otherwise OS X users will most likely experience
>
On Mon, Aug 25, 2008 at 2:59 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote:
>> No. But if the tracker doesn't email the list, please do so manually.
>
> NOTE: Setting up Trac to send a mail to the mailinglist for every
> *change* to a ticket (includes ticket creation) is trivial.
That is fine b
On Mon, Aug 25, 2008 at 9:52 PM, bugs buggy <[EMAIL PROTECTED]> wrote:
> "Single Player / Skirmish Game"
I think this will get too long. Why not just keep it "Single Player"?
It is short, descriptive and accurate ;-). Other than that, fine by
me.
- Per
On Mon, Aug 25, 2008 at 3:41 PM, Freddie Witherden
<[EMAIL PROTECTED]> wrote:
> Am I okay to commit it to trunk?
Sure.
> (We don't have a translation mailing list do we?)
Maybe we should.
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https
On Tue, Aug 26, 2008 at 6:21 AM, bugs buggy <[EMAIL PROTECTED]> wrote:
> If it is just 'Single Player', then I think the old timers might get
> confused, since before, skirmish was in the MP menu?
I am more than willing to trade two seconds of confusion by old timers
the first time they see it for
On Tue, Aug 26, 2008 at 8:32 PM, Kreuvf <[EMAIL PROTECTED]> wrote:
> bugs buggy wrote:
>> Now, last question, should 'Skirmish' be in both SP & MP menus, or just
>> leave it in the SP menu?
> I think it should be in the SP menu only. People, especially those new to WZ,
> will be confused by two see
One questiton, though: Which OpenGL ES does it support? OpenGL ES 1.0
uses the fixed pipeline functionality, like us, while OpenGL ES 2.0
relies on shaders.
The more important question: Does an RTS game like Warzone run well on
a handheld console? I think the game requires a mouse, unless you want
On Sun, Aug 31, 2008 at 12:47 PM, Freddie Witherden
<[EMAIL PROTECTED]> wrote:
> It would appear so. A while back a group got 0.2.3 running on the
> Maemo platform (as used by the Nokia N800 and N810 series).
> http://www.internettablettalk.com/forums/showthread.php?t=16502
> The game seems popul
On Thu, Sep 4, 2008 at 5:55 AM, bugs buggy <[EMAIL PROTECTED]> wrote:
>> >> liboggplay : http://annodex.net/software/liboggplay/
>> > NOT in Portage
>>
>> Debian doesn't have it either.
Can't we just put it in our tarballs, if we need it?
- Per
___
W
Attached is a patch to remove the need for GL_ARB_texture_rectangle
for the radar code. I suppose a similar approach could be used for
betawidget. The complexity of manipulating texture coordinates can be
hidden by an abstraction layer.
- Per
Index: lib/ivis_opengl/pieblitfunc.c
On Mon, Sep 8, 2008 at 9:57 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote:
>>> - Did we ever decide how we were going to provide lua? I know a
>>> while back we were talking of embedding it the same way we do with
>>> SQLite, comments anyone?
>> Include and --with-lua=system optional. My vote,
I just tried 'make' of the latest svn trunk, and it started zipping up
my data directory. This seems very wrong. So I read
http://developer.wz2100.net/ticket/62 and I do not understand what
kind of problem this patch was supposed to solve.
It is not acceptable that we regenerate .wz files for ever
On Tue, Sep 16, 2008 at 9:21 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote:
> In fact I'd like for some people to test this patch and comment on it.
> E.g. whether it improves performance and doesn't introduce any new bugs.
Hard to test when all my current savegames will not work.
> Also, yes,
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
On Sat, Sep 20, 2008 at 2:03 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote:
> Although for the purpose of editability I think it'll be easier if audio
> is separated from video.
I doubt that. If you are going to do video editing, all the better if
the audio is properly included.
- Per
_
I find it rather funny that you are seriously discussing optimization
techniques that only the fastest computers can run, those that will
not have speed problems anyway.
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listi
On Mon, Aug 18, 2008 at 8:33 AM, Per Inge Mathisen
<[EMAIL PROTECTED]> wrote:
> On Mon, Aug 18, 2008 at 12:42 AM, Dennis Schridde <[EMAIL PROTECTED]> wrote:
>> Per, will you do this, since you are currently working on patch #1095 ("Make
>> font configurable&
On Mon, Sep 22, 2008 at 10:36 AM, Dennis Schridde <[EMAIL PROTECTED]> wrote:
> 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?
I like the current way, and do not think we can manage to create
relea
On Mon, Sep 22, 2008 at 5:24 PM, Dennis Schridde <[EMAIL PROTECTED]> wrote:
> How far are the tagfile and database ideas? Any progress there? I know the
> tagfiles basically seem got stuck after the early phase of implementing the
> framework functions...
There is a separate tagfile branch, which
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 a
One idea: How about using just one repository, but shaped like this:
trunk/
branches/
tags/
then a next level (example from inside trunk):
trunk/code/
trunk/data/
trunk/originals/
so if you wanted to download the latest of all, you would do svn up on
trunk, while if you wanted to just grab a ne
On Thu, Sep 25, 2008 at 7:22 AM, bugs buggy <[EMAIL PROTECTED]> wrote:
> Ok, lets do it.
>
> Release 2.1 beta 5.
> Release 2.2 alpha / beta 1.
>
> Let them have a choice on which version they want to play.
>
> I would think they would want 2.2 for the FMVs, and the improved path
> finding, and they
On Thu, Sep 25, 2008 at 8:19 PM, Dennis Schridde <[EMAIL PROTECTED]> wrote:
> Unmaintained in a way that bugfixing has no priority (yet).
I can't believe you are saying that. Bug fixing should *always* have priority!
Maybe I am starting to understand why we are in this mess now...
> At least for
On Thu, Sep 25, 2008 at 10:10 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote:
> 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.
>
>
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
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 imprecis
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.
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/list
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 workin
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 s
On Mon, Oct 6, 2008 at 11:02 AM, Giel van Schijndel <[EMAIL PROTECTED]> wrote:
> 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
On Fri, Oct 10, 2008 at 3:17 PM, Kamaze <[EMAIL PROTECTED]> wrote:
> I would pretty love to have the ability to rate buildings in game. I
> would like them mainly for the sake of base aesthetics, but it would
> also make the game play a little bit better.
For what it's worth, I agree. This would b
On Mon, Oct 13, 2008 at 11:55 AM, Dennis Schridde <[EMAIL PROTECTED]> wrote:
> What might have caused your confusion is that a buildbot build can run through
> all steps completely, even if the overall build will be marked as a failure.
> I decided an increase in warnings to be a failure, so we get
On Mon, Oct 20, 2008 at 12:38 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote:
> 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.
Unfortunately, we get to deal with their bug reports
On Sun, Oct 26, 2008 at 7:33 PM, bugs buggy <[EMAIL PROTECTED]> wrote:
> I have modified the roadmaps to make them more realistic.
Good. Should we retire the wiki page?
> Look at http://developer.wz2100.net/roadmap
>
> AFAIK, roadmaps are not supposed to be wish lists, and that is what
> they we
On Tue, Nov 4, 2008 at 8:46 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote:
>> qwzm: Move conversion functions into their own file. Add TODO messages to
>> stdout for stuff that doesn't work.
>>
>> Modified:
>> trunk/tools/qwzm/qwzm.cpp
>> trunk/tools/qwzm/qwzm.h
>> trunk/tools/qwzm/
On Tue, Nov 11, 2008 at 1:05 AM, Gerard Krol
<[EMAIL PROTECTED]> wrote:
> The tile drawer was allocating and using a vertex array the size of the whole
> map, now it only has one big enough to fit the visible tiles.
This was actually a feature, a step on the way to making the viewable
size dynami
On Sun, Nov 16, 2008 at 12:14 PM, Kreuvf <[EMAIL PROTECTED]> wrote:
> How about copying it over to the Wiki?
If you find a good place for it, feel free.
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
On Sun, Nov 16, 2008 at 12:05 PM, Per Inge Mathisen
<[EMAIL PROTECTED]> wrote:
> The commit flood: Having been bitten by the superhuman commit, you
> split your work instead into dozens if not hundreds of separate
> commits. Guaranteed to make anyone who tries to follow the commit l
There are various ways you should not commit things into a version
control system. Let's go through some of them:
The commit & run: "I have to go now or I'll be late for...", then you
commit today's work and bolt out the door. A sure way to see to that
your colleagues sit late or go home early, de
On Sat, Nov 29, 2008 at 6:13 PM, Dennis Schridde <[EMAIL PROTECTED]> wrote:
>> Mixing and matching mods is never a good idea. If we encouraged it
>> then it would just lead to more useless bug reports.
> That's all the fun. ;) Multiple mods. Of course there'd be incompatibilities,
> but that should
On Sun, Nov 30, 2008 at 1:17 PM, Gerard Krol
<[EMAIL PROTECTED]> wrote:
> Perhaps we should integrate the tiny mods in the game (and make them
> inter-operate well), and then only allow one external mod active at a time.
That is a really good idea.
- Per
___
On Fri, Dec 5, 2008 at 9:29 PM, Kamaze <[EMAIL PROTECTED]> wrote:
> 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 & aut
On Thu, Dec 25, 2008 at 3:51 PM, Gerard Krol
wrote:
> Merry Christmas! We have only just released 2.1, but I think we should
> be deciding on the next release already.
>
> The two points to consider are:
> * what do we want to include?
> * when do we want to do the release.?
>
> We currently have
On Thu, Dec 25, 2008 at 6:39 PM, Dennis Schridde wrote:
> WZM was the new module format, iirc. I have not seen any specs on that
http://wiki.wz2100.net/WZM_format
> let alone code.
See tools/qwzm. Rendering code is in tools/display. I just need to
write a mass converter, then stuff that display
On Thu, Dec 25, 2008 at 11:55 PM, Dennis Schridde wrote:
>> New: All artwork from the original game now confirmed as released under the
>> GPL v2 or later.
> Was this not already in 2.1?
Ok. Will remove.
- Per
___
Warzone-dev mailing list
Warzone-de
On Tue, Dec 30, 2008 at 12:36 PM, Dennis Schridde wrote:
> Am Dienstag, 30. Dezember 2008 05:04:33 schrieb Dennis Schridde:
>> Author: devurandom
>> Date: Tue Dec 30 05:04:32 2008
>> New Revision: 6521
>>
>> URL: http://svn.gna.org/viewcvs/warzone?rev=6521&view=rev
>> Log:
>> GCC complained in scr
This patch adds a new cheat "noassert" which turns off asserts. ASSERT
calls will still generate log entries, but not take down the program.
This is meant for testing that code hit by an assert bug has
sufficient error handling that it can survive when compiled without
assertions. Which it always s
On Thu, Jan 1, 2009 at 3:39 PM, Per Inge Mathisen
wrote:
> This patch adds a new cheat "noassert" which turns off asserts. ASSERT
> calls will still generate log entries, but not take down the program.
> This is meant for testing that code hit by an assert bug has
> sufficie
On Thu, Jan 1, 2009 at 4:26 PM, Dennis Schridde 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.
> And there are still assert()s, which are di
On Thu, Jan 1, 2009 at 6:30 PM, Dennis Schridde wrote:
> Am Donnerstag, 1. Januar 2009 18:22:40 schrieb Per Inge Mathisen:
>> On Thu, Jan 1, 2009 at 4:26 PM, Dennis Schridde wrote:
>> > Can you not just skip asserts in the debugger?
>>
>> Can you? Ever since the cra
On Sun, Jan 4, 2009 at 10:54 PM, bugs buggy wrote:
> I was just curious, since the release of 2.1, what is the plan for the
> next version?
> I was thinking that 2.2 should be branched from trunk, and then we
> could pretty much make a release from that ASAP.
I am pretty much thinking the same th
On Mon, Jan 5, 2009 at 6:37 PM, Giel van Schijndel wrote:
> Can't we set Gna's trackers to read-only or disable the ability to
> create new items? (The latter would be preferrable).
Not that I'm aware, no.
> As for porting, Gna! provides the ability to export the entire content
> of a tracker as
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 re
On Sat, Jan 31, 2009 at 7:43 AM, bugs buggy wrote:
> I was thinking we may do something like a ASSERT_ENTER() as well
How would it work?
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
On Sat, Jan 31, 2009 at 4:05 PM, Giel van Schijndel wrote:
> 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 "_
On Sun, Feb 1, 2009 at 11:55 PM, Giel van Schijndel wrote:
> 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
This patch introduces the (currently unused) function bool
fpathCheck(Vector2i, Vector2i) that checks whether a path is
theoretically possible in O(1) time. It does this by doing lookups a
pre-calculated continents table that is created on map load using a
non-recursive flood fill algorithm. It is
On Sun, Feb 8, 2009 at 9:24 PM, Dennis Schridde wrote:
> Is this a replacement for the zones/gateways? Or something in that direction?
No. But if we ever added an attribute to path finding so that you
could create paths without a nearest fallback, it could be used to
optimize path-finding for tho
On Sat, Feb 14, 2009 at 6:50 AM, bugs buggy wrote:
> As for your issue, I think you are making it much more complex than it
> needs to be.
> All current maps have the gateway system, and that is what the game
> used before to determine where to send the units.
We all know how buggy that was, so w
On Sat, Feb 14, 2009 at 9:22 PM, bugs buggy wrote:
> In the patch, you mention "FIXME: This is not entirely correct for all
> possible maps." What types of maps does it have issues with now?
Currently assuming that we can fly to all locations on the map from
any other location on the map. Also
Hello devs,
We all know that the current and past state of the Warzone codebase is
a rather sorry excuse for something. There are so many globals all
over the place, that it is almost impossible to separate out code for
proper unit testing or reuse. The code is buggy, and we do not have a
process
On Wed, Feb 18, 2009 at 11:03 AM, Dennis Schridde wrote:
> Am Mittwoch, 18. Februar 2009 09:54:59 schrieb Giel van Schijndel:
>> On Tue, Feb 17, 2009 at 07:10:22PM +0100, Per Inge Mathisen wrote:
>> > 2) has *at least* one unit test,
>> > 3) uses *no* globals,
> BTW:
On Thu, Feb 19, 2009 at 12:47 PM, Gerard Krol
wrote:
> Per Inge Mathisen wrote:
>> I would like to suggest that we start refactoring the Warzone codebase
>> so that it can more easily be unit tested aggressively.
>>
> Would it be an idea to wait for the merge from the terr
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.
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
On Sat, Feb 21, 2009 at 10:41 PM, Bugs Buggy wrote:
> Adds some checks to detect NULL pointers in these two functions which
> resulted in crashes.
I think this should be back ported to 2.1, too.
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.or
On Sat, Feb 21, 2009 at 11:54 PM, Bugs Buggy wrote:
> Fixes issue with picking a 'invalid color flag' (for SP) in a MP game, and
> then trying to go to the game options screen to change whatever.
Backport?
- Per
___
Warzone-dev mailing list
Warzone
Hello,
I have updated the 2.1 branch with backports of fixes that I am quite
sure of, and I think it is worth doing a 2.1.2 release from it quite
soon. If anyone else have fixes that they are very confident about,
please commit them to 2.1 branch now, or let me know that it should be
merged first.
On Sun, Feb 22, 2009 at 7:06 PM, Guangcong Luo 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
On Sat, Feb 28, 2009 at 4:36 AM, Bugs Buggy wrote:
> *Actually remove features, and notify others that the feature was removed.
> (AKA, actually sync between machines.)
I would appreciate if you would not mix bug fixes and feature changes
(timer controlled drum spawning). As I see it, this must
Hello,
I have been doing some backporting for Buginator today, because he has
such trouble getting into gna.org (a subject worth a discussion of its
own), but I have noticed that he is not the only one who is forgetting
to backport changes. We now have a 2.2 branch that pretty much
everyone agreed
On Sat, Feb 28, 2009 at 11:46 PM, bugs buggy wrote:
> I hate to spam the list with the same question again, but is there any
> *good* reason why we still support 2.1, and not just go directly to a
> 2.2 release instead?
>
> Has anyone notice anything that is a show stopper for 2.2?
No, but I am
On Sat, Feb 28, 2009 at 10:42 PM, bugs buggy wrote:
>> As I see it, this must be the bug
>> fix part:
>> + // Since ANYPLAYER is supposed to be controlled by host only, that
>> creates a issue when
>> + // a MP player gets a feature, and it is 'ANYPLAYER' it would never
>> send th
On Mon, Mar 2, 2009 at 8:18 AM, Gerard Krol wrote:
> I would like to propose we switch to Git (http://git-scm.com/) for our
> version control needs.
I am all for it and have suggested it before, but our only real and
active Windows user needs to check that git is good enough on Windows.
Not just
I have nothing much to add to the general discussion, except that I
think we should look for people who can make distro-specific packages
that we put on our web page. I can make them for the latest Fedora
version, for example.
- Per
___
Warzone-dev ma
On Fri, Mar 6, 2009 at 1:05 PM, Freddie Witherden wrote:
> I am not going to be around much over the weekend and so would appreciate it
> if we could get 2.1.2 and 2.2 alpha1 (or beta1) tagged so that I can build
> the required Mac binaries.
>
> Unless there are any blockers which I am not aware o
On Sat, Mar 7, 2009 at 2:06 AM, bugs buggy wrote:
> I did some version checking code (which was in the game before, why
> was it removed?), for trunk/2.2, and we can't fix it so that it can't
> connect between 2.1.x to trunk/2.2
>
> With the version checking code, the net code is too different in
Hello,
The sound fix seemed to have some issues, so it will have to wait. I
have tagged the 2.1.2 release now, and people who want to build
binaries for various platforms please reply now to let me know that
you have work in progress for the formal release.
Thanks.
For 2.2-beta1, I need to know
Let's all test the new git repositories a bit before moving the
official repository to it.
Personally I am scared by things like this:
On Fri, Mar 13, 2009 at 11:49 AM, Dennis Schridde wrote:
>> Devurandom has convinced me that a shared repository (with multiple
>> people pushing to) does not wo
We had something akin to what is described to the "git way" of doing
version control in the Berlios days. Each developer wanting to do
something was given his own branch, and then "someone" would somehow
merge stuff for a release. It was a disaster. We need an official
repository that everyone work
On Sat, Mar 14, 2009 at 4:03 PM, Dennis Schridde wrote:
> Am Samstag, 14. März 2009 13:51:33 schrieb Per Inge Mathisen:
>> We need an official
>> repository that everyone work up against, directly or indirectly, and
>> unless I am mistaken, even the linux kernel has this.
On Sun, Mar 15, 2009 at 6:15 PM, bugs buggy wrote:
> Then there is port 2100 :)
Too good to pass over. IMHO.
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
When changing and removing files, will you please check that you do
not break 'make dist'?
All you (usually) need to do is to list the correct headers in
noinst_HEADERS in Makefile.am
However, right now the mods are giving me problems.
The issue I get is:
make[4]: *** No rule to make target `aiv
On Sat, Mar 14, 2009 at 10:20 AM, Elio Gubser wrote:
> new wheels propulsion graphics by Mysteryem. including a slight change to the
> texturing on the light wheels
>
> Modified:
> trunk/AUTHORS
> trunk/data/base/components/bodies/drhbod11.pie
Why was the python body changed? It now looks
On Mon, Mar 16, 2009 at 9:03 PM, Per Inge Mathisen
wrote:
> On Sat, Mar 14, 2009 at 10:20 AM, Elio Gubser wrote:
>> new wheels propulsion graphics by Mysteryem. including a slight change to
>> the texturing on the light wheels
>>
>> Modified:
>> trunk/AUTHORS
Developers often mistake the opinions of a vocal minority of users
with the best interests of their users. It is an easy mistake to make.
Sometimes, when trying to imagine what users want, we even manage to
entirely confuse our imagination with a reality that may be quite
different. I have come to
2009/3/18 Dennis Schridde :
> Why "remove"? I would just hide the option, so "expert users" can still access
> it, but it is officially vanished. It might be of use later, i.e. when quickly
> testing before/after stuff, comparing two changesets, or something like that.
Yes, that is what I was thin
On Sat, Mar 21, 2009 at 6:12 PM, bugs buggy wrote:
> I know it did a checksum for the program, but it don't look like they
> did any checksum for the .wdg files?
IIRC the checksum was generated from the data structures loaded into memory.
- Per
___
2009/3/29 Freddie Witherden :
> Backport a fix to the anti-painting system to 2.1.
>
> Modified:
> tags/2.1.2/src/structure.c
Wrong branch...
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
On Mon, Mar 30, 2009 at 4:14 PM, Git SVN Gateway
wrote:
> Fix ticket #293: Crashes in netlog code.
Did you find the same fix hidden in my 2.2 branch, too? ;-)
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzo
> Commit Rebalance 0.4.1
> Changelog:
> - Cyborgs further balanced. Not only should they be usable, they should be
> fairly well balanced within themselves now (Next: VTOLs!)
> - Weapon multipliers massively rearranged.
> - Cannons/Rails split from Rockets/Missiles, no longer both anti-tank.
The
On Wed, Apr 1, 2009 at 10:57 AM, Zarel wrote:
> There are simply too many and too trivial to list by hand.
I am not asking for a long list of everything, just a bit more
detailed than "Cannons/Rails split from Rockets/Missiles, no longer
both anti-tank."
I would really love to know, for example
On Wed, Apr 1, 2009 at 9:48 AM, Florian Schanda
wrote:
> I am looking into writing a python API for *writing* warzone maps, in
> particular multiplayer maps. I had some questions on the files for each map -
> if somebody could
> a) point me to the relevant source code that parses them
> b) tell me
On Thu, Apr 2, 2009 at 11:00 PM, Florian Schanda
wrote:
> In that map, there are gateways and zones (and equivalency zones). What are
> they - and are they strictly necessary?
In 2.2 and later, gateways are only used by the AI as hints as to
where to place defenses. If empty, the AI will use othe
People and Developers,
Since gna.org has trouble providing the level of service we need, we
have to look for alternatives. As far as I can tell, Google has not
responded to our request for more storage space. Git has issues with
portability, and leaves a few open questions as regards to how to
org
On Sat, Apr 4, 2009 at 11:14 PM, Dennis Schridde wrote:
> Am Samstag, 4. April 2009 22:40:16 schrieb Per Inge Mathisen:
>> So I would like to propose that we use sf.net for
>> (only!) svn service, about which I have heard no complaints as regards
>> uptime or access.
> Ad
401 - 500 of 763 matches
Mail list logo
