IRC logs for #openttd on OFTC at 2011-11-10
⏴ go to previous day
00:25:09 *** Tomazim has joined #openttd
00:27:11 <Tomazim> I am beyond pleased that there is still an OpenTTD community
00:34:17 <planetmaker> many parts of it are sleeping right now, though ;-)
00:37:25 <Tomazim> I am playing some single player hardmode now
00:38:38 <Tomazim> The beginning is slow
00:38:46 <Tomazim> i.e hard to make money with a 100k loan
00:38:50 <planetmaker> grant yourself more loan ;-)
00:39:44 <Tomazim> They like me enough for 300k now, so it's picking up
01:15:20 <z-MaTRiX> in original ttd it was lol to make profit from shares of companies, just needed to buy shares before the company requests loan, then when the company has money, just sell the share, and loan will not be shared <;
03:26:43 *** rhaeder1 has joined #openttd
04:21:14 *** Kurimus has joined #openttd
05:58:01 *** DorpsGek has joined #openttd
05:58:01 *** ChanServ sets mode: +o DorpsGek
06:03:32 <Rubidium> ctibor: because good service only increases the chance the production will increase, which means it may very well not increase or even decrease
06:15:15 <CIA-6> OpenTTD: rubidium * r23178 /trunk/src/ (5 files in 2 dirs): -Feature [FS#4780]: in-game readme.txt readmer (LordAro)
06:36:16 *** Celestar has joined #openttd
06:36:26 *** JVassie has joined #openttd
06:44:12 <planetmaker> moin Rubidium :-)
06:44:17 <planetmaker> and also all others
07:12:54 *** Cybertinus has joined #openttd
07:23:05 *** cowsgomoo has joined #openttd
07:24:21 *** andythenorth has joined #openttd
07:24:35 <andythenorth> Eddi|zuHause2: in the 'large' set scheme - containers?
07:25:33 <andythenorth> containers are interesting case - IRL they carry near everything, including bulk. In most sets they are piece / express
07:35:27 *** DayDreamer has joined #openttd
07:35:50 * planetmaker has found another interesting thing and points at trunk head. HEQS is lacking there ;-) As is FISH and FIRS and ... every NeWGRF ;-)
07:40:37 *** HerzogDeXtEr has joined #openttd
07:40:47 <andythenorth> planetmaker: all I get is 504 :P
07:41:09 <andythenorth> we've chosen to delete the repo and end the project? :o
07:42:07 <andythenorth> but yes, hg shows me tip, now I have to write text files :D
07:47:02 *** sla_ro|master has joined #openttd
07:53:44 *** Progman has joined #openttd
07:54:18 <planetmaker> yes, we've got to write readme files now in a ledgible format
07:54:27 <planetmaker> Though, andythenorth, you're doing better than Pikka ;-)
07:54:34 <planetmaker> He supplies no readme whatsoever :-P
07:54:46 <andythenorth> is the new feature announced in forums?
07:54:51 <planetmaker> nor do Georges' newgrfs supply readmes
07:54:57 <andythenorth> I think I asked for it in my ponies thread
07:55:16 <planetmaker> I thought of making a short announcement
07:55:51 *** Celestar has joined #openttd
07:56:07 <planetmaker> TrueBrain, 504 on vcs.openttd.org
07:56:19 <andythenorth> I had 'bananas changelog field' as a pony
07:57:13 <andythenorth> frosch got ahead of my idea about mapping equivalent cargo labels :(
07:57:31 <andythenorth> and it's likely that his is a good idea and mine was silly :P
08:00:18 <planetmaker> I haven't yet quite understood what he wrote. My tea water is just boiling...
08:06:18 <andythenorth> I haven't understood all of it either
08:06:34 <andythenorth> my idea was that cargos could map equivalence
08:07:36 <planetmaker> equivalent cargos sounds like identical cargos which should have the same label ;-)
08:07:39 <andythenorth> so if your cargo set introduces bauxite, you could say "copper ore is a known cargo, bauxite should be treated 1:1 like copper ore"
08:08:25 <andythenorth> I think frosch is doing something slightly different
08:10:03 <andythenorth> planetmaker: so some of my grfs already have readme.txt....
08:10:49 <Terkhen> nice, readmes can be read :)
08:12:01 <andythenorth> I think I understand frosch's proposal
08:12:59 <andythenorth> HEQS readme isn't seen :P
08:13:52 <andythenorth> they're not from bananas
08:14:38 <andythenorth> now to make them readable *before* you download :)
08:14:40 <planetmaker> andythenorth, all of your NewGRF have one
08:14:47 <andythenorth> maybe read-before-download is not needed
08:14:51 <planetmaker> but not all are very informative ;-)
08:15:19 <planetmaker> And good point. I have to adjust the 'make install' so that it tars the stuff
08:15:28 <planetmaker> such that the readme viewer works without hassle
08:15:49 <andythenorth> should I stop maintaining separate changelog? I would like the change information in the readme
08:16:58 <planetmaker> Yes, I thought about that, too. Especially with the ingame readme viewer
08:17:08 <planetmaker> except if we add a changelog viewer :-P
08:17:25 <planetmaker> which now would be very simple to add
08:17:45 <planetmaker> good idea? bad idea?
08:17:58 <Terkhen> IMO displaying a single file is enough
08:18:14 <planetmaker> then I have to merge all changelog.txt into the readme :-P
08:18:18 <andythenorth> planetmaker: indifferent idea :)
08:18:39 <andythenorth> changelog should show up before downloading - on a button called "what's new" :P
08:18:41 <planetmaker> would be just another button...
08:19:16 <Terkhen> that's my main problem with showing different text files: it needs buttons :)
08:19:19 <Terkhen> besides that I don't care
08:19:34 <andythenorth> when you know the set, the stuff you want most is "what new stuff do I get?"
08:19:48 <planetmaker> and the other way around
08:19:51 <andythenorth> but if it's new you want "what does it do"
08:19:58 <planetmaker> if you don't know it, the "what's new" doesn't give a picture
08:20:14 <andythenorth> *short* changelog copied in - latest features / fixes only?
08:20:28 <planetmaker> possibly. for now
08:20:43 <planetmaker> That's probably what I'll employ. The last or last two changelogs
08:21:37 <andythenorth> I now have an insane amount of newgrf work to do :)
08:22:39 <Terkhen> 1) Short description of the newgrf
08:25:19 *** Celestar has joined #openttd
08:26:30 <planetmaker> sounds complicated, Terkhen
08:26:47 <planetmaker> especially as bananas supports a changelog.txt
08:26:52 <Terkhen> it works on the principle of tl;dr :P
08:27:11 <Terkhen> too long; didn't read
08:28:02 <planetmaker> I mean... OpenGFX' changelog has 458 lines at the moment
08:28:08 <planetmaker> which is too long to read :-P
08:28:24 <planetmaker> (attention span of 20 lines or so :-P )
08:28:46 <andythenorth> tl;dr is pretty good
08:28:57 <Terkhen> 4) should go in a different file then
08:29:39 <planetmaker> yes, that's all I wanted to say: keep 4) in the file as now. But make sure 2) is there
08:29:47 <planetmaker> I guess we all agree but didn't notice :-P
08:29:52 <andythenorth> one more c+p before release :P
08:30:08 <planetmaker> shall I script that, andythenorth ? ;-)
08:30:29 <planetmaker> like {{new_changelog}}
08:30:34 <andythenorth> you might go mad on edge cases
08:30:47 <andythenorth> unless we fragment the changelog
08:30:59 <planetmaker> of course. I'll require a certain changelog format then. In the way I use it all the time ;-)
08:31:27 <andythenorth> if you do it I'll try it
08:31:30 <planetmaker> ^^ pretty unique and identifiable
08:31:40 <andythenorth> if I break it, I won't ask for support :P
08:31:55 <andythenorth> c+p is not too painful, releases are not frequent
08:31:56 <planetmaker> but it's not too high on my agenda right now, tbh. But I'll make a note
08:32:40 <andythenorth> so much to do :o
08:32:58 <andythenorth> if someone fixed newgrf vehicle smoke, I think my head might actually explode
08:34:09 <planetmaker> I'm afraid we can't allow that, andythenorth.
08:34:17 <planetmaker> a) who'll clean up all the debris?
08:34:24 <planetmaker> b) your head is better used where it is now
08:34:33 <planetmaker> --> no new smoke now :-P
08:34:56 <andythenorth> it's such a dumb situation, the patch was added, but is not usable for ships :)
08:35:10 <andythenorth> it's extra painful to see that it's in the spec now :P
08:36:25 <andythenorth> also....I'm thinking that Eddi|zuHause2 might have an unarguable point about two props for refittable labels
08:36:39 <andythenorth> I think an exclude prop is wrong, but maybe the way it has to be done
08:40:07 <andythenorth> lacks elegance :(
08:41:39 *** Brianetta has joined #openttd
08:41:51 <dihedral> vcs.openttd.org seems to be down <- TrueBrain, Rubidium ;-)
08:41:58 <dihedral> or whoever takes care
08:42:14 *** |Jeroen| has joined #openttd
08:42:14 <dihedral> good morning Terkhen
08:42:38 <planetmaker> use hg.openttd.org
08:44:02 <dihedral> was interested in looking at the ingame readme viewer :-)
08:44:05 *** HerzogDeXtEr1 has joined #openttd
08:46:15 <Celestar> how the hell do I git add all the changed files without using some damn awk magic?
08:47:13 <dihedral> does it now work on a folder?
08:49:23 <Celestar> git add -u seems to do the trick
08:54:35 <Celestar> I'm still amazed how fast the goddamn code is.
08:56:55 <Celestar> on my comp, the tile loop takes 87 nanoseconds per tile.
09:00:57 <Celestar> michi_cc: if the "tile stack" at one place has independent tile loop procs, couldn't we put them into seperate threads?
09:01:56 <planetmaker> would it remain deterministically?
09:02:06 <Celestar> that's what I'm wondering.
09:02:13 <planetmaker> Think of industry, airport, object or house tiles querying the adjacent tiles
09:02:19 <Celestar> planetmaker: yeah, adjacent.
09:02:32 <Celestar> planetmaker: I'm think of threading it purely in the "Z" direction
09:04:06 *** Eddi|zuHause2 is now known as Eddi|zuHause
09:04:54 * dihedral is wondering if the readme viewer could be used to display a 'rules' text from a server one would like to join :-P
09:05:04 <dihedral> or if that would not be total overkill
09:05:28 <planetmaker> that's not a readme viewer :-P
09:05:42 <planetmaker> Do you agree to the TOS [ ] yes [ ] no
09:06:58 <planetmaker> *<font size = 3>You agree to pay a fine of 50€ for the first kick and a administration fee of 500€ should you violate the rules and this violation result in a ban.</font>Please fill in credit card details here: ....
09:14:06 <Celestar> planetmaker: the main question is, what happens if a tile is deleted during the Loop processing?
09:17:35 <planetmaker> I'm not entirely familiar with the involved loops: The tile loop only visits certain tiles per tick, right, like every 1/256 tiles?
09:17:50 <planetmaker> i.e. every tick some tiles?
09:18:05 <Celestar> planetmaker: every tick 1/256th of the map.
09:18:39 <planetmaker> Then we have to make sure that those tiles cannot access eachother
09:18:43 <planetmaker> which is... difficult
09:18:59 <Celestar> I still can't follow :P
09:18:59 <planetmaker> as e.g. deleting a house can change population of a town which again can be read by tiles MUCH more distant
09:19:21 <Celestar> planetmaker: with newmap, there are multiple tiles at a single location.
09:19:43 <Celestar> planetmaker: if this location is visited during the tile loop, each of the "subtiles" has its tile loop run.
09:19:48 <planetmaker> got me confused :-)
09:19:56 <planetmaker> not x/y processing parallel. only z
09:20:03 <Celestar> planetmaker: those tile loops are (possibly) independent from one another.
09:20:09 <planetmaker> depends on whether they can access the previous state or not
09:20:23 <planetmaker> if they can: difficult
09:20:29 <planetmaker> or rather: the killer
09:20:41 <Celestar> the previous state? you mean the state of the "lower/upper" tiles?
09:20:57 <Celestar> from all I have seen: no.
09:21:21 <planetmaker> it could be threaded then, possibly, if the answer is "no and never will" ;-)
09:21:36 <Celestar> the main concern I have is what happens if the tile loop removes a tile from the stack.
09:21:56 <Celestar> is the vector we store the stuff in thread-safe? :P
09:22:17 <dihedral> why would the tile loop remove a tile??
09:22:31 <planetmaker> dihedral, removing the subway
09:22:34 <Celestar> dihedral: removal of the last tree on a tile.
09:22:48 <Celestar> dihedral: then MP_CLEAR + MP_TREE would become MP_CLEAR
09:22:50 <planetmaker> how would that remove the tile, Celestar ?
09:23:09 <Celestar> planetmaker: it would remove the "tree" part.
09:23:26 <planetmaker> hm, I see. I wasn't aware of that kind of "level"
09:24:01 <Celestar> planetmaker: well according to michi_cc, it's experimental anyway.
09:24:30 <dihedral> lets have it committed to trunk then :-P
09:24:43 <planetmaker> and call it openttdpatch
09:25:41 <Celestar> anyway. The removal of the last tree is the only thing that can remove a tile during the tile loop.
09:26:12 <dihedral> what if the tile only contains a building?
09:27:22 <Celestar> the removal would need to be thread safe. and I'm not sure it can be.
09:27:32 <Eddi|zuHause> how about: memcopy the entire map at start of tile loop, lock that copy and use it for all further read accesses. fire up the whole tileloop as one thread per tile, and write changes to the original map. after joining all threads, remove the copy, and redirect read access back to the original map
09:27:57 <Celestar> Eddi|zuHause: the read access isn't the problem.
09:28:10 <Celestar> you have, at one place, a MP_CLEAR and an MP_TREE.
09:28:23 <Celestar> MP_CLEAR has a .. bit that sais that another tile follows.
09:28:30 <TrueBrain> planetmaker: fixed; tracd decided to segfault over and over and over and over again :) He likes segfaulting :)
09:28:35 <Celestar> if MP_TREE is removed, MP_CLEAR needs to be changed.
09:29:14 <Eddi|zuHause> Celestar: yes, but if you have a locked copy of the original map, every other tile doesn't care if these two tiles change.
09:29:38 <Celestar> Eddi|zuHause: the question is: how long does a memcpy of the entire map take?
09:30:02 <Celestar> if this is more than a maybe two-digit figure of microseconds, it will not help.
09:30:03 <Eddi|zuHause> Celestar: all tiles other than the one processed currently have the state from _before_ the tile loop was run
09:30:39 *** TWerkhoven has joined #openttd
09:31:02 <Eddi|zuHause> i have no clue about nanoseconds
09:31:44 <Celestar> <Sheldon>a nanosecond is 1e-9 of a second </Sheldon>
09:32:26 <planetmaker> Celestar, call it MP_VOID then
09:32:36 <planetmaker> and leave it in place
09:33:16 <Celestar> and then have a cleanup loop run less often that does GC?
09:34:26 <planetmaker> it might also just be re-populated
09:34:39 <planetmaker> so the "surface" layer might not need deletion at all
09:34:51 <planetmaker> it's not like we are short on memory really
09:38:06 <Celestar> first question is ... how much does it gain :P
09:39:05 <Eddi|zuHause> that's something that cannot possibly be answered from an abstract point of view :p
09:39:48 <Celestar> hence I'm coding it :P
09:40:29 <Eddi|zuHause> the same approach might be taken by pathfinding, but i think that needs some further refactoring first
09:40:57 <planetmaker> the copying the whole map is expensive.
09:42:42 <Eddi|zuHause> but you can't copy only parts of the map, because the tile loop really touches all of the map at once
09:46:52 <planetmaker> well 1/256 at once
09:47:09 <Eddi|zuHause> yes. spread like cancer throughout the whole map
09:47:30 <planetmaker> yes. Actually there was recently a patch which made that a) random and b) faster
09:47:43 <planetmaker> random as in not regular
09:47:49 <planetmaker> not really random
10:11:13 *** blotek___ has joined #openttd
10:16:41 <Celestar> hacking threads into this is ... hacky :P
10:21:21 <Eddi|zuHause> which is why nobody has done it yet :p
10:28:32 <Eddi|zuHause> "Equivalent cargo labels" <-- now where do i remember that from? :p
10:46:48 *** DayDreamer has joined #openttd
10:50:50 *** andythenorth has joined #openttd
10:52:19 <peter1138> i'm so hacky, hacky hacky hacky...
10:52:58 <Eddi|zuHause> you are so old, old old old...
10:59:59 * andythenorth seems to have high boredom threshold :P
11:03:28 <andythenorth> I find myself agreeing almost 100% with MB
11:04:08 <Terkhen> so... this week long discussion is nearing a conclusion? :P
11:04:33 <andythenorth> it needs at least one decision to be made
11:04:44 <andythenorth> wrt explicit exclusion prop for labels
11:05:07 <andythenorth> but if we only did what I want, it would be a poor world :P
11:05:38 <andythenorth> my opinion on that prop has developed as far as 'meh' and 'shrug'
11:05:58 <andythenorth> as long as the XOR goes away and we get a list of included props as indices to CTT, I'm ecstatic
11:06:30 *** KenjiE20 has joined #openttd
11:08:12 *** KenjiE20 has joined #openttd
11:11:54 <peter1138> i still don't get Eddi|zuHause's objects
11:12:30 <Yexo> wasn't it just about the amount of work?
11:13:07 <peter1138> i still don't get Eddi|zuHause's objection
11:13:20 <andythenorth> he wants to be able to use classes
11:13:23 <Yexo> your set contains 300 engines. You learn of a new cargo type ABCD and want to add graphics support for that in one wagon.
11:13:33 <andythenorth> explicitly excluding things in the CTT makes work
11:13:36 <andythenorth> he might be right
11:13:43 <andythenorth> it's not elegant though :P
11:13:49 <Yexo> Now you have to add it to the CTT, which in turns means that for every wagon you either add it explicitely to the "include list" or don't include it
11:14:09 <andythenorth> he should create an internal define in his set, which composes a set of n labels
11:14:23 <andythenorth> 'groups' which are private to his set
11:14:42 <andythenorth> does the world end if the same index appears twice in the list for hte refit prop
11:15:24 <peter1138> you'll need computers able to store 2 in a single bit ;)
11:15:48 * andythenorth doesn't want ottd to cause end of world
11:16:00 <TrueBrain> 2012 takes care of that, no worries
11:16:14 <andythenorth> I hate the exclude property, but if it gets this issue moved to a conclusion, there would be happy people
11:16:37 <jonty-comp> professor bigglesworth!
11:16:45 <peter1138> doing the exclude property is actually a bit easier to cod e;)
11:17:30 <peter1138> does Eddi|zuHause use raw nfo, preprocesser nfo, or nml?
11:17:40 <peter1138> andythenorth, i don't want it though ;p
11:17:45 <andythenorth> I'll define private groups in my sets for excludes :P
11:17:47 <Eddi|zuHause> worse. a google spreadsheet
11:17:49 <andythenorth> find a way to make it optional
11:17:54 <Eddi|zuHause> and a python script
11:18:04 <Eddi|zuHause> that is then generating preprocessed nml
11:18:13 <peter1138> shouldn't be much hassle then :p
11:36:51 <Celestar> stupid friggen threading :P
11:39:01 <Celestar> maybe I should first not use our implementation
11:39:52 <Celestar> but try it with pthread directly
11:45:30 <Eddi|zuHause> peter1138: the point is that adding graphics to one wagon needs changes in totally unrelated places
11:49:40 <andythenorth> Eddi|zuHause: but you've changed the context of your set
11:49:53 <andythenorth> your set has known and unknown cargos, and by adding one, you change that
11:50:03 <andythenorth> so now you need to tell your set what to do with that
11:50:25 <Eddi|zuHause> andythenorth: it's still bad from a coding point of view
11:50:32 <andythenorth> writing code isn't bad
11:50:38 <andythenorth> letting possible errors pass silently is bad
11:51:04 <andythenorth> it's bad that when you add a parameter to a function, you might have to update every single place that's called
11:51:17 <andythenorth> why not just auto-magic that?
11:51:23 <andythenorth> but it's not how it's done
11:51:43 <Eddi|zuHause> i can add optional parameters to a function, and only use it in places that actually need it
11:52:17 <andythenorth> I tried to figure out a way to make this optional
11:52:43 <Yexo> andythenorth: making it optional is easy. Just go back to the two properties, one include list and one exclude list
11:52:57 <Eddi|zuHause> that's exactly what i said
11:53:02 <andythenorth> which is why I think Eddi|zuHause might be right
11:53:09 <andythenorth> see above somewhere ;)
11:53:35 <Yexo> one advantage of the single property is that as soon as everybody starts using it changing cargoclasses for known cargoes doesn't break those vehicle sets
11:54:09 <andythenorth> Yexo: it doesn't 'break' them in either case
11:54:10 <Eddi|zuHause> which we can't do anyway, because of backwards compatibility
11:54:15 <andythenorth> but in one case the spec is a huge mess
11:54:23 <andythenorth> and in the other it's explicit
11:54:29 <Yexo> Eddi|zuHause: that's theory, you can't influence everyone not to do it
11:54:41 <Yexo> ie even george changed cargoclasses of some cargos in ECS not too long ago
11:54:56 <andythenorth> MB made class change requests
11:54:58 <andythenorth> no-one is immune
11:55:25 <andythenorth> with the exclusion property, here is my problem
11:55:29 <andythenorth> I have cargo 'foo'
11:55:35 <Eddi|zuHause> but changing newgrf cargos is less problematic than changing original cargos
11:55:42 <andythenorth> it's not in my include or exclude list. Does my vehicle carry 'foo' ?
11:55:45 * Celestar is attempting to understand Foundations :P
11:55:51 <Yexo> andythenorth: depends on cargoclasses
11:55:55 <andythenorth> I have no fricking idea if my vehicle carries 'foo', but it's in my CTT
11:56:00 <Yexo> you can't plan for that, since you didn't know about foo when you created your set
11:56:10 <andythenorth> but it's in my CTT - so I know about it
11:56:29 <Yexo> than you should hav added it to either the include or exlucde list if you wanted to be sure
11:56:34 <Elukka> that is a pretty amazing station
11:56:39 <andythenorth> but that's not what Eddi|zuHause wants to do
11:56:51 <Eddi|zuHause> andythenorth: imagine a container wagon. why should it know whether it carries "foo", when the open wagon displays special graphics for "foo"?
11:56:56 <Yexo> it all boils down to: will cargoclasses get changed again, and do we care if that means some vehicles temporary transport some "wrong" cargoes
11:56:56 <andythenorth> Eddi|zuHause wants to be sure on the basis of classes - unless I misrepresent him
11:57:29 <andythenorth> Eddi|zuHause: it shouldn't know. But vehicle set authors think it should :P
11:58:22 <Yexo> andythenorth: that was not the point. If you want to make sure whether your vehicle can refit foo you can do that either way (just include list or both include and exclude list). With just an include list you're forced to let the vehicle know whether it can refit foo
11:58:40 <Celestar> do we have some link to decoded foundation sprites?
11:58:43 <andythenorth> the single prop is the 'correct' route imho
11:58:56 <andythenorth> but it doesn't meet the needs of vehicle set authors who want to avoid writing code
11:59:02 <Yexo> <Elukka> that is a pretty amazing station <- Celestar somewhere in that repo :p
11:59:06 <Eddi|zuHause> Celestar: in the opengfx repo?
12:00:11 <andythenorth> Yexo: exclude property: +1 or -1 ?
12:00:23 <planetmaker> Celestar, OpenGFX has them decoded
12:00:30 <Celestar> that's a shitload of parameters you need to store the (slope+foundation) in a tile.
12:00:30 <Yexo> no big opinion either way
12:02:11 <andythenorth> I guess it gets decided by whoever turns up with working code
12:02:20 <Elukka> are those passenger coaches refit for cargo in the upper left O_o
12:07:11 <Eddi|zuHause> never seen those before
12:07:33 <Eddi|zuHause> but could be repainted old mail/baggage cars
12:09:51 <Elukka> something like that probably
12:10:03 <Elukka> i've never even seen the models before
12:10:41 <Elukka> and that talgo trainset there is weird as hell, but that's talgo for you
12:16:03 *** Biolunar has joined #openttd
12:36:18 <Celestar> aren't those ICE cars a short?
12:36:32 <Celestar> they don't look like 25m to me
12:37:23 <planetmaker> indeed, they look short compared to the heads
12:46:36 <arie-> I've got a possible bug, but if I remember correctly this one has been mentioned before:
12:47:13 <arie-> strange track reservations: there's a possible path for a train but it just won't take it
12:47:25 <arie-> possibly happened during track reconstructions
12:47:43 <arie-> I think I've seen the issue before on the forums but cannot find it
12:48:59 <arie-> I'll add a post to that one with a save game
12:50:21 <Celestar> now this is a "user interface"
12:52:23 <andythenorth> needs a bigger GUI :P
12:52:33 <Celestar> storing all 4 corners of a tile is not sufficient to define the configuration of the tile.
12:52:44 <andythenorth> it should be made in squirrel so anyone can remake it as they see fit
12:53:00 <Celestar> peter1138: for example, half-tile-slopes.
12:53:01 <arie-> Ok, got two autosaves, two minutes apart.
12:53:17 <Celestar> peter1138: those even give a headache what to store in two of the corners.
12:53:28 <Celestar> because it's undefined.
12:53:34 <peter1138> slope with rail on top :S
12:54:38 <peter1138> are you storing it as a slope value, i.e. in 5 bits?
12:54:48 <Celestar> or just store the north corner and define the "half tile slope" as separate Slope value
12:54:56 <Celestar> peter1138: yeah, but currently I'm using 8 bits for simplicity.
12:55:00 <peter1138> that's where i'm going
12:55:10 <Celestar> "great minds think alike" ? :P
12:55:25 <peter1138> can you have half-tile stuff on steep slopes though?
12:55:41 <Celestar> even two half-tiles :P
12:55:54 <Celestar> but theoretically, with cliffs ....
12:56:09 <Celestar> there is no clear definition how many levels those two half-tiles are apart, is there?
12:56:41 <peter1138> ooh, a graphical bug :D
12:56:57 <Celestar> I'm not sure it's only graphical tbh :P
12:57:12 <peter1138> no, i mean in trunk :)
12:59:14 <peter1138> i suspect it doesn't matter though ;)
13:01:41 <peter1138> it's the lower foundation creeping through
13:02:09 <peter1138> possibly the wrong sprite selected :)
13:02:27 <peter1138> i don't remember everything about all the foundation sprites though :)
13:03:07 <Celestar> logically, the tile consists of 4 parts.
13:03:37 <Celestar> 4 triangles, with two corners in adjacent corners of the tile, and the third corner in the centre of the tile
13:08:10 <Celestar> with those 4, it would be easy.
13:08:18 <Celestar> ... theoretically :P
13:12:05 <Celestar> halftiles are a pita
13:34:55 * Celestar has to rethink terraforming completely
13:42:06 <Celestar> if you wanna be able to terraform cliffs/foundations, the GUI needs some changing :P
13:44:49 *** andythenorth is now known as Guest16582
13:44:50 *** andythenorth has joined #openttd
13:55:35 <Celestar> $ ls -alh bin/openttd
13:55:35 <Celestar> -rwxrwxr-x 1 vici vici 65M 2011-11-10 14:55 bin/openttd
13:56:20 *** Bluelight has joined #openttd
14:01:31 <peter1138> -rwxr-xr-x 1 petern petern 41M Nov 10 11:48 bin/openttd
14:01:38 <peter1138> big but not that big
14:10:06 *** TWerkhoven has joined #openttd
14:10:19 *** Tintinfan has joined #openttd
14:13:11 <Noldo> you are not going to like where that leads
14:15:40 <Celestar> peter1138: but the Z drawing order is fucked.
14:16:26 <Celestar> plus the engines can jump over cliffs :D
14:19:15 <Celestar> plus .. er I lack a user interface :P I just manually modded the map array :D
14:19:53 <Celestar> peter1138: the wagons should be partially hidden
14:20:03 <peter1138> that was never a problem :)
14:20:19 <peter1138> yeah, vehicles are always drawn after the landscape. hmm.
14:20:40 <Celestar> how is it done with trees?
14:21:05 <Celestar> because trees can hide vehicles
14:21:09 <peter1138> landscape then all objects
14:21:24 <Celestar> so for cliffs to be any useful, that has to be changed .....
14:21:59 * Belugas cleans his glasses and stares again at Celestar's cliffs, speahless
14:21:59 <peter1138> AddSortableSpriteToDraw()
14:22:26 <peter1138> i suspect that adding landscape to the sortable list would be another performance hit :(
14:23:09 <Celestar> Belugas: don't get too excited, i still have no UI to make them :P
14:23:31 <andythenorth> just make bridges with filled in sides?
14:23:46 <Celestar> bridges .. don't exist
14:24:03 <Celestar> peter1138: the question is .. how much of a performance hit ...
14:24:18 <andythenorth> draw tunnel sprites if another route passes under your 'cliffs' bridge
14:24:36 * Celestar pokes andythenorth with a rusty pole :P
14:24:54 * andythenorth is a big fan of doing things wrong
14:25:00 <andythenorth> except cargo refits
14:25:08 <Belugas> Celestar, who cares, it's the possiblity that such a feature can be done, no matter how it will be done in a gui (which , in fact, will never win approval of all players...)
14:25:19 <Celestar> peter1138: doesn't GTTS return whether a vehicle can actually enter a tile?
14:25:40 <peter1138> Celestar, allegedly
14:25:44 <Celestar> Belugas: but this can be yet another option to disable.
14:25:49 <peter1138> Celestar, you'll want to add a z parameter to it
14:25:53 <Celestar> peter1138: next problem. This needs to be z-aware :P
14:26:07 <peter1138> i think i may have done that once
14:26:18 <peter1138> when i was working on my original bridges over stuff patch
14:26:31 <Celestar> for ... some patch I cannot remember
14:26:51 *** andythenorth has left #openttd
14:26:53 <Belugas> the initial newmap, maybe?
14:26:57 *** andythenorth has joined #openttd
14:27:30 <Celestar> anyway I think that patch is 1) now useless, 2) lost on some of my backup disks at mom's :P
14:28:41 <Celestar> can't build a tunnel inside a cliff either :P
14:29:00 <Celestar> because there isn't a "tile" to end it :D
14:32:04 <peter1138> Celestar, viewport.cpp:23057
14:32:13 <peter1138> + AddSortableSpriteToDraw(image, pal, x, y, 16, 16, 0, z, false, extra_offs_x, extra_offs_y, 0, sub);
14:32:20 <peter1138> something like that :p
14:32:52 <peter1138> i read the revision, not the line :p
14:33:06 <Celestar> I can't do that yet, because saveload will fuck the cliff.
14:33:12 <peter1138> it's in AddTileSpriteToDraw() basically
14:33:54 <peter1138> ^B is ... different with that
14:34:09 <peter1138> the world is filled with bounding boxes ;)
14:35:03 <peter1138> view bounding boxes
14:35:36 <peter1138> hmm, bounding boxes might be wrong for slopes...
14:36:29 * Celestar thinks cliffs open not one, but several can-o-worms
14:39:27 <Celestar> 1) We need a new UI to change individual corners.
14:39:35 <Celestar> 2) Z Order problem in the viewport
14:39:42 <Celestar> 3) Missing Z information in GTTS
14:39:52 <TinoDidriksen> ...give in and just go 3D.
14:40:07 <Celestar> TinoDidriksen: and that helps exactly how? :P
14:40:48 <Celestar> I think 2) is a minimal problem other than performance
14:41:25 <Celestar> but BBs might need adaption
14:42:01 <Belugas> 3D.. the new buzz word... after XML ;)
14:42:59 <SpComb> instead, we store the XML nodes in a sparse voxel space
14:44:13 <Celestar> also, I'm not sure how difficult add Z to the GTTS stuff is.
14:46:15 <Celestar> how is it solved with bridges ....
14:46:43 <Yexo> as you said yourself, bridges don't exist
14:46:53 <Yexo> so vehicles on the bridge are on either end of the bridge
14:47:03 * andythenorth remembers an idea about terraforming
14:47:18 <Celestar> Yexo: nah I meant something else.
14:47:29 <Yexo> the drawing order? or what
14:48:00 <andythenorth> There's only so much mud in the world. If you want more mud, you have to take it from somewhere. If you want less mud, you have to put it somewhere.
14:48:05 <andythenorth> would make small maps interesting
14:48:27 * andythenorth suspects that small maps would end up flat at height level 8 :P
14:49:11 <Celestar> Yexo: same link as above, last file (Bridge)
14:50:04 <Yexo> the vehicle suddenly appears at the bridge ramp?
14:50:18 <Celestar> apparently it's not Z based :P
14:51:01 <Celestar> it goes purely by direction
14:51:16 <Yexo> see GetTileTrackStatus_TunnelBridge
14:51:27 <Yexo> you can only enter the tile from one direction
14:52:43 <Celestar> and I think I know where I last try to use z awareness....
15:08:53 <peter1138> yeah, sometimes it just knows :p
15:15:38 <z-MaTRiX> wanted to try out haskell programming, but i got demotivated when the library install 'cabal' thing attempted to count the spaces in the config file before the options (unsuccessfully)
15:33:42 *** supermop has joined #openttd
16:02:38 <andythenorth> it's gone all quiet :o
16:03:24 <z-MaTRiX> so why does openttd not have an fps meter?
16:03:50 <z-MaTRiX> rendering time/processing time statistics?M
16:04:12 <z-MaTRiX> sure its statistical...
16:04:51 <z-MaTRiX> or might tell you how slow is your pc for Openttd
16:04:54 <Yexo> well, same answer as always: nobody has been interested enough to code it
16:05:21 <__ln___> seriously, what purpose would such a meter serve?
16:05:42 <z-MaTRiX> __ln___<< informational
16:06:15 <z-MaTRiX> also you could check your overall performance if you upgrade some functions
16:07:12 <Yexo> that is way too unreliable if you actually use a gui (which you need to see such a fps meter)
16:07:19 <Yexo> we have profiling and the null blitter for that
16:08:29 <z-MaTRiX> Yexo<< sure i know SDL forces a waitvretrace, but it is still possible to check the processing time, and rendering time seperately ;)
16:08:55 <Yexo> that is compeltely besides the point
16:09:00 <z-MaTRiX> btw im making friends with mutexes right now to be able to update screen asnychronously
16:09:21 <glx> we just disable display when profinling
16:09:44 <z-MaTRiX> hmm well thats a solution for testing
16:21:13 <andythenorth> Eddi|zuHause: have you got classes all figured out yet? :)
16:35:27 *** Tintinfan has left #openttd
16:40:42 *** TGYoshi has joined #openttd
16:42:28 *** sla_ro|master has joined #openttd
17:06:58 *** valhallasw has joined #openttd
17:20:15 *** andythenorth is now known as Guest16606
17:20:16 *** andythenorth has joined #openttd
17:23:30 *** andythenorth is now known as Guest16608
17:23:30 *** andythenorth has joined #openttd
17:56:02 <CIA-6> OpenTTD: rubidium * r23179 /trunk/src/ (3 files in 2 dirs): -Codechange: use some tooltips that already existed (monoid)
17:58:57 <CIA-6> OpenTTD: rubidium * r23180 /trunk/src/lang/english.txt: -Cleanup: remove traces of having to double click on the NewGRF for changing the parameters
18:00:51 <CIA-6> OpenTTD: rubidium * r23181 /trunk/src/lang/english.txt: -Cleanup: remove some unused strings (monoid)
18:02:13 *** LordAro has joined #openttd
18:04:01 <DorpsGek> LordAro: Commit by rubidium :: r23178 /trunk/src (5 files in 2 dirs) (2011-11-10 06:15:03 UTC)
18:04:02 <DorpsGek> LordAro: -Feature [FS#4780]: in-game readme.txt readmer (LordAro)
18:06:42 <Terkhen> what are you going to code now? ;)
18:06:51 <Eddi|zuHause> <Celestar> aren't those ICE cars a short? <-- they almost fit into TTD scale then :p
18:06:58 * Terkhen hopes for something way more scary
18:07:58 <CIA-6> OpenTTD: yexo * r23182 /trunk/src/newgrf_config.cpp: -Feature: allow translatable readme files
18:07:58 <LordAro> i dunno, i had some ideas while making the readme viewer, but i've forgotten them :L
18:09:01 <Terkhen> it's late for making them translatable I guess
18:09:10 <CIA-6> OpenTTD: rubidium * r23183 /trunk/src/ (lang/english.txt town_cmd.cpp): -Codechange: merge BRIBE_FAILED and BRIBE_FAILED_2 messages (monoid)
18:09:46 <CIA-6> OpenTTD: rubidium * r23184 /trunk/src/lang/ (59 files in 2 dirs): -Cleanup: remove the removed strings from the translations as well
18:11:31 <LordAro> i think i'll probably have a go at readme viewers for AIs and base sets, etc
18:12:43 <Eddi|zuHause> CIA-6> OpenTTD: rubidium * r23180 /trunk/src/lang/english.txt: -Cleanup: remove traces of having to double click on the NewGRF for changing the parameters <-- i really would like this behaviour back...
18:13:08 <Yexo> currently double-click moves a grf from active<>inactive, right?
18:13:20 <Yexo> I don't see how that is compatible with "open parameter window on double-click"
18:14:01 <LordAro> yay! moar settings :)
18:14:05 <Rubidium> okay... I should make more cryptic messages
18:26:49 <LordAro> ty, although i would estimate that 60%+ of the work was done by Alberth and Rubidium though
18:27:03 <LordAro> but i motivated them to do it! :)
18:27:45 <Rubidium> well, then you've done the remaining 120% ;)
18:32:29 * LordAro only just got that :)
18:35:31 <Yexo> running 14 AIs makes openttd really slow
18:35:56 <Yexo> all AIs run on the same core
18:39:56 <LordAro> umm... "Warning. Your computer is too useless to run with 14 AIs. Please give up now"
18:40:48 <Yexo> main problem is lack of multicore support
18:41:08 <Terkhen> yes, I meant multicore support for running AIs in parallel :P
18:42:11 <LordAro> yes. bit advanced for me... :)
18:42:17 <LordAro> see above solution :)
18:44:00 <Terkhen> ok, as long as you use all 14 cores for displaying the message
18:45:34 <CIA-6> OpenTTD: translators * r23185 /trunk/src/lang/ (7 files in 2 dirs): (log message trimmed)
18:45:34 <CIA-6> OpenTTD: -Update from WebTranslator v3.0:
18:45:34 <CIA-6> OpenTTD: belarusian - 23 changes by Wowanxm
18:45:34 <CIA-6> OpenTTD: english_US - 3 changes by Rubidium
18:45:34 <CIA-6> OpenTTD: german - 24 changes by planetmaker
18:45:36 <CIA-6> OpenTTD: spanish - 34 changes by Terkhen
18:45:36 <CIA-6> OpenTTD: swedish - 45 changes by Zuu
18:50:53 *** TheMask96 has joined #openttd
18:51:11 *** DayDreamer has joined #openttd
19:06:11 *** Alberth has joined #openttd
19:06:11 *** ChanServ sets mode: +o Alberth
19:07:12 *** Devroush has joined #openttd
19:39:38 *** Hyronymus has joined #openttd
19:40:51 <CIA-6> OpenTTD: yexo * r23186 /trunk/src/3rdparty/squirrel/squirrel/sqbaselib.cpp: -Fix [FS#4830]: [Squirrel] replace custom qsort by std::sort to fix stack overflow
19:41:25 * Rubidium ponders the irony in those emails "asking" to consider the environment by not printing it. Does one really think that it doesn't get printed that way? I'd argue you'd be printing even more (i.e. the request not to do it) and you'd be wasting a lot of energy by adding, transporting, processing and reading it
19:41:58 *** lobstaroooo has joined #openttd
19:42:07 <TyrHeimdall> Rubidium: don't forget the added electricity needed for the transfer of said bulk of text :P
19:42:29 <Rubidium> that's the transporting and processing I'm talking about ;0
19:47:47 * Eddi|zuHause never got such an email
19:48:18 *** TWerkhoven[l] has joined #openttd
19:48:53 *** TGYoshi has joined #openttd
19:54:09 *** supermop has joined #openttd
20:04:04 *** Cybertinus has joined #openttd
20:07:15 <CIA-6> OpenTTD: yexo * r23187 /trunk/src/3rdparty/squirrel/squirrel/sqbaselib.cpp: -Fix (r23186): MSVC allowed non-const where const was mandatory
20:07:55 *** JVassie has joined #openttd
20:20:28 <Zuu> LordAro: Have you any plans to generalize the NewGRF readme reader to a Readme Reader for other content types that also use tar files?
20:33:08 <Yexo> <LordAro> i think i'll probably have a go at readme viewers for AIs and base sets, etc <- yes
20:35:28 <Zuu> I've just submitted Swedish translations for the NewGRF readme feature :-)
20:36:04 <Zuu> I kind of thinks that "NewGRF" in "NewGRF readme of {STRING}" could be omitted.
20:37:48 <Alberth> there are also 'NewGRF parameters' and 'NewGRF Settings' :)
20:38:28 *** Hyronymus has joined #openttd
20:39:01 <Yexo> but those don't have the grf name in the title
20:50:56 <Zuu> Also you need to click first on NewGRF settings to be able to view the readme.
20:59:38 * peter1138 idly ponders the purpose os 30_PaintingVoidTiles.patch
20:59:44 <peter1138> (more height levels)
21:00:30 <peter1138> why is there geometry outside of the map... :S
21:05:55 *** LordAro- has joined #openttd
21:06:17 *** LordAro- is now known as LordAro
21:07:40 <Eddi|zuHause> peter1138: afair that has something to do with the "outside" needing to be black. with the current method, that doesn't extend well beyond height level 16
21:08:22 <peter1138> i don't see the relevance :S
21:08:50 <LordAro> i think congratulations are in order for the both of us :)
21:09:34 <Alberth> I was somewhat surprised tbh :)
21:10:45 <Eddi|zuHause> peter1138: if the "void" tile is painted flat, it must be painted at level 0 and repeated for each height level, up to the level of the map border
21:11:22 <Eddi|zuHause> peter1138: if you have sloped black tiles, you can just draw them like normal tiles
21:14:47 *** TWerkhoven2 has joined #openttd
21:16:42 *** andythenorth has joined #openttd
21:20:23 <peter1138> Eddi|zuHause, turn it into a cliff :)
21:20:51 <andythenorth> Eddi|zuHause: run classes off a cliff
21:20:52 <Eddi|zuHause> peter1138: that would be very simcity-y
21:21:06 <andythenorth> seems I upset wallyweb :(
21:21:11 <andythenorth> who else can I upset :P
21:21:16 <peter1138> Eddi|zuHause, also wouldn't solve anything
21:21:22 <peter1138> because that's what it does currently
21:21:24 <b_jonas> simcity isn't the only game doing that
21:21:29 <peter1138> except it just draws the shadow sprite
21:21:48 <peter1138> i guess drawing up to 255 of those shadow sprites gets a bit... repetitive
21:23:42 <peter1138> disallow freeform edges, that'll solve it
21:24:33 *** TWerkhoven[l] has joined #openttd
21:29:58 <peter1138> i can't see how to make scaled-up tile edges match native edges :S
21:31:38 <andythenorth> Eddi|zuHause: how would you feel about abandoning cargo classes and substituting wagon classes?
21:31:45 <andythenorth> I had some pm chat with MB
21:33:45 <peter1138> scale2x is not right :S
21:35:11 <andythenorth> I'm only continuing to pursue classes because I get kicked in the teeth every time they're changed for a FIRS cargo, and I want to get it sorted out :P
21:35:17 <Eddi|zuHause> where was that ancient double mode filter patch...
21:35:44 <andythenorth> from a vehicle set point of view, I'm ecstatic if we lose the XOR on labels + gain a list instead of bitmap
21:37:53 <andythenorth> "NO you may not change classes, it breaks sets"
21:38:02 <andythenorth> "NO you may not change labels, it breaks sets!"
21:39:45 <Eddi|zuHause> i think that last one is rubbish
21:40:19 <peter1138> well yes, simple pixel doubling looks great
21:40:21 <Eddi|zuHause> it may cause a few inconsistencies, but it's not "breaking"
21:40:30 <andythenorth> nah, I'm exagerating
21:40:34 <peter1138> but the still has the issue of mixing highres and original sprites ;p
21:40:59 <andythenorth> pixel doubling? :o
21:41:10 <andythenorth> that would be useful now my eyes are getting old
21:41:49 <Eddi|zuHause> peter1138: there was a patch that had several "filters" to get to double size, not only simple doubling
21:42:16 <andythenorth> please don't ship that
21:42:20 <andythenorth> it will reveal all my mistakes
21:44:14 <Elu> i wish we could get an extra zoom level in trunk
21:44:23 <Elukka> even with just the current graphics
21:44:54 <Elukka> basically all good sprites look better at double size to me..
21:45:06 <Elukka> because they're so damn small in the game by default
21:45:23 <peter1138> yeah, 2x looks nice
21:46:06 <peter1138> the 32bpp crowd (all 2 of them?) would probably go mad if it wasn't 4x ;)
21:47:10 <andythenorth> 4x also looks nice
21:47:17 <andythenorth> they all look nice :)
21:47:39 <andythenorth> what a lot of exciting stuff is getting done
21:47:53 <Elukka> is that zoom thing something that we might one day see in trunk?
21:48:02 <andythenorth> it's more exciting even than an episode of In The Night Garden :o
21:50:13 <peter1138> ^ scale2x applied twice
21:50:49 <peter1138> road surface looks ok
21:51:24 <andythenorth> pixels should be nearly-square
21:53:33 <peter1138> paint lines go weird :S
21:54:02 <peter1138> this is 8bpp, of course
21:54:37 <peter1138> opengfx looks nicer than ttd there
21:58:33 <peter1138> anyway, it has performance issues :(
21:58:39 <Eddi|zuHause> the old patch applied some magic so that 30° lines get more emphasised
21:59:12 <Eddi|zuHause> peter1138: apply scaling on a per-sprite basis, and put the high-res sprites into the sprite cache
21:59:20 <peter1138> Eddi|zuHause, it is
22:29:55 <andythenorth> my steel sprites suck
22:36:03 <andythenorth> good night Terkhen
22:38:01 <andythenorth> fixing lighting :P
22:38:11 <peter1138> way too much effort to draw sprites zoomed out :(
22:46:14 *** Prof_Frink has joined #openttd
22:54:41 *** lobstaro0o has joined #openttd
23:03:52 <andythenorth> @calc 40 + 40 *0 +1
23:09:59 <Eddi|zuHause> even i could have calculated that...
23:11:25 <DorpsGek> TGYoshi: Error: float division
23:13:06 <__ln___> DorpsGek: float division what?
23:13:50 <TGYoshi> And I thought 0/0 == 0
23:14:06 <andythenorth> Eddi|zuHause: I got that one wrong
23:14:08 <__ln___> TGYoshi: it certainly isn't.
23:14:13 <andythenorth> annoyingly my wife got it right
23:14:49 <andythenorth> I never learnt proper order of operations before, in engineering maths we were taught that it's not a valid calculation if you don't include the brackets
23:14:51 <TGYoshi> __ln___: Why not? Zero pieces of ??? devided over zero people, how much get each guy?
23:15:20 <andythenorth> you can't divide by zero
23:15:22 <andythenorth> it's not a thing
23:15:26 <andythenorth> you get at best oo
23:15:42 <TGYoshi> Err, 1/0 = infinite, for me
23:15:46 <Eddi|zuHause> andythenorth: there's a whole branch of mathematics just about 0/9
23:15:51 <Mazur> Of the denomimator > 0 you get something infinite, yes.
23:15:53 <__ln___> TGYoshi: the question is not valid because there are zero people, so there's no one to divide to.
23:16:28 <Eddi|zuHause> __ln___: if there are zero trees in the wood, and one falls down, does it make noise?
23:16:43 <planetmaker> TGYoshi: what's lim(x->0) x/(x^2) ?
23:16:59 <planetmaker> it's 0/0 in the limit. But is 0 the right answer?
23:17:29 <planetmaker> or lim(x->0) x/(2x) ?
23:17:36 <TGYoshi> I think it depends on the situation the division happens
23:17:45 <planetmaker> there 0/0 = 0.5 is "right"
23:17:54 <planetmaker> it doesn't depend. It's never defined
23:18:33 <__ln___> (it's defined on PowerPC)
23:18:37 <planetmaker> and if you define it, it's that: a definition which is individual to that very case you define it
23:18:51 <andythenorth> philosophy before bed time :P
23:19:07 <Eddi|zuHause> i have a feeling we have this discussion every week
23:19:19 <TGYoshi> A discussion about 0/0?
23:19:32 <andythenorth> we also discuss classes
23:19:34 <planetmaker> anyway. I was about to head off :-) g'night again
23:19:43 <TGYoshi> Classes are discussed daily here >_>
23:23:29 <__ln___> yes, this must be the second 0/0==0 discussion within two weeks.
23:25:19 <TGYoshi> Maybe I should write (0/0) in every place any number can take place
23:26:42 <Eddi|zuHause> you can draw an apple in every place where a number can apperar
23:26:47 <__ln___> should there be something about 0/0 in the topic? ... on the other hand, that would make the matter on-topic
23:27:20 <Eddi|zuHause> just not a bitten one, you might run into legal troubles
23:28:04 <Eddi|zuHause> why not an apple?
23:28:23 <Eddi|zuHause> numbers are just completely random symbols
23:30:06 <TGYoshi> Id prefer an orange instead
23:30:44 *** Brianetta has joined #openttd
23:34:30 <Mazur> Here, have a bananananana.
23:38:23 <andythenorth> Eddi|zuHause: wrt to excludes - remind me - when you add a cargo to the CTT, why do you need to explicitly exclude it? You had a convincing case
23:39:06 <Eddi|zuHause> not sure what the question is
23:40:08 <andythenorth> so if a prop is added for included refits using indices to CTT
23:40:30 <andythenorth> you had compelling case to also add an exclude prop
23:40:38 <andythenorth> again, indices to CTT
23:42:12 <Eddi|zuHause> the reason was: when i add an entry to CTT, e.g. for one wagon to show separate graphics, then i shouldn't need to touch any other vehicle in the set
23:42:33 <andythenorth> that is a compelling aim
23:42:55 <andythenorth> what causes you to need to touch the others?
23:43:41 <andythenorth> you want them to still be refittable to the new cargo?
23:43:50 <Eddi|zuHause> if you automatically exclude all entries of the CTT from refitting, i need to re-add it to every vehicle that previously decided based on classes
23:46:04 <andythenorth> and time for sleep for me
23:52:21 *** devilsadvocate_ has quit IRC
23:52:30 *** devilsadvocate_ has joined #openttd
continue to next day ⏵
