[Freeciv-Dev] Re: (PR#6174) Loading transports

["Jason Short" <jshort@xxxxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=6174 >

>
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=6174 >
>
> On Mon, Feb 02, 2004 at 06:58:57AM -0800, Jason Short wrote:
>> >> but doing it in steps (rather than one monolithic patch) isn't as
>> >> easy.  But if this design is approved we can work on it and submit
>> >> patches that work toward the goal.
>> >
>> > We first should come to an agreement on the convenience rules and
>> > other problem which need attention.
>> >
>> > Let me start with the convenience rules:
>> >  - if more units want to board a container than the container can hold
>> >  the units are prioritized by their specialty. A missile carrier will
>> >  first serve missiles and so on. If this doesn't solve the conflict
>> >  the units are served on first-come-first-serve basis.
>>
>> This isn't a problem because only one unit will ever be loaded at a
>> time.

> [ transporter = moving container ]
>
> Wasn't there to idea to add a "wait for transporter and load into it"
> state. It would replace the sentry state in this regard. It if wasn't
> planned it should be added. So that you can queue units which will
> load into the next transporter. Next transporter is either a new
> transporter build in the city or a transporter which moves into the
> tile.
>
> In this case the problem above arises when a new transporter is build
> in the city.

Hmm, I suppose so.  But in this case I'd say it's the player's
responsibility to make sure things are as he wants.

>> >  - moving a unit into a tile which the unit normally can't go and if
>> >  there is a container the unit will automatically get loaded into this
>> >  container.
>>
>> Yes.  This should also apply if the position is dangerous if the unit
>> doesn't load: e.g., fighters/bombers over a carrier.
>
> I would rephrase this to "if the unit wants to be one the transporter
> more".

I don't understand this sentence.

> This avoids the clash with the term "dangerous" from path
> finding. While in may be similar these are two different concepts.>

Yes, you're right.


>> >    * unload on the spot (I also this is needed)
>>
>> Via the load command, once it's implemented.  In the interim (before the
>> load command is implemented) activating a sentried unit in a transporter
>> may do this.
>
> What changes are planned in the step current cvs to interim version?

I'm not sure.  However, assign_units_to_transporter must go _before_ the
load command can be implemented.  So either we do both operations (remove
AUTT and add load command) in one step or first we remove AUTT and then
add the load command.  In the former case we'll need some special handling
code so that we get similar behavior to what we have now (sentry => load;
unsentry => unload).

jason