IRC logs for #openttd on OFTC at 2010-04-25
⏴ go to previous day
00:06:56 *** ProfFrink has joined #openttd
00:12:05 *** ProfFrin1 has joined #openttd
00:12:39 *** ProfFrin1 is now known as Prof_Frink
00:13:10 *** Prof_Frink is now known as Guest1174
00:31:14 *** ptr is now known as Guest1177
00:39:02 <Eddi|zuHause> the site itself works fine
00:39:12 <Eddi|zuHause> maybe your provider has difficulties
00:52:50 *** theholyduck has joined #openttd
01:13:36 *** Guest1174 is now known as Prof_Frink
01:14:10 *** Prof_Frink is now known as Guest1178
02:06:54 *** r0b0tb0y has joined #openttd
02:14:39 *** Guest1178 is now known as Prof_Frink
02:15:10 *** Prof_Frink is now known as Guest1180
02:19:02 *** ChanServ sets mode: +v tokai
03:15:30 *** Guest1180 is now known as Prof_Frink
03:16:10 *** Prof_Frink is now known as Guest1194
03:37:48 *** Wizzleby has joined #openttd
03:48:13 <ashaw> Hello, I am wondering if anyone is here?
03:49:07 <DorpsGek> Rubidium: I have not seen anyone.
03:49:18 <Rubidium> no, no anyone is here
03:51:37 <ashaw> I have been thinking about signals and was wondering if the signaling system runs on passes or is event driven?
03:55:10 *** r0b0tb0y has joined #openttd
03:56:46 <Rubidium> easy, oh impatient one
03:57:15 <Rubidium> don't even get time to check which one it is?
03:58:19 <Rubidium> anyhow, it looks event driven
03:59:09 <ashaw> I was wondering as it seems that the coop have found uses for a NOT gate.\
04:00:04 <ashaw> and was thinking that a way to solve the problem of efficency was to have the gate only be able to change once every 10 ms or something similar.
04:03:16 <ashaw> would that be difficult to implement
04:08:32 <ashaw> My idea is an anti-entry signal, that give the inverse of the output that an entry pre-signal would give. to stop locks, it will only change every 10 ms, if an event occurs that wants it to change, it will not change but rather schedule an event to occur in 10ms.
04:16:33 *** Guest1194 is now known as Prof_Frink
04:17:11 *** Prof_Frink is now known as Guest1199
04:51:24 *** devilsadvocate has quit IRC
04:51:40 *** devilsadvocate has joined #openttd
04:55:54 *** Eddi|zuHause has joined #openttd
05:14:08 <planetmaker> ashaw: the idea of a not-signal is not new
05:16:21 <ashaw> I know that, I am only asking now as the general response was that it would only be added if there was a compelling reason for adding it.
05:16:49 <ashaw> coop game 180 had over 800 of them, I think that comes close to a compelling reason.
05:17:36 *** Guest1199 is now known as Prof_Frink
05:18:05 <planetmaker> we had 800 not-gates? That's something I doubt ;-)
05:18:10 *** Prof_Frink is now known as Guest1200
05:18:39 <ashaw> You had over 800 logic trains.
05:19:05 <planetmaker> that doesn't mean 800 not-gates
05:19:42 <ashaw> that can be made much simpler with a not gate.
05:19:44 <planetmaker> I don't know what it takes to build one. But one train doesn't suffice IIRC
05:20:16 <planetmaker> also not-gates are not the only use for logic trains
05:20:28 <ashaw> not, or and logic gates.
05:22:34 <planetmaker> Even if there were 800 not-gates, that's not sufficient to introduce really to OpenTTD.
05:23:07 <planetmaker> IF, then OwenS' programmable signals or something along those lines is a way to go. Not just "yet another signal type"
05:24:13 <planetmaker> who would use it other than 50 people out of 100000?
05:24:19 <ashaw> The way that they are being used, the programmable signal is overkill.
05:25:34 <ashaw> They are being used to improve load balancing, and others.
05:26:07 <planetmaker> It doesn't make sense conceptionally to introduce another signal just for the sake of this. If signals are touched, it'll be a more generic solution.
05:26:21 <planetmaker> If there's now a new not-signal, then next whoever comes with a xor signal
05:26:27 <planetmaker> that doesn't make sense
05:26:48 <planetmaker> So: either go for programmable signals which is more generic or don't do it.
05:27:13 <planetmaker> And honestly: load balancing can be achieved without.
05:27:23 <ashaw> you do not need an xor gate.
05:27:47 <planetmaker> I'm well aware of that blog :-)
05:27:59 <ashaw> also xor gates can be made easily with a not gate.
05:28:28 <planetmaker> yes, but why build it, if it can be made directly? Same as goes for not-gates now?
05:29:39 <ashaw> because, not gates are being implemented in a stop-gap method, that is really ugly.
05:30:24 <planetmaker> Also: psg180 was not the first of our SNRW / logic games. Nor will it be the last.
05:31:14 <planetmaker> But given the really limited use, it might not really be worth the additional effort which requires modification of all pathfinders and so on.
05:31:26 <planetmaker> Also the map array might not have really more space for those
05:32:01 <ashaw> What about the new map array.
05:32:02 <planetmaker> Or rather: that should be reserved space, those one(?) two(?) bits put to better use.
05:33:05 <planetmaker> go right ahead proposing a re-write of the map array
05:33:21 <planetmaker> just for the sake of not-signals
05:33:24 <ashaw> I thought there was already a project in place
05:34:10 <planetmaker> there's no intention I'm aware of that the map array is being re-written
05:34:27 <planetmaker> except that one forum thread...
05:35:58 <ashaw> Also, should it not be an ENUM rather than a bit mask
05:36:39 <ashaw> and why would you need to change the pathfinders?
05:38:07 <ashaw> there are currently 36 types of signal. this would take up 6 bits, the minimum is 8 bits.
05:38:28 <ashaw> adding a new signal type should not need to change the map array.
05:40:18 <planetmaker> 4*3*2 + 2*2 are already there
05:40:26 <planetmaker> @calc 4*3*2 + 2*2
05:41:31 <planetmaker> actually 2*2*2. So 32
05:41:42 <planetmaker> there surely are also semaphore path signals
05:42:19 <planetmaker> and why do you think that the minimum is 8 bits?
05:42:21 <ashaw> there are one way path signals.
05:42:51 <ashaw> as you adress 1,2,4 or 8 bits to something.
05:43:09 <ashaw> we have more than 4 bits, so we have 8
05:43:59 <planetmaker> ok, signals already are an enum as it seems
05:45:19 <planetmaker> the signal type currently is 3 bit
05:46:05 <planetmaker> semaphore / light is another bit
05:46:19 <planetmaker> so a current signal uses 4 bits
05:48:04 <planetmaker> also have a look at your conig file in order to see the many settings of path finders which interface with signals
05:48:26 <planetmaker> even though it seems that the "red" state is stored in the map
05:49:32 <ashaw> though the signal type uses three bits, only 6 of the 8 states are used.
05:50:23 <planetmaker> two precious states reserved
05:50:37 <planetmaker> preferrably actually for path advance signals ;-)
05:50:43 <ashaw> what are they reserved for?
05:51:20 <planetmaker> weak ahead reservation for path signals
05:51:27 <ashaw> what file is the map array defined.
05:51:39 <planetmaker> dunno. I read the docs
05:59:14 <planetmaker> in any case the short answer is: those two signal types are reserved for more general ideas on signals than a not signal
05:59:58 <ashaw> I am just wondering why it is 3 bits.
06:00:05 <ashaw> and why it could not be changed.
06:00:37 *** nighthawk_c_m has joined #openttd
06:01:43 <ashaw> there cannot be no space.
06:02:19 <ashaw> and if there is not, I will read the code and refactor it so that there is.
06:05:14 <planetmaker> look at ~/ottd/trunk/docs/landscape.html
06:05:39 <planetmaker> and ottd/trunk/docs/landscape_grid.html respectively
06:11:46 *** nighthawkcm has joined #openttd
06:18:40 *** Guest1200 is now known as Prof_Frink
06:18:42 <ashaw> but will it be added to trunk?
06:19:18 <planetmaker> but not signals on their own have a much lower chance
06:19:20 *** Prof_Frink is now known as Guest1206
06:19:56 <planetmaker> actually they belong nearly to the already rejected features ;-)
06:20:31 <planetmaker> but that might be a result of the patch quality back then
06:23:22 <ashaw> I agree that this is a much better patch.
06:38:44 *** Alberth has joined #openttd
06:44:39 *** Guest1206 is now known as Prof_Frink
07:00:50 <planetmaker> programmable signals
07:08:35 <Alberth> trying to build a nano processor?
07:21:02 *** ChanServ sets mode: +v tokai
07:22:08 <planetmaker> moin Alberth :-) Not me. And it's already possible. But yeah... not in nano-size, I guess :-P
07:22:37 <planetmaker> I rather fix all train alignments in OpenGFX :-)
07:23:38 <Alberth> A micro processor contains several millions transistors, I guessed you may want to start at a somewhat smaller scale :D
07:24:13 <Alberth> but train alignment fixes is also a good use of your time :)
07:24:19 *** r0b0tb0y has joined #openttd
07:24:47 <ccfreak2k> Alberth, better not tell him about FPGAs then.
07:27:21 <planetmaker> I think I should write a tutorial on my train alignment. I think I now have understood it :-). And it is now "just" getting all the sprites in the correct graphical layout
07:27:52 <planetmaker> but FPGA: good stuff ;-)
07:28:08 <planetmaker> faster than software crap :-P
07:28:24 <Alberth> or programmable signals :p
07:28:48 <planetmaker> but then I don't need to control OpenTTD trains at milli-second level
07:29:12 <planetmaker> usual OS wouldn't really allow for that
07:31:34 * Alberth ponders building a computer from the planets/suns of the galaxy
07:32:26 <planetmaker> the answer will be 42 or so...
07:34:08 <Alberth> hmm, yeah it has been done before
07:45:46 <nighthawkcm> A quick question, when using Pikka's basic industries (Version 1.5) - the Coal mine for example shows a line saying 0% of an estimated 8k tonnes transported - what exactly is this telling me?
07:47:23 *** lolman_ has joined #openttd
07:48:41 <amalloy> i'm curious too actually. i've had it say like 254% of estimated 8k, but never played long enough to see if it ever runs out
07:49:23 <nighthawkcm> ah, so it is not actually a limitation to the ore deposit
07:51:05 <Alberth> normally, primary industries do run out of raw material and close down. How Pikka's basic industries do this, I don't know.
07:51:55 <nighthawkcm> Normally they don't unless you use a industry grf afaik
07:52:09 <nighthawkcm> They close if they are under serviced
07:52:38 <nighthawkcm> or am I missing something here
07:53:02 <planetmaker> Alberth: primary industries DO NOT run out of raw material, eh?
07:53:16 <Alberth> planetmaker: they don't?
07:53:19 <planetmaker> except in ECS / PBI where there's some algorithm... dunno which either
07:53:25 <Alberth> oh sorry for the confusion then
07:53:30 <planetmaker> Alberth: default without newgrf? Never
07:54:07 * Alberth hardly ever plays, and if I do, I hardly use NewGRFs :)
07:54:18 <planetmaker> so you should know :-P
07:54:45 <Alberth> all my games start at 1950, and end somewhere in the '80s :)
07:55:08 <amalloy> for estimated production
07:55:10 <planetmaker> I spend half my time watching trains and vehicles go... so 1980 is little time
07:55:12 <nighthawkcm> Well, now as I understand it PBI also doesn't run out, maybe this is a placeholder for a later to be implemented algorithm to limit deposits - which I very much dislike :-P
07:55:56 <amalloy> it doesn't run out, but it starts decreasing more and increasing less
07:55:58 <Alberth> nighthawkcm: you are free to make your own better industry NewGRFs :)
07:56:33 <nighthawkcm> I have to admit that I don't understand shit about the NFO files and find the documentation very confusing for a beginner
07:56:43 <planetmaker> amalloy: it's the choice of the newgrf coder. You can devise nearly any fancy algorithm concerning decrease / increase and closing of industries
07:56:48 <asilv> in pbi, once it reaches 100% capacity, industries can only decrease production, so they will close eventually, but it may take long time
07:56:57 <nighthawkcm> And I am hardly able to read a NFO of a existing Industry GRF - so no freaking way I understand the game mechanics
07:57:35 <amalloy> planetmaker: yes, clearly. but i provided a link which shows what it does, and then summarized
08:04:17 *** andythenorth has joined #openttd
08:08:42 * andythenorth ponders hovercraft docking on land...
08:08:51 <andythenorth> ...hovercraft recolor sprites
08:08:58 <andythenorth> ...hovercraft wake sprites
08:09:08 <andythenorth> and how to best show hovercraft top speed :P
08:09:46 * andythenorth also ponders using the same hovercraft sprites for an RV
08:10:03 <planetmaker> moin andythenorth
08:10:38 <planetmaker> re max speed: that should IMHO be the speed which a vehicle drives when it's fasted. If that's unloaded only, so it be
08:10:57 <planetmaker> My car is unloaded also faster than fully loaded with the luggage of 4 people when going into longer holidays
08:11:02 <andythenorth> but the speed that is useful is the one when loaded? As that is what payment is based on....
08:11:21 <planetmaker> my papers state though the theoretical max speed ;-)
08:11:52 <planetmaker> hm... for ships there's no such thing as TE... hm
08:12:08 <planetmaker> do ships have something like drag coefficient?
08:12:15 * andythenorth wonders if a vehicle type "hovercraft" could be implemented as a monster hack on aircraft shadows
08:13:43 <Turgid> Max speed means maximum, not "somewhat limited speed" or "loaded speed," IMO.
08:13:44 <planetmaker> dbg: [sl] Game Load Failed
08:13:46 <planetmaker> File not readable
08:13:47 <planetmaker> ^^ May be true, but for a non-existing file the message could be improved ;-)
08:14:40 * planetmaker shudders at the units of that equation
08:14:51 * andythenorth thinks the logical definition of 'Max speed' may not be accepted by annoyed players
08:15:07 <planetmaker> andythenorth: any definition will not be accepted
08:15:14 <andythenorth> and yes...the hovercraft should accelerate faster - if that's what you're thinking about planetmaker
08:15:19 <planetmaker> if you introduce different max speeds as a function of load
08:15:39 <planetmaker> as such you can use the more sensible definition then.
08:16:13 <planetmaker> or just keep a single max speed.
08:16:30 <planetmaker> make it the loaded one. And fine is.
08:17:13 <peter1138> and then the next thing you know
08:19:13 *** Devroush has joined #openttd
08:28:32 <andythenorth> so when a train goes slower loaded, players don't complain. So maybe planetmaker is right
08:29:18 <planetmaker> a load dependent drag coefficient would make sense :-)
08:29:38 <planetmaker> like c_drag = 0.5 ... 0.9 for unloaded ... loaded
08:29:44 <andythenorth> is that how the real physics works for hovercraft?
08:29:57 <planetmaker> hovercraft... probably not.
08:30:05 <planetmaker> there it shouldn't matter. You just need more fuel
08:30:12 <planetmaker> as you need more lift
08:30:27 <planetmaker> the drag probably doesn't change much unless you put many containers on them
08:30:48 <planetmaker> and acceleration will be worse... well.
08:33:07 <andythenorth> dunno why I like the variable speed thing so much
08:33:21 <andythenorth> I just think it's neat :P
08:35:06 <Alberth> you are compensating for programming those industries that do not move at all :p
08:35:48 * andythenorth dreams of factory ships
08:39:24 <Alberth> as long as you don't hunt whales.
08:40:18 <andythenorth> maybe there should just be one speed for hovercraft, and then a refit for 'less cargo, but faster' or vice versa
08:42:27 <planetmaker> andythenorth: that sounds much better
08:43:06 <planetmaker> trade 1/3 of the cargo for 30% speed or so
08:43:26 <planetmaker> and rise running costs by 20% ;-)
08:43:44 <DDR> Drag is a function of the head-on silouhette, not of weight, for a hovercraft. If you were on wheels, then the drag would increase as you put more load on them.
08:45:44 <planetmaker> DDR: and exactly the silouhette changes, if you load containers
08:46:23 <DDR> I assumed the hovercraft was a covered model, where the containers fit inside the craft itself. Sorry.
08:47:38 *** |Jeroen| has joined #openttd
08:51:27 *** Progman has joined #openttd
08:51:34 <andythenorth> 20t@66mph, 30t @42mph seems about right
08:57:36 *** r0b0tb0y has joined #openttd
08:58:27 *** Cybertinus has joined #openttd
09:12:08 *** devilsadvocate_ has joined #openttd
09:12:38 *** devilsadvocate has quit IRC
09:25:44 *** lolman_ is now known as lolman
09:39:00 *** amalloy1 has joined #openttd
09:57:40 *** robotboy has joined #openttd
10:09:49 *** frosch123 has joined #openttd
10:40:36 <blathijs> Eddi|zuHause: Wtf? :-S
10:40:39 <__ln__> is that a reliable source?
10:40:48 <Eddi|zuHause> __ln__: i have no idea
10:41:19 *** KenjiE20 has joined #openttd
10:43:07 <blathijs> It doesn't cite any references, so I'm skeptical
10:43:15 *** einKarl has joined #openttd
10:43:44 <__ln__> me too, it's sounds too silly to be true.
10:44:18 <Eddi|zuHause> ... i wouldn't put it past them...
10:44:43 <ccfreak2k> I looked up extreme programming on Wikipedia and was disappointed. :(
10:44:55 <Eddi|zuHause> it sounds too manager-y plausible to say "hey, we have this for iPhone and iPad, why not make it for Mac OS as well?"
10:45:02 <Alberth> it was not so extreme?
10:45:45 <ccfreak2k> Eddi|zuHause, sure, and they've proven that it's worked well so far with the iPhone.
10:46:23 <frosch123> extreme programming :) that is what we do for ottd
10:46:37 <ccfreak2k> Alberth, I was hoping for something gameshow worthy.
10:46:49 *** robotboy has joined #openttd
10:47:21 <Alberth> frosch123: shouldn't we do pair programming too?
10:48:10 <frosch123> we review most patches... or do you mean the patch is only allowed to be reviewed by one? :p
10:48:52 <Alberth> pair programming is sitting together at the same computer afaik, we don't do that :)
10:49:07 <ccfreak2k> frosch123, maybe he means two programmers trying to use a single keyboard.
10:49:31 <Alberth> but patch reviewing is also part of extreme programming indeed.
10:49:37 <__ln__> there would be a significant delay with sending a keyboard from e.g. from netherlands to canada and back.
10:49:39 <Alberth> ccfreak2k: not at the same time :p
10:49:55 <ccfreak2k> Alberth, but that would make it extreme!
10:58:37 *** fonsinchen has joined #openttd
11:03:39 <frosch123> that image belongs to an impressive shop... how weird can keyboard be...
11:22:41 *** Polygon has joined #openttd
11:27:47 *** r0b0tb0y has joined #openttd
11:38:35 <Eddi|zuHause> i never understood those keyboards
11:39:01 <FauxFaux> The ones with the gap in the middle? They're amazing!
11:46:48 *** robotboy has joined #openttd
11:47:49 <PeterT> Servers with all capitals...gross.
11:49:49 <PeterT> fonsinchen: I'm about to make an updated binary.
11:50:02 <frosch123> a hooray for all ctrl-features \o/
11:50:39 <PeterT> Your shortlog says that the last time you updated was 2010-03-31 or something like that
11:51:06 <PeterT> do I still just 'git pull' as I did before?
11:52:17 *** devilsadvocate_ has quit IRC
11:52:37 *** Doorslammer has joined #openttd
11:58:28 <fonsinchen> petert, you have to pull "cd", not "cargodist"
11:58:41 <fonsinchen> I'm going to remove the cargodist branch now ...
11:59:23 <PeterT> completely, or just for now?
11:59:56 <fonsinchen> now it's gone. No more confusion
12:10:22 <PeterT> The download online content button in 1.0.1-RC2 looks much more hefty
12:40:32 *** robotboy is now known as roboboy
12:46:55 *** robotboy has joined #openttd
12:49:58 *** ajmiles has joined #openttd
12:50:31 *** Chruker has joined #openttd
13:35:38 *** Eddi|zuHause2 has joined #openttd
13:35:41 *** fonsinchen has joined #openttd
13:42:28 *** Chillosophy has joined #openttd
13:45:14 <CIA-6> OpenTTD: terkhen * r19716 /trunk/src/water_cmd.cpp: -Documentation: Add comments for lock building and removal functions.
13:45:49 *** robotboy has joined #openttd
13:47:27 <CIA-6> OpenTTD: terkhen * r19717 /trunk/src/tunnelbridge_cmd.cpp: -Fix: The cost of the first bridge type was added when building an aqueduct.
13:48:37 *** |NoobCp| has joined #openttd
13:50:27 <CIA-6> OpenTTD: terkhen * r19718 /trunk/src/water_cmd.cpp: -Fix: The cost of clearing tiles was not taken into account when building locks.
13:52:21 <CIA-6> OpenTTD: terkhen * r19719 /trunk/src/water_cmd.cpp: -Codechange: When building a lock, do not add the cost of building canals if they are already built.
13:57:02 <CIA-6> OpenTTD: terkhen * r19720 /trunk/src/ (4 files in 2 dirs): -Feature: New base costs for building/clearing canals, building/clearing aqueducts and building/clearing locks.
14:07:51 *** Eddi|zuHause2 is now known as Eddi|zuHause
14:10:28 *** devilsadvocate has joined #openttd
14:11:23 <Ammler> where does stable installer install the base data files?
14:15:35 *** Grelouk has joined #openttd
14:16:19 <devilsadvocate> Ammler, it doesnt, iirc
14:17:01 <Ammler> it does install to ~/OpenTTD/data
14:17:43 <devilsadvocate> i think it would go to $INSTALL_FOLDER/data
14:18:02 <devilsadvocate> or on linux to somewhere in /usr/share/games/openttd/data
14:18:04 <Ammler> devilsadvocate: a windows user told me that
14:18:07 <KenjiE20> probably depends on OS
14:18:18 <Ammler> devilsadvocate: there is no known installer for *nix, afaik
14:18:33 <devilsadvocate> Ammler, distro packages do that
14:18:56 <devilsadvocate> on windows, i remember putting the base files into program files/...
14:19:06 <devilsadvocate> and not users/...
14:19:29 <Ammler> devilsadvocate: I asked there the installer does put it.
14:20:23 <KenjiE20> SetOutPath "$INSTDIR\data\" <---
14:20:27 <Ammler> but anyway, if somone is installing stable with official *nix packages, he doesn't have automatically access to the basesets for nightlies
14:22:57 *** Adambean has joined #openttd
14:31:34 *** |NoobCp| has joined #openttd
14:32:06 *** Dreamxtreme has joined #openttd
14:47:07 <CIA-6> OpenTTD: terkhen * r19721 /trunk/src/table/pricebase.h: -Change: Set the new base costs to better values.
15:07:02 <Eddi|zuHause> that's because the data packages are usually separate
15:11:06 <Ammler> openttd should have some "hardcoded" paths, it looks for data
15:11:51 <Ammler> /usr/share/openttd/ should be one
15:13:16 <Eddi|zuHause> there are: --personal-dir, --shared-dir, --data-dir
15:14:17 *** Coco-Banana-Man has joined #openttd
15:15:08 <Eddi|zuHause> where --data-dir should be the binary-dependent data files (languages, etc.), --shared-dir the binary-independent data files (opengfx, etc.) and --personal-dir the user-downloaded data files (bananas etc.)
15:16:39 <Ammler> Eddi|zuHause: that isn't hardcoded...
15:17:09 <Ammler> and --shared-dir works for osx only
15:17:13 <frosch123> win users will be happy about that
15:23:07 <Ammler> frosch123: it is also possible that *nix systems don't have that path, so of course, it is just a path to look for possible data
15:23:51 <Ammler> but now, if you use official stable and install nightlies, you can't share the base sets.
15:24:36 <Ammler> windows user can, as there it installs the data to $HOME
15:25:03 <Ammler> frosch123: I am usre, you move the data sets around
15:25:57 <frosch123> no, i have original files in /usr/share, and the bananas stuff and repositories in ~/.openttd
15:26:09 <Rubidium> Ammler: who told you the installer puts data in $HOME?
15:26:19 <Ammler> someone in #openttdcoop
15:26:35 <Ammler> Rubidium: windows installer
15:27:39 <Ammler> frosch123: and you can use the base data from /usr/share on a nightly?
15:29:03 <Rubidium> Ammler: and what makes you believe that "someone" is more credible than say KenjiE20?
15:29:17 <Ammler> I made a symlink from /usr/share to /usr/local/share to have that possiblility
15:30:16 <KenjiE20> yea [15:21:40] <KenjiE20> SetOutPath "$INSTDIR\data\" <--- that line came from me digging in the installer so...
15:30:41 <Ammler> Rubidium: Well, then the problem exists not just for *nix, also for windows
15:31:39 <Eddi|zuHause> <Ammler> and --shared-dir works for osx only <-- have you actually tried this?
15:32:53 <Ammler> Eddi|zuHause: doesn't matter, the nightly don't use it
15:33:41 <Eddi|zuHause> Ammler: not by default, maybe, but you can configure it...
15:34:37 <Ammler> Eddi|zuHause: I am fine with the symlink :-)
15:35:13 <Ammler> the discussion is about general user issue, if the use nightlies
15:35:42 <Eddi|zuHause> Ammler: then maybe the discussion should be to change the default
15:36:08 <Rubidium> so Windows installers must get a query for two paths?
15:36:09 <Eddi|zuHause> nothing in the documentation (i.e. ./configure --help) indicates that shared-dir is OSX only
15:36:12 <Ammler> or just adding some additional paths to the search
15:36:31 <Rubidium> and OpenTTD already searches like 5 paths
15:36:44 <Ammler> Eddi|zuHause: but the readme does
15:37:28 <Ammler> well, at least, it did :-)
15:37:46 <Eddi|zuHause> 3. The shared directory
15:37:48 <Eddi|zuHause> Linux: not available
15:37:56 <Ammler> anyway, that doesn't matter :-P
15:38:03 <Rubidium> Eddi|zuHause: does it say it is OSX only?
15:38:13 <Ammler> if that would work, it whould still need the compile farm to use it
15:38:58 *** ajmiles has joined #openttd
15:40:25 <Rubidium> and the "shared" directory in OpenTTD's sense is the place to store the highscore data, i.e. it has to be user readable/writable
15:40:42 <Ammler> and then, there is another issue, debian distro use /usr/share/games, rpm distros use /usr/share, other distros might use something else...
15:41:03 <Eddi|zuHause> Ammler: that is not solveable by openttd
15:41:25 <Ammler> yeah, I just mean, it needs more than one path there :-)
15:41:56 <Eddi|zuHause> Rubidium: but would that not fall back to the personal directory if it's not writable?
15:42:36 <Rubidium> Eddi|zuHause: yes, but /usr/share is by definition the "wrong" place for the highscore data I'd say
15:42:54 <Eddi|zuHause> put it in /var :p
15:43:01 <Rubidium> even then, how many paths does Ammler want to add?
15:43:22 <peter1138> system global high sources? hah
15:43:23 <Eddi|zuHause> i have no idea what Ammler wants, and i'm not sure he knows himself
15:44:12 <Eddi|zuHause> well, over here, /var/games has some highscore files in it
15:44:36 <Rubidium> hmm, actually Ammler would likely like to add at least 8 and at least one of the is double
15:45:07 <Ammler> Rubidium: does that matter?
15:45:11 <Eddi|zuHause> so, suggestion: use /var/games/openttd as shared dir?
15:45:22 <Rubidium> /usr/[local/]share/[games/]openttd[-data] or so
15:45:39 <Rubidium> Ammler: if you care about the speed OpenTTD starts it does
15:45:55 <Rubidium> and the speed it handles data files in general
15:46:52 <Ammler> he, what a silly distro uses openttd-data?
15:47:18 <Eddi|zuHause> one that has an openttd-data package?
15:47:33 <Ammler> Eddi|zuHause: yes, for package name that is
15:47:45 <Ammler> but /usr/share implies already "data"
15:47:49 <Rubidium> Ammler: the ones that want to move the openttd-installation-non-specific data files, i.e. opengfx/opensfx/openmsx, out of the openttd installation directory
15:47:50 <Eddi|zuHause> it might be problematic if two packages write to the same dir
15:48:10 <Rubidium> Any variable data relating to games in /usr should be placed here. /var/games should hold the variable data previously found in /usr; static data, such as help text, level descriptions, and so on, must remain elsewhere, such as /usr/share/games.
15:48:30 <Rubidium> from FHS, so /var/games isn't useful for opengfx et al.
15:49:06 <Eddi|zuHause> yes, but for highscores, savegames et al.
15:49:52 <Rubidium> I don't have write access to create a games directory there
15:50:05 <Ammler> [17:45] <Rubidium> /usr/[local/]share/[games/]openttd[-data] or so <-- would be nice for a start.
15:50:52 <Eddi|zuHause> "/var/games" is owned by the user "games" and the group "games" here
15:52:28 <Eddi|zuHause> and group-writable
15:52:54 <Rubidium> Ammler: but doing that is "like" add / to the search paths, wheras adding / is more effective
15:53:28 <Rubidium> anyhow, I'm not that concerned that nightlies are not as easy to install than stable binaries
15:53:42 <Eddi|zuHause> yes, please also add /windows/C/<typical windows paths> :)
15:54:36 <Rubidium> and I don't want to add a load of paths just for the case where it might be useful for that single noob that "needs" to play nightlies and can't figure out symlinks
15:56:17 <Ammler> Rubidium: that is usually one or 2 additional paths
15:57:35 <Ammler> if the path doesn't exist, why does it waste starting time?
15:58:51 <jack> (in cargodist), should payment for income be registered in finances at the transfer or at the final destination?
15:59:03 <jack> bah, payment for transfers
16:00:13 <Rubidium> should as in "what do you think it should do" or should as in "does"?
16:00:39 <Rubidium> in the former case it shouldn't, in the latter I don't know
16:00:50 <jack> should as in intented functionality
16:04:06 <fonsinchen> payment behaves the same in cargodist as in trunk
16:04:21 <fonsinchen> transfers, however, are automated
16:07:37 *** JVassie has joined #openttd
16:12:18 <CIA-6> OpenTTD: rubidium * r19722 /trunk/src/console_cmds.cpp: -Fix: crash when using restart via rcon.
16:22:45 <Eddi|zuHause> means you don't set transfer in the orders, it will automatically transfer if necessary
16:22:58 <Eddi|zuHause> payment is only done at the final destination, like in trunk
16:27:44 <CIA-6> OpenTTD: rubidium * r19723 /trunk/src/ (7 files in 2 dirs):
16:27:44 <CIA-6> OpenTTD: -Add: a simple sprite alignment helper. It does not store the new offsets
16:27:44 <CIA-6> OpenTTD: anywhere so as soon as the sprite is reloaded the offsets are gone (use a bigger
16:27:44 <CIA-6> OpenTTD: sprite cache if this happens). Also anything that reloads NewGRFs (new games,
16:27:44 <CIA-6> OpenTTD: loading games or (re)applying NewGRFs) clears the sprite cache and as such
16:27:45 <CIA-6> OpenTTD: resets the offsets.
16:35:07 <jack> what about IS2 - does it (or trunk) make sure the payment is distributed to the correct companies?
16:35:07 <CIA-6> OpenTTD: rubidium * r19724 /trunk/src/tree_map.h: -Fix [FS#3792]: random tree type did not build all sub-tropic trees (Krille)
17:02:13 <Eddi|zuHause> in trunk it can only happen in rare cases, like using an oil rig for transfer
17:02:15 <jack> i think cargodest payed at the moment of transfer
17:02:26 <Eddi|zuHause> you think wrong then
17:05:23 <jack> stored the shares in the cargopackets
17:26:25 <Eddi|zuHause> (PS: apparently the "OSX Store" story is "not true")
17:28:45 <jack> is "days_in_transit" in CargoPacket days since it was loaded at source or at "loaded_at_xy" (last loaded)?
17:30:03 <Eddi|zuHause> i'm sure that is documented somewhere, likely in the header
17:33:37 <jack> doesn't say more than the name. it's used both for calculating total income and feeder shares...
17:36:49 <fonsinchen> it's the days it has spent in vehicles.
17:37:21 <fonsinchen> While the packet is waiting at stations the value isn't updated, only while travelling in vehicles.
17:40:00 <Eddi|zuHause> i vaguely remember that it's not real days either
17:43:27 *** Progman has joined #openttd
17:45:55 <CIA-6> OpenTTD: translators * r19725 /trunk/src/lang/ (9 files): (log message trimmed)
17:45:55 <CIA-6> OpenTTD: -Update from WebTranslator v3.0:
17:45:55 <CIA-6> OpenTTD: catalan - 4 changes by arnau
17:45:55 <CIA-6> OpenTTD: finnish - 23 changes by jpx_
17:45:55 <CIA-6> OpenTTD: french - 4 changes by glx
17:45:57 <CIA-6> OpenTTD: lithuanian - 11 changes by BlinK_
17:45:57 <CIA-6> OpenTTD: polish - 3 changes by silver_777
17:46:13 *** lasershock has joined #openttd
17:50:21 *** theholyduck has joined #openttd
18:29:58 *** Biolunar has joined #openttd
18:54:17 <andythenorth> so did Terkhen fix canal building costs?
18:55:03 <andythenorth> my svn is screwed for some reason
18:55:48 <andythenorth> nor can I relocate the repo remote url. Or I'm doing it wrong
18:56:20 <andythenorth> pdq2s-macbook-3:trunk andy$ svn up
18:56:20 <andythenorth> svn: Can't connect to host 'svn.openttd.com': No route to host
18:56:26 <andythenorth> svn: Can't connect to host 'svn.openttd.com': No route to host
18:56:39 <andythenorth> I have RTFMed in several places
18:57:23 <Alberth> what does svn info say?
18:57:33 <frosch123> Alberth: add "--relocate" to the switch command
18:58:43 <andythenorth> svn: Relocate can only change the repository part of an URL
18:58:50 <DorpsGek> Muxy: ammler was last seen in #openttd 3 hours and 53 seconds ago: <Ammler> or "how?"
18:59:20 <Alberth> add a / after the host?
19:01:24 <Alberth> svn according to the wiki
19:01:40 <Terkhen> I always use svn://svn...
19:01:54 <Alberth> what is the current repo root? (svn info)
19:02:17 <andythenorth> Repository Root: svn://svn.openttd.com
19:02:38 <frosch123> so try "svn switch --relocate svn://svn.openttd.com svn://svn.openttd.org"
19:03:09 <andythenorth> svn: Can't connect to host 'svn.openttd.org': No route to host
19:03:19 <andythenorth> ^ result of command from frosch123
19:03:38 * andythenorth could checkout again, but seems like a waste of bandwidth
19:03:55 <Alberth> svn ls svn://svn.openttd.org/trunk does this work ?
19:04:55 <Alberth> andythenorth: I'd expect a /trunk after the host at the root.
19:05:20 <Ammler> Muxy: empty highlight?
19:05:33 <Muxy> ah Ammler, i have to show you something
19:05:55 <Ammler> I am looking forward :-P
19:05:56 <andythenorth> Alberth: svn ls svn://svn.openttd.org/trunk fails
19:06:09 *** Lorenzo has joined #openttd
19:06:46 <andythenorth> pdq2s-macbook-3:trunk andy$ svn ls svn://svn.openttd.org/trunk
19:06:46 <andythenorth> svn: Can't connect to host 'svn.openttd.org': No route to host
19:06:47 <frosch123> Ammler: who types "list" ?
19:06:52 <Lorenzo> can someone tell me how to access the sprite aligner tool?
19:07:16 <frosch123> Lorenzo: did you already enable the newgrf developer tools?
19:07:36 <Ammler> frosch123: just an idea :-)
19:07:42 <Lorenzo> I think so... set the newgrf_developer_tool to true in cfg file
19:07:55 <Lorenzo> I can already inspect objects
19:08:33 <frosch123> iirc it is under the land info dropdown
19:08:47 <andythenorth> any reason I shouldn't just do a hg checkout
19:08:52 <planetmaker> Once one knows the sprite ID :-)
19:08:58 <planetmaker> andythenorth: none
19:09:13 <Alberth> andythenorth: I'd recommend it :)
19:09:27 * planetmaker only uses hg unless absolutely required otherwise
19:09:36 <planetmaker> andythenorth: should work iirc
19:09:44 <Lorenzo> that menu contain only the 7 usual options
19:09:56 <Terkhen> Lorenzo: do you have latest nightly?
19:10:03 <planetmaker> Lorenzo: rcon set newgrf_developer_tools 1
19:10:13 <Lorenzo> r19711, just downloaded it
19:10:27 <planetmaker> is the sprite aligner already in the nightly?
19:10:28 <frosch123> that is from yesterday
19:10:42 * andythenorth is slapped down by a 404
19:10:43 <planetmaker> r19723 or better is required
19:11:41 <andythenorth> newgrf debug + new canal costs on their way to me
19:12:12 <Alberth> and I'd recommend to make local copies of that repo to mess up
19:13:01 <Alberth> ie locally clone another working copy before using it
19:13:05 <Lorenzo> let me check version again :)
19:14:34 <Lorenzo> aaaalright, now I see the option
19:14:56 <Lorenzo> 10x for the help guys
19:21:51 <__ln__> what's "i'm in" in german? ... like in "we are going to buy a present to X" - "i'm in"
19:24:03 * planetmaker ponders how to properly translate 'parent scope'
19:24:48 <planetmaker> that abbreviation doesn't work in German ;-)
19:25:30 <frosch123> planetmaker: something "übergeordnet"
19:25:42 <planetmaker> frosch123: good idea. Thx
19:26:06 <__ln__> planetmaker: maybe not, but at least it's not violating a trademark of lucasfilm ltd. :)
19:34:40 *** Biolunar_ has joined #openttd
19:36:42 <andythenorth> hg changeset numbers != svn revisions :P
19:36:50 <andythenorth> for reporting purposes
19:37:45 <Alberth> hg log has a svn number
19:38:46 <Alberth> and the findversion.sh script has a complicated command to pull that number from the log :)
19:39:21 <Alberth> andythenorth: the good news is that you can do version control over your own changes
19:39:50 <planetmaker> and better merges / easier updates of mods
19:41:03 <andythenorth> oh my word, I've just found the 'change values' part of Rubidium's newgrf debug :o
19:41:35 <planetmaker> all these dev tools... they need proper documentation
19:41:39 <planetmaker> People will need them
19:42:02 <andythenorth> I am just editing the thread in dev forum that I started
19:42:08 <andythenorth> as a starting point for that
19:42:14 <andythenorth> but the wiki would obviously be better
19:42:35 <frosch123> hmm, now there is a "grfmaker" in the "grf2html" url :p
19:43:50 <planetmaker> andythenorth: yeah, wiki would be quite more appropriate
19:44:22 * andythenorth is still figuring out how to use the tools in depth
19:44:58 <planetmaker> hm... any way to get the sprite number(s) of the sprites on a certain tile?
19:48:27 <planetmaker> andythenorth: in console set newgrf_developer_tools 1 works also
19:48:34 <planetmaker> so no need to edit any cfg
19:49:40 <andythenorth> yep just done that thanks :)
19:51:07 * andythenorth thinks the sprite aligner could use a 'reset' option
19:51:13 <andythenorth> as I've just ballsed up the cursor :)
19:51:25 <frosch123> reload_newgrfs will do
19:51:29 <planetmaker> andythenorth: it has. Just re-apply ... ^
19:51:34 <frosch123> though it resets everything
19:52:28 <andythenorth> so the only thing I can't see is how to find a sprite number easily
19:52:29 <planetmaker> the good thing is: it also works for base grfs.
19:52:32 <nighthawkcm> I pray for the NFO programming language :-) All those hex numbers make me dizzy :-P
19:52:52 <planetmaker> the bad thing: reload_newgrfs doesn't work for them (dunno if it resets those ofsets, though)
19:53:22 <andythenorth> the aligner is fricking awesome
19:53:46 <planetmaker> hm... once I have toyland and maglev trains aligned... then I might add the {VERSION} tag to NML... hm
19:54:13 <andythenorth> no more, tweak, save, switch to terminal, compile, switch to openttd, reload newgrfs :D
19:54:36 <__ln__> what's 'before' in german in "we should know thing Y before we can do anything"?
19:54:58 <asilv> in ttdp sprite aligner the sprite number is same as nfo sprite number, would it be possible to do same for ottd?
19:55:30 <__ln__> ach, that's so logisch
19:55:41 <planetmaker> asilv: might even be true. Did you check?
19:55:43 <frosch123> asilv: maybe, but is that acually useful? as pm says, you rather want to align what you just see
19:55:46 <peter1138> 9nfo sprite number is not stored, so no, not really
19:56:20 <andythenorth> I don't know the sprite number in any of my projects, it just adds another bunch of clicks if I have to go look those up :o
19:56:31 <asilv> well, it sounds most natural to me, but maybe thats because i'm used toit
19:56:33 <planetmaker> but then... in my source the sprite number is still mentioned, but the sprite representation is more useful :-)
19:57:16 <frosch123> planetmaker: do you have a spritenumber in you pnfo?
19:57:43 <planetmaker> OpenGFX still has them in the comments for orientation
19:57:49 <frosch123> so spritenumber would be useles, or not?
19:57:53 <peter1138> the nfo sprite number IS stored
19:57:57 <peter1138> so yes, it is possible
19:58:04 <planetmaker> like // 2384 - 2388: Millenium falcon
19:58:18 <peter1138> but doesn't everyone just use -1 these days?
19:58:20 * andythenorth is disappointed that 2384 is actually a tunner
19:58:43 <planetmaker> frosch123: well... one can compile and look in the NFO, but... clicking on a tile to get the sprite numbers would be more useful
19:58:49 <frosch123> peter1138: where is it stored?
19:58:56 <peter1138> frosch123, in the sprite cache
19:58:56 <planetmaker> andythenorth: the sprites use that, too in the source
19:59:08 <peter1138> spritecache.cpp:293
19:59:14 <planetmaker> And only for base grf the sprite number matters really. For a newgrf I wouldn't care
19:59:55 <peter1138> file_sprite_id is passed as nfo_line for newgrf
20:00:39 <peter1138> i don't know why, i don't know what it's used for, but it wastes 4 bytes ;)
20:01:17 <frosch123> oh, if it is that easy, add it to the caption next to the filename :)
20:01:21 <planetmaker> newgrf debug messages?
20:03:32 <frosch123> hmm, a spritepicker tool: press a button in the aligner, click somewhere on the screen, redraw the screen, and check the spritebounds with the clickposition, then display a list of all sprites intersecting...
20:06:02 <planetmaker> hm... general question: are there more buttons / sprites planned in this process?
20:06:38 <planetmaker> I'm thinking of a new OpenGFX version once the trains are done
20:06:48 <planetmaker> Current alignment is crappy enough that it's worth it
20:07:00 <frosch123> is there any new button than the debug button which you already have?
20:09:14 <planetmaker> we have the debug button already in the current release
20:10:31 <frosch123> i doubt there is a need for more button sprites. everything else can use textbuttons
20:10:37 <planetmaker> but if there's the idea to actually add further ones... might be a good idea to think about it :-)
20:10:52 <planetmaker> yeah, probably :-)
20:22:54 <andythenorth> sprite picker would be awesome, but how would it deal with the layering / sorter?
20:23:00 <andythenorth> you get the sprite that the pixel you clicked on belongs to?
20:26:03 <planetmaker> andythenorth: you'd need to get a list of sprites
20:26:44 <planetmaker> even for a level crossing you might want to get 3: ground, track + traffic light
20:26:59 <planetmaker> even worse in a town with buildings and vehicles
20:27:16 <peter1138> er, you got 6 actually
20:27:18 <planetmaker> ground, vehicle, building 1 and building 2
20:27:26 <peter1138> with railtypes, anyway
20:27:27 <planetmaker> peter1138: for a single pixel?
20:27:36 <planetmaker> for a tile there are more, yes
20:27:49 <Sacro> can we finally rename 'Forbid trains and ships to make 90 deg turns'
20:28:00 <Sacro> it's not only bad English but 'deg' isn't a word
20:28:10 <peter1138> we never change it just because it annoys you
20:28:25 <Sacro> it's teaching the foreigners that that kind of sentence is valid
20:28:41 <andythenorth> so we can't just trust the pixel that was clicked on belongs to the sprite we want?
20:28:43 <planetmaker> Sacro: make a patch
20:29:03 <planetmaker> andythenorth: we can't. But we would then see when we see it in the sprite aligner
20:29:14 <planetmaker> if not, we jus try again...
20:29:33 <andythenorth> I think 'click try again' is better than a list
20:29:43 <planetmaker> andythenorth: not if sprites overlap
20:29:48 <planetmaker> you'll need a list
20:29:52 <__ln__> yes, replace 'deg' with e.g. 'bacon'.-
20:29:54 <andythenorth> so click on a different pixel
20:30:02 <andythenorth> if no pixels are showing, why bother aligning the sprite?
20:30:16 <planetmaker> maybe it should show?
20:30:16 * andythenorth occasionally clicks on pixels, just for recreational purposes
20:30:45 <planetmaker> also: it's interesting to see which sprites make the position
20:30:54 *** TheMask96 has joined #openttd
20:31:02 <planetmaker> you might then actually want to align another sprite than you initially thought you need to align
20:31:22 <andythenorth> I just wonder if catering for the edge case makes the standard behaviour worse (I don't think I want a list). Maybe I would if I tried it.
20:31:22 <planetmaker> especially with industries I think that might be true :-P Animated industries that is.
20:31:46 * andythenorth finds his sprites after guessing in 1k increments
20:33:33 *** PeterT_ has joined #openttd
20:33:37 *** Devroush has joined #openttd
20:34:13 <planetmaker> maybe you're right that it's usually too much hassle to get a list...
20:34:28 *** rhaeder has joined #openttd
20:35:35 <andythenorth> the list would contain sprites numbers? Or would it render the actual sprites?
20:35:40 <andythenorth> one is barely useful :)
20:35:45 <Rubidium> planetmaker: I hoped that andythenorth would write the documentation :)
20:36:07 <andythenorth> Rubidium: I think I should
20:36:18 <planetmaker> yes. It's "your" feature ;-)
20:36:27 <andythenorth> writing != wiki formatting though
20:36:33 <andythenorth> I fricking hate wiki formatting
20:37:02 <planetmaker> you could still just write it in the wiki
20:37:31 <Rubidium> andythenorth: then let planetmaker do the wiki formatting! :)
20:37:33 <CIA-6> OpenTTD: peter1138 * r19726 /trunk/src/lang/english.txt: -Fix [FS#Sacro]: Broken English.
20:38:05 <frosch123> [22:35] <andythenorth> the list would contain sprites numbers? Or would it render the actual sprites? <- i thought about a list inside the aligner window, so you can sequetially align them all
20:38:28 <andythenorth> could be big, space wise?
20:38:58 <frosch123> big? a column with spritenumbers and a scrollbar?
20:39:14 <planetmaker> andythenorth: that's a deal: you write, I do the formating of the article ;-)
20:39:23 <andythenorth> Interesting. ISR replaces the dock sprites, but there's no debug icon.
20:39:26 <frosch123> and i doubt there are lots of sprites in one place, or you could not see what you are aligning anyway
20:39:42 <Rubidium> andythenorth: action A
20:39:44 <planetmaker> andythenorth: that's a simple actionA replacement. Nothing to debug...
20:40:13 <andythenorth> any other likely instances of that? I've never used action A
20:40:30 <planetmaker> andythenorth: depends where and what. ActionA is quite useful
20:40:42 <planetmaker> OpenGFX uses it by default to distinguish climates
20:40:56 <planetmaker> Other newgrf - like TTRS - might replace banks or so
20:41:03 <andythenorth> roadsets use action A?
20:41:09 <planetmaker> or light houses or transmitters or road sets, yes
20:41:12 *** PeterT_ has joined #openttd
20:41:21 <planetmaker> old track sets as well. Mars conversion
20:42:00 <andythenorth> CanSet train depots show debug icon, US Road Set tram depots do not.
20:42:12 <andythenorth> Just figuring out the limits of this
20:42:22 <planetmaker> canset uses rail types surely.
20:42:27 <planetmaker> us road set probably not
20:42:39 <Rubidium> tram -> roadtypes... oh bollocks, that's not implemented yet
20:45:21 <Rubidium> anyhow, supported are: vehicles, stations, railtypes, industries, industry types, houses, airport tiles (quite untested) and (via parent) towns
20:46:04 <planetmaker> he :-) I didn't give reasons why c&p it was rejected. I assumed the person could read. Wrongly obviously.
20:46:50 <Rubidium> planetmaker: just don't call it "rejected"
20:47:04 <planetmaker> bad wording probably... yeah
20:48:35 *** Kurimus has joined #openttd
20:50:39 * andythenorth decisions decisions decisions: write documentation for newgrf debug tools, or use them to go on a rampage of newgrf authoring :P
20:50:40 <frosch123> hmm, the list contains the mousesprite :p
20:51:54 <planetmaker> andythenorth: documentation ;-)
20:52:09 <planetmaker> or it'll never get done :-P
20:52:45 <Rubidium> don't forget the parts I wrote in the commit message of the sprite aligner thingy
20:55:02 <andythenorth> documentation it is then
20:56:55 <CIA-6> OpenTTD: terkhen * r19727 /trunk/src/tunnelbridge_cmd.cpp: -Fix (r19720) [FS#3795]: Demolishing bridges or aqueducts caused a crash.
20:59:16 <Rubidium> yes, the part about the data not being stored anywhere except in the spritecache
21:00:28 <andythenorth> I'm going to save this irc transcript as an aide to documentation....any thing else I should know?
21:07:16 <CIA-6> OpenTTD: terkhen * r19728 /trunk/bin/ai/regression/regression.txt: -Fix (r19720, r19721): Update regression test due to different costs.
21:17:48 *** andythenorth has left #openttd
21:38:56 <Eoin> anyone remember a certain UK Bus Set?
21:43:41 *** Nite_Owl has joined #openttd
22:13:36 *** Coco-Banana-Man has quit IRC
22:21:51 *** fonsinchen has joined #openttd
22:37:21 *** Cybertinus has joined #openttd
22:49:04 *** ChanServ sets mode: +v tokai
continue to next day ⏵
