IRC logs for #openttd on OFTC at 2010-10-12
⏴ go to previous day
00:17:52 *** ChanServ sets mode: +v tokai
02:19:23 *** Xrufuian has joined #openttd
03:05:08 *** ar3kaw is now known as ar3k
03:38:06 *** Xrufuian has joined #openttd
03:54:21 *** JVassie has joined #openttd
04:00:42 <Xrufuian> I'm having trouble getting OpenTTD to write to the config file as user, dispite having read/write/modify permission. Anyone have an idea as to why?
04:13:52 <GhostlyDeath> Which OS? Which Filesystem?
04:24:55 <GhostlyDeath> I wouldn't know, I use Linux heh
04:25:24 <GhostlyDeath> Is the directory it's in writeable? Do you have some free disk space?
04:25:38 <GhostlyDeath> Is 7 treating OpenTTD in some compatibility mode placing files elsewhere?
04:25:54 <GhostlyDeath> C:\Users\<YourName>\AppData\Roaming or something
04:26:33 <Xrufuian> No, it's not in the "virtual store".
04:26:48 <Xrufuian> That's why I'm boggled.
04:26:57 <GhostlyDeath> Tried current working dir?
04:29:10 <Xrufuian> The config is in the exec dir, but it seems you already assumed that.
04:32:04 <Xrufuian> I've given read/write/modify permissions for hotkeys.cfg and hs.dat also.
04:34:52 <Xrufuian> I don't think there's any other files used for some sort of configuration related task, but then I don't know averything in the world, nor do I read minds.
04:39:55 <Xrufuian> Other programs (such as Notepad) will write to the config as user, but OpenTTD won't for whatever reason.
04:43:58 <Xrufuian> I can change something in notepad, save, then run OpenTTD and that's fine. But if I change a setting in-game, exit, and load it again, there's no effect.
04:45:15 <Xrufuian> So, say, for example, I change the base graphics to OpenGFX. When I reload, it's back to Foster's graphics.
04:47:09 <Xrufuian> Seems to be only an issue if I try to have it use the confg in the exec dir. Works normal if config is in %HOME%\Documents\OpenTTD
04:48:46 <Xrufuian> I think I just need to give up on using the nightlys for now, and just play with 'stable' releases.
04:56:41 *** Eddi|zuHause2 has joined #openttd
05:09:43 *** Kurimus has joined #openttd
05:43:38 *** andythenorth_ has joined #openttd
05:57:36 *** andythenorth_ has joined #openttd
06:28:38 *** ^Spike^ has joined #openttd
06:32:06 *** Cybertinus has joined #openttd
06:32:36 *** andythenorth_ has joined #openttd
07:21:27 *** Br33z4hSlut5 has joined #openttd
07:24:37 *** azaghal has joined #openttd
07:27:25 <planetmaker> good morning Terkhen
08:07:34 *** Progman has joined #openttd
08:16:08 *** TomyLobo has joined #openttd
08:21:47 *** Mortomes|Work has joined #openttd
08:42:37 *** andythenorth_ has joined #openttd
08:44:37 *** Devroush has joined #openttd
08:48:03 *** snorre_ is now known as snorre
09:05:58 *** azaghal has joined #openttd
09:11:39 <xiong> planetmaker, I have a completely different idea from 001, though. Absolutely different.
09:13:01 <xiong> 001 was just a fast stab at it. Flaws: Not committed to a schematic view, it tries somewhat to be representational, too, and does neither well. Also, way too big: obscures other game elements and attracts too much attention.
09:13:30 <xiong> Now, I think a much better approach is to put the signal right on the track, between the rails. Possible?
09:15:06 <xiong> Then, draw the signal fake-isometrically, so its bounding box is, in px, wider than it is tall. For instance, a block signal, I think, can be a simple circle; viewed this way, an ellipse. Visible yet not too obtrusive.
09:15:28 <planetmaker> you can draw it how you like and place it where you like
09:16:07 <xiong> Well, team effort, I want your thoughts. Will we need to tell users 'You must select signals on drive side' or otherwise?
09:17:14 <xiong> I'm none too clear about how the origin of each sprite must be specified.
09:17:42 <planetmaker> I'm not entirely sure whether that's a user-only setting. I think it's a server-side setting
09:17:52 <xiong> Maybe I should leave that up to you; the concept is obvious, I hope.
09:18:40 <xiong> Two questions: Must I go for a hard edge to the signal graphics or do I have full alpha-channel transparency?
09:19:19 <xiong> PNG supports full alpha, of course; I can also deliver a mask as a separate file.
09:20:15 <peter1138> If you're making 32bpp graphics, you can have alpha-channel transparency.
09:20:19 <planetmaker> There's no alpha channel
09:20:25 <planetmaker> there's no RGB either
09:20:34 <planetmaker> There's 192(?) colours and that's it.
09:21:01 <xiong> Yah, I get that. Limited palette and transparency shown by a special color. Just checking.
09:21:08 <planetmaker> except if you do 32bpp graphics - but that needs 8bpp graphics in the first place
09:21:14 <xiong> I'll deliver an indexed PNG, no problem.
09:21:19 <peter1138> Where did you get 192 from?
09:21:31 *** azaghal has joined #openttd
09:21:39 <planetmaker> peter1138, that's the number of colours not used as action or CC. Roughly
09:21:59 <planetmaker> maybe I'm off by a few.
09:22:19 <xiong> Second question: Does any signal display a different aspect to trains coming from either direction? That is, do all signals have only two states or do some have four?
09:23:54 <peter1138> planetmaker, 203 :)
09:25:11 <xiong> I miscounted, as I'm sure you know. 6 types of signal. There are of course 8 directions in which a signal might face but, IIUC, block signals may be considered to face in all directions or none.
09:25:51 <planetmaker> xiong, each signal type needs 8 directions, two states
09:26:15 <xiong> A one-way path signal is obviously unidirectional and, for orthogonality, path signals should be bidirectional.
09:26:20 <planetmaker> there are 6 signal types: normal, exit, combo, entry, path and one-way path
09:26:47 <planetmaker> you don't seem to understand how path signals work
09:26:52 <xiong> Um, yes, but I'm proposing a block signal that uses the same graphic no matter which way it faces, since that's an irrelevant consideration.
09:27:34 <xiong> Um, maybe I dunno. But I think it's my jargon that's getting in the way.
09:27:52 *** andythenorth_ has joined #openttd
09:28:12 <peter1138> xiong, good luck placing them properly.
09:28:52 <xiong> A one-way path signal permits traffic in only one direction. The higher-level question of why and when it changes state is beyond the scope of the bigsig project.
09:29:47 <planetmaker> but it also depends whether you count DOS or windows palette
09:29:58 <peter1138> I got 208 for Windows, 215 for DOS.
09:30:12 <peter1138> (I'm assuming Oskar's palettes are correct.)
09:30:28 <planetmaker> that's which I counted
09:30:31 <xiong> My focus is pretty narrow for now. I'm only counting the number of individual graphics that must be drawn. If a block signal is a round dot, then its appearance doesn't change as its rotated.
09:30:59 *** Guest2424 is now known as V453000
09:31:09 *** JVassie has joined #openttd
09:31:25 <planetmaker> xiong, the facing is an essential part of a signal,you cannot skip that
09:31:33 <xiong> peter1138, Not sure what you mean. I'd better draw some demos or none of this will be intelligible.
09:32:03 <planetmaker> facing cannot be done by alignment (alone)
09:32:31 <xiong> planetmaker, I guess I don't understand that. Here's a block signal on a piece of track; here's another, on another piece of track at right angles. How *must* they differ in appearance?
09:33:13 <xiong> Okay, I understand that the origin of the two might be different. I assume that each, even if it displays between the rails, will have its origin where the standard signal would be.
09:33:14 *** andythenorth_ has joined #openttd
09:34:38 <xiong> Um, I probably should start, after the demos, by looking at the standard signal file.
09:36:40 <peter1138> planetmaker, so 256-(transparent)1-(winapi)9-(water)11-(block?)5-(fire)7-(red)2-(yellow)4-(???)9
09:43:08 *** Devroush has joined #openttd
09:51:30 <xiong> I can't stay up too late tonight; work tomorrow. But I'll see if I can't slap together a little demo now.
09:57:53 <peter1138> xiong, yes, that last one is correct.
10:03:17 *** guru3_ is now known as guru3
10:12:12 *** azaghal has joined #openttd
10:15:39 <xiong> Cool. Just a demo tonight, need feedback on the general idea.
10:19:04 <DorpsGek> dihedral: SmatZ was last seen in #openttd 12 hours, 39 minutes, and 0 seconds ago: * SmatZ hopes the czech O2 will end as AOL
10:48:15 <planetmaker> xiong, there is NO two-way path signal
10:48:28 <planetmaker> there's a path signal and a one-way path signal
10:48:41 <planetmaker> but the normal path signal still only acts as signal in one direction
10:49:26 <planetmaker> and there are _four_ different block signals
10:49:31 <xiong> Okay, well, it may take some before I grasp that. I should probably build some test track and just see what happens.
10:49:47 <planetmaker> the entry, exit and combo signals are also block signals
10:50:16 <xiong> Okay, well, we have to choose words to talk about these things. What is a block signal that is not an entry, exit, or combo?
10:50:57 <xiong> Okay, sorry. The GUI calls it a 'Block Signal'.
10:51:00 <planetmaker> and your sketch does not make clear which direction it acts on
10:51:16 <xiong> Does a block signal act only in one direction?
10:51:19 <planetmaker> Yes. But it _also_ calls the entry, exit and combo signals block signals
10:51:34 <planetmaker> it acts on the following signal block
10:51:45 <planetmaker> two-way or not is not your concern when drawing signals
10:52:02 <planetmaker> as each direction will get its own signal.
10:52:18 <planetmaker> Thus: you have to draw each signal with each of the 8 facings
10:52:28 <xiong> Okay, well then, I was correct: a signal can be in one of 4 states.
10:52:53 <planetmaker> A tile can have up to two signals
10:53:00 <xiong> It can be red both ways, green both ways, green one way red the other or green the other and red the one.
10:53:26 <planetmaker> One signal always only ever faces one direction
10:53:41 <planetmaker> But you mix it up with the signal arangement on a tile.
10:53:49 <xiong> How can a tile have more than one signal? It's not permitted that a signal be placed at any sort of junction, right? Only on plain track.
10:54:04 <planetmaker> which can be one-way, the other way or both ways for block signals.
10:54:22 <planetmaker> Or one way or the other for path signals
10:55:42 <xiong> Obviously, I really need to build that test track. I will still have several misconceptions and stupid questions when I've fooled around with it some, but I hope fewer.
10:56:16 <xiong> I'm thinking I should do some basic research on prototype signals, too; I worry that I may draw wrong inferences, though.
10:56:46 <planetmaker> that's why I told you to for example look at the signals which are in the existing base sets. I gave you a link which shows them the other day
10:56:56 <planetmaker> as did some other person, dunno whom it was
10:57:13 <xiong> If you're feeling disgusted now, planetmaker, hang in there. I always ask stupid questions early on but I learn fast. I've only had this game up for about 3 days.
10:57:46 <xiong> I have followed many of your links but I missed that one.
10:58:09 <xiong> I would really like to see a complete set of existing light signals.
10:59:19 <planetmaker> and as you calculated yourself: 6 types, two states, 8 directions they can face
11:00:29 <planetmaker> mind that on a single tile two or four signals can exist. So... placing in the middle of the track will become a challenge, though it might work, if not centred
11:01:11 *** Chruker has joined #openttd
11:01:12 <xiong> Okay, this is where I get confused. I can more or less see that a tile might contain 2 signals. I can't see how it can contain 4.
11:01:59 <xiong> The 2-signal case is weird enough. Some signals make assertions about traffic in both directions. So, it seems to me that 2 signals might contradict one another.
11:02:03 <Yexo> one tile can have two diagonal tracks on it, each of those tracks can have a double block signal
11:02:27 <xiong> Again, I was under the impression that signals were forbidden at all junctions.
11:02:43 <xiong> I've gotten several red error pop-ups trying to do it.
11:02:46 <Yexo> two diagonal tracks do not make a junction if at the top and bottom of a tile (or left and right)
11:03:12 <xiong> Well, technically, a crossover, not a turnout, yes.
11:05:13 <xiong> We may be running into UK-US usage differences as well as prototype vs model usage. As I say, I'll fool around with a test track. Since I can't see the signals clearly, it's an issue; but in the test case, I can be very structured how I lay signals and if need be, doze them all and do over. I'll figure it out.
11:05:24 <planetmaker> thanks Yexo & hello :-)
11:06:41 <xiong> Oh, well, Yexo, those tracks are parallel. Of course each track can have its own signals. And I see what you mean, that the board tile itself contains several. Is this an issue? I don't want to center signals in the tile but in the track.
11:07:55 <Yexo> as you can see the signals are quite close together, it'll be difficult to make them bigger without obscuring the complete tile
11:08:03 <xiong> Seems to me that if we're talking relative-to-tile, I need many more instances of each class of signal.
11:08:28 <Yexo> no, the signals are relative to the track
11:08:31 <xiong> They don't need to be much bigger if their entire area is devoted to showing logical, schematic info.
11:09:47 <xiong> I realize my demo is crude but I hope it makes my point. The shape tells the type of signal, the orientation tells in which way it acts, and the color tells the state. Those 002 signals could be downsized another 50% without becoming unreadable.
11:11:08 <xiong> Rationally, a signal can always be as big as the rail gauge, no matter what other considerations obtrude.
11:11:36 <planetmaker> xiong, let them consist of half-circles: One in the signal-state colour, the other facing away from the direction then could indicate the signal type
11:11:48 <xiong> Even in the difficult case you showed, with two parallel lines running east-west, I can distinguish all four rails.
11:12:25 <xiong> Something like that, planetmaker.
11:12:29 <dihedral> use overlay arrows for 'direction' :-P
11:12:57 <planetmaker> dihedral, no, the facing of the diagonal line :-)
11:13:14 <planetmaker> then no arrow is needed and the same information coded :-)
11:13:41 <dihedral> or generally use an overlay on the tracks theselves?
11:13:57 <xiong> Okay, guys, fascinating discussion. But I do have to get into bed. Also, I'm dragging the discussion due to insufficient practical experience. I will build a test track, fool with it, and learn.
11:14:35 <xiong> I think I'm going to hold out for those 3 basic shapes, though. We'll see.
11:15:19 <xiong> Night all, and thank you for your patience.
11:20:07 <planetmaker> but if you provide a first set of 16 sprites for one signal type, you might get a better idea what it looks ingame
11:20:33 <planetmaker> as said, it's very easy to get that ingame once a set of sprites exists.
11:20:49 <planetmaker> Start with one type. See how it works then ingame. And then do the others based on that :-)
11:33:22 *** azaghal has joined #openttd
12:08:48 *** azaghal has joined #openttd
12:17:05 *** Biolunar has joined #openttd
12:32:31 <peter1138> Okay, so when you get EAGAIN from send(), you should resend the packet again later, right?
12:34:12 <Rubidium> W#define EWOULDBLOCK EAGAIN /* Operation would block */
12:34:24 <Rubidium> (from /usr/include/asm-generic/errno.h)
12:34:52 <Rubidium> so yes, I think you should try it later
12:36:18 <peter1138> Which is what I do. Maybe it's a bug in MC, but I can't see how... :S
13:01:17 *** Eddi|zuHause2 has joined #openttd
13:09:38 *** frosch123 has joined #openttd
13:22:45 *** TheMask96 has joined #openttd
13:25:09 *** KenjiE20 has joined #openttd
13:28:44 *** Progman has joined #openttd
13:40:37 *** andythenorth_ has joined #openttd
13:54:27 *** Progman has joined #openttd
13:57:12 *** Progman_ has joined #openttd
14:04:46 *** Progman_ is now known as Progman
14:07:24 *** Eddi|zuHause has joined #openttd
14:14:09 *** Adambean has joined #openttd
14:35:17 *** JVassie has joined #openttd
15:03:21 *** theholyduck has joined #openttd
15:44:07 *** andythenorth_ has joined #openttd
16:18:42 <KouDy> where ican be settings file (game advanced settings, game settings etc) found in linux?
16:19:23 <blathijs> KouDy: in ~/.openttd
16:27:16 <glx> this info is in the readme ;)
16:28:12 *** Progman has joined #openttd
16:32:32 *** trebuchet has joined #openttd
16:32:58 <planetmaker> [18:32] <glx> [18:27:14] this info is in the readme ;) <-- that file does not exist
16:33:01 <planetmaker> no one seems to find it
16:33:52 <Eddi|zuHause> we need to display the readme(s) ingame
16:36:04 <planetmaker> *someone* is a lazy brag
16:36:08 <frosch123> or passcodes: enter the 5th word of the 25th line of the readme to proceed
16:36:12 <Eddi|zuHause> i need to play more civ5
16:36:37 <Eddi|zuHause> only played 35 hours and have 31 achievements yet...
16:36:37 <Rubidium> yeah, to unlock the "change NewGRF" feature :)
16:37:03 *** azaghal has joined #openttd
16:39:01 *** Prof_Frink has joined #openttd
16:40:02 <Eddi|zuHause> just a matter of precaution: don't play ghandi with music on. you get mad...
16:40:29 <planetmaker> Rubidium: I like that ;-)
16:40:37 <KouDy> aha readme... mkay... reading it aaaaaand it brings more questions!
16:41:54 <KouDy> well or maybe it doesn't
16:42:02 <planetmaker> frosch123: apropops changing newgrfs... I added an updated version to FS
16:42:12 <planetmaker> It still uses the optional parameters
16:42:29 <planetmaker> which has the advantage that not every frigging call to that function needs changing
16:42:42 <planetmaker> and it is called in MANY places
16:42:55 <planetmaker> But all but one (newgrf_gui) want the usual behaviour
16:43:12 <planetmaker> so I warrant giving it a parameter which that sets to non-default will be fine
16:43:55 <planetmaker> or would your stance rather be to implement a separate function?
16:44:04 <planetmaker> I'd like to avoid that as it means duplication
16:46:00 <KouDy> is personal folder location hardcoded?
16:46:34 <Eddi|zuHause> on compile time, yes
16:46:42 <KouDy> i'm thinking if it was possible to change it network location so i could use exactly same stuff on all machines all the time (also saves)
16:46:45 <Eddi|zuHause> use ./configure --help
16:47:01 <KouDy> i cannot do that in windows can i?
16:47:21 <KouDy> you see, one my box is windows, other one is ubuntu
16:47:23 <planetmaker> symlinks do the trick just fine
16:47:28 <Eddi|zuHause> it should be possible in MSVC as well
16:47:51 <glx> KouDy: sharing config between windows and linux doesn't work very well (at least for newgrfs path)
16:47:56 <Eddi|zuHause> or just use the magic of the -c parameter
16:48:20 <planetmaker> glx: depends a bit upon setup of the box :-)
16:48:50 <planetmaker> if the mother file system is mapped to windows, and the mother file system supports symlinks...
16:49:05 <glx> planetmaker: a full path with d: will be fun
16:49:44 <planetmaker> IIRC it worked. But the cfg has only relative to data dir normally, no?
16:49:44 <glx> anyway -c is a good option
16:49:56 <planetmaker> at least mine seems to have only relative to it
16:51:23 <glx> relative in mine too, but I remember seeing full paths too
16:52:10 *** HerzogDeXtEr1 has joined #openttd
16:53:25 <planetmaker> yes, I've seen it, too. Maybe one can set it explicitly
16:53:33 <planetmaker> whatever sense that would make
16:55:29 <KouDy> well more handy would be (for my case obviously) to set absolute for saves and GRF files etc, but leave option to place cfg on separate location inside of each box
16:55:59 <KouDy> just to prevent possible issues with shared cfg accross the platforms
16:57:05 <planetmaker> well. The only issue can be the newgrfs which are going to become active when you don't change the newgrf config before creating a new game
16:57:28 <KouDy> well actually... thinking of it... cfg, you set it once and it's more or less same (again for me), i don't do brutal changes to it, GRFs are not issue either, just transfering files to both boxes will fix it
16:57:32 <planetmaker> not that much an issue, if you have the newgrfs in both data folders, of your VM and your host system
16:59:33 <KouDy> it would be even better to have grfs separate...
17:01:35 <KouDy> on second thought... if you have complex GRF heavy save, it's better to have them shared
17:03:36 <KouDy> so anyway... the only way is to compile stuff
17:04:59 <KouDy> and glx says it's not recommended to share cfg
17:05:33 <glx> but you can try with -c and see if it works
17:06:19 <KouDy> now now where is that readme i'm going to need it, i have only very elemental knowledge of linux
17:20:07 <CIA-2> OpenTTD: rubidium * r20916 /branches/1.0/src/order_gui.cpp: [1.0] -Fix [FS#4159]: crash when, while the 'go to' cursor is active, you open the order list of a vehicle of another company and then select a 'go to' destination
17:23:27 <planetmaker> [19:01] <KouDy> on second thought... if you have complex GRF heavy save, it's better to have them shared <-- the savegame doesn't care *where* a newgrf is found - as long as it IS found
17:35:55 <KouDy> well yea i am trying to figure out how to put network location into links which imo is not really possible
17:36:14 <KouDy> i would have problems when i take laptop (ubuntu box) and go travelling
17:36:26 <KouDy> then dir with saves and stuff would be unavailable
17:36:43 <KouDy> ultimately causing more troubles
17:45:20 <CIA-2> OpenTTD: translators * r20917 /trunk/src/lang/unfinished/basque.txt:
17:45:20 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:20 <CIA-2> OpenTTD: basque - 119 changes by bellota
17:47:28 <CIA-2> OpenTTD: frosch * r20918 /trunk/src/saveload/ (newgrf_sl.cpp saveload.cpp): -Add: Store NewGRF version information from Action14 in savegame. (planetmaker)
18:03:31 *** theholyduck has joined #openttd
18:03:34 *** ajmiles has joined #openttd
18:07:11 <KouDy> grfs with names for towns are used just like any others?
18:08:00 <frosch123> not quite, you add them to the grfsettings, then select them in gameoptions, then start a new game
18:08:07 <frosch123> so there is another step in the middle
18:09:15 <Rubidium> Lakie: you did pastebin some newobject company colour patch for me to see, but now that pastebin entry has expired :(
18:09:29 <Rubidium> would you pretty please pastebin it again?
18:12:14 *** Mortomes has joined #openttd
18:13:20 <Lakie> Um, I don't have the diff anymore...
18:13:28 *** Alberth has joined #openttd
18:13:49 <Lakie> I could probably work it out again though
18:14:09 <KouDy> haha you are right, tbh that idea came to me just after i asked
18:14:25 <KouDy> but i misslooked and changed OTTD language to japanese :)
18:14:32 <KouDy> quite interesting stuff
18:25:50 *** fjb is now known as Guest2537
18:32:13 *** andythenorth_ has joined #openttd
18:41:19 *** ChanServ sets mode: +v tokai
18:52:54 <andythenorth_> someone wrote a nice viewer app for giant screenshots?
18:53:17 <Xaroth> maybe a google maps-like interface around it? :o
18:53:36 <V453000> photoshop does well, I guess gimp would too ;)
18:54:23 <andythenorth_> someone wrote one for the web....think it chunked the png into segments then stitched them
19:06:10 <Rubidium> andythenorth_: spcomb did
19:06:53 <andythenorth_> I thought I could compress the png a bit more, but photoshop chokes on it
19:07:29 <Rubidium> photoshop just stores it uncompressed in memory once you load it
19:07:35 <andythenorth_> and my box is now in swap :P
19:13:08 <andythenorth_> that spcomb thing is neat
19:15:32 <SpComb> I agree, I'm very neat
19:16:11 *** p01ymer has joined #openttd
19:19:23 *** valhallasw has joined #openttd
19:22:03 <Rubidium> guess we need to release something on 2010-06-13. Then we can freely use whit in the release notes :)
19:27:12 <andythenorth_> fricking minecraft :P
19:27:17 <andythenorth_> apparently I should start playing it
19:28:26 <Xaroth> probably not that hard to make something sane for ottd..
19:29:05 <Xaroth> cut up the giant screenshot into sections, load it into that thing, job done.. i think
19:29:11 <andythenorth_> could the game upload to it directly? And could google pay the bandwidth somehow....
19:29:51 <Xaroth> well, making the giant screenshot automagically shouldn't be that hard
19:30:05 <andythenorth_> who has webspace lying around?
19:30:22 <andythenorth_> maybe we just compress them harder?
19:30:56 <Xaroth> I think it'll need more than 24mb to store it
19:31:10 <Xaroth> multiple zoomlevels etc
19:31:17 <andythenorth_> I have the disk space, but not the bandwidth :o
19:32:01 <Xaroth> well, i'd worry about getting the thing to work before finding bandwidth :p
19:32:13 <Xaroth> I mean, you'll want to automate most, if not all, of the process
19:37:27 <andythenorth_> it's a nice project, but I have enough projects started and unfinished
19:38:26 <Rubidium> openttd 8bpp PNG screenshot are remarkably badly compressible
19:38:50 <andythenorth_> they repeat patterns a lot (water, ground)
19:38:56 <andythenorth_> but probably not in the right way
19:39:35 <Rubidium> or, phrased differently, the PNG settings OpenTTD uses for creating the 8bpp screenshots are among the most efficient
19:40:09 <Rubidium> pngcrush won't give you a significant improvement; maybe a few .1s of a percent
19:42:19 <Rubidium> also 7z can't really compress it, or at least not better than plain old zip
19:47:13 <KouDy> when using NARS and FIRS and in advanced options enabled train car speed limits, are there any new cars later? it's kind of weird to have engine running 100mph when best car for sand is 55mph only
19:47:48 *** Wizzleby has joined #openttd
19:48:55 <CIA-2> OpenTTD: rubidium * r20919 /trunk/src/ (company_cmd.cpp object_cmd.cpp): -Fix [FS#4140]: objects didn't change colour when the company changed colour. Now they do, except when the "decide colour" callback is (defined to be) used
19:50:09 <bryjen> the >100mph engines are for passenger service
19:54:48 <KouDy> that makes sense... cargo trains don't usually run 100mph
19:55:53 <andythenorth_> FIRS has quite flat cargo payment rates for many bulk cargos
19:55:57 <andythenorth_> so speed isn't a massive issue
19:57:48 <KouDy> also i am not exactly passanger transporter
19:58:11 <KouDy> but i am thinking how to resolve several trains with these very various speeds on the same tracks
19:59:50 <Xaroth> a smart load balancer would
19:59:51 <andythenorth_> amtrak have the same issue in real life :P
20:00:15 <KouDy> also ... box cars in NARS are ... like from circus in weird colors...
20:00:24 <KouDy> i'm jsut looking at the parameters page
20:00:29 <Xaroth> a track that would make a faster favour splitting off from the 'slow' lane
20:00:40 <Xaroth> basically forcing them into their own
20:00:43 <KouDy> but can't quite figure which one is it
20:01:04 <KouDy> to much things after all that time of not playing
20:05:14 *** zodttd2 has joined #openttd
20:53:14 <planetmaker> hm... thank you frosch, even if you aren't here :-)
21:00:33 *** Brianetta has joined #openttd
21:04:25 <xiong> Okay, I'm working with my test track. Right now, the topic is normal block signals. When I place 'a' signal, 2 signals appear in the same tile, one on either side of the track. Let us say, for convenience, that the track runs E and W. So, one of these signals faces E, one W. Okay so far?
21:05:45 <planetmaker> one signal for each direction, yes
21:06:03 <planetmaker> which is - in terms of drawing - two completely different tasks. Completely unrelated
21:06:17 <planetmaker> each is one of the 8 facings
21:06:50 <xiong> It's an E-W track so there are only two facings under discussion.
21:07:32 <xiong> I cannot consider these two signals independent. They are constructed together and demolished together. Correct?
21:08:14 <xiong> That is, no clever manipulation can leave the board with only one.
21:13:39 <xiong> Okay, that seems not to be true. Now, I have a single block signal, facing only E.
21:20:12 <xiong> A train seems not to want to pass from the back one of these signals, facing only E. So, it as if there were still a signal facing W but permanently red. Correct?
21:22:16 <xiong> In fact, it is even stronger; the pathfinder does not even want to *try* to approach the one-side block signal from the back.
21:22:47 <xiong> So, can a one-side, otherwise normal block signal be considered a one-way signal?
21:25:18 <planetmaker> xiong: they are independent
21:25:29 <planetmaker> in terms of graphics and in terms of their state
21:25:41 <planetmaker> only not built independently as build functions act always on a tile
21:26:24 <planetmaker> block signals are impassable from the back, if they're single signals
21:29:37 <xiong> My actions are limited to drawing but I have to comprehend effects, both to design intelligently and to run the railroad outside of the bigsig project.
21:31:27 <xiong> It's not entirely true to say that the signals on either side of the track only control traffic in their own direction. An unsignaled section is fully permissive; the train will go through without stopping; the tile is part of the block before and behind. A signal on the other side creates a condition for trains going the other way.
21:32:40 <xiong> I realize this is all very basic but I'm big on pinning down fundamentals. Each block signal imposes a condition on both sides of the track; and the condition imposed is different. Also, the signals interact.
21:32:57 *** theholyduck has joined #openttd
21:34:00 <xiong> So, although a single block sig will not only halt but forbid traffic on the other side, a second block signal on the other side cancels that effect. The second sig may be red, in which case a train will stop and wait for it to clear to green. But the presence of the first sig does not forbid the other side traffic.
21:35:44 <xiong> So, for all intents and purposes, there are two distinct kinds of signal possible on a tile -- considering only normal block sigs. There is a one-way and a two-way normal block sig. They may share graphics but the two-way does not operate as two independent one-ways.
21:38:22 <xiong> Now, I'm going to guess that there is some conflation going on here, which is removed from our sphere of action as signal designers. The player places a 1nbs or a 2nbs and the game uses the same graphics, perhaps the same internal identity, for all. But then it recognizes the coincidence of nbs on both sides of the track and signals trains appropriately.
21:40:31 <xiong> So, to conclude: My 002 concept is deeply flawed. Signals will have a hard time competing for the center of the trackbed because we, as designers, cannot say -- when we design the nbs -- whether it will be used as 1nbs or 2nbs. The graphics must be fully independent and adaptable to both applications.
21:43:49 <xiong> I see that the entry/exit/combo sigs are the same way. They can be 1 or 2 way. So, the area available to distinguish type and aspect is quite limited.
21:46:09 <xiong> I don't, offhand, see that in all but the most complex yards, it is useful to have entry/exit/combo signals that face both ways. On entry to a station, one might have a tree of presignals, carefully directing traffic from the line down several branches and eventually onto platforms. Last thing you want is a train going the wrong way.
21:46:59 <xiong> Nevertheless, it is necessary to consider all possibilities when designing these sigs. Even if the layout is illogical, the sigs must read clearly.
21:48:51 <xiong> Now, I have got to figure out the distinction between path signals and one-way path signals. Both can be placed on only one side of the track.
21:50:26 <xiong> It's clear, though, that you can't put, say, a 1nbs on one side and a path signal or exit sig on the other side. So, on some level, the game considers all signals on a tile, on the same track, as a unit.
21:56:00 <xiong> I want to swerve off here to talk about track going in different directions. There is track that runs in the same direction as the grid, which is diagonal to the screen; and track that runs diagonal to the grid, which is orthogonal to the screen. This makes it hard to talk about these clearly, as the words 'diagonal' and 'orthogonal' are ambiguous. What terms are in common use in the OpenTTD world?
21:57:12 <Rubidium> x, y, upper, lower, left, right for track bits
21:58:30 <Rubidium> otherwise the directions, e.g. north and north-east
21:58:30 <planetmaker> alternatively one can use the usual North, East, West and South directions
22:00:12 <planetmaker> but for now: good night :-)
22:00:16 <Rubidium> diagonal is usually used from the "tile" point of view
22:10:25 <Yexo> planetmaker: what direction is north? top or top-right?
22:12:03 <Yexo> yes, but I seem to remember that openttdcoop uses something different, where either top-left or top-right is "north".
22:12:11 *** fonsinchen has joined #openttd
22:12:44 <xiong> This kind of ambiguity is unacceptable in a technical discussion. We need to settle on a convention.
22:13:00 <Yexo> just create a screenshot and mark the direction
22:13:26 <Yexo> after that you can refer to that screenshot every time you want to talk about a certain direction
22:13:48 <xiong> Yexo, here I am on IRC. I'm going to talk about things over and over, the same things, day after day. I want nouns, maybe even adjectives.
22:14:06 <Rubidium> hmm... why has MSVC been spewing a warning for over a week?
22:14:42 <Yexo> because nobody was active enough to fix it
22:14:46 <Rubidium> xiong: there's hardly anything that can be done if someone else introduces something ambiguous
22:14:49 <xiong> I don't want to introduce novel nomenclature, arrogantly. I'll be happy to use existing terms.
22:14:52 * Yexo only noticed it today, haven't bothered yet to look into it
22:16:48 <xiong> You know, I'm re-reading, for perhaps the 6th time, ZAAMM. Pirsig early on talks about the 'classical', analytical viewpoint concerned with underlying forms; and the 'romantic', groovy viewpoint concerned with surface appearance. My personal viewpoint is almost entirely classical. So, there's a great number of people I cannot understand nor explain myself to.
22:17:32 <xiong> The classical viewpoint rests heavily on the concept of unambiguous terms, on breaking things into smaller components, each with its own name.
22:17:36 <Rubidium> also, what might be good nomenclature for the user might not be good for the (source) code
22:18:08 <Rubidium> "player" being a nice example :)
22:18:12 <xiong> I'm concerned neither with the user nor the machine. I'm only interested in talking about signals and the track and trains they control.
22:19:40 <Yexo> using items from the Track enum is unambiguous, but those mght not be understood by users who've never read the source code
22:22:39 <xiong> The two are compatible. Great. There must be a similar file for signals.
22:23:08 <Yexo> but that's only for the signal types
22:23:13 <Yexo> not their place on the tile
22:24:35 <xiong> Ah, but the crossjoin of track direction and signal type covers all contingencies except aspect/indication.
22:25:18 <xiong> You already cited that last page. I can see it has more than one section.
22:25:32 <xiong> I don't mean that to sound offensive. I'm just being direct.
22:26:02 <xiong> All of that, highly useful, thank you, Yexo++.
22:26:04 <Yexo> indeed, but at first I pointed to Track, later I noticed Trackdir
22:26:24 <Yexo> not everyone looks further on such a page, I'm happy you do :)
22:26:56 <xiong> And this clearly defines 'north' as the top of the viewport -- and viewpoints/maps do not rotate.
22:28:59 <xiong> So, now I think I can speak unambiguously of 'orthogonal' track as being track laid in any of the directions N, E, S, W.
22:29:34 <Yexo> for track you need two directions, not one
22:30:01 <xiong> ... which will result in a bit of track of one of the types upper, lower, left, right.
22:30:35 <Yexo> but E<>W can also be lower
22:30:42 <Yexo> so it's still not unambiguous
22:31:25 <xiong> enum track track_upper. Is there any question to what I describe?
22:31:41 <Yexo> but there is when you say "track laid in the direction N"
22:32:50 <xiong> Agreed. But I'm trying to define the term 'orthogonal'. I say that is any track upper, lower, left, right; which track will go N, E, S, or W. A superclass of track types.
22:33:35 <xiong> As opposed to 'diagonal' track which is enum track track_x or track_y, headed NE, NW, SE, or SW.
22:34:33 <xiong> Track itself doesn't have a direction, not as it sits there statically on the board; so track pointing N is also track pointing S. The enum types are extremely handy for resolving ambiguity.
22:35:25 <xiong> But I hope the terms 'orthogonal' and 'diagonal' are now sufficiently well-defined that I can say, 'I only want to discuss orthogonal track for the moment.'
22:35:59 <valhallasw> that is not what people generally mean with orthogonal
22:37:15 <xiong> valhallasw, I am content to use other people's terms if they are not too unwieldy. Please describe the set of track: enum track left, right, upper, lower.
22:38:02 <valhallasw> there might be an existing term for that
22:38:15 <valhallasw> anyway, it's better to invent a new term than to use an existing term that means something different
22:38:22 <valhallasw> so I propose the term verthori ;-)
22:39:06 <xiong> I have to go earn money for awhile. We'll take this up later.
22:39:27 <valhallasw> I have to get some sleep so that I can earn money tomorrow :-)
22:39:46 <valhallasw> good luck with finding a nice term ;-)
22:41:04 <Rubidium> I doubt calling track_x and track_y diagonal would be wise, given "diagonal roads" and "diagonal bridges" (which both don't exist yet)
22:44:33 <Eddi|zuHause> MB style argumentation ;)
22:46:27 <Rubidium> but you can't get around the fact that the forum (and wiki) are filled with the presumption that diagonal has to do with the grid, not the visualisation
22:47:23 <Eddi|zuHause> i mean, it's one of his favourite replys: "but diagonal roads DO exist: <insert picture of normal roads>"
22:49:41 <Eddi|zuHause> although i agree, "diagonal" and "orthogonal" should refer to the grid, not the screen
22:49:42 <Rubidium> so, diagonal is a verba non grata?
23:06:06 *** ProfFrink has joined #openttd
23:11:43 *** ProfFrink is now known as Prof_Frink
23:33:18 *** Chris_Booth has joined #openttd
continue to next day ⏵
