Transport Tycoon Forums

hmm, i'm investigateing the two bugs mentioned lastly, purnos 811 issue, and the tanker long/short, and i cannot confirm neither in my local build (that is the dec15 one).
I'm continueing to fix the parameter issues. The easy fix is just around the corner. I.E the same behavior as it used to have.

edit:
uploaded is a version where the paramters is fixed to it's original state

HAPPY NEW YEAR ALL...





May i ask?

2cc train set need the tender(standard and condension) or not?
Will it effect the train?And what the usage of the tender

the tender is added to the steam engines that have tenders, you dont have to add them manually.

First of all, happy new year

I've found two bugs with the norwegian BM65:
- There is a small alignment bug (See the picture)
- The running costs are HIGHER when the train is STOPPED. (for instance, the RC is 19.000 when running, and 23.000 when stopped).

I use the 28th december version.

Hey, this is one great set and I love this, but theres 2 more things that could make this set better, More trains and Running sounds, though the running sounds might not rlly be needed I think more trains are needed, especially trains a few more trains from Canada Like the Go Trains and the VIA Rail Trains. (I think GO Transit uses FP59's for their locos)

Also, is there anyway to make it so that Monorails can be built over roads to make Elivated Rails like in various Cities around the world (eg, Chicago) or under the ground like subways like some off those Metro Locos r suppose to be for.

Ohs,i find more greater.
I hope this is a bug.

LegendDragon wrote:Ohs,i find more greater.
I hope this is a bug.

Once you start mixing trainsets that aren't designed to work together, all bets are off I'm afraid.

Different sets usually don't work together. Ok, you can use them next to each other in one game in OpenTTD, but an engine from one set, should have coaches from the same set attached.

dbkblk wrote:First of all, happy new year

Right back at ya!

dbkblk wrote: I've found two bugs with the norwegian BM65:
- There is a small alignment bug (See the picture)
- The running costs are HIGHER when the train is STOPPED. (for instance, the RC is 19.000 when running, and 23.000 when stopped).

Crap! I thought I had, or rather, I hoped I had removed all bugs by now, but they keep on coming. I've found a couple of them myself lately, so there are probably a few more out there as well.
Iore lack a sprite when standing still
A couple of metros have the wrong running cost base, makeing them cost ~5000 and not ~25000 to run

NekoMaster wrote:Hey, this is one great set and I love this, but theres 2 more things that could make this set better, More trains and Running sounds, though the running sounds might not rlly be needed I think more trains are needed, especially trains a few more trains from Canada Like the Go Trains and the VIA Rail Trains. (I think GO Transit uses FP59's for their locos)

We always want more engines, but they dont grow on trees unfortuneately.

NekoMaster wrote:Also, is there anyway to make it so that Monorails can be built over roads to make Elivated Rails like in various Cities around the world (eg, Chicago) or under the ground like subways like some off those Metro Locos r suppose to be for.

Not other then makeing certain tricks. Either with tunnels (without signals) or otherwise. There are plans to make a stationset that looks like buildings or a shopping mall or similar, but that is not finished yet (nor started afaik) And on a sidenote:
I've played a lot with cargodest lately, and it seems like the highest/normal running costs are way to high, and the easy ones (half cost) should be the normal ones. I should then make a parameter to make it even easier and thus also harder.

Running cost should be low for those who prefer to make some nice network which looks nice, rather than making the most profitable network.

What about the idea to have the default very low running costs (as Purno suggests), but have a cost parameter which acts as a multiplier to the default, very low running costs. Provided that parameters can go from 1 to 256 (or something like that), you can have people play with running costs 256 times as expensive as the easy, default mode. Everybody could be happy and no specific difficulty tuning would be needed as everybody can do that for him/herself.
Or is this approach somehow fundamentally flawed?

Regards,
pm

not fundamentally flawed, but it can be done _something_ like that.

Default could be a _set_ value, perhaps the current "easy mode". As that seem (to me) to be a nice balance between cost and challange, atleast in cargodest. Then it can be halved like 3 times (half, 1/4th and 1/8th cost), and also multiplied like 3 times (2x, 4x, 8x).


And another thing i've been thinking about:

The current TGV Atlantique, could not that be a "generic" (1st/2nd gen, they look pretty much the same) TGV, witch stats that evolve over time. After all, the first TGV came out aprox 1980, but had a much lower top speed (220 or 240kmh, and then upgraded to 270 aprox 1990, and 300kmh aprox '95) then the current one, but afaik have the old(est) ones been upgraded been upgraded to the current 300kmh.

???

planetmaker wrote:Or is this approach somehow fundamentally flawed?

Not at all.

IMO, a good approach (or maybe the best approach) would be to balance the cost against the standard TTD vehicles and then make a parameter to manually set the base cost multipliers (eiter one parameter for all base cost or seperate parameters as you see fit) and setting the default to either 08 or some higher value if you want to make the vehicles more expensive by default.

If you can't fit all costs in the default range (i.e. there are engines far more powerful than the default engines in the set), pick another default base cost multiplier while keeping the parameter thingy. That way, users can make it as hard or as easy as they like for themselves.

the only problem foobar, is the fact that i use two different "schemes" regarding running cost.

one of them go much higher, but with a "bad" resolution (for example 1000£ per step), and one with a much better resolution, but this one only go to aprox 10% of the first one. if that made sense

in other words:
steam based go from 0 to 25k in hard (game difficulty) in roughly 100£ steps
electic based go from 0 to 250k (ish) in roughly 1300£ steps

so engines that requite more then 25k i use electric based running cost, and the ones with less running cost (mainly MUs and lower power/speed engines) use steam based running costs.

DJ Nekkid wrote:the only problem foobar, is the fact that i use two different "schemes" regarding running cost.
steam based go from 0 to 25k in hard (game difficulty) in roughly 100£ steps
electic based go from 0 to 250k (ish) in roughly 1300£ steps

ok, so I understand the problem is that for the vehicles with cheap running costs, you'll get overflows, if the multiplier is set too high?

My primitive understand is to leave that scaling as it is (or maybe downscale it a bit) - and only then multiply it with the given parameter, irrespective of the initial scaling. From your posting I gather that things cannot be done that simple, e.g. the multiplier (100 resp. 1300) cannot be just modified afterwards?
E.g.
SteamBaseScaling = 100$
ElectricBaseScaling = 1300$
SteamRunningCostScaling = SteamBaseScaling * param
ElectricRunningCostScaling = ElectricBaseScaling * param
and each train then has
RunningCost = RunningCostValue * SteamRunningCostScaling
(or ElectricRunningCostScaling, whatever is appropriate).

and you could keep all train values at the very same they are. Of course it may be considered to adjust SteamBaseScaling and ElectricBaseScaling to lower values, e.g. 25$ and 425$ respectively.

Regards,
pm

Well, you could still use that parameter idea, it's just that you baseline is different than the TTD default.

You first need to establish a default for the set, regardless what base cost you have to use for that. So in fact just do whatever you've been doing, just tweak the prices until you think they're right. In the end you end up using a few base cost multipliers. Lets' say 09 and 0C.

Now because 09 is your lowest value, you could use that as the default for the parameter setting. To get to 0C, just add three to the parameter value. So if a user sets the parameter to 08, the default 09 becomes 08 and the 0C becomes 0B, thus dividing all costs by 2.
In pseudocode: And with that, users can make it as easy or as difficult as they like. You might want to enstate a ceiling for the parameter value though, or else you might end up with costs as big as ERROR:OVERFLOW.

Bug?

Probably I'm just blind, but: what exactly shall be the bug? The hopper is capable of holding granular material like Maize, Ore, Coal,... - which are different cargo depending upon climate. And different cargo capacities and wagon weights for different styles - why not? It might be argued, though, that the short version of the hopper should weigh less than the self discharging. But that may well differ in RL, too.

planetmaker wrote:Probably I'm just blind, but: what exactly shall be the bug? The hopper is capable of holding granular material like Maize, Ore, Coal,... - which are different cargo depending upon climate. And different cargo capacities and wagon weights for different styles - why not? It might be argued, though, that the short version of the hopper should weigh less than the self discharging. But that may well differ in RL, too.

And yet the hoppers default to that black sludgy liquidy stuff that comes out of the ground (oh yeah, OIL!) rather than granular materials (although if we're getting down to the atomic scale, it could be granular). I think that's the bug, not the weights/capacities.

Right. I didn't notice that