Planes take over 12 hours to load

[skreyola]

I'm playing with the most recent experimental version, and when I use planes, specifically the cargo planes, they seem to take days to load just 25 crates. It doesn't even take hours to bring a passenger jet in, unload, clean, refuel, and load, so why are planes taking so long to load cargo?
Most of the planes I use are vilvoh's "fly me to the goods" planes and helicopters, and I'd like to think they wouldn't take that much longer than trucks to load. I can't hope to make up my purchase and maintenance costs if it takes a month to fly one round trip.
Thoughts?

[jamespetts]

Apologies for the delay in replying - I have only just got broadband set up in my new flat. What you describe is intentional. The loading time is intended to be consistent with the journey time. Because aircraft in real life take a long time to turn around and load, they also do so in Simutrans-Experimental (although the times can be adjusted by the pakset authors). The loading time for each vehicle should be visible in the depot window. (Incidentally, the default loading time for aircraft in Simutrans-Experimental was largely based on passenger loading, which does take a very long time because of check-in, security, etc.. That has the effect that passengers will very rarely use air travel if the equivalent land-based journey takes less than three hours. I put in a high default loading time specifically to attempt to simulate that factor. In a Simutrans-Experimental compatible pakset, one could, if one wanted, alter the loading time for cargo aircraft only. The intention was, however, that aircraft would only be profitable for the sort of distances (assuming whatever scale is currently set: Pak128.Britain uses 250m/tile) for which they would, in real life, be profitable).

They do not take "days" to load (any more than a 'bus takes "days" to travel to its destination) because there are two different time scales in Simutrans (necessarily for playability purposes): one on which speeds, journey times and loading times are measured, and one on which days, months and years are measured.

[knightly]

Because aircraft in real life take a long time to turn around and load, they also do so in Simutrans-Experimental (although the times can be adjusted by the pakset authors).

It seems to me that airplanes' turn-around time has already been included in the calculation of average speed, right? If yes, then it would be double-counting if it contributes again to loading time.

[jamespetts]

It seems to me that airplanes' turn-around time has already been included in the calculation of average speed, right? If yes, then it would be double-counting if it contributes again to loading time.

There is no double counting: it is only taken into account in average speed because it is taken into account in loading. There is no extra factor depressing average speed for aircraft especially.

[knightly]

There is no double counting: it is only taken into account in average speed because it is taken into account in loading. There is no extra factor depressing average speed for aircraft especially.

There is double counting, because the turn-around time is already part of the journey time.

[jamespetts]

There is double counting, because the turn-around time is already part of the journey time.

I don't follow - the turn-around time being part of the journey time is the only way in which it is counted. There is no other way of counting it such that it is double counted.

[knightly]

Okay, maybe I've got you wrong. I thought you have extended the loading time out of consideration for turn-around time.

[jamespetts]

Okay, maybe I've got you wrong. I thought you have extended the loading time out of consideration for turn-around time.

I don't understand what you mean here.

[knightly]

I don't understand what you mean here.

Haven't I made it pretty clear that I have probably misunderstood your point? What do you not understand here?

[jamespetts]

Haven't I made it pretty clear that I have probably misunderstood your point? What do you not understand here?

I suspect that we are both equally confused...

[skreyola]

Apologies for the delay in replying - I have only just got broadband set up in my new flat. What you describe is intentional. The loading time is intended to be consistent with the journey time. Because aircraft in real life take a long time to turn around and load, they also do so in Simutrans-Experimental (although the times can be adjusted by the pakset authors). The loading time for each vehicle should be visible in the depot window. (Incidentally, the default loading time for aircraft in Simutrans-Experimental was largely based on passenger loading, which does take a very long time because of check-in, security, etc.. That has the effect that passengers will very rarely use air travel if the equivalent land-based journey takes less than three hours. I put in a high default loading time specifically to attempt to simulate that factor. In a Simutrans-Experimental compatible pakset, one could, if one wanted, alter the loading time for cargo aircraft only. The intention was, however, that aircraft would only be profitable for the sort of distances (assuming whatever scale is currently set: Pak128.Britain uses 250m/tile) for which they would, in real life, be profitable).

They do not take "days" to load (any more than a 'bus takes "days" to travel to its destination) because there are two different time scales in Simutrans (necessarily for playability purposes): one on which speeds, journey times and loading times are measured, and one on which days, months and years are measured.

The end result is that airplanes are pretty well unfeasible for most lines, even where a comparable line might be common in real life, say, when flying to a distant island city.
While it does take passengers a long time to get through security, etc., that all happens before the plane lands. It doesn't take a plane very long to land, unload, refuel, load, and take off. I appreciate the nod to realism and balance, but all of my airplane-based lines have very unhappy stations because of the unbalanced turnaround time, and my airports have to be huge. The worst thing is that they load fully almost instantly, then sit on the loading spot for ages without seeming to do anything.
I think planes should load a lot faster (taking, say, ten times as long as a bus), while the airports should hold passengers longer during transfer (that is, a plane lands, unloads/loads quickly, but those passengers are trapped in the station for longer than freight or non-air stations. Of course, it could be coded such that passengers going TO a non-air vehicle could go the same speed as other station transfers... but maybe not)... and anyway, why should there be real-world level security delays in ST? Air travel wasn't that slow in the early days or in most of the 20th century... so why in the game? Or if you want that delay, it should be tied to the timeline.

[jamespetts]

Skreyola,

over what distances are your aircraft lines non-viable? Even without post-2001 enhanced security, boarding an aircraft has always been a lengthy affair, involving some element of security, check-in, baggage loading and so forth. For that reason, even in decades past, aircraft were not a viable means of transport over short distances in most cases.

It is immaterial for the purposes of the game whether the passengers are logged as having boarded the aircraft before or after the turnaround delay, and it would require a major rewrite of the code to change the way in which that is done.

Remember, the 30000ms delay for loading of aircraft is simply a default value applied wherever the pakset author has chosen not to specify individual values for the specific aircraft. The intention is that larger aircraft have longer loading times, whilst smaller aircraft (such as those that might be used for a short hop to a small island) would have rather shorter loading times. For that reason, too, the loading times can be tied to the timeline - by the pakset author.

[skreyola]

security, boarding an aircraft has always been a lengthy affair, involving some element of security, check-in, baggage loading and so forth. For that reason, even in decades past,

It is immaterial for the purposes of the game whether the passengers are logged as having boarded the aircraft before or after the turnaround delay, and it would require a major rewrite of the code to change the way in which that is done.

Remember, the 30000ms delay for loading of aircraft is simply a default value applied wherever the pakset author has chosen not to specify individual values for the specific aircraft. The intention is that larger aircraft have longer loading times, whilst smaller aircraft (such as those that might be used for a short hop to a small island) would have rather shorter loading times. For that reason, too, the loading times can be tied to the timeline - by the pakset author.

To your first point, I will say again that the security procedures and passenger check-in stuff normally happens asynchronous to the loading of the plane. The passengers have gone through the checkpoints of whatever variety before the plane they'll ride even lands, in most cases.

To your second point, I'm wondering why the plane, if it's going to take 30000ms to load, doesn't progressively show the loading, i.e., why does the bar go from empty to full in 1ms if the loading of those passengers will take 30000ms? I understand that it's based on how many passengers are in the station, but perhaps this should be an extension, that the loading bar doesn't move instantly if the cargo takes a noticeable amount of time to become transportable.

Your third point answers my actual question. I need to talk to pakset authors about adjusting their loading times.

[jamespetts]

To your first point, I will say again that the security procedures and passenger check-in stuff normally happens asynchronous to the loading of the plane. The passengers have gone through the checkpoints of whatever variety before the plane they'll ride even lands, in most cases.

To your second point, I'm wondering why the plane, if it's going to take 30000ms to load, doesn't progressively show the loading, i.e., why does the bar go from empty to full in 1ms if the loading of those passengers will take 30000ms? I understand that it's based on how many passengers are in the station, but perhaps this should be an extension, that the loading bar doesn't move instantly if the cargo takes a noticeable amount of time to become transportable.

The point is simply that what is currently in the code is functionally identical to what you suggest, and was added to what was there very simply. The difference between what you suggest and what is present would simply be cosmetic, but would require an enormous amount of work to achieve - time better spent on other projects.

[Isaac Eiland-Hall]

In my humble opinion, it is a GAME. Although there is some point to discussing reality, ultimately, the game should be balanced.

Does the time required for loading balance the game? Good.

If not? Perhaps it should be changed.

:shrug:

[jamespetts]

Ahh, the view that I take of such matters is that being "balanced" is functionally inseparable from being realistic if things are done properly, and, if there is a separation, there's a flaw in the design somewhere.

[Isaac Eiland-Hall]

Then, by that measure, I propose there are inherent flaws in the design: For example, a tile is something like 20-30m *and* 1km, both.

Simutrans is a simulator, but by its very nature, it is also a game; it makes many compromises because it cannot be 1:1 scale, for example.

That's just one example, there are others, of course.

I'm not saying we shouldn't strive for realism, but ultimately I think we should strive first for game balance - balancing simulation and playability.

[jamespetts]

Some compromises are technically unavoidable: others are not. The distance scale compromises are not matters of gameplay balance, but rather technical limitation. The game would not be unbalanced if there was a single, realistic scale used: just very, very slow. I don't think that balance, per se, is opposed to realism. Technical limitations, conversely, often are.

[Isaac Eiland-Hall]

And yet these technical limitations inherently mean that the simulation is less-than-real.

[jamespetts]

Yes, indeed. But that's no reason to make it even less realistic than is achievable within the technical limitations.

[skreyola]

Some compromises are technically unavoidable: others are not. The distance scale compromises are not matters of gameplay balance, but rather technical limitation. The game would not be unbalanced if there was a single, realistic scale used: just very, very slow. I don't think that balance, per se, is opposed to realism. Technical limitations, conversely, often are.

By the same token, if you want realism, then consider that the time between a passenger's entry into the airport and the time when their plane takes off is seldom more than five hours.
For cargo, it could be a little longer, since cargo doesn't complain about delays, or significantly shorter, since cargo doesn't have to be sent through the level of bottlenecked security pax do and can be loaded concurrently with less finesse and no preflight instructions, seating hassles, etc.
However, it shouldn't be 10+ hrs. to load 25 or fewer units of cargo.
That said, I understand that the loading time should be done in the paksets, so I'm only talking about abstract realism, here... unless this is a good enough argument to alter the default load time.

[jamespetts]

...However, it shouldn't be 10+ hrs. to load 25 or fewer units of cargo....

As I've written above, this is not a correct extrapolation of the time, as, owing to other techincal/practical limitations, there are two different time scales: measuring the loading time as 12/10 hours is using the wrong timescale to measure how long that it takes.

[skreyola]

What scale should I be using? All I know is that when a vehicle takes that long in game time to move off of the stop, it makes it hard for me to keep the station status green.

[jamespetts]

What scale should I be using? All I know is that when a vehicle takes that long in game time to move off of the stop, it makes it hard for me to keep the station status green.

The scale that should be used is the one by which journey times are measured. As to having trouble keeping your status green - can you upload a saved game? It is hard to comment on balancing without seeing it in practice. It may simply be that you need another terminal at your airport and more aircraft.

[skreyola]

To make an airport work (carrying cargo), I need not just 4-8 planes but the same or nearly the same number of stop spaces. That gets expensive and sprawling pretty quickly.
But I guess if that's what I have to do, that's what I have to do.
I don't know. I may just stop playing the Exp branch. The pak authors don't seem to be jumping on this bandwagon, and this is just one of many features that are crippling to the game when played with the default Exp branch rules (another major one is the lack of tracks that can carry the heavier engines).
Thanks for your time.

[jamespetts]

Skreyola,

can you please upload a saved game? I really cannot get any sensible idea of what the balancing issues are if I cannot see them in action. It is realistic for airports to be expensive and sprawling, but, obviously, something is wrong if airports need to be so expensive that aircraft can never make money. I can have no idea whether something of that order is wrong or not until I see a saved game that I can analyse.

As for paksets - Pak128.Britain-Ex is the main Simutrans-Experimental compatible pakset, on which I and The Hood have been working for some time (The Hood being in charge of the standard version, and I its adaptation to Simutrans-Experimental).

Incidentally, the weight limits feature can be disabled in simuconf.tab: set enforce_weight_limits=0.

[skreyola]

Thank you for your response, but I do not know how to upload a saved game at this point, and I have decided to just wait until the experimental branch is more mature.
I get that a major airport can be big and sprawling, but here in the States, we have many tiny airports with a little grass strip and a few loading bays, so I question that they should have to be huge, especially if the industry doesn't produce much in a month. I'm mainly talking about lines that, in STS could be handled by one plane.
If you would like to see this in action, it can be had by connecting any crate-producing industry with its consumer. This is not a bug or something that is difficult to reproduce. I'm using pak64, so that might make a difference, but the posting about STE features indicated I could keep using the existing paks for standard. If that is not the case, it should not be posted that way.
I understand that 128.Britain is the main thing for this branch, but my poor little laptop can't handle pak128, so that's a non-starter for me.
I don't want to disable the weight limits, but having the fastest possible track unable to carry every engine available seems to me to be a balance issue, too.
Anyway, I've decided that the experimental branch just isn't ready for a casual player like me, yet. I wish you all the best on this endeavor. Fare well.

[Isaac Eiland-Hall]

In case you change your mind - if you're Windows, should be able to find the saved games in your Documents folder, in Simutrans folder. Can upload to http://files.[ simutrans [dot] us (site down, do not visit) ]/ without creating an account, then post the link here, of course.

But no worries on my account - just trying to let you know how.

[jamespetts]

Skreyola,

the only way in which Simutrans-Experimental can become more mature is through analysis of feedback such as yours, and, in many cases, the only effective way to do so is to look at saved games. If I try to reproduce what you describe using only your description, I might interpret it very differently to you. I do not know, for example, what the production of the industries in question are, what the distance is, to what you have set the scale factor, nor how large and sprawling that "large and sprawling" really is.

Given that Isaac has given an easy explanation as to how to upload a saved game, I should be very grateful if you could do so that I might analyse the issue and decide what, if any, corrective measures need to be taken to address balance issues. One possibility might be to link the default loading time of an aircraft to its capacity, for example, but I cannot tell whether that is needed, and if so, in what proportions without seeing your game in action.

[skreyola]

I started to do just that, but it seems that I no longer have a savegame with airports like what I was describing. I saved that game in a round of 3 files, and it was more than three saves ago that I bulldozed my airports and put in rail stations because the service ratings were low. I'm sorry that I could not fulfill this request at this time.
As a discussion point, remote locations can be reached by a small airfield in real life.
I'll try to remember to put together a savegame that shows this, but part of my reluctance is that I tend to have a lot of addons and extra paks loaded, and it gets difficult to remember which paks are needed for a particular savegame. I would include a listing of the files in my pak folder.

[jamespetts]

Skreyola,

thank you for your feedback. As indicated above, small aircraft should have lower loading times than large ones. With default values, it is hard to get an accurate balance. The priority needs to be the production of a Simutrans-Experimental compatible pakset, on which I am working with Pak128.Britain-Ex.

[Isaac Eiland-Hall]

It might be easier to make an archive of your pak folder and upload that - there should be plenty of space to upload that