Log for #openttdcoop.devzone on 28th March 2010:
Times are UTC Toggle Colours
00:01:42  *** DJNekkid has joined #openttdcoop.devzone
00:25:51  *** DJNekkid has quit IRC
00:31:56  *** OwenS has quit IRC
00:34:46  *** DJNekkid has joined #openttdcoop.devzone
01:46:00  *** KenjiE20 has quit IRC
02:54:30  *** Doorslammer has quit IRC
03:09:51  *** DJNekkid has quit IRC
03:26:04  *** DJNekkid has joined #openttdcoop.devzone
06:08:51  *** DJNekkid has quit IRC
06:24:19  *** DJNekkid has joined #openttdcoop.devzone
07:29:16  *** ODM has joined #openttdcoop.devzone
09:03:30  *** ODM has quit IRC
09:03:47  *** ODM has joined #openttdcoop.devzone
09:12:25  *** ODM has quit IRC
09:12:57  *** ODM has joined #openttdcoop.devzone
09:24:10  <Webster> Latest update from devactivity: OpenGFX - Revision 403: Doc: Update changelog to tip <> || Redmine - Revision 3460: Issue list improvements for subtasking (#5196): <> || Redmine - Revision 3459: Adds parent issue id to the issues CSV export. <> || Redmine - Revision 3458: Fixes backslashes escaping when quoting issue description/note (#5129). <> || Redmine - Revision 3457: Width of pre blocks in descriptions changed to auto (#5160). <> || Redmine - Revision 3456: Fixed: Links to missing wiki pages not red on project overview page (#51... <> || Redmine - Revision 3455: Escape revision on repository view (#5153). <>
09:25:42  *** ODM has quit IRC
09:44:50  *** ODM has joined #openttdcoop.devzone
09:45:21  *** DJNekkid has quit IRC
09:53:21  *** ODM has quit IRC
09:57:54  <planetmaker> something else: should I 'quickly' release OpenGFX 0.2.2 right now, Ammler ?
10:00:09  *** DJNekkid has joined #openttdcoop.devzone
10:02:04  *** KenjiE20 has joined #openttdcoop.devzone
10:05:22  *** frosch123 has joined #openttdcoop.devzone
10:22:18  <Ammler> planetmaker: you have something you miss in 0.2.2 yet?
10:22:26  <planetmaker> Ammler: not that I know
10:22:38  <planetmaker> or not something I'd be able to do today
10:22:45  <planetmaker> and nothing which cannot really wait
10:23:00  <planetmaker> I'm not happy with the double makedep generation. Alas. A fix for the next release
10:23:30  <planetmaker> it's not like it's a show stopper
10:25:42  <Ammler> well, the binary name change fedora and debian uses for renum isn't really something important
10:25:51  <planetmaker> That's in.
10:26:09  <planetmaker> and it is a feature :-)
10:26:21  <Ammler> IMO, such things shouldn't be changed from package maintainers
10:26:27  <Ammler> rather from upstream
10:27:20  <planetmaker> well. Not my worry really. It's a small one-liner and doesn't hurt me. I leave that to others :-)
10:27:26  <Ammler> if someone does change binary names individually, he should also fight with the consequences
10:27:32  <planetmaker> :-P
10:27:38  <planetmaker> yes, true
10:27:42  <planetmaker> despite
10:27:48  <Ammler> yeah, you got a request for it
10:28:15  <planetmaker> even a patch
10:28:45  <planetmaker> and receiving simple patches makes support easy
10:29:30  <Ammler> I meant more, it wasn't a feature to make compatible with fedora/debian
10:30:02  <Ammler> more with the package mainteiners...
10:30:22  <planetmaker> ah. Well.
10:31:49  <Ammler> and such things does slow down upstream to fix it, if it is a issue there...
10:32:23  <planetmaker> hehe. Dependecy will anyway change to python2nfo ;-)
10:32:58  <planetmaker> or however y3xo will call it.
10:34:01  <Ammler> well, for Rubi, it was a ugly change
10:34:11  <Ammler> he had some work with it, not just in opengfx ;-)
10:34:29  <planetmaker> you mean with nforenum / renum or what?
10:34:55  <Ammler> yes
10:35:41  <planetmaker> I must have missed that.
11:16:52  *** Seberoth has joined #openttdcoop.devzone
11:31:44  *** OwenS has joined #openttdcoop.devzone
11:59:52  *** DJNekkid has quit IRC
12:12:54  <Webster> Latest update from devactivity: OpenGFX - Bug #873 (New): hg up -rXXX && make install fail to rebuild <> || OpenGFX - Bug #872: wrong sprites for some building tools(?) <" target="_blank">> || OpenGFX - Bug #872 (New): wrong sprites for some building tools(?) <>
12:15:37  *** DJNekkid has joined #openttdcoop.devzone
12:27:04  <planetmaker> psst:
12:27:10  <planetmaker> don't use it ;-)
12:29:54  <Rubidium> then you're probably better off removing them :)
12:30:52  <planetmaker> yeah.
12:30:55  <planetmaker> they're faulty
12:31:05  <planetmaker> it's between r388:393
12:31:10  <planetmaker> my guess is r392
12:31:19  <planetmaker> Thus I messed it up myself ;-)
12:33:21  <Rubidium> extra-plus-tropic-rail-vehicels.pnfo <- vehicles! :) (don't know if it's still wrong)
12:34:05  <planetmaker> I *think* I fixed that. Let's see
12:34:17  <Rubidium> 391 seems to replace one set less in vehicels.pnfo
12:34:47  <planetmaker> but only r392 fails
12:36:43  <planetmaker> ah. r391: yes. There's no point to replace the passenger carriage, if each climate has anyway a separate definition of the passenger carriage
12:36:50  <planetmaker> that's why it's one less
12:37:13  <planetmaker> but that's extra and replacing arctic stuff.
12:37:44  <planetmaker> @calc 16 10 ad0a
12:37:59  <planetmaker> @calc 16 10 AD0A
12:38:08  <planetmaker> @base 16 10 AD0A
12:38:08  <Webster> planetmaker: 44298
12:38:15  <planetmaker> @base 16 10 0AAD
12:38:15  <Webster> planetmaker: 2733
12:38:45  <planetmaker> yes, there it is. 2733 != 2723
12:40:59  <planetmaker> better
12:43:49  <Webster> Latest update from devactivity: OpenGFX - Bug #872 (Closed): wrong sprites for some building tools(?) <" target="_blank">> || OpenGFX - Revision 404: Fix (r392) [#872]: Wrong sprite numbers in hex to decimal conversion. 0x0... <> || OpenGFX - Bug #872 (Closed): wrong sprites for some building tools(?) <>
12:48:05  <planetmaker> next try :-)
13:07:37  <planetmaker> Rubidium: you may now want to sync your mirrors.
13:10:51  <Rubidium> the files on are updated too?
13:10:51  *** DJNekkid has quit IRC
13:12:16  <Ammler> planetmaker: we could also move the compiled readme.txt to bundles
13:12:26  <Ammler> for "official" link
13:12:59  <planetmaker> Rubidium: yes
13:13:12  <planetmaker> I update bundles before I update bananas :-)
13:13:20  <planetmaker> I can reverse bundles, but not bananas ;-)
13:13:38  <Rubidium> okay, updated the installer too
13:13:43  <planetmaker> thanks :-)
13:14:07  <Webster> Latest update from devactivity: OpenGFX - OpenGFX 0.2.2 released <> || OpenGFX - Revision 405: Added tag 0.2.2 for changeset d49681015243 <>
13:15:38  <planetmaker> Ammler: done
13:21:04  <Ammler> 0.2.2 is building on all rpm distros already...
13:22:12  <Ammler> CentOS_5             i586       succeeded; openSUSE_Factory     i586       succeeded
13:22:25  <Ammler> seems like suse factory issue is fixed :-)
13:22:32  <Ammler> or make check failed...
13:24:04  <Ammler> yes, make check failed
13:24:11  <Ammler> trying md5sum -c
13:26:32  *** DJNekkid has joined #openttdcoop.devzone
13:39:44  *** Seberoth has quit IRC
13:40:37  *** Seberoth has joined #openttdcoop.devzone
13:48:01  <Ammler> + md5sum -c opengfx-0.2.2.md5
13:48:02  <Ammler> md5sum: opengfx-0.2.2.md5: no properly formatted MD5 checksum lines found
13:48:37  <planetmaker> hm?
13:49:04  <Rubidium> Ammler: works fine for me
13:49:05  <planetmaker> run make check
13:50:02  <Rubidium> (both make check and md5sum -c opengfx-0.2.2.md5 (for the source tarball!) that is)
13:51:00  <planetmaker> the repo has no md5 file by default. it's generated via make md5 or make bundle_src
13:51:25  <planetmaker> and only distributed with the source release
13:51:46  <planetmaker> which actually *could* be changed
13:52:06  <planetmaker> but... that would create the trouble that building it would overwrite the check file ;-)
13:52:22  <Ammler> hmm?
13:52:30  <Ammler> if I build from source tarball?
13:52:49  <planetmaker> if I create a .md5 for every make or bundle_zip, I'd overwrite the file I'd like to check
13:52:59  <planetmaker> Thus I don't create it, unless I run bundle_src
13:53:27  <planetmaker> --> only ...-source.tar.gz contains that file
13:53:33  <Ammler> yes, fine
13:53:42  <Ammler> the error isn't about missing file
13:53:47  <planetmaker> :-) Ok
13:54:00  <Ammler> the error is about not properly formatted checksum lines
13:55:00  <planetmaker> well. I tested it on my suse and it worked when I tested the format. I didn't check today but when I wrote that part
13:57:56  <planetmaker> how does your .md5 file look like?
13:59:46  <planetmaker> shit. My renum on my suse is broken.
14:00:16  <planetmaker> NFORenum v3.4.6 r2309 - Copyright 2004-2009 Dale McCoy.
14:00:38  <Rubidium> how is that broken?
14:02:18  <planetmaker> <-- I think I have some modified dat files from one of yexo's patches
14:03:05  <Rubidium> that's easy to fix :)
14:03:10  <planetmaker> yep
14:04:24  <planetmaker> jo, das war's wohl
14:04:53  <planetmaker> err.. yep, that's it ;-)
14:05:04  <planetmaker> different windows, different languages. Difficult
14:07:18  <planetmaker> Ammler: ok, I get the same thing here now with my suse and the supplied md5 file
14:07:20  <planetmaker> strange
14:07:25  <planetmaker> here = on my suse box
14:08:37  <planetmaker> <-- but it's not understandable
14:09:02  <planetmaker> ah... one missing space, I guess
14:09:09  <Rubidium> but... the md5 has two spaces (for me)?!?
14:09:50  <planetmaker> oh?
14:10:41  <planetmaker> mine in the source bundle doesn't.
14:13:24  <Rubidium> hmm, then does make check change it?
14:13:36  <Rubidium> yes... it does
14:13:42  <planetmaker> ?!!
14:14:01  <planetmaker> aua
14:15:03  <Rubidium> okay... clean tarball + make check -> somewhat works; it rebuilds the md5 file
14:17:16  <Rubidium> clean tarball + make + make check rebuilds the md5 file too
14:17:55  <planetmaker> that's certainly not intended...
14:18:33  <Ammler> Rubidium: what you mean with clean tarball?
14:18:46  <Rubidium> lol... the files ...md5 depends on are newer, so it rebuilds it
14:19:57  <planetmaker> damn right
14:20:04  <Ammler> also the thing worked as I tested it on my factory spec
14:20:04  <planetmaker> make check kills it.
14:20:19  <Ammler> I don't use make check
14:20:26  <Ammler> hmm
14:20:39  <planetmaker> better not ;-) It will succeed in 100% no matter what ;-)
14:21:24  <Ammler> hmm
14:21:33  <Ammler> local test worked
14:21:46  <Ammler> make md5 && make check worked
14:23:12  <planetmaker> yes. In the repo
14:23:28  <Ammler>
14:24:29  <Rubidium> anyhow... there are two problems... something created a corrupt md5 file for the source tarball and make check is totally and utterly broken
14:24:53  <planetmaker> seems like :-(
14:25:05  <Ammler> yeah, nice thing is, that openSUSE Factory doesn't build successfully
14:25:15  <Ammler> so we have a testbase ;-)
14:25:40  <planetmaker> it doesn't build successfully?
14:26:03  <Ammler> yes, grfcodec fails with compression
14:26:11  <planetmaker> hmpf
14:26:21  <Ammler> but that is issue of grfcodec, not opengfx
14:28:44  <Ammler>
14:28:52  <Ammler> something is indeed wrong with make check
15:14:25  <Ammler> planetmaker: will you fix the issue?
15:14:38  <Ammler> or is there a "working" workaround?
15:15:15  <planetmaker> Well. It will be fixed. But not in 0.2.2 :-)
15:15:38  <planetmaker> But the source release should be changed to include a proper md5 file
15:17:08  <planetmaker> I think this is yet another thing which says "please make an RC before releasing" ;-)
15:17:56  <Ammler> so the workaround is fixing the md5 file and using md5sum -c
15:18:04  <planetmaker> yes
15:18:10  <Ammler> well, you could fix it and release 0.2.3
15:18:19  <planetmaker> Is it worth it?
15:18:33  <planetmaker> well. maybe.
15:18:38  <Ammler> up2you, I don't care
15:18:45  <Ammler> but that is the same as a RC
15:18:51  <PeterT> wait, what is the problem here?
15:18:58  <Ammler> you?
15:19:24  <PeterT> why are you guys going to release 0.2.3?
15:19:46  <planetmaker> who says we will? :-)
15:19:55  <Ammler> no noticeable issue for users....
15:20:00  <PeterT> Ok
15:20:35  <Rubidium> just write about it in the news message?
15:20:46  <Ammler> but fix the md5list
15:20:53  <planetmaker> hm, yes
15:21:01  <planetmaker> md5list?
15:21:16  <Ammler> the md5file in the source bzip2
15:21:22  <Ammler> or gzip
15:22:53  <planetmaker> I updated the opengfx-0.2.2.md5 and will upload a new source release
15:22:57  <planetmaker> with updated file
15:22:58  <Rubidium> changing the source tarball after release is a bad thing to do
15:23:10  <planetmaker> Rubidium, only with the updated md5 file
15:23:24  <planetmaker> so that md5sum -c opengfx-0.2.2.md5 works
15:23:43  <Rubidium> planetmaker: you'll still end up with some distro's using the wrong tarbal because they already fetched the source tarball
15:23:53  <planetmaker> hm. ok
15:24:00  <Ammler> so the only solution is 0.2.3
15:24:19  <planetmaker> I don't have time to fix make check right now :-(
15:24:31  <Rubidium> yes, but with properly fixing the make check thing
15:25:39  <Ammler> hmm, then we should remove the release until you have?
15:26:05  <Rubidium> why remove it? Just in the news message make clear the make check stuff is broken
15:28:04  <Ammler> ok, with a message that we will soon release a fixed 0.2.3
15:28:29  <Rubidium> yeah
15:28:39  <Rubidium> it also needs a new opensfx version :(
15:28:54  <Rubidium> (I think at least)
15:29:16  <Ammler> he, in this matter, a RC as I checked it would be useless :-)
15:29:27  <Ammler> as on that time, it worked
15:31:27  *** PeterT_ has joined #openttdcoop.devzone
15:35:39  <planetmaker> Ok, release messages amended.
15:36:20  *** PeterT_ has quit IRC
15:42:13  <Ammler> planetmaker: feel free next time to use our server for building... :-P
15:43:17  <Ammler> at least for release
15:43:24  <planetmaker> :-) You'll have to walk me through that thing at one time
15:43:35  <Ammler> doesn't need to be obs
15:44:01  <Ammler> well, next time, it should make the release automatically
15:44:18  <planetmaker> you did change that already?
15:44:42  <Ammler> no, i have still some troubles with chroot
15:45:05  <Ammler> another idea is to make rpms and unrpm those again...
15:45:07  <planetmaker> if so, it also needs to generate md5sums of all generated files. Otherwise checking against locally generated files becomes too tedious ;-)
15:45:47  <planetmaker> well. It'd be nice to have upon push of a tag generate everything which needs to be put into bundles/<project>/releases automatically
15:46:18  <planetmaker> that'd take away much of the manual work
15:46:28  <planetmaker> half of it acutally
15:46:38  <planetmaker> or 2/3 even
15:47:57  <Ammler> yeah, bananas left
15:48:04  <Ammler> and news message
15:48:34  <planetmaker> yes. And that's good. That must not be automated
15:51:23  <Ammler> and bananas can use the release zip
15:51:46  <planetmaker> yes. But I don't want automatic upload.
15:52:02  <Ammler> wouldn't be that easy
15:52:11  <planetmaker> yes, but even if :-)
15:56:52  *** DJNekkid has quit IRC
16:13:56  *** DJNekkid has joined #openttdcoop.devzone
16:35:22  *** DJNekkid has quit IRC
16:44:09  *** DJNekkid has joined #openttdcoop.devzone
16:49:25  <Ammler> planetmaker: I am quite happy, this sprite issue wasn't my splitting :-)
16:49:42  <Ammler> I really thought, I made good enough checks...
16:49:53  <Ammler> comparing nfos...
16:49:55  <planetmaker> obviously you did :-)
16:50:32  <planetmaker> we need the same thing now with the pcx :-)
16:50:33  <Ammler> well, the checks I did were easy, just comparing the total of sprites :-)
16:51:36  <Ammler> just create a ticket which pcx you like to split :-)
16:51:52  <planetmaker> all big ones
16:52:20  <planetmaker> I'm not entirely sure how far they need cutting down.
16:52:26  <Ammler> ah, like infra
16:52:34  <planetmaker> hm?
16:53:18  <Ammler> nvm
16:53:55  <planetmaker> Ideally, I think like the houses: One grf per house (but included its building stages)
16:54:03  <planetmaker> s/grf/pcx/
16:54:15  <Ammler> <-- helpful tool
16:54:19  <planetmaker> I guess I should do the same for all the trains
16:55:22  <Ammler> we just never should modify a sprite in a big file
16:55:34  <Ammler> then some automatically gets splitted
16:55:40  <planetmaker> well. yes.
16:55:48  <planetmaker> But better to do it separate.
16:56:02  <planetmaker> not better. But that speeds up the process tremendously
16:56:08  <planetmaker> And helps to clean / sort things
16:56:10  <planetmaker> a lot
16:56:11  <Ammler> indeed
16:56:21  <planetmaker> ugly pcx like infra08.pcx, infra06.pcx
16:56:28  <Ammler> I just think, that wouldn't at least hurt developing
16:56:33  <planetmaker> or also the egrvts.pcx which I put there
16:56:36  <Ammler> as you can't merge binaries
16:57:02  <planetmaker> exactly that'd be the advantage
16:57:33  <Ammler> I think, we do it alreaey
16:57:36  <Ammler> already*
16:57:45  <Ammler> just not putting the files in subfolders
16:58:02  <planetmaker> yes. Partially. But we should start to be consequent.
16:58:15  <planetmaker> And that's easier, if it is really started as a task of its own
16:58:21  <Ammler> yes
16:59:23  * planetmaker assignes that task to Ammler :-)
16:59:25  <Ammler> one simple rule: never edit partial sprites
16:59:31  <planetmaker> You did a good job with the nfo ;-)
16:59:54  <Ammler> either you edit the whole pcx or you HAVE TO create a new one
17:00:20  <planetmaker> yes. And the rule should be: Don't edit big pcx. Out-source the pcx straight away.
17:00:37  <Ammler> well, my rule includes that
17:00:56  <Ammler> don't belive someone would be able to edit a whole pcx at once ;-)
17:01:09  <planetmaker> yes, I was only acknowledging that rule :-)
17:01:40  <Ammler> I have to admit that I broke this rule in past :-)
17:02:02  <Ammler> for example as I added monolev goods waggon to monolev pcx
17:02:22  <Ammler> but that pcx is obsolete anyway, I assume
17:02:47  <planetmaker> hm, yes
17:03:10  <planetmaker> I possibly shouldn't have added one pcx for all the wagons
17:03:14  <planetmaker> Though that was easy
17:03:29  <planetmaker> I guess I'll do differently for the trains and wagons to come.
17:03:53  <Ammler> well, personally I would use what you get from the drawer
17:03:58  <Ammler> he should use the templates
17:04:16  <Ammler> so you have every single waggon in a own pcx
17:04:50  <Ammler> and don't fear long file names ;-)
17:05:06  <planetmaker> _I_ don't fear long filenames :-)
17:05:39  <planetmaker> But I cannot use the pcx I get from drawers. They need nearly all re-work to some 'nicer' arrangement.
17:05:50  <planetmaker> molace does a pretty good job, though
17:05:52  <Ammler> that is quite bad :-(
17:06:59  <Ammler> on the other side, I enjoyed the investigation how to cut the stadiums
17:07:08  <planetmaker> :-)
17:07:15  <Ammler> using gimp from time to time doesn't hurt :-)
17:07:21  <planetmaker> indeed
18:03:27  <Webster> Latest update from devactivity: 2cc train set - Bug #864 (Closed): Missing file <>
18:04:16  <planetmaker> @calc pi/3 * (3/pi)
18:04:16  <Webster> planetmaker: 1.0
18:04:21  <planetmaker> @calc pi/3 * (3/pi)^(5/3)
18:04:26  <planetmaker> @calc pi/3 * (3/pi)**(5/3)
18:04:26  <Webster> planetmaker: 0.969722758044
18:06:33  <planetmaker> @calc pi/3 * (3/pi)**(5/3) 6.62e-34**2 / 9.1093e-31 * (4/3*pi*0.01**3*7e8**3)**(-2/3) * (2e30/(4*1.67e-27)*2)**(5/3)
18:06:36  <planetmaker> hm
18:06:42  *** Yexo has quit IRC
18:06:58  *** Yexo has joined #openttdcoop.devzone
18:07:01  <planetmaker> @calc pi/3 * (3/pi)**(5/3) 6.62e-34**2 / 9.1093e-31 * (4/3*pi*0.01**3*7e8**3)**(-2/3)
18:07:12  <planetmaker> @calc pi/3 * (3/pi)**(5/3) 6.62e-34**2
18:07:24  <planetmaker> @calc pi/3 * (3/pi)**(5/3) 6.62e-34
18:07:38  <planetmaker> @calc pi/3 * (3/pi)**(5/3)* 6.62e-34**2 / 9.1093e-31 * (4/3*pi*0.01**3*7e8**3)**(-2/3) * (2e30/(4*1.67e-27)*2)**(5/3)
18:07:49  <PeterT> Webster: You feelin' alright?
18:07:55  <PeterT> Webster: not up to it?
18:08:08  <planetmaker> I feel alright. But I miss my pocket calculator
18:08:34  <PeterT> planetmaker: <PeterT> @calc pi/3 * (3/pi)**(5/3)* 6.62e-34**2 / 9.1093e-31 * (4/3*pi*0.01**3*7e8**3)**(-2/3) * (2e30/(4*1.67e-27)*2)**(5/3)
18:08:34  <PeterT> -robobot- Error: invalid syntax (line 1)
18:12:03  <Paul2> welcome to #maths ?
18:12:30  <PeterT> Welcome indeed.
18:12:43  <planetmaker> what is math in that? It's just some numbers...
18:12:53  <planetmaker> math would be, if it were symbolical :-)
18:13:10  <planetmaker> It *should* be the cool-down time of a white dwarf, though
18:15:41  <OwenS> pocket calculator? Bah, get a graphical one
18:16:51  <planetmaker> what would that help?
18:17:08  <planetmaker> And: no, they're slower and serve little purpose
18:19:58  <andythenorth> you can draw smiley faces on them with the right parametric equation
18:21:10  <Rubidium> come on, can't you just calculate that on paper?
18:22:01  <planetmaker> the order of magnitude: sure
18:22:23  <Rubidium> also xey = x * 10**y
18:22:34  <OwenS> planetmaker: slower? Meh, I can use my graphical one faster than a "normal" one
18:22:38  <Rubidium> might help getting it right
18:24:01  * Paul2 recognises 6.62e-34 ;)
18:24:12  <planetmaker> yes, that's needed, Rubidium
18:24:19  <Paul2> oh and 1.67e-27 I guess
18:24:27  <planetmaker> But supybot isn't helpful:
18:24:29  <planetmaker> @calc pi/3 * (3/pi)**(5/3)* (6.62*10**34)**2 / (9.1093*10**(-31)) * (4/3*pi*(0.01**3)*(7*10**8)**3)**(-2/3) * (2*10**30)/(4*(1.67*10**(-27))*2)**(5/3)
18:24:29  <Webster> planetmaker: 974187697966850085053208141814354074151675763001804129522106434780223159398139462799535930909209762387541650596736015773534338756578297119927762296281082363904
18:24:59  <planetmaker> that may be true but is utterly useless :-)
18:25:30  <Hirundo> matlab says it's 9.7419e+158, so yes, true but useless
18:26:11  <PeterT> @calc -2**(1/2)
18:26:11  <Webster> PeterT: 1.41421356237i
18:26:22  <PeterT> @calc -4**(1/2)
18:26:22  <Webster> PeterT: 2i
18:26:26  <Rubidium> Hirundo: good old matlab :)
18:26:28  * Hirundo ads minus to the 10^34
18:26:34  <Paul2> matlab++
18:26:50  <frosch123> i get a different result if i use one of the earlier terms
18:26:53  <Hirundo> (6.62*10**34) <- this looks fishy to me
18:27:14  * Rubidium remembers the days he needed java + labview + matlab to get image recognition fast enough on an then already ancient machine
18:27:46  <planetmaker> that's indeed fishy, Hirundo. It's 6.62*10**(-34)
18:27:47  <Paul2> java != fast enough
18:27:54  <Hirundo> adding a minus there yields 9.7419e+022
18:28:11  <OwenS> Paul2: Java beats C/C++ for number crunching performance wise
18:28:15  <Rubidium> followed by the announcement just after he finished it that matlab's image recognition improved significantly (so significantly doing everything in matlab was faster)
18:28:28  <Paul2> I struggle to believe that
18:28:34  <Paul2> Java is made of slow.
18:28:35  <OwenS> Paul2: Then look up the benchmarks
18:29:02  <OwenS> Hotspot doesn't generate better code. What does happen, however, is that it trashes the cache far less than the C++ code does, because Java uses a compatcting garbage collector, vs a fragmenting malloc
18:29:45  <OwenS> Also, 99% of the "slowness" is actually the time taken to JIT the code. But you only do that once, then you crunch numbers intensively
18:29:50  <Rubidium> OwenS: don't forget to mention hotspot doing some profiling and recompiling for the fast path
18:30:10  <OwenS> Rubidium: Indeed. But it still beats C compilers and profiling
18:30:14  <OwenS> And has since about 1998...
18:34:17  <Rubidium> though ~5 years ago exceptions were seriously faster on the RVM than JVM
18:36:34  <OwenS> Do Exceptions matter mu... wait, this is Java, they do
18:56:53  <DJNekkid> im bored
18:56:56  <DJNekkid> :P
18:57:20  <planetmaker> give me farm fields with hay bales then ;-)
18:57:37  <Ammler> :-)
18:57:56  <Ammler> or nicer horizontal rail tracks
18:58:05  <Ammler> or better signals
18:58:20  <planetmaker> oh yes. Even more important ^
18:58:44  <Ammler> hmm, we might need the other pbs signals
18:58:52  <planetmaker> the other?
18:58:59  <Ammler> pbs presignals
18:59:04  <Ammler> for progsigs
18:59:12  <planetmaker> :-)
19:01:00  *** ODM has joined #openttdcoop.devzone
19:01:00  <OwenS> Ammler: The intention was progsigs would get its own signal icons :p
19:01:14  <Ammler> does it?
19:01:51  <Ammler> OwenS: if you paint those
19:02:07  <Ammler> maybe you could also generally make all light signals for opengfx?
19:02:10  <OwenS> Ammler: I painted some for openttdw.grf
19:02:14  <OwenS> But they were simple modifications
19:02:20  <OwenS> I just repainted the combo signal red :p
19:02:49  <Ammler> hmm
19:02:51  <OwenS> Im no artist :p
19:02:57  <Ammler> then you confuse with oneway pbs?
19:03:18  <OwenS> Oneway PBS is horizontal
19:03:25  <OwenS> And has a white border
19:04:15  <Ammler> progsigs could be quite big
19:04:25  <Ammler> maybe even with a hut
19:04:32  <OwenS> haha
19:05:33  <Ammler> serious that was... :-/
19:05:54  <OwenS> I know
19:05:58  <Ammler> :-)
19:06:03  <OwenS> I was taking it seriously, it would just be a interesting deviation
19:06:23  <OwenS> Also: /me wants the .dev game of cargodist to finish quickly :p
19:06:45  <Ammler> well, we made a own branch for cargodist
19:06:59  <Ammler> so we easy setup progsigs on dev
19:08:17  <Rubidium> OwenS: but the cargodist game gives very useful information
19:08:41  <Ammler> mass desync right now :-)
19:09:00  <Rubidium> that's not the useful information!
19:09:14  <Ammler> well, the funny part about is, some stay
19:09:17  <Rubidium> the useful information is that fonsinchen did not notice it (at least twice)
19:09:49  <planetmaker> :-D
19:10:11  <planetmaker> well. once.
19:10:48  <Rubidium> oh... stupid timezones et al.
19:10:55  <Ammler> [21:02] <OwenS> Ammler: I painted some for openttdw.grf <-- make your own grf until it gets trunkish
19:11:24  <Rubidium> still... I see mentions of a xx:07 desync (#openttd) and a xx:09 desync (tt-forums)
19:11:26  <planetmaker> Rubidium, true: it desynced twice. also true: 2nd time fonsinchen was in the channel and we talked while it happend.
19:11:39  <planetmaker> each one hour appart.
19:12:11  <planetmaker> well, or a few minutes but the same thing
19:12:19  <planetmaker> maybe.
19:12:24  <planetmaker> :-)
19:13:15  <planetmaker> But the 2nd time (now) everyone desynced as the server paused due to lack of players
19:14:57  <OwenS> I'm glad ProgSigs is pretty deterministic :p
19:15:13  <planetmaker> better make it 100% ;-)
19:15:16  <OwenS> No threads, no rand, the closest it gets is DoCommands
19:16:19  <Rubidium> oh... we had our fair share of nasty desyncs that you wouldn't believe
19:16:52  <Hirundo> OwenS: Most desyncs don't involve either, they are far more subtle
19:18:13  <OwenS> Hirundo: Oh, I'd expect that
19:18:24  <OwenS> But unlike Cargodist I dont have the trouble of threads
19:22:00  <Rubidium> something like bools in C on PPC were 1 byte and saving that to a savegame worked fine, until we went to C++ and the bool became 4 bytes and saving that caused trouble
19:22:49  <OwenS> Heh
19:23:06  <OwenS> I save everything as VLQ variable length integers, so
19:23:21  <Rubidium> or an array of uint32s being saved as uint16s; works fine, until you find PPC
19:23:39  <OwenS> Big endian, picked the wrong end?
19:24:01  <Rubidium> yeah, but the game just ran fine...
19:24:08  <Rubidium> because it was for the animated tiles
19:24:13  <Rubidium> and that worked for a few years
19:24:20  <OwenS> Heh
19:24:31  <Rubidium> until... industry NewGRFs with their persistent storage came about
19:25:03  <OwenS> ARM would behave even more strangely, doing a byte swizzle...
19:25:06  <Rubidium> and they were messing with that in the animation loop (or were reading the animation state) and used that for e.g. production changes
19:25:59  <OwenS> I suppose with progsigs I'll need to add a way for AIs to create them... Thats gonna be "fun"
19:29:03  <Hirundo> I fear that no sane person would write an AI for ever-changing patches like yours, or IS for that matter
19:29:35  <OwenS> Hirundo: If they were to be integrated :p
19:30:58  <Hirundo> Indeed, writing AI stuff is IMO only worth the effort when the patch is [nearly] in trunk
19:32:40  *** andythenorth has left #openttdcoop.devzone
19:32:51  <OwenS> It's gonna be interesting because the internal interface is rather baroque for a human :p
19:33:58  <OwenS> (Or: Manipulating instructions by code requires some indepth knowledge of their structure
19:48:37  *** DJNekkid has quit IRC
20:02:02  *** DJNekkid has joined #openttdcoop.devzone
20:11:22  *** DJNekkid has quit IRC
20:20:04  *** DJNekkid has joined #openttdcoop.devzone
20:24:15  *** andythenorth has joined #openttdcoop.devzone
20:56:50  *** frosch123 has quit IRC
21:26:08  <Webster> Latest update from devactivity: 32bpp-EZ - Support #874 (New): Create repository <>
21:41:20  <Webster> Latest update from devactivity: 32bpp-EZ - Support #874: Create repository <>
21:50:19  *** Seberoth has quit IRC
21:51:52  *** DJNekkid has quit IRC
21:52:46  <Rubidium> oh... do I see planetmaker flaming Apple :)
21:53:31  <planetmaker> ha, I knew you would smile on that! ;-)
21:54:28  <planetmaker> still. it's true.
21:56:28  <Webster> Latest update from devactivity: 32bpp-EZ - Support #874: Create repository <>
21:56:55  <planetmaker> today is desync day. I saw a desync on our prozone :-(
21:56:58  <planetmaker> r19443
21:57:58  <Rubidium> that sucks
22:01:26  <OwenS> Though weirdly for a spectator
22:01:42  <OwenS> Who we have never seen before, and not for a player
22:02:01  <Rubidium> oh... you could've told that too
22:02:36  <Rubidium> and he desynced pretty quickly?
22:02:46  <planetmaker> yes
22:02:56  <planetmaker> but he joined after that
22:03:46  <planetmaker> after that = separate try
22:03:46  <Rubidium> so he might have been using some sort of hacked binary and when he figured it didn't worked he used the right one
22:04:07  <planetmaker> He *might*. But he seems to be a complete newbie
22:04:42  <planetmaker> he claims to have used your binary
22:05:19  *** ODM has quit IRC
22:06:16  <Rubidium> any logs of that? Or are the logs by default an hour aged or so?
22:06:44  <planetmaker> If we have logs, we keep them.
22:06:57  <planetmaker> it's only 40 minutes ago anyway
22:07:05  <Rubidium> (irc logs that is :))
22:07:24  *** DJNekkid has joined #openttdcoop.devzone
22:07:44  <planetmaker> Dunno. Ammler do we have IRC logs of the prozone?
22:07:54  <Rubidium> how much spare CPU does the server have?
22:07:56  <Ammler> not accessable
22:07:59  <planetmaker> btw, Rubidium the player wasn't in that channel
22:08:42  <Rubidium> but doesn't he need to be there for the password?
22:08:53  <planetmaker> Rubidium: 30% now. Dunno if it's PS or PZ, though
22:09:01  <PeterT> Rubidium: XeryusTC gave it to him
22:09:11  <planetmaker> Rubidium: we gave it him via mail so he can watch
22:09:37  <planetmaker> I don't desync as spectator
22:09:57  <planetmaker> anyway: we still have CPU. 2...3x as much
22:10:20  <planetmaker> at least
22:11:42  <Webster> Latest update from devactivity: 32bpp-EZ - Revision 10: Add: v10 svn 12350 <> || 32bpp-EZ - Revision 9: Codechange: update svn 12350 <> || 32bpp-EZ - Revision 8: Add: v9 svn 12030 <>
22:12:34  <Ammler> dbg: [net] send failed with error 104
22:13:01  <Rubidium> that's harmless
22:13:32  <PeterT> what does it mean?
22:13:41  <Ammler> thats all I see on the console at his desync
22:13:48  <planetmaker> anything we should change or turn on now, Rubidium ?
22:13:50  <Rubidium> IRC would say [foo] has quit [Connection reset by peer]
22:13:59  <planetmaker> hm
22:14:11  <PeterT> You mean the "desync" was him leaving?
22:14:51  <planetmaker> PeterT: "desync" always means leaving
22:14:52  <Ammler> hmm, no
22:15:04  <Ammler> that dbg is something else anyway
22:15:17  <Ammler> *** leg3nd has left the game (desync error)
22:16:11  <Ammler> there was no docommands from his join until that
22:17:32  <Rubidium> planetmaker: -ddesync=3 (that will enable cache checks, monthly autosaves and dumping of the commands + some other data to a file; all files will be in the autosave directory)
22:17:46  <planetmaker> we have autosaves by the minute anyway
22:18:00  <PeterT> and that doesn't hurt the CPU?
22:18:42  <Ammler> the server is quite powerful
22:20:43  <PeterT> is it a VPS or dedicated?
22:20:43  <Rubidium> planetmaker: the log logs which savegame and it has a 'timestamp' :)
22:20:56  <planetmaker> ah :-)
22:21:23  <planetmaker> I just wonder, if we can catch it again.
22:21:58  <Ammler> I have no idea, how autopilot can handle a value with a "="
22:22:14  <planetmaker> we will see, Ammler :-)
22:22:17  <planetmaker> let's try
22:22:35  <Ammler> maybe just "hardcode" it to autopilot.tcl
22:22:37  <planetmaker> Rubidium: does it write automatically to a file or does it need piping?
22:23:52  <Ammler> planetmaker: just wonder
22:24:03  <Ammler> you can reproduce the desync on pz?
22:24:20  <Ammler> because that is the first thing before you start desync debugging :-)
22:24:31  <planetmaker> Ammler: I can't.
22:24:39  <Ammler> else you might need to debug a week or so :-P
22:24:49  <planetmaker> lalala
22:25:16  <planetmaker> ap+ seems to handle it gracefully. The server spams ;-)
22:25:19  <Ammler> Isn't that mentioned on the desync debugger wiki?
22:25:49  <planetmaker> possibly
22:26:00  <Ammler> well, that is the usual net debug output
22:26:10  <Ammler> which ap+ usually disables
22:26:56  <Webster> Latest update from devactivity: 32bpp-EZ - Revision 20: Codechange: update svn 13706 <> || 32bpp-EZ - Revision 19: Codechange: update svn 13693 <> || 32bpp-EZ - Revision 18: Add: v9 svn 13639 removed longer trains again from main dev stream <>
22:27:29  <Rubidium> planetmaker: it writes automatically
22:27:30  <Ammler> <-- something is there
22:28:23  <Ammler> oh
22:28:26  <Ammler> that is old
22:28:55  <PeterT> what does network_server.tmp hold?
22:29:18  <planetmaker> last savegame sent to a client
22:29:26  <PeterT> oh
22:37:47  <planetmaker> anyway, that doesn't seem to hurt the server really. still only 25% CPU give or take 5%
22:39:28  <Ammler> planetmaker: it doesn't work
22:39:31  <Ammler> no debug dumps
22:41:27  <planetmaker> uh... :-(
22:41:38  <planetmaker> that's why
22:44:50  <Rubidium> andythenorth: FIRS isn't on grfcrawler, or at least not with the GRFID of 0.1.0
22:57:19  <Webster> Latest update from devactivity: 32bpp-EZ - Revision 30: Add: svn 178326, implementation of Zephyris CC algorithm, V12 <> || 32bpp-EZ - Revision 29: Codechange: update to svn 17832 <> || 32bpp-EZ - Revision 28: Codechange: update to svn 17832 <>
22:58:06  <Rubidium> wouldn't it been better to pull straight from the trunk HG?
22:59:25  <planetmaker> hm, what? where?
22:59:33  <Rubidium> 32bpp-EZ
23:00:14  <planetmaker> :-O svn r17832!
23:00:27  <Ammler> yes, looks a bit silly
23:00:30  <Rubidium> 178326 is more interesting
23:00:31  <planetmaker> Dunno about that project...
23:01:50  <planetmaker> I guess I would re-write it for tip
23:01:50  <Ammler> gute Nacht...
23:01:59  <planetmaker> yup. N├Ąchtli.
23:02:13  <Rubidium> nobody's joing my super server :(
23:02:28  <planetmaker> :-)
23:02:42  <Ammler> prefix with "   !   !   ! "
23:03:06  <Rubidium> maybe it's because 95% can't reach me :)
23:03:23  <OwenS> IPv6 only? :p
23:03:29  <Rubidium> yep
23:07:57  *** DJNekkid has quit IRC
23:25:29  *** DJNekkid has joined #openttdcoop.devzone

Powered by YARRSTE version: svn-trunk