IRC logs for #openttd on OFTC at 2009-09-19
⏴ go to previous day
00:54:54 *** KenjiE20|LT has joined #openttd
03:06:34 *** Singaporekid has joined #openttd
03:21:28 *** Mark is now known as Guest2986
03:28:23 *** Guest2986 is now known as Mark
04:18:31 *** Guest2988 has joined #openttd
04:23:59 *** Guest2988 is now known as Mark
04:38:50 *** Mark is now known as Guest2991
04:44:01 *** zachanima has joined #openttd
04:44:02 *** Guest2991 is now known as Mark
04:56:20 *** Mark is now known as Guest2993
05:01:25 *** Guest2993 is now known as Mark
05:15:30 *** Mark is now known as Guest2994
05:22:38 *** Guest2994 is now known as Mark
05:40:22 *** Lordnokon has joined #openttd
05:40:43 <Lordnokon> any pro's of ttdx around here
05:42:08 <Lordnokon> as there no way to speed the game up when running more then 1000 units??
05:42:30 <Lordnokon> currently im running a quad core chip with 8gb run on 64bit vista... and the game slow down badly
05:48:27 *** Lordnokon has left #openttd
05:49:13 *** Lordnokon has joined #openttd
05:51:15 *** Azrael- has joined #openttd
05:59:20 <Lordnokon> is everyone sleeping or what??
06:12:56 *** Lordnokon has joined #openttd
06:13:15 <Lordnokon> is there anyone here
06:14:59 *** Lordnokon has left #openttd
06:15:50 *** Lordnokon has joined #openttd
06:16:03 <R0b0t1> You picked kind of a bad time.
06:16:13 <R0b0t1> Most people seem to go by -6ish GMT
06:16:35 <Lordnokon> ah ok, thought it was just me... lol
06:24:22 *** Alberth has joined #openttd
06:27:46 *** Cybertinus has joined #openttd
06:31:40 <Lordnokon> guys i really need some help on questions that i have
06:33:47 <Alberth> you'll have to ask a question first before we can give you an answer
06:36:47 <Lordnokon> im running a quad core chip with 8GB memory with vista 64bit
06:37:03 <Lordnokon> before I even hit 1000 units of vechiles the game slow down.
06:37:10 <Alberth> OpenTTD uses 1 core only
06:37:29 <Lordnokon> i have setup the custom speed to 99999999
06:37:56 <Lordnokon> surely the game should not slow down.
06:38:41 <Alberth> you have an too optimistic view of the amount of calculations done.
06:39:15 <Alberth> did you try a search on this topic at the forums? there are several discussions there that explain it in more detail than I can.
06:39:36 <Lordnokon> i did, must of missed them
06:41:15 <Lordnokon> can you point me to the right section??
06:44:34 <Alberth> hmm, not easily findable indeed.
06:46:32 <Alberth> common causes are the AI's that you use, and animation / full screen, together with 2k x 2k maps.
06:48:23 <Alberth> but indeed, if you want to understand why, finding discussions about ways to speed is a good start, like multi core, speed up, and threads
06:49:22 <Lordnokon> ok you guys lost me...
06:49:41 <Lordnokon> looks like this game gets more complicated than i thought...
06:51:01 <Alberth> it is mainly a matter of scale. doubling the map-size means 4 times as many tiles, thus 4 times more work.
06:51:12 <planetmaker> [08:40] <Lordnokon> [08:37:57] surely the game should not slow down. <-- you got search terms what to look for in order to find (extensive) answers
06:52:11 <Rubidium> Alberth: and generally more than 4 times more (CPU) cache trashes
06:53:30 <Alberth> also, each new train needs to have its route calculated constantly.
06:53:36 <planetmaker> hehe... possibility for huge map types: the strong union or lazy worker switch: people only work where the current viewport is centred ;-)
06:53:48 <planetmaker> thus number of calculations necessary decreases, too :-P
06:54:28 <Alberth> yeah, all trains outside the viewport stop, and do not get any income. That would be a nice challenge then :p
06:56:36 <Alberth> haha, we can then remove the signals, and have the user control which train can progress by viewing at it!
06:57:05 <planetmaker> that's then the "dummy drivers switch" ;-)
06:58:13 *** Guest2998 has joined #openttd
06:58:25 <Alberth> Lordnokon: so in short, the amount of calculations explode with a growing number of trains. At some point you hit the upper boundary of the CPU, and then the game slows down.
07:02:42 <Lordnokon> i like playing the huge maps with loads of industries, and lots of units...
07:02:58 *** Guest2998 is now known as Mark
07:05:34 <Alberth> Assuming you currently play 2000x2000, you can try 2000x1000 instead. It reduces the number of tiles by 1/2, leaving more CPU time for the trains.
07:06:51 <Alberth> I don't know if that helps, but it seems like worth a try.
07:07:30 <Lordnokon> im going to try and disable all AI's and exstra's
07:08:20 <Alberth> that helps too, AI's tend to eat lots of CPUs.
07:13:19 <planetmaker> Lordnokon: also it helps to disable full animation and full details
07:28:02 *** Aankhen`` has joined #openttd
07:35:46 *** Terkhen has joined #openttd
07:39:45 *** andythenorth has joined #openttd
07:40:18 <planetmaker> hm... what is the exact command line argument if I want to link against another SDK than my default one?
07:40:29 <planetmaker> it's probably --with-osx-sysroot=...
07:55:40 *** CraKinShOt has joined #openttd
08:13:41 *** ChanServ sets mode: +o petern
08:21:40 *** Coco-Banana-Man has joined #openttd
08:39:51 *** Progman has joined #openttd
09:26:33 *** tux_mark_5 has joined #openttd
09:35:06 *** Coco-Banana-Man has quit IRC
09:40:22 *** ChanServ sets mode: +v tokai
09:42:08 *** Coco-Banana-Man has joined #openttd
09:47:41 *** Illegal_Alien has joined #openttd
09:49:58 *** lewymati has joined #openttd
09:51:27 <CIA-4> OpenTTD: rubidium * r17570 /trunk/src/ (59 files in 9 dirs): -Fix: a number of Doxygen warnings about missing parameters, which were sometimes missing and sometimes just typos
10:05:40 <petern> hmm, zero downloads from my binaries mirror
10:07:30 <petern> guess that bit was never set up :s
10:07:32 *** Belugas has joined #openttd
10:07:32 *** ChanServ sets mode: +o Belugas
10:10:12 <Alberth> switching bits of the download counter would have caused an inbalance of the bits at your HD, which would have caused a crash. Luckily, your system detected that, and prevented those changes.
10:12:21 <Rubidium> yeah, someone hurdled into yet another project before completely finishing the previous
10:15:00 <planetmaker> I'm still looking forward to the rail and road types :-)
10:15:03 *** thingwath has joined #openttd
10:19:27 <CIA-4> OpenTTD: rubidium * r17571 /trunk/src/town_gui.cpp: -Fix [FS#3213] (r17569): town view didn't show the right town in most of the cases
10:24:54 <Rubidium> morning? It's after noon
10:27:55 <CraKinShOt> Is the hashmap the favored method for key->value lookups?
10:29:50 <Alberth> using the key as an index is usually the fastest solution.
10:30:49 <Alberth> Don't know where you want to do the lookup, but near the map, I doubt you have the time to do a hash value calculation.
10:32:37 <CraKinShOt> well I'm trying to think ahead on what the best solution would be
10:33:39 <CraKinShOt> I have a tileId and a seperate struct with additional information. Only a few tiles would have the extra information.
10:34:14 <CraKinShOt> so a flag in the tile to say the extra information is present. If so, the extra information is looked-up
10:34:23 *** |Jeroen| has joined #openttd
10:35:39 <Alberth> I am pretty much clueless about feasibility of changes in that area, unfortunately
10:36:52 <Alberth> it sounds as a sane idea, so for a proof of concept it may be good enough for now.
10:37:40 <CraKinShOt> probably, I'm just not sure on what the worst case O() is for hashmaps
10:37:53 <CraKinShOt> or at least the one in this code
10:38:13 <CraKinShOt> but I guess I can abstract it so it can be changed later
10:40:05 <CraKinShOt> so linear then. hmm.
10:40:57 <CraKinShOt> maybe this is an interesting problem in general. Adding additional information to tiles, but sparsely.
10:41:34 <Alberth> add a number with enough bits, use it as an index in another strcututre
10:42:00 <planetmaker> lighter on the map array might be even to just have a bit, and then check a list for the tile number.
10:42:25 <CraKinShOt> thats what I was heading toward
10:42:32 <petern> surely you just add a few ints to the map array ;)
10:42:41 <Alberth> if we keep it sorted, it is O(log N)
10:43:28 <Alberth> petern: yeah, a long long would be good no? :p
10:43:34 <Alberth> (unfortunately, it is not)
10:43:49 <Rubidium> it all depends what the data *not* on the map is used for; it it's important for signal states then putting it off-map might not be a wise decision, if it's only updated occasionally and drawn then off-map with some sort of hash might be feasible
10:44:43 <CraKinShOt> well, while true its used for the signals in my case, I guess it could be used for all sorts
10:45:00 <CraKinShOt> the simple solution is just an unsigned int in the map tile
10:45:22 <Alberth> until you want to save that data to disk
10:45:40 <CraKinShOt> exactly, was pointed out last night
10:46:16 <CraKinShOt> I'll have a gander at sparse-matrix see what the worst case is on that.
10:46:55 * Rubidium (again) points to TTDP's system
10:49:12 <Alberth> CraKinShOt: you have to stop thinking in general solutions here, each value in the map is uniquely balanced. That's what makes it so fast, but also so difficult to change.
10:51:05 <Alberth> eg OO dictates that every tile-kind should be a derived class, and we should use virtual methods for accessing. That would however bring down the whole game.
10:55:48 <Eddi|zuHause> <CraKinShOt> probably, I'm just not sure on what the worst case O() is for hashmaps <- the sense of hashmaps is, that the worst case hardly ever occurs, the average case is what matters
10:58:57 <Eddi|zuHause> insane idea: unify stations (waypoints) and signals
10:59:17 <Eddi|zuHause> then you could reuse the station-deceleration code for stopping at signals
10:59:45 <Eddi|zuHause> CraKinShOt: have you had a look at michi_cc's signal patch yet?
11:02:16 *** KenjiE20 has joined #openttd
11:07:29 <CraKinShOt> yeah, I thought he just added another bit?
11:12:07 *** [com]buster has joined #openttd
11:18:05 <CraKinShOt> looks like he just used the last bit in the tile (m2?)
11:18:41 <CraKinShOt> the signals I think have 3 bits, and a few cases can be added there
11:19:36 <CraKinShOt> I think 0x7 was the last free case (at least in the current trunk)
11:21:12 <CraKinShOt> I need at least 8-bits I think
11:23:04 <CraKinShOt> @Rubidium (again) points to TTDP's system <- I had a look (twice) for something to do with the landscaping, but I can't read assembler easily. Feels like a needle in a haystack and I'm blind.
11:31:25 <CIA-4> OpenTTD: alberth * r17572 /trunk/src/ (26 files in 4 dirs): -Codechange: Use the Window::GetWidget() function to access nested widgets through the nested_array.
11:38:21 *** andythenorth has joined #openttd
11:39:43 <CraKinShOt> hmm well the code on the restrictions is just as obscure to me.
11:39:55 <CraKinShOt> the limitations in the documentation are a hint though
11:40:49 <CraKinShOt> the 256 per 64*64, could be a speed up mechanism.
11:41:18 <CraKinShOt> i.e. you make a seperate array that is [mapWidth/64, mapHeight/64]
11:42:08 <CraKinShOt> then a list (variable size) in each for the tiles with extra information for specific tiles
11:43:10 <CraKinShOt> would make getting to the extra tile information a lot faster, for very large maps
11:43:42 <CraKinShOt> those programmable signals look interesting. :D
11:50:06 *** Azrael- has joined #openttd
11:55:57 <CIA-4> OpenTTD: alberth * r17573 /trunk/src/ (6 files in 2 dirs): -Codechange: NWID_SELECTION containers have a selected widget-plane, and optionally an index in the nested_array.
11:59:36 *** Audigex has joined #openttd
12:28:33 *** ChanServ sets mode: +v tokai
12:53:01 <CIA-4> OpenTTD: alberth * r17574 /trunk/src/widget.cpp: -Fix (r17573): Insert NWID_SELECTION in nested_array when appropriate.
12:58:12 *** zachanima has joined #openttd
12:58:33 *** [com]buster is now known as Combuster
12:58:34 *** Combuster is now known as [com]buster
12:58:36 *** [com]buster is now known as Combuster
13:08:50 <CIA-4> OpenTTD: alberth * r17575 /trunk/src/ (widget.cpp widget_type.h widgets/dropdown.cpp): -Codechange: Adding a new combined button+dropdown widget.
13:09:46 *** thingwath has joined #openttd
13:14:24 *** Phoenix_the_II has joined #openttd
13:25:07 *** Dred_furst has joined #openttd
13:25:14 *** Polygon has joined #openttd
13:31:38 *** Chris_Booth has joined #openttd
13:55:49 <CIA-4> OpenTTD: rubidium * r17576 /trunk/src/train_cmd.cpp: -Fix [FS#3208]: assertion triggered when the second vehicle in a 101+ (or 11+ if mammoth trains is disabled) vehicle free wagon chain is an engine and the first vehicle is moved to another chain
13:57:16 <CIA-4> OpenTTD: alberth * r17577 /trunk/src/order_gui.cpp: -Codechange: Order window uses pure nested widgets.
14:09:19 *** DJNekkid has joined #openttd
14:29:08 <planetmaker> in r17577: ottd/trunk/src/ai/../window_gui.h:402: error: default template arguments may not be used in function templates
14:29:18 <planetmaker> ^ Alberth, I guess that's your resort
14:29:36 <planetmaker> compiling with gcc 4.2
14:31:45 *** Illegal_Alien has joined #openttd
14:33:17 <Hirundo> MSVC is also complaining: ...\window_gui.h(402) : error C4519: default template arguments are only allowed on a class template
14:34:28 <Rubidium> planetmaker: are you sure it's gcc 4.2 and not llvm?
14:34:52 <Rubidium> i.e. are you using Apple's stock compiler? Or one compiled yourself from GCC's pristine sources
14:35:07 <planetmaker> I'm using my default compiler
14:35:41 <Hirundo> btw good afternoon pm :)
14:36:19 *** Hirundo has joined #openttd
14:37:15 <planetmaker> checking build cc... gcc
14:37:16 <planetmaker> checking host cc... gcc
14:37:18 <planetmaker> checking build c++... g++
14:37:19 <planetmaker> checking host c++... g++
14:38:35 <Alberth> planetmaker: g++ (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2) does not complain
14:38:59 <planetmaker> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
14:41:55 <CIA-4> OpenTTD: alberth * r17578 /trunk/src/ (order_gui.cpp window_gui.h): -Fix (r17572): Some compilers don't like default function template arguments.
14:42:28 *** Biolunar has joined #openttd
14:43:03 <Alberth> that should fix the warnings.
14:45:06 <CraKinShOt> well after a bit of thinking I'll go with the spares tile (additional) information way.
14:45:29 <Hirundo> MSVC is happy again, too
14:45:45 <CraKinShOt> For the immediate aspects and feathers, I could just use unused bits
14:46:13 <CraKinShOt> but longer term, and for things like programmable signals, make more sense to do it this way
14:46:27 <Hirundo> FWIW: MSVC complains about signed/unsigned mismatch in newgrf_gui.cpp:304
14:48:22 *** thingwath has joined #openttd
14:48:32 <CraKinShOt> in landscape_grid.html it says that m2 is used for indexing objects in object arrays
14:49:02 <CraKinShOt> but for rails with signals, m2 is directly used with states
14:50:18 <Rubidium> CraKinShOt: it's only for the general case; it's not always the case
14:50:55 <CraKinShOt> Yes, I gather as much from the documentation
14:51:40 <CraKinShOt> going from the documentation, with class 0ground, m2 is an index?
14:52:26 <Alberth> Hirundo: weird, line "int max_index = min(min_index + this->vscroll.GetCapacity(), this->grfs.Length());" you mean? that got changed last monday, quite a while ago
14:53:24 <CraKinShOt> I just wonder whether to seperate out the signal states from m2. Have m2 be an index to a table and then add on all the extra stuff in that table.
14:53:27 <Rubidium> CraKinShOt: uhm... it doesn't say that; it actually says the exact opposite
14:53:36 <Hirundo> I'm running MSVC 2008 at standard settings
14:54:00 <CraKinShOt> lol yeah, sorry... bad example
14:54:38 <CraKinShOt> presume depo's and stations then are indices
14:55:55 <CraKinShOt> but I imagine with a large game, you'll easily hit 16K "rail with signals".
14:56:58 <CraKinShOt> hmm could make it 24 bit and add on m7
14:57:38 <CraKinShOt> at least with a direct index it would be nice and fast
14:58:29 <Rubidium> except that you need to dereference
14:59:04 <CraKinShOt> true, but at least it would be faster than having a TileId to Array mapping
14:59:12 <Alberth> Hirundo: could you try casting the second argument to int, as in "int max_index = min(min_index + this->vscroll.GetCapacity(), (int)this->grfs.Length());" and check whether that fixes the warning?
15:00:08 <Hirundo> I will test in 10 mins or so
15:00:42 <Alberth> hmm, maybe changing the min() to min<int>() would be better.
15:01:22 <Alberth> ok, will make dinner first, so no hurry
15:03:49 <Alberth> hmm, all variables seem to be >= 0, so making it all unsigned would be a solution too, perhaps
15:04:30 <Alberth> why do issues always get more complicated if you investigate more closely? :p
15:14:14 <Hirundo> min() -> min<int>(), this->grfs.Length() -> (int)this->grfs.Length() and making min_index, max_index and i into uints all work
15:14:39 <Hirundo> to me, making them unsigned seems the best thing to do
15:17:59 <CIA-4> OpenTTD: rubidium * r17579 /trunk/src/ (18 files in 4 dirs): -Fix: remove doxygen docs for removed parameters, or change @param to @tparam if necessary
15:25:28 *** Grelouk has joined #openttd
16:23:01 <CIA-4> OpenTTD: alberth * r17580 /trunk/src/newgrf_gui.cpp: -Fix (r17541): Fix signed/unsigned mismatch with MSVC 2008.
16:23:22 <Alberth> thanks for the report and the testing.
16:31:46 <Hirundo> Alberth: Is using WWT_EMPTY widgets (still) the best way to order text into columns, or is there a better alternative?
16:33:13 <Alberth> WWT_TEXT and WWT_LABEL can display a single line text (in fact they are designed to do that)
16:33:58 <Alberth> WWT_EMPTY is a kind of catch-all-other-cases kind of widget. You get space but have to do everything yourself.
16:34:41 <Hirundo> I'm talking about roughly a dozen lines of text here, using separate widgets for those is a little too much I'd say
16:35:41 <Alberth> not a problem in my book, if they are separate lines (ie not one very long line that must be wrapped)
16:36:29 <Alberth> eg the news settings window has 4 widgets in each news category (12 or so categories iirc)
16:37:46 <Alberth> when dropping known sizes for text, the computations for positioning and sizing quickly get complicated. If the widget system can take care of that, why not?
16:41:47 <Hirundo> I'm dealing with 5 columns * 10 rows = 50 widgets :S
16:42:19 * Hirundo doesn't want to write such a widget tree
16:45:27 <glx> you can create the tree dynamically
16:49:14 *** Audigex has joined #openttd
16:49:58 <Alberth> yes, write a piece of code, I did that too with the news settings
16:51:06 <Alberth> news_gui.cpp:1304: NWidgetFunction(MakeButtonsColumn),
16:51:19 <Alberth> where MakeButtonsColumn is a function
16:52:36 <glx> that's one of the good feature added by nested widgets
16:56:56 <Hirundo> How does the biggest_index parameter of such a widget function work?
17:04:16 <Alberth> each nested widget has an index number in the nested array. normally those values are from an enum. In this case, you should assign numbers yourself.
17:04:53 <Alberth> the widget system needs to know the highest number you use, so it can allocate enough memory.
17:05:27 <Alberth> of course if you use bigger numbers elsewhere in the window, that is taken as 'biggest'
17:06:53 <Alberth> it does not matter if you don't use some numbers, that entry in simply left NULL
17:06:58 *** andythenorth has joined #openttd
17:08:59 <Eddi|zuHause> hm... party in the village
17:09:07 <Eddi|zuHause> and they're playing "Preußens Gloria"
17:13:11 *** Coco-Banana-Man has quit IRC
17:17:33 *** Doorslammer has joined #openttd
17:35:53 <andythenorth> can anyone think of any palette hacks to give boats exhaust smoke
17:38:24 <Doorslammer> That would be cool
17:38:49 <Doorslammer> No possibility of using the diesel smoke from a train?
17:40:37 <andythenorth> for ships there is no equivalent of prop 22 (visual effects)
17:40:56 <andythenorth> it could be done with animated frames, but that would mean a lot of extra frames...
17:41:21 <Doorslammer> I find it odd that a sprite for one thing can't be used for another
17:41:34 <Doorslammer> But of course I would say that with my lack of coding knowledge
17:42:51 <andythenorth> when I get to drawing steam ships, it's going to be more noticeably lacking
17:42:54 <Rubidium> Doorslammer: there's two ways of 'can'
17:44:08 <Rubidium> you can, in theory, use the doors of your house a garage door, but you can't without modifying a few things of the garage door
17:44:12 <Doorslammer> I wonder why I thought this was devzone
17:44:55 <Rubidium> same as with OpenTTD you can, in theory, use a prop 22 equivalent for ships, but you can't without doing the modifications needed to implement that feature
17:45:26 <CIA-4> OpenTTD: translators * r17581 /trunk/src/lang/ (finnish.txt russian.txt unfinished/vietnamese.txt):
17:45:26 <CIA-4> OpenTTD: -Update from WebTranslator v3.0:
17:45:26 <CIA-4> OpenTTD: finnish - 1 changes by jpx_
17:45:26 <CIA-4> OpenTTD: russian - 1 changes by Lone_Wolf
17:45:26 <CIA-4> OpenTTD: vietnamese - 104 changes by nglekhoi
17:45:55 <Doorslammer> Well that's fair enough
17:46:18 <Doorslammer> No doubt that situation may change in due course
17:46:34 <Rubidium> wooh... nglekhoi is doing a good job in increasing the overall completions of the translations
17:49:43 *** lordaro has joined #openttd
17:58:51 <andythenorth> fish fish fish....what should I do about container ships? I am trying to draw this set in a lazy way (coder meaning of lazy)
17:59:23 <andythenorth> adding containers to existing ships is easy, but will produce a ghoulish action 2 / varaction 2 chain
18:00:34 <andythenorth> the issue is that for many cargos, they can be validly carried in containers, or as bulk / break bulk cargo
18:01:22 <andythenorth> which gets me into a world of cargo subtypes
18:02:03 <andythenorth> How about for some cargos, after a certain date they just use containers?
18:04:19 <andythenorth> or maybe nobody cares about containers. So that would be easy :P
18:06:38 <jirik> Hi, I am looking for some OpenTTD pack with passengers destinations, but something newer then Roujin's pack which is one year old. Could anybody help me?
18:13:56 *** Lordnokon has joined #openttd
18:16:18 *** green-devil has joined #openttd
18:16:26 *** green-devil has left #openttd
18:37:52 <fjb> Almost everything is transported in containers now and most train sets support them. So containers ships would be nice to have.
18:39:17 <andythenorth> do you want to be able to choose to have containers, or would you be happy for the grf to decide what cargos get containers?
18:40:57 <asilv> being able to choose would be nice to have but not must have feature for me
18:41:15 <fjb> I would be happy if the grf decided it.
18:42:42 <fjb> Maybe explicit container ships in modern times could be an addition if the rest of the grf is in place.
18:43:46 <andythenorth> fjb: I thought of explicit container ships. The thing is that it would add a lot more ships to the buy menu (allowing for coasters, river boats, and towboats)....
18:43:55 <fjb> Btw, how do engineering supplies influence mines?
18:44:02 <andythenorth> ...plus most modern ships can carry containers or general cargo
18:44:21 <andythenorth> re: engineering supplies, they increase production, but not much. the code's not finished in that part of FIRS
18:45:26 <fjb> One of my ore mines has a production of 888 tonnes per month. Thats why I asked.
18:46:17 <andythenorth> I am reading my HEQS code to remind myself how refit cycles work. Containers might be possible as a refit...
18:47:41 <fjb> Refit would be nice. But I don't mind if containers do get added later.
18:48:21 <asilv> andythenorth: now that we are talking about FIRS, do you think I should disable gas stations and supermarkets in swedish houses if FIRS is loaded, or will FIRS do it?
18:48:39 <glx> <fjb> One of my ore mines has a production of 888 tonnes per month <-- it's not yours
18:48:49 <andythenorth> asilv: I'm not sure. That's a question for FooBar :)
18:48:50 <asilv> also what about was generation for houses?
18:49:06 <andythenorth> we have considered how FIRS interacts with town sets. we want it to play nice
18:49:20 <andythenorth> ask in the forums development thread ;)
18:49:31 <andythenorth> waste generation from houses would be nice
18:49:49 <andythenorth> we'd need to make sure players weren't confused
18:50:10 <andythenorth> i.e. they play a FIRS game with one town set, they get different industry chains to another set
18:50:17 <andythenorth> I think that adds to the game in the long term though
18:50:29 <andythenorth> it keeps it interesting figuring out how to play new chains
18:50:52 <asilv> waste generation unfortunately means that I would have to write custom cargo generation callback for all houses
18:51:41 <andythenorth> do it another day?
18:52:04 <asilv> I wastn't planning to do it now :p
18:57:00 *** Guest3025 has joined #openttd
18:57:18 <fjb> Seeing the swedish houses makes me almost feel at home.
18:58:20 <asilv> next version may also have parameter to turn flags off for non-swedish games
18:59:48 <fjb> That would be even more looking like my home.
19:01:19 <Zuu> weee, I really don't like this current behaviour of my AI. In 1950 it can detect the coverage radius of airport type 0 (small airport), but in 1960 it fails.
19:02:17 <fjb> That is odd. I would think it would fail after 2000 (greetings from Pisa).
19:06:28 <Zuu> Indeed really odd. In one save-game when I load it it is in 1950 and shortly after it runs the code that checks if the airport accepts passengers or not. If I load that game and cheats to 1960 it will fail to get the coverage radius, with, height of the airport. (I use the same function for both nonexistent and existing airports in order to test that code more)
19:07:40 <Zuu> So even for existing airports I actually create a tile list based on the top left tile and the with/height that OpenTTD returns + coverage radius and then check the cargo acceptance for that tile rect.
19:08:19 <Zuu> In 1950 the width/height of the small airport is 4x3, in 1960 it is -1, -1. :-s
19:11:15 <fjb> Does something overwrite that variables?
19:11:47 <Zuu> Unless I have found a very obscurd bug in OpenTTD I guess I somehow have a bug somewhere in my code causing this weird behaviour. I've recently restructed the code a lot. Another bug I found ended up being caused by me calling SetCurrentRoadType at a place that worked before, but now it could happen that it got called to late.
19:12:48 <Zuu> Hmm, I will add the function in question to a mini-AI and test it there.
19:13:26 <CraKinShOt> Rubidium: done it, I've used the 8bits of m7 + 4 bits from m6 and 4 bits from m2. Gives a 16bit index i can use to reference a SignalEx struct from a pool
19:19:51 *** HerzogDeXtEr has joined #openttd
19:24:07 <Zuu> I have the problem also in my mini-AI. And I have tracked it down to that when you change year between 1959 and 1960 the coverage+size of the small airport is no longer returned (instead -1 is returned). Another thing that happen when you go from 1959->1960 is that the small airport is no longer available for construction. Perhaps that is related?
19:25:11 *** Polygon has joined #openttd
19:26:11 <Zuu> Shall I file a bug for this and upload my test AI along with a savegame + instructions?
19:27:22 <Eddi|zuHause> why ask? the worst that can happen is that it gets closed...
19:28:57 <andythenorth> fish fish...it's easy enough to make all cargos refittable to containers....but that's a bit weird. Not everything travels in containers.
19:30:16 <andythenorth> I think I'll leave containers for another day...
19:31:42 <andythenorth> I think there is probably a solution using cargo classes. But I'd need help. And the refit menu would get....long
19:35:17 <Eddi|zuHause> have you seen some of the aircraft refits with realistic liveries?
19:36:17 <andythenorth> I've got code for the refit, the issue is excluding all the cargos that shouldn't really refit to containers
19:36:36 <andythenorth> with the various industry sets, that's a big job...
19:36:48 <andythenorth> partly my fault for introducing FIRS :|
19:37:36 <Eddi|zuHause> i think i did tell you that you should stick as closely to ECS as you can ;)
19:38:52 <andythenorth> when should containers become generally in use?
19:40:13 <andythenorth> NARS 2 introduces doublestacks in 1985
19:40:17 <andythenorth> seems a little late
19:41:15 <Eddi|zuHause> hm... somewhen around the 70's i'd've thought
19:41:28 <asilv> "The first vessels purpose-built to carry containers began operation in Denmark in 1951" says wikipedia
19:42:16 <andythenorth> if there was *no* choice for the player, what would be the list of cargos to go in containers, after, say, about 1975
19:43:03 <asilv> cargo class express? except tourist? :P
19:43:23 <Eddi|zuHause> anything that is not passenger or bulk?
19:43:38 <asilv> livestock in containers?
19:43:59 <Eddi|zuHause> anything that is not alive or bulk?
19:43:59 <asilv> livestock is pice googds isn't it
19:44:14 <andythenorth> the fun world of cargo classes :)
19:44:40 <andythenorth> fruit and vegetables?
19:44:45 <asilv> my spelling doesn't work today:(
19:45:09 <asilv> and the are liquid containers too
19:45:34 <Eddi|zuHause> those are not bulk?
19:45:49 <andythenorth> there are reefer containers, so refrigerated can go in those (I won't redraw, they are too small to care)
19:46:01 <andythenorth> liquid containers - I don't want to draw them :P
19:46:12 <Eddi|zuHause> you shouldn't transport wood in containers, though
19:46:25 <andythenorth> For FIRS, express cargo would work well
19:46:53 <Eddi|zuHause> so goods, valuables, mail?
19:49:22 <andythenorth> this means I need to make friends with varaction 2 variable 47 :|
19:49:24 <Eddi|zuHause> what about "engineering supplies" and the like?
19:50:32 <andythenorth> there was previously some argument that they should not be express cargo. can't remember who or what
19:50:37 <andythenorth> but they're piece goods
19:50:49 <andythenorth> they could go by container, but it's not necessary
19:51:17 <andythenorth> I have just tried loading coasters up with bulldozers for those cargos, but it doesn't look good
19:51:32 <Eddi|zuHause> i think most of the piece goods could optionally be transported by container
19:52:31 <andythenorth> So the question I have to decide - make it a player choice, or just force containers after a certain date?
19:52:48 <andythenorth> both have downsides
19:53:37 <andythenorth> I prefer forcing containers because it's way easier to code
19:57:03 *** Coco-Banana-Man has joined #openttd
19:58:02 <andythenorth> DaleStan: (probably stupid) nfo question
19:58:42 <andythenorth> is anything odd going to happen if I reuse an action 2 chain for different vehicles.
19:59:31 <Eddi|zuHause> why would it? consider varaction2 like a function call
19:59:40 <andythenorth> somehow I never grokked that
19:59:49 <andythenorth> so HEQS is probably *full* of redundant code
19:59:59 <andythenorth> and providing a better FISH just got easier
20:00:05 <Eddi|zuHause> a function may be called from more than one place
20:09:34 <DaleStan> andythenorth: Eddi|zuHause is correct. Provided the feature bytes match, you may reference any action 2 from any number of other action 2s or 3s.
20:10:23 <andythenorth> Well it only took me a year to figure that out :)
20:23:11 <Zuu> [noai] Hmm, It is actually not even possible to check the acceptance of an existing station without implementing it the same way as checking the station before building it.
20:25:31 <Zuu> Making the options for FS#3215 only being changing the implementation. Unless I've missed something fundamental.
20:25:46 <Zuu> (implementation of OpenTTD)
20:28:57 <andythenorth> hmm...do I want to learn how to use var 7E (procedures)?
20:29:36 <planetmaker> sure you do, andythenorth ;-)
20:29:46 <andythenorth> I'll probably need help
20:30:03 <andythenorth> let me try without it
20:30:05 <planetmaker> how else would you get an uber-fish? ;-)
20:30:24 <andythenorth> procedures would just make for more efficient code use. But also maybe harder to understand code
20:30:36 <andythenorth> not pythonic!! As if nfo was anything like python...
20:31:36 <planetmaker> it would have the advantage that I'd have example code then which I could re-use ;-)
20:32:42 <andythenorth> undoubtedly a good thing
20:33:07 <andythenorth> well the documentation is here:
20:33:52 <andythenorth> my case might not need procedures though
20:33:57 <andythenorth> let me try a bit of code first
20:36:49 *** ChanServ sets mode: +v tokai
20:40:03 *** Dreamxtreme_ has joined #openttd
20:41:05 <CraKinShOt> saving and loading
20:41:18 <CraKinShOt> what would be the version for "latest"?
20:41:40 <CraKinShOt> or SL_MAX_VERSION?
20:48:56 <CraKinShOt> Nearly there now. :D just need to get it to save and load properly
20:49:58 *** mechant28 has joined #openttd
20:49:58 *** co_fine has joined #openttd
20:49:59 *** co_1818 has joined #openttd
20:49:59 *** neneksky has joined #openttd
20:49:59 *** Cari_IM2_Second has joined #openttd
20:50:00 *** LoNDoNBabE has joined #openttd
20:50:00 *** Education- has joined #openttd
20:50:01 *** LeRebel has joined #openttd
20:50:01 *** belegug has joined #openttd
20:50:01 *** akhwat_santun has joined #openttd
20:50:01 *** COcariCEdwsaTE2Kecil has joined #openttd
20:50:01 *** COWO_GEDE1 has joined #openttd
20:50:01 *** cow_t4_curhat has joined #openttd
20:50:02 *** ExpressOOOO`C0ffe3 has joined #openttd
20:50:02 *** exmud_bthceww_4fun has joined #openttd
20:50:03 *** NassGorr has joined #openttd
20:50:03 *** Co_sange18cm has joined #openttd
20:50:03 *** cwo__bersahabat has joined #openttd
20:50:05 *** co-jkt-bi has joined #openttd
20:50:05 *** Cwok_dws_ajak has joined #openttd
20:50:05 *** co_solo has joined #openttd
20:50:05 *** citronade03 has joined #openttd
20:50:06 *** ^Cow_BIasa has joined #openttd
20:50:07 *** LHR^M^LHR has joined #openttd
20:50:07 *** cinta_mo_kocokin_cow has joined #openttd
20:50:07 *** cO26jkt has joined #openttd
20:50:08 *** Delicius has joined #openttd
20:50:08 *** stiffmeister has joined #openttd
20:50:08 *** co_kuliah has joined #openttd
20:50:08 *** ervina_16 has joined #openttd
20:50:08 *** Co-cr_cw_bayaran has joined #openttd
20:50:08 *** ce_CANTIK_cR_YG_MW_TRNSFER_DUI has joined #openttd
20:50:09 *** C0_C00L has joined #openttd
20:50:09 *** boy_Jkt has joined #openttd
20:50:09 *** Lumiled has joined #openttd
20:50:09 *** c0_GANTENG_BERDUIT_bt_CR_aww has joined #openttd
20:50:09 *** Alphore has joined #openttd
20:50:09 *** david[de] has joined #openttd
20:50:09 *** looking_for_nice_girl_now has joined #openttd
20:50:11 *** Mat_ure has joined #openttd
20:50:11 *** cari_agen has joined #openttd
20:50:11 *** wanita_dewasa_bth_tmn_pria_map has joined #openttd
20:50:12 *** andreas_mks has joined #openttd
20:50:12 *** co_mapan_cr_ce has joined #openttd
20:50:14 *** SanMigLyt_M has joined #openttd
20:50:14 <andythenorth> nfo: what value would I get for variable B4 (current speed) if vehicle is stopped?
20:50:15 *** lita_15 has joined #openttd
20:50:15 *** PRIA_MACHO_XXX has joined #openttd
20:50:18 *** Tarzan_de_Ch has joined #openttd
20:50:18 *** DhimmEr has joined #openttd
20:50:19 *** joe_rock has joined #openttd
20:50:20 *** Gi_Ngenet_Aja has joined #openttd
20:50:21 *** phil\420 has joined #openttd
20:50:21 *** BAYBEEEE^_^BLUEE has joined #openttd
20:50:22 *** cowok_18 has joined #openttd
20:50:23 *** andhy_nac-smapaht has joined #openttd
20:50:23 *** kefin_aja has joined #openttd
20:50:23 *** ce_berjilbab has joined #openttd
20:50:23 *** CO-HOTManCariHORNYMarriedWomen has joined #openttd
20:50:23 *** COWO_KERJA has joined #openttd
20:50:23 *** B1NTANG has joined #openttd
20:50:24 *** [Man_KERJA_JKT] has joined #openttd
20:50:24 *** _WISHmaster_ has joined #openttd
20:50:24 *** pinay_36 has joined #openttd
20:50:24 *** cwok_cri has joined #openttd
20:50:27 *** _Bianca_ has joined #openttd
20:50:27 *** link_cute has joined #openttd
20:50:27 *** pjkbtuhduit has joined #openttd
20:50:27 *** co_fb_46 has joined #openttd
20:50:28 *** Co_kul_maranatha has joined #openttd
20:50:28 *** revclyde has joined #openttd
20:50:28 *** _ce_cerfie has joined #openttd
20:50:29 *** crcebersuami has joined #openttd
20:50:30 *** __jaimatadi__ has joined #openttd
20:50:30 *** Denise_S2 has joined #openttd
20:50:30 *** co^gudel has joined #openttd
20:50:31 *** Kelana_Cinta has joined #openttd
20:50:33 *** mau_enak has joined #openttd
20:50:35 *** ce_sederhana has joined #openttd
20:50:35 *** penny^lane has joined #openttd
20:50:35 *** sam0715 has joined #openttd
20:50:36 *** MeCindy has joined #openttd
20:50:36 *** adiet_caem_cari_pacar has joined #openttd
20:50:38 *** bad2thebone has joined #openttd
20:50:38 *** nindKa_ has joined #openttd
20:50:39 *** shemale_lookin4 has joined #openttd
20:50:39 *** angel_aja has joined #openttd
20:50:39 *** nurse_akbeth has joined #openttd
20:50:39 *** No_Bizar has joined #openttd
20:50:39 *** erar_li has joined #openttd
20:50:39 *** cO_BdgLgNyaRi has joined #openttd
20:50:39 *** fikriii_mu has joined #openttd
20:50:39 *** piojo_karate has joined #openttd
20:50:39 *** cwoq_cri has joined #openttd
20:50:39 *** yangil30 has joined #openttd
20:50:39 *** c3_LuVLy has joined #openttd
20:50:39 *** nice_guyz has joined #openttd
20:50:39 *** Chat_Sauvage has joined #openttd
20:50:39 *** Wendat_28 has joined #openttd
20:50:39 *** Wingate1st has joined #openttd
20:50:39 *** dark_angel has joined #openttd
20:50:40 *** co_300_serius has joined #openttd
20:50:40 *** mBendol has joined #openttd
20:50:40 *** co-papua-gede-panjang has joined #openttd
20:50:41 <Eddi|zuHause> Rubidium, orudge, SmatZ, any op?
20:50:45 *** G\e\e\k has joined #openttd
20:50:45 *** CE_BTHKRJ has joined #openttd
20:50:46 *** BOLIHUANGGA has joined #openttd
20:50:47 *** Invierno has joined #openttd
20:50:47 *** Bnt_aBohaa has joined #openttd
20:50:47 *** Disgruntled has joined #openttd
20:50:49 *** Sty|EsS has joined #openttd
20:50:49 *** CO_LG_NGCOK_KONTL has joined #openttd
20:50:49 *** PrAyInG^EyEs has joined #openttd
20:50:49 *** co_nyante has joined #openttd
20:50:49 *** juliette40 has joined #openttd
20:50:49 *** Tueur_Vagin has joined #openttd
20:50:51 *** AnakAyam has joined #openttd
20:50:53 *** stefygurl has joined #openttd
20:50:54 *** co_fs_fb_ym has joined #openttd
20:50:56 *** Ry4n_b3tE has joined #openttd
20:50:56 *** GentL3meL has joined #openttd
20:50:57 *** Om_Mau_Jilmeq has joined #openttd
20:50:59 *** meLL_InBndung_juohh has joined #openttd
20:50:59 *** cinta_17 has joined #openttd
20:51:05 *** mortifera has joined #openttd
20:51:05 *** DedY_jogJa has joined #openttd
20:51:05 *** zZzZ_bOys has joined #openttd
20:51:05 *** StePH[G] has joined #openttd
20:51:05 *** australian_male_makati has joined #openttd
20:51:05 *** [[Co_cr_tokedt]] has joined #openttd
20:51:05 *** Luc_Brien has joined #openttd
20:51:05 *** [David]KS[Lee] has joined #openttd
20:51:05 *** PEJANTAN_TANGGU has joined #openttd
20:51:05 *** cE_imOoet has joined #openttd
20:51:05 *** cO_baEq has joined #openttd
20:51:06 *** andrew_hung has joined #openttd
20:51:07 *** Eurotrash has joined #openttd
20:51:07 *** ce_pengen_mas-mas has joined #openttd
20:51:07 *** Cepet_crCwe_bsyr has joined #openttd
20:51:07 *** cwoPplngskul_smk has joined #openttd
20:51:08 *** kMcJoe7274AG has joined #openttd
20:51:08 *** Co_Jazz_Cakepz has joined #openttd
20:51:08 *** Putri_KoDoK has joined #openttd
20:51:09 *** Laki-Banget-Bisex-CrTeman has joined #openttd
20:51:09 *** Cwo_caRi_tmen has joined #openttd
20:51:09 *** Co-AloNe has joined #openttd
20:51:09 *** loneguy has joined #openttd
20:51:10 *** ikki_jie has joined #openttd
20:51:10 *** VegePat29 has joined #openttd
20:51:10 *** le_danseur44 has joined #openttd
20:51:11 *** RUDDY_JKT has joined #openttd
20:51:11 *** georges70 has joined #openttd
20:51:12 *** bLUe_man has joined #openttd
20:51:12 *** ^^KONSELOR3_curhat has joined #openttd
20:51:12 *** pRiNCEsS_89 has joined #openttd
20:51:13 *** Andre_21_bdg has joined #openttd
20:52:03 <Rubidium> don't know whether +i is really what we wanted, but I don't know what would be the better mode
20:52:21 <Rubidium> i is invite only, right?
20:52:50 <Eddi|zuHause> other option would be +l (limit)
20:53:31 <Eddi|zuHause> only registered?
20:54:14 *** ExpressOOOO`C0ffe3 has quit IRC
20:54:24 <Xaroth> +i is invite only, +m is moderated
20:54:26 <Rubidium> Eddi|zuHause: registration people can do if they want to get in, finding someone to uhm... invite them seems harder
20:54:45 <Eddi|zuHause> quite possibly...
20:54:55 <Eddi|zuHause> i'm still not registered after all those years
20:55:15 <andythenorth> nfo: what value would I get for variable B4 (current speed) if vehicle is stopped?
20:55:16 <Eddi|zuHause> and my disconnect is in 2:30
20:55:55 *** naughty has joined #openttd
20:56:03 *** mencari_ibu2_bisyar has joined #openttd
20:56:05 *** [iMMoRtaL] has joined #openttd
20:56:09 *** cowo_biasa_25 has joined #openttd
20:56:10 *** ce_akper has joined #openttd
20:56:25 <Xaroth> means it doesn't show up in /list
20:56:32 <Eddi|zuHause> i kinda doubt that this'll help
20:56:57 <Xaroth> Join (naughty) (~ButuhFree@test.dnsbl.oftc.net)
20:57:06 <Xaroth> Join (cowo_biasa_25) (~andhy_nac@9KCAAAM99.tor-irc.dnsbl.oftc.net)
20:57:11 <Rubidium> bah, my irc is getting laggy
20:57:19 <Xaroth> duno what oftc is doing but it sure is dodgy
20:57:37 <Eddi|zuHause> those look like vhosts to me
20:57:49 *** cwoPplngskul_smk has quit IRC
20:57:51 *** mencari_ibu2_bisyar has quit IRC
20:57:57 *** cinta_mo_kocokin_cow has quit IRC
20:57:59 *** Co_kul_maranatha has quit IRC
20:58:30 <Xaroth> a LOT are @ test.dnsbl.oftc.net :o
20:58:33 *** meLL_InBndung_juohh has quit IRC
20:58:33 *** looking_for_nice_girl_now has quit IRC
20:58:59 <Xaroth> might be oper-set vhosts so they can mass-kill them :o
20:59:08 *** ^^KONSELOR3_curhat has quit IRC
20:59:24 *** andhy_nac-smapaht has quit IRC
20:59:40 <Eddi|zuHause> most of the joins only have an IP here...
20:59:49 <Eddi|zuHause> i don't get hostmasks on the kills
21:00:18 <Xaroth> sign that their vhost was set after joining
21:02:12 *** cwo__bersahabat has quit IRC
21:02:22 *** BAYBEEEE^_^BLUEE has quit IRC
21:03:05 *** PRIA_MACHO_XXX has quit IRC
21:03:13 *** c0_GANTENG_BERDUIT_bt_CR_aww has quit IRC
21:03:21 *** COcariCEdwsaTE2Kecil has quit IRC
21:03:45 *** CO-HOTManCariHORNYMarriedWomen has quit IRC
21:04:57 *** Cari_IM2_Second has quit IRC
21:06:03 *** CO_LG_NGCOK_KONTL has quit IRC
21:06:50 *** co_mapan_cr_ce has quit IRC
21:06:50 *** exmud_bthceww_4fun has quit IRC
21:06:50 *** ce_CANTIK_cR_YG_MW_TRNSFER_DUI has quit IRC
21:06:51 *** [[Co_cr_tokedt]] has quit IRC
21:06:51 *** [David]KS[Lee] has quit IRC
21:06:52 *** shemale_lookin4 has quit IRC
21:06:52 *** Cepet_crCwe_bsyr has quit IRC
21:06:52 *** Co-cr_cw_bayaran has quit IRC
21:06:52 *** [Man_KERJA_JKT] has quit IRC
21:06:52 *** PEJANTAN_TANGGU has quit IRC
21:06:52 *** australian_male_makati has quit IRC
21:06:53 *** wanita_dewasa_bth_tmn_pria_map has quit IRC
21:06:53 *** co-papua-gede-panjang has quit IRC
21:06:55 *** Laki-Banget-Bisex-CrTeman has quit IRC
21:06:55 *** ce_pengen_mas-mas has quit IRC
21:07:17 *** adiet_caem_cari_pacar has quit IRC
21:08:15 *** Co_Jazz_Cakepz has quit IRC
21:09:00 <Rubidium> probably that the length of the queue of stuff to send (to the 'client') got above some threshold
21:09:16 <Eddi|zuHause> sending faster than receiving answer packets?
21:09:42 <Rubidium> with those massive reset by peers from many channels, any thing that's in many channels might get bitten by it
21:10:05 <Rubidium> though many is probably a huge number, like 100+ or so
21:12:57 *** stuffcorpse has joined #openttd
21:14:31 <CraKinShOt> Don't see the point tbh
21:14:36 <Eddi|zuHause> don't they have bots for join-flood-protection in here?
21:15:41 <Eddi|zuHause> but you can pretty safely set a limit of 150 or something
21:15:53 <Rubidium> CraKinShOt: there are more things that most don't see the point in, like e.g. stealing
21:15:56 <Eddi|zuHause> it's rather unlikely we ever reach that ;)
21:16:18 <Rubidium> Eddi|zuHause: my fear is that we don't remember we ever set that limit
21:17:02 <Rubidium> and it wouldn't stop floods either; only make them less likely to happen
21:17:02 <Eddi|zuHause> that's why you usually have bots that set the limit automatically to around 10 above current usage
21:17:33 <Eddi|zuHause> yes, but they don't immediately jump to 800 people before anybody notifies a dev
21:18:24 <Rubidium> oh, it shows an l, that should be quasi visible
21:18:28 <Eddi|zuHause> woo... fireworks
21:18:41 <glx> the best way is 10 above connected, with update every 5 minutes
21:18:45 <Rubidium> poor roboboy, which leecher is next?
21:19:40 *** DJNekkid has joined #openttd
21:22:04 <Eddi|zuHause> is it normal that the firefighters are the worst pyromaniacs of all?
21:22:51 <Rubidium> wouldn't updating +l cause a foo set mode +l n every 5 minutes?
21:23:44 <DorpsGek> Rubidium: 5.55555555556
21:24:07 <Eddi|zuHause> but in low fluctuation channels and a halfway decent hysteresis, the amount of updates should be very low
21:24:34 <Rubidium> so within a week the +l spam probably outweighs the flooders that happen like once every 6 months
21:25:05 *** andythenorth has left #openttd
21:25:28 <Eddi|zuHause> yeah, but if you set it to users+50 and a hysteresis tolerance of 20, you hardly ever will get an update...
21:25:52 <Eddi|zuHause> don't know if the standard bots are configurable like that
21:26:03 <Sacro> i've had a request to include the original (tr*.grf and sample.cat) in the ArchLinux openttd-svn package
21:26:12 <Sacro> do any other distros provide them?
21:26:22 <Eddi|zuHause> i don't think so
21:26:44 <Rubidium> and please put them in a package called transport-tycoon-deluxe-stolen-files or so
21:26:50 <Eddi|zuHause> but you may provide opengfx
21:27:22 <Rubidium> yes, fedora provides opengfx; Debian's packager is (occasionally) working on getting opengfx in Debian
21:27:41 *** Grelouk has joined #openttd
21:27:57 <Sacro> I could provide an openttd-opengfx package
21:28:00 <Rubidium> I don't know about the rest though
21:28:13 <Sacro> like openttd-opengfx-svn or -git or -hg or something
21:28:39 <Rubidium> and bundles.openttdcoop.org (for the tarballs)
21:29:33 <Rubidium> oh, not hg. but mz.openttdcoop.org/hg (Ammler, which does hg. only show favicon?)
21:30:25 <Ammler> don't use the source packages for?
21:33:35 <Ammler> hg.openttdcoop.org isn't complete
21:41:52 *** Audigex has joined #openttd
21:46:51 *** Progman has joined #openttd
21:52:47 * Sacro contemplates package changing
21:53:41 <Sacro> so is latest opengfx-0.1.0-alpha6?
21:54:23 <Rubidium> if 0.7.3-RC1 is latest, then yes
21:55:33 <Sacro> well Arch has openttd, openttd-beta, openttd-svn
21:55:54 <Sacro> oh and openttd-rc (which is at 0.6.2-rc1)
21:56:35 <Eddi|zuHause> i can't describe it with words
21:56:36 <Sacro> i could do an openttd-nightly :D
21:56:56 <Sacro> Eddi|zuHause: i like having them all seperate
21:57:00 <Rubidium> and beta is 0.6.0-beta3 (would explain that server)
21:57:21 <Sacro> openttd-beta is 0.7.3-RC1
21:57:38 <Sacro> so I could do an openttd-opengfx-0.1.0-alpha6 package
21:59:00 <Sacro> he also wants me to include timidity as a requirement
21:59:26 <Rubidium> oh, then don't bother with opengfx
21:59:34 <Rubidium> if timidity is required, so is the music
21:59:56 <Sacro> well what about sample.cat?
22:00:01 <Sacro> is there an open sound set?
22:00:08 <Sacro> ie one i can distribute under a nice licence
22:00:09 <Rubidium> there is an open sound set
22:00:17 <Rubidium> actually, there are two
22:00:25 <Rubidium> one is GPLv2 and one is CC Sampling
22:00:59 <Rubidium> the former is as finished as it'll ever be, the latter has still half of the samples to do
22:01:09 *** HerzogDeXtEr1 has joined #openttd
22:01:14 <Rubidium> however, the open sound sets only work with trunk
22:02:26 *** valhallasw has joined #openttd
22:03:03 <Sacro> argh fooooooook, i typed sl instead of ls ><
22:03:19 * Sacro sits and watches the train go past
22:03:44 <Sacro> Rubidium: steam line or something
22:03:55 <Sacro> it shows a level crossing lowering, thena steam train goes past
22:04:04 <Sacro> then the crossing raises and you get your terminal back
22:04:51 <Eddi|zuHause> useless time waster of the day?
22:07:13 <Rubidium> ofcourse... a Japanese person
22:18:40 <CraKinShOt> see if anyone can see a better way than using the pool (not sure if its the best thing for what I'm doing)
22:19:15 <CraKinShOt> should be useful, would extend into programmable / restriction signals
22:19:40 <CraKinShOt> which would actually give use for the feather paths
22:19:49 <CraKinShOt> rather than just visual
22:23:40 <Sacro> CraKinShOt: nice idea... wonder who came up with it...
22:24:43 <CraKinShOt> Well know the patch did something simular...
22:25:25 <CraKinShOt> most of the openttd stuff I've seen on new signals, so far, all add information to the tile
22:25:53 <CraKinShOt> but I just wanted to do feathers
22:26:15 <CraKinShOt> with proper junction specification and UK based graphics (at least for my on copy.). ;)
22:26:38 <Sacro> we need a UK Signals set
22:26:47 <Sacro> the thing that pisses me off most is PBS signals having a bar on them
22:27:13 <CraKinShOt> but yeah, the restricted signals and programmable signals is all TTDPatch ideas
22:27:43 <CraKinShOt> I just want to get a general SignalEx patch into the trunk before the last remaining 16 bits are taken up. :D
22:28:27 <Sacro> well you can always add more bits
22:28:56 <CraKinShOt> apparently not... or at least it'll likely not go into the trunk if it needs it
22:29:21 <Sacro> we should start a UK signals thread
22:30:06 <CraKinShOt> that mockup did it for me. I just want that working. :D
22:31:13 <CraKinShOt> granted with 8-bit seeing the feathers would be hard
22:34:05 <Sacro> why is that second signal at yellow?
22:35:37 <Sacro> unless he was being approach controlled to red
22:37:21 <CraKinShOt> in reality it would be flashing yellow
22:37:31 <CraKinShOt> to indicate to the driver the next signal is a junction
22:37:42 <CraKinShOt> even if that junction is at green
22:37:58 <CraKinShOt> most high-speed railways have this system in one form or another
22:39:39 <CraKinShOt> in terms of using it in the game, yellow signals would slow trains down
22:39:50 <Sacro> well yes, that's the point of yellow signals
22:40:31 * Sacro knows a *lot* about GB signalling
22:40:58 <Sacro> not sure about NI though
22:41:50 <CraKinShOt> but yeah, getting the very basical (and general) patch to allow complex additions to signals, without affecting anything else is my goal at the moment
22:42:09 <CraKinShOt> ... and taking those last 16 bits. XD
22:42:16 <Eddi|zuHause> so "flashing yellow" has the meaning of "next signal has lower speed limit"?
22:42:40 <CraKinShOt> junction 2 blocks ahead
22:43:07 <Eddi|zuHause> (you can make a flashing yellow light by reusing the lighthouse colours)
22:43:23 <CraKinShOt> but yeah, its generally to specifiy that the route is coming off the mainline
22:43:57 <CraKinShOt> so trains arn't switching tracks at 90 mph. :D
22:44:15 *** Dred_furst has joined #openttd
22:44:16 <Sacro> no, flashing yellow is so they can switch at 90mph
22:44:24 <Sacro> otherwise they could just use a fixed yellow
22:45:28 <Eddi|zuHause> well, in germany, the speed limit for this and the next signal is usually given next to the signal
22:45:29 *** stuffcorpse has joined #openttd
22:45:42 <Eddi|zuHause> in <number>*10km/h
22:46:15 <CraKinShOt> the japanise system is bad
22:46:26 <CraKinShOt> so many variations
22:46:30 <Eddi|zuHause> if you want flashing yellow, check docs/ottd-colour-palette.gif, colours 241-244
22:46:34 <Sacro> german has a lot of variations
22:47:06 <CraKinShOt> ok cool, will check out.
22:47:07 <Eddi|zuHause> germany has like 5 different systems, but they are usually not intermixed
23:06:08 *** DJNekkid has joined #openttd
23:08:06 <CraKinShOt> But don't all DB trains have the signalling routed into the cabin?
23:08:52 <Coco-Banana-Man> It's only needed when driving faster than 160 kph
23:09:35 <CraKinShOt> crazy system... the more complex the signal the more likely the driver misinterprets it
23:09:38 <planetmaker> as opposed to pre-signal
23:10:11 <Eddi|zuHause> CraKinShOt: it's not that difficult to interpret
23:10:13 <planetmaker> CraKinShOt: the colours and the blink-effects are quite clear
23:10:44 <CraKinShOt> well I'm thinking about at speed.
23:10:45 <Eddi|zuHause> CraKinShOt: green still means "go" and red still means "stop". the numbers give speed limits
23:12:29 <Eddi|zuHause> the smaller lights have some less often used special meanings
23:12:53 <CraKinShOt> do I have to worry about the network code now that I have added a new pool?
23:12:54 <Eddi|zuHause> like the small white light in the top left means "the next main signal is closer than usual [1000m]"
23:13:13 <CraKinShOt> or does the network just copy commands?
23:13:24 <Eddi|zuHause> CraKinShOt: if you have proper saveload code, the network should adapt properly
23:13:45 <CraKinShOt> right okaydoky, thats makes life easier
23:13:59 <Eddi|zuHause> just have to make sure that all information can be deterministically recalculated from the savegame
23:14:25 <CraKinShOt> can you have conditional loading in the SaveLoad mechanism?
23:14:45 <CraKinShOt> i.e. load something, if thats true, load something else, else dont
23:16:36 <Eddi|zuHause> you can probably do about anything if you add a new saveload chunk
23:17:01 <Eddi|zuHause> but that might be a way you don't want to go ;)
23:17:14 <Eddi|zuHause> i don't really have any experience in that field
23:17:52 <CraKinShOt> well I'm looking at the SLE_... defines
23:18:43 <CraKinShOt> trying to go through the existing object _sl files to see if I can spot a conditional statement being used
23:20:00 <Eddi|zuHause> i don't know what you're trying to achieve
23:20:34 <CraKinShOt> basically, I have 2 states. Something is or isn't being used
23:20:51 <CraKinShOt> if its being used then I need to save 7*sizeof(TileIndex)
23:21:26 <CraKinShOt> saving that regardless seems like it could be detrimental to the network speed if it has to send that infomation all the time
23:21:56 <CraKinShOt> ... so yeah if its not being used, don't store those 7 variables
23:22:39 <CraKinShOt> I suppose I could do a two-pass, save everything without it, then save everything with it.
23:23:22 <Eddi|zuHause> "all the time" means when a player joins the network game
23:23:43 <Eddi|zuHause> during the connection, almost no data is sent.
23:24:15 <Eddi|zuHause> only interactive commands and a checksum in form of the random seed
23:33:14 *** Eddi|zuHause has joined #openttd
23:37:59 *** Dreamxtreme has joined #openttd
23:38:07 <Dreamxtreme> This channel is invite-only. You must have an invite from an existing member of the channel to join. odd
23:39:32 *** DJNekkid has joined #openttd
23:42:18 <Belugas> mmh... render in stereo what has been recorded in stereo
23:42:27 <Belugas> ooops... sorry... wrng channel
23:43:01 <Eddi|zuHause> Dreamxtreme: we had a join-flood
23:43:40 *** Nite_Owl has joined #openttd
23:58:18 *** Coco-Banana-Man has quit IRC
continue to next day ⏵