Fuel Enhancements
-
@General_Zod I can see how the "move existing fighters to a newly build carrier" can seem like a rule breaker or exploit, giving a free move in the placement phase. (Question: does this move actually require that the fighters have unspent movement points left in the same round? I have not tested this out.) Anyway, the rule is an optional XML set rule and it can really help some maps out, like if a map has a problem with newly build fleets being vulnerable to attack. I had to activate this rule in the Star Wars maps because it improved gameplay allowing new fleets to immediately pick up fighters from the planetside, making new fleets less vulnerable.
@All
Am I right to assume that it would seem acceptable to most to have all carried air units not use fuel while carried/move along with their carrier vehicle, not even if the carrier moves into an attack on sea zone and the fighters end up fighting? (in line with the "fighting in own territory uses no fuel" concept) But that this also (maybe because of in-univers time spend) uses up like 2 of like 4 fighter movement points. Also meaning that when a fleet moves 2 and attacks land and launch the fighters inland, that this would then require 2 fuel per fighter?Edit: If the fighter has a range of 2 and the carrier a range of 3, I guess that the fighter can then just be carried 3, still be launched fuel free if number 3 carrier move is an attack on sea zone, but be able to join a land attack?
Edit 2: Maybe the above concept should be totally different, as it would set up strange situations if a carrier has many moves, carrying fighters with less movement, and then when it comes to an attack on land the fighters may not join in. Pretty strange taking in mind that the fighters have been sitting in a fighter bay and waiting for the land attack for a long time?

@redrum
It seems like there is already a good deal of consensus regarding some of the fuel rules. I know that the more far away a new fuel ruleset is from the existing, the more difficult it might be to program. But since the current rules are nearly not used, it would maybe be good to lay out our community wishlist or vision regarding the a fuel ruleset that would make sense and actually be used. I know that I would implement them
-
Currently terrain can stop movement by disallowing entrance, but that's it. A specific unit type can be manipulated by technology and triggers but it affects all the units of that type, on map. I'm proposing more functionality, flexibility and ease of coding in my suggestion, since it would be essentially controlled by any territory on map. (Or via terrain modifier expansion.)
Also, I don't think there's any existing "fuelCost" options other than the one used as an unitAttachment.
The game property "
Moveexisting fighters to new carriers", I'm referring to allows an actual extra movement.Example, an existing fighter can fly 4 spaces during NCM to get to a land territory that is also a coastal factory territory (adjacent sea zone would make 5 spaces). During the placement phase, if an acc is placed, the same fighter can be
movedover to the sea zone containing the acc. Thus effectively exploiting 1 extra move for a total of 5 movement.There are other game properties that allow you to land existing or new fighters on existing or new acc without the movement exploit. "Produce fighters on carriers", "Produce new fighters on old carriers", "Land existing fighters on new carriers" and "LHTR Carrier production rules".
Btw, I think this was an allowed loophole because the v2 and v3 rules transition, changed during what phase, the existing air unit had to be in the intended sea zone, from "place phase" to "NCM phase".
-
@general_zod While I agree the original rule makes no sense. It really doesn't matter to our discussion since it would only matter if you included it into your game (with fuel) in the first place.
-
@Hepps Excluding it from the equation of fuel cost would be ideal if possible, but it was brought up. So I just tried to clarify what it really does.
-
In the current configuration. It doesn't appear that the air units are ever truly carried. It looks like a hack, which just allows the air to land at end of NCM. So if this configuration isn't changed, then the air units need to use fuel get to the landing site (acc) during NCM. And they need to use fuel to get anywhere during CM.
If this is changed to where the air units are true cargo, then they should be able to get a fuel free ride on acc during NCM at the very least. I'm not sure if it makes good sense to ever allow a fuel free ride during CM.
I agree we should nail down as many parameter as possible, to assist the developer who is actually willing to code what is required, into engine. Hopefully @redrum is willing.
-
@general_zod That was why I suggested the ACC have a property attachment that allows it to give fuel back when accompanied by the fighters.
It would achieve the same result without having to completely rewrite the ACC behavior.
-
@Hepps
I think I see what your getting at, but this would leave loopholes. Or the engine code would need to plug all loopholes.Maybe you can you elaborate how it works.
-
@general_zod I don't know what loopholes you are referring to.
You Could attach this exactly the same way you do the other unit attachments.
<attachment name="unitAttachment" attachTo="italianCarrier" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="negatesfuel" value="navalfighter:2"/>With something like this you could then eliminate the fuel consumption for the specified unit(s) and specify the quantity of the unit(s) while they move together. Pretty much in the same manner as the Mech blitzing with a Tank.
-
I like it, but I see one loophole (for lack of better term) which needs plugging.
What happens if the air unit has used its max movement to get to the acc during the beginning of NCM phase? How does the air unit move together with the acc during the NCM, if it has no more available movement?
It seems to require, more functionality.
-
@general_zod Well the ACC would not be able to move since the fighter has already moved its max movement.
No different then it currently is. You cannot currently move a fighter with all it's moves then proceed to move the ACC X number of more moves.
what I am suggesting would not change any part of the current functionality. If your Air moves with a ACC during combat or noncombat this would simply negate the fuel consumption... while still keeping the fighter consuming its own movement during the moves. Exactly the same as the game currently works.
-
So why not add another attribute in addition. That gives the air unit a free ride, even after it used all it movement. As long as it moves with the acc. Like the current mech infantry does.
<attachment name="unitAttachment" attachTo="italianCarrier" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="addsMovement" value="navalfighter:2"/> -
@general_zod Well now we are talking about something entirely different.

what you are suggesting would completely change the mechanics and abilities of Carriers and Fighters. Effectively adding more range to the fighters.
-
No, not giving it more operational range, just a lift. But yes, I am proposing more than current ability, to act more like a true acc should. I am also only proposing for the NCM phase.
But there's likely a better method of achieving the same result. I'm just throwing out a quickie,

-
@general_zod Correct, and while that may be a desirable request. I don't think it has any bearing on my suggestion for a way to add functionality to ACC and fighters as it pertains to the fuel question.
-
I thought we were spitballing ideas on how to reasonably bring a nice fuel consumption model to fruition. Whatever that entails.
Logical acc seems important. Unless we just aiming for the fastest method to get to playable fuel consumption.
-
@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.
-
@hepps haha,
Point taken. You have a fine loophole free idea. 
-
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)
-
@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.
-
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?
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login