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