IRC logs for #openttd on OFTC at 2012-03-01
⏴ go to previous day
00:33:15 *** kkb110_ has joined #openttd
00:44:15 *** DorpsGek has joined #openttd
00:44:15 *** ChanServ sets mode: +o DorpsGek
00:56:09 *** dotwaffle has joined #openttd
04:43:05 *** cmircea has joined #openttd
05:02:15 *** tokai|mdlx has joined #openttd
05:08:15 *** TWerkhoven[l] has joined #openttd
05:08:19 *** ChanServ sets mode: +v tokai
05:17:55 *** Cybert1nus has joined #openttd
05:27:33 *** tokai|mdlx has joined #openttd
05:40:37 *** kkb110_ has joined #openttd
05:56:23 *** Eddi|zuHause has joined #openttd
06:25:57 *** JVassie has joined #openttd
06:42:54 *** Zeknurn has joined #openttd
07:06:52 *** sla_ro|master has joined #openttd
07:09:10 *** andythenorth has joined #openttd
07:18:42 *** TheMask96 has joined #openttd
07:44:46 *** Twofish has joined #openttd
07:56:03 *** TWerkhoven has joined #openttd
08:19:00 * andythenorth ponders duck-typing
08:21:20 <NGC3982> andythenorth: duck-typing?
08:22:30 <planetmaker> or: if it quaks, it's a duck. if it moos, it's a cow
08:22:36 *** Cybert1nus is now known as Cybertinus
08:25:12 <andythenorth> or if it says "I am an object that can give you a valid colour, take the result as a colour"
08:25:45 <planetmaker> any reason you chose such dim light as your nick, NGC3982?
08:26:10 <DorpsGek> planetmaker: 244.140625
08:26:57 <planetmaker> (or is there no astronomical reference?)
08:30:13 <NGC3982> planetmaker: number 3982 is a spiral galaxy in ursa major.
08:30:38 <planetmaker> I know. With 12mag
08:30:56 <planetmaker> hence my first question ;-)
08:31:14 <NGC3982> well, i love the conformity of the galaxy. big and round, and a bit like the milky way.
08:31:23 <NGC3982> havent really thought about the visibility of it.
08:31:51 <planetmaker> the images I saw look nice indeed
08:33:11 <andythenorth> I could just check the type of the class (is it PixaColour?), but that would be restrictive
08:33:20 <planetmaker> hm... I guess given usual NGC brightnesses, 12mag is above average :-)
08:33:24 <andythenorth> and not useful for people who wanted to extend the base methods
08:33:43 <NGC3982> planetmaker: although, i feel; most people do tend to forget about the beauty in the more "normal" stuff in the universe.
08:34:04 <NGC3982> sure, the crab nebula is cool, but it lacks a certain ..normality.
08:34:43 <NGC3982> i love these huge, almost perfect structures.
08:36:49 <DorpsGek> planetmaker: 27.0759704357
08:37:53 <NGC3982> planetmaker: that is your own photography?
08:38:19 <planetmaker> yes, it is. 3*30 minutes exposure
08:39:03 <NGC3982> 5194 sure has some great colors from the hubble photos
08:39:37 <planetmaker> 8" Celestron on an SBIG ST-8 with r,g, and b filters respectively
08:40:09 <NGC3982> im about to buy my first telescope.
08:40:16 <NGC3982> havent decided on what, yet.
08:40:20 <NGC3982> i barely have the knowledge on it.
08:40:50 *** Zeknurn has joined #openttd
08:41:36 <bolli> don't buy a refracting telescope... :P
08:42:05 *** BERLIN22M has joined #openttd
08:42:45 <bolli> don't you just love porn spambots....
08:43:39 <blathijs> Hmm, I was about to click that link, expecting to get a funny picture of a cute piglet or something
08:43:46 <blathijs> Good thing I didn't :-)
08:44:05 <NGC3982> well, freud would love a specimen like that
08:44:20 <NGC3982> someone who reads "tight ass babe gets ass licked and analed" and only recognices "babe".
08:46:32 <bolli> right... next stupid compiling question...
08:46:38 <bolli> any idea what 5>LINK : fatal error LNK1104: cannot open file 'libpng.lib' means?
08:47:38 <bolli> its the last error i've got, and it doesn't tell you where its called from...
08:57:21 <planetmaker> bolli, it doesn't find libpng which probably was linked to dynamically
08:58:03 <planetmaker> NGC3982, "which telescope" is a tricky question. It IMHO highly depends on what you want to do. "Buy a reflector" is also not necessarily the correct answer there either...
08:58:38 <planetmaker> if you just start and it'll be your first telescope and you want to watch with your eye... probably a Dobson mount reflector might be the most fun for the buck
08:59:00 <planetmaker> but you won't do photography with that
09:00:46 <planetmaker> but then... I probably wouldn't invest too much money in the first telescope anyway unless you're absolutely sure you want to keep the hobby and that you want to do astro photography
09:01:01 <planetmaker> but then it rather needs 4-digit amounts of money
09:02:39 <bolli_> its been a few years since I did any astro photography...
09:02:58 <bolli_> i'm trying to remember the name of the moving mount that we used
09:03:22 <NGC3982> planetmaker: absolutely.
09:04:06 <NGC3982> planetmaker: i have a decent amount of money tucked away for the soul purpose
09:04:18 <NGC3982> although, i think ill start with something for the eye
09:04:48 <NGC3982> i find more interest then enough in the local solar system
09:05:02 <NGC3982> where i guess a small dobson reflector would do.
09:06:00 <NGC3982> something like <12-13" f/5?
09:07:27 <bolli_> slightly pricy though :/
09:07:44 *** Zeknurn has joined #openttd
09:08:46 <NGC3982> for god sake, what am i doing.
09:09:09 <bolli_> it allows you to take long exposure shots without getting blurring caused by the earths rotation...
09:09:55 <NGC3982> i didnt think an dslr objective of that small size could produce those pictures
09:10:30 *** bolli_ is now known as bolli
09:12:12 <bolli> those pictures were probably taken with a special lens or even a telescope looking at them...
09:12:21 <bolli> then extensively modified
09:14:50 <bolli> i took those years ago...
09:14:58 <bolli> using a remotely operated telescope in hawaii
09:15:11 <planetmaker> with a setup like that and a decent dslr you'll get nice overview images of things like the whole of Orion or so
09:15:22 <planetmaker> or, depending on lens, of course also smaller detail
09:15:28 <planetmaker> but you need very good tracking
09:15:49 <planetmaker> which would be an automated mount
09:17:52 <NGC3982> M104 is the sombrero galaxy, right?
09:18:24 <NGC3982> thing is, automated mount + dslr is very expencive for me as a beginner.
09:20:21 <planetmaker> As such, it probably often is not a good idea wanting to start with photography
09:20:39 <planetmaker> As non-star trail images require an automated mount
09:21:19 *** Zeknurn has joined #openttd
09:21:55 <planetmaker> Anything longer than a few seconds will already give you trails w/o guidance, already for "normal" focal lengths of common DSLR lenses
09:22:09 <planetmaker> *few seconds exposure
09:22:27 <planetmaker> And that effect of course gets worse when you mount the camera to a real telescope
09:43:04 *** sla_ro|master has joined #openttd
09:46:45 <andythenorth> I need a class that when called, returns an object with a value baked in
09:46:50 <andythenorth> like a small factory
09:54:29 *** Zeknurn has joined #openttd
10:00:00 <andythenorth> must be an insane solution?
10:10:37 *** Zeknurn has joined #openttd
10:26:30 *** Firartix has joined #openttd
11:02:16 *** Firartix has joined #openttd
11:37:58 <NGC3982> planetmaker: obsonian telescopes was really, really expencive.
11:38:20 <NGC3982> i think i need to stick to the more usual stuff before i get there.
11:39:00 <NGC3982> planetmaker: how about a neat litle celestron nexstar 6SE?
11:39:02 <planetmaker> sorry, what's expensive?
11:39:29 <planetmaker> Dobson-type telescopes?
11:39:38 <planetmaker> That's not a manufacturer. It's a mount type
11:39:46 <planetmaker> Which gives you the largest apperture for the buck
11:40:40 <NGC3982> i cant seem to find anything below 5-7.000 usd.
11:40:48 <NGC3982> i guess thats me not searching correctly.
11:41:07 <planetmaker> And the Celestron you quote with the auto-guider and the mount certainly is not cheap. A Dobson basically is a telescope w/o a (proper) mount
11:42:57 <planetmaker> what you quote is probably... 2000€ ?
11:43:59 <NGC3982> something like that, yes.
11:44:27 <NGC3982> actually, i cant say i have any idea on what so ever, what kind of prices i should be looking for. if it demands it, ill pay 4000.
11:44:34 <SpComb> wouldn't a nice tele objective be enough for looking across the street?
11:46:50 * NGC3982 scans ebay for porthole glass.
11:46:58 *** andythenorth has joined #openttd
11:49:37 <planetmaker> NGC3982, the main question you really should answer before you buy is: what do you want to do?
11:49:54 <planetmaker> - visual observation or photography?
11:50:05 <andythenorth> planetmaker: wrt FIRS recycling depot - it appears to simply miss the relevant location check(s)
11:50:23 <andythenorth> it slipped out when converted I guess
11:50:23 <planetmaker> - solar system bodies and alike? Or rather deep sky objects (like your nick implies)
11:50:25 <planetmaker> andythenorth, probably
11:51:00 <andythenorth> so a bug, but missing code rather than broken
11:53:10 *** Illegal_Alien has joined #openttd
11:53:14 <Eddi|zuHause> bah fuck... kmail got totally unusable now...
11:53:34 <Eddi|zuHause> i tell it to "delete duplicates"
11:53:44 <Eddi|zuHause> and it does everything, except actually delete the duplicates...
11:53:52 <SpComb> deletes everything else?
11:53:54 *** orudge` has joined #openttd
11:53:55 *** ChanServ sets mode: +o orudge`
11:54:52 <planetmaker> NGC3982, the Dobson telescopes might seem more expensive. But their average aperture also usually is quite a lot bigger. Thus much more fun for visual deep sky tours
12:02:10 *** cmircea has joined #openttd
12:02:21 *** tokai|noir has joined #openttd
12:02:21 *** ChanServ sets mode: +v tokai|noir
12:04:54 *** lofejndif has joined #openttd
12:05:08 <Eddi|zuHause> <andythenorth> and not useful for people who wanted to extend the base methods <-- there is "isinstance", which should properly handle derived classes
12:05:29 <planetmaker> NGC3982, seems that the NexStar series indeed is good value meanwhile. Computerisation of the mounts made the expensive mounts kinda obsolete...
12:05:42 <Eddi|zuHause> i haven't seen any sane functions to check interface-conformity for proper duck typing
12:06:14 <Eddi|zuHause> so it'll fail somewhere deep inside the code instead of at a simple "assert hasinterface(blah)"
12:06:33 <andythenorth> Eddi|zuHause: I found an article where Guido is quoted as saying "know your codebase" wrt interfaces & duckytpin
12:06:53 <Eddi|zuHause> now that sounds like a useless argument :)
12:07:05 <andythenorth> also - "use tests" ;)
12:09:04 *** ChanServ sets mode: +v tokai
12:16:21 *** tokai|mdlx has joined #openttd
12:17:51 <Ammler> does debian build debug packages for openttd?
12:27:38 <Ammler> it seems like --enable-debug is not useable for packages, how shall I enable debug but not change the final binary?
12:30:44 <Eddi|zuHause> andythenorth: i don't understand a word of that
12:31:40 <andythenorth> thanks anyway ;)
12:32:01 *** TGYoshi has joined #openttd
12:36:42 *** theholyduck has joined #openttd
12:36:45 <andythenorth> I know try: except: is a valid python pattern, but it makes me itch
12:37:09 <andythenorth> usually it's easy to kick holes in what "except" is doing
12:37:35 <andythenorth> maybe python has something like hasttr()
12:42:31 <Ammler> looks like debug binary is built per default, maybe via CFLAGS?
13:16:33 *** Rhamphoryncus has joined #openttd
13:16:45 <Rhamphoryncus> Heya andythenorth
13:17:36 <Rhamphoryncus> The nml clicked an hour after you left. I understand it
13:18:05 <Rhamphoryncus> But I also figured out a problem in your pseudocode
13:18:48 <Rhamphoryncus> The amount of supplies consumed is constant at a given production level, so as long as you exceed it by 1 you'll eventually hit saturation of the 3x chance
13:19:05 <Rhamphoryncus> Exceeding it by 50% would accomplish that in 6 months
13:21:09 <Rhamphoryncus> Two parts. First is to average the supplies out over 3 months. Implemented by having supply_store in 3 variables: first (current month) you consume a third of it, second (previous month) you consume half of it, and third (month before that) you consume all that's left. Then you rotate them, making new for the new month.
13:22:04 <andythenorth> how do you retrospectively consume?
13:22:09 <andythenorth> suggests time travel... :)
13:22:24 <Rhamphoryncus> Those are just stockpiles of what's left
13:23:17 <Rhamphoryncus> So you have a budget for tuesday, wednesday, and thursday. Each started at a 3 dollars and you consume 1 dollar from each each day
13:24:00 <Rhamphoryncus> So just before you consume it'll look like 1, 2, 3. After it'll be 0, 1, 2. Then you rotate for the new month: 1, 2, 0
13:26:00 <planetmaker> Rhamphoryncus, it's not like my patch series doesn't use that concept already...
13:26:18 <Rhamphoryncus> planetmaker: does it? I'm going off his proposal mostly
13:26:47 <planetmaker> the idea there is to take a configurable time and use that as basis...
13:27:15 <planetmaker> or so was the idea when I started it
13:28:03 <planetmaker> you also need to mind that you only have so many persistant storage registers
13:28:31 <Rhamphoryncus> yeah, but I think 3 is acceptable
13:29:30 <andythenorth> I recall that we discussed whatever is in the patch queue at the time, and it made sense
13:30:08 <Rhamphoryncus> So what's not done in the patches?
13:30:11 <planetmaker> it's not a question of 'acceptable' but of 'still available'?
13:30:21 <planetmaker> Rhamphoryncus, removing the bugs in it
13:30:25 <planetmaker> and proper testing
13:30:43 <Rhamphoryncus> like the bit shifting :)
13:36:26 <andythenorth> I'm always surprised by that
13:40:12 <andythenorth> there's no sane way to assign an attr to a method is there?
13:40:39 <andythenorth> e.g. I have "def colour(self, colourset=None)
13:41:00 <Rhamphoryncus> ( production_level / 16 * ((production_level + 128) / 32 - (4 - LOAD_PERM(var_supply_efficiency_factor)))) is equivalent to (production_level / 16 * (production_level + / 32 + LOAD_PERM(var_supply_efficiency_factor)))
13:41:16 <andythenorth> and I want to provide an easy interface for authors, who might prefer to call self.colour
13:41:28 <andythenorth> self.colour = self.colour() fails
13:41:29 <Rhamphoryncus> But I'm also guessing the /16 should be done last, to minimize rounding
13:41:35 <andythenorth> this might be a stupid dumb idea anyway
13:41:47 <andythenorth> methods are methods, and should look like methods
13:42:07 <Rhamphoryncus> You want to create a function and make it a method on that specific object?
13:42:36 <andythenorth> I want to assign it to an attr :P
13:42:46 <andythenorth> I can think of at least two reasons this shouldn't work
13:42:53 <Rhamphoryncus> "foo = foo" doesn't make sense :)
13:43:15 <andythenorth> foo = foo() is somewhat problematic too
13:43:25 <andythenorth> object = call object :P
13:43:31 <Rhamphoryncus> You'd need a different name
13:43:44 <Rhamphoryncus> but self.myfunc = self.colour works fine
13:43:54 <andythenorth> nah, it's a problem I should stop solving, it's just a bad idea
13:43:57 <Rhamphoryncus> It creates a bound method object when you look it up
13:44:30 <andythenorth> in the case above - what happens if I call self.myfunc(args) ?
13:44:35 <andythenorth> do the args get passed?
13:45:27 <andythenorth> is it good that authors can use attr access when they don't need args?
13:45:41 <Rhamphoryncus> Methods in python are attributes. Internally, if you do self.colour(args) it does "func = self.colour; func(args)"
13:45:41 <andythenorth> and only write a method call when args are present?
13:45:59 <Rhamphoryncus> wait, I don't think I'm understanding you
13:46:14 <Rhamphoryncus> You want the method to behave as a different kind of object when not called?
13:46:49 <andythenorth> I want to enable the following
13:46:55 <andythenorth> foo.colour = result
13:47:02 <andythenorth> foo.colour(args) = similar result
13:47:09 <andythenorth> but I think it's a dumb idea tbh
13:47:18 <andythenorth> and totally unnecessary
13:47:41 <Rhamphoryncus> Ahh. Assignment is technically possible, but not retrieval (it's already used to get the bound method). And yeah, bad idea :)
13:48:07 <andythenorth> I'm filing it under 'stupid'
13:48:53 <Rhamphoryncus> But a property would be okay. let you do "foo.colour = 3" or "foo.colour = (3, 15, 12, hut)" or "foo.colour = 'red'" and have that call a function
13:50:14 <Rhamphoryncus> That function can sanity check it and convert to a standard form
13:54:21 <andythenorth> this is when reading
13:54:29 <andythenorth> and compactness is a virtue
13:54:49 <andythenorth> result = foo.colour() will do fine ;)
13:56:20 * andythenorth ponders "what is love"
13:56:30 <andythenorth> Haddaway seems to have done that too
13:56:31 <Rhamphoryncus> Looks like the patchset has the same issue of constant consumption.
13:57:25 <andythenorth> so the issue is that it's trivial to max out the chance of an increase?
13:57:33 <andythenorth> by delivering > amount per month?
13:57:48 <andythenorth> MNIM seems to be the case
13:57:58 <andythenorth> Rhamphoryncus: and that's an issue because....?
13:58:30 <Rhamphoryncus> You might as well just have a flat chance
14:00:11 <andythenorth> ...or remove the supplies concept
14:00:26 <Rhamphoryncus> I never got to the second part of my proposal ;)
14:00:27 <planetmaker> the point of my production patches is that the required amount of delivered supplies changes with output
14:00:59 <planetmaker> thus raising the production level requires increasing supply supply.
14:01:31 <planetmaker> the point is not to make a variable increase chance
14:01:50 <Rhamphoryncus> hrm. I think I'm confusing it with andy's proposal again x_x
14:03:17 <andythenorth> if you have enough supplies on the map, you'll always be able to flood an industry with enough to get the max
14:03:21 <andythenorth> there's no way out of that
14:03:35 <planetmaker> except limiting supply production ;-)
14:04:17 *** Biolunar has joined #openttd
14:04:24 <Rhamphoryncus> My proposal used decreasing returns. If the target is 10 and that gets you a 1x chance then you'd need 90 supplies to get a 3x chance
14:05:32 <andythenorth> I had the idea of efficiency somewhere
14:05:38 <andythenorth> possibly even on a per industry basis
14:06:11 <Rhamphoryncus> The target scales proportional to output, but so does the primaries that feed your supply chain, so they stay together
14:07:02 <andythenorth> I can't remember all the details of current proposal right now (and haven't read the patches)....but
14:07:18 <planetmaker> Rhamphoryncus, and where's the difference when my proposal is like you need 1 supply / month to have a chance to increase from output lv1 to lv2 while you need n**2 supplies to increase from output lv. n to lv (n+1)?
14:07:18 <andythenorth> this was the only proposal we found that wasn't worse than just leaving it alone at >1 / month
14:07:34 <andythenorth> many proposals have been made, but they're all flawed somehow
14:07:48 <planetmaker> though I probably tried to implement something which is not exactly quadratic and toyed with something like a look-up table
14:08:39 <Rhamphoryncus> planetmaker: ahh, I was only looking at the current increase, not what the target is
14:08:44 <planetmaker> and if you stop supplying half the required amount of supplies, you start dropping the prod. lv.
14:09:07 <planetmaker> production lv. is not only about increasing...
14:09:08 <Rhamphoryncus> If it grows quadratically then eventually consumption will exceed demand
14:09:10 <andythenorth> some of the suggestions failed because they contained 'A Xor B but also A && B'. A might be 'have cake' and B might be 'eat cake' :P
14:09:13 <planetmaker> it's a bit more complex :-)
14:09:52 <Rhamphoryncus> Quadratic growth also encourages spreading around
14:09:55 <Eddi|zuHause> man it always amazes me that the dutch set thread is so extremely fast-moving... i don't look for a day, and it has like 5 new pages
14:10:06 <Rhamphoryncus> So umm.. I like it :)
14:10:16 <Eddi|zuHause> that's more than the total rest of the forum togehter :p
14:10:31 <andythenorth> they're nice graphics
14:10:37 <andythenorth> and FooBar gets stuff done
14:10:45 <Rhamphoryncus> I'm guessing you can't hit 2k production with it, which is a large change from standard play
14:10:48 <andythenorth> you won't see him pondering here much :P
14:11:03 <MNIM> It seems to me that there's also quite a contingent of dutch OTTD fans out there.
14:11:06 <Eddi|zuHause> <planetmaker> and if you stop supplying half the required amount of supplies, you start dropping the prod. lv. <-- i hate that part about ECS... you miss one delivery, and the whole economy collapses
14:12:18 <planetmaker> I'm well aware of that. And be ensured that exactly that is what I'll try to avoid, Eddi|zuHause
14:12:44 <planetmaker> thus a sufficient long hysteresis is needed
14:12:59 <planetmaker> or a time constant that one can miss X months or so
14:13:03 <andythenorth> hence the internal stockpiles iirc
14:13:09 <andythenorth> not 'stockpiles' in the PBI sense
14:13:32 <planetmaker> memory of past delivery might be better :-)
14:13:38 <andythenorth> 'stockpiling' is a nice idea, but is silly really
14:13:51 <andythenorth> i.e. gradual processing
14:13:57 <andythenorth> it's a faceted special case that could be done with registers and text stack
14:14:04 <Rhamphoryncus> Alright, I think I'm back on the correct track :)
14:14:31 <Eddi|zuHause> andythenorth: i guess it's one of those "grown" things that are kept for hysterical raisins
14:15:48 <andythenorth> grf v9! "the removal edition"
14:16:28 <Eddi|zuHause> i don't think you'll get a strong enough momentum for that :p
14:18:52 * andythenorth reads the actual 'rework supplies' ticket
14:19:50 <andythenorth> Rhamphoryncus: ok, so yup, if target for a 3x increase chance is n, and player drops off > n, that's fine
14:20:05 <andythenorth> they met the goal, they get the increase chance
14:20:18 <Rhamphoryncus> andythenorth: so a flat chance, alright
14:20:21 <andythenorth> the value of n is a bunfight remaining to be had
14:20:42 <Rhamphoryncus> I'll give you a chart :)
14:20:53 <andythenorth> I personally don't find it interesting to have huge trains of supplies going to every industry ;)
14:21:03 <Rhamphoryncus> Give me a minute to relabel and such
14:21:25 <planetmaker> andythenorth, a NewGRF version which only removes stuff is not worth it. As it will a) complicate OpenTTD code, will b) compilcate grf specs and c) what will be gained?
14:22:02 <planetmaker> that's the apple way: break backward compatibility regularily
14:22:20 <planetmaker> I think developers don't appreciate that really
14:22:28 <andythenorth> the internet doesn't know about 'tidy mind fallacy'
14:22:37 <andythenorth> perhaps I invented it, but I thought it was in the C2 wiki or such
14:23:07 <andythenorth> expending effort on tidying things up that are of no consequence
14:23:27 <andythenorth> like folding your recycled paper neatly
14:25:07 <andythenorth> planetmaker: it irritates me that we have to have 'cargo waiting to be processed' text in FIRS windows when they are of very limited value
14:25:17 <andythenorth> (because that string is tied to use of production cb)
14:25:36 <andythenorth> It would be useful to have a cb that made industry window a blank slate
14:27:22 <andythenorth> you know how the production multiplier changes?
14:28:25 <Rhamphoryncus> production_level? It's a number of supplies produced 8 or 9 (or 10) times a month. Unless it's different in FIRS :)
14:30:26 <andythenorth> Rhamphoryncus: there's an internal multipler, iirc the range is (1..16)
14:30:38 <Rhamphoryncus> internal to FIRS?
14:30:44 <andythenorth> internal to industries
14:30:50 <andythenorth> used for primaries mostly
14:30:56 <andythenorth> it's documented, just a minute...
14:30:59 <Rhamphoryncus> but in firs? Not standard?
14:31:38 <Rhamphoryncus> "Current production level of the industry. Usually in range 4 .. 128, default starting level is 16. A level of 0 indicates imminent closure." for production_level
14:32:22 <Rhamphoryncus> 250*8=2000, thus the ~2k cap
14:33:54 <andythenorth> the cap actually varies according to value of props 12, 13
14:35:23 <andythenorth> so how/why is your curve smooth, whereas pm's patch is stepped (in what looks to me like 16 steps corresponding to multiplier increases)?
14:37:17 <Rhamphoryncus> hrm. so props 12,13 are production_level?
14:37:30 <Rhamphoryncus> I rearranged the math to avoid division until the end
14:37:34 <andythenorth> they're the input multipliers to the production multiplier
14:37:47 <andythenorth> production multiplier * prop 12,13
14:38:03 <andythenorth> is amount of cargo produced 8 or 9 times per month
14:38:24 <Rhamphoryncus> And 12,13 is treated as a 16-bit value?
14:39:44 <Rhamphoryncus> So the real cap would be 9*255*65535 = 150402825?
14:40:42 <Belugas> bonjour andythenorth, comment vas tu?
14:41:31 <andythenorth> still writing a pixel generator....
14:42:02 <andythenorth> but think of the time saved!
14:46:11 <andythenorth> Rhamphoryncus: "The production rate is a value between 04h and 80h (initial value 10h)"
14:46:25 <DorpsGek> andythenorth: 293760
14:47:12 <andythenorth> but I'm not sure that's quite how it works anyway
14:47:19 <andythenorth> "The properties specify the amount produced at default production level"
14:47:35 <andythenorth> and also "Multiply operations that would bring the production above 8 times of the original will only increase it to that value."
14:48:10 <andythenorth> in this case I've always found the spec precise, but hard to understand
14:48:20 <andythenorth> reading the code gives a better answer :P
14:48:39 <andythenorth> industry_cmd.cpp will know what *actually* happens
14:48:48 <andythenorth> and that varies from spec occasionally anyway
14:49:23 <Rhamphoryncus> I'll take a look
14:49:28 <planetmaker> Rhamphoryncus, you may also not overflow...
14:49:40 <Rhamphoryncus> yeah, that'd be bad :)
14:49:52 <Rhamphoryncus> for calculations?
14:50:02 <andythenorth> as that's been bugging me for ages
14:50:14 <andythenorth> all industries of type x have same production at game start
14:50:21 <andythenorth> which destroys a lot of the early gameplay
14:50:32 <andythenorth> it's very bland :(
14:51:38 <Rhamphoryncus> That can be my next thing to work on :)
14:54:01 <andythenorth> it should be decoupled from supplies mechanism, if I've understood automatic production multiplier correctly
14:54:09 <andythenorth> but...I'm not sure
14:54:38 <andythenorth> it may be that register values for supply logic need initialising accordingly wrt randomised production
14:56:30 <Rhamphoryncus> Oh.. duh. 12,13 is for two different types
14:56:37 <Rhamphoryncus> i->produced_cargo_waiting[0] = min(0xffff, i->produced_cargo_waiting[0] + i->production_rate[0]);
14:56:37 <Rhamphoryncus> i->produced_cargo_waiting[1] = min(0xffff, i->produced_cargo_waiting[1] + i->production_rate[1]);
14:57:06 <andythenorth> there are two output cargos
14:57:24 <Rhamphoryncus> All I'm seeing there is a single value range 0.255
14:57:51 <Rhamphoryncus> Aha, found something setting that
14:58:30 <_maddy> anyone up for a multiplayer game??
14:58:52 <Rhamphoryncus> this->production_rate[0] = min(CeilDiv(indspec->production_rate[0] * this->prod_level, PRODLEVEL_DEFAULT), 0xFF);
14:58:52 <Rhamphoryncus> this->production_rate[1] = min(CeilDiv(indspec->production_rate[1] * this->prod_level, PRODLEVEL_DEFAULT), 0xFF);
14:59:48 <Rhamphoryncus> that's for old, non-smooth economies
15:01:14 <andythenorth> the economy in FIRS is ignored
15:01:43 <andythenorth> because we handle the callbacks explicitly
15:01:55 <andythenorth> although there may be some parameter settings where the economy is respected
15:02:53 <andythenorth> it confuses me that we have production_rate and prod_level, but neither is labelled production_multiplier :)
15:03:15 <planetmaker> industries w/ production callback ignore economy
15:04:15 <andythenorth> this is wrt cb29 and 35, where returning 04h will respect the economy settings
15:04:49 <andythenorth> let's read some actual code though...
15:05:45 <andythenorth> ok so the FIRS primaries use production cb, but for consumption not production
15:06:04 <andythenorth> so my memory hasn't failed yet :P
15:06:12 <andythenorth> well, at least not for that case
15:06:40 <Rhamphoryncus> ah, smooth economy is disabled for industries with a callback. That explains some of it
15:07:17 *** Markavian has joined #openttd
15:08:19 <andythenorth> the FIRS primaries also never seem to return 04h so that's also a non-issue
15:08:35 <andythenorth> so economy is simply a non-issue for FIRS primaries, my conclusion
15:09:04 <Rhamphoryncus> PRODLEVEL_DEFAULT is 0x10 ie 16, so if your prod_level is 10 then production_rate = old_production_rate * 10 / 16
15:09:36 <andythenorth> yes that sounds right
15:09:54 <planetmaker> you have a produce callback where you can make use of it explicitly...
15:10:36 <andythenorth> why didn't we implement that for randomisation? there was at least one reason...
15:10:58 <andythenorth> maybe we don't have any method to randomise production multiplier on construction
15:11:26 <Rhamphoryncus> prod_level ends up being squared. 64 hits the cap
15:12:19 <andythenorth> common.DEFAULT_CC1_INDEX or just common.CC1 ? :P
15:12:35 <andythenorth> explicit versus verbose :|
15:12:42 <Rhamphoryncus> And once you had it at 64 for a few months and you've hit the cap you can drop it to 16 and still maintain the cap
15:13:37 <Rhamphoryncus> It does sound odd
15:14:30 <andythenorth> I'd look at the handlers for cb29 and 35, I would hope that prod_level is not increased once the cap is reached
15:15:32 <andythenorth> I'm not convinced that writing "common.colours['CC1']" everywhere is actually better than writing "202" and using find/replace
15:16:44 <Rhamphoryncus> Where are the cb numbers defined? I'm only finding names
15:16:52 <andythenorth> I'd have to read the code...
15:17:07 <andythenorth> there is header file somewhere else that would tell you
15:17:14 <andythenorth> but I should read this code again anyway
15:17:22 <Rhamphoryncus> monthly_prod_change and random_prod_change?
15:17:43 <Rhamphoryncus> or CBID_INDUSTRY_MONTHLYPROD_CHANGE and CBID_INDUSTRY_PRODUCTION_CHANGE
15:18:58 <andythenorth> even if prod cb. is enabled, returning 04h *does* respect economy
15:19:00 <planetmaker> using NML you should not need the numbers...
15:19:19 <andythenorth> Rhamphoryncus: yes those
15:19:19 <planetmaker> the names should speak for themselves. Usually. Otherwise you'll have to dig in the NML source
15:19:33 <Rhamphoryncus> The squaring sounds odd but may be right: you may go from 64/month to 80/month, a difference of 16, but later on going from 2000/month to 2200/month is a difference of 200. That's due to squaring
15:19:35 <andythenorth> industry_cmd.cpp
15:19:41 <Rhamphoryncus> planetmaker: I need numbers to understand andy ;)
15:19:52 <planetmaker> yes... he talks numbers only...
15:20:01 <andythenorth> didn't have the code open
15:20:07 <planetmaker> always find it confusing when talking nml callbacks
15:20:33 <planetmaker> it usually doesn't help my understanding either ;-)
15:20:36 <andythenorth> I'll adapt at some point
15:20:42 <andythenorth> the more NML I write...
15:21:09 <Rhamphoryncus> So if you use a return that tells it to increment or decrement by 1 it alters prod_level, which then feeds into production_rate to smooth out the effect
15:21:11 <andythenorth> although I'd need frosch and co to also then use NML references, not numbers :|
15:21:20 <andythenorth> Rhamphoryncus: yes
15:21:42 <Rhamphoryncus> But if we wanted we could set production_rate directly and ignore prod_level. That'd let us use our own smoothing
15:21:56 <planetmaker> I usually guess from context what the number is supposed to mean
15:22:01 <andythenorth> it was convenient to rely on the game's built in handling
15:22:08 <andythenorth> but we can use the produce() cb
15:22:53 <andythenorth> whereever possible, I tried to use game's mechanics rather than roll my own
15:22:58 <andythenorth> not always possible
15:23:10 <planetmaker> Rhamphoryncus, if possible, it's a good idea to rely on the game...
15:23:31 <planetmaker> it's less confusing then for users as the game switches then actually remain meaningful
15:23:36 <Rhamphoryncus> What's bothering me is that prod_level is another saturation function. 16/16 is stay level, 17/16 is increase, 15/16 is decrease
15:24:24 <andythenorth> explain that another way :)
15:24:35 <Rhamphoryncus> Once you get it over 16, given enough months it should eventually give you a production_rate of 255
15:25:07 <andythenorth> that's not the case though
15:25:36 <andythenorth> work it through with numbers
15:25:48 <andythenorth> let's use dec for ease
15:25:49 <andythenorth> assume prop 12 is 08d
15:26:03 <andythenorth> and prod_level is 16 (default)
15:26:37 <andythenorth> @calc 8*((16*8)/16)
15:27:20 <Rhamphoryncus> what's production_rate now?
15:27:32 <andythenorth> I'm not sure about the /16 tbh
15:27:45 <Rhamphoryncus> Oh, I just realized: the compounding only ticks when you increment or decrement production
15:28:18 <Rhamphoryncus> So you have to bounce between 17 and 18, not just stay at 17
15:28:46 <andythenorth> in default game, you only increment when the random production cb swings by and marks your industry instance for a production change
15:29:13 <Rhamphoryncus> That explains why we don't see the squaring normally
15:29:15 <andythenorth> in FIRS we use the monthly cb for more frequent smaller changes
15:30:54 <andythenorth> maybe that's actually less fun :o :P
15:31:05 <andythenorth> maybe 600t -> 1200t is a fun change to deal with
15:31:20 <andythenorth> but on big maps...not
15:31:20 <Rhamphoryncus> Maybe as a temporary burst :)
15:31:44 <Rhamphoryncus> "XXX has had record production! Production doubled for 3 months!"
15:32:25 <andythenorth> Rhamphoryncus: l2162 - is part of the confusion here that 'production_rate' has two meanings?
15:32:31 <andythenorth> I don't read C++ brilliantly
15:32:44 <Rhamphoryncus> There's prod_level and production_rate
15:32:52 <andythenorth> but it looks like to me it's the name of a prop, and the name of a var multiplied by prod_level
15:32:59 <andythenorth> which if so, is fricking confusing
15:33:11 <Rhamphoryncus> I believe 12,13 are production_rate
15:33:20 <andythenorth> but production_rate is also amount produced
15:33:27 <andythenorth> I write that kind of code too :P
15:33:38 <andythenorth> foo = transform(foo)
15:34:00 <Rhamphoryncus> case 0x12: // Production multipliers
15:34:00 <Rhamphoryncus> indsp->production_rate[prop - 0x12] = buf->ReadByte();
15:34:17 <Rhamphoryncus> There isn't multiple meanings to production_rate
15:34:33 <Rhamphoryncus> You can set it directly OR go through prod_level.
15:34:45 <andythenorth> this->production_rate[0] = min(CeilDiv(indspec->production_rate[0] * this->prod_level, PRODLEVEL_DEFAULT), 0xFF);
15:34:52 <Rhamphoryncus> Is going through prod_level
15:35:10 <Rhamphoryncus> that's only called if you use a return that changes prod_level
15:37:01 <andythenorth> still baffles me
15:37:01 <Rhamphoryncus> So here's the issue: if we use supplies to change prod_level then eventually you won't need the supplies anymore
15:37:19 <andythenorth> that's by design
15:37:32 <andythenorth> check out FIRS parameters ;)
15:38:15 <andythenorth> "eventually you won't need the supplies anymore" iff "production levels never fall"
15:38:36 <andythenorth> If you allow primary production decrease, you need supplies to maintain current level
15:38:57 <andythenorth> otherwise, once maxed, then no supplies needed
15:39:09 <Rhamphoryncus> Even if you allow falling you won't need to maintain it
15:39:24 <andythenorth> does the code say that? :)
15:39:48 <Rhamphoryncus> Once you have production_rate capped at 255 then you only need a prod_level of 16 to maintain it
15:40:18 <andythenorth> if so that's a bug
15:40:54 <Rhamphoryncus> That's the design of that function. 255 * 16 / 16 == 255
15:41:16 <andythenorth> but to get to 255, what's your production level?
15:41:21 <andythenorth> prod_level =...?
15:41:56 <Rhamphoryncus> You need a combination of prod_level AND updates to prod_level
15:42:07 *** Cybertinus has joined #openttd
15:42:20 <Rhamphoryncus> Give me a couple minutes and I'll figure out how many months of continuous increases will do it
15:42:39 <andythenorth> assume you need prod_level n to get to 255
15:42:50 <andythenorth> how would you get from n back to 16 without calling recalculate_multipliers or such?
15:43:41 <Rhamphoryncus> prod_level isn't production level. It's production CHANGE level
15:43:52 <andythenorth> it's the production multiplier
15:44:08 <Rhamphoryncus> So you only need a multiplier >= 1.0
15:44:11 <andythenorth> the terms are somewhat opaque btw
15:44:21 <andythenorth> work it through with maths
15:44:33 <Rhamphoryncus> But I keep being distracted by typing
15:44:39 <andythenorth> I am 99% certain that you're wrong, but I have room for doubts ;)
15:44:56 <andythenorth> due to finding big bugs here before
15:45:11 <andythenorth> which also took some convincing of others :P
15:46:53 <Rhamphoryncus> Okay, on the 12th increase, which puts you to prod_level 28, you'll hit production_rate of 358, which'll cap down to 255
15:47:01 <Rhamphoryncus> faster than I was expecting >.>
15:47:29 <Rhamphoryncus> oops, that's the 11th :)
15:48:04 <Rhamphoryncus> Just doesn't seem right
15:48:32 <Rhamphoryncus> All the other documentation I've seen implied a direct effect, not this indirect one
15:49:20 * Rhamphoryncus fires up openttd
15:57:00 <Rhamphoryncus> Hah, I'm using smooth economy which of course bypasses this
15:57:18 <Rhamphoryncus> That might be the issue: you're expecting this to behave like smooth economy, but it's totally separate
16:02:18 <andythenorth> Rhamphoryncus: gtg, back in an hour or so
16:02:35 <andythenorth> look for recalculate_multipliers in the cb handling
16:02:45 <andythenorth> I think it's called when changing the prod level
16:09:45 <Rhamphoryncus> .. fuck. Well, we both failed to read the code
16:09:50 <Rhamphoryncus> this->production_rate[0] = min(CeilDiv(indspec->production_rate[0] * this->prod_level, PRODLEVEL_DEFAULT), 0xFF);
16:10:08 <Rhamphoryncus> That's *indspec* production_rate. NOT the last production_rate here.
16:13:52 <Rhamphoryncus> So.. there are two production_rate's after all :)
16:14:09 <Rhamphoryncus> Both the industry spec and this specific instance of that industry
16:35:18 <__ln__> how does the german 'Sie' work in plural, or does it?
16:41:46 *** Cybertinus has joined #openttd
16:44:46 <Nat_aS> I just had an idiot on the internet tell me video game prices in the US are at an all time low
16:44:58 <Nat_aS> compared to Australia maybe
16:45:36 *** Guest4682 has joined #openttd
16:45:52 *** Guest4682 is now known as macee
16:45:52 <planetmaker> __ln__, it works. After all, it is already plural
16:46:28 <planetmaker> You use it the same way basically as singular
16:50:19 <planetmaker> __ln__, "ach so" usually is only used when the answer is contrary to the previous believe or statement.
16:50:58 <planetmaker> s/believe/assumption/
16:51:03 <__ln__> hmmm, i'll try to remember that. dnk.
16:51:43 <__ln__> so with 'Sie' it is ambiguous (without context) whether someone is speaking to many people or just one person?
16:52:18 <planetmaker> if it's doubtful, you use "Sie, Herr/Frau XY" or "Sie alle"
16:54:05 *** Devroush has joined #openttd
16:54:15 <planetmaker> the latter "Sie alle" is usually used in spoken language only, though
16:58:26 *** valhallasw has joined #openttd
17:01:48 *** tokai|noir has joined #openttd
17:01:49 *** ChanServ sets mode: +v tokai|noir
17:27:46 *** Keyboard_Warrior has joined #openttd
17:30:58 *** andythenorth has joined #openttd
17:33:42 *** HerzogDeXtEr has joined #openttd
17:50:00 *** |Jeroen| has joined #openttd
17:55:30 *** Progman has joined #openttd
18:01:23 *** frosch123 has joined #openttd
18:24:30 *** sla_ro|master has joined #openttd
18:26:12 *** Vic|UNNT has joined #openttd
18:27:30 <Vic|UNNT> im trying to un my own server, ive did a port forvarding but it still dont shows in server list... that is the reason?:(
18:28:30 <planetmaker> aha. what port forwarding did you do where?
18:28:49 <andythenorth> Rhamphoryncus: did you figure out production?
18:29:09 <planetmaker> and on your computer?
18:29:10 <Rhamphoryncus> andythenorth: yup. We were both misreading the line we pasted several times
18:29:14 <Vic|UNNT> 3978,3979 to 192.168.1.113 my IP on it
18:29:20 <Rhamphoryncus> this->production_rate[0] = min(CeilDiv(indspec->production_rate[0] * this->prod_level, PRODLEVEL_DEFAULT), 0xFF);
18:29:29 <Rhamphoryncus> that's *indspec*->production_rate
18:29:30 <Vic|UNNT> no firewall on my comp
18:29:32 <planetmaker> and both, UDP and TCP protocols?
18:29:49 <planetmaker> 192.168.x.y are private IP addresses
18:30:00 <andythenorth> Rhamphoryncus: I was reading it that way
18:30:03 <planetmaker> they are never communicated to the outside world
18:30:05 <andythenorth> it gets the value of prop 12 in that case
18:30:09 <andythenorth> I'm just bad at explaining :P
18:30:22 <Rhamphoryncus> .. that'd explain why you didn't understand me :)
18:30:27 * Vic|UNNT slaps planetmaker around a bit with a large trout
18:30:34 <Vic|UNNT> it connect by router:)
18:31:03 * planetmaker grabs the trout. And makes filled trout in salt crust
18:31:09 <Rhamphoryncus> Oi, I didn't realize prop 12/13 was on the indspec too
18:31:55 <andythenorth> that's why I think production_rate is a misleading identifier
18:32:36 <andythenorth> I can see why it's used in two different ways, but it's easily conflated (especially when searching source)]
18:32:42 <planetmaker> Vic|UNNT, also make sure you set your server to advertise and to play an internat (not LAN) game
18:33:36 <Rhamphoryncus> it should be indspec->base_production_rate
18:33:47 <andythenorth> yeah, that's not as leet though
18:34:01 <Rhamphoryncus> But I wouldn't have wasted an hour of your time
18:34:42 <andythenorth> it's useful to read the code again
18:34:54 <andythenorth> and you just reviewed openttd and found no bugs?
18:34:57 * Vic|UNNT slaps planetmaker around a bit with a large trout
18:35:28 * andythenorth is tempted to rename those vars in industry_cmd.cpp
18:35:45 <andythenorth> that would be my third patch if accepted
18:35:53 <Vic|UNNT> ive just understand... i connected to internet via router, and it connected via another router...:(
18:35:56 <Rhamphoryncus> Sounds like a good idea
18:36:13 <planetmaker> then, if you set both ports for forward both UDP and TCP to your server, enabled internet game and advertising, it shall work
18:36:13 <Vic|UNNT> and i havent access to another router settings..
18:36:29 <planetmaker> unless you didn't do that completely or your computer does have a FW
18:36:43 <planetmaker> server.openttd.org is your friend to check
18:37:06 <planetmaker> and if advertising fails, you usually get a message
18:37:11 <Rhamphoryncus> So all I'm doing with this patchset is testing it, fixing any bugs I find, and perhaps smoothing the math as in my chart?
18:40:27 <Rhamphoryncus> btw, I came up with a decent way to regulate delivery to a station as a player. Have a vehicle there doing nothing but full load & unload, then have your train go to the near side, transfer, then to the far side and load back up
18:40:46 <Rhamphoryncus> The waiting vehicle will immediately skim some off, the train will get the rest
18:42:45 <Vic|UNNT> at this point i have to have white IP for internet connectrion...
18:43:13 <Rhamphoryncus> Want more to that station? Build a second vehicle with its own bay. You can even lock the vehicle in (remove roads out), assuming breakdowns are disabled.
18:45:34 <CIA-1> OpenTTD: translators * r24000 /trunk/src/lang/ (5 files):
18:45:34 <CIA-1> OpenTTD: -Update from WebTranslator v3.0:
18:45:34 <CIA-1> OpenTTD: french - 13 changes by OliTTD
18:45:34 <CIA-1> OpenTTD: latvian - 5 changes by Parastais
18:45:34 <CIA-1> OpenTTD: romanian - 1 changes by kkmic
18:45:35 <CIA-1> OpenTTD: serbian - 4 changes by etran
18:45:35 <CIA-1> OpenTTD: vietnamese - 1 changes by nglekhoi
18:46:42 <Rhamphoryncus> I kind of wish that was builtin to FIRS, but it should really be in openttd itself as a partial-unload order
18:49:00 *** Alberth has joined #openttd
18:49:00 *** ChanServ sets mode: +o Alberth
19:08:46 *** Cybert1nus has joined #openttd
19:09:18 *** TheMask96 has joined #openttd
19:14:26 <andythenorth> I invented...more
19:14:37 <andythenorth> I've either done something really good, or really bad :)
19:15:13 * Alberth guesses it is the former
19:16:24 <Alberth> I'd like to do some digging why my code is not working tonight
19:17:02 <andythenorth> what are you coding?
19:19:47 <Alberth> I am changing the encoding program of rcd files, but the output is changing. So now I have to write a rcd inspection program to see whether the error is in the encoding program, or in the decoding. Unfortunately, the inspection program believes the image is wrong :p
19:20:17 <Alberth> so instead of going from 2 to 1 problem, I go from 2 to 3 problems
19:21:44 <andythenorth> I shall not bother you with python problems then :)
19:27:42 *** Chris_Booth has joined #openttd
19:33:19 *** JVassie has joined #openttd
19:33:46 *** lmergen has joined #openttd
19:41:32 *** Cybertinus has joined #openttd
20:04:45 <Alberth> ah, using one veriable for two purposes doesn't quite work :)
20:08:27 <Alberth> offset = rcd.uint8(offset + ptr)
20:08:27 <Alberth> count = rcd.uint8(offset + ptr + 1)
20:08:27 <Alberth> this does not read two consequtives bytes from memory :p
20:11:33 *** Chris_Booth has joined #openttd
20:12:34 <andythenorth> 'pc_stripe_colour()' or 'pc_stripe()' where pc = PixaColour
20:13:57 <Alberth> no idea what 'stripe' exactly means, but doesn't it imply 'colour'?
20:14:11 <andythenorth> if I only used these occasionally I'd include 'colour'
20:14:20 <andythenorth> but I have lines and lines of them consecutively
20:14:40 <andythenorth> and the definition of the object is nearby
20:15:15 * Alberth would go for the short version
20:16:21 *** holyduck has joined #openttd
20:17:41 <andythenorth> 'building one to throw away' is good
20:17:52 <andythenorth> but making the second one is work :P
20:18:10 * andythenorth is refactoring list definitions which is mind-numbingly dull
20:18:14 <andythenorth> maybe I should script it :P
20:22:52 <andythenorth> something worked - surprisingly
20:23:38 *** Keyboard_Warrior has quit IRC
20:37:59 *** Progman_ has joined #openttd
20:42:31 *** Progman_ is now known as Progman
20:46:50 *** Cybertinus has joined #openttd
20:49:27 *** Progman has joined #openttd
21:01:19 *** valhallasw has joined #openttd
21:19:57 <andythenorth> anyone see a way to get started with this module?
21:20:12 <andythenorth> I can't figure out which classes might return an image from a layer
21:30:10 *** frosch123 has joined #openttd
21:38:12 <Rhamphoryncus> umm.. oh, that won't help. Started a test game with *only* firs. Can't even load supplies
21:38:30 <andythenorth> you might need some vehicles :P
21:39:12 <Rhamphoryncus> Can't modify existing games, unless there's a secret trick?
21:39:34 <Yexo> and if you've just started a new game, there is no harm in restarting
21:39:45 <Rubidium> pff... nothing a hex editor can't solve ;)
21:39:52 <andythenorth> Rhamphoryncus: you have newgrf developer tools enabled?
21:40:07 <andythenorth> you'll definitely want those if you're writing newgrf :D
21:40:14 <Rubidium> yay... you voided someone else's warranty ;)
21:40:32 <Rhamphoryncus> Okay, before I start building again I better do that :)
21:40:44 <Rhamphoryncus> Rubidium: I have gdb. My warranty was voided to begin with.
21:40:57 <andythenorth> making test games for supplies - a lot more boring than writing the code for supplies
21:41:04 *** peteris has joined #openttd
21:41:12 <andythenorth> you have to set up an entire fricking primary-secondary-tertiary chain :P
21:41:30 <Zuu> Can't an AI help with that?
21:42:02 <andythenorth> write a testing AI Zuu ?
21:42:26 <Rhamphoryncus> Hey, there's the bounding box option! I came across the keyboard shortcut a bit ago but couldn't get it to work :D
21:42:30 <Zuu> I've already offered quite high level building blocks in SuperLib for road and air transport.
21:42:57 * andythenorth goes back to generating sprites ;)
21:43:31 <Zuu> Someone managed to make a networking AI using SuperLib for station and road building in just 1000 lines of code.
21:43:53 * Rhamphoryncus is a cheater :O
21:44:49 <Zuu> That said, I have only packaged the road pathfinder in a Connect(tile_a, tile_b) function with my finetuning of it.
21:48:28 <Rhamphoryncus> So if I save this game, modify the grf, and restart, will openttd refuse to load it? Or will happily continue until it dies from me changing registers?
21:49:01 <Yexo> if you have enabled the newgrf developer tools openttd will continue, if not it'll refuse to load the game
21:49:03 * Rhamphoryncus applauds himself. Load coal at the lime kiln and transport to coal mine >.>
21:49:31 <Yexo> if you change too much you might be able to crash openttd that way
21:49:43 <Yexo> it shouldn't happen, but it's hard to protect against everything a newgrf can do
21:53:44 <xiong> Do yapf.rail_longer_platform_penalty and etc. apply only to station stops or to all routing through platform tracks?
21:54:13 <Yexo> that one applies only when stopping
21:55:29 <xiong> Good. I expect yapf.rail_station_penalty applies when through routing.
21:56:25 <xiong> I do not see why my trains are taking an extremely long detour in preference to routing through a platform track.
21:59:05 <Rhamphoryncus> that station penalty might be per tile. Dunno.
21:59:46 <xiong> There are distinct longer/shorter penalties per station and per tile.
22:00:32 <xiong> yapf.rail_longer_platform_penalty = 800 yapf.rail_longer_platform_per_tile_penalty = 100
22:01:30 <andythenorth> that was a fun bug to eat
22:01:40 <xiong> yapf.rail_station_penalty = 1000 yapf.rail_pbs_station_penalty = 800
22:02:06 <xiong> Those are not real high but if either apply per tile, well, I'm looking at 12-tile platforms.
22:03:26 <xiong> Well, I can tinker with the pf weightings or I can order my trains via.
22:03:29 <planetmaker> nice white line programme, Alberth. Thanks
22:04:02 <Rhamphoryncus> xiong: or don't force them through a platform? :)
22:04:37 <Rubidium> not that it has much use in 32bpp land; there you just want transparent pixels ;)
22:04:48 <xiong> I have plenty of open platforms, Rhamphoryncus; that's why I built the station that way.
22:04:49 *** tokai|mdlx has joined #openttd
22:04:50 <Rubidium> no blue and no white
22:05:05 <michi_cc> xiong: The long/short stuff only applies to the destination stations, the normal and pbs station penalties apply to all station tiles.
22:06:09 <michi_cc> And yes, the latter two are by tile.
22:06:40 *** valhalla1w has joined #openttd
22:06:42 <planetmaker> true, Rubidium. I keep forgetting that
22:06:51 <xiong> michi_cc, Are you saying that with the above settings, my through trains see a penalty of 12*1800 = 21600?
22:07:32 <michi_cc> Code is "segment_cost += Yapf().PfGetSettings().rail_station_penalty * platform_length;"
22:07:34 <xiong> I think that's what you just said but it's an impressively high figure.
22:08:12 <xiong> Did I ignorantly boost those penalties at some earlier date?
22:08:35 <michi_cc> The PBS penalty only applies if the tile has a reservation though, if not, it's only the normal penalty.
22:09:01 <xiong> Even 12000 is prohibitive.
22:10:39 *** theholyduck has joined #openttd
22:19:39 <xiong> Well, okay, default. But I need to change something. Either a different plan of routing, different orders, or different penalties. Obviously.
22:20:43 <xiong> I guess that, even per tile, 1000 is not unreasonable on a network where player hasn't *planned* stations with excess platforms (possibly) for through trains.
22:22:04 <Rhamphoryncus> If you're planning excess platforms then you can plan some non-platforms
22:22:10 <xiong> Thing is, I built excess platforms and also through non-platform tracks. Trains exiting the station cannot get to the through tracks so I thought they'd exit through platforms. But they're taking the very long way around instead.
22:23:13 <xiong> I suspect it would actually be better to have no non-platform tracks at all, so penalties are equal on all tracks. That's easier than changing all train orders or tinkering with .cfg.
22:23:38 <xiong> My belt got caught in my suspenders.
22:23:54 <Rhamphoryncus> Changing the weighting is generally a bad idea
22:25:03 <xiong> I only recall making one penalty change; I adjusted the longer/shorter penalties for trains of radically different lengths hitting stations with mixed-length platforms.
22:25:10 <xiong> That seemed to work well.
22:25:53 <xiong> But I'm inclined to chalk up my troubles now to poor station design. Well, thanks all.
22:31:54 <xiong> Yes, that fixed it. The outside tracks are now platforms as well. They're linked and signaled differently but yapf sees them as platforms so, equal penalties and the simple route is chosen. Thanks again, guys.
22:34:21 <Rhamphoryncus> Does an industry's random_bits get reset every month? Or is it per-call, also per-month in this case?
22:39:01 <planetmaker> it's set at industry creation
22:39:18 <planetmaker> unless you ask them to be re-randomized
22:44:16 * andythenorth is a github newbie
22:44:22 <andythenorth> how do I 'like' a project :P
22:45:58 * Rhamphoryncus rearranges your punctuation. "how do I, like, a project?"
22:46:28 <Rhamphoryncus> <--- not helping
22:50:28 <Eddi|zuHause> something makes mingw-get-inst crash...
23:23:33 *** Firartix has joined #openttd
23:50:05 *** Wooteman has joined #openttd
23:51:04 <Rhamphoryncus> is it possible to inspect random_bits for an industry via the debugging tools?
23:55:12 <Rhamphoryncus> Nevermind, figured out how to eek out the information I want from the registers saved
23:57:45 *** Twofish has joined #openttd
continue to next day ⏵
