Fuel Enhancements

[redrum]

So on to fuel flat costs... Here is an example of what I'm proposing for the new XML parameter (fuelFlatCost):

	<attachment name="unitAttachment" attachTo="fighter" javaClass="games.strategy.triplea.attatchments.UnitAttachment" type="unitType">
		<option name="movement" value="4"/>
		<option name="carrierCost" value="1"/>
		<option name="isAir" value="true"/>
		<option name="attack" value="3"/>
		<option name="defense" value="4"/>
                <option name="fuelcost" value="oil" count="1"/>
		<option name="fuelFlatCost" value="oil" count="2"/>
                <option name="fuelFlatCost" value="pilots" count="1"/>	
	</attachment>

This would mean a fighter pays 2 oil & 1 pilot if it moves at all plus 1 oil per each move. So if it moved a total of 3 then it would pay 5 oil and 1 pilot. The goal is to have both the existing per move fuel cost (fuelCost) and the new fuel flat cost (fuelFlatCost) work for all unit types and be able to be used in any combination.

[prastle]

@redrum are oil reserves being added for future maps

[prastle]

@redrum storage tanks that can be bombed?
smells a Heppster in this scenario

[redrum]

@prastle I sure hope so. Otherwise I'm adding features just for the fun of it

Actually I believe you could probably do some kind of bombing where when a structure is destroyed, you trigger loss of resources.

[prastle]

@redrum your both evil bastards

[Hepps]

@redrum Looks great! Adding all these features just for the fun of it. What a champ!

[prastle]

@hepps @redrum you both realize I EXPECT POS2 @ UPDATES and this will make GD a very rough map
sigh

[prastle]

@hepps its almost like you want all to ignore unless Tylenol scripts

[redrum]

@prastle Did you just volunteer to update POS2 XML?

[prastle]

@redrum NOPE! but with all your additions I really hope you did

[redrum]

Here is the PR adding the "fuelFlatCost" unit option: https://github.com/triplea-game/triplea/pull/3244

XML

    <attachment name="unitAttachment" attachTo="elite_cavalry" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
      <option name="consumesUnits" value="1:cavalry"/>
      <option name="movement" value="2"/>
      <option name="transportCost" value="3"/>
      <option name="canBlitz" value="true"/>
      <option name="requiresUnits" value="parade_ground"/>
      <option name="requiresUnits" value="general"/>
      <option name="createsResourcesList" value="-4:Supplies"/>
      <option name="fuelCost" value="Supplies" count="1"/>
      <option name="fuelFlatCost" value="Supplies" count="2"/>
      <option name="fuelFlatCost" value="Industry" count="1"/>
      <option name="canInvadeOnlyFrom" value="transport:train"/>
      <option name="createsResourcesList" value="-1:Manpower"/>
      <option name="attack" value="4"/>
      <option name="defense" value="3"/>
    </attachment>

Before

After

ron-murhammer created this issue in triplea-game/triplea

closed Add New Unit Option "fuelFlatCost" #3244

[prastle]

@redrum and you questioned why I said you were brilliant?

[Frostion]

Nice update. I still hope that you would reconsider removing the ( and the ) signs. They just make the movement bar unnecessarily long, and not having them would be more consistent with how icons and numbers are displayed elsewhere.

I think that I will have to start work on Iron War and Iron War Europe movement fuel versions. Hopefully balanced versions of these can be ready alongside a new engine release Jubii! And they can make use of the hide resources from players feature!

[redrum]

@frostion Yeah, I think you already saw but I updated the route message in the other forum thread already

And yeah, I definitely think Iron War can benefit from a lot of the recently added features. And could be the first map to ever implement fuel in a balanced and user friendly way!

[redrum]

Thoughts on how carriers and fighters fuel costs should work? I think I see 2 options:

1. Simple - If carriers and fighters are moved together during combat or non-combat move then only the carrier is charged fuel. This would include moving into combat and so a fighter moved with a carrier into combat wouldn't be charged fuelCost or fuelFlatCost.
2. Noncombat Only - If carriers and fighters are moved together during non-combat move then only the carrier is charged fuel. Any moves during combat move are considered that the fighter has taken off from the initial carrier position so is always charged fuel during all combat moves.

There are other more complex variations of these that meet somewhere in the middle but I'm pretty hesitant to go there. Open to suggestions and ideas but want to pick something we feel works well across all maps and is fun/intuitive to use.

[Frostion]

1. Simple has my vote. It seems logical and during game it would make sense if fuel was consumed on these terms. People would also see the carrier actually carrying fighters, not just acting as a landing strip at sea.

[General_Zod]

@redrum

Choice 2 seems better to me. Choice 1 would only be logical if your making air units true cargo on the acc. But then you need handle issue where air units are being carried 2 sea zones while cargo during CM or NCM. Then the air units fly their full normal movement during CM or NC, in addition to the moves as cargo. Or maybe you have a solution already.

[wc_sumpton]

@redrum I tend to agree with @General_Zod here. Choice 2.
If you have a loaded transport, you only need to click on the transport to move it an its cargo. Moving the ac and fighter requires that both items are clicked on to move. I can see the point of not charging for a NCM where both ac and fighter start and end in the same territory. But any move during CM, which implies that both are going into battle, should charge both their movement resources.

[Hepps]

Deuce has my vote as well.

[redrum]

Well, given that I'd vote for option 2 as well, I'm going to move forward with that. In the future, if we get lots of maps that implement fuel adding different options around consumption should be fairly easy. Now the fun part, implementing it and making sure it works properly with both fuelCost and flatFuelCost.