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,
Maybe limit small planes form flying longer distances or by making them expensive on longer routes.
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 like that,
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
@arianen:Payback Period = A+(B/C)
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.
Err, does it act always strictly as a bonus? I think not. ****.
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.
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 ;)
@Zeno ... so at the moment you are the person, how make a rebalance?
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.
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!
the same income per ton
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?
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.Four(eight) times bigger...?? I'm afraid I don't understand why at all :'(
x4/x8 is probably the change in bits_per_month from hard-coded to the new default values (depending on pak) configurable in simuconf.tabThen 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...?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... ;)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.
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#msg4852Ups. Sorry for not searching before ask... :-[
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).
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
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.
I haven't read all of the topic so I don't know what are you doing (I tried understand the excel sheet but ...)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.
I would only know if the prices will increase or decrease ?
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.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
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).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"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 .....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 ;)
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.
|
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)
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:
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 ;))Don't expect to see any logic there... it's more like a mental/ability game between battleships and sudoku ;D ;D ;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 ;)
Mmmm... The export sheet is just a snapshot in a certain time; you should take the engines one as reference, but
I'm thinking we must calculate MUs having fixed wagons number separately... The Komachi is one of them, isn't it?
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
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'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.
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).
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?The balancing only changes Running Cost and Vehicle Cost. Vehicles weight is not calculated but coded in the PAK.
Cheers
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 :)
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.
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...Mmmm... yeah, sounds easy ;)
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.
You now, that Monday and Friday the Nightly-Computer build a new Pak (if there new Data)?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.
For This: If you have check in new data to the svn, give me a mail and I start a special run ...
...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 :)
Did somebody hear somethink about the new pricing in the pak128?No news on that... seems the balancing has perfect results ;)
positiv or negativ?
The Version is 1 week old ...
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).
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 :-\
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 :-\
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).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).
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!!