IRC logs for #openttd on OFTC at 2010-09-06
⏴ go to previous day
00:34:18 *** JVassie_ has joined #openttd
01:16:18 *** [hta]specx has joined #openttd
01:18:17 *** ChanServ sets mode: +v tokai
01:28:23 *** wollollo has joined #openttd
01:36:07 *** glevans2 has joined #openttd
01:36:41 *** r0b0tb0y has joined #openttd
02:36:43 *** robotboy has joined #openttd
03:36:49 *** r0b0tb0y has joined #openttd
03:52:29 *** HerzogDeXtEr1 has joined #openttd
04:36:57 *** robotboy has joined #openttd
04:59:00 *** Eddi|zuHause has joined #openttd
05:01:51 *** robotboy has joined #openttd
06:01:21 *** r0b0tb0y has joined #openttd
06:33:31 *** Cybertinus has joined #openttd
06:37:56 *** ^Spike^ has joined #openttd
06:55:28 *** Kurimus has joined #openttd
07:31:40 <Rubidium> gooood morningk Terkhen :)
07:32:18 *** JVassie_ has joined #openttd
07:32:41 *** snorre_ is now known as snorre
07:39:53 <Terkhen> should I translate the name of the GRF?
07:40:13 *** Progman has joined #openttd
07:42:04 <planetmaker> I did it for the German translation.
07:42:17 <planetmaker> Even though I'm not entirely sure that translating the name is a good thing
07:42:24 *** robotboy has joined #openttd
07:43:00 <planetmaker> What would your view on that be?
07:43:46 <Terkhen> I'd go with Original name (Translated name), so you can search/filter both
07:45:00 *** TomyLobo has joined #openttd
07:47:22 <planetmaker> That's what I did with the Snowline... so I should do that here do, I guess. Maybe you can adopt the name string accordingly? The English cannot have that or it would look funny ;-)
07:58:19 *** Biolunar has joined #openttd
08:17:52 <planetmaker> thanks, Terkhen :-)
08:30:04 * Rubidium ponders just closing all bug reports that claim to be of an "unknown" version, i.e. "version?"
08:31:31 <planetmaker> you should allow to change that later then ;-)
08:32:09 <Eddi|zuHause> "Judge rules police raid as illegal." - "Judge rules, compensation can only be paid for legal raids." ... law is obscure at best...
08:32:39 <planetmaker> though... the crash log has the info always, Rubidium :-)
08:34:23 <peter1138> Eddi|zuHause, no it's not
08:34:47 <peter1138> First is about a specific case, second is general.
08:35:44 <Rubidium> planetmaker: still in the bug list it shows up with version "version?" instead of "trunk"
08:36:54 <planetmaker> it also applies to stable / testing
08:37:15 <planetmaker> when I can trust other people report similar things in the FIRS thread
08:37:36 <planetmaker> which unfortunately did not report crashes where they belong
08:37:40 <Eddi|zuHause> peter1138: both rulings are about the same raid
08:39:04 <peter1138> Ah well, still makes sense to me
08:39:09 <Rubidium> planetmaker: do I understand it correctly that it happens after saving and reloading only? So not when you start a new game with the exact same NewGRFs?
08:39:51 <peter1138> What's the compensation for, heh
08:39:56 <planetmaker> Rubidium: exactly
08:39:58 <peter1138> Who's compensating what
08:40:36 <Rubidium> planetmaker: and he's using actionD stuff to determine whether the NewGRF can be loaded or not?
08:40:44 <Rubidium> smells a lot like: "Note that parameters are never reset after the game has started, therefore you must not modify newgrf(w).cfg parameters with any kind of irreversible operation. It is valid to, for example, add a value to a parameter only if the same value is later subtracted, to keep the parameter the same across loading or starting several games.
08:41:33 <Eddi|zuHause> peter1138: a german left-autonomist was raided for "being member of a terrorist organisation", police confiscated three cellphones, one of which was required for work, the person then needed to buy a new cellphone, and requested to be reimbursed for the replacement costs
08:41:40 <planetmaker> I'm not sure I follow you here quite... but yes, actionD is used to find out whether FIRS should load or not
08:41:48 <Rubidium> in which case the NewGRF parameters are changed, which isn't quite supported by OpenTTD, it's not logged though
08:42:11 *** Br33z4hSlut5 has joined #openttd
08:42:49 <planetmaker> But indeed... if I may not modify a parameter it might be exactly that case indeed
08:43:03 <Eddi|zuHause> the claim was reduced to "being member of a criminal organisation", and cancelled completely, as investigation progressed...
08:43:17 <planetmaker> though, of course I started both w/o parameter. But there are internal ones, of course...
08:46:33 *** |Jeroen| has joined #openttd
08:48:44 <planetmaker> I don't really see another way to do that...
08:49:39 <Rubidium> it's just the only thought I had with the bug report; I don't have the time to actually look into it
08:50:17 <planetmaker> One could probably do w/o the parameter involved. But it's a parameter set to the presence of the grf.
08:52:19 *** thvdburgt has joined #openttd
09:11:26 *** Chillosophy has joined #openttd
09:27:05 <Ammler> [09:43] <Terkhen> I'd go with Original name (Translated name), so you can search/filter both <-- you should be able to filter both also without the English precense
09:28:21 <Eddi|zuHause> the filter string should simply be checking both languages
09:28:29 <Ammler> hmm, at least it worked that way with the town names
09:28:41 <Eddi|zuHause> no need for having two names in one
09:29:30 <Ammler> hmm, maybe a new var for the a14: tags like on bananas :-)
09:30:57 <Eddi|zuHause> the bananas .tar should also contain the infos (tags, description, etc.) in a machine-readable format, and openttd should be able to display them
09:35:15 <Ammler> the bananas description is in the readme
09:35:58 <Ammler> rather bananas should be able to read a14
09:36:24 <planetmaker> tags.txt included and read :-)
09:36:32 <Eddi|zuHause> Ammler: but openttd is not capable of displaying the readme
09:36:53 <Eddi|zuHause> planetmaker: unlikely to be...
09:37:08 <planetmaker> Not sure. A simple text display with scrollbar.
09:37:16 <Ammler> the bananas description is not needed ingame, imo
09:37:17 <planetmaker> For a plain text file? That should be feasible
09:37:21 <Eddi|zuHause> planetmaker: what if the readme is a .doc?
09:37:32 <Ammler> the needed part is in the grf desc
09:37:34 <planetmaker> Eddi|zuHause, then it's not according to the specs and not displayed
09:37:54 <Eddi|zuHause> planetmaker: there is no specs for readme format.
09:38:23 <Ammler> not sure, if a "ingame readme" is still needed since with a14
09:38:43 <Ammler> the readme was mainly to explain the parameters
09:38:51 <planetmaker> Eddi|zuHause, yes. But if one wants OpenTTD to display a readme, it's perfectly ok to say "provide it as plain txt file"
09:39:56 <planetmaker> it's not like a readme display-routine would need to be capable of reading all formats. A man page also requires a very specific file format
09:40:05 <planetmaker> For newgrf readmes it could be plain txt files
09:40:14 <Eddi|zuHause> Ammler: parameters are only a small part of a readme
09:40:33 <Ammler> Eddi|zuHause: what else?
09:40:52 <Ammler> (which can't be in the grf desc)
09:42:06 <Eddi|zuHause> e.g. the dbset readme contains information about the available vehicles, a link to the description of the original vehicle it is based on [defunct, since the disappearance of HIS website], stats for each vehicles, colour schemes used, special information on constructing "realistic" trains, some example configurations how they behave on slopes with realistic acceleration...
09:42:36 <Ammler> and that is needed to play with dbset?
09:43:15 <Ammler> I didn't say, remove the docs, I just don't think it is needed to read ingame :-)
09:43:39 <planetmaker> Ammler, the point of a readme is not only parameter description. Additional information on updates, contents, purpose, ways-to-best-use, etc are part of it
09:43:41 <Eddi|zuHause> oh, and the license is in the readme ;)
09:43:53 <Ammler> that is the last part needed ingame :-P
09:44:08 <planetmaker> Eddi|zuHause, e.g. that is already one thing which is required by bananas: a separate license.txt in plain text format
09:44:19 <planetmaker> currently readme is accepted as readme.txt or readme.pdf
09:44:19 <Ammler> a oneliner wich license is fine enough
09:44:39 <planetmaker> the pdf could be accepted with the limitation that it will not be displayed.
09:45:10 <planetmaker> I think even you or I could in principle write the window which displays a plain text file :-)
09:45:25 <planetmaker> And it would be a step forward in user-friendlyness
09:45:32 <planetmaker> currently most users have no clue about readmes
09:45:51 <planetmaker> as they're not exposed to them in any way
09:52:50 *** Adambean has joined #openttd
10:05:54 *** thvdburgt has joined #openttd
10:16:13 *** |Jeroen| has joined #openttd
10:47:27 *** KenjiE20 has joined #openttd
11:10:56 *** robotboy has joined #openttd
11:21:38 <maddy> can me say anyone where i can set a welcom massage on a dedicatet server OR were i can set a message that respawn every time
11:22:47 <Ammler> maddy: scripts (wiki) or Autopilot
11:24:21 * dihedral should get rid of that highlight :-P
11:25:06 *** [com]buster has joined #openttd
11:25:24 <Ammler> did you see the security bug with custom commands?
11:32:28 <maddy> ammler ? where do I must to copy the scripts? i use a linux dedicatet server and i dont find a directory
11:33:25 <planetmaker> maddy, there where the default scripts are
11:33:29 <planetmaker> it comes with openttd
11:33:35 <dihedral> oh - those scripts :-P
11:33:47 <dihedral> probably in a directory next to your openttd.cfg
11:34:25 <Ammler> maybe called "scripts"
11:34:44 <Ammler> no, can't be, too obvious :-)
11:44:00 *** fonsinchen has joined #openttd
11:59:15 *** [alt]buster has joined #openttd
11:59:32 *** [alt]buster is now known as [com]buster
12:10:58 *** r0b0tb0y has joined #openttd
12:21:35 *** [com]buster has joined #openttd
12:33:08 *** Chruker has joined #openttd
12:37:12 *** TheMask96 has joined #openttd
12:52:44 <fonsinchen> At the moment half of Cargo{List|Packet} is documented in cargopacket.h and the other half in cargopacket.cpp. There is no apparent pattern of what is documented where.
12:52:55 <fonsinchen> Can we agree on some rule here?
12:53:30 <fonsinchen> I'd like "document everything in the header file."
12:56:59 <fonsinchen> The coding style has a section about where documentation goes, but obviously we don't follow it.
12:57:46 <planetmaker> Supply a patch :-)
12:58:20 <fonsinchen> I'd like to agree on a common style before changing everything and then being told that this was the wrong way.
12:58:28 <Rubidium> I'd say: whenever the function is implemented in .cpp, document it there. If it's implemented in the .h, then document it there
12:58:59 <Rubidium> (for the sake of compilation speed)
12:59:58 <fonsinchen> OK. So I'll document everything I change for cargodist in this way.
13:07:57 *** Devroush has joined #openttd
13:11:05 *** robotboy has joined #openttd
13:13:25 *** [alt]buster has joined #openttd
13:13:29 <ccfreak2k> fonsinchen, Doxygen is supposed to solve that.
13:13:32 *** [alt]buster is now known as [com]buster
13:14:53 *** Progman has joined #openttd
13:16:07 * Rubidium wonders what switch needs to be set for doxygen to solve that issue
13:16:15 *** fjb is now known as Guest776
13:20:42 <fonsinchen> doxygen may solve that in its output. However, I usually don't use that output. I use my IDE for navigation and read the comments in the code.
13:21:02 <fonsinchen> So, it's nice to know where the documentation is in the code - at least for me.
13:27:29 <Eddi|zuHause> "at the implementation" might be better, as that's the area you usually spend more time...
13:27:58 <Eddi|zuHause> but using an IDE might make it easy to jump between implementation and declaration...
13:36:27 *** [com]buster has joined #openttd
13:51:40 <fonsinchen> Yes, I know that code quote well by now and I have found everything. But I know you're all very picky about coding style, so I'm trying to follow it. Understanding the reason for certain decisions helps with that.
13:58:13 *** [com]buster has joined #openttd
13:59:26 *** michi_cc has joined #openttd
13:59:26 *** ChanServ sets mode: +v michi_cc
14:11:12 *** r0b0tb0y has joined #openttd
14:14:34 <CIA-2> OpenTTD: smatz * r20753 /trunk/src/ (11 files): -Feature [FS#3999]: make it possible to select vehicle to clone and vehicle to clone orders from directly from vehicle lists and depot window
14:16:28 <Eddi|zuHause> yay! i occasionally missed that ;)
14:20:11 <Ammler> if I run "make mrproper && hg purge && hg up null", the workdir should be empty?
14:21:14 * SmatZ puts Ammler in the ignore list
14:21:17 *** [alt]buster has joined #openttd
14:21:39 <Ammler> oh, can someone forward my smily to him?
14:21:55 *** [alt]buster is now known as [com]buster
14:23:04 * SmatZ removes Ammler from the ignore list :)
14:23:48 <planetmaker> Maybe rather ask for ignoring your last comment only?
14:38:36 <Rubidium> statistics question: got a number of measurements that if plotted seem to show a power curve (it looks like x^2). What (open source) tool can I use to determine the formula of the best fitting curve?
14:43:50 *** [alt]buster has joined #openttd
14:43:53 *** [alt]buster is now known as [com]buster
14:48:04 <planetmaker> there's also a free implementation of IDL. That will also do the trick
15:01:27 <Rubidium> planetmaker: thanks, that looks promising :)
15:06:19 <Rubidium> now I need to find a way to teach it to look at the data relatively instead of absolutely; on a value of 150m deviating more than 3k is fine, but deviating 30k on a value of 300k isn't that good
15:07:07 <Rubidium> basically reducing the squared error in my case isn't such a good strategy
15:07:30 <TrueBrain> Rubidium: matlab or maple, but not open source :p
15:08:23 <planetmaker> Rubidium, a measure for that is the chi square goodness of fit
15:09:35 <planetmaker> you can also get the 1-sigma for the fit parameters IIRC
15:09:57 <planetmaker> where you can then easily determine the relative uncertainty by a/sigma(a)
15:11:46 <planetmaker> or you can argue with 1/n * \sum (y-yi)^2
15:12:13 <planetmaker> where yi is the fitted y value and y the measured
15:13:11 <planetmaker> where you can then easily determine the relative uncertainty by a/sigma(a) <-- sigma(a)/a of course ;-)
15:14:26 <planetmaker> Rubidium, why is reducing the squared error no good idea?
15:15:16 <planetmaker> because... it then needs more information of what you try to actually do ;-)
15:15:35 *** roboboy has joined #openttd
15:15:36 <planetmaker> of what type and quality the data are and what you try to (dis)prove with them
15:15:39 <Rubidium> planetmaker: because it favours a 0.0000001% deviation at my 1m "point" and a 10+% deviation at my 3k point
15:16:06 <planetmaker> Rubidium, then the solution is to fit the logarithmic data with a straight line
15:16:22 <planetmaker> the slope will give you the power law easy enough
15:16:35 <planetmaker> and the error of the large value is not of that big importance
15:17:30 <planetmaker> that said my IDL gives me the option to define the weight of the single data points... Not sure whether GnuPlot allows to do that, too
15:21:03 <Rubidium> (well, one of many sets of points)
15:23:29 <CIA-2> OpenTTD: yexo * r20754 /trunk/src/industry_cmd.cpp: -Fix [FS#4112]: assert when an industry previously build on water was flooded because it's grf changed/is missing
15:25:40 *** [alt]buster has joined #openttd
15:25:43 *** [alt]buster is now known as [com]buster
15:31:03 <tneo> planetmaker, can I delete/ clean a game log ?
15:31:11 <planetmaker> tneo, of course not
15:31:27 <planetmaker> it's the history of all changes ever made to a map
15:31:45 <planetmaker> even if you hacked it clean, it would not change it / make it better
15:32:02 <tneo> so you say I need to recreate it from scratch?
15:33:07 <planetmaker> Rubidium, I do get in your case lg y = (1.17 +- 0.035) + (3.06 +- 0.38) lg x
15:33:16 <planetmaker> with a chisq of 0.16
15:33:25 <planetmaker> which is kinda ok. But I don't like the residuals
15:33:42 <planetmaker> they show a clear pattern from + to - to +
15:33:52 <planetmaker> That'd need looking for meta-statistics with your other data
15:34:26 <planetmaker> or maybe monte-carlo simulation whether those residuals can be explained by random errors (if you know the intrinsic errors)
15:34:47 <planetmaker> tneo, yes. That's what I propose
15:35:12 <planetmaker> Use a stable version 1.0.3 for that without patches. Add the newgrfs prior to creation. And that should be it
15:35:39 <planetmaker> Maybe some landscape editing in the scenario editor, if you chose to go the SE path.
15:35:48 <Rubidium> planetmaker: it's basically it's "<# of items> inserted into collection takes <nanoseconds>"
15:36:40 <planetmaker> Rubidium, so there's much more data and what you pasted only a small sub-set of the same measurement? Or you want to compare several of these short measurement series?
15:37:41 <Rubidium> currently there's no more data
15:38:33 <planetmaker> well. The question then for further data is: will it expand the statistics (same measurement method?) or will you compare different algorithms / measurements
15:38:43 <Rubidium> and it's definitely possible to get more data points, but... that takes a lot of time
15:39:02 <Rubidium> it'll be to compare algorithms
15:39:26 <Rubidium> and those numbers are from a microbenchmarking
15:39:30 <planetmaker> ok, I guess it should be enough data points
15:39:45 <planetmaker> But significance depends upon the data points ;-)
15:40:02 <planetmaker> How reliably is a single data point repeated?
15:40:19 <Rubidium> they're the average of 1000 runs
15:41:05 <Rubidium> from where I remove the top and bottom 5%, which leaves me with a standard deviation < 0.05
15:41:08 <planetmaker> with the fit I get it's rather a 3rd power
15:41:38 <planetmaker> ok, so they're reliable
15:42:19 <Rubidium> (before removing the top/bottom 5% its standard deviation <= 0.13
15:43:01 <Rubidium> and the larger the numbers, the smaller the standard deviation
15:43:18 <Rubidium> so that would imply standard deviation has to do with scheduling stuff
15:44:34 <Rubidium> oh, I've not been completely honest: the two largest number are the average of 100 runs
15:44:39 <planetmaker> can you give the error / stddev for the single points, too?
15:45:11 <planetmaker> I'd like to see whether / what difference it makes
15:45:18 <Rubidium> 0.02 0.06 0.03 0.04 0.00 0.04
15:46:48 <planetmaker> there's one missing ;-)
15:47:24 <CIA-2> OpenTTD: smatz * r20755 /trunk/src/fios.h: -Fix (r19975): small memory leak at program exit (happens only once)
15:47:25 *** [com]buster has joined #openttd
15:49:39 <planetmaker> and... of course I mixed up slope and offset in what I gave above ;-)
15:54:01 <planetmaker> looks ugly when I give those errors for a logarithmic fit ;-)
15:59:08 <planetmaker> any case, from those data you gave, I'd guess on a functional relation in the form of either lg y = A + B sqrt( lg (x + C)) or lg y = A + B lg ( C lg (x + D))
15:59:20 <planetmaker> But it might not be significant
16:02:39 <Rubidium> those formulae are a bit more complex than what I hoped for
16:02:51 <Rubidium> something y = A + B*x^C
16:02:57 <CIA-2> OpenTTD: smatz * r20756 /trunk/src/newgrf.cpp: -Cleanup: no need to check return value of CallocT
16:03:30 <planetmaker> But the residuals of a log - log fit are not uniformly distributed
16:03:38 <planetmaker> As you can see in the image I posted ;-)
16:03:58 <planetmaker> That may be random. Or it may be functional. That I don't know and will need further analysis
16:04:16 <planetmaker> (an analysis which takes more than a few minutes, I fear)
16:05:19 *** frosch123 has joined #openttd
16:05:58 <Rubidium> planetmaker: okay, then I'll try some more stuff. In any case thanks for the effort!
16:08:20 <planetmaker> no problem. I guess... Before you try too much, try to understand what the chi-square value of 0.13 I get for a linfit tells you
16:08:32 <planetmaker> I always have problems interpreting that
16:11:25 *** robotboy has joined #openttd
16:24:29 <planetmaker> actually... Rubidium... it seems that the ChiSquare tells that a linear fit of the logarithms is still quite fine.
16:24:45 <planetmaker> (yes, I need to understand this anyway, so no worries ;-) )
16:26:00 <VVG> Terkhen: can you please refreshe my memory with a commit number you pointed me to some time ago when i asked about limiting sort funcs to a certian vehicle list?
16:29:08 *** Prof_Frink has joined #openttd
16:33:47 <VVG> yeah, it's the one, thanks a lot
17:36:37 <Wasila> More error messages D:
17:37:25 <Wasila> make[1]: *** [mswindows.o] Error 1
17:37:25 <Wasila> make[1]: Leaving directory `/usr/src/wget-1.9.1/bld/src'
17:37:25 <Wasila> make: *** [src] Error 2
17:37:25 <Wasila> cd src && make CC='gcc' CPPFLAGS='' DEFS='-DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"c:/mingw/etc/wgetrc\" -DLOCALEDIR=\"c:/mingw/share/locale\"' CFLAGS='-O3 -s -mms-bitfields -march=i686' LDFLAGS='' LIBS='' prefix='c:/mingw' exec_prefix='c:/mingw' bindir='c:/mingw/bin' infodir='c:/mingw/info' mandir='c:/mingw/man' manext='1' install.bin
17:37:25 <Wasila> make[1]: Entering directory `/usr/src/wget-1.9.1/bld/src'
17:37:26 <Wasila> gcc -I. -I/usr/src/wget-1.9.1/src -I/opt/include -DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"c:/mingw/etc/wgetrc\" -DLOCALEDIR=\"c:/mingw/share/locale\" -O3 -s -mms-bitfields -march=i686 -c /usr/src/wget-1.9.1/src/mswindows.c
17:37:26 <Wasila> C:/MinGW/msys/1.0/src/wget-1.9.1/src/mswindows.c: In function 'set_sleep_mode':
17:37:28 <Wasila> C:/MinGW/msys/1.0/src/wget-1.9.1/src/mswindows.c:332:8: error: lvalue required as left operand of assignment
17:37:28 <Wasila> make[1]: *** [mswindows.o] Error 1
17:37:30 <Wasila> make[1]: Leaving directory `/usr/src/wget-1.9.1/bld/src'
17:37:30 <Wasila> make: *** [install.bin] Error 2
17:37:32 <Wasila> Does that mean anything to anyone?
17:38:45 <Wasila> So I'm not the only one <_<
17:39:03 <glx> it means compilation fails
17:39:33 <ln-> it means when you have more than two lines to paste, you use a pastebin.
17:39:59 <ln-> because flooding is bad. just look what happened to New Orleans.
17:40:16 <avdg> pastbin.com pastebin.org
17:40:24 <avdg> or whatever the extention may be
17:40:51 <Wasila> Do we know what the source of the problem is?
17:41:37 <Wasila> I had established that
17:42:15 <glx> looks like x = y where x is not a variable
17:42:49 *** TheMask96 has joined #openttd
17:43:13 <Wasila> Which means you don't know??
17:44:03 <Wasila> But it means no compiling?
17:44:41 <Wasila> And wget is vital for compiling, right?
17:45:05 <glx> no it's used to download files
17:45:21 *** De_Ghosty has joined #openttd
17:45:25 <Wasila> Why do I need to do that? To get the sourcecode?
17:45:37 <CIA-2> OpenTTD: translators * r20757 /trunk/src/lang/ (galician.txt norwegian_nynorsk.txt unfinished/chuvash.txt):
17:45:37 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:37 <CIA-2> OpenTTD: chuvash - 23 changes by mefisteron
17:45:37 <CIA-2> OpenTTD: galician - 62 changes by Condex
17:45:37 <CIA-2> OpenTTD: norwegian_nynorsk - 42 changes by mantaray
17:45:56 <Wasila> Would it be possible to do it manually?
17:49:02 <Wasila> I mean, where to get the files?
17:49:09 *** fmauneko has joined #openttd
17:57:57 <Wasila> I can't find anything about the error on the internet...
17:59:21 <glx> why not use mingw/msys installer ?
17:59:41 <Terkhen> Wasila: you can find a precompiled wget at the mingw/msys page
17:59:56 <Wasila> Glx, what do you mean? I've already installed mingw/msys
18:00:21 <glx> then why does it need to compile wget ?
18:00:32 <andythenorth> (following comments on FIRS thread....) what's stopping 'many industry sets' on one map?
18:00:38 <Wasila> I just follow the instructions <_<
18:00:43 <andythenorth> i.e. industry pool and cargo pool?
18:01:16 <Wasila> Where is the precompiled wget? I can only find the tar
18:01:41 <Terkhen> andythenorth: the same cargo being defined differently in each industry set
18:01:55 <andythenorth> there would have to be a cargo pool
18:02:24 <andythenorth> i.e. 'FIRS Coal', 'ECS Coal', 'Pikka Coal'
18:02:43 <andythenorth> it has certain....problems.
18:03:02 <VVG> both ecs and firs are quite complex already and some people want a them combined?
18:03:18 <andythenorth> which to players probably makes perfect sense
18:03:27 <andythenorth> I used to play with canset industries + PBI
18:03:36 <andythenorth> made sense to me
18:04:54 <planetmaker> andythenorth, you can only sensibly combine industry sets, if you don't define cargos
18:05:17 <planetmaker> but leaving the cargo definition to a 3rd-party newgrf. But then it'd be difficult to know...
18:05:31 <planetmaker> you'd need to test for cargo existance. And possibly define new, additional cargos.
18:06:42 <andythenorth> I wonder if the idea is so bad...in theory
18:07:34 <Ammler> Wasila: you should build mingw packages self
18:07:43 <Ammler> but isn't there a installer?
18:08:04 <Wasila> Yeah, but wget etc weren't included
18:08:52 <Wasila> I had to download them separately
18:09:56 <Terkhen> but check the RELEASE-NOTES first, it might have some dependencies
18:10:17 *** ajmiles has joined #openttd
18:10:38 <Terkhen> andythenorth: IMO having the same cargo defined multiple times would drive most people crazy
18:11:03 <Wasila> Thanks Terkhen, I'll check that out now
18:11:42 <andythenorth> so in reality, industry grf authors would have to work closely with some other grf author providing cargos :P
18:11:56 <andythenorth> we almost have that with cargo classes
18:12:18 <andythenorth> imagine there wasn't a 32 cargo limit
18:12:36 <andythenorth> (imagining is several orders of magnitude than coding) :P
18:13:15 <Wasila> Terkhen, am I supposed to be able to extract the file?
18:13:41 * andythenorth tries to figure out how three grfs could define one cargo :P
18:14:15 <Terkhen> if you can't, look for a program that can extract that format
18:14:35 <Wasila> And then extract it to /msys/home?
18:15:14 <Terkhen> IIRC it should be explained at the release notes file
18:20:23 <CIA-2> OpenTTD: smatz * r20758 /trunk/src/ (newgrf.cpp newgrf.h openttd.cpp): -Fix: when leaving the program, current newgrf config would leak, causing valgrind warnings
18:23:44 <Wasila> But I *think* I've got it
18:23:54 <Wasila> Does wget.exe go into the /msys/bin folder?
18:24:37 <Wasila> I'll press on and see what happens
18:25:13 * Terkhen wonders when mingw will get some kind of usable package manager
18:27:33 <Wasila> msys-crypto-1.0.0.dll not found
18:27:51 <Terkhen> told you to check RELEASE-NOTES for dependencies :)
18:28:43 <Wasila> That is a LOT of dependencies:(
18:29:26 <Wasila> This isn't one of them, though
18:33:51 <andythenorth> anyone know how many cargos ECS defines?
18:36:46 *** perk111 has joined #openttd
18:40:38 <Wasila> Is zlib necessary for compiling?
18:43:20 <Terkhen> Wasila: if you want to try an unfinished method that I still haven't tested much, check your private messages at the forum
18:44:00 <Wasila> SmatZ, zlib doesn't come with a readme
18:44:39 <SmatZ> OpenTTD does not require any of the libraries to be present, but without
18:44:40 <SmatZ> zlib you cannot open most savegames or use the content downloading system.
18:45:23 * andythenorth thinks multiple industry sets in one map should be possible
18:45:36 <Wasila> Downloading the "base", now
18:46:28 <planetmaker> andythenorth, then go, make FIRS adopt to the two existing industry sets :-)
18:46:46 <planetmaker> you 'just' have to accept flexible cargo definitions
18:47:17 <andythenorth> lets see how it would work in theory....
18:47:32 <andythenorth> FIRS steel mill: accepts coal, iron ore, scrap metal, produces metal
18:47:52 <Wasila> Terkhen, am I supposed to install the Luna thing to /mingw?
18:48:21 <Terkhen> I installed it to c:\mingw
18:48:25 <andythenorth> ECS steel mill: accepts coal, iron ore, produces steel
18:48:34 <Terkhen> should work at the default dir
18:49:14 <Terkhen> but if you don't uninstall your current mingw/msys things will get very messy
18:49:34 <andythenorth> so both steel mills are in one game
18:49:42 <andythenorth> but no cargos are defined by either grf
18:51:17 *** fjb is now known as Guest813
18:51:58 <andythenorth> nothing happens :P
18:52:17 <andythenorth> now Alice comes along with a cargo grf, defining coal, iron ore, scrap metal, steel and metal
18:52:22 <andythenorth> so the steel mills work
18:52:37 <Wasila> I suppose I should have done it fresh... if it works I might do it again from scratch
18:52:40 <planetmaker> andythenorth, and both re-define the original steel mill. Probably producing some kind of clash :-)
18:52:47 <planetmaker> The last grf winds
18:52:58 <andythenorth> but that's an implementation problem, not an architectural problem
18:53:00 <Wasila> I would have to install both mingw and msys before following your instructions, Terkhen, right?
18:53:06 <andythenorth> I am thinking about architecture... :)
18:53:27 <andythenorth> FIRS steel mill will get redefined as new industry soon anyway
18:53:50 <andythenorth> so where does steel go?
18:53:51 <Terkhen> Wasila: lunac contains both
18:54:07 <Wasila> Oh, so I wouldn't need to do anything?
18:55:10 <andythenorth> where does coal come from?
18:55:15 <Wasila> It's spewing out lots of random stuff
18:55:22 <andythenorth> coal from ECS coal mine
18:55:25 <andythenorth> coal from FIRS coal mine
18:55:54 <planetmaker> that's the easy thing. That's the same
18:56:01 <andythenorth> can ECS steel mine build near ECS coal mine?
18:56:11 <andythenorth> their are limitations to prevent that
18:56:26 <andythenorth> can ECS steel mill build near FIRS coal mine?
18:56:37 <andythenorth> is George's set now broken?
18:56:38 * planetmaker likes steel mines
18:56:40 <Wasila> No application dares to compile on my computer...
18:56:54 <andythenorth> arguably that would 'break' ECS
18:57:03 <planetmaker> andythenorth, that's the same thing as with different trains
18:57:29 <Terkhen> andythenorth: IMO something like this would break any industry sets that are not prepared to work together
18:57:38 <planetmaker> you can choose to accept any wagon. Or you can choose to only use your own one
18:57:44 <andythenorth> what if cb28 could use a var to check for production of a cargo at an industry, instead of checking industry?
18:58:02 <planetmaker> andythenorth, instead won't work. It'd need to be a separate callback
18:58:17 <planetmaker> Mind that you can -whatever change you propose and implement - not change existing newgrf
18:58:22 <planetmaker> They absolutely need continue to work
18:58:41 <planetmaker> What needs not work is a nice behaviour for two newgrfs.
18:58:54 <planetmaker> like a ecs coal mine adjacent to a firs steel mill is fine
18:59:15 <andythenorth> it breaks ECS concept
18:59:16 <planetmaker> One could then provide newgrf means to prevent such things in future versions of both OpenTTD and the related newgrfs
18:59:38 <planetmaker> it breaks the ECS concept. But that is already broken, if you use it with another NewGRF
18:59:39 <andythenorth> so lets say FIRS 1 and ECS 1 would never be compatible
19:00:02 <andythenorth> what about if there was a FIRS 2 and ECS 2 and some method (like engine pool) for allowing them to co-exist
19:00:08 <planetmaker> They've little means to talk to eachother. And too little free resources
19:00:22 <planetmaker> for v2 like you say... maybe
19:00:51 <andythenorth> the number of cargos would *have* to be increased (may not be possible)
19:01:10 <planetmaker> not possible doesn't fit. But it might involve quite some complications ;-)
19:01:15 <andythenorth> and there should be a way to do it decoupled, i.e. no industry grf needs know about other industry grf
19:02:11 <andythenorth> planetmaker: can you understand why Muzzy wants it?
19:02:18 <andythenorth> is it to get more cargos or what?
19:02:52 <planetmaker> I don't quite get it. I guess more industry variety. Different regions with different looks
19:02:58 <planetmaker> The latter might be a good reason
19:03:57 <andythenorth> 'all grfs in one map' would encourage competition between industry sets, in a brutal way
19:04:05 <Wasila> Terkhen, the program has finished running
19:04:08 <andythenorth> if there are 3 steel mills, players will deliver to most 'efficient'
19:04:13 <andythenorth> i.e. most output per input
19:04:14 <Wasila> No errors reported, although it didn't look promising at some points
19:04:15 <planetmaker> andythenorth, I'd not call it competition.
19:04:23 <Wasila> svn: command not found
19:04:24 <planetmaker> It's the same competition different vehicle sets have
19:04:32 <planetmaker> Take the most cost efficient / fastest vehicle.
19:04:36 <planetmaker> But yeah... so what?
19:04:54 <Wasila> is my latest error message
19:04:54 <planetmaker> People can do that. people actually DO that
19:05:10 <planetmaker> But it's no fun for me. And not the point for me to allow several of those newgrfs.
19:05:15 <planetmaker> But ... it's probably a valid reaosn
19:05:45 <andythenorth> if the intention is variety, would that actually happen? Or does winner-take-all, i.e. if there are two steel mills types, only one actually gets used
19:05:48 <planetmaker> The 'true' reason for multiple grfs of one kind is to allow variety. And extend certain themes in depth
19:05:49 <Terkhen> Wasila: as I mentioned, the method does not cover how to checkout OpenTTD code; install SVN as explained at the wiki
19:06:30 <planetmaker> andythenorth, it would seem to me that if two newgrf define it that both would be used. Would need to be used
19:06:50 <Terkhen> with lunac they should go to c:/mingw instead of to c:/msys
19:06:57 <andythenorth> but if one type gives more cargo out per cargo in....
19:07:01 <planetmaker> Because steel mill A could provide metals, steel mill B steel. But a chain in A requires metals and a chain in B steel. Which either would be broken without the respecive input cargo
19:07:26 *** [com]buster has joined #openttd
19:08:13 <Wasila> oh, I installed SVN to the wrong folder
19:08:26 <planetmaker> a bit besides the point: andythenorth you're really a man full of visions :-) And the most sympathic point about that is that you work towards them ;-) I just needed to tell that
19:09:05 <Terkhen> Wasila: if configure ran without problems it should be ok
19:09:38 <Wasila> Yeah, everything's ticking along nicely
19:10:17 <Wasila> Now I've got something to do until Civ V comes out <_<
19:10:29 <Terkhen> I'll update the wiki once I have time, then... I won't include the script though; I don't want to add something that requires maintenance
19:11:05 <Wasila> Is the script not necessary?
19:12:20 * ABCRic made some monorail lines going through NoCAB's roads. ABCRic is an evil person :D
19:12:25 <andythenorth> it's a fun design brief....
19:12:51 <andythenorth> player A: "FIRS / ECS are *way* too complicated for me, why not make them smaller and simpler"
19:13:04 <andythenorth> player B: "please can I have both together"
19:13:40 <planetmaker> That clearly shows that the quadrature of a circle is impossible
19:14:19 <ABCRic> I'm thinking AIs could have a debug message complaining about their vehicles being destroyed :P
19:15:17 <planetmaker> I'm not surprised if nocab will work around you evilism
19:15:52 <ABCRic> Ah, but it isn't *evil grin*
19:16:38 <planetmaker> I'd give you a warning if it was obvious that you do it only for the sake of detriment to your opponent.
19:17:44 <ABCRic> Meh, there was some AI that printed some pretty human-like messages to the debug window, but I can't seem to find it...
19:18:13 * andythenorth wonders if Muzzy just talks about industry graphics
19:18:19 <planetmaker> look a bit through the NoAI sub-forum
19:18:30 <andythenorth> does he understand that different industries have different production etc?
19:18:43 <planetmaker> andythenorth, I tried to explain...
19:18:58 * andythenorth never gives up on users :)
19:20:57 <ABCRic> planetmaker: I'm searching, but I can't find it :(
19:21:55 <planetmaker> you could also simply start an all-AI game and look at the logs
19:23:48 <ABCRic> Guess I'll download every available AI and see if I can find it then.
19:26:00 <ABCRic> Wonder how many crashes I'll get xD
19:26:58 <planetmaker> If you use _all_ ai.
19:27:20 <planetmaker> which would be more than one game as there are afaik more than 14 AI
19:31:04 <ABCRic> wait, never mind, "the following red text is not actually an error".
19:33:46 <Terkhen> Wasila: it isn't required if you run all the commands manually
19:34:02 <ABCRic> one year and no AIs crashed yet. Guess I'll go have some dinner then :) brb
19:34:04 <Wasila> Oh, so you'd just put those commands up on the wiki?
19:35:05 <Terkhen> I'll probably reorder them to follow the format of the wiki
19:36:10 * andythenorth stops with 'multiple industry grf' idea....for now :P
19:44:44 *** wollollo has joined #openttd
19:44:45 *** p01ymer has joined #openttd
19:59:31 <VVG> I fail hard at updating the sorter from itim to current trunk, i better give it up
20:09:36 *** [alt]buster has joined #openttd
20:09:39 *** [alt]buster is now known as [com]buster
20:46:45 <TomyLobo> i have a deadlock spanning half my network :/
21:01:57 *** ABCRic_ has joined #openttd
21:02:19 <VVG> which might be cause by just one signal placed wrong :)
21:05:03 *** ABCRic is now known as Guest826
21:05:03 *** ABCRic_ is now known as ABCRic
21:32:06 *** Progman has joined #openttd
21:43:03 <Eddi|zuHause> or a missing catenary
21:43:44 <Eddi|zuHause> i used to have a lot of deadlocks, because my junctions were impossible to signal correctly...
21:44:21 <Eddi|zuHause> ... then came along some genious path signal implementation ;)
21:52:28 *** ChanServ sets mode: +v tokai
21:55:00 <fjb> The only thing which it misses are one way markers without a waiting point.
21:56:20 <VVG> that's not the only thing it misses :)
21:58:41 <VVG> What will be a better way to see if a new minute has come inside increase date. A seconds counter like a date_fract, or computing the new minute using an avaible function? To me, it looks like the 1st case is better, since it requires less computations and the integer may be quite small, but i may lack some knowledge
22:03:58 <Hirundo> Fetching a cached value from memory may take longer than a few arithmetic operations, if you're that concerned about performance
22:04:43 <Eddi|zuHause> i'd create a (reusable) inline function that calculates the value from the tick counter
22:05:37 <Eddi|zuHause> could make it easier if you ever wanted to introduce more factors than 1,2,3,4
22:05:47 <Rubidium> Eddi|zuHause: weren't you of the one day is one minute side?
22:06:10 <Eddi|zuHause> i said i always used 1 tick = 1 second
22:06:43 <Rubidium> then who did suggest one day = one minute?
22:07:04 <Eddi|zuHause> i'm not sure, but effectively that would mean a factor of 74/60
22:07:50 <Hirundo> It'd mean, some seconds are slightly less hard to notice before they're passed, compared to others
22:08:52 <Eddi|zuHause> Hirundo: problem with factors 1 tick < 1 second is that you may have two consecutive ticks with second 0, so it's more difficult to check whether the minute changed
22:09:42 <Eddi|zuHause> there are, of course also advantages to 1 day = 1 minute
22:09:57 <Hirundo> minute = ticks / DAY_TICKS <- is that hard? the CPU does it for you
22:10:42 <Hirundo> bool changed_minute = ticks / DAY_TICKS - (ticks - 1) / DAY_TICKS
22:10:55 <Eddi|zuHause> Hirundo: ticks%60==0 is easier than ticks/74 != (ticks-1)/74
22:11:09 <Eddi|zuHause> first one is one division and second one is two divisions
22:11:10 <VVG> the commented parts there are from itim, seconds_counter is what i just thought of
22:11:18 <Eddi|zuHause> divisions are traditionally very slow commands
22:11:36 <Hirundo> Eddi|zuHause: It has the advantage of reusing the existing OnNewDay handler, so the amount of extra code is 0
22:12:12 <Eddi|zuHause> Hirundo: but it makes it more difficult to add more factors
22:12:58 <Eddi|zuHause> Hirundo: and it may conflict with daylength
22:13:33 <Eddi|zuHause> which is not a rejected feature, just a long list of rejected/unfinished patches
22:14:26 <Hirundo> If you write a 'daylength patch' using #define DAY_TICKS (74 * day_length_setting), you should not complain if it fails
22:16:35 <Hirundo> If the timetable part is properly factored, making 1 day = $day_length_setting minutes should be doable
22:17:19 <VVG> why would you want 1 day = 1 minute?
22:17:37 <Eddi|zuHause> VVG: easier to calculate in your head
22:18:17 <Eddi|zuHause> VVG: everything...
22:18:38 <Eddi|zuHause> VVG: also solves the rounding problems when autofilling timetable
22:19:53 <VVG> i don't see a probelm with rounding, as that can be done according to settings
22:20:25 <Eddi|zuHause> VVG: it can't be, if the setting should be client-side
22:20:58 <VVG> i already did it that way, the rounding factor is passed via DoCommandP
22:21:26 *** ChanServ sets mode: +v tokai
22:21:54 <VVG> rounding factor itself is a property of a vehicle
22:27:57 <VVG> back to my original question. Your answers didn't make it clearer for me, which one is better. :(
22:28:35 <TrueBrain> Rubidium: thought it would be nice to CC you, so you can reply for me next time :D
22:33:12 <Rubidium> I wouldn't have guessed that :)
22:40:30 <Hirundo> VVG: I just think that 49 kb of diff for something that should be a simple client side setting is a bit too much, but I'd have to study in greater depth to see what makes it so complicated
22:42:48 <VVG> virtual Point OnInitialPosition - is this the place where initial position of a window is calculated? I tried a few things with it and it didn't change a thing for me
23:45:14 *** Nite_Owl has joined #openttd
23:48:57 <Nite_Owl> Has anyone yet reported the "you cannot build trees" problem in r20757 ?? I have checked and you could be trees in r20750.
23:49:35 <Nite_Owl> or would that be "plant trees" ??
23:55:44 *** [alt]buster has joined #openttd
23:55:47 *** [alt]buster is now known as [com]buster
continue to next day ⏵
