Page 100 of 147
Posted: 14 Aug 2005 10:42
by Aegir
Grigory1 wrote:Su-27!
Transports nothing but very well flies!

Niiice

.
Posted: 14 Aug 2005 12:02
by krtaylor
Mobius, if you want to draw some real-life liveries that we don't have, that would be great. Otherwise, we're just waiting on coding.
Posted: 14 Aug 2005 15:32
by George
DaleStan wrote:George wrote:Why not to use several planes on the one slot? You can select with refit.
Not really. They still have to have the same: introduction date and size (S/L/H).
No, why do they have to?
Posted: 14 Aug 2005 16:51
by DaleStan
George wrote:DaleStan wrote:George wrote:Why not to use several planes on the one slot? You can select with refit.
They still have to have the same: introduction date and size (S/L/H).
No, why do they have to?
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.
Posted: 14 Aug 2005 18:54
by George
DaleStan wrote:George wrote:DaleStan wrote:They still have to have the same: introduction date and size (S/L/H).
No, why do they have to?
but there's no callback to change aircraft size
Yes, my mistake, it is impossible
Posted: 14 Aug 2005 19:15
by 459
DaleStan: If you want to play around with this, you might want to try merging DC-10 and MD-11 into the same slot. Basically, only sprite and operational characteristics differ. Both planes (sprite, coded values and operational characteristics) can be found from the 459 remix version.
Posted: 16 Aug 2005 21:02
by 459
I researched the dependencies between plane size, plane speed and running costs. I made a "short" route and a "long"
route that was 2x the lenght of the shorter route. Then I ran some planes on the route. The "short" route was Cardiff-Bristol and "long" route Cardiff-Bournemouth in TTD built-in "West Country 90201" map.
And now the things are getting oh-so-f***ing-complicate that we need to discuss how to go on. Somebody REALLY has to develop a way to make running costs dependant on distance travelled. For instance that the running cost of a plane should decrease A LOT when it's on airport or in holding pattern (flying around the congested airport waiting for landing) versus flying point-to-point.
Speed RunCost Revenue
Concorde Short
1 590 4100
2 450 4100
3 420 4100
4 420 4100
Concorde Long
1 670 8900
2 500 8900
3 450 8900
4 450 8900
757 Short
1 500 7200
2 350 7200
3 300 7200
4 280 7200
757 Long
1 600 15600
2 410 15600
3 350 15700
4 320 15800
Dash8 Short
1 220 1650
2 140 1650
3 120 1650
4 100 1650
Dash8 Long
1 290 3300
2 180 3600
3 140 3600
4 120 3600
Noticeable:
-Running cost consists heavily of time on airport and in holding pattern, especially with planespeed settings 2, 3 and 4.
-Revenue at full load doesn't really depend on planespeed since cargo value doesn't drop quickly enough, only the distance between stations matters. Only if you are flying a slow plane between two stations far away from each other there's a revenue drop.
-Operating costs are in such way dependent on speed that there's a given cost multiplier for each setting.
We'll have to get around this somehow. For the time being, I suggest following speed-dependent multipliers for running cost settings. These offset the decrease of running cost per trip 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
These multipliers are so low because some smaller and slower planes (Sikorsky S-58 and Trimotor) are already on the verge of being unprofitable under all circumstances. If there will be no solution for the main problem, IMO we'll have to axe those two planes since they become completely unusable (running costs >> profitmaking capability) if we want to make other planes running costs more sensible.
I want some good opinions from krtaylor, DaleStan and patch crew.
Posted: 16 Aug 2005 21:17
by krtaylor
I'm not totally sure I understand what the trouble is.
If some planes are unprofitable under all circumstances, then lower their operating costs. The helicopters don't work well in TTD, for many reasons, but you have to have them to service the oil rigs. If larger airports were made, and were more efficient, then the helicopters would work better. Notice, though, that IRL there are way way more planes than helicopters, for some of the same reasons helicopters don't work well in TTD: they are very expensive to operate per unit carried.
I think that maybe TTD designed the airports inefficiently, because otherwise there would be no reason to use passenger trains, and trains are the emphasis of TTD.
I am surprised that the revenue doesn't change with the speed noticeably. However, it still makes more sense for the running costs to be more, even if the revenue is the same, because a faster plane can make more trips in the same period of time - same revenue per trip, but more trips per time interval.
Posted: 16 Aug 2005 21:45
by 459
One problem is, that if we increased the running costs with slower speeds, the already-useless Ford Trimotor and Sikorsky S-58 (because of their puny size) would become something that just can't generate profit. Besides, much faster and higher-capacity DC-3 and S-61 aren't that far away from Trimotor and S-58. Still, even if we increased the running costs that way the jets would remain pretty much as murderously overprofitable as before.
The main problem is how airplane running costs get generated in the game. The trip itself between two stations doesn't take much time at all in TTD environment, majority of time is wasted in holding pattern or at the airport. Since TTD running cost is the same whether the plane was boarding or it was flying between airports the ramping up the running costs this way would just cause inconsistency as planes that fly to congested airports (circling the holding pattern, waiting for boarding gate) would become unprofitable. What I'm suggesting is that when the airplane is in holding pattern or at airport the running cost would be reduced a lot. This way the smaller airplanes would become proportionally easier to make profit with. Also, making shorter routes become more interesting when flying twice shorter route costs only 60% of flying the longer route instead of those 85% figures I got for all faster planes from testing.
Flying 757 on short route costs 500 and generates 7200 while on long route it costs 600 to generate 15600 and that's so stupid. It would be MUCH better if flying short route costs 2000 and generates 7200 while longer route costs 3500 and generates 15600. The modification I suggest addresses this issue. I hope this example clarifies the issue. The numbers in my suggestion can be tweaked but you should get the idea.
Posted: 16 Aug 2005 21:56
by DaleStan
459 wrote:For instance that the running cost of a plane should decrease A LOT when it's on airport or in holding pattern
That'll have to be done in the patch.
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 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?
If changing the running cost balancing will help; feel free to do so; just change .renum/planeset.txt and run MakeRCosts again. (After, of course, removing the sprites that MakeRCosts added when I ran it.)
Posted: 16 Aug 2005 22:02
by 459
DaleStan wrote:
459 wrote:
For instance that the running cost of a plane should decrease A LOT when it's on airport or in holding pattern
That'll have to be done in the patch.
Apparently. Patchman should comment.
DaleStan wrote:
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 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?
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

Posted: 16 Aug 2005 22:18
by Patchman
459 wrote:DaleStan wrote:
459 wrote:For instance that the running cost of a plane should decrease A LOT when it's on airport or in holding pattern
That'll have to be done in the patch.
Apparently. Patchman should comment.
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.
Posted: 16 Aug 2005 22:38
by DaleStan
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

Well, then, just change those first 8 numbers in .renum/planeset.txt.
should do the trick.
If I'm doing my math the same way you are, the current values for those rcost multipliers are 0.8, 1.2, 1.6, 2.0. IOW, the rcosts will be increased for planespeeds 1..3, and left untouched for planespeed 4. Is that what you wanted?
Patchman wrote:I'm not sure it's realiably possible to detect whether a plane is in the holding loop or in regular flight.
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.
[0]Planes cruise with byte 62 set to 12, and choppers with byte 62 set to 14. However, the holding pattern uses byte 62 set to 10..14.
Posted: 16 Aug 2005 22:50
by krtaylor
In a perfect world, we'd have the larger airports that didn't get as congested, and maybe had a short runway dedicated to small planes. That would give them an advantage, a la LaGuardia IRL. But that ain't gonna happen either.
Posted: 17 Aug 2005 13:24
by 459
Seems like there's two options:
EITHER
1. We'll delay the release until there's a good solution for this running cost problem. I'd like to know soon whether it's doable in some sensible way or if anyone has any interest towards implementing it. I'm interested in hearing your suggestions in order to figure something out.
OR
2. I'll axe S-58 and Trimotor, replace them with something useful, implement the current model of speed-dependent running cost multipliers, tweak the rest of smaller planes to be useful, finish the documentation and release the set.
Say something.
Posted: 17 Aug 2005 14:30
by krtaylor
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.
Posted: 17 Aug 2005 20:20
by 459
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.
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:
-Add Fokker F-27. This'd make Dash 8-100 kinda useless since it has similar stats while it appears years later. The Dash 8-100 can be replaced with a 70-seat prop plane (we don't have anything like that yet!) such as BAE ATP, Dash 8-400 or ATR72. F-27 and ATR72 already exist in the 459 remix so there's minimal work putting them into this set.
-A 70-seat regional jet is something we are also missing. CRJ-700 would be great. Then again, we'd have two CRJ's but we could replace the CRJ-100 with Embraer ERJ145.
To sum it up, I'm suggesting following
OUT:
Sikorsky S-58
Ford Trimotor
Dash 8-100
Canadair CRJ-100
IN:
Fokker F-27
BAE ATP or Dash 8-400 or ATR72
Canadair CRJ-700
Embraer ERJ-145
I wouldn't have too much problems making the required gfx and coding job for these planes in one day. I'd see these changes necessary in order to make plane catalogue more coherent.
Posted: 17 Aug 2005 21:17
by krtaylor
Well, OK. I'm sorry to lose the Trimotor because it was a very famous plane, in the US at least.
Posted: 17 Aug 2005 22:02
by DanMacK
Honestly, I didn't use the trimotor much, I used the Zeppellins or the DC3. I'm all for these changes.
Posted: 17 Aug 2005 22:18
by RPharazon
As long as the DC-3 stays in, I'm fine. I use the zeppelins and the DC-3 in those times, only if a railway option isn't feasable.
The DC-3 is an amazing piece of airplane, if you've seen one up close, it's easy to see why it was so big in those times. It was like the 747 of way back when.