IRC logs for #openttd on OFTC at 2011-07-30
⏴ go to previous day
00:17:11 <Kazune> hello, I'm having an issue with music on openttd 1.1.1. I'm running ArchLinux, I have timidity++ and freepats installed. The jukebox just skips through all the songs, but it plays it if I run it as root.
00:19:16 <Eddi|zuHause> i'm not sure how anyone here can help you with that, as it's clearly an issue with your distribution/setup
00:19:37 <Kazune> just asking, in case someone had that problem
00:20:20 <Eddi|zuHause> you're better off asking in your distribution channel, though, or a timidity channel if that exists
01:11:17 <Eddi|zuHause> dear cat. do you mind if i want to use this bed for my own now?
02:26:29 *** rhaeder has joined #openttd
02:37:40 *** DJNekkid has joined #openttd
02:37:40 *** KingJ- is now known as KingJ
04:56:22 *** Eddi|zuHause has joined #openttd
05:48:11 *** sla_ro|master has joined #openttd
06:23:19 *** Kurimus has joined #openttd
06:44:39 *** frosch123 has joined #openttd
06:50:18 *** JVassie has joined #openttd
06:58:55 *** George|2 has joined #openttd
07:04:31 <frosch123> yay, translators are again translating wiki article of advanced settings which no longer exist
07:18:26 <planetmaker> hm, the openttd wiki doesn't feature the ref extension
07:30:49 *** DayDreamer has joined #openttd
07:38:19 *** Progman has joined #openttd
07:38:45 <CIA-2> OpenTTD: planetmaker * r22694 /trunk/src/music_gui.cpp: -Cleanup [FS#4579]: Remove unused but confusing widget
08:07:52 *** Alberth has joined #openttd
08:07:52 *** ChanServ sets mode: +o Alberth
08:31:22 <Terkhen> hmm... there was a thread about problems creating realistic heightmaps in the scenario subforum and no one mentioned the tutorials on the general openttd subforum sticky :/
08:33:43 <planetmaker> hm... what about rather moving that info into the wiki?
08:33:48 <planetmaker> it's easier found there, I guess
08:33:55 <planetmaker> or at least linking it there
08:33:59 <planetmaker> is there such page?
08:35:09 <Terkhen> besides, there are a lot of different tutorials in the sticky :P
08:35:27 <Terkhen> I made one which works fine, but it requires to use the console :P
08:36:25 *** Vikthor has joined #openttd
09:02:37 <frosch123> Terkhen: noone reads stickies
09:03:16 <frosch123> including the mods, else they would have unstickied celestar's balancing branch 2 years ago :p
09:04:09 <frosch123> though maybe it catches some reappearing new topics in the suggestion forum
09:20:29 <frosch123> damn, we have a emoticon template on ottd wiki, and it is even used quite often
09:29:37 *** Progman has joined #openttd
09:45:44 <krinn> this hide the whole option or just disable it ?
09:48:56 <JVassie> is it me or are nutracks not on bananananananas?
09:49:58 <JVassie> searching for nu only shows manual industries
09:51:47 <frosch123> Zuu: the call to ViewportAddString uses st->owner == OWNER_NONE, maybe use that instead of < MAX_COMPANIES
09:52:25 <frosch123> also there is no \n after if (..) when there are no {}
09:54:40 <planetmaker> JVassie: NuTracks is on bananans
09:54:49 <planetmaker> maybe you have a too old OpenTTD version, though
09:55:32 <planetmaker> that can be anything ;-)
09:55:57 <JVassie> cant remember which chillcore PP it is
09:56:03 <JVassie> one of his versions :p
09:56:24 <JVassie> i apepar to have nutracks 1.0.0 anyway though
09:57:11 <Zuu> frosch123: Using OWNER_NONE would mean that if ever a station would be owned by a town, it wouldn't be shown
09:57:27 <Zuu> As there is also a OWNER_TOWN
09:57:36 <frosch123> Zuu: but the drawing code cannot handle that either
09:57:43 <frosch123> what colour should it pick
09:58:00 <frosch123> i mean, just use the same condition for the same test :)
09:58:44 <Zuu> Regarding \n and { }, I just followed the coding style of the if-statement above that "continue;" if drawing of station/waypoint signs has been disabled.
09:59:55 <frosch123> + if (_settings_client.gui.show_only_own_signs) <- that one in signs_gui
10:00:14 <frosch123> viewport.cpp is fine
10:00:17 <Eddi|zuHause> not all code follows the code style :)
10:00:52 <Zuu> frosch123: Ah, okay. I'll fix that.
10:01:09 <frosch123> Eddi|zuHause: it gets harder if you involved in multiple projects
10:04:14 <Eddi|zuHause> the "idle" performance of the game is hopelessly bad...
10:04:24 <Eddi|zuHause> paused and minimised, it uses ~20% cpu
10:04:59 <Alberth> paused doesn't mean much, since you can even build in that mode :)
10:05:23 <planetmaker> sure you can. But doing nothing and 20% cpu?
10:05:51 <planetmaker> it basically means that just waiting for input and checking whether anything needs redraw uses 20%
10:09:46 <planetmaker> indeed quite a bit nicer from my POV, JVassie
10:10:19 <krinn> Eddi|zuHause, top report 7% cpu usage when in title screen, it is because of the map size ?
10:12:14 <JVassie> why would nutracks have house sprites included? :x
10:14:24 <JVassie> just lookign at all the sprites id have to change :x
10:15:03 <JVassie> in theory, if I replaced every sprite, then the 3rd rail could be at the top in the __ view, yeah?
10:16:24 <Eddi|zuHause> JVassie: i think the 3rd rail is too close to the real rail
10:17:05 <JVassie> ill do a version with 1px further away, 2 secs
10:21:28 <JVassie> you can see a comparison of different distances away from the real rails
10:21:37 <JVassie> smallest a to largest d
10:22:25 <JVassie> a is the same as the previous version btw
10:24:22 <Eddi|zuHause> ah, i'd go with 'd' then...
10:25:12 <Eddi|zuHause> oh, and i think you can check the tile x/y position in varaction 2, so you can make opposite sides like for catenary
10:25:23 <JVassie> oooh now that would be cool
10:25:45 <JVassie> can you do somethign similar (but opposite) for stationS?
10:25:53 <Eddi|zuHause> i'm not sure how crossings are done, though
10:26:45 <JVassie> as obviously in stations the 3rd rails are on the far side from the platform
10:26:57 <krinn> anyone made chaotic rail design for early train usage yet ? all i saw are always perfect (like some missing plank that horizontally fix the rail, or a uncommon plank design) like early days when men were need to repair & check the rails and so many rails were more or less damage and chaotic
10:26:58 <Eddi|zuHause> i don't think you can sensibly do that
10:27:48 <Eddi|zuHause> i mean without providing a patch that won't be accepted ;)
10:27:59 <JVassie> platform sides can be 'variable'
10:28:10 <JVassie> and the station wont know which side the platform actually is
10:28:17 <Eddi|zuHause> most station graphics have platforms on both sides
10:28:53 <CIA-2> OpenTTD: rubidium * r22695 /trunk/src/network/ (core/address.cpp core/address.h network_udp.cpp): -Fix [FS#4697]: mark addresses that could not be resolved as 'do not resolve anymore' as well, instead of trying to resolve them each and every time the address is accessed
10:30:09 <JVassie> 1.1.0 is latest not 1.0.0 >.>
10:30:30 <Eddi|zuHause> that 3rd rail looks like the monorail painted over the rails...
10:30:57 <Eddi|zuHause> and i hate those new nutrack rails
10:31:17 <Eddi|zuHause> they are too greasy, and have too little difference between them
10:32:06 <JVassie> i dont think from the actual angle you look at ottd tracks
10:32:29 <JVassie> the 'little black bits' the 3rd rail sit on shouldnt be (very) visible
10:34:43 *** IchGuckLive has joined #openttd
10:35:22 <IchGuckLive> Hi is there a trevel minimum for the 1.1.2 version
10:36:01 <IchGuckLive> ok then i will trevel 8 tiles
10:42:04 *** andythenorth has joined #openttd
10:42:43 <andythenorth> I tried to pm you, but I can't post to forums :P
10:43:11 *** LordAro has joined #openttd
10:44:59 <CIA-2> OpenTTD: rubidium * r22696 /trunk/src/network/ (network.cpp network_gui.cpp): -Fix: don't requery the servers when the server list window isn't opened
10:48:41 <LordAro> frosch123: regarding Template:Feature period on the wiki: it seems that the 1.1 'check box' does not show up unless defined explicitly by a template use. then it's displayed by all templates
10:58:22 *** Biolunar has joined #openttd
11:03:34 *** Chillosophy has joined #openttd
11:06:52 <frosch123> LordAro: actually the feature and feature period templates should be merged
11:07:10 <frosch123> but it annoys me that they are all translated :p
11:07:30 <frosch123> so maybe it needs some generic template with takes the translated caption as parameter
11:07:36 <LordAro> yeah, probably, but (as you saw from my attempt at Template:Forum) i'm useless at mediwiki templating :)
11:10:30 <LordAro> it doesn't help of course that the mediawiki software is so outdated... nudge, nudge ;)
11:11:15 <andythenorth> server times out on me
11:11:34 <andythenorth> anyway - I wanted to say I'm happy to do the helicopter load sprites if not done
11:11:52 <frosch123> LordAro: it is not as outdated as ttdp wiki was
11:12:12 <Pikka> well, I've done a box already, I can send it over if you want a look :)
11:12:14 <frosch123> btw. what would a newer wiki offer which is so much needed?
11:12:36 <Pikka> but not via forum pm? :)
11:12:49 <andythenorth> just can't post anything
11:15:38 *** TWerkhoven has joined #openttd
11:16:56 <andythenorth> I'd tell orudge - but I can't post to do so :D
11:20:13 <orudge> are you connecting via IPv6?
11:20:54 <andythenorth> I don't think so, but let me see if it's specific to my isp
11:21:31 <orudge> [12:10:25] <LordAro> it doesn't help of course that the mediawiki software is so outdated... nudge, nudge ;) <-- if you mean tt-wiki, you'll have to wait for Debian Wheezy for anything to change.
11:21:35 <andythenorth> orudge: yeah it works on a different connection
11:21:42 <orudge> To be fair, the OpenTTD wiki is still on debian lenny, tt-wiki is at least on squeeze :)
11:21:45 <andythenorth> must be specific to virgin media
11:22:47 <orudge> Wheezy ought to be out in two years or so, though ;)
11:32:23 <andythenorth> Pikka: do you mind if I include the skycrane in HEQS?
11:33:53 <Pikka> not at all, I can ship you the code if you want it to be av8-identical
11:34:13 <andythenorth> that would help - I just realised I don't want to learn to code planes :o :p
11:38:04 <frosch123> identical vehicles in multiple grfs? :p
11:38:25 <frosch123> what message shall i use when closing bug reports to ottd about that?
11:38:49 <Pikka> we shall use our cleverness to make it only appear once
11:39:37 <Pikka> viz I shall set a parameter in av8 2.0 which heqs can check for, and disable its version of the helicopter accordingly?
11:39:41 <frosch123> i guess such a scenario would not even work in grftopia
11:43:44 <planetmaker> hm... why now planes in heqs, too?
11:43:49 <andythenorth> I have been told n times that including multiple vehicle types in heqs is a bad idea
11:43:53 <andythenorth> but it amuses me
11:44:16 <Eddi|zuHause> grfs are already plugins
11:44:37 <Wolf01> like MB one for db set
11:44:57 <Eddi|zuHause> Wolf01: that's a bad idea in general
11:45:01 <andythenorth> maybe we just leave it in AV8 :P
11:45:05 <Eddi|zuHause> Wolf01: and you mean "addons"
11:45:24 <Eddi|zuHause> andythenorth: at least provide parameters "disable <X> vehicle type"
11:45:29 <Wolf01> maybe, plugin, addon, the same for me :D
11:45:32 <andythenorth> Eddi|zuHause: I would / already do
11:46:05 <andythenorth> but I am not convinced by parameters - I had not understood that players can't change them during gameplay
11:46:12 <Eddi|zuHause> Wolf01: the dbset extension is only because he didn't have anything that was releaseable on its own
11:46:38 <Eddi|zuHause> andythenorth: how is that relevant?
11:47:03 <andythenorth> because hiding / showing vehicles by parameter is a stupid reason to have to start a new game
11:47:17 <andythenorth> it literally sucks to have to restart because a vehicle is missing
11:47:29 <andythenorth> and there's likely no good fix for that
11:47:43 <andythenorth> unrelated - it also sucks to have to restart to change running costs
11:48:22 <andythenorth> I have always been somewhat against parameters and increasingly I think they should only be used for extreme cases
11:49:21 <andythenorth> I am inclined to rebalance HEQS against base vehicles and remove the cost parameters
11:49:59 <andythenorth> I think vehicle sets with their own running cost parameters is a bad pattern
11:50:30 <Eddi|zuHause> changing base costs was never a good idea...
11:51:06 <andythenorth> it was prior to engine pool
11:51:12 <Wolf01> <andythenorth> and there's likely no good fix for that <- custom configurator interface based on grf data
11:52:17 <andythenorth> can't remove a vehicle type that has instances in game though
11:52:26 <andythenorth> and configurator would have to be MP safe
11:54:37 <andythenorth> Eddi|zuHause: what are the reasons for needing to disable <X> vehicle type?
11:55:25 <Eddi|zuHause> andythenorth: like "i use heqs only because of the trams", then i'd want to disable the dump trucks, the planes, etc.
11:55:43 <andythenorth> and also for MP...?
11:55:59 <andythenorth> because it seems common to 'ban vehicle type X' on MP?
11:56:01 <Eddi|zuHause> i have no opinion about MP
11:56:19 <Pikka> changing base costs is much better now than it used to be
11:56:28 <Pikka> because it's on a per-grf basis
11:56:37 <andythenorth> I had a massive oversight though
11:56:51 <andythenorth> I've been happily changing running costs in game using parameters
11:56:55 <andythenorth> but users can't do that
11:57:33 <Pikka> also, base vehicles running costs suck :)
11:57:39 <andythenorth> who wants to play a few test games to find whether the HEQS costs parameters should be set to '1/2', '1', '2' etc?
11:57:49 <andythenorth> it's a crap shoot :P
11:58:17 <andythenorth> I think it's a misfeature
11:58:51 <andythenorth> cost multiplier parameters on newgrfs
11:59:04 <Pikka> yes, it is a very silly idea
11:59:24 <andythenorth> I thought it was great - but I didn't know that users can't change parameters during gameplay
11:59:41 <Pikka> they can if they try hard enough
11:59:55 <andythenorth> but mostly they'll just do something else :P
11:59:55 <Ammler> servers 1.1.1 are lost
11:59:58 <Pikka> anyway, there's already an option for people to dial the running costs up and down :P
12:00:01 <Alberth> Ammler: except for some chinese characters in some names, the page seems to work
12:00:26 <Ammler> Alberth: you have 1.1.1 listed?
12:00:35 <Eddi|zuHause> Pikka: the main problem is balancing vehicle costs between grf sets
12:01:04 <Pikka> I find I don't have that problem
12:01:18 <Ammler> it looks like "current stable" is broken
12:01:30 <Eddi|zuHause> Pikka: if i use GermanRV and HEQS, both have completely different running costs
12:01:50 <Alberth> but I do have 1.1.2-RC1
12:01:56 <Eddi|zuHause> or if i use eGRVTS and HEQS, it's different again
12:01:59 <Pikka> well, don't use germanrv and heqs then :P
12:02:29 <Pikka> didn't we have this discussion in PM recently? :P
12:02:34 <Ammler> Alberth: last time I checked, the page was grouped in latest stable first and then the rest
12:02:50 <Eddi|zuHause> "we" have been having this discussion for years :p
12:03:07 <Pikka> yes. but a group of us discussed it particularly not long ago :)
12:03:27 <Alberth> Ammler: I don't look at that page ever :)
12:03:32 <andythenorth> match to default costs + cost parameters is the current winning conclusion iirc
12:03:39 <andythenorth> but I don't like cost parameters :P
12:03:53 <Ammler> I did by accident, that is why I am not sure if it is broken :-)
12:05:27 <Pikka> the fact that my vehicle grfs all use variable running costs means they're not going to line up with other people's grfs in any case.
12:12:19 <planetmaker> which is much more so an argument for a parameter to allow people to adjust running and purchase costs
12:12:36 <LordAro> Alberth: about the 'name of grf in readme window' suggestion: i went looking for examples of how to do this, but found that none of the newgrf windows do it, nor the ai settings window. should i not bother?
12:12:48 <planetmaker> it's a shame if otherwise good newgrfs just don't play along eachother "just because"
12:14:01 <Alberth> LordAro: perhaps the other windows are wrong too? ;)
12:14:28 <LordAro> :) yeah, the other thought was a new patch on the queue that added it to all of them
12:16:19 <LordAro> y/n? but it at the bottom of the list of things todo?
12:17:53 <CIA-2> OpenTTD: rubidium * r22697 /trunk/src/town_cmd.cpp: -Fix [FS#4694-ish]: when building a house it could be built at the wrong place if multitile houses failed some tests
12:17:59 <Alberth> It is definitely a separate patch for the other windows. If you do it, do it before, and add it to your window immediately.
12:18:50 <Alberth> Whether it is good or not, I don't know, I have to see how it looks first, and for that the patch needs to run, which so far, it doesn't
12:20:25 <andythenorth> the cost parameter is only of use to quite expert users
12:20:34 <andythenorth> maybe it's unfair to call it a misfeature
12:20:44 <andythenorth> but it's unlikely useful to the majority of players
12:22:25 <LordAro> Alberth: ok, in that case, i need help on making the patch run :) because i'm stuck
12:24:47 <Alberth> you'll have to explain what you need, as "write patch; compile; ./openttd" is probably too global help on making it run :)
12:27:27 <LordAro> well, the two major problems at the moment are high cpu usage when viewing readme, and 'utf8 unknown string command character 9/13' error messages
12:27:34 <LordAro> i have no idea how to fix either
12:28:50 <CIA-2> OpenTTD: frosch * r22698 /trunk/src/object_cmd.cpp: -Fix [FS#4694]: Only insert cleared object tiles into _cleared_object_areas if clearing actually succeeds, else subsequential tests of the same tile will be skipped and considered successful.
12:30:37 <planetmaker> andythenorth: why is it not useful to the majority?
12:30:58 <planetmaker> Most will use default settings, yes. And most will assume that different NewGRFs play along without config
12:31:44 <planetmaker> But the chance to set costs... is not a miss-feature IMHO. A maglev needs to cost more than the steam train ;-)
12:33:17 <Pikka> so does that mean I need to allow for people who make grfs with ridiculously cheap maglevs?
12:34:36 <Alberth> LordAro: do you read your saved logs? I am *very* sure I explained about not copying 9/13 characters
12:34:39 <planetmaker> But what it IMHO means is to take the default prices as a guide for default price levels
12:34:55 <Pikka> what if we think the default prices are rubbish?
12:35:17 <planetmaker> global price levels are easily changed by a global base cost newgrf
12:35:27 <Alberth> LordAro: as for high CPU use, you probably must make a list of lines instead of relying on DrawStringMultiLine() or whatever the function is called
12:35:27 <planetmaker> and then it works for ALL newgrfs and you don't get an imbalance
12:35:51 <Pikka> vehicle base cost multipliers are grf specific these days
12:36:03 <planetmaker> Pikka: yes and no :-)
12:36:10 <planetmaker> they're grf-specific, if you define vehicles
12:36:14 <planetmaker> they're global, if you don't
12:36:30 <planetmaker> did you ever try a global base cost grf?
12:36:34 <Pikka> I don't want to make it so that in order to get the effect from my grfs that I want, people need to a) download another grf, and b) set a parameter correctly
12:36:51 <Pikka> because then about 0.01% of people will get the gameplay experience intended
12:36:55 <planetmaker> the order is unharmed and of no consequence, if you define vehicles. There they're local
12:37:03 <planetmaker> the base cost grf then changes everything
12:37:55 <Alberth> Pikka: maglevs are cheap whatever you do, as by that time I am more than wealthy
12:37:59 <planetmaker> My personal suggestion would be: balance your vehicle grfs to the default (yes) and release one pikka-cost grfs which sets your idea of how price levels should be
12:39:43 <planetmaker> note 'balance against default vehicles' does not necessarily mean to always use a base cost factor of 8 (unchanged) but can for maglevs also mean to use something higher or for horse carriages to use something lower
12:40:40 <Hirundo> IMO, 'balance against default' should be one of the options, but not necessarily the default one
12:41:11 <Pikka> I'm sure that just as different grf authors have come up with different definitions of what costs make for good gameplay, they would come up with different definitions of what is "balanced against the default vehicles" too.
12:41:11 <Hirundo> Getting a good 'out of the box'-experience is important also, which requires somewhat sane prices
12:41:45 <planetmaker> Pikka: yes, there certainly can be different definitions of 'balanced against default'.
12:42:04 <planetmaker> but they surely are not as far off-scale as the different ideas on how cost and running cost levels in general should be
12:42:35 <planetmaker> And yes, the option to balance against default vehicles need not necessarily be default. But IMHO it would be great to have it an option
12:42:40 <andythenorth> I dislike the cost parameter for two reasons (a) players can't change it in game (b) "0.5x, 1x, 2x" <- but what does it mean?
12:43:01 <krinn> why not 2 grf: one for cost, one with the gfx ? Costs lovers download them both, "classic" users download only the gfx one
12:43:25 <planetmaker> krinn: that's what base costs do... But you'll still have to adjust relative costs...
12:43:50 <planetmaker> and to split that for a single newgrf is somewhat pointless.
12:44:03 <Alberth> krinn: if I play with 2 sets, I'd have two cost grfs, which of course will not have the same idea about costs
12:44:04 <planetmaker> if the newgrf itself allows adjustment via parameter
12:44:18 <Rubidium> making everything twice as costly in OpenTTD is easy!
12:44:32 <Rubidium> custom currencies FTW
12:44:40 <Alberth> krinn: if you balance against something common, such as default vehicles, you need only one cost grf
12:44:57 <krinn> Alberth, maybe, but this way you can have a thread which will drove "costs loving player" and they could set a standar for their own gameplay...
12:45:11 <Alberth> Rubidium: but then I get also twice as much money for cargo delivery
12:45:26 <planetmaker> krinn: please have a look how base cost newgrfs work
12:45:34 <Rubidium> Alberth: yes... cargo delivery costs twice a much
12:45:47 <krinn> planetmaker, yep speaking of something i don't know
12:46:28 <planetmaker> yes. If you knew you'd see your suggestion is... more difficult and troublesome than can already now be done
12:47:16 <krinn> it's just bad to have a newgrf with fancy real nice gfx in it, that isn't usable because the author is another fan of "if it's maglev, kill it"
12:49:00 <Pikka> well if what you're into is building super maglev circuits, you're not going to see 95% of the grf anyway, so why bother with it?
12:49:43 <krinn> because they are at end of game, why would i don't see 95% of the grf ?
12:50:38 <Pikka> if you're /not/ into building super maglev circuits and are going to play with the whole grf, then how does a lack of maglevs make it unusable?
12:51:27 <krinn> because maglev are within the 100% too, why would you then wish remove the 5%
12:53:02 <Pikka> if you're making a "realistic" set maglev is very hard
12:53:28 <krinn> i don't care realistic, and if one care about realism, then why wouild maglev should cost more ?
12:53:35 <krinn> in life it's not how it work:
12:53:43 <LordAro> Alberth: 9/13 characters: yes, you did explain that i should use "!IsPrintable(c) || c != '\n'" stuff, but i do not know how to get from readme_text with 9/13 characters, to readme_text without. i am presuming its something to do with strcpy, but beyond that, i dn't know
12:53:59 <krinn> when tech goes out, it cost a lot, but prize goes down fast
12:54:17 <Pikka> who said maglev should cost more?
12:54:35 <Alberth> LordAro: no function, a for loop over the characters
12:54:50 <Pikka> I'm saying the reason why I'm 'another fan of "if it's maglev, kill it"' is that maglev is difficult to do in a realistic set
12:56:21 <Pikka> adding a whole fictional rail system to an otherwise real-world-based set in a way that doesn't feel tacked on is not an easy thing to do
12:56:43 <Pikka> one day I will make a seperate maglev/monorail only futuristic set that's balanced against my other grfs
12:56:50 <Pikka> but that day is not today :)
12:57:33 <planetmaker> well... I may still wish for a parameter which allows me to use your NewGRFs with unmodified base costs ;-)
12:58:31 <planetmaker> when is Christmas?
12:59:46 <planetmaker> Nah, honestly, just two parameters to adjust base cost and base running cost would make it MUCH more easy to create well-balanced maps :-)
12:59:53 <planetmaker> so. enough lobbied for today :-P
13:00:59 <LordAro> Alberth: ok, i can handle having to delete characters in the char, but how do i move all the other characters? e.g. char = [1,2,3,4] if i remove '3' i get char == [1,2,(?),4] how would i move '4' (and any other characters beyond that) into the right space?
13:01:28 <andythenorth> planetmaker: I will re balance HEQS against default vehicles I guess
13:01:36 <andythenorth> dunno about FISH
13:01:53 <planetmaker> But if you have a good suggestion, Pikka, on how to make it for average Joe easy to use arbitrary vehicle newgrfs along eachother - always welcome :-)
13:01:53 <planetmaker> I just know nothing better than bugging everyone to add these two parameters
13:01:53 <planetmaker> (or to add in the openttd-side per-newgrf config capability - but that'd be... somewhat insane, too
13:02:11 <andythenorth> so here's the thing
13:02:29 <andythenorth> does opengfx + RVs have a cost parameter?
13:02:48 <andythenorth> so I have HEQS and opengfx + RVs in my game
13:02:52 <andythenorth> both have parameters
13:03:01 <andythenorth> so both can be adjusted with respect to each other
13:03:06 <planetmaker> leave them untouched. And use a base cost grf ;-)
13:03:08 <andythenorth> what's the correct settings?
13:03:19 <planetmaker> but yes, they could. You'll have to know the correct settings
13:03:26 <andythenorth> and how do I test?
13:03:32 <andythenorth> I have to start playing a game
13:03:43 <planetmaker> set parameters, create map, check depot / purchase list
13:03:44 <andythenorth> then having played enough of it, I have to quit
13:03:47 <planetmaker> repeat. Ad nauseam
13:03:52 <andythenorth> then I have to roll the dice again
13:03:57 <andythenorth> it's a crap user experience
13:04:03 <planetmaker> nah, you don't need to play to adjust.
13:04:14 <planetmaker> Just create map, check. Re-create
13:04:19 <planetmaker> until it fits. Only then play
13:04:26 <planetmaker> everything else is stupid
13:04:35 <andythenorth> but that assumes you can forward-model the money you're going to make on routes
13:04:42 <andythenorth> which might vary by industry set or other things
13:05:07 <planetmaker> I'm talking about the relative costs of vehicles mostly
13:05:12 <planetmaker> that's easy to check
13:05:22 <planetmaker> absolute cost levels... that's indeed more difficult
13:05:27 <andythenorth> but still they might be the wrong costs for the game you want to play
13:05:52 <planetmaker> so, what's the option?
13:05:56 <andythenorth> because everyone can set costs - it's almost impossible to solve
13:06:28 <planetmaker> allow to configure costs on newgrf hardcoded, newgrf parameter, base cost parameter and openttd cost parameter, all at once?
13:06:32 <planetmaker> Not helping either
13:06:38 <andythenorth> so the solution is one-author(s)-provides-all-grfs
13:06:53 <andythenorth> so we're back to 'balance against base costs'
13:06:59 <planetmaker> That's not happening. As such: balance against...^yeah
13:07:15 <andythenorth> which might as well be 'stop dicking around letting newgrfs set as many costs'
13:07:56 <andythenorth> there are n valid sets of costs which will result in a worthwhile game
13:08:07 <andythenorth> costs need to be coherent across multiple aspects
13:08:20 <andythenorth> how many cost universes do we currently Have?
13:08:34 <Pikka> so what do you do when that valid set of costs doesn't fit within the default vehicles' range of possible costs?
13:08:59 <andythenorth> numerous of these are incoherent though
13:09:13 <andythenorth> only base world and pikka world have enough stuff done to be coherent
13:09:42 <Rubidium> don't forget a Rubidium world...
13:09:51 <planetmaker> Pikka: as said: writing a newgrf can mean to adjust the base costs still. But the price should be adjusted to match defaults.
13:09:56 <LordAro> Alberth: copying how? i've done some searches, but there's nothing (all about using <cstring>)
13:09:57 <Rubidium> there where everything will be Rubidium coloured ;)
13:09:58 <andythenorth> Rubidium when did you last ship a (non-trunk) grf?
13:10:18 <LordAro> again, i apologize about being entriely out of my depth :L
13:10:23 <planetmaker> I.e. a super-duper-mega train from year 3000 may still be at base cost +2 to match the defautl trains
13:10:57 <planetmaker> currently you also have to do with one base cost settings per newgrf, nothing changes there. Just the 'level' which you adjust against
13:11:03 <Rubidium> which means greyish white and red
13:11:05 <planetmaker> the general level of costs
13:11:08 <Pikka> I still prefer my grfs, they're more interesting. :)
13:11:17 <andythenorth> maybe I just change the parameters in my grfs
13:11:26 <Alberth> LordAro: dest = buffer; for (char *src = buffer; *src; src++) *dest++ = *src;
13:11:35 <Alberth> LordAro: ie do many assignments
13:11:37 <andythenorth> 1 setting. 2 options: 'default costs', 'pikka costs'
13:11:48 <planetmaker> Pikka: yes, that most probably is true - I don't even disagree there.
13:11:51 <andythenorth> FISH is matched to pikka costs (also assuming FIRS use)
13:11:59 <planetmaker> My whole argument is only for the sake of interoperability of newgrfs
13:12:17 <planetmaker> And the only really common base line is: default vehicle costs and running costs.
13:12:17 <Pikka> to take av8 as an example
13:12:51 <planetmaker> The price levels (which you iirc set to 0 / +2 (purchase / running)) can then just as well be set by a global cost grf.
13:12:56 <Rubidium> andythenorth: does being a co-author count?
13:13:00 <planetmaker> I don't argue really to change your relative balance
13:13:09 <Pikka> the default aircraft have their costs really squashed together, as well as low, and I have a lot more small aircraft in my grf than in the default
13:13:44 <planetmaker> yes. I understand that you stretch the costs more. I'd actually not go that far to argue against that.
13:13:57 <Pikka> it would be very difficult, if not impossible, to "balance" my concorde against the default concorde, whille maintaining sensible prices at the lower end
13:13:58 <Rubidium> andythenorth: and does it count when bits of said NewGRF have their origin in openttd[dw].grf?
13:14:02 <planetmaker> I'd only argue to adjust the "average" plane to match the "average" default plane
13:14:13 <planetmaker> more cannot be asked.
13:14:48 <andythenorth> I suspect it's easier to just ask players to make simple(r) choices
13:14:56 <planetmaker> Yes, the result will be that your concorde and the default concorde might be off by a factor of 2?
13:15:02 <planetmaker> But not by a factor of 20
13:15:29 <Pikka> default costs $21k a year, mine costs $236 a year
13:15:51 <Eddi|zuHause> you have to consider inflation
13:16:03 <planetmaker> yes, but you changed the running base cost to +2 relative, right?
13:16:19 <Pikka> eddi: numbers are with inflation turned off
13:16:37 <planetmaker> if you made that 0 relative, then it'd be a factor of 3.
13:16:47 <Rubidium> there's another setting that influence (some) prices... what was it?
13:17:04 <andythenorth> construction cost?
13:17:05 <Eddi|zuHause> difficulty level
13:17:09 <planetmaker> the base running cost setting stretches the scale.
13:17:20 <Rubidium> ah yes, andy's right
13:17:44 <andythenorth> even a stopped clock tells the right time twice a day
13:18:15 <Rubidium> andythenorth: not necessarily...
13:18:35 <Eddi|zuHause> not when it's blinking 0:00, and at exactly 0:00 the blinking is off :p
13:18:41 <Rubidium> could also do it just once or thrice
13:19:30 <andythenorth> this is much harder because the default costs are all wrong
13:19:42 <andythenorth> so balancing RVs against them is nonsense
13:20:13 <andythenorth> if the default costs weren't wrong, some of this mess would not be necessary
13:20:34 <andythenorth> for RVs, pegging to the baseline of default RVs is just stupid
13:20:54 <andythenorth> so there is no baseline for RVs. I used eGRVTS as my baseline for HEQS, but it's way too cheap
13:21:07 <andythenorth> mess mess mess :D
13:21:07 <Eddi|zuHause> andythenorth: how about you pick a handful of known grfs, and then make the parameters like "Running costs: {x2 (eGRVTS)|x1 (HOVS)|x1/2 (GermanRV)}"?
13:21:17 <Rubidium> the whole payment is wrong ;)
13:21:45 <planetmaker> Eddi|zuHause: that might be a guide. But what do you choose, if you have heqs, germanRV and egrvts
13:21:51 <krinn> it as sense if you intend to play fun and not realistic, and fun is primary goal of openttd
13:22:14 <Eddi|zuHause> planetmaker: that's the players fault.
13:22:55 <planetmaker> Eddi|zuHause: but that's the point. It must not be
13:23:01 <planetmaker> the grfs should just play along
13:23:09 <Rubidium> e.g. short trips shouldn't make busses totally profitless, and long trips shouldn't be massive profit makers
13:23:33 <Eddi|zuHause> planetmaker: that is impossible to achieve.
13:23:48 <andythenorth> it's not so hard to achieve
13:23:50 <planetmaker> relative balance among each set is one thing - that's very hard to agree upon
13:24:00 <andythenorth> (1) fix default costs for the ones that are broken (RVs, others??)
13:24:17 <planetmaker> But the relative costs of the newgrfs wrt eachother - that can be achieved
13:24:19 <andythenorth> (2) grf authors match to base costs, and/or to other schema (e.g. pikka-costs)
13:24:37 <Eddi|zuHause> planetmaker: it cannot. ever.
13:24:38 <Rubidium> so cargo would pay some base fare and something for distance, and a tiny speed component. Finally add a slightly bigger 'surcharge' when the speed is significantly above average for the class of vehicles
13:24:38 <andythenorth> players use difficulty setting to change base costs
13:25:16 <andythenorth> this seems solvable for once - bbl
13:25:32 <planetmaker> of course it can, Eddi|zuHause. Not to a factor of 2 or 4. But within that bounds: yes
13:25:37 <planetmaker> bye bye, andythenorth
13:26:00 <Eddi|zuHause> planetmaker: you cannot force grf authors.
13:26:26 <planetmaker> yes, one cannot. That's why I *argue* for people to use a quasi standard
13:26:33 <Alberth> except by changing the newgrf specs :)
13:26:34 *** TWerkhoven has joined #openttd
13:26:40 <Rubidium> which would be funny because... when you replace all trains with super fast trains, they won't make as much money anymore
13:26:47 <planetmaker> like you cannot force newgrf authors to also use the default cargo classes and labels. But they do
13:27:02 <Pikka> that's because it makes sense
13:27:13 <Pikka> but there's a number of different philosophies when it comes to pricing
13:27:31 <Eddi|zuHause> planetmaker: apples, pears.
13:27:52 <planetmaker> I do well understand that. And I'm not arguing against different pricing philosophies. I'm arguing for approx. similar price *levels*
13:27:52 <Pikka> for example, mb and george tend to favour very high purchase prices and lower running costs compared to other grf authors. how do you balance against that?
13:28:25 <Eddi|zuHause> planetmaker: it's a futile effort.
13:28:29 <planetmaker> The relative balance purchase and running costs is player's choice
13:28:48 <planetmaker> Eddi|zuHause: anything constructive?
13:28:57 <krinn> the result is easy: with too high concorde i cannot play the concorde and i'm sad to not see it when i could have a fast (concorde) looking aircraft when using stock game
13:29:03 <Eddi|zuHause> no. it's wasted thought power.
13:30:04 <planetmaker> not at all. If the main grf authors could agree to use comparable price *levels* - the biggest part of the problem is gone
13:30:30 <Pikka> why not have parameters for different vehicle speeds, power, capacities and introduction dates too for players who don't like that part of the grf either?
13:30:42 <Alberth> Pikka: sum the purchase cost + running cost over the entire lifetime, and balance that number w.r.t. default vehicles?
13:31:05 <planetmaker> ach. That's all not the point, Pikka
13:31:14 <planetmaker> People ususally just want "those nice vehicles"
13:31:30 <planetmaker> The exact purchase prices and running costs are of little importance as the economy is dead simple anyway
13:31:35 <Pikka> well, they can have them
13:31:38 <Rubidium> pff... alt-1 solves all pricing problems
13:31:54 <planetmaker> but what DOES impact game fun is if things are grossly out of proprotion among differently concurrently used sets
13:32:19 <Pikka> I'm going to go out on a limb here and say "no it doesn't"
13:32:35 <planetmaker> and the 'grossly-out-of-proportion' would be gone if there'd be somewhat a comon average price for each vehicle set
13:32:38 <Pikka> people who lump in every grf they can find don't care about details like that
13:32:58 <planetmaker> Pikka: it's not about that. Ach...
13:33:23 <planetmaker> But pretty please tell me how I shall play a European scenario with Dutch, German and UK trains?
13:33:33 <planetmaker> I can't. It will be fucked relative costs
13:33:36 <Alberth> Pikka: it happens much earlier. I only loaded the dutch train set, and the one engine costs 228,000, while default vehicles are around 20,000
13:33:41 <Rubidium> german trams + japanese trains + aviator planes + dutch rvs + spanish ships?
13:34:07 <Rubidium> (maybe contains ficticious sets)
13:34:10 <Alberth> with a max loan of 300,000 the choice is easy
13:34:10 <planetmaker> The argument "only crazy people mix newgrfs" is not an argument
13:34:23 <planetmaker> people generally do that. And many have a good reason for their choice
13:34:42 <planetmaker> so the argument is "how can in general the fun be enhanced"
13:34:55 <Pikka> planetmaker: you still haven't convinced me why I should put a lot of effort into making my grfs compatible with grfs with bad vehicle prices, including the defaults.
13:35:14 <Rubidium> but even when you have different types of NewGRFs, such as the ones I just listed, you want them to be equally balanced regardless the train NewGRF you use
13:35:32 <planetmaker> Pikka: for exactly those people who like to play elaborate scenarios. Like I just said, for example a European scenario.
13:35:43 <planetmaker> I cannot get grfs to agree on an even roughtly price level
13:35:51 <Pikka> any grf where the author has put half an ounce of effort into making the gameplay nice, including eGRVTS and andy's grfs, work reasonably well with my grfs
13:35:59 <planetmaker> even with the best effort save of adding openttd-side per-grf cost settings
13:36:02 <Rubidium> IMO if you want an elaborate scenario you don't care about the original vehicles, or do you?
13:36:57 <planetmaker> Pikka: I'm not arguing the *relative* balance of your costs
13:37:03 <Rubidium> you'd almost get the idea to make the scaling of vehicle costs against other sets configurable per NewGRF
13:37:18 <planetmaker> I'm *only* arguing about base cost levels
13:37:18 <Pikka> neither am I, planetmaker
13:37:42 <Rubidium> so the user can say: the vehicles from that NewGRF should be twice as high, and then you can balance sets a bit to your own liking
13:37:47 <planetmaker> and the general base cost levels IMHO are rather to the player - or an economy grf much better
13:37:56 <planetmaker> as you then can balance also the track and road costs
13:38:01 <Rubidium> e.g. they are too expensive, so you make them cheaper (as end-user)
13:38:04 <planetmaker> and you'd apply that to other vehicle sets as well
13:38:10 <Pikka> I'm saying that my aircraft need to have running costs 5-10 times the default vehicles in order to be interesting :)
13:38:31 <Pikka> ditto trains in UKRS, etc.
13:38:53 <planetmaker> Pikka: what's "interesting"? That type of "interesting" would apply also to other newgrfs.
13:39:15 <planetmaker> So what's the pain in changing the base costs in a "Pikka interesting costs" grf?
13:39:26 <Pikka> because no-one will use it
13:39:52 <planetmaker> With this separation of "interesting cost levels" into a separate newgrf you'd also gain the additonal benefit, that'd you'd be able to rebalance ALL your newgrfs at the same time
13:39:59 <planetmaker> to another interesting economy
13:40:11 <planetmaker> Oh, I'm very much sure people would use it, if it came from you
13:40:21 <planetmaker> call it pikka economy ;-)
13:40:24 <Rubidium> planetmaker: just use the per-newgrf price scaling I just proposed ;)
13:40:30 <Pikka> by doubling or halving all costs? it's hardly a subtle "rebalancing" feature...
13:40:36 <planetmaker> Rubidium: on the openttd-side?
13:40:42 <Alberth> perhaps *require* a cost grf to be loaded?
13:40:58 <Rubidium> like the palette setting
13:41:02 <planetmaker> yes, that's the only alternative. And I'm quite tempted to go that way.
13:41:10 <Rubidium> (but not queryable by the NewGRF)
13:41:15 <planetmaker> But I first want(ed) to try and see whether that's necessary
13:42:09 <Alberth> Pikka: so the cost setting is not fine grained enough. that is a separate issue from balancing sets against each other
13:42:20 <planetmaker> And it'd not solve the issue that it then still would be a pain to configure things
13:42:28 <planetmaker> It'd add yet another layer of settings
13:42:51 <Pikka> balancing sets against each other is not an achievable feature, though
13:42:52 * Alberth thinks stuff should be removed instead of added
13:43:33 <planetmaker> I'm only talking about rough price levels. Not a nice game balance as I'd expect to see when coherently designed to work along eachother
13:43:45 <Alberth> Pikka: sure you can, but you need to agree on how you balance
13:44:40 <planetmaker> and that's the issue
13:46:07 <Alberth> you'd need to give purchasing costs / running cost balance to the user, I think
13:46:09 <Pikka> and it is an issue because...?
13:46:10 <planetmaker> I don't see the problem in using no base costs for vehicles and using the global base cost mods to set economies
13:46:19 <planetmaker> that'd make the game MUCH more user-friendly
13:46:27 <planetmaker> it's user-friendlyness
13:47:12 <Alberth> as in, 'purchasing costs / running cost balance' is not a property of a single newgrf but of all loaded newgrfs
13:47:28 <Pikka> remove the newgrf loading code, that'll make the game more user-friendly
13:47:54 <planetmaker> well, sulking and sarcasm don't help
13:48:27 <Pikka> how is loading more grfs and setting more parameters /more/ user-friendly than what we have now?
13:48:28 <Alberth> it does not lead to a solution
13:49:02 <planetmaker> And that's exactly why I argue for a *common* base cost reference
13:49:18 <planetmaker> and not every grf defining its own idea how general price and running cost levels should be
13:49:40 <Pikka> the latter seems much more user-friendly to me
13:49:51 <planetmaker> because if they all would use a common base level, then there'd be only one setting which sets it globally.
13:49:51 <Pikka> if grfs can run out-of-the-box as their author intended
13:49:58 <Alberth> it leads to chaos, as the current situation proves
13:50:13 <Pikka> what current situation?
13:50:14 <planetmaker> no, configuring 10 grfs individually, each having a separate idea of what is good is very user unfriendly
13:50:40 <Pikka> well my grfs aren't a problem there, because you can't configure them :)
13:50:42 <Alberth> Pikka: different grfs having different ideas about costs.
13:51:07 <Alberth> and no flexibility for the user to correct it
13:52:06 <Pikka> "the user" doesn't have a clue about what is an appropriate base cost
13:52:23 <planetmaker> that's why I suggest you make a newgrf called "pikka economy"
13:52:31 <Alberth> so set some default. but advanced users should be able to do it
13:53:18 <Pikka> planetmaker: so I'm now forcing people to use all the basecosts I like, or wade through a million meaningless parameters, in order to use av8?
13:53:22 <planetmaker> well, it's two issues we have here: a) the default value and b) possibility to change defaults
13:53:55 <planetmaker> what's your point?
13:54:39 <Pikka> my point is that that doesn't sound very user-friendly :)
13:54:52 <planetmaker> my point is: "economy balancing needs to be done globally". Not on a per-vehicle-grf basis
13:55:03 <planetmaker> and the latter is the case everywhere. Resulting in a great mayhem
13:55:15 <planetmaker> a base cost grf needs to have no single parameter
13:55:40 <planetmaker> or one which just selects different 'economies'. Very simple. Very user-friendly
13:55:45 <CIA-2> OpenTTD: rubidium * r22699 /trunk/src/road_cmd.cpp: -Fix [FS#4681]: Cost of adding an extra road type to a bridge or tunnel was undercalculated (adf88)
13:55:51 <planetmaker> so where's there your argument?
13:56:04 <Pikka> what happens when the user loads five base-cost grfs, the last of which just happens to have been created by someone who didn't care about aircraft and so has the default value?
13:56:25 <planetmaker> what shall happen?
13:56:49 <planetmaker> nothing will happen
13:56:55 <Pikka> then they'll be playing av8, with the grf that sets the av8 base costs loaded, but still with the wrong base costs.
13:57:13 <Pikka> and they'll have no idea that it's happened, or how to fix it.
13:57:18 <krinn> was way but wishing to show a good example of why grf authors should use same base: if X author do mediteranean tgv (blue/white) and Y author do the national french one (orange color) i find it real bad to see one cost me 250M while the other is at 700M
13:57:45 <planetmaker> is your idea on cost levels "right" and mine "wrong"?
13:58:21 <planetmaker> it's no mistake nor error nor bug to play with av8 ad /4 running costs
13:59:11 <planetmaker> you miss the argument still: general running and purchase costs are a global thing
13:59:41 <Alberth> Pikka: so disable yourself if the pikka costs are not loaded
13:59:51 <planetmaker> but what you can make sure is that different vehicles of the same type play along somewhat kindly
14:00:02 <Pikka> no you can't, planetmaker
14:00:20 <Pikka> my view of what's a good cost balance is different from MB's or george's
14:00:44 <Pikka> and it's certainly different from numpty joe who barely understands what they're doing with nfo and has costs and other stats all over the place
14:01:05 <planetmaker> And if all yours and their newgrf would use an indifferent (default) base cost reference, then A SINGLE economy newgrf would allow me to play a somewhat balanced game with all those vehicles
14:01:15 <planetmaker> dead easy. On newgrf authors as well as players
14:01:48 <planetmaker> currently an economy newgrf is pointless as it cannot balance individual newgrfs
14:02:13 <Pikka> they can't balance the vehicle costs. they can balance the other costs still, presumably?
14:02:14 <Alberth> planetmaker: why not, if an author considers HIS ideas so important that he cannot live without, let him
14:03:01 <krinn> i totally agree with planetmaker if one wish play pikka's style cost, why limit that to only pikka vehicle ? and if one wish play with nice pikka gfx why would it need to learn a new of playing the game to do that ?
14:03:02 <planetmaker> yeah. But indeed. The only conclusion I can draw is "implement openttd-side a per-newgrf base cost config", "implement a per-newgrf basecost preset"
14:03:41 <planetmaker> and possibly a switch of "ignore all base cost commands in newgrfs"
14:03:54 <planetmaker> to make the thing easier to configure
14:04:02 * Alberth ponders to do automagic cost calculations based on physical properties of the vehicles
14:04:03 <planetmaker> and more user-friendly
14:04:18 <planetmaker> and thus brute-force cooperation
14:06:19 <planetmaker> Pikka: just to re-cap and put aside all the redherring: the base problem which I *somehow* would like to see solved *somewhen* is this:
14:07:07 <planetmaker> - Assumption 1: player use several vehicle newgrfs alongside and don't know or like to put work into configuration
14:07:47 <planetmaker> - Assumption 2: players like to have approximately price levels of different grfs in sync
14:08:14 <planetmaker> - Assumption 3: costs / difficulty should be a globally configurable thing (that's why we also have diffiuclty settings)
14:10:13 <CIA-2> OpenTTD: rubidium * r22700 /trunk/src/ (bridge_gui.cpp tunnelbridge_cmd.cpp): -Fix [FS#4680]: cost of changing bridge type is undercalculated when adding road types as well (based on patch by adf88)
14:10:57 <planetmaker> Question: how can we reduce the amount of time spent on setting up a game with sensible values without going as player into technical details or à priori-knowledge about how individual authors of vehicle grfs think the game needs to be balanced?
14:11:32 <JVassie> loving the new Electrostar :)
14:12:00 <planetmaker> assumptions 1 and 2 are easily verfied by reviewing problem and newgrf sections - and looking at random savegames which are horrible sometimes wrt their newgrf config
14:12:27 <Pikka> question 1, if players have no knowledge or desire for knowledge about configuration or balance, why leave the choice of running cost balance up to them?
14:12:30 <planetmaker> and yes, with 3 also I don't find it easy to avoid all traps
14:12:54 <Pikka> question 2, how do you know that vehicles with different base cost multipliers aren't balanced against each other?
14:13:37 *** Adambean has joined #openttd
14:14:26 <planetmaker> ad 1) if they can choose vehicles, they can also choose an economy model. It's easier to choose one economy model than the check the implicit economy model behind each newgrf
14:14:44 <planetmaker> ad 2) much more likely than the other way around
14:15:03 <Pikka> for example, in NARS I came across a situation where the very biggest locos needed running costs slightly higher than were available, so I increased the base multiplier by 1 and halved the costs of all other locos. so the set is still balanced for the lower multiplier, I just needed a higher number.
14:16:01 <Pikka> you're talking about removing the possibility of sets that are generally balanced towards one end of the multiplier range but needed to go "up one" to take in outliers
14:17:08 <planetmaker> No, I don't. But what are the options, if every newgrf tries to introduce its own idea of how an economy should work?
14:17:42 <planetmaker> the only option then, if newgrfs aren't "nice" is "ignore their idea and use a globally defined one"
14:17:55 <Alberth> s/introduce/force/ imho
14:18:08 <Pikka> the option is "accept the possibility that newgrfs aren't '"nice"'.
14:18:37 <planetmaker> they aren't. And you argue - as it comes accross - "I don't want to be nice" ;-)
14:19:20 <Pikka> most grf authors are interested in improving the gameplay experience, and most grfs work together at least as balancedly as the default vehicles do (how balanced are the default vehicles really, across different transport modes?)
14:19:45 <planetmaker> but yes, "accept the possibility that newgrfs aren't 'nice'" is what we have to face. As in so many aspects of the newgrf land
14:20:16 <planetmaker> btw, comparing different transport modes is also a no-brainer, if you accept a global economy newgrf: it could do just that without any pain.
14:20:58 <planetmaker> which - thanks for the argument - is yet another point in favour of ONE econoamy newgrf over each vehicle newgrf defining its idea of what it should be like
14:22:51 <Pikka> but that presupposes that grf authors can balance the economy in a meaningful way, which seems to be something you doubt :P
14:23:41 <Alberth> balance between sets is a requirement before even considering that
14:24:39 <Pikka> what about balance within sets? The balance between purchase and running cost, for example?
14:24:42 <planetmaker> Pikka: no, I don't doubt that. But the prerequisite is all non-economy newgrfs playing 'nice' and not forcing their idea of what it should be like
14:24:58 <planetmaker> Pikka: no such balance. That's part of economy
14:27:03 <Alberth> Pikka: you like to play with some purchase/running factor, I'd like to use another one. the good news imho is that by making that global, you can play with all vehicle sets with that setting, rather than just your own
14:27:55 <Pikka> but the balance /within/ that purchase/running factor is not necessarily the same between sets
14:28:46 <Pikka> as in the case of NARS I quoted above, and UKRS2 which has inherited NARS's base costs
14:29:06 <planetmaker> base costs are economy
14:29:09 <Pikka> all of the running costs of vehicles in UKRS2 are in the bottom half of the running cost range
14:29:15 <planetmaker> only (relative) costs are grf
14:30:02 <Pikka> so you could quite reasonably have another grf with the same vehicles and the same spread of costs and the same base cost, and the vehicles in the other set would cost twice as much
14:30:26 <Alberth> planetmaker: what Pikka wants, I think, is to have several newgrfs, next to each other, with different purchase/running cost factors (like a manufacturers choice)
14:30:42 <Pikka> which is what we have now, Alberth
14:31:10 <Eddi|zuHause> are you still discussing this?
14:31:18 <Eddi|zuHause> i told you it's going nowhere...
14:31:33 <planetmaker> Eddi|zuHause: if you don't intend to be constructive, can you shut up?
14:31:43 <Alberth> Pikka: but a factor 10 difference is just plain stupid
14:32:11 <Eddi|zuHause> i've been quiet for an hour, obviously that didn't help at all
14:32:13 <Pikka> I agree, Alberth. So the fact that some other grf has silly numbers means that my grf has to, by default, have silly numbers too?
14:32:27 <Pikka> some other grf / the default vehicles
14:32:55 <planetmaker> Pikka: that's the point. Buy ONE newgrf trying to do it right individually you make it IMPOSSIBLE to make it right globally
14:33:01 <Alberth> Pikka: that is the best we could find until now
14:34:20 <Alberth> you are welcome to have a go too
14:35:25 <Alberth> Pikka: we can use anything as a global base, but the only common vehicle set is the default set, so that's why it came into play.
14:36:27 <Pikka> that most openttd players
14:36:32 <Pikka> don't play with newgrfs
14:36:49 <Pikka> some do, and some will load every grf they can get their hands on
14:37:26 <Pikka> but they're a very small number, and I think of that number, those who care about balance are even smaller
14:38:45 <planetmaker> so you claim that people don't care about an easy and good gaming experience?
14:39:43 <planetmaker> from our bug reports, a very substantial part of the players meanwhile do use newgrfs...
14:40:21 <Pikka> but this attempt at giving them one is a bit half-assed, and takes away a lot of potential for creating an "easy and good gaming experience" from newgrf authors?
14:40:37 <planetmaker> and even: the amount of players using newgrfs is all no argument against making it difficult to have a good one when using newgrfs
14:41:33 <planetmaker> why does it? Where does it? An economy NewGRF which sets your base costs for ALL vehicle types is written in 30 minutes
14:41:50 <Pikka> I've put a lot of effort into making sure that players /do/ have a good gaming experience from my newgrfs, and the fact that a lot of authors /don't/, or have a different idea of what a good gaming experience is, is no reason to detract from my work
14:42:15 <Pikka> yes planetmaker, but I maintain that the base cost values provided in the grfs are the /only/ valid ones for those grfs
14:42:46 <krinn> maybe people (like me) just want your newgrf to get your nice graphisms and more diversity with vehicle -> eye candy
14:43:06 <krinn> but still want to play openttd, not pikka's openttd
14:43:32 <planetmaker> Pikka: that's ... hard to argue with, but an assumption which certainly is not true. For example on grounds of the argument krinn gave
14:44:18 <krinn> and also: if people don't play much newgrf, maybe it's because they don't like your graphism, or maybe, the root is somewhere else, and that root might be "prize" no ?
14:44:29 <planetmaker> a vehicle grf is not an economy grf. Forcing a certain economy doesn't work as it can be overridden with some effort - but it forces players dismay
14:45:14 <Pikka> well, my grfs are a work of art, and they are what they are and are imo best appreciated whole. so my response to krinn's argument is if he doesn't like it, he doesn't have to use it, I don't mind.
14:45:33 <Pikka> the stats are as important a part of the grf as the graphics.
14:46:35 <planetmaker> well then. Sacrifice the usability in a heterogenous environment on grounds of "my way" :-(
14:46:54 <krinn> pikka: yeah but do a poll: 1/ you prefer pikka's grf with ugly gfx + hard mode economy OR pikka's gfx with 0 change to economy = guess result ?
14:47:10 <planetmaker> they'd be enjoyed much better, if the pikka-economy was separate.
14:47:23 <planetmaker> Especially as that'd make sure that the other price levels would match that idea
14:47:28 <planetmaker> for all vehicle types etc
14:47:32 <Pikka> for a given value of enjoyed, planetmaker
14:48:17 <planetmaker> yes. enjoyed as in "don't worry about config" and "it just works" would increase tremendously
14:48:26 <Pikka> UKRS2, for example, has been carefully worked to make all the vehicles useful, and avoid the deltics-on-everything that you tend to see in UKRS1 servers, and all the feedback I've had about that aspect of things has been really positive
14:48:39 <Pikka> but if you quarter all the costs, that goes out the window
14:49:26 <planetmaker> nothing would change with the relative balance, nothing would be lost
14:49:54 <krinn> what you seem to not see, is that people love your work with gfx, but people cannot just play with them because of the economy change. That's why people are frustrate, if your work was ugly nobody would complain as noone care to play with ugly gfx set, but it's not, and that's what hurt people
14:51:16 <krinn> and the problem is even worst if playing with 2 newgrf with similar model but 10x prize difference, this time as my tgv example, you'll see the map with only the orange version or the blue depending what tgv prize is the more acceptable
14:52:32 <Pikka> if different grf authors have different ideas about costs, I think that should be respected. and if they want to get together and make their sets compatible, that's an issue for them
14:52:53 <Pikka> newgrfs really /are/ modifications to the game after all, they're not necessarily just pretty graphics
14:53:23 <planetmaker> yes. But they don't live alone
14:53:47 <planetmaker> and as such the idea of general cost levels is mis-placed in the individual vehicle grfs
14:53:52 *** supermop has joined #openttd
14:54:13 <Pikka> what's the difference between a general cost and a specific cost?
14:55:35 <Pikka> I balance my sets by playing the game and observing profits and loss of vehicles on different kinds of services. what I have to set the basecost to to get the costs I need is a technical detail.
14:56:15 <Pikka> the basecost is no less an integral part of the set balancing than the internal costs of the vehicles
14:57:07 <planetmaker> no, it's not. It's part of the economy. And it's that part of the newgrfs which make it impossible for newgrfs to live peacefully alongside eachother
14:57:40 <Pikka> they live peacefully alongside each other just fine
14:57:43 <planetmaker> it's that part which shoots the players foot if the wants to use tow same vehicle-type newgrfs
14:58:30 <Pikka> my set is balanced how I saw fit, author B's set is balanced how he saw fit.
14:58:33 <planetmaker> of course. the player cannot reasonably use them both as they often grossly disagree about general cost levels
14:58:53 <Pikka> well, that's your perception, it's not an error in either grf
14:58:56 <planetmaker> and it's the player playing. So HE should set an economy how he sees fit.
14:59:10 <planetmaker> as such it's an error in the grf specs. yes
14:59:40 <planetmaker> rubidium is right all the time :-) No other solution than make grfs blind and mouth-gagged ;-)
15:00:13 <Pikka> it's an error in the grf specs to allow an author to specify the stats of a vehicle? hmm.
15:00:17 <peter1138> sets can be totally unbalanced without basecosts involved
15:00:59 <Pikka> of course they can, peter. and what constitutes "balanced" is a matter of opinion.
15:01:19 <krinn> it's like if a grf author as done : "german town" but put in the specs to use it it disable all rails, because the author doesn't like trains... It's the same, do gfx in newgrf and your economic vision in another one
15:01:25 <planetmaker> I can only repeat "that's why I argue about the general level of the costs"
15:01:32 <planetmaker> Not individual or relative balance
15:02:03 <planetmaker> it's about where and how to exert control over how the player plays the game
15:02:21 <planetmaker> and vehicles should not control economy nor sabotage it
15:02:24 <Pikka> yes, and I'll say again, in my opinion the only valid level of "general costs" for my grfs is the one specified in the grf
15:02:37 <Pikka> and other grf authors may feel the same
15:02:48 <Pikka> my grfs should not impose on theirs, nor theirs on mine.
15:03:14 <krinn> that's what your grf are doing on players
15:03:18 <planetmaker> ach, that's totally past the argument, 90° tangent
15:03:22 <Pikka> then don't use the grf, krinn
15:03:33 <krinn> i don't, but i'm sad i couldn't
15:04:14 <planetmaker> I'm sad that your answer to "how can we make vehicle newgrfs work easier alongside" is only "do it my way or not"
15:04:23 <Pikka> no, that's not my answer
15:04:52 <Pikka> my answer is that grfs work fine alongside each other already, and what you're interpreting as a bug is a difference in style of the grf authors
15:05:21 <planetmaker> not the style. The economical settings they prefer
15:05:29 <Pikka> that's part of the style
15:06:03 <planetmaker> It thus needs to be split hard. Or we can never get a chance to tackle economy
15:06:20 <planetmaker> similar to how base costs were made grf-local only
15:07:34 <planetmaker> but I'm really sad that the global economy and game balance is no consideration for you as it seems
15:08:08 <Pikka> it is of great consideration to me; that's why I make grfs balanced to the economic style I prefer
15:08:32 <Alberth> aka "do it my way and only my way"
15:08:44 <planetmaker> But it needs quite obviously a global solution. Or it will fracture and shatter
15:08:47 <Pikka> just let me do it any way I like :)
15:09:10 <planetmaker> Pikka: and my argument was: do the way you like. But please do that via a *global* economy newgrf
15:09:13 <planetmaker> Not on the local level
15:09:33 <planetmaker> as the local tiddle-taddle-fixing destroys the global picture
15:10:25 <Pikka> planetmaker: what kind of economy "fixing" do you have planned?
15:10:31 <Ammler> why does that matter, can't you still make such a global economy set?
15:10:44 <Pikka> yes Ammler, but most people won't use it
15:11:03 <Ammler> yes, the question was for pm :-)
15:11:06 <Pikka> and so my other grfs will not have their proper valies
15:11:17 <planetmaker> Pikka: none. Or any arbitrary one. But the 'global' scope would make sure the same balancing would apply equally to ALL vehicles
15:11:24 <Ammler> as the costs are "chained" already
15:11:26 <Pikka> yes, you can, but it won't "balance" misc vehicle sets :)
15:12:02 <Pikka> planetmaker: setting a basecost is not the same thing as "balancing"
15:13:11 <planetmaker> but my whole argument has only been about the base cost level... *sigh*
15:13:11 <Ammler> using basecosts on a vehicle set is just for changing bandwith
15:13:37 <Ammler> should not be used for "economy"
15:13:48 <planetmaker> but most vehicle newgrfs do
15:13:51 <Pikka> ammler wins a coconut :)
15:15:17 <Ammler> but aren't you still able to change costs of a pikka set via a basecosts grf?
15:15:40 <Pikka> no Ammler, vehicle grfs which set their own basecosts are now independent
15:15:54 <planetmaker> Ammler: only if it's the only newgrf of that kind
15:15:55 <Ammler> well, you could use override, can't you?
15:17:07 <Pikka> but I don't see why one would want to
15:17:14 <Ammler> planetmaker: do you ask grf authors to not use basecosts at all?
15:17:30 <Ammler> I mean in same set as the vehicles
15:18:34 <krinn> it's a design fault, newgrf should have been design with a close target: naming, gfx, sound, economy... so newgrf authors were force not to add too many things in it to keep the "player" freedom
15:18:53 <krinn> and so players wishing to play like pikka could installl pikagfx+pikaeconomy
15:18:57 <Ammler> krinn: pikka does that
15:19:39 <Ammler> as he said, he didn't change economy, just balacining costs and for that, he needed to change basecosts as the costs factor would be out of scope, right pikka?
15:20:26 <krinn> this would have also gave another good thing: auto-classing of newgrf so players could easy find newgrf by category and get what they seek and not a surprise bundle with it
15:20:51 <planetmaker> try to match running costs with any other trainset. You have a 66% chance to fail
15:20:53 <Ammler> krinn: there aren't many such newgrfs available are there?
15:21:20 <Pikka> Ammler: actually, my grfs do change the economy. They change it so aircraft aren't money printing machines, and they change it so that it's not best to always have the fastest and most powerful locomotive available on every train.
15:21:21 <Ammler> planetmaker: and solution would be?
15:21:43 <planetmaker> not setting the running cost base to +2
15:21:51 <Ammler> Pikka: yes, but with different newgrfs
15:22:03 <Ammler> and ukrs does not change costs of av8, right?
15:22:17 <Pikka> right, but I don't think that's planetmaker's issue
15:22:57 <planetmaker> my issue is that I have no chance to balance Dutch TS, DBXL and UKRS2 against eachother
15:23:09 <Pikka> his issue is that grfs which add vehicles should not significantly change the gameplay from default
15:23:38 <Pikka> so that all newgrfs from all authors may be used together in a coherent manner
15:23:44 <planetmaker> s/gameplay/vehicle purchase cost and running cost levels/
15:25:37 <Ammler> I see, well you could create as said a economy grf additionally
15:25:46 <Ammler> no need to change anything in the existing grfs
15:26:12 <Ammler> does not matter who does it :-)
15:26:18 <Pikka> planetmaker is looking at this from an average player point of view
15:26:32 <Ammler> kind of makepikkasetsbehavelikedefault.grf
15:26:39 <Pikka> he wants all newgrfs to be compatible by default
15:26:56 <Pikka> where "compatible" means "have costs in roughly the same ballpark"
15:27:16 <planetmaker> or at least have a parameter which allows me to do that
15:27:23 <Ammler> but default costs aren't good, planetmaker
15:27:37 <planetmaker> I don't say they are.
15:28:25 <planetmaker> that's what you have economy newgrfs (aka base cost newgrfs) for
15:28:41 <planetmaker> please don't make me re-iterate the discussion. Just read back, ok?
15:29:29 <Ammler> anyway, what about my suggestion?
15:29:40 <planetmaker> or try to get 2ccts, ukrs2 and dbset to a somewhat sane cost levels concurrently in one game
15:30:17 <planetmaker> feel free to make a "balanacenewgrf" for every new newgrf which there ever will be. That's boring and doesn't fix the broken-ness of the situation
15:30:41 <Pikka> planetmaker: at least in that cirumstance, UKRS2 will genteely refuse to load until the user agrees that they're doing something unsupported. so it's not that I don't completely not care about this issue
15:30:43 <Ammler> or simply make a "fixdefaultcosts.grf"
15:31:11 <Ammler> planetmaker: well, then you will have the same issue with every author, not just pikka
15:31:33 <planetmaker> Ammler: please just try to balance those three train grfs and see.
15:31:45 <Ammler> and it is not really that easy to convince someone to make his grf worse just to be compatible
15:31:47 <planetmaker> there's no single way existing which does that now
15:31:56 * Pikka gives Ammler another coconut
15:32:16 <Ammler> worse from his view, of course :-)
15:32:41 <Ammler> Pikka: but you could make a "makeMyGrfsLikeDefault.grf" :-P
15:32:55 <planetmaker> he could just add a parameter. done
15:32:57 <Pikka> ammler: often requested. :)
15:33:53 <Ammler> Pikka: parameters are no issue as long as you have good default
15:34:08 <Ammler> like ukrs needed parameters per default was bad
15:34:39 <Pikka> but UKRS2, not so bad. :) so I'm not really interested in giving players an easy mode button.
15:34:44 <Ammler> might be good idea to "force" peple reading the readme :-P
15:35:15 <Alberth> Ammler: just like reading of the licenses in current software ?
15:35:33 <Pikka> I like to think there's some depth to my grfs beyond pretty graphics, I put a lot of work into it. So I'm not keen to have it taken away.
15:35:50 <Ammler> the sets from eis_os needed a code as parameter to run at all
15:35:54 <Pikka> (it could be worse, I could enforce wagon speedlimits like oztrans did :P )
15:36:54 <planetmaker> Pikka: it's not about taking anything away
15:37:02 <Ammler> Pikka: that is rather a issue of openttd allowing it
15:37:03 <krinn> how about adding (if possible) in it an option to disable that? Still the newgrf works like you've made it,but user could disable your economic rules
15:37:13 <planetmaker> It's about how a game is best configured
15:38:26 <Rubidium> well, the first thing we need is an option to enable those options... after all, many say there are already too many options
15:38:44 <Rubidium> (though I doubt they looked at ttdpatch)
15:38:46 <Ammler> krinn: the issue is that basecosts in vehicle sets are not made for economy, as said
15:40:31 <planetmaker> well. Good that we talked about it. Sad that we didn't find any concensus nor any newgrf-side solution to one of the more nasty problems in user-land. But well...
15:41:00 <Ammler> planetmaker: maybe you should make a kind of recommendation in the wiki
15:41:34 <Alberth> but it just gets ignored, then what?
15:41:41 <Pikka> planetmaker: the fact is, most users of my grf will be unaware of these issues. and I'd rather those users saw my grf as I would like, rather than as krinn would like. :)
15:41:47 <Ammler> well, something not make costs like default
15:41:58 <Ammler> so the costs are at least useable
15:42:19 <Ammler> and authors don't need to make the set worse
15:42:56 <krinn> Pikka, you might miss it's not how i wish, but as it is in openttd
15:44:31 *** KritiK_ has joined #openttd
15:45:26 *** KritiK_ is now known as KritiK
15:51:24 *** andythenorth has joined #openttd
15:52:54 <Pikka> you missed plenty of fun :)
15:58:36 <andythenorth> there are logs :P
16:10:25 <supermop> been playing a really fun 128x128 passenger timetable game
16:22:57 <supermop> not too old, but not brand new
16:23:54 <supermop> technically firs is the industry set, but there are no industries
16:24:58 <supermop> I was placing a few in the editor, then decided it would be more enjoyable to focus just on a metropolitan transit network, given the map size
16:25:16 <supermop> ooh, also finish town names, which I always use lately
16:34:20 <supermop> I am aiming to use only one depot
16:34:43 <supermop> (two actually, as subways need their own)
16:34:44 * dihedral is updateding the data directory: Receiving objects: 87% (15155/17397), 676.35 MiB | 174 KiB/s
16:35:13 <andythenorth> it's a shame Pikka is *so* against providing a baseline for costs
16:35:34 <supermop> 2cc running costs seem much higher than i remember
16:35:57 <supermop> I am 30 years in and still have not paid off my loan, very tight margins
16:36:10 <supermop> need to borrow for large capital projects
16:36:30 <supermop> egrvts is printing money, of course
16:38:14 <andythenorth> egrvts is too cheap
16:38:30 <andythenorth> I think Zeph overshot when 'fixing' the stupid default rv costs :D
16:39:18 <andythenorth> I have a partial solution to costs, but it has flaws
16:39:22 <supermop> doesnt really bother be as its only there to make my cities look cute, and alleviate cargodist links between rail stations in the same city
16:39:31 <andythenorth> 1. balance against default costs
16:39:35 <andythenorth> 2. balance against pikka sets
16:39:43 <andythenorth> 3. use parameter to select which
16:39:53 <supermop> but currently rv revenue is about 1/3 train revenue
16:40:04 <supermop> and cost is about 1/10 or less
16:40:07 <andythenorth> 1. default RV costs are broken, so balancing against them is broken
16:40:34 <andythenorth> 2. it will be quite an easy parameter for users to understand *but* if they forget to set it, they have to restart their game
16:41:04 <supermop> 'realistically' in a large urban network the RVs should be running at a loss
16:41:16 <supermop> and just providing synergies for the trains
16:41:27 <supermop> but in my game its the other way around
16:42:07 <supermop> was thinking this morning of a crazy, needlessly complex way to represent running cost
16:52:04 <andythenorth> sounds like just what we're missing :P
16:53:36 <Eddi|zuHause> <supermop> 'realistically' in a large urban network the RVs should be running at a loss <- that should apply only after ~1960
16:53:42 <supermop> i have the good sense to hold my tongue
16:53:52 <supermop> well i just hit 1963,
16:54:50 <supermop> just stumbled across this guy; love the way it looks:
16:55:23 <supermop> too bad there is no real way to capture that look in TT sprites
16:56:37 <Eddi|zuHause> hm... i need some cheat to get the 3lu and 4lu tenders to turn at the right place...
17:01:31 <Terkhen> if all costs are set to zero, all sets are balanced to each other
17:24:54 <Hirundo> Is it possible to 'hide' an articulated part, in order to refit a vehicle to either 3 or 4 parts?
17:25:10 <andythenorth> Hirundo: set the length to 1/8
17:25:18 <andythenorth> use empty graphics
17:25:28 <Hirundo> And then set another part to 7/8?
17:25:38 <andythenorth> depends what you want to achieve
17:25:54 <Hirundo> I don't want a gap between it and the next vehicle in the train
17:26:10 <andythenorth> changing the length isn't necessary if it's the last vehicle in the train, but if it's a mid vehicle - then yes 7/8
17:26:49 <andythenorth> Hirundo: HEQS trams do it
17:27:03 <Eddi|zuHause> it's better to set the visible vehicle to 1/8 and the invisible to 7/8, for bounding box purposes
17:27:04 <Hirundo> My intention is to create a MU that can be refitted to 3 or 4 parts, so it needs to be coupled
17:27:07 <orudge> Huzzah, that in theory should be the entire TTDPatch wiki more or less tidied up now
17:27:15 <orudge> although I still want to do things with templates, navigation, and so on
17:27:41 <Hirundo> Eddi|zuHause: Then put the visible part in front or at the back?
17:27:58 *** AD is now known as Guest4209
17:28:01 <Eddi|zuHause> visible part is the front one
17:28:17 *** Chris_Booth has joined #openttd
17:28:46 <Hirundo> so in this case <visible 8/8, visible 8/8, visible 1/8, invisible 7/8> ?
17:29:30 <Eddi|zuHause> or <visible 8/8, visible 1/8, invisible 7/8, visible 8/8>, if you want to make fewer special cases for the last vehicle
17:29:33 <Hirundo> Do I need a special sprite template for that, or can I use the normal (pikka) ones?
17:29:33 <Rubidium> not visible 8/8, visible 1/8, invisible 7/8, visible 8/8?
17:30:09 <Eddi|zuHause> no, just use your normal sprite
17:30:43 <Eddi|zuHause> sprite and alignment should not change
17:31:52 <Eddi|zuHause> (at least until fs#3569 is fixed)
17:33:12 <Rubidium> Eddi|zuHause: I fear that fixing 3569 fixes nothing for the actual drawing
17:33:35 <Rubidium> after all, the old drawing method ought to be maintained for backward compatability reasons
17:33:57 <Eddi|zuHause> Rubidium: any fix to this must be specifically enabled by the grf
17:34:14 <Eddi|zuHause> a special grf flag, like 32px vehicles
17:35:52 <Eddi|zuHause> Rubidium: after all, even if only the bounding box and turning points are changed, without changing sprite alignment, then still var45 etc. give different results than before
17:37:57 <Rubidium> which means there needs to be backward compatability code for that as well :(
17:39:16 <Eddi|zuHause> not if you fix it quickly before we release CETS ;)
17:39:51 <Rubidium> why? There are no newgrfs that use that var already?
17:41:23 <Eddi|zuHause> not that i know of
17:41:50 <Eddi|zuHause> at least not in a way that would make a difference
17:42:04 <Eddi|zuHause> only Georges test grfs
17:44:15 <Eddi|zuHause> hm, some russian train set maybe
17:45:26 <andythenorth> so set a message that the old method will be deprecated?
17:45:48 <CIA-2> OpenTTD: rubidium * r22701 /branches/1.1/ (13 files in 6 dirs):
17:45:48 <CIA-2> OpenTTD: [1.1] -Backport from trunk:
17:45:48 <CIA-2> OpenTTD: - Fix: [Network] Failed network address resolving could trigger temporary freezes [FS#4697] (r22696, r22695)
17:45:48 <CIA-2> OpenTTD: - Fix: [NewGRF] The override managers were not reset in some cases like creating a new scenario [FS#4691] (r22693)
17:45:48 <CIA-2> OpenTTD: - Fix: [NewGRF] Aircrafts defined with IDs above the default aircrafts always defaulted to passenger cargo (r22690)
17:46:03 <Eddi|zuHause> andythenorth: old grfs are guaranteed to work in the future. it's part of the spec
17:46:24 <andythenorth> I could dispute that
17:46:32 <andythenorth> I'm sure you'd tell me I'm wrong though :P
17:46:47 <andythenorth> it's not empirically true though
17:46:54 <planetmaker> Eddi|zuHause: except in the NewObject case ;-)
17:47:01 <andythenorth> you'd need to qualify quite some more to make it true
17:47:57 <Rubidium> "everything that has been in a stable release and not incorrect w.r.t. the reference implementation". I can't think of anything that'd fall outside of those bounds
17:48:05 <andythenorth> old grfs are guaranteed to work in the future, except where it's decided that the spec is wrong, or that ottd is out of compliance with the spec, but there is no canonical version of the spec
17:48:10 <andythenorth> ^ is closer to the truth
17:48:25 <CIA-2> OpenTTD: rubidium * r22702 /branches/1.1/ (6 files in 2 dirs):
17:48:25 <CIA-2> OpenTTD: [1.1] -Backport from trunk:
17:48:25 <CIA-2> OpenTTD: - Fix: Cost of adding an extra road type to a bridge or tunnel was undercalculated [FS#4680, FS#4681] (r22700, r22699)
17:48:25 <CIA-2> OpenTTD: - Fix: Only insert cleared object tiles into _cleared_object_areas if clearing actually succeeds, else subsequential tests of the same tile will be skipped and considered successful [FS#4694] (r22698)
17:48:26 <CIA-2> OpenTTD: - Fix: When building a house it could be built at the wrong place if multitile houses failed some tests (r22697)
17:49:25 <andythenorth> and also, it's fine to break andy's grf because some other authors complained, because there's a good chance he'll fix it
17:49:40 <andythenorth> we won't discuss flipping of trains in depot :P
17:50:53 <Eddi|zuHause> that was never part of the spec
17:51:26 <andythenorth> I didn't say it was :)
17:53:11 <CIA-2> OpenTTD: rubidium * r22703 /branches/1.1/ (6 files in 4 dirs): [1.1] -Prepare for 1.1.2-RC2
17:55:25 <CIA-2> OpenTTD: rubidium * r22704 /branches/1.1/src/lang/ (8 files): [1.1] -Backport from trunk: language updates
17:59:47 <Eddi|zuHause> those two are backwards, aren't they? ;)
18:00:49 <Rubidium> language updates are never mentioned, so the order doesn't matter much
18:01:05 <Rubidium> just the script to generate the diff between trunk and the branch is somewhat slow
18:16:15 <CIA-2> OpenTTD: rubidium * r22705 /tags/1.1.2-RC2/ (. src/os/windows/ottdres.rc.in src/rev.cpp.in): -Release 1.1.2-RC2
18:18:38 <Eddi|zuHause> wait, it's not even 45 minutes to midnight yet...
18:21:48 <Rubidium> it's not the one without the -
18:22:09 *** Cyrilshark has joined #openttd
18:24:26 <Cyrilshark> Ah nevermind, I think I got it 2026 trying to use the 32 bit graphics on my mac
18:27:52 *** Brianetta has joined #openttd
18:51:51 *** Chris_Booth_ has joined #openttd
18:58:04 *** Chris_Booth_ is now known as Chris_Booth
19:29:09 <Zuu> I miss AIAirport.GetNoiseLevelIncrease in the GUI. Why can't humans see how much noise an airport cause a town at a given distance? (by eg holding the airport at some location)
19:31:31 <Zuu> Wiki says "The noise level added is the noise level given in the airport description less a distance modificator. The distance modificator is distance divided by (8 + 4 * council's permissiveness (0 for permissive, 1 for tolerant, 2 for hostile). ". Does this mean that in a hostile city noise is reduced quicker over distance?
19:32:47 <Zuu> Or is the modificator multiplied with the distance again to get some value?
19:32:57 <planetmaker> sounds complicated :-)
19:33:01 <Zuu> hmm, guess the source code is where one has too look in.
19:33:09 <Eddi|zuHause> if the divisor is larger, the distance increases
19:34:12 <Eddi|zuHause> at permissive it's distance/8, at hostile distance/16
19:35:02 <Zuu> Is a the amount of noise that the town get?
19:35:15 <Eddi|zuHause> effective noise := airport noise - distance/modificator
19:36:13 *** planetmaker changes topic to "1.1.1, 1.1.2-RC2 | Website: *.openttd.org (translator: translator, server list: servers, wiki: wiki, patches & bug-reports: bugs, revision log: vcs, release info: finger) | Don't ask to ask, just ask | 'Latest' is not a valid version | English only"
19:36:16 <Eddi|zuHause> so a small airport at 16 tiles distance will be 3-16/8=1 on permissive and 3-16/16=2 on hostile
19:36:58 <Zuu> Thanks Eddi. I'll put that formula on the wiki.
19:37:00 <Eddi|zuHause> "alle Klarheiten beseitigt?" :p
19:54:37 <Zuu> Zuu's current AI-dev wishlist: remember window positions, console command to load last loaded game :-)
19:56:14 *** DayDreamer has joined #openttd
19:56:52 <Zuu> I also think about implementing AIController.BreakAI which has been proposed but noone has implemented it yet.
19:56:55 *** supermop_ has joined #openttd
20:09:22 <Zuu> Hmm, the API don't let you to get the noise level of a depricated airport type. I see a one-liner patch comming :-D
20:14:07 <Eddi|zuHause> i think V453000 got truely insane now. i mean stages beyond TrueInsanity, err, ...Brain...
20:15:00 <V453000> you havent seen the _true_ stuff yet :P
20:16:34 <Eddi|zuHause> i think you should start out with the flintstone engine
20:16:55 <Zuu> Without it (FS#4704), CluelessPlus need 4 extra noise tollerance from the town in order to upgrade small airports after the small airport has dissapeared.
20:18:39 * Zuu goes and enable the setting "airports never expire"
20:18:48 *** Rieksts has joined #openttd
20:20:45 <Rieksts> What compact slh is viable in busy tl4 ll-rr network
20:21:11 <Eddi|zuHause> english, please.
20:22:25 <Alberth> (as in, you are the only person that knows what 'slh' and '5051' means)
20:22:41 <Ammler> or you are in wrong channel
20:22:50 <planetmaker> slh is a side-line hub
20:22:58 <planetmaker> tl is train length
20:23:25 <Alberth> definitely the wrong channel :)
20:29:01 <Eddi|zuHause> @base 10 16 5051
20:57:39 <andythenorth> sleepy time iggle piggle
20:58:14 *** andythenorth has left #openttd
21:00:32 *** KritiK_ has joined #openttd
21:04:27 *** KritiK_ is now known as KritiK
21:05:29 <Eddi|zuHause> hm, proposal: railtype property: "equivalent labels".
21:06:34 <Eddi|zuHause> like: if i define a railtype "Track Class B, slow, electrified" with label "DBbe", i might want to define the labels "DBNE" and "ELRL" as 'equivalent', as in "is this label defined" checks will return true
21:30:50 *** HerzogDeXtEr has joined #openttd
22:32:04 *** Guest4209 is now known as AD
23:34:05 <Eddi|zuHause> "Dunkel wars, der Mond schien helle"
23:34:14 <Eddi|zuHause> "Schneebedeckt die grüne Flur"
23:34:21 <Eddi|zuHause> "Als ein Auto blitzeschnelle"
23:34:27 <Eddi|zuHause> "langsam um die Ecke fuhr"
23:59:40 <Zuu> Hmm CluelessPlus is way to good at selling vehicles filled with valuable cargo just to buy a new one a moment later for the same connection.
continue to next day ⏵
