[warzone2100-dev] [Warzone 2100 Trac] #1507: Crash on Skirmish

[Warzone 2100 Trac]

#1507: Crash on Skirmish
+---
Reporter:  Lartza |Type:  bug  
  Status:  new  |Priority:  major
   Milestone:   |   Component:  other
 Version:  2.3 beta 9   |Keywords:   
Operating_system:  GNU/Linux|   Blockedby:   
Blocking:   |  
+---
 Arch Linux, compiled 2.3_beta9 myself. After long Skirmish game, 1vs1 bot
 the game crashed. I will try to reproduce it with GDB installed, but here
 is what I have for now.

-- 
Ticket URL: 
Warzone 2100 Trac 
The Warzone 2100 Project
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[warzone2100-dev] [Warzone 2100 Trac] #1506: 2.3 beta 7 FTBFS on Debian GNU/Hurd

[Warzone 2100 Trac]

#1506: 2.3 beta 7 FTBFS on Debian GNU/Hurd
+---
Reporter:  Paul Wise   |Type:  bug 
  
  Status:  new  |Priority:  major   
  
   Milestone:  2.3  |   Component:  Engine: 
Networking
 Version:  2.3 beta 7 (unsupported!)|Keywords:  
  
Operating_system:  GNU/Linux|   Blockedby:  
  
Blocking:   |  
+---
 Forwarding from:

 https://buildd.debian.org/status/package.php?p=warzone2100&suite=experimental
 #fail-warzone2100-hurd-i386

 warzone2100 fails to build from source on hurd-i386 with reason:

 [Category: none]
 > miniwget.c:251: error: 'MAXHOSTNAMELEN' undeclared (first use in this
 function)

 Looks like another PATH_MAX style failure. Solution is to either define
 MAXHOSTNAMELEN or restructure the code so that it doesn't hard-code
 lengths.

-- 
Ticket URL: 
Warzone 2100 Trac 
The Warzone 2100 Project
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [warzone2100-dev] Mod List Patch

[Guangcong Luo]

On Fri, Jan 29, 2010 at 9:14 PM, buginator  wrote:
> Yeah, I know this is obviously too late now, and I don't see any
> replies here on the ML, but I assume that the replies about this patch
> was requested here and not the ticket?
> Here goes my (late) comments.

Well, they were supposed to go on the ticket, but now that the
ticket's closed, here is fine.

> I am glad this didn't make it into the patch,  and I agree with
> cybersphinx's comment about this.  We shouldn't do this.

Can you be more specific? Why not?

> Why did you make a new ticket of this, since we talked about it here?
> http://developer.wz2100.net/ticket/688

There were major changes - I basically scrapped everything in that
patch, so I thought it was better off in a new ticket.

> Autoloading anything is still is a bad idea if not done correctly.
> Users need to keep track of what is in the autoload directory,
> remember to remove everything from that directory when they need to,
> and of course, check to see if the mod is the same version as what the
> host has (_before_ they enter the game), and possibly the most
> important thing, what happens if the mods conflict with each other?
> Anything less, and it leads to frustration for everyone, annoying host
> restarts, and possibly more bug tickets which were pretty much all
> alleviated with the removal of the autoload directory in the first
> place.

Well, now that Warzone lists all the loaded mods in several prominent
places, users will often be reminded of what's in their autoload
directory. Comparing versions will indeed be an issue - do you suppose
you could adapt the data checking code for that?

I don't remember any users reporting confusion over autoload folders
before they were removed, and I got the impression many users found it
quite convenient. I don't remember any bug reports over conflicting
mods - only a few forum threads that were easily resolved. We could
also only load the first mod in the autoload directory, if conflicting
mods is the only issue.

> Don't get me wrong, this is a good start, but it is only half done,
> and I would have preferred to hold off on this patch for a better
> version for a 2.3.1 release.

I still believe this is enough of a start for the benefits of an
autoload folder to outweigh the drawbacks.

> I also noticed that you didn't add the mod information to the crash
> report file?  Any reason why not?

I don't know how to. :( Point me to the loc, and I'll do it.

> The community itself has stepped up to the task of not having a
> 'autoload' directory and made frontends for warzone which is pretty
> cool.  Some of those appear to be cross-platform as well, so we could
> have bundled one of their programs until we fix this mod mess.

Yes, but they are relatively unnecessary, and I find them difficult to
use... and they suffer the many of the same problems the autoload
folders suffered. The fact that even those are preferable to the
command-line system should illustrate the necessity of autoload
folders.

-Zarel

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[warzone2100-dev] Freeze! Please read this about 2.3

[buginator]

As was previously mentioned a long time ago, Debian will be freezing in March.

 ok, so the latest release team mail says "we propose freezing
in March 2010."
 to transition to testing/squeeze, wz needs 10 days in
unstable, but IIRC as long as it is uploaded before the freeze the
release team will add an exception
 and if there are important issues that need fixing, we could
upload beta10 or 2.3.0 before the freeze and get exceptions as needed
 info about the Ubuntu debian import freeze:
https://wiki.ubuntu.com/DebianImportFreeze
  https://wiki.ubuntu.com/LucidReleaseSchedule
 so February 11th is the Ubuntu -> Debian import freeze
 and lucid imports from Debian testing
 so 2.3 needs to be in Debian sid before Feb 1st or you'll need
freeze exceptions

Now that that has been said, can I get the current status of what we
have ready or where we are at?

Are we going to meet this deadline or will we need the exception?

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[warzone2100-dev] VCS / DCS changes?

[buginator]

Greetings all.

Talking with sourceforge, they said if we are still having issues with
svn being slow, we can open a ticket with them, and they can migrate
us over to their BETA svn server which would need svn:// access
instead of https:// access that we have now.


 Buginator: Submit a ticket. We have a test svn system that
appears to be working for folks
 I can post you instructions in the ticket for how to get set up
 If you're thinking about moving to git, though, I can't
recommend it highly enough


Now, since it looks like most of the new guys, and the old guys like
git better anyway, we won't bother with hg.

The question is, do we want to give the new BETA svn server a shot, or
should we just switch to git and hope all goes well for everyone?

Pabs3 noted that "TortiseGit released a new version recently btw,
seems to be less buggy"...

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [warzone2100-dev] Merging the Qt branch

[Christian Ohm]

On Thursday, 28 January 2010 at 13:48, Per Inge Mathisen wrote:
> The Qt port branch has come a long way recently, and now runs entirely
> without SDL and QuesoGLC (and all its dependencies). I would like to
> merge it into trunk soon, so I would encourage everyone to take the
> branch for a test run, and see if you can find issues in it that need
> to be addressed first.

Well, I'm sure I already mentioned it, imo QT's fullscreen mode sucks (since
all it does is make the window use the full screen, my WM can do that as well).
Looks like resolution switching isn't implemented yet, if that works well at
least I guess I can live with it.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [warzone2100-dev] Merging the Qt branch

[buginator]

On 1/28/10, Per Inge Mathisen  wrote:
> Hello,
>
>  The Qt port branch has come a long way recently, and now runs entirely
>  without SDL and QuesoGLC (and all its dependencies). I would like to
>  merge it into trunk soon, so I would encourage everyone to take the
>  branch for a test run, and see if you can find issues in it that need
>  to be addressed first.
>

Cool.
Since the Qt branch was inactive (as in, everyone not committing
patches to it) for a long period of time, have you tried a test merge
(to a new branch?) first to make sure all is OK?

Once that is done, can I convince you of getting rid of popt and all
its dependencies as well?

My only question is what the performance hit will be (if any) going
from SDL to Qt.  Have you profiled it to get some rough estimates?

I can take care of the MSVC files, that shouldn't be a problem.  I
have made Qt stuff before with it.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [warzone2100-dev] Multi-turrets

[buginator]

On 1/29/10, Guangcong Luo  wrote:
> On Fri, Jan 29, 2010 at 7:36 AM, Per Inge Mathisen
>
>  wrote:
>
> > I highly doubt that forum users are in any way statistically
>  > representative of ordinary users, nor in my experience are they good
>  > representatives of the interests of ordinary users. We should be
>  > really wary of letting expert tweakers, the type of user that usually
>  > dominate such forums, determine where this project is going.
>

I agree about this point.  The vast majority of our userbase don't
frequent the forums.

>
> Sorry, I didn't hear any objections, and it seemed like we were making
>  most things into polls. What should we do about the one currently up?

You know, I think we need a forum section for polls, and then we can
throw lots of those stickies in that forum section.
Polls can be useful, but in this case, I am not sure how useful it can be.

>  Anyway, I'm sure ordinary users would enjoy multi-turrets, too, or at
>  least not mind them. As mentioned, in a choice between no multiturret
>  at all, and multiturrets that may look weird in certain turret
>  combinations, I'm guessing most would choose the former. As I
>  mentioned in the forum thread, anyone particularly bothered by how
>  certain combinations look can simply avoid using those combinations.
>

lol, so if they are bothered by it, then they also shouldn't play MP
games, since someone could make a combination that pushes them over
the edge!

I sure hope you increased the cost of this thing ?

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [warzone2100-dev] Mod List Patch

[buginator]

On 1/16/10, dak180  wrote:
> Because Zarel is currently unable to post to the list he asked me to pass
> this on; http://developer.wz2100.net/ticket/1415
>
>
Yeah, I know this is obviously too late now, and I don't see any
replies here on the ML, but I assume that the replies about this patch
was requested here and not the ticket?
Here goes my (late) comments.

> 4)Searches for videos-hq.wz and videos-lq.wz as well as sequences.wz. These 
> new
> proposed names help make sure that a user does not accidentally overwrite HQ 
> videos
> with LQ videos, and that a user can easily tell what kind of videos he/she 
> has.

I am glad this didn't make it into the patch,  and I agree with
cybersphinx's comment about this.  We shouldn't do this.

Why did you make a new ticket of this, since we talked about it here?
http://developer.wz2100.net/ticket/688

Autoloading anything is still is a bad idea if not done correctly.
Users need to keep track of what is in the autoload directory,
remember to remove everything from that directory when they need to,
and of course, check to see if the mod is the same version as what the
host has (_before_ they enter the game), and possibly the most
important thing, what happens if the mods conflict with each other?
Anything less, and it leads to frustration for everyone, annoying host
restarts, and possibly more bug tickets which were pretty much all
alleviated with the removal of the autoload directory in the first
place.

Don't get me wrong, this is a good start, but it is only half done,
and I would have preferred to hold off on this patch for a better
version for a 2.3.1 release.

I also noticed that you didn't add the mod information to the crash
report file?  Any reason why not?

The community itself has stepped up to the task of not having a
'autoload' directory and made frontends for warzone which is pretty
cool.  Some of those appear to be cross-platform as well, so we could
have bundled one of their programs until we fix this mod mess.

Oh, and just so I make it clear, the data checking code in the
codebase is NOT mine, it is all pretty much Pumpkin's original code
minus some of their bugs.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[9538] branches/2.3

[buginator]

On 1/28/10, Per Inge Mathisen  wrote:
> On Thu, Jan 28, 2010 at 10:34 AM,   wrote:
>  > Revision: 9538
>  >  
> http://warzone2100.svn.sourceforge.net/warzone2100/?rev=9538&view=rev
>  > Author:   zarelsl
>  > Date: 2010-01-28 09:34:18 + (Thu, 28 Jan 2010)
>  >
>  > Log Message:
>  > ---
>  > 2.3: Rename "original.wz" to "old-1.10-balance.wz" - I had an agreement 
> with Delphinio that the mod could be named anything but "original", which was 
> vague and confusing to new users.
>
>  This breaks compilation. You also need to rename the directory by the same 
> name.
>

Grumble... why didn't you speak up about this before the commit?
(see svn rant)

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[9038] trunk

[buginator]

On 1/7/10, Per Inge Mathisen  wrote:
> On Thu, Jan 7, 2010 at 4:01 AM,   wrote:
>  > PNG optimization, also known as 'Crush them all!'.
>
>  Again?
>
>  Did you measure any significant savings from doing this? It is kinda
>  annoying to have to download every image anew for every working copy,
>  you know.
>

This is highly annoying, in the future, if anyone has any big changes
that involved lots of files, please, please post to the list first,
and ask if it is OK.

The reason it is annoying, is with the current VCS, when we need to
revert back and forth we end up having to download noise again for a
savings that really didn't save that much.

BTW, uploading the tarball is another annoying thing.  Is there a good
reason for it?

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [warzone2100-dev] Replacing Aivolution with DyDo-AI

[buginator]

On 1/25/10, wp1004671-obooma  wrote:
>
> First of all, hello everybody in the mailing list.
>  I am not going, for now, to commit to anything else but DyDo, for the
>  future let`s see but my programmer skills are not that good...and here to
>  the second point, I have no idea how this all works ->no idea how to update
>  the several makefiles but before asking for help prefer have a look o my
>  own. I`ll come back asking for help for sure!!
>  DD
>  you see...I alreday learned the bottom-post (the default top-post was due
>  to the use of "roundcubemail" by host europe, the host provider I am using)
>  ;-)
>

Hello, and welcome aboard!
Are you a windows, or linux or mac person?

If you have any other questions about what you need to do, and are not
sure, then please, either mail the list, or get on freenode,
#warzone2100-dev and we can talk you through it, or as Zarel said, we
can do it for you.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[warzone2100-dev] Fwd: [Openal-devel] OpenAL Soft 1.11.753 released!

[buginator]

This was sitting in my inbox, and I thought it could help our userbase
with their PulseAudio issues.

-- Forwarded message --
From: Chris Robinson 
Date: Jan 17, 2010 10:25 PM
Subject: [Openal-devel] OpenAL Soft 1.11.753 released!
To: ope...@opensource.creative.com
Cc: openal-de...@opensource.creative.com


New version is up and ready:

 http://kcat.strangesoft.net/openal.html

 This release fixes compatibility with PulseAudio 0.9.21, and makes PulseAudio
 the default backend (if PA is not available, it will still fall back to ALSA,
 OSS, etc). The PulseAudio backend will also attempt to match an output format
 and frequency as reported by the default sink, if an override was not set in
 the config file (so if Pulse is configured for 5.1 output, OpenAL Soft will
 automatically pick that up and render 5.1; no extra configuration needed).

 The crash with the echo effect is fixed, and reverb has been improved. It now
 supports the Modulation and Echo properties. Multi-channel sources are also
 passed through the auxiliary sends, as a mono mix, so they will work with
 auxiliary slot effects.

 There is also a new head-dampening config option, which slightly filters
 sources emanating behind the listener, for mono and stereo output. It also
 supports the AL_EXT_source_distance_model extension, as described here
 .
 Additionally, there is a new config option to select between 3 resamplers:
 nearest (no interpolation), linear (default), and cosine.


 The next version will hopefully see more of the experimental extensions
 completed, better resamplers (such as cubic), and more. I'll also try to get
 out more frequent releases if major issues turn up.


 Thanks for looking! Please feel free to try it out, and let me know how it
 works for you. :)

 - Chris
 ___
 Openal-devel mailing list
 openal-de...@opensource.creative.com
 http://opensource.creative.com/mailman/listinfo/openal-devel

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [warzone2100-dev] Planning to commit unicode, raytrace, retarget -> 2.3, and pointtree -> trunk

[buginator]

On 1/16/10, C yp  wrote:
> Hi, I was told big commits should go on this mailing list before being
> committed. And apparently a quick rewrite of a few files is considered a big
> commit.

Sounds good, but just a slight note, since we are still using svn for
our VCS, all patches should be in svn-diff style, and not git-diff
style.

Luckily, devurandom made a script for you git people to autoconvert them.
You can find it here:  http://developer.wz2100.net/wiki/GitTricks

Also, welcome aboard!
Looking forward to seeing more patches / bug fixes / random comments
from you. :)

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [warzone2100-dev] Splitting out original campaign

[buginator]

On 1/4/10, Kreuvf  wrote:
> Per Inge Mathisen wrote:
>  > So here is my suggestion: We pick one branch as the final campaign
>  > release tree, and at some point branch it to become an "original
>  > campaign only" branch, removing anything other than campaign from it
>  > (ie no skirmish, multiplayer, etc). Starting the executable built from
>  > this branch just brings up the tutorials, load game, options and
>  > campaign. Whenever we build releases from newer branches, we also
>  > build an original campaign executable from this branch to include.
>  > Then we drop all code and scripts specific to the original campaign
>  > from newer branches and trunk. Instead we focus on rebuilding campaign
>  > support code on top of the new savegame format and lua branch when
>  > those are done, so that new campaigns can be written.
>
> Please tell me if I understand this correctly (don't mind the version 
> numbers!):
>  - Pick one branch as final campaign release tree --> for instance 2.3
>  ==> 2.3 = campaign branch
>
>  - Time goes by.
>
>  - Remove anything not necessary for the campaign.
>  ==> campaign only branch (cob)
>
>  - Remove campaign stuff from 2.4 and trunk.
>
>  - Rebuilding campaign support code on top of new savegame format and lua 
> branch,
>  when those are done
>
>  - Release of 2.4
>  ==> executable of 2.4 + executable of cob
>
>  - Release of 3.0
>  ==> lua branch and new savegame format done
>
>  - Release of 4.0
>  ==> rewritten campaign
>  ==>  Die, cob, die!
>  ==> RIP cob.
>
>  If this is the basic idea, I'm fine with it. But I suggest the following:
>  Thoroughly think through the many side-effects. Videos will have to be split 
> as
>  there is a general part (those vids shown on the intelligence screen), an
>  MP-only part and an SP-only part. Nonetheless, I am willing to help 
> where/when I
>  can. :)
>
>
I don't know where you got the idea of me saying die! xzy die! I would
never say that! ;)
[invisibleink]die! 2.2.x die![/invisibleink]

As hard as it is to believe, I would rather keep campaign going since
it really is the part that brought me to this project.
I understand that campaign is very easy to break, and we really lack
people that want to play campaign over & over again from square one,
but, if it works out, the answer to this will be a custom script that
we can use to test all aspects of campaign for us.

IIRC, lua is also not a silver bullet to all our script issues.  Yes,
it will be a nice improvement, but as long as we still use any of the
old code in the codebase, we will still have script issues.
I also think that the most of the hold-up for getting lua done has to
do with campaign scripts conversion.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [warzone2100-dev] A question of wikis

[buginator]

On 1/2/10, NoName  wrote:
> Am 02.01.2010 19:03, schrieb Dennis Schridde:
>
> > Hello!
>  >
>  > Am Samstag, 2. Januar 2010 18:07:36 schrieb Daniel Kliman:
> > Kamaze likes to maintain a server and provide us with hosting. (At least 
> > last
>  > time I talked to him.)
>  >
> I still do, but i'm always pretty short in time when people want
>  something for the website, because they always ask a few weeks before my
>  exams. Also, i'm absolutly unhappy with the current situation, which is
>  nothing more than a temporary solution. As soon as I got/made the right
>  software, and a nice theme, there will be a bigger overhaul.
>
>  We dropped our MediaWiki because some developers liked Trac's wiki and
>  started to put stuff there. As result, we had 2 wikis running, some
>  information was located in the Trac wiki and some in the MediaWiki. And
>  because Trac was essential, MediaWiki lost the game.
>

Trac's style (formatting) is very unfriendly to new people.
Anyone know of a option that we can change to fix this?

Main issue is, people paste whatever into the edit box, and it comes
out looking like crap since they didn't use the {{{ }}} codetags.

The other problem with our trac is, we have no fallback.  If the
website/forum goes down for whatever reason, then we lose access to
trac which isn't fun for anyone.
I know that Sourceforge's trac and ours wouldn't mix, so we can't have
a mirror there.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[8906] branches/2.3

[buginator]

On 1/1/10, Per Inge Mathisen  wrote:
> On Fri, Jan 1, 2010 at 5:14 PM, Dennis Schridde  wrote:
>  > Am Freitag, 1. Januar 2010 17:01:58 schrieb ...@users.sourceforge.net:
>  >> Revision: 8906
>  >> Property Changed:
>  >> 
>  >> branches/2.3/
>  >> branches/2.3/data/mods/multiplay/original/
>  >> branches/2.3/src/frontend.c
>  > You are changing unrelated files randomly as it seems.
>
>
> That is a "feature" of the merge operation in recent versions of
>  subversion. Which, combined with its ever more glacial speed, is why I
>  rarely ever use svn merge anymore.
>

Yeah, it is a by-product of having ancestry.
It can be turned off via the --ignore-ancestry switch.

I will post a new mail about switching to a different VCS and
hopefully we can come up with a better alternative.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [warzone2100-dev] Multi-turrets

[Guangcong Luo]

On Fri, Jan 29, 2010 at 7:36 AM, Per Inge Mathisen
 wrote:
> I highly doubt that forum users are in any way statistically
> representative of ordinary users, nor in my experience are they good
> representatives of the interests of ordinary users. We should be
> really wary of letting expert tweakers, the type of user that usually
> dominate such forums, determine where this project is going.

Sorry, I didn't hear any objections, and it seemed like we were making
most things into polls. What should we do about the one currently up?

Anyway, I'm sure ordinary users would enjoy multi-turrets, too, or at
least not mind them. As mentioned, in a choice between no multiturret
at all, and multiturrets that may look weird in certain turret
combinations, I'm guessing most would choose the former. As I
mentioned in the forum thread, anyone particularly bothered by how
certain combinations look can simply avoid using those combinations.

- Zarel

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[warzone2100-dev] [Warzone 2100 Trac] #1505: Fix multisync

[Warzone 2100 Trac]

#1505: Fix multisync
+---
 Reporter:  Per |  Owner:  
 Type:  bug | Status:  new 
 Priority:  major   |  Milestone:  2.3 
Component:  Engine: Networking  |Version:  svn/trunk   
 Keywords:  sync check network  |   Operating_system:  All/Non-Specific
Blockedby:  |   Blocking:  
+---
 Offscreen updates did not seem to work anymore. I traced this back to
 offscreen updates only setting pos.x and pos.y on a droid for most orders,
 and those are promptly overwritten next frame by sMove.fx and sMove.fy
 which are not updated. So I rewrote the code a bit to only use the
 floating point values. I also made it issue move command for onscreen
 changes when in guard order. Not sure why we do not do this for all
 orders, but at least guard should also be safe. DORDER_NONE is rarely used
 anymore.

-- 
Ticket URL: 
Warzone 2100 Trac 
The Warzone 2100 Project
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [warzone2100-dev] Multi-turrets

[DylanDog]

On Fri, 29 Jan 2010 14:36:05 +0100, Per Inge Mathisen
 wrote:
> 
> I highly doubt that forum users are in any way statistically
> representative of ordinary users, nor in my experience are they good
> representatives of the interests of ordinary users. We should be
> really wary of letting expert tweakers, the type of user that usually
> dominate such forums, determine where this project is going.
> 
> We should never outsource substantial disagreements to forum polls. I
> should perhaps have said something earlier, but I did not like this
> going to a poll.
> 
>   - Per
> 
I got the point. Also you have much more experience on this and you are
possibly right concerning the tweakers even if what you say is a bit sad. I
am not the kind of guys who does not change his views if they have
to...therefore ok, no polls.
My opinion about Multi-turrets is, from an AI perspective, that I do not
like them but if what Zarel wrote on this matter is true (people do want
Multi-Turrets) then we should re-introduce them.


-- 
-DD

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [warzone2100-dev] Multi-turrets

[Per Inge Mathisen]

On Fri, Jan 29, 2010 at 1:51 PM, wp1004671-obooma  wrote:
> Yes the forum poll would be the most democratic solution ;-)

I highly doubt that forum users are in any way statistically
representative of ordinary users, nor in my experience are they good
representatives of the interests of ordinary users. We should be
really wary of letting expert tweakers, the type of user that usually
dominate such forums, determine where this project is going.

We should never outsource substantial disagreements to forum polls. I
should perhaps have said something earlier, but I did not like this
going to a poll.

  - Per

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[warzone2100-dev] [Warzone 2100 Trac] #1504: Display crash in trunk with intel gfx

[Warzone 2100 Trac]

#1504: Display crash in trunk with intel gfx
-+--
Reporter:  Per   |Type:  bug 
  Status:  new   |Priority:  major   
   Milestone:  3.0   |   Component:  Engine: Graphics
 Version:  svn/trunk |Keywords:  intel gfx   
Operating_system:  All/Non-Specific  |   Blockedby:  
Blocking:|  
-+--
 Not reproducible. See backtrace.

-- 
Ticket URL: 
Warzone 2100 Trac 
The Warzone 2100 Project
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [warzone2100-dev] Multi-turrets

[wp1004671-obooma]

On Wed, 27 Jan 2010 14:49:11 -0600, Zarel  wrote:
> On Wed, Jan 27, 2010 at 9:26 AM, Per Inge Mathisen
>  wrote:
>> A while ago we disabled multi-turret because they had graphical
>> glitches that made them look horrible. Now they have been re-enabled
>> again, for only the stated reason that a lot of work was put into
>> fixing the multi-turret code. That is, however, not a valid reason for
>> adding anything, and nothing has been fixed in regards to the original
>> problem of multi-turrets looking horrible. After having tesed
>> multi-turret designs quite a bit, I am again proposing that we disable
>> multi-turrets before the 2.3 release. We should strive to make the
>> game look more polished and high quality, not less.
>>
>> Opinions?
> 
> Actually, the stated reason was that everyone wanted multi-turrets,
> and no one cared about how "bad" they looked. That I had just fixed
> the multi-turret code and balanced it so they were Dragon-only were
> just why I didn't want to re-enable them earlier.
> 
> We could have a forum poll, if you want. And maybe ask the Artwork
> forum for a better model.
> 
> -Zarel
> 
> ___
> Warzone-dev mailing list
> Warzone-dev@gna.org
> https://mail.gna.org/listinfo/warzone-dev

Yes the forum poll would be the most democratic solution ;-)

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [warzone2100-dev] Replacing Aivolution with DyDo-AI

[wp1004671-obooma]

On Thu, 28 Jan 2010 03:21:44 -0600, Zarel  wrote:
> On Wed, Jan 27, 2010 at 1:14 PM, wp1004671-obooma 
wrote:
>> ...help requried! please give me some advice on how to replace
AIvolution
>> with DyDo.
>> I took a look but I have no idea where to start from.
> 
> Go into data/mods/multiplay/
> 
> Delete the aivolution/ directory; add the dydo-ai/ directory. Edit
> Makefile.am and Makefile.win32 - look at how Aivolution does it, and
> just replace Aivolution with DyDo.
> 
> Is that enough detail? If not, I just can do it for you - just tell me
> which version of DyDo. :)
> 
> -Zarel

Thanks a lot Zarel,
I will give it a try next week, I have had very few free this week...also
I never have time on the week-end to dedicate to this which is just an
hobby for me.
I`ll let you know when done.
-DD


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev