Log for #openttdcoop.devzone on 5th September 2011:
Times are UTC Toggle Colours
00:00:18  <Brot6> DevZone Help Center - ttd-newgrf-psp7-dos.pal (planetmaker) @
00:00:18  <Brot6> DevZone Help Center - ttd-newgrf-dos.gpl (planetmaker) @
07:05:30  <Brot6> OpenGFX+ Airports - Feature #3031: Todo for release 0.3.0 (planetmaker) @
07:06:20  <planetmaker> Ammler, do you have an idea what triggered the two messages of Brot from 2am?
07:45:08  *** mib_ajnjwk has joined #openttdcoop.devzone
07:45:38  <mib_ajnjwk> HI
07:46:22  <planetmaker> hi
07:50:51  <mib_ajnjwk> I was wondering if someone could give me a hand on a Problem I have. I need a guide on How to change teh properties of Vehicles in a newgrf file
07:52:18  <Hirundo> Guide can be found here:
07:55:34  *** ODM has joined #openttdcoop.devzone
08:04:25  <mib_ajnjwk> thanks
08:04:52  <mib_ajnjwk> Still try to figure ot how to create a nml from a nfo
08:05:24  <planetmaker> that doesn't exist in a releasable, automated way
08:06:08  <planetmaker> you might sweet-talk yexo to convert something for you; you'll have to do a lot of cleanup afterwards (e.g. nice naming and stuff)
08:06:22  <planetmaker> but maybe that code meanwhile doesn't work anymore properly due to certain changes in NML... dunno
08:06:45  <mib_ajnjwk> oh, ok! So, there is noch easy way in extracting a grf file, changing for example a view starting dates for vehicles and compiling them again?
08:07:02  <planetmaker> (I hope Yexo doesn't mind talking about the existance of such draft ;-) )
08:07:14  <planetmaker> no, that doesn't exist.
08:07:31  <planetmaker> But what you can do is write an add-on NewGRF which modifies properties of vehicles defined in another NewGRF
08:07:39  <planetmaker> as such you don't need to de-compile anything
08:07:56  <Hirundo> the state of the NFO->NML converter is quite interesting... it's known to exist but no-one has ever seen it :)
08:08:08  <mib_ajnjwk> lol
08:08:09  <planetmaker> ^ quantum code ;-)
08:08:57  <Hirundo> though arguably, decompilers may be harder to write than compilers
08:08:59  <mib_ajnjwk> ok, one last question, then I won't bugger you again.... soon :-)
08:09:08  <planetmaker> I wonder whether it could be attached to some long-term issue in NML
08:09:12  <planetmaker> yes, de-compiler...
08:09:17  <mib_ajnjwk> Are there any guid on how to create those extensions?
08:09:32  <mib_ajnjwk> Mentioned above
08:09:53  <Hirundo> You'll need an engine_override(..) in NML
08:10:53  <Hirundo> bbl
08:11:35  <planetmaker>
08:12:12  <planetmaker> small sidenote: works only in OpenTTD, not in TTDPatch
08:13:19  <planetmaker> then you subsequently (re-)define the properties you want with the correct vehicle IDs as found in the target NewGRF you want to override
08:13:52  <planetmaker> make sure you come back to us with the source code of the complete NewGRF - there's no example NewGRF written in NML which does this
08:14:15  <planetmaker> except maybe a regression test or so. dunno
08:14:28  <mib_ajnjwk> Allrigth, that'll do! I'll try it
08:14:35  <mib_ajnjwk> Thanks a lot for your help
08:14:54  <planetmaker> you're welcome
08:15:19  <planetmaker> if you like, request a project on the DevZone - provided you use an open source license :-)
09:56:24  *** andythenorth has joined #openttdcoop.devzone
10:01:13  <Yexo> <Hirundo> the state of the NFO->NML converter is quite interesting... it's known to exist but no-one has ever seen it :) <- I've uploaded the code a few times
10:01:34  <Yexo> the main problem with it is that there are quite some cases where it doesn't work
10:01:51  <Yexo> hence I'm not too happy about releasing it to the general public, as I already know that will lead to lots of bug reports
10:02:26  <Yexo> but no, I don't mind talking about the existance of it, or even trying to decompile some grfs
10:02:32  <Yexo> mib_ajnjwk: which grf are you trying to decode?
10:04:10  <Yexo> Hirundo: <- that patch is from June 18 this year
10:09:18  <Brot6> Central European Train Set - Revision 143:a1c85b0ab15d: make the 16lu wagons visible again (Eddi) @
10:12:47  <Brot6> Central European Train Set - Revision 144:305777fd2f10: remove some now unused files (Eddi) @
10:15:44  *** andythenorth has left #openttdcoop.devzone
10:32:11  <Brot6> FIRS Industry Replacement Set - Revision 2577:bfe1d14d2af2: Codechange: Rename Biorefinery layout... (Terkhen) @
10:43:20  <planetmaker> btw, Yexo did you risk a look at the "prepare release" diff I added to the related opengfx+airports issue?
10:45:57  <planetmaker> #3031
10:45:57  <Brot6> planetmaker: #3031 is "OpenGFX+ Airports - Feature #3031: Todo for release 0.3.0 - #openttdcoop Development Zone"
10:52:07  <Yexo> not yet, I missed it
10:52:10  <Yexo> will look now
10:52:50  <Yexo> the credits in readme.txt don't align (tabs vs spaces)
10:53:43  <planetmaker> hmpf
10:55:28  <Yexo> readme files is still biased towards nfo projects: "MinGW/MSys contain the above mentioned programmes (except renum and
10:55:28  <Yexo> 71
10:55:28  <Yexo> grfcodec of course)"
10:56:18  <Yexo> but that's probably a more general issue with the makefile bundle, not specially for this project
10:57:17  <Yexo> imo that can be left, is you fix the credits section it's good enough to release
10:57:18  <planetmaker> well... the makefile bundle doesn't ever patch existing readmes :-)
10:57:37  <Yexo> ah, true
10:58:53  <planetmaker> indeed, I'll leave the description for building now, though...
10:59:07  <Yexo> as version imo 0.3 would be good now
10:59:07  <planetmaker> The makefile bundle indeed _does_ need an update there
10:59:17  <planetmaker> ok, then I just do that :-)
10:59:28  <Yexo> then we can release 1.0 as new version as soon as openttd 1.2 is released and as such the newgrf is supported by stable openttd
11:02:21  <planetmaker> This NewGRF will suffer the same issue as now FIRS and OpenGFX+Landscape have: not suitable for trunk... what min. version should I set?
11:03:18  <Yexo> the minimum version it needs?
11:04:03  <Brot6> OpenGFX+ Airports - Revision 142:5022fcadf0d8: -Prepare: Update documentation and version informa... (planetmaker) @
11:28:21  <Brot6> OpenGFX+ Airports - Bug #3032 (Confirmed): preview graphics have holes (planetmaker) @
11:29:00  <planetmaker> <-- we don't release yet ;-)
11:29:03  <planetmaker> ^ Yexo
11:37:13  <Yexo> strange bug
11:43:28  <Yexo> I can reproduce it, but the graphics in the repo look fine
11:43:38  <Yexo> as does the code
11:43:42  <planetmaker> hm...
11:43:58  <planetmaker> strange. I shall try maybe later today at home
11:44:04  <planetmaker> osx cannot be an excuse ;-)
11:45:01  <planetmaker> might it be a bug with a specific sdl version?
11:45:37  <Yexo> seems unlikely
11:45:48  <Yexo> why would both you and me have it, and only for this specific type of sprites?
11:46:28  <Yexo> to me it seems to be either a very strange bug in nml (but why haven't we seen it before?) or an obscure one in openttd (again, why now?)
11:47:10  <planetmaker> hm... I compiled with nml r1661
12:11:50  <Brot6> Central European Train Set - Revision 145:aed8a43cba02: experimental movement scheme for 16lu veh... (Eddi) @
12:19:52  <Hirundo> planetmaker: Yexo: Could it be an overflow in the sprite encoder?
12:20:29  <Yexo> it could be, I really have no clue
12:20:43  <Yexo> haven't looked into it either yet
12:22:26  <Hirundo> hmm yes, it seems tile compression overflows after 7f pixels
12:23:32  <planetmaker> @base 16 10 7f
12:23:33  <Webster> planetmaker: 127
12:23:39  <planetmaker> that's tiny
12:24:43  <Hirundo> I don't see where you'd use such wide sprites other than for airport previews
12:25:13  <planetmaker> oh, you mean sprite width?
12:25:34  <planetmaker> object preview
12:25:35  <Hirundo> yes
12:25:36  <Brot6> OpenGFX+ Airports - Bug #3032: preview graphics have holes (planetmaker) @
12:25:40  <Hirundo>
12:25:47  <Hirundo> ^ Could you try with this diff?
12:27:46  * planetmaker tries but has slow computer here :-)
12:29:11  <Hirundo> Yexo: Why is sprite width limited to 255? I thought only ysize (num_lines) had such a low limit
12:33:55  <Yexo> hmm, python is using 2.5gb before it's killed (oom) while trying to encode airportsplus
12:35:45  <Yexo> Hirundo: ^^ that is with your patch, without it python "just" using 500mb
12:36:08  <Hirundo> and when compiling a different grf ?
12:38:33  <Yexo> firs: without patch 180mb, with patch the same
12:38:44  *** dnicholls has joined #openttdcoop.devzone
12:40:12  <Yexo> about sprite size: I don't know what the exact limits are
12:41:55  <dnicholls> afternoon all
12:42:40  <Hirundo> IIRC xsize 16 bit, ysize 8 bit
12:43:46  <Yexo> think I found the problem
12:44:59  <Yexo> your patch was correct, but triggered an infinite loop
12:45:08  <Yexo> after fixing that it's correct now
12:45:13  <Brot6> NewGRF Meta Language - Revision 1662:b81b54157472: Fix: overflow with sprites wider than 127px (H... (yexo) @
12:46:40  <Yexo> dnicholls: is anything missing before a release of OpenGFX+airports?
12:46:40  <Hirundo> ah great
12:46:50  <Brot6> OpenGFX+ Airports - Bug #3032 (Closed): preview graphics have holes (planetmaker) @
12:46:50  <Brot6> OpenGFX+ Airports - Bug #3032 (Closed): preview graphics have holes (yexo) @
12:49:43  <dnicholls> yexo: I think there's nothing missing
12:50:59  <Yexo> planetmaker: so ok for release?
12:55:51  <Hirundo> Yexo: I can understand the issues with a nfo->nml converter that works in all cases
12:55:58  <Hirundo> What are the main points that don't work?
12:56:29  <Yexo> everytime we have special cases in nml for action0 properties they need special handling in the decompiler too
12:56:39  <planetmaker> you evil BOFH, Hirundo ;-)
12:56:44  <Yexo> skipping actions with action7 / action9 is only partially supported by the decompiler
12:56:47  <planetmaker> You rdos'ed my computer
12:57:16  <Hirundo> My bad :) Don't shoot me!!!
12:57:21  * Yexo was happy my kernel decided to kill python first
12:57:25  <planetmaker> just this time ;-)
12:57:39  <Hirundo> That's what happens when releasing untested code
12:57:44  <planetmaker> hehe :-)
12:59:21  <Yexo> Hirundo: a more general problem: nml supports code like: return sound("some_file.wav"); in switch-blocks
12:59:36  <Yexo> in nfo that is just "return 73;" (for the first sound, second sound would be 74 etc.)
12:59:52  <Yexo> the decompiler has no way of knowing that is should convert the "73" to a soundfile
13:00:07  <Yexo> and it doesn't support named callbacks yet
13:00:16  <Yexo> if that is done, that could solve the sound problem
13:00:42  <Hirundo> Though it depends on having a sane varaction2 structure in nfo
13:00:50  <Yexo> yes
13:01:12  <Yexo> GRM is not yet supported, and neither are patch variables
13:01:35  <Yexo> the latter is problematic since most patch variables are not directly accessible in nml, only parts of them or only after some conversion
13:02:13  <Yexo> some grfs have for example multiple cargo translation tables, which is very problematic for a decompiler
13:02:30  <Hirundo> I guess you could get away with "I'm sorry, I don't understand this patch variable/... on line X." Please fix up later
13:02:40  <Yexo> that is what it currently does
13:02:57  <Yexo> it just prints "TODO_PATCH_VARIABLE" instead of the real variable name
13:03:08  <Hirundo> IMO that's not a big deal, as long as it's documented and/or provides a clear warning
13:04:04  <Yexo> to have somewhat sane nml output it needs to know which constants belong to which properties
13:04:22  <Yexo> ie functions like this:
13:05:20  <Hirundo> Such information could be useful for the nml->nfo conversion also, to warn if the user does stupid things
13:05:48  <Yexo> yep
13:05:59  <Yexo> actionA is completely ignored currently, although that should be easy to fix
13:06:14  <Yexo> (it's properly ignored, the real sprites are also skipped)
13:06:39  <Yexo> the decompiler doesn't support the more advanced string features
13:07:24  <Hirundo> That's to be expected, as they were added recently
13:07:50  <Yexo> I meant "cases" and "plural" codes
13:08:01  <Yexo> those are not that new anymore
13:08:03  <Hirundo> I'd say it makes sense to add as much as possible to the repository, that way it's much easier to keep up to date
13:08:49  <Yexo> that's true
13:09:18  <Yexo> I'll make a start with adding it bit by bit to the repo, documenting whatever I add in the process
13:09:48  <planetmaker> totally different topic: C++: I have a class derived from a base class which implements a function declared virtual in the base class. Does it matter whether I delcare it (again) virtual in the derived class?
13:10:05  <Yexo> AFAIK not
13:10:30  <Hirundo> no, unless you plan to make a 'derived-derived'  class later
13:10:31  <planetmaker> we find in OpenTTD's code both nicely mixed in all places
13:10:46  <planetmaker> ok... so it matters for the "child"
13:12:02  <Yexo> Hirundo: I'd prefer to start after we branch 0.2, so it's clearly separated from that
13:12:21  <Hirundo> agreed
13:14:48  <planetmaker> what stops tagging 0.2.0?
13:15:33  <Yexo> the open issues
13:16:06  <Yexo> those should be the first efforts now, only after that more codechanges / new features
13:16:26  <Yexo> Hirundo: what do you plan for #1395?
13:16:27  <Brot6> Yexo: Hirundo: #1395 is "NewGRF Meta Language - Feature #1395: sprite layouts - #openttdcoop Development Zone"
13:16:41  <Yexo> all for 0.2 or leave it for now?
13:16:50  <Hirundo> passing a spriteset as a parameter
13:17:03  <Yexo> yes, but that only adds option, it's a new feature that can as well be added later
13:17:24  <Hirundo> I have the initial steps ready, but still no working dev environment nor time to properly set one up :(
13:17:32  <planetmaker> The example projects are not a show-stopper anymore. We have the wiki now
13:17:41  <Yexo> agreed
13:18:09  <Yexo> #1629 and #2933 are show-stoppers
13:18:10  <Brot6> Yexo: #1629 is "NewGRF Meta Language - Bug #1629: Review conversion for speed property - #openttdcoop Development Zone"
13:18:10  <Brot6> Yexo: #2933 is "NewGRF Meta Language - Bug #2933: Handling of failed callbacks - #openttdcoop Development Zone"
13:18:44  <Yexo> #2977 is nice-to-have, but not critical imo
13:18:44  <Brot6> Yexo: #2977 is "NewGRF Meta Language - Feature #2977: town variables - #openttdcoop Development Zone"
13:18:50  <Yexo> on the other hand it should be fairly easy
13:19:33  <Hirundo> ^it takes some time, but you can switch off half of your brain while doing it
13:20:47  <Hirundo> For #1692, you'd need to study all the conversion effects inside nml/openttd
13:20:47  <Brot6> Hirundo: #1692 is "FIRS Industry Replacement Set - Feature #1692: Why is scrap metal piece goods, not bulk? - #openttdcoop Development Zone"
13:20:58  <Hirundo> err, #1629
13:20:58  <Brot6> Hirundo: err: #1629 is "NewGRF Meta Language - Bug #1629: Review conversion for speed property - #openttdcoop Development Zone"
13:21:41  <Hirundo> AFAIK rounding of other units was changed from floor() to nearest() in OpenTTD, but speeds were unchanged because of legacy reasons
13:21:57  <Hirundo> therefore, the speed conversion is biased and much worse than others
13:21:58  <Yexo> yes, I have quite a good overview of what happens, but it's hard to come up with a clean way to fix the problem in nml
13:22:15  <Yexo> and yes, speed doesn't round properly in openttd
13:42:12  <dnicholls> planetmaker: typo in readme, my first name is David
13:42:25  <planetmaker> hm, what did I write?
13:42:31  <dnicholls> daniel
13:42:34  <planetmaker> oh :-)
13:42:37  <planetmaker> sorry
13:42:45  <dnicholls> heh :)
14:02:10  *** mib_ajnjwk has quit IRC
14:11:49  <Brot6> OpenGFX+ Airports - Revision 143:5e664675b76c: Fix: typo in readme (yexo) @
14:11:55  <Yexo> dnicholls: you want to write a forum post about the release?
14:12:38  <planetmaker> thanks for the fix, Yexo :-)
14:13:00  <Yexo> last call, anything blocking the release before I push the 0.3.0 tag?
14:13:18  <planetmaker> if it works without broken sprites :-)
14:13:37  <planetmaker> let me compile here, too
14:13:56  <Yexo> make sure to pull last nml
14:14:16  <planetmaker> thx
14:14:24  <planetmaker> Yexo: then don't push a tag now
14:14:32  <planetmaker> The CF will use yesterday's nightly otherwise
14:14:43  <Yexo> hmm, right
14:15:07  <dnicholls> yexo: yep I can write something
14:17:51  <Yexo> ok, compiling a new nml nightly first now
14:22:20  <Brot6> nml: update from r1661 to r1662 done -
14:23:45  <Yexo> planetmaker: did it work for you too?
14:24:27  <dnicholls> works on my end
14:24:45  * planetmaker should stop trying to multi-task
14:28:05  <planetmaker> other computer, but looks ok to me
14:28:15  <Yexo> ok, here goes :)
14:28:32  <Brot6> OpenGFX+ Airports - Revision 144:210a3c22bd6d: Added tag 0.3.0 for changeset 5e664675b76c (yexo) @
14:33:22  <Brot6> airportsplus: update from 0.2.1 to 0.3.0 done -
14:36:37  <dnicholls> nice work :)
14:37:21  <dnicholls> can anything be done about it being called "Climate dependent airports" on bananas?
14:37:21  <planetmaker> your work! :-)
14:37:57  <planetmaker> hm... I shall take a look. But won't promise anything
14:38:04  <planetmaker> I fear to destroy stuff :-)
14:38:17  <planetmaker> normally the answer is 'no'
14:39:46  <Yexo> that can't be fixed (easily)
14:41:00  <Yexo> planetmaker: I can upload from to bananas, right?
14:41:19  <Yexo> dnicholls: the description on bananas can be changed, if you have any suggestions?
14:41:53  <planetmaker> Yexo: that's the savest way, yes. Just upload that zip
14:44:00  <dnicholls> "Adds rotations and climate-dependent graphics for the default airports" might be nicer
14:44:48  <Yexo> done :)
14:45:38  <planetmaker> Yexo: how do you change that?
14:45:56  <planetmaker> or you mean upload? I mean changing name
14:45:56  <Yexo> bananas, manager tab, click "edit", change description
14:46:16  <Yexo> I meant done with updating the description as dnicholls proposed it
14:46:35  <Yexo> I have no clue how to change the name. I've heard it requires manually fixing it in the database
14:46:50  <Yexo> and I don't even have access to the link you posted in the other channel
14:47:08  <planetmaker> oh, the description can be changed during upload, yes
14:47:23  <planetmaker> I thought about the displayed name. Which still is climate dependent airports
14:47:46  <planetmaker> And I don't even find it in our database ;-)
14:47:53  <planetmaker> and I'm scared of the datebase, too :-P
14:47:57  <Yexo> but the displayed name has a direct relationship with the filename
14:48:12  <planetmaker> yes
14:51:05  <dnicholls> if tags can also be edited, would be useful to add opengfx, snow, rotation
14:51:29  <planetmaker> they can
14:51:52  <planetmaker> dnicholls: are you actually interested in updating OpenGFX itself with your updated graphics?
14:52:18  <dnicholls> I would like to :)
14:52:30  * planetmaker too :-)
14:53:37  <planetmaker> It's mostly in nfo, though. But for real sprites that's not that bad...
14:54:14  <dnicholls> nfo can be tamed
14:54:38  <planetmaker> base sets are as tame as nfo can be
14:54:42  <planetmaker> except the rivers ;-)
14:55:27  <planetmaker> ok, I give you access to that repo then, too and you "fix" the airports there, too?
14:56:04  <dnicholls> yes please :)
14:56:21  <planetmaker> great :-)
14:56:28  <planetmaker> done
14:57:17  <planetmaker> when changing sprites: make sure you add or modify credits in docs/authorreview.csv
14:57:31  <planetmaker> it keeps track roughly who drew and modified which sprites
14:57:53  <planetmaker> (and who coded them)
14:58:00  <planetmaker> code = align
14:59:30  <dnicholls> ok will do
15:03:02  <dnicholls> hmm I don't think airportsplus has a release thread. Make a new one or add to the dev thread?
15:03:50  <Yexo> so far it was a bit work in progress, I think with all your new graphics it can have a release thread
15:04:13  <planetmaker> I agree
15:04:31  <planetmaker> it's now definitely a 'full set'
16:18:29  <dnicholls> post done
16:21:23  <Yexo> nice work, and nice screenshots too :)
16:23:15  <dnicholls> would it be possible to have layouts with introduction dates?
16:23:56  <dnicholls> the idea being we could add more "rotations" of the small airport with modern graphics at some point
16:24:37  <Yexo> that is not (yet) possible
16:25:05  <Yexo> you can just add more variations and let the user take care of when he/she builds those
16:26:23  <dnicholls> sounds good
16:27:27  <Ammler> <-- why are grass parts of the big airport snowy, some aren't?
16:27:43  <Yexo> the two tiles that are snowy are not part of the airport
16:27:59  <Yexo> the other tiles will have to be made more properly snow-aware at some point
16:31:51  <Ammler> I see
16:37:30  <dnicholls> I suppose we could also have partially snowy graphics for tiles that are one tile below the snowline
16:38:03  <Yexo> yes, planetmaker has done it for firs
16:38:12  <dnicholls> ahh
16:58:39  <Brot6> DictatorAI - Revision 191:104c377e64e2: - Delete the train engine and its wagon when we need an u... (krinn) @
17:07:17  *** frosch123 has joined #openttdcoop.devzone
17:20:03  *** Hanf has joined #openttdcoop.devzone
17:22:25  <Brot6> firs: update from r2574 to r2577 done -
17:25:37  <Brot6> cets: update from r140 to r145 done (475 warnings) -
17:28:07  <Brot6> airportsplus: update from r135 to r144 done -
17:28:08  <Brot6> Following repos didn't need a nightlies update: ogfx-trains (r252), narvs (r52), bros (r52), ogfx-industries (r123), opengfx (r732), ailib-tile (r16), foobarstramtracks (r23), transrapidtrackset (r28), 2cctrainset (r750), ailib-list (r32), opensfx (r97), ttdviewer (r34), worldairlinersset (r672), heqs (r640), openmsx (r97), basecosts (r25), nutracks (r208), nml (r1662), water-features (r51), 32bpp-extra (r40), manindu (r7),
17:28:09  <Brot6> newgrf_makefile (r305), ailib-direction (r17), ailib-common (r21), snowlinemod (r49), dutchtramset (r87), ai-admiralai (r75), swisstowns (r22), metrotrackset (r56), dutchroadfurniture (r12), spanishtowns (r10), frenchtowns (r6), grfpack (r279), ogfx-rv (r110), fish (r684), ogfx-landscape (r85), ttrs (r36), ogfx-trees (r51), swedishrails (r206), grfcodec (r833), ai-aroai (r49), german-townnames (r34), smts (r19), chips (r143),
17:28:12  <Brot6> belarusiantowns (r8), indonesiantowns (r41), ailib-string (r29), comic-houses (r71)
17:46:21  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-trains, narvs (11 warnings) (Diffsize: 7113), ogfx-industries (1 warnings) (Diffsize: 127939), foobarstramtracks (Diffsize: 11458), manindu (Diffsize: 2), newgrf_makefile, dutchtramset (Diffsize: 25964), swisstowns, dutchroadfurniture (Diffsize: 4509), spanishtowns (Diffsize: 2), frenchtowns, ogfx-rv, ogfx-landscape (1 warnings), swedishrails
17:46:21  <Brot6> (Diffsize: 1350), german-townnames (Diffsize: 1), belarusiantowns (Diffsize: 30), indonesiantowns (1 warnings) (Diffsize: 1)
18:06:37  *** andythenorth has joined #openttdcoop.devzone
18:55:53  *** andythenorth has quit IRC
18:56:20  *** andythenorth has joined #openttdcoop.devzone
19:06:11  <Brot6> clientpatches: compile of r22896 still failed (#2964) -
19:12:11  <Brot6> openttd-vehiclevars: update from r22893 to r22896 done (2 warnings) -
19:13:49  <Brot6> serverpatches: compile of r22896 still failed (#2966) -
19:15:46  <Brot6> 32bpp-ez-patches: compile of r22896 still failed (#2446) -
19:32:57  *** Zuu has joined #openttdcoop.devzone
19:33:27  *** Zuu is now known as Guest8990
19:42:12  <andythenorth> Terkhen: did you figure out the FIRS tile templates? :D
20:00:31  *** dnicholls has quit IRC
20:09:56  <Terkhen> andythenorth: no
20:12:02  <andythenorth> :P
20:12:08  * andythenorth has been reading template code
20:12:12  *** Guest8990 is now known as Zuu
20:13:13  <Terkhen> with any success?
20:13:22  <andythenorth> not really
20:13:33  <andythenorth> I don't really understand the aim at the moment
20:13:54  <Terkhen> of what templates? I can explain the spritelayout templates
20:14:08  <andythenorth> yes those
20:14:19  <andythenorth> I can make guesses, but guesses aren't reliable
20:15:04  <Terkhen> check SPRITELAYOUT_NORMAL_BEGIN first
20:15:22  <Terkhen> spritelayout_name is the name that will be used to reference the spritelayout defined by the template
20:15:45  <Terkhen> ground_sprite_normal contains either a ttdsprite number or a spriteset containing the sprite to use for ground
20:15:57  <Terkhen> building_spriteset contains the spriteset with the building sprite
20:16:11  <Terkhen> building_zextent is the value to use for the zextent of the building bounding box
20:16:23  <Terkhen> the template starts a spritelayout block
20:16:35  <Terkhen> the ground block inside it defines the ground sprite
20:16:50  <Terkhen> ignore that LOAD_TEMP stuff for now :P
20:17:05  <Terkhen> treat it as if it was "sprite: GROUNDSPRITE_NORMAL;"
20:17:25  <Terkhen> which contains the "normal" ground sprite for the current climate
20:17:37  <andythenorth> hmm
20:17:44  <Terkhen> everything right for now? :P
20:17:45  <andythenorth> so SPRITELAYOUT_NORMAL chains a call to SPRITELAYOUT_NORMAL_BEGIN?
20:17:51  <Terkhen> yes
20:17:58  <Terkhen> SPRITELAYOUT_NORMAL_BEGIN can be used as a block
20:18:03  <Terkhen> it is a template missing the ending "}"
20:18:37  <Terkhen> so you can do stuff like this:
20:19:04  <Terkhen> you can define additional buildings and so on inside the template, and then close it
20:19:21  <Terkhen> kind of messy, but it saves creating a thousand templates :)
20:20:11  <andythenorth> right
20:20:13  <andythenorth> ok
20:20:51  <Terkhen> that template is thought for a different structure of spritelayouts
20:21:01  <Terkhen> before, we had one, two or three different ground sprites
20:21:08  <Terkhen> normal, desert, snow
20:21:12  <Terkhen> and different building sprites
20:21:34  <Terkhen> now we want to have a truly tile aware ground sprite
20:21:50  <Terkhen> that takes into account half-desert, partial snow and so on
20:22:03  <Terkhen> that template is already made, and it stores the correct sprite number inside a temporary register
20:22:11  <Terkhen> besides that, we have ground overlays
20:22:30  <Terkhen> the number of ground overlays is not fixed so we can't add that to the template itself
20:24:10  <andythenorth> why don't we fix it?
20:24:24  <andythenorth> there should be 1 ground overlay per tile
20:24:31  <andythenorth> there may be n building sprites
20:26:12  <Terkhen>
20:26:17  <Terkhen> I'm planning something like that
20:26:30  <Terkhen> you can also have as many buildings as you want
20:27:15  <Terkhen> a example of condition might be terrain_type == TILETYPE_SNOW
20:27:46  <Terkhen> why only a ground overlay? planetmaker mentioned more
20:27:50  <Terkhen> one per tile type IIRC
20:28:04  <andythenorth> hmm
20:28:09  <andythenorth> maybe I misunderstand
20:28:17  <Terkhen> there are many ways of doing this :)
20:28:30  <Terkhen> in my example, all overlays are defined, but they are hidden conditionally
20:28:39  <Terkhen> but we could have a single overlay in the template
20:28:47  <Terkhen> and use another temporary register to store the sprite used for overlay
20:28:56  <Terkhen> and if sprite == 0 -> no overlay
20:29:23  <andythenorth> do we have a case for >1 ground overlay?
20:29:31  <Terkhen> I don't know :P
20:29:57  <Terkhen> IIRC you planned to use them for the black silhouettes of buildings in transparent mode, right?
20:30:09  * Terkhen is usually lost when actual sprites appear in the conversation
20:30:58  <andythenorth> yes
20:31:06  <andythenorth> I am lost with the macros :P
20:31:28  *** JVassie has joined #openttdcoop.devzone
20:31:29  <Terkhen> which ones?
20:32:14  <andythenorth> the spritesets and spritelayouts
20:32:39  <Terkhen> name?
20:32:54  <andythenorth> e.g. tmpl_building_sprite_filename
20:33:17  <Terkhen> ah, yes, those are nml templates
20:33:17  <andythenorth> probably I should just trust them
20:33:52  <andythenorth> I'm currently lost at sea though :)
20:34:01  <Terkhen> usually spritesets use this syntax: [12, 12, 64, 31, -31, 0]
20:34:17  <Terkhen> explained here:
20:34:25  <andythenorth> yes
20:34:34  <andythenorth> xpos, ypos, crop, offset
20:34:47  <Terkhen> but nml allows you to define templates to write common stuff
20:35:00  <Terkhen> for example, all ground tiles use [x, y, 64, 31, -31, 0]
20:35:17  <andythenorth> k
20:37:22  <Terkhen> common smoke animations are templated as buildings at smoke_templates.pnml
20:39:14  <andythenorth> I saw those :)
20:40:08  <Terkhen> it could be possible to add a animation_offset param so that all smoke in the same industry don't appear at the same time
20:40:19  <Terkhen> s/same time/same frame/
20:40:32  <andythenorth> do they randomly offset when constructed?
20:40:52  <Terkhen> no
20:40:55  <Terkhen> check the biorefinery for example
20:41:43  <Terkhen> I added the second smoke to it but both smoke fumes move at the same time :P
20:41:48  <andythenorth> nah they're fine as far as I can see
20:41:56  <andythenorth> the brickworks has smoke which is not in sync
20:41:59  <andythenorth> which is correct
20:42:25  <andythenorth> it's fine for two adjacent chimneys to be in sync
20:42:47  <Terkhen> oh, in the brickworks it is done without templates :P
20:42:55  <Terkhen> sprite:  3701 + ((animation_frame + 6) % 8); <--- magic
20:43:10  <Terkhen> I probably made the templates after that
20:43:13  <andythenorth> heh
20:43:16  <andythenorth> I see
20:43:41  <Terkhen> similar "magic" is done for industries with two different animations
20:44:05  <Terkhen> for example the cement plant
20:45:14  <Terkhen> the oil wells animation is a translation to advanced spritelayouts from pm's code in ogfx-industries
20:45:20  <Terkhen> I don't claim to understand that one :P
20:50:13  <planetmaker> hm... I thought you did that one :-P
20:50:46  <Terkhen> I did a simple animation, which was stopped sometimes
20:50:54  <Terkhen> you did the code that stops the animation gracefully
20:51:07  <Terkhen> so neither of us understands that code? :)
20:51:18  <planetmaker> should I look? :-)
20:51:39  <Terkhen> I commented when I was doing the conversion
20:51:44  <Terkhen> it seems that I understood it for a brief period of time
20:51:54  <Terkhen> then again, the comments might be completely wrong :P
20:52:11  <Terkhen> s/commented/added comments/
20:53:09  <planetmaker> ok, oil well animiation: random bits are re-randomized on the tile loop (256 ticks or so)
20:54:31  <planetmaker> it basically has two loops: frames 0...9 and frames 10...20
20:55:49  <planetmaker> frames 0...9 are for the real animation and 10... 20 the same but animation stops after that cycle is done
20:55:54  <planetmaker> (10 is stop)
20:57:11  <Terkhen> the comments look right then
20:58:10  <planetmaker> on frame 0 we decide whether we switch loops (i.e. continue pumping or decide whether this is the last of the cycle
20:59:03  * andythenorth -> bedtime :)
20:59:40  <planetmaker> that was all the next animation frame. And animation control callback swaps at any time between those loops
20:59:45  <Terkhen> good night andythenorth
20:59:50  <planetmaker> i.e. when pumping go to frame + 10
20:59:54  <planetmaker> good night andy
21:00:20  <planetmaker> or when stopped consider randomly to start pumping. Just finsish, if we're in the "finish animation loop"
21:01:03  <Terkhen> ok :)
21:01:54  *** andythenorth has left #openttdcoop.devzone
21:34:20  *** Hanf has quit IRC
21:58:39  *** frosch123 has quit IRC
22:10:01  *** Zuu has quit IRC
22:19:28  *** ODM has quit IRC
22:22:37  *** JVassie has quit IRC
22:27:47  *** ChanServ changes topic to "Talk about things hosted and developed on | Downloads log: | Sandbox passwords are the same as the usernames"
23:22:17  <Brot6> OpenGFX - Revision 733:906be4e859db: Feature: Separate water for rivers (Graphics by Lepkka) (planetmaker) @

Powered by YARRSTE version: svn-trunk