IRC logs for #openttd on OFTC at 2012-02-18
⏴ go to previous day
00:00:35 *** valhallasw has joined #openttd
00:27:03 <Nat_as> is there a way to get trains to maintenance at any convenient depot
00:27:20 <Nat_as> I like the mantance if needed button, but it's kind of awquard to have to specify depots
00:27:43 <Nat_as> esp if you want them to each use diffrent ones to avoid congestion.
00:32:12 <Rhamphoryncus> click the dropdown arrow and select maintain (or depot?)
00:32:44 <Nat_as> I know about the maintain/refit optin
00:33:00 <Nat_as> but is there a way to tell it to just pick a depot by itself when needed?
00:33:15 <Nat_as> like how it finds a depot when you give it a goto depot order
00:33:41 <Rhamphoryncus> hit the down triangle beside "go to", select "go to nearest depot", then highlight that order, then hit "maintain"
00:34:30 <Rhamphoryncus> Note that maintain means "maintain if needed" as opposed to always getting maintenance. The default for that order is always getting maintenance
00:35:28 <Rhamphoryncus> Also note that it picks a specific depot as soon as it starts the order, so if you have a lot of trains getting maintenance you should use a conditional order and joined waypoints instead
00:37:55 <Nat_as> I want to to find a depot automaticly when it needs to maintain
00:38:07 <Nat_as> instead of Checking every time it passes this depot
00:38:38 <Rhamphoryncus> The default finds one when it needs one, but won't if there isn't one close by.. which is why it does that
00:39:08 <Rhamphoryncus> What you can do is insert maintain-at orders after each stop
00:39:27 <Nat_as> I want an alternitive to that
00:39:37 <Rhamphoryncus> I don't understand the problem then
00:39:44 <Nat_as> because that means I have to click each depot at each stop
00:40:05 <Nat_as> and even if I build two depots per stop, trains will still try to use the same one
00:40:14 <Nat_as> I want it to look for a depot itself
00:40:20 <Rhamphoryncus> <Rhamphoryncus> Also note that it picks a specific depot as soon as it starts the order, so if you have a lot of trains getting maintenance you should use a conditional order and joined waypoints instead
00:40:31 <Rhamphoryncus> That's what I was referring to
00:40:40 <Nat_as> or possibly combine depots so it understands to pick the one that is clear.
00:40:43 <Rhamphoryncus> load balancing of depots
00:41:12 <Rhamphoryncus> You can't join depots but you can combine waypoints (ctrl-click when building)
00:41:53 <Eddi|zuHause> "if needs servicing, goto waypoint => goto nearest depot"
00:41:53 <Rhamphoryncus> So what you do is have it go to the waypoint, but make sure the waypoints are balanced (combo signals or whatever), then each waypoint has a depot after it
00:42:44 <Nat_as> what do waypoints have to do with depots?
00:42:59 <Rhamphoryncus> You cannot join depots. You can join waypoints
00:43:16 <Rhamphoryncus> Use the waypoints to split the trains on to different tracks, and have them only look for a depot after the waypoint
00:43:48 <Nat_as> but you have to tell them to visit the depot
00:43:59 <Nat_as> I don't want to have to click on a depot
00:44:08 <Nat_as> if I wanted to manualy assign trains to depots I would just do that
00:44:10 <Eddi|zuHause> no, you can tell them to visit "a" depot
00:44:29 <Nat_as> (this is what I was asking in the first place)
00:44:32 <Eddi|zuHause> by choosnig "find nearest depot"
00:44:33 <Rhamphoryncus> What's a good image dump? I'll put up an example
00:56:13 <Rhamphoryncus> hmm, yes, no. Signing up makes it a bad image dump.
00:56:38 <Nat_as> it's really usefull though
00:56:46 <Rhamphoryncus> Don't care. It's still bad.
00:56:48 <Nat_as> I use it to host all my pictures and documents
00:57:13 <Nat_as> no content or bandwidth restrictions. Free 2gb
00:57:35 <Nat_as> and it syncs files between two computers
00:59:12 <Nat_as> it would be cool if there were more ways to sort trains in the buy list
00:59:32 <Nat_as> like if there was a sub menu inside of running cost so you could sort by running cost and reliability
01:00:04 <Nat_as> power/running cost is nice, but more bivariable sorts would be cool.
01:04:56 *** Phoenix_the_II has quit IRC
01:14:04 <Nat_as> which is better, building a short feeder line or extending the station catchment area?
01:17:22 <Rhamphoryncus> Mechanically? Extending, 100%
01:17:31 <Rhamphoryncus> fun.. can go either way
01:18:04 <Nat_as> I call it the super terminus.
01:18:31 <Rhamphoryncus> A single passthrough? The amount that can enter/exit at any time will still be very limited
01:19:06 <Rhamphoryncus> And.. if all 4 of the rear platforms are occupied then 1 train could block the access to them
01:19:33 <Rhamphoryncus> Technically they might go through the forward platforms in that case. It's hard to tell though.
01:21:12 <Nat_as> yes I could double the passthrough
01:21:12 <Rhamphoryncus> If you really want to extend lengthwise like that I'd suggest disconnecting the front platforms so that pass-through is the only way, remove the inward signal so a train won't wait there, and stick a waypoint in for trains you expect to sit for a while
01:21:38 <Nat_as> well this IS an unloading station
01:21:42 <Nat_as> trains don't wait here long
01:21:55 <Nat_as> unlike farm stations which typicaly have at least one train loading at all times
01:22:12 <Rhamphoryncus> Also, be aware of why trains are sitting for a while. If they're loading goods then there's a potential for them to block the track in and not let the unload trains come
01:22:18 <Nat_as> then I am limited to how many trains I dare let sit at the station
01:22:23 <Rhamphoryncus> Pure unloading? Goods are picked up from trucks?
01:23:41 <Nat_as> I don't have many goods/food cars though
01:23:49 <Nat_as> just one or two cars mixed into other trains mostly
01:23:53 <Rhamphoryncus> If you take out that signal and stick a waypoint there then the depot *might* act like an overflow
01:24:32 <Nat_as> in the beginning i actually mixed them with passengers, and still do on some smaller lines
01:24:40 <Nat_as> but now i have dedicated express trains
01:24:45 <Rhamphoryncus> But also be aware that once a train enters the depot it will be able to path out to the front platforms, which it will happily do
01:25:35 <Nat_as> I wish it was easier to mix cargos
01:25:48 <Nat_as> I have to make a dedicated food boxcar at the end of a miaze train
01:26:09 <Nat_as> I could set to refit, but that would mean a million tons of food getting shiped to some tiny farm town
01:26:10 <Rhamphoryncus> If you really wanted it robust I'd remove the front unloading platforms and rebuild them as a separate station. Make sure that's *always* an unloading station.
01:26:22 <Nat_as> or mixed cargo in cars.
01:26:23 <Rhamphoryncus> Yeah, that's a pain
01:27:44 <Nat_as> also aircraft can only cary one type of cargo at once
01:28:19 <Rhamphoryncus> As for throughput on dropoff trains.. often it's the entry that's the limiting factor, and in particular the tendency to path across to a different platform and block any other train from entering/exiting at the same time
01:28:44 <Rhamphoryncus> Which is why roro is popular. Minimum of 1 entry and 1 exit at a time
01:29:44 <Nat_as> hmm i might be able to lower stress if I route my express trains to the oil refinery station (just of screen)
01:29:49 <Rhamphoryncus> Mind you, that junction at the top right can't be terribly high throughput either
01:29:58 <Nat_as> it's also the airport but has less passinger catchment
01:30:09 <Nat_as> although that shouldn't be an issue since this is cargo dist
02:00:06 *** supermop has joined #openttd
02:11:21 *** roboboy has joined #openttd
02:45:42 *** roboboy has joined #openttd
03:11:48 *** a2A209_ has joined #openttd
03:50:24 *** cmircea has joined #openttd
04:36:47 *** kkb110_ has joined #openttd
05:56:23 *** Eddi|zuHause has joined #openttd
06:08:33 *** roboboy has joined #openttd
06:09:07 *** andythenorth has joined #openttd
06:14:10 <andythenorth> is it really bad manners to include far too many pngs?
06:14:56 <andythenorth> i.e. to do different coloured cargos in the spritesheet, instead of using recolour sprites?
06:15:02 <Rubidium> too many as in many many many, but mostly needed... or many many many, but onlya few needed
06:15:23 <andythenorth> as in 'could be done with recolour sprites' :)
06:15:44 <andythenorth> but recolour sprites don't interest me
06:16:05 <andythenorth> having my pixel generator just write out another png in correct colour interests me
06:16:51 <Rubidium> that shouldn't be a big problem I'd say; after all recolour sprites add magic voodoo
06:19:46 <andythenorth> I was thinking about whoever pays the bandwidth :)
06:21:23 <andythenorth> :o PIL is writing out insanely large png files
06:21:34 <andythenorth> 86KB on disk for one spritesheet
06:21:55 <andythenorth> photoshop compresses it 2.2KB (4KB on disk due to minimum block size)
06:22:10 <andythenorth> with no loss and no removal of palette
06:25:42 * andythenorth discovers PIL optimize=1 option
06:26:17 <andythenorth> ~5.4KB is PIL's best effort
06:32:47 <Rubidium> but you'd generate the spritesheets during compilation, right? ;)
06:33:18 *** robotboy has joined #openttd
06:33:35 <andythenorth> I could batch them through photoshop to reduce size
06:33:53 <Rubidium> but then it's not about bandwidth
06:33:57 <andythenorth> Rubidium: do recolour sprites have performance implications for ottd?
06:35:22 <Rubidium> although there might also be performance implications of many sprites when the spritecache fills, although with the current cache size that's not something that's very likely I think
06:35:39 <andythenorth> it's probably swings / roundabouts
06:36:00 <andythenorth> so filesize doesn't seem to be a concern for newgrfs afaik
06:36:14 <andythenorth> and what I'm doing is no worse than many sets do anyway
06:36:35 <andythenorth> e.g. HEQS I drew sprites for every supported bulk cargo type
07:03:28 *** andythenorth has joined #openttd
07:39:27 *** robotboy has joined #openttd
07:52:21 *** lmergen has joined #openttd
07:54:22 *** tokai|noir has joined #openttd
07:54:22 *** ChanServ sets mode: +v tokai|noir
07:57:19 *** Alberth has joined #openttd
07:57:20 *** ChanServ sets mode: +o Alberth
08:03:08 *** Progman has joined #openttd
08:07:11 *** tokai|mdlx has joined #openttd
08:24:46 *** andythenorth has joined #openttd
08:37:48 <Alberth> moin Terkhen, andythenorth
08:38:14 <Alberth> nice, more than two loading stages :)
08:38:25 <andythenorth> but I have a design question :)
08:38:30 * andythenorth just needs to make a commit
08:39:35 <andythenorth> Alberth: I'm experimenting with moving the sequence definitions to separate files
08:39:40 <andythenorth> one per vehicle type (gestalt)
08:39:57 <andythenorth> but I've also used an object to hold the sequence (suggested by Rhamorphycus)
08:40:16 <andythenorth> this causes me a headache with imports
08:40:24 <andythenorth> I'm certain there's a better way...
08:41:05 <andythenorth> currently I would have to define this stubby P object in every gestalt file, which is silly
08:41:16 <Alberth> yeah, imports are not designed to be done temporary
08:42:39 <andythenorth> I could move the config stuff to config files, but that seems inefficient for this case
08:43:20 <andythenorth> I could do without the stubby P object, but it seems nice in principle
08:44:25 <Alberth> say you have 2 gestalts, what do you want to do?
08:44:41 <Alberth> as in, what's the output?
08:45:04 *** Devroush has joined #openttd
08:45:40 <Alberth> or do you have say 3 vehicles of each gestalt?
08:45:58 <andythenorth> so gestalts might be: tanker, tipper, flatbed
08:46:12 <andythenorth> and I might generate one of each for 5/8, 6/8, 7/8, 8/8 long
08:46:19 <andythenorth> (also loading states, but that's a detail)
08:46:50 <andythenorth> and the final pngs might all just be single row, but that's also a detail
08:47:43 <andythenorth> I should probably figure out a design before coding :
08:47:56 <andythenorth> but sometimes code tells me what the design wanted to be :)
08:48:12 <Alberth> one way is to import all and store the gestalts in a dict, so you can select it easily
08:49:15 <andythenorth> how might I define these stubby P objects in just one place, instead of in every gestalt file?
08:49:23 <Alberth> the disadvantage is that you have to keep a list of available gestalts, but if you don't add/remove them often, that's not a problem
08:49:32 <andythenorth> that would be fine
08:49:38 <andythenorth> I need the list anyway
08:49:46 <Alberth> define it separately, and import it in every gestalt file
08:49:57 *** DayDreamer has joined #openttd
08:50:21 *** mahmoud has joined #openttd
08:50:50 <andythenorth> that means I'd need to add to the module search path in every gestalt file?
08:51:07 <andythenorth> or can they inherit from importing module?
08:51:32 <Alberth> just make a proper package
08:51:59 * andythenorth is reading python docs on packages...
08:52:09 <Alberth> ie add an empty __init__.py in each sub-directory, and import from the root of the package
08:52:53 <Alberth> (and move the main script outside the package :p )
08:53:13 <andythenorth> ah. that's why there are so many __init__.py files in the python projects I work on :)
08:53:15 <Alberth> often the main script is not much more than from package import main; main.run()
08:53:36 <andythenorth> the package should be the gestalts? Or the gestalts + generator?
08:54:11 * andythenorth -> toddler poo incident
08:55:21 <Alberth> I'd make the pixel_test_generator top-level. The files in misc look like 'commands' rather than 'library functions'
08:56:14 <Alberth> basically, the script that you run should be in the same directory as the top-level package directory
08:56:29 <Alberth> that way you don't have to do magic with python paths
08:59:38 <andythenorth> poo incident resolved
08:59:58 <andythenorth> +1 on where top-level should be
09:00:05 * andythenorth will now be reading more about packages
09:01:17 <andythenorth> might there be any noticeable difference between encoding lots of small pngs or few large pngs?
09:01:36 <andythenorth> file I/O _might_ be a factor I'm thinking
09:01:44 <andythenorth> for compile time
09:01:56 <andythenorth> but maybe file I/O is insanely fast now?
09:02:06 <Alberth> most systems have a large disk-cache
09:02:36 <Alberth> if you have enough memory, that is. So from the 2nd time, you are basically working from memory
09:02:38 *** robotboy has joined #openttd
09:02:57 <Alberth> I would expect pixel plotting to be more costly
09:03:22 <andythenorth> I was wondering about nmlc / grfcodec times too
09:03:40 <andythenorth> I don't mind if compiling all pngs is slow, it's an occasional task
09:03:55 <andythenorth> and I could optimise it to only compile what's needed (with command line args or such)
09:04:06 <Alberth> yeah, but the profile showed it's actually expression reduction in nml that's slow rather than pushing pixels
09:04:21 <andythenorth> profiling ftw :)
09:05:23 <Alberth> I normally make sure code scales nicely, and then stop worrying about performance
09:06:01 <Alberth> it is pretty impossible to guess what will cause problems, or even if you will ancounter them
09:06:45 *** sla_ro|master has joined #openttd
09:07:22 <Alberth> you may want to make sure that you have a simple relation between input and output files, and be able to generate only a part
09:07:45 <Alberth> that way, you can use a Makefile easily
09:08:52 *** |Jeroen| has joined #openttd
09:31:47 *** tokai|noir has joined #openttd
09:31:47 *** ChanServ sets mode: +v tokai|noir
09:32:07 <andythenorth> python package appears to work now
09:32:22 <andythenorth> quote from the tutorial I used: "have each and every script manually manipulate the PYTHONPATH so that
09:32:22 <andythenorth> when the user calls that script, it adds its parent folder to the
09:32:22 <andythenorth> PYTHONPATH before importing what it needs. Messy and ugly.
09:42:11 <SpComb> andythenorth: running your packages scripts while developing?
09:42:20 *** tokai|mdlx has joined #openttd
09:50:36 <andythenorth> not from the shell though
09:50:39 <andythenorth> as module imports
09:51:48 *** tokai|noir has joined #openttd
09:51:48 *** ChanServ sets mode: +v tokai|noir
10:06:21 *** peteris has joined #openttd
10:09:51 *** theholyduck has joined #openttd
10:12:27 <andythenorth> Alberth: a single input to this generator is (probably) a png file containing floor plan(s) of given length
10:12:40 <andythenorth> and to build the entire set, I would pass a list of pngs somehow
10:13:17 <andythenorth> input pngs can be assumed to be in a single directory
10:14:47 <andythenorth> I would need to know the length somehow, for file naming convention purposes
10:17:45 <andythenorth> I have the config file for BANDIT....which contains this information
10:18:38 <andythenorth> hmm...I'd prefer not to tightly couple the pixel generator and the build script
10:23:25 *** frosch123 has joined #openttd
10:24:09 <Alberth> one form could be to make a python file with the configuration data, then import some module from the package, and call mymoduke.doit(config_data)
10:37:53 *** Firartix has joined #openttd
10:49:53 *** TGYoshi has joined #openttd
10:50:45 <andythenorth> it might be better if the pixel generator knows almost nothing about filenames etc
10:51:16 <andythenorth> and just takes the name of the input png, and appends the gestalt id to it
10:51:40 <andythenorth> e.g. trailer_7_8.png becomes trailer_7_8_tanker.png trailer_7_8_flatbed.png etc
10:52:05 <andythenorth> so the generator is deliberately very stupid in that respect
10:52:24 <andythenorth> I don't want config files with n-dimensional complexity :P
10:52:48 <andythenorth> dimensions would be: vehicle id, gestalt, load sprites :P
10:53:00 <andythenorth> also colour options :o
10:53:43 <andythenorth> so maybe I have one config file for the generator, which sets the available gestalts and any variations they provide, like colour
10:54:01 <andythenorth> and use the BANDIT config file to make calls to the generator on demand
10:54:02 <Alberth> you can also make a configuration class that understands the relations
10:54:18 <andythenorth> any chance of an example? :)
10:55:26 <Alberth> but then you could move the filename manipulation above out of the generator, for example
10:55:50 <andythenorth> sounds like interfaces and adapters
10:56:20 <Alberth> no doubt it is not a new problem :)
10:57:19 <andythenorth> ^ somewhat overkill :P
10:57:51 <frosch123> you have module that supports quaking? nice :)
10:57:53 <Alberth> well, have fun with it, I have enough general frameworks at work already :p
10:58:01 <andythenorth> I won't be using that. That's work
10:58:05 <andythenorth> and other people do that bit
10:58:29 <andythenorth> I do vaguely useless things, like write their paycheque once a month and tidy away the dangerous wires and things
10:58:52 <andythenorth> frosch123: all python modules support quak() :P
10:59:42 <andythenorth> it even handles the ambiguity between english quak (duck) and your quak (frog)
11:00:19 <andythenorth> so the generator could just handle sequencing the sprites, and returning them as a bitmap in memory or such
11:00:38 <andythenorth> something else could write them to disk
11:00:46 <andythenorth> might be over-engineering at this stage?
11:01:06 <frosch123> job offer: OpenTTD is looking for a restless warrior, who copies silly bug reports (like FS#5071) to known-bugs.txt. You will be able to gain a lot of insanity in this job.
11:01:34 <andythenorth> curl url | regex > append to file?
11:01:41 <MNIM> What else does it get you, besides insanity?
11:02:04 *** valhallasw has joined #openttd
11:02:24 <frosch123> you can have unidirectional communcation with a lot of people
11:02:55 <frosch123> maybe that feels better than communicating with /dev/null
11:05:04 <Alberth> andythenorth: doing one thing at the same time makes the software nicely modular and flexible
11:05:46 <andythenorth> Alberth is that +1 or -1 in favour of separating pixel sequencing from file writing? :)
11:07:23 <andythenorth> what I need to do (I think) is open a config file, or pass a config class which: defines a list of output targets (filename), and for each output, which gestalt and options to use
11:07:40 <andythenorth> options could be define within the gestalt perhaps
11:08:00 <andythenorth> I think it makes more sense to specify desired output and how to achieve it
11:08:07 *** chester has joined #openttd
11:08:11 <andythenorth> rather than specify input and have lots of rules in the generator
11:09:25 *** FLHerne has joined #openttd
11:14:18 <andythenorth> should the gestalts be in the generator package?
11:14:24 <andythenorth> or should they be passed to it as objects?
11:16:04 * andythenorth is hitting limits of coding ability :P
11:16:17 <andythenorth> I am not a good architect of implementations :P
11:18:43 *** LordPixaII has joined #openttd
11:19:18 <SpComb> andythenorth: just hack at it until it works \o/
11:19:48 <andythenorth> hack at it until $someone else fixes it is my usual approach ;)
11:19:52 <SpComb> but seriously, config files aren't really that great in Python
11:19:56 <SpComb> stdlib just has ConfigParser and it smells
11:20:15 <Alberth> since the generator needs a gestalt object, you either pass a name or an object. In the former case it's easier to specify, in the latter case it is easier to make a custom gestalt
11:20:45 <SpComb> andythenorth: but important to note re Python; `import` is strictly for code, never for data
11:20:57 <andythenorth> SpComb: tell nml that ;)
11:20:58 <andythenorth> I might want custom gestalts
11:21:17 <andythenorth> also yes - importing the gestalts seems wrong
11:21:27 <Alberth> configuration object :)
11:21:48 <andythenorth> hmm...I'll still end up importing gestalts from disk somewhere :o
11:21:58 <Zuu> Hmm, noone has published a water body pathfinder as NoGo library.
11:22:14 <Alberth> that's not a problem imho, constants can be seen as code imho
11:22:55 <Alberth> Zuu: path finding at sea is very hard to do efficiently
11:23:26 <Zuu> In this case Djikstras would be fine as I only want to check if the user has built a canal between two tiles or not.
11:24:19 <SpComb> andythenorth: one option is to have the gestalts import the common code
11:24:50 * andythenorth didn't think of that
11:25:06 <Zuu> Alberth: not very hard to implement, was just hoping to save myself some work by using existing code. :-)
11:25:07 <andythenorth> that would be much better
11:25:25 <andythenorth> that's like providing each gestalt with a render() method
11:25:39 <andythenorth> which also works much better when there is variation between the gestalts
11:26:38 <andythenorth> so each gestalt is a first class object
11:36:52 <andythenorth> I can chain imports so each gestalt only has to import one thing to get all the common stuff it needs?
11:37:06 <andythenorth> it's just importing a package right?
11:37:23 <andythenorth> then the package imports all modules that are deps for the package?
11:38:41 <andythenorth> so (example), I might have a vehicle_generator package
11:39:03 <andythenorth> which provides a utility for sequencing pixels, and a utility for compositing multiple images
11:39:18 <andythenorth> and I can just import vehicle_generator package?
11:40:33 <Alberth> just import the single function that does 'it' ?
11:41:13 <andythenorth> 'it' might vary for each gestalt...
11:41:17 <andythenorth> I think this is all fine
11:41:28 * andythenorth will try coding it
11:41:34 <Alberth> you can also make a base class for gestalts that does 'it' in a general sense
11:41:50 <Alberth> and then make derived gestalt classes that do some things differently
11:42:34 <andythenorth> I think I just accidentally reinvented factory pattern :P
11:58:57 *** lmergen has joined #openttd
12:05:00 *** Rhamphoryncus has joined #openttd
12:13:58 * andythenorth ponders procedurally generating buildings
12:14:06 <andythenorth> not complex structures
12:14:13 <andythenorth> but office blocks and such
12:14:26 <andythenorth> OpenGFX renewal? :P
12:16:19 *** LordPixaII has joined #openttd
12:23:41 <Rubidium> andythenorth: for grfcodec you get the best performance if they are in a single file, and they would be read strictly from top-to-bottom. If the 'next' sprite starts only a single pixel higher it needs to reread the whole file up to that location
12:25:52 <Rubidium> it might be that small/short sprite files are beneficial or nml as it seems to be (re)opening the image file every time
12:27:51 <andythenorth> Rubidium: thanks
12:28:22 <Rubidium> maybe preventing reopening each time might give a significant performance boost for NML?
12:28:48 <Rubidium> (but I don't know what the time consuming part of NML is so this is pure speculation!)
12:29:44 <Alberth> (22:38:03) Eddi | zuHause: www.informatik.uni-halle.de/~krause/profile_cumulative.txt <-- profile of nml for CETS
12:30:09 <Alberth> it seems expression simplification eats lots of cpu seconds
12:30:32 * Rubidium can't connect to that server
12:33:31 <Rhamphoryncus> nope, works for me too
12:33:43 * MNIM blarghs at the lack of diagonal bridges.
12:34:05 <MNIM> making a three-way station is hard when you want a minimal 90degree turn length of at least five.
12:34:07 <Rhamphoryncus> MNIM: #178 on the things that suck list ;)
12:34:36 <Alberth> MNIM: only lay diagonal tracks :)
12:35:37 <MNIM> Well, I can't do that. the station is located at the stem of a T-shaped intersection.
12:35:50 <Rubidium> Alberth: it seems to miss writing the GRF
12:36:17 <MNIM> I could make it without bridges, of course, but Im trying to avoid the evil X-es.
12:37:04 <Rubidium> it spends 13 seconds in parsing the nml though
12:37:33 <Rhamphoryncus> MNIM: the general trick is to put the turns in, then make have the straight track use bridges
12:38:22 <MNIM> the trouble is that the only layout I can think of right now has two diagonals crossing each other.
12:38:50 <MNIM> Hmmmh. I can compact the station lexit area a bit, perhaps that'll give me enough space for an arch avoiding this.
12:38:54 <Rubidium> and this profile might be somewhat ill ordered for determining the real time consuming code
12:40:00 <Rubidium> on the other hand, maybe it isn't the code that's slow but some algorithm that's chosen "incorrectly"
12:41:01 <Rubidium> 17 million base_expression inits seems a bit much to me
12:41:14 <Alberth> CETS is a bit insanely large :)
12:41:15 <Rubidium> can't connect to that one either
12:41:54 <Rubidium> Alberth: it may be large, but... millions of constructor calls might be a bit too much
12:43:25 <MNIM> Oh hey, would you look at that.
12:43:28 <Alberth> every expression node is an object, so have a million very soon
12:43:33 <MNIM> I think Ive got one that works now.
12:44:15 <andythenorth> building generator would need to be procedural in two ways
12:44:22 <andythenorth> pixel sequences would need nesting
12:45:01 <Rubidium> Alberth: am I safe to assume that a + b is three nodes?
12:45:46 <Alberth> and perhaps even more, depending on how the position information is stored
12:45:46 <Rubidium> so cets.nml would be at least 16 MiB to have a+b+c+d+e.... to create enough nodes
12:46:09 <Alberth> iirc, it's a separate object, so you'd have 6 objects then
12:46:23 <Rubidium> okay, you might create nodes during reduction that replace others. So assume half of them are created... still at least 8 MiB cets.nml
12:47:46 <Alberth> every expression getting copied at least once would be a quite safe assumption
12:48:20 <Rubidium> looking at cets.nml there can't that many expressions
12:48:32 <Alberth> although they should be getting smaller, as nml tries to compute the constant value
12:49:49 <Alberth> I don't know what is happening inside nml in detail unfortunately
12:49:58 <Rubidium> 175k lines with something possibly useful on them
12:50:48 <Alberth> doesn't sound very large
12:51:15 <Rubidium> and it doesn't look like there are on average more than 5 expression nodes
12:51:27 <Rubidium> and then I could misc_flags: 0;
12:52:26 <andythenorth> that's about 10 mins work max
12:52:29 <Alberth> probably 3 as well, as you need something to hold each case together
12:52:30 <andythenorth> I'll add windows later
12:53:06 <Alberth> the people will appreciate that :)
12:53:19 <Rubidium> Alberth: my point is that I've got the feeling the number of expression nodes is off by an order of magnitude
12:55:46 <Rubidium> it's even the init of ConstantNumeric
12:58:03 <Rubidium> there are ~800k digits in the file, so by reduction you can in theory create a single digit. Even then you'd be creating at most 800k intermediate nodes, which means 1.6M not 16M
12:58:23 <Alberth> everything is an expression afaik, even expressions reduced to a constant
12:58:56 <Rubidium> 16644431 20.191 0.000 33.590 0.000 base_expression.py:121(__init__)
12:59:03 <Rubidium> that means the init at line 121, right?
12:59:10 <Rubidium> that's the init of ConstantNumeric
12:59:26 <Alberth> or a derived class, but that may not exist
13:00:23 <Rubidium> I can't find a derived class
13:00:43 <Alberth> yeah, but something weird is going on, I agree
13:01:05 <Rubidium> i.e. a line with both class and ConstantNumeric that is not the definition of ConstantNumeric itself
13:02:01 <Alberth> constantnumeric doesn't sound like a useful baseclass either
13:02:18 <Rubidium> @calc 17288417 - 16644431
13:02:39 <Rubidium> so 650k non-ConstantNumeric Expressions
13:03:07 *** roboboy has joined #openttd
13:03:23 *** Firartix has joined #openttd
13:06:49 <Alberth> 'zoffset' : {'value': expression.ConstantNumeric(0), 'validator': self._validate_bounding_box}, <-- they are also used in constants
13:17:19 *** TWerkhoven has joined #openttd
13:18:50 *** roboboy has joined #openttd
13:27:08 <andythenorth> planetmaker: ^ opengfx renewal? :P
13:30:56 <frosch123> can you also generate extra zoom graphics? :p
13:31:37 <andythenorth> frosch123: can you scale 1 dimensional sequences?
13:31:54 <andythenorth> you can figure out an interpolation rule for neighbouring pixels
13:32:02 <andythenorth> based on contrast perhaps
13:32:32 * andythenorth is no good at maths, but you should be able to transform these pixel sequences
13:33:00 <V453000> you sure it isnt better to just draw it? :D
13:34:50 <andythenorth> frosch123: to get 4x zoom, for each point in list, copy into 4 points in a new list
13:35:15 <andythenorth> if colour of this point == colour of next point, the 4 new points will have same colour
13:35:24 <frosch123> you mean keep the same colours, just make the edges longer
13:35:26 <andythenorth> if colour of this point != next point -> some rule
13:35:47 <andythenorth> but you could smooth
13:36:32 <andythenorth> are EZ full 32bpp?
13:36:57 <andythenorth> smoothing with an 256 colour palette would be an arse tbh
13:37:05 <Rhamphoryncus> andythenorth: it hurts my head that your approach is working well
13:37:36 <andythenorth> life is just patterns
13:37:41 <andythenorth> architechture is just patterns
13:37:46 <andythenorth> vehicles are just patterns
13:38:14 <Rhamphoryncus> But it *should* be about the nuance. The subtle details that don't conform to the pattern
13:38:16 * andythenorth did technical drawing in school - it helps you think about how 3D objects can be reduced to projections, nets and meshes
13:38:24 <andythenorth> Rhamphoryncus: its 8bpp pixel art :)
13:38:38 <Rhamphoryncus> The roof is really important there
13:40:16 <Rhamphoryncus> the 8bpp is what makes it so hard. You can't actually be subtle
13:43:00 * andythenorth just pretends it's lego
13:45:23 <planetmaker> andythenorth: replacing the houses by something less noisy is something I'd quite fancy
13:45:33 <andythenorth> houses are harder :)
13:45:47 <planetmaker> wrt zoom levels: both 8bpp and 32bpp should get zoom versions
13:46:29 <Alberth> and while you are at it, in all 4 orientations :p
13:46:55 <andythenorth> in that case we should finish the generator as a standalone python package :)
13:47:21 * andythenorth just had an idea
13:48:18 <planetmaker> andythenorth: you know zephyris procedural building generator?
13:48:51 <andythenorth> he never made it shade
13:49:00 <andythenorth> he got the raster part done :)
13:53:20 <Rhamphoryncus> mid roof looks a little off. In particular it doesn't continue to the back side.
13:53:29 <andythenorth> I made a boo boo
13:55:40 <Rhamphoryncus> hrm. Better, but still not quite right
13:56:16 <Rhamphoryncus> I probably wouldn't notice in a full city though
13:59:37 <andythenorth> you could always overpaint it ;)
14:01:40 <andythenorth> prefer the building in brown? change one constant...
14:02:26 <MNIM> was that you, andy, who makes FIRS?
14:02:50 <andythenorth> MNIM: not just me
14:03:05 <MNIM> Well, anyway, I suppose you can help me then.
14:03:28 <MNIM> For some reason I can't fund a recycling plant in-game (while I can fund others)
14:03:36 <MNIM> the 'fund' button is greyed out.
14:03:42 <Rhamphoryncus> hrm. Those are 32bpp, not 8bit?
14:03:53 *** roboboy has joined #openttd
14:03:59 <andythenorth> Rhamphoryncus: 8 bit
14:04:08 <Rhamphoryncus> gimp loads it as 32bpp
14:04:12 <andythenorth> MNIM: what year of game?
14:04:14 <andythenorth> Rhamphoryncus: ah
14:04:24 <andythenorth> the originals are 8bpp
14:04:37 <andythenorth> I'm pasting screenshots zoomed in
14:04:42 <MNIM> Oh. it's year-dependent?
14:04:53 <MNIM> oh, kay, that probably solves my problem.
14:05:51 <MNIM> Ah. guess I won't be planting a recycling plant nest to my steel mill any time soon then.
14:06:09 <Rhamphoryncus> good news! My overpainting looks like shit :D
14:06:25 <Eddi|zuHause> [18.02.2012 13:28] <Rubidium> maybe preventing reopening each time might give a significant performance boost for NML? <-- my profile was created with --nfo output, so no image processing at all
14:06:58 <andythenorth> Rhamphoryncus: no proof without a link ;(
14:08:11 <Eddi|zuHause> <Rubidium> looking at cets.nml there can't that many expressions <-- i think the template evaluation is quite problematic, it's fairly large expressions that are repeated many times
14:08:54 <Rhamphoryncus> andythenorth: try making the top building 1 pixel narrower on each side
14:09:26 <Rhamphoryncus> That approach works okay
14:09:44 <Rhamphoryncus> What didn't work was tweaking the rear roofline to look like that, but without shrinking the building
14:12:06 <Eddi|zuHause> probably could be improved by caching some partial results
14:13:34 <Zuu> Doh, having both american and british spelling of the same variable is not a good idea :-)
14:14:11 <Eddi|zuHause> talking about my code?
14:15:57 <Rhamphoryncus> I'll stick with the canadian spelling, thanks *g*
14:24:10 <Zuu> andythenorth: nope, "neighbours"
14:27:22 <andythenorth> procedurally generate ships?
14:28:09 <michi_cc> procedurally generated procedures :p
14:28:26 <andythenorth> michi_cc: that's CETS
14:28:51 <michi_cc> Now that we have an NML generator and a pixel generator, we just need a spreadsheet generator (input: wikipedia category, output: filled spreadsheet)
14:30:28 * Zuu just released yet another GS library. :-) (not announced on forums yet)
14:30:46 <Zuu> But there is a good readme included with it.
14:31:50 <Zuu> Doh.. you can't view GS Library readmes ingame... :-)
14:33:15 <Eddi|zuHause> michi_cc: that would be cool, i'd just feed it "list of swiss engines" and it spiders through it :p
14:36:03 <andythenorth> now all we need is an openttd generator
14:40:50 *** LordPixaII has joined #openttd
15:02:05 *** lmergen has joined #openttd
15:09:52 *** TWerkhoven[l] has joined #openttd
15:38:33 *** andythenorth has joined #openttd
15:46:42 *** lofejndif has joined #openttd
15:46:52 *** supermop has joined #openttd
15:53:19 <andythenorth> also...hi supermop
15:56:18 <supermop> can you teach it to be metabolist
15:57:06 <andythenorth> supermop: yes it could do metabolist
16:05:11 *** Phoenix_the_II has joined #openttd
16:18:28 <supermop> it is sort of small for a tall building - even at tto scale
16:20:13 <andythenorth> that's resolvable ;)
16:20:37 <andythenorth> metabolist isn't the easiest to do this way, but it would be possible
16:20:52 <andythenorth> it doesn't look much right now
16:21:23 <andythenorth> I think you'd spend quite a while setting up the block patterns
16:21:25 <Rubidium> andythenorth: yes, the colours are wrong. The rest looks quite nice. Just go a little higher
16:21:58 <Zuu> Hmm, why is it that GS can't even depend on GS libraries on banans?
16:22:44 <andythenorth> supermop: from a quick google, metabolist looks highly procedural :P
16:22:56 <andythenorth> the tricky bit is getting the shading right
16:23:16 <Zuu> The tutorial GS want to depend on SuperLib and TileLabels.
16:23:27 <andythenorth> if I was going to write a metabolist generator (I'm not) I'd do it a little more specifically
16:23:38 <andythenorth> this generator just draws patterns of pixels
16:23:57 <Rubidium> Zuu: might be useful to highlight (SROTS/Lord) TrueBrain for that
16:23:57 <andythenorth> I'd pre-define the blocks that seem to be the basic building unit
16:24:03 <supermop> well capsule tower might be a good test for that - draw shaft or variable height, stick random boxes on the sides
16:24:14 <andythenorth> then I'd sequence chains of blocks
16:24:38 <andythenorth> the method I've got is good for vehicles - the sequences are only a few px
16:25:04 <andythenorth> for buildings, it might be better to define 'window', 'wallsection', 'metabolistblock' etc
16:25:10 <supermop> yep - the capsule tower
16:25:29 <Zuu> TrueBrain: Could you make it so that GameScripts can depend on GameScript libraries and scenarios. It would also be nice if scenarios can depend on game scripts. Hopefully OpenTTD don't get mad at cyclic dependencies :-)
16:25:40 <supermop> tto was responsible for me looking into metabolist architecture in the first place, back in the mid 90s
16:25:53 <TrueBrain> make a bug report in the website secion Zuu
16:25:57 <TrueBrain> I might not forget it then ...
16:26:08 <Zuu> I think there is one already, but I'll check.
16:26:14 <andythenorth> supermop: there are only two block styles in the capsule building
16:26:26 <andythenorth> and they're just drawn z pixels above the floor, at x, y
16:26:34 <supermop> (i snuck inside it once)
16:26:35 <andythenorth> in the TTD sprite?
16:26:44 * andythenorth means the TTD sprite ;)
16:26:55 <andythenorth> I don't count the colours, colours are trivial
16:27:08 *** Devroush has joined #openttd
16:27:22 <andythenorth> given the blocks, that sprite could be sequences
16:27:28 <supermop> well in real life you have those with the door on the end or on the side, and also with the window on the end or on the side
16:30:17 <andythenorth> this method I have in mind isn't much different from compositing a building tile from multiple sprites
16:30:22 <andythenorth> just at compile time
16:30:37 <andythenorth> and using directly sequenced pixels, rather than drawing them...
16:30:49 <andythenorth> (which sounds insane, but somehow isn't)
16:32:25 <Zuu> Hmm, I don't find the website section when creating a new task on FlySpray.
16:33:02 <Zuu> Does it have a separate flyspray URL?
16:33:34 <Rubidium> it's a separate project
16:33:43 <Rubidium> there is a dropdown/combobox in the top left corner
16:33:51 <Rubidium> with a button switch next to it
16:33:54 <Rubidium> select the website there
16:35:59 *** FLHerne has joined #openttd
16:40:32 <Rhamphoryncus> andythenorth: it IS insane, but sometimes insanity works :D
16:40:56 <andythenorth> only valid for highly regular shapes
16:42:49 <Steve^> Is there anyway to make catchment areas bigger for train stations? Other than artificially expanding the station into towns with bus stations
16:45:08 <andythenorth> artificially expand them with station tiles from a station set
16:45:17 <andythenorth> using distant-join (ctrl-click to build)
16:45:38 * andythenorth can recommend station sets, but is not a reliable witness
16:47:08 <Steve^> !! Ctrl is the magic key
16:47:22 <Steve^> I've been manually building adjacent stations
16:47:44 <andythenorth> using a station newgrf will make it prettier
16:47:47 <Steve^> I knew It'd be a good idea to ask in here :)
17:05:06 <appe> is there any grf that enables me to stimulate the standard industries more?
17:05:16 <appe> for instance, make mines produce a bit more
17:05:23 <appe> would make my day a bit brighter.
17:06:27 <Zuu> Sounds like a feature request for a new OpenGFX+ Industries parameter.
17:06:59 <Zuu> (unless there is one already)
17:07:42 <appe> would be neat to be able to bring sufficient needs to stimulate the industry production in a matter like this (in the picture).
17:07:59 <appe> for instance, workers, tools or such.
17:08:11 <appe> doesnt FIRS have something similar?
17:08:24 <Eddi|zuHause> yes, "mining supplies"
17:08:26 <Zuu> Oh, sorry, I though you wanted to just multiply the production levels by say 1.25 generally for industries.
17:08:32 <appe> Eddi|zuHause: ah, i see.
17:08:35 <Eddi|zuHause> or rather "engineering supplies"
17:08:44 <appe> Eddi|zuHause: ..and vehicles!
17:09:04 <appe> Eddi|zuHause: something like that would be neat to use applied to the standard industry models.
17:09:09 <appe> do we have something like that?
17:09:22 <Eddi|zuHause> appe: make a suggestion for FIRS economies
17:10:43 <andythenorth> appe: you'd need a source industry for the supplies...
17:11:15 <andythenorth> one that's in default set, in all climates
17:12:39 <Eddi|zuHause> make factory/sawmill/refinery output a second cargo, and input those to oil wells/mines/forests (cyclic)
17:12:42 <Steve^> I don't see where infrastructure costs appear in the end of year finances
17:12:56 <appe> Eddi|zuHause: that sounds resonable.
17:13:01 <Steve^> my infrastructure is greater than my property maintenance
17:13:39 <Eddi|zuHause> so you get a chain mine->factory->oil well->refinery->forest->sawmill->mine or something
17:14:15 <Eddi|zuHause> as an incentive to supply all branches of the economy
17:14:34 <appe> a system like that would make small maps more and more fun
17:15:24 <appe> since development into smaller and smaller scales will be possible
17:17:10 <andythenorth> that's a standalone grf imo
17:17:20 <andythenorth> it's just modify existing industry behaviour
17:17:56 <andythenorth> it's a mini-set, the only graphic needed is a cargo icon for the supply cargo
17:19:21 <andythenorth> you need to learn nml in that case :)
17:23:11 * andythenorth has stopped writing code
17:23:14 <andythenorth> like Eddi|zuHause
17:26:07 <andythenorth> we have code to write the code
17:27:36 *** mahmoud has joined #openttd
17:29:37 * andythenorth now has a load of test pixel generator code in the BANDIT repo
17:29:52 * andythenorth wonders whether to move this to a standalone project
17:32:15 *** HerzogDeXtEr has joined #openttd
17:34:15 <Zuu> Hmm, I got about twice as many downloads of the Tutorial GameScript as the scenario for version 6. And with version 7, there is already more GS downloads than scenario downloads.
17:34:58 <Zuu> This dispite the fact that you need to have a hidden setting active in OpenTTD in order to being able to even load the GS without the scenario.
17:38:35 <Eddi|zuHause> maybe person A gives person B the scenario, but person B must still download the script?
17:39:45 <Zuu> I noticed though that I had forgoten to put a big warning in the GS that you need the scenario too on bananas. Probably why the difference was so big.
17:40:17 <Zuu> There was a big warning in the scenario, but not in the GS. Now both have big warning messages. :-)
17:42:30 <CIA-1> OpenTTD: rubidium * r23963 /trunk/src/openttd.cpp: -Fix [FS#5072]: do not look for missing sprites twice during startup
17:46:04 <Zuu> Eddi|zuHause: I guess that is also a possible scenario.
17:46:59 <Rubidium> or... I need an AI... don't know which one, select everyone from the content list in the ai menu
17:48:10 <Rubidium> you could fudge the supported version so it doesn't show up in the list unless the scenario puts a dependency on it
17:48:23 <Rhamphoryncus> Rubidium: got my timetable patch working :) Other than one latent issue with passengers continuously extending the loading process
17:48:56 <Rubidium> although it might (in theory at least) be possible to set a dependency on the scenario from the game script
17:49:44 <Rubidium> yes, the conductors are *very* gracious to late comers
17:50:07 <Eddi|zuHause> Rhamphoryncus: i though we solved that some time ago in trunk
17:50:29 <Zuu> The Tutorial GS is only visible in the GS list for GS/AI-developers (don't remember if there is a separate setting for GS). The method to put a wrong OpenTTD version requirement would need FS#5073 to be fixed first so that the scenario can depend on the GS.
17:50:32 <Rhamphoryncus> oh, the passenger bit?
17:53:17 <Zuu> But that might then actually be quite clean then. Users only seeing the scenario which is what they would interact with.
17:54:17 <Rubidium> Zuu: try content download now (the AI one first, or the one from play scenario)
17:54:50 <Rubidium> though for full effect you need to remove them from OpenTTD's 'search path'
17:55:32 <Eddi|zuHause> @openttd commit 20506
17:55:32 <DorpsGek> Eddi|zuHause: Commit by michi_cc :: r20506 /trunk/src (economy.cpp vehicle_base.h) (2010-08-15 22:37:30 UTC)
17:55:33 <DorpsGek> Eddi|zuHause: -Change: Vehicles will now stop loading after a load cycle that loaded less than possible, unless it's a full load order. This should improve behaviour with gradual loading and cargo continuously trickling in.
17:55:48 <Eddi|zuHause> Rhamphoryncus: i think that was the revision
17:55:53 <Zuu> The one form AI/GS-window now shows the scenario and selects it if I click the Tutorial GS.
17:56:01 <Rhamphoryncus> Eddi|zuHause: alright, I'll take a look
17:56:12 <Zuu> The dependancy works also the other way around.
17:57:22 <Zuu> I don't have them according to bananas (probably because I don't develop in content_download)
17:58:02 <Rubidium> for the scenario the server attached a 'unique' id (needed for updates)
17:58:06 <Zuu> I have both in Documents\OpenTTD\game\Tutorial
17:58:16 <Rubidium> for the GS the server might replace newlines
17:59:03 <Zuu> Both are unchecked in the banans list.
17:59:14 <Zuu> The scenario is not even in the search path.
17:59:30 <Rubidium> yep, missing unique ID for scenario and windows -> unix newlines for GS
18:00:46 <Zuu> But that isn't really an issue. It only affects me. :-)
18:01:50 <Zuu> So will you keep the dependancies as you set them or was this just an experiment? Eg. should/can I remove the warnings in the descriptions on bananas?
18:02:16 <Zuu> Still, ideally *someone* need to make a patch for bananas to allow me to set the dependency myself for updates.
18:04:49 <Zuu> Though, given that I will probably receive string updates and perhaps make a new update soon, you don't want to get into the database and set it manually each time. So perhas remove it and people will not know that you can do it. ;-)
18:08:23 <DorpsGek> Eddi|zuHause: 8.93333333333
18:11:23 <Rubidium> Zuu: if you don't update too often it shouldn't be a (big) problem to add this to the database
18:15:01 <appe> what kind of sorcery is this
18:15:15 <appe> started openttd with chrome running in the background
18:15:27 <andythenorth> the pixel generator has *no* guarding against exceeding the blue box etc :)
18:15:29 <appe> the clip was showed ontop of the game
18:15:34 <andythenorth> I don't think I'll add any either
18:15:35 <appe> but not the rest of the site?
18:16:21 <appe> not related to the game, i guess?
18:16:35 <appe> it only happends with openttd, thati s.
18:17:07 <appe> why do i have to correct 50% of everything i say.
18:17:56 *** supermop has joined #openttd
18:19:33 *** |Jeroen| has joined #openttd
18:21:23 <supermop> generative helicopters?
18:27:49 <Zuu> Rubidium: Thanks, then I'll remove the dependancy warning.
18:29:03 <Rubidium> are you going to upload both the GS and a scenario each time?
18:29:13 <Zuu> Though, that might overwrite your manual changes.
18:29:42 <Rubidium> okay, then there's no need to note the current IDs somewhere
18:30:24 * Rubidium might be able to remove the warning as well
18:30:37 <Zuu> The scenario reference a specific version of the GS. And the GS that is uploaded is set to only load savegames of that particular version.
18:31:13 <Rubidium> there... warning gone
18:31:58 <andythenorth> Alberth: I'm not 100% sure how to package the generator into a simple standalone utiity
18:32:08 <andythenorth> it only needs one method currently
18:32:47 <andythenorth> it accepts: 1 spritesheet (PIL image object), a mapping of colours to sequences, a mapping of sequence definitions
18:32:58 <andythenorth> it returns: 1 PIL image object
18:33:18 <xiong> I started to build a scenario and now I want to upgrade a NewGRF to a current version; I have installed the newer version. I don't seem to be able to alter the set of NewGRFs associated with the scenario, let alone in the middle of a running game.
18:33:38 * andythenorth recalls python has some method like __main__ which can be called on a class
18:33:46 <andythenorth> but that might be the wrong route
18:35:00 <xiong> I take it this is not fixable, Alberth.
18:35:13 <Alberth> a mapping of colours to sequences, ugh
18:35:20 <andythenorth> in one respect what I actually want to do is extend the methods available on the spritesheet, so I can call im.generate_pixels(colour_keys, pixel_sequences)
18:35:26 <andythenorth> but that's extending PIL
18:36:13 <Rhamphoryncus> Rubidium: fixed it, thanks. Regression due to my patch.
18:36:56 <xiong> BTW, I'm playing 1.2.0-beta4 now. Kudos; it's a real improvement.
18:37:13 <Alberth> andythenorth: give it an extra image with the sequences?
18:37:26 <andythenorth> I considered that
18:37:46 <andythenorth> it's quite neat for sequences that only vary in y direction
18:37:54 <andythenorth> it falls apart for sequences where x varies
18:37:57 <Alberth> what's 'a mapping of sequence definitions'
18:38:23 <Rubidium> Zuu: *massive* bug ;) I disobeyed the tutorial and clicked on the hangar for the order. It told me to remove the order and make an airport order (which I did), and now the bug... the window saying that isn't closed automatically even if it has the "Close" button implying it would be closed automatically
18:38:34 <andythenorth> Alberth: here's a current gestalt file - but I'm reversing the approach
18:38:47 <andythenorth> so the gestalts will call pixel generator, rather than vice versa
18:39:55 <Alberth> that call is missing there?
18:40:29 <andythenorth> doesn't exist yet
18:40:41 * andythenorth is now doing 'design before code' :o
18:40:46 <Rubidium> Zuu: also the aircraft tutorial doesn't seem to be the first chapter even those the final one says it is
18:41:04 <andythenorth> maybe I should just pitch into code
18:41:13 <Zuu> Rubidium: Oh, I should add that that is only valid for messages displayed by the MessageWindowStep class ;-)
18:41:25 <Alberth> so what does the input look like, except for the image?
18:41:34 <Zuu> Or better for the user, it is not valid for warning or question type messages :-)
18:41:39 <andythenorth> currently looks like the paste
18:41:45 <andythenorth> there will be more
18:42:05 <Rhamphoryncus> andythenorth: you can.. code before design?
18:42:19 <Alberth> Rhamphoryncus: that's easy :)
18:42:22 <andythenorth> I have also employed lots of people who think the same :P
18:42:26 <andythenorth> not always with good results
18:42:52 <Zuu> Though, I might make it close the warning message when you accomplished the task
18:42:52 * andythenorth has spent ~£30k learning about 'design before code[sometimes]'
18:42:58 <Rhamphoryncus> It's a foreign concept to me. I could spend a week designing and redesigning before writing a single line.
18:43:27 <andythenorth> code can be expensive if you don't design it first :P
18:43:43 <Alberth> andythenorth: the input looks complicated enough to me to not try pusing it in some standard text format
18:44:07 <andythenorth> Alberth: on my current thinking, I don't see how the gestalts can be anything except a mix of config and code
18:44:07 <Alberth> so that leaves you either a .py file as main entry point, or a custom parser
18:44:19 <andythenorth> I think each gestalt file is quite sophisticated
18:44:32 <andythenorth> much like the nfo or nml for a vehicle can be quite sophisticated :P
18:44:56 <andythenorth> I don't like it much, but it's cleaner than writing spaghetti code with 10 bazillion 'if' conditions
18:45:17 <andythenorth> and a 5-level deep chain modifying constants
18:45:34 <Alberth> you can keep the data separately by importing it from your main scripy
18:45:43 <CIA-1> OpenTTD: translators * r23964 /trunk/src/lang/ (8 files in 2 dirs): (log message trimmed)
18:45:43 <CIA-1> OpenTTD: -Update from WebTranslator v3.0:
18:45:43 <CIA-1> OpenTTD: belarusian - 2 changes by Wowanxm
18:45:43 <CIA-1> OpenTTD: german - 6 changes by NG
18:45:43 <CIA-1> OpenTTD: hungarian - 14 changes by IPG
18:45:44 <CIA-1> OpenTTD: lithuanian - 54 changes by Stabilitronas
18:45:44 <CIA-1> OpenTTD: portuguese - 4 changes by JayCity
18:45:48 <appe> are we talking fullerenes?
18:46:18 <Alberth> the usual on-topic talk :)
18:46:42 <andythenorth> Alberth: I'll bash at some code once baby #1 is out of the bath and baby #2 is asleep :P
18:47:32 <Alberth> but a .py as main script seems like the simplest approach to me atm
18:48:34 <Zuu> Rubidium: The last message says "you have now completed your first transport route in OpenTTD.". There navigation chapter will probably not teach any transport routes. Though you could now take the ship chapter first and then the aircraft chapter, but then you have already been warned that you are not taking them in the order that the tutorial is designed for.
18:48:57 <Zuu> s/There navigation/The navigation/
18:49:41 <Rubidium> STR_AIRPLANES_1_4_5_DONE :You have now completed the first chapter of this tutorial.
18:49:42 <andythenorth> Alberth: this may not make sense with explanation...but it's my current spec
18:49:53 <Rubidium> STR_AIRPLANES_1_1_1_INTRO :Aircraft - Building an Airport{}{}In this first chapter
18:50:22 <Zuu> Oh, my bad, I didn't reach the end of the chapter :-)
18:50:31 <Zuu> Only the summary heading...
18:51:47 *** LordPixaII has joined #openttd
18:52:05 <andythenorth> a gestalt = a vehicle type, providing all colour variations, load variations etc
18:53:12 <supermop> hmmm i wonder if i can get away with playing go at work?
18:54:49 <andythenorth> supermop: learn to generate buildings instead ;) That *is* work...
18:54:52 <appe> where does glass go in the ECS grf?
18:54:56 <andythenorth> for you at least ;)
18:56:06 <Eddi|zuHause> the car factory?
18:56:20 <Eddi|zuHause> click the glass industry, there you can see the industry chains
18:56:28 * Rubidium can at least get away with "playing" with train network models at work ;)
18:56:31 <xiong> YAPF now recommended for ships? I seem to recall Original used to be recommended; YAPF didn't work so well with ships. Anybody know anything about this?
18:57:42 <Eddi|zuHause> i should probably stop trying to be helpful to xiong...
18:58:32 <valhallasw> xiong: I would suggest to use the CNPF: Chuck doesn't find paths - the world just shapes so that the straight path is the right one.
18:59:21 * xiong hopes valhallasw is joking but checks anyhow
19:00:17 <xiong> Okay, valhallasw, good one. Ha ha.
19:01:42 <supermop> andythenorth: right now my job is furniture, doing anything architecture related makes it look like I am getting ready to leave to go back to that.
19:01:45 <Noldo> I haven't heard of any progress on the ship PF since someone did a patch that did area based search
19:01:47 <valhallasw> (I don't actually have an answer. As far as I can remember, the problem with YAPF for ships was CPU usage (because there are many possible paths). If it just works for you, and your computer doesn't grind to a halt, you're probably fine.)
19:03:14 <xiong> But the Advanced Settings GUI now says 'YAPF (Recommended)'.
19:04:06 <xiong> Not an urgent question for me now. I'm playing an all-land, all flat test map. :(
19:04:18 <xiong> But inquiring minds want to know.
19:04:50 <Alberth> but you've made it very clear you don't want help, to me at least
19:06:08 <andythenorth> supermop: oops :o
19:06:16 <andythenorth> procedural furniture? :P
19:06:36 <supermop> i was trying to get us to do that last year
19:06:52 <supermop> it was over my head but i was the one who mentioned it
19:07:12 <supermop> the way we work would be really well suited to it
19:07:49 <supermop> and automatically generate shop drawings and renderings for architects based on what we plan in our tool
19:08:22 <andythenorth> that's not done already?
19:08:29 <andythenorth> is your tool 2d or 3d?
19:08:50 <supermop> we produce axonimetrics and elevations only
19:09:02 <supermop> it is sort of 3d in as much as tt is
19:09:16 <supermop> its a java based tool we wrote ourselves
19:09:43 <Rhamphoryncus> still much to clean up though, and whatever gui changes are necessary
19:09:44 <supermop> with all sorts of problems
19:09:54 <supermop> but it is still industry leading
19:10:04 <supermop> (says something about the industry)
19:10:29 <supermop> (we are way out ahead on that just because we thought it would be neat to have a tool at all)
19:10:46 <andythenorth> anyone suggest a name for the pixel generator? I need to move it to it's own package
19:11:47 <Rhamphoryncus> andyspixelfactory
19:11:48 <supermop> Procedurally iterated Graphics system
19:11:50 <Rubidium> or.. LordPixaII as it's full name and Pixa as it's short name. That way you have tab completion in here ;)
19:12:08 <andythenorth> pixa will do nicely
19:15:14 <Zuu> Rubidium: Do you use one of those railway simulation models or a more generic model like Visum/Emme?
19:17:37 <Zuu> At my work there is a merklin railway track with a train on it in the reception. :-)
19:18:16 * Rubidium has no clue what kind of track there is on our office, though it's just a few pieces of straight track with some trains on them
19:21:41 <Zuu> Is it that what you were aiming at when stated that you got to play with railway models at work?
19:26:12 <supermop> my valentine is now working!
19:26:32 <andythenorth> is there a good way to handle that?
19:26:44 <andythenorth> is it even a valid aim?
19:26:49 <Rubidium> my company does (all kinds of) rail measurements, and we need to report on the customer's model of their railway network
19:27:19 <Eddi|zuHause> andythenorth: if __name__ == "__main__":?
19:27:36 <Zuu> okay, interesting to read
19:27:39 <Rubidium> but ofcourse all customers have a different model, and thus we have a generic model and all kinds of code to go between models
19:27:43 <Rhamphoryncus> Eddi: standard python convention
19:27:56 <Rhamphoryncus> damnit, gotta read better
19:28:55 <Zuu> Of course, why would there be a standard? :-)
19:29:18 <Rubidium> because WGS84 sucks ;)
19:29:54 <Rubidium> but that's where the petroleum industry comes into play
19:29:58 <Zuu> In Sweden there is generally only two different geo coordinate systems (none of them is WGS84)
19:33:10 <Zuu> And then there is about 8-10 variants of RT90 :-)
19:36:08 <Rubidium> it's the ID the petroleum guys gave it
19:36:25 <Rubidium> and they have a massive database of all kinds of projections
19:36:37 <Rubidium> making it pretty easy to go from one projection to another
19:36:53 <Zuu> I sometimes get lost in the projections list in our GIS software.
19:37:03 <Alberth> andythenorth: I'll clean it up a bit
19:37:42 <Rubidium> spatial reference only knows ~8000 of them ;)
19:50:32 <andythenorth> I created and then deleted a generate method :)
19:51:56 * andythenorth copies the paste...
20:13:16 *** tokai|mdlx has joined #openttd
20:16:47 <andythenorth> so I want some kind of module for handling gestalts
20:16:55 <andythenorth> which each gestalt file then imports
20:17:24 *** Firartix has joined #openttd
20:17:36 <Alberth> import them all , and put them in a dict?
20:18:19 <andythenorth> the gestalts will get more complicated
20:18:36 <andythenorth> they need to run multiple render passes or composite images
20:18:40 <andythenorth> specfic to each gestalt
20:19:28 <andythenorth> maybe time to try some more actual shapes
20:19:36 <andythenorth> to see what else is needed
20:19:47 <Alberth> gestalt.generate(input_name, output_name)
20:20:01 <andythenorth> something like that yes
20:20:07 <andythenorth> output name is actually by convention
20:20:24 <andythenorth> I just want to call gestalt.generate from my main.py
20:20:46 <andythenorth> probably for each vehicle in BANDIT config, or for one vehicle at a time (with command line args)
20:21:18 <andythenorth> gestalts is a package now with __init__.py
20:21:26 <andythenorth> what happens if I put code in the __init__.py?
20:22:15 <Xaroth> you can put stuff in __init__.py
20:23:01 <Xaroth> if you put stuff in bla/__init__.py you can import it 'from bla import <something>' instead of 'from bla.something import something'
20:23:20 *** kais58_ is now known as kais58
20:25:21 <andythenorth> I import pixa.py (the generator code) to the gestalt file
20:25:26 <andythenorth> then I call render on the generator :)
20:25:31 <andythenorth> generator? gestalt :P
20:28:03 <andythenorth> can I consolidate those somehow to a single import?
20:28:13 <andythenorth> import gestalt ? or such
20:34:00 <Alberth> why do you want to reduce the #imports in a gestalt?
20:34:38 *** DayDreamer has joined #openttd
20:37:29 <andythenorth> Alberth: reduce duplication
20:37:32 <andythenorth> not sure I can though
20:37:40 <andythenorth> this is a bit like adding objects in a web app I think
20:37:56 <andythenorth> you want page_1 to behave differently to page_2
20:38:03 <andythenorth> but both use various utilities
20:38:04 *** dragonhorseboy has joined #openttd
20:38:24 <dragonhorseboy> any of you perhaps know if ottd can be compiled without any sound files on linux?
20:38:26 <andythenorth> you have to import modules, define local constants, and write logic
20:38:38 <andythenorth> dragonhorseboy: that wasn't an answer to your question ;)
20:39:22 <dragonhorseboy> lol andy, I already figured that out :p
20:39:49 <Alberth> dragonhorseboy: there is a 'nosound' package
20:40:03 <Rubidium> Alberth: that's not even needed
20:40:15 <MNIM> Heh. It takes a LONG time to traverse a 1024x1024 map at 99kmh.
20:40:21 <Rubidium> OpenTTD starts perfectly fine without opensfx or the original sample.cat
20:40:26 <Alberth> but for compilation, you don't need sound files at all :)
20:40:53 <MNIM> Some of my freight trains take two years for a single return trip.
20:41:00 <Rubidium> actually... nosound and nomusic are part of the openttd installation
20:41:41 * andythenorth has written some awfully circular code
20:41:50 <andythenorth> file under 'fix later'
20:42:47 <dragonhorseboy> alberth thanks, just wondering about why it was needing a 100+MB dependancy just for audio alone ... so guess I'll see about compiling from source and see how that goes
20:43:11 <Rubidium> what needs that dependency?
20:43:28 <dragonhorseboy> ottd.i686 itself obviously
20:43:31 * Rubidium wonders which packager did depend on a music player
20:43:41 <dragonhorseboy> heh sorry ln...never could spell that word sometimes
20:44:54 <Rubidium> any sane OpenTTD packager would recommend or suggest openmsx + music player, but shouldn't depend on it
20:45:34 <Alberth> 'sane' and 'packager' in one sentence :o
20:45:50 <dragonhorseboy> rubidium well the packager is the os' not openttd's so :-)
20:46:27 <Rubidium> the packager did package OpenTTD right, so he's OpenTTD's packager (for a particular OS/distribution)
20:47:34 <dragonhorseboy> heh yeah thats fair enough
20:48:37 <Alberth> dragonhorseboy: it's a dependency invented by the package creator, openttd itself can live without, or just with nosound just as well
20:49:09 <dragonhorseboy> yeah alberth...thats why I thought that it might be plausible to just compile it from source instead....looking that way by now :)
20:49:28 <dragonhorseboy> at least thankful for the opengfx so I don't have to try figure how to copy these files over to that laptop heh
20:50:01 <Rubidium> the compile dependencies are probably quite a lot as well
20:52:00 <dragonhorseboy> actually rubidium...not really..its just the typical make/gcc/zlib things that are usually already installed anyway :)
20:53:49 <Alberth> dragonhorseboy: you need a lot of libraries too :)
20:55:52 *** LordAro has joined #openttd
20:57:21 <dragonhorseboy> alberth just a silly question as its been some time since I last played it myself...I assume openttd has train path reserving and programmable signals?
21:00:41 <dragonhorseboy> hmm...how come no or its just that someone simply decided to not bother work on it yet?
21:01:12 <Alberth> many people consider current signals too complicated already
21:01:33 <dragonhorseboy> alberth hmm...I see
21:02:29 <dragonhorseboy> alberth for me (in ttdxp mind you) I always have light long lines and rather than bothering with go-to-waypoint or holding loops I just use the signals themself to manage trains by types
21:02:36 <dragonhorseboy> but thats my own style after all I guess
21:03:21 <Alberth> wouldn't railtype help here?
21:04:38 <andythenorth> kind of works, but I want to redefine value of BULK_CARGO when passing it
21:04:47 <andythenorth> but the lists I'm passing don't see the redefinition
21:05:07 <andythenorth> should I def the list in a method, then call that?
21:05:11 <Alberth> I think the main problem with using signals is that people bolt all kinds of functionality to it, and it becomes one big blob of complicated functionality
21:06:31 <dragonhorseboy> alberth heh well I'll be honest with you..there's no need for more complications than just simply traintype or pathset ones.. that can't be many signals in the first place
21:06:35 <dragonhorseboy> but what do I know of other players
21:06:59 <dragonhorseboy> whats railtype tho?
21:07:21 <planetmaker> play a game with NuTracks
21:07:39 <planetmaker> and possibly the 2ccTrainset. Then you know
21:07:58 <Alberth> basically, you have more variations than normal, electric, mono, maglev tracks
21:09:03 <Alberth> andythenorth: the value it originally contains is copied into the literal, so any change of the name later is not seen
21:09:43 <Alberth> thus make a function that creates a list literal with the right value on demand
21:11:37 <dragonhorseboy> unless I'm missing something nutracks might be just useless for mixed traffic lines since everything would be laid to the same E125 type
21:12:32 <andythenorth> the list literal is included in a dict
21:12:36 <Alberth> could be, I never played with railtypes, I just know it exists
21:12:40 <andythenorth> I might need to def the dict as well :o
21:13:20 <dragonhorseboy> alberth mm its ok anyway
21:15:37 <Alberth> hmm, not enough money to lay tracks :p
21:16:31 <dragonhorseboy> alberth I do sometimes do quite basic things with programmable signals only because I'm trying to emulate real life dispatching without any actual signal towers you know
21:16:44 <dragonhorseboy> one example I still do from time to time goes like this...
21:18:24 <dragonhorseboy> first route early on takes a hard way through the mountain due to little money ... eventually railroad prospects but the old route starts to remain a headache with stregthened short trains...
21:19:25 <dragonhorseboy> finally spend a big chunk of budget on a longer route that makes much easier uphill work...and set new junction signals that any short freights can slog up the old line while everything else are diverted
21:25:16 <dragonhorseboy> can be amusing to see an express E16 chasing a coal E75 up to till the junction where the E16 then literally passes the E75 even although it had a longer path
21:25:27 * dragonhorseboy always plays with dbsetxl in temperate yeah
21:26:22 <andythenorth> Alberth: I have some kind of object caching issue :o
21:26:49 * Alberth always plays with the opengfx vehicles & industries, except today, as opengfx industries does not like toyland :(
21:28:18 <andythenorth> I have two colours: 4 and 77; if I print out the value of the P objects being passed to the render module, I see 4 for the first call, then 77 for the second call
21:28:32 <Rhamphoryncus> andythenorth: generate() in the paste before was assigning to a local named BULK_CARGO. You need a "global BULK_CARGO" statement if you want to assign to a global
21:28:44 <andythenorth> but the spritesheet is drawn with 4 in both cases
21:28:57 <andythenorth> Rhamphoryncus: I've scrapped the globals ;)
21:29:14 <Rhamphoryncus> yeah, figured it was worth explaining anyway
21:29:20 <Rhamphoryncus> it tends to get people
21:29:20 <dragonhorseboy> alberth heh if I had to play with original limited selection of vehicles I would had rather ended up with a hundred asiastars all over the place which makes no sense :p
21:29:32 <andythenorth> spritesheet is probably modified :o
21:29:50 <dragonhorseboy> alberth I used to try FIRS on and off a bit before...this was while it was still more or less in progress yet
21:30:03 <andythenorth> yes, the spritesheet is being modified
21:30:13 <andythenorth> I need to tell PIL how to copy it
21:30:27 <andythenorth> or I need to reload it from disk, which seems...inefficient
21:30:32 <dragonhorseboy> don't like either ukrsi due to stock-against-chain problem ... and ecs is just a bit too wieldy especially with the chemical chains being a bit weird
21:30:58 <Rhamphoryncus> aside: lowercase module names are recommended.
21:31:50 <dragonhorseboy> alberth and by stock-against-chain I meant like eg the steel mill refusing to accept the amount of ore I left even although this equival amount of steel is actually needed for a processing plant which refuses to produce food without steel in first place
21:31:55 <Alberth> andythenorth: I was already wondering how that code could break :)
21:31:57 <Rhamphoryncus> mostly for consistency, but also to minimize trouble on case-insensitive filesystems
21:32:11 <dragonhorseboy> don't have this issue with FIRS which is a bit easier on my thing with running mixed trains at times
21:32:22 <dragonhorseboy> andythenorth I imagine :p
21:32:40 <andythenorth> dragonhorseboy: I also run mixed trains ;) So there is some bias in the design of FIRS
21:33:03 <andythenorth> ok andythenorth now has a not-insane pixel generator
21:33:12 <andythenorth> a bit more work and it's kind of done for v1
21:33:22 <dragonhorseboy> andythenorth its hard to find real freight trains that are not 100% solid on one single cargo type right? :)
21:33:35 <Alberth> dragonhorseboy: I tried ECS a two-three times, and got fed up with the stockpiling behavior very quickly, so I switched to FIRS (or default industries). Never tried ukrsi
21:33:36 <Rhamphoryncus> andythenorth: so, planning v2 yet? ;)
21:33:38 <Rhamphoryncus> <--- not helping
21:33:46 <dragonhorseboy> even these long trains of containers in north america actually still can have one or two tanker cars in the consist too...go figure
21:35:41 <dragonhorseboy> anyway need to go....only meant to come in for a short time to ask about compiling :p
21:35:48 <dragonhorseboy> might be back tomorrow tho :)
21:35:56 *** dragonhorseboy has left #openttd
21:40:09 *** JVassie has joined #openttd
21:49:27 <planetmaker> seems like a valid bug, Alberth
21:49:46 <planetmaker> and looks ugly :-(
21:54:25 <Eddi|zuHause> hm... the StEG doesn't have any sane express engines
22:02:27 <Alberth> the rivers make the land much more enjoyable
22:02:45 <Eddi|zuHause> aye, the rivers are awesome
22:03:02 <Alberth> no longer can you put long straight tracks down without thinking :)
22:05:10 <Alberth> planetmaker: why does opengfx+industries throw a fatal error for toyland?
22:05:44 <andythenorth> rivers need diagonals
22:05:55 * andythenorth makes rod for own back
22:06:31 <supermop> rivers and oceans should be able to have similar types of edges
22:06:51 <planetmaker> /* This NewGRF currently does not work properly in toyland
22:06:51 <planetmaker> * climate. Disable it in that case
22:07:17 <planetmaker> mostly it has to do with cargo definitions afair
22:07:36 <Alberth> ok, known issue it seems :)
22:07:48 <planetmaker> Rather "not designed (yet) for toyland"
22:08:39 <planetmaker> the check could probably be disabled... with a strong warning that graphical glitches are for the user to worry about
22:09:31 <planetmaker> Alberth: mostly it's a case of "we don't want to deal with those bug reports" :-P
22:09:55 <planetmaker> do you need it for toyland2mars?
22:10:04 <planetmaker> I'll add an exception there then
22:10:55 <Alberth> no, I play plain toyland :)
22:11:11 <planetmaker> OpenGFX+ Industries has no single toyland industry yet
22:11:54 <Alberth> I expect so, otherwise it would be REALLY strange :)
22:11:57 <planetmaker> I agree though, finally it should also support toyland. But that shares nothing with the existing industries, so it's a bit more work.
22:12:10 <planetmaker> Or one accepts that they always look out-of-place also wrt ground tiles
22:12:13 *** tokai|noir has joined #openttd
22:12:13 *** ChanServ sets mode: +v tokai|noir
22:12:26 <Alberth> but a fatal error is so strong
22:12:48 <Alberth> just a silent 'do nothing' would be nicer.
22:13:09 <Eddi|zuHause> you can simply disable the grf, in NFO terms "skip to end of file"
22:13:11 <Alberth> or error 'we don't do anything'
22:13:39 <planetmaker> Yes, that's possibly a good point. Let's change that
22:13:53 <Alberth> as a kind of reminder (which might get tedious, but perhaps better than getting reports 'it does not work' ?
22:15:56 <planetmaker> Alberth: but it poses the question then: "why do the NewGRF parameter not work in toyland" when the user there selected like wood chain, farm chain and iron ore chain
22:16:42 <planetmaker> after all, the point is (also) to select those industries which you'd like
22:17:14 <andythenorth> Alberth: "it lives"
22:17:30 <andythenorth> I've cleaned up the generator files and committed to BANDIT
22:17:42 <andythenorth> there's some clunky code in the gestalt
22:18:09 * andythenorth refuses to use %s for string concatenation :P
22:19:53 <Alberth> planetmaker: good point
22:20:43 <Alberth> andythenorth: good idea, I removed one "%s\n%s" from the ConfigParser module once, as it took ages to load a big file.
22:20:56 <Alberth> andythenorth: and nice that it 'lives' :D
22:21:03 * andythenorth generates grain sprites
22:21:11 <andythenorth> that was ~2s work for me
22:21:20 <Alberth> does it do plastic fountains too ?
22:22:18 <andythenorth> could generate some :P
22:25:23 <xiong> Is it possible for town to demolish my road and build on that tile? I think I've observed this but it's hard to tell.
22:26:32 <andythenorth> not if you own the road
22:26:32 <xiong> I've turned off "remove absurd road elements" and towns are not allowed to build roads at all. Don't know if this relates.
22:26:58 <andythenorth> if it happens to road you own, it's a bug
22:27:00 <xiong> Even if I leave "remove absurd road elements" on?
22:27:11 <andythenorth> might happen, but if it does, it's a bug
22:27:37 <xiong> These are short little access roads I'm throwing in to force the center of 3x3 blocks to build. They very rarely build without such directly adjacent access.
22:28:52 <planetmaker> it's possible on half-road tiles
22:29:09 <xiong> Aha! As I suspected, planetmaker.
22:29:44 <xiong> Does "remove absurd road elements" affect this either way?
22:31:14 <xiong> A full tile road, straight in from the edge, presents the dead end to the center tile; and I'm fairly sure dead ends of that sort -- full tile dead ends -- inhibit construction. Not absolutely, but somewhat.
22:32:15 <xiong> So for maximum effect, in some places I've been running half a tile to the center, with a T cross. This seems to encourage growth more than the full tile straight in. In some cases, I've just done a half tile.
22:32:26 <xiong> Those must be the ones that I'm losing to town.
22:36:40 <Rhamphoryncus> xiong: oh, it just occurred to me: town growth operates based on randomly picking a path from the center of town. A T could provide multiple paths in.
22:37:21 <xiong> Well, that's interesting, Rhamphoryncus.
22:38:04 <xiong> For each build, the grid is *walked* from town center to a vacant tile!?
22:38:50 <xiong> I do really think the center of 3x3 blocks should build on their own. Rarely, they do.
22:39:14 <Rhamphoryncus> As I said last time we discussed this: they do for me. It must be fixed in trunk
22:39:33 <xiong> I'm disturbed by some backsliding I'm seeing: downtown tiles that long ago built their centers but now have gone to grass.
22:40:24 <xiong> I upgraded to 1.2.0-beta4 and my building set is TTRS 3.13. I don't even know if the town set should affect it.
22:40:52 <Rhamphoryncus> Go into the scenario editor and experiment
22:41:13 <xiong> Um, what advantage in the scenario editor?
22:41:23 <Rhamphoryncus> you can place a town and tell it to expand
22:41:47 <Rhamphoryncus> Of course it's also conceivable that it behaves different there
22:41:48 <xiong> Same algorithm? I mean, I've got an authentic game on now.
22:42:05 <Rhamphoryncus> I assume it's the same, but I might be wrong
22:42:56 <xiong> I let the town grow to about 20K pop without tinkering with the road system. Very few centers built -- 3 out of 16 downtown blocks.
22:48:25 <xiong> What are you trying to stop, Stimrol_?
22:49:06 <Stimrol_> that you can have this as the same station
22:49:48 <xiong> Um, do you want to build two logical stations? Or prohibit one logical station?
22:49:52 <Stimrol_> this is in a way cheat because like this you can get for example wood from two forest
22:50:23 <xiong> Different players see it differently. I like to play with disjoint stations. We're all different.
22:50:49 <Rhamphoryncus> Stimrol_: the only practical way to stop it is have a small maximum station size
22:51:22 <Stimrol_> it is 12 now, default
22:51:39 <Stimrol_> so you mean have highest like seven
22:51:51 <Rhamphoryncus> Yup. Or 4 and really suffer ;)
22:52:14 <xiong> If you want to prohibit disjoint stations, set distant_join_stations = false
22:52:26 <Stimrol_> does not work I have it like that
22:52:44 <xiong> But it will still be possible to form a disjoint station; you can "walk" it out.
22:52:47 <Rhamphoryncus> distant join doesn't stop you from having disjoint stations. It only makes them awkward to build because you have to walk them out. Which is lame.
22:52:54 <Stimrol_> you build and connect each one then you delete the station inbetween
22:53:15 <xiong> But then, what are you doing, Stimrol_? Playing alone or setting up a server?
22:53:37 <xiong> Either way, I think you can just make it a rule, if you please: No disjoint stations allowed.
22:54:18 <xiong> I tend to prefer ingame enforcement of rules. But in this case, it's tough.
22:54:29 <Stimrol_> yes, I was hoping there was a fix for this. Because if you can do something you will do it even it not allowed
22:54:45 <Stimrol_> I just have to have it like this, but thanks anyway :)
22:54:51 <xiong> Dunno. I like to run around with people who don't fight.
22:54:54 <Eddi|zuHause> planetmaker: i'm thinking with going with splitting early austrian engines into two: "Northern" (StEG+kkStB) and "southern" (SB)
22:56:35 <xiong> I'd go along with Rhamphoryncus, Stimrol_; set max station spread to 8. Do you really care if stations are disjoint? 8 tiles is roughly catchment area; so it's "walkable".
22:57:36 <xiong> Or, equally realistically, the distance a crew can be expected to haul cargo with industry-owned vehicles.
22:57:41 <Rhamphoryncus> Need smaller catchment areas, hehe
22:57:50 <Rhamphoryncus> Drop it down to, say, 2.
22:58:24 <xiong> Nobody builds a railhead right up to the tree to be felled.
22:59:52 <Rhamphoryncus> You can use truck depots with transfer orders
23:00:03 <xiong> Here's what you can do if you're a real tough guy, Stimrol_: Build antennas completely surrounding your industries, right out to the rail catchment limit. Leave one-tile corridors for truck feeders.
23:00:37 <xiong> For extra brutality, leave fewer corridors than you have players. ;)
23:00:47 <Stimrol_> no I am playing to, this is for everybody
23:01:08 <Rhamphoryncus> Play with hills on those antennas, so they can't walk a truck depot through them :)
23:01:28 <Rhamphoryncus> But also consider the large catchment area of airports
23:01:51 <xiong> What are you thinking, Rhamphoryncus? I was thinking solid antennas. Mind you, I hate antennas.
23:02:32 <xiong> Strategic placement of antennas at various heights would exclude airports, too.
23:02:58 <Rhamphoryncus> If you have a path for a road then you have a path for depots
23:03:09 <Rhamphoryncus> hrm. I'm wrong. You can't block them so long as the road is removable :(
23:03:51 <xiong> Well, I thought the idea would be to put a truck stop next to the industry and a single road out.
23:04:45 <xiong> If there are more antennas than station spread, you *must* set up a feeder. No?
23:05:22 <xiong> Erm, antenna_radius > station_spread + catchment.
23:05:53 <xiong> That would be a lot of antennas. :(
23:05:57 <planetmaker> Eddi|zuHause: I'm not a big railway historian. Thus if it makes sense, I've totally no issue with such split
23:06:20 <planetmaker> I'd only consider the game aspect (less the reality). Thus... :-)
23:06:59 <Eddi|zuHause> planetmaker: i'm not a historian either, i'm just browsing wikipedia trying to make some sense of this mass of engine types
23:07:07 *** roboboy has joined #openttd
23:38:47 *** roboboy has joined #openttd
23:54:14 *** tokai|mdlx has joined #openttd
23:58:58 *** ChanServ sets mode: +v tokai
continue to next day ⏵
