Log for #openttdcoop.devzone on 19th March 2012:
Times are UTC Toggle Colours
01:08:14  <Brot6> Japanese Buildings - Bug #627: pure white pixels (alignment?) (PaulC) @
01:08:42  *** th_gergo has quit IRC
03:49:54  <Brot6> Japanese Buildings - Code Review #3849 (New): Building texts (PaulC) @
06:45:47  *** JVassie has joined #openttdcoop.devzone
07:03:25  *** JVassie has quit IRC
07:34:40  *** Zuu has joined #openttdcoop.devzone
07:49:16  <Ammler> oh, stupid me, just checked the file with cat and didn't see the missing newline at the end
07:49:51  *** Zuu has quit IRC
10:06:07  *** Brot6 has quit IRC
10:08:20  *** Brot6 has joined #openttdcoop.devzone
10:10:50  <Brot6> BANDIT - Revision 443:36009a39e33d: DevZone: add pixa as build require (Ammler) @
10:11:23  <Brot6> bandit: compile of r443 still failed (#3842) -
10:11:38  <Brot6> bandit: compile of r443 still failed (#3842) -
10:17:41  <Brot6> bandit: compile of r443 still failed (#3842) -
10:23:03  <Brot6> BANDIT - Revision 444:4ad0857c92ff: DevZone: of course, if we overrule the default nml config, we... (Ammler) @
10:27:20  <Brot6> bandit: compile of r444 still failed (#3842) -
10:30:02  <Ammler> the error doesn't look like a pixa issue
10:33:57  <V453000> planetmaker: found some issue with japanese landscape
10:37:31  <Brot6> BANDIT - Bug #3842: DevZone compile failed (Ammler) @
10:37:53  <Ammler> hmm
12:46:14  <Brot6> Dutch Trains 2.0 - Support #3801: Sprite templating instructions (Transportman) @
14:03:51  <Brot6> Dutch Trains 2.0 - Support #3801: Sprite templating instructions (foobar) @
14:10:47  <Brot6> Dutch Trains 2.0 - Support #3801: Sprite templating instructions (foobar) @
15:30:16  <Ammler> is someone else that andy able to build bandit?
16:14:00  *** jazzyjaffa has joined #openttdcoop.devzone
16:14:07  *** jazzyjaffa has left #openttdcoop.devzone
16:40:28  <Brot6> Dutch Trains 2.0 - Support #3801: Sprite templating instructions (Mahoo76) @
16:42:51  <Brot6> Dutch Trains 2.0 - Feature #3850 (New): Ketelwagen & ZHESM BC6 -> template & purchase (Mahoo76) @
16:44:45  <Brot6> Dutch Trains 2.0 - Feature #3850: Ketelwagen & ZHESM BC6 -> template & purchase (Mahoo76) @
17:13:50  *** andythenorth has joined #openttdcoop.devzone
17:24:12  <Brot6> dutchtrains: update from r347 to r370 done -
17:27:22  <Brot6> bandit: compile of r444 still failed (#3842) -
17:28:36  <Brot6> make-nml: compile of r0 still failed (#3730) -
17:29:52  <V453000> hm, damn I will need the cargo capacity switch anyway ... with passengers/mail/goods it does not matter much but with goods having double capacity than other cargoes it will be an issue :z
17:32:09  <andythenorth> Ammler: hi hi...I saw .devzone in pixa repo
17:32:14  <andythenorth> is there progress? :)
17:32:50  <V453000> andythenorth: when cargo_capacity:   railpax_capacity_switch; affects only the purchase menu as we discovered yesterday, isnt that an issue in NML then? When there is a special thing to do exactly that (I guess) purchase_cargo_capacity: 77; like this thing
17:34:12  <andythenorth> V453000: I'm not sure.  The situation around refitted capacities is very complex
17:34:27  <andythenorth> and I think changes were made recently (or proposed).  I haven't read the changelog though :P
17:34:33  <V453000> oh
17:34:49  <V453000> I updated NML few days ago so that should not be too outdated
17:35:36  <V453000> not much to raed there either
17:35:36  <V453000> :D
17:37:32  <V453000> is there any place I could read how do the refitted capacities work?
17:42:27  *** ODM has joined #openttdcoop.devzone
17:44:00  <michi_cc> V453000:
17:44:13  <V453000> thank you :)
17:45:00  <michi_cc> Be amazed by the complexity ;)
17:45:34  <V453000> o_O
17:45:37  <V453000> christ
17:47:01  <V453000> michi_cc: I see that is NFO specs, does it apply also for NML?
17:47:19  <michi_cc> It's not NFO specs, it's GRF specs.
17:47:34  <V453000> thats what it says in the right menu :>
17:48:07  <michi_cc> NFO is the syntax of a special kind of text files, just like NML is. GRF what OpenTTD understands.
17:48:19  <V453000> alright :)
17:49:13  <Brot6> Britrains (BROS based on CETS) - Revision 27:4adc34f87e12: Fix/Feature: CETS revisions 655 to 664 (oberhuemer) @
17:50:16  <michi_cc> So both NFO and NML produce GRF output, but NML might set some of the properties/callbacks etc indirectly (e.g. the XOR refit mask for current NML).
17:52:17  <V453000> I see
17:52:51  <V453000> from what I understand, I need to find callback 15 and use it to let the wagons recognize cargoes and set capacities appropriately
17:52:56  <V453000> as the last image description says
17:55:50  <planetmaker> CB 15 is implemented in NML as cargo_capacity IIRC
17:56:12  <Ammler> andythenorth: I am also not able to build bandit here
17:56:13  <V453000> just found that :( ... that is the thing which I already tried
17:56:26  <V453000> and it affects only purchase menu value
17:56:30  <V453000> but doesnt change the actual capacity
17:56:34  <planetmaker> and optionally also purchase_cargo_capacity
17:57:03  <Ammler> andythenorth: are you certain, is working, do you use it that way?
17:57:15  <andythenorth> Ammler: it installed for me
17:57:28  <Brot6> britrains: update from r26 to r27 done (5 warnings) -
17:57:32  <V453000> that does the same, no?
17:57:35  <V453000> at least it did for me
17:57:39  <V453000> or seemingly
17:57:44  <andythenorth> wrt building bandit, it's not production ready yet, but that is work that needs to get done
17:57:56  <andythenorth> Ammler: can you install pixa locally to your os?
17:59:04  <Ammler> yes, I can
17:59:05  <planetmaker> cargo_capacity applies to both ingame and purchase menu. Unless purchase_cargo_capacity is set. Then cargo_capacity defines capacities ingame and purchase_cargo_capacity capacities in the purchase menu
17:59:18  <Ammler> andythenorth: but I have the same error here as devzone
17:59:23  <andythenorth> ok, so has two data points in favour of 'it works'
17:59:24  <planetmaker> If that doesn't work something is wrong somewhere. No-one can tell what without test code / grf
17:59:29  <andythenorth> Ammler: the error is?
18:00:09  <Ammler>
18:00:15  <andythenorth> yup
18:00:17  <andythenorth> expected
18:00:18  <andythenorth> good
18:00:24  <Ammler> :-)
18:00:29  <andythenorth> expected errors are useful.  unexpected ones, less so :P
18:00:32  <planetmaker> best something which actually can be built.. thus incl. necessary sprites + lang files. Saves a lot of time on getting the test case running
18:00:59  <andythenorth> Ammler: the BANDIT makefile knows nothing about running the pixel generation yet.
18:01:15  <Ammler> so how to build it?
18:01:31  <andythenorth> option (1): I need to learn more make
18:01:50  <andythenorth> option (2) there is a separate makefile for the pixel generation
18:01:58  <andythenorth> option (3) something else
18:02:00  <Ammler> how you call it?
18:02:12  <andythenorth> from src/pixel_generator, just call make
18:02:31  <V453000> planetmaker: in game, passenger capacity is 70 as set in the cargo_capacity in item property, and mail/gold just do the half/quarter capacity of 70
18:02:33  <andythenorth> it may need a dir creating called 'output'
18:02:51  <V453000> is something wrong between the chair and the keyboard, or is there something fishy going on in NML?
18:03:09  <andythenorth> getting hg to provision an empty directory is hacky, so I didn't bother
18:03:27  <andythenorth> ideally the makefile or python would create the dir if it was missing.  I just didn't get that far yet
18:03:47  <andythenorth> there is much we could do with dep checks and such, but also I didn't get that far yet :)
18:03:59  <andythenorth> 'DevOps' :)
18:05:10  <Ammler>
18:05:20  <planetmaker> V453000: as said, please create a complete bug report. And include lang files / graphics so that it can be tested easily
18:05:30  <Ammler> andythenorth: the paste is for you
18:05:31  <planetmaker> (for NML)
18:05:40  <andythenorth> Ammler: thanks :)
18:05:42  <andythenorth> how interesting
18:06:17  <Ammler> multiprocessing issue?
18:06:18  <andythenorth> Ammler: is there a dir called 'output' with path 'src/pixel_generator/output'
18:06:19  <andythenorth> ?
18:06:30  <Ammler> no
18:06:38  *** th_gergo has joined #openttdcoop.devzone
18:06:43  <andythenorth> can you manually create it?  Or shall I trick hg into adding it?
18:06:52  <andythenorth> or I can tell python to maybe
18:07:00  <Ammler> mkdir output fixed it
18:07:01  <andythenorth> or make
18:07:12  <andythenorth> that step should be automated away
18:07:24  <Ammler> make should create the dir
18:07:48  <Ammler> hg is not able to track dir
18:07:52  <andythenorth> yup
18:08:02  <andythenorth> you have to put an empty file in the dir, which is horrible
18:08:55  <Ammler> well, hg does not need to track empty dir, it would be uly
18:08:58  <Ammler> ugly*
18:09:14  <V453000> will do :)
18:09:36  <andythenorth> so I need to learn this:
18:09:37  <Webster> Title: how to check if a directory exists in a makefile - Stack Overflow (at
18:09:37  <andythenorth> :P
18:10:22  <planetmaker> V453000, I do not know where the error is.
18:10:27  <Ammler> andythenorth: or simplty create the dir always
18:10:40  <Ammler> no need to ceck
18:10:59  <andythenorth> so I need to learn that ;)
18:11:08  <Ammler> mkdir -p output
18:12:21  <andythenorth> oh that was easy then :)
18:13:06  <Ammler> planetmaker: you might be able to tell andythenorth how to run a "submake" in one sec
18:13:37  <Ammler> make -C afaik
18:14:12  <Brot6> BANDIT - Revision 445:f75153de580e: DevOps: have pixel generator makefile create output dir if mi... (andythenorth) @
18:15:58  <Ammler> andythenorth: make -C src/pixel_generator/
18:17:25  <planetmaker> yes make -C filename
18:17:29  *** frosch123 has joined #openttdcoop.devzone
18:17:47  <andythenorth> ok
18:17:48  <andythenorth> cool
18:17:49  <planetmaker> it will start another instance of make, intended to be run in another dir or so
18:17:54  <planetmaker> what do you want to achieve, andythenorth ?
18:18:11  <andythenorth> planetmaker: I don't have a clear spec in mind yet
18:18:14  <andythenorth> I'm new to this :)
18:18:23  <planetmaker> I didn't ask for spec
18:18:25  <planetmaker> But for goal
18:18:28  <andythenorth> Ammler: can you time the pixel make?
18:19:01  <andythenorth> planetmaker: ok, one makefile to build all of BANDIT, including generated pngs
18:19:07  <andythenorth> probably with dep checks, maybe
18:19:33  <andythenorth> retaining the current ability to call pixel generator standalone
18:19:37  <Brot6> bandit: compile of r445 still failed (#3842) -
18:20:02  <andythenorth> I have bits of the puzzle in place :)
18:22:05  <Ammler> real    0m4.686s
18:22:05  <Ammler> user    0m7.953s
18:22:34  <andythenorth> interesting.  any idea how many cores / thread units it can utilise on your box?
18:23:05  <planetmaker> in that case it's indeed advantegous to have a separate makefile for pixa. which then can be called by the newgrf's makefile
18:23:35  <andythenorth> good :)
18:24:00  <andythenorth> that makes it easier for other projects to copy the graphics generation approach, if they wish
18:24:34  <Ammler> andythenorth: could you update with make -C...
18:25:39  <andythenorth> hmm
18:25:49  <andythenorth> "tabs not spaces" :P
18:26:09  <andythenorth> apparently I'm wrong :P
18:30:43  <V453000> planetmaker: I put it all in a new newgrf file, compiled it and it works ... so now finding where is my error :D
18:31:14  <planetmaker> lol :-)
18:31:30  <planetmaker> welcome to the fun of development :-)
18:31:32  * andythenorth toddler -> bath
18:31:53  <planetmaker> bath -> total mess ;-)
18:33:51  <andythenorth> this sort of works
18:33:51  <andythenorth>
18:33:58  <andythenorth> it needs a 'make clean' first
18:34:12  <andythenorth> and it only prints 1st line of output from pixel generator
18:37:35  <Brot6> BANDIT - Revision 446:72e78d0b1aa8: DevOps: call pixel generator make from main makefile (andythenorth) @
18:37:58  <Ammler> now you will see bandit succeeds again :-)
18:38:51  <andythenorth> Ammler: how many CPU cores / thread units on the box?
18:39:56  <Ammler> my?
18:40:04  <andythenorth> yup
18:40:06  <Ammler> this is a very old duo
18:40:11  <andythenorth> just for speed comparison info
18:40:12  <Ammler> Sysinfo for '': Linux 3.1.9-1.4-desktop running KDE Development Platform 4.7.2 (4.7.2) "release 5", CPU: Genuine Intel(R) CPU           T2300  @ 1.66GHz at 1000 MHz (3324 bogomips), HD: 42/72GB, RAM: 837/983MB, 167 proc's, 9.1h up
18:40:13  <planetmaker> 	make -C src/pixel_generator/
18:40:20  <planetmaker> looks wrong. It needs a file iirc. not a dir
18:40:38  <planetmaker> though maybe it just looks for makefile or Makefile in that dir then. But I'd want to be explicit there
18:40:45  <Ammler> planetmaker: I guess, this is good
18:40:51  <Ammler> -C = changedir, not?
18:41:04  <planetmaker> no. call
18:41:13  <Ammler> don't you confuse it with -F
18:41:15  <V453000> seriously ... I just copy it to another vehicle and it works there :D LUCKILY, the other vehicle is the only one where I need it
18:41:19  <Ammler> hmm
18:41:31  <Rubidium> -C is change dir
18:41:33  <V453000> code magic?
18:42:33  <V453000> ok nevermind it is screwed up as well
18:43:50  <Brot6> bandit: update from r415 to r446 done (1 warnings) -
18:44:40  <V453000> ok, finally :> the cargo_capacity in graphics block takes effect
18:44:47  <V453000> I dont know how or why, but doe
18:44:48  <V453000> s
18:55:04  <andythenorth> V453000: paste
18:56:25  *** KenjiE20 has quit IRC
18:57:23  <V453000> it is done exactly the same way, pasted ... only difference is that one is cargo wagon with having goods capacity changed
18:57:27  <V453000> and the first one was the passengers
18:59:57  <V453000> but when I pasted it in separate grf, it works even with passengers
19:00:18  <planetmaker> forcing the ID and overwriting it again?
19:00:39  <planetmaker> or just a copy&paste error which causes ^
19:01:00  <V453000> no, different id
19:11:23  <Brot6> Dutch Trains 2.0 - Feature #3746: Coaches (Voyager1) @
19:25:18  *** JVassie has joined #openttdcoop.devzone
19:53:09  <andythenorth> V453000: what's the first refittable cargo on the wagon?
20:04:20  *** KenjiE20 has joined #openttdcoop.devzone
20:14:17  <V453000> passengers
20:15:04  <V453000> anyway. I made a discovery: when I connect the wagon to a different engine, it works. To an engine which doesnt "belong" to it, thus does not influence it with livery refit ... will dig into it more after dinner
20:36:04  <V453000> the difference is between those two engines ... with railfast9 it works, with railice4 it does not ... testing whether the livery override breaks that
20:38:54  <V453000> IT DOES!
20:39:00  <V453000> :o
20:43:40  <V453000>
20:44:02  <V453000> red engine breaks, green does not
20:44:39  <V453000> -> I guess that shouldnt happen, right?
20:46:52  <planetmaker> livery override iirc should only disable wagon speed limits
20:48:10  <planetmaker> in any case, try to not use livery override. Choose the graphics on the wagon by querying the engine ID in the PARENT scope :-)
20:48:24  <planetmaker> maybe NML should just kill livery overrides ;-)
20:48:31  <planetmaker> they're redundant anyway :-P
20:48:38  <planetmaker> (95% at least)
20:48:57  <andythenorth> wtf is a livery override
20:49:00  <andythenorth> why would I ever need?
20:49:12  <andythenorth> I read that bit of the spec and filed under 'magical nonsense'
20:49:28  <planetmaker> the difference to querying PARENT scope is first engine vs. preceeding engine
20:49:37  <andythenorth> probably they're incredibly useful, but as usual I didn't pay proper attention :P
20:49:42  <planetmaker> it is not needed indeed
20:50:05  <planetmaker> especially when the related objects (preceeding engine) becomes available as scope, too ;-)
20:50:10  <planetmaker> in the CBs
20:50:17  <planetmaker> and VA2
20:53:18  <V453000> oh, alright :D
20:53:44  <V453000> I am just searching for the callback/variable/what that is which would go to the parent switchblock
20:54:03  <planetmaker> V453000: besides being an alternative it has the advantage that all wagon-related stuff is directly in the wagon's scope and graphics block
20:54:13  <planetmaker> vehicle_id
20:54:14  <planetmaker> or so
20:54:27  <V453000> oh, like that :D
20:54:29  <planetmaker> thus the wagon needs to know the vehicle_id of the engine and display the proper graphics
20:59:06  <planetmaker> V453000: as vehicle_id you can use the engine's name (like item_red)
20:59:20  <planetmaker> so you don't actually need to assign numbers manually anywhere
20:59:29  <V453000> that I actually know :p
20:59:33  <V453000> but I also have set numbers
20:59:33  <planetmaker> k :-)
20:59:38  <planetmaker> why?
20:59:47  <V453000> I felt like it is good for compatibility
20:59:54  <V453000> so I can add engines in the middle of the code
20:59:55  <planetmaker> that might be, indeed
21:00:01  <planetmaker> +1
21:00:14  <planetmaker> just make sure to not accidentially use them twice ;-)
21:00:28  <V453000> And for me it is very useful for orientation in the 8000 line code ... I have it all in one file so using IDs instead of names is helpful
21:00:44  <V453000> as name is often referenced in many switchblocks, spritesets, spritegroups and where not
21:00:55  <V453000> so when I just ctrl F and set the ID, I am there instantly
21:01:03  <planetmaker> you should learn to use the makefile ;-)
21:01:18  <planetmaker> ctrl F + name would bring you there, too ;-)
21:01:37  <planetmaker> but yes, they're more often referenced
21:01:42  <V453000> if I didnt use the name in spriteset definitions etc :)
21:02:07  <V453000> I usually use the name everywhere the same ... which might not be the smartest thing to do for those reasons but it is done now :)
21:02:22  <V453000> and I figured the IDs would be useful anyway and help with the orientation as well
21:04:08  <V453000> I like to have openttd open and just rescan newgrfs when I update sprites ... it used to break sometimes before
21:06:11  <planetmaker> reload_newgrfs
21:06:14  <planetmaker> in console
21:06:43  <planetmaker> (during a running game that is)
21:06:45  <V453000> yeah but the problem wasnt in openttd but in the newGRF when I updated it, it sometimes broke
21:06:50  <planetmaker> but that's what you want when testing sprites
21:06:56  <planetmaker> of course
21:07:00  <planetmaker> it can break
21:07:09  <planetmaker> it's changing newgrfs on a running game
21:07:20  <V453000> well it doesnt now when I added IDs ... or unless I change something major
21:07:21  <planetmaker> you've been warned when enabling developer settings :-P
21:07:29  <planetmaker> exactly
21:07:31  <V453000> im not complaining about anything! :D
21:07:43  <planetmaker> I know
21:07:52  <planetmaker> :-)
21:08:52  <V453000> oh, reload newgrfs is a lot faster
21:08:59  <V453000> doesnt have to rescan the whole folder :)
21:09:24  <planetmaker> yep
21:09:36  <planetmaker> just continue playing and update your newgrf
21:09:45  <planetmaker> you see changes immediately
21:09:51  <planetmaker> keep the train in view and see
21:10:05  <V453000> yes yes :) I do that all the time, I just used the relatively long rescan newgrfs
21:10:13  <V453000> and then apply changes, and stuff
21:10:14  <planetmaker> oh, from ingame?
21:10:16  <V453000> this is much faster :)
21:10:18  <V453000> sure, from the gui
21:10:33  <planetmaker> meh, yes, that's the 2nd most tedious way ;-)
21:10:34  <andythenorth> V453000: you're setting numeric IDs?  :)  Could be wise
21:10:50  <planetmaker> only restarting openttd would be more tedious :-P
21:10:53  <V453000> andythenorth: yes, I am even leaving spaces between them for expansions :D
21:10:53  <andythenorth> but you should get a framework of sorts into your set ;)
21:11:03  <V453000> planetmaker: I did that in the start :D
21:11:04  <planetmaker> V453000: don't leave spaces for the IDs
21:11:09  <planetmaker> make that continuous
21:11:11  <andythenorth> I would actually, in blocks of 10
21:11:15  <andythenorth> based on experience
21:11:32  <andythenorth> but that's for a specific case
21:11:49  <andythenorth> maybe not wise for trains
21:11:56  <V453000> it makes it easy for me to remember
21:12:20  <V453000> I know that rail vehicles have 0xx, monorail 1xx, maglev 2xx, wagons 3xx etc
21:13:22  <planetmaker> but the vehicle IDs are... completely unimportant. Except as internal house number
21:15:00  <V453000> well then why care if they are a sequence or some other system?
21:18:32  <andythenorth> I found my nice 'tidy' numeric id schemes didn't survive long
21:18:45  <andythenorth> my gaps weren't big enough etc
21:18:50  <andythenorth> but it does no harm
21:19:39  <V453000> :)
21:20:35  <andythenorth> I use them in BANDIT, trucks have gaps of 10, and trailers go in the gaps
21:20:47  <andythenorth> I know I'll never have more than 9 unique trailers per vehicle in this case
21:20:56  <V453000> :)
21:21:13  <V453000> switch (FEAT_TRAINS, PARENT, switch_green, vehicleid) what should be there instead of the vehicleid? vehicle_id doesnt exist either :z
21:21:14  <andythenorth> did I try and sell you a set framework yet? :P
21:21:21  <andythenorth> you should get a set framework :D
21:21:36  <V453000> I cant seem to find the variable that I need
21:22:00  <planetmaker> V453000: I shouldn't care for other people's newgrfs, that's true. But I made with such numbering scheme bad experience. It helped nowhere except eating time
21:22:12  <planetmaker> and was insufficient on the first extension of the set
21:22:25  <planetmaker> thus messed up then already
21:22:28  <planetmaker> but meh. Not my cake :-P
21:23:25  <V453000> :) I see ... but I think I have my own reasons and I left 1 expansion space between every engine, which means I can double the set, which I think is the maximum reasonable, that would make a new train come every year
21:23:45  <V453000> and the orientation by IDs is quite good for me too
21:24:50  <V453000> and I also intend to improve the set graphically, eventually add bonus engines to a "bonus engine ID sphere" but once I code the set it should stay that way for a long time, re-drawing it is basically step 2 after the first version is out
21:25:48  <V453000> because I simply learn on drawing the sprites, and I use even the oldest sprites that I drew ... therefore of course the style of drawing is very inconsistent and the old sprites (and of course even some new) need redrawing or at least enhancing
21:26:40  <V453000> but anyway, any ideas about the ID variable? switch (FEAT_TRAINS, PARENT, switch_green, vehicleid) vehicleid nor vehicle_id does not work and I cant seem to find it in the specs :z
21:26:47  <andythenorth> V453000: welcome to my world wrt redrawing :P
21:27:02  <V453000> :P
21:27:04  <andythenorth> did I mention I know have a framework that can rebuild lots of the set...quickly? :P
21:27:09  <andythenorth> know / now /s
21:27:13  <V453000> :DDD
21:27:18  <andythenorth> ^ stupid english language
21:27:33  <V453000> I enjoy the drawing the most
21:27:36  <V453000> so .. :)
21:28:13  <V453000> coding is fun too, but drawing is drawing :)
21:28:28  <andythenorth> this is all the nml for BANDIT
21:28:35  <andythenorth> most of those files are < 100 lines
21:28:50  <V453000> true that coding doesnt make me zoom in in every game in openttd I play atm and observe graphic styles ......
21:28:51  <planetmaker> if you looked a bit at the nml specs you'd have found vehicle_type_id
21:28:58  <V453000> I found that
21:28:59  <planetmaker> looking through the vehicle variables
21:29:10  <planetmaker> but...?
21:29:13  <V453000> didnt work somehow
21:29:17  <V453000> ok lets fiddle again
21:29:59  * andythenorth ponders converting FISH to nml
21:30:23  <V453000> hm I perhaps screwed a few things around
21:30:37  *** ODM has quit IRC
21:31:00  * andythenorth goes back to writing response to 'request for expressions of interest' for people in Australian government :P
21:31:17  <planetmaker> sorry, I was rude. I'm pissed at my programme here, V453000 :-P
21:31:46  <V453000> no you werent :)
21:31:52  <andythenorth> you should kban yourself :D
21:31:54  <andythenorth> not
21:32:23  <V453000> the vehicle_type_id indeed is obvious, I just dont know why it doesnt work for me atm ... investigating
21:33:03  <planetmaker> you use that in the wagon's graphics switch?
21:33:19  <V453000> yes, to replace the livery thing
21:33:29  <planetmaker> the livery is at the engine
21:33:59  <planetmaker> thus it need go in a different switch chain
21:37:17  <V453000> I have the switch at the wagon graphics block, trying to scan for vehicle id and returning the appropriate spriteset
21:38:55  <andythenorth> that makes sense
21:38:56  <andythenorth> pastebin?
21:44:15  <V453000> something very super weird is still happening though
21:44:17  <V453000> here is the code
21:47:18  <V453000> please kill me
21:47:33  <V453000> I left there the livery override block and was surprised that stuff is breaking
21:49:02  <V453000> there we go
21:49:04  <V453000> works now :)
21:49:05  <V453000> finally
21:50:05  <V453000> still, if something is great at coding then it is that you absolutely know if it works properly. When you finish drawing something, you might like it, but never can be 100% sure that it is perfect :)
21:50:38  <V453000> and especially here where 99% of the community will just tell you "that is good" on 99% stuff, and "that is not so good" on the 1%
21:50:51  <V453000> but something more constructive .. :)
21:54:42  <andythenorth> coding has a win condition
21:54:47  <andythenorth> until you find edge cases :P
21:55:06  <andythenorth> also, pasting your code for others will usually enable you to see the obvious mistake you were missing
21:55:20  <andythenorth> thereby wasting everyone else's time, but getting you unstuck from your stuck-ness
21:55:27  <planetmaker> lol
21:55:30  <planetmaker> so true! :-)
21:55:36  <V453000> :D
21:55:54  <andythenorth> V453000: you should at least use constants for your IDs :P
21:55:58  <andythenorth> but nvm
21:57:22  <andythenorth> are you going to have a lot of vehicles using things like 'switch_green' ?
21:58:37  <V453000> no that is just test newgrf
21:58:44  <andythenorth> k
21:59:35  <andythenorth> not much in your repo :)
22:10:35  *** Zuu has joined #openttdcoop.devzone
22:19:17  <V453000> lol
22:19:25  <V453000> I came to conclusion that I will have 3 switches in one
22:20:05  <V453000> firstly wagons change sprites based on engine, then based on cargo, and finally based on engine, cargo and being the last wagon in the consist
22:21:46  <andythenorth> makes sense
22:27:15  <andythenorth> bye
22:27:17  *** andythenorth has quit IRC
22:51:09  *** th_gergo has quit IRC
22:59:45  *** JVassie has quit IRC
23:11:17  *** frosch123 has quit IRC

Powered by YARRSTE version: svn-trunk