Launchpad looks rather nice, although there are some things I do not
quite understand yet, like the difference between
https://launchpad.net/warzone2100
and https://launchpad.net/~warzone2100, and whether they offer
subversion hosting, or just bazaar.
Basically, though, I have still to see
On Fri, Mar 21, 2008 at 11:38 PM, Dennis Schridde [EMAIL PROTECTED] wrote:
I would like to ask whether anyone has objections against merging ivis_common
and ivis_opengl.
No objection from me.
- Per
___
Warzone-dev mailing list
On Sat, Mar 22, 2008 at 12:20 AM, Giel van Schijndel [EMAIL PROTECTED] wrote:
No objection from me either. Though I do suggest renaming it to
lib/graphics or something similar, as ivis is a bit too cryptic IMO.
lib/opengl ?
- Per
___
Warzone-dev
On Tue, Mar 25, 2008 at 3:41 PM, Dennis Schridde [EMAIL PROTECTED] wrote:
Move bool2string() conversion function from tagfile.c to frame.h
Would it be possible to do it the other way instead? I'd like to keep
tagfile.c and tagfile.h pretty much self-contained, since they are
meant to be reused
On Sat, Mar 29, 2008 at 1:26 AM, Giel van Schijndel [EMAIL PROTECTED] wrote:
-Wmissing-declarations causes compiling of the lexers to generate
warnings, which due to -Werror now fail to compile.
I am sorry about that. Can you post the warnings?
- Per
On Wed, Apr 9, 2008 at 9:54 PM, Per I. Mathisen [EMAIL PROTECTED] wrote:
Fix bug #11467: Assert when loading a savegame in campaign. Reported by Dale
Gill.
Modified:
trunk/configure.ac
Looks like I committed my stack protector patch by accident while I
was at it. I'm leaving it in for
One word about terminology first. The word 'mod' is often understood
as third-party, user-created modifications to a game. In Warzone,
however, we should look at this in a wider sense, since the game uses
overrides quite extensively during the campaign. So any way that one
set of data is
On Fri, Apr 11, 2008 at 8:12 PM, Dennis Schridde [EMAIL PROTECTED] wrote:
Can you then please explain
The only difference is
actually a small but important restriction: You can only add a data
set on top of another if it lies underneath it in the file system
hierarchy.
and the
On Mon, Apr 28, 2008 at 3:52 AM, Giel van Schijndel [EMAIL PROTECTED] wrote:
r4834 *might* have partially broken loading of *.lev files as that's the
backport of r4830 (among others) which replaces the previous custom
written parser with a bison/yacc generated one.
Why is this stuff being
On Mon, Apr 28, 2008 at 3:00 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
Thus I think a revert of this backport won't be required for this code.
As long as it doesn't become a habit, I'm happy ;-)
- Per
___
Warzone-dev mailing list
On Sun, May 4, 2008 at 11:49 PM, Freddie Witherden
[EMAIL PROTECTED] wrote:
The problem: we need a way for child widgets to position themselves
within their parents. We do not want to use pixel co-ordinates and
need the system to be flexible.
My suggestion is simply to make it snap to
On Mon, May 5, 2008 at 1:02 PM, Freddie Witherden [EMAIL PROTECTED] wrote:
My suggestion is simply to make it snap to another widget (not
necessarily a parent, could be a sibling), and then provide an (x, y)
constant offset from it in pixel independent values (millimeters?).
Seems
On Mon, May 5, 2008 at 2:25 PM, Freddie Witherden [EMAIL PROTECTED] wrote:
I was thinking more like widgetAdd(parentWidget,
frameOfReferenceWidget, side, offsetX, offsetY);
Putting an icon in the lowest right side of the main window:
widgetAdd(screen, screen, BottomLeft, 10, 10);
On Mon, May 5, 2008 at 3:55 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
r4926 | per | 2008-05-04 18:10:14 +0200 (zo, 04 mei 2008) | 3 lines
Remove limitation that VTOLs cannot pass over tall cliffs, and allowance
that
VTOLs can fly over anything to rearm. This removes the ugly
On Wed, May 7, 2008 at 4:31 PM, Roman [EMAIL PROTECTED] wrote:
Got rid of indestructible T3 weapons, gave rockets more body points.
Is it really wise to give cannon and rocket the same amount of body
points? Why would anyone use cannon now?
- Per
On Fri, May 9, 2008 at 10:00 AM, Dennis Schridde [EMAIL PROTECTED] wrote:
http://www.mozilla.com/en-US/legal/eula/firefox2-en.txt
As a digression, I would note that few Linux users ever see or can
click 'yes' to this EULA, since Firefox is installed quietly by system
tools that do not allow EULA
There seems to be a new crash/memory corruption bug somewhere, both in
2.1 and trunk now. I currently suspect my r5038 bugfix, but won't be
able to look into it more today. It is triggered by loading various
savegames multiple times, also seen it when mission done in cam1 first
off-world mission.
On Mon, May 12, 2008 at 7:43 AM, bugs buggy [EMAIL PROTECTED] wrote:
I think there are 2 different issues, I loaded back-to-back(x4)
savegame, and it worked OK. I am not sure what the deal is with that.
I have two savegames that can I can reproduce it reliably with.
For the 1st away
On Mon, May 12, 2008 at 4:14 PM, Dennis Schridde [EMAIL PROTECTED] wrote:
Requesting permission to merge r5049:5051 from trunk. (--join host support,
by Buginator)
Since we need some time to iron out the latest crash bugs, anyway
I'd say feel free.
- Per
On Wed, May 14, 2008 at 2:06 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
As for avoiding it, you could generate a working parser with 2.1 by
removing the %destructor parts, it _will_ introduce memory leaks though.
Does this mean the memory leaks are fixed now? I also suspect that
changes
On Thu, May 15, 2008 at 2:19 AM, Dennis Schridde [EMAIL PROTECTED] wrote:
Simplification and slight speedup for trigSin/trigCos. Make trigIntSqrt wrap
sqrtf, since the old lookup implementation was probably slower than that.
Please be careful and test a lot when changing this code. Much of the
Try droid sliding behaviour, what it does when colliding with
impassable objects in the world, like structures or other droids, as
that is the worst and most brittle of the movement code. I hope to axe
some of that when we make the path-finding a bit more intelligent.
- Per
On Thu, May 15, 2008 at 12:36 PM, Dennis Schridde [EMAIL PROTECTED] wrote:
Am Donnerstag, 15. Mai 2008 11:39:23 schrieb Per Inge Mathisen:
Try droid sliding behaviour, what it does when colliding with
impassable objects in the world, like structures or other droids, as
that is the worst
I think this should fix the eventRemoveContext crashes that we have.
It assumes that the bison/flex stuff frees its own allocations, so we
don't have to. I could not see any leaks, but did not test that much,
since my box tends to hang after running valgrind a while.
Comments? Testing results?
Nice! Why are you commenting out the smoke trail from indirect weapons
firing directly?
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
On Fri, May 23, 2008 at 2:13 PM, Per Inge Mathisen
[EMAIL PROTECTED] wrote:
Why are you commenting out the smoke trail from indirect weapons
firing directly?
Ignore that.
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org
Looks very good now. :-)
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Hello all,
I think we are back on schedule with 2.1 beta3, after some ugly
workarounds. Do anyone know a good reason to further delay 2.1 beta3?
Ari - any luck getting it to compile on MacOSX again?
- Per
___
Warzone-dev mailing list
On Sat, Jun 7, 2008 at 12:21 AM, Dennis Schridde [EMAIL PROTECTED] wrote:
Rename VectorXY_Set to VectorXY_New and make it conform to API of the other
vector functions
Don't know about others, but new gives me strong associations to
memory allocation (of the malloc kind), not parameter returned
On Thu, Jun 5, 2008 at 9:40 PM, Per Inge Mathisen
[EMAIL PROTECTED] wrote:
We are starting the process with creating beta3. Except for
macosx-related changes, and updating release information, the 2.1
branch should not be changed until further notice.
Beta3 has been tagged as
svn+ssh://[EMAIL
On Sat, Jun 7, 2008 at 4:29 PM, Ari Johnson [EMAIL PROTECTED] wrote:
There will be no Mac executable of beta3 because it cannot build as
currently tagged. Thanks.
I thought Freddie had fixed the Mac build. If there still are
problems, you can check the fix into both the 2.1 branch and the
On Sat, Jun 7, 2008 at 5:21 PM, Ari Johnson [EMAIL PROTECTED] wrote:
It was the removed level_parser.y that caused this. Easy fix. 2.1
builds again and appears to run just fine. Also, if you copy
macosx/Warzone.xcodeproj/project.pbxproj over into 2.1_beta3, that one
should build as well. I
We now have two Mac builds. I understand that Ari's is a debug build,
while Freddie's is not? If that is the only difference, I'd like to
use Freddie's build for beta3, if none has any objections to this.
- Per
___
Warzone-dev mailing list
We found and fixed a serious endianness problem in the network code
(packet size was not byte swapped), which means we will have to
recreate the binaries again. Sorry.
Let me know when you are ready.
- Per
___
Warzone-dev mailing list
On Sun, Jun 8, 2008 at 7:01 PM, Freddie Witherden [EMAIL PROTECTED] wrote:
Since we are yet to announce beta-3 I am suggesting that we remove
all beta3 builds from Gna! (there is always the nightly builds by
Giel if you want bleeding edge) or rename them accordingly.
I do not see why we need
On Tue, Jun 10, 2008 at 12:23 AM, Dennis Schridde [EMAIL PROTECTED] wrote:
We are:
- Defining DEBUG on debug builds and not otherwise.
- Defining NDEBUG to shutup asserts.
It also seems inconsistent to sometimes decide depending on DEBUG and
sometimes depending on NDEBUG, for the same case
For those of you who have not followed the latest events on the forum
and/or IRC, EIDOS have now granted us permission to distribute both
the FMVs and the soundtracks from the original game under the GPL.
This bodes well for the future.
It does, however, give us somewhat of a challenge for 2.1,
On Fri, Jun 13, 2008 at 8:55 AM, Giel van Schijndel [EMAIL PROTECTED] wrote:
Sure, but do we want to change every single [lexer interpreted] file format
to Lua?
Why not? :-)
I guess some can just plain be retired, like the animation lexer,
which WZM will obsolete entirely.
- Per
On Fri, Jun 13, 2008 at 2:03 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
Per Inge Mathisen schreef:
On Fri, Jun 13, 2008 at 8:55 AM, Giel van Schijndel [EMAIL PROTECTED]
wrote:
Sure, but do we want to change every single [lexer interpreted] file format
to Lua?
Why not? :-)
I guess
I would like to commit the original game music to the repository under
base/music. I ripped it directly from the game CDs, using normal ogg
compression. Any objections?
The music playing patch that is attached is a quick hack, but should
work well enough.
- Per
Index: lib/sound/playlist.c
On Sun, Jun 15, 2008 at 1:46 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
Per Inge Mathisen schreef:
I would like to commit the original game music to the repository under
base/music. I ripped it directly from the game CDs, using normal ogg
compression. Any objections?
Which quality
On Sun, Jun 15, 2008 at 4:11 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
That would mean keeping one music playlist in data/ and one in
~/.warzone2100. I do not like duplicated data files, as that tends to
be confusing.
Nope, it wouldn't be a duplication because the one in ~/.warzone2100
Hello all,
We need to implement some stricter commit policies and focus more on
quality control and avoiding patch conflicts.
Here is what I would like to see:
1) Every patch goes into the patch tracker. Give a quick run down of
what it does and what it changes.
2) After a patch has been put
On Mon, Jun 16, 2008 at 9:21 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
Per Inge Mathisen schreef:
Here is what I would like to see:
1) Every patch goes into the patch tracker. Give a quick run down of
what it does and what it changes.
2) After a patch has been put into the patch
After some discussion, I would like to soften the suggestion a bit:
Commit guidelines:
1) All larger patches should go into the patch tracker. Give people
time to comment on it. Add yourself to the cc: list of patches you are
interested in.
2) Try to break up larger changes into smaller patches
I would like someone to take a look at patch #969: Rewritten minimap
code. It changes the familiar radar window quite a bit. Instead of
zoom and pan, the window always contains the entire map, and you can
enlarge or shrink the radar window using the scroll wheel when the
cursor is over the radar
On Tue, Jun 17, 2008 at 12:17 AM, Angus Lees [EMAIL PROTECTED] wrote:
Can we keep the original files losslessly compressed (using something like
flac, perhaps) for posterity? or are the flac files still too large to put
through our repository?
I do not think they are too large, as long as you
On Tue, Jun 17, 2008 at 12:43 AM, Dennis Schridde [EMAIL PROTECTED] wrote:
So you cannot zoom into just a part of the map anymore?
Correct.
Is there the possibility for a split mode?
Like having the minimap as it is now, and when pressing ...m... it brings up
a fullscreen (or rather:
On Tue, Jun 17, 2008 at 6:57 AM, bugs buggy [EMAIL PROTECTED] wrote:
I would also like to add, *test* your patch, and if you can't, then
please let others know.
Yes, good point. More testing before commits are made would be very
welcome. I play a bit with rush2, load a savegame, try to play
On Tue, Jun 17, 2008 at 12:35 AM, Dennis Schridde [EMAIL PROTECTED] wrote:
4) Do not mix unrelated cleanup and feature changes or bug fixes in
the same patch.
...
4) Seems cumbersome to me, since when I try to fix a bug, some cleanup will
almost always sneak in, and additionaly I first
On Tue, Jun 17, 2008 at 9:04 AM, Dennis Schridde [EMAIL PROTECTED] wrote:
Because I maybe want to see what is going on in my current corner of the map
(i.e. on big maps), but also want to get an overview quickly.
...
I think having a nearest-surroundings minimap and a whole-world macromap would
On Tue, Jun 17, 2008 at 3:18 PM, Dennis Schridde [EMAIL PROTECTED] wrote:
Am Dienstag, 17. Juni 2008 09:02:13 schrieb Per Inge Mathisen:
On Tue, Jun 17, 2008 at 12:35 AM, Dennis Schridde [EMAIL PROTECTED]
wrote:
Principle, yes. I am also against commits like change style in a.c, b.c, ...,
z.c
Hello,
In bug report #11892, Dennis started a discussion about where we
should track feature requests. I am moving the discussion here since
the bug tracker is not an appropriate forum for this discussion.
Quote:
Per: I encouraged treating feature requests like bugs when it comes to
tracking
On Thu, Jun 26, 2008 at 2:47 PM, Dennis Schridde [EMAIL PROTECTED] wrote:
Some endianness swaping, as found in tags/2.1_beta3. Apparently was forgotten
to port back...
+NETend();
This was removed on purpose so that --selftest works again. NETend()
calls byte swapping on the
Hello,
I will be away, in Grenoble, France, from Sunday to Friday, and will
not have much time for anything Warzone related, although I may be
able to access email.
Can someone please look into the sound related crash(es)?
- Per
___
Warzone-dev
On Sun, Jul 6, 2008 at 8:34 PM, Dennis Schridde [EMAIL PROTECTED] wrote:
The only real issue which absolutely needs to be fixed or worked around for
the release is bug #11847 [2] (Playlist code causes segfaults).
I would like to focus all available manpower on that.
I tried digging into that
On Sat, Jul 12, 2008 at 9:41 AM, Dennis Schridde [EMAIL PROTECTED] wrote:
Fix bug that made droids seemingly explode randomly during the game. The
cause was that they would pursue the enemy on another person's computer,
but not on yours. Now your droids only decide to pursue on your computer,
On Tue, Jul 22, 2008 at 3:19 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
Further the two revisions by Per, 5261 [1] and 5281 [2], are the changes
to the playlist format.
Solutions are welcome.
As a solution I propose backporting of the two mentioned revisions.
@ Per: I'd like to hear
On Tue, Jul 22, 2008 at 5:11 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
Merged revisions
On Tue, Jul 22, 2008 at 10:00 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
Why are you merging all these revisions into a stable branch???
It's basically dead code removal. Though if you meant to ask: what does
it gain us, then aside from cleaner code the answer is: nothing.
Then it has no
On Tue, Jul 22, 2008 at 8:53 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
All just bugfixes?
No, all of that boils down to code removal actually.
The only code that cannot contain bugs is no code.
That is not true. Code removal can definitely trigger new bugs. Even
if the code removal is
On Thu, Jul 24, 2008 at 5:50 AM, bugs buggy [EMAIL PROTECTED] wrote:
For what it is worth, I rather have 2.1 (beta or not) be included, for the
simple fact that if it is not, then people keep submitting bugs for 2.0.10,
and that doesn't do anybody any good.
I do not think Debian ships 2.0.x
I
http://wiki.wz2100.net/Commit_guidelines
Last call for comments.
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
On Sun, Aug 3, 2008 at 10:04 PM, Per I. Mathisen [EMAIL PROTECTED] wrote:
When iterating over neighbouring start tiles for a path, do not iterate from
the end
position of the path. Fixes bug in new multi-threaded path finding code.
While this fixes the crash issue, the patch itself is totally
As discussed on IRC, here is the solution we came up with to implement
multiple weapons on a single droid better:
Each PIE connector gets an additional value, a range in degrees that
any weapon on that connector can turn. The first weapon connector
should not have any such limitations, to avoid
On Fri, Aug 15, 2008 at 8:31 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
originals/AUTHORS
originals/naval/
originals/naval/prhnaval1/
originals/naval/prhnaval1/naval.png (with props)
originals/naval/prhnaval1/naval.xcf.gz (with props)
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) anyway?
I can look into it. However, time may be short this week.
- Per
___
On Tue, Aug 19, 2008 at 7:22 AM, bugs buggy [EMAIL PROTECTED] wrote:
Are we going to wait this out, or try to find a new server/host or what?
Got a suggestion for a new server? As long as we use svn (and not a
fully distributed tool), I would like a host that has reliable
backups, in addition to
On Tue, Aug 19, 2008 at 7:04 PM, Dennis Schridde [EMAIL PROTECTED] wrote:
Am Dienstag, 19. August 2008 07:57:00 schrieb bugs buggy:
On 8/18/08, Dennis Schridde [EMAIL PROTECTED] wrote:
It is mostly good, but sometimes (almost exclusively in debug() calls) you
have no spaces between
On Sun, Aug 24, 2008 at 4:55 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
Author: muggenhor
Date: Sun Aug 24 16:55:50 2008
New Revision: 5864
URL: http://svn.gna.org/viewcvs/warzone?rev=5864view=rev
Log:
Merged revision r5861 into the 2.1 branch via svnmerge from trunk
r5861
See http://wiki.wz2100.net/Commit_guidelines
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
On Sun, Aug 24, 2008 at 5:42 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
Author: muggenhor
Date: Sun Aug 24 17:42:59 2008
New Revision: 5865
URL: http://svn.gna.org/viewcvs/warzone?rev=5865view=rev
Log:
* Split ASSERT out into ASSERT_HELPER:
* ASSERT_HELPER can be used by debug
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 it
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 unusual
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 pertinent
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
last
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 list,
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 by me.
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
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 seemingly
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
___
Warzone-dev
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
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, I
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
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
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) anyway?
I can look into it. However, time may
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
releases
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 is
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
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 can play
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.
In any
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
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
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
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
201 - 300 of 577 matches
Mail list logo
