Fuel Enhancements

[Hepps]

@general_zod Ok. And that is fine... but you provided an example under the pretext that it was a "loophole" that would need to be fixed in order for my idea to work with current functionality.

When really what you were doing was making an entirely different feature idea.

I'm not against your idea... I'm just saying your example does not identify any "loophole" in my suggestion.

[General_Zod]

@hepps haha, Point taken. You have a fine loophole free idea.

[Hepps]

Thinking of this with an even broader long term scope in mind...

The attachment might want to be expanded out to provide more options as well as be defined in better terms....

<attachment name="unitAttachment" attachTo="italianCarrier" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
<option name="negatesConsumption" value="fuel:navalfighter:2"/>

Where the attachment name is called "negatesConsumption"...

and the value is defined as.... "Type of consumable: Unit that would normally consume the specified consumable: number of specified Unit which no longer consume"

Depending on how workable this idea is I think it would work for all the different types of transport units while also allowing you to potentially have different types of consumable resources. (If you wanted)

[Frostion]

@Hepps Thats seems like a good idea. I could imagine other resources in use in some maps when ships carry units, like food supplies and salary.

[redrum]

So I didn't read all of the posts in this thread but seems that most of the remaining debate is around carriers/fighters and how to handle fuel consumption. And it is correct that generally fighters aren't considered 'cargo' and launch from carriers at the start of their turn.

My thought is to treat it kind of like land transports. If you select carrier and fighters in the same SZ and move together then they are considered cargo so don't burn fuel. If you move them in separate moves then they are not considered cargo. I think this makes sense from a gameplay perspective and minimizes changes to the existing carrier/fighter system.

Thoughts?

[Hepps]

@redrum Did you read my suggestion?

[redrum]

@hepps I didn't. Was it along the same lines?

[Hepps]

@redrum 1all you have to do is look up!

[redrum]

@hepps I see. A more generic version for any unit pairing. Guess the question is can we imagine any scenarios outside of transports and carriers that could impact fuel consumption?

[wc_sumpton]

@redrum Trains?

[Hepps]

@redrum Yah I can think of a few different scenarios outside of just movement.

Food
Supplies
energy

I suppose there are quite a few different scenarios where this type of attachment could also benefit from a action qualifier.

[General_Zod]

@redrum

If your gonna pair the air and carriers up like mech inf. I suggest only allow the pairing during the NCM. I think it should not be allowed to pair up during the CM. So it prevents the air from getting a free ride into combat.

[General_Zod]

Also what happens if lets say, the air uses all its movement to get to the combat. And an acc is 1 territory away from that combat. Can the acc move 1 space during NCM to pick up the air and then move its remaining movements with the air as cargo during NCM?

I would ask the same question if only in respect to fuel as well.

[Hepps]

@general_zod That is function of movement... not fuel.

[General_Zod]

@hepps Its linked imo. So the air isn't really cargo. Its just a patch for fuel is what your saying. Sounds confusing already.

[Frostion]

@general_zod
Yes. If fighters do not deplete some of their movement during a ride with a carrier, it will surely mess with a lot of maps. I don't think any current maps would want to have aircraft combat or noncombat moving their aircraft as "carrier's movement" + "own movement". A carried aircraft should deplete movement. It could logically symbolize that time is spent. And for this reason, carried offensive aircraft should normally have higher movement stats than the carriers.

I do think however that they should not spend fuel while moving and / or fighting in the same territory as their carrier, as the fighters fuel consumption could be characterized as limited compared to an offensive use of aircraft. So in that sense they should freeride if with a carrier.

I think this would make sense both in a World War map setting as well as a SCI FI setting, like if a space mothership flew through space, ended up at a planet and then launched its fighters down into the atmosphere of the planet as a part of a planet invasion. The fighters were carried fuel free, but when they move out and away from the capital ship as a part of an offensive operation, then the start consuming fuel. Same as a WW invasion fleet with fighters.

[vicvictory]

@frostion I fully agree. Same should be in use for transports by train.

[Cernel]

It's amusing that after the years people think that fuel cost charged on loading only must have been the result of some actual reasoning behind it.
Actually, it was not.
It was made it that way only because Veqryn found that was the easiest way to code it (it worked on unloading, before then, or rather I should say it was supposed to, but there were bugs related to unloading from hostile sea zones).
The only other alternative was fuel being removed as a whole.
Veqryn would have preferred fuel costs being charged both upon loading and upon unloading. I was and am surely strongly against that, and would have preferred it charged on unloading only, but charged on loading only is acceptable too, as long as it is not both. Ultimately, what was made was just what was the easiest.

Fuel is a very important element of TripleA for future development of maps, that has been discussed a bit, but with little ever coming out of it. I'll review this topic and try to make a complete evaluation of the matter.

[Hepps]

@general_zod I think the idea of changing the functions & abilities of the ACC & fighters really has to be considered as a completely independent feature request.

As @Frostion mentions... the idea of fundamentally changing the behavior has huge impacts on pretty much every single existing map. If I had to guess... it would really need to be added as a new Global property in order to allow us to maintain the existing repository while also making it available to map makers.

[General_Zod]

@hepps True they are separate features, but they also overlap and should be evaluated together to avoid future roadblocks. The road blocks we seem to have now because backward compatibility is a priority. And we want to keep what in many respects is inferior functionality (because it was likely the easy method then).

@cernel I wasn't there but it seems that the decisions to take the easiest methods then. Is gonna impact TripleA for a very long time. In form of stifling potential progress, into the more ideal directions.

That being said, I respect those decisions too. Its a lot of hard work and we are volunteers. But maybe, we can find a new way, and not settle.

Or maybe, I'm just being too idealistic.