Log for #openttdcoop.devzone on 30th July 2012:
Times are UTC Toggle Colours
00:02:11  *** ODM has quit IRC
00:32:38  <Brot6> zBase - Revision 49:2b197b342f07: Add: Temperate farm. XzephyrisX @
05:05:17  <Brot6> zBaseBuild - Revision 73:399d7757f14f: Add: farm tiles XRubidiumX @
06:04:03  <Rubidium> if someone asks: farm fences and farm buildings are still to be 'coded'
06:37:38  <Brot6> FISH - Revision 877:e4294250830c: Fix: remove non-translatable generator code from dutch.pylng XandythenorthX @
06:38:48  <Brot6> FISH - Revision 878:6116b5038348: Codechange: add a prop to config file to handle which vehicle repl... XandythenorthX @
07:30:12  <Brot6> FISH - Revision 879:7678f83d886d: Codechange: provide support for deriving model life from intro dat... XandythenorthX @
07:33:28  <Brot6> FISH - Revision 880:1d51359f755f: Codechange: remove deprecated model_life property XandythenorthX @
07:33:28  <Brot6> FISH - Revision 881:beef4084ab7f: Codechange: updated backup of FISH content management system XandythenorthX @
07:41:54  <Brot6> FISH - Revision 882:fe587a1ad267: Change: set replacement id props for all current ships (sets model... XandythenorthX @
07:44:56  <Brot6> FISH - Feature #4116 (Closed): Handle model life automatically XandythenorthX @
08:48:26  <Terkhen> <--- strange, the r21 folder contains r71
08:48:58  <Brot6> FISH - Feature #4115 (Closed): nml conversion lacks deprecated medium trader (climate hidden), also ... XandythenorthX @
08:49:10  <Ammler> that is because zbuild builds zbasebuild
08:49:41  <Ammler> cf has the rev of zbuild, but the Makefile the rev of zbasebuild
08:49:59  <Xotic750> G'morning
08:50:30  *** andythenorth has joined #openttdcoop.devzone
08:50:36  <Brot6> FISH - Feature #4041 (Closed): Requests XandythenorthX @
08:50:53  <Terkhen> oh, ok :)
08:50:59  <Terkhen> good morning Xotic750
08:51:24  <Xotic750> Ammler: did you manage to make any progress on backing up the repos?
08:51:35  <Xotic750> Hi Terkhen
08:52:24  <Ammler> Xotic750: not yet the WE was a bit disturbing :-P
08:52:50  <Brot6> FISH - Feature #2387 (Rejected): Large Passenger Steamer (cruise ship) XandythenorthX @
08:52:50  <Brot6> FISH - Feature #2388 (Rejected): Small Paddle Steamer XandythenorthX @
08:52:50  <Brot6> FISH - Feature #2389 (Rejected): Medium Paddle Steamer XandythenorthX @
08:52:50  <Brot6> FISH - Feature #1137 (Rejected): Laker XandythenorthX @
08:53:02  <Ammler> well, backuping isn't a issue...
08:53:10  <Ammler> n
08:53:36  <Brot6> FISH - Feature #1136: Large Freight Hovercraft XandythenorthX @
08:55:03  <Xotic750> Both the reworked repos are ready, I posted the URLs in #4017
08:55:03  <Brot6> Xotic750: #4017 is "Support #4017: Reduce repo size by archiving sources that are split into own repo - OpenGFX+ Trains - #openttdcoop Development Zone"
08:55:09  *** ODM has joined #openttdcoop.devzone
08:59:11  <Xotic750> If there's something more that I need or can do, then please let me know.
09:00:55  <Ammler> well, I would like to have planetmaker at least involved in this tasks, as that is not a technical issue anyway
09:01:20  <Ammler> my part is fixing the http server and compiler
09:01:38  <planetmaker> Ammler: from my part the new repo could be moved to replace the old one
09:01:56  <planetmaker> I was... waiting for you to be available to fix http and CF :-P
09:03:12  <planetmaker> but... let's checkout
09:04:01  <Ammler> planetmaker: basically you would need to move the repos via ssh on the server and then remove the repo and readd on redmine
09:04:09  <Ammler> I can do that for you
09:04:34  <planetmaker> yes... though we probably could simply clone from server-side the reduced-size repo
09:05:32  <planetmaker> let me build the new repo
09:14:23  <planetmaker> Xotic750: for commits like r626 (languages), remember to update readme with proper credits
09:15:31  <Xotic750> Ok, I have been keeping a list in issues #4020
09:15:32  <Brot6> Xotic750: Ok: #4020 is "Bug #4020: Language files not up to date with new text - OpenGFX+ Trains - #openttdcoop Development Zone"
09:16:17  <planetmaker> why keep a list when it's commited - except credits?
09:17:03  <planetmaker> just amend credits as appropriate when updating or adding a language
09:18:44  <planetmaker> lists with "credits still to be given and added later" tend to be forgotten and only lead to embarresment and sour translators
09:20:17  <planetmaker> besides that issue does not list which credits are missing
09:22:23  <Xotic750> The credits will be updated as soon as we are ready with the reduced size repo, it will be the first push
09:40:50  <Brot6> OpenGFX+ Trains - Bug #4020: Language files not up to date with new text XXotic750X @
09:52:33  <Brot6> zBase - Feature Request #4110: Missing license XzephyrisX @
09:54:20  <Brot6> zBase - Bug #4111: Mask sprites incorrect XzephyrisX @
09:56:20  <Brot6> zBase - Bug #4100: snowy arctic terrain sprites not contiguously decreasing in snowy-ness XzephyrisX @
10:01:08  <planetmaker> cloning the converted ogfx-trains repos to devzone server now
10:12:59  <planetmaker> Ammler: better to rename the old repos (and keep the URL for the current project) or better adjust the repo path in the project description?
10:29:22  <Brot6> ogfx-t: compile of 0.3.0 failed -
10:31:54  <planetmaker> uhm, aha
10:47:06  <Ammler> planetmaker: I would rename to ogfx-*-backup
10:48:08  <planetmaker> the problem I see is that people pull into their old repo
10:48:21  <Ammler> why is that an issue?
10:49:01  <planetmaker> you don't expect the repo content to change
10:49:40  <Ammler> yes, and if it will you will ask here, you need to inform in any way
10:50:08  <Ammler> either a new repo url or refetch
10:50:58  <Ammler> and it does not simply pull the new repo to the old one
10:51:07  <Ammler> hg will error/warn
10:51:45  <Ammler> well, anyway, that is why I wanted you to do this :-)
10:52:22  <planetmaker> well, ok. I renamed the repos.
10:52:37  <planetmaker> ogfx-trains-render is not yet fully cloned to the server. So that will need time still
10:53:13  <planetmaker> the old repo urls are ogfx-trains-org and ogfx-trains-render-org
10:53:24  <planetmaker> hm... maybe -old is better
10:53:32  <planetmaker> I don't like -backup as it's not a backup really
10:53:39  <Ammler> yeah, org is bad, imo
10:53:56  <planetmaker> changed to -old
10:54:57  <Ammler> what is ogfx-t?
10:56:20  <planetmaker> the clone. I renamed it now
10:56:36  <planetmaker> don't yet rename ogfx-t-render :-)
10:57:21  <planetmaker> so can you re-scan the history view for redmine for ogfx-trains now, please, Ammler?
11:02:00  <Ammler> just readd the repo to the project
11:02:20  <planetmaker> hu? I just did what you suggested: renamed dirs...
11:02:28  <Ammler> yes
11:02:32  <Ammler> in redmine I mean
11:02:42  <Ammler> delete repo, add it again
11:03:02  <Ammler> (that is how you reset the vcs history in redmine)
11:03:36  <Ammler> oh, and if there is no pull, it might need a hour to the cron refetch
11:03:45  <Ammler> s/pull/push/
11:03:45  <Brot6> Ammler meant: "oh, and if there is no push, it might need a hour to the cron refetch"
11:04:16  <planetmaker> I've no clue how I can do that
11:06:13  <Ammler> <-- delete right bottom
11:06:27  <Ammler> and then add the same path again
11:37:21  <Ammler> please ping if you are done
11:37:28  <Ammler> or ask for help
12:01:29  *** Alberth has joined #openttdcoop.devzone
12:01:39  <Alberth> moin
12:02:01  <Alberth> are there zbase builds?  zephyris likes to have one
12:02:15  <planetmaker> I replied as to where they are :-)
12:02:29  <Alberth> k, already handled thus :)
12:02:32  <planetmaker> it seems to build... though I wonder why all of a sudden
12:02:47  * Alberth fixed 2 ../  thingies 
12:02:53  <planetmaker> ah :-)
12:03:16  <Alberth> aka "magic" :D
12:03:48  <planetmaker>
12:04:07  <planetmaker> well, the publish URL follows always the same pattern for all projects :-)
12:04:56  <Alberth>   <-- it still fails somewhat though
12:05:45  <Alberth> yeah I suspected as much but I was looking at zbase rather than zbuild, I need more coffee apparently :)
12:07:55  <planetmaker> :-)
12:08:06  * planetmaker hands Alberth a cup of coffee
12:08:24  <Alberth> ah, thanks, that should help :)
12:09:59  * Rubidium doesn't dare to pass Alberth the stuff that should pass as coffee from here
12:12:20  <Alberth> Did you switch to tea, or do you bear the coffee stuff?
12:12:49  <Rubidium> Brot6: translate nl en "koffie en bier zijn vies" ;)
12:12:49  <Brot6> Rubidium: worldlingo failed to provide a translation
12:19:36  <Rubidium> Alberth: if you're bored: farm fences and farm buildings need to be done
12:21:34  <andythenorth> Alberth: I need a tree parser in python if you're bored :P
12:21:51  <Alberth> tree of what?
12:22:06  <andythenorth> ships have a 'replacement_id' property
12:22:16  <andythenorth> this is the id of another ship that...replaces them
12:22:35  <andythenorth> it's only for docs, but it would be nice to be able to render in text the upgrade paths
12:22:44  <andythenorth> e.g. A -> B -> C etc
12:23:00  <andythenorth> I don't have 'replaced_by' however as I don't want to maintain 2-way mappings
12:23:16  <andythenorth> and I can't figure how to find the starting points :P
12:23:21  <andythenorth> it's a silly side project :)
12:23:52  <Alberth> find the ship that never gets replaced by something else?
12:24:36  <andythenorth> yeah
12:24:50  <andythenorth> just means walking a stack of objects a few times :P
12:27:14  <Alberth> hmm, that is actually the end point I guess
12:31:18  <Alberth> perhaps first make bi-directional links, then create set(ship for ship in all_ships if ship.predecessor is None)
12:34:44  <andythenorth> I also thought first make the bi-directional links
12:35:25  <andythenorth> then build sets, then merge sets
12:35:39  <andythenorth> it's a DAG, there are probably standard approaches :P
12:45:19  <Brot6> OpenGFX+ Trains - Feature #1528 (Closed): Support for additional cargos XplanetmakerX @
12:53:16  <Alberth> I'd guess so, although I cannot be bothered to learn how to do such things, I just re-invent it each time :p
12:54:07  <andythenorth> eddi probably knows :P
12:54:25  <andythenorth> but I thought you might like it :)
12:54:42  <andythenorth> but anyway, there's probably more useful things to do :)
12:57:06  <Alberth> there always is :)
13:03:29  <andythenorth> anybody fancy painting ships?
13:03:40  <andythenorth> could be a chance for devs to try painting
13:03:53  <andythenorth> after all...I keep trying coding :P
13:08:03  <Alberth> doesn'r bandit work here?
13:08:15  <Alberth> s/'r/'t/
13:08:15  <Brot6> Alberth meant: "doesn't bandit work here?"
13:10:56  <andythenorth> pixa generation?
13:11:01  <andythenorth> not so much for ships :P
13:11:12  <andythenorth> the shapes are not regular enough
13:32:52  * Hirundo ponders NML houses
13:33:38  <planetmaker> I saw your wiki page, Hirundo
13:34:05  <planetmaker> from the brief read I had, it looked good to me
13:34:10  <Hirundo> Houses are on the wrong end of the (sanity ~ 1 / feature_number) scale
13:34:26  <planetmaker> :-)
13:34:30  <planetmaker> you mean they're too sane?
13:34:39  <planetmaker> or too unsane?
13:35:00  <Hirundo> hmm... that formula is wrong
13:35:02  <planetmaker> houses specs so far did not look too bogus to me
13:35:14  <Hirundo> sanity ~ feature number
13:35:26  <Hirundo> houses are half-sane
13:35:36  <planetmaker> which spec is sane? :-)
13:36:33  <Hirundo> afaik objects is pretty clean
13:36:49  <Hirundo> and other new stuff, like airporttiles and railtypes
13:37:02  <andythenorth> vehicles are mostly ok
13:37:03  <planetmaker> yes. It's missing sadly means to modify the behaviour of the default objects
13:37:33  <andythenorth> incidentally, for reasons of co-incidence, lots of FOO_SHIP stuff works even if you use FOO_ROADVEH :P
13:37:40  <andythenorth> I found that out the hard way
13:37:47  <Hirundo> That's in NML, but not in nfo :-)
13:37:53  <andythenorth> yup
13:38:08  <andythenorth> blame copy-paste coding :)
13:38:13  <planetmaker> nml abstracts away a lot of insanity :-)
13:38:50  <Hirundo> Problem with multitile houses is that they are done 'like in TTD'
13:39:20  <Hirundo> which basically means that they have to work without callbacks, so each tile has to have a separate ID
13:40:53  <Hirundo> One of the things I dislike and have not yet decided about is the accepted cargo types callback for houses (and industry tiles)
13:41:11  <Hirundo> Basically, you have to return 3 cargo types in bits 0..4, 5..9 and 10..14
13:41:23  <Hirundo> Which has several problems:
13:41:42  <Hirundo> - User has to do bit stuffing manually (can be worked around in NML)
13:41:59  <Hirundo> - Limited to 32 cargo types (like the old xor-refit mask)
13:43:10  <Hirundo> - No reliable way to specify an invalid cargo type to disable acceptance
13:43:31  <Hirundo> - Unable to be extended to more than 3 cargo types (like is possible for industries)
13:44:11  <andythenorth> seems fugly
13:44:30  <Hirundo> The industry callback is fine, it is called repeatedly until the grf returns 0xFF
13:44:33  <andythenorth> NewHouses
13:44:35  <andythenorth> !
13:44:39  <andythenorth> will never get done :P
13:44:50  <Hirundo> which avoids all problems listed above
13:45:11  <Hirundo> NewHouses in what sense? grf by MB?
13:46:11  <planetmaker> Hirundo, would make sense to add a industry-like CB for houses?
13:46:37  <andythenorth> NewHouses as in: new nfo spec items
13:46:43  <andythenorth> less insane, more sane
13:47:42  <Hirundo> planetmaker: possibly
13:48:10  <Hirundo> I have also thought about abstracting it away in NML
13:48:31  <Hirundo> Which is quite possible, but the abstraction will be leaky
13:49:51  <Hirundo> There is simply no way to fully abstract away having only 5 bits of entropy per cargo type
13:50:32  <Hirundo> but it might be tmwftlb
13:50:45  <Hirundo> I wonder if any house set at all uses variable acceptance
13:50:46  <planetmaker> hm... thus the optimal solution is: abstract it away in NML. Use that for the time being. But change OpenTTD and use that in NML 0.4 ;-)
13:51:18  <planetmaker> and the 2nd part... might be the tmwftlb right now indeed
13:54:48  <Hirundo> Actually banananas contains 8 house sets, more than I thought
13:55:55  <planetmaker> indeed. swedish, ttrs, uk, japanese(?), ...?
13:56:41  <planetmaker> early, ecs, TAI
13:57:24  <Hirundo> real arcade town set and snow aware houses
13:57:37  <planetmaker> ah
13:58:16  <Hirundo> japanese also, but it doesn't use 'house' or 'town' so I didn't find it initially
14:19:15  <Brot6> OpenGFX+ Trains - Bug #4020: Language files not up to date with new text XXotic750X @
14:31:26  <michi_cc> Hirundo: Cargo acceptance callback for houses smells like something that should have gone into GRFv8 even somebody would have though of it.
14:31:42  <michi_cc> s/even/if/
14:31:42  <Brot6> michi_cc meant: "Hirundo: Cargo acceptance callback for houses smells like something that should have gone into GRFv8 if somebody would have though of it."
14:32:19  <planetmaker> michi_cc, can't we still change that? iirc there's no new house newgrf since
14:35:04  <michi_cc> Uk Houses and TaI? Or are they both still v7?
14:35:48  <planetmaker> I'd be surprised if they were grf v8
14:35:56  <planetmaker> granted, I didn't yet check
14:36:06  <michi_cc> And how about all those russian, japanese or something stuff we never see?
14:36:44  <planetmaker> not on bananas = doesn't exist :-P
14:37:17  <planetmaker> yes, I know, problematic :-)
14:37:21  <michi_cc> Convince frosch :)
14:37:34  <planetmaker> :D I'll give it a shot
14:38:19  <planetmaker> Ammler, so... what about the now?
14:55:38  <Hirundo> michi_cc: I agree about grfv8. FWIW, I smoke-tested all house grfs on bananas and found none that uses variable acceptance
14:57:08  <Brot6> OpenGFX+ Trains - Bug #4040: DevZone compile failed XXotic750X @
14:57:38  <michi_cc> We can't guaranteed that though, so changing it right under the feet of some NewGRF feels at least a bit meh.
14:59:04  <michi_cc> Of course, from the coding side, introducing GRFv9 would be easy enough, but then you have those not immediately obvious 'OTTD too old' problems again.
15:07:39  <planetmaker> we could kinda introduce a new grf version with each major openttd version
15:07:48  <planetmaker> to eliminiate these kinda pesky things slowly
15:08:45  <andythenorth> nice and tidy
15:08:46  <andythenorth> plausible in reality?
15:08:49  <planetmaker> but one change only for that... hm
15:09:16  <planetmaker> we should then roll-out grf v13 next April ;-)
15:18:09  <Rubidium> v666
15:18:21  <Rubidium> much better, then it won't clash with v32
15:20:30  <planetmaker> I thought 13 as with 1.3 :-)
15:21:42  <michi_cc> Angering every remaining Patch user/developer? :p
15:24:25  <Rubidium> aren't they already angered like hell
15:24:26  <planetmaker> they're all on simuscape anyway. And one hasn't seen any published newgrf since from there
15:26:37  <andythenorth> I'm going to play a canset game soon
15:26:40  <andythenorth> there's a release
15:28:20  <planetmaker> will be grf v7 anyway for ttdp compatibility
15:28:30  <planetmaker> and... "release" at best behind closed gates
15:29:05  <planetmaker> it even exists less than non-bananas grfs
15:30:43  <Brot6> zBaseBuild - Revision 74:b46a63f584cc: Add: temperate farm building XRubidiumX @
15:31:47  <Alberth> Rubidium: I have farm fences
15:31:55  <Alberth> unless you committed already
15:32:42  <Rubidium> no, I have no fences (yet)
15:33:44  <Brot6> ogfx-trains: update from r703 to r632 done -
15:33:56  <planetmaker> hm
15:34:09  <planetmaker> that sucks
15:34:12  <Rubidium> Alberth: so out of work again :(
15:34:51  <andythenorth> add ship smoke back to FISH 2?
15:34:52  <Alberth> and Y3xo hasn't even started :)
15:34:55  <andythenorth> I forgot about it :P
15:34:56  <andythenorth> not that ship smoke is any bloody use anyway :P
15:35:37  <planetmaker> doing a nice job there, rubi, albert :-)
15:36:10  <Rubidium> look at the HQ ;)
15:38:20  <Ammler> ogfx-trains build?
15:38:50  <planetmaker> seems like :-)
15:39:00  <Xotic750> :)
15:39:35  <Ammler> nice, that it can handle lower rev :-P
15:39:35  <planetmaker> and how long will it take till the repo view in redmine is fixed?
15:39:53  <Ammler> planetmaker: you deleted the repo?
15:39:54  <planetmaker> yes. And re-added
15:40:05  <planetmaker> and now... it knows like r574 in the view currently
15:40:07  <Ammler> and why do you think, it isn't fixed?
15:40:16  <planetmaker> just look....
15:40:22  <planetmaker> why do you think I talk bullshit?
15:40:30  <Xotic750> it's slowly increasing in revision number
15:40:57  <planetmaker> like maybe 1 rev per 5 minutes, I'd guess
15:41:12  <planetmaker> at most
15:41:57  <Ammler> and that is an issue because?
15:42:10  <Ammler> you would prefer the server crashes?
15:42:37  <Ammler> I think, it is much better with the new vz
15:42:40  <planetmaker> it's an issue because it's not "just delete and re-add"
15:42:45  <planetmaker> it's a day-long process...
15:42:53  <Ammler> :-D
15:43:01  <Ammler> you don't need to watch it, you know?
15:43:39  <planetmaker> Oh, I thought I had to refresh the browser view for every rev...
15:43:40  <Ammler> hmm, also possible the fetch stopped...
15:43:54  <Ammler> are you sure, it is still increasing?
15:43:56  <planetmaker> no
15:44:03  <planetmaker> simply as the speed is... abysmal slow
15:44:26  <Ammler> fetch on page call is disabled
15:44:28  <Xotic750> when I first looked it was a r3xx or something and I've seen it steadiliy going up
15:45:52  <Ammler> dev      27389 23.2  2.5 258260 157408 ?       R    15:44   0:20 ruby ./script/runner -e production Repository.fetch_changesets
15:45:58  <planetmaker> Ammler, I don't mind so much the speed but with the speed as seen, I'd like have had some kind of warning instead of "just re-add"
15:46:01  <Ammler> still running :-)
15:46:26  <Ammler> planetmaker: usually it is faster
15:46:59  <Ammler> but if it needs to share cpu power with compiling etc., it could be slow
15:47:09  <Brot6> OpenGFX+ Trains - Bug #4040 (Closed): DevZone compile failed XXotic750X @
15:47:38  <Ammler> Xotic750: my taks is still undone (yfi)
15:47:42  <Ammler> j
15:47:55  <Ammler> whatever :-P
15:48:10  <Xotic750> ?
15:48:20  <Brot6> OpenGFX+ Trains - Revision 628:e96c50be3f42: Update: Credits for language files #4011, #4015, #4020 XXotic750X @
15:48:20  <Brot6> OpenGFX+ Trains - Revision 629:58c90b1cba62: Merge with default XXotic750X @
15:48:20  <Brot6> OpenGFX+ Trains - Revision 630:8844e4ea35b1: Update: Credits for language files #4020, made alphabet... XXotic750X @
15:48:21  <Brot6> OpenGFX+ Trains - Revision 631:14ff1423a90b: Merge with default XXotic750X @
15:48:24  <Brot6> OpenGFX+ Trains - Revision 632:0554b0dffc29: Backed out changeset: 6e6004a26b0a, re-enabled nightly ... XXotic750X @
15:48:28  <Brot6> OpenGFX+ Trains - Revision 633:97ed65bf4f0e: Merge with default XXotic750X @
15:48:28  <Ammler> I still need to fix http server and compiler
15:49:02  <Xotic750> you mean that is the same issue number?
15:49:12  <Ammler> nono, just wanted to note
15:49:23  <Rubidium> Alberth: are the fences difficult?
15:49:26  <planetmaker> Xotic750, no, that's an issue not for ogfx-trains but generally
15:49:39  <Xotic750> ok
15:49:40  <planetmaker> we have the same issue also with zbase, for instance
15:49:40  <Ammler> not that you guys think, because ogfx-trains compiled, I succeeded
15:49:44  <Rubidium> Alberth: it would also make sense to disable compression of the sprites as that speeds up some things
15:49:57  <planetmaker> all people work on that with ssh, too
15:50:00  <planetmaker> iirc
15:50:27  <Rubidium> yes, the pinnacle of open source development... you need a ssh connection to check it out! ;)
15:50:47  <Ammler> nah, you can checkout it
15:50:54  <Ammler> just not at once
15:51:10  <Alberth> Rubidium: fences just needs manual sprite alignment, which takes time; the real fences look like they need some extra fixing
15:51:28  <Ammler> hg should have a partial clone/pull
15:51:45  <planetmaker> Ammler, probably due to hg 2.3 ;-)
15:51:48  <Rubidium> real = rail?
15:51:49  <planetmaker> *due in
15:51:54  <Ammler> might also be the reason, git is so much slower, wouldn't be suprised git would work with my setup
15:52:16  <Alberth> Rubidium: but for automagic builds you'd like compressed sprites; tbh I am not too much bothered by it as nml caches the stuff
15:52:21  <Brot6> OpenGFX+ Trains - Support #4017: Reduce repo size by archiving sources that are split into own repo XXotic750X @
15:53:00  <Alberth> landscape/fences/farm_fences/ 1..8 needs some fixing at first sight
15:53:39  <Ammler> hmm, is full 32bpp openttd goal for 1.3?
15:53:50  <planetmaker> Ask Zephyris ;-)
15:53:59  <Ammler> just because so many core devs work on it :-)
15:54:07  <Xotic750> the redmine web interface is now up-to-date :)
15:54:12  <Rubidium> Alberth: put in zbasebuid (it will need to recompile everything once though)
15:54:13  <planetmaker> It gets away with much whining, Ammler :-)
15:54:25  <planetmaker> ah, great, Xotic750  :-)
15:54:45  <Rubidium> Ammler: more because OpenTTD starts to be very boring for me
15:55:05  <Ammler> 3DTTD :-P
15:55:46  <Alberth> Ammler: mostly because no-one of the 32bpp project does anything
15:55:52  <Rubidium> it's already OpenTTD2D, or OpenTT3D
15:56:19  * planetmaker hugs Alberth 
15:56:43  <Rubidium> Alberth: lies... they do a lot
15:57:00  <Rubidium> ... of whining, talking, proposing and especially procrastinating
15:57:01  * planetmaker excepts xotic from generalisations :-)
15:57:02  <Alberth> ok :)
15:57:11  <Ammler> do you guys already have an idea to handle the different revs on hg subrepos?
15:57:17  <Alberth> and Geektoo, it seems :)
15:57:42  <Alberth> Ammler: like it is done now?
15:58:04  <Ammler> well, now it seems to confuse some
15:58:15  <planetmaker> Alberth, like it's done now is actually not exactly ideal. It should get the zbuild revison. Not the zbasebuild (or zbase) one
15:58:16  <Rubidium> r<opengfx>.<zbase>.<zbasebuild>.<zbuild>
15:58:32  <planetmaker> as zbuild stores the revs of the sub repos in its rev
15:58:58  <Ammler> well, it is rather your makefile
15:58:58  <Rubidium> but if you change anything in the sub repos, hg st doesn't notice it
15:59:19  <planetmaker> indeed
15:59:26  <Ammler> planetmaker: might be another reason to make a makefile in zbuild ;-)
15:59:39  <planetmaker> yes
15:59:53  <planetmaker> Rubidium, does hg st -S work?
16:00:01  <Rubidium> Alberth: the main problem with the rail fences is that the same sprite is used for both sides of the rail
16:00:05  <Rubidium> planetmaker: yep
16:00:11  <Ammler> or we build directly with zbasebuild
16:00:22  <planetmaker> Ammler, that's what we do...
16:00:32  <planetmaker> but that does *not* notice changes to the graphics then at all
16:00:39  <Ammler> well, I meant adding .devzone to it
16:00:45  <planetmaker> ?
16:00:57  <planetmaker> no, not good idea. For that very reason
16:01:02  <Rubidium> but it's much easier to just update zbase or zbasebuild to "r1" and zbuild just says r6789 with modifications
16:01:29  <planetmaker> yes, that's true. But... it *is* true then ;-)
16:02:27  <Xotic750> planetmaker: I assume that the ogfx-trains.render repo is still pulling? :)
16:04:50  <planetmaker> hm... no. Seems my ssh connection died. And I didn't use screen :D
16:04:57  <planetmaker> thus doesn't exist at all currently :-)
16:06:56  <Xotic750> ok
16:08:17  <planetmaker> cloning anew. This time in screen :-)
16:08:54  <Xotic750> :)
16:10:36  <planetmaker> Xotic750, I renamed the old repo already. Thus I'm cloning directly into ogfx-trains-render
16:10:55  <planetmaker> so the repo as linked from redmine might be in a somewhat funky state transiently
16:12:20  <planetmaker>  bbl 1...2 hours
16:12:42  <Xotic750> ok
16:15:37  <Brot6> OpenGFX+ Trains - Support #4017: Reduce repo size by archiving sources that are split into own repo XXotic750X @
16:38:25  *** frosch123 has joined #openttdcoop.devzone
16:40:27  <Alberth> hi
16:51:23  <Hirundo> hello frosch123
16:51:35  <Hirundo> Do you mind if I bug you with nfo spec issues once again?
16:52:00  <frosch123> i already read the logs :)
16:52:43  <Hirundo> And your thoughts are?
16:53:45  <frosch123> wrt. house acceptance cb, they were on the list for: noone uses them, there is no sane way to keep the result similar, there are free bits in the result to returns something completely different
16:54:35  <frosch123> e.g. take acceptance amount cb, set bit 14 for new result, set number of accepted cargos in lower byte, and then return pairs of cargotype/acceptance amount in 100+x registers
16:54:59  <frosch123> do not call the old cargotype cb if the acceptance cb returns a new result
16:55:51  <frosch123> but everything only if someone really wants to use those callbacks :p
16:56:28  <Hirundo> I have not been able to find any grf that does
16:56:40  <frosch123> yeah, i doubt there is any
16:57:03  <frosch123> everything i read about cargo acceptance/production for houses was: it's unstable, unplayable, bad :p
16:57:36  <Hirundo> Industry tiles have the same issue, with the same callbacks
16:57:45  <Hirundo> They possibly are used, not sure
16:58:15  <frosch123> they are used for stockpiling industries to deny acceptance
16:58:55  <frosch123> but that is also broken, since tile acceptance and industry acceptance cb are not called in sync
16:59:22  <Yexo> <Alberth> [17:34:48] and Y3xo hasn't even started :) <- If you two can manage without me that's fine :)
16:59:49  <Alberth> :)
16:59:58  <planetmaker> quak
17:00:05  <planetmaker> and hello yexo
17:00:13  <Yexo> good evening
17:00:19  <Hirundo> not in sync? that's baad...
17:00:39  <Hirundo> Did noone (George?) ever complain about that?
17:01:16  <Hirundo> s/noone/no-one
17:01:28  <frosch123> Hirundo: it only hurts the player :p
17:01:50  <Hirundo> I would assume he playtests his grfs
17:02:13  <frosch123> but yes, he complained that the cb is not called for every single unit of cargo
17:02:28  <frosch123> and thus industries can end up with 1005 units stockpiled, while the limit is 1000
17:02:45  <andythenorth> thus don't use that feature
17:02:53  <andythenorth> because 'tis broken
17:03:25  <frosch123> anyway, ottd updates station acceptance every 250 ticks or so
17:03:38  <frosch123> and industries are asked for acceptance for every cargo packet unloaded
17:03:56  <planetmaker> thus one can deliver industries 500 tiles from the station :-)
17:03:57  <frosch123> so there are times when the industry already denies the cargo, while the station still accepts
17:04:01  <planetmaker> just deliver enough :-)
17:04:18  <planetmaker> (or isn't it (anymore?) then given to the next accepting industry?
17:04:28  <frosch123> i am not sure about ottd's current behaviour. but it might actually be that the cargo is unloaded, but not paid for :p
17:04:49  <planetmaker> might be... I recall one coop savegame with pikka industries
17:05:17  <planetmaker> there we had one saw mill station. But due to low stockpile loads of sawmills actually got stuff, even when > 40 tiles out of reach
17:05:26  <planetmaker> thux next accepting station got it then
17:05:27  <frosch123> originally they were paid, but at some point smatz had to restructure that code, and a side effect was, that it stopped paying
17:05:31  <planetmaker> s/station/industry
17:05:43  <frosch123> the idea then was to return the cargo to the vehicle, but i think that was never done
17:05:49  <planetmaker> :-D
17:06:15  <frosch123> at least i have still some trunk checkout with some wip with that :p
17:06:23  <planetmaker> o_O
17:06:38  <frosch123> r22538
17:06:44  <andythenorth> acceptance is one of the more broken bits of industries :P
17:06:46  <Hirundo> In the ideal world, industries would have the option to specify a maximum amount accepted in CB 3D (ie return value 2, specify max amount in register 100)
17:06:56  <andythenorth> most of industries make at least some sense
17:07:46  <frosch123> Hirundo: good point, can be done now
17:08:31  <andythenorth> stations don't cache anything for 'accepting industries' ?
17:09:03  <Hirundo> AFAIK they do
17:09:37  <frosch123> andythenorth: they cache accepted cargo types
17:09:37  <frosch123> from houses and industries
17:10:02  <andythenorth> shame they can't update their cache after delivering n units cargo :P
17:10:14  <andythenorth> thereby achieving round-robin
17:10:53  * Hirundo senses another pony
17:11:01  <frosch123> there is also seasonal acceptance
17:11:18  <frosch123> and even original ttd has the bug that cargo acceptance ends up to 2 days after the industry closed
17:12:06  <frosch123> but those are corner cases compared to continuous acceptance changes of industries with stockpiles
17:15:13  <Hirundo> Would it be possible to set some (per-cargo) flag for industry tiles that says 'synchronize tile acceptance with the acceptance of the industry'?
17:15:58  <frosch123> then you cannot cache it anymore
17:16:13  <frosch123> you can only do the reverse: accept as along as tile accept
17:16:23  <frosch123> which is updated every 200 ticks
17:16:30  <frosch123> *250
17:16:43  <frosch123> but then you can quickly unload 64k tons, while the limit is 1k :p
17:17:27  <frosch123> maybe you could only cache house acceptance that way
17:17:31  <Yexo> <frosch123> then you cannot cache it anymore <- why is that?
17:17:34  <frosch123> and always iterate over all nearby industries
17:17:58  <frosch123> stations know about nearby industries
17:18:07  <frosch123> in that case tile acceptance of industries would have no meaning anymore
17:18:17  <frosch123> it would only depend on one tile begin in the catchment area
17:18:20  <frosch123> and the industry accepting it
17:18:26  <Yexo> so make a reverse cache to let industries about nearby stations that might need to be updated?
17:18:35  <frosch123> though that would break oilrigs
17:19:05  <frosch123> Yexo: what shall that cache contain?
17:19:12  <frosch123> a map of all tiles and their acceptance?
17:19:37  <frosch123> currently we only have a bitmask of cargos that resulted in more than 8/8 during the last update
17:19:46  <Yexo> for every industry list all stations that can deliver to one tile of that industry
17:19:48  <andythenorth> would break default steel mill as well, it has pax on some tiles
17:19:50  <andythenorth> iirc
17:19:52  <Brot6> nml: update from r1961 to r1964 done -
17:20:15  <frosch123> Yexo: we already have a list of industries in the catchment area of a station
17:20:21  <Yexo> if we'd change that bitmask to an integer count we could update it without having to redo the complete calculation
17:20:27  <frosch123> but industry acceptance != tile acceptance
17:20:38  <Yexo> but in an optimal world they would be equal, right?
17:20:45  <frosch123> oilrgis
17:20:50  <frosch123> banks
17:20:57  <frosch123> all industries which accept something
17:21:00  <frosch123> but do not process it
17:21:26  <Yexo> I probably do not get the problem
17:21:37  <andythenorth> it's a bad design :P
17:21:42  <andythenorth> but an elegant hack :)
17:22:10  <andythenorth> production code makes it obvious :)
17:23:15  <andythenorth> oil rig doesn't accept PAX
17:23:55  * andythenorth checks that's actually true :P
17:24:20  <frosch123> yeah, the oilrig industry window does not list pax acceptance
17:24:30  <frosch123> but the oilrig station accepts it nevertheless
17:24:33  <Hirundo> Bank accepts valuables, but the tiles accept valuables and (some) pax
17:24:50  <frosch123> we could change the meaning of industry tile acceptance
17:24:58  <frosch123> so that it always behaves like house acceptance
17:25:14  <frosch123> and every industry tile accepts all industry input nevertheless
17:25:28  <frosch123> so, in the normal case you would set all tiles to no acceptance
17:25:33  <frosch123> and only handle it via the industry
17:25:56  <frosch123> then the station can cache the cargo mask of house-style acceptance
17:26:04  <frosch123> and iterate the industries for industry-style acceptance
17:26:23  <Hirundo> That would be the 'ideal world' scenario
17:26:51  <frosch123> then stations no longer need to cover specific tiles of industries, but everyone suits
17:27:06  <Hirundo> IIRC george used that 'feature'
17:27:08  <frosch123> or we add a flag to industry tiles that they accept the industry's cargos
17:27:14  <frosch123> always 8/8 in that case
17:27:35  <frosch123> Hirundo: yeah, only the tank tile of powerplants accept oil
17:28:08  <frosch123> hmm, alternatively, we could compare the tile acceptance with the industry acceptance
17:28:41  <frosch123> and then consider the tile acceptance as house acceptance if they differ, or consider it as industry acceptance otherwise
17:29:12  <Hirundo> Makes sense
17:29:15  <frosch123> then only some industry tiles would accept some industry cargos, but every tile would still have 8/8
17:29:46  <frosch123> that would not need any specs change :p
17:30:20  <Hirundo> I'm not sure I understand that fully
17:30:58  <planetmaker> I like the idea to set acceptance only via industry
17:31:24  <frosch123> i should add another wiki page :p
17:31:26  <frosch123> i wanted that for long
17:31:29  <Hirundo> If a tile accepts (for x/8) a cargo accepted by the industry, tile acceptance is set to 8/8?
17:32:31  <frosch123> industry tiles are destingished between accepting cargos the industries processes, and cargos it does not process
17:33:17  <frosch123> a station accepts a cargo if there is a industry with a tile that accepts an processed cargo in the catchment area and cb 1d allows, OR if all houses and indtiles accepting non-processed cargos add up to 8/8
17:33:48  <frosch123> so, for houses and indtiles accepting non-processed cargos, everything stays the same
17:34:14  <frosch123> indtiles accepting processed cargos count always as 8/8, but only if cb 1d allows
17:34:32  <frosch123> the station caches the house-style acceptance
17:34:49  <frosch123> and a map of nearby industries to cargo types
17:36:57  <Hirundo> Which contains all combinations of industries and cargo types, for which a) the cargo type is accepted by the industry (or not, if the CB denies it) and b) at least 1 tile having at least 1/8 acceptance for the cargo type is within the station rectangle??
17:37:38  <frosch123> yes
17:38:26  * andythenorth tries to work out if this changes newgrf behaviour
17:38:57  <frosch123> andythenorth: you do no longer have to implement the tile acceptance cb for stockpiling
17:39:21  <frosch123> actually, if you would, it would make it as broken as currently
17:39:36  <andythenorth> and for tiles accepting cargos the industry doesn't accept?
17:39:40  <andythenorth> e.g. oil rig
17:39:56  <frosch123> you can change the acceptance every 250 ticks using the tile cb
17:40:14  <frosch123> if you really want to
17:40:20  <frosch123> (stockpiling does no such things)
17:40:38  <andythenorth> I just want 8/8 acceptance, constant
17:47:33  *** Xotic750_ has joined #openttdcoop.devzone
18:09:21  <Brot6> zBaseBuild - Revision 75:1bd4a67fc2cc: Add: Farm fences XAlberthX @
18:10:41  <Brot6> zBuild - Revision 23:d88002af46cd: Change: Update subrepos XAlberthX @
18:12:29  <Brot6> Useless Tracks - Revision 7:be1bff5923d1: Update: lifted track graphics XfoobarX @
18:12:29  <Brot6> Useless Tracks - Revision 8:b801f4854b43: Feature: planning tracks XfoobarX @
18:21:59  <Brot6> Useless Tracks - Revision 9:2bb92615d853: Add: level crossings for planning tracks XfoobarX @
18:47:43  <Brot6> Useless Tracks - Revision 10:8864a84a352a: Add: TTD style GUI for planning tracks XfoobarX @
18:48:46  <Brot6> zBase - Bug #4120 (Closed): Missing temperate trees XRubidiumX @
18:48:46  <Brot6> zBase - Revision 50:c09c7f4ffa0f: Fix (r45): Add missing temperate tree sprites, fix render overwrit... XzephyrisX @
18:48:46  <Brot6> zBase - Bug #4120 (Closed): Missing temperate trees XzephyrisX @
19:14:55  <Brot6> zBaseBuild - Revision 76:812d37384305: Add: last missing temperate tree XRubidiumX @
19:15:44  <Brot6> zBuild - Revision 24:c8cedb158b82: Add: last missing temperate tree XRubidiumX @
19:17:43  <Brot6> zBase - Revision 51:8c1be36f3712: Fix (r42): Alter headquarters to use separate building sprites fro... XzephyrisX @
19:17:43  <Brot6> zBase - Bug #4118 (Closed): HQ made of split sprites XzephyrisX @
19:18:52  <Brot6> zBase - Bug #4121 (New): Climate-specific 1st and 2nd Generation HQs XzephyrisX @
19:27:26  <Brot6> zbuild: update from r21 to r23 done (1168 warnings) -
19:31:55  <Brot6> zBase - Revision 52:a784e51737ba: Fix (r31): Fix asymmetry in wood bridge decks. (Bug: #4109) XzephyrisX @
19:31:55  <Brot6> zBase - Bug #4109 (Closed): Wooden bridge edge misaligned XzephyrisX @
19:33:19  <Brot6> zBase - Bug #4122 (New): Last stage HQ south western ground tiles too small XRubidiumX @
19:35:06  <Brot6> zBaseBuild - Revision 77:edf99922a81f: Change: use the proper HQ building sprites/ground tiles XRubidiumX @
19:36:20  <Brot6> zBuild - Revision 25:81d3ea1f6cd2: Update: HQ sprites and wooden bridge XRubidiumX @
19:47:00  <Brot6> zBase - Revision 53:1e12944bc415: Fix (r26): Correct slope shape for temperate 2/3 grass (0, 1, 1, 1... XzephyrisX @
19:47:00  <Brot6> zBase - Bug #4108 (Closed): 66% grassy sloped tiles wrong XzephyrisX @
19:49:26  *** andythenorth has quit IRC
19:50:41  <Brot6> zBuild - Bug #4123 (New): DevZone compile failed XcompilerX @
19:51:21  *** Alberth has left #openttdcoop.devzone
19:55:57  <Rubidium> can I somewhere, easily, see whether the compile farm is busy with building a pushed z[base][build]?
20:01:08  <planetmaker> hm...
20:02:28  <Rubidium> if it is compiling the last pushed version, then I'll leave it at that. Otherwise I'll push something so it can compile a 'fixed' version as somehow I guess I didn't update the zbuild sub repositories properly
20:02:35  <Rubidium> which is why zbuild failed
20:02:55  <planetmaker> looks inactive
20:04:44  <Rubidium> then it may try to compile again now ;)
20:04:50  <Brot6> zBuild - Revision 26:47f0d71ed038: Fix: also incorporate the updated 66% grassy tiles XRubidiumX @
20:07:15  <planetmaker> he, did you push a release to zbuild?
20:07:51  <Rubidium> not that I'm aware of
20:10:46  <planetmaker> then the call parameters just look funny to the build script :-)
20:11:09  <planetmaker> bash /home/hg/misc/compiler/ -releases zbuild
20:24:07  *** frosch123 has quit IRC
20:26:44  <Brot6> OpenGFX+ Trains - Support #4124 (New): Have m4_experiment branch built nightly XXotic750X @
21:06:25  <Brot6> zbuild: update from r23 to r26 done (1168 warnings) -
21:11:00  <Brot6> zBase - Bug #4122 (Closed): Last stage HQ south western ground tiles too small XRubidiumX @
21:11:00  <Brot6> zBase - Revision 54:f8267253c7b2: Fix (r51): South west ground tile size for 5th generation headquar... XzephyrisX @
21:11:00  <Brot6> zBase - Bug #4122: Last stage HQ south western ground tiles too small XzephyrisX @
21:11:00  <Brot6> zBase - Bug #4122 (Closed): Last stage HQ south western ground tiles too small XzephyrisX @
22:16:44  *** Xotic750_ has quit IRC
22:45:48  <Brot6> zBase - Revision 55:9ce889d94fc9: Add: Factory (assuming I worked out the sprites correctly!). XzephyrisX @
23:08:18  <Brot6> zBase - Revision 56:96b2291cabea: Add: Printing works. XzephyrisX @
23:09:27  <Brot6> zBase - Revision 57:47d619a3bd25: Add: Arctic and tropic farm (currently a duplicate of temperate). XzephyrisX @
23:49:49  <Brot6> zBase - Revision 58:9a6a17f435a9: Add: Steel mill. XzephyrisX @
23:59:02  *** ODM has quit IRC

Powered by YARRSTE version: svn-trunk