IRC logs for #openttd on OFTC at 2011-03-20
⏴ go to previous day
00:03:17 *** windstrider has joined #openttd
00:19:44 *** DoubleYou has joined #openttd
00:42:22 *** roboboy has joined #openttd
00:59:07 *** DanMacK has joined #openttd
01:03:20 * DanMacK looks at the forums and notices a crapload of bot/i mean people turning 33
01:19:12 *** tokai|mdlx has joined #openttd
01:26:32 *** JOHNSHEPARD has joined #openttd
02:27:38 *** supermop has joined #openttd
02:44:17 *** DoubleYou has joined #openttd
03:18:15 *** Catarinense has joined #openttd
03:18:55 <Catarinense> Hey there, my computer crashes when I run openttd
03:20:19 <Catarinense> I'm using 1.1.0-RC3
03:20:19 <Catarinense> right now but it also crashes when using 1.0.5
03:21:21 <Catarinense> would anyone please help me or tell me where can I find help?
03:23:01 <Eddi|zuHause> we can only help when openttd itself crashes. any other crashes are out of our reach
03:24:55 <Catarinense> well, computer crashes some seconds after I run openttd. I guess it happens because of opentdd
03:25:16 <Eddi|zuHause> what are the symptoms of this crash?
03:25:51 <Catarinense> the screen freezes and i need to restart it manually
03:26:23 <Eddi|zuHause> could be a bug in your graphics driver, or a heat problem of your computer
03:27:29 <Catarinense> I'm gonna check this
05:04:42 *** fjb is now known as Guest1465
05:56:19 *** Eddi|zuHause has joined #openttd
06:14:16 *** HerzogDeXtEr1 has joined #openttd
06:16:24 <supermop> hmm just had a crash
06:37:00 *** andythenorth has joined #openttd
06:51:57 *** sla_ro|master has joined #openttd
07:46:28 *** Kurimus has joined #openttd
08:54:22 *** Alberth has joined #openttd
08:54:22 *** ChanServ sets mode: +o Alberth
09:03:38 * planetmaker likes the "evil.grf" ;-)
09:05:22 <planetmaker> it only disables 12 other grfs, changes all default and road vehicle traction types and the size of default houses :-P
09:05:39 <planetmaker> s/default/default rail/
09:11:07 <Alberth> any newgrf that messes with other data than its own should be disabled
09:14:13 <andythenorth> any suggestions for how to fix this?
09:14:24 <andythenorth> I could check slope data, but rivers can also be on slopes....
09:14:30 <andythenorth> so currently I'm stumped
09:15:13 <Rubidium> Alberth: point is that NewGRFs can detect other NewGRFs and disable themselves, or disable others due to incompatability issues
09:15:13 <planetmaker> Alberth: yes, I agree
09:15:28 *** CrashPL has joined #openttd
09:15:37 <planetmaker> but it's not that easy. They can modify common data chunks - which is the same as disabling others in effect
09:17:20 <Rubidium> not to mention some NewGRF deliberately needing to override others, e.g. "DBsetxl ECS extension pack"
09:17:22 <Alberth> Rubidium: yes they can, and it is making it quite impossible to ever get a sane addition mechanism
09:18:24 <Alberth> so perhaps they should explicit state dependencies or so?
09:18:31 <Rubidium> you could consider industry/house type pools so you can load multiple sets, but those are inherently incompatible
09:19:17 <Alberth> having several types of industry or houses makes little sense imho
09:19:28 <planetmaker> Alberth: why not?
09:19:32 <andythenorth> they're still coupled by cargos for one thing
09:19:41 <Rubidium> thus disabling itself when detecting others isn't that bad
09:19:43 <planetmaker> two industry sets which provide different chains
09:19:53 <andythenorth> but cargos aren't pooled...
09:20:02 <planetmaker> two house sets for, say different eras, regions or whatever
09:20:18 <Alberth> planetmaker: good points :)
09:20:18 <andythenorth> house / town pool *does* make sense in gameplay
09:20:23 <andythenorth> dunno about the implementation :P
09:20:56 <Alberth> andythenorth: that should be fixable, eventually :)
09:21:29 <andythenorth> ^ this is the varact 2 for north tile of fishing harbour
09:21:40 <andythenorth> I didn't write it, so don't know exactly what it does
09:21:48 <andythenorth> think it checks for water + slope
09:22:42 <andythenorth> is it by design or accident that rivers are treated as slope?
09:23:01 <andythenorth> slope / coast /s
09:24:49 <andythenorth> issue also applies to canals :(
09:26:33 <planetmaker> same could be with pools for industry tiles, industries and similar. Possibly
09:26:38 <Rubidium> so it checks for "!ocean" instead of "coast"?
09:28:12 <andythenorth> Rubidium: I'm not sure what the check is
09:28:20 <andythenorth> peter wrote it for me ;)
09:31:57 *** amkoroew has joined #openttd
09:41:04 *** Cybertinus has joined #openttd
09:42:56 <andythenorth> I've checked with crtl-b, the bounding boxes *look* ok
09:43:12 <andythenorth> the count of unsolvable FIRS is...not good
09:49:00 <planetmaker> andythenorth: there are bugs and bugs ;-)
09:51:49 <andythenorth> this one is troubling
09:51:54 <andythenorth> I can't replicate it
09:51:58 <andythenorth> and it's quite serious
09:54:18 <planetmaker> hm, I played around with that the other day, too...
09:55:15 <planetmaker> I also had trouble exactly replicating it. But maybe I was too unpatient.
09:55:31 <andythenorth> if the bug count increases sufficiently, can I stop supporting the openttd platform for FIRS?? :P
09:55:42 <planetmaker> mind that with a new game you need to run it for several game years (like > 5 or so)
09:56:12 <planetmaker> openttd stops to support the firs platform? :-P
09:56:41 <andythenorth> testing time-dependent industry stuff is effectively impossible in the time I have
09:56:59 <andythenorth> I could do with a set of openttd instances somewhere else, logging
09:57:18 <andythenorth> similar to server games...
09:57:57 <planetmaker> andythenorth: when it comes to checking closure things: Just setup very simple test games. And leave your computer run over night.
09:58:07 <planetmaker> save the next morning and evaluate later
09:59:20 <planetmaker> For 'no closure' it should have not fewer industries than before
10:01:39 *** Dreamxtreme has joined #openttd
10:02:05 * Alberth ponders a newgrf test environment
10:03:15 <Alberth> hmm, order of calls matters probably, very tricky to keep in sync with the real program
10:03:22 *** Progman has joined #openttd
10:05:40 <andythenorth> a test environment would be better
10:05:47 <andythenorth> or something deterministic at least
10:06:12 <andythenorth> even a long running test game is no guarantee of correctness when random production cb or random varact 2 are being used
10:07:37 <andythenorth> I'm not sure if that's solvable
10:37:19 *** ZirconiumX has joined #openttd
10:38:11 * ZirconiumX isn't sure what to make of the 'news'
10:39:00 <ZirconiumX> It would appear that the guy who has stabbed me has striked/struck(delete where appropriate) again
10:40:50 <ZirconiumX> My friends - who live down the road - reported to me yesterday that the guy slashed a ginger haired kid (why do people pick on ginger kids?) - and a black haired kid (lots of detail(!))
10:46:05 * ZirconiumX is annoyed about Libya
10:54:26 *** ZirconiumX has joined #openttd
11:00:31 *** andythenorth_ has joined #openttd
11:08:52 *** frosch123 has joined #openttd
11:14:37 <andythenorth_> opinions on town industries for FIRS....
11:14:49 <andythenorth_> should petrol station accept food + goods (it does currently)
11:16:26 <andythenorth_> should there be some kind of 'entertainment' industry (like hotel, restaurant), accepts food + alcohol
11:16:53 <andythenorth_> could be built in town, out of town, or on water (restaurant boat)
11:17:22 <planetmaker> only on water within town ;-)
11:17:30 <andythenorth_> and next to land
11:17:35 <planetmaker> that'd make it a rare thing - but highly desired. As easter egg
11:17:49 <andythenorth_> would it be valid / fun to allow petrol station to build anywhere, but it must be next to road?
11:18:13 <planetmaker> should. But... don't bother. They'll nearly invariably be built near road
11:18:26 <planetmaker> except if you use a 1x1 station in a 3x3 grid
11:18:34 <andythenorth_> I was thinking of petrol station out in the middle of nowhere
11:19:50 *** Biolunar has joined #openttd
11:20:34 <planetmaker> oh. I thought of them being in town. But indeed... in the middle of nowhere makes much sense and will be even more fun than only towns
11:20:58 <andythenorth_> I'll consider it
11:21:14 <andythenorth_> it should be quite rate
11:21:52 <planetmaker> landscape class two
11:22:00 <planetmaker> and no need to be too rare
11:22:09 <planetmaker> most roads will anyway be near towns
11:22:45 <planetmaker> just don't care about over-building of houses, just do it, if the location fits, but don't worry, if they're not over-build
11:28:00 *** KenjiE20 has joined #openttd
11:37:38 *** devilsadvocate_ has quit IRC
11:38:06 *** devilsadvocate has joined #openttd
11:41:40 *** Devroush has joined #openttd
12:30:31 *** andythenorth_ has left #openttd
13:19:49 <wito> If I wanted to switch around the model lifes of two wagons in a train set newGRF; how would I go about doing that?
13:24:39 *** Aylomen has joined #openttd
13:27:13 <frosch123> wito: either modify the newgrf, or code an addition-newgrf
13:28:22 <wito> The latter part seems simpler somehow
13:29:10 *** fonsinchen has joined #openttd
13:29:12 <frosch123> it is at least easier wrt. licenses and compatiblitiy
13:30:21 <frosch123> anyway, for the addition-newgrf: you need to know the grfid of the original grf, and the grf-local engine id of the vehicle
13:31:11 <frosch123> depending on your knowledge of nfo or the availability of the source of the original grf, you might extract that from the source, or you might use grf2html to figure out the engine id
13:31:49 <wito> I assume I can use grf2html to figure out the grfid as well?
13:32:24 <frosch123> yes, but that is also shown by ottd in game
13:40:29 <wito> grf2html is giving me a No such file or directory error
13:41:00 <wito> or rather, bash is when trying to run it
13:41:10 <frosch123> if you are using windows, then just drag&drop the .grf file onto grf2html.exe in the explorer
13:42:41 <wito> but booting up my virtual machine might on balance be simpler
13:42:56 <Alberth> so grf2html is not in your search path
13:43:28 <Alberth> sure it is bash that complains?
13:43:32 <wito> PATH=$PATH:$HOME/bin := -bash: /home/wito/bin/grf2html: No such file or directory
13:43:32 <frosch123> then just run "./grf2html path/to/newgrf.grf"
13:44:05 <wito> wito@totland:~$ ls /home/wito/bin/grf2html
13:44:43 <wito> -rwxr-xr-x 1 wito wito 924080 2010-05-02 19:58 bin/grf2html
13:45:42 <Alberth> ldd bin/grf2html does not give missing libraries ?
13:46:14 <wito> ldd is trying to tell me that it's not a dynamic executable.
13:46:18 <wito> which is just plain wrong.
13:46:43 <Alberth> depends on how it was compiled
13:47:15 <wito> file is saying that is *is* dynamcially linked, tho'.
13:47:20 <wito> So one of them is wrong, obviously.
13:47:31 <wito> and linux32 is giving me the same message as bash
13:47:35 <wito> No such file or directory
13:47:44 <wito> which is equally not true
13:47:57 <frosch123> maybe redownload :)
13:48:10 <Alberth> mine says "... dynamically linked (uses shared libs) ..."
13:48:30 <wito> but I've booted up my VM
13:48:43 <frosch123> wito: we are all using linux here :)
13:49:19 <wito> well, I could spend all night trying to debug this, or I could just download for windows. ;)
13:49:29 <Alberth> it looks like your system does not know what to do with 32bit executables
13:49:43 <wito> Alberth: Well, that's why I tried running it using linux32
13:49:49 <wito> which worked equally poorly.
13:50:01 <Alberth> yeah, it does not make sense
13:51:30 <wito> anyway; it worked right away on my Win7 x64 VM
13:52:50 <wito> anyway, I have the generated HTML up
13:54:41 <Pikka> are we though, frosch123 ?
13:56:18 <wito> frosch123: So I have the grfid, and the two train ids; where do I go from here?
13:59:18 <frosch123> Pikka: at least everyone involved up to that point
13:59:44 <Pikka> wito, sorry I came in late, what are you trying to do? :)
14:00:00 <wito> trying to make a local fix to the japanese train set
14:00:01 <frosch123> wito: well, first i have to reask whether the "never expire vehicles" advanced setting is enough :p
14:00:23 <wito> frosch123: Did you ask that at any point? ;)
14:00:41 <frosch123> no, but i thought it might be good thing to do nevertheless :)
14:01:40 <wito> settings, schmettings. :P
14:02:04 <frosch123> anyway, for modifying the original grf you could use the grf2html output to find the action 0 which defines the ages, decode the grf, modify that sprite and recode.
14:02:21 <frosch123> for the add-on grf you likely need to code it in plain nfo
14:02:33 <Pikka> or for creating a newgrf, you need an action0generalvariables which tells openttd which grf you want to change, then action 0s which change the vehicles
14:02:43 <frosch123> nml does not support the grfid-overrides afaik
14:03:17 <wito> grfcodec -d $GRF.grf $GRF; grfcodec -e $GRF.grf $GRF should, in theory, produce a file identical to the original, yes?
14:03:58 <frosch123> Pikka: be careful, you are a nfo-liking minority in here :p
14:05:30 <Pikka> yes, I am alone in enjoying tools that can implement more than 20% of the spec.
14:06:27 <frosch123> wito: for the add-on newgrf you would need to read about action 8, action 0 feature 8 property 11, and action 0 feature 00 property 03 or 04
14:06:42 <wito> That's a lot of numbers o.o
14:06:55 <wito> I think I'll just mod the grf; wasn't planning on distrbution at any rate.
14:07:23 <frosch123> Pikka: not quite, nml supports around 60%, and it especialy supports that parts, which no nfo-coder can handle (e.g. grf parameters, action 6 and such)
14:07:42 <frosch123> so, you would be more correct to say, that plain nfo only support 80% of the specs
14:07:54 <Pikka> well I can handle grf parameters in nfo just fine
14:07:56 <frosch123> and 60% is not much less than 80%
14:08:31 <frosch123> depends on what extent :)
14:08:32 <Pikka> and I've never encountered a situation where I've even come close to wanting to use action 6...
14:09:58 <frosch123> the action6 part for example :p
14:10:34 <Pikka> I don't understand what's so hard about that, reading the page
14:10:59 <frosch123> of course it is not hard
14:11:28 <frosch123> who claimed that nfo would be hard?
14:11:52 <Pikka> so in what way can "no nfo-coder handle" it?
14:12:22 <Eddi|zuHause> "hard" != "complex"
14:12:27 <frosch123> nml grf tend to have a lot more parameters than nfo coded grfs, because it is much easier to add some parameter
14:13:51 <Pikka> I can only speak for myself, of course, but my grfs tend to have the parameters they need to have...
14:14:20 <Pikka> I guess industry grfs might feasibly have more...
14:15:04 <Eddi|zuHause> nutracks supposedly has dozens of parameters
14:15:13 <Eddi|zuHause> i haven't used it myself yet
14:23:04 * Rubidium is bored, even by the "nfo { ... }" statement to nml? Then it must be as good as NFO in all cases ;)
14:23:30 * Rubidium is even so bored that he can't be bothered to split thoughts
14:23:54 <frosch123> oh, it has inline-nfo meanwhile?
14:24:12 <Rubidium> don't know, they should just add it
14:24:22 <Rubidium> otherwise my nfo = asm, nml = c analogy won't work
14:28:10 <wito> Anyway, thanks for the help. :)
14:28:17 <wito> Catch you all on the flip side.
14:35:07 <Yexo> <Pikka> and I've never encountered a situation where I've even come close to wanting to use action 6... <- so you've never used GRM
14:36:06 <Pikka> not in a "find available IDs and slot in there" way, no
14:36:28 <Yexo> it's almost essential for a station newgrf
14:36:41 <Yexo> at least if you don't want to duplicate some sprites too much
14:36:43 <Pikka> well, I've never made a station newgrf, so there you go :)
14:37:37 <sllide> how do i run a dedicated server without the use of SDL?
14:37:48 <sllide> it keeps asking for it even tho i'm running it dedicated
14:37:55 <Yexo> did you compile yourself?
14:38:00 <Yexo> if not, you'll have to do so
14:38:52 <Ammler> the problem is not the amount of parameters, more the defaults of it, newgrfs can have dozens of parameters as long as you can use it without
14:39:22 <Ammler> like ukrs(1) has quite silly defaults :-)
14:40:30 <Ammler> well, iirc you need to set 0 3 0 to use it
14:41:14 <sllide> can i use nightly then?
14:41:19 <glx> sllide: precompiled builds require SDL
14:41:50 <sllide> ill have to ask my admin to install some packages then
14:42:18 <Yexo> you could compile a dedicated-only binary on another machine
14:42:52 <Ammler> I have dedicated bins for rpm distros (suse/fedora)
14:45:25 <frosch123> the only other freebsd user here is likely fjb
14:46:49 <sllide> i could just install sdl..
14:46:55 <sllide> iirc we got access to the package manager
14:47:10 <sllide> or does sdl require X?
14:47:18 <frosch123> if you have no environment for compilation, installing sdl might be the easiest
14:48:34 <frosch123> yeah, i doubt there is a precompiled sdl without x requirement
14:48:53 <sllide> wait, i just remembered
14:51:17 *** TrueBrain has joined #openttd
14:52:37 <frosch123> tb: you do not need to enter the channel when the word "admin" is mentioned. it does not necessarily refer to you :p
15:04:38 *** Vikthor has joined #openttd
15:08:16 *** JOHN-SHEPARD_ has joined #openttd
15:14:57 <sllide> any orther games simmilar to openttd
15:15:16 <sllide> focused around money and long games
15:15:16 <__ln__> Transport Tycoon Deluxe
15:20:05 <Eddi|zuHause> is transport empire still alive?
15:20:07 <frosch123> everyone playing transport games either plays openttd or simutrans :)
15:20:17 <Alberth> Eddi|zuHause: was it ever?
15:20:40 <sllide> simutrans has a linux server?
15:20:59 <sllide> i want to host a linux server for a very long game
15:21:05 <frosch123> hmm, but yes, maybe they are not that mulitplayerish
15:21:34 <Eddi|zuHause> long multiplayer games are only sensible with people you know
15:22:22 <Markk> I've played on the same map of Minecraft since august
15:23:06 <sllide> but i'm looking for a game that goes on when your not online
15:23:15 <sllide> like those odd browser games
15:26:15 <Eddi|zuHause> openttd needs too much micromanagement to sensibly let your company run without attention
15:36:59 *** ar3k is now known as ar3kaw
15:52:41 *** _goblin_ has joined #openttd
15:52:50 <sllide> what about some slow paced game involved around fighting/
15:52:54 <sllide> something like tribal wars
15:56:54 *** supermop has joined #openttd
16:02:49 *** Chillosophy has joined #openttd
16:36:47 <fjb> sllide: SDL without X is possible on FreeBSD if you install from the port instead of a precompiled package.
16:39:23 <fjb> But I never tested it. OpenTTD compiles right out of the box on FreeBSD, just use gmake instead of make.
16:47:44 <sllide> i did find something else while waiting
16:51:15 <Eddi|zuHause> wait... multi-player packman? :p
16:56:37 <SmatZ> I want to play as the ghost
16:56:44 <confound> ghosts got nerfed in the last patch
16:57:31 *** windstrider has joined #openttd
17:00:20 <Eddi|zuHause> 18:00... time for prognosis
17:00:56 <Eddi|zuHause> FDP 3.5%, NPD 4.5%... that looks great ;)
17:01:49 <fjb> But NPD 4.5% is still way too much.
17:03:09 <Eddi|zuHause> CDU lost ~3%, Green gained ~3%, FDP lost ~3%, SPD and Left about unchanged
17:03:52 <Eddi|zuHause> current CDU+SPD government likely to continue, but SPD+Linke is also possible
17:04:48 <fjb> SPD + Linke will never happen.
17:04:50 <Eddi|zuHause> FDP goes out of parliament, Green will join after long abstinence
17:05:11 <frosch123> it's east after all
17:05:23 <fjb> Eddi|zuHause: Sure for Sachsen-Anhalt.
17:09:51 <Eddi|zuHause> SPD says "we don't continue the coalition for the coalition's sake, but we want to talk about continuing for content's sake", and wants to talk to both sides. so it isn't so "sure" as you paint it
17:12:22 <fjb> It is the same as 5 years ago.
17:12:41 <Eddi|zuHause> yes, but it is not 5 years ago.
17:13:26 <fjb> SPD is talking left and acting right (political sense, not doing it right).
17:14:12 <Eddi|zuHause> the most likely cause for failing the left coalition will be the question for ministerpresident
17:38:10 *** andythenorth has joined #openttd
17:50:32 *** JOHNSHEPARD has joined #openttd
17:51:07 *** JOHNSHEPARD has joined #openttd
17:52:48 *** Ruudjah has joined #openttd
17:53:54 <Yexo> TrueBrain: the wiki is _very_ slow again
17:55:58 <Rubidium> probably someone is triggering a (php) page that requires an expensive SQL query
17:56:32 <Rubidium> I've tried some tricks to make the php stuff faster, but it only made it slower
17:56:41 <Rubidium> (tricks as in use accelerators)
17:57:06 <Rubidium> no idea why it failed exactly, though it might very well be lack of memory
17:57:44 * avdg wonders if the wiki is using apc or any other caching method
17:57:50 <Yexo> that could even be me. Would it be hard to find out which page(s) is/are problematic?
17:58:12 <Rubidium> Yexo: no clue how to trace that reliably
17:58:30 <Rubidium> avdg: apc made it worse, it uses memcache
18:02:17 <avdg> so there is really nothing that caches the bytecode then?
18:04:40 <Rubidium> not that I'm aware of
18:06:08 *** Chillosophy has joined #openttd
18:14:18 <Ruudjah> Is there a way to let trains behave the same on different signal types when the network is changed?
18:14:57 <Ruudjah> The simple one-way, one-way, two-way signals behave much better compared to the most right signal in the signal toolbox
18:15:30 <Yexo> so just build only those signals?
18:16:01 <Ruudjah> e.g. make single line, put two trains on it, when they almost crash quickly make a double track
18:16:24 <Ruudjah> when train 1 comes back and train2 goes to destination
18:17:04 <Ruudjah> when the double track is in place, if using the signaltype most right of toolbox trains have still a route to the wrong way
18:17:43 <Ruudjah> they will stop when they find signal is for other way, and turnaround instead of just taking the correct track which happens with "classic" signals
18:17:56 <Alberth> yes, they allocate a track, and follow it until the next signal
18:18:11 <Ruudjah> The rightmost signals in toolbox are better because much less clicks
18:18:49 <Yexo> those "rightmost signals" are called "path signals", as opposed to "block signals" which you seem to call "classic signals"
18:19:02 <Alberth> oh no double signal case
18:19:08 <Ruudjah> block vs path then, thanks for definition
18:19:28 <Alberth> but that is just a single click
18:19:38 <Ruudjah> pathsignals only require two types, block signals three types and also require one more click when setting them
18:20:02 <Ruudjah> also a misclick adds two more clicks with blocksignals
18:20:14 <Alberth> you do know you can set them along a whole line as long as it does not branch?
18:20:18 *** ZirconiumX has joined #openttd
18:20:31 <Ruudjah> still blocksignals require more clicks
18:21:10 <Ruudjah> that's the beauty of path signals, make line, add two signals, ctrl+click, done
18:21:18 <Alberth> yeah, somewhat although I never considered that a problem
18:21:22 <Ruudjah> with block you need presignals
18:22:16 <Alberth> depends somewhat on your style of signalling, but possibly yes
18:22:46 <Ruudjah> so, is there a way to let path signals behave same as block signals when changing network?
18:23:26 <Ruudjah> when network changes, the train on path signal track recalcs path anyways
18:23:35 <Ruudjah> it just picks the wrong path
18:23:35 <Alberth> no, they work in a different way, path signals really allocate a track before hand
18:23:51 <Alberth> that's why you can have several trains in the same block
18:23:59 <Ruudjah> but when network changes, they still recalc path
18:24:15 <Ruudjah> the path recalc, i assume, can be different?
18:24:18 <Alberth> if you don't want that, you could temporary switch to block signals
18:24:23 <Yexo> I'm not sure they do, I think they only lose the reservation after the first wrong signal
18:24:46 <Alberth> Ruudjah: but when network changes, they still recalc path <-- they don't until the next signal, or they find a broken path
18:25:10 <Ruudjah> but then there are two paths, why does it always pick the wrong path?
18:25:43 <Ruudjah> because the double track part's "to dest" line was the same as the before-double-track line?
18:25:51 <Alberth> only if you added the 'right' one after it allocated the 'wrong' one.
18:26:00 <Ruudjah> so train coming back only has their path cut off, instead of recalc
18:26:25 <Ruudjah> the path cut off at position where pathsignal resides on the "wrong" track
18:27:03 <Ruudjah> if that's true, the train doesnt recalc path but cuts off old path
18:27:19 <Ruudjah> which makes sense to me
18:28:03 <Ruudjah> "I think they only lose the reservation after the first wrong signal"
18:28:25 <Ruudjah> in other words: they cut off old path at "first wrong signal"
18:28:32 <Alberth> turn on 'show reserved track' in the advanced settings, and see for yourself what track they claim when
18:28:42 <Yexo> sorry for my lack of comments, but I'm still not sure if I understand your problem correctly so I'd rather not add to the confusion
18:28:49 <Ruudjah> and its exactly like we say here
18:29:10 <Ruudjah> Yexo: simple described situation:
18:29:27 <Ruudjah> I start game at coal mine, and pick some power plant
18:29:46 <Ruudjah> make station, add train to load, make single line to station at dropoff station at power plant
18:30:21 <Ruudjah> train1 comes in, generates money for train2, which is bought immediately at load, click --> ignore signals
18:30:27 <Ruudjah> now two trains on one line
18:30:38 <Ruudjah> train2 loads, starts going to power plant
18:30:43 <Alberth> bad idea in general :)
18:30:47 <Rubidium> ignore signals == signal state is forcefully screwed
18:30:50 <Ruudjah> somwhere in the middle, those trains will crash
18:31:24 <Ruudjah> just before that happens, using the 10K you saved you make a double track
18:31:43 <Ruudjah> you add four signals, both at each part of track
18:32:05 <Ruudjah> when using path signals, one train won't pick correct entrance of double track
18:32:33 <Ruudjah> this seemingly depends on _what line in double track is added_
18:32:56 <avdg> the wiki is really slowly :/
18:32:59 <Rubidium> when a train has reserved a path it won't change it, unless you turn it around
18:33:05 <Ruudjah> e.g. add line back, the train coming back wants to enter the go-to line, not the go-back line of the double track
18:33:28 <Ruudjah> blocks signals do not have this problkem
18:33:30 <Rubidium> so it will happily go into the wrong "branch" because it already reserved a path into the wrong branch
18:34:04 <Rubidium> and that's precisely what the path signals are meant to do
18:34:10 <Ruudjah> now, I want to use path signals while maintaining the "block signal" behaviour
18:34:45 <Rubidium> as it might decide to take another path while in the section and go through another reservation or something
18:34:50 <Ruudjah> but at some point, the train "knows" the track became different
18:35:13 <Ruudjah> because the reserved track is changed
18:35:29 <Rubidium> that's because you messed with a signal
18:35:40 <Ruudjah> still, it's reserved path is changed
18:35:59 <Rubidium> because you remove the safe waiting point
18:36:31 <Ruudjah> i dont remove anything
18:36:45 <Ruudjah> I just add a line next to existing line with 4 signals
18:37:00 <Rubidium> ergo: you remove the safe waiting point
18:37:28 <Ruudjah> where was the "dsafe waiting point"?
18:37:43 <Rubidium> at the other station
18:37:50 <Rubidium> (due to ignoring signals)
18:37:59 <Rubidium> or at least as far as it could reserve a path
18:39:02 <Ruudjah> but when I put signals, it )_still_ changes its reserved path
18:39:37 <Ruudjah> at that exact moment, it should be possible to *do something* such that it can allocate the "correct" path?
18:40:10 <Ruudjah> sure it's an edgecase
18:40:20 <Ruudjah> but still feels "buggy"
18:40:28 <Rubidium> an edge case due to ignoring signals, thus not important
18:40:45 <Ruudjah> that's anayzing the situation too lightly
18:40:46 <Rubidium> as such an edge case undoubtedly breaks normal behaviour
18:41:24 <Ruudjah> since there is a part of the track that's now double track, the behaviour caused is not solely the responsibility of the ignore signals
18:42:03 <Rubidium> no, also due to removing safe waiting points (or at least making them inaccessible)
18:42:07 <Ruudjah> the undesired situation is caused by both: the "ignore signals" part, and the "add doubletrack" part
18:43:26 <Rubidium> the problem with ignoring signals is that the vehicles will (likely) share their reserved path, which means unreserving does all kinds of odd stuff
18:43:49 <Rubidium> and likewise does trying to find the "right" train
18:44:01 <Rubidium> as it'll only find one train per reserved path
18:44:49 <Ruudjah> but in above situation, the "ignore signals" state is "gone" when the double track is added
18:45:35 <CIA-1> OpenTTD: translators * r22265 /trunk/src/lang/unfinished/ (basque.txt frisian.txt):
18:45:35 <CIA-1> OpenTTD: -Update from WebTranslator v3.0:
18:45:35 <CIA-1> OpenTTD: basque - 8 changes by Thadah
18:45:35 <CIA-1> OpenTTD: frisian - 71 changes by gjannema
18:45:37 <Rubidium> then it must be achievable when signals are not ignored, and you seem to be reiterating that ignoring signals is an important step
18:46:00 <sllide> is there a chance of new gameplay elements getting made?
18:46:30 <Ruudjah> Rubidium: Indeed, it';s achievable when on signals are ignored
18:46:31 <Rubidium> there's always a chance (or am I too literal?)
18:47:03 <Ruudjah> The path being changed surely is a case which happens almost never, right?
18:47:17 <Ruudjah> usually trains will find a path, then ride it, find next path
18:47:29 <Rubidium> it happens only when messing with the signals
18:47:37 <sllide> i'm looking forward to something new
18:47:43 <Ruudjah> only very rare trains find path, ride it, meanwhile the path changes somehow
18:48:16 <Rubidium> and as always, messing with signals when a train is running in it is not guaranteed to give the right result
18:48:49 <Ruudjah> So the routine fired when the path is changed, under the condition that a "path signal train" uses the path, is very rare and therefore instead of "cutting off" the path, can be changed to "recalc path"?
18:49:25 <Rubidium> neither does the vehicle repathfind when it's running along its reservation due to the exponentional costs O(n^2) of checking whether it's crossing itself or another path
18:49:39 <Ruudjah> (ergo: edge case which implementation for a possible fix won't affect the code of the usual cases)
18:50:43 <Ruudjah> I always had exactly the result I "predicted" when using block signals
18:50:52 <Ruudjah> without any known exception
18:51:36 <Ruudjah> "neither does the vehicle repathfind when it's running along its reservation due to the exponentional costs O(n^2) of checking whether it's crossing itself or another path" --> right, it simply follows reserved track, correct?
18:51:55 *** Adambean has joined #openttd
18:52:26 <Ruudjah> the expensive recalc path operation only is performed under rare circumstances, so the cost should not affect performance
18:52:51 <Rubidium> but if it recalculates paths then, it should under normal circumstances as well
18:53:14 <Ruudjah> under normal circumstances, the track isnt changed
18:53:15 <Alberth> sllide: you tried all the newgrfs already?
18:53:16 <Rubidium> in any case, I won't touch the behaviour of path signals
18:54:11 <Ruudjah> this code is to be found in /yapf, no?
18:54:19 <Eddi|zuHause> Ruudjah: probably not
18:54:27 <Rubidium> sadly enough it already grew way too complex and with way too many edge cases for my taste. Yay for people not liking the simple version...
18:55:11 <Rubidium> though, I guess there are about a dozen or so files that have to do with path signals' behaviour
18:55:37 <Eddi|zuHause> Ruudjah: what Rubidium is trying to say: present a test-savegame where you didn't force a train through signal. only then we can discuss possible solution
18:55:43 <Ruudjah> My coders mantra is: ginourmous amounts of code is fine, presuming it's documented/written such that it's ;learning curve is low.
18:56:19 <Ruudjah> I work with forcnig trains ignoreing signal like 10-20% of time spend in games
18:56:30 <Eddi|zuHause> Ruudjah: that's irrelevant.
18:56:44 <Ruudjah> So, "fixing" this "issue" would be very nice for me
18:57:21 <Rubidium> path signals are inherintly complex, and for all corner cases you'll have to look through the source; it's not documented in one place as that would be out-of-date in any case
18:58:46 <Ruudjah> I like to visualize knowledge in documentation areas, so if there's a way to add images to the code, I can surely put in some cents
18:59:20 <Eddi|zuHause> Ruudjah: i really didn't understand the actual problem, probably because you explained it poorly. but i think what you want is in CmdPlaceSignal (may be called differently) to check whether there is a path reservation, and recalculate path of all trains sharing this path (which is difficult to impossible to find out, if you have forced a train through a signal)
19:00:08 <Ruudjah> that would be a second pointer, thanks
19:00:32 <Ruudjah> does source of openttd contain images at all?
19:00:45 <Eddi|zuHause> only the ones in the docs/ directory
19:01:54 <Ruudjah> right, but is there a way to add images into comments?
19:02:46 <Eddi|zuHause> depends on what image you mean
19:03:38 <Eddi|zuHause> you can add a comment /* see xx.png */ or do you mean some doxygen thing?
19:04:38 <Eddi|zuHause> that i have no idea
19:04:39 <Ruudjah> so ide's/docgen's show
19:11:28 <Alberth> doxygen also generates some images (inheritance thingies iirc)
19:13:07 <Ruudjah> I bloat classes with hard to understand algo's with lots of images
19:13:57 <Ruudjah> sometimes add javascript stuff, completely with animations etc
19:14:35 <Alberth> pretty sure we don't need it that detailed
19:15:19 <Ruudjah> untill you see some of the generated docs ;)
19:15:30 <Ruudjah> lemme see if there's some OSS example i can link to
19:16:25 <Ruudjah> Hm, one fork waiting for psuh to master, other not yet authorized to be made OSS
19:16:53 <Alberth> somebody reading pathfinding code should already understand path finding as concept
19:17:11 <Alberth> but more docs in the details are always welcome
19:17:21 <Ruudjah> and know how to use code editor
19:18:08 <Alberth> you are welcome to explain that too, but it won't be added to openttd docs :p
19:20:02 * andythenorth proposes some kind of algorithm for 'please make it an advanced option'
19:20:08 <andythenorth> a bit like a sine wave perhaps
19:20:29 <andythenorth> first request automatically applies -infinity to the chances of it being implemented
19:21:43 <andythenorth> or something like: chance of implementation = 1 - (1/n^2) where n = number of requests
19:22:01 <andythenorth> and for sufficiently close to n, it's allowed
19:22:14 <andythenorth> every advanced setting should require at least one kitten to die
19:23:17 * andythenorth has stumbled into some 'requests' on fs
19:23:25 * andythenorth will now go away do something useful
19:23:33 <Ruudjah> whats the problem with them?
19:24:23 <Alberth> Ruudjah: we have too many
19:24:51 <andythenorth> variation is bad
19:25:17 <Alberth> andythenorth: wandering around there is dangerous :p you find may all kind of weird things there
19:25:44 <Ruudjah> I just built a complete settings engine. I like settings. Lots of them. User requests -> ok, make patch, add setting
19:26:09 <andythenorth> 'an advanced option' mostly means 'I want to avoid making a decision because I shirk social conflict / lack the taste to decide which of the n options is more crappy'
19:26:21 * andythenorth does not shirk conflict
19:26:31 * andythenorth does not claim taste
19:27:07 <Ruudjah> social conflict because of no setting -> add setting, solved
19:27:48 <andythenorth> well I hope you kill a kitten each time
19:28:05 <Ruudjah> but usually settings are just meta instead of real settings, so it doesnt affect any code.
19:28:49 <Ruudjah> e.g. settings with "allowed" or "can" or "enable" in their name
19:28:55 <Eddi|zuHause> political decisions like adding/removing advanced settings are a matter of loud minorities
19:29:27 <Ruudjah> I don't make em political, i reduce them to technicalities
19:29:28 <Eddi|zuHause> the loudest minority is usually the developers ;)
19:29:52 <Eddi|zuHause> Ruudjah: the technicality is that we tend to have too many settings
19:30:03 <Ruudjah> then you need a settings engine
19:30:19 <Eddi|zuHause> we have a settings engine
19:31:21 <Alberth> a game engine I can understand, but an engine for settings?
19:31:53 <Ruudjah> remove "meta settings code" from classes and put it where they belong
19:32:31 * andythenorth doesn't understand but is intrigued
19:32:44 <Ruudjah> some kind of meta-model for settings instantly implements all the "meta settings
19:32:58 <Ruudjah> so you only need to worry about the settings really affecting code
19:33:06 <Eddi|zuHause> you mean like an ini file which gathers meta-data about settings?
19:34:44 <Ruudjah> an example (YMMV on different codebases) seeing features as first class citizens in the system, and add property "enabled"
19:35:20 <Ruudjah> then there's probably some class initializing them, and ignoring the disabled ones
19:35:34 <Ruudjah> ergo: no code for meta settings stuff
19:36:27 *** Devroush has joined #openttd
19:36:40 <Ruudjah> afaik when last diggin into openttd code, there was no such thing as an abstracted setting/feature
19:41:57 <Ruudjah> Seems like a onesizefitsall class for settings
19:43:31 * Alberth nods, very useful for making an array of these things
19:44:49 <Ruudjah> In another java game impl, I did not care about class bloat (openttd seems very, very concerned about this, so prolly not good idea for ottd), and just made an interface Setting, and then make concrete class for every setting
19:45:29 <perm> so I just went from .7 to the current rc3... when did food change to goods? and did fruit get dropped?
19:45:40 <Ruudjah> then pass factory for UI instantiation
19:46:27 <andythenorth> perm: something sounds quite wrong there
19:46:28 <Ruudjah> in OpenTTD this would result in a concrete class for every setting, and about 20 classes for UI widgets
19:46:46 <Ruudjah> and a few management classes
19:48:30 <andythenorth> those things shouldn't have changed
19:49:43 <Ruudjah> oh, btw, any considerations/plans to switch to git?
19:49:51 <Ruudjah> [for openttd as project]?
19:50:33 <Alberth> there is a git mirror
19:52:14 <Alberth> otherwise, I personally see no further advantage for switching to a distributed VCS
19:53:24 <Alberth> in fact, I find them a nuisance when committing to a common repo
19:53:26 <perm> well, I was playing the goonpack which might have been different than the actual release
19:55:05 <perm> just a custom install put together for goons
19:56:35 <Alberth> anyways, those things should not have changed, so if you can show it by providing a 0.7 save game from the official release, we'd happy to fix it.
19:56:48 <Alberth> just make an issue in the bug tracker
20:08:54 <__ln__> is there a newgrf that adds dragons to the edges of the map?
20:13:24 *** Adambean` has joined #openttd
20:26:52 *** Progman has joined #openttd
20:28:39 *** Progman has joined #openttd
20:29:27 <Rubidium> woohoo... a bug that isn't someone not understanding "it"
20:31:38 <Alberth> a happy exception to the rule :)
20:33:01 <frosch123> hotkey 6 crashes just on click
20:33:06 <Rubidium> all hotkeys for docks it seems
20:33:28 <andythenorth> that explains it :)
20:51:43 <CIA-1> OpenTTD: rubidium * r22266 /trunk/src/dock_gui.cpp: -Fix [FS#4558]: In the scenario editor you could build a ship depot using the hotkeys. Removing that depot causes an assertions to trigger.
20:52:44 <CIA-1> OpenTTD: rubidium * r22267 /trunk/src/lang/lithuanian.txt: -Fix: broken language file...
21:07:44 <sllide> i compiled it to run without sdl
21:07:54 <sllide> but, the new problem is it wont bind to an address
21:08:06 <sllide> the odd thing is if i use netcat on the same port it works just fine
21:08:55 <andythenorth> which is better?
21:09:00 <andythenorth> fruit & veg -> town
21:09:09 <andythenorth> fruit & veg -> pack house -> food -> town
21:10:43 <supermop> i prefer fresh vegtables in real life
21:11:25 <supermop> F & V payment rates decay very fast, but food does not
21:11:46 <supermop> you can deliver local produce to nearby towns,
21:12:07 <supermop> but have to process it to make the journey to faraway places
21:26:38 <Rubidium> sllide: I guess netcat doesn't bind udp
21:28:12 *** andythenorth has left #openttd
21:28:26 <Eddi|zuHause> andythenorth: i guess a (small, but frequent) pack house would be better
21:31:25 <supermop> progress! (sort of...):
21:32:49 <sllide> Rubidium, dont know what it was but recompiling it helped
21:53:48 *** Markavian has joined #openttd
21:54:04 *** guru3_ is now known as guru3
22:09:56 *** JOHNSHEPARD has joined #openttd
22:51:02 *** JOHN-SHEPARD_ has joined #openttd
23:10:41 *** grzywacz has joined #openttd
23:17:37 *** Kurimus has joined #openttd
23:41:02 *** Brianetta has joined #openttd
23:47:52 *** JOHNSHEPARD has joined #openttd
continue to next day ⏵
