Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2003:
[Freeciv-Dev] Re: (PR#3489) Patch to add new generator
Home

[Freeciv-Dev] Re: (PR#3489) Patch to add new generator

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jjc@xxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#3489) Patch to add new generator
From: "rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>
Date: Wed, 17 Sep 2003 09:31:19 -0700
Reply-to: rt@xxxxxxxxxxxxxx

I suspect at some point this, or a common "energy" pool concept from which
movement and attack subtract appropriate amounts, will be required.

But it sounds like the real problem here is the generator concept has some
fundamental problems it needs to resolve, or it needs to be shelved until
the base code supports some features that aren't yet needed elsewhere.

This is often the case with specialized generators. It is also a good
reason to stop all work on the core server gennerators and build a better
way to integrate scenarios, or on-the-fly user generators into the startup
process rather than waste effort fighting over changing a common shared
resource with lots of past and present status quo pre-conditions.

Cheers,
RossW
=====

John Wheeler wrote:
> [per - Sat Sep 13 00:36:04 2003]:
> 
> 
>>On Fri, 12 Sep 2003, jjc@xxxxxxxxxxxxxxxxxx wrote:
>>
>>>The problem is that land movement withoutroads is really really
>>
>>slow.
>>
>>Perhaps supply new ruleset where units have more movement points?
>>
>>Or, each map could have a movement point multiplier, which we for
>>starters can apply to move rate, but later perhaps can replace
>>SINGLE_MOVE with.
> 
> 
> As far as I can tell, there is no way to increase the movement rate for
>  units in units.ruleset without also increasing the total number of
> attacks.  I seriously doubt you would want to do the latter.  If you
> really wanted a units ruleset solution, I would suggest putting a factor
> in the [units_adjust].  (Adjusting terrain.ruleset could work, too, but
> would mean allowing fractional movement_cost.)
> 
> OTOH, I think a movement rate multiplier would work especially well for
> scenario maps.




[Prev in Thread] Current Thread [Next in Thread]