IRC logs for #openttd on OFTC at 2008-09-28
⏴ go to previous day
00:26:31 *** Eddi|zuHause2 has joined #openttd
00:27:11 *** Wezz6400_ has joined #openttd
00:28:50 *** Wezz6400 is now known as Guest2000
00:28:50 *** Wezz6400_ is now known as Wezz6400
00:33:19 *** Eddi|zuHause2 has joined #openttd
01:51:23 *** Nite_Owl has joined #openttd
01:58:02 *** Yeggs-coding is now known as Yeggzzz
02:53:10 *** hnsz2002_ has joined #openttd
04:30:29 *** TinoDidriksen has joined #openttd
05:07:40 *** [demi]Xerres has joined #openttd
05:14:37 *** Doorslammer has joined #openttd
06:20:54 *** Singaporekid has joined #openttd
06:44:37 *** Alberth has joined #openttd
07:17:28 *** LordAzamath has joined #openttd
07:27:03 <LordAzamath> is there a way to return which graphics set (obg) is loaded?
07:32:02 <Alberth> ./openttd -d grf=1 reports graphics base sets loaded
07:36:00 <LordAzamath> ok... is there a way in nfo to return which set is loaded :
07:42:25 <Alberth> There is action 07 var 8D, but you probably already knew that, and it existed way before .obg files, so I'd be surprised if that would give you want you want. On the other hand, I know next to nothing about NFO codes, so anything is possible :)
08:03:14 <LordAzamath> peter1138: Will there be a support for this? So if I make a grf, I can support both graphics sets.. Like I would have the the base tiles of either opengfx or orignial
08:03:20 <LordAzamath> for some industries for example
08:48:10 *** Doorslammer has joined #openttd
09:17:31 *** Progman has joined #openttd
09:25:14 *** Wezz6400 has joined #openttd
10:10:10 <fonso> The basic problem in FS#119 is that the "behind" relation between two sprites isn't transitive but the sprite sorter takes it as such. Is that right?
10:12:32 <fonso> The natural solution to this would be assigning an absolute position to every sprite (or BB) instead of a relative one. It should be possible to calculate transitioning the X, Y and Z values into "screen" coordinates. Has that been tried?
10:17:51 <Eddi|zuHause2> i'm not sure if that properly describes the problem
10:19:24 <Eddi|zuHause2> the sprite sorter has nothing to do with the screen coordinates. they are fixed. the problem is, for each screen coordinate, only one pixel can be drawn. so all sprites overlapping this screen coordinate must be sorted, so only the "front" sprite is drawn at that place
10:23:05 <Eddi|zuHause2> .ini files that say which graphic base set is used (dos/win/custom)
10:23:12 <fonso> as I get it, this is done by drawing the "lowest" sprites first and then overdrawing with "higher" sprites. The sorting is the process of defining "low" and "high".
10:24:11 <fonso> screen coordinates are a misleading expression as I don't want only x and y in screen coordinates but more a "depth" coordinate of visibility.
10:24:15 <Alberth> fjb: see also docs/obg_format.txt
10:25:02 <fonso> You have a 3d in-game coordinate system. By coordinate transition you could align two axes with the screen x and y and automatically have the third axis as depth
10:25:30 <fonso> then you could draw the deepest (in absolute numbers) sprites first and the shallowest last.
10:26:12 <fonso> This would get rid of the "behind" relation.
10:26:13 <Eddi|zuHause2> the main problem you have is when bounding boxes overlap
10:26:23 <fjb> I should look into the docs directory more often.
10:26:31 <fonso> You take their centers, like now
10:26:47 <Alberth> fonso: could you explain non-transitivity of 'behind' please?
10:26:50 <fonso> you take their fronts, of course
10:27:06 <fonso> in the concorde example, if I finally got it right:
10:27:31 <Eddi|zuHause2> e.g. when the bounding box of a slope tile, which is like 32x32x8 or something overlaps partially with a bounding box of an engine, which is 16x8x12 or something...
10:27:35 <Alberth> fjb: Watch the SVN modified file lists ;)
10:27:36 <fonso> The fence is in front of the concorde, the foundation is in front of the fence, but the concorde is not behind the foundation
10:29:41 <fonso> You should be able to calculate the front most point of every bounding box in screen coordinates. It can't be that hard.
10:30:47 <fonso> The question is if that's enough.
10:31:00 <Eddi|zuHause2> but does that really suffice? shouldn't you rather calculate the bottom point? e.g. it doesn't matter how high the engine is, all it matters is that it will be drawn on top of the slope?
10:31:46 <Eddi|zuHause2> the question i'd ask in the concorde example is: must the foundation really be in front of the fence?
10:32:14 <Alberth> maybe the foundation should be split?
10:32:24 <fonso> our behind relationship of comparing in game X, Y and Z dictates it.
10:32:45 <fonso> You can surely solve that particular example by modifying the bounding boxes
10:32:53 <fonso> But it won't be a general solution.
10:33:14 <Alberth> I was thinking maybe the z coordinate is enough for sorting (if 2 sprites collide at (x,y) at screen, draw the one with highest z)
10:33:58 <Eddi|zuHause2> Alberth: that sounds horrible, you'd always draw the higher house over the lower house
10:34:30 <fonso> at the moment we only declare an order if all three coordinates indicate "behind"
10:35:07 <fonso> That makes the ordering between fence and foundation indetermined (I think).
10:35:32 <fonso> Well, back to the drawing board. I still haven't gotten it.
10:35:55 <Alberth> Eddi|zuHause2: only if they 'collide' in 2D at the screen, in which case it should be correct, since higher z means further towards the player as far as I can see.
10:37:23 <Alberth> fonso: We should first find a theoretically correct way to draw such a scene, probably down to deciding about single pixels. Once we have that, it should be scaled up to complete sprites (but that may not be possible)
10:37:58 <Eddi|zuHause2> no, it's not that kind of z coordinate... game coordinates are x in / direction, y in \ direction (towards the bottom corner of the screen) and z in ↑ direction
10:41:43 <Alberth> How are sprites defined? along a x or y game axis?, or are they always flat (ie parallel to the screen) despite the appearance? Afaik OpenTTD doesn't do sprite rotation
10:42:18 <fonso> They are either ground sprites (which are flat) or "bounding boxes".
10:42:30 <fonso> Run a game and press CTRL-B to illustrate it.
10:46:48 *** Belugas has joined #openttd
10:46:48 *** ChanServ sets mode: +o Belugas
10:49:20 <fonso> Actually a screen Z coordinate won't help with the concorde. The nose of the concorde is the shallowest point and it's not inside its bounding box.
10:51:26 <fonso> A special rule is needed: Nothing but foundations can be drawn below flat ground sprites. That, however doesn't help with the bridge bug.
10:53:13 *** frosch123 has joined #openttd
10:53:32 *** ChanServ sets mode: +v tokai
10:56:01 <fonso> Perhaps keep the sorting in principle and add a few special rules:
10:56:01 <fonso> 1. Nothing but foundations can be drawn behind plain ground sprites
10:56:01 <fonso> 2. Rails can't be drawn in front of bridges at the same position and direction
10:56:01 <fonso> 3. Train cars can't be drawn behind rails at the same position and direction
10:56:01 <fonso> These rules could be enforced at each position change in the do-loop.
10:58:08 <frosch123> 1. is already enforced by ground sprites being drawn as childsprites of foundations
10:58:38 <fonso> Then I still don't get why the concorde is behind the runway.
10:59:02 <frosch123> first the landscape is put into the parent sprite list
10:59:43 <frosch123> when it comes to a runway tile, a BB for the foundation and a BB for the fence is added
11:00:07 <frosch123> the foundations for the tiles nearer to the player are added later
11:00:25 <frosch123> so the fence BB is initially before the foundations of other tiles
11:00:31 <frosch123> later the plane is added
11:00:38 <frosch123> and is correctly sort before the fence
11:01:07 <fonso> but shouldn't the concorde be behind the fence?
11:01:09 <frosch123> when you set the fence to invisible and there is no similiar object on nearby tiles, the plane glitch does not happen
11:01:53 <frosch123> well, before, after, front, back are ambiguous here, you have to watch and think yourself
11:02:51 <fonso> OK, "in front of" means "drawn later" and "more visible", "behind" means the opposite
11:03:11 <fonso> then what is the relation between fence and foundation?
11:03:42 <frosch123> I need a virtual blackboard ...
11:04:10 <petererer> Netmeeting had one.
11:07:34 <fonso> Whatever. Initially the concorde is (correctly) in front of all ground sprites. That's because of the order the sprites are added to the array. Correct?
11:07:58 <fonso> Then somehow the sorter determines that the concorde should be behind the runway.
11:08:18 <fonso> If we expressly forbid this operation everything should be fine.
11:08:48 <frosch123> ok, consider the runway to consist of tiles A,B,C and D (from back to front)
11:09:13 <fonso> what is back? The right end on screen?
11:09:28 <frosch123> the initial ordering of the sprites is foundation A, fence A, foundation B, fence B, foundation C, fence C, foundation D, fence D, plane
11:09:53 <frosch123> all sorting is fine, except plane being drawn after fence B
11:10:16 <frosch123> so plane is moved and it ends up as : foundation A, fence A, foundation B, plane, fence B, foundation C, fence C, foundation D, fence D
11:10:41 <frosch123> which is totolly fine for the BB, but causes foundation C and D to be drawn after plane
11:11:37 <fonso> we could forbid moving the plane behind foundation D and move the fence in front instead.
11:12:10 <frosch123> write a patch for it and enjoy everything else sorted wrong
11:12:56 <fonso> In which cases do we need anything drawn behind foundations?
11:13:07 <fonso> and can we include that in the special rules?
11:13:19 <frosch123> vehicles can very well end up behind foundations
11:13:33 <frosch123> just build a rail track on the backside of a hill
11:13:42 <frosch123> with foundations in front of it
11:14:07 <fonso> then we need to consider the Z coordinate and refine the rule.
11:14:46 <fonso> I think it is possible to formulate a set of special rules to address specific clipping problems without destroying anything else.
11:15:41 <fonso> The most extreme case would be to only consider the special concorde and foundation sprites.
11:15:59 <frosch123> with the more recent changes it should sort a lot nice, just it will cause a lot incompatibility to newgrfs
11:16:12 <frosch123> esp. with georges grfs
11:20:03 <fonso> What do you mean by "recent"? I'm up to date with trunk.
11:20:21 <frosch123> but the patch in the above forum post is not :)
11:23:49 <fonso> The algorithm is way more complicated than simply a set of special rules for problematic cases.
11:24:37 <frosch123> I cannot imagine something more complicated than a few special rules :)
11:25:20 <frosch123> But I guess you should start experimenting with some coding
11:25:43 <fonso> Simply means: I hook up a check in the do-loop and if it hits I move the other sprite backward instead of the first one forward. Of course the check-thing should be extendable.
11:51:19 *** Doorslammer has joined #openttd
11:57:05 *** Yeggzzz is now known as Yeggstry
12:20:07 <fjb> Is there a way to replace a railcar with the same type?
12:21:28 <frosch123> why would you want to do that?
12:24:07 <fjb> Because some railcars change their look over time. And because they do not get old like lokomotives you end up with a futuristic lokomotive pulling a train build in the last century.
12:24:28 <fjb> Autorenew only renews the lokomotives.
12:26:06 <Eddi|zuHause2> so you mean rail wagons, not railcars
12:26:30 <Eddi|zuHause2> railcars are self driving wagons (-> Schienenbus)
12:26:40 <fjb> However that is called. The things that get pulled by the lokomotive.
12:28:04 <Eddi|zuHause2> autoreplace can't possibly handle that case...
12:29:00 <Eddi|zuHause2> in a way that it's flexible enough, uncomplicated to use and easy to code
12:31:23 <fjb> And most train sets have only one type of universal passenger coach.
12:39:30 <CIA-1> OpenTTD: frosch * r14409 /trunk/src/viewport.cpp: -Codechange: Simplify a loop and correct a comment.
12:40:47 *** Swallow has joined #openttd
12:52:46 <Alberth> how does one submit a HG patch queue to Flyspray? :P
13:07:36 <TrueBrain> not; make a normal single file patch from it
13:21:52 <Alberth> TrueBrain: Sure? There are 13 conceptual changes/additions in the patch then.
13:27:50 <TrueBrain> Alberth: then make 13 patches out of them
13:28:45 <Alberth> TrueBrain: What do you think in the in mercurial patch queue?
13:29:14 <TrueBrain> now that was almost understandable ..
13:31:23 *** mortal` has joined #openttd
13:34:12 <Alberth> Just submitted into FS#2322, however it cannot be good that I have to manually tell HG how to generate a diff of each patch.
13:35:02 <frosch123> arn't they just somewhere in the .hg directory?
13:37:16 <Alberth> Hmm yeah, they are <grump>, in .hg/patches apparently. Ok, good to know for next time. tnx.
13:38:21 *** mortal`` has joined #openttd
13:50:24 <CIA-1> OpenTTD: rubidium * r14410 /trunk/src/ (strings.cpp strings_func.h): -Codechange: one can't inject a negative number of parameters, so enforce this by using a uint.
13:56:36 *** Sacro|SSL has joined #openttd
14:04:14 *** Dred_furst has joined #openttd
14:05:05 *** Sacro|SSL is now known as Sacro
14:43:42 *** Sacro|SSL has joined #openttd
14:47:34 <Ammler> src/autoreplace_cmd.cpp:484: CommandCost Repla
14:47:35 <Ammler> ceChain(Vehicle**, uint32, bool, bool*): Assertion `ret.Succeeded()' failed.
14:51:34 *** Zealotus has joined #openttd
14:51:37 <frosch123> Ammler: before r14406 or after?
14:52:24 <frosch123> you pushed the depot mass replace button with free wagons in the depot (i.e. not attached to an engine) ?
14:54:44 <Ammler> yes, we update to 1407
14:55:54 *** Wezz6400 has joined #openttd
15:00:17 *** mortal` has joined #openttd
15:00:25 *** Mortal is now known as Guest2112
15:00:25 *** mortal` is now known as mortal
15:02:35 <Ammler> src/train.h:33: bool IsFrontEngine(const Vehic
15:02:37 <Ammler> le*): Assertion `v->type == VEH_TRAIN' failed.
15:04:16 <frosch123> hmm, should have tested it also for other vehicles than trains :)
15:04:42 <Ammler> do you have a workaround for?
15:07:15 <CIA-1> OpenTTD: frosch * r14411 /trunk/src/autoreplace_cmd.cpp: -Fix (r14406): IsFrontEngine() is only valid for trains.
15:28:52 *** Sacro|SSL is now known as Sacro
15:30:01 *** eQualizer has joined #openttd
15:32:23 *** Sacro|SSL has joined #openttd
15:33:09 *** MapperOG has joined #openttd
15:33:19 <MapperOG> where can I find the latest version of the DS version?
15:33:49 <Ammler> MapperOG: there is a wikipage about
15:36:21 <petererer> Where abouts is it about?
15:39:12 <petererer> That's the problem, it's easy when you know what the magic word to search for is.
15:42:28 <CIA-1> OpenTTD: frosch * r14412 /trunk/src/ (settings.cpp settings_gui.cpp): -Documentation: Comment some functions related to the advanced settings. Patch by Alberth, but with less excessive use of 'at'.
15:44:04 *** Sacro|SSL is now known as Sacro
15:47:36 *** stillunknown has joined #openttd
15:53:18 <Wezz6400> dang, I've been away from openttd for a little while, to come back and find that a few patches are out giving features I've always wanted :D
16:11:36 *** Frostregen has joined #openttd
16:37:31 <Sacro> isn't `hg parents | grep changeset | awk '{print $2}' | cut -c 3-` a better way of finding the version number?
16:37:46 <Sacro> oh that is what's already there
16:38:31 <glx> HASH=`LC_ALL=C hg parents 2>/dev/null | head -n 1 | cut -d: -f3 | cut -c1-8`
16:40:10 <Sacro> almost what I've got :)
16:40:21 <Sacro> the error message nees updating though
16:40:49 <Sacro> WARNING: there is no means to determine the version.
16:40:49 <Sacro> WARNING: please use a subversion or git checkout of OpenTTD.
16:41:00 <Sacro> you can use mercurial too
16:43:11 <Sacro> glx: what version, trunk?
16:43:35 <Sacro> will it get commited and have my name on it? :o
16:44:01 *** Michael_uk has joined #openttd
16:44:20 *** Michael_uk has left #openttd
17:02:18 <Tefad> glx: good ol command line.
17:02:40 <Tefad> no one teaches that crap any more : (
17:06:59 *** Progman has joined #openttd
17:10:58 <Tefad> the last i checked, head cut grep awk were all programs
17:11:10 <Tefad> are pipes even part of a shell
17:13:03 <Tefad> if so, it's extremely fundamental part. easily overlooked : x
17:13:14 <Tefad> behaves the same practically everywhere eh? : )
17:13:36 <Tefad> fun bits pop up when you start using control structures
17:20:44 <CIA-1> OpenTTD: truebrain * r14413 /trunk/config.lib:
17:20:44 <CIA-1> OpenTTD: -Fix: when no revision detected, the error didn't indicate 'mercurial' was accepted as source too (patch not by Sacro)
17:20:44 <CIA-1> OpenTTD: -Fix: that same message was slightly unclear in what it would mean for network joins
17:21:13 <Sacro> I was just about to clone the repo and write a patch
17:21:22 <TrueBrain> MWHAHAHAHAHAHAHAHAHAHA
17:21:40 <TrueBrain> it was too tempting :)
17:21:43 <Sacro> with blackjack and hookers
17:22:17 * Sacro wants to write a really important patch
17:22:19 * TrueBrain hugs Sacro some more
17:22:31 <Eddi|zuHause2> hahaha, that totally made my day :p
17:25:06 * Sacro considers reviving the yellow signals patch
17:25:47 * fjb hands Sacro a handkerchief.
17:26:47 * TrueBrain is still smiling :)
17:28:30 <Sacro> also, being able to change between crossovers and double slips
17:30:30 <fjb> Thank you. That station is a bit small, I need to build a new one. It started as a two platform station on a single track line, clamped between the town and the mountain.
17:31:26 <fjb> Now I don't want to blow up half of the town to make room for a bigger station.
17:39:19 <fjb> But how is it possible that 14373 people are living in 342 houses? :-)
17:40:44 <TrueBrain> a bit crowded, I say
17:42:36 <fjb> So I'm raising land from the water.
17:44:33 <Rexxars> would it be hard to make a patch that saves station settings? (number of tracks/platform length/coverage area highlight)
17:45:22 <Rexxars> not per savegame, obviously, but per installation...
17:46:14 *** ChanServ sets mode: +o Bjarni
17:46:52 <Bjarni> yeah, it's getting colder
17:47:02 <Rexxars> when are settings like that usually stored to filesystem? on setting change, or on exit? (sorry, I guess I should be reading the source, heh)
17:47:40 <Bjarni> if you mean the stuff written in openttd.cfg
17:47:41 <TrueBrain> sounds like a plan ;)
17:47:50 <Ammler> is there something similar to the old scoreboard.php?
17:48:24 <TrueBrain> Ammler: not at the moment
17:48:29 <TrueBrain> (not required at the moment)
17:48:52 <Ammler> well, indeed, but it was nice to watch the process... :-)
17:49:18 *** Dr_Jekyll has joined #openttd
17:54:47 *** beardie27 has joined #openttd
18:00:13 <TrueBrain> Ammler: live status report: the compile started :p
18:00:35 <Ammler> will the binary compied to the download page?
18:00:58 <TrueBrain> that is a one time thingy btw :p
18:01:47 <petererer> Celestar, there are still issues with refitting :(
18:01:52 <Ammler> but 14413 is the revision
18:02:20 <petererer> Oh, he's not here :D
18:02:31 <TrueBrain> Ammler: you will know in 30 minutes
18:02:33 <TrueBrain> finger will tell you
18:03:08 <TrueBrain> Ammler: in some weird cases it can happen a compile is never published (too many failures, stuff like that)
18:03:27 <Ammler> well, last nightly is also broken...
18:03:43 <Ammler> so we don't have a server right now
18:03:55 <TrueBrain> glx: OOM is not an issue for the compile-farm
18:04:24 <nicfer> for me, Batti5 is actually Jasperthecat12
18:04:33 <TrueBrain> Ammler: what is broken about it? :)
18:04:50 <Ammler> something with autoreplace...
18:05:02 <TrueBrain> glx: each VM is restricted to 384M, and there is always enough free within that context
18:05:03 <Ammler> and the workaround of frosch123 was to wait :P
18:05:05 <nicfer> only that Batti5 has much worse grammar
18:05:17 <TrueBrain> Ammler: ah, so the compile did succeed ;)
18:05:38 <TrueBrain> (which is all I care about :p)
18:09:24 <Ammler> so we have to wait until all bundles are done?
18:10:22 <Eddi|zuHause2> *mental note* check file system space before starting a recording...
18:10:27 <TrueBrain> everything or nothing
18:10:32 <TrueBrain> much easier to track and handle :)
18:11:32 <TrueBrain> Eddi|zuHause2: note failure -- out of disksspace
18:11:34 <DorpsGek> petererer: celestar was last seen in #openttd 2 days, 4 hours, 2 minutes, and 10 seconds ago: <Celestar> SmatZ: did it work?
18:11:58 <Ammler> [20:10] <PublicServer> Ammler: Game version is r14412
18:12:04 <Eddi|zuHause2> the problem is, kaffeine doesn't tell me about it...
18:12:08 <Ammler> TrueBrain: your config change :P
18:12:17 <Ammler> which rev does the compile farm use?
18:12:20 <Eddi|zuHause2> it just records into /dev/null instead...
18:12:46 <TrueBrain> Ammler: you will know when it is done
18:13:00 <TrueBrain> but as 14413 is a non-src change, you can do the math
18:14:47 <TrueBrain> [2008-09-28 18:00:05] Task 0000126 created (svn://svn.openttd.org/trunk, r14412)
18:14:53 <TrueBrain> does that make you happy? :p
18:16:12 *** welshdragon has joined #openttd
18:16:24 <Ammler> now all bundles will be available at same time...
18:16:44 <petererer> If you can't wait, compile your own.
18:17:26 <TrueBrain> if you cna't compile your own, wait
18:18:59 <nicfer> hmmm would be too hard to move openttd to python?
18:19:14 <Ammler> petererer: I do not need such obvious help :P
18:19:31 <TrueBrain> nicfer: very simple; run: mv openttd /usr/lib/python2.5/site-packages/
18:19:51 <nicfer> I mean, recreate openttd in python
18:19:54 <Ammler> nicfer: there is already something about that...
18:20:15 <DorpsGek> Ammler: Yorick was last seen in #openttd 6 days, 22 hours, 17 minutes, and 59 seconds ago: <yorick> I wrote such a patch...
18:20:16 <TrueBrain> only people with very very little knowledge of both OpenTTD and python will try that
18:20:39 <TrueBrain> (or even: will suggest that)
18:22:27 <Eddi|zuHause2> i fail to see the sense of all these "openttd should be ported to XYZ language" suggestions/attempts
18:22:52 <nicfer> well, my main goal is make a web based version of openttd
18:23:32 <Eddi|zuHause2> i can't understand that either ;)
18:23:36 <TrueBrain> Eddi|zuHause2: me 2 ... but as I just said, it is only suggested by people who have absolutely no knowledge of either Python or OpenTTD
18:24:27 <ln> and how is web-based related to porting to python?
18:24:27 *** Eddi|zuHause2 is now known as Eddi|zuHause
18:24:32 <Ammler> TrueBrain: didn't you try something similar?
18:24:55 *** Sacro|SSL has joined #openttd
18:25:19 <TrueBrain> but not via python or something weird like that ..
18:25:51 <TrueBrain> Ammler: the problem only was bandwidth .. :(
18:26:44 <nicfer> hmmm what about porting it to java?
18:27:05 <Eddi|zuHause> nicfer: how about porting it to brainfuck?
18:27:19 <TrueBrain> oh, and if you talk about webdune, that again was based on a completely different idea :) (but yes, in python :)) Failed due to speed-issues :(
18:27:25 <nicfer> and with some changes it would be posible to run it in java-based mobile phones
18:27:29 <TrueBrain> NO! Port it to shakespear!
18:27:42 <ln> Eddi|zuHause: are there brainfuck bindings for SDL? (if not, someone should create those!)
18:27:57 <TrueBrain> whoho! Lets do that! 160x100 to the win!
18:28:13 <TrueBrain> better yet, 120x120!
18:28:26 <Eddi|zuHause> nicfer: unless you have a source-to-source compiler, any such porting attempt would be completely futile...
18:28:28 <TrueBrain> YES YES! Can you see that pixel moving! THAT IS MY BRAND NEW TRAIN! Ha! :)
18:28:36 <TrueBrain> join network games via UMTS!
18:29:00 <TrueBrain> (I think nicfer needs to learn the search option at tt-forums.net)
18:29:11 <TrueBrain> Ammler: hmm, yorick .. you have a good point there ...
18:29:11 <Eddi|zuHause> and if you have one, the result is most likely unuseable
18:30:08 <nicfer> with java it should be also posible to use it in a web browser once OpenGFX is complete
18:30:43 <ln> NOBODY WANTS TO RUN IT IN THEIR WEB BROWSER, especially not if it's a Java applet.
18:31:57 <Ammler> TrueBrain: he is still quite :-)
18:32:28 <TrueBrain> Ammler: it is not like he has a choice :p
18:34:41 <nicfer> well, what makes sense is to port it to smartphones like the Nokia's N-Series or the iPhone
18:34:42 <Ammler> good job frosch123, server runs again. thanks.
18:34:44 <TrueBrain> @mode -q *!*Yorick@*
18:34:44 *** DorpsGek sets mode: -q *!*Yorick@*
18:34:48 <TrueBrain> I guess we can give him an other try
18:35:18 <TrueBrain> nicfer: it still makes absolutely no sense at all ... but then again, you might want to use the search function on tt-forums to find some interesting stuff regarding the subject
18:35:37 <nicfer> one question, how would work openttd on UMPCs/MIDs?
18:36:35 <FauxFaux> Works on my eee right now.
18:36:50 <FauxFaux> the eee that I am, in fact, using to type this message.
18:37:07 <TrueBrain> nicfer: just one question? I thought you asked many more ...
18:37:26 <TrueBrain> FauxFaux: I was at the store yesterday, almost bought an EEE .. couldn't make up my mind, left without one
18:38:17 <frosch123> Ammler: wait, it will assert in 5 minutes :)
18:38:32 * FauxFaux has a first gen one that you can now get for £140, not even a question if you don't have a laptop atall.
18:38:40 <yorick> nicfer: about that python, if I would have had enough time...
18:38:58 <TrueBrain> FauxFaux: I want one to code in trains and shit :p
18:39:28 <FauxFaux> Mmm, not such a great choice given the first gen's battery life. :p
18:39:31 <TrueBrain> yorick: even with all the days of the earth, you would not manage
18:39:45 <TrueBrain> (it is impossible to write OpenTTD in python in any efficient way .. you will fail, without using C)
18:39:56 <yorick> who said I can't use C?
18:40:16 * FauxFaux is just trying to get used to Colemak on a keyboard that was never designed for a home-row typist.:p
18:40:36 <TrueBrain> yorick: theb est you can do is make a python library around OpenTTD C++ .. which is almost useless
18:41:43 <yorick> maybe JIT compiling for python could work better...
18:42:36 * TrueBrain sends yorick to a python class
18:42:40 *** Sacro|SSL is now known as Admin
18:42:46 *** Admin is now known as Sacro
18:42:50 <TrueBrain> you might want to consider reading up for what Python is meant, and reconsider
18:43:19 <TrueBrain> but then again .. that is all on the forums
18:44:10 * yorick mumbles something about psyco, but then again, that is C
18:49:47 <Rexxars> TrueBrain: where would settings like drag and drop, station length etc belong? under stations or under gui settings?
18:50:18 <Eddi|zuHause> i use python for my diploma thesis because speed optimisation is a non-target... i can't imagine openttd working like that...
18:51:13 <TrueBrain> Eddi|zuHause: did you know python is one of the fastest 'math' scripts available to the common public?
18:51:25 <TrueBrain> it runs the fibionic test faster than any other scripting language :)
18:51:34 <TrueBrain> (4 times faster than PHP :p)
18:51:50 <yorick> is assembly a scripting language?
18:51:52 <Eddi|zuHause> speed is a non-issue, because the model checking algorithm that's supposed to deal with my results is at least one complexity class higher than any of my analyses;)
18:52:12 <TrueBrain> yorick: I really hope you didn't really asked that question ..
18:52:17 <TrueBrain> don't make me regret removing the +q
18:52:30 <TrueBrain> hehe @ Eddi|zuHause :)
18:53:12 <Eddi|zuHause> it doesn't matter if my algorithms take 2 seconds or 5 minutes, when instead the model checking algorithm takes 2 hours instead of 1 week ;)
18:54:16 <TrueBrain> there are nice clusters to run expensive jobs ;)
18:54:35 <TrueBrain> I myself use IDL for expensive math operations (2d operations that is, so matrices)
18:54:42 <Eddi|zuHause> well, it's not my problem... the model checking is another person's job ;)
18:54:43 <TrueBrain> very very fast language to do those operations
18:55:06 <Eddi|zuHause> i just have to deliver valid (and as additional bonus: optimized) input
18:55:21 <TrueBrain> hehe, that makes an easy job ;)
18:56:07 <Eddi|zuHause> the problem is i have to do the analyses crossing language barriers
18:56:30 <Eddi|zuHause> as the input source code is mixed python and c++
18:58:14 <Eddi|zuHause> statical analysis of a dynamic scripting language is not easy ;)
18:59:06 <Eddi|zuHause> but i think that part is working pretty well already
19:00:55 *** krkrkr is now known as hello
19:04:28 <Ammler> the voice of newKITT is too human...
19:05:38 <petererer> Where can I see or hear this new KITT?
19:05:43 <Rexxars> I find some of these types very confusing, whats the difference between STDC_X and STD_X?
19:05:51 <TrueBrain> petererer: the internet ;)
19:05:57 <TrueBrain> Ammler: I agree, still it is VERY cool :)
19:06:09 <Ammler> I have only the german old KITT in mind.
19:06:17 <Ammler> dunno, how the original sounded.
19:06:46 <ln> isn't the new KITT Val Kilmer?
19:06:59 <Ammler> many american series are better after sync...
19:07:07 <petererer> Wasn't it always a human sound, just with a certain intonation...
19:07:45 <Ammler> petererer: the new one IS like human, not intonation or such...
19:08:55 <ln> petererer: you never know what kind of robot has dubbed the lines into German or Switzerlandish.
19:14:24 *** Euro_swallow has joined #openttd
19:14:42 <Eddi|zuHause> speaking of sync... the translation of star wars that is broadcast on tv is not sync
19:16:35 *** Euro_swallow is now known as Swallow
19:16:39 *** lobster_MB has joined #openttd
19:30:35 *** yorick is now known as Guest2151
19:33:22 <Ammler> oh, that was the wrong word, I had it from peter1138 ;-)
19:33:39 <Rexxars> yorick: I can't figure out how to get these station settings under the station part of the config (the StationSettings struct are shared settings, and only the ClientSettings only consists of GUISettings and NetworkSettings... I'd have to make another struct just for these 3 settings)
19:34:07 <yorick> how do you mean shared settings?
19:34:36 <yorick> last time I checked you could specify the shared-ness with a flag
19:35:05 <Rexxars> this is the first time I've even looked at the source, so I'm fairly confused
19:36:58 <Rexxars> hrm, cause the GUI and network settings go under client settings, then theres a GameSettings extern which I suppose I could use - I just don't think it's much of a game setting tho
19:38:05 <yorick> unsaved patch settings have flag "S"
19:38:06 <Rexxars> personally I feel it fits better under GUI, it doesn't really have anything to do with the game settings as such
19:39:07 <Rexxars> I've added it under there, but all of those settings are under the GUI part
19:41:17 <Rexxars> I'm refering to settings_type.h here
19:43:35 <yorick> what are you trying to do?
19:45:04 <Rexxars> I'm making OTTD remember the "drag and drop", "platform length", "number of tracks" settings in the rail GUI.. having trouble getting those saved under the stations part in the config, as you told me to do
19:46:04 <Rexxars> maybe I should just put it under gui? ;)
19:46:10 <yorick> try looking at settings.cpp
19:46:17 <yorick> the settings are defined there
19:47:19 <yorick> I think it is outdated, but it should be of some use
19:48:35 <Rexxars> ok, can you just update me on the difference between SDT and SDTC? heh
19:49:47 <Rexxars> all the similar settings seems to be defined as SDTC, since they are unsaved patch variables, from the looks of it
19:51:36 <yorick> you should use SDTC seems not to be saved
19:51:51 <Rexxars> yeah, but this is where the problem arises
19:52:45 <Rexxars> those are client settings
19:53:01 <yorick> just make it a gui setting ;)
19:53:25 <yorick> the SDTC seems not to be using GameSettings
20:35:06 <Rexxars> can anyone give me a hint on where a good place to read and store settings would be done?
20:35:27 *** Zephyris has joined #openttd
20:44:03 *** Eddi|zuHause2 has joined #openttd
20:46:11 *** welshdragon has joined #openttd
20:47:18 <SmatZ> Rexxars: cp openttd.cfg backup.cfg ; cp backup.cfg openttd.cfg
20:49:35 <Rexxars> I'm trying to store the selected settings in the rail gui, ie drag and drop, platform length etc.. right now I have to set both the settings value (to make OTTD store it on exit) and set the local variable (to make OTTD use it)...
20:50:50 <Rexxars> this seems a bit redundant though. what's the best thing to do? replace every instance of _railstation.platlength with _settings_xxx?
20:51:50 <Rexxars> or is there somewhere clever where I can just do _settings_xxx = _railstation.platlength (right before it saves the settings to file, for example)
20:54:17 <Rexxars> I'm trying to contribute, but I'd rather do this right the first time than have to go back and do it all over again ;)
20:55:33 <glx> Rexxars: add it in settings.cpp (IIRC)
20:58:12 *** welshdragon has joined #openttd
21:03:44 <Rexxars> glx: Any ideas on what I should do though? Add a function that alters both? Make a function that saves the settings before shutdown? And if so, where do I call it from? (sorry, first time I've looked though the code)
21:04:07 <glx> you just need to add an entry in the arrays
21:04:24 <glx> will link the vars to the cfg vule
21:05:46 <Rexxars> I've done that, but like I said, I have to edit the cfg value for it to be saved, as well as the internal setting (_railstation.platlength, for example) - and I have to do this multiple places, so it seems less than optimal to change both the global setting and the local every place...
21:09:52 *** stillunknown has joined #openttd
21:10:19 *** Yeggstry is now known as Yeggzzz
21:11:54 *** grumbel has joined #openttd
21:19:37 <sexten> how annoying is it on a level from 1-10 when you join a 2048x2048 multiplayer game and start creating a successfull network when the ONE other player decides to start building in all the exact same spots you've already built just to halt you
21:21:11 <Rexxars> small map though, can't blame him ;)
21:23:26 <sexten> that's the really annoying part, if it was a 256x256 it would of course have been ok, if it was a productive industry or something. but this was on a 2048 map and the industries wasn't THAT great:p
21:26:59 <Prof_Frink> If your network collapses at the slightest hint of competition, it ain't successful.
21:27:29 <sexten> it didn't collapse, but of course I lost some of my profit (this was all the way in the start)
21:27:47 <sexten> and he probably ended up losing more than me on it, but it's still damn annoying
21:27:56 <sexten> railwaytracks in the way etc.
21:28:14 <Rubidium> if you don't want to compete you're better of in SP
21:29:25 <sexten> I love to compete, but not by copying whatever the other one does
21:29:26 <Rubidium> and it's not something "we" can solve for you
21:29:51 <sexten> I'm just throwing it out there. Starting a debate if you'd like.
21:30:02 <Rexxars> has to be allowed to air ones frustration? :)
21:30:07 <Prof_Frink> sexten: You should try playing on Brianetta's Standard some time.
21:30:14 <Rexxars> even if it can't be "fixed" by developers ;)
21:30:38 <sexten> and no, I wasn't asking anyone to fix/edit anything:)
21:30:41 <Prof_Frink> Plenty of competition, but being a tit *will* get you kicked.
21:31:11 <sexten> Prof_Frink: the only problem I can imagine is that those players are probably 1 or 2 levels above me:)
21:32:35 <Rexxars> would it piss the developers off if I submitted a patch that replaced _station_show_coverage with _settings_client.gui.station_show_coverage?
21:39:22 <Rexxars> good, I'm gonna do that ;)
21:42:39 *** Osai is now known as Osai^zZz
22:23:03 *** Digitalfox has joined #openttd
22:23:14 *** Eddi|zuHause has joined #openttd
23:56:05 <Sacro> note to self, don't go with tpgi.com.au
23:56:56 <welshdragon> Gekz, your ISP sucks
continue to next day ⏵
