Matrix Games Forums

Jeww wrote: Wed Jul 20, 2022 10:42 pm

Rob322 wrote: Tue Jul 19, 2022 3:50 am

Jeww wrote: Mon Jul 18, 2022 11:58 pm

Ok, well, if you look at the schedule for SFO there are only 100 flights scheduled the entire day.

Ummm, no, there are better and easier ways to figure this out than googling it. Flightaware shows the airport data for SFO shows they're currently averaging 1000 departures and arrivals daily. That's still down from pre-pandemic volumes but it is climbing.

https://flightaware.com/live/airport/KS ... -container

That proves my math. You proved aircraft have a 100 hour life and didn't read your own source which proved my math.

In order to reply you have to do math which you obviously can't.

Gizzmoe wrote: Wed Jul 20, 2022 11:49 pm You are either one of the most deliberate trolls I've every met in my 30+ years of online experience, in which case you are to blame 100% for your trolling, or you have (that's not mutually exclusive), like I said before, a mental condition, which would be nothing to be ashamed of, I had my share of mental issues in my 50+ years. But please try to keep that out of this forum as much as possible, it makes you look very ridiculous.

alphali wrote: Thu Jul 21, 2022 6:00 pm The fact that he is changing accounts tells me it's most likely the first one.

thewood1 wrote: Thu Jul 21, 2022 6:29 pm Yeah, but its actually a combination of both. Smart trolls can easily pass themselves off as normal for a while. This is not an example of that.

Zanthra wrote: Fri Jul 22, 2022 2:59 am What about a simple RTB - Exhaution Doctrine, which similar to Bingo or Winchester, will order a normal RTB when the aircraft reaches 50 to 90 percent of it's fatigue (user selectable in Doctrine). This way the Miucromanagement is eliminated while still maintaining controllability of the aircraft on the way back to base. If the aircraft does reach it's fatigue limit, it turns into a forced RTB as it is now.

The doctrine limit is the "rule" so to speak, and aircraft will automatically follow that. You can break that rule within limits, but reduces your safety margins before the aircraft is forced to RTB.

Zanthra wrote: Fri Jul 22, 2022 2:59 am What about a simple RTB - Exhaution Doctrine, which similar to Bingo or Winchester, will order a normal RTB when the aircraft reaches 50 to 90 percent of it's fatigue (user selectable in Doctrine). This way the Miucromanagement is eliminated while still maintaining controllability of the aircraft on the way back to base. If the aircraft does reach it's fatigue limit, it turns into a forced RTB as it is now.

The doctrine limit is the "rule" so to speak, and aircraft will automatically follow that. You can break that rule within limits, but reduces your safety margins before the aircraft is forced to RTB.

UncertainlyCertain wrote: Fri Jul 22, 2022 10:18 am

Zanthra wrote: Fri Jul 22, 2022 2:59 am What about a simple RTB - Exhaution Doctrine, which similar to Bingo or Winchester, will order a normal RTB when the aircraft reaches 50 to 90 percent of it's fatigue (user selectable in Doctrine). This way the Miucromanagement is eliminated while still maintaining controllability of the aircraft on the way back to base. If the aircraft does reach it's fatigue limit, it turns into a forced RTB as it is now.

The doctrine limit is the "rule" so to speak, and aircraft will automatically follow that. You can break that rule within limits, but reduces your safety margins before the aircraft is forced to RTB.

If I understand correctly, you propose a system in which the player is first issued a warning (akin to a JOKER fuel state) and the unit sets course back to base, then, once the limit is reached, the same RTB Exhaustion logic as is now kicks in and forcibly sends the unit back.
This somewhat goes around the problem yet doesn't really solve it : I still have no control over a "hard locked" RTB order.

The main problem with a forced RTB is that it can lead to a frustrating moment when I need a unit, I have said unit close but suddenly it simply turns around and flies back.
Some may say that this is a planning problem, one should always plan ahead so as to avoid such situations. But as practice, both IRL and in game, has shown even a well thought plan is not fool-proof and the occurrence of such situations may not be entirely avoided but rather just significantly reduced.

Hence the need for tactical flexibility: I thought I could do it but suddenly X happened (and left me dumbfounded) and I need resources/strategies to counter it. But if I'm precluded from using certain resources/strategies (e.g. "hard locked" plane just flies away) I have less possibilities to recover.

UncertainlyCertain wrote: Fri Jul 22, 2022 10:18 am

Zanthra wrote: Fri Jul 22, 2022 2:59 am What about a simple RTB - Exhaution Doctrine, which similar to Bingo or Winchester, will order a normal RTB when the aircraft reaches 50 to 90 percent of it's fatigue (user selectable in Doctrine). This way the Miucromanagement is eliminated while still maintaining controllability of the aircraft on the way back to base. If the aircraft does reach it's fatigue limit, it turns into a forced RTB as it is now.

The doctrine limit is the "rule" so to speak, and aircraft will automatically follow that. You can break that rule within limits, but reduces your safety margins before the aircraft is forced to RTB.

If I understand correctly, you propose a system in which the player is first issued a warning (akin to a JOKER fuel state) and the unit sets course back to base, then, once the limit is reached, the same RTB Exhaustion logic as is now kicks in and forcibly sends the unit back.
This somewhat goes around the problem yet doesn't really solve it : I still have no control over a "hard locked" RTB order.

The main problem with a forced RTB is that it can lead to a frustrating moment when I need a unit, I have said unit close but suddenly it simply turns around and flies back.
Some may say that this is a planning problem, one should always plan ahead so as to avoid such situations. But as practice, both IRL and in game, has shown even a well thought plan is not fool-proof and the occurrence of such situations may not be entirely avoided but rather just significantly reduced.

Hence the need for tactical flexibility: I thought I could do it but suddenly X happened (and left me dumbfounded) and I need resources/strategies to counter it. But if I'm precluded from using certain resources/strategies (e.g. "hard locked" plane just flies away) I have less possibilities to recover.

thewood1 wrote: Fri Jul 22, 2022 10:36 am

UncertainlyCertain wrote: Fri Jul 22, 2022 10:18 am Hence the need for tactical flexibility: I thought I could do it but suddenly X happened (and left me dumbfounded) and I need resources/strategies to counter it. But if I'm precluded from using certain resources/strategies (e.g. "hard locked" plane just flies away) I have less possibilities to recover.

And thats why putting it on doctrine is good solution. If you don't want it, set the doctrine.

Thats probably the simplest and most workable solution. While I don't believe in too many settings, when I do, I like them in the doctrine so its easier to use for the AI.

In doctrine, its easier to use as a template and move it in and out.

Now the question is, should there be any penalties if we decide to switch off Exhaustion RTB?

KnightHawk75 wrote: Tue Jul 26, 2022 10:51 am

Now the question is, should there be any penalties if we decide to switch off Exhaustion RTB?

I don't think it needs hard-coded penalty, I'm thinking you basically saying use realism model in this regard, don't use realism model in this regard.

Gizzmoe wrote: Tue Jul 26, 2022 3:29 pm

KnightHawk75 wrote: Tue Jul 26, 2022 10:51 am

Now the question is, should there be any penalties if we decide to switch off Exhaustion RTB?

I don't think it needs hard-coded penalty, I'm thinking you basically saying use realism model in this regard, don't use realism model in this regard.

I also think that it doesn't need hard-coded penalties. What was the second part you wrote about, I don't get what you are trying to say

KnightHawk75 wrote: Thu Jul 28, 2022 5:51 am Such as once every 5m check airtime via unitwrapper field, vs exhaustion cap (presumably also available somewhere), if close to exhaustion time reset via lua airtime on the unit to 0 to keep the exhaustion system from kicking in.