IRC logs for #openttd on OFTC at 2011-11-25
⏴ go to previous day
00:00:10 <z-MaTRiX> thought you were linux graphics coder
00:01:51 <z-MaTRiX> some dudes got some scrap pplasma tvs that used FPGA-s
00:02:12 <z-MaTRiX> reprogrammed them, and used it for other purposes
00:02:42 <z-MaTRiX> it is a programmable functional logic array.
00:02:58 <z-MaTRiX> you can program it to be a video card
00:03:09 <z-MaTRiX> washing machine, or anything.
00:03:42 * Eddi|zuHause still waits for the day when are you telling us something of value
00:04:20 <z-MaTRiX> Eddi|zuHause<< well you asked if i know what it is
00:05:22 <Eddi|zuHause> but how does "you can program an FPGA to be a graphics card" relate to "a graphics card is a specialized FPGA"?
00:05:29 <z-MaTRiX> i don't see any reason to post random crap on here
00:06:19 <z-MaTRiX> it is a fixed function ic
00:06:26 <__ln__> is this the shortest way to map {<0,0,>0} to {0,1,2}: (s<0)?0:(s>0)?2:1 (we can imagine s is a return value by strcmp, for example)
00:06:27 <z-MaTRiX> that is why its cheaper
00:07:35 <Eddi|zuHause> __ln__: how about "cmp(0,value)+1"?
00:08:58 <Eddi|zuHause> __ln__: likely you're asking a way too specialized question, and should look at the more general problem
00:10:48 <z-MaTRiX> cmp value,0;ja above;jb below;mov ax,1;jmp done;above: mov ax,2;jmp done;below:mov ax,0;done:
00:11:18 <__ln__> well, actually i'm just thinking about the shortest piece of C code that would give me one of '<','=','>' characters based on the return value of strcmp or strcoll.
00:13:22 <__ln__> this isn't obviously very important.
00:14:13 <z-MaTRiX> wouldn't you want it because you want better performance?
00:15:12 <__ln__> no no, the parameter of optimization is indeed the number of characters in source code this time.
00:15:57 <Eddi|zuHause> __ln__: chr(clamp(value,-1,+1)+ord('='))
00:16:37 <Eddi|zuHause> where in C, chr and ord are NOPs
00:17:44 <__ln__> and clamp is something that would need to be defined separately
00:19:03 <Eddi|zuHause> __ln__: look in src/core/math_func.hpp
00:24:42 <__ln__> z-MaTRiX: cool, that's the winner so far
00:25:20 * Pinkbeast is a Perl programmer and we don't even bother with obfuscated code contests. :-/
00:25:43 <Pinkbeast> It would be like a contest for falling off a log
00:26:18 <Eddi|zuHause> maybe something like s&1-2*s>>31
00:26:32 <Eddi|zuHause> for -1,0,1, assuming s is 32bit
00:28:10 <Eddi|zuHause> should check operator precedence first, though
00:28:26 <__ln__> yeah, bit operations would be nice, but as far as i can imagine they need an assumption of the size.
00:30:24 <z-MaTRiX> in asm i'd use rol now
00:30:40 <__ln__> so now i have: printf("%s %c %s\n", argv[1], "<=>"[(s>=0)+(s>0)], argv[2]); which is comfortably short and elegant to add in a thesis, for example
00:30:59 <Eddi|zuHause> hm... one moment
00:31:41 <Eddi|zuHause> __ln__: i think that is needlessly complicated
00:32:35 <Eddi|zuHause> __ln__: as in ascii, <=> are neighbours, so you can just use '='+1 and '='-1
00:33:21 <Eddi|zuHause> or save one character by writing 61 instead of '='
00:34:16 <Eddi|zuHause> yeah, they weren't so bright :p
00:35:21 <Eddi|zuHause> peter1138: but good luck compiling your ascii-encoded c-file on that one :p
00:35:30 <z-MaTRiX> so write char "$3c+(s>=0)+(s>0)"
00:37:18 *** LordAro has joined #openttd
00:38:05 <Eddi|zuHause> how about: "61+s&0-(s<0)"?
00:38:36 <Eddi|zuHause> hm, might have some "odd" results
00:38:54 <Eddi|zuHause> that one's wrong
00:40:01 <Eddi|zuHause> need to stay at "61+(s>0)-(s<0)"
00:40:18 <Eddi|zuHause> comparison operators are "bad" because of the needed parentheses
00:41:35 <Eddi|zuHause> __ln__: is that an acceptable solution?
00:42:13 <z-MaTRiX> seems short enough for me
00:42:30 <Eddi|zuHause> "<=>"[(s>=0)+(s>0)] == 19 chars, 61+(s>0)-(s<0) = 14 chars
00:42:36 <__ln__> Eddi|zuHause: sure, it's self-contained and short.
00:43:10 <Eddi|zuHause> well, it does rely on the assumption of ascii
00:43:55 <z-MaTRiX> otherwise you need to include an ascii table
00:47:36 <z-MaTRiX> i'm willing to include an ascii font set in my SDL.h for basic text output ;/
00:47:54 <z-MaTRiX> i'd prefer the one from my bios
00:49:01 <z-MaTRiX> it'd be cool to detect x86 at program start, and use x86 optimized inline ASM code for outputting text then to graphic sreen
00:49:40 <Eddi|zuHause> that's the compiler's job
00:49:45 <z-MaTRiX> why not? bit manipulations in C in a loop?
00:50:25 <Eddi|zuHause> that's still the compiler's job
00:51:06 <__ln__> z-MaTRiX: what does "detect x86 at program start" mean actually... your program is compiled for ARM, and then it suddenly detects it's been ran on an x86 (which isn't possible), and utilizes x86-optimized code?
00:51:13 <z-MaTRiX> but its a low level function and could take adventage of optimization
00:51:43 <Eddi|zuHause> then you need to teach the compiler to do these optimisations
00:52:28 <peter1138> computer graphic subsystems haven't been that low-level for years
00:52:59 <Eddi|zuHause> you would not program a game this way since the mid 90's
00:53:21 <z-MaTRiX> well i was only talking about the outputting of 8x5 pixel fonts
00:53:44 <z-MaTRiX> that only needs 5 bytes / character
00:54:23 <__ln__> and that's the thing that needs optimization the most?
00:54:46 <Eddi|zuHause> "i use a graphical abstraction layer to override the abstraction by directly outputting to video memory"
00:55:01 <Eddi|zuHause> i'm sure you trigger a dozen antipatterns by that :p
00:55:40 <z-MaTRiX> ok the virtual framebuffer may be inefficient too. so?
00:56:07 <z-MaTRiX> i shouldn't optimize anything and just "make it work" ?
00:56:42 <Eddi|zuHause> z-MaTRiX: the order is "make it work" => "profile it" => "optimize the most significant parts"
00:56:50 <z-MaTRiX> it seems to me that bit operations are not the strength of C
00:57:50 <peter1138> ok, 823 sprites in this "32bit megapack"
00:57:54 <peter1138> that seems somewhat of a shortfall
00:57:55 <Eddi|zuHause> z-MaTRiX: of course writing C is going to be bad if you're an ASM programmer.
00:58:24 <z-MaTRiX> Eddi|zuHause<< i can take some compromises
00:58:45 <z-MaTRiX> but i will still optimize my putpixel.
00:58:51 <Eddi|zuHause> z-MaTRiX: likewise your C code will be bad if you're a Haskell programmer
00:59:29 <z-MaTRiX> depends on what you want
00:59:31 <Eddi|zuHause> just from the complete opposite direction
00:59:47 <z-MaTRiX> i've been at both extremes
00:59:50 <__ln__> a compiler can generate different code for different processors even, can you?
01:00:30 <Eddi|zuHause> __ln__: yes. it can even dynamically switch on processor type, if you set it the right way
01:01:16 <__ln__> indeed, i was referring to different code within the same binary
01:01:30 <z-MaTRiX> that'd be interesting :)
01:01:47 <peter1138> oh. hmm. there are sprites that have 32bpp replacements showing up as 8bpp only :S
01:03:06 <z-MaTRiX> __ln__<< well it might need recompiling though ;<
01:03:16 <peter1138> ,.......,.......if (height > UINT8_MAX || width > UINT16_MAX) {
01:04:50 <z-MaTRiX> it'd be like ifdef x86 ... putpixel_x86 endif ...
01:05:09 <z-MaTRiX> and still be portable
01:06:10 <__ln__> putpixel_arm could be a bit trickier to do
01:06:14 <Eddi|zuHause> peter1138: that sounds evil
01:06:29 <z-MaTRiX> willing to do that if i'll have an arm :)
01:08:16 <peter1138> putpixel -> buffer[x+y*pitch] = value
01:08:28 <peter1138> obviously you keep y*pitch around if you're drawing lots on the same line
01:08:46 <peter1138> do you think specific assembly will help you with that?
01:09:27 <__ln__> i bet a lot of ARMs don't have any kind of graphics controller, and even within those that do, its specs vary a lot.
01:09:35 <Eddi|zuHause> inline putpixel, and the compiler will likely result in waaaay better assembly that you could ever come up with
01:10:13 <Eddi|zuHause> like some evil MMX or SSE call
01:10:21 <peter1138> __ln__, modern smartphones do, i guess
01:10:51 <Eddi|zuHause> __ln__: but SDL covers all that
01:10:56 <z-MaTRiX> i have not done any benchmark on it
01:11:12 <z-MaTRiX> anyway i did meant DDE2 code for optimizations.
01:11:18 <peter1138> of course, pixel pushing always comes down to setting a value in a buffer, whether that's video memory or some system memory buffer
01:11:46 <__ln__> Eddi|zuHause: but i suppose SDL covers that through some OS abstraction layer, which isn't optimal.
01:11:58 <z-MaTRiX> and it will surely improve matrix transformation speeds.
01:12:04 <Eddi|zuHause> __ln__: yes, we pointed that out already
01:12:49 <peter1138> bbc micro had a 'fun' memory layout for the screen
01:12:52 <z-MaTRiX> i believe SSE2 code has to be hand written.
01:13:07 <z-MaTRiX> gcc does not optimize for that
01:13:36 <Eddi|zuHause> z-MaTRiX: and is tha belief based on any data?
01:14:18 <Eddi|zuHause> z-MaTRiX: it won't if you put "-m i386"
01:14:20 <z-MaTRiX> Eddi|zuHause<< well, have you used SSE2 before?
01:14:55 <z-MaTRiX> single instruction multiple data
01:15:04 <z-MaTRiX> parallel computing #1
01:15:21 <z-MaTRiX> but still, core functions
01:15:35 <Eddi|zuHause> z-MaTRiX: that's an obvious optimization when you do loop-unfolding
01:15:48 <Eddi|zuHause> why wouldn't GCC do that?
01:16:35 <Eddi|zuHause> and there's other compilers, like icc
01:17:16 <z-MaTRiX> yeah i have seen compilers for $10000+
01:17:36 <z-MaTRiX> doing some insane optimizations
01:18:21 <z-MaTRiX> i'm not argueing with making a monkey drawing
01:18:38 <z-MaTRiX> or painting some art
01:19:11 <z-MaTRiX> it's probably straight-forward
01:26:22 <z-MaTRiX> they say in-theory gcc can optimize using SSE2
01:36:11 <peter1138> heh, never noticed that, original trains are drawn 2 pixels too low in the horizontal view
01:36:41 <peter1138> oh what have i unleashed? :S
01:37:32 <Eddi|zuHause> yes, that's why practically every set has a depot offset of 2
01:55:50 *** supermop_ has joined #openttd
03:12:22 <z-MaTRiX> [010246] __ln__ is this the shortest way to map {<0,0,>0} to {0,1,2}: (s<0)?0:(s>0)?2:1 (we can imagine s is a return value by strcmp, for example)
03:12:36 <z-MaTRiX> btw it was overcomplicated from the beginning
03:16:38 <z-MaTRiX> (s<0)?"<":(s>0)?">":"="
03:18:33 <z-MaTRiX> seems to be the most logical approach
03:21:17 <Eddi|zuHause> but the question was not "logical"
03:32:59 <Jerik> Can anyone help me with how to design a good reversal?
03:33:28 <Jerik> As in, say I have a line linking A-B-C-D
03:34:00 <Jerik> How to I get a train to just loop in B and C without travelling all the way around to A and D
03:34:10 <Jerik> This is assuming a two-way line
03:34:50 <Eddi|zuHause> you need to enable the difficulty setting: allow reversing in stations
03:35:40 <Jerik> Yeah, is there a good way without doing that?
03:35:53 <Jerik> So that my stations can all be Roro's
03:36:37 <Eddi|zuHause> never tried that
03:37:32 <Eddi|zuHause> but you'll just need a track that runs around the station, which may be tricky depending on size
03:37:54 <Jerik> I've been trying to put a depot between the lines
03:37:58 <Jerik> And then run tunnels under
03:38:09 <Jerik> But I feel like that just destroys efficiency
03:38:23 <Eddi|zuHause> or you run through the station twice, with "no loading" orders
03:39:31 <Eddi|zuHause> so arrival and departure will be on different platforms
04:24:31 *** LordPixaII has joined #openttd
04:43:02 *** supermop_ has left #openttd
05:56:22 *** Eddi|zuHause has joined #openttd
07:09:32 *** Cybertinus has joined #openttd
07:36:40 *** DayDreamer has joined #openttd
08:00:42 *** Alberth has joined #openttd
08:00:42 *** ChanServ sets mode: +o Alberth
08:05:58 *** sla_ro|master has joined #openttd
08:19:44 *** Progman has joined #openttd
08:20:13 <peter1138> why do they make so many different types for the same thing :(
08:20:24 <peter1138> TRPD transrapid track Transrapid track type
08:21:21 <Xaroth> I think XKCD made a nice comic about that one
08:29:49 <planetmaker> peter1138: the use of railtypes is not quite clearly defined: should it unique per track type or unique per "traction" type
08:30:03 <planetmaker> where traction is broader as to also distinguish speed or axle weight
08:30:36 <peter1138> planetmaker, the slow/med/fast stuff is all fine
08:31:15 <peter1138> but the DB*/TRPD/FR* stuff is plain unnecessary
08:33:57 <peter1138> and the MTR* stuff is all a horrible hack
08:34:03 <planetmaker> though the db* stuff is supposed to rather represent an axle weight scheme - thus there might be some sense. As there is some sense for NG labels
08:34:27 <peter1138> narrow gauge, definitely
08:35:30 <planetmaker> all the FR* are supposed to be NG
08:36:00 <planetmaker> thus "wrong" labels
08:36:28 <planetmaker> but if we wanted a use of RT labels similar to cargo labels, we'd have to define a somewhat canonical ensemble of labels to be used
08:37:01 <planetmaker> and not let every track author define his or her own.
08:40:06 <planetmaker> hehe, yeah, that's a good one
08:40:26 <planetmaker> peter1138: the "problem" is that railtypes can be used as
08:40:38 <planetmaker> a) just an internal name w/o much meaning and using the compatible railtype list
08:41:02 <planetmaker> b) as a semi-canonical label which defines tracks which somewhat match what the label stands for
08:42:35 <planetmaker> there was an idea of the property of an "equivalent" railtype label list
08:42:52 <planetmaker> which gives vehicle sets the chance to focus on a somewhat canonical subset
08:44:36 <peter1138> did we ever have a weight limit property?
08:44:55 <peter1138> i don't think it could work actually, heh
08:45:53 <peter1138> hmm, only as an average
08:46:23 <peter1138> and then loading algorithms would need adjusting... god... no...
08:46:45 <planetmaker> there's no such property, no
08:46:59 <planetmaker> it'd need support by vehicles in the first place
08:47:16 <planetmaker> but can still be done with a trainset which supports the appropriate labels
08:53:58 *** Celestar has joined #openttd
08:57:30 <peter1138> anyone fancy add zoom in/out buttons to the sprite viewer? :)
09:05:40 *** Celestar has joined #openttd
09:07:44 *** rhaeder has joined #openttd
09:08:11 <planetmaker> peter1138: the sprite aligner is also a bit broken... I need to click 4x to have the sprite move 1px at normal zoom level
09:08:21 <planetmaker> while the number goes up with each click
09:08:36 <planetmaker> (it shows the zoomed-in sprites for 4x though
09:08:55 <peter1138> planetmaker, yeah the alignment is for 4x sprites
09:09:07 <peter1138> i'm wondering about alignment now, though
09:09:17 <planetmaker> imho it should be for the current zoom-level
09:09:28 <planetmaker> no zoom-selector then needed
09:09:38 <planetmaker> aligning a sprite of a non-active zoom-level seems stupid
09:09:55 <peter1138> zoom level of which viewport ;)
09:11:14 <peter1138> wondering how per-zoom level sprite size/offsets would work
09:12:14 <Celestar> where was the option to reverse mouse scrolling
09:12:56 <peter1138> interface -> interaction
09:23:28 <peter1138> heh, these 32bpp-ez sprites have incorrect palettes for the mask sprites
09:31:43 <planetmaker> what? that EJ fails on reading comprehension?
09:32:08 <planetmaker> hm... or is he right after all? :-)
09:33:42 <peter1138> eh, i meant the original post. hmm.
09:35:38 <planetmaker> hm, the OP writes TTD, not OpenTTD. Maybe EJ is right after all :-)
09:35:50 <planetmaker> never underestimate stupidity, it seems
09:41:50 <Alberth> appe: look at the initial letters of the name of the final post author
09:42:40 <appe> you have the cutest forum on the web.
09:43:09 *** tokai|noir has joined #openttd
10:17:21 *** Phoenix_the_II has quit IRC
10:57:45 *** andythenorth has joined #openttd
10:58:53 <planetmaker> salut andythenorth
10:59:38 <planetmaker> I'm afraid the worst assumption in that thread was right, peter1138 ;-)
11:09:37 <peter1138> hmm, resizable spriteviewer window?
11:10:02 <planetmaker> peter1138: why resizable?
11:10:12 <peter1138> cos 4x sprites don't fit :p
11:10:23 <peter1138> well, not too important
11:11:22 <planetmaker> seems like an off-by-one-day, lugo ;-)
11:12:01 *** Zeknurn has joined #openttd
11:18:47 <TrueBrain> I have no clue what so ever. The CF puts the right date in the file, and during transfer I receive a file of a day earlier
11:20:07 <dihedral> ... because summer time is exactly one day, not one hour ...
11:21:23 <Alberth> someone has been playing with a time machine :p
11:21:42 <TrueBrain> the odd part is that finger is correct .. which is also deduced from the same information
11:22:31 *** KenjiE20 has joined #openttd
11:22:56 <Alberth> that would point to the FS info being correct, imho
11:23:49 <Alberth> timezone of the website?
11:28:02 <Alberth> you need only -20 or so
11:28:09 <TrueBrain> no, it is exactly -24
11:28:45 <TrueBrain> added some debug statements, we will see tonight what it thinks it is doing :P
11:29:10 * Alberth keeps fingers X-ed tonight
11:29:45 <planetmaker> meh... just recreated an hour-long a patch which I thought I had lost. And now I find it :S
11:30:36 <TrueBrain> it seems it takes the relased.txt of last night, which would be odd .. meh, we will see
11:30:44 <TrueBrain> poor planetmaker :(
11:32:36 <peter1138> is the recreation better?
11:34:20 <planetmaker> they're identical except some variable names
11:34:39 <planetmaker> I still knew quite exactly what I needed / was looking for
11:35:17 <CIA-6> OpenTTD: truebrain * r23323 /trunk/src/town_cmd.cpp: -Fix: when you fund a town, it should grow; goals reached or not
11:40:31 * andythenorth had some thoughts about industries and GS
11:40:43 <andythenorth> there is some stuff that really should be delegated to GS, e.g. closure
11:42:46 *** Br33z4hSlut5 has joined #openttd
11:44:57 <planetmaker> andythenorth: we had the idea to introduce a callback for industries for that purpose
11:45:38 <andythenorth> some parts of industries need to be a black box (e.g. production)
11:45:44 <andythenorth> or we need to move to industry code being provided by GS rather than newgrf
11:45:47 <CIA-6> OpenTTD: peter1138 * r23324 /trunk/src/spriteloader/grf.cpp: -Fix (r15555): Don't free reusable buffer.
11:45:49 <andythenorth> which might be better long term
11:46:00 <andythenorth> a goal script *should* be able to control industry production
11:46:10 <andythenorth> but currently that's insane
11:46:15 <TrueBrain> it would be nice if it can *hint* increase/decrease
11:46:51 <andythenorth> industries are quite a detailed problem
11:47:21 <TrueBrain> but given the amount of shit already in newgrfs, it would be (kinda) impossible to make it more than hinting :)
11:47:52 <andythenorth> so break newgrfs
11:47:57 * andythenorth doesn't care about breaking newgrfs
11:48:15 <TrueBrain> sadly, you are not the only grf author :P
11:48:15 <andythenorth> newgrfs are fragile because the APIs are fragile in place
11:48:22 <andythenorth> we can't fix the APIs without breaking stuff
11:48:40 <peter1138> industry classes...
11:48:41 <andythenorth> fortunately I am not the only grf author :P
12:27:25 *** LordPixaII is now known as Pixa
12:31:42 <peter1138> these CETS wagons turn a bit oddly
12:31:56 <peter1138> i guess due to michi's changes?
12:35:27 <michi_cc> peter1138: Probably. The graphic offsets were quite specifically tuned to the old behaviour.
12:52:24 <planetmaker> the zoom levels are really nice, peter1138 :-)
12:52:38 <planetmaker> just makes me find many small sprite glitches :-(
12:56:08 <peter1138> minor sorting/position issues or hugely in the wrong place issues? heh
12:56:12 <Alberth> a fresh pair of eyes sees many errors :)
13:01:39 <CIA-6> OpenTTD: peter1138 * r23325 /trunk/src/screenshot.cpp: -Fix (r23316): World screenshot was incorrectly positioned.
13:02:55 <planetmaker> peter1138: mostly I found some small position errors. But also that the animations of industries differ in pixels where they shouldn't
13:03:06 <planetmaker> It doesn't show on normal zoom. But looks funky when zoomed in
13:03:22 <planetmaker> like the animation of the coal mine shaft
13:03:28 <peter1138> yeah, some things are known wrong, i'm working on them :)
13:03:54 <planetmaker> not your fault. It's all sprites what I meant
13:04:26 <planetmaker> look at the opengfx coalmine for example
13:04:35 <planetmaker> There are pixels changing colour slightly which should not
13:04:51 <planetmaker> it didn't really show before, though. At least not to me
13:05:18 <planetmaker> same with basically all other animations
13:06:55 <peter1138> even so, there are some offsets that are wrong still :)
13:09:02 <peter1138> Trunk uses 32bpp sprites just fine. Same as it does for years. Literally.
13:45:10 *** TomyLobo2 has joined #openttd
13:48:34 <peter1138> does nml understand 32bpp pngs?
13:48:49 <peter1138> as in for openttd to load, not to compile into the newgrf
13:50:58 <Hirundo> NML supports 32bpp, it used to work for both normal and EZ sprites
13:51:02 *** TomyLobo2 is now known as TomyLobo
13:52:07 <planetmaker> it's mostly untested, though
13:54:45 <Hirundo> I don't know if NML needs changing after the recent changes to ottd
13:56:08 <Eddi|zuHause> <peter1138> these CETS wagons turn a bit oddly <-- haven't gotten around to adjusting it yet
13:56:50 <Eddi|zuHause> possibly i need to completely revamp the "slicing" system
13:56:51 <andythenorth> wrt to industries and GS
13:56:54 <planetmaker> Hirundo: so far wrt sprite handling nothing changed
13:57:00 <andythenorth> we probably need to look at how GS can influence:
13:57:07 <planetmaker> no new zoom level sprites yet accepted
13:57:09 <andythenorth> - production multiplier
13:57:15 <andythenorth> - automatic production multiplier handling
13:57:56 <andythenorth> - cb28 (but probably not 2f)
13:58:31 * andythenorth needs to have a think.
13:58:56 <andythenorth> newgrf industries *should* be able to cede a reasonable amount of control to GS, but it needs a clean boundary
14:00:09 <Alberth> 'need more/less cargo X' ?
14:01:37 <Eddi|zuHause> maybe we should scratch the idea of changing industry production, since the GameScript has no idea what the cargos actually represent
14:01:42 <Alberth> adjustment of probabilities?
14:01:53 <andythenorth> Eddi|zuHause: +1
14:02:05 <andythenorth> unless game scripts are tied to a specific newgrf...
14:02:09 <andythenorth> which they could be
14:02:34 <Eddi|zuHause> andythenorth: which will horribly break once you have different versions of the game script and the newgrf
14:03:01 <Noldo> how concrete is that thing?
14:04:58 <andythenorth> Eddi|zuHause: agreed
14:05:17 <Alberth> Eddi|zuHause: place of building is a scenario thing, isn't it?
14:05:27 <andythenorth> it's also incredibly tiresome if every GS has to try and fix industry closure
14:05:33 <andythenorth> which is currently broken
14:06:04 <Eddi|zuHause> Alberth: yes, but scenario editor can only do initial placement, the rest is up to the game script
14:06:09 <planetmaker> why is it broken, andythenorth?
14:06:29 <andythenorth> planetmaker: have you experienced mass closure ever? :)
14:06:53 <Alberth> Eddi|zuHause: I was thinking to define areas where you can create certain industries.
14:06:58 <Eddi|zuHause> Alberth: what i had in mind was e.g.: the game script marks some towns as "mining towns", and allows mines to only appear near these towns throughout the game
14:07:08 <planetmaker> I might have done so. But no, I so far had not much issue with industry closures
14:07:15 <planetmaker> with nor without newgrfs really
14:07:15 <andythenorth> Eddi|zuHause: how would it know which are mines?
14:07:24 <planetmaker> not in any annoying way at least
14:07:33 <Eddi|zuHause> andythenorth: "extractive" industries
14:07:42 <planetmaker> andythenorth: extractive type
14:07:46 <andythenorth> so go by existing prop
14:07:49 <andythenorth> makes good sense
14:08:09 <Eddi|zuHause> the station naming code has a similar calculation what constitutes a mine
14:09:16 <andythenorth> so an industry has 'proprietary' (or private) information, and 'public' information
14:09:30 <andythenorth> the code for processing has to be private
14:09:45 <Alberth> andythenorth: makes sense
14:09:51 <andythenorth> that's a black box
14:09:58 <andythenorth> from perspective of GS
14:10:00 <Belugas> sir Alberth, I salute ya
14:11:16 <Eddi|zuHause> suppose i have a TileIndex, what's the canonic way to get the X and Y coordinates (in game script)?
14:12:13 * Belugas salutes planetmaker as well :)
14:18:53 <Belugas> and Xaroth receives a salute as well
14:19:12 <V453000> hello, is there an option to disable the extra zoom levels?
14:20:04 <planetmaker> yes. in the adv. settings
14:20:34 *** TWerkhoven has joined #openttd
14:21:04 <Eddi|zuHause> ... and what's the squirrel equivalent to python's "for i, x in enumerate(list)"?
14:21:22 <Belugas> fun... new feature comes in.. how to disable it... almost the same every time
14:21:32 <Belugas> just a simple observation, not ranting
14:23:28 <Xaroth> Eddi|zuHause: foreach (i, x in list) {} ?
14:23:57 <Xaroth> Belugas: the extra zoom levels are quite.. intrusive, so I can totally understand V453000 :P
14:25:41 <Belugas> and.. i said it was an observation, not a charge against the comment ;)
14:25:55 <planetmaker> if you zoom out and then back in, you easily go past the normal zoom
14:26:09 <planetmaker> esp. when doing so via scroll wheel or guesture
14:27:39 <V453000> yes but one often zooms out to see the map, and then zoom in back. I constantly keep zooming in to 2x or 4x even instead of the desired 1x :)
14:28:00 <V453000> and in the end, the extra zoom not really useful anyhow
14:28:59 <V453000> well one could zoom in to discover some minor problems of some sprites which are normally invisible :D
14:35:41 <lugo> what about ctrl+zoom-in/out = 1x?
14:37:14 <peter1138> 1x can be an eyestrain on high resolutions, at least
14:37:20 <peter1138> and lcds suck for scaling, so...
14:37:40 <peter1138> but yes, those settings are there for a reason too :)
14:40:13 <Xaroth> well zooming max the first time does give you instant-headache on 1920x1200 :P
14:40:31 <Xaroth> but once you get used to it (and change the setting to max 2x) it's actually useful.
14:41:06 *** Prof_Frink has joined #openttd
15:02:00 *** Adambean has joined #openttd
15:05:35 <Alberth> lugo: then you immediately get requests to make the default configurable
15:55:41 *** Kurimus has joined #openttd
16:02:24 *** frosch123 has joined #openttd
16:32:45 *** TGYoshi has joined #openttd
16:44:50 *** TheMask96 has joined #openttd
16:51:59 *** sla_ro|master has joined #openttd
17:16:56 *** |Jeroen| has joined #openttd
17:34:10 <CIA-6> OpenTTD: rubidium * r23326 /trunk/src/table/gameopt_settings.ini: -Fix [FS#4852] (r23239): snow line for very old savegames wasn't retrieved from the savegame anymore
17:35:55 <Eddi|zuHause> is something like this possible in squirrel: "sign(x) == cmp(y,z)"?
17:36:45 <Eddi|zuHause> as in "if (x<0 and y<z OR x>0 and y>z)"?
17:47:32 <Zuu__> Does one of OR or AND operator have higher priority?
17:51:57 <frosch123> AND is higher than OR in boolean context
17:52:25 <frosch123> in traditional computer science as well in those programming languages i know
17:53:20 <frosch123> don't mix bitwise with logical though
18:06:50 *** HerzogDeXtEr has joined #openttd
18:15:08 <Alberth> it will be great fun debugging such a mess
18:30:10 *** mahmoud has joined #openttd
18:36:55 *** andythenorth has joined #openttd
18:37:31 * andythenorth has been...pondering GS
18:39:23 *** mahmoud has joined #openttd
18:40:37 <andythenorth> allowing GS to change industry production multiplier - yes/no?
18:41:58 <Rubidium> directly change: no, influence the NewGRF/default behaviour: yes
18:42:08 <frosch123> changing production multiplier, opening and closing towns are the things that should work from my pov
18:42:27 <frosch123> direct change should work as well, except maybe for ecs
18:42:51 <andythenorth> Rubidium: 'influence' via what mechanic?
18:42:51 <frosch123> however, gs won't be able to prevent industries from closing or altering production theirself
18:43:32 <andythenorth> I am 100% convinced that all of the production cb is out of scope for GS
18:43:34 <Rubidium> frosch123: but then you have two competing systems influencing the production, which means stuff gets much harder to figure out when it goes wrong
18:43:49 <frosch123> andythenorth: additional parameter in cb 29 or so, which gives a hint from the script
18:43:50 <andythenorth> currently the game can come by and do that anyway
18:44:06 <andythenorth> production multiplier is exposed to the game
18:45:06 <andythenorth> why not just interpret return of 04 80 as 'do whatever game or GS tries to do'
18:45:22 <andythenorth> with GS hooked to the production change
18:45:54 <CIA-6> OpenTTD: translators * r23327 /trunk/src/lang/ (8 files): (log message trimmed)
18:45:54 <CIA-6> OpenTTD: -Update from WebTranslator v3.0:
18:45:54 <CIA-6> OpenTTD: belarusian - 16 changes by KorneySan
18:45:54 <CIA-6> OpenTTD: finnish - 15 changes by jpx_
18:45:54 <CIA-6> OpenTTD: german - 8 changes by planetmaker
18:45:56 <CIA-6> OpenTTD: italian - 8 changes by lorenzodv
18:45:56 <CIA-6> OpenTTD: korean - 10 changes by junho2813
18:46:01 <andythenorth> my idea doesn't actually achieve what I have in mind for GS at all :P
18:47:03 <frosch123> changing the distribution of goods should also work. i think cargodest does that also somewhat
18:47:05 <andythenorth> my idea is that GS should be able to (quite aggressively) force primary production up or down
18:47:25 <andythenorth> frosch123: you mean cargo distributed to stations?
18:47:50 <frosch123> the relation between "cargo distributed to stations" and "station rating"
18:48:06 <frosch123> currently it is 1:1, but with cargodest it is not afaik
18:48:17 <andythenorth> that's also quite valid for newgrf to adjust - we have that code in FIRS...
18:48:40 * andythenorth could do with some kind of diagram :P
18:49:12 <andythenorth> for example, I think it's also totally valid for a GS to adjust vehicle intro dates, or reliability, or purchase costs
18:49:16 <frosch123> anyway, both cargo callback (profit and station rating) have callback flags
18:49:27 <peter1138> cargo dest in gs? :p
18:49:35 <frosch123> so we have actually a sane way to make the gs detect, whether some newgrf wants to control that
18:50:00 <frosch123> so, maybe we should just add some setting to control whether those callbacks are called, or whether the gs is caleld
18:50:12 <frosch123> i never liked those callbacks anyway :p
18:50:27 <andythenorth> they're not widely used afaik
18:50:31 <andythenorth> we only just added them to FIRS
18:51:02 <andythenorth> imho we're trying to do far too much stuff with FIRS
18:51:11 <frosch123> hmm, though profit calculation might actually not work for gs
18:51:29 <frosch123> it requires immediate response
18:51:39 <frosch123> remains station rating
18:52:35 <andythenorth> profit calculation or similar is actually something I would want to control for GS
18:52:37 <Rubidium> (and by proxy industry rating ;), influencing industry production)
18:53:27 <andythenorth> I want to provide spot price economy, which means localised control over cargo payments (or, as proxy, profits)
18:54:14 <Rubidium> I think cargo payments happens way too often and is so fine grained that anything you want to do blows up in some way or another
18:54:45 <andythenorth> can't be cached per town?
18:54:49 <Rubidium> e.g. you are paid for (basically) each bit of cargo individually (and least when transfers and such are in the picture)
18:55:54 <Rubidium> andythenorth: 32 cargos, 256 durations, ~4000 manhattan distances
18:57:04 <Rubidium> which is a big potential amount of variableness for something to cache often
18:57:27 <Rubidium> (like in a few hundred towns)
18:58:36 <Rubidium> not even talking about the effects on transfer payments (you get a lot of the first leg, but the final town says you ought to get a lot less: massive loss for the last vehicle)
18:58:49 <frosch123> hmm, gs could store some propotional factor for every cargotype at every station
18:59:01 <frosch123> so, payment on cargoage etc. is grf controlled
18:59:16 *** Devroush has joined #openttd
18:59:20 <frosch123> while gs can decide than one town pays twice as much for goods than others do unter the same conditionjs
18:59:39 <frosch123> hmm, transfers... :p
18:59:41 <Rubidium> frosch123: which brings us back to transfers
19:00:36 <Rubidium> making losses for no apparant reasons, except that the GS decided that it virtually paid a lot for delivering in B and near nothing for delivering in C
19:00:48 <Rubidium> although that can be "solved" when you know what C will be
19:01:07 <Rubidium> as then you always use C as the payment reference instead of the current station
19:01:14 <andythenorth> with town control, GS could stick something on the town, the profit cb can run from that
19:01:26 <andythenorth> transfers are always tricky :P
19:02:01 <andythenorth> as is the idea of 'every vehicle must make a profit'
19:02:19 <frosch123> well, gs should be able to control the highscore
19:03:00 <frosch123> there is no newgrf callback for highscores yet :p
19:03:19 <frosch123> or does firs fancy to use newhighscores? :p
19:03:39 <andythenorth> firs already does too much :P
19:04:04 <Rubidium> pff, let them first do HD ;)
19:04:09 <andythenorth> currently 'industry newgrf' is synonymous with 'economy newgrf'
19:05:49 *** HerzogDeXtEr1 has joined #openttd
19:07:18 <andythenorth> Rubidium: in the transfer case, why doesn't that problem happen when newgrf controls profit cb?
19:08:06 <Rubidium> it is possible that it happens there as well, but there is no location awareness
19:08:20 <Rubidium> so it will always happen
19:08:54 <Rubidium> and if it would happen, then people would be able to notice that they get significantly less for transporting stuff far away than to transport it locally
19:13:23 <andythenorth> so the 'problem' with spot price economy is that transport companies aren't paid that way
19:13:37 <andythenorth> they're paid by tonmile
19:13:49 <andythenorth> so maybe it's a bad idea. but it would be fun :P
19:14:40 <andythenorth> *dist is probably a better way of modelling supply and demand
19:16:15 <Zuu_> And faster than Squirrel.
19:18:13 <andythenorth> GS being able to influence *dist is attractive though
19:18:25 <andythenorth> or GS -> influencing town -> town influencing *dist
19:21:14 *** JVassie has joined #openttd
19:21:19 <andythenorth> dealing with industry stuff and GS is brain ache
19:25:24 * andythenorth is also wondering if FIRS 'economies' should be dropped as an idea
19:25:39 <andythenorth> and ceded to GS, via cb 22
19:27:02 <planetmaker> TrueBrain: what happens when I create a map w/o a goal script being present but then load the game with a server which has one?
19:27:59 <Zuu_> It just run rhe script I guess.
19:28:02 <andythenorth> tying GS to a specific newgrf version - that's all handled via savegame?
19:28:33 <Zuu_> Save/load is not yet implemented
19:28:46 <andythenorth> conceptually I mean
19:29:09 <andythenorth> this stuff could make a big difference to how (industry) newgrfs should be designed
19:29:35 <Zuu_> I answered pms question.
19:30:32 <planetmaker> Zuu_: that's what I figured so far, too. I just wonder... would stuff go haywire, if things are not initialized maybe on map creation?
19:31:07 * andythenorth is in a world of ponder
19:31:28 <andythenorth> how tightly bound / decoupled should GS be from specific maps / newgrfs / settings
19:32:00 <Zuu_> I say you will not get any such problems. The init code will run when the game loads.
19:32:05 * andythenorth wants to be able to play quite intricate challenges, bound to specific maps and newgrfs
19:32:10 <andythenorth> but maybe that's wrong
19:32:26 <planetmaker> andythenorth: I'd say that's most probably possible
19:32:32 <planetmaker> it will make for awesome scenarios
19:32:43 <Zuu_> Actually the GS might be unaware that it is a loaded game.
19:32:45 <planetmaker> but it will be _very_ time consuming to produce
19:32:52 <andythenorth> planetmaker: it could also make for some epic falling outs
19:33:05 <andythenorth> if for example, version of FIRS needed for a GS is not available on bananas
19:33:21 <planetmaker> theoretically possible
19:33:23 <andythenorth> goal scripts *must* be GPL?
19:33:47 <andythenorth> they execute code in same space as ottd, so they have to be GPL? Or they're a separate library?
19:34:16 <planetmaker> they're as separate as AIs
19:34:18 <Zuu_> AIs don't have to be GPL.
19:34:24 <andythenorth> you can place a bet on what I think GS licensing should be
19:35:38 <Zuu_> The difference is that AIs have AI libraries that can have a different license to the AI. For GS that is currently not.possible.
19:36:27 <Zuu_> So any GS that use SuperLib has to be GPL2.
19:45:53 <andythenorth> is GS fast enough to handle things like industry production code?
19:47:07 <frosch123> gs can generally not react on stuff in time
19:47:13 <frosch123> it can only do monthly stuff etc
19:47:24 <frosch123> not on delivery etc
19:51:56 <andythenorth> that shoots my idea in the head then
19:52:14 * andythenorth thinks industry newgrfs should cede control over nearly everything to GS
19:52:53 <andythenorth> with libraries, so each GS author doesn't have to write *everything* just to get industry support
19:54:53 <andythenorth> production code, industry window text, open/close, cb28, accepted/produced cargos, production multiplier
19:55:47 <andythenorth> station name, availability dates, fund window text, fund cost, probability
19:56:24 <andythenorth> newgrf should handle cb2f (tile restrictions) and tile (graphics) callbacks, and nothing else
19:56:57 <andythenorth> is this possible though?
20:03:28 <Alberth> industry window text? fund window text?
20:03:49 <andythenorth> nearly everything
20:04:11 <andythenorth> station name is probably immaterial
20:04:15 <andythenorth> the rest should go to GS
20:04:22 <Alberth> feels somewhat insane to me :)
20:04:51 <Alberth> tile graphics callback?
20:05:07 <andythenorth> tile graphics are a self-contained aspect of the industry
20:05:09 <Alberth> oh, sorry, read wrong
20:06:14 <Alberth> why would you have coal mine accept steel?
20:06:31 <andythenorth> because you want that for your scripted scenario?
20:06:32 <Alberth> or provide diamonds or so?
20:06:39 <andythenorth> to make interesting scripted scenarios, GS author needs control over production + open / close + location + availability
20:07:21 <andythenorth> to control production, and not have madness, you also need to control cargos (per industry via cb) and that means controlling texts
20:07:51 <Alberth> controlling cargoes is madness imho
20:08:13 <andythenorth> FIRS economies would have controlled cargos
20:08:23 <andythenorth> which means your GS might explode depending on FIRS parameters
20:08:35 <andythenorth> or GS has to have intimate knowledge of newgrf parameters
20:08:40 <andythenorth> same for ECS, not FIRS specific
20:09:36 <andythenorth> I've come up with some alternative ideas...
20:09:57 <andythenorth> newgrf could always cede control of some things to default cb result
20:10:06 <andythenorth> allowing GS to control that if GS is provided
20:10:59 <andythenorth> newgrf could have parameters for use with any GS, (or specific GS) - but parameters are generally crappy
20:11:04 <Alberth> imho either you make a special combination of firs & gs, or you make a much more general gs
20:11:27 <Alberth> in the latter case, assume you have both
20:12:30 <Alberth> if you want cargoes tricks, imho the newgrf should supply them, not the gs
20:14:18 * andythenorth thinks it gets a lot more interesting when GS authors can do things like:
20:14:30 <andythenorth> - "this mine will produce a lot of stuff"
20:14:45 <andythenorth> - "this steel mill will close in 1970, no matter what you do"
20:14:45 <frosch123> andythenorth: you lose any industry specific behaviour that way
20:15:12 <frosch123> the latter required the script to actually distinguish mines and steelmills
20:15:32 * andythenorth should read current GS docs :P
20:15:32 <frosch123> you get problems like cargos with vehicles :p
20:15:59 <andythenorth> so can a GS identify an industry type (by ID)?
20:17:28 * andythenorth finds the docs :)
20:17:33 <frosch123> scripts are completely decoupled from newgrfs
20:17:54 <frosch123> they are not even supposed to know cargolabels, though they can read them for 'display purposes'
20:19:24 <andythenorth> how 'done' is town control? I've seen commits for it, but I don't trust my assumptions
20:19:50 <frosch123> newgrf town control? or gs town control?
20:20:05 <andythenorth> newgrf - we got stuck on persistent storage question? Or is that solved?
20:20:18 <frosch123> that's the only part that was implemented :p
20:20:27 <frosch123> though you cannot write to storage of other grfs
20:20:34 <frosch123> (which is not too limiting)
20:20:35 <andythenorth> could GS write to storage?
20:21:05 <andythenorth> or have it's own storage that grfs can read
20:21:46 <frosch123> "could"? the question is rather whether that would be "good" at all
20:22:05 <andythenorth> maybe I explain my aim, rather than guessing implementations :P
20:22:26 <andythenorth> so it seems best that industries are pretty much a black box to GS?
20:22:41 <andythenorth> i.e. GS can't know much about the internals of an industry, as it's very decoupled
20:23:23 <andythenorth> that rules out nearly everything where a GS might touch an industry
20:23:48 <andythenorth> even cb 28 and such might be unwise if GS doesn't know about industry
20:24:01 <andythenorth> but industry and GS could communicate predictably using town
20:24:19 <andythenorth> if industry newgrf had a spec for how it will behave according to certain town storage values
20:24:32 <andythenorth> GS could produce predictable and interesting results
20:24:59 <andythenorth> 'town' is probably a fine-grained enough level of detail for gameplay
20:27:43 <andythenorth> there would be some gaps
20:28:13 <andythenorth> like the GS might be trying to control number of coal mines in a town (based on knowing about a specific newgrf), but that still wouldn't be possible
20:28:56 <andythenorth> but the industry could write the number of coal mines to town storage when cb 28 runs
20:29:28 <andythenorth> the industry could also do a lot of the other interesting stuff, like store cargo delivered etc
20:29:35 <andythenorth> this assumes storage isn't limited :P
20:29:41 <Terkhen> andythenorth: GS should not have access to the standard town / industry storage... but you could add special storages with a specific, fixed format and meaning to enable communication between NewGRFs and GS
20:30:06 <andythenorth> it's an appealing idea
20:31:11 <Terkhen> the default NewGRF storages have no fixed format, therefore all GS would need specific support for each NewGRF
20:31:14 <Terkhen> that would be madness :)
20:31:28 <andythenorth> no more madness than cargo classes
20:31:59 <Terkhen> a lot more actually ;)
20:31:59 <andythenorth> is what I'm describing asynchronous signalling?
20:32:31 <andythenorth> seems like there would separate GS and newgrf storage for each newgrf
20:32:49 <andythenorth> each can read but not write to the others
20:36:41 <andythenorth> rather than GS being able to control industries, it can leave hints behind, and if the hint is in the right place, the industry will do something predictable with it
20:36:56 <andythenorth> what each newgrf does is up to the newgrf authors
20:37:26 <andythenorth> any intricate GS though will be tightly bound to a single industry newgrf (nothing else makes sense)
20:37:44 *** HerzogDeXtEr has joined #openttd
20:46:28 <andythenorth> can we add 'monologue by andythenorth' to the topic please?
20:50:43 <guru3_> anyone know anything about 32bpp?
20:50:47 *** guru3_ is now known as guru3
20:55:41 <planetmaker> it's 4x as much memory as 8bpp ;-)
20:59:08 <andythenorth> Terkhen: there would be one town storage for each newgrf?
21:09:37 <frosch123> you can read the storages of other grfs
21:10:42 <andythenorth> I had an idea for a scheme with multiple storages per newgrf
21:10:54 <andythenorth> with the offsets corresponding to industry or cargo IDs :P
21:11:04 <andythenorth> for convenience :P
21:26:01 <Terkhen> andythenorth: each NewGRF has write access to a single town persistent storage, and has read access to all of them
21:26:21 * andythenorth should stop inventing complex schemes :P
21:26:43 <andythenorth> Terkhen: did you move yet?
21:31:33 <Terkhen> fine, I'm still getting accustomed, everything is different at a big city :P
21:33:54 <Belugas> yeah, no more sheep running around :)
21:34:09 <Terkhen> my hometown is not that small :P
21:34:46 <TrueBrain> planetmaker: atm scripts are not stored with the savegame, and are forced loaded upon game start; warning: loading a savegame gives an unwanted initial delay in the setup of the script
21:35:01 <Belugas> hehehe joking, Terkhen
21:48:25 <planetmaker> hm, thx, TrueBrain
21:49:21 <TrueBrain> it is best to start a newgame atm :)
21:54:08 *** LordAro has joined #openttd
21:58:20 *** valhallasw has joined #openttd
22:09:42 <andythenorth> dunno what use those vehicles would be :P
22:09:50 <andythenorth> zero gameplay advantage ;)
22:10:12 <peter1138> the last one looks ... well...
22:10:42 <peter1138> something from the 50s, in a "this is what the future will look like" way
22:10:54 <andythenorth> ...like a good case for roadtypes?
22:14:04 <andythenorth> I was going to add that to heqs
22:14:11 <andythenorth> but really....pointless :P
22:17:23 <andythenorth> can a GS build new objects?
22:20:01 <andythenorth> so...a GS could open / close certain numbers of industries in a town
22:20:11 <andythenorth> using special one tile industries
22:20:30 <andythenorth> 'proper' industries could then use industry count in the town as a var to control behaviour
22:20:44 <andythenorth> so basically using the map as storage to communicate between GS and industry
22:21:39 <andythenorth> the GS could also communicate directly with a specific industry by building 'special' industry types on neighbouring tiles, and the industry checking those
22:22:08 <andythenorth> GS would need to be able to use magic bulldozer in that second case
22:22:45 <andythenorth> GS could also raise and lower land around an industry as a means of storing values
22:23:08 <andythenorth> to allow GS to control industry
22:23:08 <Xaroth> I mean.. GS doesn't need to raise/lower to store anything :P
22:23:56 <Xaroth> or it can call a specific callback?
22:24:23 <Xaroth> I'm not really a fan of using hack-ish workarounds when you can do it properly
22:24:26 <andythenorth> industry newgrf could define behaviour, like 'raise one corner of tile next to N tile of industry for production multiplier 8' or such
22:24:48 <andythenorth> lower 3 corners of N tile to close industry
22:24:49 <Xaroth> why interact with the game
22:24:56 <Xaroth> if you can interact directly?
22:25:59 <Xaroth> that's like placing a pink hippo in your neighbours garden to inform them their dog was barking again last night
22:26:10 <Xaroth> sure, with some magic sekrit language they'd understand
22:26:20 <Xaroth> but.. what's wrong with going 'yo, dog was barking again last night'
22:26:52 * andythenorth visits newgrf spec
22:27:06 * andythenorth wonders what else towns can do
22:27:36 <andythenorth> hmm, varaction 2 is a bit limited wrt towns
22:28:29 <andythenorth> encoding information via the slope bits would be best
22:29:35 <andythenorth> although I also like the idea of constructing specific industries
22:30:07 <andythenorth> var 68 can use layout numbers
22:30:17 <andythenorth> that's a lot of potential data....
22:31:27 <Xaroth> it all sounds wonderful and stuff, but I still don't see the point in doing visual (as minimal as they be) changes ingame, to allow for backend communication
22:31:38 * andythenorth ponders....an industry can have 255 layouts
22:31:59 <andythenorth> but it would probably make more sense to treat the number as a bitmask
22:32:13 <andythenorth> which gives...rather fewer values
22:33:54 <andythenorth> Xaroth: the aim would be to allow GS to control industries
22:34:20 <frosch123> Xaroth: luckily andy's set are all gpl. so if the ruins them, we can branch off :p
22:34:32 <Xaroth> frosch123: thank fook for that :P
22:34:44 <andythenorth> frosch123: you don't like my idea of communicating via stuff on the map? :P
22:34:59 <Xaroth> andythenorth: but surely you must see the insanity of using top-level stuff to communicate low-level information?
22:35:42 <Xaroth> then you need a sanitycheck :P
22:35:55 <andythenorth> frosch123: does var 68 allow both layout *and* town check?
22:36:01 <andythenorth> spec implies it does
22:36:50 <andythenorth> 64 industry types are not enough for this scheme
22:36:56 <andythenorth> rather more would be needed
22:38:06 <frosch123> andythenorth: i would read it like that, yes
22:38:09 <andythenorth> for a set with 64 'real' types, that gives 15 bytes of storage per industry type
22:38:25 <andythenorth> the 'storage' industries could look like houses or such
22:38:53 <frosch123> something different
22:39:14 <frosch123> on the front page of the specswiki: i keep on clicking the the features in the wrong tables
22:39:23 <frosch123> so i get to action2 instead of varaction2
22:40:02 <frosch123> is it a good idea to add a huge "0", "2", "VA", "R" and "3" to the tables
22:40:06 <frosch123> (i.e. spanning 4 rows)
22:40:18 <andythenorth> frosch123: looks like a layout issue to me
22:40:21 <frosch123> or is it only me who misclcks?
22:40:33 <andythenorth> the gap between table and title is the same for preceeding and following
22:40:59 <andythenorth> i.e. there should be a larger gap between a table and the following title
22:41:56 <andythenorth> wiki formatting :(
22:41:58 <frosch123> i think empty rows would make it look weird
22:42:19 <andythenorth> I can only fix it with an empty list bullet
22:42:30 <andythenorth> wiki formatting is remarkably stupid
22:42:46 <andythenorth> in the quest to make it easy for idiots, they made it harder for normal people
22:42:49 <planetmaker> frosch123: it's not only you who mis-clicks
22:42:52 <frosch123> just add an empty line?
22:43:08 <andythenorth> wiki formatting allows an empty line? which magic characters do I press :P
22:44:47 <andythenorth> <br /> is not only allowed, but recommended :P
22:44:55 <andythenorth> frosch123: try now
22:45:10 <andythenorth> might help, might not
22:47:03 <andythenorth> I only added one <br />
22:49:48 <Mazur> That sounds utterly stupid, andythenorth, are you sure?
22:50:02 <Mazur> <br> is a thing in and of itself, begin and end in one.
22:50:38 <andythenorth> I mean I just added it once
22:51:14 <andythenorth> mediawiki prefers xhtml
22:51:19 <Mazur> <BR> is a break in a line, bypassing automatic formatting.
22:51:31 <andythenorth> I'm just surprised it works at all
22:52:45 <Mazur> It might simply have been added to pacify the kind of people who use Macro$hit products and take every tag needs an end-tag too literally.]
22:52:57 <andythenorth> Mazur: that's a bit wrong
22:53:01 <andythenorth> for various reasons
22:53:29 <Mazur> Only one bit? I must be sickening or something.
22:53:32 <andythenorth> but anyway, I'm surprised that mediawiki respects any html / xhtml at al
22:53:34 <frosch123> andythenorth: the empty line looks weird, but i like the bold number in a separate column :)
22:53:43 <andythenorth> frosch123: I was going to revert my change
22:53:46 <andythenorth> it was only a test
22:53:53 <frosch123> i reverted it already :p
22:54:30 <Xaroth> Mazur: obviously you missed out on the xml spec?
22:55:08 <Xaroth> a <br /> is just a br element with no content
22:55:16 <frosch123> what? who added a link to the nml-specs in the "game mechanics" section?
22:55:37 <andythenorth> someone well meaning?
22:55:47 <andythenorth> but perhaps mistaken?
22:56:05 <Xaroth> it's also the same reason you should close an img tag, and a hr, and several others
22:56:06 <frosch123> planetmaker did, but i cannot ask him anymore whether he really wanted it in that place
22:56:21 <Mazur> Xaroth, yep, never laid eyes on it, perhaps never will.
22:57:07 <andythenorth> Xaroth: try closing an <a name="foo"/> :P
22:57:11 <andythenorth> for explodey results
22:57:14 <planetmaker> frosch123: looks stupid there. Feel free to revert. ;-)
22:57:31 <Xaroth> andythenorth: that doesn't work, the <a> isn't 'empty'
22:57:38 <andythenorth> I always try it for a named anchor
22:57:41 <andythenorth> with explodey results
22:57:54 <Xaroth> you anchor to a piece of content
22:57:59 <Xaroth> so you should include content in it.
22:58:03 <andythenorth> <form /> would also be witty :P
22:58:12 <peter1138> iirc those anchers are deprecated now
22:58:29 <andythenorth> there's probably a specific html 5 tag for them :P
22:58:43 <andythenorth> 'everything must be semantically perfect'
22:59:01 <peter1138> html 5, the one where they removed the xml-ness because muppets found it too hard
22:59:12 <Xaroth> html 5 looks at id=<x>
22:59:29 <Xaroth> so <div id="foo" > is linkable by page.html#foo
22:59:38 <andythenorth> that is interesting
22:59:45 <Xaroth> that's been around for ages :P
23:00:01 * andythenorth lives in a world where IE 6 support still matters
23:00:11 <peter1138> i always end up forgetting that input fields need name= instead of id=
23:00:22 <andythenorth> we don't move to new standards quickly
23:01:16 <andythenorth> html 5 seems to be spawning tags merrily from my limited knowledge of it
23:01:58 <Xaroth> and iirc, IE6 might even support the id=foo method.
23:02:14 <Xaroth> don't care though, I'm long glad I don't have to do ie-compatible crap :P
23:02:27 * andythenorth will try it next time
23:02:34 <andythenorth> named anchors are odd
23:02:41 <CIA-6> OpenTTD: peter1138 * r23328 /trunk/src/vehicle.cpp: -Change: Make the viewport vehicle position hash cover the same area.
23:03:17 * andythenorth has finally learnt something new today :)
23:03:36 <andythenorth> also that means that named anchors could collide with ids
23:03:43 <andythenorth> so one more reason to not use them
23:04:34 <andythenorth> Xaroth: using the ottd map for industry communication seems no more insane to me than ajax apps which use lists with display:none as data storage :P
23:04:39 <andythenorth> which I have seen done
23:06:19 <CIA-6> OpenTTD: peter1138 * r23329 /trunk/src/ (viewport.cpp viewport_func.h): -Fix (r23316): Scale child sprite pixel offsets unless told not to. Fixes lifts and industry graphics.
23:06:54 <peter1138> named anchors could collide with named anchors
23:07:01 <peter1138> seeing as name="" isn't unique
23:07:19 <andythenorth> named anchors suck
23:07:24 <Xaroth> andythenorth: sometimes you can combine that with compatibility for javascript-less clients
23:07:26 <andythenorth> I'm going to war with them on monda
23:08:24 <Xaroth> like a filtered display, for non-js clients they just see the entire list, where javascript-enabled clients can apply filters to only see a subset of the items
23:08:33 <Xaroth> elegant, yet effective
23:08:36 <andythenorth> yeah it makes sense for some cases
23:08:58 <Xaroth> by all means, in >50% of the cases you see it they should have done with a js var
23:09:06 <andythenorth> I've seen it used for things that would make more sense to push into an array or such
23:09:15 <andythenorth> instead of creating spurious DOM elements
23:09:51 <andythenorth> keeping state in the GUI weirds me out in the first place; keeping it in the actual markup seems insane
23:10:44 <andythenorth> and yes, my suggestions about industry communication are not entirely serious :P
23:26:05 <Eddi|zuHause> any evil GS guru around? need a lab animal for www.informatik.uni-halle.de/~krause/delaunay.nut (beware of syntax errors etc. i have not actually executed this code)
23:36:19 <frosch123> there is at least one ai doing that
23:36:23 <frosch123> so, compare the code :p
23:40:21 <Eddi|zuHause> you do know that comparing two programs is an undecidable problem? :)
23:41:22 <Eddi|zuHause> and i'm sure my program is hopelessly wrong
continue to next day ⏵
