NiiiceGrigory1 wrote:Su-27!
Transports nothing but very well flies!

Moderator: Graphics Moderators
NiiiceGrigory1 wrote:Su-27!
Transports nothing but very well flies!
OK, I had a brain freeze on the intro-date thing, but there's no callback to change aircraft size (that is, the Small/Large/Helicoper setting). I don't see that such a callback has any business being implemented either. Even if there were no technical problems, refitting a 747 into a VTOL or a small-airport-safe craft just seems counter-intuitive.George wrote:No, why do they have to?DaleStan wrote:They still have to have the same: introduction date and size (S/L/H).George wrote:Why not to use several planes on the one slot? You can select with refit.
That'll have to be done in the patch.459 wrote:For instance that the running cost of a plane should decrease A LOT when it's on airport or in holding pattern
I'm afraid I don't follow. Do you mean that for planespeed 2, planes should travel 1.6x faster than at planespeed 1, or that at planespeed 2, planes should have an advertised speed of 1.6x faster than planespeed 1?459 wrote:We'll have to get around this somehow. For the time being, I suggest following speed-dependent multipliers for speed settings. These offset the decrease of running cost if planespeed goes up but they don't really help with longer routes being clearly more profitable than short:
1: 1.0
2: 1.6
3: 1.8
4: 2.0
Apparently. Patchman should comment.DaleStan wrote:That'll have to be done in the patch.459 wrote: For instance that the running cost of a plane should decrease A LOT when it's on airport or in holding pattern
No. What I'm trying to explain is that with Planespeed 2 the running cost would be 1.6 times the running cost with Planespeed 1 and so on.DaleStan wrote:I'm afraid I don't follow. Do you mean that for planespeed 2, planes should travel 1.6x faster than at planespeed 1, or that at planespeed 2, planes should have an advertised speed of 1.6x faster than planespeed 1?459 wrote:We'll have to get around this somehow. For the time being, I suggest following speed-dependent multipliers for speed settings. These offset the decrease of running cost if planespeed goes up but they don't really help with longer routes being clearly more profitable than short:
1: 1.0
2: 1.6
3: 1.8
4: 2.0
I'm not sure it's realiably possible to detect whether a plane is in the holding loop or in regular flight. And even then, changing the running cost from a fixed value to a variable one would be complicated. I'm not really sure it's worth it.459 wrote:Apparently. Patchman should comment.DaleStan wrote:That'll have to be done in the patch.459 wrote:For instance that the running cost of a plane should decrease A LOT when it's on airport or in holding pattern
Well, then, just change those first 8 numbers in .renum/planeset.txt.459 wrote:No. What I'm trying to explain is that with Planespeed 2 the running cost would be 1.6 times the running cost with Planespeed 1 and so on.
Edited that text btw. Seems like I'm writing BS here and there at 1 AM
Code: Select all
10 8 9
10
0 1 1 1
AFAICT, it's not reliably detectable in GRF[0], but the patch may be able to find a spare bit somewhere to store such information.Patchman wrote:I'm not sure it's realiably possible to detect whether a plane is in the holding loop or in regular flight.
The problem with Trimotor and S-58 is the combination of too few seats and too slow speed (smallest capacity original TTD plane had 25 seats and was three times faster). Few seats make it uninteresting to operate since you need too many of them and the unit cost is still high. They are actually so slow that it hurts profit since it takes ages to fly one from airport to another not even mentioning the time they spend in holding pattern. I'd prefer to axe them in behalf of something useful like below:krtaylor wrote:I don't see why it's necessary to kill the Trimotor and S-58, just lower their operating costs somewhat, then do the rest as you plan.
Users browsing this forum: No registered users and 28 guests