Back to Home / #openttd / 2012 / 01 / Prev Day | Next Day
#openttd IRC Logs for 2012-01-07

---Logopened Sat Jan 07 00:01:02 2012
00:24-!-fjb|tab is now known as Guest23080
00:24-!-fjb|tab [] has joined #openttd
00:27-!-Guest23080 [] has quit [Ping timeout: 480 seconds]
00:56-!-Eddi|zuHause [] has quit [Remote host closed the connection]
00:56-!-Eddi|zuHause [] has joined #openttd
01:09-!-Pixa [] has joined #openttd
01:09-!-LordPixaII [] has quit [Read error: Connection reset by peer]
01:13-!-andythenorth [] has joined #openttd
01:34<CIA-6>OpenTTD: rubidium * r23768 /trunk/changelog.txt: -Fix: inconsistent stye in changelog
01:42<andythenorth>could model availability be handled by a CB?
01:43<andythenorth>either for prop 06 (climate) or prop 04 (model life)
01:43<andythenorth>climate would be better
01:52*andythenorth ponders magic
02:11<andythenorth>doesn't work so well for hiding one model when a new one becomes available
02:11*andythenorth is spamming the buy menu with trucks, and would like some to go away :P
02:11<andythenorth>model life is....unpredictable at best
02:25-!-andythenorth [] has quit [Ping timeout: 480 seconds]
02:28-!-sla_ro|master [~slaco@] has joined #openttd
02:35-!-DayDreamer [] has joined #openttd
02:36-!-DayDreamer [] has left #openttd []
02:52-!-sla_ro|master [~slaco@] has quit [Ping timeout: 480 seconds]
02:54-!-sla_ro|master [~slaco@] has joined #openttd
02:59-!-Remi_Woler [] has quit [Read error: Connection reset by peer]
03:02-!-sla_ro|master [~slaco@] has quit [Ping timeout: 480 seconds]
03:13-!-andythenorth [] has joined #openttd
03:21-!-andythenorth is now known as Guest23177
03:21-!-andythenorth [] has joined #openttd
03:25-!-Elukka [] has quit []
03:27-!-Progman [] has joined #openttd
03:27-!-Guest23177 [] has quit [Ping timeout: 480 seconds]
03:30-!-sla_ro|master [~slaco@] has joined #openttd
03:34<@Terkhen>good morning
03:35-!-TdlQ_ [] has joined #openttd
03:35-!-TdlQ_ is now known as MJP
03:39<andythenorth>hola Terkhen
03:40*andythenorth ponders using the nml generator from Eddi|zuHause
03:40<andythenorth>"but generators are evil!"
03:46-!-fonsinchen [] has joined #openttd
03:50-!-sla_ro|master [~slaco@] has quit [Ping timeout: 480 seconds]
03:51-!-Alberth [] has joined #openttd
03:51-!-mode/#openttd [+o Alberth] by ChanServ
04:02-!-KouDy [~KouDy@] has joined #openttd
04:10*andythenorth wonders if CPP can do something like #define veh_id _filename_
04:12<@Alberth>you mean dynamically create new #define ? no, afaik
04:12*Alberth recommends m4 instead
04:14<@Alberth>cpp is designed as text replacement engine, not as code generator
04:16<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)
04:16<andythenorth>it's probably a bad pattern :P
04:17-!-sla_ro|master [~slaco@] has joined #openttd
04:17<@Alberth>there is __FILE__
04:29-!-pjpe [] has quit [Quit: ajax IRC Client]
04:35-!-Chris_Booth [] has joined #openttd
04:44-!-TdlQ [] has joined #openttd
04:51-!-MJP [] has quit [Ping timeout: 480 seconds]
04:51-!-TdlQ is now known as MJP
04:56-!-fonsinchen [] has quit [Ping timeout: 480 seconds]
05:00-!-sla_ro|master [~slaco@] has quit [Quit: Sla Mutant Co-Op for Renegade - coming back soon]
05:07-!-Devroush [] has joined #openttd
05:19-!-sla_ro|master [~slaco@] has joined #openttd
05:24-!-Kurimus [] has joined #openttd
05:30-!-TGYoshi [~TGYoshi@] has joined #openttd
05:30-!-andythenorth [] has quit [Quit: andythenorth]
05:31-!-fonsinchen [] has joined #openttd
05:42-!-welshdragon [] has joined #openttd
05:47-!-JVassie [~James@] has joined #openttd
05:54-!-fonsinchen [] has quit [Ping timeout: 480 seconds]
06:14-!-sla_ro|master [~slaco@] has quit [Quit: Sla Mutant Co-Op for Renegade - coming back soon]
06:21-!-DDR [~chatzilla@] has quit [Remote host closed the connection]
06:22-!-DDR [~chatzilla@] has joined #openttd
06:25-!-sla_ro|master [~slaco@] has joined #openttd
06:30<TrueBrain>Why is it that Windows Update takes longer than a Gentoo update?
06:30<TrueBrain>that surely has to be wrong :(
06:35-!-Zuu [] has joined #openttd
06:36<@Alberth>MS minutes
06:38<Ammler>you update windows every half a year when you accidentially start it
06:38<Ammler>or when you want to play Mass Effect
06:40-!-frosch123 [] has joined #openttd
06:40<@Alberth>they want to make sure there are enough sysadmins around to manage the window systems
06:40<@Alberth>o/ frosch123
06:41-!-fonsinchen [] has joined #openttd
06:41<frosch123>hai albert :)
06:44<TrueBrain>weird part is, I update every month. Yet it takes FOR EVER :(
06:46*Alberth blames DRM
06:47<TrueBrain>you are most likely right
06:49-!-APTX_ [] has joined #openttd
06:50<@Alberth>moin pm
06:51-!-kkb110_ [] has joined #openttd
06:51-!-APTX [] has quit [Read error: Connection reset by peer]
06:51<kkb110_>Q: I would like to add custom toolbar that needs drag-drop on the view... what file/function should I look at???
06:52-!-tokai|noir [] has joined #openttd
06:52<@Alberth>you want to make a new toolbar?
06:54<@Alberth>if so, you are basically creating a new window, so any toolbar window will do
06:55<@Alberth>the airport build bar is quite simple, should be in airport_gui
06:55<@Alberth>Window *ShowBuildAirToolbar()
06:57<@Alberth>I am not sure that we have cross-window drag/drop. you could look in the depot window perhaps
06:57<@Alberth>that is not cross-window, but it does show the functions involved
06:57-!-tokai|mdlx [] has quit [Ping timeout: 480 seconds]
06:58-!-andythenorth [] has joined #openttd
06:59<@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
06:59<@Alberth>o/ andy
07:00-!-DDR [~chatzilla@] has quit [Quit: ChatZilla 0.9.88 [Firefox 9.0.1/20111221202647]]
07:04<kkb110_>Alberth, ok I'll give a shot thank you :)
07:04<frosch123>be careful, the order window is the most complicated window code we have
07:05<kkb110_>most codes are already complicated enough for me lol
07:06<@Alberth>what do you want to drag/drop?
07:07<kkb110_>I'm planning to "remake" copy/paste feature
07:09<@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
07:09<@Alberth>or the other way around, click 'raise', drag an area, and it gets raised
07:11<@Alberth>tbh I don't see the need for drag/drop so much
07:11<kkb110_>then how to specify copying area?
07:11<@Alberth>just like terraforming does it
07:12<kkb110_>wait.. so it's drag-drop now?
07:12<@Alberth>dragging until mouse is released already exists
07:12<kkb110_>yes that's what I'm looking for
07:13<@Alberth>oh, I understood your question as drag from your new window onto the main display
07:13<kkb110_>it hope it makes easier than before lol
07:14<@Alberth>the terraform window would be useful to study
07:14<kkb110_>ok terraform_gui.cpp..
07:15<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
07:15<@Alberth>the station placement window can also drag an area
07:16<@Alberth>I would assume they have covered the UI already
07:16<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!
07:16<@Alberth>kkb110_: so focus on the window parts only
07:17<@Alberth>kkb110_: and quite likely, those thousands of lines are mostly all needed :p
07:18<kkb110_>Alberth, haha yes probably
07:20-!-Brianetta [] has joined #openttd
07:21-!-fjb|tab [] has quit [Remote host closed the connection]
07:22-!-fjb|tab [] has joined #openttd
07:26-!-fjb|tab is now known as Guest23256
07:26-!-Guest23256 [] has quit [Read error: Connection reset by peer]
07:26-!-fjb|tab [] has joined #openttd
07:30<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 :)
07:31<@Alberth>that saves a few hundred lines of code :p
07:51-!-hbc [~hbc@] has joined #openttd
07:51-!-hbc [~hbc@] has left #openttd []
07:51-!-hbc [~hbc@] has joined #openttd
07:52-!-hbc [~hbc@] has left #openttd []
07:52-!-hbccbh [~hbc@] has joined #openttd
07:52<@Alberth>staying now hbccbh ?
07:53<@Alberth>welcome then :)
07:53<hbccbh>thx, my network down just now =(
08:00<fonsinchen>good morning everybody
08:01-!-hbccbh [~hbc@] has quit [Ping timeout: 480 seconds]
08:06-!-KritiK [~Maxim@] has joined #openttd
08:08-!-glx [glx@2a01:e35:2f59:c7c0:ed8d:5832:265a:d29c] has joined #openttd
08:08-!-mode/#openttd [+v glx] by ChanServ
08:13<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?
08:13<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.
08:13-!-luxOOr [] has joined #openttd
08:14<fonsinchen>(And don't say hg patch queues as those are linear only and apart from that have the same problem)
08:15<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 ...
08:15<@Alberth>did you automate this handling?
08:16<fonsinchen>I have that "" script in my repo which does all the merging for me
08:16<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
08:16-!-hbccbh [~hbc@] has joined #openttd
08:16<fonsinchen>However, if there is a conflict somewhere it's likely I have to resolve that several times in a row for different branches
08:17<@Alberth>that's where the shit hits the fan thus :)
08:17<fonsinchen>And merges are ugly, they destroy the commit history
08:18<@Alberth>MJP: euhm, somewhen later today perhaps? do you have a link?
08:18<MJP>it's there : … and there's no hurry :)
08:19<@Alberth>I never change history
08:19-!-valhallasw [~valhallas@] has joined #openttd
08:20<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
08:20<@Alberth>it destroys history in the sense that you don't have a sequence patch1, patch2, etc ?
08:20<fonsinchen>No, it intermixes trunk changes with my changes
08:21<fonsinchen>So if I'm looking for some set of commits where I changed something it's likely they're not in a sequence.
08:22<fonsinchen>and it creates loads and loads of "Merge blah" commits.
08:22-!-luxOOr [] has left #openttd []
08:22<@Alberth>I am trying to picture what you want to achieve
08:23<@Alberth>basically have a repo for each revision?
08:23<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.
08:24<fonsinchen>for example one branch for feature "reservation", one for "MCF" and one for "cargomap" which depends on "MCF" and "reservation"
08:24<@Alberth>what if you consider each to be a separate project?
08:25<fonsinchen>And then?
08:25<@Alberth>with its own repo, and releases
08:26<fonsinchen>Then I have 22 folders each with one copy of OpenTTD and some changes on top of that.
08:26<fonsinchen>Sounds like a mess ...
08:27<@Alberth>I am not sure what exactly the problem is, often creating more structure helps, but perhaps not here
08:28<appe_>bah, i can see the ufo land
08:28<appe_>but i cant prevent it?
08:28<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.
08:29<fonsinchen>I'm constantly switching branches, merging things back and forth, resolving conflicts and stuff like that.
08:29-!-Mucht [] has joined #openttd
08:30<@Alberth>appe_: quickly remove all tracks :p
08:30<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.
08:31<@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
08:32<@Alberth>ie I think it now treats each patch as a separate patch without taking into account it came from a queue
08:33<@Alberth>which gives the multiple conflict mess you talk about
08:34<@Alberth>but writing such software is a whole new project in itself :(
08:34<fonsinchen>It should be possible to use git or hg in a more intelligent way, though.
08:35<@Alberth>maybe you should talk to some git gurus
08:35<+michi_cc>git rebase -i and git add -i
08:36<+michi_cc>Are the commits in your branches smaller, bigger or equal to a typical trunk commit?
08:36<fonsinchen>they differ wildly
08:37<fonsinchen>sometimes they're one liners where I only fixed some whitespace problem, sometimes it's a complete reimplementation of some class.
08:37<fonsinchen>I don't like my commit history so much anyway
08:38<fonsinchen>I should restructure the whole thing and rebase it on trunk.
08:39<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?
08:39<+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.
08:39<fonsinchen>and you make that fix commit on top of the one and only YACD branch I guess?
08:40<fonsinchen>probably you mark it somehow as "belongs to commit X". I see ...
08:43<+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.
08:45<+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).
08:46<+michi_cc>The YACD repository went through too many iterations that hide this process by now.
08:46<fonsinchen>Ah nice, autosquash is what I was looking for, I guess.
08:46<fonsinchen>what is git citool?
08:47-!-FLHerne [] has joined #openttd
08:47<@Alberth>MJP: I didn't invent the focus stuff, Zuu did. How does it fix what problem?
08:47-!-Wolf01 [] has joined #openttd
08:47<@Alberth>o/ Wolf01
08:47<Wolf01>o/ Alberth
08:48<+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
08:49<+michi_cc>Just to spell it out explicitly, my kind of workflow completely relies on working with the index/staging area of git.
08:50<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.
08:50<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)
08:51-!-valhalla1w [~valhallas@] has joined #openttd
08:51<fonsinchen>You would probably edit the head until the feature is ready and then reorder the commits with git rebase -i, right?
08:52<fonsinchen>Saves a lot of checkout and merge action and makes a nice commit history ...
08:52<+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.
08:52<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
08:52-!-valhalla1w [~valhallas@] has quit [Remote host closed the connection]
08:53<@Alberth>MJP: ? this->nested_root->GetWidgetOfType(WWT_EDITBOX) != NULL fails for news afaik
08:53<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.
08:54<fonsinchen>and so I think the commit (or branch) should also be there.
08:55<@Alberth>MJP: maybe I don't understand "getting focus" here? A viewport also doesn't have an edit box
08:55<MJP>Alberth: this is strange because when the news shows up, _focused_window points to its window
08:57<@Alberth>MJP: the whole focus stuff already existed when I came in, and I 'only' changed how widgets are created and sized.
08:57-!-valhallasw [~valhallas@] has quit [Ping timeout: 480 seconds]
08:58-!-vodka [] has joined #openttd
08:58<+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.
08:58<@Alberth>so far I never really understood what its function is
08:59<@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
09:00<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)
09:00<+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.
09:01<+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.
09:02<@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 :) )
09:02-!-FLHerne [] has left #openttd []
09:03<@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
09:04<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
09:05<@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
09:05<@Alberth>perhaps your fixes force a few extra redraws or so?
09:06<+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.
09:06-!-dageek [~dageek@2001:8b0:ff85:0:223:32ff:fec9:1f10] has joined #openttd
09:06<MJP>while I scroll a viewport, it refreshes its position if there are viewports ar a map zoomlevel
09:07<@Alberth>michi_cc: sounds useful
09:12<@Alberth>when a news window rises, you get a second source of redraw requests, perhaps that interferes in some way
09:12<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?
09:13<MJP>Zuu: take a look at
09:13<Zuu>Yes, I have patch5 open here.
09:13<MJP>the white box on the map moves as I scroll the extra viewport
09:14<MJP>to draw that white box, I use _focused_window
09:14<fonsinchen>brrr, my patches are between 2.1K and 71K in size. I definitely should restructure the whole thing ...
09:15<MJP>but when the news rises, the white box has size and position of the news window and not the extraviewport I am scrolling
09:15<Zuu>So you draw this white rectangle automatically if a extra viewport is open and is focused?
09:15<MJP>and scrolled, yes
09:15<fonsinchen>OK, the largest one is smallmap-refactor which is only syntactical sugar.
09:17<Eddi|zuHause>the 64x zoom out patch starts to look interesting (basically like "smallmap in main viewport")
09:17<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.
09:18<Zuu>Ok, I guess then scrolling a small map will qualify as grabing input.
09:18<Eddi|zuHause>the space bar to close the news?
09:18<MJP>Eddi|zuHause: thanks :)
09:18<Zuu>Could be a global hotkey
09:19<Zuu>I don't know actually, but I would guess it's global.
09:19<Zuu>Meaning thas as far as no text input has focus, you can execute a global hotkey.
09:19<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
09:21-!-Chris_Booth [] has quit [Remote host closed the connection]
09:21<Zuu>I can not really say if it is wrong or right. If you need to do it, I guess you have too.
09:22<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.
09:23<Zuu>So perhaps your solution is not that bad after all. :-)
09:23<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)
09:24-!-Markavian [] has joined #openttd
09:24<Eddi|zuHause>that was quite annoying, honestly
09:24<MJP>well time will tell if there are unwanted side effects :)
09:25-!-Markavian` [] has quit [Ping timeout: 480 seconds]
09: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?
09:27<MJP>err, no
09:28<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.
09:29<MJP>ok, I'll do that for the next release
09:29<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.
09:43<CIA-6>OpenTTD: rubidium * r23769 /trunk/src/ (3 files in 3 dirs): -Codechange: make the lag/join start timeouts configurable as well
09:48-!-pugi [] has joined #openttd
09:58-!-TWerkhoven [] has joined #openttd
10:09-!-Chris_Booth [] has joined #openttd
10:11-!-valhallasw [~valhallas@] has joined #openttd
10:15<fonsinchen>Is there an explanation of the commit message prefixes somewhere? For example when do you use "Add:" and when do you use "Feature:".
10:15<appe_>i just found a big set back with using big circular network to get lots of trains around
10:16<appe_>the amount of work needed when you have 2-300 trains on the same railway (but none of them to the same industry)
10:16<appe_>is staggering
10:17<frosch123>but it is pretty mood :)
10:17<frosch123>i use feature/change for user-visible stuff, and add/codechange for more refactoring/preparation stuff
10:19<fonsinchen>Thanks. Can I get that check script?
10:23-!-hbccbh [~hbc@] has quit [Quit: Leaving.]
10:24<frosch123>i would guess tb would find it faster than me
10:27<fonsinchen>TrueBrain: Could you find me that commit stye check script for the openttd repository, please?
10:28<TrueBrain>its embedded in our post-commit
10:28<TrueBrain>a simple regexp .. euhh ..
10:28<TrueBrain>euh, precommit of course
10:29<fonsinchen>The regex would be enough then, I gues
10:29<TrueBrain>then validation of the variables follow
10:30<TrueBrain>hope I copy/pasted it correct, as linebreaks go all crazy
10:31<TrueBrain>overly complex due to branches
10:31<TrueBrain>cut -d: -f1
10:31<TrueBrain>would work too :P
10:31-!-andythenorth [] has quit [Remote host closed the connection]
10:32<fonsinchen>And it doesn't really enforce the types from, does it?
10:33<@planetmaker>It does
10:33<TrueBrain>it has a big switch following yeah
10:33<@planetmaker>at least the leading "-"
10:33<TrueBrain>which is a part of this list :P
10:33-!-andythenorth [] has joined #openttd
10:34<TrueBrain>things like Move are also accepted; but that is of little relevance to most :)
10:34<fonsinchen>OK, I can recreate that list myself.
10:34<TrueBrain>it depends on the project :)
10:35<fonsinchen>I just want to make sure my commit messages look like yours and I'm notoriously mistyping them
10:37<@Alberth>fonsinchen: can you use a Python script? I have written a check thingie for hg
10:38<fonsinchen>a python script would also be nice
10:38<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 :)
10:38<TrueBrain>I would not worry too much if you pick the right word, like Fix, Add, ...
10:38<TrueBrain>the devs already have different interpertations of it :P
10:41<@Alberth>but quite likely the commit message is typed again manually when merging to trunk, so I wouldn't worry too much about them
10:43<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.
10:45<fonsinchen>this looks a lot nicer I think:
10:56-!-fonsinchen [] has quit [Ping timeout: 480 seconds]
11:02-!-Illegal_Alien [] has quit [Ping timeout: 480 seconds]
11:02-!-Snail_ [] has joined #openttd
11:08-!-dageek [~dageek@2001:8b0:ff85:0:223:32ff:fec9:1f10] has quit [Quit: dageek]
11:23-!-George [~George@] has quit [Read error: Connection reset by peer]
11:23-!-fonsinchen [] has joined #openttd
11:24-!-Mucht [] has quit [Ping timeout: 480 seconds]
11:27-!-George [~George@] has joined #openttd
11:34-!-TWerkhoven [] has quit [Quit: He who can look into the future, has a brighter future to look into]
11:41-!-FLHerne [] has joined #openttd
11:41-!-FLHerne [] has left #openttd []
11:42<appe_>what kind of parameters decide whether new industries open on a normal map?
11:42<Zuu>What is the state with readmes now, should content providers insert hard line breaks or not?
11:43<frosch123>readmes use monospaced fonts now
11:43<frosch123>so they may do any kind of ascii formatting they like to do
11:44<frosch123>no idea about wrapping though
11:45<andythenorth>appe_: map generator settings
11:45<andythenorth>using an industry newgrf?
11:46<appe_>no, all standard
11:46<appe_>im playing online
11:46<appe_>the server settings allow new industries (they occationally pop up)
11:46<appe_>but i need ways to make new pop up
11:48<appe_>the server settings are: manual primary ind.. ..method: none, allow multiple similar industries per town = off.
11:48<appe_>that is what i find
11:49<frosch123>it's random then, no chance for you to influence it
11:49<Rubidium>except disabling industries at all
11:50<appe_>ah, ok.
11:50<appe_>increasing city size should promote the rate of new industries
11:50<appe_>that would be neat
11:50<appe_>and realistic, if im honest.
11:52<andythenorth>GS :P
11:52<TrueBrain>what have I done .. I made GS the default goto for any issue
11:53<TrueBrain>read the crasiest things already :P
12:00<andythenorth>TrueBrain: I may not always be serious when I offer GS as the default answer :P
12:01<andythenorth>although I did wonder today if we should deprecate most of newgrf
12:04<TrueBrain>please not :)
12:04-!-mahmoud [] has joined #openttd
12:05<@Terkhen>why? they are separate things
12:05<Eddi|zuHause>and certainly not "most of"...
12:05<andythenorth>just make them graphics
12:05<andythenorth>with names defined in xml
12:05<andythenorth>all properties decided by GS
12:06<Eddi|zuHause>that's nonsense
12:06<andythenorth>otherwise how are things like tech trees supported?
12:06<TrueBrain>I wonder how GS would handle that, CPU-wise
12:06<TrueBrain>I wonder how hard it is to write a GRF interperter in GS :P
12:07<andythenorth>to achieve some things, GS needs control of, e.g. vehicles directly,
12:07<@Terkhen>NewGRFs are slow already
12:08<@Terkhen>besides that, I don't see why the format makes a difference regarding "who has control"
12:09<andythenorth>it's a question of what's canonical
12:09-!-DOUK [] has quit [Ping timeout: 480 seconds]
12:09<andythenorth>if a GS can modify properties defined by newgrf, that's a nightmare of bug reports
12:09<andythenorth>therefore - remove newgrf...
12:09<andythenorth>GS authors who want things like tech trees then need to provide the vehicles
12:09<andythenorth>it makes no sense unless they do anyway
12:10<@Terkhen>why can't that be done with NewGRFs?
12:10<andythenorth>instead of GS?
12:10<andythenorth>or combined with GS?
12:11<@Alberth>TrueBrain: one squirrel instance per house :p
12:13<@Terkhen>andythenorth: what I mean is, what makes those ideas format dependent?
12:14<andythenorth>newgrf can't do things like raise a dialogue box to the user?
12:15<TrueBrain>Alberth: I rather to .. fuck .. my brain goes blank
12:15<TrueBrain>I would love to write OpenTTD in erlang, the statemachine part of it :)
12:15<TrueBrain>would result in some epicness :D
12:16<TrueBrain>to = do
12:16<TrueBrain>I need a dinner :P
12:16<@Alberth>yeah, that's one of the few positive properties you can attach to that :D
12:16<@Terkhen>andythenorth: how would an XML format do it?
12:16<@Alberth>enjoy TB
12:16<TrueBrain>andythenorth: tbh, you do have a point. Some hybrid would be best for everything
12:17<TrueBrain>but .... :)
12:17<andythenorth>we are where we are :)
12:17-!-Brianetta [] has quit [Quit: Tschüß]
12:17<andythenorth>I don't advocate that we drop newgrf
12:17<Eddi|zuHause>mäh... google docs is so buggy...
12:17<TrueBrain>GS in NewGRF
12:17<andythenorth>but that limits GS potential
12:17<TrueBrain>would be a nice hybrid :)
12:17<TrueBrain>let iets NewGRF run his own GS :P
12:19<andythenorth>moderately valid actually :)
12:19<@Terkhen>so... deprecate NewGRFs and use a new format that is coupled better with GS?
12:19<andythenorth>Terkhen: it's not format
12:19<andythenorth>it's canonicalness
12:19<TrueBrain>in some way NewGRF is like GS, just GS has an easier API :D :P :D
12:22<frosch123>he, we already failed to make gs actually define an entity :p
12:22<frosch123>in gmae
12:26-!-[lan3y] [] has joined #openttd
12:27<[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?
12:27<frosch123>or alt+center
12:30-!-George [~George@] has quit [Read error: Connection reset by peer]
12:35-!-George [~George@] has joined #openttd
12:37-!-TdlQ [] has joined #openttd
12:39-!-fonsinchen [] has quit [Remote host closed the connection]
12:42-!-MJP [] has quit [Ping timeout: 480 seconds]
12:49-!-TdlQ is now known as MJP
12:50<andythenorth>BANDIT is done :P
12:51<@Alberth>so many! :O
12:52<andythenorth>too many probably
12:52<andythenorth>the set covers at least 110 years of gameplay though
12:52<andythenorth>those trucks cover 1905-1970
12:52<frosch123>they look all the same :p
12:52<andythenorth>probably too many :P
12:53<frosch123>make them available only for 5 years each :p
12:53<andythenorth>if I didn't have to replicate 'trucks without trailers' and 'trucks with trailers' there would be fewerer
12:53<andythenorth>but as that's required....
12:55<andythenorth>frosch123: one of them is different in appearance
12:55<andythenorth>I challenge you to spot which :D
12:56<andythenorth>[some of the above may be lies]
12:58<frosch123>they look the same to me
12:59<andythenorth>my lie is discovered :P
12:59<frosch123>the names are different though :p
13:00<andythenorth>that's about all so far :P
13:00<andythenorth>for semi-trailer trucks, /me has to calculate weight transfer from trailer to truck, and split capacity accordingly :P
13:03<appe_>i found a way to make new industries on my tiny 64x64 internet game
13:03<appe_>make the water dissapear.
13:04-!-Chris_Booth [] has quit [Ping timeout: 480 seconds]
13:13-!-welshdragon [] has quit [Quit: welshdragon]
13:19<andythenorth>too many trucks :P
13:22-!-welshdragon [] has joined #openttd
13:24-!-andythenorth [] has quit [Quit: andythenorth]
13:37<CIA-6>OpenTTD: smatz * r23770 /trunk/src/script/api/ (script_station.hpp script_waypoint.hpp): -Fix: compilation with GCC 4.7
13:41-!-Chris_Booth [] has joined #openttd
13:45<CIA-6>OpenTTD: translators * r23771 /trunk/src/lang/ (8 files in 2 dirs): (log message trimmed)
13:45<CIA-6>OpenTTD: -Update from WebTranslator v3.0:
13:45<CIA-6>OpenTTD: belarusian - 2 changes by Wowanxm
13:45<CIA-6>OpenTTD: catalan - 23 changes by arnau
13:45<CIA-6>OpenTTD: finnish - 2 changes by jpx_
13:45<CIA-6>OpenTTD: latvian - 65 changes by Tranzistors
13:45<CIA-6>OpenTTD: romanian - 3 changes by tonny
13:46<appe_>room, plz.
13:49<@Alberth>3 platforms for a powerplant? a bit overkill, isn't it?
13:50<appe_>its for the power plant and the timber station
13:50<appe_>im forced to rebuild it to get more trains on there.
13:53<@Alberth>lack of space is the biggest challenge in 64x64 indeed :)
13:53<Eddi|zuHause>i never found fun in 64x64... after three lines you're "done" and have "nothing" to do anymore...
13:54<Eddi|zuHause>you should probably put up more path signals
13:54<appe_>Alberth: hehe
13:55<appe_>Eddi|zuHause: to tight it up a bit?
13:55<@Alberth>Eddi|zuHause: play FIRS at 64x64, you get 1 industry of each :)
13:56<@Alberth>oh, plenty of space :p
13:57<appe_>man, this is fn
13:57<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
13:57<appe_>since i cant affect the rules, cheat or fast forward.
13:57<appe_>its neat.
13:58*Alberth likes building things together
13:59<Eddi|zuHause>Alberth: the smallest i played sensibly was 128x256. that also brought me 1 of each industry
14:00<@Alberth>yes, you always get at least 1 of each required industry, unless it cannot be placed
14:01<Eddi|zuHause>Alberth: i mean "not more"
14:02<Eddi|zuHause>that was my YACD game, and passengers kinda trumped cargo anyway
14:02-!-pjpe [] has joined #openttd
14:03<Eddi|zuHause>YACDist may be more interesting for cargo
14:03<Eddi|zuHause>or some hybrid that we discussed a while ago
14:06-!-HerzogDeXtEr1 [] has joined #openttd
14:11-!-andythenorth [] has joined #openttd
14:12-!-HerzogDeXtEr [] has quit [Ping timeout: 480 seconds]
14:18<appe_>Alberth: no, not really, its more like singelplayer on someone elses rules.
14:18<appe_>since he doesnt really play.
14:20<appe_>i have this town (small) with appaling status
14:21<appe_>the status doesnt change with planting trees, and its too small to be bribed
14:21<appe_>what to do?
14:22<frosch123>clear all trees thoroughly
14:22<frosch123>then replant
14:22<frosch123>only the first tree on a tile coutns
14:24<appe_>for pete sake
14:24<TrueBrain>who is this Pete you talk about?
14:24<appe_>ive wasted £31,000,000 on trees.
14:25<frosch123>sometimes it is better if you do not know the mechanics of a game :p
14:25<frosch123>makes it more mysterious
14:25<TrueBrain>spoils the game, or at least makes you feel stupid :D
14:27-!-APTX_ [] has quit [Ping timeout: 480 seconds]
14:30<andythenorth>the first part of a game is figuring what the game is
14:30<andythenorth>the other part is learning to win it :P
14:30<andythenorth>with those two precepts, most of human pyschology is covered
14:33*andythenorth wishes there was a special flag for RVs: "inherit refit from lead vehicle"
14:33<andythenorth>i.e. refittable classes + properties
14:34<@Alberth>changing capacity of other vehicles does not cause enough chaos already?
14:34<andythenorth>not really
14:34<andythenorth>changing capacity is essential
14:34<@Alberth>OTHER vehicles
14:35<@Alberth>ie you buy a new engine and the wagons change capacity
14:37<andythenorth>does that happen?
14:37<andythenorth>sounds like newgrf author being odd
14:37<andythenorth>or interestingly evil
14:37<andythenorth>meanwhile I have to create a separate trailer vehicle for each trailer-truck
14:41-!-Mucht [] has joined #openttd
14:42<SmatZ>@commit 23683
14:42<@DorpsGek>SmatZ: Commit by rubidium :: r23683 /trunk/src (4 files) (2011-12-28 19:48:04 UTC)
14:42<@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
14:43<andythenorth>make it a road-vehicle-only special flag, not valid for lead vehicle?
14:43<frosch123>just solve it with nml
14:43<frosch123>much easier
14:43<andythenorth>nml can change props dynamically in the game? :o
14:44<andythenorth>can it also make tea?
14:44<andythenorth>I can solve it fast with templating + liberal use of vehicle IDs
14:44<andythenorth>that's my plan right now
14:44<frosch123>yup, do that
14:44<andythenorth>"IDs are cheap" ?
14:44<frosch123>that's why we extended artic parts to more than 128
14:48<andythenorth>I've added too many trucks :P
14: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
14:52<frosch123>though that might cause trouble with properties like weight
14:55<andythenorth>frosch123: it's tmwftlb :)
14:55<andythenorth>endless cb36
14:55<andythenorth>I'll just sacrifice IDs
14:57<andythenorth>if I used stats-upgrade-over-time for models, it would save IDs
14:57<andythenorth>but nobody likes that :P
15:01<TrueBrain>and I am a bit bored ...
15:11-!-FLHerne [] has joined #openttd
15:12<Eddi|zuHause>frosch123: afair, weight is not supported for articulated parts
15:12<Eddi|zuHause>i.e. "ignored, should be zero"
15:14<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)
15:16<Eddi|zuHause>info: we just hit 600
15:19<andythenorth>@calc 70 * 2.5
15:19<@DorpsGek>andythenorth: 175
15:19-!-supermop [] has joined #openttd
15:19<andythenorth>@calc 175 * 1.4
15:19<@DorpsGek>andythenorth: 245.0
15:19<andythenorth>should be ok
15:20-!-APTX [] has joined #openttd
15:21<andythenorth>is there any problem with BANDIT disabling default trucks?
15:21<andythenorth>or do I have to make that optional? :P
15:25<andythenorth>Yexo: could nml contain a macro or such for 'disable default vehicle [type]'
15:29<Eddi|zuHause>andythenorth: just leave the busses alone
15:29<Eddi|zuHause>andythenorth: disable_items()
15:29<Eddi|zuHause>or something
15:29<Eddi|zuHause>src/engines.gnml:disable_item(FEAT_TRAINS, 0, 115);
15:30<andythenorth>Eddi|zuHause: I'll leave the buses ;)
15:32-!-stinkyfax [] has quit [Remote host closed the connection]
15:33<andythenorth>Eddi|zuHause: ^^ is that an actual feature, or a suggestion?
15:34<andythenorth>found it
15:34*andythenorth learns to tick 'nml' option on wiki search :P
15:34<andythenorth>that helps rather a lot
15:38-!-vodka [] has quit [Quit: Leaving]
15:43<andythenorth>disable_item(FEAT_ROADVEHS, 123, 203);
15:43<andythenorth>fails for me
15:44*andythenorth fixes that
15:44<Eddi|zuHause>need to use the _other_ id :)
15:45<Eddi|zuHause>i.e. 0x07..0x39 (
15:45<Eddi|zuHause>(or 0x57)
15:50<andythenorth>indeed :)
15:57-!-pjpe [] has quit [Quit: ajax IRC Client]
16:04-!-ricky26 [~quassel@] has quit [Quit: - Chat comfortably. Anywhere.]
16:14-!-Mucht [] has quit [Remote host closed the connection]
16:31-!-glx [glx@2a01:e35:2f59:c7c0:ed8d:5832:265a:d29c] has quit [Ping timeout: 480 seconds]
16:32-!-TomyLobo2 [] has joined #openttd
16:38-!-TomyLobo [] has quit [Ping timeout: 480 seconds]
16:38-!-TomyLobo2 is now known as TomyLobo
16:45-!-DDR [~chatzilla@] has joined #openttd
16:47-!-Elukka [] has joined #openttd
16:52-!-Snail_ [] has quit [Quit: Snail_]
16:53-!-glx [glx@2a01:e35:2f59:c7c0:bd2d:766b:b0ec:d2b5] has joined #openttd
16:53-!-mode/#openttd [+v glx] by ChanServ
16:53-!-pjpe [] has joined #openttd
16:55-!-[lan3y] [] has quit []
16:56-!-pipfjsdf [] has joined #openttd
16:59-!-pjpe [] has quit [Quit: ajax IRC Client]
17:00*andythenorth bed
17:00-!-andythenorth [] has quit [Quit: andythenorth]
17:10-!-sla_ro|master [~slaco@] has quit [Quit: Sla Mutant Co-Op for Renegade - coming back soon]
17:17<xQR>wow with TrueBrain i have finally found someone who can keep up with my quantity of writing on the forums :D
17:20-!-Brianetta [] has joined #openttd
17:24<@Terkhen>he's not always in a writing mood :P
17:25-!-Hyronymus [] has joined #openttd
17:25<@Terkhen>good night
17:25<TrueBrain>haha; very true, I can also be very short :P
17:26-!-MagisterQuis1 [] has joined #openttd
17:27<Hyronymus>TrueBrain, planetmaker and Yexo
17:27<Hyronymus>can we join a private channel
17:27<TrueBrain>do you know how to use IRC? :P :D
17:27<Hyronymus>yes, I do
17:27<Hyronymus>want to share some stuff with you guys
17:27<TrueBrain>take the invite :)
17:27<@Yexo>make a channel and send some invites
17:28<TrueBrain>Yexo: I just invited him to dev channel :P
17:28<@Yexo>fine :)
17:28<TrueBrain>but he doesnt have auto-join-on-invite :P
17:30<__ln__>makes me curious what's so secret it needs a private channel
17:31<Chris_Booth>one can only speculate __ln__
17:31<xQR>i smell conspiracy
17:32-!-MagisterQuis [] has quit [Ping timeout: 480 seconds]
17:33<Chris_Booth>i smell burning
17:37-!-FLHerne [] has quit [Remote host closed the connection]
17:38-!-FLHerne [] has joined #openttd
17:42-!-KritiK [~Maxim@] has quit [Quit: Leaving]
17:43-!-Brianetta [] has quit [Quit: Tschüß]
17:48<TrueBrain>lol; curious people :P
17:54<FLHerne>So what is it? :P
17:55<@Yexo>a conspiracy of course!
17:57<frosch123>something about replacing the forums' captcha with some ottd applet. e.g. fix the signalling of this junction to proceed
17:57<FLHerne>Ooh, underground building at last :-)
17:57<FLHerne>Or NewGRF penguins?
18:02<@planetmaker>NewGRF ice bears meet NewGRF penguin
18:02<TrueBrain>hmm ... penguins
18:02<TrueBrain>"does this count as annoying?!"
18:03<@DorpsGek>/me is bored
18:03<TrueBrain>DorpsGek: again?!
18:03<TrueBrain>and use action
18:03<TrueBrain>not say
18:03<supermop>frosch123: that would be great for AI development, as suddenly there is an incentive for spambots to intelligently signal junctions
18:03<@Yexo>you must be really bored now ;p
18:03<supermop>thus we co-opt all the effort of the malicious coding industry to improve our game
18:04<TrueBrain>haha, lol @ who used DorpsGek, I did not expect you to say that :)
18:04<TrueBrain>that is, you are not my usual suspect :P
18:08-!-KouDy [~KouDy@] has quit [Quit: Leaving.]
18:19-!-Snail_ [] has joined #openttd
18:31-!-Alberth [] has left #openttd []
18:35-!-TGYoshi [~TGYoshi@] has quit [Quit: Popidopidopido]
18:41-!-FLHerne [] has left #openttd []
18:42-!-FLHerne [] has joined #openttd
18:48-!-Chris_Booth [] has quit [Quit: ChatZilla 0.9.88 [Firefox 10.0/20120104111456]]
18:51-!-Progman [] has quit [Remote host closed the connection]
18:56-!-Hyronymus [] has quit [Remote host closed the connection]
18:57-!-FLHerne [] has left #openttd []
18:57-!-fjb|tab is now known as Guest23287
18:57-!-Guest23287 [] has quit [Read error: Connection reset by peer]
18:57-!-fjb|tab [] has joined #openttd
18:57-!-Zuu [] has quit [Ping timeout: 480 seconds]
19:02-!-supermop [] has quit [Quit: supermop]
19:07-!-Rezt [] has joined #openttd
19:12-!-Devroush [] has quit []
19:14-!-Illegal_Alien [] has joined #openttd
19:18<Eddi|zuHause>so... did $someone profile nml yet?
19:20-!-Rezt [] has quit [Quit: Textual IRC Client:]
19:22<@Yexo>a big part of the time is spend in compressing real sprites
19:24<frosch123>like > 50%
19:26<Eddi|zuHause>we need nmlcache :p
19:26<Eddi|zuHause>at least the realsprites, which don't change 99% of the time...
19:28<Eddi|zuHause>and grfcodec can compress the sprites in 2 seconds...
19:29<Eddi|zuHause>> time grfcodec -e -p1 cets.grf
19:29<Eddi|zuHause>Sprite80646 Done: 99% Compressed: 39% (Transparency:100%, Redundancy: 35%)
19:29<Eddi|zuHause>user 0m2.086s
19:30-!-MJP [] has quit [Ping timeout: 480 seconds]
19:30<welshdragon>is down?
19:31<Rubidium>welshdragon: no
19:31-!-Snail_ [] has quit [Ping timeout: 480 seconds]
19:31<Eddi|zuHause>can we do nfo-output and pipe that through grfcodec?
19:31<@Yexo>Eddi|zuHause: sure
19:31<@Yexo>you'll get a slightly worse compression
19:34-!-Brianetta [] has joined #openttd
19:37<Eddi|zuHause>still not really fast
19:38<@Yexo>I know
19:38<@Yexo>haven't found a good way to profile nml though, so it's been hard to figure out where the slowness comes from
19:39<welshdragon>can Giant Screenshot be disabled? I've just killed my map I've been working on
19:39<Eddi|zuHause>just waaaaait... :)
19:40<Eddi|zuHause>we could make a confirmation box like when selling all vehicles and stuff
19:40<welshdragon>why does it kill OpenTTD
19:41<Eddi|zuHause>no, it just locks up until it's done
19:41<Eddi|zuHause>(maybe it can be threaded?)
19:42<+michi_cc>Eddi|zuHause: Out of interest, what's the reason to have all track sets as separate entries in the CETS RTT instead of using the fallback mechanism?
19:42<welshdragon>so it could be hours before it's completed? :(
19:43-!-vodka [] has joined #openttd
19:43<Eddi|zuHause>michi_cc: it felt easier to generate this way
19:44<Eddi|zuHause>michi_cc: i mean composing the tracktypeXY identifiers
19:45<Eddi|zuHause>michi_cc: it could probably compressed somewhat with using #defines
19:45<Rubidium>Eddi|zuHause: it'd be pretty difficult to do that as you'd be calling the drawing methods from two threads which might easily cause artefacts
19:46<Rubidium>and then I'm talking about the 'easy' case where you use a bootstrap-esque window to show the progress, i.e. without a background of vehicles
19:46<Eddi|zuHause>Rubidium: hm, so the drawing functions need to get de-globalised?
19:47<Rubidium>Eddi|zuHause: that, and sprite loading, possibly blitting
19:47<+michi_cc>Where's the difference between using "tracktype_certs%s%s%s :\n'%(track_type[1], track_type[0], track_type[4])" or "tracktype_dbrails%s%s%s :\n'%(track_type[2], track_type[0], track_type[4]))" instead of having whatever tracktype_certs??? evaluates to have the matching tracktype_dbrails??? has fallback?
19:47-!-DOUK [] has joined #openttd
19:47<+michi_cc>Then you wouldn't need all that runtime querying for each engine.
19:48<Eddi|zuHause>michi_cc: the nutrack railtypes are kinda orthogonal to that, so it won't work for them
19:49-!-Snail_ [] has joined #openttd
19:50<Eddi|zuHause>there's not much "runtime querying". the track set is calculated once and stored in a parameter, the railtype property is calculated once during the loading stage for each engine, the only "runtime" decision is checking the parameter in CB23 (purchase list text)
19:50<+michi_cc>Okay, you're right with that. Still, the DBrails case could be done with RTT fallback.
19:51<Eddi|zuHause>michi_cc: yes, but then i lose the ability to display dbrails-specific text
19:51<Eddi|zuHause>which is kind of a micro-feature, but i see no harm in that
19:51<+michi_cc>Do we really need that? Maybe mb will also adapt the proposed TC** scheme :p
19:52<Eddi|zuHause>one has hopes and dreams, right? :p
19:52<Rubidium>will he release?
19:52-!-mahmoud [] has quit [Ping timeout: 480 seconds]
19:52<Eddi|zuHause>he has the 12.12.12 left :)
19:55<+michi_cc>One interesting (vapour) feature is the variable loading weight of wagons depending on track class (if it really will be in 0.9, that is). I don't really know how to sanely handle a wagon driving from heavy track to light track though, otherwise it would be quite nice to have.
19:56<Eddi|zuHause>i think he said he won't implement that
19:57<Eddi|zuHause>i'm still thinking of a way to sanely implement that in CETS
19:58<Eddi|zuHause>my idea was providing one wagon each with light/medium/heavy load, and even empty wagons can only run on the high track class. alternative would be to severely limit speed if overloaded
19:59<+michi_cc>Either a big running cost penalty or better a speed penalty. The only problem with that is that ideally YAPF would know that and apply penalties for too light track.
19:59<Eddi|zuHause>i don't see how to sanely do that
20:00-!-frosch123 [] has quit [Remote host closed the connection]
20:00<Eddi|zuHause>need a tracktype penalty callback
20:00<Snail_>is it possible at all? I think we can't change the vehicles' speed according to the railtype they're traveling on
20:01<Eddi|zuHause>Snail_: speed limit can be adjusted with cb36
20:01<+michi_cc>Maybe do the light/medium/heavy load via (auto-)refit, but that would require CB changeable track type.
20:01<Snail_>coz speed, unlike TE, is cached so it can be changed only at certain times (depot visit, stop at station, etc)
20:01<+michi_cc>Snail_: CB36 for speed will be called if the vehicle enters a tile with a new railtype.
20:01<Eddi|zuHause>Snail_: i think railtype change is such a time
20:02<Snail_>well, I tried to do a test about this
20:02<Snail_>I tried to change the speed through property depending on the railtype
20:02<Snail_>and my engines didn't change speed when crossing a different railtype tile.. they only changed it after reversing, depot visit etc
20:03<Eddi|zuHause>a test grf for that case would be nice
20:04<Snail_>I could make one, but that would work with my new tracks...
20:05<Snail_>anyway I talked to MB about this and he told me that speed is cached, and entering new railtype tile doesn't enforce it to be reset
20:05<Snail_>unlike TE (with TE, this works well)
20:05<+michi_cc>Snail_: Looking at the source code I see that this is done when the lead engine enters the new railtype, so you have to query the railtype if the engine via parent scope and not use the current vehicle.
20:06<Snail_>but what if I code this for the engine itself?
20:06<Snail_>I coded my engines so that their speed would be limited if they entered rackrail tracks, but it didn't work
20:07<+michi_cc>Hmm, but doing it for the wagon should still work, the whole chain is updated when any part changes railtype.
20:07<+michi_cc>Snail_: OpenTTD source looks correct at first sight to me, so it might be a bug in your test code.
20:08<Snail_>ok, I can provide you with the *.GRF with this
20:08<+michi_cc>Can you paste the apporpriate CB36 source code?
20:08<Snail_>but I also have to include my tracks :p
20:08<Snail_>ok, I'll do it... wait a sec, I'll write it in m4nfo and then translate to NFO
20:09<+michi_cc>Maybe m4nfo has a bug :p
20:12<Snail_>ok, I can paste the code that (1) checks for the railtype, (2) limits the speed if the railtype is of a certain type, and (3) sets this property for the engine's callback
20:12<Snail_>/ Test for rackrail: limit speed
20:12<Snail_>11364 * 0 02 00 03 81 4A 00 FF 01
20:12<Snail_> 0a 80 07 07
20:12<Snail_> 00 00
20:12<Snail_>/ properties
20:12<Snail_> 11365 * 0 02 00 04 81 10 00 FF 03
20:12<Snail_> 02 00 1f 1f
20:12<Snail_> 03 00 09 09
20:12<Snail_> 00 80 14 14
20:12<Snail_> 00 00
20:12<Snail_>/ End of test for rackrail
20:12<Snail_>/ callbacks
20:12<Snail_> 11366 * 0 02 00 13 85 0C 00 FF FF 02
20:12<Snail_>/ ref(1) if(CB_TSFX) // text
20:12<Snail_> 04 00 36 00 36 00 // no capacity
20:12<Snail_> cf 00 2d 00 2d 00 // switch lights
20:12<Snail_> 00 00 // graphics
20:12<Eddi|zuHause>don't paste in IRC
20:12<+glx>use a paste service
20:13<Snail_>is this ok?
20:13<Snail_>sorry, I'm not much of an IRC expert :)
20:14<Snail_>the line I commented as "no capacity" in the end is the one that collects the property reducing speed when on rackrail tracks
20:16<@Yexo>can you also show us your railtype table?
20:17<Eddi|zuHause>is the engine already on the new tile when the callback is run?
20:17<@Yexo>to test that send the vehicle to a rackrail depot and out again, the callback is run again in that case and it must be onthe rackrail railtype
20:18<Eddi|zuHause>he said earlier that it worked in depot etc.
20:19<@Yexo>aha, I had missed that
20:19<Snail_>Yexo: yes, the railtype for rack is called NRAN ( {N}arrow gauge, {R}ackrail speed, axle weight {A}, {N}o electrification )
20:19<Snail_>yes, when it gets out of a depot it works
20:20<Snail_>but if I buy it in a non-rackrail depot and start it, and send it on a track that is non-rackrail until a certain point, and rackrail beyond that point, the engine won't slow down when hitting the first rackrail tile
20:20<Eddi|zuHause>what if you have a track like <normal><rackrail><normal>?
20:20<Snail_>mind you, when it reaches the end of the track (which is a rackrail tile) and reverses to come back, the slower speed limit is enforced
20:21<Snail_>Eddi|zuHause: in that case, it will go through the rackrail part at the normal speed, then it reaches the normal track again, and continues with the same speed
20:23<Eddi|zuHause>but, TE should be cached the same way as speed, or not?
20:24<Snail_>I don't think so. I'm no expert, but I asked MB and he told me it's not the case
20:24<Snail_>TE is not cached, but always computed
20:25<@Yexo><michi_cc> Snail_: OpenTTD source looks correct at first sight to me, so it might be a bug in your test code. <- can you give me a pointer?
20:25<@Yexo>I can't find the right code
20:25<@Yexo>speed is updated by Train::ConsistChanged, but that doesn't seem to be called (not even indirectly) when entering a new tile
20:26<Snail_>Yexo: ok, do you need all the NFO that codes the engine I'm testing this on?
20:26<Eddi|zuHause>Yexo: i'd search for the compatible/powered calculation
20:26<@Yexo>Snail_: no, I just wanted to have a quick look at the openttd code
20:27<+michi_cc>Yexo: I think you're right. It updates the max track speed, but not the vehicle speed.
20:27-!-dotwaffle [] has quit [Quit: Farting around]
20:27<Eddi|zuHause>void Train::RailtypeChanged() <-- i think it should be added there
20:28<Eddi|zuHause>there's only this->PowerChanged();
20:28<@Yexo>it might actually be intentional that it doesn't work for speed
20:28<+michi_cc>I guess we should call ConsistChange insead of PowerChange then.
20:28<@Yexo>if speed was set to 0 on a new railtype, things would break pretty badly
20:29<Eddi|zuHause>Yexo: speed is clamped to 1
20:29<Eddi|zuHause>or, should be :p
20:29<@Yexo>^^ probably that :p
20:29<Snail_>perhaps it's like this not to be too much CPU-intensive? otherwise, if it were always recomputed, there would be *lots* of recalculations all the time... i.e. whenever any train enters a new tile...
20:30-!-valhallasw [~valhallas@] has quit [Quit: leaving]
20:30<@Yexo>it only has to recalculate if a vehicle enters a new tile with another rail type
20:30<Eddi|zuHause>Snail_: no, only when entering a new railtype
20:30<Eddi|zuHause>Snail_: and at that point, lots of other things need calculation anyway, so the effect won't be that big
20:30<Snail_>oh, ok
20:31<@Yexo>good night
20:31<Eddi|zuHause>michi_cc: does ConsistChanged do anything that is dangerous outside a depot?
20:31<+michi_cc>Yexo: From looking at blame output the power changed is basically a remains from the elrails merge. It was always just PowerChanged from then on.
20:32<+michi_cc>Eddi|zuHause: Yes, but it has a parameter to error for length changed.
20:32<Eddi|zuHause>so it was just forgotten in railtypes...
20:32<@Yexo>not perse, IIRC the "current railtype var" was a later addition
20:33<@Yexo>before that addition there was no use for redoing the speed callback
20:33-!-dotwaffle [] has joined #openttd
20:34<+michi_cc>Yes, but I think ConsistChanged can be used for that. It's also called when reversing for example, so I guess nothing would break.
20:34<@Yexo>@commit 20165
20:34<@DorpsGek>Yexo: Commit by michi_cc :: r20165 /trunk/src (newgrf_engine.cpp newgrf_railtype.cpp) (2010-07-16 19:02:59 UTC)
20:34<@DorpsGek>Yexo: -Feature: [NewGRF] Information (var 4A) about the current railtype a train is on.
20:35<@Yexo>michi_cc: I guess you're right
20:35<Eddi|zuHause>issue solved. moving on :)
20:35<@Yexo>18 months and only now the first bug report
20:35<Snail_>you me
20:36<Snail_>you mean it will be solved in the next nightly?
20:36<Eddi|zuHause>it's not commited yet
20:36<@Yexo>not by me, I'm really off to bed now
20:36<Snail_>Yexo: good night :)
20:36<Eddi|zuHause>but "there exists a solution" is already enough for me :)
20:38<Snail_>ok, so I'll be on the lookout for a nightly that solves this ;)
20:38<+michi_cc>The only thing I'm a bit skeptical about is that ConsistChanged also updates the cargo capacity. But nobody complained yet about trains changing capacity on reversing, so I guess that's okay :)
20:39<Eddi|zuHause>does it throw away the surplus cargo?
20:40<Eddi|zuHause>anyone fancy implementing ctrl+flip for articulated vehicles? :)
20:40<Snail_>michi_cc: meaning that, if you code wagons with different capacities across different railtypes, they might lose cargo if mving from heavy tracks to light tracks/
20:40<Snail_>Eddi|zuHause: it might be cool, but only for certain vehicles
20:41<Eddi|zuHause>Snail_: that's probably a very silly idea to change capacity :p
20:41<Snail_>i.e. it would be great for certain MUs, not for steamers with tenders ;)
20:41<Eddi|zuHause>Snail_: well, the newgrf controls which vehicles can be flipped
20:41<Eddi|zuHause>Snail_: and some steamers were designed to run equally fast in both directions. like BR 50
20:42<Eddi|zuHause>BR 50 was a "light" engine for branch line use, and generally too large for many turntables
20:42<+michi_cc>Eddi|zuHause: It doesn't, but like I said, you could already mess with it on reversing, which is why I'm not that worried.
20:43<+michi_cc>In theory the speed update could be split, but then there's simply some other property than isn't updated but should.
20:44<Eddi|zuHause>yeah, should probably just tell the newgrf coders "better not change <XYZ> outside depot"
20:44<Elukka>some steamers also ran on push-pull trains which made reverse speed pretty important
20:44<Snail_>Eddi|zuHause: then I'd like articulated vehicles to be flippable. In fact one of my DMUs would benefit from this :D
20:45<Eddi|zuHause>Elukka: those are usually ones that have builtin tenders
20:46-!-dotwaffle [] has quit [Quit: WeeChat 0.3.6]
20:46-!-dotwaffle [] has joined #openttd
20:49<Snail_>yep those were the tank engines. They can be flippable already
20:49<Elukka>assuming i understand the term 'wendezug' right and they're titled correctly...
20:49<Eddi|zuHause>Snail_: well, not mine :p
20:50-!-namad8 [] has joined #openttd
20:50<Elukka>well, that br 23 certainly seems to be pushing judging from the smoke
20:50<Eddi|zuHause>Elukka: that was already very late, 1960s or so
20:51<appe_>so tired.
20:51<appe_>zup guys.
20:51<Eddi|zuHause>Elukka: and the P8 has a "wannentender" from the war-time BR 52 (which is derived from the above mentioned BR 50)
20:52<Elukka>yeah, the tender really doesn't fit it :P
20:52<Elukka>(visually i mean)
20:55<Eddi|zuHause>well, DB quickly scrapped the inferior-material 52's, but reused the tenders elsewhere
20:56-!-namad7 [] has quit [Ping timeout: 480 seconds]
20:56<Eddi|zuHause>DR, however, used them quite long, because they couldn't get replacements
20:57-!-JVassie [~James@] has quit [Ping timeout: 480 seconds]
20:57<Elukka>i think it's one of the prettier steamers, particularly with the original tender
20:58-!-namad8 [] has quit []
20:58-!-fjb|tab [] has quit [Read error: Connection reset by peer]
20:58-!-fjb|tab [] has joined #openttd
20:58-!-pugi [] has quit [Ping timeout: 480 seconds]
20:59-!-pugi [] has joined #openttd
21:02-!-namad7 [] has joined #openttd
21:02-!-pugi [] has quit []
21:08<Eddi|zuHause>Elukka: anyway what i meant to say, the tender is already specially crafted for backwards travel
21:08<Eddi|zuHause>where "fast" is like 90km/h
21:09<Eddi|zuHause>which is "ok" for a generic passenger train
21:10<Eddi|zuHause>a P8 with original tender wouldn't be able to go that fast backwards
21:10<Elukka>i've heard that, but what feature of a tender enables a locomotive to go fast backwards?
21:12<Eddi|zuHause>i guess the connection to the engine. and the BR 50/52 tenders had a wind shield on the sides
21:14<Eddi|zuHause>the engine-tender connection is usually made in a way so the tender pulls down the engine (to get more adhesive weight). while going backwards, the engine may not push up the tender
21:14<Eddi|zuHause>otherwise it might jump off the tracks
21:14<Elukka>hmm. makes sense
21:15-!-Snail_ [] has quit [Quit: Snail_]
21:15<Eddi|zuHause>this is not a design goal if you're only going 40km/h backwards
21:17<Eddi|zuHause>a related issue is getting steering cars for express trains like modern IC or the ICE2
21:18<Eddi|zuHause>to this day the ICE2 may not go top speed with steering car in front when there are high winds
21:22-!-Snail_ [] has joined #openttd
22:06<Wolf01>'night all
22:06-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
22:12-!-fonsinchen [] has joined #openttd
22:23-!-vodka [] has quit [Quit: Leaving]
22:25-!-fonsinchen [] has quit [Remote host closed the connection]
22:29-!-MagisterQuis [] has joined #openttd
22:35-!-MagisterQuis1 [] has quit [Ping timeout: 480 seconds]
22:42-!-Brianetta [] has quit [Quit: Tschüß]
23:00-!-TomyLobo [] has quit [Quit: Standby mode...]
23:25-!-DOUK [] has quit [Ping timeout: 480 seconds]
---Logclosed Sun Jan 08 00:00:04 2012