Log for #openttdcoop.devzone on 18th May 2012:
Times are UTC Toggle Colours
00:25:35  <Brot6> OpenGFX+ Trains - Bug #3904 (Rejected): DevZone compile failed (planetmaker) @
00:26:10  <Brot6> OpenGFX+ Trains - Bug #3920 (Closed): DevZone compile failed (planetmaker) @
01:04:05  <Brot6> Script Communication Protocol - Revision 21:b1b757cf4bf2: - fix bug with command unknown when comman... (krinn) @
07:01:46  *** Xotic750 has joined #openttdcoop.devzone
07:13:24  *** Zuu has joined #openttdcoop.devzone
07:27:23  *** Zuu has quit IRC
07:50:35  *** Nat_AFK is now known as Nat_aS
07:56:26  <Brot6> OpenGFX+ Trains - Revision 490:24c8e6008b31: Change: Add a dummy parameter for tenders (planetmaker) @
08:04:15  <Brot6> OpenGFX+ Trains - Revision 491:43979d9fa45c: Fix: Amend .hgignore by a missing entry (planetmaker) @
08:06:15  <Nat_aS> slowpoke, the people who were talking about this were already gone, but is it possible to have cars that are a quarter of a tile long? or does the way cars are measured prevent that?
08:06:35  <Nat_aS> because it would be nice if all cars were round numbers long.
08:31:34  <planetmaker> you can have rail vehicles in multiples of 1/16 tile length
08:31:49  <planetmaker> where the maximum is glitch-free at 8/16, Nat_aS
08:33:41  <planetmaker> actually 8/16 is the absolut upper limit, 1/16 the absolute lower. But ofc you can try some graphical tricks with articulated vehicles to get longer things than 8/16
08:58:02  <Brot6> OpenGFX+ Trains - Revision 492:79e45f32ecfe: Update: Removed material holder (Xotic750) @
08:59:40  <Brot6> OpenGFX+ Trains - Revision 493:0ac6c0f25142: Feature: Dash now gets its own livery to differentiate ... (Xotic750) @
09:05:06  <Brot6> OpenGFX+ Trains - Revision 494:1490f3d1f221: Feature: Dash livery models (Xotic750) @
09:06:00  <Brot6> OpenGFX+ Trains - Revision 495:04dff222edd3: Change: Added development left-overs for 32bpp, (Xotic750) @
09:26:52  <Xotic750> planetmaker: I was wondering if there is a 3rd cc colour and if there is then we use it for containers instead of the 2nd cc for randomising colour. Because as it is at the moment the randomising also affects the 2nd cc of the flatbed wagon
09:27:21  *** Nat_aS is now known as Nat_AFK
09:28:06  <planetmaker> there's no 3rd CC
09:28:22  <planetmaker> but one can, ofc, as for containers, use random CCs
09:28:39  <planetmaker> or define to use a pre-set colour
09:29:02  <planetmaker> yes, flatbed wagons should for this reason not include the 2nd CC
09:29:14  <planetmaker> is that feasible?
09:30:34  <planetmaker> there are ways around that by defining custom re-colour sprites. But don't expect that to work in 32bpp mode
09:31:00  <planetmaker> btw, ogfx-trains takes 12 minutes to build here
09:31:17  <Xotic750> :)
09:31:45  <planetmaker> and I re-discovered why I had reservations about articulated steam engines:
09:32:00  <planetmaker> you cannot operate articulated vehicles in reverse mode (driving backwards)
09:32:00  <Xotic750> I can use a preset colour for the container if it can be coded that way?
09:32:25  <planetmaker> I don't understand
09:33:15  <planetmaker> is it big trouble to not use the 2nd CC for the flatbed wagon?
09:33:23  <Xotic750> actually it is the 1st cc that is affected by the randomisation
09:33:36  <Xotic750> the blue
09:34:14  <Xotic750> at the moment I have the 2nd cc along the side, the 1st cc on the top of the flatbed and the container is the 1st cc
09:34:28  <planetmaker> hm, indeed. I think I went for the cheap solution to just use uniform-colour wagons and randomize CC
09:35:15  <Xotic750> I was just trying to find some kind of solution
09:35:44  <Xotic750> but I was wondering if I could use a predetermined colour for the container and then map that colour to random
09:35:52  <planetmaker> it's tricky. I spend surely one week on getting flatbed wagon colours right
09:36:47  <planetmaker> I don't think there's a way to re-define any other colour than CC or 2CC to a random colour
09:37:01  <planetmaker> I might err, but I don't know how to
09:37:55  <planetmaker> What is feasible - albeit also quite a bit work - to randomize the 2nd CC instead of 1st CC
09:38:09  <planetmaker> or so I believe
09:39:26  <planetmaker> May I suggest as intermediate solution to not use CC or 2CC for flatbeds? (And to re-map those colours to steel or wood - whatever is appropriate for now in the model)?
09:39:58  <Xotic750> it only affects the container I believe
09:40:15  <Xotic750> so I could easily replace that empty flatbed for one without colour
09:40:36  <planetmaker> Yes. But for consistency that would need to be the same for other cargos as well
09:40:59  <planetmaker> I know what you want - and I want it, too, though
09:41:26  <planetmaker> at least some CC there wouldn't hurt
09:41:50  <planetmaker> but at the moment that means much work which we could use on other places for much greater effect
09:42:06  <Xotic750> to make all of them without 2cc is quite alot of work
09:42:34  <Xotic750> to do just the empty container is easy
09:42:50  <Xotic750> and full container
09:44:13  <planetmaker> But... the container wagon looks the same like paper or steel coils
09:44:16  <planetmaker> or so it should
09:45:20  <Xotic750> yes, they do, but I would have to alter each model to use a different flatbed top, whereas if I do the container sprites then it is just 2 models to alter and re-render etc
09:46:03  <planetmaker> the flatbed wagon has three distinct shapes: flat, stakes and vehicles. They may look different. But the wagon should not change appearance in a station upon refit
09:46:27  <planetmaker> without consistent look the wagon will change looks in the station between unload and load.
09:46:29  <planetmaker> That's very ugly
09:47:32  <Xotic750> ok, well I can change the library onject and remove all the colour from there, that way no models need to be changed but everything will need a re-render
09:47:39  <Xotic750> *object
09:47:50  <planetmaker> hm... but it looks like that only GOOD is the complete flat, container version
09:47:53  <planetmaker> so it might be no issue
09:48:10  <planetmaker> see lines 230 ff in wagon_flatbed.pnml for the autorefit
09:48:35  <planetmaker> between free refits the wagon appearance must not change, only the cargo
09:49:33  <planetmaker> but looking at it, it seems ok to treat containers separate
09:50:30  <planetmaker> "GOOD" is one group. "FMSP, ENSP, VEHI" another. The other cargos have about the same wagon
09:51:02  <planetmaker> it's a bit of funny wagon which probably doesn't quite exist this way in reality. It's much more multi-purpose than usual :-)
09:51:09  <planetmaker> three or four wagons in one
09:51:49  <planetmaker> one might add a 4th group of cargos to differ between e.g. a shallow wall and stakes
09:52:12  <Xotic750> so, what shall we go for then, I change the library so that the flatbed has no cc and just re-render all flatbeds
09:52:41  <planetmaker> well. As it seems, the container version needs a refit in depot anyway. Thus it can have a separate look
09:53:12  <planetmaker> and the others don't need a re-visit
09:53:29  <Xotic750> ok, then that is alter 2 models and re-render just those (container empty container full)
09:54:47  <planetmaker> btw, why are the wagon sprites in the "engine" directory?
09:55:29  <planetmaker> (and not where the flatbed wagon sprites already are, for instance)?
09:55:41  <Xotic750> that was where you suggested when we started, we began with passenger if you remmber and you said put them there :)
09:56:29  <planetmaker> hm, I did?
09:56:45  <Xotic750> I needed a single destination for the post-processing to be simple
09:57:23  <Xotic750> otherwise we will need to change the script, which is simple for a single destination
09:57:27  <planetmaker> ah, that was the culprit
09:57:35  <Xotic750> but if we want multiple then it gets really complicated
09:58:24  <planetmaker> yeah, forgot about that.
09:58:37  <Xotic750> we can choose somewhere else if you like, very simple change in the script, but just a single destination
09:58:47  <planetmaker> <-- btw, this is why I did not yet do articulated engines. You can't flip the lower one (articulated), but the upper one (normal)
09:58:48  <Webster> Title: Imagebin - A place to slap up your images. (at
09:58:55  <planetmaker> nah, we keep it
09:59:10  <planetmaker> maybe just skipping the "engine" subdir and putting it directly in gfx. But well
09:59:17  <planetmaker> not worth the trouble now
09:59:51  <Xotic750> I can do that very simply, if you want
10:00:08  <Xotic750> the image doesn't display for me :)
10:00:35  <Xotic750> I get "Duplicate headers received from server" :P
10:00:43  <planetmaker> he, works for me
10:01:24  <Xotic750> ok, so I will change the container sprites to have no cc
10:01:37  <planetmaker>
10:01:48  <Xotic750> and move the sprite destination from engines down to gfx, if you want
10:02:08  <planetmaker> well. Yes and yes.
10:02:20  <planetmaker> use hg mv to move the files
10:02:25  <planetmaker> don't delete and re-add
10:02:52  <Xotic750> I will look at how to do that
10:03:14  <planetmaker> Or I could move the dirs. But it requires adjustment of all the paths in the pnmls, too
10:03:39  <planetmaker> in any case hg mv keeps the history so that it'll know that it is the same file
10:03:42  <Xotic750> is that reversed train in the gui really important then or are there other affects
10:03:57  <Xotic750> it is just 17 changes, I think
10:04:02  <planetmaker> it's not only in the GUI. you can send it that way on the tracks
10:04:07  <Xotic750> 1 in the post-processing
10:04:12  <Xotic750> and 16 in the nml
10:04:31  <planetmaker> People do use it for the looks
10:04:54  <planetmaker> And the outcry was gigantic when OpenTTD disallowed flipping of newgrf engines which do not explicitly allow it
10:05:16  <planetmaker> though probably it was just a very loud minority
10:05:44  <Xotic750> so, we need some kind of patch to the trunk to fix it then?
10:05:55  <Xotic750> for articulated
10:06:00  <planetmaker> thus adding artiuclation to those vehicles breaks this capability
10:06:02  <planetmaker> But... not important. We have a switch for that :-)
10:06:10  <planetmaker> No. Trunk won't change there
10:06:12  <planetmaker> can't change
10:06:29  <planetmaker> as there's no good way to define how a reversed articulated vehicle looks like really
10:07:03  <Xotic750> is there some kind of flag we can test and then use an alternative spriteset for reversed?
10:07:12  <planetmaker> yes
10:07:20  <planetmaker> vehicle_is_reversed as variable
10:07:28  <planetmaker> but that's unrelated to articulated
10:07:37  <planetmaker> you cannot reverse articulated vehicles
10:08:13  <planetmaker> and for shorter than 8/8 engines we DO need to check the vehicle_is_reversed variable in case it's an unarticulated vehicle
10:08:19  <planetmaker> s/vehicle/engine
10:08:27  <planetmaker> it only makes sense for engines
10:08:55  <planetmaker> this "reversed" is basically an eye candy thing which allows players to add an engine in reverse operation where they see fit
10:09:01  <planetmaker> it has no further effect
10:09:16  <planetmaker> But ofc it has to be dealt with graphically, esp. for non 8/8 length vehicles
10:10:30  <Xotic750> I think I may have to let you deal with those kind of issues, at least to begin with until I fully understand :)
10:11:20  <planetmaker> I wished I understood all of them ;-)
10:11:24  <Xotic750> oh, I have now created a different livery for Dash, to help people distinguish it from the floss
10:11:42  <planetmaker> What this means basically now for us is: we'll have a parameter to enable tenders
10:11:52  <Xotic750> so it now gets it own passenger, mail and armoured model in matching colours :)
10:11:59  <planetmaker> if enabled, the steam engines will become articulated vehicles and cannot be flipped. If not, nothing changes
10:12:09  <Xotic750> ok
10:12:26  <planetmaker> Yup, saw that commit. I like to see them differentiated
10:12:34  <planetmaker> But I didn't yet look at the sprites
10:12:41  <Xotic750> I will get some new sprites up soon so you can have a play
10:12:46  <planetmaker> was busy talking and writing code :-P
10:12:49  <Xotic750> still rendering :P
10:12:56  <planetmaker> :-D
10:13:17  <planetmaker> I'll add separate code files for all steam engines
10:13:57  <Xotic750> I was also thinking of changing just the engine livery of the sh30 and sh40 so that they look more different from one another too
10:14:49  <Xotic750> but I don't think that they will need their own passenger, mail and armoured liveries?
10:15:40  <planetmaker> sounds good to me
10:16:05  <Xotic750> but I can always create those if we think they are needed
10:18:43  <planetmaker> Xotic750: do we already have sprites for the tender?
10:19:42  <Xotic750> still rendering
10:20:17  <Xotic750> I will get some up as soon as I can
10:20:31  <planetmaker> ok
10:20:34  <Xotic750> I changed the OTTD text on the side to OpenGFX
10:20:39  <planetmaker> :-)
10:20:53  <planetmaker> How does it look?
10:21:03  <planetmaker> (ok, still rendering :-P )
10:21:10  <Xotic750> none of it is readable once the scaled down
10:21:16  <planetmaker> a pity
10:21:27  <Xotic750> it just there for effect really
10:21:48  <Xotic750> give a little brass coloured texture along the side to break up the main colour
10:21:58  <Xotic750> and give a perception that there is writing there
10:22:56  <Xotic750> I have noticed one problem with moving my destination directory to gfx
10:23:16  <Xotic750> I have a directory called flatbed, and there is already a flatbed directory in gfx
10:25:03  <planetmaker> hm... is everything in the 'engines' directony exclusively 32bpp?
10:26:04  <planetmaker> ah, no. But all the subdirs in there
10:26:37  <Xotic750> yes, just subdirs
10:27:30  *** ODM has joined #openttdcoop.devzone
10:28:05  <planetmaker> let's make it easier then: just create a dir "32bpp" next to "engines" and move all subdirs there
10:28:26  <planetmaker> it might make it then also kinda clear that the output there is rendered and should not be hand-edited
10:29:36  <Xotic750> yeah, sounds better
10:30:18  <Xotic750> you know there are also 8bpp sprites in all of my directories
10:30:42  <Xotic750> for possible future use :)
10:31:21  <Xotic750> maybe we should call it "rendered" instead of "32bpp"
10:31:43  <planetmaker> yup. That's a better name
10:39:58  <Xotic750> from the command prompy, how do you add a commit comment?
10:40:15  <planetmaker> hg ci -m "Fix: blah blah"
10:40:22  <Xotic750> ok, cheers
10:40:27  <planetmaker> alternatively it might open an editor if you just do
10:40:28  <planetmaker> hg ci
10:40:30  <Brot6> OpenGFX+ Trains - Revision 496:c822fdddde54: Codechange: Prepare steam engines for parameter dealing... (planetmaker) @
10:41:10  <Xotic750> I'll try, as I'm ssh'ing to another box to speed up rendering :)
10:41:24  <Xotic750> normally, locally I use tortoisehg
10:41:39  <planetmaker> for longer commit message like above from myself it opens here the default editor which is vi
10:41:51  <planetmaker> but you then have to like it. Usually using -me is much faster
10:41:58  <planetmaker> *using -m is...
10:42:21  <Xotic750> vi is fine, I it all the while :)
10:42:28  <planetmaker> :-)
10:42:52  <planetmaker> btw, the credits are terribly outdated. Do you want to appear with your real name there, too?
10:42:57  <planetmaker> (if so, what is it?)
10:43:20  <Xotic750> it's in my files but it's Graham Fairweather
10:45:05  <planetmaker> that's an interesting name inded :-)
10:45:32  <Xotic750> not so common I guess :)
10:46:25  <planetmaker> I guess not
10:48:13  <Brot6> OpenGFX+ Trains - Revision 497:88082e1ab27f: Update: Credits needed some update (planetmaker) @
10:56:04  <Brot6> OpenGFX+ Trains - Revision 498:48535f9a7f59: Update: Changed tender text (Xotic750) @
10:56:33  <Brot6> OpenGFX+ Trains - Revision 499:140796f50d5a: Update: Changed flatbed to have no cc (Xotic750) @
10:58:20  <Brot6> OpenGFX+ Trains - Revision 500:13917e7341c5: Change: Add license info to all source files (planetmaker) @
11:00:10  <planetmaker> Xotic750: does every steam engine get its own tender or do we use the same tender for each?
11:00:35  <Xotic750> they will each have a tender as the shapes change slightly
11:00:59  <planetmaker> hm, ok. Thus I'll need to change the code slightly :-P
11:01:35  <planetmaker> Or maybe really only slightly
11:01:59  <planetmaker> can you help me orient myself, where are the tender sprites?
11:03:08  <planetmaker> and... what is the 'gresley' engine? we have no such...
11:03:20  <Xotic750> the gresley is the Ginzu
11:03:27  <planetmaker> then we should name it so
11:03:28  <Xotic750> in real life it is a Gresley A4
11:03:33  <planetmaker> I'll rename the dir.
11:03:39  <planetmaker> Please use ingame names
11:04:31  <Xotic750> in TTD it is also Gresley :)
11:04:53  <planetmaker> In TT maybe
11:05:00  <planetmaker> but surely not in TTD
11:05:10  <Xotic750> I didn't notice it was Ginzu till later
11:05:34  <planetmaker> yes. But use the names of the vehicles as ingame. Not real names. It otherwise gets very messy and no-one will find anything anywhere
11:05:44  <planetmaker> Tbh, I don't care which real vehicle something is
11:05:47  <Xotic750> I will need change a few files
11:07:06  <Brot6> Metro Track Set - Bug #3981 (New): UKRS2 dual-mode engines require both 3rd rail and catenary to be ... (EmperorJake) @
11:08:48  <Brot6> OpenGFX+ Trains - Revision 501:019be2a61564: Change: Name the ginzu's source like the ginzu's name (planetmaker) @
11:24:43  <planetmaker> I'm afraid I'm really allergic to introducing yet another layer of names, Xotic750 :-)
11:25:00  <planetmaker> If you like to document that and hint to the real vehicles the only place to do so is IMHO the readme
11:25:28  <Xotic750> no problem, I will fix it
11:25:38  <planetmaker> but for me this set has already sufficiently many names that it is confusing without double naming vehicles
11:25:57  <planetmaker> well, I renamed it already as you might see ^
11:26:18  <Xotic750> yeah, I'm just trying to figure how to merge your change to my local :P
11:26:29  <planetmaker> :-D why is a merge needed?
11:26:49  <Xotic750> because I had local changes waiting
11:26:57  <planetmaker> hm, sorry
11:27:07  <Xotic750> I'll figure it out
11:27:52  <Xotic750> I'm just not used to this multi developer situations :)
11:28:24  <planetmaker> what kind of changes are that you have?
11:28:47  <Xotic750> the render and post process that was running
11:29:04  <planetmaker> if it's image updates: easiest copy them *somewhere*. revert local changes. update. copy back to new destination
11:29:30  <planetmaker> one might work with rebase. But that's not always nice with moves
11:29:48  <planetmaker> I tripped over that a few times in OpenGFX
11:29:54  <planetmaker> tripping myself there
11:30:11  <Xotic750> I'll figure it once the renders finish so I know exactly where I am
11:31:02  <planetmaker> any idea on the axle weight of the engines?
11:31:07  <planetmaker> (all of them)
11:31:28  <Xotic750> nope
11:35:04  <planetmaker> I guess I'll invent something which approx. fits :-P
11:35:11  <planetmaker> gameplay first, then realism
11:35:38  <planetmaker> I'm trying to implement the track type table as FooBar made for DutchTrainset
11:36:00  <planetmaker> to deal with (hopefully future) axle load railtype newgrfs which define proper track classes
11:43:10  <Xotic750> ok, I have no idea about that stuff :)
11:47:11  <planetmaker> I thought you know the vehicles :-P
11:47:26  <planetmaker> after all you seem to model based on real ones :-)
11:48:43  <Xotic750> only by look, I just look at the train table in the wiki then look at pictures the model are based on
11:49:20  <Xotic750> I not a train spotter, so to speak :)
12:15:47  <Brot6> OpenGFX+ Trains - Revision 502:4a81fd2f97df: Feature #3491: Add extensive railtype list which also r... (planetmaker) @
12:17:12  <Brot6> OpenGFX+ Trains - Feature #3491 (Feedback): Implement extensive railtype table (planetmaker) @
12:19:00  <Brot6> OpenGFX+ Trains - Feature #1920 (Closed): Wagon speed limits (planetmaker) @
12:31:18  <Brot6> OpenGFX+ Trains - Revision 503:53a5371bb86f: Update: Changed flatbed to have no cc and renamed gresl... (Xotic750) @
12:38:32  <Brot6> OpenGFX+ Trains - Revision 504:80cc525c9911: Change: Moved gresley rendered to ginzua4 (Xotic750) @
13:14:22  <Brot6> Dutch Track Set - Bug #3982 (New): Track type introduction (foobar) @
14:09:22  <Brot6> OpenGFX+ Trains - Revision 505:8b701b4dd6f1: Update: Render run (Xotic750) @
14:11:15  <Brot6> OpenGFX+ Trains - Revision 506:75bb1a9c80cc: Update: Post-process run (Xotic750) @
14:12:59  <Brot6> OpenGFX+ Trains - Revision 507:6017cec644fb: Feature: Dash livery (Xotic750) @
14:23:59  <Xotic750> planetmaker: the sprites are uploaded now, haven't tested a build yet, still waiting but will fix if it doesn't work
14:30:16  <Brot6> OpenGFX+ Trains - Revision 508:5c2cb616554c: Fix: Flatbed container, remove cc (Xotic750) @
14:45:25  <Terkhen> planetmaker: I have something for you :P
14:45:41  <Terkhen> <-- that is my completely untested implementation of autorefit in a common file
14:46:54  <Terkhen> <--- this is a new readme for ogfx-rv, autorefit is described in section 2.2
14:47:11  <Terkhen> I added cargos that were missing, but maybe ogfx-trains does things differently
14:47:43  <Terkhen> I'm specially doubtful of the cargos carried in containers by the flatbeds
15:09:20  <planetmaker> Xotic750: you mean the tender sprites?
15:09:56  <planetmaker> Terkhen: uh, that sounds good. /me takes a look
15:10:03  <Xotic750> yep, have the dash to still upload shortly but the tender ones are there to play with
15:10:22  <Terkhen> ok :)
15:10:35  <planetmaker> ok, I'll play with them then tonight
15:10:36  <Terkhen> the readme lists all supported cargos btw
15:11:01  <planetmaker> ah, that's good :-)
15:17:26  <Brot6> OpenGFX+ Trains - Revision 509:1e1ba410fafe: Update: Dash livery (Xotic750) @
15:39:50  <Xotic750> planetmaker: the valuables wagon for the Dash is having the same problem as the valuable for TIM and Asia Star
15:42:46  <planetmaker> hm
15:43:54  <Xotic750> it's really wierd, they all use the same templates
15:45:28  <Xotic750> and all the other livery overrides work, just not the valuables wagons
15:45:54  <Xotic750> or I should say, it uses the correct sprites but not the mask
15:50:12  <planetmaker> sh125 works?
15:51:44  <Xotic750> yep
15:53:27  <Xotic750> it must be something very simple and obvious that I can't see
15:59:04  *** Zuu has joined #openttdcoop.devzone
16:11:45  *** Nat_AFK is now known as Nat_aS
16:17:07  <Terkhen> planetmaker: any comments? :)
16:21:57  <planetmaker> not really. I haven't applied it to ogfx-trains yet. The only thing I wondered whether the autorefit should not get a sseparate file
16:22:38  <planetmaker> but that might be both unneeded and scattering the stuff too much, more than is good
16:29:56  <Terkhen> as I said, it is not tested
16:30:00  <Terkhen> I only wanted comments for now :P
16:30:18  <Terkhen> yes, maybe all the callbacks should be in a different file
16:32:09  *** Nat_aS is now known as Nat_AFK
16:35:47  *** Xotic750 has quit IRC
16:35:57  <planetmaker> I wonder, Terkhen, whether we should put this in a common OpenGFX+ repo which we include as sub repo or so
16:36:12  <Terkhen> that would be better, yes
16:36:27  *** Nat_AFK is now known as Nat_aS
16:36:32  <Terkhen> but before we decide to share autorefit code, we need to be sure that it works the same in both sets
16:36:57  <planetmaker> :-) yeah
16:37:12  <planetmaker> First I need to tidy a bit the kitchen ;-)
16:37:15  <Terkhen> some cargos were missing from ogfx-trains implementation, and I made assumptions on how to implement them based on how sprites are assigned in ogfx-rv
16:37:50  <Terkhen> if my assumptions are correct regarding ogfx-trains sprites, everything is fine, if not, I can probably adapt because most of them do not have specific sprites in ogfx-rv
16:38:18  <Terkhen> and, to my knowledge, there are no huge differences (or maybe none at all) between the kind of sprites used for cargo support in ogfx-trains and in ogfx-rv
16:38:20  <Terkhen> ok :)
16:39:10  <planetmaker> indeed I think the cargo support is very similar. I don't expect problems to take what you suggest there / fix my oversights
16:50:41  <Terkhen> ok :)
16:51:12  <Terkhen> how could we set up the makefile to work with a common repository?
16:56:39  *** Nat_aS is now known as Nat_AFK
16:58:20  <planetmaker> it would not even need to know about it, if it only contains some shared source
16:58:36  <Terkhen> oh
16:58:42  <planetmaker> it still would be the (main) project's responsibility to update to the proper sub repo version
16:58:47  <planetmaker> (if that changed)
16:58:53  <Terkhen> so we commit to both the shared repository and to our own newgrf
16:58:58  <planetmaker> it's not automatically updated. But update is easier. Yes
16:59:06  <Terkhen> yes, sounds better :P
16:59:18  <planetmaker>
16:59:20  <Webster> Title: Subrepository - Mercurial (at
16:59:46  <planetmaker> that is, the shared repository is part of the source of opengfx+trains and opengfx+rv
17:00:04  <planetmaker> thus part of each source is in a 3rd shared repo
17:00:35  *** Nat_AFK is now known as Nat_aS
17:00:37  <planetmaker> I recently thought about doing the same again with the build framework... much less hassle for me then ;-)
17:00:53  <planetmaker> and sub repos meanwhile seem to be established enough to be reliable
17:02:10  <planetmaker> but well. That's just thinking so far. Let's stick to current practise. I'll toy with that - and might change that, when it works locally like I want :-)
17:04:15  <Terkhen> nice :)
17:04:17  <Terkhen> sorry, bbl
17:07:14  *** andythenorth has joined #openttdcoop.devzone
17:33:51  *** andythenorth has quit IRC
17:37:13  <Terkhen> hello again
17:37:59  <Terkhen> that subrepository thing looks interested, but yes, maybe for the future :)
17:38:16  <Terkhen> for now I'll finish formatting my computer, get linux working and test my code
17:38:46  <planetmaker> :-D
17:44:24  *** andythenorth has joined #openttdcoop.devzone
18:18:27  <planetmaker> I like your readme part better than mine, Terkhen. I guess I'll just change s/stop/station and s/truck/wagon :-P
18:25:33  <Terkhen> planetmaker: borrow as much as you like, I'm already stealing that huge autorefit implementation :)
18:25:49  <planetmaker> :-D
18:26:13  <Terkhen> and, as you might have noticed, I already stole your readme organization :P
18:26:21  <Terkhen> the magic of open source
18:29:29  *** andythenorth has quit IRC
18:30:19  <planetmaker> :-)
18:32:57  *** andythenorth has joined #openttdcoop.devzone
18:33:02  <planetmaker> Terkhen: should I kick out the dev section of the readme? It's kind of pointless in the ingame readme...
18:33:10  <planetmaker> Maybe separate info somewhere else?
18:33:56  <Terkhen> that's what I thought too
18:34:05  <Terkhen> I already removed it from mine, but I don't know where it should go
18:34:34  <Terkhen> that's also almost common between ogfx-trains and ogfx-rv
18:35:00  <Terkhen> I'm not sure if ogfx-trains uses gimp, or if it does something strange regarding the new 32bpp
18:35:44  <planetmaker> well. It does not yet automatically generate the sprites form the blender source
18:36:11  <planetmaker> Given xotic's compile times of that - which is measured literally in days - I'd not do that anyway,  I think
18:36:24  <planetmaker> so nothing special for 32bpp
18:38:19  <Terkhen> wow
18:38:26  <Terkhen> does not sound like a serious possibility then
18:38:32  <Brot6> OpenGFX+ Trains - Revision 510:c8ce248bbea3: Doc: More verbosely explain the rail wagon properties (... (planetmaker) @
18:38:47  <Terkhen> so yes, we could have a common development information somewhere
18:39:14  <planetmaker> Probably c/should go in a separate txt file into the makefile thingy
18:39:18  <Terkhen> which could also be shared by future ogfx+ sets :P
18:39:36  <Terkhen> yes, maybe included in the src but not in bundles
18:43:02  <planetmaker> yes
18:43:11  <planetmaker> no point to put that into non-source releases
18:43:24  <Terkhen> ok :)
18:43:26  <planetmaker> and yes, the makefile... it pities me. Or bothers
18:43:43  <Terkhen> I also wanted to ask you something about the makefile
18:43:53  <planetmaker> I got a couple of new ideas... but meh
18:43:58  <Terkhen> summary:     Change: [Makefile] Install into NewGRF dir instead of data dir
18:44:10  <planetmaker> yes?
18:44:17  <Terkhen> that's one of ogfx-trains commits
18:44:22  <planetmaker> oh
18:44:29  <planetmaker> but not in ogfx+rv, I guess
18:44:36  <Terkhen> so I suppose that the makefile has been updated while I was ignoring ogfx-rv for months :P
18:44:42  <Terkhen> what should I do to update it?
18:47:32  <planetmaker> that update is contained in scripts/Makefile.def
18:47:51  <planetmaker> you could just copy it over from ogfx-trains
18:50:02  <planetmaker> I more and more feel the need to rewrite that totally from scratch
18:50:11  <planetmaker> it's too complicated
18:52:15  <Terkhen> true, but it's worth the effort?
18:52:18  <Terkhen> the current one works
18:52:53  <planetmaker> it has no effect on the grf's result. Just where it's copied when you use 'make install'
18:56:08  <Terkhen> I know, sorry, my question was about the "makefile rewrite"
18:57:05  <Terkhen> I'll keep a note about the makefile update :)
18:58:08  <planetmaker> It might well be 'yes'. Simpler: Only NML. Simpler: no complicated dep (force rebuild when called). Simpler: call gfx generation separately (if desired). Simpler: allow to replace gfx, nml and grf generation by custom rule
18:58:30  <planetmaker> the dep check seems totally unneeded really
18:58:44  <planetmaker> either it's fulfilled (then it builds) or it's not - then the build fails
19:13:17  <planetmaker> Terkhen: do we keep the refit CB now in the same file as cargo defiitions? Or separate?
19:16:13  <Terkhen> those makefile changes sound really good :)
19:17:10  <Terkhen> planetmaker: IMO they belong together
19:17:48  <Terkhen> the callbacks and the REFIT_PROPERTIES_... defines are defining the same thing; how vehicles behave wrt cargo
19:23:03  <planetmaker> ok. Then I'll give the paste you posted a shot and will make the required changes
19:23:22  <planetmaker> the only backdraw of the makefile changes: they're just phantasy so far :-P
19:24:47  <Terkhen> ok :)
19:24:52  <Terkhen> mind that it is completely untested :P
19:25:39  <Brot6> OpenGFX+ Trains - Code Review #3973: TIM and Asia Star Valuables Livery (Xotic750) @
19:36:37  *** Xotic750 has joined #openttdcoop.devzone
19:47:00  <planetmaker> Terkhen: your file misses the MU declaration... that causes issues when copying ;-)
19:48:57  <Terkhen> yes, I mentioned that a few years ago, before I started with my implementation
19:49:10  <Terkhen> the MU thing is missing because I have no idea of what it is and which cargos it should include
19:49:13  <Yexo> planetmaker: I've seen #3979, but haven't yet time to look at the patch
19:49:14  <Brot6> Yexo: planetmaker: #3979 is "Feature #3979: vehicle current_max_speed - NewGRF Meta Language - #openttdcoop Development Zone"
19:49:16  <Yexo> hopefully later this weekend
19:49:50  <Terkhen> planetmaker: it's up to you to move them, I don't mind having the MU definitions in ogfx-rv even if they are not used
19:49:58  <Terkhen> time for me to leave, see you tomorrow
19:51:10  <planetmaker> Terkhen: yes, they should go there then, too. It's used in several trains - and a new file for that would be... very strange
19:51:40  <planetmaker> :D FEAT_ROADVEH is wrong :-P
19:51:49  <planetmaker> We got a problem there ;-)
19:52:56  <planetmaker> oh... it's a define :-)
19:53:17  <planetmaker> Terkhen: that define... can we move it to the top of the file?
19:53:31  <planetmaker> Easier to then just copy&paste the remainder till the end
19:55:49  <planetmaker> ah... now it seems to compile. Let's wait 15 minutes :-P
20:08:58  <planetmaker> Terkhen: my amended cargo_deinitions.pnml:
20:13:18  <planetmaker> Terkhen: I'll be daring. I commit that cargo definitions file :-)
20:13:52  <planetmaker> what I'd like to do is play some test game maybe... some joint test game :-)
20:14:20  <planetmaker> maybe FIRS, ogfx+trains, ogfx+rv,... something like that
20:15:47  <Brot6> OpenGFX+ Trains - Revision 511:bb330a60d0ac: Change: Sync refit properties with OpenGFX+RV (planetmaker) @
20:15:52  <planetmaker> and we need a xotic clone to make the models for ogfx+rv ;-)
20:16:08  <planetmaker> especially the early ones 1900+
20:16:21  <planetmaker> and horse stuff 1300+ :-P
20:16:28  <planetmaker> and ox carts
20:16:53  <V453000> slaves? :)
20:18:51  <planetmaker> I don't think so. I prefer people who think and act on their own like xotic ;-)
20:21:04  <V453000> no I meant slaves like instead of horse transports
20:21:15  <V453000> :p
20:21:18  <planetmaker> oh :-P
20:22:31  <planetmaker> but only for pax / tourist transport. New transport type: Sedan
20:23:00  <planetmaker> capacity: 2. Speed 5km/h
20:23:07  <V453000> :D
20:23:17  <V453000> reliability?
20:23:43  <planetmaker> 2% or so
20:23:55  <planetmaker> with regular whipping maybe 10%
20:24:09  <V453000> :D
20:26:02  <planetmaker> Xotic750: with the flatbed wagon, I find that the stakes look kinda transparent to me
20:34:33  <Brot6> OpenGFX+ Trains - Code Review #3763 (Feedback): replace refittable_cargo_types (planetmaker) @
20:34:46  <planetmaker> Xotic750: would you have fun to think of ?
20:35:04  <planetmaker> Like a diner wagon and differences for local / long-distance?
20:52:37  <Brot6> OpenGFX+ Trains - Code Review #3973: TIM and Asia Star Valuables Livery (planetmaker) @
21:05:37  *** andythenorth has quit IRC
21:23:19  *** ODM has quit IRC
21:34:36  <Brot6> OpenGFX+ Trains - Code Review #3973: TIM and Asia Star Valuables Livery (Xotic750) @
21:34:47  <Xotic750> planetmaker: the stakes are definitely solid as they are using the same material as the main vehicles, the cc1 material
21:35:42  <Xotic750> planetmaker: we can make a diner wagon or whatever you would like :)
21:36:20  <planetmaker> I'd like 3 kind of pax wagons: long-distance, local and a restaurant wagon ;-)
21:37:06  <Xotic750> we can do that, just need find some photos or examples of what we want to achieve
21:37:34  <Xotic750> I posted a screenshot of the masking problem
21:38:13  <Xotic750> and got to rerun the renders again, I got the library file mixed up somewhere along the line when I was merging :)
21:38:30  <Xotic750> so some wehicles are back to being too dark
21:38:41  <Xotic750> like the Dash that I updated
21:39:35  <V453000> I would suggest to use the other CC for the stakes on flatbed wagons
21:39:43  <V453000> using the same CC makes the stakes really invisible
21:40:08  <planetmaker> I'd actually only make the stakes CC and normal floor
21:40:27  <V453000> or even that
21:40:43  <V453000> or at least darken the CC on the floor
21:43:06  <Xotic750> ah yes, forgot we had the stakes and the floor the same colour :)
21:43:22  <Xotic750> small oversight
21:44:24  <Xotic750> that's the problem of spending all the time modelling and rendering without a chance to actually play :P
21:45:44  <planetmaker> just make the floor non-CC :-)
21:46:06  <planetmaker> Would probably generally look better when CC is only on the sides or so
21:47:06  <V453000> generally stuff that isnt CC looks better I think ... it is so much harder to make it look nice in CC, at least because white/orange always screws it up even if it looks good in other colours
21:47:07  <V453000> imo
21:47:59  <V453000> not exactly sure how far that applies with 32bpp but I guess the brightness difference is still important
21:54:09  <Xotic750> yeah, I will get rid of the 2cc on the top of the flat and do something else. Yes, I probably could make things look better without worrying about 2cc all together but it seems quite important for multiplayer, I just have to work a little hard to get good results :)
21:57:10  <V453000> for sure, I myself use a huge amount of company colours, but I just noticed that when you make only like smaller stripes of the cc, it in most cases looks better as the result is much less based on the cc conversion
22:03:06  <planetmaker> anyway, I need to go to bed. Good night
22:04:19  <V453000> gn
22:06:24  <Xotic750> yep, me too, gn
22:11:32  *** Xotic750 has quit IRC
23:39:44  *** Zuu has quit IRC

Powered by YARRSTE version: svn-trunk