Back to Home / #openttd / 2011 / 07 / Prev Day | Next Day
#openttd IRC Logs for 2011-07-30

---Logopened Sat Jul 30 00:00:48 2011
00:56-!-Eddi|zuHause [] has quit [Remote host closed the connection]
00:56-!-Eddi|zuHause [] has joined #openttd
01:07-!-a1270 [] has joined #openttd
01:48-!-sla_ro|master [~slaco@] has joined #openttd
02:23-!-Kurimus [] has joined #openttd
02:44-!-frosch123 [] has joined #openttd
02:50-!-JVassie [] has joined #openttd
02:58-!-George|2 [~George@] has joined #openttd
02:58-!-George [~George@] has quit [Read error: Connection reset by peer]
03:04<frosch123>yay, translators are again translating wiki article of advanced settings which no longer exist
03:13-!-KouDy [] has joined #openttd
03:18<@planetmaker>hm, the openttd wiki doesn't feature the ref extension
03:29-!-pugi [] has joined #openttd
03:30-!-DayDreamer [~DayDreame@] has joined #openttd
03:32-!-DayDreamer [~DayDreame@] has quit []
03:38-!-Progman [] has joined #openttd
03:38<CIA-2>OpenTTD: planetmaker * r22694 /trunk/src/music_gui.cpp: -Cleanup [FS#4579]: Remove unused but confusing widget
03:55<@Terkhen>good morning
03:55-!-Neon [] has joined #openttd
04:07-!-Alberth [] has joined #openttd
04:07-!-mode/#openttd [+o Alberth] by ChanServ
04:09-!-Progman [] has quit [Remote host closed the connection]
04:31<@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 :/
04:33<@planetmaker>hm... what about rather moving that info into the wiki?
04:33<@planetmaker>it's easier found there, I guess
04:33<@planetmaker>or at least linking it there
04:33<@planetmaker>is there such page?
04:34<@Terkhen>I don't think so
04:35<@Terkhen>besides, there are a lot of different tutorials in the sticky :P
04:35<@Terkhen>I made one which works fine, but it requires to use the console :P
04:36-!-Vikthor [] has joined #openttd
04:49-!-Zuu [] has joined #openttd
05:02<frosch123>Terkhen: noone reads stickies
05:03<frosch123>including the mods, else they would have unstickied celestar's balancing branch 2 years ago :p
05:03<Rubidium>whom's? ;)
05:04<frosch123>though maybe it catches some reappearing new topics in the suggestion forum
05:04<frosch123>cheater :p
05:20<frosch123>damn, we have a emoticon template on ottd wiki, and it is even used quite often
05:29-!-Progman [] has joined #openttd
05:38-!-krinn [] has joined #openttd
05:41<Zuu>Hello krinn
05:44<krinn>cool !
05:45<krinn>this hide the whole option or just disable it ?
05:48<JVassie>is it me or are nutracks not on bananananananas?
05:48<Zuu>It hides the option
05:49<Zuu>JVassie: It is you
05:49<JVassie>searching for nu only shows manual industries
05:51<frosch123>Zuu: the call to ViewportAddString uses st->owner == OWNER_NONE, maybe use that instead of < MAX_COMPANIES
05:52<frosch123>also there is no \n after if (..) when there are no {}
05:54<@planetmaker>JVassie: NuTracks is on bananans
05:54<@planetmaker>maybe you have a too old OpenTTD version, though
05:55<JVassie>hmm, maybe i guess
05:55<JVassie>using r21900M
05:55<@planetmaker>that can be anything ;-)
05:55<JVassie>cant remember which chillcore PP it is
05:56<JVassie>one of his versions :p
05:56<JVassie>i apepar to have nutracks 1.0.0 anyway though
05:57<Zuu>frosch123: Using OWNER_NONE would mean that if ever a station would be owned by a town, it wouldn't be shown
05:57<Zuu>As there is also a OWNER_TOWN
05:57<frosch123>Zuu: but the drawing code cannot handle that either
05:57<frosch123>what colour should it pick
05:57<Zuu>Ok, I'll change
05:58<frosch123>i mean, just use the same condition for the same test :)
05:58<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.
05:59<frosch123>+ if (_settings_client.gui.show_only_own_signs) <- that one in signs_gui
06:00<frosch123>viewport.cpp is fine
06:00<Eddi|zuHause>not all code follows the code style :)
06:00<Zuu>frosch123: Ah, okay. I'll fix that.
06:01<frosch123>Eddi|zuHause: it gets harder if you involved in multiple projects
06:04<Eddi|zuHause>the "idle" performance of the game is hopelessly bad...
06:04<Eddi|zuHause>paused and minimised, it uses ~20% cpu
06:05<@Alberth>paused doesn't mean much, since you can even build in that mode :)
06:05<@planetmaker>sure you can. But doing nothing and 20% cpu?
06:05<@Alberth>big enough map :)
06:05<@planetmaker>it basically means that just waiting for input and checking whether anything needs redraw uses 20%
06:09<JVassie> any thoughts on my very quick attempt a 'new' 3rd rail? (bottom track) - compared to current 3rd rail in 2nd track from top
06:09<@planetmaker>indeed quite a bit nicer from my POV, JVassie
06:10<Zuu>New patch at FS#4701
06:10<krinn>Eddi|zuHause, top report 7% cpu usage when in title screen, it is because of the map size ?
06:12<JVassie>why would nutracks have house sprites included? :x
06:13<@planetmaker>JVassie: subway
06:14<JVassie>smart cookie :D
06:14<JVassie>just lookign at all the sprites id have to change :x
06:15<JVassie>in theory, if I replaced every sprite, then the 3rd rail could be at the top in the __ view, yeah?
06:16<Eddi|zuHause>JVassie: i think the 3rd rail is too close to the real rail
06:17<JVassie>ill do a version with 1px further away, 2 secs
06:21<JVassie>bottom most
06:21<JVassie>you can see a comparison of different distances away from the real rails
06:21<JVassie>smallest a to largest d
06:22-!-dfox [] has joined #openttd
06:22<JVassie>a is the same as the previous version btw
06:24<Eddi|zuHause>ah, i'd go with 'd' then...
06:25<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
06:25<JVassie>oooh now that would be cool
06:25<JVassie>can you do somethign similar (but opposite) for stationS?
06:25<Eddi|zuHause>i'm not sure how crossings are done, though
06:26<JVassie>as obviously in stations the 3rd rails are on the far side from the platform
06:26<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
06:26<Eddi|zuHause>i don't think you can sensibly do that
06:27<JVassie>hmm i guess so
06:27<Eddi|zuHause>i mean without providing a patch that won't be accepted ;)
06:27<JVassie>platform sides can be 'variable'
06:28<JVassie>and the station wont know which side the platform actually is
06:28<Eddi|zuHause>most station graphics have platforms on both sides
06:28<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
06:30<JVassie>1.1.0 is latest not 1.0.0 >.>
06:30<Eddi|zuHause>that 3rd rail looks like the monorail painted over the rails...
06:30<Eddi|zuHause>and i hate those new nutrack rails
06:31<Eddi|zuHause>they are too greasy, and have too little difference between them
06:32<JVassie>i dont think from the actual angle you look at ottd tracks
06:32<JVassie>the 'little black bits' the 3rd rail sit on shouldnt be (very) visible
06:34-!-IchGuckLive [] has joined #openttd
06:35<IchGuckLive>Hi is there a trevel minimum for the 1.1.2 version
06:35<@Alberth>yes, 1 tile
06:36<IchGuckLive>ok then i will trevel 8 tiles
06:36-!-IchGuckLive [] has quit []
06:42-!-andythenorth [~Andy@] has joined #openttd
06:42<andythenorth>Pikka: hello
06:42<andythenorth>I tried to pm you, but I can't post to forums :P
06:43-!-LordAro [] has joined #openttd
06:43<LordAro>(for me :) )
06:44<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
06:48<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
06:50-!-bodis [] has joined #openttd
06:55-!-Pulec [] has joined #openttd
06:58-!-Biolunar [] has joined #openttd
07:03-!-Chillosophy [] has joined #openttd
07:06<frosch123>LordAro: actually the feature and feature period templates should be merged
07:07<frosch123>but it annoys me that they are all translated :p
07:07<frosch123>so maybe it needs some generic template with takes the translated caption as parameter
07:07<LordAro>yeah, probably, but (as you saw from my attempt at Template:Forum) i'm useless at mediwiki templating :)
07:10<LordAro>it doesn't help of course that the mediawiki software is so outdated... nudge, nudge ;)
07:10<Pikka>hello andy
07:11<Pikka>why not?
07:11<andythenorth>server times out on me
07:11<andythenorth>anyway - I wanted to say I'm happy to do the helicopter load sprites if not done
07:11<frosch123>LordAro: it is not as outdated as ttdp wiki was
07:12<Pikka>ah, okay
07:12<Pikka>well, I've done a box already, I can send it over if you want a look :)
07:12<frosch123>btw. what would a newer wiki offer which is so much needed?
07:12<Pikka>but not via forum pm? :)
07:12<andythenorth>I can read fine
07:12<andythenorth>just can't post anything
07:15-!-TWerkhoven [] has joined #openttd
07:16<andythenorth>I'd tell orudge - but I can't post to do so :D
07:20<@orudge>Andel: what what?
07:20<@orudge>andythenorth, even
07:20<@orudge>are you connecting via IPv6?
07:20<andythenorth>I don't think so, but let me see if it's specific to my isp
07:21<@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.
07:21<andythenorth>orudge: yeah it works on a different connection
07:21<@orudge>To be fair, the OpenTTD wiki is still on debian lenny, tt-wiki is at least on squeeze :)
07:21<andythenorth>must be specific to virgin media
07:21<@orudge>andythenorth: strange
07:22<@orudge>Wheezy ought to be out in two years or so, though ;)
07:25-!-KouDy [] has quit [Quit: Leaving.]
07:32<andythenorth>Pikka: do you mind if I include the skycrane in HEQS?
07:32-!-ar3kaw [] has joined #openttd
07:33<Pikka>not at all, I can ship you the code if you want it to be av8-identical
07:34<andythenorth>that would help - I just realised I don't want to learn to code planes :o :p
07:35<Pikka>goodo then
07:38<frosch123>identical vehicles in multiple grfs? :p
07:38<frosch123>what message shall i use when closing bug reports to ottd about that?
07:38<Pikka>do not worry frosch123
07:38<Pikka>we shall use our cleverness to make it only appear once
07:39-!-ar3k [] has quit [Ping timeout: 480 seconds]
07:39<Pikka>viz I shall set a parameter in av8 2.0 which heqs can check for, and disable its version of the helicopter accordingly?
07:39<frosch123>i guess such a scenario would not even work in grftopia
07:43-!-Wolf01 [] has joined #openttd
07:43<@planetmaker>hm... why now planes in heqs, too?
07:43<andythenorth>I have been told n times that including multiple vehicle types in heqs is a bad idea
07:43<andythenorth>but it amuses me
07:44<Eddi|zuHause>grfs are already plugins
07:44<Wolf01>like MB one for db set
07:44<Eddi|zuHause>Wolf01: that's a bad idea in general
07:45<andythenorth>maybe we just leave it in AV8 :P
07:45<Eddi|zuHause>Wolf01: and you mean "addons"
07:45<Eddi|zuHause>andythenorth: at least provide parameters "disable <X> vehicle type"
07:45<Wolf01>maybe, plugin, addon, the same for me :D
07:45<andythenorth>Eddi|zuHause: I would / already do
07:46<andythenorth>but I am not convinced by parameters - I had not understood that players can't change them during gameplay
07:46<Eddi|zuHause>Wolf01: the dbset extension is only because he didn't have anything that was releaseable on its own
07:46<Eddi|zuHause>andythenorth: how is that relevant?
07:47<andythenorth>because hiding / showing vehicles by parameter is a stupid reason to have to start a new game
07:47<andythenorth>it literally sucks to have to restart because a vehicle is missing
07:47<andythenorth>and there's likely no good fix for that
07:47<andythenorth>unrelated - it also sucks to have to restart to change running costs
07:48<andythenorth>I have always been somewhat against parameters and increasingly I think they should only be used for extreme cases
07:49<andythenorth>I am inclined to rebalance HEQS against base vehicles and remove the cost parameters
07:49<andythenorth>I think vehicle sets with their own running cost parameters is a bad pattern
07:50<Eddi|zuHause>changing base costs was never a good idea...
07:51<andythenorth>it was prior to engine pool
07:51<Wolf01><andythenorth> and there's likely no good fix for that <- custom configurator interface based on grf data
07:52<andythenorth>can't remove a vehicle type that has instances in game though
07:52<andythenorth>and configurator would have to be MP safe
07:54<andythenorth>Eddi|zuHause: what are the reasons for needing to disable <X> vehicle type?
07:55<Eddi|zuHause>andythenorth: like "i use heqs only because of the trams", then i'd want to disable the dump trucks, the planes, etc.
07:55<andythenorth>and also for MP...?
07:55<andythenorth>because it seems common to 'ban vehicle type X' on MP?
07:56<Eddi|zuHause>i have no opinion about MP
07:56<Pikka>changing base costs is much better now than it used to be
07:56<Pikka>because it's on a per-grf basis
07:56<andythenorth>I had a massive oversight though
07:56<andythenorth>I've been happily changing running costs in game using parameters
07:56<andythenorth>but users can't do that
07:57<Pikka>also, base vehicles running costs suck :)
07:57<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?
07:57<andythenorth>not me :P
07:57<andythenorth>it's a crap shoot :P
07:58<andythenorth>I think it's a misfeature
07:58<Pikka>what's a misfeature?
07:58<andythenorth>cost multiplier parameters on newgrfs
07:58<Ammler> <-- something broken or just me?
07:59<Pikka>yes, it is a very silly idea
07:59<andythenorth>I thought it was great - but I didn't know that users can't change parameters during gameplay
07:59<Pikka>they can if they try hard enough
07:59<andythenorth>but mostly they'll just do something else :P
07:59<Ammler>servers 1.1.1 are lost
07:59<Pikka>anyway, there's already an option for people to dial the running costs up and down :P
08:00<@Alberth>Ammler: except for some chinese characters in some names, the page seems to work
08:00<Ammler>Alberth: you have 1.1.1 listed?
08:00<Eddi|zuHause>Pikka: the main problem is balancing vehicle costs between grf sets
08:01<Pikka>I find I don't have that problem
08:01<@Alberth>Ammler: nope
08:01<Ammler>it looks like "current stable" is broken
08:01<Eddi|zuHause>Pikka: if i use GermanRV and HEQS, both have completely different running costs
08:01<@Alberth>but I do have 1.1.2-RC1
08:01<Eddi|zuHause>or if i use eGRVTS and HEQS, it's different again
08:01<Pikka>well, don't use germanrv and heqs then :P
08:02<Pikka>didn't we have this discussion in PM recently? :P
08:02<Ammler>Alberth: last time I checked, the page was grouped in latest stable first and then the rest
08:02<Eddi|zuHause>"we" have been having this discussion for years :p
08:03<Pikka>yes. but a group of us discussed it particularly not long ago :)
08:03<@Alberth>Ammler: I don't look at that page ever :)
08:03<andythenorth>match to default costs + cost parameters is the current winning conclusion iirc
08:03<andythenorth>but I don't like cost parameters :P
08:03<Ammler>I did by accident, that is why I am not sure if it is broken :-)
08:05<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.
08:05<Pikka>and even if they did
08:05<Pikka>I wouldn't. :P
08:10-!-lugo [] has joined #openttd
08:12<@planetmaker>which is much more so an argument for a parameter to allow people to adjust running and purchase costs
08:12<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?
08:12<@planetmaker>it's a shame if otherwise good newgrfs just don't play along eachother "just because"
08:13-!-glx [glx@2a01:e35:2f59:c7c0:80b8:3a5c:fa0:9466] has joined #openttd
08:13-!-mode/#openttd [+v glx] by ChanServ
08:14<@Alberth>LordAro: perhaps the other windows are wrong too? ;)
08:14<LordAro>:) yeah, the other thought was a new patch on the queue that added it to all of them
08:16<LordAro>y/n? but it at the bottom of the list of things todo?
08:17-!-davis [] has joined #openttd
08:17<@planetmaker> <-- and that's the long(er) version 'why' ;-)
08:17<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
08:17<@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.
08:18<@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
08:20<andythenorth>the cost parameter is only of use to quite expert users
08:20<andythenorth>maybe it's unfair to call it a misfeature
08:20<andythenorth>but it's unlikely useful to the majority of players
08:22<LordAro>Alberth: ok, in that case, i need help on making the patch run :) because i'm stuck
08:24<@Alberth>you'll have to explain what you need, as "write patch; compile; ./openttd" is probably too global help on making it run :)
08: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
08:27<LordAro>i have no idea how to fix either
08:27<LordAro>afk lunch
08:28<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.
08:30<@planetmaker>andythenorth: why is it not useful to the majority?
08:30<@planetmaker>Most will use default settings, yes. And most will assume that different NewGRFs play along without config
08:31<@planetmaker>But the chance to set costs... is not a miss-feature IMHO. A maglev needs to cost more than the steam train ;-)
08:33<Pikka>so does that mean I need to allow for people who make grfs with ridiculously cheap maglevs?
08:34<@planetmaker>Pikka: no.
08:34<@Alberth>LordAro: do you read your saved logs? I am *very* sure I explained about not copying 9/13 characters
08:34<@planetmaker>But what it IMHO means is to take the default prices as a guide for default price levels
08:34<Pikka>what if we think the default prices are rubbish?
08:35<@planetmaker>global price levels are easily changed by a global base cost newgrf
08:35<Pikka>no they're not
08:35<@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
08:35<@planetmaker>and then it works for ALL newgrfs and you don't get an imbalance
08:35<@planetmaker>how they're not?
08:35<Pikka>vehicle base cost multipliers are grf specific these days
08:36<@planetmaker>Pikka: yes and no :-)
08:36<@planetmaker>they're grf-specific, if you define vehicles
08:36<@planetmaker>they're global, if you don't
08:36<@planetmaker>did you ever try a global base cost grf?
08:36<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
08:36<Pikka>because then about 0.01% of people will get the gameplay experience intended
08:36<@planetmaker>the order is unharmed and of no consequence, if you define vehicles. There they're local
08:37<@planetmaker>the base cost grf then changes everything
08:37<@Alberth>Pikka: maglevs are cheap whatever you do, as by that time I am more than wealthy
08:37<@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
08:39-!-TWerkhoven [] has quit [Ping timeout: 480 seconds]
08:39<@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
08:40-!-KritiK [] has joined #openttd
08:40<Hirundo>IMO, 'balance against default' should be one of the options, but not necessarily the default one
08:41<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.
08:41<Hirundo>Getting a good 'out of the box'-experience is important also, which requires somewhat sane prices
08:41<Pikka>indeed Hirundo
08:41<@planetmaker>Pikka: yes, there certainly can be different definitions of 'balanced against default'.
08:42<@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
08:42<@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
08:42<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?
08:43<krinn>why not 2 grf: one for cost, one with the gfx ? Costs lovers download them both, "classic" users download only the gfx one
08:43<@planetmaker>krinn: that's what base costs do... But you'll still have to adjust relative costs...
08:43<@planetmaker>and to split that for a single newgrf is somewhat pointless.
08:44<@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
08:44<@planetmaker>if the newgrf itself allows adjustment via parameter
08:44<Rubidium>making everything twice as costly in OpenTTD is easy!
08:44<Rubidium>custom currencies FTW
08:44<@Alberth>krinn: if you balance against something common, such as default vehicles, you need only one cost grf
08:44<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...
08:45<@Alberth>Rubidium: but then I get also twice as much money for cargo delivery
08:45<@planetmaker>krinn: please have a look how base cost newgrfs work
08:45<Rubidium>Alberth: yes... cargo delivery costs twice a much
08:45<krinn>planetmaker, yep speaking of something i don't know
08:46<@planetmaker>yes. If you knew you'd see your suggestion is... more difficult and troublesome than can already now be done
08:47<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"
08:49<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?
08:49<krinn>because they are at end of game, why would i don't see 95% of the grf ?
08:50<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?
08:51<krinn>because maglev are within the 100% too, why would you then wish remove the 5%
08:53<Pikka>if you're making a "realistic" set maglev is very hard
08:53<krinn>i don't care realistic, and if one care about realism, then why wouild maglev should cost more ?
08:53<krinn>in life it's not how it work:
08:53<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
08:53<krinn>when tech goes out, it cost a lot, but prize goes down fast
08:54<Pikka>who said maglev should cost more?
08:54<@Alberth>LordAro: no function, a for loop over the characters
08:54<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
08:55-!-pugi [] has quit [Ping timeout: 480 seconds]
08:56<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
08:56<Pikka>one day I will make a seperate maglev/monorail only futuristic set that's balanced against my other grfs
08:56<Pikka>but that day is not today :)
08:57<@planetmaker>well... I may still wish for a parameter which allows me to use your NewGRFs with unmodified base costs ;-)
08:58<Pikka>you may wish
08:58<@planetmaker>when is Christmas?
08:58<Pikka>around christmas
08:59-!-MNIM [] has quit [Remote host closed the connection]
08:59<@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 :-)
08:59<@planetmaker>so. enough lobbied for today :-P
09:00-!-MNIM [] has joined #openttd
09:00<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?
09:01-!-pugi [] has joined #openttd
09:01<andythenorth>planetmaker: I will re balance HEQS against default vehicles I guess
09:01<andythenorth>dunno about FISH
09:01<@Alberth>by copying, I'd say
09:01<@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 :-)
09:01<@planetmaker>I just know nothing better than bugging everyone to add these two parameters
09:01<@planetmaker>(or to add in the openttd-side per-newgrf config capability - but that'd be... somewhat insane, too
09:02<andythenorth>so here's the thing
09:02<andythenorth>does opengfx + RVs have a cost parameter?
09:02<andythenorth>so I have HEQS and opengfx + RVs in my game
09:02<andythenorth>both have parameters
09:03<andythenorth>so both can be adjusted with respect to each other
09:03<@planetmaker>leave them untouched. And use a base cost grf ;-)
09:03<andythenorth>what's the correct settings?
09:03<@planetmaker>but yes, they could. You'll have to know the correct settings
09:03<@planetmaker>or test
09:03<andythenorth>and how do I test?
09:03<andythenorth>I have to start playing a game
09:03<@planetmaker>set parameters, create map, check depot / purchase list
09:03<andythenorth>then having played enough of it, I have to quit
09:03<@planetmaker>repeat. Ad nauseam
09:03<andythenorth>then I have to roll the dice again
09:03<andythenorth>it's a crap user experience
09:04<@planetmaker>nah, you don't need to play to adjust.
09:04<@planetmaker>Just create map, check. Re-create
09:04<@planetmaker>until it fits. Only then play
09:04<@planetmaker>everything else is stupid
09:04<andythenorth>but that assumes you can forward-model the money you're going to make on routes
09:04<andythenorth>which might vary by industry set or other things
09:05<@planetmaker>I'm talking about the relative costs of vehicles mostly
09:05<@planetmaker>that's easy to check
09:05<@planetmaker>absolute cost levels... that's indeed more difficult
09:05<andythenorth>but still they might be the wrong costs for the game you want to play
09:05<@planetmaker>so, what's the option?
09:05<andythenorth>because everyone can set costs - it's almost impossible to solve
09:06<@planetmaker>allow to configure costs on newgrf hardcoded, newgrf parameter, base cost parameter and openttd cost parameter, all at once?
09:06<@planetmaker>Not helping either
09:06<andythenorth>so the solution is one-author(s)-provides-all-grfs
09:06<andythenorth>so we're back to 'balance against base costs'
09:06<@planetmaker>That's not happening. As such: balance against...^yeah
09:07<andythenorth>which might as well be 'stop dicking around letting newgrfs set as many costs'
09:07<andythenorth>there are n valid sets of costs which will result in a worthwhile game
09:08<andythenorth>costs need to be coherent across multiple aspects
09:08<andythenorth>how many cost universes do we currently Have?
09:08<andythenorth>- default
09:08<andythenorth>- pikka world
09:08<Pikka>so what do you do when that valid set of costs doesn't fit within the default vehicles' range of possible costs?
09:08<@planetmaker>- DJN world
09:08<andythenorth>- Can world
09:08<andythenorth>- MB world
09:08<andythenorth>- zeph world
09:08<andythenorth>numerous of these are incoherent though
09:09<andythenorth>only base world and pikka world have enough stuff done to be coherent
09:09<Rubidium>don't forget a Rubidium world...
09:09<@planetmaker>Pikka: as said: writing a newgrf can mean to adjust the base costs still. But the price should be adjusted to match defaults.
09:09<LordAro>Alberth: copying how? i've done some searches, but there's nothing (all about using <cstring>)
09:09<Rubidium>there where everything will be Rubidium coloured ;)
09:09<andythenorth>Rubidium when did you last ship a (non-trunk) grf?
09:10<LordAro>again, i apologize about being entriely out of my depth :L
09:10<@planetmaker>I.e. a super-duper-mega train from year 3000 may still be at base cost +2 to match the defautl trains
09:10*andythenorth wonders
09:10<@planetmaker>currently you also have to do with one base cost settings per newgrf, nothing changes there. Just the 'level' which you adjust against
09:11<Rubidium>which means greyish white and red
09:11<@planetmaker>the general level of costs
09:11<Pikka>I still prefer my grfs, they're more interesting. :)
09:11<andythenorth>maybe I just change the parameters in my grfs
09:11<@Alberth>LordAro: dest = buffer; for (char *src = buffer; *src; src++) *dest++ = *src;
09:11<@Alberth>LordAro: ie do many assignments
09:11<andythenorth>1 setting. 2 options: 'default costs', 'pikka costs'
09:11<@planetmaker>Pikka: yes, that most probably is true - I don't even disagree there.
09:11<andythenorth>FISH is matched to pikka costs (also assuming FIRS use)
09:12<@planetmaker>My whole argument is only for the sake of interoperability of newgrfs
09:12<@planetmaker>And the only really common base line is: default vehicle costs and running costs.
09:12<Pikka>to take av8 as an example
09:12<Fish-Face>hi btw
09:12<@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.
09:12<Rubidium>andythenorth: does being a co-author count?
09:13<@planetmaker>I don't argue really to change your relative balance
09:13<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
09:13<@planetmaker>yes. I understand that you stretch the costs more. I'd actually not go that far to argue against that.
09:13<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
09:13<Rubidium>andythenorth: and does it count when bits of said NewGRF have their origin in openttd[dw].grf?
09:14<@planetmaker>I'd only argue to adjust the "average" plane to match the "average" default plane
09:14<@planetmaker>more cannot be asked.
09:14<andythenorth>I suspect it's easier to just ask players to make simple(r) choices
09:14<@planetmaker>Yes, the result will be that your concorde and the default concorde might be off by a factor of 2?
09:15<@planetmaker>But not by a factor of 20
09:15<Pikka>default costs $21k a year, mine costs $236 a year
09:15<Eddi|zuHause>you have to consider inflation
09:15<Rubidium>that's cheap
09:16<@planetmaker>yes, but you changed the running base cost to +2 relative, right?
09:16<Pikka>eddi: numbers are with inflation turned off
09:16<@planetmaker>if you made that 0 relative, then it'd be a factor of 3.
09:16<Rubidium>there's another setting that influence (some) prices... what was it?
09:17<andythenorth>construction cost?
09:17<Eddi|zuHause>difficulty level
09:17<@planetmaker>the base running cost setting stretches the scale.
09:17<Rubidium>ah yes, andy's right
09:17<andythenorth>even a stopped clock tells the right time twice a day
09:18<Rubidium>andythenorth: not necessarily...
09:18<Eddi|zuHause>not when it's blinking 0:00, and at exactly 0:00 the blinking is off :p
09:18<Rubidium>could also do it just once or thrice
09:19<andythenorth>this is much harder because the default costs are all wrong
09:19<andythenorth>so balancing RVs against them is nonsense
09:20<andythenorth>if the default costs weren't wrong, some of this mess would not be necessary
09:20-!-LordAro [] has quit [Ping timeout: 480 seconds]
09:20<andythenorth>for RVs, pegging to the baseline of default RVs is just stupid
09:20<andythenorth>so there is no baseline for RVs. I used eGRVTS as my baseline for HEQS, but it's way too cheap
09:21<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)}"?
09:21<andythenorth>mess mess mess :D
09:21<Rubidium>the whole payment is wrong ;)
09:21<@planetmaker>Eddi|zuHause: that might be a guide. But what do you choose, if you have heqs, germanRV and egrvts
09:21<krinn>it as sense if you intend to play fun and not realistic, and fun is primary goal of openttd
09:22<krinn>(for me)
09:22<Eddi|zuHause>planetmaker: that's the players fault.
09:22<@planetmaker>Eddi|zuHause: but that's the point. It must not be
09:23<@planetmaker>the grfs should just play along
09:23<Rubidium>e.g. short trips shouldn't make busses totally profitless, and long trips shouldn't be massive profit makers
09:23<Eddi|zuHause>planetmaker: that is impossible to achieve.
09:23<andythenorth>it's not so hard to achieve
09:23<@planetmaker>relative balance among each set is one thing - that's very hard to agree upon
09:24<andythenorth>(1) fix default costs for the ones that are broken (RVs, others??)
09:24<@planetmaker>But the relative costs of the newgrfs wrt eachother - that can be achieved
09:24<andythenorth>(2) grf authors match to base costs, and/or to other schema (e.g. pikka-costs)
09:24<Eddi|zuHause>planetmaker: it cannot. ever.
09:24<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
09:24<andythenorth>players use difficulty setting to change base costs
09:25*andythenorth gtg
09:25<andythenorth>this seems solvable for once - bbl
09:25<Pikka>gnight andy
09:25<@planetmaker>of course it can, Eddi|zuHause. Not to a factor of 2 or 4. But within that bounds: yes
09:25<andythenorth>bye mr bird
09:25<@planetmaker>bye bye, andythenorth
09:25-!-andythenorth [~Andy@] has quit [Quit: andythenorth]
09:25<Eddi|zuHause>planetmaker: you cannot force grf authors.
09:26<@planetmaker>yes, one cannot. That's why I *argue* for people to use a quasi standard
09:26<@Alberth>except by changing the newgrf specs :)
09:26-!-TWerkhoven [] has joined #openttd
09:26<Rubidium>which would be funny because... when you replace all trains with super fast trains, they won't make as much money anymore
09:26<@planetmaker>like you cannot force newgrf authors to also use the default cargo classes and labels. But they do
09:27<Pikka>that's because it makes sense
09:27<@planetmaker>yes :-)
09:27<Pikka>but there's a number of different philosophies when it comes to pricing
09:27<Eddi|zuHause>planetmaker: apples, pears.
09:27<@planetmaker>I do well understand that. And I'm not arguing against different pricing philosophies. I'm arguing for approx. similar price *levels*
09:27<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?
09:28<Eddi|zuHause>planetmaker: it's a futile effort.
09:28<@planetmaker>The relative balance purchase and running costs is player's choice
09:28<@planetmaker>Eddi|zuHause: anything constructive?
09:28<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
09:29<Eddi|zuHause>no. it's wasted thought power.
09:30<@planetmaker>not at all. If the main grf authors could agree to use comparable price *levels* - the biggest part of the problem is gone
09: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?
09:30<@Alberth>Pikka: sum the purchase cost + running cost over the entire lifetime, and balance that number w.r.t. default vehicles?
09:31<@planetmaker>ach. That's all not the point, Pikka
09:31<@planetmaker>People ususally just want "those nice vehicles"
09:31<@planetmaker>The exact purchase prices and running costs are of little importance as the economy is dead simple anyway
09:31<Pikka>well, they can have them
09:31<Rubidium>pff... alt-1 solves all pricing problems
09:31<@planetmaker>but what DOES impact game fun is if things are grossly out of proprotion among differently concurrently used sets
09:32<Pikka>I'm going to go out on a limb here and say "no it doesn't"
09:32<@planetmaker>and the 'grossly-out-of-proportion' would be gone if there'd be somewhat a comon average price for each vehicle set
09:32<Pikka>people who lump in every grf they can find don't care about details like that
09:32<@planetmaker>Pikka: it's not about that. Ach...
09:33<@planetmaker>But pretty please tell me how I shall play a European scenario with Dutch, German and UK trains?
09:33<@planetmaker>I can't. It will be fucked relative costs
09:33<@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
09:33<Rubidium>german trams + japanese trains + aviator planes + dutch rvs + spanish ships?
09:34<Rubidium>(maybe contains ficticious sets)
09:34<@Alberth>with a max loan of 300,000 the choice is easy
09:34<@planetmaker>The argument "only crazy people mix newgrfs" is not an argument
09:34<@planetmaker>people generally do that. And many have a good reason for their choice
09:34<@planetmaker>so the argument is "how can in general the fun be enhanced"
09:34<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.
09:35<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
09:35<@planetmaker>Pikka: for exactly those people who like to play elaborate scenarios. Like I just said, for example a European scenario.
09:35<@planetmaker>I cannot get grfs to agree on an even roughtly price level
09:35<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
09:35<@planetmaker>even with the best effort save of adding openttd-side per-grf cost settings
09:36<Rubidium>IMO if you want an elaborate scenario you don't care about the original vehicles, or do you?
09:36<@planetmaker>Pikka: I'm not arguing the *relative* balance of your costs
09:37<@planetmaker>They're fine
09:37<Rubidium>you'd almost get the idea to make the scaling of vehicle costs against other sets configurable per NewGRF
09:37<@planetmaker>I'm *only* arguing about base cost levels
09:37<Pikka>neither am I, planetmaker
09:37<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
09:37<@planetmaker>and the general base cost levels IMHO are rather to the player - or an economy grf much better
09:37<@planetmaker>as you then can balance also the track and road costs
09:38<Rubidium>e.g. they are too expensive, so you make them cheaper (as end-user)
09:38<@planetmaker>and you'd apply that to other vehicle sets as well
09:38<Pikka>I'm saying that my aircraft need to have running costs 5-10 times the default vehicles in order to be interesting :)
09:38<Pikka>ditto trains in UKRS, etc.
09:38<@planetmaker>Pikka: what's "interesting"? That type of "interesting" would apply also to other newgrfs.
09:39<Pikka>I agree
09:39<@planetmaker>So what's the pain in changing the base costs in a "Pikka interesting costs" grf?
09:39<Pikka>because no-one will use it
09:39<@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
09:40<@planetmaker>to another interesting economy
09:40<@planetmaker>Oh, I'm very much sure people would use it, if it came from you
09:40<@planetmaker>call it pikka economy ;-)
09:40<Rubidium>planetmaker: just use the per-newgrf price scaling I just proposed ;)
09:40<Pikka>by doubling or halving all costs? it's hardly a subtle "rebalancing" feature...
09:40<@planetmaker>Rubidium: on the openttd-side?
09:40<@Alberth>perhaps *require* a cost grf to be loaded?
09:40<Rubidium>planetmaker: yep
09:40<Rubidium>like the palette setting
09:41<@planetmaker>yes, that's the only alternative. And I'm quite tempted to go that way.
09:41<Rubidium>(but not queryable by the NewGRF)
09:41<@planetmaker>But I first want(ed) to try and see whether that's necessary
09:42<@Alberth>Pikka: so the cost setting is not fine grained enough. that is a separate issue from balancing sets against each other
09:42<@planetmaker>And it'd not solve the issue that it then still would be a pain to configure things
09:42<@planetmaker>It'd add yet another layer of settings
09:42<Pikka>balancing sets against each other is not an achievable feature, though
09:42*Alberth thinks stuff should be removed instead of added
09:43-!-Sacro1 [] has joined #openttd
09:43<@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
09:43<@Alberth>Pikka: sure you can, but you need to agree on how you balance
09:44<Pikka>yes Alberth
09:44<Pikka>and we don't
09:44<@planetmaker>and that's the issue
09:46<@Alberth>you'd need to give purchasing costs / running cost balance to the user, I think
09:46<Pikka>and it is an issue because...?
09:46<@planetmaker>I don't see the problem in using no base costs for vehicles and using the global base cost mods to set economies
09:46<@planetmaker>that'd make the game MUCH more user-friendly
09:46<@planetmaker>it's user-friendlyness
09:47<@Alberth>as in, 'purchasing costs / running cost balance' is not a property of a single newgrf but of all loaded newgrfs
09:47<Pikka>remove the newgrf loading code, that'll make the game more user-friendly
09:47<@planetmaker>well, sulking and sarcasm don't help
09:48<Pikka>it's not, it's a point
09:48<Pikka>how is loading more grfs and setting more parameters /more/ user-friendly than what we have now?
09:48<@Alberth>it does not lead to a solution
09:48<@planetmaker>Pikka: exactly
09:49<@planetmaker>And that's exactly why I argue for a *common* base cost reference
09:49<@planetmaker>and not every grf defining its own idea how general price and running cost levels should be
09:49<Pikka>the latter seems much more user-friendly to me
09:49<Pikka>if grfs can run out-of-the-box as their author intended
09:49<@planetmaker>because if they all would use a common base level, then there'd be only one setting which sets it globally.
09:49<@planetmaker>dead easy
09:49<@Alberth>it leads to chaos, as the current situation proves
09:50<Pikka>what current situation?
09:50<@planetmaker>no, configuring 10 grfs individually, each having a separate idea of what is good is very user unfriendly
09:50<@planetmaker>^ that
09:50<Pikka>well my grfs aren't a problem there, because you can't configure them :)
09:50<@Alberth>Pikka: different grfs having different ideas about costs.
09:51<@Alberth>and no flexibility for the user to correct it
09:52<Pikka>"the user" doesn't have a clue about what is an appropriate base cost
09:52<@planetmaker>that's why I suggest you make a newgrf called "pikka economy"
09:52<@Alberth>so set some default. but advanced users should be able to do it
09:53<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?
09:53<@planetmaker>well, it's two issues we have here: a) the default value and b) possibility to change defaults
09:53<@planetmaker>hu, Pikka?
09:53<@planetmaker>what's your point?
09:54<Pikka>my point is that that doesn't sound very user-friendly :)
09:54<@planetmaker>my point is: "economy balancing needs to be done globally". Not on a per-vehicle-grf basis
09:55<@planetmaker>and the latter is the case everywhere. Resulting in a great mayhem
09:55<@planetmaker>a base cost grf needs to have no single parameter
09:55<@planetmaker>or one which just selects different 'economies'. Very simple. Very user-friendly
09:55<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)
09:55<@planetmaker>so where's there your argument?
09:56<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?
09:56<@planetmaker>what shall happen?
09:56<@planetmaker>nothing will happen
09:56<Pikka>then they'll be playing av8, with the grf that sets the av8 base costs loaded, but still with the wrong base costs.
09:57<@planetmaker>what is "wrong"?
09:57<Pikka>and they'll have no idea that it's happened, or how to fix it.
09:57<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€
09:57<@planetmaker>is your idea on cost levels "right" and mine "wrong"?
09:57<@planetmaker>why? why not?
09:58<@planetmaker>it's no mistake nor error nor bug to play with av8 ad /4 running costs
09:58<Pikka>yes it is
09:59<@planetmaker>you miss the argument still: general running and purchase costs are a global thing
09:59<@Alberth>Pikka: so disable yourself if the pikka costs are not loaded
09:59<@planetmaker>but what you can make sure is that different vehicles of the same type play along somewhat kindly
09:59<@planetmaker>Alberth: NO!
10:00<Pikka>no you can't, planetmaker
10:00<Pikka>my view of what's a good cost balance is different from MB's or george's
10:00<@planetmaker>Pikka: exactly
10:00<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
10:01<@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
10:01<@planetmaker>dead easy. On newgrf authors as well as players
10:01<@planetmaker>currently an economy newgrf is pointless as it cannot balance individual newgrfs
10:02<Pikka>they can't balance the vehicle costs. they can balance the other costs still, presumably?
10:02<@Alberth>planetmaker: why not, if an author considers HIS ideas so important that he cannot live without, let him
10:03<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 ?
10:03<@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"
10:03<@planetmaker>and possibly a switch of "ignore all base cost commands in newgrfs"
10:03<@planetmaker>to make the thing easier to configure
10:04*Alberth ponders to do automagic cost calculations based on physical properties of the vehicles
10:04<@planetmaker>and more user-friendly
10:04<@planetmaker>and thus brute-force cooperation
10:06<@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:
10:07<@planetmaker>- Assumption 1: player use several vehicle newgrfs alongside and don't know or like to put work into configuration
10:07<@planetmaker>- Assumption 2: players like to have approximately price levels of different grfs in sync
10:08<@planetmaker>- Assumption 3: costs / difficulty should be a globally configurable thing (that's why we also have diffiuclty settings)
10:08-!-KouDy [] has joined #openttd
10:10<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)
10:10<@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?
10:11<JVassie>hi Pikka
10:11<JVassie>loving the new Electrostar :)
10:12<@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
10:12<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?
10:12<@planetmaker>and yes, with 3 also I don't find it easy to avoid all traps
10:12<Pikka>question 2, how do you know that vehicles with different base cost multipliers aren't balanced against each other?
10:13-!-Adambean [] has joined #openttd
10:14<@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
10:14<@planetmaker>ad 2) much more likely than the other way around
10:15<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.
10:16<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
10:17<@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?
10:17<@planetmaker>the only option then, if newgrfs aren't "nice" is "ignore their idea and use a globally defined one"
10:17<@Alberth>s/introduce/force/ imho
10:18<Pikka>the option is "accept the possibility that newgrfs aren't '"nice"'.
10:18<@planetmaker>they aren't. And you argue - as it comes accross - "I don't want to be nice" ;-)
10:19<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?)
10:19<@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
10:20<@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.
10:20<@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
10:22<Pikka>but that presupposes that grf authors can balance the economy in a meaningful way, which seems to be something you doubt :P
10:23<@Alberth>balance between sets is a requirement before even considering that
10:24<Pikka>what about balance within sets? The balance between purchase and running cost, for example?
10:24<@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
10:24<@planetmaker>Pikka: no such balance. That's part of economy
10:27<@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
10:27<Pikka>but the balance /within/ that purchase/running factor is not necessarily the same between sets
10:28<Pikka>as in the case of NARS I quoted above, and UKRS2 which has inherited NARS's base costs
10:29<@planetmaker>base costs are economy
10:29<Pikka>all of the running costs of vehicles in UKRS2 are in the bottom half of the running cost range
10:29<@planetmaker>only (relative) costs are grf
10:30<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
10:30<@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)
10:30<Pikka>which is what we have now, Alberth
10:31<Eddi|zuHause>are you still discussing this?
10:31<Pikka>apparently we are
10:31<Eddi|zuHause>i told you it's going nowhere...
10:31<@planetmaker>Eddi|zuHause: if you don't intend to be constructive, can you shut up?
10:31<@Alberth>Pikka: but a factor 10 difference is just plain stupid
10:32<Eddi|zuHause>i've been quiet for an hour, obviously that didn't help at all
10:32<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?
10:32<Pikka>some other grf / the default vehicles
10:32<@planetmaker>Pikka: that's the point. Buy ONE newgrf trying to do it right individually you make it IMPOSSIBLE to make it right globally
10:33<@Alberth>Pikka: that is the best we could find until now
10:34<@Alberth>you are welcome to have a go too
10:35<@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.
10:36<Pikka>I think
10:36<Pikka>that most openttd players
10:36<Pikka>don't play with newgrfs
10:36<Pikka>some do, and some will load every grf they can get their hands on
10:37<Pikka>but they're a very small number, and I think of that number, those who care about balance are even smaller
10:38<@planetmaker>so you claim that people don't care about an easy and good gaming experience?
10:38<Pikka>they do
10:39-!-Juo [] has quit [Quit: Juo]
10:39<@planetmaker>from our bug reports, a very substantial part of the players meanwhile do use newgrfs...
10:40<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?
10:40<@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
10:41<@planetmaker>why does it? Where does it? An economy NewGRF which sets your base costs for ALL vehicle types is written in 30 minutes
10:41-!-Juo [] has joined #openttd
10:41<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
10:42<Pikka>yes planetmaker, but I maintain that the base cost values provided in the grfs are the /only/ valid ones for those grfs
10:42<krinn>maybe people (like me) just want your newgrf to get your nice graphisms and more diversity with vehicle -> eye candy
10:43<krinn>but still want to play openttd, not pikka's openttd
10:43<@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
10:44<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 ?
10:44<@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
10:45<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.
10:45<Pikka>the stats are as important a part of the grf as the graphics.
10:46<@planetmaker>well then. Sacrifice the usability in a heterogenous environment on grounds of "my way" :-(
10:46<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 ?
10:47<@planetmaker>they'd be enjoyed much better, if the pikka-economy was separate.
10:47<@planetmaker>Especially as that'd make sure that the other price levels would match that idea
10:47<@planetmaker>for all vehicle types etc
10:47<Pikka>for a given value of enjoyed, planetmaker
10:48<@planetmaker>yes. enjoyed as in "don't worry about config" and "it just works" would increase tremendously
10:48<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
10:48<Pikka>but if you quarter all the costs, that goes out the window
10:49<@planetmaker>nothing would change with the relative balance, nothing would be lost
10:49<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
10:51<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
10:52<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
10:52<Pikka>newgrfs really /are/ modifications to the game after all, they're not necessarily just pretty graphics
10:53<@planetmaker>yes. But they don't live alone
10:53<@planetmaker>and as such the idea of general cost levels is mis-placed in the individual vehicle grfs
10:53-!-supermop [] has joined #openttd
10:54<Pikka>what's the difference between a general cost and a specific cost?
10:55<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.
10:56<Pikka>the basecost is no less an integral part of the set balancing than the internal costs of the vehicles
10:57<@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
10:57<Pikka>they live peacefully alongside each other just fine
10:57<@planetmaker>it's that part which shoots the players foot if the wants to use tow same vehicle-type newgrfs
10:57<Pikka>no it isn't
10:58<Pikka>my set is balanced how I saw fit, author B's set is balanced how he saw fit.
10:58<@planetmaker>of course. the player cannot reasonably use them both as they often grossly disagree about general cost levels
10:58<Pikka>well, that's your perception, it's not an error in either grf
10:58<@planetmaker>and it's the player playing. So HE should set an economy how he sees fit.
10:59<@planetmaker>as such it's an error in the grf specs. yes
10:59<@planetmaker>rubidium is right all the time :-) No other solution than make grfs blind and mouth-gagged ;-)
11:00<Pikka>it's an error in the grf specs to allow an author to specify the stats of a vehicle? hmm.
11:00<@peter1138>sets can be totally unbalanced without basecosts involved
11:00<Pikka>of course they can, peter. and what constitutes "balanced" is a matter of opinion.
11:01<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
11:01<@planetmaker>I can only repeat "that's why I argue about the general level of the costs"
11:01<@planetmaker>Not individual or relative balance
11:02<@planetmaker>it's about where and how to exert control over how the player plays the game
11:02<@planetmaker>and vehicles should not control economy nor sabotage it
11:02<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
11:02<Pikka>and other grf authors may feel the same
11:02<Pikka>my grfs should not impose on theirs, nor theirs on mine.
11:03<krinn>that's what your grf are doing on players
11:03<@planetmaker>ach, that's totally past the argument, 90° tangent
11:03<Pikka>then don't use the grf, krinn
11:03<krinn>i don't, but i'm sad i couldn't
11:04-!-Juo [] has quit [Quit: Juo]
11:04<@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"
11:04<Pikka>no, that's not my answer
11:04<@Alberth>no, it is "no"
11:04<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
11:05<@planetmaker>not the style. The economical settings they prefer
11:05<Pikka>that's part of the style
11:06<@planetmaker>It thus needs to be split hard. Or we can never get a chance to tackle economy
11:06<Pikka>of course you can
11:06<@planetmaker>similar to how base costs were made grf-local only
11:07<@planetmaker>but I'm really sad that the global economy and game balance is no consideration for you as it seems
11:08<Pikka>it is of great consideration to me; that's why I make grfs balanced to the economic style I prefer
11:08<@Alberth>aka "do it my way and only my way"
11:08<Pikka>do it any way you like
11:08<@planetmaker>But it needs quite obviously a global solution. Or it will fracture and shatter
11:08<Pikka>just let me do it any way I like :)
11:09<@planetmaker>Pikka: and my argument was: do the way you like. But please do that via a *global* economy newgrf
11:09<@planetmaker>Not on the local level
11:09<@planetmaker>as the local tiddle-taddle-fixing destroys the global picture
11:10<Pikka>planetmaker: what kind of economy "fixing" do you have planned?
11:10<Ammler>why does that matter, can't you still make such a global economy set?
11:10-!-Adambean [] has quit [Ping timeout: 480 seconds]
11:10<Pikka>yes Ammler, but most people won't use it
11:11<Ammler>yes, the question was for pm :-)
11:11<Pikka>and so my other grfs will not have their proper valies
11:11<@planetmaker>Pikka: none. Or any arbitrary one. But the 'global' scope would make sure the same balancing would apply equally to ALL vehicles
11:11<Ammler>as the costs are "chained" already
11:11<Pikka>yes, you can, but it won't "balance" misc vehicle sets :)
11:12<Pikka>planetmaker: setting a basecost is not the same thing as "balancing"
11:13<@planetmaker>but my whole argument has only been about the base cost level... *sigh*
11:13<Ammler>using basecosts on a vehicle set is just for changing bandwith
11:13<Ammler>should not be used for "economy"
11:13<@planetmaker>but most vehicle newgrfs do
11:13<Pikka>ammler wins a coconut :)
11:13<Ammler>planetmaker: not sure
11:14*planetmaker knows
11:15<Ammler>but aren't you still able to change costs of a pikka set via a basecosts grf?
11:15<Pikka>no Ammler, vehicle grfs which set their own basecosts are now independent
11:15<@planetmaker>Ammler: only if it's the only newgrf of that kind
11:15<Ammler>well, you could use override, can't you?
11:16<Pikka>possibly :)
11:17<Pikka>but I don't see why one would want to
11:17<Ammler>planetmaker: do you ask grf authors to not use basecosts at all?
11:17<Ammler>I mean in same set as the vehicles
11:18<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
11:18<krinn>and so players wishing to play like pikka could installl pikagfx+pikaeconomy
11:18<Ammler>krinn: pikka does that
11:19<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?
11:19<Pikka>correct Ammler
11:20<@planetmaker>Ammler: no.
11:20<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
11:20<Ammler>so what?
11:20<@planetmaker>try to match running costs with any other trainset. You have a 66% chance to fail
11:20<Ammler>krinn: there aren't many such newgrfs available are there?
11:21<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.
11:21<Ammler>planetmaker: and solution would be?
11:21<@planetmaker>not setting the running cost base to +2
11:21<Ammler>Pikka: yes, but with different newgrfs
11:22<Ammler>and ukrs does not change costs of av8, right?
11:22<Pikka>right, but I don't think that's planetmaker's issue
11:22<@planetmaker>it isn't
11:22<@planetmaker>my issue is that I have no chance to balance Dutch TS, DBXL and UKRS2 against eachother
11:23<Pikka>his issue is that grfs which add vehicles should not significantly change the gameplay from default
11:23<Pikka>so that all newgrfs from all authors may be used together in a coherent manner
11:23<@planetmaker>s/gameplay/vehicle purchase cost and running cost levels/
11:24<@planetmaker>quite so, yes
11:25<Ammler>I see, well you could create as said a economy grf additionally
11:25<Ammler>no need to change anything in the existing grfs
11:26<Pikka>@ planetmaker or me?
11:26<Ammler>does not matter who does it :-)
11:26<Pikka>planetmaker is looking at this from an average player point of view
11:26<Ammler>kind of makepikkasetsbehavelikedefault.grf
11:26<Pikka>he wants all newgrfs to be compatible by default
11:26<Pikka>where "compatible" means "have costs in roughly the same ballpark"
11:27<@planetmaker>or at least have a parameter which allows me to do that
11:27<Ammler>but default costs aren't good, planetmaker
11:27<@planetmaker>I don't say they are.
11:28<@planetmaker>that's what you have economy newgrfs (aka base cost newgrfs) for
11:28<@planetmaker>please don't make me re-iterate the discussion. Just read back, ok?
11:28-!-frosch123 [] has quit [Remote host closed the connection]
11:29<Ammler>nah, it's fine
11:29<Ammler>anyway, what about my suggestion?
11:29<@planetmaker>or try to get 2ccts, ukrs2 and dbset to a somewhat sane cost levels concurrently in one game
11:30<@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
11:30<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
11:30<Ammler>or simply make a "fixdefaultcosts.grf"
11:31<Ammler>planetmaker: well, then you will have the same issue with every author, not just pikka
11:31<@planetmaker>Ammler: please just try to balance those three train grfs and see.
11:31<Ammler>and it is not really that easy to convince someone to make his grf worse just to be compatible
11:31<@planetmaker>there's no single way existing which does that now
11:31*Pikka gives Ammler another coconut
11:32<Ammler>worse from his view, of course :-)
11:32<Ammler>Pikka: but you could make a "makeMyGrfsLikeDefault.grf" :-P
11:32<@planetmaker>he could just add a parameter. done
11:32<Pikka>ammler: often requested. :)
11:33<Ammler>planetmaker: or that
11:33<Ammler>Pikka: parameters are no issue as long as you have good default
11:34<Ammler>like ukrs needed parameters per default was bad
11:34<Pikka>but UKRS2, not so bad. :) so I'm not really interested in giving players an easy mode button.
11:34<Ammler>might be good idea to "force" peple reading the readme :-P
11:35<@Alberth>Ammler: just like reading of the licenses in current software ?
11:35<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.
11:35<Ammler>the sets from eis_os needed a code as parameter to run at all
11:35<Pikka>(it could be worse, I could enforce wagon speedlimits like oztrans did :P )
11:36<@planetmaker>Pikka: it's not about taking anything away
11:37<Ammler>Pikka: that is rather a issue of openttd allowing it
11:37<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
11:37<@planetmaker>It's about how a game is best configured
11:38<Rubidium>well, the first thing we need is an option to enable those options... after all, many say there are already too many options
11:38<Rubidium>(though I doubt they looked at ttdpatch)
11:38<Ammler>krinn: the issue is that basecosts in vehicle sets are not made for economy, as said
11:38<Ammler>well, not just
11:40<@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...
11:41<Ammler>planetmaker: maybe you should make a kind of recommendation in the wiki
11:41<@Alberth>but it just gets ignored, then what?
11: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. :)
11:41<Ammler>well, something not make costs like default
11:41<Ammler>so the costs are at least useable
11:42<Ammler>and authors don't need to make the set worse
11:42<krinn>Pikka, you might miss it's not how i wish, but as it is in openttd
11:44-!-KritiK_ [] has joined #openttd
11:45-!-KritiK [] has quit [Ping timeout: 480 seconds]
11:45-!-KritiK_ is now known as KritiK
11:47-!-krinn [] has quit [Quit: Quitte]
11:51-!-andythenorth [~Andy@] has joined #openttd
11:52<Pikka>hello andy
11:52<Pikka>you missed plenty of fun :)
11:58<andythenorth>there are logs :P
11:58<Pikka>night all
11:58<Pikka>there are indeed :P
11:58<andythenorth>bye Pikka
11:58-!-Pikka [] has quit [Quit: Leaving]
11:58<andythenorth>what did I do?
12:03-!-bryjen [~bryjen@] has joined #openttd
12:09-!-davis [] has quit [Ping timeout: 480 seconds]
12:10-!-davis [] has joined #openttd
12:10<supermop>been playing a really fun 128x128 passenger timetable game
12:18-!-davis [] has quit [Ping timeout: 480 seconds]
12:18<JVassie>supermop: neat
12:18<JVassie>which set?
12:19-!-davis [] has joined #openttd
12:22<supermop>an older nightly
12:22<supermop>not too old, but not brand new
12:23<supermop>swedish houses
12:23<supermop>and nutracks
12:23<supermop>and fish
12:23<supermop>technically firs is the industry set, but there are no industries
12:24<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
12:25<supermop>ooh, also finish town names, which I always use lately
12:31-!-davis [] has quit [Ping timeout: 480 seconds]
12:31-!-davis [] has joined #openttd
12:34<supermop>I am aiming to use only one depot
12:34<supermop>(two actually, as subways need their own)
12:34*dihedral is updateding the data directory: Receiving objects: 87% (15155/17397), 676.35 MiB | 174 KiB/s
12:35<andythenorth>it's a shame Pikka is *so* against providing a baseline for costs
12:35<supermop>2cc running costs seem much higher than i remember
12:35<supermop>I am 30 years in and still have not paid off my loan, very tight margins
12:36<supermop>need to borrow for large capital projects
12:36<supermop>egrvts is printing money, of course
12:38<andythenorth>egrvts is too cheap
12:38<andythenorth>I think Zeph overshot when 'fixing' the stupid default rv costs :D
12:39<andythenorth>I have a partial solution to costs, but it has flaws
12:39<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
12:39<andythenorth>1. balance against default costs
12:39<andythenorth>2. balance against pikka sets
12:39<andythenorth>3. use parameter to select which
12:39<supermop>but currently rv revenue is about 1/3 train revenue
12:40<supermop>and cost is about 1/10 or less
12:40<andythenorth>1. default RV costs are broken, so balancing against them is broken
12:40<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
12:41<supermop>'realistically' in a large urban network the RVs should be running at a loss
12:41<supermop>and just providing synergies for the trains
12:41<supermop>but in my game its the other way around
12:42<supermop>was thinking this morning of a crazy, needlessly complex way to represent running cost
12:52<andythenorth>sounds like just what we're missing :P
12:53<Eddi|zuHause><supermop> 'realistically' in a large urban network the RVs should be running at a loss <- that should apply only after ~1960
12:53<supermop>i have the good sense to hold my tongue
12:53<supermop>well i just hit 1963,
12:54<supermop>just stumbled across this guy; love the way it looks:
12:55<supermop>too bad there is no real way to capture that look in TT sprites
12:56<Eddi|zuHause>hm... i need some cheat to get the 3lu and 4lu tenders to turn at the right place...
13:01<@Terkhen>if all costs are set to zero, all sets are balanced to each other
13:21-!-AD [] has quit [Read error: Connection reset by peer]
13:24<Hirundo>Is it possible to 'hide' an articulated part, in order to refit a vehicle to either 3 or 4 parts?
13:25<andythenorth>Hirundo: set the length to 1/8
13:25<andythenorth>use empty graphics
13:25<Hirundo>And then set another part to 7/8?
13:25<andythenorth>depends what you want to achieve
13:25<Hirundo>I don't want a gap between it and the next vehicle in the train
13:26<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
13:26<andythenorth>Hirundo: HEQS trams do it
13:27<Eddi|zuHause>it's better to set the visible vehicle to 1/8 and the invisible to 7/8, for bounding box purposes
13:27<Hirundo>My intention is to create a MU that can be refitted to 3 or 4 parts, so it needs to be coupled
13:27<@orudge>Huzzah, that in theory should be the entire TTDPatch wiki more or less tidied up now
13:27<@orudge>although I still want to do things with templates, navigation, and so on
13:27-!-AD [] has joined #openttd
13:27<Hirundo>Eddi|zuHause: Then put the visible part in front or at the back?
13:27-!-AD is now known as Guest4209
13:28<Eddi|zuHause>visible part is the front one
13:28-!-Chris_Booth [] has joined #openttd
13:28<Hirundo>so in this case <visible 8/8, visible 8/8, visible 1/8, invisible 7/8> ?
13:29<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
13:29<Hirundo>Do I need a special sprite template for that, or can I use the normal (pikka) ones?
13:29<Rubidium>not visible 8/8, visible 1/8, invisible 7/8, visible 8/8?
13:30<Eddi|zuHause>no, just use your normal sprite
13:30<Eddi|zuHause>sprite and alignment should not change
13:30<Hirundo>k, thanks
13:31-!-Sacro1 [] has quit [Read error: Connection reset by peer]
13:31<Eddi|zuHause>(at least until fs#3569 is fixed)
13:33<Rubidium>Eddi|zuHause: I fear that fixing 3569 fixes nothing for the actual drawing
13:33<Rubidium>after all, the old drawing method ought to be maintained for backward compatability reasons
13:33<Eddi|zuHause>Rubidium: any fix to this must be specifically enabled by the grf
13:34<Eddi|zuHause>a special grf flag, like 32px vehicles
13:35<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
13:37<Rubidium>which means there needs to be backward compatability code for that as well :(
13:39<Eddi|zuHause>not if you fix it quickly before we release CETS ;)
13:39<Rubidium>why? There are no newgrfs that use that var already?
13:41<Eddi|zuHause>not that i know of
13:41<Eddi|zuHause>at least not in a way that would make a difference
13:42<Eddi|zuHause>only Georges test grfs
13:43-!-Sacro1 [] has joined #openttd
13:44<Eddi|zuHause>hm, some russian train set maybe
13:45<andythenorth>so set a message that the old method will be deprecated?
13:45<CIA-2>OpenTTD: rubidium * r22701 /branches/1.1/ (13 files in 6 dirs):
13:45<CIA-2>OpenTTD: [1.1] -Backport from trunk:
13:45<CIA-2>OpenTTD: - Fix: [Network] Failed network address resolving could trigger temporary freezes [FS#4697] (r22696, r22695)
13:45<CIA-2>OpenTTD: - Fix: [NewGRF] The override managers were not reset in some cases like creating a new scenario [FS#4691] (r22693)
13:45<CIA-2>OpenTTD: - Fix: [NewGRF] Aircrafts defined with IDs above the default aircrafts always defaulted to passenger cargo (r22690)
13:46<Eddi|zuHause>andythenorth: old grfs are guaranteed to work in the future. it's part of the spec
13:46<andythenorth>I could dispute that
13:46<andythenorth>I'm sure you'd tell me I'm wrong though :P
13:46<andythenorth>it's not empirically true though
13:46<@planetmaker>Eddi|zuHause: except in the NewObject case ;-)
13:47<andythenorth>you'd need to qualify quite some more to make it true
13:47<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
13:48<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
13:48<andythenorth>^ is closer to the truth
13:48<CIA-2>OpenTTD: rubidium * r22702 /branches/1.1/ (6 files in 2 dirs):
13:48<CIA-2>OpenTTD: [1.1] -Backport from trunk:
13:48<CIA-2>OpenTTD: - Fix: Cost of adding an extra road type to a bridge or tunnel was undercalculated [FS#4680, FS#4681] (r22700, r22699)
13:48<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)
13:48<CIA-2>OpenTTD: - Fix: When building a house it could be built at the wrong place if multitile houses failed some tests (r22697)
13:49<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
13:49<andythenorth>we won't discuss flipping of trains in depot :P
13:50<Eddi|zuHause>that was never part of the spec
13:51<andythenorth>I didn't say it was :)
13:53<CIA-2>OpenTTD: rubidium * r22703 /branches/1.1/ (6 files in 4 dirs): [1.1] -Prepare for 1.1.2-RC2
13:55<CIA-2>OpenTTD: rubidium * r22704 /branches/1.1/src/lang/ (8 files): [1.1] -Backport from trunk: language updates
13:55-!-Sacro_ [] has joined #openttd
13:59<Eddi|zuHause>those two are backwards, aren't they? ;)
14:00<Rubidium>language updates are never mentioned, so the order doesn't matter much
14:01<Rubidium>just the script to generate the diff between trunk and the branch is somewhat slow
14:03-!-Sacro_ [] has quit [Ping timeout: 480 seconds]
14:16<CIA-2>OpenTTD: rubidium * r22705 /tags/1.1.2-RC2/ (. src/os/windows/ src/ -Release 1.1.2-RC2
14:18<Eddi|zuHause>wait, it's not even 45 minutes to midnight yet...
14:21<Rubidium>it's not the one without the -
14:22-!-Cyrilshark [] has joined #openttd
14:22<Cyrilshark>Hey guys?
14:24<Cyrilshark>Ah nevermind, I think I got it2026 trying to use the 32 bit graphics on my mac
14:27-!-Brianetta [] has joined #openttd
14:35-!-Sacro1 [] has quit [Read error: Connection reset by peer]
14:35-!-Sacro1 [] has joined #openttd
14:38-!-Biolunar [] has quit [Quit: All your IRC are belong to us!]
14:40-!-Cyrilshark [] has quit [Quit: Bye for now!]
14:45-!-tneo- is now known as tneo
14:47-!-bryjen [~bryjen@] has quit [Remote host closed the connection]
14:51-!-Chris_Booth_ [] has joined #openttd
14:58-!-Chris_Booth [] has quit [Ping timeout: 480 seconds]
14:58-!-Chris_Booth_ is now known as Chris_Booth
15:19-!-davis [] has quit [Ping timeout: 480 seconds]
15:22-!-bryjen [~bryjen@] has joined #openttd
15:29<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)
15: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?
15:32<Zuu>Or is the modificator multiplied with the distance again to get some value?
15:32<@planetmaker>sounds complicated :-)
15:33<Zuu>hmm, guess the source code is where one has too look in.
15:33<Eddi|zuHause>if the divisor is larger, the distance increases
15:34<Eddi|zuHause>at permissive it's distance/8, at hostile distance/16
15:34<Zuu>a := distance/8
15:35<Zuu>Is a the amount of noise that the town get?
15:35<Eddi|zuHause>effective noise := airport noise - distance/modificator
15:36-!-planetmaker changed the topic of #openttd to: 1.1.1, 1.1.2-RC2 | Website: * (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
15:36<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
15:36-!-Sacro1 [] has quit [Quit: Leaving.]
15:36<Zuu>Thanks Eddi. I'll put that formula on the wiki.
15:37<Eddi|zuHause>"alle Klarheiten beseitigt?" :p
15:40<@planetmaker>alles Chlor
15:54<Zuu>Zuu's current AI-dev wishlist: remember window positions, console command to load last loaded game :-)
15:56-!-DayDreamer [~DayDreame@] has joined #openttd
15:56<Zuu>I also think about implementing AIController.BreakAI which has been proposed but noone has implemented it yet.
15:56-!-supermop_ [] has joined #openttd
16:03-!-a1270 [] has quit [Ping timeout: 480 seconds]
16:09<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
16:14<Eddi|zuHause>i think V453000 got truely insane now. i mean stages beyond TrueInsanity, err, ...Brain...
16:15<V453000>you havent seen the _true_ stuff yet :P
16:15<Zuu>FS#4704 :-)
16:16-!-DayDreamer [~DayDreame@] has quit [Quit: Leaving.]
16:16<Eddi|zuHause>i think you should start out with the flintstone engine
16:16<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.
16:18*Zuu goes and enable the setting "airports never expire"
16:18-!-Rieksts [~Rieksts@] has joined #openttd
16:20<Rieksts>What compact slh is viable in busy tl4 ll-rr network
16:21<Eddi|zuHause>english, please.
16:22<@Alberth>(as in, you are the only person that knows what 'slh' and '5051' means)
16:22<Ammler>or you are in wrong channel
16:22<@planetmaker>slh is a side-line hub
16:22<@planetmaker>tl is train length
16:23<Ammler>(in #openttdcoop) :-)
16:23<@Alberth>definitely the wrong channel :)
16:23<Ammler>but what is 5051?
16:29<Eddi|zuHause>@base 10 16 5051
16:29<@DorpsGek>Eddi|zuHause: 13BB
16:30<@planetmaker>@base 10 36 5051
16:30<@DorpsGek>planetmaker: 3WB
16:30<@planetmaker>hm, neither
16:30-!-Rieksts [~Rieksts@] has quit [Quit: used jmIrc]
16:32-!-bryjen [~bryjen@] has quit [Quit: Leaving]
16:37-!-a1270 [] has joined #openttd
16:38-!-perk11 [] has joined #openttd
16:43-!-bryjen [~bryjen@] has joined #openttd
16:47-!-Alberth [] has left #openttd []
16:47-!-a1270 [] has quit [Ping timeout: 480 seconds]
16:57<andythenorth>sleepy time iggle piggle
16:57<andythenorth>good night
16:58-!-andythenorth [~Andy@] has left #openttd []
16:58-!-Sacro_ [] has joined #openttd
17:00-!-KritiK_ [] has joined #openttd
17:04-!-KritiK [] has quit [Read error: Connection reset by peer]
17:04-!-KritiK_ is now known as KritiK
17:05<Eddi|zuHause>hm, proposal: railtype property: "equivalent labels".
17:06<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
17:07-!-a1270 [] has joined #openttd
17:13-!-Sacro_ [] has quit [Ping timeout: 480 seconds]
17:30-!-HerzogDeXtEr [] has joined #openttd
17:37-!-HerzogDeXtEr1 [] has quit [Ping timeout: 480 seconds]
17:41<@Terkhen>good night
17:58-!-perk11 [] has quit [Quit: Miranda IM! Smaller, Faster, Easier.]
18:02-!-supermop_ [] has quit [Quit: supermop_]
18:11-!-JVassie [] has quit [Ping timeout: 480 seconds]
18:23-!-Sacro1 [] has joined #openttd
18:24-!-sla_ro|master [~slaco@] has quit [Quit: The Third Tiberium War -]
18:30-!-Pulec [] has quit []
18:30-!-Neon [] has quit [Ping timeout: 480 seconds]
18:32-!-Guest4209 is now known as AD
18:37-!-Kurimus [] has quit []
18:38-!-Juo [] has joined #openttd
18:47-!-TWerkhoven [] has quit [Quit: He who can look into the future, has a brighter future to look into]
18:53-!-Progman [] has quit [Remote host closed the connection]
18:56-!-bryjen [~bryjen@] has quit [Quit: Leaving]
19:02<Ammler> <-- no 1.1.1
19:07-!-bodis [] has quit [Remote host closed the connection]
19:07-!-KritiK [] has quit [Quit: Leaving]
19:07-!-supermop [] has left #openttd []
19:12-!-Vikthor [] has quit [Quit: Leaving.]
19:19-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
19:34<Eddi|zuHause>"Dunkel wars, der Mond schien helle"
19:34<Eddi|zuHause>"Schneebedeckt die grüne Flur"
19:34<Eddi|zuHause>"Als ein Auto blitzeschnelle"
19:34<Eddi|zuHause>"langsam um die Ecke fuhr"
19:45-!-KouDy [] has quit [Quit: Leaving.]
19:59<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.
20:08-!-Chillosophy [] has quit []
20:23<Eddi|zuHause>could enforce unloading before selling?
20:26<Zuu>good idea
20:26<Zuu>but an even better idea is to go to sleep. Good night ;-)
20:27<Eddi|zuHause>sleep is overrated
20:27-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
20:35-!-Zuu [] has quit [Ping timeout: 480 seconds]
20:52-!-lugo [] has quit [Remote host closed the connection]
21:07-!-Pikka [] has joined #openttd
21:09-!-DoubleYou [] has joined #openttd
21:14-!-Brianetta [] has quit [Quit: Tschüß]
21:25-!-DoubleYou [] has quit [Ping timeout: 480 seconds]
21:26-!-DoubleYou [] has joined #openttd
21:38-!-DoubleYou [] has quit [Ping timeout: 483 seconds]
21:39-!-DoubleYou [] has joined #openttd
23:34-!-glx [glx@2a01:e35:2f59:c7c0:80b8:3a5c:fa0:9466] has quit [Quit: bye]
23:52<Sevalecan>W \o/
---Logclosed Sun Jul 31 00:00:49 2011