Log for #openttdcoop.devzone on 2nd August 2010:
Times are UTC Toggle Colours
00:20:13  *** frosch123 has quit IRC
00:54:38  *** ODM has quit IRC
02:01:08  *** Seberoth has quit IRC
07:30:08  *** Alberth has joined #openttdcoop.devzone
07:58:53  *** Seberoth has joined #openttdcoop.devzone
08:44:54  *** ODM has joined #openttdcoop.devzone
09:42:03  *** frosch123 has joined #openttdcoop.devzone
10:43:33  *** KenjiE20 has joined #openttdcoop.devzone
10:50:42  <Brot6> OpenMSX - Bug #1078: songs causing pitch problems to tttheme2.mid using dmusic (Ammler) @
10:55:37  <frosch123> hmm, my knowledge about ttdp's newgrf behaviour is below the floor :s
10:55:52  <frosch123> anyone knows, whether action4 is processed similiar to actionb?
10:56:12  <frosch123> that is "any" language has to go first, as later action4 just check the language and overwrite the text
10:56:21  <frosch123> so if "any" would be last it would always win
10:56:55  <Brot6> Base Costs Mod - Presets - Revision 14:414b2e41b009: Fix (r10): accidentially committed backup files (Ammler) @
10:58:45  <Ammler> at least that is what the spec tells, afaik
10:59:40  <frosch123> ah, true, overread that
11:00:39  <Ammler> iirc as we talked about the language support, we discused that here once, that 7F needs to be proceed first because of that
11:01:06  <Ammler> but long ago, pm and foobar would know it better :-)
11:01:22  <Ammler> isn't that the case in openttd?
11:01:25  <frosch123> but that also means that action14 has to go past action8 :)
11:02:36  <frosch123> no, ottd stores the texts separately
11:02:43  <Ammler> I assume, that is ment to speedup scanning, so you can quit right after Action8, as that is only oncde
11:02:47  <frosch123> you can change language without reloading newgrfs :)
11:02:52  <Ammler> Action14 can be there multiple times
11:03:12  <frosch123> but you could also say that action14 needs to go straight after action 8
11:03:25  <frosch123> and stop whenever you have an action8 and no further 14
11:16:19  <Rubidium> I would say: keep it as it is. TTDP has implemented lots of things that are troublesome for us, and this shouldn't be that troublesome for them; just store the last information of the language that matches best *and* keep information on which language that is so "inferior" later languages don't overwrite it
11:23:04  *** FooBar has joined #openttdcoop.devzone
11:23:48  <Brot6> OpenMSX - Bug #1078: songs causing pitch problems to tttheme2.mid using dmusic (foobar) @
11:23:59  <FooBar> so no luck :(
11:24:35  <Ammler> that is what Rubidium already feared
11:25:09  <Rubidium> though it tttheme2.mid now "fixed", or is that still broken as well?
11:25:34  <FooBar> either that, or other songs are broken as well
11:25:46  <Rubidium> s/it/is/
11:26:23  <FooBar> If tttheme2 is broken, it should be able to break itself, right?
11:26:42  <Rubidium> not necessarily
11:27:20  <Rubidium> if it depends on some value being N and it doesn't change that but another midi changes the N, then it's a broken tttheme2 triggered by the other song
11:29:51  <FooBar> well, it might not just be tttheme2 with pitch problems; other songs could experience that as well, but I never looked into that
11:31:43  <FooBar> it took me long enough to actually hear what was going on in tttheme2; I'm pretty much an audio-noob at that. I also don't hear mp3 loss in anthing from 128 kbps, while others swear they hear it even when not having heared the original in a while
11:36:57  <FooBar> one you know where to look for the pitch problem, you'll hear it instantly though
11:39:29  <Rubidium> agreed, so it's still broken
11:55:31  <FooBar> yes, something indeed is still broken
11:56:30  <Brot6> OpenMSX - Bug #1078: songs causing pitch problems to tttheme2.mid using dmusic (Rubidium) @
11:57:22  <Brot6> Metro Track Set - Feature #1199 (New): add action 14 (foobar) @
12:00:48  <Brot6> Base Costs Mod - Revision 20:cecd23dca966: Fix (r15): unify factor unset and 0 (Ammler) @
12:53:40  <Ammler> FooBar: <-- close the version after release or set a date of the release
12:54:01  <FooBar> oh, but that's not released yet ;)
12:54:02  <Ammler> so it does disapear from default roadmap view
12:54:10  <Ammler> oh
12:54:13  <Ammler> mäh
12:54:15  <Ammler> .1 :-P
12:54:51  <FooBar> I set "locked" plus a date for the released version. Should I make that "closed"?
12:55:36  <Ammler> nah, it is ok, I meant it is the released 0.9.0
12:56:00  <FooBar> that one is here with a date :) :
12:56:36  <FooBar> but thanks for your concern
12:57:02  <Ammler> I just saw 100% done, and didn't check the version string :-P
12:57:17  <FooBar> I'm glad you keep an eye open, as I sometimes /do/ make silly mistakes. Like backup to the wrong repo for instance :P
12:57:45  <Ammler> dunno, how I came there :-)
12:57:59  <Ammler> serving on the DevZone...
13:02:00  <FooBar> by the way, is it correct that I do not have SSH access to the server any more (I don't mean for just hg, but the more advance access I had previously)?
13:02:08  <FooBar> Not that I need it back or anything
13:02:36  <FooBar> Just wondering, as I couldn't get it to work in search of the website access log yesterday
13:07:20  <Yexo> FooBar: you ssh key is under .ssh/hg-repos/, not under .ssh/full/ (but I can't tell you what exactly the difference is)
13:08:11  <FooBar> thanks Yexo; I once had one in /full, but this is all I need to know
13:08:24  <Yexo> according to the wiki keys in .ssh/hg-repos/ are restricted to hg repos only
13:08:32  <FooBar> exactly
13:10:13  <FooBar> I once had full access to be able to create repos and give new users repo access, but that is not needed any more with http push and auto creation of repo
13:11:24  <FooBar> I was mainly interested in if I did something wrong yesterday :)
13:19:48  <Ammler> hmm, we might cleandup your key during inactivity :-)
13:21:45  <Ammler> both keys are in hg-repos now
13:22:39  <Ammler> again in full
13:23:34  <Ammler> you like to setup a header file for bundles?
13:35:54  <FooBar> hmm, that wasn't really needed, but now that I can I might indeed just as well set up some header files this week :)
13:51:13  <Ammler> don't hurry with that...
13:51:18  <FooBar> I'm not
13:51:30  <FooBar> are you planning something?
13:51:34  <Ammler> should support that
13:51:58  <Ammler> but as I setup that, we had the troubles with apache and I changed to nginx
13:52:47  <Ammler> another idea was to generate the index file completely
13:54:38  <FooBar> generating it could give you something that OpenTTD website had, which auto-selects most likely download
13:55:21  <FooBar> I would like something like that, as for most users it is currently a bit difficult to see which file they need
13:56:32  <Ammler> yes, exactly, but I have troubles to extract the needed scripts from :-)
13:57:07  <FooBar> let me have a look...
13:57:07  <Ammler>
13:57:34  <Ammler> might need django anyway...
13:58:34  <FooBar> depends if you want to use the exact thing or maybe port it to php or something
13:59:03  <FooBar> This is basically the download page, but it's full of django stuff:
13:59:40  <FooBar> I might be persuaded to invent something someday
14:02:14  <FooBar> listing the zip with the grf as suggested download by default shouldn't be too complicated
14:02:37  <FooBar> I'll continue on NoGFX first though
14:15:03  <Ammler> I would like to have a static html page finally
14:15:32  <Ammler> so we can trash apache
14:15:56  <Ammler> nginx doesn't have a nice autoindex
14:18:49  <FooBar> you do run PHP with nginx, right?
14:22:05  <Brot6> NewGRF Meta Language - Revision 639:f09cf5a265e2: Feature: Dynamic setting of base costs. This sh... (Hirundo) @
14:22:05  <Brot6> NewGRF Meta Language - Revision 640:1742fb7ae29e: Codechange: Make the format and naming of the s... (Hirundo) @
14:22:52  <FooBar> hmmm... NoGFX might be a bit of a lost cause
14:23:49  <FooBar>
14:23:57  <Rubidium> it's becoming 'quite-a-lot-of-gfx' pretty quickly?
14:24:33  <FooBar> yes, there needs to be a sprite everywhere to stop it from glitching
14:25:10  <FooBar> and since groundsprites are not drawn underneath everything, that still leaves a lot of sprites
14:26:00  <Rubidium> reminds me on "newmap"
14:26:30  <FooBar> I suppose OpenTTD can't draw sprite 1004 (black map edge sprite) underneath everything?
14:28:34  <FooBar> "undrawing" the windows is basically the problem
14:29:25  <Rubidium> it can, at the cost of making drawing like 40% slower
14:29:38  <Ammler> you should replace the clima sprites with something like "DOWN LOAD OPEN GFX"
14:30:04  <Ammler> or BASE SET
14:30:44  <FooBar> hmmm, that doesn't seem to be like a good plan then. I have no clue how the drawing system works, so I have no clue what could be a good fix
14:30:58  <FooBar> ammler: yes, I had something like that in mind
14:31:37  <Ammler> how did you replace the ground sprites?
14:32:27  <Ammler> did you change from opengfx to nogfx?
14:32:53  <Ammler> that "can" glitch, as that doesn't make sense anyway
14:32:55  <FooBar> ground sprites are currently not replaced
14:33:28  <FooBar> I planned to replace them with black, but since a lot of sprites need to be black now...
14:34:09  <Ammler> don't get it
14:34:09  <Rubidium> OpenGFX's pure black sprites might do quite a lot of the trick and with the best pixel "compressor" it might not be that large (although I might be completely wrong about the file size)
14:34:33  <Rubidium> there are ofcourse many things that can still be really small transparent sprites
14:34:42  <Ammler> what happens if you replace all sprites with a one pixel blue?
14:34:45  <FooBar> it's currently a little over 400 kB
14:35:04  <FooBar> which is IMO still too much, but I can only see it grow
14:35:18  <Rubidium> yep
14:35:27  *** Seberoth has quit IRC
14:35:34  *** Seberoth has joined #openttdcoop.devzone
14:35:43  <Ammler> how can transparent sprites glitch?
14:35:50  <FooBar> If I replace all with one blue pixel, the windows will glitch as shown in the screenshot
14:36:14  <FooBar> basically the background never gets updated, only overdrawn with sprites
14:36:33  <Ammler> ah, I see
14:36:42  <FooBar> having all sprites transparent reveals this background
14:37:37  <FooBar> so I can only see it work if OpenTTD somehow can clear this background
14:37:40  <Ammler> and grfcodec does include every "black sprite" again, also if you use the same in the nfo
14:37:55  <FooBar> yes, it does
14:38:17  <FooBar> I defined everything EMPTY now, after your(?) example
14:40:19  <FooBar> I'll continue to remove everything but the GUI to make a sort of "proof of concept". The OpenTTD devs can then see if it's worth to have OpenTTD clear the background and include NoGFX with OpenTTD, or that they don't want it at all :P
14:42:38  <Ammler> in that case, it should be loaded as alternative, if no base set is around but not listing it in the menu
14:42:45  <Ammler> and show a red box like they do for sound
14:43:09  <Ammler> maybe already automatically open the bananas gui :-P
14:43:35  <Ammler> with only basesets listed
14:45:19  <FooBar> that's basically the idea. It would allow OpenTTD to start with text and GUI required to access content-download
14:49:48  <Ammler> well, theoretically, opengfx is GPL, so it could be included already
14:51:13  <FooBar> true, but its sheer size would put too much of a strain on the servers
14:51:37  <FooBar> there's a topic about it at tt-forums
14:52:31  <Ammler> try to find another game with size < 10MB
14:52:48  <Ammler> (which so rocks)
14:53:55  <Ammler> well, 11 MB with ogfx
14:55:10  <FooBar> try to convince devs to include it ;)
14:56:52  <Ammler> hmm, I guess, that isn't our job, our job is to give them a nice base set :-P
14:57:09  <Ammler> what they do with it...
14:57:50  <Rubidium> including graphics (especially with a different release cycle) in the OpenTTD download package isn't that "good"
14:57:52  <Ammler> I would extend the search paths for data...
14:58:42  <Rubidium> it means that if you would fix an "important" graphical glitch it will only be the next stable release of OpenTTD where that glitch is fixed instead of all stable releases just minutes after your fixed package is released
14:59:18  <Ammler> well, it means, that you will update opengfx right after installing openttd
14:59:32  <Ammler> instead that you need to download it
15:00:56  <Ammler> I mean, the base set can only have glitches, not really things which breaks or crashes
15:01:05  <Ammler> like it has now
15:01:16  <Ammler> and almost nobody noticed
15:36:18  <FooBar> hmmm 270 kB is about the least I can do
15:36:32  <FooBar> anyone wants a test version?
15:37:42  <FooBar> here is download:
15:37:53  <Brot6> OpenGFX - nogfx-nogfx.tar (foobar) @
15:53:19  <FooBar> Ammler: I made NoGFX as a branch in OpenGFX. Shall I commit that to OpenGFX repo?
15:53:44  <Ammler> feel free to :-)
15:53:51  <Ammler> I don't think, it hurts
15:54:25  <FooBar> probably not. Even if we don't use it any time soon, it's just archived there nicely
15:54:40  <Ammler> yes, it should not trigger nightly
15:55:06  <FooBar> well, here goes :)
15:55:38  <Ammler> but do not tag yet
15:56:12  <FooBar> I wasn't going to. It's nothing that is release-worthy at the moment anyways
15:56:23  <Ammler> the makefile does have branch support, but I fear, the publisher doesn't
15:56:41  <FooBar> hmmm "abort: push creates new remote branches: nogfx!"
15:56:44  <Ammler> so it would replace the opengfx
15:56:54  <Ammler> hg push -f
15:57:14  <Ammler> one case, where -f is ok :-)
15:57:20  <FooBar> :)
15:57:37  <Brot6> OpenGFX - Revision 470:6d2114891bd9: Branch: NoGFX (foobar) @
15:57:37  <Brot6> OpenGFX - Revision 471:020739620020: Feature: remove complete sprite blocks that are not needed (foobar) @
15:57:37  <Brot6> OpenGFX - Revision 472:a8f3d68c06d3: Update: readables (foobar) @
15:57:37  <Brot6> OpenGFX - Revision 473:b41a7639f0fe: Fix (r471): nogfx1_base was broken (foobar) @
15:57:40  <Brot6> OpenGFX - Revision 474:7710cc022c50: Feature: reduce more sprites (foobar) @
15:57:43  <Brot6> OpenGFX - Revision 475:ee648444d34a: Feature: instructions how to get OpenGFX on climate buttons (foobar) @
16:05:50  <Ammler> FooBar: did you try to start a game with it?
16:08:31  <Brot6> OpenGFX - Feature #1200 (New): NoGFX for dedicated (Ammler) @
16:09:06  <Rubidium> if it has some graphics it's more like "SomeGFX"
16:09:19  <Rubidium> NoGFX would have no graphics at all
16:09:37  <Ammler> my proposal was MiniGFX
16:09:51  <Rubidium> oh.. yes.. Ammler, don't expect the screenshot feature to work for a dedicated server if it uses NoGFX
16:09:59  <Ammler> :-)
16:10:35  <Ammler> screenshot feature does still need patching openttd
16:10:47  <Ammler> so that is "unsupported" anyway
16:10:57  <Rubidium> guess we'll disable the screenshot command for dedicated servers
16:11:19  <Ammler> :-P
16:11:48  <Ammler> just do it in a nice single commit :-)
16:16:24  <FooBar> well, change the name if you like. NoGFX was in line with the other Nothings, so I picked that
16:16:35  <FooBar> by the way, I'm not here right now ;)
16:16:54  <Ammler> where are you?
16:17:14  <FooBar> well, around the house but not in front of computer mostly
16:17:30  <Ammler> :-)
16:18:33  <Brot6> basecosts: update from r10 to r20 done -
16:19:53  <Brot6> nforenum: update from r420 to r421 done -
16:20:36  <Brot6> nml: update from r636 to r640 done -
16:21:10  <Brot6> transrapidtrackset: update from r11 to r15 done -
16:21:12  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r573), 32bpp-extra (r38), airportsplus (r52), comic-houses (r71), firs (r1098), fish (r386), grfcodec (r188), heqs (r371), metrotrackset (r40), newgrf_makefile (r124), nutracks (r90), ogfxplus (r41), opengfx (r469), openmsx (r91), opensfx (r97), snowlinemod (r15), swedishrails (r140), worldairlinersset (r659)
16:21:59  <Brot6> 2cctrainset: rebuild of r573 done (6 errors) (Diffsize: 13) -
16:22:36  <Brot6> 32bpp-extra: rebuild of r38 done (1 errors) (Diffsize: 13) -
16:23:00  <Brot6> airportsplus: rebuild of r52 done (Diffsize: 13) -
16:23:47  <Brot6> comic-houses: rebuild of r71 done (3 errors) (Diffsize: 13) -
16:24:25  <Brot6> firs: rebuild of r1098 done (2 errors) (Diffsize: 13) -
16:25:01  <Brot6> fish: rebuild of r386 done (6 errors) (Diffsize: 13) -
16:25:26  <Ammler> yes, diff-diff is needed :-)
16:25:45  <Brot6> heqs: rebuild of r371 done (Diffsize: 13) -
16:26:20  <Brot6> metrotrackset: rebuild of r40 done (6 errors) (Diffsize: 13) -
16:26:39  <Brot6> newgrf_makefile: rebuild of r124 done (Diffsize: 13) -
16:27:41  <Brot6> ogfxplus: rebuild of r41 done (Diffsize: 1) -
16:28:43  <Brot6> opengfx: rebuild of r469 done (Diffsize: 78) -
16:29:10  <Brot6> snowlinemod: rebuild of r15 done (Diffsize: 13) -
16:29:44  <Brot6> swedishrails: rebuild of r140 done (Diffsize: 8) -
16:30:45  <Brot6> worldairlinersset: rebuild of r659 done (Diffsize: 13) -
16:30:46  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: basecosts, nutracks (13 errors)
16:31:05  <Ammler> basecosts the only perfect set :-P
16:31:47  <Rubidium> why?
16:32:05  <Ammler> no diff and no errors
16:32:34  <Ammler> well, except transrapidtrackset
16:32:46  <Rubidium> the 13 diff is in 99% of the times caused by a change of me in NFORenum
16:32:57  <Rubidium> that doesn't make the set less perfect
16:32:57  <Ammler> yes, the nicer header
16:33:11  <Rubidium> okay, errors are bad
16:34:05  <Ammler> those grow since you output the warnings to stderr too
16:34:17  <Ammler> grew*
16:34:17  <Rubidium> yep
16:34:21  <Rubidium> I hope you like it
16:34:56  <Ammler> yeah, you don't need to check the non error log anymore
16:35:25  <Ammler> and people can't hide 1000 warnings behind one make error
16:37:28  <Ammler> I just should silence those repeating rebuild diff annoucement
16:52:04  <Rubidium> Ammler: <- worky?
16:53:59  <Ammler> Rubidium: how do you respect the src/?
16:54:31  <Ammler> not that you need :-)
16:57:48  <Rubidium> Ammler: found the "trick" already?
16:59:19  <Ammler> wth
16:59:22  <Ammler> can't apply
17:00:44  <Rubidium> oh... don't use such ancient versions then!
17:01:15  <Ammler> you already committed :-P
17:01:22  <Rubidium> no
17:02:49  *** DJNekkid has quit IRC
17:07:12  *** ODM has quit IRC
17:07:48  <Ammler> Rubidium: but now, trunk doesn't work
17:08:07  <Ammler> r20308 should show r20307
17:08:19  <Ammler> but at least that might be on all the same now?
17:08:32  <Ammler> so then it is obvious that hg log -f works
17:09:09  <Rubidium> so it works and gets the version of "trunk" instead of "trunk/src"?
17:09:31  <Ammler> yes, but is that what you want?
17:09:41  <Ammler> I mean, that is why michi "declined" my patch
17:10:03  *** ODM has joined #openttdcoop.devzone
17:10:04  <Rubidium> yeah, and why I just changed that behaviour
17:10:18  <Ammler> would be nice and fast how it is now
17:10:25  <Ammler> (with your patch)
17:11:17  <Ammler> just hard to test as there is no commit after it :-)
17:11:41  <Rubidium> then make on in your repository :)
17:13:59  <Ammler> yes, already did and seems fine
17:19:12  *** DJNekkid has joined #openttdcoop.devzone
17:24:18  <Ammler> Rubidium: please close the fs then with that diff :-)
17:25:33  <Rubidium> Ammler: huh?
17:26:27  <Ammler> it solves the issue?
17:27:27  <Rubidium> oh, you're talking about the thing I did ~10 minutes ago
17:27:53  <Ammler> mäh :-)
17:28:19  <Ammler> we shouldn't talk about openttd trunk here :-P
17:32:26  <Ammler> oh, and thanks :-)
18:09:31  *** Seberoth is now known as Seb|afk
18:26:57  <Brot6> NewGRF Meta Language - Revision 641:0ad9a26101fd: Codechange: Yet Another Base Cost Code Restruct... (Hirundo) @
18:42:25  <Brot6> OpenMSX - Bug #1202 (Confirmed): Corrupt songs crashing MIDI playback (Rubidium) @
18:49:39  <Brot6> NewGRF Meta Language - Revision 642:e4cced5eeaae: Add: Regression test for base costs. (Hirundo) @
19:05:52  <Brot6> NewGRF Meta Language - Revision 643:0f87ca4ef09d: Fix: Save properly before committing, i.e. add ... (Hirundo) @
19:09:33  <Brot6> NewGRF Meta Language - Revision 644:69c66e85eca7: Fix: Give a proper error message instead of an ... (Hirundo) @
19:38:56  <Hirundo> Can someone with a TTDP wiki account add a note on the base costs page that build/remove train depot affects build/remove waypoint
19:39:19  <Hirundo> ?
19:40:33  <Rubidium> huh?
19:42:07  <Rubidium> just set 52/34
19:42:31  <Hirundo> There are lots of notes over there  "also affects foo"
19:42:59  <Hirundo> but these ones seem to be missing
19:43:37  <Hirundo> {    600, PCAT_CONSTRUCTION, GSF_END,          PR_BUILD_DEPOT_TRAIN  }, ///< PR_BUILD_WAYPOINT_RAIL <- default is build train depot
19:44:30  <Ammler> shouldn't that be station?
19:46:00  <Hirundo> Seems more logical to me, but this is what the source tells me
19:48:41  <Hirundo> <- It used to be the depot cost, so there is a reason
19:49:26  <frosch123> it's just the usual old waypoint difference between ottd and ttdp :)
19:49:45  <frosch123> Thu 26 of Nov, 2009 [14:52] 	frosch	added (most) fallback modifiers <- maybe i left it even out intentionally :)
19:50:12  <Hirundo> With what intentions ?
19:50:14  <frosch123> to avoid some mb moaning about "waypoints are stations" or so
19:50:21  <Ammler> :-)
19:50:56  <Hirundo> Waypoints are BaseStations
19:51:47  <Hirundo> but mb is always right, so arguing is pointless...
19:52:51  <Ammler> Hirundo: there is simply no need to support old behaviour with nml, is there?
19:54:03  <Hirundo> It's not that much about 'old behaviour', it's a matter of telling the nml user what will happen if he adjusts the cost of train depots
19:54:32  <Ammler> yes, nml shouldn't change the costs of waypoints then
19:55:02  <Hirundo> That's not possible without setting the cost to 8 and possibly overriding another grf
19:55:49  <Ammler> and what happens, if you don't set it to 8 but another grf did set it?
19:56:40  <Hirundo> I'll have to look that up in the source
19:57:37  <Ammler> what would you like should happen?
19:58:27  <frosch123> if your grf only sets depot, it will overwrite the waypoint of earlier loaded grfs
19:58:50  <frosch123> so, i guess best for nml is to always set waypoint too when setting depot
19:59:37  <Yexo> why should nml do that? the user wanted to set "depot", not "waypoint"
19:59:50  <Yexo> unless he explicitely also specifies to set "waypoint"
20:00:18  <Yexo> or should nml write "default" to waypoint when the user sets "depot" ?
20:00:23  <Yexo> whatever the default value is
20:00:41  <Hirundo> That's very difficult to apply in practice
20:01:06  <Hirundo> What if the user sets his base costs based on some parameter
20:01:30  <Yexo> I didn't think of that case
20:01:40  <Hirundo> You'd have to supply a lookup table to correctly make that work
20:01:48  <Yexo> so the easiest solution is to just do as nfo and make sure to document properly what values will change
20:02:15  <Yexo> lookup table in nfo is not possible, it'd become a series of action7
20:02:24  <frosch123> Yexo: well, you cannot modify depotcost without modifying waypoint cost
20:02:38  <Hirundo> Then so be it
20:04:03  <Ammler> what about using 0 as "do not change"?
20:05:47  <frosch123> that only makes it more complicated :)
20:06:15  <frosch123> better put it on the list for version 8 to no longer apply fallbacks, but require individual costs
20:06:26  <Hirundo> Or some global grf flag to say 'hey, we're smart, we don't need base cost overrides'
20:06:39  <Hirundo> Perhaps in action14 :)
20:07:58  <frosch123> action14 shall contain non-essential stuff only
20:08:14  <frosch123> i.e. grf shall stay working when you ignore them
20:09:45  <Hirundo> What about a bit in var 9E?
20:10:55  <Hirundo> s/var/param
20:11:02  <frosch123> well, then i prefer action14 :p
20:15:03  *** Seb|afk is now known as Seberoth
20:16:07  <frosch123> actually action14 is not that wrong. it is also meant for enabling extensions which the grf can then check with versions checks
20:17:15  <frosch123> actually doing so would also allow to do several other version8 things which are just annoying
20:17:28  <frosch123> e.g. the not-translated default cargo of vehicles
20:18:09  <frosch123> but it would require to set this stuff in every grf, instead of a single version number
20:18:47  <frosch123> though that does not hurt with a compiler :)
20:19:18  <Yexo> how should that work exactly? 1. grf defines in action14 "I want to use this feature (ie no fallbacks for basecosts). 2. OpenTTD honors the request only if it understands that part of the action14 (so only when it actually supports it), 3. grf checks for if openttd version supports it, if not false back to what it did before
20:20:08  <frosch123> 3. grf checks ottd version to tell whether ottd understood the action14 and then disables itself, or whatever
20:20:53  <frosch123> (it does not need to disable itself though, if it does not care)
20:21:53  <Yexo> documentation for NML: when setting basecost and using the grf in openttd versions < 1.1 it might also set some related basecosts
20:22:04  <frosch123> i.e. it is not the action14 which makes ottd disable the grf because it does not support it, but the grf deciding whether it needs it
20:22:06  <Yexo> then just always supply that action14 when the basecost chunk is used
20:22:13  <Yexo> yep
20:23:19  <frosch123> how about "FEAT" -> "GLOB" -> "BCTF"
20:23:31  <frosch123> (base cost fallback)
20:24:22  <frosch123> and "FEAT" -> "VHCL" -> "DEFC"
20:24:48  <frosch123> or are that many boolean values too tedious, and there should be something else?
20:25:51  <Hirundo> Again, when it's written by a compiler tediousness matters very little :)
20:26:06  <Yexo> it should be separate values imo
20:26:35  <frosch123> i just do not want to run in the ttdp trap, i.e. hundreds of settings which have to work in every combination :)
20:29:47  <Yexo> what is actually blocking grf version 8?
20:30:28  <frosch123> i got lost in the requirement that boolean callback shall only return 0 or 1 (instead of 0 or != 0)
20:30:53  <frosch123> i did not found proper code to check for that and throw errors :)
20:31:06  <frosch123> (as it is pointless if there are no errors)
20:31:20  <frosch123> (and i consider the boolean stuff quite important)
20:31:35  <Yexo> what is the problem with making that a requirement for the newgrf but in the code still checking for !=0 ?
20:31:55  <Yexo> when there actually is another valid return value you can at that time check for it
20:32:07  <frosch123> if ottd does not check the results, no grf will do so
20:32:36  <Yexo> good point
20:47:50  <Brot6> NewGRF Meta Language - Revision 645:771d268124c5: Doc: Document setting base costs. (Hirundo) @
20:59:52  *** Alberth has left #openttdcoop.devzone
20:59:59  *** FooBar has quit IRC
21:06:47  <Hirundo> which TTDP guru thought "hmm... Real Bit Hackers (tm) don't need bit shifting in varaction2advanced" ?
21:08:00  <Hirundo> of course, bit rotation is much more useful
21:09:13  <frosch123> rotate and AND suffice :p
21:09:28  <Hirundo> with what and mask?
21:10:21  <frosch123> hmm, ok it does only work if the second operand is constant
21:10:35  <frosch123> so, maybe we should just add those operators :p
21:10:46  <Hirundo> if it's a constant, you might as well use multiplication/division
21:12:52  <Yexo> you can also do that if it's not constant
21:13:25  <Hirundo> how?
21:13:46  <Yexo> one moment, writing it in a pastebin
21:14:37  <Hirundo> I can come up with a >> b => b ==0 ? a : a ror b & ((1 ror b) - 1)
21:15:08  <frosch123> there are only 32 cases, so you might also do it with a procedure
21:15:39  <Yexo> <- like that
21:15:55  <Yexo> A / ((1 ror (32-B)) basically
21:16:52  <Hirundo> I guess that approach is much nicer :)
21:17:26  <Hirundo> also, that method to compute 2^b can be used for both unsigned/signed and left/right shifts
21:18:15  <Yexo> should we make pow(2, x) also available to nml code?
21:19:03  <Hirundo> pow(2,x) or pow2(x) ?
21:20:20  <Yexo> is it needed at all?
21:20:28  <Yexo> and if so, should we allow other bases?
21:20:34  <Hirundo> it's needed for >> and << in action2
21:20:42  <Yexo> yes, but I mean for nml code
21:22:44  <Hirundo> it's not needed, if << and >> are available
21:23:00  <Yexo> good point, so let's just support << and >>
21:23:51  <Hirundo> <- updated
21:23:59  <Brot6> NewGRF Meta Language - Bug #1032: support all operators for both actionD and varaction2 or give a... (Hirundo) @
21:27:59  <Brot6> NewGRF Meta Language - Bug #1032: support all operators for both actionD and varaction2 or give a... (yexo) @
21:28:07  <Yexo> I agree with the other points btw
21:30:23  <Yexo> about the special check for x >= 32: imo we just document it properly that x must be < 32 and be done with it
21:30:44  <Yexo> ie "behavior of << and >> is undocumented when x >= 32"
21:31:04  <Yexo> s/undocumented/undefined/
21:34:54  <Hirundo> That seems easiest, at least for now
21:35:31  <Hirundo> I think 90% of all shifts have a constant at the right-hand-side anyway
21:36:01  <Yexo> most likely yes :)
21:36:32  <frosch123> who is going to add them?
21:37:15  <Yexo> to nml? Hirundo if he wants to, otherwise me
21:37:45  <frosch123> hmm, maybe i got it wrong. i wondered about adding << and >> to ottd
21:38:31  <Yexo> but if nml made use of those new operators then all grfs would be openttd >1.1 only
21:39:10  <frosch123> we could also add such a small feature to 1.0.4
21:39:25  <Yexo> true
21:40:23  <Yexo> 1.0.4 won't be out for another 2 months though, so for nml we'll need the fallback now anyway
21:40:45  <frosch123> who knows how many complain about ecs :p
21:41:23  <Yexo> only 1 in the first 48 hours
21:43:08  <frosch123> <- i guess that is all needed
21:44:13  <frosch123> or does it also need ROL and SAR? :p
21:44:25  <Hirundo> shift is signed or unsigned?
21:44:45  <frosch123> shift right is unsigned there, shift left is same for both
21:45:24  <frosch123> (interestingly mul is also the same for signed and unsigned due to clamping the result to 32bit)
21:45:57  <frosch123> s/32bit/whatever is the length of ther operands/
21:46:46  <Hirundo> having both signed and unsigned shr may be nice, since other operators are also available in two flavours
21:47:46  <frosch123> oh fail
21:48:05  <frosch123> i take "b" as signed, so the sign also matters for shift left
21:49:39  <frosch123> 	rot %= 32; <- hmm, maybe we should do the same to the shifting
21:49:55  <frosch123> s/.*//
21:50:37  <Hirundo> <- seems cpus do the same :)
21:50:38  <Webster> Title: shifting bits, shift 32 bits on 32 bit int (at
21:50:59  <frosch123> yes, we had that just a few days ago :)
21:53:28  <frosch123> updated the diff
21:54:14  <frosch123> hmm, maybe i drop the RIOL again
21:55:48  *** ODM has quit IRC
21:58:16  <Yexo> diff looks fine
21:58:53  <Yexo> do we need to run this past the ttdpatch guys so they can't complain about not asking?
22:05:58  <frosch123> sometimes i wonder to just post patches for ttdp to the forums :p
22:06:25  <Rubidium> frosch123: they bug tracker and the forum?
22:06:40  <Rubidium> frosch123: or actually... the German forum!
22:06:51  <frosch123> i was only once at the bugtracker, and it was totally unusable
22:07:11  <frosch123> hmm, german forum... i could do that., and then post to english forum with linking to the german :p
22:10:31  <frosch123> 	dd addr(.add),addr(.sub),addr(.signed_min),addr(.signed_max),addr(.unsigned_min),addr(.unsigned_max)
22:10:33  <frosch123> 	dd addr(.signed_divmod),addr(.signed_divmod),addr(.unsigned_divmod),addr(.unsigned_divmod)
22:10:34  <frosch123> 	dd addr(.multiply),addr(.and),addr(.or),addr(.xor),addr(.storevar),addr(.copy),addr(.storepers)
22:10:36  <frosch123> 	dd addr(.rotater),.signed_cmp,.unsigned_cmp
22:11:07  <frosch123> sometimes i only wonder: either i do not understand it, they have zero consistent style, or it just wrong
22:11:58  <Rubidium> it's just a hack
22:12:37  <frosch123> signed_cmp and unsigned_cmp do not seem to need an addr() :p
22:18:00  *** andythenorth has left #openttdcoop.devzone
22:32:07  <frosch123> well, what is more useful? shift left, unsigned shift right and signed shift right? or unsigned and signed shift (with signed "b")?
22:32:47  <frosch123> i guess the former
22:34:41  <Yexo> how does "shift with signed b" work? reverse the direction fo the shift?
22:34:52  <Yexo> ie 8 << -1 == 4 ?
22:35:08  <frosch123> yes, b >= 0 ? a << b : a >> -b
22:35:38  <frosch123> the ror also allows that
22:35:48  <Yexo> oh? that's good to know
22:35:54  <Yexo> does that also work in ttdpatch?
22:36:30  <frosch123> 	ror eax, cl <- ttdp does just that
22:36:50  <frosch123> i expect the cpu to use again only 5 bits
22:37:10  <frosch123> so rotate by 255 is the same as by -1
22:37:58  <Yexo> ah, didn't think of that
22:38:00  <frosch123> rotate is easier than shifting wrt. direction
22:38:06  <Yexo> of course
23:46:10  *** Seberoth has quit IRC

Powered by YARRSTE version: svn-trunk