Re: [Warzone-dev] Embedding fonts in Warzone
I see them in C:\Program Files\Warzone 2100\fonts They're also in C:\Windows\Fonts\, but I have a feeling I put those there manually. -Zarel 2008/9/20 Per Inge Mathisen <[EMAIL PROTECTED]>: > Question - where should we load the font from? Does the Windows > installer put it somewhere specific that should be hardcoded into the > game? > > Perhaps someone with more experience with the windows builds should > look at this. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Version numbering
2008/9/24 bugs buggy <[EMAIL PROTECTED]>: > We got windows builds available nightly. > We should use that to our advantage, and let the community test. > > I don't know how we will handle mac builds though. It doesn't look like we > will have nightly builds with them. But 2 out of the 3 platforms we support > isn't all that bad, it should at least find most of the errors that way. > Well, I suppose I can make Mac builds every week or so. Will that be close enough? -Zarel ___ 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.
2008/9/25 bugs buggy <[EMAIL PROTECTED]>:
> 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 2.1 for.. um... {insert a reason here}
>
I vote it be called 2.2 beta 1. Trunk is at _least_ as stable as one
of the 2.1 betas.
- Zarel
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.1_beta5
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? Heck, why don't we just backport the threaded pathing from 2.2? That can't be worse than the other pathing fix. Other than that, I agree. - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Request: Rotating Buildings.
So. Does anyone have any idea which keys should be used to rotate? 2008/10/10 Per Inge Mathisen <[EMAIL PROTECTED]>: > 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 be a very nice feature. > > - Per > > ___ > Warzone-dev mailing list > Warzone-dev@gna.org > https://mail.gna.org/listinfo/warzone-dev > ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Request: Rotating Buildings.
2008/10/10 Zarel <[EMAIL PROTECTED]>: > So. Does anyone have any idea which keys should be used to rotate? > Whoops, sorry about that top-posting. I absolutely hate Gmail's default settings. >_< -Zarel ___ 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
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. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Pushing 2.1 out the door
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 or attack another target. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Pushing 2.1 out the door
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. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Pushing 2.1 out the door
On Mon, Oct 20, 2008 at 5:38 AM, Giel van Schijndel <[EMAIL PROTECTED]> wrote: > Zarel schreef: >> 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. > If users want half-working multi-turrets, they can use trunk. I think a stable version should be, as its name implies, stable. In addition, having the configuration in multiplayer would require some kind of change to the netcode to make sure everyone has it configured the same way, which would require a lot of work that would need to go through testing. In other words: On Mon, Oct 20, 2008 at 5:38 AM, Giel van Schijndel <[EMAIL PROTECTED]> wrote: > 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? Yes. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] How not to use a version control system
2008/11/16 Gerard Krol <[EMAIL PROTECTED]>: > The untested commit: after a careful reading of the code you conclude > that there possibly can't be any bugs left. Unfortunately a trivial bug > renders the entire program unusable. Better stay available to do > emergency fix-ups. > > (coloured cursors anyone?) > Hey, the patch that broke cursors wasn't the colored cursor patch; it was a different cursor-hiding patch... -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] File Association For Mods
On Sat, Nov 29, 2008 at 5:48 AM, Freddie Witherden <[EMAIL PROTECTED]> wrote: > > Hi all, > > I am interested in knowing what everyone things about the idea of > associating .wz files with Warzone in the shell. This would mean that > to start the game with a mod foo.wz all the user would need to do is > double click it. While it's better than the current way, the problem with such a scheme is that it only allows one mod at a time. I much prefer the old Warzone way of simply renaming the mod to enable/disable it. Double-clicking it could even toggle its enable/disable state. Other suggestions include simply bundling a separate mod manager (like the old Warzone Launcher), or including a mod manager in-game. The game should at least report in the main menu which mods are active. Kamaze: > And another request, is it possible to register additional protocols > on linux/max, like "warzone://:" so that we can fire up > warzone from a server-list inside the browser, for example? I like this idea. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Branching for 2.2
I agree with everyone else who says we should branch now. As for specifics: On Thu, Dec 25, 2008 at 9:17 AM, Dennis Schridde wrote: > Generally I agree. > > But what are the new features of current trunk? > > -00-00: SVN > * Video: > * New: Add support for playing of videos (OggTheora) > * General: > * New: Add mouse menu option. > * New: Add ability to toggle between hardware (SDL) and software (colored) > cursors, in new mouse menu option. > * Fix: Should fix flickering background on loading screen. > * Fix: --nosound works correctly with videos now. > * Fix: Clean up input stream after saving a save game, to prevent it from > going into chat mode. > * AI: > * Fix: Allow a droid to pick a new target while auto-repairing. (ticket:35, > bug #12217) > * Fix: Improve targetting AI so that it does not select bad targets, and > make it use full weapon range instead of limited to sensor range. (ticket:97) > * Buildsystem: > * Fix: Only compile the translations when $(TRANSLATION) is "yes". > (ticket:130) > > Is that *all*? Even compared to the late 2.1 betas that's *nothing*... It's plenty. I don't even see threaded pathfinding in that changelog. And what about structures having partial HP while being built? I think it's a good idea that should be committed soon. On Thu, Dec 25, 2008 at 10:05 AM, Gerard Krol wrote: > The big question is, would this be a reason to delay the branching + > release for a month or two? Does it fix any bugs? Especially if you > don't know if you will have time to finish it soon, I don't think we > should wait for it. I'm not sure delaying the branching means we _have_ to delay the release. We'd just have less time between branching and release. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] ping
On Sat, Jan 31, 2009 at 12:37 AM, bugs buggy wrote: > Just checking if list is alive and well. > > I haven't heard from many people that use to frequent the list, and > just wondered what everyone was up to? > > The MAC people seem to be very quiet, and there has been little mac > related feedback for 2.1, and how the new netcode works between macs & > linux & pc machines. I'm here, as you know. As for the Mac stuff: I've played quite a few games with me on Mac OS X 10.5 (Intel) and everyone else on Windows. I haven't hosted a game, but I've joined games, IP, lobby, they've all worked perfectly. Well, relatively perfectly. As perfectly as it does on Windows, which means some sync problems, but still playable. Also, why do you say "MAC"? "MAC" always makes me think of "MAC address"; Macintosh computers are generally called "Mac"s. - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] New fields needed for trac
2009/2/14 bugs buggy : > The response of "Feature request" so we can close the ticket, and keep > track of features that way, instead of saying 'Invalid' or whatever > else we do now when we get feature requests. Isn't that what "Enhancement" means? And there needs to be some way of differentiating tickets that include a patch and tickets that don't. I can't tell the difference between a ticket that, say, submits a patch for a bug from one that reports a bug, nor between one that requests a feature or a patch that adds a feature. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Map packs
2009/2/14 bugs buggy : > That is one of things that is crashing us now. > Host has that map pack. > User connecting don't. > game tries to send map, but since, it is in the map pack, it has no > idea how to deal with it, and it can't find anything to send. > If we send false on that condition, then the User still don't have the > map, and it requests the map again, and we run into a infinite loop. > > My patch right now, has a force exit() to the host, since *all* > players must have that map pack to work correctly. > The other option would be to kick the user that don't have the map > pack. And since we can't send messages on a kick, they will try to > connect again & again... > > Which is the lesser of two evils? Well, first, we should fix that: Add the ability to send a message on a kick, and depending on the message, have the client not auto-reconnect. And then, if each map contains its filename, they could all contain the map pack name, and then the host could just send the entire map pack to everyone. - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Function to check impossible paths
2009/2/14 Per Inge Mathisen : > 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 some esoteric (and unused) > propulsion methods are mostly ignored, like ski and jump. Not sure how > to properly handle those. > > Hover is properly handled, however. > > - Per Is it impossible to fly to some locations on the map? Jump can get to the same places VTOL can get to, I think. I haven't done enough messing with it to know for sure. Propellor is the same as hover. I've never heard of Ski. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2 branch
2009/2/19 Freddie Witherden : > Lua is fine with me -- so long as it is not too hard to parse on the Python > (server) side of things. The one advantage that JSON did have was that it > was possible to write an HTTP interface for the lobby server (using JSON) > allowing for web-based clients. > > Therefore a better way might be to get a Lua script for serialising Lua > objects as JSON. That way we get maximum compatibility with minimum effort. This is a good idea. I'd also like to see an HTML interface for checking on the lobby server. Heck, I'd write it myself. - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] A plan to refactor and clean up the warzone code base
2009/2/19 Per Inge Mathisen : > No problem. I agree we should branch for 2.2 now. Anyone see any > reasons why not? Now that I've figured out how to commit to branches other than trunk, I'm fine with this, too. It seems everyone's in support of branching immediately? (I count me, Buggy, Gerard, Per for, and no one against) - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.1.2 release
2009/2/22 Per Inge Mathisen : > Then, unless anyone have good reasons why we should wait, I will tag > it in a day or two. I hope someone have time to create Windows and Mac > builds the next few days. I think we should wait until we can fix the infinite oil drum bug before releasing 2.1.2. Otherwise, I'm fine with it. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Effect memory pools
2009/3/1 bugs buggy : > On 3/1/09, Dennis Schridde wrote: >> Rejected by Per because of lack of useful new features. >> > I see no real issues with the patch. If it improves the way it was > before, and it doesn't cause any side-effects, and it makes it a bit > cleaner (code wise) as well... > > http://imagebin.ca/view/cSaZeFbW.html > I agree. If it improves performance, and it makes code cleaner, I don't see why not. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] FMV delivery and installer thingys
2009/3/4 Dennis Schridde > They currently live on the Gna servers to be downloaded on-demand by the > Windows installer. (Or by distro packagers.) > They will definitely be in, and the current method of distribution (credits go > to Giel) seems to work. Last time I installed trunk (a week and a half ago), they weren't downloaded by the installer at all. Is it currently implemented like the music? I think the music download should be implemented better - it shouldn't be downloaded if it already has been downloaded and hasn't changed since then (I hate having to uncheck "install music" each time I update Warzone so I don't have to wait for a slow Gna! server to send me the music files again). Heck, right now, I don't even know how the sequences are supposed to be packaged. The only way I've managed to get them to work without having them unpacked is either packaging them within warzone.wz, or putting sequences.wz in mods/global/autoload/. Putting sequences.wz in the main Warzone directory just causes Warzone to ignore it. > Till now we had no issues with this. Some mods even live in svn, and I do not > think that there are a lot of serious issues with this either. > And then: Why should Aivolution be special in this regard? When does a mod > become "official"? When the creator is also a WZ developer? Does he have to be > active? What type of contributions do count as "development"? ... > Summary: As long as no issues arrise from that type of distribution, we should > stick with it. Well, Aivolution is different because it doesn't change game balance, nor models, nor anything like that; it simply improves the AI. > The one in Gentoo is quite current... ;) > Arch is probably the same. Ubuntu crawled a bit, but that's nothing new. > Maybe you should show some stats for the major distros, so we have some ground > for discussion. Well, the one in the Ubuntu repositories for intrepid (the current version) is 2.1-beta4. Older versions have ridiculously old svn builds (r3595 and r1436). The next version of Ubuntu that hasn't been released yet has 2.1.0. - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] FMV delivery and installer thingys
2009/3/4 Dennis Schridde : > As an additional note: Ubuntu apparently just managed to sync with their > upstream and is therefore just as up-to-date as Debian again. Wow. :) Well, to be exact, they've acknowledged the bug, which means they'll probably sync sometime in the near future. They're currently still at: Jaunty (2.1.0-1): universe/games Intrepid (2.1.0~1.beta4-2): universe/games Hardy (2.1.0~0.svn3595.dfsg.1-1): universe/games Gutsy (2.1.0~0.svn1436-1): universe/games The relevant bug: https://bugs.launchpad.net/ubuntu/+source/warzone2100/+bug/337915 Which was filed after I prodded them in #ubuntu-motu -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] FMV delivery and installer thingys
2009/3/4 Zarel : > 2009/3/4 Dennis Schridde : >> As an additional note: Ubuntu apparently just managed to sync with their >> upstream and is therefore just as up-to-date as Debian again. Wow. :) > > Well, to be exact, they've acknowledged the bug, which means they'll > probably sync sometime in the near future. 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... -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Tag 2.1.2 and 2.2 alpha1
2009/3/6 Freddie Witherden : > 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 of. What is tagging, and is it more difficult than it sounds? -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Tag 2.1.2 and 2.2 alpha1
2009/3/6 Per Inge Mathisen : > The only patch we discussed for 2.1.2 was Buginator's music fix. > However, I do not know where it is, so I think we can schedule it for > 2.1.3 instead. It's here: http://developer.wz2100.net/ticket/224 -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
2009/3/13 Stephen Swaney > Perhaps I'm becoming a neo-Luddite or perhaps I've been in this > business too long, but I find the lack of a single shared repository > disturbing. I do know a software development effort lives and dies on > the basis of its source code management. > > The ability to branch freely is great but without a primary location > for the source keeping track of who is 'it' sounds difficult. How do > we keep all the package maintainers connected to what is going on? > I'm betting they run build scripts to do a checkout from the > 'official' repository when they go to build. I echo this. Having a single repository makes sure conflicts get resolved quickly. If we don't have that, then what do we have? Several versions of Warzone, each incompatible with each other, and no way to easily merge them? I mean, I wouldn't mind having my local copy as a separate repo, but it should be merged with trunk fairly quickly. In short, I prefer the current way. In addition, Git doesn't have anywhere near as good a Windows GUI as TortoiseSVN. I like being able to diff/blame/make-patch in around two clicks. Committing is two clicks. Unless you only want to commit some files, in which case it gives a list with a bunch of checkboxes. All versioned files are checked by default, and there are buttons to check all, none, or versioned only. That's the kind of thing I imagine will be much more complex with a commandline. :/ I can handle using a commandline if I have to (I currently have no better way to compile than to type "mingw32-make -f makefile.win32" - the longest string I have muscle memory for. I should make that my password somewhere), but I'd really prefer my lovely TortoiseSVN GUI. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
2009/3/13 Dennis Schridde : > 1) Have a someone maintain the mainline repository on Gitorious and prepare > releases from there. > > Or my favourite: > 2) Assign a release maintainer (practically we already did that for 2.0 and > 2.1), and he will fetch all the loose ends from the dev repos and for version > X his repository will be what becomes the official version. > > 2 is my favourite, because it is the freemost variant, dead simple, not too > much additional workload, we can easily shift the load around, ..., etc. > If we had someone insane in the team, or someone being paid for it, 1 would > probably be the first logical solution, since (s)he would devote their > lifetime to the game anyway. But since we don't 2 looks a lot more promising > to me. > 2 still requires a release maintainer, which has the same issues as #1. And what happens when the release maintainer finds conflicts between the dev repos? Lots of wasted time/effort there, I think. Sure, no one ships directly from SVN trunk, but they ship directly from their release branch. I again suggest Google Code (SVN). The last time I suggested it, the only objection was that EvilGuru disliked that even though Google would near certainly accept the request, they have the choice to reject the request. Which is a rather silly objection, since Gna had a project approval process, too. Google just has it for projects larger than 100 MB. I could e-mail them and ask. I would send them something like: > Hello, Google Code staff. > > We, the developers of Warzone 2100, an open-source cross-platform > real-time strategy game (wz2100.net), are considering hosting our project > at Google Code. > > Our project is fairly large - each branch is around 200-600 MB > uncompressed (Trunk is 400-600 MB depending on whether or not > FMVs/cinematics are included), an installer is ~50 MB, not including > the FMVs/cinematics, which are ~130 MB. In other words, we're well > above your default 100 MB limit. > > Can you host us? > > - Zarel Objections? Approval? -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
2009/3/13 bugs buggy : > I finally found the cause for people getting disconnected for no > apparent reason (especially in longer games). > The fix is simple enough, but the issue is, we can't stop 2.1.2 people > from connecting to 2.1.3 people. And since the main point of the fix > is to allow people to NOT drop connections, I don't see a alternative > besides changing ports to prevent the clients from connecting. I don't see the problem with just fixing 2.1.3 and leaving it at that. Yes, 2.1.2 networking with 2.1.2 will be unstable, but that's kind of impossible to fix. Yes, 2.1.3 networking with 2.1.2 will be unstable, but not more unstable than 2.1.2 currently is. And 2.1.3 networking with 2.1.3 will be stable (or at least moreso), so why not? -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
2009/3/14 Elio Gubser : > As far as i understand the 'git-way' needs a person who merges every > developers commits togheter. Well I fear, with our current development > activity and team size, this would produce a lot of overhead and > bureaucracy for no big advantage. This. (By the way, I sent the e-mail yesterday. No idea how long before I get a reply.) -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2 alpha/beta changes
2009/3/15 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? (Note, this will be the last > switch, since we will have version checking code in the codebase) > 9996 is used by a trojan (W32.Sasser.Worm), so I doubt we want to use > that port-- I know a few ISPs are blocking that one. > http://www.speedguide.net/port.php?port=9996 shows the worm > http://www.speedguide.net/port.php?port= has warzone listed , > along with another worm. :S > http://www.speedguide.net/port.php?port=1 is used by everquest, so > that seems like a safe bet? > Then again, it was mentioned on IRC that we could use port 80, since > everything but the kitchen sink uses that...(which means, that for the > most part, people already have this open in their FW/router). Then > there is port 2100 :) > 9995 is a good idea. So's 2100. I don't like 1 since it breaks the "999x" theme. 80 is a terrible idea, everyone and their cat has that port blocked. Some ISPs block it because they don't want webservers running on user computers, etc, etc. If we wanted a port with a higher probability of being open, we could find a port used by another popular online game that requires port opening. > Also, for the write dir, we have for 2.1: > win: Warzone 2100 2.1 > mac: Warzone 2100 2.1 > linux: .warzone2100-2.1 > > Since 2.2 will need a new port, (and thus a new config file specifing > a new port), > Do we stick with the format above, and just make it 2.2? Well, clearly we're going to use a different dir. I guess we could stick with the format above. > Anyone think of anything else that needs changing before we kick out > the alpha (or beta)? Wait for me to put some more rebalance changes into 2.2. Do we think we can wait another week? -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
2009/3/18 bugs buggy : > Right now, we only check on the version string. All the other stuff > we send isn't used. > > I am also not sure about the time period to wait before we auto kick > someone. Right now, it is set to 7secs. > > Logic is, player joins. Host sends version request query. If Host > don't get response within 7 secs, then we auto-kick. > If wrong version string, we auto-kick. > If all is fine, you won't notice anything. We should send a message with the "wrong version string" auto-kick, though. "You're using version X, we require version Y" And we should only send the "wrong version string" auto-kick if the two versions are netcode-incompatible. Let's set the time period to 12.8 secs. ;) /me likes powers of 2 -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
2009/3/18 bugs buggy : > Well, it does that in the console via LOG_ERROR... doing that in the > GUI... is not going to happen anytime soon. Oh, come on. So the user just gets kicked out, no explanation why? It _better_ go in the GUI. > Ha! Ok, then 4 secs. ;) I thought Warzone's game code had 1/10 sec ticks? So the closest approximation would be 6.4 secs. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
2009/3/18 Dennis Schridde : > Make it 10, at least. > It could happen that the peer is under load, has some weird network setup > which needs more time, or whatever. If the peer is _that_ under load, that peer isn't going to be able to play Warzone very well. 2009/3/18 bugs buggy : > _YOU_ can do it then... GUI stuff is... well, you will see if you > tackle this. It takes a heck of allot of code changes / additions to > do this kind of thing. I'll see what I can do. :/ I know widget code is a mess, which is why we're all waiting for Betawidget. > Besides, they DO get a explanation, it is just using stderr that will > show them the message. That doesn't count. Survey 1000 gamers; see how many know what "stderr" means. Then see how many of those would look at "stderr" after being randomly kicked from a game. I estimate those numbers at 3 and 0, btw. > And I almost forgot, we are going with port 2100 right? I believe everyone agrees yes. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Mods considered harmful
This is amusing timing, since I read the Wikipedia articles on Dijkstra and "Considered Harmful" yesterday. 2009/3/18 Per Inge Mathisen : > As for Warzone, we are facing the same issues, just that we are now > where Freeciv was ten years ago. Our mean number of working, complete > mods is zero. That is, if we do not count Rebalance, which is an > exception that pretty much proves my point, since not only was the mod > absorbed into our core, we even assimilated its developer... ;-) So > let's not make the same mistakes that Freeciv did. Users in general > are not going to learn the arcane switches and incantations necessary > for making mods work (--mod_mp?), and as long as we refuse to greatly > simplify the way mods are treated, we will not be able to offer an > appealing user interface for users to access them. As others have mentioned, WarZombie is a mod that's fairly popular. And we don't have more mods because we don't have many players, because none of us feel like marketing Warzone until 2.2. At least, that's when I'm holding off my marketing for. I keep on planning to write to Ask Slashdot to call for developers, but I never get around to it. And this is more an argument for a better mod interface than anything else. > What we need first and foremost is an easier way for users to create, > distribute and download maps. I have the "distribute and download" part on my to-do list. I'll leave it to the others to handle the "create" part. > After that we need a better way to offer users a way to install and > play total modifications. Those are either new campaigns, or totally > different and network incompatible multiplayer/skirmish games using > their own AIs and own game data. Overriding base game data is a risky > way to create them, since even small changes to non-overridden base > data could break it. So the best way to create them is to replace > everything. Then we can offer a menu where such conversions can be > chosen. In other words, what we want to do is take our existing mod interface, and make sure only one can run at a time. This is a good idea, and completely different from discarding the entire mod support code. And it's kind of assumed that mods will be network incompatible. I'm thinking mods should have some sort of network compatibility flag indicating this. > As for the small mods that just change one or two things, like > increasing mg firepower or adding flying trucks... I dare say they are > by and large not needed, and won't be used, except as a proof of > concept. For that you can use ordinary patches to the core game data, > and deal with them like we deal with code patches. In the long run, > supporting them is probably harmful. Lies. I think a lot of them are important and in demand. And though mods aren't exactly trivial to implement, I daresay it's easier than downloading and compiling trunk. Especially for distribution. > So in order to get good support for user modifications, we should > remove support for mods. Though I disagree, I do think we should merge mp.wz and warzone.wz back together. Although I think sequences.wz should remain separate. We should add loading code for sequences.wz, by the way. It's currently, as far as I know, impossible to load sequences.wz without treating it as a mod. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Mods considered harmful
2009/3/20 bugs buggy : > While this would be most welcomed, it is also the most difficult to do. > Warzone isn't really mod friendly at all, and one small mistake and > the game crashes, and the odds of finding out what caused it can be > pretty long sometimes. Echoed. While I fortunately haven't wasted tons of time in it yet, debugging mods can be a very frustrating experience. The game's method of objecting to mods generally involves force-closing itself with no error message. Common mistakes: Not leaving a linebreak at the end of a file. Not counting the number of prereqs, results, etc on research.txt correctly. Not adding a corresponding entry to names.txt - some things, like sensors, require an entry, while some things, like functions, don't. And if you made a typo somewhere? You have to look through _every single file_ you modified. If it weren't for diff, I don't think Rebalance would have ever happened. :/ -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] last word before port change
2009/3/21 bugs buggy : > Apparently, I didn't make it clear enough. > > For all previous versions of the game, we only changed 'masterserver_port'. > That was 9998 for 2.0.10 > http://svn.gna.org/viewcvs/warzone/tags/2.0.10/src/configuration.c?rev=3225&view=markup > > It is 9997 for 2.1.x > http://svn.gna.org/viewcvs/warzone/tags/2.1.0/src/configuration.c?rev=6472&view=markup > > gameserver_port has always been . > > 2.2 & trunk will be: > masterserver_port = 2100 > gameserver_port = > > Any final objections? Apparently everyone wants gameserver_port to be 2100. masterserver_port is kind of irrelevant; it doesn't even need to be open on client machines. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Roadmap 2.2
2009/3/28 Kamaze : > Hey there, > > the roadmap says that there are 3 month left for the 2.2 release (I know > that this isn't mandatory). However, from my informations this is going > to be our first `big´ release, since it will our first distribution of > the _full_ game. > > So, since we drum up the business the first time, what are the > plans/whishes/todos for the 2.2 release? What should be done on the website? Hmm. I wonder if I should try my hand at redesigning the website. - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Specifications for ECM/'cloaking'
2009/3/29 Kreuvf : > There must be a clear specification of the goal that is achieved by ECM > technology, otherwise there will be problems when ECM is finally added to the > game, e. g. those people responsible for documentation cannot keep up with the > actual development as it diverges from what the documenter thought was agreed > on > before. I'm going to suggest a much simpler system: It seems the existence of an "ECM" cursor implies that ECM was meant to be targeted. Therefore, I propose that one ECM disables one sensor completely (any sensor, not necessarily just a sensor turret/tower). So if your lone cannon tank got ECM'ed, it would be unable to see anything. This is lifted when the ECM stops targeting you (i.e. when the ECM targets something else, or you move out of the ECM's range). I propose that the ECM has a range of 18 tiles, so it's enough to disable any other sensor without getting too far into their range. For reference: Sensor Turret: 12 Sensor Tower: 16 CB Turret, Tower: 16 VTOL Strike Turret, Tower: 16 VTOL CB Turret, Tower: 16 WSS Turret, Tower: 18 CC: 16 Uplink: 18 Fortresses: 12 Towers: 10 All other units/structures: 8 -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r6940 - in /trunk/data/mp/stats: ./ research/multiplayer/
On Wed, Apr 1, 2009 at 3:00 AM, Per Inge Mathisen wrote: >> 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 changes look good. As far as I can tell. What I would really like > is a more detailed breakdown of the changes. I do *not* want to be > guessing what has changed, and I am not going to start parsing the > changes by hand. There are simply too many and too trivial to list by hand. If you don't want to parse the changes by hand, http://wzguide.co.cc/new/ has charts that can be compared/contrasted with the Guide for 2.1. It's always updated to be the latest version of Rebalance. In particular, the cannon vs rocket split can be noticed at the Weapon Table at the bottom of Turrets. > It would also be nice with some discussion in advance (eg on the > forums) of such changes. Well, I guess we can have post-discussion now. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r6940 - in /trunk/data/mp/stats: ./ research/multiplayer/
On Wed, Apr 1, 2009 at 6:00 AM, Per Inge Mathisen wrote: > 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, *which* of them is no longer > anti-tank, and what the other one is now. This kind of information we > have to give our users, too, when we make a release, so you can just > as well put it in the commit message. Well, I mean, does it matter which one is _called_ "anti-tank"? They've both been changed so neither one is any more or less anti-tank than the other (okay, okay, rockets are more anti-tank-y) You can know which one uses which name on the Guide by either clicking on a weapon name or mousing over the damage, which will tell you the damage type. Anyway, as I'm sure you've noticed, I'm posting details on the forums, because feedback is a good idea either way. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Question on maps
On Fri, Apr 3, 2009 at 2:22 AM, Per Inge Mathisen wrote: >> I assume I need this to effectively define starting positions of players -- >> each should be given two initial construction droids? No other items are >> strictly necessary? > > Correct. Wait wait, I thought CCs were necessary, too. I echo Per, by the way. Having a usable map editor, as opposed to EditWorld, which is extremely difficult to do anything with, would be great. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] FMV distribution
I have sequences.wz on Warzone Guide -> http://wzguide.co.cc/files/ In any case, I suggest that the installer shouldn't come with the FMVs, but have it check to see if the system already has the sequences, and if it doesn't, download them during the installation (like the community music mod). I should also suggest that the sequences be packaged in a .wz file, instead of unpacked into the Warzone directory, which slows down the installation process greatly. 2009/4/5 Kreuvf : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi-Di-Ho, everybody, > > I uploaded the 2.2 beta 1 to my site and now I am wondering about how you will > distribute the FMVs in upcoming releases? I just cannot afford having ~500 MB > wasted for Windows releases every time while every other version comes at ~50 > MB > per release (Windows = 200 MB with and without debug + 50 MB with and without > debug). Now I am not obliged to upload everything to my site, but I'd really > like to have at least the current and the upcoming versions mirrored on my > site > completely. The maximum amount of data I am willing to dedicate to > files.warzone2100.de is ~7 GB. Keep in mind that not only releases are hosted > there, but mods, maps and whatever else as well. > > Side note: I will probably have enough time to redo the whole structure of it, > but the space limit still persists. > > To cut a long story short: Would it be possible to publish something like an > original_videos.wz mod that everybody could apply to every version instead of > including the videos in the windows installer every time? I am pretty sure I > saw > such a .wz file once on gna ;) > > - - Kreuvf > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJ2IiI4y86f1GXLDwRAtXWAJkBrVtUBDGuqUMFLIGaRqNhgAJkygCeIVny > FzWk24kMRtzuqDNIGnHsVMU= > =VLdI > -END PGP SIGNATURE- > > ___ > Warzone-dev mailing list > Warzone-dev@gna.org > https://mail.gna.org/listinfo/warzone-dev > ___ 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
2009/4/7 bugs buggy : > We also may want to change GAMESTRUCT, so the master server can take > care of games that have a password, and other stuff we want to check > for? YES. The master server should also save the version number, and any mods loaded. I'm sick and tired of people joining my Rebalance games and then refusing to leave (they seem to auto-reconnect when kicked). 2009/4/7 Per Inge Mathisen : > Instead, I suggest that for trunk we use port 2100 for game, port 9990 > (or something else) for master; for 2.2 we use port 2100 for master, > and port 9990 (or something else) for game. That means, we switch them > when changing 2.2->trunk. This way people will not have to open new > ports in their firewall for the 2.2->trunk upgrade. In the trunk > version, we add version checking and probably a ton of other network > changes. No... For one thing, only the game port needs to be opened, the master server port does _not_ need to be opened on user machines. It's a _lot_ simpler just to add version checking to 2.2. > Another reason why adding a version check to 2.2 may not be > sufficient, is that we may end up making totally network incompatible > changes that it cannot pick up anyway when we first start picking > apart the netplay code. I do not want to freeze any part of the > network code before this work is even seriously started. ...even the version check part? Obviously, the version check part ensures that anything that happens after the version check can be as incompatible as you want - simply bump the version number. imho, most of the problems with hosting multiplayer games is that people with incompatible versions always join, and it's impossible to shoo them away. That's why I find version check so important. By the way, Buggy, I sincerely hope your version checking code affects mods. Even if we make totally network incompatible changes, there's an easy fix without even changing the corresponding ports: In 2.2: - Interpret an unrecognized packet as a kick. In the lobby server: - Have the lobby server retain backwards compatibility. In 2.3: - Use either a recognized version check packet, or a known unrecognized packet. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Changing the mod system
2009/4/9 bugs buggy : > When a person hosts game, they can pick any mods they want, and they > would specify each one on the command line. How's about, they don't specify them on the command line, but mods are selected like maps are when a game is being hosted? Here's how it works: we can manually load the mod directory, search for mod files, and list those files in the mod selection screen (which will be similar to the current map selection interface). When a mod is selected, we include its location in PhysFS's search path upon game load. This would only work if PhysFS loads game data _after_ the mod/map selection phase. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[6996] trunk/src/multiplay.c
2009/4/10 Dennis Schridde : >> Log Message: >> --- >> Fixes a crash that should never happen in multiplayer, but still somehow >> did. > Please be more specific. > *At least* a ticket id should be given, and if you can spend the additional 10 > seconds, also a short description/keyword/hint so one knows what you refer to > without having to search the ticket. > > --DevU Unfortunately, I don't remember which ticket it was, or if it was even submitted as a ticket. I think it was just mentioned on either IRC or the forums, and I can't find its mention. You can just think of it as pre-emptively fixing a possible crash? :S -Zarel ___ 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
2009/4/19 Giel van Schijndel : > 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. This isn't the first time this has come up. Let's agree on a solution right here and now, so we don't have to go through this every time I commit Rebalance. Per and I agreed on this solution: considering I change everything so many times, it's simpler to just provide a full changelog from 2.1 when Rebalance is finished. Otherwise, it's too much information. I change minor values once, then change them back when they don't work, etc, etc. I will name every single change I made when Rebalance is finished. Doing it each commit simply requires more time than even making the changes and playtesting them over and over. The summary of major changes and the website with detailed changes is enough. It won't go down before my full changelog when Rebalance is finished, anyway. And the data is separate enough that we can revert all of it while leaving the rest of the code untouched. Everyone agree? - Zarel ___ 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
2009/4/20 Per Inge Mathisen :
> ... and discuss the bigger changes on the forum prior to making them ;-)
Yeah, yeah.
> I would still *prefer* to get a detailed changelog each time, and I
> also think it would be better for you, since that makes it much easier
> to playtest the new changes instead of going about it merely by
> guesswork.
The current changelogs are detailed enough to point to what needs playtesting.
2009/4/20 bugs buggy :
> Are you saying you commit the changes first, then write your changelog
> at your site?
Hmm. Apparently, I've been committing with a summarized changelog from
my site. I guess I'll use the full changelog now.
> If not, a simple copy & paste from that would be good enough for the most
> part.
> I rather see a '+' | '-' table generated, so at a quick glance, we can
> all tell if you nerfed something, or made something stronger.
>
> The main point is, when you say something like "VTOLs partially fixed.
> " and don't go into details on the how & why, it gets a bit confusing
> to those that don't live in CSV hell ;), and they must do a diff to
> see what you have done.
Other than "VTOLs fixed" and "cyborgs fixed" every once in a while, I
generally indicate which direction ("Heavy cyborgs are slightly
lighter. Should be able to move now."). In those cases, it's because
it's a bunch of minor tweaks in both directions: Some are slightly
weaker, some are slightly stronger - saying which one's which takes
_way_ too much time. The diff generated automatically by Trac should
be enough, I think.
-Zarel
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] New defaults for 2.2?
2009/4/23 Christian Ohm : > - Change the font to DejaVu Sans: monospaced fonts are quite ugly imo, and > there's no need for it, OSX even uses a proportional font already. Agreed, although I'm not a big fan of DejaVu Sans, either. I preferred the old bitmap font... The problem is that most of the free fonts out there look pretty ugly (I don't think very many typographers are OSS type people). By the way, when can we fix the problem of Warzone attempting to scan the entire Windows font directory on startup? It's causing start-up take as long as half an hour on some computers. > - Play videos fullscreen: Options for smaller display exist, and with the > nearest neighbour filtering it uses now the only blur is what is in the > videos itself. Let's apply the no texture_rectangle patch already. > - Coloured cursors on: Comments in the code say it has a performance hit, but > there's a config option to disable them (and shadows also have a cost and are > enabled by default). But it's a severe performance hit. Mouse lag is unacceptable in a real-time strategy game. > - Disable pause on focus loss: If you want to pause, you can always press > escape to pull up the menu, and it's annoying as default. Agreed. > Per also wanted to disable the rotating radar. It doesn't bother me much, but > I > agree that it's somewhat strange. No, I like the rotating radar. We should fix the Mac OS X issue, though. I reported it a while ago and I don't think anyone's fixed it yet. > I've attached a patch that changes those defaults. The font change needs an > updated dev package with the DejaVu Sans and Sans Bold fonts included. Since > OSX apparently doesn't support monochrome cursors, I've made the menu option > unchangeable for it. > > OK to apply? Comments, or other defaults that we might want to change for 2.2? Trap Cursor should be on by default. Texture resolution should be 2048 by default. 2.2 should keep the texture resolution setting at 2048 regardless of whether or not it supports that high. That way, I don't have to change the texture resolution back up each time I play trunk. - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] New defaults for 2.2?
2009/4/23 Christian Ohm : > I don't like it much, either. But this was possible by deleting 18 bytes, > and its NOT MONOSPACE, which changes the look from ugly to ok (I hope we can > agree on that, except perhaps the person who chose the mono font). That's > enough for me (until we find a good free sans serif font we can all agree > upon). Oh, I agree we should do it. I'm just saying we should keep looking for something better. Do you think DejaVu Sans is better, or DejaVu Sans Bold? > I think that's fontconfig's doing. I don't know how that works on Windows, > but it should be possible to use a private font directory (but then you don't > have fallback fonts, and the included font(s) have to provide all needed > glyphs). So how exhaustive is DejaVu Sans? > [Colored cursors] > Really? I enabled them and noticed nothing. Haven't played much since then > though, only short testing. Yeah, well, I have a reasonably specced: 2.4 GHz Core 2 Quad 6 GB RAM GeForce 8800 GT And colored cursors still provide a noticeable performance hit. I can't stand cursor lag. I might be more sensitive to it than most, though. > Not for me, or do we have an untrap cursor hotkey (the trap cursor workaround > being alt-enter)? Alt-Enter doesn't work on Windows, and I don't think it works on OSX either. LogoKey and Alt+Tab work for "untrap cursor" in Windows, and so does Esc. I'm guessing at least Esc and Alt+Tab should work in Linux. Cmd+Tab doesn't work in full-screen mode in Mac OS X, which is really annoying, but I don't know about windowed mode. > How about changing the config directory for trunk to .warzone2100-trunk > instead? Works for me. 2009/4/23 bugs buggy : > I am not sure it is fontconfig, freetype, or QuesoGLC. I just know > that I can't duplicate it, and I don't have vista to really see what > lib is responsible. > I just know that we don't do anything wrong in the codebase, so the > problem should be reported upstream. To who, I dunno, but the above > listed ones are prime suspects. "Blame upstream" seems to be mostly an OSS thing. Have you ever worked in proprietary software? If upstream has a problem, they're unlikely to fix it, so you work around it. I mean, do we want to make the best RTS in a theoretical world where upstream is always perfect, or do we want to make the best RTS on Earth? > [Texture resolution] Again, no, that is way too big. 128 or 256 should be > default. 2048 in trunk is the equivalent of 128 or so in 2.2. Seriously. Compare 128 in 2.2 with 128 in trunk. 2.2 will look sharp, and trunk will look _ridiculously_ blurry. - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7156] branches/2.2/src/combat.c
2009/4/24 Per Inge Mathisen : > On Fri, Apr 24, 2009 at 3:24 AM, wrote: >> 2.2: Commit patch #374: Fix artillery prediction, submitted by Adam Olsen. > > Backport to 2.1? Would make sync even worse with earlier versions. The current artillery prediction is good enough, I'd say. - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7258] trunk/src
2009/5/1 Per Inge Mathisen : > On Fri, May 1, 2009 at 9:14 AM, wrote: >> Misc. multiplayer bugfixes. > > Please work harder on your commit messages. Ehh, sorry about that. Was trying to get back to working on other bugfixes. The specific fixes are: - Interface is no longer hidden for a few seconds when someone changes team/color/location/readiness in multiplayer staging area - Continue looking if chosen research gift is invalid - Internationalize "The game is full!" message -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Install OpenAL silently
Hey, guys.
Having to click "OK" twice in the middle of an installation (to
install OpenAL) is kind of annoying. Also, having the OpenAL installer
pop up when the Warzone installer is in silent mode is not only
annoying, but defeats the purpose of silent mode.
Apparently, the reason it's currently not silent is because we
supposedly can't agree to the license for the users.
But I've looked through the license being agreed to:
> Creative Labs, Inc. is providing you with this OpenAL32.dll installer and
> other
> OpenAL files ("Software"). You may use and freely integrate with your
> software
> applications and distribute such throughout the world at no cost or further
> obligation to Creative.
That's not a EULA, that's a distribution license. Furthermore, it
gives us permission for free distribution: "You may... freely
integrate with your software... at no cost or further obligation." It
doesn't say anything like "as long as your users agree to this
license." Making our users agree to it would count as a "further
obligation". It's like the GPL - you don't need to agree to it to
install software with that license, only to redistribute it.
Because of this, I think we can safely make it silent.
Thoughts?
-Zarel
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Getting rid of third-party mods
2009/5/7 Dennis Schridde > Am Donnerstag, 7. Mai 2009 21:11:00 schrieb bugs buggy: > > And note, AIV is *not* a 3rd party mod IMO, that should stay for now. > > Why dont we remove 1.10-ai and replace it with aiv? Are there issues with the > latter? (1.10-ai could stay as a mod if someone desires.) The issue is that 1.10-ai is a better AI than Aiv. Aiv uses a _very_ limited subset of the weapons, namely, only those that were overpowered in 2.1 with Troman's balance (namely, minipod tanks, cannon tanks, and flamer cyborgs - no VTOLs at all). This also makes Aiv very easy to counter: It just so happens that the only units and structures Aiv uses are the only units and structures with a weakness to flamer. Even in 2.1, unless you stack the odds _way_ against you, a flamer cyborg rush will take care of Aiv. Aiv's flaws are very readily apparent in T3. In 2.1 balance, T3 weapons are weaker than T1 weapons, so Aiv refusing to use any weapon beyond Hyper Velocity Cannon was strategically sound. In 2.2, T3 weapons are again the more powerful ones, and while 1.10-ai eventually gets to Scourge Missile, Gauss Cannon, and Pulse Laser, Aiv will stick with Hyper Velocity Cannon and lose utterly. In addition, while Aiv is technically a first-party mod, it's unmaintained, and there are many Aiv-related crashes that no one has fixed. 1.10-ai is more stable, since it's actually somewhat maintained. I'm advocating dropping Aiv not because it's a third-party mod, but because it's worse than 1.10 AI, and it's caused many crashes that no one's bothered to fix. - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2 RC1 scheduled for release this weekend
2009/5/7 bugs buggy : > And I would like to remind everyone, that 2.2 is just as stable (if > not more so) as 2.1 was at the time of its release. Are you sure of this? The forums are rife with people going back to 2.1 because 2.2 is too unstable. Complain all you want about the vagueness of their bug reports, but the fact remains that the bugs are there. - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2 RC1 scheduled for release this weekend
2009/5/7 bugs buggy : > How about you compare apples to apples? > Those are 'debug' builds, as you are well aware of, and I am sure I > don't have to explain this to you, but since you brought it up... > > The main reason why people find the current 2.2 beta 'unstable' is it > is a *debug* build. Debug builds assert. Release builds don't. That > isn't exactly a news flash is it? > So of course a *debug* build will *seem* more 'unstable' than a > release build, it is *meant* to give us more information about > *possible* issues. > > If we were to release a new 2.1 build and only do a *debug* build, > you will pretty much see the same issues & asserts, and, the forums > will be wondering how 2.1 became so 'unstable'. See, the problem is that people are reporting that the game crashes whenever people click "Ignore" on the assert. Since clicking "Ignore" causes a crash for these asserts, I'd think that nearly every assert corresponds to a crash in the release version. - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2 RC1 scheduled for release this weekend
By the way, guys, is it okay if we release 2.1.4 concurrently with 2.2 RC1? Buggy and stiv seem to be very against the idea, Cybersphinx sounds neutral, Per sounds for it. Here's why I think releasing 2.1.4 is a good idea: - As mentioned earlier in the 2.2 RC1 thread, it's not as stable as 2.1 yet. - 2.1.4 has one of the most requested bugfixes - namely, how the interface hides itself whenever someone changes color/team/position/etc in multiplayer game staging - We're not going to be releasing a 2.2 stable for at least another three weeks - people should get an interim stable release. - It theoretically shouldn't be more work than just making a release. I mean, it sounds like we're dropping support for 2.1 either way. I can handle most of the work - I just need people to compile and upload source tarballs, Windows binaries, and Mac binaries. Giel? EvilGuru? If we do it at the same time as 2.2 RC2, it shouldn't be too much more work, right? - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2 RC1 scheduled for release this weekend
2009/5/8 Stephen Swaney : > [16:28] it is hardly effortless > [16:28] and when looking more closely at the bugs fixed since 2.1.3, > i'm not so sure anymore It seems a bit disingenuous to quote per from before I explained what the bugs were. Here are some quotes from _after_ he said that: [16:27] and when looking more closely at the bugs fixed since 2.1.3, i'm not so sure anymore [16:27] which bug is it that warrants the release? [16:28] * Fix: No longer shows map and hides interface when others switch color/position/team/etc in multiplayer staging area. (r7257) [16:28] That's the most requested bugfix in #warzone2100-games [16:30] Zarel: if EvilGuru and Giel agree to spend the effort to make builds, i see now reason not to do it [16:31] Meh. What if we release it concurrently with 2.2 RC1? [16:31] well, that kinda has a precedent, doesn' it ;) [16:31] ? [16:31] i mean, we did that for the previous release [16:31] so why not > Compile 2.2 RC1 with the asserts off. That seemed to be the issue, judging > from the IRC conversation. This is why not: > See, the problem is that people are reporting that the game crashes > whenever people click "Ignore" on the assert. Since clicking "Ignore" > causes a crash for these asserts, I'd think that nearly every assert > corresponds to a crash in the release version. ^^ which is the bigger issue. > I concede to your claim that this is the most important bugfix > in the history of software development, but isn't it also in 2.2? True, but 2.2 is a significant time off. > 3 Weeks - that's like 21 days? :P That's "at least". > Aren't we? And if we are, why not get on with 2.2? We don't really know for sure if 2.2 is actually going to be rushed out that fast. While I currently have no objections, who knows what could turn up? We're getting quite a few bug reports from the allegedly small number of testers Buggy complains about. > Actually, releasing two versions should be approximately twice as much work. I'd assume that making a release is one of those things for which the amount of time spent preparing for it is significantly greater than the amount of time spent during it. It's kind of like writing an e-mail. Writing a six-sentence message at once is a lot easier than writing one sentence each day for six days, since most of the time is spent in opening the e-mail client, going to Drafts, opening the message, collecting your thoughts, etc, etc. Heck, I wouldn't even need to say "I'd assume" - I know from experience that two releases at once is easier than two releases separately. The only part I don't know how to do is upload to Gna (or build 2.1, but as long as it isn't significantly different from building 2.2, my experience applies), and I've uploaded to other places often enough to know it's easier to do concurrently than separately. 2009/5/8 bugs buggy : > People are not going to test 2.2 if the 'most requested bugfixes' are > fixed in 2.1. They have no motivation to upgrade. I should also mention that I accept this as a valid objection to 2.1.4, so there's little point in arguing further. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Getting rid of third-party mods
2009/5/8 bugs buggy : > Check the lua branch. Most all these script issues will be fixed with > lua, once we get that up and running. > AFAIK, Gerard did have AIV at least partially converted. Does Lua fix the BecomePrey issues? If so, why not just replace it with BecomePrey? BecomePrey was designed for 1.10, and Aiv was designed for 2.1, and 2.2 balance is _much_ more similar to 1.10 than 2.1. Plus, I've heard that BecomePrey is overall a much better AI than Aiv - many have mentioned that BecomePrey is hard to beat at the lowest settings, while Aiv can be beaten by spamming flamers on lowest pretty easily. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Final call for 2.2 changes
2009/5/8 bugs buggy : > About mods: > * NTW Delphino said he will maintain it, and wishes it to remain in svn. Someone needs to give Delphinio SVN access. > * 'grim's' mod is broken. ( I think we should remove it, for reasons > stated on ML) Agreed. > * Remove 'autoload' folder? ( I think we should remove it, for reasons > stated on ML) Sigh. I've had "rewrite loading code" on my list of things to do, for a while. Gimme some more time with it. > About sequences.wz > * It does *not* contain any info about all the files inside. Should > it have GPL / COPYING.REAMDME in it? Well, I think the GPL included with the rest of the game should suffice, shouldn't it? > * I also suggest a version number for this file. (for when/if we > update the vids) I'm guessing we're only going to update them once, ever, so we can just rename it to video.wz, then. In fact, I propose after we rename all the .ogg files to .ogv and reencode them, to distribute a 160 MB video.wz, and a 1 GB video-highquality.wz. > Config file changes: > * Any more requested changes? About the colored cursor thing - I have a decently high-end computer and I still experience mouselag. It might not be consciously noticeable, but it could still impact user experience. > About known issues: > Do we revert this patch, or apply the new patch (Artillery prediction > fix) ? http://developer.wz2100.net/ticket/374 We've done neither. We have, however, fixed some of the other issues with this patch. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Final call for 2.2 changes
2009/5/9 Dennis Schridde : > He has it already, since at least a few months. > His last commits happened to Gna though, so someone will need to merge them > into SF. He has commit access to Gna. He doesn't have commit access to sf.net (or if he does, he doesn't know how to access it - he's been asking me about it a few _days_ ago). > No, since the file is distruted independendly from the game, it needs it's own > license file. I suggest naming it COPYING, to match the common. The only time it comes up is if it's downloaded with the installer, in which case it's effectively distributed with the game. Feel free to add that file, though. > I suggest a version number, too. Should we ever update it, cutscenes-1.wz > makes it clearly distinctible from cutscenes-2.wz, while cutscenes.wz could be > anything. > So just for the possibility (new/better Theora encoder is one of them) I > suggest a version number. You never know what the future brings. I prefer "video" - it's more widely understood than "sequences", "fmv", "cutscenes", or "cinematics". Other than that, we don't have version numbers for base.wz and mp.wz. Why should this be different? > That is why there is a config option to switch to hardware cursors. Afaik this > issue only appears on high end nVidia cards, which is probably not the > majority of our userbase. Most users don't config away from defaults, which is why defaults should be the best settings in the usual case. If it _really_ only affects high-end Nvidia cards, then it's not a big deal, but I think it's more of an issue that the game could feel laggy to players who don't know that it's mouselag. - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Final call for 2.2 changes
2009/5/9 Kreuvf : > Just in case this scheme is a proposal: This reminds me of "New File (1)", > "New > File (2)" etc. which is why I suggest adding the date to the file-name such as > cutscenes-2009-05-09.wz. Additionally the problem with adding numbers is that > people might think that *-1.wz, *-2.wz etc. are different parts or stand for > the > different campaigns - whatever. People should not get confused. A scheme like: videos-1.0.wz should fix it. Dates in a filename is a really bad idea. It's marginally acceptable for nightlies or something, but not for releases. Either way: 2009/5/9 Dennis Schridde : > Am Samstag, 9. Mai 2009 10:14:51 schrieb Zarel: >> Other than that, we don't have version numbers for base.wz and mp.wz. >> Why should this be different? > Those are inside a warzone2100-x.y.z.tar.bz2 We could put our different video.wz files under a corresponding directory at Gna. Heck, put a COPYING file in each of those directories, too, for good measure. - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2 RC1 scheduled for release this weekend
2009/5/9 Christian Ohm : > I don't think releasing 2.1.4 will result in much less _useful_ testing for > 2.2. Yes, you might get more people to try 2.2, but if they are "tricked" into > using it they'll just see it's unstable yet, and go back to 2.1 (if 2.1 isn't > too unstable for them either) instead of giving useful bugreports. But with a > 2.1.4 release those who don't want to test 2.2 get a better 2.1. What is it now? Devu, Christian, Kreuf, Per, me in support cybersphinx neutral Buggy, stiv against Let's just release 2.1.4. Seriously, I've never heard of dropping support for the current release branch just because you want everyone else playing the development branch, no matter how close the development branch is to release (and, again, I don't consider "three weeks if we're lucky and nothing goes wrong" to be "close"). > OTOH announcing the 2.2 releases on more than just our website (Freshmeat has > only 2.1.3, the Linux Game Tome is at 2.1.1 for example) will reach a far > wider > audience and thus potential testers. Incidentally, the only reason Freshmeat has 2.1.3 instead of 2.1.0 is because I submitted it to them. These "aggregator" sites should really do their aggregation themselves, instead of waiting for us to do it for them. <_< 2009/5/10 Dennis Schridde : > Am Sonntag, 10. Mai 2009 14:10:00 schrieb Christian Ohm: >> So you want to do release builds then as well? I thought it was "no release >> builds before release", not sure who said that though. > In fact it is very different from that: Always release builds, never anything > else. > I don't want to repeat the reasons again, so if you forgot, just ask me again. I dunno. The policy I've been recommending is (and what we've been doing since 2.1.2, iirc): Release builds only for stable, RC Debug builds only for beta, alpha, everything else Or maybe both for RC. Ensures testers have proper tools for testing and can provide good feedback, but stable is stable enough for widespread use. 'Course, that's just my opinion - I have no idea what official policy is. And yes, I don't think I was here the last time you gave the reasons for "always release builds", so I'd like to hear them again. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Trunk and free software ati drivers
2009/5/9 bugs buggy : > That is a known issue with the gfx. The road gfx needs to be redone. > Any volunteers? I've done most of the work; just never got around to finishing it. I should probably throw the PSD somewhere so someone else can finish it. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] pausing the game
2009/5/17 bugs buggy : > When you hit pause, it just shows the menu, and you will get a black > screen, and CPU time goes down to practically 0. Oh, wait, black screen? Can't you just cache the current screen, so we don't redraw it? Then it'd use significantly less CPU, and still look exactly the same. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] pausing the game
2009/5/17 Christian Ohm : > On Sunday, 17 May 2009 at 12:24, Zarel wrote: >> Oh, wait, black screen? Can't you just cache the current screen, so we >> don't redraw it? Then it'd use significantly less CPU, and still look >> exactly the same. > > But needs support for screen sized textures, or drawing with several tiles. Graphics has become _so_ much more complicated since the days when you could just memcpy to and from the screen buffer. :( -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] pausing the game
2009/5/17 bugs buggy : > So what is the bottom line? Apply this patch for 2.2, and not trunk, > and if enough people don't like it, we can revert back to the old > behavior on the release after 2.2? Oh, no, we are not changing it up to a black screen in the RC stage of 2.2. Is it really that hard just to store the rendered screen? Or re-render as little as possible? -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Handling GIGO (Garbage in, Garbage out)
2009/5/20 bugs buggy : > For those of you that have missed it, I am currently changing (some) > ASSERT()s to ASSERT_OR_RETURN() to prevent crashes and / or garbage > output in release builds. > > Of course, the change only happens if the condition in the ASSERT can > cause a crash/ undefined behavior / garbage output. > > The only wrinkle in this, is, it will add a bit more conditional code > to each function the change is done in. This may slightly slow things > down. > > Before I start changing allot of lines, I would like to know if anyone > has any issues with this? No problems here. DO IT. 2009/5/21 Kreuvf : > Slightly slower? What is "slightly" slower for you? :X He's using unnecessarily scary language. The speed difference is unnoticeable in practice (it's far less than the difference in speed between debug builds and release builds), and most importantly it makes the game much more stable. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] The "needinfo" status.
Currently, the only way to set "needinfo" status on a ticket is to close it. The problem is, due to a recent spam attack, normal users no longer have the privileges to reopen a ticket (or remove the "needinfo" status). Furthermore, even if they do, they can be intimidated by the fact that a ticket has been closed (and this is a psychological thing - it's not something we can get around just by telling users that it's fine). Therefore, I propose that we interpret "needinfo + close ticket" to mean "This ticket has been deserted (closed), and we do not have enough information to solve this problem (needinfo)", and that we do not close tickets with "needinfo" unless a question sits unanswered for a week or so. If we get a new ticket without enough information, we should just ask for more information and leave it open, and only close it after a week of no further information. Thoughts? -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Savegame incompatibility rc1->rc2
2009/5/27 Christian Ohm : > Keep the fix _and_ make rc2 load rc1 savegames? Not sure if that's possible, > but savegame compatibility is important (esp. for campaign, which doesn't seem > affected - this time). Wouldn't it just be a matter of suppressing this error? error |01:21:11: [eventLoadContext] Context 1 of 6: Number of context variables (946) does not match the script code (945) If it causes problems, see where to reindex the variables? -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Savegame incompatibility rc1->rc2
2009/5/27 bugs buggy : > That is why we should revert, and fix this error another way, like I > explained before. Do you have a good way of fixing the error? If you do, I welcome it. Otherwise, I think this bugfix is more important than skirmish savegame compatibility (campaign savegames are fine). Another idea - when the script loader breaks like it does here, just restart the AIs? -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Savegame incompatibility rc1->rc2
2009/5/28 Per Inge Mathisen : > Won't work for campaign scripts. Campaign scripts aren't broken, so that's not an issue. :P Besides, skirmish AI changes a lot more than campaign AI does. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Savegame incompatibility rc1->rc2
2009/5/28 bugs buggy : > I still don't think you understand the issue, if we have 2 members for > each struct, x1=10, x2=20, y1=5, y2 = 6, then it is fine. > If one of the structs now has 3 entries, it doesn't match the data, so > the first struct will now have 10,20,5 and the other struct will have > 5,(whatever the next value is), and so on. > > We would have to reset all values, and that would mean the savegame is > nothing like it was before. ...why? I am indeed suggesting that we reset all values, and I don't see why the savegame would be affected. Remember, this is in skirmish, not campaign. The worst that happens is that the AI is disoriented for a few seconds while it recounts its units and structures. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Savegame incompatibility rc1->rc2
2009/5/28 Zarel : > ...why? I am indeed suggesting that we reset all values, and I don't > see why the savegame would be affected. Remember, this is in skirmish, > not campaign. The worst that happens is that the AI is disoriented for > a few seconds while it recounts its units and structures. Heck, I've suggested the exact same thing as a temporary solution to script crashes. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Final checklist for 2.2 (Final) -- ETA of release is 5/31/09
2009/5/31 bugs buggy > Just waiting on some windows icons, and then we can tag it, and then > make the builds. Icons are done. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Drag rearm pad building
2009/5/31 Per Inge Mathisen : > This small patch makes it possible to drag a line of rearm pad > production similar to how walls and defenses can be built by dragging > the production with the mouse. It also removes the obligatory empty > tile between rearm pads. Um... but the obligatory empty line between rearm pads is like a staple of Warzone! We can make the drag only place every other rearm pad. We can just rewrite the drag routine to only place structures in the places they can go, instead of invalidating the whole line when only a few of them are in bad places. I've also been considering leaving the build menu up if a building is placed while Shift or Ctrl is held down. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2 has been released!
2009/6/1 Kreuvf : > The ChangeLog states that "Mortar Fast Loader requires Mortar Rapid Loader > Mk3", > but I cannot find "Mortar Rapid Loader" (or any line containing mortar and > rapid) by grepping for it in the po files. I did some research then and found > the following: > > Looking at the change (7559, file prresearch.txt) it becomes clear that the > description (see above) is wrong: > Mortar Fast Loader (R-Wpn-Mortar-ROF04) now requires > Mortar Autoloader Mk3 (R-Wpn-Mortar-ROF03) and the pre-requisite > Cannon Rapid Loader (R-Wpn-Cannon-ROF04) has been changed to > Cannon Autoloader Mk3 (R-Wpn-Cannon-ROF03). Whoops. Well, it was R-Wpn-Mortar-ROF03. I didn't really cross-reference names.txt to figure out what it was called. But yes, I meant Mortar Autoloader, not Mortar Rapid Loader. On second thought, Mortar Fast Loader should be renamed to Mortar Rapid Loader. All the "Fast Loader" research items, like "Sensor Upgrade", are boilerplate text that Pumpkin never got around to replacing. Ideas? - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] change the way we handle trunk tertiles ?
Hmm, from the second one, it appears there are a few other tiles you haven't managed yet. If we just turn it into generic burnt patches, I think that'd be good. -Zarel 2009/6/1 bugs buggy : > I tested a few changes, and fixed tile-73.png, tile-51.png, > tile-50.png, tile-49.png, tile-72.png (the tracks), and these are the > results so far: > http://imagebin.ca/view/fkmJrERR.html and http://imagebin.ca/view/YW2tae.html > > I only fixed the 128x128 tertiles, and then I wondered why do we even > bother with anything smaller than that for trunk? > > We should go back to letting openGL handle mipmaps for us, basically, > like how we handle the terrain textures. > > Any objections to this? > > ___ > Warzone-dev mailing list > Warzone-dev@gna.org > https://mail.gna.org/listinfo/warzone-dev > ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] change the way we handle trunk tertiles ?
> 2009/6/1 bugs buggy : >> I tested a few changes, and fixed tile-73.png, tile-51.png, >> tile-50.png, tile-49.png, tile-72.png (the tracks), and these are the >> results so far: >> http://imagebin.ca/view/fkmJrERR.html and http://imagebin.ca/view/YW2tae.html http://imagebin.ca/view/xLiOkU1X.html Here's my latest try. -Zarel P.S. Apologies for top-posting my last one. I blame Gmail. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Project rename, website changes
Hey, dev list and/or staff forums (This message has been sent out to both). I have several proposals for changes. First, the minor changes: -> The site logo in the upper left should be updated to be inline with the new Warzone logo. It's the only place the old logo still appears. A new one, correctly sized, can be found here: http://forums.wz2100.net/viewtopic.php?f=3&t=2990&p=29583#p29583 -> The "Development" tab should be removed, and the "Trac" tab should be renamed "Development". I've already gone and merged the information from Development into WikiStart page, and we do not need that many tabs in the header. -> It might help to add a "Download" tab between "FAQ" and "User Guide". -> The Blog _really_ isn't updated enough for its entire own tab. We mention new blog posts on the home page; I think that's enough. I think we should, however, find some way to merge the blog and the news system. -> I believe the Warzone Guide is complete enough that it can directly replace the "User Guide" tab (so that the tab button takes users directly there). If there's a thematic issue, I can re-layout the Guide to match the current Warzone site. I can also add whatever information currently on the User Guide page to the Guide, if requested. Those changes should bring the Warzone site tabs to: Home | Download | FAQ | User Guide | Forums | Development Six tabs - not ideal, but better than the seven we currently have. And now, the major proposed change: Let's rename our project from "Warzone 2100 Resurrection Project" to "Warzone 2100 Project" (and the abbreviation from "WRP" to "WZP"). Reasons include: 1. At this point, after five years, there are no other Warzone 2100 projects - the only other one (Warzone 2200) is dead and never released anything at all, no binaries, not even any source. We are _the_ undisputed Warzone Project. 2. There's no confusion that we are affiliated with Pumpkin - Pumpkin's been gone for ages - anyone who has heard of the old Warzone and could potentially confuse us would know that. And if they don't, there's still the "Project" in there for disambiguation. 3. We are no longer "resurrecting" anything at this point. We have _succeeded_ in resurrecting Warzone and making a great cross-platform game out of it. Now, all we're doing is continuing the development of our successful project. We can signify this achievement by removing the word "Resurrection" from our name. 4. "Resurrection" is confusing to users who do not know our history. And I don't think it's important for your average Warzone to know the entire history of the project, however amazing that is. 5. New users (who have never heard of Warzone before) who visit the site may erroneously guess from the title that the game has something to do with resurrection. "Project", on the other hand, leads users to the right direction for what the campaign is about. 6. It's much shorter. So, what does everyone think? I would _really_ like your feedback on these. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Project rename, website changes
On Wed, Jun 17, 2009 at 3:21 AM, Dennis Schridde wrote: > Hi Zarel, > hi list! Ello. > http://developer.wz2100.net/ starts with bug reports. For a general > development introductory page this might not be the best choice. I would put > it more towards "Programming", and maybe even dedicate an own page to it. > - Reason: The introductory page should direct to the right documentation. The > chunk of text at the beginning draws more attention than necessary. > Apart from that: Agreed. I agree that it's not perfect, but I'm at a loss for further improvement, and I feel like I'd lose information from it if I rewrote it entirely. Feel free to make whatever changes you see fit (it is a wiki, after all). > PS: Is it possible to improve the CSS of http://developer.wz2100.net/? I like > the one of http://wz2100.net/ a lot more, if we are going to use the site not > exclusively for technical documentation. The one of wz2100.net is missing a lot of the CSS that developer.wz2100.net has. I had to argue with Giel for a while to get monospaced fonts the right size, and right now superscripts still do not render correctly (compare http://wz2100.net/download with http://developer.wz2100.net/wiki/Download ). It also doesn't render indentation properly (compare http://wz2100.net/ with http://developer.wz2100.net/wiki/Website/Frontpage ). Overall, it's missing a lot of CSS that's probably used in the wiki. While I agree that what it does implement, it implements better, but we should probably duplicate all the features of the current CSS file first. On the subject of CSS, the forum CSS sometimes makes links invisible until a user mouses over them (limited testing seems to show this occurs only on unvisited links to URLs within the wz2100.net domain) - this should be fixed. > I would prefer to have such stuff in the Wiki. > - Reason: Ease of editing. Infeasible, because it uses a ton of charts that are formatted in ways that can't be done on the wiki (the pages are stored in raw HTML). Plus, many of those charts are generated on-the-fly, and it would take lots of work to change the wiki on-the-fly. Plus, the URLs wouldn't look nearly as nice. Plus, wikis in general impose limitations that simply don't work in a guide. > If that's infeasible, at least make sure it's on the same server (make > wz2100.net a mirror using rsync, for example) and stays in line with the > current layout/style. (Use the same (links, not copies) CSS files.) Ever since it's been moved to guide.wz2100.net, it's been on the same server. I would allow any user to edit the Guide pages, however Kamaze isn't letting me access the user database, so I can't identify users to allow them access. Currently I just give access to nearly any user who asks for it. Using the current layout/style is a bit more complicated. I can duplicate the _current_ style, and use its stylesheet in addition to my own, but I can't guarantee that it would be updated when the main site's layout is updated (that would be up to Kamaze). > In addition http://guide.wz2100.net/ is not an introductory page like > http://wz2100.net/user-guide is. > http://guide.wz2100.net/intro comes closes, though it is not the frontpage. Well, I'm not sure an intro page would make a good home page. A contents index with quick links to major sections makes the most sense to me. More suggestions along these lines would be nice. > It also has style issues: > - Starts with a *huge* flash box, which makes the page look almost empty on > first sight for me. Well, the video _is_ a good introduction. And it's only 640x480. I guess I could use the 320x240 one again. > - The "Introduction" section should be merged into the http://wz2100.net/ > frontpage if necessary. In this location it seems like duplication. Agreed. > - "Installing" mentions compilation instructions. I'd prefer a link to the > Wiki instead. It _does_ link to the wiki. It just also provides basic compilation instructions. I believe this part was lifted from the Docs Project - in fact, the entire introduction is a rewrite of the introduction in the Docs Project. > - The Documents Project finds no mention at all. The Documents Project is nearly completely written about the 1.10 version. I've moved nearly all the information relevant to 2.2 into the Guide itself. > - There is no hint to the Development section. "Hint"? If you mean link, there's a link to the development section on the home page. > - Contact information (better: a link to them) is lacking. Can be added. > - The navigation panel on the right is not immediately noticed as such. ...? What navigation panel on the right? There's a navigation panel on the left, but I'm not entirely sure how you want it to b
Re: [Warzone-dev] Project rename, website changes
On Wed, Jun 17, 2009 at 10:10 AM, Kamaze wrote: > We could/should do a lot of work to improve the website. However, can we > delay this for around 3 weeks? In exactly 3 weeks I have to write the > last exam. Until then, I don't want to fill my brain with XHTML/CSS pain > and such things. Until then, can we make the simpler suggested changes? -> Replace http://static.wz2100.net/img/logo.png with the one found here: http://forums.wz2100.net/viewtopic.php?f=3&t=2990&p=29583#p29583 -> Remove the "Development" and "Blog" tabs, rename "Trac" to "Development", and add a tab "Download" between "Home" and FAQ. These shouldn't require "XHTML/CSS pain". ;) -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Reencoding the videos
On Fri, Jun 19, 2009 at 2:13 AM, Dennis Schridde wrote: >> For the windows installer, I was thinking if we could use a softlink >> for the files, and then we can always point them to the newest >> version, on gna, to download (if that is possible?) > warzone2100-sequences-latest.wz? Sounds good. What's wrong with sequences.wz? o_O -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Fwd: Summer of Mods and Indies Promotion with ModDB]
On Sun, Jun 21, 2009 at 4:16 AM, Kamaze wrote: > What do you think? LET'S DO IT. :D -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7807] trunk/data
On Mon, Jun 22, 2009 at 8:25 PM, Dennis Schridde wrote: > Are you sure this is exactly what you wanted? base.wz was meant to contain > (almost) all files, and mp.wz should contain the minimum necessary to be > replaced for a multiplayer game. (That part for which WZ has no way to > distinguish between sp and mp, like special stats.) > That is the reason why base.wz's string files contain strings only found in > multiplayer games, why it contains textures and icons not necessary for > singleplayer games, etc. > The final goal was to have just one wz file for the unmodified warzone2100 > base game one day. Ah. I didn't know. You should really publish this somewhere, like a high-profile wiki page. Fortunately, my change still makes sense. The base/stats/research/multiplayer folder is not used in any singleplayer mode (campaign/tutorial/fastplay), and is replaced with the entire mp/stats/research/multiplayer in skirmish/multiplayer. If we were really to force as much as possible into base.wz, we could move the stats/research/multiplayer folder from mp.wz into base.wz, but I don't think this should be done since it's incompatible with the other files in base/stats/, since it's designed for mp/stats/. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Website
On Tue, Jul 7, 2009 at 4:03 AM, Kamaze wrote:
> After the last exam tomorrow, I have a ~2 1/2 month semester break :o)
Oh, good, let's talk short-term.
First of all, the forum attachment limit needs to be raised by a lot.
A lot of users are reporting hitting attachment limits all the time.
Second, let's promote Neuralize (and maybe also Cathuria) to "Artist".
You might not need to give him forum moderator access, but he should
at least get an "Artist" badge for his work on the logo. After all,
this is an open-source project; people aren't working for money, so we
should at least give them a bit of reknown instead.
"Warzone 2100 Resurrection" should be changed to "Warzone 2100" in the
page titles. "Warzone 2100 Resurrection Forums" should be changed to
"Warzone 2100 Forums". If possible, "Frontpage" and "Index page"
should really be removed from the titles; they don't add anything.
This helps make the website look better on bookmarks bars and
bookmarks lists ("Warzone 2100" looks a lot better than "Warzone 2100
Resurrecti..." or "Warzone 2100 Resurrection » Fro...", which is how
it currently looks in my tab bar and bookmarks list respectively).
- Zarel
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Website
> On Tue, Jul 7, 2009 at 4:03 AM, Kamaze wrote: >> After the last exam tomorrow, I have a ~2 1/2 month semester break :o) Also, superscripts don't work correctly on the web root. Compare: http://wz2100.net/download http://developer.wz2100.net/wiki/Download -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7892] originals
On Thu, Jul 23, 2009 at 2:21 AM, Per Inge Mathisen wrote: > On Thu, Jul 23, 2009 at 12:17 AM, wrote: >> Add uncompressed terrain textures to originals. > > Did you do lossy compression on the terrain tiles? Yes (that's what the previous revision was), hence adding the uncompressed ones to originals/. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7892] originals
On Thu, Jul 23, 2009 at 2:57 AM, Per Inge Mathisen wrote: > On Thu, Jul 23, 2009 at 9:32 AM, Zarel wrote: >>> Did you do lossy compression on the terrain tiles? >> >> Yes (that's what the previous revision was), hence adding the >> uncompressed ones to originals/. > > Well, then I'm a bit worried about exactly what you did to those poor > tiles, since they were already indexed by running them through a png > optimizer program, IIRC. Um, I just indexed them. They were truecolor before. If they were run through a PNG optimizer, it might've been a lossless optimizer. - Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7892] originals
On Thu, Jul 23, 2009 at 10:41 AM, Kreuvf wrote: > AFAIK they were processed with optipng. That explains it; optipng is lossless. Feel free to run optipng on the new ones; they were saved moderately inefficiently with Photoshop. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Project Status?
On Sun, Jul 26, 2009 at 7:11 AM, Per Inge Mathisen wrote: > Unless I am hearing any objections, I'll be tagging for release today. No, no, no, by "relatively soon", I didn't mean _that_ soon! I still have some uncommitted patches! Wait up! Although, unless I am hearing any objections, I can tag for release either today or tomorrow after I commit everything. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Just a few comments about a few commits
On Sat, Jul 25, 2009 at 10:11 PM, bugs buggy wrote:
> Revision: 7842
> http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7842&view=rev
> Author: zarelsl
> Date: 2009-07-13 21:10:49 + (Mon, 13 Jul 2009)
> "2.2: Fix possible buffer overflow in missionFlyTransportersIn and
> getLandingX/Y."
>
> How does this fix anything?
> These should be asserts (so we can find the real cause), and this code
> fragment in getLandingX() and getLandingY() is just wrong:
> if ((unsigned int) iPlayer > 8)
> {
> iPlayer = 8;
> }
>
> You can't make that assumption, and you are possibly introducing more
> bugs with that.
I discussed this with cybersphinx before committing, and we've
discussed on IRC again why it's a perfectly valid assumption to make.
I'll go update the numbers to use the #defined ones, okay? =/
> Revision: 7887
> http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7887&view=rev
> Author: zarelsl
> Date: 2009-07-19 22:26:54 + (Sun, 19 Jul 2009)
> "2.2: Stop rotation when "Continue" is pressed after winning a
> multiplayer/skirmish game."
>
> IIRC, the whole reason behind this, was so you can't 'continue' the
> game as normal, ie, it is mainly to fire the fireworks, to show you,
> you won, or lost. This could introduce more bugs, since your screwing
> with the original design, and you haven't modified any of the scripts
> for the win/loss stuff.
> Which means, that in the least, I would add a info("Game has ended"),
> or perhaps a addDumpInfo("Game has ended"), so we can weed out crash
> reports when people "continue" after a win/loss.
Sure, go ahead and do that, or I will at some point.
Seriously, I would've modified the scripts for win/loss stuff, but
they don't make any sense at all. Where does a loss disconnect a
player? I still can't find that code. Please _please_ point me to it;
I've been asking for months.
> Revision: 7891
> http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7891&view=rev
> Author: zarelsl
> Date: 2009-07-22 22:12:41 + (Wed, 22 Jul 2009)
> "Index terrain textures (~68 MB -> ~22 MB); idea suggested by i-NoD."
>
> ... I thought any big data changes should be brought to the attention
> of the ML for comments. True, in this case, since most everyone is
> away, it wouldn't have made a difference, but it would have been nice.
> I also don't think this was required per se, perhaps when we would
> have branched 2.3...
Erm, I never heard this. Why? I mean, it's not exactly a controversial change.
-Zarel
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Project Status?
On Sun, Jul 26, 2009 at 12:53 PM, Christian Ohm wrote: > I object. "Let me put untested stuff in and tag immediately afterwards" > doesn't > exactly sound like good quality-control. It'd actually be rather well-tested, overall. I mean, I've been testing it myself, and the code logic is simple enough that it's doubtful anything would break. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Project Status?
On Sun, Jul 26, 2009 at 2:23 PM, Stephen Swaney wrote: > Has it been tested by anyone besides yourself? > > Not directed at you personally, but the standard excuse for > commiting broken code is "But I tested it myself!". It ought to be > the punch line of a joke. Programmers are the worst people to test > their own code. True, I guess it's better if we wait another week for release, and everyone can press S a lot and see if it works as advertised. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Test
On Thu, Aug 6, 2009 at 10:47 AM, Elio Gubser wrote: >> Does the mailing list work? > > yes Well, it does now. You'll notice he sent that two days ago, and we only received it today. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Patch] Spelling fixes, do those break things?
You're right; there are a bunch of those that I've left alone for precisely that reason. Most of the other renaming I can agree with, but why did you change Command Turret MkII to Command Turret Mk2? Unlike normal upgrades, they're actually different turrets (and thus do not upgrade automatically). -Zarel On Thu, Aug 13, 2009 at 8:18 AM, Christian Ohm wrote: > Since changing A-Veng-Trk-Guass would probably break things, I left it. For > the > other changes, I'm not sure. I changed the command turret for consistency with > other names. > ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Patch] Spelling fixes, do those break things?
On Thu, Aug 13, 2009 at 10:17 AM, Zarel wrote: > You're right; there are a bunch of those that I've left alone for > precisely that reason. > > Most of the other renaming I can agree with, but why did you change > Command Turret MkII to Command Turret Mk2? Unlike normal upgrades, > they're actually different turrets (and thus do not upgrade > automatically). > > -Zarel ACK TOP-POSTING SORRY SORRY I blame whoever made top-posting standard in e-mail. :[ -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Patch] Spelling fixes, do those break things?
On Thu, Aug 13, 2009 at 10:34 AM, Christian Ohm wrote: > Oh, ok, didn't know that. Then the difference to the other names makes sense. > But at least the "turret" could be capitalized. New patch attached. All those > changes are ok? Maybe call them Command Turret II, Command Turret III, etc, to make it more obvious they're not upgrades? =| -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7968] trunk/lib/exceptionhandler/exceptionhandler. c
On Fri, Aug 14, 2009 at 8:02 AM, Christian Ohm wrote: > The question is, why do we need to be C90 compliant in unix-only code at all? > r7850 removed quite a few "const"s that might help prevent problems. I'd > prefer > both this and r7850 to be reverted completely, but at least now it works. > Stiv/Zarel, did you actually test this before committing? Good question. Stiv came online one day and started talking about how he couldn't compile stuff for some reason. I wasn't sure on the specifics, but I committed his patch under the impression that all it did was move a few variable declarations to the beginnings of blocks... If it doesn't, you'll have to ask Stiv for details. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7968] trunk/lib/exceptionhandler/exceptionhandler. c
On Fri, Aug 14, 2009 at 2:46 PM, Stephen Swaney wrote: > I don't see anything about C90 in the command line and have no idea > where that idea came from. Erm, that part may have been a typo on my part. I may have meant C89. (Using "may have" since it's a long time ago and I don't remember precisely why I used "C90" in the commit message.) -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
