Recent Posts

Pages: [1] 2 3 4 ... 10
I can see that this might be useful - although I suspect that it would also be a fair bit of work, not least as I do not know much about the physics engine myself, it (including the current haulage estimates) having been written by Bernd Gabriel some years ago.
Simutrans Extended Discussion / Re: Bus route through schedule hours.
« Last post by jamespetts on Today at 12:42:57 PM »
We already have a system that has the same function, although it works slightly differently, in Simutrans-Extended: you can set fixed departure intervals for all convoys on a certain line using the "wait for time" option in the schedule dialogue when creating or editing a line.
What I had understood that Dr. Supergood had suggested was that the public player (and only the public player) should be able to create roads that can be modified by other players (i.e., have the same status as the current privately owned/unowned public rights of way).

This should not be exploitable, as the roads would start as being built by the public player and thus the players would have no way of divesting themselves of their own maintenance costs.

Such a tool would be relatively simple in principle to implement, although it would involve a fair bit of tedious (but conceptually simple) work of the sort that accompanies implementing any new tool.
This was introduced into Extended (then "Experimental") back in 2011 by a developer (Yobobandana) who has long since left the Simutrans community. Its purpose is to mean that the "mirror schedule" feature can be used for double track railways, the trains automatically finding the correct platform on the same track without the player having to specify manually that the train should stop on the down platform on the way out and the up platform on the way back. This should not (and, to my knowledge, does not) result in trains incorrectly using bay platforms, as the route to a bay platform is almost always longer than the route to a normal platform (although I have not seen any cases where London Underground style centre bay platforms are used in this configuration).

This functionality is different to that of choose signals; however, I should be grateful on people's views as to whether this functionality should also be disabled when the "ignore choose signal" option is selected in the forthcoming feature-set (as currently under development on the vehicle-management branch).
That would be very helpful, thank you. I suspect that the biggest inefficiency is in the use of the weighted vector: the at_weight function has a computation time which increases with the number of elements in the vector, which, of course, is quite different from an ordinary vector, where performance is constant no matter the number of elements.

I did look into this, but there is no standard weighted vector, and all the suggestions for writing algorithms for this that I can find use precisely the same sort of iterate through everything in the list mechanic used by the current system. In theory, I imagine it would be possible to have a system with multiple entries in a vector, the number of entries representing the weight. This would then greatly improve access time, but probably at the cost of much higher insertion/removal time for elements and higher memory overhead (although all that would be stored would be 64-bit pointers).

Do not worry about the time, incidentally, as it takes me a long time to get around to things to, and the code is complex.
Can you upload a savegame for this, in which the lines and convoys are already made and just need to be dispatched?
If passenger generation is the main performance issue, then I'll add that code to my list of things to investigate, and see if I can find any improvements to it (although at my current rate someone else may get there first). It seems like the sort of code that would be easy to write inefficiently, and hard to fully optimise.
Incidentally, this sort of thing would probably be easier for me to investigate once I have a more powerful laptop (in particular, with more RAM) and can actually run the server game myself.
So if I understand you correctly, then the current behaviour might result in train being inappropriately sent off a through line into a bay platform if the mainline is congested. Is that correct? If so, when did this behaviour get introduced, and why? I don't remember it being a feature when I played Simutrans in the past, and I can't see why it would be a desirable feature, given that choose signals exist.
Are you suggesting that players should be able to make roads that other players are allowed to subsequently modify? For example, if I upgrade the road between two cities, that shouldn't prevent another player upgrading the road further? I think a good solution to this (without encountering the issues of abandonding responsibility of rights of way, on which I know you disagree) would be to separate the concepts of 'owner' and 'maintainer', and allow players to designate a road as having a (NULL) owner, or maybe even a different player owner.

This could then provide a mechanism for transferring ways between players. If player A wants to transfer a road and its costs to player B, then player A sets the owner to player B, and player B then sets the maintainer to player B. However, this doesn't immediately allow for player B to pay player A for the road.
Simutrans Extended Discussion / Nonsense rail physics?
« Last post by DrSuperGood on Today at 06:44:26 AM »
The very first horse drawn trains have arrived to the server game. However I am struggling to get them to cope with inclines. A single 18 km/h horse will pull a single passenger truck at 18 km/h on the flat but fall to a painful <<1 km/h on a single incline (1 elevation difference, not a double incline). Trying with 2 such horses yields similar, but slightly better results. Only with 3 horses per passenger truck can it go up single elevation inclines at a reasonable speed while still dropping to 1 km/h towards the top of a single incline.

So I went ahead and tried the silly thing of 0 trucks and 1 horse. The results are that a horse pulling no load can achieve 18 km/h on the flats but only 7 km/h climbing an incline. The UI says it will drop as low as 4 km/h if multiple are chained but it seems pretty stable at 7 km/h. Now I am no expert on horses but I am pretty sure they can gallop up hills at a faster speed than 39% of their flat gallop speed, after all horses are often found in hilly areas.

Now I do not really know about rail physics but from a game play perspective this is kind of ludicrous. I understand that single slopes are meant to represent an incline of ~26.565 degrees which is kind of steep as far as transport goes. However that is the shallowest one can make an incline due to game limitations meaning more realistic inclines of 10 degrees or less over longer distances is mechanically not possible for the player.

I am not saying the physics itself is wrong but game play wise something is off.
Pages: [1] 2 3 4 ... 10