Config
Log for #openttdcoop.devzone on 6th July 2010:
Times are UTC Toggle Colours
00:04:00  *** KenjiE20 has quit IRC
02:45:07  <Brot6> Redmine - Revision 3828: Extend changes.path and changes.from_path to support longer paths. #5771 (edavis10) @ http://dev.openttdcoop.org/projects/redmine/repository/revisions/3828
02:45:07  <Brot6> Redmine - Revision 3829: Include visible subprojects when checking for available Activity event t... (edavis10) @ http://dev.openttdcoop.org/projects/redmine/repository/revisions/3829
05:45:33  *** Yexo has quit IRC
06:28:44  *** ODM has joined #openttdcoop.devzone
06:51:06  <Brot6> OpenGFX+ - Revision 34:ac84be39d98f: Change: Re-order wagons a bit. And disable all cargo classes... (planetmaker) @ http://dev.openttdcoop.org/projects/ogfxplus/repository/revisions/ac84be39d98f
07:05:48  <Brot6> OpenGFX+ - Revision 35:9b2c5edb27c5: Change: Use the more verbose industry type names instead of ... (planetmaker) @ http://dev.openttdcoop.org/projects/ogfxplus/repository/revisions/9b2c5edb27c5
07:19:53  <Brot6> OpenGFX+ - Revision 36:3a4524c30a66: Doc: This is OpenGFX+. And wrap the readme properly. (planetmaker) @ http://dev.openttdcoop.org/projects/ogfxplus/repository/revisions/3a4524c30a66
07:23:49  <Ammler> hg clone http://dev.openttdcoop.org/projects/ogfxplus <-- does this work?
07:25:46  <planetmaker> hm, probably not
07:26:20  <planetmaker> nope
07:26:46  <Ammler> of course not :-P
07:27:24  <Ammler> s/projects/hg/
07:27:40  <Ammler> or http://hg.openttdcoop.org/ogfxplus
07:30:53  <planetmaker> yep. Thanks :-)
07:32:43  <Brot6> OpenGFX+ - Revision 37:c09a310f57fb: Fix (r36): Use the correct repository path (planetmaker) @ http://dev.openttdcoop.org/projects/ogfxplus/repository/revisions/c09a310f57fb
08:02:00  <Brot6> OpenGFX+ - Revision 38:05cc9fb064b4: Revert (r35): Industry type constants don't quite (yet) work (planetmaker) @ http://dev.openttdcoop.org/projects/ogfxplus/repository/revisions/05cc9fb064b4
09:04:45  <Brot6> OpenGFX+ - Revision 39:a38d8b6d55b8: Change: Re-order and extend .hgignore (planetmaker) @ http://dev.openttdcoop.org/projects/ogfxplus/repository/revisions/a38d8b6d55b8
09:28:33  *** FooBar has joined #openttdcoop.devzone
09:29:06  *** FooBar is now known as Guest2200
09:29:58  *** Guest2200 is now known as FooBar
09:59:14  <planetmaker> Ammler: do we have a working collection / repository for small helpful ba[tch|sh] files?
09:59:52  *** fmauNeko has joined #openttdcoop.devzone
10:00:06  <fmauNeko> Hi
10:00:17  <fmauNeko> Is there an ap+ dev around ?
10:00:32  <planetmaker> FooBar: regarding OpenMSX and the different playback in OpenTTD / media player: any idea whether they use different backends?
10:00:52  <planetmaker> fmauNeko: either dihedral or Ammler might know something
10:00:54  <FooBar> I have no clue
10:01:19  <planetmaker> FooBar: because... I do *think* that those files are valid midi...
10:01:34  <planetmaker> and I'd like to attribute it to 'not my fault' ;-)
10:01:44  <FooBar> I don't think there's a problem with the files
10:02:19  <FooBar> I think it's more a problem of how openttd delivers the files to the OS
10:03:15  <FooBar> That reminds me, Media Player Classic allows to set which output method is used...
10:03:27  <planetmaker> could you try for me, please?
10:03:45  <FooBar> I'm on it
10:13:43  <FooBar> No problems whatsoever. Tried system default, DirectSound and WaveOut; those are the options I have
10:14:00  <planetmaker> hm, interesting
10:14:21  <FooBar> I bet OpenTTD provides the music as one continuous stream to the OS, while any odd media player treats every song as a new stream
10:16:13  <planetmaker> that's what I speculated in the thread :-)
10:17:23  <FooBar> oh well there you go: we speculate the same thing :P
10:17:54  <planetmaker> :-)
10:20:33  <FooBar> Interesting thing (if not already known): problem does not occur when the intro repeats itself in the main menu
10:22:36  *** KenjiE20 has joined #openttdcoop.devzone
10:24:42  <planetmaker> yeah... then no song-specific settings change ;-)
10:33:25  <Rubidium> in the win32 music driver OpenTTD sends a command to play a particular midi file and then (every second or so) checks whether it's still playing. If not, it starts the next one
10:35:17  <Rubidium> in the dmusic driver OpenTTD uses the dmusic API to load a midi file and then passes that on to another dmusic API. Again every second or so it checks whether it's still playing
10:36:03  <planetmaker> so it's send as separate streams, too?
10:36:07  <Rubidium> so... the amount of work OpenTTD does in case of music playing is very limited; it doesn't handle the midis in ANY way, it just passes them on to some functions
10:36:40  <FooBar> Another interesting thing: if you skip all the way to the last song in the list and then back to the first, nothing is wrong
10:36:41  <Rubidium> planetmaker: it doesn't send them as streams! OpenTTD just passes the filename that needs to be played. After that it's all under the hood in Windows
10:36:58  <planetmaker> ok...
10:36:59  <FooBar> however, if you skip from the last to the first directly, it gets screwed up
10:37:19  <planetmaker> what's the last song, FooBar ?
10:37:28  <FooBar> deep down chemistry lab
10:37:44  <planetmaker> hm. can you compile OpenMSX?
10:37:45  <FooBar> Just the default list of OpenMSX
10:38:05  <Rubidium> FooBar: maybe it's caused in the 0.6th second of the song and in one case you skipped it in 0.5s and the other time in 0.7s
10:38:07  <planetmaker> and try whether you have the same effect, if the music set would come without that song? Or different order?
10:38:26  <planetmaker> or what Rb says
10:38:27  <Rubidium> but... I remember someone doing a search for the "dark" song
10:38:49  <planetmaker> yes. But those reports were contradictory
10:39:03  <FooBar> I don't think it's really dark, just the pitch is screwed, like someone is turning the pitch knob at certain moments
10:39:49  <Rubidium> remember: the dark song might not be the cause
10:41:33  <FooBar> removing chemistry lab: nothing solved
10:41:40  <FooBar> I'll now remove everything but one
10:41:53  <FooBar> actually but two: intro plus another one
10:46:11  <FooBar> "busy schedule" might be the culprit
10:47:36  <FooBar> yes, it is at least one culprit: busy scheldule + intro is bad luck
10:47:42  <Rubidium> are "modern motion" / "the fast route" culprits as well?
10:47:50  <FooBar> I'll check
10:48:05  <Rubidium> oh, does -mwin32 / -mdmusic as command line parameter to OpenTTD make any difference?
10:48:07  <FooBar> "keep on rolling" was fine by the way
10:48:27  <Ammler> [12:46] <fmauNeko> [12:00:17] Is there an ap+ dev around ? <-- no meta questions please :-)
10:49:15  <Ammler> there is no ap+ development anymore, except what I commit from time to time to keep it working with openttd
10:49:19  *** fmauNeko has quit IRC
10:49:25  <Ammler> hmm
10:49:27  <planetmaker> :-D
10:49:28  <Rubidium> hahah...
10:49:40  <Rubidium> I was waiting for him to timeout, but this suffices as well :)
10:49:48  <Ammler> :-P
10:49:52  <planetmaker> why were you waiting?
10:50:24  <Rubidium> planetmaker: because Ammler said "no meta questions please", which is a tell for people timing out
10:50:34  <planetmaker> :-)
10:53:20  <FooBar> "modern motion" is ok, but "fast route" is another problem-causer
10:54:08  <Rubidium> okay... that would mean > 16 tracks => problem causer
10:54:37  <Ammler> I really should learn to ignore meta questions completely
10:54:51  <Rubidium> I was first thinking about 1/96 "speed", but if modern motion is correct with only 11 tracks...
10:55:14  <Rubidium> was keep on rolling fine?
10:56:17  <FooBar> yes
10:56:43  <FooBar> if I leave out the two "problems", it's still not good
10:57:17  <Rubidium> and if you leave out tttheme2.mid?
10:58:06  <FooBar> then I cannot hear what the problem is, as that's my benchmark :)
10:58:33  <Rubidium> tttheme2.mid has 17 tracks as well
10:59:22  <Rubidium> (i.e. the same amount of tracks as fast route and busy schedule)
11:00:02  <Rubidium> on the other hand... some of the original midis did have 17 (some even 19) tracks
11:00:20  <Rubidium> anyhow, have you checked -mdmusic / -mwin32 ?
11:00:39  <FooBar> not yet, but I might be on to something now
11:01:44  <FooBar> No I'm not
11:01:57  <FooBar> chemistry lab is another problem
11:02:22  <FooBar> I'll try the commandline options now first
11:03:19  <FooBar> -mdmusic: problem persists
11:04:03  <FooBar> I bet that's the default
11:04:45  <FooBar> -mwin32: takes longer for songs to load, but problem is gone
11:05:33  <FooBar> I'll try that last one again with another problem-causing song
11:07:47  <FooBar> -mwin32 is still good
11:08:04  <Rubidium> so dmusic is causing the problems
11:08:15  <FooBar> as it appears yes
11:08:51  <Rubidium> what does change in the songs? You said pitch, right?
11:09:29  <FooBar> yes
11:09:57  <FooBar> It's not a overall constant pitch change, but only in certain parts of the song
11:11:48  <FooBar> The difference is very clear in the part between 0:20 and 0:30 of the intro song
11:13:42  <FooBar> In the first 20 seconds I don't hear the difference. It might be there, but I don't hear it.
11:15:37  <Rubidium> can't find anything obvious in timidity's output
11:18:36  <FooBar> Shall I continue finding out which songs cause the problem?
11:18:51  <Rubidium> yes please
11:19:08  <FooBar> ok
11:19:10  <Rubidium> the more data the better I'd say
11:19:29  <FooBar> I thought so too. Maybe some pattern can be derived from it
11:33:13  <FooBar> ok, narrowed it down to 7. I'll post a list on the devzone
11:38:49  <Brot6> OpenMSX - Bug #1078 (New): songs causing pitch problems to tttheme2.mid using dmusic (foobar) @ http://dev.openttdcoop.org/issues/1078
11:45:39  <Brot6> #openttdcoop - Revision 83:5b42e655f4be: [Compiler] Change: save debug files like nfo also in sub... (Ammler) @ http://dev.openttdcoop.org/projects/home/repository/revisions/5b42e655f4be
11:54:44  <Brot6> #openttdcoop - Revision 84:e404092028ff: [HG] Fix (r82): ":" is required (Ammler) @ http://dev.openttdcoop.org/projects/home/repository/revisions/e404092028ff
11:58:15  <planetmaker> Ammler: where shall I put this highly un-documented bash-script: http://pastebin.ca/1895447
11:59:23  <Ammler> isn't that part of your newgrf framework?
11:59:46  <planetmaker> Well, I wonder
11:59:51  <planetmaker> Not strictly speaking
12:00:07  <planetmaker> But it can be considered as such
12:00:17  <planetmaker> or it could just be added to some ottdbash. Or alike
12:00:53  <Ammler> yes, I recreated the project ottdbash :-)
12:01:03  <Ammler> and will start pushing my libs
12:01:07  <planetmaker> :-)
12:01:42  <Ammler> but feel also free to simply create a new project
12:02:40  <planetmaker> not worth.
12:04:59  <planetmaker> Ammler: you mean this: http://dev.openttdcoop.org/projects/ottdbash/repository ? ;-)
12:05:22  <Ammler> yes
12:05:46  <planetmaker> Did you click the link? ;-)
12:05:51  <Ammler> yes :-P
12:05:56  <Ammler> I didn't push something
12:06:08  <planetmaker> isn't that a redmine error?
12:06:40  <Ammler> well, yeahowish
12:06:54  <Ammler> if the repo is empty, redmine does show that
12:07:56  <Ammler> but you can use the misc repo for your script
12:12:29  <planetmaker> nah, then better in newgrf_makefile
12:13:00  <Ammler> why don't you use python for that?
12:14:39  <Brot6> Example NewGRF Project - Revision 119:3eba821fb9b5: Change: Add swedishrails to the updated projects (planetmaker) @ http://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/3eba821fb9b5
12:14:39  <Brot6> Example NewGRF Project - Revision 120:d1f0ec2cd87f: Change: Enhance the make_changelog script (planetmaker) @ http://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/d1f0ec2cd87f
14:09:56  *** Seberoth has joined #openttdcoop.devzone
14:28:27  <Brot6> FIRS Industry Replacement Set - Revision 1031:847ab246fd00: Feature: indicate position of fishing... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/847ab246fd00
14:54:31  <Brot6> NewGRF Meta Language - Revision 530:9df64e09934a: Doc: Revise action0 properties of vehicles a bit (planetmaker) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/9df64e09934a
15:40:43  *** ODM has quit IRC
16:18:53  <Brot6> firs: update from r1023 to r1031 done (1 errors) - http://bundles.openttdcoop.org/firs/nightlies/r1031
16:19:13  <Brot6> newgrf_makefile: update from r118 to r120 done - http://bundles.openttdcoop.org/newgrf_makefile/nightlies/r120
16:19:54  <Brot6> nml: update from r529 to r530 done - http://bundles.openttdcoop.org/nml/nightlies/r530
16:20:24  <Brot6> ogfxplus: update from r33 to r39 done - http://bundles.openttdcoop.org/ogfxplus/nightlies/r39
16:20:30  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r562), 32bpp-extra (r36), airportsplus (r52), bros (r12), comic-houses (r70), fish (r386), heqs (r346), nmts (r16), nutracks (r82), opengfx (r464), openmsx (r80), opensfx (r96), snowlinemod (r15), swedishrails (r135), worldairlinersset (r648)
16:23:55  <FooBar> The error on FIRS is due to renum not supporting something newish
16:25:13  <planetmaker> then you should disable the error message
16:25:25  <planetmaker> But that's a feature which is IMHO supported which it complains about
16:25:34  <planetmaker> Are you really sure that it's not a valid one?
16:27:55  <FooBar> the sprite is valid
16:28:07  <planetmaker> well. yes.
16:28:16  <planetmaker> but the bounding box sharing?
16:28:38  <FooBar> that is a reasonably new syntax to allow multiple ground tiles
16:28:52  <planetmaker> grfcodec may be buggy in many places. But this one would be new and I'm moderately confident that nothing in that respect changed recently
16:29:06  <planetmaker> ah... right... ground tils.
16:29:09  <planetmaker> Then yes
16:29:12  <FooBar> see http://wiki.ttdpatch.net/tiki-index.php?page=Action2HousesIndustryTiles, right below the explanation of the extended syntax
16:29:13  <planetmaker> *tiles
16:30:09  <planetmaker> "Since 2.0.1 alpha 55 vcs 3, houses and industry tiles support an extended syntax as well, which looks as follows:" <-- you mean that?
16:30:19  <FooBar> no, below that...
16:30:31  <FooBar> Since OpenTTD r18959 you can draw multiple ground sprites for a tile...
16:30:54  <planetmaker> right. yes
16:31:05  <planetmaker> So disable the error message around where it will be triggered
16:31:55  <FooBar> oki
16:33:35  <planetmaker> It just is better to have not faulty error messages crying around; they'll hide the real ones
16:35:46  <Rubidium> sounds like some "essential" tools need some updating
16:37:15  * Rubidium really wonders whether nml is capable of parsing nfo and compiling that into grf
16:37:24  <planetmaker> it's not
16:38:01  <planetmaker> it can write NFO, but not read it.
16:38:39  <planetmaker> And I guess it'd need a complete new lexical analyser, thus being the same thing as is written now for NML another time
16:39:09  <Rubidium> ah well... too bad then
16:41:37  <planetmaker> though one could of course come out with less work than was already input into NML as one could possibly re-use some parts. But...
16:42:56  <Rubidium> ... it probably wouldn't have the checking stuff which means nforenum is still kinda needed
16:43:22  <planetmaker> yeah... I wonder... how much difference there's between the NFO and the GRF
16:43:27  * planetmaker opens a hex editor
16:43:46  <Hirundo> Also, it could function as a nfo->nml converter
16:44:02  <Hirundo> So existing projects could be 'backported' without too much rewriting
16:44:16  <planetmaker> backported?
16:44:28  <planetmaker> I'd not call it a backward motion but a forward one
16:44:57  <Brot6> FIRS Industry Replacement Set - Revision 1032:bed60a34789c: Fix (r1031): silence some warning and... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/bed60a34789c
16:45:26  <Hirundo> whatever :)
16:48:31  <Rubidium> planetmaker: probably not much, besides "strings" and escapes
16:50:16  <planetmaker> yes indeed. And some start and stop bytes
16:50:33  <planetmaker> -1 * 9 --> 09 00 FF
16:50:54  <planetmaker> describing sprite length
16:51:07  <planetmaker> and a 3-byte header
16:51:57  <Hirundo> planetmaker: Do you know of a file that uses the dos palette?
16:52:54  <planetmaker> I have some, yes. E.g. the TBRS in both versions
16:53:06  * Hirundo looks
16:54:03  <planetmaker> Hirundo, otherwise you can easily use grfcodec in order to conver an existing newgrf
16:54:43  <planetmaker> shall I send you the dos version?
16:54:46  <planetmaker> or both?
16:55:52  <Hirundo> good point about grfcodec, I'll work with that when I get to it
16:56:03  <planetmaker> :-)
16:56:33  <planetmaker> It'd be really cool if we manage to call NML more or less feature-complete still this year :-)
17:05:12  <andythenorth> FooBar: I missed some of the conversation about errors (apolgies)
17:05:30  <andythenorth> if the error is spurious, suppress it locally not globally
17:05:46  <andythenorth> I've been working quite hard to keep FIRS building without error :)
17:05:52  <andythenorth> although Ammler may disagree :P
17:06:01  * planetmaker doesn't disagree
17:06:24  <planetmaker> andythenorth, it's an unavoidable one due to insufficiencies in nforenum
17:06:39  <andythenorth> sounds familiar
17:06:40  <planetmaker> hm.. insufficiencies probably is no word :-)
17:06:46  <andythenorth> it is
17:06:57  <planetmaker> then xchat's dictionary is crap ;-)
17:07:11  <Ammler> andythenorth: we can't care about nfo error messages anymore
17:07:19  <andythenorth> I do
17:07:41  <planetmaker> Ammler, we can and should
17:07:49  <Ammler> ok
17:07:51  <planetmaker> We just need to be really aware of which are real
17:07:59  <Ammler> you can, I don't :-)
17:08:01  <planetmaker> and which are unavoidable and should be muted
17:09:34  <planetmaker> we can't throw away all existing NFO just because there's an emerging alternative way to write newgrfs.
17:10:24  <Rubidium> actually... there's a third option to nforenum error messages
17:10:40  <Rubidium> and it's starting to become more attractive by the day
17:10:53  <Ammler> fixing renum :-)
17:11:08  <Rubidium> kinda yes... a fork
17:11:57  <Rubidium> or someone getting commit access to the official repository
17:12:30  <Ammler> I remember such a discussion already 2-3 months ago :-)
17:16:57  <Ammler> I would be happy to host a fork, planetmaker feared some "inter"-project troubles
17:18:01  <Ammler> but we can simply convert the svn repo and if the "real" svn devs return, let them use the modifications and delete our fork
17:21:21  <Ammler> http://hg.openttdcoop.org/nforenum/ :-)
17:24:07  <planetmaker> it'd certainly improve the situation a lot
17:24:43  <planetmaker> All I said is to not do that with too big haste.
17:24:54  <planetmaker> But DaleStan's absence is getting long...
17:25:16  <Rubidium> I'm trying to get some contact with patchman at the moment, though he hasn't been "acting" in #tycoon for a long time it seems
17:25:33  <planetmaker> :-)
17:26:43  <planetmaker> who all has access to their repos?
17:27:08  <planetmaker> doesn't JGR and Lakki also have access? They might be able to help along, too
17:28:09  <Ammler> > hg log --template="{author}\n" | sort | uniq
17:28:10  <Ammler> DaleStan
17:28:12  <Ammler> minime
17:28:13  <Rubidium> anders, csaboka,
17:28:13  <Ammler> patchman
17:28:18  <Rubidium> eis_os
17:28:21  <Ammler> hmm
17:28:22  <Rubidium> jgr
17:28:23  <Rubidium> lakie
17:28:27  <Rubidium> mek
17:28:28  <Rubidium> minime
17:28:31  <Rubidium> orudge
17:28:34  <Ammler> does it have limit :-o
17:28:36  <Rubidium> steven_h
17:28:39  <Rubidium> terom
17:28:43  *** Alberth has joined #openttdcoop.devzone
17:28:45  <Rubidium> uzurpator
17:28:55  <Ammler> ah, repo access
17:29:02  <Rubidium> or... those are the ones that have committed to repository
17:29:11  <Rubidium> and I assume everyone has access everywhere
17:40:47  <planetmaker> quite likely
17:45:51  *** frosch123 has joined #openttdcoop.devzone
17:50:45  <Hirundo> Tip: do not use openttd as source for your palette data
17:55:11  <planetmaker> :-)
17:55:11  *** FooBar has quit IRC
17:55:48  *** FooBar has joined #openttdcoop.devzone
18:04:19  *** ODM has joined #openttdcoop.devzone
18:39:41  <Brot6> FIRS Industry Replacement Set - Revision 1033:898886ecaa3b: Feature #533: Sand pit snow sprites (... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/898886ecaa3b
18:39:41  <Brot6> FIRS Industry Replacement Set - Feature #533 (Closed): Winter sprites for the sandpit (foobar) @ http://dev.openttdcoop.org/issues/533#change-2829
18:41:17  <Alberth> is  'cargo_type' a number n where 0 <= n <= 255?
18:41:52  <Alberth> ie #1077 fails due to pushing 256 into cargo_type, but is eg 252 valid?
18:43:11  <Alberth> ie is it useful to keep a lower and upper limit with each action0property ?
18:43:47  <planetmaker> Alberth: it's something like IORE I was told yesterday
18:43:49  <planetmaker> and it works
18:43:57  <planetmaker> a cargo label
18:44:32  <planetmaker> which then *somehow* is - afaik - changed to a 0 ... 64 entry in the cargo slots
18:44:46  <Brot6> #openttdcoop - Revision 85:23d2d790152a: [HG] Update to templates of mercurial 1.5.4 (Ammler) @ http://dev.openttdcoop.org/projects/home/repository/revisions/23d2d790152a
18:44:46  <Brot6> #openttdcoop - Revision 86:249df8b399db: [HG] Move hg-tmpl-coop to mercurial/templates (Ammler) @ http://dev.openttdcoop.org/projects/home/repository/revisions/249df8b399db
18:44:49  <Alberth> I am more interested in what nml2nfo should do in such a case
18:45:17  <Alberth> I can obviously check for < 256 for 1 byte, but should it be more precise than that?
18:45:26  <planetmaker> would make sense
18:45:30  <planetmaker> let me look
18:45:47  <Rubidium> isn't the cargo_id just a local ID?
18:45:58  <Rubidium> and not the global 4 byte thing?
18:46:07  <Alberth> it's a 1 byte thing
18:46:26  *** DJNekkd_NL is now known as DJNekkid
18:46:41  <planetmaker> yes
18:46:44  <Alberth> at least that is what nml2nfo is thinking
18:46:46  <planetmaker> http://wiki.ttdpatch.net/tiki-index.php?page=CargoTypes <- the column 'B'
18:47:04  <planetmaker> Rubidium: the property is not a label. NML just allows to use it
18:48:04  <DJNekkid> yey, 1-0 :D
18:48:22  <Rubidium> ooh... Uruguay has scored?
18:48:26  <DJNekkid> no :D
18:48:32  <DJNekkid> 0-1 then :D
18:48:32  <Rubidium> then it's not 1-0
18:48:34  <andythenorth> evening
18:48:41  <Rubidium> and they're not complying with my wishes
18:48:42  <DJNekkid> but its 1-0 to "us" :)
18:49:25  <Rubidium> oh yes... If the NL wins, us Europeans have won the world cup and they can cancel the rest of the games
18:49:32  * andythenorth still cares about nfo errors :D
18:49:48  <andythenorth> nml doesn't invalidate >20k lines of nfo :P
18:50:01  <Alberth> yet :p
18:50:24  <Brot6> 2cc train set - Revision 563:c7aec8e83b03: Fix: #1067 : (DJNekkid) @ http://dev.openttdcoop.org/projects/2cctrainset/repository/revisions/c7aec8e83b03
18:50:24  <Brot6> 2cc train set - Bug #1067 (Closed): AI special flag: optimized for passengers set for all engines (DJNekkid) @ http://dev.openttdcoop.org/issues/1067#change-2830
18:50:27  <planetmaker> Alberth: what I just wonder is whether the cargo_slot can be re-defined
18:50:42  <planetmaker> I guess so... but I don't quite know. But maybe andythenorth does:
18:50:53  <Alberth> I wouldn't know
18:51:05  <andythenorth> planetmaker: what is the question? - I just joined
18:51:05  * Rubidium wonders to what extent NML to NFO is like C to assembler
18:51:12  <planetmaker> http://wiki.ttdpatch.net/tiki-index.php?page=CargoTypes <-- andythenorth the entries as cargo slots. How and where can they be re-defined?
18:51:40  <planetmaker> E.g. like RV property 10
18:51:44  <andythenorth> planetmaker: what's the context / aim?
18:51:57  <planetmaker> can the meaning of that property 10 be changed by means of... cargo translation table or so?
18:52:00  <Alberth> Rubidium: most likely not enough
18:52:34  <Alberth> ie the underlying AST is very close to NFO
18:52:35  <Rubidium> Alberth: yeah... asm { #include "foo.asm" }
18:52:41  <planetmaker> andythenorth: aim: understanding what NML should do / allow :-)
18:53:05  <andythenorth> planetmaker: (assuming I understood correctly)....if a cargo translation table is defined, then prop 10 refers to the cargo TT, not the default slots
18:53:13  <andythenorth> same for refit masks
18:53:54  <planetmaker> I mean... you surely use it in HEQS, do you?
18:53:58  <andythenorth> yes
18:53:59  <andythenorth> and FISH
18:54:10  <andythenorth> do you want a worked example?
18:54:50  <andythenorth> http://dev.openttdcoop.org/projects/heqs/repository/entry/sprites/nfo/heqs_header.pnfo
18:54:50  <planetmaker> well... the question is, what value range for prop 10 will be acceptable.
18:55:00  <andythenorth> I'm not sure
18:55:02  <planetmaker> 0 ... 32? or 0...64?
18:55:12  <andythenorth> well no, it's a byte, so 0-255 I'd assume
18:55:29  <andythenorth> otherwise you need a dev to check actual openttd code
18:55:36  <andythenorth> from a newgrf side it's a black box :P
18:56:10  <andythenorth> ttdp wiki page has no info on limit of cargo table
18:57:22  * Alberth assumes it is a byte for now
19:01:48  <planetmaker> andythenorth: I don't even think anymore it has cross-talk with the table. Or it's not properly documented...
19:01:55  <planetmaker> which wouldn't be first either.
19:03:03  <andythenorth> what does cross-talk mean in this context? :)
19:03:12  <frosch123> planetmaker: andythenorth: the default cargo of a vehicle is a cargoslot, not a cargobit. that is, it is not translated, and totally useless.
19:03:28  <planetmaker> ok... So really pointless?
19:03:35  <frosch123> you can only set it to passenger, mail, and <first refittable>
19:03:36  <planetmaker> when and where is it used?
19:04:00  <andythenorth> frosch123: that would make sense
19:04:00  <frosch123> what?
19:04:03  <planetmaker> hm... what is the 'first refittable'?
19:04:12  <frosch123> FF
19:04:13  <andythenorth> depends on the refittable classes
19:04:18  <planetmaker> eh?
19:04:25  <andythenorth> meh
19:04:30  <andythenorth> depends on the refit mask
19:04:36  <planetmaker> yes, of course
19:04:37  <frosch123> n/a	n/a	FF	Use first refittable cargo type as default cargo
19:04:46  <andythenorth> basically it's a horrible structure to understand
19:05:06  <planetmaker> ok... useless.
19:05:28  <planetmaker> Alberth: but so you have the range: 0,1, FF ;-)
19:05:41  <frosch123> it's part of grf version 8, so in ten years...
19:05:46  <planetmaker> or ... we should possibly set it always to FF
19:06:04  <Rubidium> frosch123: nah... 9 years... that way we can get support for it in 2.0
19:06:09  <frosch123> "0" and "1" are only valid as they are not changed usually
19:06:23  <planetmaker> Does anyone see detriment in setting it always to FF?
19:06:26  <Rubidium> oh shoot... did I spoil the future versioning there?
19:06:43  <frosch123> planetmaker: if you set it to ff and the refitmask is empty (e.g. engines) the vehicle is not available iirc
19:07:05  <planetmaker> hmpf. So... not setting it at all?
19:07:11  <frosch123> i am not entirely sure about that though
19:07:12  <Alberth> so that means nml can do much more checking on such property values :)
19:07:44  <planetmaker> :-)
19:10:06  <frosch123> the save method seems to be to not set the default cargo at all if capacity is 0
19:10:31  <DJNekkid> 1-1 ... insane shot!
19:11:09  <Ammler> \o/ :-)
19:11:17  <frosch123> Rubidium: how do you get to 9?
19:12:19  <Rubidium> we need some time to implement and test it
19:12:37  <frosch123> oh, true
19:12:44  <Rubidium> release 2.0 in 2020, so mid 2019 grfv8 needs to be started
19:12:50  <frosch123> obiwan on my side :)
19:13:00  <Brot6> NewGRF Meta Language - Revision 531:ca35bbd00bd4: Doc: Document Action0Property instance variables. (Alberth) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/ca35bbd00bd4
19:13:00  <Brot6> NewGRF Meta Language - Revision 532:2c28387e956f: Fix: Add value size check to action 0 propertie... (Alberth) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/2c28387e956f
19:16:54  * andythenorth might wait for grfv8 before starting another set
19:17:35  <Alberth> that should give you some time to finish the current ones :)
19:18:43  <Rubidium> Ammler: what did we decide was the problem for grfcodec incorrectly compressing stuff?
19:18:43  <andythenorth> spending another 9 years on FIRS is a scary thought :o
19:19:09  <frosch123> Rubidium: you mean the old clipping problem?
19:19:12  <Ammler> gcc 4.5
19:19:52  <Rubidium> frosch123: "Error: invalid compression, data diff at 275 of 576 bytes, trying without it for this sprite
19:19:57  <Rubidium> ^that^
19:21:20  <Brot6> NewGRF Meta Language - Bug #1077: internal error, assertion of byte value (Alberth) @ http://dev.openttdcoop.org/issues/1077#change-2831
19:22:10  <Rubidium> interesting... I can't reproduce it anymore
19:23:19  <Rubidium> which would mean it's likely fixed in the 4.5 branch
19:24:52  <Ammler> hmm
19:26:37  <Rubidium> the Debian gcc package maintainers are generally quite active; when (important) enough bugfixes have been committed to the release branch they just build a new package and push that out
19:27:01  <Rubidium> so I'm using the gcc 4.5 branch r161383 (20100625)
19:28:04  <Ammler> I fear, that won't go to suse 11.3 anymore
19:28:13  <Ammler> as the release is in 10 days?
19:28:31  <Rubidium> they shouldn't release with gcc 4.5 as default then
19:29:24  <Ammler> well, will gcc self release something?
19:30:39  <Rubidium> yes, they'll release gcc 4.5.1
19:31:46  <Ammler> then we can use that, if suse self doesn't :-)
19:34:15  <Ammler> 4.5.0 20100604
19:34:30  <Rubidium> in any case you could make a bug report about grfcodec being horribly broken (unfit for release) due to a broken gcc and file a bug report at the gcc packager
19:34:59  <Ammler> you know, which commit it fixes?
19:35:11  <Rubidium> no
19:35:35  <Ammler> well, at least it is something after 6.4. :-)
19:35:40  <Rubidium> although a guess would be any of the PR *-optimization/* commits
19:35:54  <Rubidium> like
19:35:55  <Rubidium> PR rtl-optimization/42461
19:36:04  <Rubidium> PR tree-optimization/44258, PR tree-optimization/44423
19:36:09  <Rubidium> PR tree-optimization/44508, PR tree-optimization/44507,
19:36:40  <Rubidium> yes, that were the optimisation fixes mentioned in my the package's changelog
19:38:05  <Ammler> hmm, I mgiht also be able to define a legacy gcc
19:58:04  <DJNekkid> 1-2 :D
20:01:21  <DJNekkid> 1-3
20:11:13  <Rubidium> hmm... patchman doesn't care whether someone gets svn access or it gets forked. He also says he isn't developing those tools anymore so probably not the right person to ask anyway
20:11:54  <planetmaker> he
20:18:35  <Rubidium> lets see what dalestan thinks of this (assuming his email address is still current)
20:20:13  * andythenorth should work on FIRS 0.3
20:20:15  <andythenorth> but is tired
20:20:39  <DJNekkid> 2-3
20:31:31  *** Alberth has left #openttdcoop.devzone
20:50:23  <FooBar> andythenorth: are you around?
20:50:29  <andythenorth> hi hi
20:50:37  <andythenorth> assumed you were watching football
20:51:06  <FooBar> match is finished, but yes I watched
20:51:57  <FooBar> anyways, I was wondering why the syntax of the bottom green part is correct nfo: http://dev.openttdcoop.org/projects/firs/repository/diff/sprites/nfo/i_oilplatform.pnfo?rev=01baec6c16ba&rev_to=a3977346e21c
20:52:19  <FooBar> Is this something new?
20:52:46  <andythenorth> hmm
20:52:48  <FooBar> I would expect something like -1 * 0 03 09 04 19 1A 1B 1C FF FF FF FF FF FF FF FF
20:52:50  <andythenorth> I'm not sure
20:53:02  <FooBar> well, you made it ;)
20:53:14  <Rubidium> the * is basically what tells whether the line has a new sprite
20:53:23  <FooBar> since r617 by the way
20:53:24  <Rubidium> otherwise the newline is just interpreted as a whitespace
20:54:45  <FooBar> I know about the * ;)
20:54:47  <andythenorth> I don't remember making that :)
20:55:17  <FooBar> it basically were three seperate action3s, but now consolidated into one.
20:55:45  <FooBar> While that is fine to do, I don't understand why this particular syntax works...
20:56:07  <andythenorth> me neither
20:56:22  <FooBar> good, then we're on the same page
20:57:02  <andythenorth> does it appear to work?
20:57:28  <FooBar> well, renum doesn't complain and the syntax is used in multiple industries
20:57:48  <FooBar> I didn't dare to touch it, because I didn't understand
20:58:40  <FooBar> for the coal mine you did something different: http://dev.openttdcoop.org/projects/firs/repository/revisions/01baec6c16ba/diff/sprites/nfo/i_coalmine.pnfo
20:58:42  <andythenorth> hmm
20:59:06  <FooBar> also for the complete revision: http://dev.openttdcoop.org/projects/firs/repository/revisions/01baec6c16ba
20:59:37  <andythenorth> it's possibly a mistake that happened to work
20:59:50  <FooBar> could be, it just looks like something is missing
21:01:38  <andythenorth> wouldn't be a bad idea to change it
21:02:50  <FooBar> I bet I can remove the complete action3, as it references nothing in the industry file
21:03:03  <FooBar> It might reference something in some other industry
21:05:12  *** frosch123 has quit IRC
21:05:30  <andythenorth> FooBar: isn't it referencing the tiles?
21:06:14  <FooBar> take this oil platform for instance
21:06:50  <FooBar> it uses the tiles from ttd, which only have new properties defined via action0, but no new graphics nor any callbacks
21:08:10  <FooBar> wait, maybe in this template...
21:09:30  <FooBar> no, that's about the industry itself, not the tile...
21:15:06  <andythenorth> hmm
21:15:36  <andythenorth> there was a load of varaction 2 to handle stockpile limits, but that was since removed
21:15:53  <FooBar> yes, it seems to be leftovers if you ask me.
21:16:09  <FooBar> Removing it didn't hurt the oil platform at first glance
21:17:46  <FooBar> but anyways, I have to watch tv again
21:18:02  <FooBar> if you have to say anything, I'll read it back in an hour or so ;)
21:18:14  <andythenorth> bed time for me :)
21:18:36  *** andythenorth has left #openttdcoop.devzone
21:19:46  <Rubidium> who has destroyed the css for http://hg.openttdcoop.org/?sort=lastchange ?
21:23:08  <planetmaker> hm
21:23:46  <planetmaker> was there ever one?
21:26:58  <Rubidium> well... it looked somewhat pretty in the past
21:27:10  <Rubidium> now it's just html 1.0-ish
21:42:09  <planetmaker> hm... I guess that's a question for Ammler ^
21:44:26  <Brot6> Redmine - Revision 3830: Force the default value of path to be set on the Change model class. #5771 (edavis10) @ http://dev.openttdcoop.org/projects/redmine/repository/revisions/3830
21:44:38  <Ammler> Rubidium: fixed :-)
21:45:07  <planetmaker> Ammler: how do we update the description and author contact there?
21:45:27  <Ammler> you don't :-(
21:45:42  <Rubidium> .hgrc?
21:45:57  <Ammler> yes, but that isn't part of the repo
21:46:11  <Rubidium> sorry... .hg/hgrc
21:46:20  <Ammler> planetmaker: any specific repo you like to edit?
21:46:57  <planetmaker> not really. But I'd update some
21:47:14  <Ammler> well, feel free to edit .hg/hgrc :-)
21:47:29  <Ammler> (on the server)
21:47:36  <planetmaker> of course :-)
21:47:50  <planetmaker> he... it could update them from the redmine database ;-)
21:48:01  <planetmaker> project description and managers
21:48:42  <Ammler> it does
21:49:00  <Ammler> like https://push.openttdcoop.org/nml
21:49:28  <Ammler> well, feel also free to provide some script or update hgredmine
21:49:49  <Ammler> that is why hgredmine is still not running automatically
21:53:10  <planetmaker> hm... right. So it's probably on the feature-request list. :-)
21:53:34  <Ammler> I would like to run everything over the proxy
21:53:45  <planetmaker> though 'Project owner' is a bad owner name ;-)
21:53:58  <Ammler> :-)
21:54:33  <planetmaker> anyway... night time for me
21:54:41  <planetmaker> good night :-)
21:54:47  <Rubidium> ieuw... it's passworded :(
21:54:59  <planetmaker> you have a password
21:55:01  <Ammler> Rubidium: use your redmine credentials
21:55:01  <Rubidium> and I've got no clue what my password would be (if I have any)
21:55:03  <planetmaker> your redmin login
21:55:29  <Ammler> but you need to be member of the project
21:55:46  <planetmaker> then indeed it doesn't make much sense to pw-protect *that* page
21:56:11  <planetmaker> anyway...
21:56:15  <Ammler> :-D
21:56:26  <Rubidium> ah, that explains why my password didn't work
21:56:34  <Ammler> notice "push."
21:57:05  <Ammler> I just liked to show you, it might be possible to connect redmine with hgweb
21:57:19  <Rubidium> yeah... so it needs to be psychic and know that it's me!
21:57:54  <Ammler> Rubidium: you can use e.g. https://push.openttdcoop.org/opengfx
22:53:30  *** FooBar has quit IRC
23:10:15  *** ODM has quit IRC
23:48:05  *** Seberoth has quit IRC

Powered by YARRSTE version: svn-trunk