The International Simutrans Forum

 

Author Topic: Next steps for Experimental  (Read 9534 times)

0 Members and 1 Guest are viewing this topic.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Next steps for Experimental
« on: February 06, 2011, 04:33:03 PM »
Sadly, it seems as though the discussions about missing economic dynamics in Simutrans may well not progress much further for reasons which are somewhat unclear, so this seems to be a good time to consolidate what has been learned so far from that discussion and prepare a list of features to be working towards for the next major version number release of Experimental. In that process can also be consolidated a number of other enhancements that have shown themselves to be necessary following user feedback from the 9.x versions. I shall set out a list with a brief description and invite comment.

In the meantime, the 9.x branch will continue to be developed with bug fixes and minor enhancements, and, to that end, I am planning a release of 9.3 at around the same time as the next stable release of Standard, which I am told is imminent. That fixes a number of bugs reported, and also greatly reduces the adverse effect on performance caused by the private car routing feature. I also plan to release Pak128.Britain-Ex 0.8 fairly soon, which will incorporate an industry re-balancing based on the work done by AEO in this thread.

Physics features

Axle loads

Standard will be implementing axle loads after the next stable release, which will be accommodated into Experimental. From previous discussions on the topic, it seems that bridge weight limits are generally not axle load weight limits, but total weight limits. There may be some advantage in having bridges retaining the existing per-vehicle weight limit, while other types of way use the axle loading systems. This would be differentiated to the user by showing "xt (axle)" or "xt (vehicle)" in the tooltips showing the weight limit for ordinary ways and bridges.

Gradients Complete

It has been found that the current physics system in Experimental does not provide a sufficient disincentive to build gradiented ways, especially railway lines. The problem appears to be that the momentum of vehicles when they are moving fast enough is almost always sufficient to overcome the gradient without any significant reduction in speed if the gradient is only one tile, as most gradients are. The solution that I propose is to give the physical effect of a gradient not just on the gradient tile itself, but on the several tiles before and after the gradient, in much the same way as is already done for corners, thus spreading out the effects of gradients without changing the underlying physics model.

Economic features

Credit interest rate Complete

Players would earn interest on any liquid capital that they have in their bank account at any given moment, at a rate specified in simuconf.tab. This would typically be lower than the debit interest rate already specified. This is a very simple feature.

Usage adjusted vehicle maintenance costs

The best way of implementing this in gameplay terms, I think, is to increase the per kilometre (and possibly also per month, although, if this is mostly staff cost, is this appropriate?) maintenance cost as each vehicle's odometer increases up to a fixed maximum, using the "sigmoid" non-linear function suggested. In the .dat files, the number of kilometres before the maximum maintenance figure is reached and that adjusted maximum maintenance figure (as a percentage of the normal maintenance figure) would be specified.

This mechanism would work together with a system of overhauls. An overhaul, which would not require the vehicle to return to the depot, would cost an amount specified in the .dat file (or, query, would a fixed proportion of the unit's purchase price be better?) for the first overhaul. Each subsequent overhaul would cost more than the last (possibly using the "sigmoid" algorithm, or perhaps a simple capped linear approach). A possible addition to this feature would be the ability to delay overhauls either per convoy or per line. I imagine a simple mechanism for delaying overhauls, with a simple binary control: the vehicles would either be overhauled (by default) at the standard time, which would be the most economic point to overhaul the vehicle (either specified in the .dat file or perhaps calculated by the game at runtime), or at the delayed time, which would be the latest possible point for overhaul (after which it is presumed that the unit would be unserviceable unless overhauled). The button for delaying the overhaul might perhaps have a tooltip showing, when depressed, what the immediate cost would be of overhauling all vehicles whose overhaul is delayed by that option being selected, which cost would be incurred as soon as the button is released. Except for this ability to delay overhauls, vehicle overhauls would be conducted without any intervention by the player. Query whether (1) overhaul costs should have their own graph in the finances window; and (2) the cost of overhauls of obsolete vehicles should additionally be increased by the obsolescence factor.

Usage based way maintenance costs

Way tiles would record the weight passing over them and charge maintenance - in addition to the fixed monthly maintenance - based on that weight loading, perhaps at the end of the month. One issue yet to be resolved on which feedback would be appreciated is whether the cost should be a simple value per unit of weight, or should vary depending on the ratio of each axle load to the maximum axle load of the way, and, if so, whether that variance should be linear, logarithmic or exponential. Also in need of discussion: how best to represent this to the player, and, if the cost is anything other than a flat per unit of weight charge, how to set the value in simuconf.tab?

Closely connected to this would be the need to renew ways after they have been used a particular amount to give them effectively a limited lifetime. The options for doing this are constrained by the need to avoid excessive "micromanagement" on the part of the player. Players certainly should not have to re-lay roads or tracks themselves when it gets time to renew. The simplest way of achieving this would be to have a built in renewal cost and renewal threshold, that threshold being set in terms of the total weight (or possibly axle loading in proportion to the limit?) that that way tile has born since it was last laid or renewed. One matter on which feedback would be appreciated: is it better to have set the renewal cost in the .dat files as an absolute figure or as a percentage of the as new price? The only realistic way of representing this to the player would be to show statistics about the age and total weight carried of a way tile when that way tile is inspected, as well as its date of last renewal and cost of next renewal.

Consumer industries in towns to depend on town size Complete

Consumer only industries in towns would have their production set when first built according to the size of the town relative to other towns on the map, within its existing range. For example, if an industry had a base production of 100 and a range of 50 (that is, a production range of between 100 and 150), then, on the smallest sized town on the map, its production would be 100, on the largest 150, and in intermediate towns, intermediate values.

Way upgrade costs and mothballing

It would cost less to upgrade one way to another way of the same type (for example, one sort of road to another sort of road) than to build the second way fresh. The percentage reduction (by default, 25%) would be able to be set in simuconf.tab.

It is already possible for a pakset author to have a "mothballed" waytype, that is, a waytype that has a 0 build cost, a 0 maintenance cost and maximum speed and weight of 0 to which other ways can be downgraded (CTRL+click when laying to downgrade) to give players an alternative to demolishing a route, although no pakset author has done this so far. The advantage of this at present is somewhat marginal, but it is cheaper than bulldozing and prevents other players or cities from taking over the land in cases where one might want to use the way again in the future. The reduced way upgrade costs would give an extra incentive to mothball as opposed to bulldoze, as re-upgrading a way after mothballing it would be cheaper than bulldozing it then building it again from scratch. However, it would mean that mothballed ways of this type could be used as an exploit: build a mothballed way (at 0 cost), then immediately upgrade it to the desired waytype to acheive a 25% reduction in cost. To avoid this, it will be necessary to make it impossible to build a mothballed way (designated as any with a maximum speed and maximum weight of zero) other than by downgrading an existing way.

Miscellaneous features

Replacer enhancements

The replacer needs to be able to work with stored but out of production vehicles. It also needs to be changed so that it does not cause huge disruption by replacing everything at once.

To acheive the first aim, I plan to overhaul the way in which the replacer deals with existing stored vehicles: instead of taking no account of them when the selections for replacement are made, then using whatever it can find at the depot, the best solution, I think, is for the replacer to show all stored vehicles available at all the player's depots (whether out of production or not) in the same way as the current depot windows do with vehicles stored at that depot. When replacing, the vehicles will be sent to the depot in the same way as now. If that depot doesn't happen to be the one in which the stored vehicles are located, they will automatically be transferred (not by sending them out over the ways, but by making them available in the new depot instantly and deleting them from the old depot). If the player has used or sold the vehicles in the meantime, the replacer will simply buy new ones when it reaches the depot. If those vehicles happen to be out of production vehicles, it will still buy new ones, but will charge twice what they cost when they were not out of production, and display a message to that effect. This is necessary to discourage this mechanism being used as an exploit to buy out of production vehicles new.

A similar mechanism can eventually be used to allow players to trade vehicles on the secondhand market between themselves, but it would require further refinements.

As to the second replacer issue, the solution is simpler: let the user specify how many convoys are to be replaced at once; then, once the first batch has been replaced, the second batch will be sent for replacement and so forth until all convoys on the line have been replaced.

Edit: The replacer also needs to be modified, as suggested some time ago by Neroden, to treat convoys as the same as each other when they have the same set of vehicles, regardless of order.

Industry re-linking Complete

Because industries close down in Experimental, it is sometimes the case that an industry with many inputs ends up with few inputs and only a small proportion of the necessary input goods, greatly reducing its output capacity. A mechanism needs to be built, therefore, to re-link existing industries with other producing industries so as to maintain some level of equilibrium. Such a mechanism should also enable less stringent criteria about the parameters of the industries to which other industries can be upgraded, as has been requested recently by a user.

Liveries Complete

I have thought somewhat further about The Hood's idea of having players select liveries from a drop-down menu: this might actually be quite a good idea, especially if combined with the vehicle overhaul feature, as it would help to add a degree of historical consistency to vehicle appearances.

My preliminary view is that this is best achieved in the following way: for each vehicle, one could define a number of liveries or appearances in the .dat file. These would be defined in the same way as the existing graphics (I am not yet sure what syntax would be best to show additional liveries). Each livery could be assigned a name and a date range in the .dat file (for example, something like: LiveryName[0]=BR-Blue; LiveryIntroYear[0]=1965; LiveryIntroMonth[0]=5; LiveryRetireYear[0]=1984, etc.). If the existing standard .dat files are used without livery definitions, the vehicle would be deemed to have one livery with the name "default". More than one livery on each vehicle might have the same name, but a different date range. If two liveries with the same names had overlapping date ranges (which ought not be specified), the cut-off point between the two would be deemed to be the introduction date of the newer livery. Whenever a vehicle is overhauled, it would automatically be upgraded to a livery that is current according to its specified date range, if possible, one with the same name as its present livery. This has now been implemented.

Players could specify the livery scheme by a drop-down menu in the convoy window or the line window, containing the names of all the liveries supported by any of the vehicles in that convoy or line. Liveries could thus be specified by convoy or by line. Whenever a player makes a selection of livery for a convoy in a line, all the vehicles in that convoy or line would be switched over to the current version of the livery with that name if a livery with that name is available for that vehicle. If no suitably named livery is available, the current livery would be retained. When built new, vehicles would have by default the first livery specified in the .dat file that is within the current date range (or, if no livery is within the current date range, the first livery specified).

Thus, the triggers for changing the livery would either be: (1) an overhaul; or (2) the player selecting a new livery from the drop-down box in the line or convoy. One issue on which feedback would be appreciated, however, is this: what is to be done about different liveries with the same names but different date ranges when the timeline is disabled?

Edit: Updated to add reference to consumer industries' productivity values and upgrade costs/mothballed ways.

Edit 2: Updated to refer to those features now implemented as of 9.11.

Edit 3: Updated to refer to those features now implemented as of 10.1
« Last Edit: October 07, 2011, 01:30:33 AM by jamespetts »

Offline The Hood

  • Devotee
  • *
  • Posts: 2889
  • pak128.Britain developer
Re: Next steps for Experimental
« Reply #1 on: February 06, 2011, 05:32:40 PM »
I like the sound of the livery option - seems the best of both worlds.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Next steps for Experimental
« Reply #2 on: February 06, 2011, 05:35:30 PM »
I must confess, I do rather look forward to seeing an aesthetically homogeneous set of trains running about in era-appropriate colours! I should be able to output livery variations on my outputs in due course. Incidentally, did you ever get around to putting together those Victorian locomotive .blends to send to me for gap filling?

Offline The Hood

  • Devotee
  • *
  • Posts: 2889
  • pak128.Britain developer
Re: Next steps for Experimental
« Reply #3 on: February 06, 2011, 05:50:23 PM »
Would appear I forgot - which did you want?

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Next steps for Experimental
« Reply #4 on: February 06, 2011, 05:55:36 PM »
The planetee, Jenny Lind, Bloomer and SDR Derwent. Thank you - that's most kind.

Offline Banksie_82

  • *
  • Posts: 47
Re: Next steps for Experimental
« Reply #5 on: February 07, 2011, 06:10:32 AM »
I’m a civil engineer, so I deal with the design, construction, coordination, maintenance, running and all associated costs of different type’s infrastructure on a daily basis. I’m happy to share my knowledge with those that want ST-Exp to be as realistic as possible with respect to these things. If you want me to go deeper please ask, but I can get quite long winded.

Load limits…
As mentioned by others, load limits are a complex situation in real life, as an example, I’ll concentrate on roads.
At least in my country, and from what I can gather most countries around the world, roads are designed based on a concept of “Equivalent Standard Axles” or ESAs. Very roughly, an ESA is a single axel, two tires at each end and a total load of 80kN (about 8 tonne). Everything on the road is then scaled to this base unit. However, the scale is not linear. For example, a heavy vehicle (semi-trailer) does 11,000 times more damage to the road than a normal family car. When designing the pavement structure of a road, cars are completely ignored; it’s the heavy trucks that do ALL the damage. The ESA is calculated for the design life of the road, not a per year quantity. However, the design life is also affected by other factors, such as corrosion of pavement and weathering effects. In my country, a standard design life for a road is 20 years, but that can vary depending on what it is.
For the load bearing capacity of a bridge as a structure (remember that bridges still have pavement and therefore ESA or axle load is still relevant) the total load on the bridge is what’s important. For Simutrans, that’s all convoys on the bridge at any one time. However, the distribution of load is also a factor. The total load in the middle of a span is worse than the same load evenly spread over the structure, or close to the supports. Also, the longer the span, the more stress applied to the structure for the same given load, and so the structure needs to be stronger. It gets quite complicated, there’s a reason it’s a part of a 4 year university degree. I don’t think that ST would want to go to this level of detail.

Usage based way maintenance costs…
See my little rant above about ESAs. The number of ESAs certainly has a bearing on the maintenance of a road or rail. But so does the speed at which those loads pass over the way and also the stopping and cornering. If you think of a wheel going over a road at a constant speed, the only force is down, due to gravity. Once you introduce cornering, breaking and accelerating, the forcers suddenly become horizontal as well as vertical. This dramatically increases the maintenance of a road as well as rail. For this reason, intersections for roads and corners for rail, are often built at a higher grade. However, if you look closely near bus stops, you’ll often find the road pavement is a lot worse off than the surrounding pavement. Similarly, rail tracks near stations need to be replaced more often than other parts of the network.

As for the replacement of ways… I always just assumed that in ST the monthly maintenance cost took care of the replacement of ways, granted in a fairly simplistic way. In reality, companies and governments plan for this from the day the infrastructure is built. Often they will have a sinking fund that they put money in, either real or just an accounting trick, which they then draw on to renew things as needed. The amount they put in is based on the design life, as advised by engineers, and accounting methods, such as discount rates and the like. Maybe ST-exp can have a sinking fund also, in which players can use for capitol costs if they want, knowing full well that they are effectively borrowing from themselves. Maybe even have a graph of expected infrastructure renewal costs, as best as can be estimated, for the future 5 or so years that the player can look at and plan for.

Also, the replacement of ways should not cost the full amount for those ways if they were new. I’m kind of uncomfortable with the fact that currently to upgrade a way over an existing way costs the full amount as though it was new. In reality, the cost of a new road or rail track includes, but is not limited to, the following: minor earthworks (smaller than the ST scale), major earthworks (raising and lowering terrain in ST), clearing the land (trees as well as shrubs and grassland), demolition of existing infrastructure (building as simulated in ST but also fences, very minor access tracks etc.), purchase of the property (somewhat simulated in ST with fields and in cities with buildings but what about all the free space in between, is this owned by no one and free for anyone wanting to build on it? I would have thought that this was government land, or crown land in the case of “Commonwealth Realm” countries.), relocation of services (water pipes, telecommunications, low voltage electrical, gas, stormwater, sewer. All this is not a trivial cost, especially in built up areas), preparation of the subgrade… and that’s before you even get to the construction of the infrastructure its self. For ST, taking into account all the stuff that is and is not effectively modelled, to replace an existing way with one the same quality, I would say two thirds of the cost does not need to be spent again. If you are upgrading then perhaps half the cost of the new way does not need to be spent. I base this on the fact when you upgrade roads they become a little wider, some minor earthworks are carried out, rail corners may become a little bigger, gradients become a little friendlier, ballast may need to be increased etc.

I think that whatever you end up going with, the need to avoid too much micromanagement should be ever present in your mind. Even now in the game, to upgrade a large section of track to accommodate a heavier locomotive, I find can be a chore. Especially if I have got carried away with upgrading my fleet and haven’t realised that the existing track can’t cope.

I’m happy to share my expertise on anything you may want to know, please feel free to ask. I’m just a bit worried that my posts can become long and tedious for the casual reader.

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4564
  • Languages: EN, DE, AT
Re: Next steps for Experimental
« Reply #6 on: February 07, 2011, 06:11:40 AM »
The ideas about liveries is a great one. It could as well be implemented in standard, as I do not see a reason to have this exclusive for experimental. Whoever will come up with a patch, please provide it for standard too :)

Offline sdog

  • Devotee
  • *
  • Posts: 2039
Re: Next steps for Experimental
« Reply #7 on: February 07, 2011, 06:49:02 AM »
@banksie, you shan't see a tl;dr here!
Thanks this was an interesting read.


@james
if you use a sigmoid curve for maintenance costs, you don't have to worry about defining any fixed overhaul intervals. The player has enough incentive from this curve already. What you could do to ameliorate micro management is to flag the vehicle as 'needs overhaul' at 37% of initial maintenance. If this flag is set, use of a 'overhaul all' will overhaul all those vehicles

I'm quite unsure about the gradients change you propose. But i have to read this again and think. There's also something fishy with the behaviour of trains for some combinations of gradients and curves, where trains seem to be slowed down more than i would expect. I haven't really tested it yet. Last but not least there might arise some issues related to the ability to change the tiles per km setting in simuconf.tab. This effectively changes the gradient for a fixed elevation height.


one small extension request,
this would be an adition to yoyobandanas reverse code, it would be very helpful if vehicles in vehicle list and line list had a visible sign after they name that they reverse. A second less important addition would be signs for circular or reversing routes behind the line name.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9438
  • Languages: De,EN,JP
Re: Next steps for Experimental
« Reply #8 on: February 07, 2011, 09:22:14 AM »
I do not think different liveries of vehicles would help gameplay; especially with networks, where player colors are really needed. Or are you talking of the same vehicle in different colors?

Offline TheUniqueTiger

  • *
  • Posts: 78
    • HiFiBB ... Simply HiFi!
Re: Next steps for Experimental
« Reply #9 on: February 07, 2011, 02:24:59 PM »
James, also please consider displaying line average speed or convoy average speed so that we can make appropriate changes to the network if required. Its already calculated in the game, isn't it? So why not display the same at appropriate place as well... A number of Simutrans features which should provide feedback to player are often hidden.
Thanks.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Next steps for Experimental
« Reply #10 on: February 08, 2011, 12:30:00 AM »
I do not think different liveries of vehicles would help gameplay; especially with networks, where player colors are really needed. Or are you talking of the same vehicle in different colors?

I am indeed talking of the same vehicle in different colours: some paksets (such as Pak128.Britain) do not use player colours, but use historical liveries, and such a feature would be a good way of representing progression through time without doing anything to the economics of the game, and might also enable distinction between different players in paksets without player colours being set.

Quote from:
TheUniqueTiger
James, also please consider displaying line average speed or convoy average speed so that we can make appropriate changes to the network if required. Its already calculated in the game, isn't it? So why not display the same at appropriate place as well... A number of Simutrans features which should provide feedback to player are often hidden.
Thanks.

This has always been displayed: it's the brown graph in the line/convoy information windows.

Quote from:
Sdog
I'm quite unsure about the gradients change you propose. But i have to read this again and think. There's also something fishy with the behaviour of trains for some combinations of gradients and curves, where trains seem to be slowed down more than i would expect. I haven't really tested it yet. Last but not least there might arise some issues related to the ability to change the tiles per km setting in simuconf.tab. This effectively changes the gradient for a fixed elevation height.

I'd be very interested in the results of these tests. The changes to the scale would only affect hill-climbing if the before/after gradient tile distances were defined in kilometres, rather than tiles, whereas I was thinking of implementing it in the same way as with corners, specifying tiles.

Banksie - lots of very interesting information there! There is a limit to how much detail that we can go into, as you appreciate, so the trick is to find the right balance between interesting/important detail and relative simplicity (especially as far as the decisions that the player has to make is concerned and the information presented to the player).

From what I understand from Moblet, it's important that the cost of ways not be constant, but increase over time and that their lifetime is effectively limited. However, your figures for renewal/upgrading are very helpful indeed, and this would be a very straightforward feature to implement.

Offline TheUniqueTiger

  • *
  • Posts: 78
    • HiFiBB ... Simply HiFi!
Re: Next steps for Experimental
« Reply #11 on: February 10, 2011, 05:52:35 AM »
I'd be interested in seeing the revenue/profit for each goods type. For example, if my total 'proceeds' is 1 million, I would want to know what is the share of passenger/coal/oil etc etc. Probably a goods-wise breakdown of the finances. Just a suggestion...

Offline wlindley us

  • Devotee
  • *
  • Posts: 960
    • Hacking for fun and profit since 1977
  • Languages: EN, DE
Re: Next steps for Experimental
« Reply #12 on: February 10, 2011, 01:39:26 PM »
If the "Allies and Competitors" suggestion would turn Simutrans into an MMO game, then some wonderful detailed revenue and expense reports, which I would love, would turn it into the world's premier FPA (first person shooter^H^H^H^H^H accountant) game in the DBS (death by spreadsheet) genre.  Support!

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Next steps for Experimental
« Reply #13 on: February 10, 2011, 11:38:04 PM »
I'd be interested in seeing the revenue/profit for each goods type. For example, if my total 'proceeds' is 1 million, I would want to know what is the share of passenger/coal/oil etc etc. Probably a goods-wise breakdown of the finances. Just a suggestion...

This might be something worthwhile suggesting for Standard.

Offline jk271

  • *
  • Posts: 292
  • Languages: CZ, EN, DE
Re: Next steps for Experimental
« Reply #14 on: February 15, 2011, 07:26:26 PM »
I'd be interested in seeing the revenue/profit for each goods type. For example, if my total 'proceeds' is 1 million, I would want to know what is the share of passenger/coal/oil etc etc. Probably a goods-wise breakdown of the finances. Just a suggestion...

I think it's good idea. I had been thinking about something similar. I suggest make "Finances" window having more tabs (similar to line management window). New tabs would have: "proceeds", "operational costs", "maintenance", and "operational profit" differentiated by type of transport: monorail, train, tram, truck, ship, airplanes and powelines (powerlines not in operational costs). I would include powerlines too, because it is hard to find out it's maintenance.

I am operating several tram lines (among other) and i can not simply find out if they are generating profit or loss. (Lines are in black but i don't know total tram rail maintenance.)

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Next steps for Experimental
« Reply #15 on: February 28, 2011, 01:11:03 AM »
I'd be interested in any comments on the latest additions to the above list, the reduced way upgrading costs/mothballing in particular (as the industry productivity issue has already been discussed elsewhere, although I don't discourage any further comment on that issue that anybody would like to make).

Offline TheUniqueTiger

  • *
  • Posts: 78
    • HiFiBB ... Simply HiFi!
Re: Next steps for Experimental
« Reply #16 on: February 28, 2011, 01:57:57 PM »
This might be something worthwhile suggesting for Standard.
Thanks, posting in Extension Requests for standard.

Offline neroden

  • Devotees (Inactive)
  • *
  • Posts: 831
  • Nathanael Nerode
Re: Next steps for Experimental
« Reply #17 on: March 06, 2011, 05:19:55 AM »
OK, here's a problem you probably haven't thought of: the code for adjusting things for the map scale (km per tile) is a bit screwy.  I encountered this during my work trying to get actual trip times measured.  There's something very confusing in the way distances and times are computed.  

From what I can tell from the code:
- A vehicle going the x tiles and taking a time of y ticks to do so is always displayed as going at the same number of km/hr, regardless of the tile scale
- However, the number of minutes it is claimed to have gone is adjusted by the tile scale....

This just isn't right.  Experimental needs to get its times and distances straightened out.

One of the unfortunate side effects of the way times and distances are handled is that it is completely impossible, due to wild imbalances, to play a pak at a scale other than the one it is intended for.  If we can straighten things out just a little bit more, it should become possible (though suboptimal) to do so.

So I would make it a priority to try to get *everything* associated with this straightened out.

Remember, it's not always about adding more features; often it's about getting existing ones cleaned up.  Unfortunately both Standard and Experimental are badly in need of this at this point.  Case in point: the refunds feature from 7.2 is causing some interference in my attempts to clean up the time and distance code.  I would call for some "retrenching" or simplifying actions at this point, looking for features which were good experiments but which can be simplified now.

EDIT:
I would also request that the changes in my departure_time branch up to revision 6f685f61d2745.... be considered for inclusion in version 10.  The practical effect is a change in the computation of average line speeds to eliminate certain counterintuitive behavior, but it requires a change in the savegame format.   (Subsequent changes I'm trying out ought not require a change in savegame format and therefore you can worry about their inclusion later.)
« Last Edit: March 06, 2011, 05:33:48 AM by neroden »

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Next steps for Experimental
« Reply #18 on: March 08, 2011, 12:23:29 AM »
OK, here's a problem you probably haven't thought of: the code for adjusting things for the map scale (km per tile) is a bit screwy.  I encountered this during my work trying to get actual trip times measured.  There's something very confusing in the way distances and times are computed. 

From what I can tell from the code:
- A vehicle going the x tiles and taking a time of y ticks to do so is always displayed as going at the same number of km/hr, regardless of the tile scale
- However, the number of minutes it is claimed to have gone is adjusted by the tile scale....

This just isn't right.  Experimental needs to get its times and distances straightened out.

Hmm, is this necessarily wrong? This was intended, as I did not want to alter the movement code, as it has been set to look right for the scale of the vehicles themselves (which, of course, does not change). If one is changing the distances, then, to compensate, changing the time will have the same mathematical effect as changing the speed, will it not?


Quote
One of the unfortunate side effects of the way times and distances are handled is that it is completely impossible, due to wild imbalances, to play a pak at a scale other than the one it is intended for.  If we can straighten things out just a little bit more, it should become possible (though suboptimal) to do so.

So I would make it a priority to try to get *everything* associated with this straightened out.

Did you have anything in particular in mind as to what this might entail?

Quote
Remember, it's not always about adding more features; often it's about getting existing ones cleaned up.  Unfortunately both Standard and Experimental are badly in need of this at this point.  Case in point: the refunds feature from 7.2 is causing some interference in my attempts to clean up the time and distance code.  I would call for some "retrenching" or simplifying actions at this point, looking for features which were good experiments but which can be simplified now.

What difficulties is the refunds feature causing?

Quote
EDIT:
I would also request that the changes in my departure_time branch up to revision 6f685f61d2745.... be considered for inclusion in version 10.  The practical effect is a change in the computation of average line speeds to eliminate certain counterintuitive behavior, but it requires a change in the savegame format.   (Subsequent changes I'm trying out ought not require a change in savegame format and therefore you can worry about their inclusion later.)

I'll respond to this issue in its own thread, when I get the time, as this raises some quite complicated issues which need very careful consideration.

Thank you very much for all your efforts both in coding and in contributing to the discussion about the direction of Simutrans-Experimental - they are much appreciated.

Offline neroden

  • Devotees (Inactive)
  • *
  • Posts: 831
  • Nathanael Nerode
Re: Next steps for Experimental
« Reply #19 on: March 08, 2011, 08:18:16 AM »
Hmm, is this necessarily wrong? This was intended, as I did not want to alter the movement code, as it has been set to look right for the scale of the vehicles themselves (which, of course, does not change). If one is changing the distances, then, to compensate, changing the time will have the same mathematical effect as changing the speed, will it not?

No, it does not.  :-)  Among other things, I think it's going to make reported acceleration come out wrong (to avoid this you need to do an adjustment determined by the derivative using the chain rule...).  More importantly, it screws up the relationship between waiting time and travelling time -- unless waiting time is *also* multiplied by the tile scale, which is a really ugly way to do it.  The same applies to factory production!  You end up having to adjust *all* time conversions by the tile scale.  I suppose you *can* do this, but it's not a sensible way to do things...

If you're trying to get the same "visual speed" displayed as the same "km/h" speed, regardless of scale, I think that's an erroneous choice.  The player can pick the game speed in any case, and I certainly don't think the horses "look" particularly distinctively 4 km/h at the graphical scale used.

I think it would make more sense to convert the numbers for display in a rational fashion.

The movement code should not need to be meaningfully altered -- it's all in tiles per tick, which are cleanly converted from km/h at runtime  -- but the data reporting code ought to be straightened out.  Paksets are already specific to a specific number of tiles per km, so this shouldn't meaningfully affect behavior; doing the conversions correctly would actually make them *less* tied to this, for the reasons given above.

EDIT: But then I didn't think it made sense to rotate the world instead of merely rotating the view of the world when rotating the map, so apparently there's a tradition of doing things in the more convoluted and hard-to-maintain way in simutrans....

Quote
What difficulties is the refunds feature causing?

Nothing serious, it's just complicating the code.  Some things need to be measured when doing refunds, some things need to not be measured.  I'm trying to avoid duplicating code, and it keeps wanting to be duplicated in the refunds block and the non-refunds block.  So far I've managed to avoid doing so....

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Next steps for Experimental
« Reply #20 on: March 08, 2011, 11:51:53 PM »
The waiting time is varied with the distance scale, and I think that Bernd Gabriel adjusted for this in his physics code that gives the report of the acceleration (or, rather, adjusted the actual acceleration to match the scale). How/why does factory production need to be adjusted according to the scale? Players can't pick the game speed in a network game, and there is quite a clear default otherwise. On the basis of the above, I'm really not convinced that this needs changing, unless I've missed something...?

Offline neroden

  • Devotees (Inactive)
  • *
  • Posts: 831
  • Nathanael Nerode
Re: Next steps for Experimental
« Reply #21 on: March 09, 2011, 04:07:52 AM »
The waiting time is varied with the distance scale, and I think that Bernd Gabriel adjusted for this in his physics code that gives the report of the acceleration (or, rather, adjusted the actual acceleration to match the scale). How/why does factory production need to be adjusted according to the scale?

Necessary for game balance if you ever want to change tile scale on a pak.  Factory production rate is based in months, so as related to the movement of vehicles, it effectively alters according to the distance scale.

Look, you CAN do this the stupid way, and yes I am going to call it that.  But it's like rotating the world instead of rotating the view of the world, or like any number of the confounding unit mixups embedded into simutrans (which I've been trying to clean up), or like the duplication of the projection code in multiple different places, or like translating the code from German incrementally -- *it makes it much harder to maintain later*.  Everything involving time needs to be adjusted instead of only ONE thing related to distance.  I'm a big believer in elegant clean code, and this is the opposite of that.

There may even be subtler problems I've missed, because time is all over the code.  *Every* use of time, speed, or acceleration requires an adjustment if you do it this way.  Past, present, and future.  Acceleration requires adjustment by the square of the time adjustment if I'm remembering correctly.

This is just bad coding.

Offline wlindley us

  • Devotee
  • *
  • Posts: 960
    • Hacking for fun and profit since 1977
  • Languages: EN, DE
Re: Next steps for Experimental
« Reply #22 on: March 09, 2011, 01:05:26 PM »
Half the battle of changing anything, whether it's core or a pak, is the Berlin Wall that surrounds write-access to the source repository.  If I wanted to change a few hundred German words to English ones, how could I do that, without a branch in svn? Without write-access, one of the core developers has to re-do half my work. Same thing with making pak128.Britain consistent in putting all images in an images/ directory instead of mixed with the .dat's.

Give us write-access to create personal branches of the svn and we can all work on these things.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9438
  • Languages: De,EN,JP
Re: Next steps for Experimental
« Reply #23 on: March 09, 2011, 02:12:02 PM »
For translation there is simutranslator. Even experimental has its own section there.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Next steps for Experimental
« Reply #24 on: March 09, 2011, 11:56:07 PM »
Neroden,

The reason that it was done in this way was because, when I was first coding Experimental, the code for setting the convoy speed was already present and working, and I did not want to interfere with it, but there was no code for setting journey times, so I coded my new part to fit around what was already present to be as conservative as possible. What exactly had you envisaged as a replacement for the current system?

WLindley,

Experimental uses Git for exactly that reason.

Offline neroden

  • Devotees (Inactive)
  • *
  • Posts: 831
  • Nathanael Nerode
Re: Next steps for Experimental
« Reply #25 on: March 10, 2011, 03:19:54 AM »
Neroden,

The reason that it was done in this way was because, when I was first coding Experimental, the code for setting the convoy speed was already present and working, and I did not want to interfere with it, but there was no code for setting journey times, so I coded my new part to fit around what was already present to be as conservative as possible. What exactly had you envisaged as a replacement for the current system?
At this point, it might be easiest to explain if I simply coded it.  As usual, it's another "not meant to cause major behavior changes" patch, being code cleanup.  I'll get back to you when I code it -- it's no hurry, as the code changes shouldn't be "fighting" with anything else you're planning to do, so far.

I've got more stuff I want to clean up in standard first, though; I want to try to get back to all the patches I've already written which are waiting for revision, and/or waiting for prissi's approval and checkin to svn.  Code cleanup, mostly.

I just prefer clean code.  I know getting projects started requires coding quick-and-dirty, but now is the time to clean up the code base.  (If I can get through the patches I already have in the queue for standard, I'm going to try to see if I can pull the duplicated overtaking code out into a single superclass, and I'm going to see what else I can move around to avoid duplication of algorithms and formulas without sacrificing game speed.)

Quote
WLindley,

Experimental uses Git for exactly that reason.
I've been loving git since James introduced me to it.  :-)

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Next steps for Experimental
« Reply #26 on: March 10, 2011, 10:02:51 AM »
I shall be interested to see what you come up with, in that case! Some careful testing will be required, I think, but we should be able to manage that. How will it affect existing pakset balance, do you think?

As to overtaking, that code might need some enhancement (stationary traffic is never overtaken, for example, so motorways/dual carriageways are not much use), but perhaps that's a different project.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Next steps for Experimental
« Reply #27 on: July 04, 2011, 10:54:19 PM »
I have updated this topic to take into account the features outlined above that have been implemented so far.

Offline neroden

  • Devotees (Inactive)
  • *
  • Posts: 831
  • Nathanael Nerode
Re: Next steps for Experimental
« Reply #28 on: September 15, 2011, 03:19:51 AM »
For reference, it took me months to get the first time/distance cleanup patch into standard.  Months.  Much more cleanup is needed. 

In the meantime, the single most useful thing James could do would be to stop putting arbitrary constant multipliers in the code.  Stuff like this should *never ever exist in any computer program*:

const sint32 average_speed = (journey_distance_meters * 3) / (journey_time * 5);

This atrocity was encountered during my attempt to update my departure_time branch (which actually *removes* code while improving behavior).

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9438
  • Languages: De,EN,JP
Re: Next steps for Experimental
« Reply #29 on: September 15, 2011, 09:11:57 PM »
Short offtopic remark to overtaking loading vehicles: That has been done for standard lately.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Next steps for Experimental
« Reply #30 on: September 16, 2011, 10:57:03 PM »
And a great step forward that that is, too! And I take the point about the coding convention - I shall try to use a standardised conversion method for that sort of thing when implemented in the future.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Next steps for Experimental
« Reply #31 on: October 07, 2011, 01:32:09 AM »
See now here for a list of the projects currently planned for Experimental: if anyone would like to assist with any of those projects, please let me know by posting in that thread.