Model of ship transfer mechanics that can be acceptable by most of the opposing groups of players and can be implemented using current game mechanics:
1. Definitely ship transfer must be implemented! (very awaited feature)
2. Base principle: Time/space are not compressed in any way. Balance and mechanics remain untouched (nearby). No new magic involved.
3. General case: Let the player be docked on the station (with access to transfer menu) in system A, and he wants to transfer one of his ships docked somewhere in system B to another station (S) in system C.
4. Restrictions to be applied:
No present game mechanics altered. If planned ahead the ship will be there upon players arrival - 0 delay and no *NEW* magic. Profit for all.
Consequences of implementation on current gameplay
Original idea is not certainly mine, same kind was discussed many times in different threads.
But this one can be implemented in short terms using only mechanics that we have already or those shown during gamescon.
With all my respect I insist on the fact that FD is simply trying to trick community, replacing the long time awaited - and promised - "Ship transfer" feature with magic ship recall/"summon" realization.
But I'll be very pleased to hear FD opinion and comments on-topic.
To moderators and commanders:
This is not a duplicate theme about good or not presented by FD "transfer" feature realisation, nor the theme for whining
This is kind of suggestion that could potentially end all those forum wars
I would like also to add to this thread a poll with two options:
Question to commanders: Is this schema is more acceptable then that presented by Frontier Development:
cmdr Dja
1. Definitely ship transfer must be implemented! (very awaited feature)
2. Base principle: Time/space are not compressed in any way. Balance and mechanics remain untouched (nearby). No new magic involved.
3. General case: Let the player be docked on the station (with access to transfer menu) in system A, and he wants to transfer one of his ships docked somewhere in system B to another station (S) in system C.
4. Restrictions to be applied:
4.1 Station S must be "visible" to player on system's B system map.
4.2. Distance between system A and system B, as also distance between B and C - each one must not exceed - say - 1000 ly (this restriction is a kind of may be temporary replacement of the preferable checkup if the transferred ship - mass/fsd into account - is at least theoretically capable to attain the target system C using real star-to-star plot route, as this can be hardly implemented using available game mechanics)
5. Time. Time must be comparable to the players travel time and takes into account following factors:4.2. Distance between system A and system B, as also distance between B and C - each one must not exceed - say - 1000 ly (this restriction is a kind of may be temporary replacement of the preferable checkup if the transferred ship - mass/fsd into account - is at least theoretically capable to attain the target system C using real star-to-star plot route, as this can be hardly implemented using available game mechanics)
5.1 Fast and jumpy courier-like ship trip from A to B (yep, possible background - hire npc and give him your key/access codes)
5.2 transferred ship travel time from B to C
5.3 all time calculations based on the ships actual mass and fsd, no real route plotting involved
6. Payment. Also based on distances and ships involved, takes into account:5.2 transferred ship travel time from B to C
5.3 all time calculations based on the ships actual mass and fsd, no real route plotting involved
6.1 Payment for courier from A to B (if needed)
6.2.Payment for player ship transfer: time/distance, ship class/value, may be ship firepower (as reducing factor), insurance?.
6.3 If ship doesn't have fuelscoop module installed than additional convoy/refuel npc-ship supposed to be hired - with appropriate payment. (So they'll travel in a wing)
6.4.Total price must be however reasonable, not another kind of provocation for grind mechanics
7. Realization.6.2.Payment for player ship transfer: time/distance, ship class/value, may be ship firepower (as reducing factor), insurance?.
6.3 If ship doesn't have fuelscoop module installed than additional convoy/refuel npc-ship supposed to be hired - with appropriate payment. (So they'll travel in a wing)
6.4.Total price must be however reasonable, not another kind of provocation for grind mechanics
7.1 All calculations is based solely on involved ships current masses and fsd parameters. No route plotting
7.2 No animations. I mean - not at all. At the current stage of game development it is impossible and can be only be the source of many exploits. Ship is grayed-out from the ship storage menu for all period of transfer - with some countdown timer).
7.3 Additional "icon"/function type on system map for "target" station. Handy, but currently player ships travel destination icon can be used.
8. Gameplay. As I see the process: Player opens galactic map, finds system C, opens system map for this given system and marks station S as "target" - exits map to transfer ship menu (at that moment all times and prices for all stored ships are calculated, restrictions checked) - player selects ship he want to transfer - pay the necessary amount - and - volila - problem solved. After given time the ship will become accessible at the target station.7.2 No animations. I mean - not at all. At the current stage of game development it is impossible and can be only be the source of many exploits. Ship is grayed-out from the ship storage menu for all period of transfer - with some countdown timer).
7.3 Additional "icon"/function type on system map for "target" station. Handy, but currently player ships travel destination icon can be used.
No present game mechanics altered. If planned ahead the ship will be there upon players arrival - 0 delay and no *NEW* magic. Profit for all.
Consequences of implementation on current gameplay
(+) LORE in not affected, no *new* magic
(+) Game Universe scale (objective or subjective) is not affected, no anomalous zones created
(+) minimize the number of "loadscreens" (jumps) necessary for commander to transfer one of his ships from one system to another
(+) Yes, the content will be available for a larger group of players.
(+) More social interaction (CG's are more accessible for different playstyles)
(+) This schema requires "planning" skill - a good point for the game
(+) in case of good planning the waiting delay will be equal to 0.
(+) that kind of implementation produces many opportunities for future developpemnt of the game thus promise more playability, and at the same time doesn't imply new restrictions.
(-) there is some work to do for FDevs to implement this schema (minimal, yes, but however)
(-?) all related to "ship transfer" as an option, disregarding instantaneous or not
(-?) as part of the above - all wealthy enough commanders will tend to use only fastest ship for their own travel trips.
_______________________________________________________________________________________(+) Game Universe scale (objective or subjective) is not affected, no anomalous zones created
(+) minimize the number of "loadscreens" (jumps) necessary for commander to transfer one of his ships from one system to another
(+) Yes, the content will be available for a larger group of players.
(+) More social interaction (CG's are more accessible for different playstyles)
(+) This schema requires "planning" skill - a good point for the game
(+) in case of good planning the waiting delay will be equal to 0.
(+) that kind of implementation produces many opportunities for future developpemnt of the game thus promise more playability, and at the same time doesn't imply new restrictions.
(-) there is some work to do for FDevs to implement this schema (minimal, yes, but however)
(-?) all related to "ship transfer" as an option, disregarding instantaneous or not
(-?) as part of the above - all wealthy enough commanders will tend to use only fastest ship for their own travel trips.
Original idea is not certainly mine, same kind was discussed many times in different threads.
But this one can be implemented in short terms using only mechanics that we have already or those shown during gamescon.
With all my respect I insist on the fact that FD is simply trying to trick community, replacing the long time awaited - and promised - "Ship transfer" feature with magic ship recall/"summon" realization.
But I'll be very pleased to hear FD opinion and comments on-topic.
To moderators and commanders:
This is not a duplicate theme about good or not presented by FD "transfer" feature realisation, nor the theme for whining
This is kind of suggestion that could potentially end all those forum wars
I would like also to add to this thread a poll with two options:
Question to commanders: Is this schema is more acceptable then that presented by Frontier Development:
- Yes
- No
cmdr Dja
