-
Ok since we need to get started somewhere, somewhen and somehow...
... I decided that "right here", "right now" and "whatever comes out of this" are the best answers to these questions. ;)
Now, the old system was very, very complex - as even things like tractive power and speedbonus were core items of the basic calculations. With the new, table-based speed bonus system, I hope we can get things easier than this.
...
BRAIN STORMING:
So for the beginning we will ignore all these special & complex things like bonuses, etc. and just do it simple.
Step 1: Calculate the max. income (vehicle fully loaded) per km(=tile) a vehicle can generate (according to the freight-types transport fee from the goods definition).
Step 2a: Calculate a balanced RunningCost for that. I think other paks do it this way, so might also try it: we could figure out a load percentage that marks the point above which a vehicle will be profitable (or will generate losses if below that).
Of course we have to consider the fact that most freight vehicles will drive empty on 50% of the way, while passenger and mail usually carry loads both ways.
Step 2b:
We also have to include some margin in 2a that will be able to pay all the required infrastructure (like roads, tracks, catenaries, bridges, tunnels, stations, etc.)
Step 3:
Purchasing price... I think that one is actually quite freely adjustable, but we could develop some kind of "guide line" balanced on net income of each vehicle - i.e. determining "how long" it should take until a vehicle pays itself from its own net income.
Open problems so far:
- solution for vehicles that only pull others but have no payload themselves (loco's, trucks)
- implementation of speed bonus
- ... probably several more - but I'm not going to do this all alone. ;)
So, now... YOUR ideas, comments and solutions are required...
EDIT:
I had another look at the old Excel sheet - and it seems that load percentages were also used as reference in pak128 (Pass. 75% and freight 48%). And I got quite a number of ideas from it - let's see how many I can get to work in my version. ;)
-
So, first - about trains. Calculate whole convoi of one loco and say six wagons. Take wagon prices and rc's as fixed, then substract from the resulting number -> the rest must go to the loco. Obviously wagon<<locomotive must be true in both aspects.
Second, I wouldn't remove at least speed. Speedbonus directly affects revenues, and thus the whole calculation. You can't drop it completely. Also with power value increases - at least for trains this holds absolutely true.
-
I've started with the easiest: EMU's/DMU's. ;) I'll have a look at conventional trainsets later.
Trying to orient myself on how Napik did things in his Excel sheet - starting with the simple functions and getting into the more complex stuff later.
Now, speed bonus...
The problem with speed bonus, is that it is just a bonus. So we should make sure that vehicles can generate profits even when they do not get this bonus...or not? If we do that, then vehicles which qualify for the bonus, will simply receive some %'s more money. If we require the bonus for being able to make money at all, that's... well that's not what I'd like speed bonus to be, if I'm honest. And that's going to be much more complicated as well.
-
That makes sense. Now that it does not have to be "loopbacked" with the other values, it should be actually possible to make it a true bonus, not some degenerated threshold.
So, the task is easier...
Err, does it act always strictly as a bonus? I think not. ****.
-
All I can say is: we need to get things much more simple than what napik did. Even on the "Waggons" sheet (that's not even using the macro!) there are so many calculatons and references between dozens of cells...
I don't think I will ever understand it all, unless I do a printout for every cell... ???
So let's just hope we can manage to get things easier... :-\
-
With speed bonus read from external table, you can easily skip hundreds of calculations required to determine it from available vehicles…
The main problem with spreadsheet "programming" is that you have very limited capabilities for actual computing. You can't expand the code beyond that boundary no matter what...
-
What about having classes for different types of vehicle, so older vehicles should be have a lower purchasing price, but much higher running cost and the opposite for newer, plus maybe a 30-50+ % profit margin for the back trip and new investments.
Maybe limit small planes form flying longer distances or by making them expensive on longer routes.
-
@VS:
Yes, but speed bonus is not all that makes Napik's Excel sheet complex. There are quite a few other factors that are also used for calculations - and it's almost impossible for me to sort it all out.
By the way, Frank gave me his balancing sheet for pak.german - I hope that will be easier. ;)
---
What about having classes for different types of vehicle, so older vehicles should be have a lower purchasing price, but much higher running cost and the opposite for newer,
If that is wanted, it could be done after all other calculations are finished. After all it's just multiplying cost / running cost by some factor that depends on the intro_year. Shouldn't be too difficult - question is do we want that? But even so - that's of no relevance
yet.
Maybe limit small planes form flying longer distances or by making them expensive on longer routes.
That's impossible to do in a pak set. To get that working, simutrans code would need to be changed - and that
a) belongs into another forum section
and
b) requires other people to do.
-
By the way, Frank gave me his balancing sheet for pak.german - I hope that will be easier. ;)
Sounds good.
-
Some ideas (just ideas, no implementation):
I think locos running cost should have a relation with its power and speed (as they can't be directly tuned to goods capacity); maybe not a full dependance, but a percentage would be fine.
For purchasing prices, I would take as reference some "medium" benefit or "typical" benefit and calculate then a number of years to get it paid back (f.i., 6 years for bus/truc, 10 years for locos, 15 for planes/ships).
I can help on excel formulas & tests, lists and other similar stuff. On-game testing would be harder for me :P
-
Some ideas (just ideas, no implementation):
I think locos running cost should have a relation with its power and speed (as they can't be directly tuned to goods capacity); maybe not a full dependance, but a percentage would be fine.
For purchasing prices, I would take as reference some "medium" benefit or "typical" benefit and calculate then a number of years to get it paid back (f.i., 6 years for bus/truc, 10 years for locos, 15 for planes/ships).
I can help on excel formulas & tests, lists and other similar stuff. On-game testing would be harder for me :P
I like that,
Pay back is a flawed model, NPV would be much better, so if its a positive value you should buy that thing negative buy some other.
Formula is CF/(1+i)^t i=15 % (interest) and t=time CF= cash flow and the first cf is the purchasing price.
-
@Zeno:
The difficulty is that both, a vehicle's income and running costs are based on distance - not time. And in-game speed is not directly related to any tile/min rate. (IIRC Hajo just had a certain animation speed, watched in on screen and then decided "that looks like xxx km/h") So it's not easy to calculate a typical benefit over any amount of time... We'd need a tiles/sec or tiles/min rate for any given speed (the factor beween real time and ST time can be calculated). There is some value for that in Napik's sheet, too - but I'm not sure if it's correct (any more).
Now, don't get me wrong: the general idea isn't difficult to implement - I think I already did that. It is just that I used some "artificial" factor that is not really connected to a specific amount of time, just something that produced about the same price as the old system (taking vehicle speed into account) - but I have no idea how many months/years of time in ST that number corresponds to at the moment. But fortunately, changing a fixed number to a formula (once we have it) is no problem at all in Excel. ;)
@arianen:
We are trying to get this system as simple as possible, not as realistic as possible. And when I look at your proposal, I looks just the opposite to me.
-
@arianen:
We are trying to get this system as simple as possible, not as realistic as possible. And when I look at your proposal, I looks just the opposite to me.
Payback Period = A+(B/C)
A = Years before final payback year
B = Total to be paid back
C = Total Paid back at the end of final payback year.
Is just as simple in my eyes :D
How about average speed form the speedometer, that would be easy to calculate
-
Err, does it act always strictly as a bonus? I think not. ****.
Actually I just found out that it works a bit different from what I thought.
Apparently speed bonus works like this:
You have a given speed for a year - let's say e.g. 100km/h. If a vehicle has speed=100, it gets exactly the amount of money defined in the goods files (e.g. 0.05 cr / km / passenger). (In reality it's just 0.04666... but let's make it easier by assuming that it's exactly 0.05).
For
every km/h more (or less) than that, 1/10 from the given speed-bonus % is added (or subtracted) from that (e.g. 18%/10=1.8%) - so if your vehicle has a speed of 200km/h (=100 above bonus speed) it gets 0.05+(100*0.05*0.018)=0.14 cr / km / passenger, or if has only speed=50 (50 less than bonus speed) it gets 0.05-(50*0,05*0.018)=0.005 cr / km / passenger.
So, unlike I thought, it must already be included in the basic calculations.
-
The difficulty is that both, a vehicle's income and running costs are based on distance - not time.
Maybe we could base it in a couple or three parameters not calculated but really tested and extract a medium value. Let me explain. For instance, we could calculate fore each loco how much income do they produce transporting a "standard" product (maybe books or canned food) across 30 sqares with 4 wagons; then repeat with 8 wagons; maybe repeat with cheapest and most expensive goods; then extract a medium value.
I think we won't need a *real* medium profit, but a value representing the ability of each loco to make money. And it's as simple as test & write down :D
-
I've got some ideas for locos RC calculation, at least usable for pulling locos (no cargo). I've been thinking of factors which can make a running cost increase or decrease, and I get to these ones: power, speed and type (electric,steam...). I thought about calculating RC with these values, and leave other factors to the purchase price. So I played a little with some numbers, and got some formulas:
RC = POWER * GEAR / SPEED / 2 is giving me "reasonable" numbers (2 to 10 most, 10-16 some, +16 a couple).
It's soooo easy to calculate :D
I can think of two coeficients to apply:
1) Multiply result by a bonus-speed coef (vehicle speed vs. bonus speed of launch year in %)
2) Multiply result by a bonus-power coef (vehicle power vs. power "normal" value of launch year in %)
We could use these coeficients to calibrate a little more the values. Also comment that we could apply to all locos, and then charge to locos which can carry goods by themselves to the purchase price.
Edit (1): I forgot to introduce WEIGHT in the formula... it should be dividing the result... I'll gonna play a little more with numbers ;D
Edit (2): Following this way of thinking/calculate, a "constant" could be invented for each cargo type, and used to calculate all vehicle RCs using an expression like VEHICLE_TYPE_RC + CARGO_RC, calculating the vehicle RC using only its physical parameters, and adding aditional RC value for the cargo it carries using capacity, type... ::)
-
Did you look at the excel sheet for pak64 in the sourceforge SVN. That is like I did rebalance pak64 ...
-
Did you look at the excel sheet for pak64 in the sourceforge SVN. That is like I did rebalance pak64 ...
No, I was looking/using the old excel from pak128... but I think your name appears somewhere in it anyway ;)
I'll take a look to that excel from SVN, thanks!
-
@Zeno ... so at the moment you are the person, how make a rebalance?
-
Can't find the excel that prissi talks about... anyone knows where to find it? ???
Edit:
Found something... cars.xls into vehicle folder! :P
Edit2:
@prissi: I don't know how much I really understand of it, but it seems to be a similar calculation to mine... I think you used a typical cargo to calculate revenue, while I proposed to use a constant to simulate that itself (which actually is getting to the same thing).
-
@Zeno ... so at the moment you are the person, how make a rebalance?
Mmmm... actually I don't know exactly what are you asking :P
But anyway, IMHO we should decide which are our objectives:
- balance vehicle data?
- improve playability?
- develop an easy way to get vehicle params?
- make a guide on how to create vehicles so they can fit into simutrans engine?
- all of the previous options?
Then decide how to deal with the problem in a simple way, and develop it till we decide is enough.
Edit: Is goods pricing pak-dependant? And if yes,
pak128 pricing & balancing includes goods income balancing?
-
First, a way to calculate something must be created, implemented and documented.
Then use that to balance 128 - specifically vehicle data and goods (if needed) but maybe also industries.
-
First, a way to calculate something must be created, implemented and documented.
IMHO, a vehicle's running cost should not depend on its cargo type or capacity, but its physical values (vehicle type, engine type, weight, power, speed...); another thing is if this way of thinking can (or should) be applied to simutrans, or not.
Anyway I think that should be the way to calculate engine's RC, just using physical parameters, and make it as easy as possible.
-
So far three people expressed some kind of interest: DirrrtyDirk, Zeno and wernieman.
It's up to you three to come up with something. If you let me do it, I would probably make some horrible program in Python :D
-
Sorry, at the moment I look to cross-compiling to mac......
-
Well, first of all I'd like to say I prefer to spend my time on doing this than in making addons, as long as I consider this much more important. So, what about designing a
route planning for this?
I would say first we need to decide which parameters will be involved in the balancing, and what do they affect to.
Just to begin somewhere, I think we should consider we
may change this three things: vehicle purchase prices & RCs, infrastructure prices & mantainence and goods incomes. Do you agree? Do you want to add something to this list?
Next step could be deciding which game parameters should be involved in each point, and maybe its relevance.
It's up to you three to come up with something.
Well, I guess you should get involved a lot in this, not necessary working on it directly but giving advice at least. Also advice from prissi would be important, as an expert, as he has done this for pak64!
-
Well, I used nearly the same system as you (as you find out) with the aim to get nearly the same income per ton (including the car) of goods transported. I also include the speedbonus for passenger engines, and thus I calculate two values: The income at the start and the end of an epoch. Thus for every engine I can calculate how many cars (and estimate and income at introduction and retirement) and then use about 10% of this income as running cost (for land engines, for ships it would be 45% and for airplanes 70%).
The price I just handwaving guess form power and epoch.
-
So, I think I could resume this way of calc like: Running Cost = XX% * Medium(ExpectedYearlyIncomes).
YearIncomes are calculated for intro and retire dates, based on speed, weight, power & cargo capacity (estimated for trucks & engines). Also for this we need the year calculation, based on some space-time calculations using some constants like squares/sec and stuff like that (we'll define later on).
Everyone agrees on calculating RC based on a predefined percent of the expected income? I do agree. OPINIONS REQUIRED!!! :police:
For price we can use additional ideas like payback time, as well as power and epoch, and mix them as percents or additive coeficients.
-
I'd say only the financial aspects should be changed freely, the other parameters are mostly good already.
This I'll admit I didn't think about, but makes good sense:
the same income per ton
About RC, I was thinking more or less the same - except there should be a check if the vehicle is still profitable at end of its lifetime. When is the end? Dunno. Maybe retire date + constant - 10 years for RVs, 20 (15?) trains and planes, 30 for ships…
-
I'd say only the financial aspects should be changed freely, the other parameters are mostly good already.
We may change only vehicle's running costs now, without considering other pricing/costs as far as we can. We might consider, but, electric locos should (must?) have a RC lowering factor due to line mantainance.
... same income per ton ...
I also think getting a similar income/ton is interesting. I assume you meant same income per ton including running cost. Didn't you? Also another question for you: did you consider half-way-full plus half-way-empty, or X% of cargo loaded, or you assume train always is full of cargo for calculation?
-
If somebody whant to balance the full PAK ... then it is a good idea..
At my last playing, I see the big problems im balancing street (busses, trucks) and train.. so this is a good think to resolve first ...
-
I have been looking to an excel file that was used some time ago (I think T.Kubes did it). It was looked time ago, but as it's quite complex, interest on it was gone. Now, with our last comments and ideas, I'm back to that excel, and I've understood many things I didn't in the past, and I think they could be a good reference for us now.
I've only left the necessary parts for locos (I've deleted trucks, buses, trams and so); there is a 'engine' sheet where all data of locos should be entered and then calculations are made over its data. I've writed down some comments on the formulas (see numbers above column headers, and annotations made after all data, aroud row 200 or so). I've tried to explane a little what I think is pretended to calculate with the formula, and how is it done.
There are other sheets where constants, goods, bonuses and other calculations are made (or just there is raw data on it). They help making some calculations on the engines sheet.
I hope it's a good reference, and even a good template to work in it (we could just simplify it, or just tune up the parts we think we have to and document it for further use). Whatever you think IMHO is good at least to take a look on it, and to get some ideas from :)
Let me know your opinion on it!
-
The Napik Excel sheet puts most emphasis on the buying price and less on the running cost, if I remebered it correctly. As a reuslt thing were quite cheap and running cost were also relatively low, compared to pak64 "reloaded".
-
Yes, prissi. I think you're right, cause used to play pak128, pak64 running costs look to me as huge as purchasing costs too low :D
But I think that's more a general thinking problem than a mathematical one...
-
Well, the Napik was done assuming five years to pay back for everything. This was of course five years on the old system. With the slower default flow of time, this is just one year three months. Most company would like such a high revenue ...
-
Well, the Napik was done assuming five years to pay back for everything.
That's only a decision we've got to take. I think at the moment the excel has ten years for locos...
With the slower default flow of time, this is just one year three months.
Slower flow? Has the game engine time flow changed? I mean, I know of the bits per month parameter that regulates the real play time, but has anything else been changed in the engine to alter time flow?? So 0,0113 squares/second is still valid using 19 bits per month or not? :-[
-
Yes, but the distance covered per year is now four (or eight) time larger => faster return of investment.
-
Yes, but the distance covered per year is now four (or eight) time larger => faster return of investment.
Four(eight) times bigger...?? I'm afraid I don't understand why at all :'(
In the excel it's been calculated as 0,0113 sqares/second x 260 seconds/month x 12 months/year ... If 0,0113 is valid, and I hope a year still has 12 months!! So, it only remains 260 seconds/month (it's been used in the excel as DayLength, but I think it's wrong as later it uses DaysInYear=12); Anyway it's not explained anywhere. So I guess a month
now isn't 260 real seconds, is it?
Edit: Arrrrg!!! I hadn't noticed!! Four times more distance covered per year means much lower RC!!! :o Errr... won't really affect, I see :P
Edit2: Is that (4x/8x) true for current stable (r1867), or is a new (nightly) implementation??
-
x4/x8 is probably the change in bits_per_month from hard-coded to the new default values (depending on pak) configurable in simuconf.tab
-
x4/x8 is probably the change in bits_per_month from hard-coded to the new default values (depending on pak) configurable in simuconf.tab
Then the excel sheet might be correct, as it's written "19 bits/month", as in the default simuconf.tab... But 19bits/month means 2^19=524 seconds per month, not 260 ???
-
262 would be 18 bits per month - and I think that was the hard-coded entry. So maybe the numbers are still from 18, and just the text has changed to 19...?
-
262 would be 18 bits per month - and I think that was the hard-coded entry. So maybe the numbers are still from 18, and just the text has changed to 19...?
Mmm... might be. Anyway, some calculations are not based in distance (as average car/wagon income), and changing this value in the excel sheet makes things weird; i guess because of raw data used (saved data). It will need some update ;)
-
I know. I've had Napik's Excel sheet for quite a while... ;)
-
I know. I've had Napik's Excel sheet for quite a while... ;)
Actually I think one of the problems to solve is the average income of a wagon/car is pre-calculated, "raw" saved data. I think is a good way to use prissi's way of thinking on this: first get an average revenue per ton and km and then apply it to driven distance to get the expected yearly revenue.
-
Go ahead - as long as it works, pretty much everything is acceptable!
-
Can anyone please tell me how to apply bonus levels? I wish to know how to convert the difference of speeds (vehicle_speed-bonus_speed) to the number of levels it represents. I guess if level of bonus is 3 then is applied the bonus 3 times... am I right? Or maybe is applied bonus*3?
-
Well, not sure what you want. The money you get is:
revenue*(1+((100*v_max)/v_speedbonus-100)*bonus_faktor/1000)
v_max is the convoi top speed
v_speedbonus the current speed according to speedbonus.tab (or the average speed of all engines of this category)
bonus_faktor is between 0 and 18 in pak64, pak128 may differ ...
-
Between 0 and 18 is true for pak128 also.
And about how the numbers work - look a little earlier in this thread: http://forum.simutrans.com/index.php?topic=584.msg4852#msg4852
-
revenue*(1+((100*v_max)/v_speedbonus-100)*bonus_faktor/1000)
Uh... seems quite easy... ::)
And about how the numbers work - look a little earlier in this thread: http://forum.simutrans.com/index.php?topic=584.msg4852#msg4852
Ups. Sorry for not searching before ask... :-[
Btw, I'll take a look... I think I'll have some nice calcs soon :)
-
If you look in cars.xls from pak64, there is already the formula used in the income column ...
-
If you look in cars.xls from pak64, there is already the formula used in the income column ...
Thanks, moreover it's also in this excel (somewhere in goods or bonus sheet).
I've been doing a little remake of the excel... but I get revenues much higher than before... I must have made a mistake somewhere...
Anyway, I attach the current xls here (I've deleted it from previous post).
Edit: Actually, now revenues are more credible... they're more like 50 thousand cr/year or 120 thousand cr/year and so. Before they were like five thousand or so! But I get terribly higher RCs (if compared to previous). I think they wouldn't fit at all in ST. But I can't see what can be the causes to this :-\
If you could take a look, I've updated some explanations to keep it as easy as I could. Also remade the macro so ef speed is calculated a lot faster.
Updated xls.
-
Well, taking into account that vehicles do not run always in straight lines, need more time than possible with max speed and are not always 100% filled, I used 10% of the maximum revenue for running cost for pak64. Maybe this would give sensible results too?
-
So you suggest to use 10% of theorical revenue? I saw in this sheet was established a "efficiency" percentage, 75% for pass and 48% for cargo (75% loaded passenger in both runs; 95% loaded cargo in 1 run, empty on return = 48%). I think it's the same concept, but maybe you used a lower value.
Actually, I get much more logical values for RC if I take 25% of income instead of 100%.
Moreover, I've also introduced a new factor: bonus percentage applied. I think I can calculate the revenue using half (f.i.) of the possible bonus (maybe 75% or other value), as trains might not recieve always the maximum bonus value... ::)
Edit: Added updated xls.
-
Well, now the excel file looks quite nice. I managed to get new values with deviations between 25-30% vs old ones. I've added a couple of new things to the sheet: (In red background) at the begining of the sheet, there are two factors affecting ALL values of the locos, which are bonus and pricing percentage used to calculate RCs; also the average deviation for the whole pak (only locos).
This two factors, are simple: how much of theoric max. revenue and bonus are used to get RC value. Using 12% of the max revenue and around 40% I get quite low global deviation, which means I don't get too away from what it is right now, while I keep % of max revenue near reasonable values (prissi says he used 10% for pak64).
Note the deviation is in absolute value, so it's not a deviation from medium value but measures just deviation importance. The good thing is that the values are now calculated the same way for all locos in the pak, so they should be balanced. I think now it's just a matter of testing in-game and correcting (if needed).
Now the purchase prices bother me, because I used 5 years payback to calculate it, but I *really* think 10 or even more years should be a more realistic value (despite being conscious it will be really hard to start a game with current values if vehicle's prices are two or three times higher). I place you to discuss also this; what do you think of increasing a bit vechicles purchase pricing, and also starting money for the player to compensate this?
I leave the last version of the sheet for you to take a look.
-
Well done. I had a look at the loco purchasing prices and computed them using your Excel file for 10 year payback. In my opinion - and with the playing experience of the current pak128 - the prices are reasonable (I do not know however how significantly the profits changed from old to new system). We might need to adjust the starting capital to account for higher vehicle prices, but not too much - it seems to me that 500 thousands instead of 300 thousands should be more than enough.
The question is, of course, what about the purchasing price of wagons - should it also use in future 10 year payback? It looks sensible.
-
This is starting to look good! Thanks!
What will be needed to transform the numbers into reality?
-
What will be needed to transform the numbers into reality?
Mmmm... I'll need all DATs to modify them, and lot of patience I guess... ;D
-
Give me a mail and we make a deal ;o)
-
About the 10%: This I used for engines, for wagon I used 1cr/ton/tile and for trucks 40%, for ships 48-49% and for planes 70% of the theoretical revenue.
-
I haven't read all of the topic so I don't know what are you doing (I tried understand the excel sheet but ...)
I would only know if the prices will increase or decrease ?
-
About the 10%: This I used for engines, for wagon I used 1cr/ton/tile and for trucks 40%, for ships 48-49% and for planes 70% of the theoretical revenue.
Printed! I'll take them as reference values. Actually, I got best results for engines with aprox 10%, so I expect the others will be also quite similar. Thanks a lot prissi.
Btw, I've developed a small tool which I use to massive replace values in DAT files. As I don't know how do you deal with DATs, I can provide the tool to the comunity when finished if you wish so.
Edit:
I haven't read all of the topic so I don't know what are you doing (I tried understand the excel sheet but ...)
I would only know if the prices will increase or decrease ?
Don't get scared! The prices may be rebalanced in near future; some can go up, some down, but not in a
significant amount (20-30% in worst cases). We are trying to establish some basis and rules on how should running costs be calculated for all vehicles.
-
A side note- originally the excel was designed so that you could export the relevant part to csv and load into simutranslator - and vice versa. Now that it is not certain when it finally works 100%, I would really prefer to have this functionality doubled/backed up…
-
A side note- originally the excel was designed so that you could export the relevant part to csv and load into simutranslator - and vice versa. Now that it is not certain when it finally works 100%, I would really prefer to have this functionality doubled/backed up…
Uh? I had no idea about this. Could you please give a little detail of this process of data import/export? Is there a tool already done, or it's done with a script, or...?
-
It's a feature of translator. You can upload a csv file with data for the vehicles. But I don't really know if it works or not, I never used it…
-
It's a feature of translator. You can upload a csv file with data for the vehicles.
Nice! Is there any documentation on file format expected? I mean the columns, order and so...
But I don't really know if it works or not, I never used it…
Uh, oh... ;D
-
Ha, here:
http://translator.simutrans.com/help/object_cvs.htm
-
Nice, it does exacly the same than my tool (with some more fields), and externally looks like using quite similar formats and so... ::)
-
I've newly compiled the vehicles.all.pak with 10% revenue used to calc RC and purchasing costs about 2 or 3 times higher; that might be compensated by using higher player cash.
I think these values will be quite equilibrated, as RCs appear to be a bit lower. I'll test tonight or tomorrow (and probably during the whole week) to play with these values and see what happens. If someone wants to test this beta pak, post here and I may publish it on a web/ftp site (german file hosting could be a good option).
-
Do not try this on the actual translator, as this only operated on pak with internal reference 0, which is now the base translation texts.
-
Do not try this on the actual translator, as this only operated on pak with internal reference 0, which is now the base translation texts.
Ok. I'll keep using my own tool for a while. If ever it's working back, will be nice to have a couple of ways to do it ::)
-
zeno: If you need some help / a second person for testing the new cost structure, let me know - I can test them (now and later versions as well).
-
zeno: If you need some help / a second person for testing the new cost structure, let me know - I can test them (now and later versions as well).
Nice! I'll let you know when I finish with wagons. Then some testing on train routes will be needed.
-
If you have a "beta", we could make a "spezial-nightly-pak128"
-
If you have a "beta", we could make a "spezial-nightly-pak128"
Thanks werner! Later on it can be a good idea, I'll tell you when ready. By now, too much testing needed until an
acceptable version is ready :P
-
P.S. if you need, I could make a spezial SVN .....
This is only a information!
-
P.S. if you need, I could make a spezial SVN .....
Thanks, werner, but IMHO no SVN is needed: the only new thing I manage is the excel sheet, so a special SVN for it I think is too much ;)
By the way, I've got the first "beta" of the pak (actually I only created the vehicles.all.pak), but I don't know wether a special nightly for pak128 is needed. It should be a decision of the PAK admins. It's good to know you can provide the service; and I can provide the
product; so now we know it can be created... It's just a decision matter.
Well, I'll begin to test it as soon as I arrive home!
-
From my side there is absolutely no objection to releasing testing versions.
Maybe making the first results available could provide feedback from the players?
-
if you have make a vehicles.all.pak ... then you cold make it available for player like an alpha-Pak
When a player have:
nightly-simutrans
nightly-PAK128
Your "aplha" PAK
.... The he could give you better feedback :police:
-
Yes, it's a great idea to adquire feedback via users using a nightly.
If you want, I can provide the vehicles.all.pak, or the modified DAT files, or I can try to compile the whole pak...
Tell me the best way and what files should I update... and we'll have a new nightly :D
-
When you only change the vehicle then make only the vehicle.all.pak
When you make bigger changes, then I could make a spezial-nightly-pak ;o)
For an alpha pak it is better to make only parts of the pak, so only better informed user used them.
(I hope nobody misunderstand me)
-
Sorry, I messed up with some things in the last post... I've just deleted and rewritten it :-[
Now I've done first (and second) tests... And here are the results:
- Excel (xlsx) format (http://www.telefonica.net/web2/albertyuste/simutrans_rebalance_comparative.xlsx)
- HTML plain format (http://www.telefonica.net/web2/albertyuste/simutrans_rebalance_comparative.html)
I used a saved game; date was 22nd november 1971 and I used each different compiled pak until reach end of year. First column is end of year train's
benefit with the old pak, and the following are the same with the altered paks (modifications are indicated in column header; 10%income - 55%bonus, 10%income - 100%bonus, and 15%income - 100%bonus).
Conclusions: I don't see a really important changes despite changing the parameters. Really the results are what I expected, but in a very small scale: I thought the impact would be much bigger.
I can see a big change is noticed in car transport. Notice that all tracks for car transport are 110kmh, despite the engine, and they are all using
long car wagon (by Rvg), which have 6 cars capacity and its RC is 0.13cr/km. I'll have to take a look at this (deeply).
Edit: I forgot to say (almost) all goods trains were 8 squares long, 14/15 wagons for cargo.
-
I am sorry I do not understand what is the default in the above tables = what does the first column (acum. year benefit ...) correspond to (to which setting)?
-
NOTE: This concerned version with 10-year-payback prices as opposed to 5-year-payback prices. Clarification will follow.
It seems though that even with the latest (5-year) prices the text below applies.
--------------------------------------------------------------------------------------------------------------------
By the way, I have shortly experimented with the new prices for trains transporting goods (not passangers) in 1930s (one of the typical starting period for a game). In various realistic scenarios for raw materials such as coal, which belong to initially transported goods at the start of a game, and for various steam locs it seems that the vehicles are really paid back by their profits roughly within 10 year provided that (i) a reasonable length of convoys is chosen (not too short = low capacity, not too long = long speed), (ii) the train is on average 50% full, and (iii) train does not stand/wait anywhere too long. On the other hand, it is not too difficult to get some profit with most trains as long as they are operating close to their 50% average capacity and there not many unnecessary maintenance items.
This means that the 10-years return on investment is achieved only at the start of a game only if one is playing wisely, which is OK. On the other hand, setting up a train transport from one factory to another can consume easily 100000-150000 given the higher purchasing costs (depending on the distance etc.). In my opinion, we could thus possibly increase the starting capital to 500000 so that about three train connection (separate or a chain) can be built up in initial years - otherwise, the gameplay could become too boring in the first years. (One can of course argue that cars are preferable at the beginning, but their purchasing prices will probably adjust as well...).
P.S.: I like the new prices also because the ratio purchase / running cost gets a bit more realistic even though they might make the play slightly more difficult at the beginning - but that is something to be decided, that is, how difficult should pak128 be?
-
I am sorry I do not understand what is the default in the above tables = what does the first column (acum. year benefit ...) correspond to (to which setting)?
Well, it has not many sense there; It was originally put there to have a reference, but now it may be nonsense. That column has the values of the vehicle's benefit on 22nd september 1971. It was before changing anything, standard pak128. The following columns are all the benefit at 31st december 1971 with several configurations.
Sorry, I hope you understand now :P
I'm agree with all of your last post, but take care with the payback period; I calculated the price based on a 5 year payback period!
-
Just a quick explanation: I called your previous prices (before re-download) 10-year prices because they resembled those from some earlier Excel. If one replaces in the above posts 10-year by "older version, higher purchase, lower running cost" and 5-year by "the lastest version, lower purchase, higher running cost", it should hopefully clarify it.
Let me also add that higher purchasing price does not necessarily mean tougher game play - purchase is just a lumpsum and after a long time, only running costs and profits determine whether a player makes profit (obvious). So higher running costs are in fact harder to play (provided enough initial capital).
-
I've done another test: this time, I built two transport (coal and waste) with two kristina's + 10 small ore wagons. The results are:
| Year | 1931 | 1932 | 1933 | | Income | 23409,15 | 21486,62 | 22843,82 | | RC | 8044,26 | 7633,77 | 7851,03 | | Mant. | 11116,80 | 11116,80 | 11116,80 | | Benefit | 4248,09 | 2736,05 | 3875,99 | | Payback | 41,79 | 64,88 | 45,80 |
|
So *real* payback periods are quite high I think... :-\
If noone does it before, I'll repeat this test with both the official pak and the modified one; I have no idea of how it was before, but the income trains were gaving seemed *normal* to me: were being paid between 1000 and 1500 cr for a medium run. I'll have to see if costs are also similar than before. But you'll have to wait till next program... ;D
Edit: Some notation for those who are not familiar with these!
Benefit = Income - RC - Benefit
Payback (in years) = 177520 / Benefit
177520 is the total cost of the two trains, 88760 each.
-
That is what I described in my previous post (the one starting with NOTE) - with the new prices, the payback time in real scenarios can be 10 year if everything is done well, which means among else that trains are transporting without much waiting for the goods. In a similar case like you did I managed get profit with coal trains of 12 waggons roughly between 6-8000 without much waiting and the price of tested trains was certainly below 60-80000 with the latest prices. As I wrote you, I will have a more detailed look and report over weekend.
-
To support my claims above and check whether we have similar setups etc., I have done following: run last nightly simutrans + last nightly pak128 with original prices and with your latest prices. The goal was the transport of bulk goods (they pay the least amount per ton and are typically first transported goods) in 1930 with different locos and bulk waggons. Important is that the train was always able to run without any waiting for being loaded 100% (which is not the case if one does not adjust the train capacity to the production). Thus, this is in a sense the optimal case except for maintance - I kept depot etc. unlike AI.
Old prices:
RVG-2-5-1 + 11 JNC_R11 + 8 RVG-2-4-0 + 12
Purchase 31970 20360 48430
Income 29454 19287 33443
RC -9445 -5232 -13049
Maintain -10401 -8421 -10005
Benefit 10795 5633 10388
Payback 2.96 3.61 4.66
Your latest prices:
RVG-2-5-1 + 11 JNC_R11 + 8 RVG-2-4-0 + 12
Purchase 66630 44540 120710
Income 29454 19287 33443
RC -9281 -5155 -12288
Maintain -10401 -8421 -10005
Benefit 9772 5710 11150
Payback 6.81 7.80 10.82
Conclusions:
- new purchasing prices are slightly more than twice higher (this is OK)
- running costs are very similar between both version because RC of locs are a bit smaller and RC of waggons are a bit higher under the new price scheme
- profit is thus approx. equal under both prices, and because of the purchasing price, the payback more than twice the years it used to be (also fine)
- real payback can thus be around 7 year if transport is set up wisely (train runs most of the time, its capacity is appropriate, etc.). In the above example, JNC_R11 accelarates slowly with heavy load, drives less kilometers per year, and thus earns a bit less than RVG-2-5-1. An extreme example is the last column with RVG-2-4-0, where the loc is powerful compared to the other two and can run at more than 100 km/h while waggons allow only 50 km/h - this expensive loc is not a good choice here and one sees it on the payback.
Hence, I think that paybacks around 7 years are feasible under your prices, which is fine with me. Moreover, you achieve this fast payback only with a good choice of transport chain (size of perrons, locs, number of waggons, ...), which is also good.
Finally, the only real change seems to be (at least for the waggons / locs i have checked so far) mainly the purchasing price as running cost etc. are approximately equal. The 2-3 times higher prices thus means 2-3 times higher payback time and nothing else compared to the original prices in the pak128 nightlies.
-----
Additional illustration (approximate, not precise) for a small slow loc with just 4 wagons, but maintanance cost kept to the minimum for such a small train. The results are the same as above and real 7 years payback is achieved
Old prices:
1Dampflokomotive + 4
Purchase 9380
Income 8761
RC -2541
Maintain -3370
Benefit 2760
Payback 3.39
New prices:
1Dampflokomotive + 4
Purchase 20420
Income 8942
RC -2553
Maintain -3370
Benefit 3018
Payback 6.8
-
Additional note: while the above comparison shows things are fine and working as expected in 1930s, the story will be probably quite different in very late stages of the game. Initial checks show that running cost are slightly higher for electric train engines introduced after 2000 (but nothing extreme), and at the same time, purchasing prices can increase sometimes very high, sometimes just a little bit. This is not necessarily bad, one just has to check the extreme cases. Extreme examples with purchase price change out of 2-3 interval:
- 1Benst138: 75900 (2.59/km) ==> 84300 (1.41/km)
- SBB_Re460: 90300 (2.72/km) ==> 328000 (4.63/km)
- RVg_Spike_Duplex (front): 73600 (2.36/km) ==> 482100 (5.36/km)
I do not however know how the coefficients for hydrogen / electric / steam engines are set up and it could be that they initial (old) prices were just inappropriate. The RVg_Spike_Duplex train, mentioned last above, used to be profitable with old prices even if it had just front+end engine + 4 waggons and 50% average load. This will no longer be the case with the new prices and will change the use of such a train (actually with 4 waggons, it can still show profit if running 85%-90% full on average [tested], but the payback will be slow [20-30 years], which does not matter so much given that these trains are never obsolete in the game) .
-
Finally, the only real change seems to be (at least for the waggons / locs i have checked so far) mainly the purchasing price as running cost etc. are approximately equal. The 2-3 times higher prices thus means 2-3 times higher payback time and nothing else compared to the original prices in the pak128 nightlies.
I don't know what do you mean. I changed only cost and RC, and it has turned to be similar RCs than before (some trains change) and higher purchasing costs. I'll try post a list of significant changes as soon as I can, so we'll know what to look at 8)
-
I meant that after balancing and change of the cost and RC, RC are similar to those before (just as you say) and it is thus easy to guess what the change in play will be compared to the original prices (this was not the case of the prices originally posted by you if I remember correctly) - this makes life certainly simpler. Moreover, since the purpose of the change was to make prices generate by a rel. simple system, to keep most things similar, and to make it a bit more challenging (higher purchasing prices) - you succeeded so far :)
Regarding the significant changes, I do not have the current excel sheet and do not see how prices are generated - thus, I can point to the extreme cases and check whether they are profitable or not and to which extent, but I can only guess why they are as they are.
-
By now I'm in the middle of a re-make process of the excel sheet. When finished, I will update the link to the new one.
Important question:
I hope the vehicle list I got from simutranslator is the current and valid one, isn't it???
I think so, at least the number of locos is the same... but maybe some were replaced.
Changing to another thing: I've discovered (well, I knew it but didn't realise) there is a time factor affecting to the purchasing cost. It's configured to 0.25% going from 1960 (reference year). But it comes down instead up, I mean, it makes vehicles cheaper as their release date raises. I really think it should be better upside down: as newer locos should be a little more expensive because they're technologically more advanced, and also because of inflation, we all know. It would be a good way to simulate both things togheter, not in a very realistic way but in a very easy way. What do you think about?
Edit: A quick list with heavy changes on vehicles:
The following have running cost arisen by 50-76%:
skoda163, RVg_M1_tail, Haru_E3_KOMACHI_(mid), Haru-BR182_Taurus, 3Bens185, Haru_Spike-PSE_Head2, Haru_Spike-PSE_Tail2, Monatetsu_Steam_Ceres, Haru_E3_KOMACHI_(rear), SBB_Re4_4_II, SBB_Re6_6, SBB_Re460 and 1Bens155.
The following have running cost arisen by more than 94%:
skoda151, Haru_E3_KOMACHI, DB_BR103_1, SBB_IC2k_corch_Bt, SBB_IC2k_corch_Bt_tail, Haru_Spike-PSE_Head1, Haru_Spike-PSE_Tail1, Thunder_(front_engine), Thunder_(rear_engine), RVg_Hiawatha, RVg_Spike_Duplex, RVg_Spike_Duplex_tail, RVg_Daylight, Haru-ACE1_Head and Haru-ACE1_Tail.
There are no vehicles with RC lowered more than 50%. Most lowered are RVg-Pioneer_Alladin and wagons (47% all of them), 1Benst138 by 45.7%, vsys_garatt all three between 40 and 44%...
I'll release a new excel soon, as statistics here on the board are insane, I know ;D
-
I've just built a new version. Some running costs corrected: f.i. Haru ICE1 (6 wagons) had RC about 21cr/km ~= Airbus A380!!! ;D
Now there is a new version of the vehicles.all.pak. Please, re-download before further testing!!!
Current pricing included in wernieman's nighly downloads!!
-
Changing to another thing: I've discovered (well, I knew it but didn't realise) there is a time factor affecting to the purchasing cost. It's configured to 0.25% going from 1960 (reference year). But it comes down instead up, I mean, it makes vehicles cheaper as their release date raises. I really think it should be better upside down: as newer locos should be a little more expensive because they're technologically more advanced, and also because of inflation, we all know. It would be a good way to simulate both things togheter, not in a very realistic way but in a very easy way. What do you think about?
I agree - one can imagine that a purchase price of a loc 15 years after its introduction might be lower than at the beginning (but that can be implemented only within simutrans exe), but new engines are typically getting more expensive at the time of their introduction due to more advanced technologies. Thus, I think this percentage should have a positive (increasing) effect on the price
for railroad vehicles. Considering 0.25% from 1960, the latest new vehicles originate in 2040, which means max. 80*0.25=20% increase - that is acceptable.
On the other hand, I am not sure whether one can use the same argument for the road vehicles / trucks - maybe only for busses, because for trucks i feel the cost grow with better fuel economy and smaller RC, but we do not have this effect in current prices (well, they are still to be defined). So the price increase should probably be modelled differently for good trucks? It is open for discussion as well as prices for all other vehicles.
Edit: A quick list with heavy changes on vehicles:
I have downloaded the latest prices. I will have a look at the profitability of the vehicles with the largest changes in price structure and report "optimal" payback years. For example,
* RVg_Spike_Duplex train of total length 12 running on average 90-95% full on the best track of a relatively short length (it cannot go too fast - max. 220 km/h - and mileage per year is kept reasonable) has in year 2050 with the new cost structure 6.4 years payback (Price ~ 1.6 mil., Profit-RC ~ 325 th., maintanance ~ 75 th.). This looks fine as it does not deviate much the locs tested in 1930s.
-
Mmm... That sounds even better than I expected 8)
I've had an out-home weekend, so I have not been able to test at all :(
I'll try to get back to it during this weekend (despite having a lot of work).
-
I have downloaded the latest prices and post results by updating this message.
I however wonder whether I have right prices (or where else an error could be) because while RVG_Spike_duplex looks reasonable (e.g., cost=408200/RC=3.11 for the head), the prices for Haru_E3_Komachi look strange. The Haru_E3_Komachi set consists of always of 4 waggons: head (1200 kW, cost=12400, RC=0.11), mid (1200 kW, cost=202900, RC=1.68), trailer (just passangers, cost=44420, RC=0.53), rear (1200 kW, cost=30400, RC=0.25). This results in very low cost on front and rear engines and very low RC altogether, but you reported this engine as the one with increased cost. At the same time, this train does not make all that much profit so it is not like it could bear high RC cost.
* RVg_Spike_Duplex train of total length 12 running on average 90-95% full on the best track of a relatively short length (it cannot go too fast - max. 220 km/h - and mileage per year is kept reasonable) has in year 2050 with the new cost structure 6.4 years payback (Price ~ 1.6 mil., Profit-RC ~ 325 th., maintanance ~ 75 th.). This looks fine as it does not deviate much the locs tested in 1930s.
* Thunder train set up in the same way as RV_Spike_Duplex above (although 12 is too short for this train), 90% full on average in 2050 etc. resulted in 7 years payback despite rel. short length and very high purchasing cost (2.5 mil.) because it accelarates and goes faster.
* RVg_thunder_2: compared to Thunder_(front engine) and Thunder_(rear_engine) in the previous point, it is cheaper (440 th. instead of 791 th.), it is more powerful (7700 kW instead of 4900 kW per engine), it is faster (370 km/h instead of 250 km/h) and it has lower RC (13.54 instead of 18.53 per train of length 12). The question is why - why some much cheaper and lower RC when it is more powerful and faster?
* RVg_M1: again the same setup as before with trains of length 12, etc. Here one sees a strong effect of speed bonus. At 2010, the payback in years would 4.5 (train of length 12 earning 175000 per year). The number is OK I think because it looks like a regional train, so in practice trains would be shorter than 12 (although the train runs fine also at this length). In year 2050, the train running almost always 100% full earns about 75000 per year after subtracting the running cost. Because it costs about 550000, its payback would be 10-15 year depending upon how many trains share the maintanance cost.
* to be re-tested, payback years will go up SBB_Re460 with 11 waggons of the same speed (Marks_passagierwagen), year 2050, running 90% full as in previous test, payback in year is 4.7 because of relatively small RC of the train (but that comes from waggons as the standard passanger train cars have lower RC than the special train cars used in high speed trains).
* to be re-tested, RC increased a lot Haru_ACE1 train of length 12, year 2010 (20 years after its introduction, 10 year before being obsolete) with the setup as before has payback about 6.7 years (and smaller after its introduction) (yearly earnings after RC and maintanance subtracted ~ 300 ths., purchase cost ~ 2 mil.)
* Skoda151 with 11 72p-waggons of the same speed in year 2001 results in payback period around 7 years, one can however use also 100p-waggons without slowing the loc down or increasing the weight of the train, which would lead to a lower payback period.
* Skoda151 with 11 72p-waggons of the same speed in year 2001 results in payback period around 7 years, one can however use also 100p-waggons without slowing the loc down or increasing the weight of the train, which would lead to a lower payback period.
* DB_BR103_1 with 11 72p-waggons of the same speed in year 2001 results in payback period of 6 years (it is expensive, but also faster that Skoda151, so it gets higher speed bonus).
* RVg_Tigress of length 12, year 2050, price ~ 2.6 mil., profit per year - RC - maintanance ~ 430 ths., payback years ~ 6 years
* JR_700_Series_Shikansen_Hikari_Rail_Star of length 11 (longer waggons) in 2050 (tried because of different structure - every waggon has an engine), price ~ 2.7 mil., profit per year - RC - maintanance ~ 230 ths., payback years ~ 11.7 years; the same in year 2010 (to check speed bonus effect): price ~ 2.7 mil., profit per year - RC - maintanance ~ 320 ths., payback years ~ 8.5 years. This is generally more than for the trains consisting of fixed number of engines and waggons without engines.
-
Great feedback! Thanks jatypc!!
Let me comment a couple of things:
i) RVg_thunder_2: Let me take a look on it. I'll see what can I find out when I'm back home tonight.
ii) RVg_M1: Actually is what I expected. I pretend to make all trains have similar conditions, so all RCs and prices calculated same way, but I don't expect bonus system and time advance to affect all they in the same way; I think that's not our war now ;)
iii) Others: I'm quite happy overall tests seem to be keeping playability while extreme cases (big RC/price changes) seems to keep some logic and are integrated. That is our goal, ain't? ;D
-
Yes, I agree the bonus should not be our concern - if a train is purchased when it is relatively new, it earns money easily; in later years, it has already earned its cost, so it just has to cover RC and maintanance and give some extra profit.
I'm quite happy overall tests seem to be keeping playability while extreme cases (big RC/price changes) seems to keep some logic and are integrated. That is our goal, ain't?
Yes, I hope I will be able to see some logic in the final Excel sheet too :P (you are by now much more familiar with it ;))
-
Oh %@&¿$h&!!! I forgot to update the excel link! :-[
Yes, I hope I will be able to see some logic in the final Excel sheet too :P (you are by now much more familiar with it ;))
Don't expect to see any logic there... it's more like a mental/ability game between battleships and sudoku ;D ;D ;D
-
Looking good so far.
The MUs can be balanced separately if you need… I guess there aren't that many?
-
As I promised, I leave here the link to the last excel version (http://www.simutrans-germany.com/files/upload/simutrans_economy_locos.7z) I have been playing with. I've made lots of small updates here and there. Biggest changes are in speed_bonus sheet, where I tried to reflect actual way of doing things with a list of years and speeds (like the tab file, but calculated for every year). Also some big changes in the engines (locos) sheet: looks basically the same, but some formulas have been adapted. Also I did a small remake version of the macro: now it takes 30s in my computer (I disabled screen updating and removed cell selections to use cell values). Anyway, questions and doubts are addmited ;D
The MUs can be balanced separately if you need… I guess there aren't that many?
That's a possibility. Let's see what differences we find between "non-cargo-engines" and MUs and then decide. But my opinion before looking at it is to balance separately if they don't fit in current measures. But by now, first tests are looking quite nice for me: cargo engines are quite less sensible to losses (as they are calculated to run back empty); meanwhile MUs (I've tested a couple EMUs) are quite profitable, but if they get loaded below 80% they can sink your company :o And I like that way ;)
-
Thanks for the Excel file - it clarifies some things. Most importantly, strange prices and cost for Haru_E3_Komachi and some other vehicles are explained by the difference between the Excel prices in tabs Engines & Waggons and those in tab Export. For example, the prices for Haru_E3_Komachi_(rear) are 30400/0.25 in simutrans and Export tab, but they are 215000/2.66 in tab engines (there are more examples of this). Is this intended? Without knowing what the correct prices are it is difficult to test.
By the way, Haru_E3_Komachi can never be profitable with the current prices in tab Engines, which comes from the fact that there are 3 (passanger carrying) engines in that train and only one waggon, but the entries in the Excel sheet look like each engine pulls 3 waggons. Putting the number of waggons to 1 should give more or less reasonable results I guess.
-
Mmmm... The export sheet is just a snapshot in a certain time; you should take the engines one as reference, but beware the values in red cells are the correct ones. They're supposed to be 15% for income/rc, 100% for bonus influence. The other ones are just calculations. After adjusting them remember to recalculate effective speeds using the macro (click on calculate eff_spd button). Then you should get correct values in the engines sheet. Tell me if you have any trouble with that.
I'm thinking we must calculate MUs having fixed wagons number separately... The Komachi is one of them, isn't it?
-
Mmmm... The export sheet is just a snapshot in a certain time; you should take the engines one as reference, but
OK, then the "vehicles.all.pak" does not correspond to the current Excel and I will try to test only vehicles, where I have the same numbers...
I'm thinking we must calculate MUs having fixed wagons number separately... The Komachi is one of them, isn't it?
Yes, Haru_E3_Komachi, Haru-IC3, RVg_flying_berliner, Haru-373, RVg-Pioneer_Alladin, Evil_BR357, Evil_BR170, 471, nankia21K, Haru-PlanV have all fixed length larger than 1.
How do the units (rail busses such as DC22) consisting of one engine carrying passagers and no waggons fit in the picture? (Haru_VT98, Dc22, JRW_Mc123, Evil_BR153)
By the way, it seems that high speed trains with a fixed number of engines and waggons earn back their purchasing price generally faster than the high speed trains consisting of engine-waggons (each waggon has an engine such as Shikansen trains).
-
I'm sorry I've been quite busy these days, so I've been absolutely disconnected. I'll try to get back to work after finishing some homework during this week :-[
-
No problem, vilvoh already explained your situation to me :)
I always tell any people who work on hobby projects and I am their "boss" in some way: you do not have to do anything. This is for fun, not for money. Just tell me when you want to do something, and when you aren't going to do something you already started.
I am quite content just knowing you have to postpone this but remember.
-
Sorry for the question but ...
what is the status of he poject?
I think we could make a nighly of a new pricing-system ..... so we get better feedback ...
-
Zeno has something to do…
-
I'm a little busy with both work and studies, but I'm getting back to this ASAP; 5th december will be my last day of studies for a long time, so I'll have some more free time. By now, we can get a beta version if you want. I'm playing a bit with new prices for all locos and wagons, and I haven't seen anything out of normal perception, so I think it could be possible to use current sheet for the beta version.
Btw, I'm still wondering to treat EMU/DMU locos separately (look at jatypc comments). So it may happen some little adjustment later, but I think the newly calculated prices are quite fine: I've taken my best saved game and I still get some benefit ;D
The only bad thing of using them right now is that if bugs/issues are detected, it will take some time for me to fix them. But if despite it you still want to use them as beta... no problem, bugs will be efficiently enqueued and wait to be processed ;)
-
Thanks for the dat-Files. The next nightly (tomorow) have your price-System.
So for everybody: PLEASE TEST IT!!!!
-
I've begun to work in road vehicles balancing, and it looks quite complex. I think it will take some time to get anything clear... btw, I'm messing with the old sheet, trying to update some formulas with some used in the new sheet with locos, and trying to get some numbers to consider later.
The first results gave me numbers which appear to be much higher than current values. Another conclusion is that, without considering bonuses, I get very similar values to current ones, so it's possible that calibrating those numbers I can get some "useful" results ;)
I'll report further advances.
-
Thank you :)
-
I think I'll have a big deal with trailers and trucks. But I see no problem with buses or one-pieced lorries, already got them in the right place :)
I'll take a couple of days to do some tests and decide if make a new sheet or what can I do with trailers and so.
Anyway, now I have to go back to homework! >:(
-
Just post here when you have something to test, I will have a look and "torture" it with tests ;) (it is going to be a bit more difficult to balance and test trucks, but anyway, you do the hard work...)
-
For the changes of the trains ... just look at the nightlys ;o)
@zeno:
When you have a betta of the new System for Trucks and/or Bussesn, just informe me. I think it will be good, when we have a alpha/betta ...
-
Nice!
At the moment I'm changing all income calculation formulas: I want to try income with income being calculated in a similar way that locos and wagons, based in the capacity, effective speed (bonus) and trip length. I need to try different things, different options, because I can't make the old sheet to work using that formulas, so I see I'll have to rewrite some. Stay tuned! ;D
@jatypc:
Thanks for your help! Everything is just work, but some is shorter and some longer ;)
@wernieman:
Ok. I'll give you some files in short time. Anyway, I've got a big headache with trailers. And yes, I also need new pricing for buses and trucks. I think it was suggested before that was very difficult to make benefit using buses until toooooo late dates... Actually I think so.
-
Before you do too much balancing of individual vehicles....
The speedbonus chart in the recent nightlies (2133) is really no good at all, at least for starting in 1930. It needs to be rewritten. Either that or *all* vehicle speeds need to be changed, which is a lot more work.
Problems:
(1) Train expected speeds are much too high. Trains can only be used for bulk cargo, never for passengers or express cargo, even if there are huge volumes. The 134 kph train, running full all the time, is just less effective than a 60 kph tram.
(2) Truck expected speeds are a bit too high. It's very hard to make a profit on trucks for any sort of cargo at all, and buses are never any good.
(3) Tram expected speeds are a bit too low. You can make quite a lot of money on trams.
(4) Ship expected speeds are very low. Time-senstive cargos should always be sent by slow boats, for maximum profit!
(5) In general, the differences in 'expected speeds' between modes are very large and *do not* correspond to the difference in the speeds of the available vehicles. All the available trams in 1932 are "faster than expected" and all the buses are "slower than expected", with predictable results.
You get paid much more to run a fleet of hundreds of 35 mph trucks than one 70 mph train. Or to run a 19 mph ship rather than a 70 mph train! This is sufficiently unrealistic that it's bizarre. Building a canal to transport fish is expensive, but if I can swing the capital cost, it's better than buying cooling trucks. And the trucks are far better than a train which is twice as fast. Apparently people pay huge premiums for slower delivery. :-) I can see having some difference in the expected speed of different modes, but a *small* difference, not 19 kph for a ship and 116 kph for a train.
Once the speedbonus chart is fixed, the vehicles do need to be fixed too, but it might not be as big an issue afterwards. There are a lot of passenger vehicles which are slightly slower than the alternative. With the speedbonus as important it is, I found that I always needed to use the fastest possible tram, or if I couldn't afford the tracks then the fastest possible bus; nothing else was *ever* worthwhile, because the speedbonus effect was so large. The same was true for anything with 5% or more speedbonus. If the speedbonus effect wasn't so huge, it might be reasonable to use a 55 kph tram instead of the 60 kph one.
-
Before you go into too much detail, know that so far only trains were changed, everything else is still as broken as before.
But the observations are useful! :)
-
AFAIK only the theoretical, not the actual max speed of a vehicle counts, so if the engine and the cars in use have a max speed that allows for the bonus, you'll get it - regardless of whether or not the train (or whatever vehicle) actually reaches this speed. Or has that been changed?
-
Uhmm... you mean if its max speed is 80kmh it will receive the bonus for 80kmh even if it never goes faster than 50kmh (f.i. in city)? If so, effective speeds should be forgiven, and use theorical max speed instead. ???
But anyway, I think this should be changed in game, if not you could use lower quality and maintainance roads to get same income ... :-\
-
At least it used to be that way for quite a long time - I don't really know if this is still so. You gotta ask prissi to be sure.
-
I don't remember any change to that. Yes, reached speed is not accounted for. However, it has some effect on how much cargo you can move and thus the revenue, too, albeit indirectly.
-
I don't remember any change to that. Yes, reached speed is not accounted for. However, it has some effect on how much cargo you can move and thus the revenue, too, albeit indirectly.
I don't think that can really affect too much to a road vehicle... maybe trucks-trailers, but not buses since they have enough power to move their cargo by far. But actually I'm using an effective speed calculated from prissi's formula: weight=power/(vmax^2/2500+1). But all vehicles except 3 get same effective and max speeds :D
-
Oh, that! Yes, if you overload a vehicle, it can slow down.
Can you list the weak vehicles?
-
Goods_Truck_4. Max speed 130kmh, 236kW. Fuel: Hydrogen. Theorical effective speed: 116. Difference: 14.
MS_Hino_goods Truck. Max speed 130kmh, 200kW. Fuel: Diesel. Theorical effective speed: 125. Difference: 7.
Bulk_Truck_3. Max speed 90kmh, 194kW. Fuel: Diesel. Theorical effective speed: 83. Difference: 5.
But I would bet that PMNV_50_Mack is also quite weak... I's always suffering to accelerate when pulling any heavy trailer ;)
-
After some exhausting hard work days... I'm back guys ;D
Get the last vehicles.all.pak HERE (http://www.simutrans-germany.com/files/upload/vehicles.all.pak.7z).
I've updated the last prices for road vehicles: they are calculated the same way no matter is bus or truck or lorry.
I've finally built a pak file so you can test. It would be great if I get some FEEDBACK, please!!
-
Thank you! I will try to test it... it's been soooo long since I played Simutrans!
-
thanks a lot, I will test them.
-
If you give us the dat-Files .. whe can check it in the vsn ...
-
I see "broken" as a binary state. If the numbers are broken, you can't break them more, no?
By the way, I changed some other values (engine_type) in the meantime, please do not overwrite these... but that's a problem of using svn the right way, not your changes.
edit: I started playing and immediately some flaws are apparent... not just with your balancing! This is starting to be a rather complex problem. Let's see:
Start in 1930, now I am finishing 1930.
I "kinda" overdid it with field productivity. Grain farms are far more productive than is the actual need, at least as far as I can observe. Good for me, at least somewhere I can pump money steadily.
Compared to my memories, quite a few vehicles feel underpowered.
Ironically enough, there are not enough buses to meet the speed limit when starting game! I get zero bonus for 50 kmh, but most vehicles can do only up to 45, and even poorer model is introduced. The PC-ed bus with 58 kmh is all nice and should make insane money compared to the rest, but is horribly weak and can't drive at full speed… it could be easily overtaken by the slower models!
So I have real trouble making any money with buses, I use the most economical one and the fastest one and they make more or less same money. But the other models have even worse parameters...
Clearly the speedbonus table is too optimistic ::) Let's see about that >:(
Question: how do you decide if a vehicle is "productive"? As I see it, it should make profit at the time it is removed from production, since it can be bought even then. It doesn't look that way with all the costly buses...?
Argh, now I am really starting to be frustrated. I can make lots of money on grain and flour :-/ Coal pays poorly. Passengers are hell.
So, I stayed up until 3:20 am and kept feverishly punching fast-forward button to see what comes next… never more!
The speed bonus is largely disconnected from reality, so obviously that needs to be changed. Should I look into that, or do you want to perform some C# black magic punishment on it yourself?
road=1911,21,1928,50,2001,82,2032,85
The entry "1928,50" obviously created most of my problems.
I had only one train line, so most of the comments are not related to it. Everything is about road transport.
One more idea... maybe I am overestimating the importance of speed bonus. It certainly does not matter with some cargoes. But I see most vehicles always under it! That's what I can't get over.
-
Question: how do you decide if a vehicle is "productive"? As I see it, it should make profit at the time it is removed from production, since it can be bought even then. It doesn't look that way with all the costly buses...?
I suppose it's fully loaded and get its "theorical" max speed [weight=power/(vmax^2/2500+1)], then I compare with the bonus speed of its introduction date. Then I apply "normal" income based in distance driven and capacity, and then I use a percentage of the bonus it should get if its speed is "theorical" max speed.
I use a percentage of the bonus because if I use ALL the calculated bonus I get very unbalanced results. Still got to play a little bit with it.
Anyway, I'm with you the bonus system is not perfect. That 50kmh in 1928 is the example :D
And another problem is we don't have a continuous vehicle time-line coberture, I mean, there are not vehicles available for any purposes at any time (not always have city buses or inter-city line buses or...) :'(
Another thing I've detected looking at planes, and I don't know if will be the same for other types of vehicles, is that there is an arbitrary use of dat parameters sometimes. Look at raven's Airbus A380 and mine. Raven's weighted 500tn and mine 277. And mine is more powerful!! If this also happens with other types of vehicles (much more difficult to detect!), this will be some kind of madness because vehicles will never get the results we expect :-\
-
Hmm, you do interpolate the bonus speed, right?
-
Mmm... yes. Suppose:
1930 -> 50kmh
1940 -> 60kmh
Then I interpolate the values between: 1931(51), 1932(52)...1939(59). Then I look for the year and get the speed. Shouldn't I do it this way???
-
Yes, it was just a quick idea what could go wrong in some cases...
-
Well... I'm thinking now that if bonus is calculated with vehicles' max speed (DAT) and not the higher speed it reaches in the trip (game) then I should not use the "effective" speed but the DAT max speed. Do you think I am right??
Btw, one thing I have clear is we have to make the bonus speeds table to fit our current vehicle designs, because we can not make the designs to fit our current bonus table ;D
And lastly, I remember talking with VS some months ago about planes in pak128. After analysing them now, I do think we MUST do something (not now but in mid or long term) because planes are IMHO really the weakest part of pak128: unbalanced pricing, unbalanced data, unbalanced time-line, unbalanced graphics, ... :-[
-
Yep, planes really need many changes. Something about half of them is from unreachable authors.
5 HIBARI (-5 copyright)
4 Haru (-4 copyright)
8 Raven (-4 too ugly - even Raven complained about them, but never got to replacing them with anything)
7 MHz
1 Sindor (-1 too small)
With this outlook, one could almost say, don't care :)
I'll try to plot all vehicle speeds and find some reasonable bonus values - or do you want to do it?
-
I'll try to plot all vehicle speeds and find some reasonable bonus values - or do you want to do it?
You can try it, as I don't really have a need of it for my calculations; I will have to update bonus table when finished and everything will be re-calculated.
If you are too busy I can try it myself later on, probably next week.
What would be great is to calculate it in a sheet function of our vehicle repository, so any time a new vehicle is introduced to pak128 we'd have a quick and easy update to the bonus table. What do you think? Any idea for a formula? :P
-
Nice progress, Zeno. It is pitty I will be able to have a more detailed look only in one or two weeks.
-
So - here are the charts:
http://www.simutrans-germany.com/files/upload/vehdata.rar
And the script is in svn, as always...
-
Wow! It's nice :D
What about "auto-building" the bonus table for a % of the avg speed on each year? Let's say... 75%? That way it could be nearer to in-game reality 8)
-
Yes, it is a possibility.
However I would like to use also some brain cells, not brute-force ;) If you take a look at the trends of average and median, they are more or less "stairs" or linear bits.
So let's combine percentages with rough interpolation by human factor. 75 is good guess - comparing the values and what I saw while playing, it could be a bit too generous, but... let's see.
More to follow tomorrow.
-
Yeah, some combination could be applied to get best results. F.i., I'm playing a game and just detected on 1965, my boeing 707 were earning tons of money, about 700-900K per year. Later on, about 1972, maybe 1973... it gets losses!!! I think that could be calibrated better, as long as there are only 3 or 4 values for planes. Trains & road vehicles won't be so easy to put in place ::)
-
I know that I have come to this discussion somewhat late, but I should like to add some general thoughts on balancing philosophy if I may. Firstly, in my view, it is a mistake to have all vehicles have exactly the same value for money (having exactly the same ratio of purchase price to running costs to haulage capacity to maximum speed for each cargo type) because it makes the choice between different kinds of vehicles less interesting (and also less realistic). Some vehicles would be better value for money than others, and some, although worse value for money overall, would be more profitable in certain specialist situations (such as crack express trains, or short-haul bulk transport at slow speed, etc.). There should perhaps be an element of diminishing returns, in that paying ever more for a vehicle makes it better in increasingly small increments, the player having the difficult but interesting decision in every case where to stop. (The ideal manifestation of this would be to have several different price bands of vehicles all available at the same time, and then, as technology moves on, those same price bands applied to respectively higher specifications). There should also be a certain element of randomness: some vehicles should just be plain better than others (not necessarily be large amounts, but enough to make a difference). Again, this makes gameplay more varied and interesting, especially if players cannot rely on improvements in technology to be consistent.
Also, the game would be more interesting if the ratios changed over time. The trend in reality has been (very approximately) for newer vehicles to have higher purchase prices, but lower running costs and/or better performance. If this pattern was implemented in the game, the result would be a game in which both the risks and rewards slowly increased with the passage of time, starting out with it being fairly easy to make a small profit, but difficult to make larger margins, but becoming increasingly the case that, if one has the money to invest, and one manages the network well, one can make very considerable margins on newer vehicles, but there is a far higher risk of overspending and losing a very large amount of money quickly if one makes a mistake. That again would make the game more interesting.
Furthermore, I have been working on some patches to the main code which, if accepted, could make a real difference to how the paksets should be balanced. Further discussion can be found, amongst other places, here (http://forum.simutrans.com/index.php?topic=952.0), which also contains an initial version of the first half of the patch. (I am still working through some techincal problems on the second half). In essence, the function of the patches would be (1) to make the speed bonus (either positive or negative) have less and less impact the shorter the journey; and (2) gradually increase the maintenance costs of obsolete vehicles from the date of their obsolescence until (by default) 20 years after retirement. The cumulative effect of those changes would be to make differently balanced vehicles preferable for short-haul transport than are preferable for long-haul transport. There should be high capacity vehicles with low running costs but a low speed for short haul transport, but lower capacity vehicles with a higher top speed and higher running costs for long haul transport, since the earnings with short-haul transport would not vary much with speed, and so would benefit from capacity and low cost instead. These modifications would also mean that the speed bonus ought be set perhaps a little more aggressively than it is now, so that the speed that gets the 0% bonus is faster than the speed of the vehicles designed just for local transport (and is, perhaps, the approximate average of older but not obsolete vehicles designed for medium distance transport).
Finally, may I ask - are the British and 19th century vehicles available on addons.simutrans.com part of this great rebalancing? I always like playing with those vehicles, and it would be a great pity if they were not included.
-
Yes, you are late. Very. I don't know how far along the work actually is right now, but we are trying to get a new official release of pak128 out as soon as we can manage. And my guess is that redoing everything from the start (once more!) isn't helping us to get there... So my guess is that these ideas will probably not get into the next release. After that, who knows... but let's walk step by step - first things first.
Oh and all vehicles using the same ratio of value for money might not be realistic - but it a) makes things easier for new players (no danger of buying a "wrong" vehicle, since they are all comparable and calculated by the same method) and b) it allows for more diversity (otherwise you'll probably end up with people only using the single best vehicle, instead of allowing them to choose one from several equals... at which point we could almost remove 80% of the not so efficient vehicles completely, because nobody would be using them anymore). So... no, I don't think that's a good idea - not for the near future at least. We are actually trying to get things simpler and easier to understand, not more realsitic (and therefore also more complicated).
And since there is a whole pakset for Britain and British vehicles of itself, I don't think any additional ones are needed in pak128 at this point. Also, once again: there's a reason for addons to exist. Not everything that is created - and liked by a couple of people - needs to be part of the basic sets. So if you like these vehicles and they are available as addons - just use them. ;)
-
Yes, you are late. Very. I don't know how far along the work actually is right now, but we are trying to get a new official release of pak128 out as soon as we can manage. And my guess is that redoing everything from the start (once more!) isn't helping us to get there... So my guess is that these ideas will probably not get into the next release. After that, who knows... but let's walk step by step - first things first.
Ah. Note to self: join in earlier next time ;-) Of course, once the new basis for calculation is set up and all the vehicles have their figures generated on a standard basis, it would be relatively easy to make small adjustments based on the suggestions here.
Oh and all vehicles using the same ratio of value for money might not be realistic - but it a) makes things easier for new players (no danger of buying a "wrong" vehicle, since they are all comparable and calculated by the same method) and b) it allows for more diversity (otherwise you'll probably end up with people only using the single best vehicle, instead of allowing them to choose one from several equals... at which point we could almost remove 80% of the not so efficient vehicles completely, because nobody would be using them anymore). So... no, I don't think that's a good idea - not for the near future at least. We are actually trying to get things simpler and easier to understand, not more realsitic (and therefore also more complicated).
I don't agree with this, for two reasons: (1) because making things as simple as possible is not the way to make a game fun; and, more importantly, (2) because I was not suggesting that any vehicle be balanced so as to be the "wrong" vehicle overall: every vehicle should be balanced such that it is the right vehicle for at least
some situations, but, just as in real life, some vehicles will have a wider range of situations for which they are the right vehicles than others. A vehicle that is, overall, worse value for money than another vehicle can still be the best vehicle to use in certain situations. It might also be that, as technology advances, vehicles gradually become better value for money in some respects, and worse in other respects. Aircraft might well become better value for money as time progresses, for instance, and trains worse value for money.
As to the British pakset - do you know whether that was ever finished?
And since there is a whole pakset for Britain and British vehicles of itself, I don't think any additional ones are needed in pak128 at this point. Also, once again: there's a reason for addons to exist. Not everything that is created - and liked by a couple of people - needs to be part of the basic sets. So if you like these vehicles and they are available as addons - just use them. ;)
[/quote]
-
james, let me add that it is true we are trying to make profitability similar across vehicles. On the other hand, the rules to set up pricing are relatively simple, and therefore, there is quite some variability in profitability among different vehicles (e.g., years to earn the purchasing costs can vary, for example, from 4 to 9 in more or less "optimal" setup - make something wrong and profitability is gone). Moreover, there are many other factors influencing the choice of a vehicle:
a) speed and capacity (small vs. large number of vehicles, sufficient vs. insufficient service)
b) speed vs. the cost of infrastructure
c) number of convoys vs. the structure of infrastructure (connections)
To choose the optimal vehicle for given route is thus far from trivial and variability as well as chance of having money-losing vehicle is there...
-
I can't really say anything about Zeno, but I just cower in the corner and hope it goes away soon :D
A few minutes ago, in r275, I set the speed bonus to values that roughly match average speed. Of course it is interpolation of uncertain data by a set of linear functions, so there are quite a few rough jumps. I tried to keep avg(speed, time) >= speedbonus(time). This means there are some fat and some hungry times - depending on how big the actual difference is. Btw, the old values were complete nonsense, sometimes completely out of the min/max bounds...
Monorails should now make some money - previous speed for zero bonus was in the lowest place 20% higher than maximum.
Ships also had these gross extremes, so now the trend is more sane. The new values are set so that average speed is almost identical, except for a plentiful period in 1900-1950.
There is a drop in tramway speed after 1910, so trams should be very profitable before 1910... if you can get any!
-
Why was everyone ignoring the speedbonus.tab I had exactly made for pak128? VS, you could have used it ...
-
Oops, I didn't see it there. The new values are very similar indeed. In my defence, I wasn't the only one to overlook it :(
At least I learned something about the speeds - and printed them on paper…
-
I am trying to do some development and I've got problem with vehicle data. Is there any template or calculator to set vehicle data according to the new balancing rules?
And another question.
How the weight of vehicles is calculated? Because according to official pack Icarus 260 weight 28 tons! witch got nothing to do with real life. Is that weight of bus with full passengers load or is it only vehicle?
Cheers
-
The weight should be the unladen weight, since the program adds the weight of the freight dynamically.
-
How the weight of vehicles is calculated? Because according to official pack Icarus 260 weight 28 tons! witch got nothing to do with real life. Is that weight of bus with full passengers load or is it only vehicle?
Cheers
The balancing only changes
Running Cost and
Vehicle Cost. Vehicles weight is not calculated but coded in the PAK.
I use the value the creator put there, so if Icarus 260 weights 28 tons, I will adjust its RC and purchasing price to match that value.
Btw, if you detect some more incorrect vehicle's data, I would suggest you create a post collecting data issues so they can be modified.
Edit:
AFAIK Icarus 260 and 280 both have (yes, I mean in game!) a weight of 31 tonnes (empty) ;)
-
Are you referring to reality or the vehicles in game?
It should be 12t...
http://www.busnumber7.com/index.php?id=1
-
Are you referring to reality or the vehicles in game?
To game data, of course!! That's why I suggested to create a post with errors in data files :)
-
Oh! I have felt that quite a lot of road vehicles is somehow weaker than they used to. Some could use a lower weight or higher power... but a systematic approach would be better than guesswork.
-
Some could use a lower weight or higher power... but a systematic approach would be better than guesswork.
I can give you a general idea by getting those vehicles which have lowest values for theorical/potential max speed (w/o limit) minus real max speed; that would give us a list of potentially
weak vehicles. ;)
-
Oh! I have felt that quite a lot of road vehicles is somehow weaker than they used to. Some could use a lower weight or higher power... but a systematic approach would be better than guesswork.
Ok, VS. :) Have you heard the joke about the sound of cars, related to their power ... ? ;) ;D I guess you did... :)
If you don't know ... :) I'll PM it to you, as it might upset someone, here... :( :-\
-
I have just discoverd that on latest nightly build pack version "simupak128-325" some buses are still cheaper then others.
KC-B10M Keisei Bus seems to be cheaper then any other bus.
I'm not sure is it after rebalancing version pack but links abowe to test versions are not working.
Cheers
-
Yes, you may find newer buses seem to be cheaper, but that's the effect of the bonus-speed: newer vehicles need higher speed to get same money. So they're a bit cheaper.
-
I'm doing new testing with trains: I've changed weighting of engine types. I've seen electric trains RC is calculated using same formula and weighting than diesel ones, so if mainainance of electric overheads is a plus on electric locos. That way electric locos are much less profitable, so I'm trying to level it a little.
Original weighting for loco's RC was:
- RC*1.1 for Steam, RC*1.0 for Diesel, and RC*1.0 for Electric.
- Now testing with 1.15 steam (+5%), 1.05 diesel (+5%) and 0.95 electric (-5%).
I've also raised electric loco's purchase price by 10%.
I'll report results and impressions... That's auto-feedback! :D
Btw, what do you think about the idea? Any suggestions?
-
I think it is a good idea (originally - in 1.00/128 - the eletric engines had smaller running costs than diesels, mostly). My guess it even corresponds to reality as long as one assumes that an electric power plant generates electricity more efficiently or cheaper (by 30-40%) than the diesel engine in dieselelectric locs.
-
In reality, electrics are considerably cheaper to run and build than diesels, since they are a great deal simpler and more efficient. That is offset to some extent, however, by the infrastructure cost for the delivery of electricity.
-
Electric locos are cheaper to build than diesel ones? I've always thought they were more expensive... ::)
-
Electric locos are cheaper to build than diesel ones? I've always thought they were more expensive... ::)
Hmm, why would they be more expensive? A diesel-electric has to have everything that an electric locomotive has, plus a diesel engine...
-
Hmm, why would they be more expensive? A diesel-electric has to have everything that an electric locomotive has, plus a diesel engine...
Mmmm... yeah, sounds easy ;)
I may take away that price rising...
-
Well... We're entering last stage!
I've been doing some numbers for planes and ships... Actually it's applying same idea used to get trains & road vehicles' values. I've but introduced a new concept, which are some price factors, that raise purchase prices of planes and ships so it gets more like IRL, where a plane may cost 100 to 300 M$ while a train may cost 6 to 10 M$. I've used a weight factor combined with a capacity (in tonns) factor to increase/decrease the pre-calculated purchase price.
These are some global numbers we can get from new values ("." is thousand sep, "," is decimal sep):
- Ships average cost raised from 47.479,38 to 67.209,07 cr
- Ships average RC lowered from 14,28 to 10,84 cr/km
- Planes average cost raised from 319,644.40 to 874.888,62 cr
- Planes average RC raised from 6,30 to 8,75 cr/km
That's just to get an idea of how modifications affect general/global gameplay. It should be analised at different ages (1930s, 50s, 70s, 90s, fi).
I'll now build a new beta pak so these changes are testeable; also last train modifications will be included: +3% RC diesel locos, -4% RC electric locos. Until then (maybe this afternoon), suggestions/comments will be welcome :)
PS: Also I've introduced a new factor for RC in planes, which is as easy as RC = RC * times_sound_speed_crossed, so planes below 1 match don't get any modification, but planes quicker than sound speed get higher running costs. At the moment only my Concorde is affected, and isn't in the official pak, so no problem with that.
-
You now, that Monday and Friday the Nightly-Computer build a new Pak (if there new Data)?
For This:
If you have check in new data to the svn, give me a mail and I start a special run ...
-
That's just to get an idea of how modifications affect general/global gameplay. It should be analised at different ages (1930s, 50s, 70s, 90s, fi).
That is all related to the profit and/or revenue made in the game, right? :-\
-
That is all related to the profit and/or revenue made in the game, right? :-\
Well, that's related as long as running costs change a bit, so profit will also change a bit (revenue is what is). Also purchasing prices change, so time elapsed until the price gets payed back also changes. But all it will depend a lot on the vehicle and year.
As always, all prices/rc are calculated based on vehicle intro year bonus speed versus vehicle speed. So the vehicles are all balanced respect their intro date. As time advances, all vehicles keep getting a little less competitive, as long as the bonus speed is raising.
You now, that Monday and Friday the Nightly-Computer build a new Pak (if there new Data)?
For This: If you have check in new data to the svn, give me a mail and I start a special run ...
Thanks Werner, I may upload data today if I feel it's ready; if I think it worths to make a special run I will upload and tell you. Thank you.
-
P.S. I am Freiday and Sunday on the "Autobahn", so the new Version will go tomorow, when you check in today ;D
So you have time :police:
-
...so the new Version will go tomorow, when you check in today...
I've the balance almost ready... Maybe I'll upload the files before going to sleep. I'll load a saved game and let it play for some years (accelerated, of course). I'll see results then if everything ok I'll upload so tomorrow there is new nightly :)
Edit: Just uploaded changes. We'll see if feeback increases now with next nighty ::)
-
There should be a nw PAK128-Version on the nightly-Webpage ....
-
As I think current results are quite acceptable, I'll focus my efforts on migrating current excel sheets to open office calc format. I may do some changes to the format that Tomas K. gave to this sheet, but essentially will keep most of its data and functionality. When finished, I will upload it to svn server.
-
Did somebody hear somethink about the new pricing in the pak128?
positiv or negativ?
The Version is 1 week old ...
-
Did somebody hear somethink about the new pricing in the pak128?
positiv or negativ?
The Version is 1 week old ...
No news on that... seems the balancing has perfect results ;)
As some other people suggested, I think with the next release will come more feedback... I hope!
Anyway there's still some work to do, specially with troleybuses and trams. So we'll see.
-
O.K ...
could we give us a "Milestone"?
A full Version in 1 week?
-
Yes. On Wednesday (Mittwoch, úterý, ...) I sit an exam, and then I have all time in the world, because there will be no way to improve anything.
-
I have just tested pak128-379, and it is quite good possible to make profit with passenger network in the 1930´s and early 1940´s, so balancing seems to be fine. For now I just use busses and trains, as soon as possible I will try to integrate some Airplanes and see how the goods transport is.
Greets
Rohal
-
Thank you very much, Rohal. I'm glad you find the game so playable! I guess it's similar with goods, but planes or ships are still in experimental mode, so I would thank a lot any feedback reported. Thank you!
-
I'm no hardcore Simutrans player (yet) so maybe I can't give expert feedback, but I agree with Rohal that the balancing seems to be fine. You can make money early on even though it's not too easy - just the right degree of difficulty for me (having played lots of other transport sims before). :)
-
My personal indicator of balancing are the Czech subforum people, who complain violently all the time about prices. Now that ceased, so I can only assume this project was a success!
Thank you, Zeno!
-
Well, I'm not Czech, but promise I also complained a lot about it!! ;D
Btw, I'll take a look to trolleys and trams. And I'll write down some documentation about the process so all work don't get lost.
-
Balancing for Passangerferries (in the 1940s and 50s) on medium range routes is also good. Ships repaid buildingprice after 2 years. Airplanes like Junkers 52 and Dakota DC-3 don't work profitable, but it might be that the route still was to short. So from my point of view you did a real good job.
Greets
Rohal
-
I also tried planes in around year 1936 and they are not profitable (RVg Ju-52 and MHz McDonnell Douglas DC-3 Dakota).
In 99.xx version i usually started with coal trains, from coal mine to coal power station, but now i can't get that to profitable. Busses and passenger trains seems to be in good balance.
(Simutrans 101 and pak128-1.4.4)
-
Mmm... from your comments (thanks!) and my own experience, I'm feeling like oldest planes are less profitable, and newer ones (707 and above) are too profitable.I think it's because 2 things:
1) I apply same calculation to planes than other vehicles types, but planes are much more critical and unaccurate profit calculation ends into huge disadjustments.
2) The bonus table for planes has a terrible jump near 1958 when first jet fast planes appear. That makes profit a bit crazy for some years until it stabilizes a little bit; anyway planes are an amazing profit source after those dates, if enough passengers available to transport.
Well, I'm gona write down my reflexions at same time I think:
After reading tomilepp comments, I have to say I don't find any difficulty on making profit with coal/petrol/garbage transport. But sure he will agree with me: I have the feeling (but can't mathematically demonstrate it) that it's more difficult now to make money with freighter trains in gerenal; before the balancing I had the impression it was really simple to start making some good money just with a coal train; now I can't get to make really big money until jet-planes arrive around 1960 or so.
That gives me to a point: if passenger services are (quite) profitable, even in early games, and freight convois aren't such a profitable bussiness, may I be wrong if I get to the conclusion that goods prices should also need a little balancing?
Maybe I will have to rewrite profit formulas: maybe they're wrong, I can't promise they are not; maybe passenger transport is more accurate; maybe high-bonus-goods (passengers included) are the trick...
I'd like you guys to help me by writing here your impressions too. I really like the model we have right now; low-bonus goods make some money (but not enough to become millionaire), but high-bonus goods are quite profitable (specially passengers). Do you think this should be the right model? Do you think it's ok but not such a big difference between them? I'm looking forward listening your opinion. Thank you all for your feedback & comments!!
-
I like to build Pasanger Networks, so this is good for me. But for an new simutrans player, it is hard to leran. Normaly he/she build a Transport Network and with this system he have big problems .....
Only my thinking
-
I agree with wernieman's opinion, new players normaly will start building goods network, so maybe the goods prices should be raised a bit.
As wernieman I am a player who likes to start with passanger network, because it is more chalanging. In so far I still haven't tested the goods transport, but I will try to start soon.
Greets
Rohal
-
Well, I could correct that behaviour by raising a little passenger revenue calculation (which would also raise related RCs) and lower general all RCs. That would make easier to make money using freighter convois, while not modifying very much passenger service revenues.
Maybe I'll give a try; I can make some quick tests in a couple of days.
-
To be more precise, i could make coal trains profitable, but it is not profitable enough to pay maintenance of tracks, stations and depot.
I tried to make small network of 3 stations, 2 in coal mines and one in coal power plant. One small train hauling coal from both stations. Income is about 1000/month and maintenance about 2000/month.
-
To be more precise, i could make coal trains profitable, but it is not profitable enough to pay maintenance of tracks, stations and depot.
Yes, I assumed that. The trick is the game dificulty resulting after all (profit+maintenance).
It's nonsense it my current game I've built between 15 and 20 freight lines, plus two airports in two big cities, and 5-6 passenger services to nearest towns; also bus services in all towns. I've built it in about 30 game years, just by spending any money I get into building new lines. I'm earning about 1200K/1300K credits per year. I think it's a bit too slow.
Moreover it's also nonsense again that when boeing 707 appears (after waiting a couple of years to get enough money) I buy one (1 700 000 00 cr, maybe more) and only that plane begins earning more than 1000K per year). It breaks down all efforts I've previously done. I must find a workaround for this :-\
-
Hi, do you take into account the maintanance of airports (runways, taxiways,...)? They are very expensive in terms of maintanance and two airports can turn nicely profitable game into losing or slowly earning one - unless there is a lot of air traffic that would cover those costs.
-
Yes, maintenances are taked into account. The trick is in early games airport maintenance is very high, and the profit you get from planes is rather low; in later games, maintenance is even higher, but since profits are up to a million credits per plane and year manteinance becomes insignificant... if you have enough planes and passengers to transport, of course ;)
-
Because of nobody else, who writes something about his experience I will continue.
The passenger service is good balanced, my game contiued to 1969 (Exec 102r2325, PAK128-458), small map 256x256 16 cities, yearly profit 7300K, proceeds 10700K.
I´ve tested several Industries in new games. I started every game with the standard starting money of 500K.
With establishing a coal service 3 mines (each had an seperate train) and one Powerplant and suppling mines with power I made an yearly op of 15K. I spent nearly 400K to establish this service.
With establishing Oil service, 2 Oilfields, one Refinery and 2 Gas stations (2 trains for Oil and 2 for Gasoline), I made a n yearly op of 20K. I invested 400k
And last but not least I tried a grain service, 2 Grain farms (connected with 3 Trains), 1 Grain Mill and 1 bakery (connected with 2 trains) I made a yearly operating profit of 33K. To get this established I spent 500K.
Finaly I would say that you need to build complete industry chains to be able to grow. But I think it is very hard for newbies to achieve fast success when starting indutry service. I would say that goods payment should get an workaround.
If you need some more testing assistence I would like to help.
Greets
Rohal
-
Yes, I assumed that. The trick is the game dificulty resulting after all (profit+maintenance).
It's nonsense it my current game I've built between 15 and 20 freight lines, plus two airports in two big cities, and 5-6 passenger services to nearest towns; also bus services in all towns. I've built it in about 30 game years, just by spending any money I get into building new lines. I'm earning about 1200K/1300K credits per year. I think it's a bit too slow.
Moreover it's also nonsense again that when boeing 707 appears (after waiting a couple of years to get enough money) I buy one (1 700 000 00 cr, maybe more) and only that plane begins earning more than 1000K per year). It breaks down all efforts I've previously done. I must find a workaround for this :-\
It's in pak64 too. The solution is not to just increase the maintenance costs or decrease the capacity but I think to decrease the profit curve for speed. (if you can do that, and if speed is a factor (?)... I forgot) Example: something that goes twice as fast should only get 50% more profit, not 100%.
-
I've found small problem with city bus routes.
I started in 1990 and I am using seperate companies to run city network and intercity network. Inter city companies generating nice income but city companies making constant lose. Number of vehicles is balanced carefully with at least 60% capacity used all time very often around 90-100%.
-
The solution is (...) decrease the profit curve for speed (...) something that goes twice as fast should only get 50% more profit, not 100%.
Yeah, that can be a nice approach, but still difficult because it's not trivial which are min and max speed; But I'll make some try-error approach I think, that will be enough for a test. Thanks a lot for the idea.
(...) city companies making constant lose (...)
It's quite strange. Btw, try to avoid circular lines, as simutrans engine has recently experienced variations on this kind of lines handling. I use to make linear lines and they give me excellent results (not allways lots of profit, but most of them). And most people say it's much better now... Give it a try and let me know!
-
Moreover it's also nonsense again that when boeing 707 appears (after waiting a couple of years to get enough money) I buy one (1 700 000 00 cr, maybe more) and only that plane begins earning more than 1000K per year). It breaks down all efforts I've previously done. I must find a workaround for this :-\
Hi,
I had a look at Boeing 747-200 (and DC-10 etc.) around year 1985 (simply where my play was at the moment). It costs around 2.2 million. If it runs 100% full all the time on a very long route (not much slow down on airport), it was able to earn around 500 000 (after running and maintenance cost). This gives me about 4.5 year payback (although one would normally expect a longer one for such a big plane) - but this looks as a reasonable number as this was achieved under optimal circumstances (other planes looked reasonable as well). The problem for 707 could be caused:
1) by speed bonus in the time when the "speed_bonus" speed is very slow (compared to that of 707) such as 400 in 1966 [my test takes place in 1980s, when speed_bonus speed is above 600 already]
or
2) by some specifics of that model
In the first case, the high profit in your experiment would simply be cause of the speed bonus because its baseline speed grows more or less linearly, whereas the speed of planes develops in big jumps (e.g., there is an era of planes with max. around 400 km/h and then the next ones appearing can fly at around 800 km/h already).
On the other hand, I agree that maintanance cost are relatively small once these big fast planes enter the service.
--------------------------------------
EDIT: 10 years later, I tried 747-400 (Jumbo), which has a higher capacity and relatively low running cost. This one can earn more than 800 000 per year, while it does not cost much more than 747-200 (just 2.4 million). Anyway, this will descrease later on as speed bonus changes. The main "problem" is that the speed_bonus reference speed should reach 800 km/h only in 2020, but there are no passanger planes slower than 800 km/h in 1980s already. Of course, some cargo planes are slower, which is probably the reason for the speed_bonus speed...
-
The main "problem" is that the speed_bonus reference speed should reach 800 km/h only in 2020, but there are no passanger planes slower than 800 km/h in 1980s already. Of course, some cargo planes are slower, which is probably the reason for the speed_bonus speed...
Sorry for being so late. The main problem is I've got the following speeds for the plane bonus:
80km/h in 1912
300km/h in 1950
930km/h in 1975 (and same value till 2039)Maybe you should use these values in the speedbonus.tab file and see what happens (backup yours first!!!). I don't know at all wether your file is old or it is mine. When I've got some time (maybe saturday or sunday) I'll take a look on cvs to see what values I can find there, and what I can do with them (if they're newer than mine).
Thanks again for your ideas :)
-
Would it be possible to have supersonic speed bonuses? Or is it limited to 999?
-
Would it be possible to have supersonic speed bonuses? Or is it limited to 999?
This has nothing to do with vehicles speed; it only indicates the speed at which vehicles will get paid by their cargo a normal price. Over the bonus speed it will get better paid, and worse if it runs below. So it's which
speed should travel the vehicle to have a decent profit. If the bonus speed is doubled, all vehicles will automatically earn half the money they used to (aprox).
-
Hi,
I have checked my speedbonus file (from nightly pak128-535), which says
air=1925,150,1942,220,1966,400,1978,600,2020,670,2021,790
Your proposal is of course a big difference compared to this one, becase 747-200 flying max. 810 km/h introduced in 1970 and gets huge bonuses, whereas with
1912,80,1950,300,1975,930
it will not get any. I just wonder, whether it is OK that that speed in 1975 is higher than speed on any airplane - I am never sure whether slow vehicles get no bonus or actually a negative bonus... ???
-
I am never sure whether slow vehicles get no bonus or actually a negative bonus... ???
Neither I, at least in the game (but I always think it does). In the balancing sheet I DO use a negative bonus if slower!!
I'll check last speedbonus.tab and update the excel. It will be quite easy and quick, and maybe I'll have new prices for next week nightlies. Then we'll be able to proceed with further testing :)
-
By the way, what is the intended minimum load for airplanes to turn profit or no loss? 75% as for busses etc?
-
It's set for 85% both ways in passenger transport, 95% 1 way (52.5% for both ways) for goods (but it's used a 110% penalty for goods transport by air, which makes all unnecessarily complicated). But I can advance the results aren't what is expected, just a fair aproximation :-\
-
btw.
wich the airplaine in the beginning there is a problem to make mony .... could it be that the running cost and/or the speedbonus are to high?
Beginning: 1930-1950
-
I've been making some tests on planes and I also detected it's quite difficult to make any profit with earlier planes, so I'm wondering if making an alternative calculation for them. Then I get to two options:
1) Applying a speed-differential multiplier: e.g. calculated factor which halves RC for planes running at 0 km/h, multiplies by 0.75 planes running at 300 km/h, and by 1 (keep as it is) for planes above 600 km/h. This is more like an ugly patch to benefit elder planes, and I don't like it very much, despite the results are quite acceptable.
2) Splitting engine types for planes in 2 types: Piston and Turbine engines (both with same properties, as actual diesel). So they can be calculated separately.
The thing is I don't know the difficulty it means to change engine types, but it would be a much cleaner solution. Any other suggestions/alternatives?