Log for #openttd on 7th January 2012:
Times are UTC Toggle Colours
00:00:10  *** Snail_ [] has joined #openttd
00:00:32  <Snail_> back, comp crashed
00:01:16  <frosch123> so we finally get non-railtype specfic tunnels?
00:01:41  <swissfan91> maybe they'd look better viewed in Ogfx? they seem to suit that more.
00:02:14  <Snail_> well, I'm drawing some sprites that can be the base on which custom tunnel portals can be built
00:02:40  <Snail_> they just include the grass/desert/snow, the slope and the area around the portal
00:03:05  <Snail_> then, a railtype set could ideally provide its own graphics for the track and the portals
00:03:59  <swissfan91> when I think of France, I think of these tunnels ..
00:04:12  <frosch123> hmm, i don't see what the 16 sprites represent
00:04:16  <frosch123> 4 per direction
00:04:23  <frosch123> one below the rail, one above
00:04:27  <frosch123> what are the other two ?
00:04:57  <frosch123> snow? grass density?
00:05:34  *** Adambean [] has quit [Quit: Gone fishing]
00:05:38  <Snail_> frosch123: what sprites are you referring to?
00:07:04  <frosch123> +static const uint16 RAILTYPE_TUNNEL_BASE_COUNT = 16; <- those :p
00:08:32  <Eddi|zuHause> <frosch123> so we finally get non-railtype specfic tunnels? <-- no, we get railtype specific tunnels in the first place
00:10:11  <Snail_> 2 for the landscape and 2 for the portal for each direction
00:10:31  <Snail_> the landscape would be provided by OTTD (it's what I'm trying to draw now ;) )
00:10:46  <Snail_> and the portals by the rail
00:14:25  <michi_cc> frosch123: Grass and snow/desert.
00:15:14  <frosch123> no grass densities?
00:15:17  *** JVassie [~James@] has quit [Ping timeout: 480 seconds]
00:15:30  <Snail_> basically they get drawn with this order: (1) the landscape behind and below the train; (2) the track and the part of the portal behind the train; (3) the landscape above; (4) the part of the portal above the train
00:15:33  <Snail_> so, 4 parts
00:15:33  <planetmaker> hm, very good point
00:15:46  <planetmaker> we should start providing it for all snow and grass densities
00:16:22  <swissfan91> grassy tt-forums have returned! at least on mine..
00:20:48  *** vodka [] has quit [Quit: Leaving]
00:21:14  <michi_cc> frosch123: If snail draws them... But then, the original tunnel portals don't have that either.
00:21:36  <planetmaker> michi_cc: then we draw it all the new way ;-)
00:21:51  <planetmaker> but providing that for all grass densities makes much sense
00:22:09  <planetmaker> otherwise we make the path to nicer snow densities again much more difficult
00:22:20  <planetmaker> or rather ugly, if not more difficult
00:22:35  <frosch123> hmm, original tunnels don't have that? :o
00:22:39  <planetmaker> nope
00:22:52  <planetmaker> snow transition anywhere not plain terrain is binary
00:22:56  <frosch123> hmm, ok, then we should make it consistent with that
00:22:57  <planetmaker> as is desert transition
00:23:05  <frosch123> more is fore action 123 new landscape then :)
00:23:16  <planetmaker> :-D
00:23:27  <planetmaker> Do you think a Feature for landscape is acceptable?
00:23:58  <planetmaker> Probably would need a test, eh?
00:24:15  <frosch123> as long as it does not get animation or similiar cb-heavy stuff
00:24:38  <frosch123> (so it does not increase the cpu load for stuff not being visible)
00:24:57  <frosch123> zoom-out is slow anyway :p
00:25:13  <frosch123> there is that smallmap-like zoomout on the forums
00:25:21  <frosch123> maybe we should do that already for the current 8x zoom out
00:25:28  *** Biolunar [] has quit [Quit: All your IRC are belong to us!]
00:25:48  <Snail_> are snow densities implemented already?
00:25:56  <planetmaker> Snail_: they are in TTD
00:26:19  <planetmaker> and newgrfs have that variable for eons
00:26:27  <planetmaker> at least industries and houses
00:26:48  <planetmaker> implicitly via the snow height
00:27:20  <planetmaker> thus full snow awareness is mostly a matter of coding effort
00:27:44  <planetmaker> exceptions are bridges (no info at all) and railtypes (only snow yes/no)
00:27:54  <Snail_> but the tunnel sprites are all the same
00:27:56  <planetmaker> as they have both no tileheight info
00:29:03  <planetmaker> FIRS: have a look at the new FIRS or at OpenGFX+ Airports
00:30:17  *** Progman [] has quit [Remote host closed the connection]
00:31:24  *** Devroush [] has quit []
00:37:26  <Snail_> I'd say to finalize the general shape first, using the grassy temperate sprites... once the general shading and length of the "bowl" are finalized, I can start drawing other landscapes and grass/snow densities
00:38:46  <planetmaker> that makes sense
00:45:56  *** swissfan91 [] has quit [Quit: ajax IRC Client]
00:51:17  <Snail_> I'll probably enhance those sprites during the weekend ;)
00:52:18  *** Neon [] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
00:52:44  <frosch123> night
00:52:47  *** frosch123 [] has quit [Remote host closed the connection]
01:07:30  *** valhallasw [~valhallas@] has quit [Ping timeout: 480 seconds]
01:08:42  *** pugi [] has quit []
01:10:15  *** Snail_ [] has quit [Quit: Snail_]
01:15:39  <welshdragon> the reason why I need copy and paste:
01:15:54  <welshdragon> trying to recreate that is going to be messy
01:16:19  <welshdragon> (or even savegame compatibilty, but meh...
01:30:10  *** TdlQ_ [] has quit [Ping timeout: 480 seconds]
01:38:08  <Eddi|zuHause> i have never ever had a use case for copy-paste
01:39:40  <welshdragon> nope, I can't do it....
01:39:56  <welshdragon> brain. cannot. compute.
01:40:29  *** Brianetta [] has quit [Quit: TschÌß]
01:41:24  <planetmaker> welshdragon: why would I want to re-create something which I have already?
01:41:32  <planetmaker> especially via c&p?
01:41:56  <welshdragon> planetmaker: because I like to play the same map over and over and over again?
01:42:07  <planetmaker> The easier approach there seems to me the "play me" button. Available via the AI of your choice
01:42:24  <welshdragon> >AI
01:48:47  *** Zuu [] has quit [Ping timeout: 480 seconds]
01:51:08  <Wolf01> 'night
01:51:21  *** Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
01:51:40  *** Markavian` [] has joined #openttd
01:52:47  *** DDR [~chatzilla@] has joined #openttd
01:58:00  *** Markavian [] has quit [Ping timeout: 480 seconds]
02:01:22  *** hbc [~hbc@] has joined #openttd
02:03:01  *** hbc [~hbc@] has left #openttd []
02:04:04  *** welshdragon [] has quit [Quit: welshdragon]
03:22:00  *** fjb|tab [] has joined #openttd
03:33:06  *** kkb110 [] has quit [Read error: Operation timed out]
03:34:28  *** LordPixaII [] has joined #openttd
03:34:28  *** Pixa [] has quit [Read error: Connection reset by peer]
03:39:16  *** glx [glx@2a01:e35:2f59:c7c0:90ec:9e1a:2895:512b] has quit [Quit: bye]
03:48:55  *** Kurimus [] has quit []
04:52:32  *** hbc [~hbc@] has joined #openttd
04:53:47  *** hbc [~hbc@] has left #openttd []
05:24:30  *** fjb|tab is now known as Guest23080
05:24:30  *** fjb|tab [] has joined #openttd
05:27:25  *** Guest23080 [] has quit [Ping timeout: 480 seconds]
05:56:02  *** Eddi|zuHause [] has quit [Remote host closed the connection]
05:56:18  *** Eddi|zuHause [] has joined #openttd
06:09:18  *** Pixa [] has joined #openttd
06:09:19  *** LordPixaII [] has quit [Read error: Connection reset by peer]
06:13:46  *** andythenorth [] has joined #openttd
06:34:16  <CIA-6> OpenTTD: rubidium * r23768 /trunk/changelog.txt: -Fix: inconsistent stye in changelog
06:42:57  <andythenorth> could model availability be handled by a CB?
06:43:23  <andythenorth> either for prop 06 (climate) or prop 04 (model life)
06:43:28  <andythenorth> climate would be better
06:52:52  * andythenorth ponders magic
07:07:24  <Rubidium> action6?
07:11:43  <andythenorth> doesn't work so well for hiding one model when a new one becomes available
07:11:43  * andythenorth is spamming the buy menu with trucks, and would like some to go away :P
07:11:43  <andythenorth> model life is....unpredictable at best
07:25:12  *** andythenorth [] has quit [Ping timeout: 480 seconds]
07:28:27  *** sla_ro|master [~slaco@] has joined #openttd
07:35:12  *** DayDreamer [] has joined #openttd
07:36:06  *** DayDreamer [] has left #openttd []
07:52:15  *** sla_ro|master [~slaco@] has quit [Ping timeout: 480 seconds]
07:54:53  *** sla_ro|master [~slaco@] has joined #openttd
07:59:11  *** Remi_Woler [] has quit [Read error: Connection reset by peer]
08:02:58  *** sla_ro|master [~slaco@] has quit [Ping timeout: 480 seconds]
08:13:24  *** andythenorth [] has joined #openttd
08:21:53  *** andythenorth is now known as Guest23177
08:21:54  *** andythenorth [] has joined #openttd
08:24:59  *** Elukka [] has quit []
08:27:01  *** Progman [] has joined #openttd
08:27:17  *** Guest23177 [] has quit [Ping timeout: 480 seconds]
08:30:59  *** sla_ro|master [~slaco@] has joined #openttd
08:34:26  <Terkhen> good morning
08:35:13  *** TdlQ_ [] has joined #openttd
08:35:27  *** TdlQ_ is now known as MJP
08:39:37  <andythenorth> hola Terkhen
08:39:56  <andythenorth> hmm
08:40:12  * andythenorth ponders using the nml generator from Eddi|zuHause
08:40:18  <andythenorth> "but generators are evil!"
08:46:34  *** fonsinchen [] has joined #openttd
08:50:22  *** sla_ro|master [~slaco@] has quit [Ping timeout: 480 seconds]
08:51:20  *** Alberth [] has joined #openttd
08:51:23  *** mode/#openttd [+o Alberth] by ChanServ
09:02:14  *** KouDy [~KouDy@] has joined #openttd
09:10:09  * andythenorth wonders if CPP can do something like #define veh_id _filename_
09:11:50  <Alberth> ?
09:12:34  <Alberth> you mean dynamically create new #define ?    no, afaik
09:12:46  * Alberth recommends m4 instead
09:14:30  <Alberth> cpp is designed as text replacement engine, not as code generator
09:16:14  <andythenorth> Alberth: no, the define will be in the file, I just want to use the filename as an argument (to set the value of the define)
09:16:20  <andythenorth> it's probably a bad pattern :P
09:17:31  *** sla_ro|master [~slaco@] has joined #openttd
09:17:49  <Alberth> there is __FILE__
09:29:14  *** pjpe [] has quit [Quit: ajax IRC Client]
09:35:16  *** Chris_Booth [] has joined #openttd
09:44:13  *** TdlQ [] has joined #openttd
09:51:07  *** MJP [] has quit [Ping timeout: 480 seconds]
09:51:19  *** TdlQ is now known as MJP
09:56:38  *** fonsinchen [] has quit [Ping timeout: 480 seconds]
10:00:32  *** sla_ro|master [~slaco@] has quit [Quit: Sla Mutant Co-Op for Renegade - coming back soon]
10:07:58  *** Devroush [] has joined #openttd
10:19:07  *** sla_ro|master [~slaco@] has joined #openttd
10:24:04  *** Kurimus [] has joined #openttd
10:30:20  *** TGYoshi [~TGYoshi@] has joined #openttd
10:30:28  *** andythenorth [] has quit [Quit: andythenorth]
10:31:19  *** fonsinchen [] has joined #openttd
10:42:05  *** welshdragon [] has joined #openttd
10:47:37  *** JVassie [~James@] has joined #openttd
10:54:33  *** fonsinchen [] has quit [Ping timeout: 480 seconds]
11:14:11  *** sla_ro|master [~slaco@] has quit [Quit: Sla Mutant Co-Op for Renegade - coming back soon]
11:21:37  *** DDR [~chatzilla@] has quit [Remote host closed the connection]
11:22:19  *** DDR [~chatzilla@] has joined #openttd
11:25:21  *** sla_ro|master [~slaco@] has joined #openttd
11:30:54  <TrueBrain> Why is it that Windows Update takes longer than a Gentoo update?
11:30:58  <TrueBrain> that surely has to be wrong :(
11:35:57  *** Zuu [] has joined #openttd
11:36:13  <Alberth> MS minutes
11:38:34  <Ammler> you update windows every half a year when you accidentially start it
11:38:55  <Ammler> or when you want to play Mass Effect
11:40:15  *** frosch123 [] has joined #openttd
11:40:28  <Alberth> they want to make sure there are enough sysadmins around to manage the window systems
11:40:36  <Alberth> o/ frosch123
11:41:40  *** fonsinchen [] has joined #openttd
11:41:41  <frosch123> hai albert :)
11:44:32  <TrueBrain> weird part is, I update every month. Yet it takes FOR EVER :(
11:46:25  * Alberth blames DRM
11:47:27  <TrueBrain> you are most likely right
11:47:29  <TrueBrain> sadly
11:49:58  *** APTX_ [] has joined #openttd
11:50:16  <planetmaker> moin
11:50:51  <Alberth> moin pm
11:51:00  *** kkb110_ [] has joined #openttd
11:51:34  *** APTX [] has quit [Read error: Connection reset by peer]
11:51:50  <kkb110_> Q: I would like to add custom toolbar that needs drag-drop on the view... what file/function should I look at???
11:52:10  *** tokai|noir [] has joined #openttd
11:52:52  <Alberth> you want to make a new toolbar?
11:54:37  <Alberth> if so, you are basically creating a new window, so any toolbar window will do
11:55:54  <Alberth> the airport build bar is quite simple, should be in airport_gui
11:55:57  <Alberth> Window *ShowBuildAirToolbar()
11:57:34  <Alberth> I am not sure that we have cross-window drag/drop.  you could look in the depot window perhaps
11:57:55  <Alberth> that is not cross-window, but it does show the functions involved
11:57:58  *** tokai|mdlx [] has quit [Ping timeout: 480 seconds]
11:58:59  *** andythenorth [] has joined #openttd
11:59:09  <Alberth> hmm, pehaps the order window would be useful too, where you can add an order, and click at the main display for actual adding
11:59:16  <Alberth> o/ andy
12:00:24  *** DDR [~chatzilla@] has quit [Quit: ChatZilla 0.9.88 [Firefox 9.0.1/20111221202647]]
12:04:21  <kkb110_> Alberth, ok I'll give a shot thank you :)
12:04:42  <andythenorth> mornings
12:04:44  <frosch123> be careful, the order window is the most complicated window code we have
12:05:36  <kkb110_> most codes are already complicated enough for me lol
12:06:56  <Alberth> what do you want to drag/drop?
12:07:33  <kkb110_> I'm planning to "remake" copy/paste feature
12:09:22  <Alberth> the usual approach is like what happens with stations and airports and so, where you switch the mouse mode to 'placement' and then wait for a click
12:09:42  <Alberth> or the other way around, click 'raise', drag an area, and it gets raised
12:11:06  <Alberth> tbh I don't see the need for drag/drop so much
12:11:33  <kkb110_> then how to specify copying area?
12:11:50  <Alberth> just like terraforming does it
12:12:24  <Alberth> dragging until mouse is released already exists
12:12:24  <kkb110_> wait.. so it's drag-drop now?
12:12:39  <kkb110_> yes that's what I'm looking for
12:13:12  <Alberth> oh, I understood your question as drag from your new window onto the main display
12:13:55  <kkb110_> it hope it makes easier than before lol
12:14:20  <Alberth> the terraform window would be useful to study
12:14:39  <kkb110_> ok terraform_gui.cpp..
12:15:29  <TrueBrain> another copy/paste patch; like we dont have enough of them already :D Hehe :) You might also be interested to look into works of others
12:15:31  <Alberth> the station placement window can also drag an area
12:16:23  <Alberth> I would assume they have covered the UI already
12:16:31  <kkb110_> TrueBrain, I'm gonna look at it when I really don't get it :) I skimmed it.. thousands of lines... it's too long!
12:16:54  <Alberth> kkb110_: so focus on the window parts only
12:17:17  <kkb110_> ok~
12:17:48  <Alberth> kkb110_: and quite likely, those thousands of lines are mostly all needed :p
12:18:19  <kkb110_> Alberth, haha yes probably
12:20:48  *** Brianetta [] has joined #openttd
12:21:17  *** fjb|tab [] has quit [Remote host closed the connection]
12:22:59  *** fjb|tab [] has joined #openttd
12:26:21  *** fjb|tab is now known as Guest23256
12:26:21  *** Guest23256 [] has quit [Read error: Connection reset by peer]
12:26:21  *** fjb|tab [] has joined #openttd
12:30:35  <kkb110_> ok I think I'm now getting it.. and instead of making a new toolbar, it seems attaching a button to terraform_gui.cpp is more duable :)
12:31:35  <Alberth> that saves a few hundred lines of code :p
12:51:03  *** hbc [~hbc@] has joined #openttd
12:51:08  *** hbc [~hbc@] has left #openttd []
12:51:41  *** hbc [~hbc@] has joined #openttd
12:52:03  *** hbc [~hbc@] has left #openttd []
12:52:32  *** hbccbh [~hbc@] has joined #openttd
12:52:52  <Alberth> staying now hbccbh ?
12:52:59  <hbccbh> yep
12:53:08  <Alberth> welcome then :)
12:53:27  <hbccbh> thx, my network down just now =(
13:00:53  <fonsinchen> good morning everybody
13:01:31  *** hbccbh [~hbc@] has quit [Ping timeout: 480 seconds]
13:06:45  *** KritiK [~Maxim@] has joined #openttd
13:08:31  *** glx [glx@2a01:e35:2f59:c7c0:ed8d:5832:265a:d29c] has joined #openttd
13:08:34  *** mode/#openttd [+v glx] by ChanServ
13:13:15  <fonsinchen> Any suggestions on how to better manage my cargodist code and split it up into even smaller parts which would be still independenty modifiable?
13:13:37  <fonsinchen> The whole git branching and merging business is slowly getting out of hand. I'd like some solution where I'd be able to use rebase and have a "stable branch" somewhere.
13:13:47  *** luxOOr [] has joined #openttd
13:14:07  <fonsinchen> (And don't say hg patch queues as those are linear only and apart from that have the same problem)
13:15:05  <fonsinchen> Also I need to split up the code in even smaller parts, but in my current setup this would increase the number of branches even more ...
13:15:43  <Alberth> did you automate this handling?
13:15:47  <fonsinchen> Yes
13:16:07  <fonsinchen> I have that "" script in my repo which does all the merging for me
13:16:25  <MJP> Hi all! Alberth, since you are a GUI expert, would you mind to take a look at the part5 of my zoom64 r26 patchset? In particular the 3 modifications of window.cpp, I think they could be considered as an independant fix. Thx
13:16:38  *** hbccbh [~hbc@] has joined #openttd
13:16:40  <fonsinchen> However, if there is a conflict somewhere it's likely I have to resolve that several times in a row for different branches
13:17:05  <Alberth> that's where the shit hits the fan thus :)
13:17:17  <fonsinchen> And merges are ugly, they destroy the commit history
13:18:10  <Alberth> MJP: euhm, somewhen later today perhaps?  do you have a link?
13:18:52  <MJP> it's there : 
 and there's no hurry :)
13:19:20  <Alberth> I never change history
13:19:49  *** valhallasw [~valhallas@] has joined #openttd
13:20:14  <fonsinchen> Sometimes it's a good idea. michi_cc does it and he doesn't need 22 branches for YACD as his commits are what my branches are
13:20:16  <Alberth> it destroys history in the sense that you don't have a sequence patch1, patch2, etc ?
13:20:43  <fonsinchen> No, it intermixes trunk changes with my changes
13:21:17  <fonsinchen> So if I'm looking for some set of commits where I changed something it's likely they're not in a sequence.
13:22:06  <fonsinchen> and it creates loads and loads of "Merge blah" commits.
13:22:26  *** luxOOr [] has left #openttd []
13:22:45  <Alberth> I am trying to picture what you want to achieve
13:23:27  <Alberth> basically have a repo for each revision?
13:23:34  <fonsinchen> At the moment I have that complicated graph of branches where each branch has a set of "precondition branches" and I'm using make to merge it all together if something changes somewhere.
13:24:19  <fonsinchen> for example one branch for feature "reservation", one for "MCF" and one for "cargomap" which depends on "MCF" and "reservation"
13:24:43  <Alberth> what if you consider each to be a separate project?
13:25:12  <fonsinchen> And then?
13:25:19  <Alberth> with its own repo, and releases
13:26:14  <fonsinchen> Then I have 22 folders each with one copy of OpenTTD and some changes on top of that.
13:26:23  <fonsinchen> Sounds like a mess ...
13:27:30  <Alberth> I am not sure what exactly the problem is, often creating more structure helps, but perhaps not here
13:28:36  <appe_> bah, i can see the ufo land
13:28:36  <appe_> but i cant prevent it?
13:28:36  <appe_> :)(
13:28:39  <appe_> :(
13:28:40  <appe_> *
13:28:47  <fonsinchen> I'm also not quite sure, but I'm about to add 4 more branches and I somehow think a lot of that structure is actually not helpful.
13:29:21  <fonsinchen> I'm constantly switching branches, merging things back and forth, resolving conflicts and stuff like that.
13:29:49  *** Mucht [] has joined #openttd
13:30:13  <Alberth> appe_: quickly remove all tracks :p
13:30:19  <fonsinchen> However, I need the code to be split into small chunks as once I give that up I won't be able to easily recreate it if it needs to be merged into trunk.
13:31:39  <Alberth> I have those problems in patch queues too. I feel that the software could be made smarter in the sense that it understands there are relations between patches
13:32:28  <Alberth> ie I think it now treats each patch as a separate patch without taking into account it came from a queue
13:33:07  <Alberth> which gives the multiple conflict mess you talk about
13:34:04  <Alberth> but writing such software is a whole new project in itself :(
13:34:46  <fonsinchen> It should be possible to use git or hg in a more intelligent way, though.
13:35:20  <Alberth> maybe you should talk to some git gurus
13:35:22  <michi_cc> git rebase -i and git add -i
13:36:32  <michi_cc> Are the commits in your branches smaller, bigger or equal to a typical trunk commit?
13:36:50  <fonsinchen> they differ wildly
13:37:30  <fonsinchen> sometimes they're one liners where I only fixed some whitespace problem, sometimes it's a complete reimplementation of some class.
13:37:41  <fonsinchen> I don't like my commit history so much anyway
13:38:07  <fonsinchen> I should restructure the whole thing and rebase it on trunk.
13:38:59  <fonsinchen> michi_cc: Do you actually have more branches you work with or do you really keep exactly one commit for each feature? What do you do if you need to fix something? git commit --amend?
13:39:08  <michi_cc> My development process makes liberal use of rebase -i. If I notice some bug I make a fix commit which is then squashed into the broken commit when I rebase the next time.
13:39:55  <fonsinchen> and you make that fix commit on top of the one and only YACD branch I guess?
13:40:29  <fonsinchen> probably you mark it somehow as "belongs to commit X". I see ...
13:43:34  <michi_cc> Splitting features into proper sized commits is easy using git add -i (respectively git citool). If you take for example, I wrote everything (except the NoAI commit) more or less in one go the first time and then carved proper commits from my working dir. It's quite good to see in this case that all commits are mostly independent.
13:45:03  <michi_cc> After the first iteration I (of course :) discovered lots of errors, which then went into fixup commits which were squashed into the proper base commit (look up --autosquash in get help rebase).
13:46:22  <michi_cc> The YACD repository went through too many iterations that hide this process by now.
13:46:26  <fonsinchen> Ah nice, autosquash is what I was looking for, I guess.
13:46:56  <fonsinchen> what is git citool?
13:47:09  *** FLHerne [] has joined #openttd
13:47:24  <Alberth> MJP: I didn't invent the focus stuff, Zuu did. How does it fix what problem?
13:47:37  *** Wolf01 [] has joined #openttd
13:47:43  <Alberth> o/ Wolf01
13:47:49  <Wolf01> o/ Alberth
13:48:01  <michi_cc> short from of git gui citool, i.e. the integrated GUI tool. With that the process of picking diff hunks or even just lines is much easier than the text interface of git add -p/-i
13:49:12  <michi_cc> Just to spell it out explicitly, my kind of workflow completely relies on working with the index/staging area of git.
13:50:22  <fonsinchen> Now, say you want to add a major new feature somewhere in between. What I'm doing so far is creating a new branch, working on the new feature until it's complete and then adding the new branch to the merge hierarchy.
13:50:49  <MJP> well, if I have two extra viewports, I move the first, so it gets the focus, then I right click in the middle of the second and it does not receive focus (though I'm interacting with it)
13:51:09  *** valhalla1w [~valhallas@] has joined #openttd
13:51:26  <fonsinchen> You would probably edit the head until the feature is ready and then reorder the commits with git rebase -i, right?
13:52:03  <fonsinchen> Saves a lot of checkout and merge action and makes a nice commit history ...
13:52:20  <michi_cc> In principle yes, but why would I want that feature in between? If it's a new feature, the old code can, by definition, not rely on it, so just leave it at the head be good.
13:52:22  <MJP> the other thing is the news window can get focused while I'm interacting with another window... I don't think that's normal
13:52:53  *** valhalla1w [~valhallas@] has quit [Remote host closed the connection]
13:53:21  <Alberth> MJP: ?   this->nested_root->GetWidgetOfType(WWT_EDITBOX) != NULL   fails for news afaik
13:53:43  <fonsinchen> For example I'm adding code to support transfer and "unload all"/"no unload" orders. This touches several distinct places. For example I have to add a linkgraph normalizer which should logically be placed between the linkgraph creating code and the demand calculator.
13:53:59  <fonsinchen> and so I think the commit (or branch) should also be there.
13:55:06  <Alberth> MJP: maybe I don't understand "getting focus" here?   A viewport also doesn't have an edit box
13:55:07  <MJP> Alberth: this is strange because when the news shows up, _focused_window points to its window
13:57:34  <Alberth> MJP: the whole focus stuff already existed when I came in, and I 'only' changed how widgets are created and sized.
13:57:38  *** valhallasw [~valhallas@] has quit [Ping timeout: 480 seconds]
13:58:07  *** vodka [] has joined #openttd
13:58:29  <michi_cc> If I don't really code a completely new feature but instead change/extend the existing code I basically create two types of commits intermixed, squash commits for earlier stuff and new commits that will be moved to a good place in the commit history. Mostly I would completely code and test the new stuff and then use selective stating and commit to carve good commits from it.
13:58:30  <Alberth> so far I never really understood what its function is
13:59:44  <Alberth> michi_cc: I tend to code a feature, then use diff mode of gvim to copy the changes in the right order to a new patch queue
13:59:59  <MJP> well, it does not seem to be very important for the rest of the game... it only "corrupts" the position and size of what I draw on my map while the news window rises (after that, it goes back to normal)
14:00:01  <michi_cc> This does require some diligence to make sure you carve the commits in the order they will end up in the commit history (i.e. commits that will end up further from HEAD have to be created first). If you don't do that, the result will still work, but most likely give merge conflicts on rebasing.
14:01:12  <michi_cc> Alberth: That's a bit similar to partial staging I guess. git can do it down to line level, no idea if gvim can do that too.
14:02:10  <Alberth> MJP: that sounds weird to me. Perhaps have a closer look how the news window gets risen? There have been other problems with it in the past, but I cannot remember the details (but svn blame can :) )
14:02:27  *** FLHerne [] has left #openttd []
14:03:49  <Alberth> michi_cc: down to single characters if you want to :)    basically you get an old/new window next to each other, and you can copy/edit both in any way you like. gvim just highlights the differences for you, nothing more
14:04:18  <MJP> ok, I'll see if I can understand the problem better... seems that there is only a problem with the news window... I didn't read that code yet... anyway, those 3 modifications of window.cpp did fix my specific problem
14:05:23  <Alberth> MJP: afaik focus is only about where to draw the caret, and where to send keyboard input to. I don't understand how that would interfer with drawing stuff at the screen
14:05:44  <Alberth> perhaps your fixes force a few extra redraws or so?
14:06:39  <michi_cc> Ah, then it is not really the same as partial staging, just with a somewhat similar result. Partial staging basically means that you look at the output of git diff in your working copy and select for each diff hunk or even line if it shall be marked for the next commit or not. And if you're crazy enough you can even edit the to-be-staged diff hunk in a text editor.
14:06:52  *** dageek [~dageek@2001:8b0:ff85:0:223:32ff:fec9:1f10] has joined #openttd
14:06:52  <MJP> while I scroll a viewport, it refreshes its position if there are viewports ar a map zoomlevel
14:07:56  <Alberth> michi_cc: sounds useful
14:12:04  <Alberth> when a news window rises, you get a second source of redraw requests, perhaps that interferes in some way
14:12:04  <Zuu> MJP: Why do you need to not give keyboard input focus to a text box if you are scrolling the map at the sime time?
14:13:28  <MJP> Zuu: take a look at
14:13:39  <Zuu> Yes, I have patch5 open here.
14:13:55  <MJP> the white box on the map moves as I scroll the extra viewport
14:14:22  <MJP> to draw that white box, I use _focused_window
14:14:57  <fonsinchen> brrr, my patches are between 2.1K and 71K in size. I definitely should restructure the whole thing ...
14:15:11  <MJP> but when the news rises, the white box has size and position of the news window and not the extraviewport I am scrolling
14:15:22  <Zuu> So you draw this white rectangle automatically if a extra viewport is open and is focused?
14:15:40  <MJP> and scrolled, yes
14:15:40  <fonsinchen> OK, the largest one is smallmap-refactor which is only syntactical sugar.
14:17:28  <Eddi|zuHause> the 64x zoom out patch starts to look interesting (basically like "smallmap in main viewport")
14:17:32  <Zuu> Is there case when news need focus? Unless changed, focus is so far used for deciding if and which text widget that should grap the key input.
14:18:25  <Zuu> Ok, I guess then scrolling a small map will qualify as grabing input.
14:18:28  <Eddi|zuHause> the space bar to close the news?
14:18:53  <MJP> Eddi|zuHause: thanks :)
14:18:54  <Zuu> Could be a global hotkey
14:19:05  <Zuu> I don't know actually, but I would guess it's global.
14:19:40  <Zuu> Meaning thas as far as no text input has focus, you can execute a global hotkey.
14:19:44  <MJP> Zuu: I do not know the focus thing very well, I just had to look at it to fix a graphic glitch in my patch
14:21:11  *** Chris_Booth [] has quit [Remote host closed the connection]
14:21:59  <Zuu> I can not really say if it is wrong or right. If you need to do it, I guess you have too.
14:22:38  <Zuu> If it is only news that cause the problem, an alternative thing might be to black list the news window from grabing focus. But I guess also a vehicle offer could do the same thing.
14:22:59  <Zuu> So perhaps your solution is not that bad after all. :-)
14:23:57  <Eddi|zuHause> ah... a propos: when i playtested recently, the vehicle offers popped up in the background (behind the game/newgrf settings window, i believe)
14:24:03  *** Markavian [] has joined #openttd
14:24:24  <Eddi|zuHause> that was quite annoying, honestly
14:24:25  <MJP> well time will tell if there are unwanted side effects :)
14:25:28  *** Markavian` [] has quit [Ping timeout: 480 seconds]
14:26:26  <Zuu> MJP: Have you added hotkey hooks for your vegitaion/owner/industry view switch? So that folks like me that "suffers" from no mouse wheel can acces your features too?
14:27:04  <MJP> err, no
14:28:12  <Zuu> You can just provide hooks that will end up in hotkeys.cfg without assigning default hotkeys for things that you don't think qualify to grab a key in the default config.
14:29:17  <MJP> ok, I'll do that for the next release
14:29:39  <Zuu> For example in the filter sign list window I added one to focus the text edit control. In my hotkeys.cfg I've assigned Global+Ctrl+L to it. That way whenever I press ctrl+L, that window is opened up and I can filter signs. Still, others who don't think it is important are not bothered by it.
14:43:47  <CIA-6> OpenTTD: rubidium * r23769 /trunk/src/ (3 files in 3 dirs): -Codechange: make the lag/join start timeouts configurable as well
14:48:57  *** pugi [] has joined #openttd
14:58:11  *** TWerkhoven [] has joined #openttd
15:09:44  *** Chris_Booth [] has joined #openttd
15:11:07  *** valhallasw [~valhallas@] has joined #openttd
15:15:20  <appe_> jeez
15:15:21  <fonsinchen> Is there an explanation of the commit message prefixes somewhere? For example when do you use "Add:" and when do you use "Feature:".
15:15:54  <appe_> i just found a big set back with using big circular network to get lots of trains around
15:16:18  <appe_> the amount of work needed when you have 2-300 trains on the same railway (but none of them to the same industry)
15:16:22  <appe_> is staggering
15:16:57  <frosch123> fonsinchen:
15:17:00  <frosch123> but it is pretty mood :)
15:17:44  <frosch123> i use feature/change for user-visible stuff, and add/codechange for more refactoring/preparation stuff
15:19:04  <fonsinchen> Thanks. Can I get that check script?
15:23:15  *** hbccbh [~hbc@] has quit [Quit: Leaving.]
15:24:38  <frosch123> i would guess tb would find it faster than me
15:27:38  <fonsinchen> TrueBrain: Could you find me that commit stye check script for the openttd repository, please?
15:28:00  <TrueBrain> eeeuuuuhhhhhhhh
15:28:07  <TrueBrain> its embedded in our post-commit
15:28:20  <TrueBrain> a simple regexp .. euhh ..
15:28:43  <TrueBrain> euh, precommit of course
15:29:36  <fonsinchen> The regex would be enough then, I gues
15:29:51  <TrueBrain>
15:29:56  <TrueBrain> then validation of the variables follow
15:30:18  <TrueBrain> hope I copy/pasted it correct, as linebreaks go all crazy
15:30:31  <fonsinchen> thanks
15:31:29  <TrueBrain> overly complex due to branches
15:31:38  <TrueBrain> cut -d: -f1
15:31:42  <TrueBrain> would work too :P
15:31:49  *** andythenorth [] has quit [Remote host closed the connection]
15:32:51  <fonsinchen> And it doesn't really enforce the types from, does it?
15:33:05  <planetmaker> It does
15:33:12  <planetmaker> iirc
15:33:20  <TrueBrain> it has a big switch following yeah
15:33:23  <planetmaker> at least the leading "-"
15:33:27  <TrueBrain> which is a part of this list :P
15:33:48  *** andythenorth [] has joined #openttd
15:33:59  <TrueBrain> things like Move are also accepted; but that is of little relevance to most :)
15:34:22  <fonsinchen> OK, I can recreate that list myself.
15:34:36  <TrueBrain> it depends on the project :)
15:35:44  <fonsinchen> I just want to make sure my commit messages look like yours and I'm notoriously mistyping them
15:37:32  <Alberth> fonsinchen: can you use a Python script? I have written a check thingie for hg
15:37:46  <fonsinchen> yes
15:38:02  <fonsinchen> a python script would also be nice
15:38:20  <TrueBrain> fonsinchen: I doubt the commit message will ever be a real issue :) And by following the wiki, at least the idea of the wiki (so the -, the: and the space), and the rest will follow :)
15:38:33  <TrueBrain> I would not worry too much if you pick the right word, like Fix, Add, ...
15:38:47  <TrueBrain> the devs already have different interpertations of it :P
15:39:21  <Alberth>
15:41:17  <Alberth> but quite likely the commit message is typed again manually when merging to trunk, so I wouldn't worry too much about them
15:43:08  <fonsinchen> nice
15:43:47  <fonsinchen> I know it's not terribly important, but the commit history I have now is quite a mess and I want to properly clean it up.
15:45:16  <fonsinchen> this looks a lot nicer I think:
15:56:07  *** fonsinchen [] has quit [Ping timeout: 480 seconds]
16:02:35  *** Illegal_Alien [] has quit [Ping timeout: 480 seconds]
16:02:58  *** Snail_ [] has joined #openttd
16:08:51  *** dageek [~dageek@2001:8b0:ff85:0:223:32ff:fec9:1f10] has quit [Quit: dageek]
16:23:10  *** George [~George@] has quit [Read error: Connection reset by peer]
16:23:56  *** fonsinchen [] has joined #openttd
16:24:07  *** Mucht [] has quit [Ping timeout: 480 seconds]
16:27:56  *** George [~George@] has joined #openttd
16:33:59  *** TWerkhoven [] has quit [Quit: He who can look into the future, has a brighter future to look into]
16:41:29  *** FLHerne [] has joined #openttd
16:41:32  *** FLHerne [] has left #openttd []
16:41:39  <appe_> hm
16:42:05  <appe_> what kind of parameters decide whether new industries open on a normal map?
16:42:16  <Zuu> What is the state with readmes now, should content providers insert hard line breaks or not?
16:43:36  <frosch123> readmes use monospaced fonts now
16:43:50  <frosch123> so they may do any kind of ascii formatting they like to do
16:44:18  <frosch123> no idea about wrapping though
16:45:42  <andythenorth> appe_: map generator settings
16:45:48  <andythenorth> using an industry newgrf?
16:46:07  <appe_> no, all standard
16:46:11  <appe_> im playing online
16:46:26  <appe_> the server settings allow new industries (they occationally pop up)
16:46:40  <appe_> but i need ways to make new pop up
16:48:01  <appe_> the server settings are: manual primary ind.. ..method: none, allow multiple similar industries per town = off.
16:48:04  <appe_> that is what i find
16:49:35  <frosch123> it's random then, no chance for you to influence it
16:49:53  <Rubidium> except disabling industries at all
16:50:12  <appe_> ah, ok.
16:50:30  <appe_> hm
16:50:46  <appe_> increasing city size should promote the rate of new industries
16:50:48  <appe_> that would be neat
16:50:54  <appe_> and realistic, if im honest.
16:50:56  <appe_> :)
16:52:30  <andythenorth> GS :P
16:52:55  <TrueBrain> what have I done .. I made GS the default goto for any issue
16:53:01  <TrueBrain> read the crasiest things already :P
16:57:18  <appe_> GS?
16:58:07  <Terkhen> gamescripts
16:58:29  <appe_> ah.
17:00:55  <andythenorth> TrueBrain: I may not always be serious when I offer GS as the default answer :P
17:01:10  <andythenorth> although I did wonder today if we should deprecate most of newgrf
17:04:06  <TrueBrain> lol
17:04:09  <TrueBrain> please not :)
17:04:11  *** mahmoud [] has joined #openttd
17:05:10  <Terkhen> why? they are separate things
17:05:28  <Eddi|zuHause> and certainly not "most of"...
17:05:42  <andythenorth> just make them graphics
17:05:53  <andythenorth> with names defined in xml
17:05:59  <andythenorth> all properties decided by GS
17:06:28  <Eddi|zuHause> that's nonsense
17:06:31  <andythenorth> otherwise how are things like tech trees supported?
17:06:31  <TrueBrain> I wonder how GS would handle that, CPU-wise
17:06:58  <TrueBrain> I wonder how hard it is to write a GRF interperter in GS :P
17:07:22  <andythenorth> to achieve some things, GS needs control of, e.g. vehicles directly,
17:07:54  <Terkhen> NewGRFs are slow already
17:08:42  <Terkhen> besides that, I don't see why the format makes a difference regarding "who has control"
17:08:59  <andythenorth> it's a question of what's canonical
17:09:12  *** DOUK [] has quit [Ping timeout: 480 seconds]
17:09:17  <andythenorth> if a GS can modify properties defined by newgrf, that's a nightmare of bug reports
17:09:22  <andythenorth> therefore - remove newgrf...
17:09:40  <andythenorth> GS authors who want things like tech trees then need to provide the vehicles
17:09:50  <andythenorth> it makes no sense unless they do anyway
17:10:01  <Terkhen> why can't that be done with NewGRFs?
17:10:15  <andythenorth> instead of GS?
17:10:18  <andythenorth> or combined with GS?
17:11:12  <Alberth> TrueBrain: one squirrel instance per house :p
17:13:38  <Terkhen> andythenorth: what I mean is, what makes those ideas format dependent?
17:14:11  <andythenorth> newgrf can't do things like raise a dialogue box to the user?
17:15:35  <TrueBrain> Alberth: I rather to .. fuck .. my brain goes blank
17:15:36  <TrueBrain> euh
17:15:38  <TrueBrain> erlang
17:15:46  <TrueBrain> I would love to write OpenTTD in erlang, the statemachine part of it :)
17:15:55  <TrueBrain> would result in some epicness :D
17:16:33  <TrueBrain> to = do
17:16:35  <TrueBrain> ugh
17:16:36  <TrueBrain> I need a dinner :P
17:16:49  <Alberth> yeah, that's one of the few positive properties you can attach to that :D
17:16:51  <Terkhen> andythenorth: how would an XML format do it?
17:16:53  <Alberth> enjoy TB
17:16:56  <TrueBrain> andythenorth: tbh, you do have a point. Some hybrid would be best for everything
17:16:59  <TrueBrain> but .... :)
17:17:06  <andythenorth> we are where we are :)
17:17:18  *** Brianetta [] has quit [Quit: TschÌß]
17:17:20  <andythenorth> I don't advocate that we drop newgrf
17:17:34  <Eddi|zuHause> mÀh... google docs is so buggy...
17:17:35  <TrueBrain> GS in NewGRF
17:17:36  <andythenorth> but that limits GS potential
17:17:38  <TrueBrain> would be a nice hybrid :)
17:17:50  <TrueBrain> let iets NewGRF run his own GS :P
17:19:19  <andythenorth> moderately valid actually :)
17:19:25  <Terkhen> so... deprecate NewGRFs and use a new format that is coupled better with GS?
17:19:37  <andythenorth> Terkhen: it's not format
17:19:43  <andythenorth> it's canonicalness
17:19:50  <TrueBrain> in some way NewGRF is like GS, just GS has an easier API :D :P :D
17:22:30  <frosch123> he, we already failed to make gs actually define an entity :p
17:22:35  <frosch123> in gmae
17:26:25  *** [lan3y] [] has joined #openttd
17:27:23  <[lan3y]> hi i set openttd to full screen in options but it makes the whole screen go black/grey and nothing is usable, is there a settings file i can tweak to change it back?
17:27:44  <frosch123> openttd.cfg
17:27:47  <frosch123> or alt+center
17:27:51  <frosch123> *enter
17:28:43  <[lan3y]> thanks
17:30:37  *** George [~George@] has quit [Read error: Connection reset by peer]
17:35:20  *** George [~George@] has joined #openttd
17:37:30  *** TdlQ [] has joined #openttd
17:39:23  *** fonsinchen [] has quit [Remote host closed the connection]
17:42:55  *** MJP [] has quit [Ping timeout: 480 seconds]
17:49:58  *** TdlQ is now known as MJP
17:50:19  <andythenorth> BANDIT is done :P
17:50:20  <andythenorth>
17:51:28  <Alberth> so many!  :O
17:52:03  <andythenorth> too many probably
17:52:19  <andythenorth> the set covers at least 110 years of gameplay though
17:52:30  <fjb|tab> Nice
17:52:37  <andythenorth> those trucks cover 1905-1970
17:52:40  <frosch123> they look all the same :p
17:52:42  <andythenorth> probably too many :P
17:53:03  <frosch123> make them available only for 5 years each :p
17:53:10  <andythenorth> if I didn't have to replicate 'trucks without trailers' and 'trucks with trailers' there would be fewerer
17:53:34  <andythenorth> but as that's required....
17:55:46  <andythenorth> frosch123: one of them is different in appearance
17:55:51  <andythenorth> I challenge you to spot which :D
17:56:13  <andythenorth> [some of the above may be lies]
17:56:59  <appe_> hm
17:58:08  <frosch123> they look the same to me
17:59:31  <andythenorth> my lie is discovered :P
17:59:53  <frosch123> the names are different though :p
18:00:04  <andythenorth> that's about all so far :P
18:00:32  <andythenorth> for semi-trailer trucks, /me has to calculate weight transfer from trailer to truck, and split capacity accordingly :P
18:03:08  <appe_> i found a way to make new industries on my tiny 64x64 internet game
18:03:20  <appe_> make the water dissapear.
18:03:20  <appe_> :D
18:03:33  <appe_> disappear*
18:04:35  *** Chris_Booth [] has quit [Ping timeout: 480 seconds]
18:13:53  *** welshdragon [] has quit [Quit: welshdragon]
18:19:37  <andythenorth> too many trucks :P
18:22:37  *** welshdragon [] has joined #openttd
18:24:58  *** andythenorth [] has quit [Quit: andythenorth]
18:37:23  <CIA-6> OpenTTD: smatz * r23770 /trunk/src/script/api/ (script_station.hpp script_waypoint.hpp): -Fix: compilation with GCC 4.7
18:41:15  *** Chris_Booth [] has joined #openttd
18:45:41  <CIA-6> OpenTTD: translators * r23771 /trunk/src/lang/ (8 files in 2 dirs): (log message trimmed)
18:45:41  <CIA-6> OpenTTD: -Update from WebTranslator v3.0:
18:45:41  <CIA-6> OpenTTD: belarusian - 2 changes by Wowanxm
18:45:41  <CIA-6> OpenTTD: catalan - 23 changes by arnau
18:45:41  <CIA-6> OpenTTD: finnish - 2 changes by jpx_
18:45:41  <CIA-6> OpenTTD: latvian - 65 changes by Tranzistors
18:45:41  <CIA-6> OpenTTD: romanian - 3 changes by tonny
18:46:47  <appe_>
18:46:49  <appe_> room, plz.
18:49:31  <Alberth> 3 platforms for a powerplant? a bit overkill, isn't it?
18:50:07  <appe_> powerplant?
18:50:15  <appe_> its for the power plant and the timber station
18:50:28  <appe_> im forced to rebuild it to get more trains on there.
18:53:01  <Alberth> lack of space is the biggest challenge in 64x64 indeed :)
18:53:37  <Eddi|zuHause> i never found fun in 64x64... after three lines you're "done" and have "nothing" to do anymore...
18:53:46  <[lan3y]> ^^
18:54:52  <Eddi|zuHause> you should probably put up more path signals
18:54:58  <appe_> Alberth: hehe
18:55:20  <appe_> Eddi|zuHause: to tight it up a bit?
18:55:32  <appe_>
18:55:33  <appe_> solved!
18:55:58  <Alberth> Eddi|zuHause: play FIRS at 64x64, you get 1 industry of each :)
18:56:44  <Alberth> oh, plenty of space :p
18:57:00  <appe_> man, this is fn
18:57:27  <appe_> the best thing with this - in wich i recently discoverd - is that playing online (with someone i know) makes the game a lot more fun
18:57:36  <appe_> since i cant affect the rules, cheat or fast forward.
18:57:38  <appe_> its neat.
18:58:30  <Alberth> coop?
18:58:46  * Alberth likes building things together
18:59:04  <Eddi|zuHause> Alberth: the smallest i played sensibly was 128x256. that also brought me 1 of each industry
19:00:53  <Alberth> yes, you always get at least 1 of each required industry, unless it cannot be placed
19:01:29  <Eddi|zuHause> Alberth: i mean "not more"
19:02:17  <Eddi|zuHause> that was my YACD game, and passengers kinda trumped cargo anyway
19:02:46  *** pjpe [] has joined #openttd
19:03:14  <Eddi|zuHause> YACDist may be more interesting for cargo
19:03:33  <Eddi|zuHause> or some hybrid that we discussed a while ago
19:06:24  *** HerzogDeXtEr1 [] has joined #openttd
19:11:18  *** andythenorth [] has joined #openttd
19:12:40  *** HerzogDeXtEr [] has quit [Ping timeout: 480 seconds]
19:18:48  <appe_> Alberth: no, not really, its more like singelplayer on someone elses rules.
19:18:53  <appe_> since he doesnt really play.
19:19:22  <Alberth> :(
19:20:46  <appe_> tho
19:20:53  <appe_> i have this town (small) with appaling status
19:21:27  <appe_> the status doesnt change with planting trees, and its too small to be bribed
19:21:27  <appe_> what to do?
19:22:22  <frosch123> clear all trees thoroughly
19:22:25  <frosch123> then replant
19:22:42  <frosch123> only the first tree on a tile coutns
19:24:29  <appe_> seriosly?
19:24:32  <appe_> for pete sake
19:24:38  <TrueBrain> who is this Pete you talk about?
19:24:55  <appe_> ive wasted £31,000,000 on trees.
19:25:30  <frosch123> sometimes it is better if you do not know the mechanics of a game :p
19:25:46  <frosch123> makes it more mysterious
19:25:50  <TrueBrain> spoils the game, or at least makes you feel stupid :D
19:25:55  <appe_> hehe
19:26:02  <appe_> indeed
19:27:32  *** APTX_ [] has quit [Ping timeout: 480 seconds]
19:30:34  <andythenorth> the first part of a game is figuring what the game is
19:30:44  <andythenorth> the other part is learning to win it :P
19:30:58  <andythenorth> with those two precepts, most of human pyschology is covered
19:33:06  * andythenorth wishes there was a special flag for RVs: "inherit refit from lead vehicle"
19:33:40  <andythenorth> i.e. refittable classes + properties
19:34:04  <Alberth> changing capacity of other vehicles does not cause enough chaos already?
19:34:27  <andythenorth> not really
19:34:35  <andythenorth> changing capacity is essential
19:34:56  <Alberth> OTHER vehicles
19:35:22  <Alberth> ie you buy a new engine and the wagons change capacity
19:37:06  <andythenorth> does that happen?
19:37:13  <andythenorth> sounds like newgrf author being odd
19:37:25  <andythenorth> or interestingly evil
19:37:58  <andythenorth> meanwhile I have to create a separate trailer vehicle for each trailer-truck
19:38:01  <andythenorth> :P
19:41:34  *** Mucht [] has joined #openttd
19:41:50  <Alberth> r23683
19:42:13  <SmatZ> @commit 23683
19:42:13  <DorpsGek> SmatZ: Commit by rubidium :: r23683 /trunk/src (4 files) (2011-12-28 19:48:04 UTC)
19:42:15  <DorpsGek> SmatZ: -Fix [FS#4912]-ish: when fitting another engine the cargo capacity of wagons could become lower, causing them to contain more than they should. This caused the cargo transfer from the replaced parts to put even more stuff in the already full wagon. Prevent this from happening by reducing the amount of cargo in the vehicle to the capacity when moving vehicles/wagons around, or when autoreplacing
19:43:19  <andythenorth> make it a road-vehicle-only special flag, not valid for lead vehicle?
19:43:32  <frosch123> just solve it with nml
19:43:33  <frosch123> much easier
19:43:42  <andythenorth> hmm
19:43:56  <andythenorth> nml can change props dynamically in the game? :o
19:44:07  <andythenorth> can it also make tea?
19:44:32  <andythenorth> I can solve it fast with templating + liberal use of vehicle IDs
19:44:40  <andythenorth> that's my plan right now
19:44:41  <frosch123> yup, do that
19:44:52  <andythenorth> "IDs are cheap" ?
19:44:58  <frosch123> that's why we extended artic parts to more than 128
19:45:14  <andythenorth> k
19:48:45  <andythenorth> also
19:48:51  <andythenorth> I've added too many trucks :P
19:51:51  <frosch123> andythenorth: if all your articulated parts have the same refittability as the front, you might actually consider to use the same id for all articulated parts as the front
19:52:35  <frosch123> though that might cause trouble with properties like weight
19:55:07  <andythenorth> frosch123: it's tmwftlb :)
19:55:14  <andythenorth> endless cb36
19:55:26  <andythenorth> I'll just sacrifice IDs
19:57:04  <andythenorth> if I used stats-upgrade-over-time for models, it would save IDs
19:57:08  <andythenorth> but nobody likes that :P
20:01:48  <TrueBrain> and I am a bit bored ...
20:11:17  *** FLHerne [] has joined #openttd
20:12:14  <Eddi|zuHause> frosch123: afair, weight is not supported for articulated parts
20:12:28  <Eddi|zuHause> i.e. "ignored, should be zero"
20:14:45  <Eddi|zuHause> any bets on when CETS will hit the next ID barrier? (which is currently 4096, but that may be stretched slightly if necessary)
20:16:04  <Eddi|zuHause> info: we just hit 600
20:19:39  <andythenorth> @calc 70 * 2.5
20:19:40  <DorpsGek> andythenorth: 175
20:19:42  *** supermop [] has joined #openttd
20:19:53  <andythenorth> @calc 175 * 1.4
20:19:53  <DorpsGek> andythenorth: 245.0
20:19:56  <andythenorth> meh
20:19:58  <andythenorth> should be ok
20:20:03  *** APTX [] has joined #openttd
20:21:37  <andythenorth> is there any problem with BANDIT disabling default trucks?
20:21:53  <andythenorth> or do I have to make that optional? :P
20:24:52  <andythenorth> hmm
20:25:18  <andythenorth> Yexo: could nml contain a macro or such for 'disable default vehicle [type]'
20:25:19  <andythenorth> ?
20:29:02  <Eddi|zuHause> andythenorth: just leave the busses alone
20:29:32  <Eddi|zuHause> andythenorth: disable_items()
20:29:38  <Eddi|zuHause> or something
20:29:54  <Eddi|zuHause> src/engines.gnml:disable_item(FEAT_TRAINS, 0, 115);
20:30:43  <andythenorth> Eddi|zuHause: I'll leave the buses ;)
20:32:12  *** stinkyfax [] has quit [Remote host closed the connection]
20:33:04  <andythenorth> Eddi|zuHause: ^^ is that an actual feature, or a suggestion?
20:34:00  <andythenorth> nvm
20:34:01  <andythenorth> found it
20:34:10  * andythenorth learns to tick 'nml' option on wiki search :P
20:34:17  <andythenorth> that helps rather a lot
20:38:25  *** vodka [] has quit [Quit: Leaving]
20:43:00  <andythenorth> hmm
20:43:09  <andythenorth> disable_item(FEAT_ROADVEHS, 123, 203);
20:43:11  <andythenorth> fails for me
20:43:59  <andythenorth> oh
20:44:02  * andythenorth fixes that
20:44:51  <Eddi|zuHause> need to use the _other_ id :)
20:45:10  <Eddi|zuHause> i.e. 0x07..0x39 (
20:45:30  <Eddi|zuHause> (or 0x57)
20:50:14  <andythenorth> indeed :)
20:57:52  *** pjpe [] has quit [Quit: ajax IRC Client]
21:04:37  *** ricky26 [~quassel@] has quit [Quit: - Chat comfortably. Anywhere.]
21:14:03  *** Mucht [] has quit [Remote host closed the connection]
21:31:25  *** glx [glx@2a01:e35:2f59:c7c0:ed8d:5832:265a:d29c] has quit [Ping timeout: 480 seconds]
21:32:23  *** TomyLobo2 [] has joined #openttd
21:38:12  *** TomyLobo [] has quit [Ping timeout: 480 seconds]
21:38:13  *** TomyLobo2 is now known as TomyLobo
21:45:51  *** DDR [~chatzilla@] has joined #openttd
21:47:19  *** Elukka [] has joined #openttd
21:52:44  *** Snail_ [] has quit [Quit: Snail_]
21:53:24  *** glx [glx@2a01:e35:2f59:c7c0:bd2d:766b:b0ec:d2b5] has joined #openttd
21:53:27  *** mode/#openttd [+v glx] by ChanServ
21:53:59  *** pjpe [] has joined #openttd
21:55:32  *** [lan3y] [] has quit []
21:56:33  *** pipfjsdf [] has joined #openttd
21:59:01  *** pjpe [] has quit [Quit: ajax IRC Client]
22:00:07  * andythenorth bed
22:00:08  *** andythenorth [] has quit [Quit: andythenorth]
22:10:44  *** sla_ro|master [~slaco@] has quit [Quit: Sla Mutant Co-Op for Renegade - coming back soon]
22:17:14  <xQR> wow with TrueBrain i have finally found someone who can keep up with my quantity of writing on the forums :D
22:20:33  *** Brianetta [] has joined #openttd
22:24:06  <Terkhen> he's not always in a writing mood :P
22:25:18  *** Hyronymus [] has joined #openttd
22:25:28  <Terkhen> good night
22:25:54  <TrueBrain> haha; very true, I can also be very short :P
22:26:15  *** MagisterQuis1 [] has joined #openttd
22:27:12  <Hyronymus> TrueBrain, planetmaker and Yexo
22:27:21  <Hyronymus> can we join a private channel
22:27:29  <TrueBrain> do you know how to use IRC? :P :D
22:27:35  <Hyronymus> yes, I do
22:27:47  <Hyronymus> want to share some stuff with you guys
22:27:49  <TrueBrain> take the invite :)
22:27:49  <Yexo> make a channel and send some invites
22:28:04  <TrueBrain> Yexo: I just invited him to dev channel :P
22:28:08  <Yexo> fine :)
22:28:17  <TrueBrain> but he doesnt have auto-join-on-invite :P
22:28:23  <planetmaker> :-)
22:30:02  <__ln__> makes me curious what's so secret it needs a private channel
22:30:59  <Chris_Booth> one can only speculate __ln__
22:31:10  <xQR> i smell conspiracy
22:32:01  *** MagisterQuis [] has quit [Ping timeout: 480 seconds]
22:33:05  <Chris_Booth> i smell burning
22:33:24  <iddqd> :(
22:34:25  <xQR> ^^
22:37:03  *** FLHerne [] has quit [Remote host closed the connection]
22:38:14  *** FLHerne [] has joined #openttd
22:42:40  *** KritiK [~Maxim@] has quit [Quit: Leaving]
22:43:26  *** Brianetta [] has quit [Quit: TschÌß]
22:48:42  <TrueBrain> lol; curious people :P
22:54:30  <FLHerne> So what is it? :P
22:55:05  <Yexo> a conspiracy of course!
22:57:28  <frosch123> something about replacing the forums' captcha with some ottd applet. e.g. fix the signalling of this junction to proceed
22:57:39  <FLHerne> Ooh, underground building at last :-)
22:57:51  <FLHerne> Or NewGRF penguins?
23:02:01  <planetmaker> NewGRF ice bears meet NewGRF penguin
23:02:18  <TrueBrain> hmm ... penguins
23:02:23  <TrueBrain> "does this count as annoying?!"
23:03:00  <DorpsGek> /me is bored
23:03:08  <TrueBrain> DorpsGek: again?!
23:03:14  <TrueBrain> and use action
23:03:15  <TrueBrain> not say
23:03:17  <TrueBrain> :P
23:03:17  <supermop> frosch123: that would be great for AI development, as suddenly there is an incentive for spambots to intelligently signal junctions
23:03:18  <Yexo> you must be really bored now ;p
23:03:48  <supermop> thus we co-opt all the effort of the malicious coding industry to improve our game
23:04:11  <TrueBrain> haha, lol @ who used DorpsGek, I did not expect you to say that :)
23:04:16  <TrueBrain> that is, you are not my usual suspect :P
23:08:55  *** KouDy [~KouDy@] has quit [Quit: Leaving.]
23:19:22  *** Snail_ [] has joined #openttd
23:31:39  *** Alberth [] has left #openttd []
23:35:32  *** TGYoshi [~TGYoshi@] has quit [Quit: Popidopidopido]
23:41:40  *** FLHerne [] has left #openttd []
23:42:04  *** FLHerne [] has joined #openttd
23:48:53  *** Chris_Booth [] has quit [Quit: ChatZilla 0.9.88 [Firefox 10.0/20120104111456]]
23:51:09  *** Progman [] has quit [Remote host closed the connection]
23:56:18  *** Hyronymus [] has quit [Remote host closed the connection]
23:57:09  *** FLHerne [] has left #openttd []
23:57:28  *** fjb|tab is now known as Guest23287
23:57:28  *** Guest23287 [] has quit [Read error: Connection reset by peer]
23:57:28  *** fjb|tab [] has joined #openttd
23:57:38  *** Zuu [] has quit [Ping timeout: 480 seconds]

Powered by YARRSTE version: svn-trunk