patchFreeciv - Patches: patch #4805, Transferring units between...

 
 
Show feedback again

patch #4805: Transferring units between transports on the same tile

Submitted by:  Jacob Nevins <jtn>
Submitted on:  Sat 14 Jun 2014 11:38:08 AM UTC  
 
Category: NonePriority: 5 - Normal
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Planned Release: 

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 15 Jun 2014 09:33:52 AM UTC, comment #5:

>Obviously realism cannot be used as the guideline here, as none of these things is realistic. So it becomes mainly gameplay and balance issue - we should disallow major exploits.

I do not say that it is less realistic this use of transports, but I think it will harm the playability, because players who want to take full advantage of this feature are forced to perform a lot of micromanagement.

In civ3 it was possible to transfer units between transports, and I found that the fastest way to move my troops from one continent to another was, for example, to place my transports (6 movement points) 3 tiles away from each other, creating a line between my continent and the target continent.
This way, I was able to load 8 units in the first transport, move it 3 tiles to meet the next transport, transfer the units, and then move back the 3 tiles to repeat the same operation in next turn. Then move next transport, transfer units, and move back, etc.
At the end, you can move units from one continent to another in one single turn, but the task is so tedius that after several turns, I ended hating it.

I understand that some people may like this feature, I just ask some way to limit it, and the cost of one SINGLE_MOVE sounds good enough to me.

David Fernandez <bardo>
Sat 14 Jun 2014 08:20:36 PM UTC, comment #4:

When considering limitation of movement between collocated transports on the same non-native tile, remember that we permit movement between adjacent transports on non-native tiles with a cost of SINGLE_MOVE: rather than a blanket restriction, I suspect it makes more sense to charge SINGLE_MOVE movement: given the right unit, one can still move implausibly far with relay transports, but not any farther than one can today (actually, slightly less far, if one transfers on the same tile, rather than the next adjacent).

I don't think it makes sense to consider the case of being in a base/city for this: it should only depend on the unit nativity. In the special case of sea-only transports and land-only cargo, only tiles that have bases or cities will be native to both, but there's no reason to apply the same rules for e.g. Paratroopers moving between transport-capable Helicopters on Plains tiles.

In terms of narrative support, consider that two transports with embedded debarkation ramps may be able to align them to transfer a tank (assuming a common-plan transport also supporting a pontoon bridge role). In a more complex ruleset, consider a helicopter loading a scout vehicle from a transport: if the transport is intended to be a winch (according to ruleset dynamics), then it oughtn't matter that the scout vehicle isn't native to the tile.

Emmet Hikory <persia>
Project Member
Sat 14 Jun 2014 05:00:17 PM UTC, comment #3:

Going a bit OT, but this is the general spacetime distortion in our model. Units have movement points telling how much they can move a turn (lat's say; year). Yet units are not moving at the same time, but one at a time. When they interact, that interaction can clearly happen in the different point of the unit A's year than unit B's year. Let's say unit A moves all around (spends almost full year first) and then attacks B which has not moved at all, and B wins and remains alive. Unit B then moves, making it clear that the attack against it took place in the beginning of the year.
As such, it's not always clear what things are to be considered bugs and which are just features of our model. Obviously realism cannot be used as the guideline here, as none of these things is realistic. So it becomes mainly gameplay and balance issue - we should disallow major exploits.

Marko Lindqvist <cazfi>
Project Administrator
Sat 14 Jun 2014 04:46:18 PM UTC, comment #2:

That's a good point.

I think there are limited cases where it is possible to do what you describe today, where a unit can unload/reload on native terrain. For instance it's possible to transport a unit arbitrarily far along your own coastline by hopping from city to city, taking a fresh transport in each one. Land transports would have similar issues.

A default behaviour where units transferring between transports outside of a base/city lose movement points similar to moving between adjacent transports would be better than nothing, but I suspect it really needs fine ruleset control to fix this properly.

Jacob Nevins <jtn>
Project Administrator
Sat 14 Jun 2014 03:18:33 PM UTC, comment #1:

Something that I liked from freeciv compared to other civs is that it was not possible to use chains of transports in order to move units indefinitely in one single turn.

If you allow transferring units between transports on the same tile, I'm afraid it could be possible to load a unit in one transport, move it until it reaches another transport, transfer the unit without wasting movement points, and then continue moving in the new transport.
If you exploit it, for example, you can place 10 triremes 3 tiles away from each other, and use them to move one land unit 30 tiles in one single turn.

I'd suggest to make it possible to avoid this kind of unlimited movement, for example by reducing the movement points every time a unit is transfered from one transport to another.

David Fernandez <bardo>
Sat 14 Jun 2014 11:38:08 AM UTC, original submission:

Currently we have the situation that you can move transported units between ships on adjacent tiles (using the UNIT_MOVE packet), but not between ships on the same tile (with the UNIT_LOAD packet).

I think this can be fixed without network protocol changes -- change could_unit_load(). Possibly we'd want to unify some of the move and load logic, since unit_move() is currently in effect doubling up as a load/transfer packet. (It's probably worth thinking about patch #4804 while doing this.)

This lets transfers be done atomically; without it, you'd have to allow unloaded units in non-native terrain.

This will need some UI. I think this will be the same as needed for bug #13943 (selective load).

For narrative reasons it would obviously be ideal if ruleset authors could specify when transfers in non-native terrain were allowed (moving tanks between transports in open sea is implausible). But that's fiddly to specify and I'd like to keep that the subject of another ticket; for now it should at least respect embarks/disembarks.

Jacob Nevins <jtn>
Project Administrator

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Digest:
   patch dependencies.

 

Carbon-Copy List
  • -unavailable- added by persia (Posted a comment)
  • -unavailable- added by cazfi (Posted a comment)
  • -unavailable- added by bardo (Posted a comment)
  • -unavailable- added by jtn (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 14 Jun 2014 11:38:28 AM UTCjtnDependencies-=>patch #4804 is dependent
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup