IRC logs for #openttd on OFTC at 2011-07-21
⏴ go to previous day
00:16:23 <blanham> is there any documentation for openttd's save game format? google is failing me
00:17:26 <Eddi|zuHause> apart from the canonical documentation, the basic file format is RIFF, and the structure of the map is in docs/landscape.html
00:18:11 <Eddi|zuHause> the structure of each chunk is best determined from the saveload handlers
00:18:24 <Eddi|zuHause> in src/saveload/*
00:27:01 <blanham> i have a crazy idea that i am weighing the feasibility of
00:27:33 <blanham> namely, using the openttd renderer as the base of a rollercoaster tycoon clone
00:32:43 <Eddi|zuHause> i'd say you're crazy, but that never stopped anybody :p
00:33:59 <Eddi|zuHause> not sure what that has to do with the savegame format, though
00:34:50 <blanham> to see if i could take the terrain data from rct and use it in openttd
00:35:03 <blanham> as far as the height map and such
00:35:38 <Eddi|zuHause> the problem with that idea is that openttd has no "cliffs"
00:35:53 <Eddi|zuHause> and no ability to rotate the map
00:36:27 <blanham> oof, that is certainly a problem
00:36:32 <Eddi|zuHause> the latterr is probably easy to implement, but there are no graphics for that
00:37:15 <Eddi|zuHause> the former is probably also not too dificult to implement, but it's kinda bad when you have no way of seeing behind such a cliff
00:37:48 <blanham> yeah, but my rendering skills are probably not up to snuff
00:39:27 <Eddi|zuHause> main problem with rotating is buildings, expecially ones which span multiple tiles (industries, hotels, airports)
00:40:00 <Eddi|zuHause> you might not immediately need to care about that, if you're trying to be independent from the TTD-graphics
00:40:44 <Eddi|zuHause> most other graphics come in all necessary rotations
00:43:28 <Eddi|zuHause> i'm saying it's not impossible to do these things
00:43:51 <Eddi|zuHause> and in fact they are even fairly commonly requested
00:44:33 <Eddi|zuHause> no real technical limitations prevent them, mostly missing (original) graphics
02:26:02 *** rhaeder has joined #openttd
03:02:47 *** Kurimus has joined #openttd
04:56:23 *** Eddi|zuHause has joined #openttd
05:50:49 *** sla_ro|master has joined #openttd
06:17:47 *** TheMask96 has joined #openttd
06:33:35 *** Br33z4hSlut5 has joined #openttd
07:16:22 *** DayDreamer has joined #openttd
07:21:10 *** DayDreamer has left #openttd
07:49:04 *** Progman has joined #openttd
07:54:50 *** Alberth has joined #openttd
07:54:50 *** ChanServ sets mode: +o Alberth
08:03:03 *** |Jeroen| has joined #openttd
08:16:18 <dihedral> peter1138, it is here :-P
08:29:24 <peter1138> not enough sleep :S
08:44:14 *** sla_ro|master has joined #openttd
09:36:50 *** TinoDidriksen has joined #openttd
09:59:59 *** Vikthor has joined #openttd
10:41:48 *** DoubleYou has joined #openttd
10:54:58 *** Biolunar has joined #openttd
11:05:53 *** Chris_Booth has joined #openttd
11:18:08 *** HerzogDeXtEr has joined #openttd
11:36:28 *** DoubleYou has joined #openttd
12:25:56 *** andythenorth has joined #openttd
12:26:02 <andythenorth> openttd is fascist
12:26:07 <andythenorth> and I want my money back
12:26:42 <andythenorth> am I? I was wondering where I was
12:27:01 <andythenorth> now I know I'm here
12:28:42 <andythenorth> openttd really does remind me of microsoft you know
12:28:48 <andythenorth> and Rubidium is Bill Gates
12:29:33 <Eddi|zuHause> you mean "guy that doesn't program that much himself, but cashes in on all the money"?
12:30:11 <andythenorth> jake has drawn some nice boats
12:30:14 <andythenorth> long may that continue
12:30:21 <andythenorth> then I may stop sulking and start coding
12:33:26 *** fjb is now known as Guest3027
12:40:02 *** Hirundo has joined #openttd
12:41:11 *** ^Spike^ has joined #openttd
12:41:34 *** Terkhen has joined #openttd
12:41:34 *** ChanServ sets mode: +o Terkhen
12:42:00 *** XeryusTC has joined #openttd
12:42:05 *** V453000 has joined #openttd
12:42:40 *** TWerkhoven has joined #openttd
12:43:04 *** DJNekkid has joined #openttd
12:44:04 *** planetmaker has joined #openttd
12:44:05 *** ChanServ sets mode: +o planetmaker
12:53:41 <Belugas> good day dear sir Alberth :)
12:54:23 <V453000> hello mr. co-realism-hater
13:00:48 *** Adambean has joined #openttd
13:02:47 <V453000> reality is fine, unless some braindead people start up the word "realism" and connect the good reality with a game
13:04:17 *** Brianetta has joined #openttd
13:04:39 <planetmaker> reality is fine. fiction is fine - and is meant to be fun. Thus realism in fiction is always second to any 'fun' argument
13:05:39 <planetmaker> hm... if we ever get OSX binaries again, I guess I'll advocate to drop all ppc support ;-)
13:14:22 <Eddi|zuHause> planetmaker: so what about a repo for all CETS-related openttd patches?
13:15:08 <TWerkhoven> central european train set
13:15:28 *** DanMacK has joined #openttd
13:17:46 <planetmaker> Eddi|zuHause, question is: mercurial queues or a patched trunk?
13:18:25 <planetmaker> you sound like preferring a mq - type project, right?
13:18:42 <Eddi|zuHause> not sure, they seem like fairly small and isolated patches
13:19:28 <Eddi|zuHause> i'm still not very familiar with mq
13:19:41 <planetmaker> not difficult :-)
13:20:06 <Eddi|zuHause> there was something with versioned queues and unversioned queues
13:20:09 <planetmaker> hg qnew -m "Commit message" filename_first_patch
13:20:57 <planetmaker> well... you can create a hg repo inside the mq patches dir. That then can be used to gain a versioned mq
13:21:23 <planetmaker> the patches of a mq are stored in .hg/patches
13:21:40 <planetmaker> that's the dir you can then call hg init in to version it
13:22:12 <V453000> patches for a train set? :o
13:22:21 <planetmaker> yup, we need it :-P
13:22:22 <Eddi|zuHause> "hg qinit [...] This command is deprecated. [...] use "hg init --mq" instead.
13:22:42 <planetmaker> I didn't need to inialize a queue in a new repo for long
13:22:56 <planetmaker> I mostly just use the same, but constantly changing queue in my trunk repo
13:23:01 <Eddi|zuHause> "will create a separate nested repository for patches"
13:23:16 <Alberth> Eddi|zuHause: just start using the queue (hg qnew first.patch)
13:23:46 <planetmaker> and yes... qinit is deprecated in 1.5 it seems
13:24:43 <planetmaker> I'll need to check back with Ammler how exactly we solved the mq repos on the DevZone so that the openttd CF could pull from it
13:25:12 <Alberth> Eddi|zuHause: I never have VCS control for the patches in the queue, I found it too confusing
13:25:14 <Eddi|zuHause> planetmaker: the CF should always pull tip, or not?
13:25:17 <Ammler> the devzone is able to prepare a hg repo from mq for the CF
13:25:28 <planetmaker> Eddi|zuHause, yes... but it needs a full repo, not the patches :-)
13:25:50 <Alberth> planetmaker: in 'default' ?
13:25:58 <planetmaker> Alberth, yes, IIRC
13:26:18 <planetmaker> i.e. the CF needs simply a patched trunk repo
13:26:38 <Eddi|zuHause> planetmaker: so steps: 1) create repo on devzone, 2) fill it with trunk, 3) clone repo to local, 4) add patches, 5) push patches?
13:27:42 <planetmaker> that'd not store the patches, but the modified trunk... ^ Ammler ?
13:28:05 <planetmaker> iirc there was *some* way such that you only need to push patches
13:28:25 <Ammler> then push the mq to your devzone project
13:28:52 <Ammler> well, or use hg.openttd.org...
13:28:59 <Ammler> those just don't have tags and such
13:30:48 <Eddi|zuHause> Ammler: that leaves two questions: a) where do i get a devzone project from (and how to name it), and b) how do i push the queue repo?
13:31:00 <Belugas> Realism is fine for a game initially designed as such, lime flight simulator, racing cars and so on. Pushing a feature request, or begging for a feature to be corrected simply beuase it's not realistic sucks when the main subject of the game is not about realism, but about fictionnal fun
13:31:11 <Belugas> sorry, out of contect, lagging...
13:31:28 <Eddi|zuHause> Ammler: b) "hg push --mq"?
13:33:35 <planetmaker> Eddi|zuHause, from .hg/patches: just hg push
13:33:46 <planetmaker> maybe you way works also :-)
13:36:04 <Eddi|zuHause> so. what about a)?
13:36:24 <planetmaker> Yexo, me or Ammler :-)
13:36:48 <planetmaker> hm... well, you're already a project manager. You can also create it yourself
13:37:06 <planetmaker> existing project managers can create new projects
13:37:12 <Eddi|zuHause> i'm useless with such bureaucracy
13:38:19 <planetmaker> well, what should be its name?
13:38:34 <Eddi|zuHause> that was part of the question ;)
13:39:20 <planetmaker> then it's openttd-trainvars?
13:39:37 <planetmaker> not to mix up with openttd-train wars :-P
13:40:14 <Eddi|zuHause> because it's also for roadveh
13:40:25 <Eddi|zuHause> at least it should work
13:41:26 <planetmaker> close to wau wau close to miau ;-)
13:41:26 <xabann> Hi, do I need Transport Tycoon Deluxe to make use of OpenTTD?
13:41:35 <planetmaker> xabann, no, you don't
13:41:43 <planetmaker> on windows: just use the installer and follow defaults
13:41:55 <planetmaker> on linux: use your packet manager
13:42:22 <xabann> In the past I always installed first TTD before installing OpenTTD
13:42:31 <planetmaker> Unless, of course, you insist to install an OpenTTD aged 3 years or older
13:43:33 <Eddi|zuHause> xabann: you still can use the trg*.grf and sample.cat files from TTD
13:43:49 <Eddi|zuHause> xabann: but you don't have to
13:44:04 <xabann> Well, I don't own the CD anymore :)
13:45:08 <planetmaker> project repo will be the usual path (analoguous to CETS). Just push your patches, nothing more
13:45:49 <planetmaker> repo might need a few minutes before it is created server-side.
13:47:35 <Ammler> echo "openttd" > .devzone/mq/mainrepo
13:47:44 <Ammler> so the devzone can create the repo for CF
13:47:59 <xabann> hmm, the grafix are a bit different
13:49:11 <planetmaker> xabann, sure enough we may not just steal the original graphics; as such everything was drawn from scratch
13:49:53 <xabann> I have to find my CD then :))
13:52:35 <Ammler> [15:46] <Eddi|zuHause> [15:31:28] Ammler: b) "hg push --mq"? [15:46] <planetmaker> [15:33:35] Eddi|zuHause, from .hg/patches: just hg push <-- that's the same
13:53:10 <Eddi|zuHause> i think i got the theory now.
13:53:11 <Ammler> planetmaker: you seem to use quite depreciated mq workflow :-)
13:53:39 <planetmaker> Ammler, yes... I hardly need anything else than hg qnew / qpush / qpop / qfinish
13:54:40 <Ammler> best way to apply a git patch
13:54:41 <planetmaker> I write the patches myself usually - or I don't need to qimport them
13:55:13 <Ammler> or is patch able to apply binaries?
13:55:37 <planetmaker> but I can hg import it ;-)
13:57:24 <planetmaker> I hardly keep external patch queues for longer... thus I just apply the patches without mq support
14:15:07 *** douknoukem has joined #openttd
14:15:19 *** andythenorth has joined #openttd
14:15:37 <Ammler> please tell me if it is useable, then we could add it to our little guide
14:22:22 <planetmaker> holladrioh DanMacK and andythenorth
14:46:43 <V453000> weird ... question: What colour does a duck have? Brown-ish looks odd, yellow is not obvious that it is a ducky an white is like goose but with short neck ...
14:50:58 <V453000> hm lets say brown is the one
14:52:02 *** DayDreamer has joined #openttd
14:52:31 *** DayDreamer has left #openttd
14:54:08 <Eddi|zuHause> male ducks have a green head, female ducks are brownish-grey
14:56:06 <Belugas> daffy duck is black, with a white colar
14:57:04 <Eddi|zuHause> i've never ever seen a "real" duck that was yellow...
15:00:37 <Eddi|zuHause> Alberth: i've not really seen one of those either :)
15:01:26 <Eddi|zuHause> it's a "pol-ente" ;)
15:09:26 <Alberth> but it is not yellow ;)
15:21:49 *** supermop_ has joined #openttd
15:26:21 <Eddi|zuHause> hm... i can't edit the description of a ticket, only comments?
15:37:44 <alluke> whats invalid chunk size
15:38:01 <alluke> i get that when i try to load old cargodist game with new one
15:39:01 <Eddi|zuHause> alluke: it means the patch does not provide any savegame compatibility
15:39:15 <Eddi|zuHause> alluke: either stay with the old version, or start a new game
15:39:31 <alluke> and there arent any savegame converters available?
15:43:48 *** Progman has joined #openttd
15:45:20 <Eddi|zuHause> ah, i found where i can edit the description... it's very... hidden...
15:51:55 <CIA-2> OpenTTD: planetmaker * r22677 /trunk/src/toolbar_gui.cpp: -Doc: A few doxygen sprinkles in toolbar_gui.cpp
16:08:36 *** frosch123 has joined #openttd
16:13:36 <CIA-2> OpenTTD: planetmaker * r22678 /trunk/src/ (3 files in 2 dirs): -Doc: More doxygen sprinkles in MacOSX code and cocoa video driver
16:41:21 <Eddi|zuHause> so many standards. we should have one unified standard!
16:44:26 <__ln__> yes, as long as the unified one has the logo of the worker's party in it
16:48:17 <Alberth> obviously north korea will not accept a non-northern korean standard, so it would be KPS_9566
16:50:36 <Eddi|zuHause> there was no east-german code page...
16:50:57 <Eddi|zuHause> (that i know of)
16:51:08 *** andythenorth has joined #openttd
16:59:45 <fjb> Written east-german was not that different from german.
17:17:49 <CIA-2> OpenTTD: planetmaker * r22679 /trunk/src/newgrf_commons.cpp: -Change [FS#4692] (r22655): [NewGRF] Use a value of 0 to indicate the invalid waterclass in the nearby land info (0x60 ind. tiles, 0x62 houses, objects,...)
17:22:37 <frosch123> the keyboard is older than east germany
17:22:49 <Eddi|zuHause> fjb: maybe not the letters, but definitely the words :p
17:24:09 <Eddi|zuHause> there might have been things like an upper case ß, if things went slightly differently ;)
17:25:35 <frosch123> the german code page did not have an ß either, it only had a β
17:26:15 <frosch123> (wrt. the dos codepage)
17:39:20 <Eddi|zuHause> at the screen resolutions in use back then, there was not too much difference between both ;)
17:45:18 <Rubidium> just wanted to ask andy whether we should be more like apple
17:45:28 <CIA-2> OpenTTD: translators * r22680 /trunk/src/lang/ (croatian.txt dutch.txt finnish.txt greek.txt serbian.txt):
17:45:28 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:28 <CIA-2> OpenTTD: croatian - 1 changes by VoyagerOne
17:45:28 <CIA-2> OpenTTD: dutch - 1 changes by habell
17:45:28 <CIA-2> OpenTTD: finnish - 1 changes by jpx_
17:45:30 <CIA-2> OpenTTD: greek - 66 changes by kyrm
17:45:30 <CIA-2> OpenTTD: serbian - 1 changes by etran
17:51:01 *** andythenorth has joined #openttd
17:51:26 <__ln__> Rubidium: can you resist buying an apple now that they have announced the new Full-screen apps feature in Lion?
17:51:29 <Rubidium> andythenorth: we should be more like Apple?
17:51:42 <andythenorth> be more like microsoft
17:51:59 <Lakie> Only just annonced such a feature, __ln__?
17:52:03 <andythenorth> anyway openttd is clearly fascist
17:52:08 * Alberth will recommend re-install for every problem
17:52:33 <andythenorth> wrt the circular discussion from yesterday
17:52:34 <Eddi|zuHause> __ln__: what was wrong with the old feature?
17:52:38 <Rubidium> andythenorth: but we're like microsoft in many sense, e.g. obnoxious efforts to keep old stuff working
17:52:43 <Alberth> andythenorth: re-install will help
17:53:10 <andythenorth> anyway, grfs disabling themselves is - to borrow a quote - a misfeature
17:53:20 <andythenorth> why not just refuse to start the game if a grf disables
17:53:34 <andythenorth> there is no plausible reason why you'd want to start the game with a disabled grf
17:53:41 <andythenorth> it leaves n other problems, but solves some
17:53:42 <Rubidium> andythenorth: it's like applications not starting because the version of Windows is not right, instead of subtly not working right
17:53:43 <Alberth> because eg firs disables itself if i witch to toyland?
17:53:44 <Eddi|zuHause> Rubidium: that doesn't fully work out either. remember the two people that vehemently demanded that we re-introduce the old behaviour of turning around vehicles? :p
17:54:17 <andythenorth> Alberth: I'm not accepting that kind of argument
17:54:30 <Alberth> ie there are legitimate cases
17:54:33 <andythenorth> it's an unrelated edge case
17:54:43 <Alberth> and I don't know how to distinguish between them
17:54:58 <andythenorth> name any benefit of starting a new game (not a save game) with grfs disabled
17:55:15 <Lakie> I suppose you should spewcify the reasons for why it disabled, andythenorth.
17:55:16 <Alberth> no need to disable newgrfs
17:55:18 <Eddi|zuHause> andythenorth: reuse the same preset for different climates
17:55:31 <Lakie> People not bothered to change their newgrf settings
17:55:49 <andythenorth> Lakie: we can't specify the reasons - we have to assume that any reason the newgrf author chooses is valid :|
17:56:10 <frosch123> we should add support for downloading newgrf presets from banans
17:56:21 <Lakie> Well, cimate is pretty valid reasoning, similarly does not work with grf foo is valid?
17:56:29 <frosch123> and then in the next step disallow players to pick their own grf configuration
17:57:03 <Lakie> I can't imagine that going down well, with the community opr newgrf authors
17:57:10 <andythenorth> none of these are benefits to starting a new game with disabled grfs :P
17:57:33 <Lakie> As I said, laziness of not removing grfs which don't work in other climates
17:58:33 *** andythenorth has left #openttd
17:59:25 <Lakie> Ideally shouldn't OpenTTD not necessarily store the grfs which are disabled (when starting a new game) when saving?
18:00:31 <frosch123> action7 makes a difference of grfs being present or being disabled
18:00:53 <Rubidium> heh, just wanted to ask whether I remembered something like that correctly. Guess I did ;)
18:01:15 <Lakie> So why is a game with disbaled grfs a problem?
18:01:39 <Rubidium> it's an andy problem
18:02:44 <frosch123> i think he considers disabled grfs too complex for the average user
18:02:58 <Eddi|zuHause> andy wants a system where people can add and remove grfs, with detecting the dangerous side effects
18:03:26 <Lakie> Thats quite tricky, due to having to workout what'd change in the game..
18:03:39 <Rubidium> Eddi|zuHause: more like s/with detecting the dangerous/without/
18:04:04 <Eddi|zuHause> Rubidium: well, if dangerous side effects get detected, the change is refused
18:04:27 <Lakie> I doubt you could ever get an automated syste which would always get that right though
18:05:02 <Eddi|zuHause> and andy thinks with reducing the things grfs are allowed to do, this check gets easier
18:06:26 <Lakie> Well, it might make it easier, but doesn't it render them far less useful
18:07:05 <Eddi|zuHause> that's the smaller problem
18:07:19 <Eddi|zuHause> the bigger problem is that all existing grfs get invalid
18:07:40 <Lakie> Thats true, which would be pretty cataclisic in hate mail...
18:08:38 <planetmaker> They need not get invalid.
18:09:48 <planetmaker> But the enhanced 'allow to modify grfconfig' would then only be allowed when only newgrfs with 'limits'
18:10:37 <planetmaker> are active / about to become active
18:10:43 <Eddi|zuHause> Ammler: yes, the warnings are harmless
18:11:05 <Eddi|zuHause> or rather: due to the fact the set is heavily unfinished :p
18:13:53 *** andythenorth has joined #openttd
18:19:43 <Ammler> because of nml, i had to change errors to warnings ;-)
18:20:59 <Alberth> do you have an 'intelligent' build system or so?
18:21:51 <planetmaker> Alberth: if a 'this is deprecated' message terminates the build, it's not what is desired ;-)
18:22:51 <Alberth> yeah, a 'smart' system, that thinks it understands what it is doing.... NOT
18:23:41 <Ammler> planetmaker: it's not that message
18:23:45 <andythenorth> the "I changed climates and I'm too lazy to change newgrfs" case doesn't hold up as a benefit
18:23:51 <andythenorth> it's actually another problem
18:24:11 <andythenorth> grf x might be fine with grf y in tropic, but disable it in climate
18:24:15 <andythenorth> result: broken game
18:25:34 <Alberth> what are you trying to achieve with non-disabling of newgrfs?
18:25:55 <andythenorth> reduce the number reasons why players might want to change newgrfs in game
18:26:08 <andythenorth> changing newgrfs is stupid
18:26:13 <andythenorth> for obvious reasons
18:26:18 <Alberth> disabling is just another form of 'changing'
18:26:54 <Eddi|zuHause> andythenorth: all that needs is popping up the newgrf config on game start, if there were errors
18:27:34 <andythenorth> that's better than my suggestion of not allowing start
18:27:46 <Alberth> you may be able to take away one reason, but there are many many cases
18:28:05 <andythenorth> no silver bullet
18:28:07 <andythenorth> and other cliches
18:28:15 <Alberth> and many of them are user-related, so no hope of solving
18:28:22 <Eddi|zuHause> bonus points for actually selecting the erroneous grf
18:28:24 <andythenorth> is 'not being able to solve it all' a reason to not solve what can be solved?
18:29:50 <Alberth> first question to answer is do you actually want to rescue the current system?
18:30:01 <andythenorth> rescue it from what?
18:30:02 <Alberth> I can only see a very long and painful road
18:30:30 <andythenorth> all of these discussions seem to end in 'we need to ditch newgrf' which I find odd
18:31:03 <Alberth> that may be the case, yes
18:31:08 <andythenorth> this is why I'm baffled
18:31:22 <andythenorth> we can't change anything apparently because we have to maintain legacy support - even for stuff that's just wrong
18:31:36 <andythenorth> yet the proposed solution is often 'throw away all of newgrf'
18:32:00 <Alberth> different devs, different opinions :)
18:32:49 <andythenorth> I don't really care that much
18:32:58 <andythenorth> I play with newgrf developer tool on and change whatever I want
18:33:00 <Rubidium> so, what concrete changes to the handling of NewGRFs do you propose?
18:33:02 <Alberth> I'd be in favor of cutting of broken stuff of the newgrf spec, but can you identify that, or is it just as hopeless as trying to remove an advanced setting?
18:33:20 <andythenorth> 1. forbid grf disabling other grfs
18:33:35 <andythenorth> 2. don't start game with disabled newgrfs - show newgrf window
18:33:46 <andythenorth> 3. post information in useful places that DOS palette is best
18:33:57 <andythenorth> 4. strongly encourage action 14
18:33:57 <planetmaker> andythenorth: it's moderately simple:
18:34:18 <planetmaker> a) add a property which states that a newgrf cannot access other newgrfs at all
18:34:26 <planetmaker> b) enforce that property, if set by the newgrf
18:34:40 <planetmaker> c) if all active newgrfs have that property, set, allow also changes
18:34:52 <planetmaker> fallback to current behaviour if there's one which does not follow that
18:35:11 <planetmaker> of the active ones / to be active ones; not the complete lest
18:35:24 <andythenorth> planetmaker: you propose *allowing* to change newgrf in game?
18:35:24 <planetmaker> well. simple is the theory
18:35:24 <Rubidium> doesn't that get us back to the: why doesn't changing NewGRFs work for 99% of the cases for years because old NewGRFs stay around like cancers
18:35:36 <andythenorth> changing newgrf in game should be a done argument
18:35:40 <andythenorth> it shouldn't be allowed
18:35:53 <andythenorth> there's too much that can go wrong
18:35:53 <planetmaker> whatever. adding newgrfs then maybe
18:36:04 <Rubidium> andythenorth: you can do 3 and 4 yourself easily
18:36:05 <planetmaker> like adding vehicle sets to a map
18:36:19 <andythenorth> Rubidium: I like those 3 and 4 for that reason :P
18:36:29 <planetmaker> if all newgrfs cannot talk to eachother, adding new vehicles is safe
18:36:38 <andythenorth> that was the point of pools?
18:36:49 <Alberth> planetmaker: and ECS + FIRS together?
18:37:00 <andythenorth> cargo cluster fuck
18:37:13 <Alberth> it breaks 'do not talk' principle
18:37:28 <andythenorth> so continue to disallow adding
18:37:29 <Rubidium> I don't see what option 1 would achieve; okay, not disabling another... but you can still disable yourself based on another NewGRF
18:37:53 <andythenorth> disabling other grfs is just plain rude
18:38:00 <planetmaker> Alberth: they're not vehicles ;-)
18:38:32 <Alberth> planetmaker: so 'vehicle sets do not talk' :)
18:38:36 <planetmaker> industry newgrfs probably need to stay an exception
18:38:52 <planetmaker> but you can only allow that, if neither can listen
18:39:04 <planetmaker> or the industry newgrf could disable XY when it finds vehicle AB
18:39:05 * Rubidium ponders whether it's feasible to make a NewGRF that disables one part of competing sets of NewGRFs
18:39:38 <planetmaker> like one ECS vector is easily done
18:39:47 <planetmaker> or one of opengfx+ newgrfs or whatever
18:40:42 <Rubidium> about option #2; the game is technically already started if you want to be able to show that window. Next question is, when is it disabled? It could pretty well throw a warning and skip all sprites, and still be effectively disabled without knowing that
18:41:31 <planetmaker> Rubidium: that's why my a) was 'forbid all newgrfs to see and listen to eachother'
18:41:50 <planetmaker> only if that is obeyed completely we can allow adding vehicle newgrfs
18:42:19 <andythenorth> there's nothing can be done about the 'skip all sprites' case
18:42:31 <andythenorth> except berate any newgrf author who does such a thing
18:42:38 <Rubidium> planetmaker: that'd mean that there's no way to detect e.g. swedish rails, so it might get pretty messy w.r.t. introduction of track types. Or am I overlooking something?
18:42:40 <andythenorth> there's not enough berating of newgrf authors :P
18:42:56 <Rubidium> although... they should all just be using a single specification of rail types
18:43:11 <Rubidium> maybe that ought to be fixed as well
18:43:13 <planetmaker> Rubidium: that's true. But there's the anonymous check for railtypes. So that'll work
18:43:32 <planetmaker> one can check for labels being available
18:43:41 <andythenorth> nobody dares touch cargo classes because MB will be after them
18:43:48 <andythenorth> all it takes is one person...
18:44:02 * Rubidium sacrifices andythenorth for that job ;)
18:44:23 <andythenorth> if it wasn't for MB I would already have done my own alternative classes
18:44:32 <andythenorth> which would have beeen a Bad Idea
18:44:58 <andythenorth> someone being pernickety about spec is good
18:47:34 * andythenorth remembers HEQS used to disable all vehicles in toyland
18:47:39 <andythenorth> nothing ottd can do about that
18:47:57 <andythenorth> users asked me to change it.
18:48:06 <planetmaker> andythenorth: default vehicles is something else
18:48:29 <andythenorth> what - whether a set disables them?
18:50:21 <andythenorth> for reference - HEQS only used to disable it's own vehicles in toyland iirc
18:50:50 <andythenorth> although maybe it also disabled the default vehicles
18:51:05 <andythenorth> anyway, I fixed whatever it was that was requested
18:54:51 <planetmaker> the most problematic wrt newgrf configs really is only the cross-talk
18:55:29 <planetmaker> that makes adding additional vehicles (or say other landscape or tree or newobjects newgrfs) so dangerous.
18:56:40 <planetmaker> if you always do the same, independent of other newgrfs... that's unproblematic
18:57:40 <Terkhen> the system is too complicated? :P
18:59:59 <andythenorth> planetmaker: that's another % fix
19:00:13 <andythenorth> there are probably enough % fixes to make most of the issue go away
19:00:21 <andythenorth> without navel gazing whether newgrf is all wrong
19:00:39 <andythenorth> but still....adding some types and not others is complex
19:00:50 <andythenorth> and you have to be sure there's no action 0 for a cargo or such in a vehicle grf
19:01:33 <planetmaker> that can in principle be checked
19:03:18 <planetmaker> andythenorth: yes, it's a %fix, as you call it. But makeing all newgrfs incompatible with OpenTTD is not a good solution, I think
19:03:19 <andythenorth> it's probably quite a horrible graph of what can and can't be cross-talked though?
19:03:37 <andythenorth> it's valid for FIRS to disable in presence of station names grf for example
19:03:46 <andythenorth> yet station names would seem safe
19:03:46 <planetmaker> the other way is via the scenario path - just regenerate industries, houses and alike and re-initialize everything from point 0
19:03:52 <planetmaker> with a certain discrepancy
19:04:37 <planetmaker> andythenorth: the station name newgrf defines industries. So in principle it's easy to know that
19:04:56 <planetmaker> it "just" needs the players to recognize / know that
19:05:02 <planetmaker> andythenorth: yes. That's why it's incompatible
19:05:16 <planetmaker> you define in FIRS also station names. Via industry property you-know-what
19:05:29 <andythenorth> oh yes, that's an industry prop not a station prop
19:06:15 <andythenorth> seems to be a lot of work
19:06:23 * andythenorth wonders about a social factor
19:12:30 *** supermop_ has joined #openttd
19:16:59 <aditsu> hi, what are the major changes from 1.0.5 to 1.1.1? I found some changelogs in the wiki but they are really long; so far I mainly noticed depot naming, and the train length was divided by 2
19:17:49 <Ammler> well, openttd could just assume windows palette for nonaction14 grfs
19:18:11 <andythenorth> not using action 14 is lame for n reasons
19:18:39 *** Brianetta has joined #openttd
19:18:52 <andythenorth> solving the palette issue is a % problem
19:19:23 <andythenorth> savegame compatibility
19:19:31 <andythenorth> remember all those boring chats we used to have about grfid
19:19:40 <planetmaker> andythenorth: the palette issue is a real non-issue
19:20:02 <andythenorth> I think it's an issue
19:20:10 <andythenorth> using the windows palette is a worse choice
19:20:15 <andythenorth> I should have made one that said "This NewGRF is lame: it uses the Windows palette"
19:20:46 <Ammler> the only issue with palette is that we use bad names for it :-)
19:20:50 <planetmaker> aditsu: the changlogs are there for a reason... and the list of lines starting with 'feature' is not dozens of pages
19:21:04 <planetmaker> you have a changlog enclosed with your binary
19:21:29 <andythenorth> Ammler: I assumed that windows palette was best, due to windows being newer than DOS :)
19:21:53 <Ammler> yes, it should be called reduced and full
19:22:20 <planetmaker> well, it is like it is
19:22:46 <Ammler> planetmaker: we were able to get ride of "patches" in settings :-P
19:22:49 <planetmaker> grfcodec and nml could warn about the use of the windows palette
19:23:41 <planetmaker> what one could do for added fun add a 3rd improved really 256 colour palette ;-)
19:23:43 <Terkhen> it includes also all "minor" changes though
19:23:46 <planetmaker> 60 colours more than now ;-)
19:24:51 <planetmaker> well, let's assume we want to keep 8bpp and 32bpp
19:25:12 <planetmaker> and a 3rd palette ... bad choice to mention it here ;-)
19:25:15 <Ammler> performance is a valid reason
19:27:33 <aditsu> planetmaker: 109 lines
19:27:59 <planetmaker> features? I'm surprised
19:28:18 <planetmaker> my memory is too bad
19:28:39 <Ammler> aditsu: maybe the news article tells the main changes
19:32:58 * planetmaker remembers sloped stations ;-)
19:33:16 *** sla_ro|master has joined #openttd
19:36:00 <aditsu> I'm playing a new multiplayer game now, and it's running much slower than I'm used to
19:36:17 <aditsu> could that be a server setting?
19:36:49 <Rubidium> sounds like you're normally playing fast forward
19:37:01 <Rubidium> or the server is too slow to actually handle the game at the right speed
19:37:09 <planetmaker> or the server is running a heavily overloaded map
19:37:16 <aditsu> no, I'm talking about multiplayer games, at normal speed
19:37:37 <aditsu> the map is big but not huge
19:37:47 <planetmaker> and the vehicle count is 5000?
19:37:48 <Rubidium> multiplayer goes as fast as single player
19:38:01 <aditsu> there are quote a lot of trains though, let me see..
19:38:41 <aditsu> I estimate there are about 600 vehicles
19:38:46 <Rubidium> or actually, multiplayer goes as fast as the server could run it in single player excluding things like pausing
19:39:18 <aditsu> yes, but one big difference with multiplayer is that I can't fast forward
19:39:31 <planetmaker> of course you can't
19:39:48 <planetmaker> I'd not say thank you if you fast-forwarded the game I was playing, too ;-)
19:39:57 <planetmaker> thus it's simply not possible
19:40:12 <planetmaker> (mostly for technical reasons, though)
19:40:15 <Wolf01> planetmaker: I would like to continue it, but I have no time at the moment, and if I do, I don't have enough willpower :P
19:40:24 <aditsu> sure, I was just explaining that it's not about normal speed vs fast forward
19:41:58 * Rubidium wonders whether he has to repeat that the speed of multiplayer is that same as non-fast forwarded play of the exact same game in single player on the server
19:43:06 <Rubidium> unless the server is at its max capacity. Then running it as (dedicated) server is faster than running it as GUI single player, though there'd be no measurable difference between GUI multiplayer server and GUI single player or GUI multiplayer client
19:48:12 * aditsu wonders why everybody seems to think that I got something wrong and they need to explain it
19:49:01 <Rubidium> you were asking whether multiplayer is slower for some reason
19:49:34 <aditsu> I was asking why this particular game could be slower than other ones
19:49:54 <aditsu> actually, let me time it..
19:51:04 <planetmaker> aditsu: and you got exactly the possible answers to your question. Why do you complain now?
19:51:20 <aditsu> 10 days in about 38 sec
19:51:53 <DorpsGek> planetmaker: 0.0513513513514
19:52:28 <aditsu> planetmaker: well, I got the answer about 3 lines after the question, I'm just saying that the next 20 or so lines were unnecessary
19:52:30 <planetmaker> maybe it's an under-powered server. But we told you that already
19:53:01 <planetmaker> ... ok. as you wish
19:55:21 <aditsu> huh, actually, it's running quite a lot faster now, maybe the server was busy with something else
20:10:39 *** DayDreamer has joined #openttd
20:35:49 <__ln__> is 'h' pronounced in latin?
20:37:10 <planetmaker> that depends on whom you ask, I guess. But usually yes
20:39:55 <__ln__> umm, teaching pronunciation without sound.
20:41:28 <planetmaker> good night Terkhen
20:42:43 <planetmaker> comments say it's not the classical pronounciation shown there
20:43:23 <__ln__> i would only trust a youtube video by a native latin speaker
20:46:05 *** Chris_Booth has joined #openttd
20:46:52 <planetmaker> so you need some bishop who grew up in vatican ;-)
20:50:12 <Rubidium> rather someone who grew up in ancient Rome
20:50:51 <Rubidium> as pronounciation changes quite a lot in a few thousand years
20:51:46 <planetmaker> he didn't say 'classical latin' ;-)
20:52:12 <Rubidium> well, then any pronounciation is right ;)
20:52:27 <Rubidium> as I don't quite trust the pronounciation from the Vatican
20:52:45 <__ln__> so in classical latin 'h' is pronounced, but not in spanish, italian nor cockney.
20:52:52 <Rubidium> the mess they made of thanking the Dutch for the flowers is quite big
20:54:37 <planetmaker> __ln__: yes, that's what I seem to recall, too
20:56:11 <__ln__> what went wrong and when? :)
20:57:44 *** LordAro has joined #openttd
20:59:20 <planetmaker> in other parts of the carmina burana they might sing one or another latin dialect - whoever performs it
21:01:43 * __ln__ is reading grammar of italian atm
21:13:48 <__ln__> congratulations greece for your new 1.09*10^11 € loan
21:16:44 *** Prof_Frink has joined #openttd
21:26:40 *** Brianetta has joined #openttd
21:27:33 <__ln__> Berolinum, Monacum, Brunsvicum, ...
21:27:54 <planetmaker> Nunc est dormendum. Bona nox
21:28:34 <__ln__> nunca está dormiendo. buena noche?
21:29:06 <planetmaker> indeed. *dormiendum
21:33:37 *** SpComb^ has joined #openttd
21:34:25 <__ln__> pity i've never studied latin. would be useful on #openttd and in vatican.
21:35:06 *** SpComb^_ has joined #openttd
21:38:11 <__ln__> the finnish broadcasting company transmits news in latin once a week on radio.
21:38:40 <Prof_Frink> And was somewhat surprised when the characters from my Latin course turned up in Doctor Who.
21:53:06 *** SpComb^_ is now known as SpComb
22:15:28 *** Progman has joined #openttd
22:23:16 *** DoubleYou has joined #openttd
22:43:14 <ccfreak2k> What do you call people that speak Latin?
22:54:32 <lugo-> <frosch123> we should add support for downloading newgrf presets from banans << i think this would very much destroy most arguments for a voting/rating system for newgrfs
22:55:24 <lugo-> how is that not done yet ;)
23:02:46 <Ammler> the download counter should also go as it seems not working anyway
23:03:12 <Ammler> it looks like an "age counter"
23:18:45 <Eddi|zuHause> Ammler/planetmaker: i now pushed the mq repository with the 3 patches
23:21:50 <Eddi|zuHause> and of course i forgot setting the username :p
23:25:02 <Ammler> you need now to tag with svnrev you want the CF to build against
23:25:14 <Ammler> then enable release building
23:25:25 <Eddi|zuHause> how do i do that?
23:25:32 <Ammler> and enable testing so it does alert you if patch does not apply or build anymore
23:26:12 <Ammler> well, first the build settings
23:26:42 <Ammler> mkdir -p .devzone/mq && echo "openttd" > .devzone/mq/mainrepo
23:28:00 <Eddi|zuHause> svn rev is r22680
23:28:02 <Ammler> or let me show in a clone
23:28:13 <Eddi|zuHause> yes, please show me
23:48:37 <Ammler> the openttd CF needs to use the .mq repo
23:49:54 <Ammler> oh, btw. not sure if the findversion.sh bug is fixed in the meantime
23:50:15 <Ammler> does findversion still report the patch as version?
23:51:55 <Ammler> well, it should work anyway...
23:52:12 <Eddi|zuHause> the version string is totally weird
23:52:34 <Eddi|zuHause> says something like "OpenTTD qtip tip patch_nameM"
23:55:26 <Eddi|zuHause> so... do i understand that right testing/enable and and releases/enable are empty files, and mq/mainrepo contains "openttd"?
23:56:20 <Eddi|zuHause> "md -p .hg/patches/.devzone/mq"?
23:57:04 <Ammler> or just pull from my repo :-)
23:57:21 <Eddi|zuHause> better if i do that right once ;)
23:58:13 <Ammler> GT from 32bpp patch is a bit absent and I had some changes, need to check, if testing will still work, but the repo creating works
23:58:43 <Ammler> testing runs around the same time when nightly are created
23:59:28 <Ammler> testing simply applies the patches to default and tries to build openttd
23:59:41 <Ammler> if that fails, it triggers a ticket
continue to next day ⏵
