IRC logs for #openttd on OFTC at 2012-01-25
⏴ go to previous day
00:13:52 *** Asteconn has joined #openttd
00:35:40 *** Eddi|zuHause has joined #openttd
01:27:57 *** tokai|noir has joined #openttd
02:02:19 <Eddi|zuHause> we *really* need to increase the default timeouts
02:06:16 <Eddi|zuHause> also, we need a "connection timed out" error message
02:08:03 <Asteconn> 480 is pretty generous in my view
02:08:24 <Asteconn> Also - in the UKRS - what do brake vans do? Or are they just eyecandy?
02:11:00 <Eddi|zuHause> afaik early trains need them, if they reach a certain length
02:15:16 <Asteconn> You wouldn't happen to know what length would you?
02:23:49 <Asteconn> Is it usually this quiet in here? o.ô Or is everyone just idling because they're playing TTD? =3
02:30:54 <Eddi|zuHause> it is usually that quiet at 3:30 AM
02:34:22 <Asteconn> Most of the populace European?
02:57:50 <Asteconn> What are everyone's preferred GRFs then?
03:03:41 <Rhamphoryncus> Only one I use consistently is trams
03:03:54 <Rhamphoryncus> And there's several of those. Dunno which ones are the good ones ;)
03:04:01 <kais58> my server runs OpenGFX+
03:07:34 <Asteconn> I've never managed to get OpenGFX+ to work actually
03:07:43 <Asteconn> Question marks everywhere D:
03:10:50 <Asteconn> As I cannot remember off hand, does UKRS include any 3rd rail stuff?
03:16:27 <Asteconn> And another odd question: why are some of my trains of the same sort in slightly different liveries?
03:17:02 <Asteconn> I have 4 Brush type 4s sporting 2 different paint jobs
03:19:29 <Rhamphoryncus> Some newgrf sets randomly select different appearances
03:19:53 <Rhamphoryncus> I've only noticed it for horse-drawn buses, but I'm sure it could be done for other vehicles
03:21:36 <Asteconn> Ahhh righty! Awesome
03:29:09 <Rhamphoryncus> Is there any existing/cheap way to tell if a vehicle is at a station loading/waiting on the timetable? I'm hesitant to loop over all the vehicles every time I do an update (potentially once a tick, for a very busy route)
03:34:30 <Rhamphoryncus> I could keep a running count, but then I'd have to track down all the ways a vehicle can change what it's doing..
05:33:22 *** shoehorn has joined #openttd
05:56:22 *** Eddi|zuHause has joined #openttd
06:13:32 *** roboboy has joined #openttd
06:38:39 *** JVassie has joined #openttd
06:59:23 *** Cybertinus has joined #openttd
07:00:51 <shoehorn> are there any devs around?
07:06:05 <DorpsGek> planetmaker: Don't ask to ask, just ask
07:16:23 *** sla_ro|master has joined #openttd
07:20:47 *** DayDreamer has joined #openttd
07:55:55 *** Devroush has joined #openttd
07:59:10 *** Twofish has joined #openttd
09:48:22 *** Brianetta has joined #openttd
10:06:35 *** roboboy has joined #openttd
10:29:27 *** kais58_ has joined #openttd
10:42:30 *** TheMask96 has joined #openttd
10:45:45 *** andythenorth has joined #openttd
10:47:18 *** mahmoud has joined #openttd
11:26:50 *** Progman has joined #openttd
11:40:14 *** kais58_ has joined #openttd
12:04:03 *** cmircea has joined #openttd
12:24:46 *** roboboy has joined #openttd
13:35:34 <Jupix> Rubidium: it's his prototype, you shouldn't take it so seriously, nor label the whole of 32bpp under what he does
13:36:28 <Jupix> people experiment with stuff, doesn't mean they expect others to adapt their ways to that experiment
13:40:36 <Jupix> but! it's good that you posted there
13:43:47 <lugo> ehm, what's the limit in size for forum attachments? nothing in the faq?
14:12:43 <planetmaker> lugo, iirc around 5 or 6 MByte. But don't take my word on it.
14:18:09 *** TWerkhoven has joined #openttd
14:20:54 <planetmaker> I'll have a look tonight
14:24:17 *** andythenorth has joined #openttd
14:41:06 <michi_cc> Jupix: I would avoid calling the zoom levels z0, z1 and z2 where possible, as that nomenclature is bound to fail as soon as there is e.g. a x8 or a x1.5 or whatever, and doesn't cover zoom-out either.
14:42:58 <Rubidium> I think o2, o4, o8, i2, i4 are what peter1138 thought of
14:47:49 <Jupix> that's a really quick rename if/when there is ez sprite loading, for now it's a lot less confusing to stick with the existing naming convention that works with geektoo's patch
14:48:43 <Jupix> again I fail at inline editing
14:49:02 <Jupix> I meant to say when there is ez sprite loading in trunk and there is a naming convention for those sprites
14:49:23 *** TheMask96 has joined #openttd
15:02:49 *** Stimrol has joined #openttd
15:21:59 *** Asteconn has joined #openttd
15:42:41 *** Xrufuian has joined #openttd
16:00:59 *** Dozzer_X has joined #openttd
16:04:51 *** glevans2 has joined #openttd
16:16:50 *** devilsadvocate has quit IRC
16:17:42 *** devilsadvocate has joined #openttd
16:18:47 *** Rhamphoryncus has joined #openttd
16:19:55 *** Biolunar has joined #openttd
16:23:11 *** Asteconn has joined #openttd
16:47:04 *** devilsadvocate has quit IRC
16:56:02 <planetmaker> Jupix: and what are those "512 x 512 pixels" you talk in section 7.5 about?
16:56:37 <planetmaker> A tile in OpenTTD is never square and never has equal extend. And if you count pixels on a diagonal line... how do you count them?
16:56:52 <planetmaker> Especially if it's not 45° wrt the screen but... like 30°?
16:56:55 *** devilsadvocate has joined #openttd
17:10:54 *** TWerkhoven[l] has joined #openttd
17:12:08 *** valhallasw has joined #openttd
17:15:48 *** devilsadvocate has quit IRC
17:16:22 *** devilsadvocate has joined #openttd
17:19:20 <__ln__> "Kassel, the only East German city in the west"
17:19:25 *** Prof_Frink has joined #openttd
17:22:07 *** Asteconn has joined #openttd
17:25:36 <Eddi|zuHause> __ln__: that isn't really funny if you have no context
17:28:11 <__ln__> no particular context was expressed by the person who said that
17:29:04 <__ln__> so i typed it here to find out if anyone knows why :)
17:31:49 *** frosch123 has joined #openttd
17:37:40 *** valhalla1w has joined #openttd
17:43:46 *** Stimrol_ has joined #openttd
17:44:41 *** sla_ro|master has joined #openttd
17:45:07 <Eddi|zuHause> __ln__: well, you can make such a statement about any city
17:45:56 <Eddi|zuHause> __ln__: and after you've made up the statement out of thin air, you make up a statistic that founds it...
17:47:17 <__ln__> soon enough that statement will be found with a google search in openttd logs, which consequently proves the statement.
17:48:29 <planetmaker> note the many omissions I made
17:49:11 <planetmaker> hm... that was intended to be under my own user pages there...
17:54:13 * appe delivers poop on random doorstep.
18:01:58 <cypher> I hate the regional investigator! He's a complete jackass!
18:18:12 <xiong> __ln__, Perhaps you should insert the statement into Wikipedia, citing openttd. Then it will become a Known Fact.
18:22:27 *** Hirundo has joined #openttd
18:22:53 *** ChanServ sets mode: +o SmatZ
18:23:10 <peter1138> Jupix, tar format for 32bpp might not even remain ;p
18:23:28 *** ChanServ sets mode: +o Yexo
18:23:34 <Jupix> oh, I expect it to go away
18:23:40 *** planetmaker has joined #openttd
18:23:40 *** ChanServ sets mode: +o planetmaker
18:24:27 *** ^Spike^ has joined #openttd
18:24:51 *** XeryusTC has joined #openttd
18:24:57 *** Terkhen has joined #openttd
18:24:57 *** V453000 has joined #openttd
18:24:57 *** ChanServ sets mode: +o Terkhen
18:25:17 <peter1138> what do you anticipate in its place?
18:26:49 <Jupix> base set and newgrf's on top of it
18:29:01 <Jupix> planetmaker: I like the "what this project is not" part
18:31:15 <Eddi|zuHause> Jupix: not-goals are a very important part of a design process
18:31:43 <Jupix> I think in a couple days I'll be withdrawing my proposal and having to think whether to work a new pretty drastically new one
18:32:13 <Jupix> the vote is heavily against
18:32:29 <planetmaker> it's mixing different things
18:32:36 <planetmaker> - graphics guidelines
18:32:43 <planetmaker> - project organisation
18:32:56 <planetmaker> - 32bpp implementation in a (broken) patch
18:33:12 <planetmaker> - future OpenTTD implementation and speculative details for that
18:33:25 <planetmaker> - dictionary of terms
18:33:42 <planetmaker> - basesets vs. newgrfs
18:34:01 <Aygar> There is a bug in the doxygen documentation generation of the source; under what category should I file the bug report?
18:34:40 <CIA-1> OpenTTD: rubidium * r23849 /trunk/src/order_cmd.cpp:
18:34:40 <CIA-1> OpenTTD: -Fix [FS#5008]: when the network is lagging, you try to copy a vehicle's order
18:34:40 <CIA-1> OpenTTD: but accidentally create a station order and then copy the vehicle's order
18:34:40 <CIA-1> OpenTTD: (before the first command is executed) one could trigger an assertion from the
18:34:40 <CIA-1> OpenTTD: pool. Simplify the ancient code and make it more fool proof, even though it
18:34:41 <CIA-1> OpenTTD: could stop copying a vehicle's orders slightly earlier than it would now... but
18:34:42 <planetmaker> - oh, and a history section
18:34:43 <CIA-1> OpenTTD: who has come near that limit and really needed that many orders?
18:34:53 <Jupix> planetmaker: your point?
18:35:42 <planetmaker> it's a vote on a somewhat fuzzy vision. Mixed with some more or less technical details where some matter and some don't
18:35:58 <planetmaker> the point is: not a good thing to vote on as a whole
18:36:22 <Rubidium> but the vote doesn't tell why they are against it, right?
18:36:25 <planetmaker> some might need discussion or agreement. Some just need be followed by the person who actually codes the thing
18:36:38 <Rubidium> maybe they are against it because it doesn't contain "curved corners"?
18:37:47 <planetmaker> And IMHO the goal "32bpp blender files with GPL license" needs not a vote really.
18:37:53 <Jupix> Rubidium: some people posted what they thought was wrong, and some of those I tried to fix. whether those were the "no" votes I don't know
18:38:40 <Jupix> planetmaker: it's the vision of the people mentioned in the first chapters ... whether it's fuzzy or not, I'd say no, you say yes, so I don't know
18:39:10 <Jupix> planetmaker: I think it's all relevant and there's a lot of confusion in all those things you listed, so that's why they're touched upon
18:39:15 <planetmaker> the vision may not be fuzzy. But it's not... what you can vote on
18:39:20 <Rubidium> I'm not sure whether everything should be "drawn" as blenders. I can easily imaging that drawing the rail by hand is easier
18:39:35 <Jupix> Rubidium: that's taken into account
18:40:28 *** Alberth has joined #openttd
18:40:28 *** ChanServ sets mode: +o Alberth
18:40:35 <Jupix> in the de facto "official" process :D
18:40:51 <Jupix> so nowhere, since my proposal didn't pass
18:41:23 <Jupix> IIRC the ground tiles were all photoshop
18:41:48 <Jupix> the sources not being blender models or such is taken into account in the definition of sources
18:42:08 <Jupix> though the definition of sources is in that spec which didn't pass
18:42:21 *** Brianett1 has joined #openttd
18:44:41 <Jupix> I'm a bit burnt out from working the latest 4 revisions. as far as I'm concerned all of it is probably going on a back burner for a while and someone else can do what they want
18:45:19 <Jupix> you could just instate your proposal immediately since you have dev status :P
18:45:32 <CIA-1> OpenTTD: translators * r23850 /trunk/src/lang/ (french.txt polish.txt portuguese.txt):
18:45:32 <CIA-1> OpenTTD: -Update from WebTranslator v3.0:
18:45:32 <CIA-1> OpenTTD: french - 28 changes by OliTTD
18:45:32 <CIA-1> OpenTTD: polish - 3 changes by wojteks86
18:45:32 <CIA-1> OpenTTD: portuguese - 55 changes by JayCity
18:46:33 *** Brianett1 is now known as Brianetta
18:50:39 <planetmaker> Jupix: where does that change anything? And... what I wrote is imho the essence of what you wrote. So nothing new. Just cut down to what _I_ think is the important core
18:50:59 <planetmaker> without any distractions and side tracks
18:51:53 <Jupix> do you agree with its content?
18:52:41 <planetmaker> I agree to what I extracted from it ;-)
18:52:59 <Jupix> yes I mean the content of what you put on the wiki
18:53:38 <planetmaker> That's why I wrote it.
18:54:08 <planetmaker> it's not nicely written. just in 10 minutes or so
18:54:13 <planetmaker> so it will have it's rough edges
18:55:14 <frosch123> planetmaker: maybe add a sentence to "scale", that scale may not even be consistent within the same object
18:55:23 <frosch123> i.e. horizontal scale vs. vertical scale
18:55:58 <planetmaker> good point. Though I meant that, it should be explicit
18:56:50 *** ChanServ sets mode: +v tokai
18:57:06 <planetmaker> like now, frosch123?
18:59:04 *** tokai is now known as tokai|noir
19:00:21 *** cmircea has joined #openttd
19:01:24 <Jupix> planetmaker: my IRC shell is basically unusable right now due to lag, but I'm just gonna say you should set whatever you have there as "official" due to your developerness and because few else seem to care to do it
19:01:59 <Jupix> stuff like how it's laid out is secondary to the content
19:05:23 <Jupix> it appears very different to what I had and I can't read it completely at this mo to find out what content there is from my proposal. if it's similar, good, because I thought the content of mine was for the best, if it's different, so be it
19:06:37 <Jupix> I'll read it word by word tomorrow or friday
19:07:45 <planetmaker> I really think we want the same thing. The only difference might be that we have a slightly different view how to go there
19:08:03 *** andythenorth has joined #openttd
19:08:21 *** HerzogDeXtEr1 has joined #openttd
19:08:36 <andythenorth> what is today's discussion / argument / monologue?
19:10:40 <Alberth> andythenorth: you usually take care of the 'monologue' part :p
19:10:58 <cypher> Alberth : and what that production limit may be exactly?
19:12:11 <andythenorth> Jupix: I'm gonna have to ask you for those TPS reports
19:12:18 <cypher> planetmaker 255*9? Look at the screenshot...
19:12:34 <cypher> Alberth : what happens if the industry should produce more and hits the limit?
19:12:36 <Alberth> cypher: scaled by the unit of production
19:13:12 <planetmaker> cypher: and what about the screenshot? What shall I notice?
19:13:43 <cypher> 10K production, which in my opinion is a bit more than 255*9. I'm just wondering what would happen.
19:13:43 <Alberth> cypher: no idea, I never got further than a few 1,000 uints
19:14:12 <Alberth> but the system just won't transfer cargo any faster
19:14:32 <planetmaker> cypher: yes. It's a secondary industry. There more is feasible
19:14:39 <planetmaker> maybe not more than 2**16
19:14:52 <Alberth> so likely it is not accepted or it is stockpiled
19:14:54 <planetmaker> I'd have to look at the code to be sure
19:15:04 <planetmaker> Alberth: it's a default industry... so all is accepted
19:15:21 <Alberth> ok, so it goes up in smoke then :)
19:15:24 <planetmaker> and immediately processed
19:15:36 <planetmaker> I hope the sawmill doesn't produce too much smoke, though ;-)
19:15:44 <cypher> Alberth : it will transfer faster. There is no stockpiling that can't be solved by buying a few gazillion ships ships.
19:15:45 <Alberth> planetmaker: until you bring more than the limit
19:15:47 <cypher> planetmaker : what? :D
19:16:25 <Alberth> afaik something like 255 units every tick or so
19:16:29 <planetmaker> cypher: let me find you a game with saw mills...
19:16:46 <cypher> So you're concerned about the amount of smoke from the sawmill, but didn't even notice that riddiculous pile of ships in the top left corner.
19:17:01 <Alberth> planetmaker: multiplied by the unit of cargo perhaps?
19:17:11 <planetmaker> no. the unit of wood is 1
19:17:19 <planetmaker> and of goods at most 2
19:17:24 <planetmaker> but might be 1, too
19:17:37 <planetmaker> but it's production upon delivery
19:17:41 <frosch123> iirc for secondary industries the max production is also affected by the number of tiles the industry has
19:17:42 <Alberth> diamonds seem to be units of 16?
19:17:43 <planetmaker> thus... it might simply not be limited
19:17:48 <frosch123> (something completely weird actually)
19:18:19 <cypher> frosch123 : is there any docs about how exactly this works?
19:18:31 <Alberth> print the source code :)
19:18:33 <DorpsGek> andythenorth: 499824
19:18:44 <DorpsGek> andythenorth: 589824
19:18:53 <frosch123> 255 units * number of tiles * 9
19:19:06 <Rhamphoryncus> Huh. Why is a day 74 ticks rather than 72?
19:19:16 * andythenorth missed that bit of the original industry code :o
19:19:21 <Alberth> Rhamphoryncus: we borrowed 2
19:19:36 <Alberth> @calc 27000 / (9*255)
19:19:36 <DorpsGek> Alberth: 11.7647058824
19:19:46 <DorpsGek> frosch123: 885.621621622
19:20:03 <DorpsGek> Alberth: 364.864864865
19:20:05 <planetmaker> there's a max. And we needed 6 sawmills to reach 100k
19:20:15 <planetmaker> but they were sufficient ;-)
19:20:31 <frosch123> the limit is TransportIndustryGoods
19:21:29 <cypher> planetmaker : missing files, and they won't autodownload :(
19:26:42 <Rubidium> he probably lived on 4A ;)
19:26:50 <cypher> planetmaker : this is the most riddiculous thing i have ever seen in OpenTTD.
19:27:12 <planetmaker> goal: transport 100k goods. We made it ;-)
19:27:15 <cypher> I mean... is that still a game? :D
19:27:35 <planetmaker> well, yes, it's fun :-)
19:28:05 <planetmaker> we have there also other games... like game #200 or 201 are... a bit extreme, too
19:28:30 <planetmaker> #openttdcoop Records: Clients: 26 | Trains: 2666 (PSG#219) - 2522 (PZG#5) - ( 3000 (PSG#180) logic net) | Single cargo type output: 200,169 (PZG#13) | World Pop: 6,150,671 (PSG#201)
19:29:11 *** Chris_Booth has joined #openttd
19:30:55 <Alberth> cypher: that's what openttdcoop does, build extreme setups and other weird things. You should read their website :)
19:31:16 <cypher> Alberth : I'm not sure that I want to :-D
19:31:52 <planetmaker> You can (maybe) get back your sanity at the exit :-P
19:32:28 <Alberth> they have quite useful techniques for doing things in a network, like handling priority at a junction
19:32:29 <planetmaker> But in reality we just love to build together big train networks. Thus we agree on a common plan. And then build it
19:32:56 <planetmaker> And yes, we might use some advanced techniques. Which could also sometimes pass as cheating the path finder ;-)
19:33:44 <Alberth> or make large terminus stations with good performance
19:35:28 <planetmaker> yeah. That's... a tricky thing. A nice challenge :-)
19:36:31 <planetmaker> My personally favourite game style is a regional setup: one, two handful of regions with their local networks. They bring passengers to a hub central to each region. They then connected by a high-capacity intercity network
19:36:51 <planetmaker> makes good building for many. Different people can build different styles of local networks
19:36:59 <planetmaker> But it's still all one big picture :-)
19:37:19 <planetmaker> And it allows to compare different building techniques nicely how they perform under (heavy) load
19:37:20 <Eddi|zuHause> hm... trying to encode the turning states in the sprite is difficult...
19:37:24 <Rhamphoryncus> Alberth: I don't understand 27000 related to. In fact, it appears that nothing would even notice if I changed DAY_TICKS to 24. The only possible problem is I'd have to change the 885 multiplier in newgrf.cpp, and they could conceivably be dependant on it being a multiple of 885.
19:37:36 <andythenorth> Eddi|zuHause: animation frame?
19:37:49 <Eddi|zuHause> andythenorth: no.
19:38:52 <cypher> planetmaker : just saw game 201. One thing is that it almost crashed my computer.
19:39:02 *** supermop has joined #openttd
19:39:03 <Eddi|zuHause> andythenorth: assume two wood wagons, one is already turned, the other is not. if the wood spans two wagons, both wagons must be coded as one sprite
19:39:12 <cypher> Second thing is, I now conclude that you guys are weird.
19:39:22 <andythenorth> Eddi|zuHause: sounds like fun :) :P
19:40:20 <Eddi|zuHause> andythenorth: another example is the early prussian electrics, which consist of three very short parts, which would be difficult as single parts
19:40:46 <andythenorth> did I mention that I think you're insane?
19:41:04 <andythenorth> Eddi|zuHause: I think you're insane
19:41:06 <planetmaker> cypher: both may well be true ;-)
19:41:10 <Eddi|zuHause> did i mention that i think i'm insane?
19:41:56 <Rhamphoryncus> I'm definitely insane
19:43:31 <DorpsGek> Eddi|zuHause, Rhamphoryncus: as insane as thinking you are a bot?
19:43:43 <Rhamphoryncus> Who says I'm not?
19:43:48 <Eddi|zuHause> DorpsGek: almost :)
19:44:06 * Rhamphoryncus hums boten anna
19:44:17 <DorpsGek> Rhamphoryncus: i can smell bots
19:44:44 <Rhamphoryncus> How's my odour? Am I pungent enough?
19:49:14 <Eddi|zuHause> HA... IT HAPPENED. german government party CDU uses Megaupload to justify a SOPA-like law
19:52:34 *** andythenorth is now known as Guest496
19:52:34 *** andythenorth_ has joined #openttd
19:52:34 *** andythenorth_ is now known as andythenorth
20:02:51 <Rubidium> Eddi|zuHause: if only governments supported a SOHA-like law (stop online hypocracy act)
20:03:41 <Rubidium> e.g. be punished for saying a particular application is totally ruining your profit, while (still) distributing said application for many years
20:06:25 *** brendan10211 has joined #openttd
20:19:37 <Belugas> hoo... BestBuy has a flyer announcing Asus Tranformer Prime
20:21:22 <frosch123> hmm, am i too young or to old to not know what that is?
20:21:56 <planetmaker> probably you live on the wrong continent. I've no clue either. But then... our age is not grossly different ;-)
20:23:35 <Rubidium> isn't that just some new computer or so?
20:25:32 <andythenorth> when will newgrf smoke be done?
20:25:50 <frosch123> when you add fire to it
20:26:29 <andythenorth> frosch123: you had a spec
20:26:35 <andythenorth> why don't you rummage for it>
20:27:12 <frosch123> i don't think i had a spec for smoke :)
20:27:56 <andythenorth> 'spec' is approximate term
20:28:21 <andythenorth> I think it died because (as happens) it became over complicated
20:28:42 <andythenorth> e.g. 'need' for newgrf effect vehicles, 'need' to replace industry smoke with this etc
20:29:43 <frosch123> andythenorth: newgrf smoke vehicles were already planned 7 years ago :p
20:29:54 <Eddi|zuHause> can't be that hard...
20:29:59 <andythenorth> so was world peace :)
20:30:04 <andythenorth> newgrf smoke vehicles are overkill
20:30:24 <andythenorth> maybe Eddi|zuHause could use them to draw logs for vehicles though
20:30:29 <frosch123> the specs still state that livery overriding an engine with itself can be used to specify helicopter rotos and later visual effects :p
20:30:30 <andythenorth> they *will* be abused :P
20:30:48 *** lollercaust has joined #openttd
20:31:04 <andythenorth> how about something simpler?
20:31:07 <Eddi|zuHause> could be used for sails
20:31:23 <andythenorth> could be used to composite sprites for vehicles like ships
20:31:30 <andythenorth> providing cargo sprites for example
20:31:44 <andythenorth> single-tick animation cycle
20:32:13 <Alberth> Eddi|zuHause: but the wind always comes from the same direction, so you van draw sails statically
20:32:28 *** andythenorth has joined #openttd
20:33:35 <Eddi|zuHause> Alberth: but then you need to repeat the sail animation for each loading stage and cargo
20:34:00 <Eddi|zuHause> Alberth: same argument could be used to make rotors "static"
20:34:27 <andythenorth> I could fix ship smoke by drawing it into the sprites
20:34:34 <andythenorth> probably more likely to succeed
20:35:27 *** andythenorth is now known as Guest499
20:35:27 *** andythenorth_ has joined #openttd
20:35:27 *** andythenorth_ is now known as andythenorth
20:38:05 <Eddi|zuHause> andythenorth: that'll fail on turning
20:38:16 <andythenorth> Eddi|zuHause: I can handle that
20:38:53 <andythenorth> how many speed states should I provide?
20:39:01 <andythenorth> slow / medium / fast?
20:39:26 <Eddi|zuHause> andythenorth: how do you want to ensure the already-emitted smoke stays in place when the ship turns?
20:39:44 <andythenorth> store the previous angle
20:40:03 <andythenorth> 255 animation frames available?
20:40:05 <Eddi|zuHause> andythenorth: and moving when the ship accelerates?
20:40:26 <andythenorth> change the distance the smoke sprite is drawn at
20:40:32 <Eddi|zuHause> andythenorth: this is the point where i tell you that you're insane?
20:40:38 <andythenorth> how many angle-specific sprites do I need?
20:40:58 <andythenorth> what if the ship turns, then turns again?
20:41:02 <andythenorth> that's a harder case
20:41:06 <Eddi|zuHause> andythenorth: there's NO way that this will ever work
20:41:49 <andythenorth> what choice is there?
20:41:56 <andythenorth> (1) do nothing :)
20:42:21 <Eddi|zuHause> andythenorth: have you considered just emitting smoke from one chimney?
20:42:49 <andythenorth> is at least one of the problems
20:42:59 <andythenorth> the code can handle a z index btw, I tested
20:43:17 <Eddi|zuHause> so why not fix that first?
20:43:33 <andythenorth> because it was decided already that ad-hoc fixes won't be used for this
20:43:49 <andythenorth> a full newgrf-effect-vehicles spec is needed
20:43:55 <andythenorth> to avoid potential future cruft
20:44:23 <Eddi|zuHause> sure, a spec, but that doesn't mean that all of it has to be implemented at once
20:44:32 <andythenorth> e.g. the case was let's not build hysterical raisins
20:45:19 <andythenorth> are you sure It won't work in pure sprites?
20:45:41 <andythenorth> I'm not doing load sprites in FISH
20:45:58 <andythenorth> so I have 4 sprites for ships moving, 8 angles, 6 smoke sprites, and 8 'ship turned' angles to encode
20:46:29 <andythenorth> if GIMP scripting could be figured out, it might be possible to automate that
20:46:54 <CIA-1> OpenTTD: rubidium * r23851 /trunk/src/station_cmd.cpp: -Fix: infrastructure cache could get out of sync when overbuilding a drive through road stop
20:47:05 <andythenorth> I currently have 12 sprite rows per ship
20:47:10 <andythenorth> 192 isn't that many more
20:47:27 <andythenorth> I can probably write a code generator or templating to handle the nfo
20:48:01 <Eddi|zuHause> thanks, i'll have nightmares about this now...
20:48:49 <andythenorth> if you solve logs, you could patch HEQS logging trucks :P
20:52:38 <andythenorth> if gimp scripting can be figured out, we could avoid touching the smoke code at all
20:52:56 <planetmaker> gimp scripting is not terribly difficult
20:53:05 <planetmaker> let's say... I use it
20:53:12 <planetmaker> to export the proper sprites
20:53:14 <andythenorth> if the vehicle + all cargos are in one png, we could simply duplicate the png for each animation frame needed
20:53:29 <andythenorth> we need to feed it the co-ordinates to place smoke at for each angle of the vehicle
20:53:49 <andythenorth> so we'd have vehicle_smoke_frame_1.png, vehicle_smoke_frame_2.png etc
20:54:07 <planetmaker> just make a separate layer where the smoke is adjusted relative to the vehicle
20:54:17 <andythenorth> I'd want to script it
20:54:19 <planetmaker> and then it's a solved problem
20:54:24 <andythenorth> doing it by hand is a bit insane
20:54:32 <andythenorth> and scripting it makes it available to all sets
20:54:46 <andythenorth> it would be better to solve this in code
20:54:57 <planetmaker> no. Only those which use the exact template
20:55:08 <planetmaker> and then they could just as well use the same 4 layers of slightly shifted smoke
20:55:51 <planetmaker> and those smoke layers could be overlayed onto each vehicle, of course
20:56:02 <andythenorth> we could open multiple files and merge them
20:56:05 <planetmaker> though I think that's a very bad solution to do it that way
20:56:19 <planetmaker> like adding smoke vehicle-side
20:56:54 <andythenorth> it's viable though
20:57:36 <andythenorth> I wouldn't find it fun to do tbh
20:58:52 <Rhamphoryncus> Is there an easy way to print out a destination name for debugging?
21:00:14 *** andythenorth is now known as Guest500
21:00:15 *** andythenorth has joined #openttd
21:04:07 <andythenorth> the smoke will move with the vehicle
21:04:16 <andythenorth> this is sub-optimal
21:04:31 <Eddi|zuHause> Rhamphoryncus: string handling is definitely "not easy"
21:04:56 <andythenorth> I'll need bigger sprites
21:04:59 <andythenorth> that means new templates
21:05:20 <andythenorth> and also...FISH already flickers because the sprites extend beyond bounding box
21:05:28 <Rhamphoryncus> Eddi|zuHause: plenty of l10n stuff I could understand, but the station name itself? Once generated it should be fixed (and the user can edit it arbitrarily). So where is it?
21:05:55 <Eddi|zuHause> Rhamphoryncus: no. it doesn't work this way
21:06:19 <Eddi|zuHause> Rhamphoryncus: the station name is consisting of parts, which are reconstructed every time it is displayed
21:06:32 <Eddi|zuHause> Rhamphoryncus: that way it can react e.g. on town name changes
21:06:44 <Eddi|zuHause> Rhamphoryncus: only if the user actually edits it, it is stored
21:07:11 <Rhamphoryncus> Ahh. So I need to go do a trivial edit to make it easy
21:08:01 <Eddi|zuHause> Rhamphoryncus: i'd say you should rather copy-paste the station sign code
21:08:21 <Rhamphoryncus> ... for a debug printf?
21:09:05 <Rhamphoryncus> So I should start rolling my own debugging lib
21:10:14 <Rubidium> SetDParam(0, stationid); char buffer[512]; GetString(buffer, STR_STATION_NAME, lastof(buffer); printf("%s\n", buffer);
21:10:28 <Rubidium> no need to copy code; that's only making it harder/more difficult
21:11:56 <Rhamphoryncus> That's still a bit obtuse, but it's survivable
21:13:04 <Rubidium> oh... why do I now want to play some Mike Oldfield?
21:14:25 <Eddi|zuHause> planetmaker: suggestion: remove the dep call completely, and replace it with a "find -iname '*.png'"
21:14:25 <Rubidium> well, the strings aren't meant to be printed to the console, so it's not optimised for that workflow
21:30:35 *** andythenorth has joined #openttd
21:40:01 <planetmaker> Eddi|zuHause: that then assumes that all pngs are automatically needed
21:40:23 <Eddi|zuHause> planetmaker: that's a better approximation than waiting 2 minutes for an exact result
21:40:44 <Eddi|zuHause> planetmaker: alternatively, i can make the generator script create the dep file
21:42:34 <planetmaker> one could also just not use a dep check at all
21:46:29 <andythenorth> dep check was added for a reason
21:46:32 <andythenorth> I forget it though
21:48:12 <Aygar> Is the last tile in the map tile array always MP_VOID?
21:50:25 <Yexo> all tiles at the south-east and south-west border are MP_VOID
21:50:42 <Yexo> if you play with custom map borders all tiles at the north-east and north-west borders are also MP_VOID
21:50:45 <Rubidium> what is always in this context? I remember TTDPatch savegames messing with some of the void types
21:51:03 <frosch123> yeah, ttdp stores data on those tiles
21:51:16 <frosch123> but i guess not in the tiletype, but in the other bits
21:51:27 <Rubidium> so the tiles might not always be exactly the same as the MP_VOID tiles generated by a new game
21:52:30 <Belugas> Best Buy is a store, and Asus Transformer Prime is an android tablet, pretty cool from what we can gather :)
21:52:44 <Belugas> and not, it's not a north amercian stuff, it's mondial
21:53:00 <Belugas> and yes, i have a big case of lagging :)
21:54:40 <Eddi|zuHause> "ten minutes before work ends"?
22:01:46 <Aygar> If the last tile in the map tile array never has its tile_loop_proc() run could that be a problem?
22:02:37 <frosch123> i remember a fs task about that... was that your patch?
22:03:12 <Aygar> just thinking about alternate ways to make it work.
22:03:23 <frosch123> well, then.. there is a fs task about making the tileloop's pattern less noticeable. it just misses the last tile on the map :p
22:04:15 <frosch123> the most imporant part about this is, that every tile needs to be processed every 256 ticks
22:04:34 <frosch123> not more often and not less often
22:04:52 <frosch123> the order is not important though
22:05:46 <frosch123> (but obviously the order must stay constant, if the frequence for a single tile must be 1/(256 ticks))
22:07:11 <Aygar> frosch123: okay, thanks for the info
22:09:01 <Yexo> create a list with all valid TileIndexes on game start. Shuffle that list. Run tileloop on 1/256 part of that list every tick
22:09:14 <Yexo> really random order every game :)
22:09:53 <CIA-1> OpenTTD: rubidium * r23852 /trunk/Doxyfile: -Fix [FS#5011]: doxygen went haywire on FINAL token
22:09:59 <frosch123> random might look weird :p
22:10:16 <CIA-1> OpenTTD: rubidium * r23853 /trunk/src/ (3 files in 3 dirs): -Fix: several incorrect @files
22:10:30 *** ricky26 has joined #openttd
22:15:10 <Eddi|zuHause> well, we just need something like the 1/x function in GF(map_size)
22:15:23 <Eddi|zuHause> where GF is the galois-field
22:19:58 <Eddi|zuHause> it's "random" in the sense that it does not have a clear pattern, and it's "not random" in the sense that it has no repetitions
22:20:24 <Eddi|zuHause> and it always exists, because map_size is a power of two
22:22:23 <andythenorth> which will be done first? CETS or BANDIT? :D
22:23:02 * andythenorth has no artist currently
22:23:41 <Eddi|zuHause> we have two artist, but they're kinda "not fast enough"
22:26:06 * andythenorth has to hope for DanMacK to get enthused
22:27:22 <andythenorth> purchase cost by formula
22:27:41 <andythenorth> truck costs are remarkably boring
22:28:36 <Eddi|zuHause> in CETS i do something like cost = weight*power^(1/4)
22:28:52 <andythenorth> yeah, FISH has algorithms similart
22:29:09 <andythenorth> number crew * tonnage * (river || sea) etc
22:29:45 <andythenorth> trucks might be vehicle life * weight * blah
22:30:07 <andythenorth> cab type (sleeper = more)
22:30:32 <Eddi|zuHause> don't include stuff that isn't modelled anyway
22:30:54 <andythenorth> you mean stuff without a game prop?
22:31:12 <Eddi|zuHause> stuff that has no gameplay effect
22:31:39 * andythenorth will disagree most politely with that :)
22:31:49 <andythenorth> cost has a gameplay effect in it's own right ;)
22:33:01 <Eddi|zuHause> CETS compile time: real 7m15.717s user 7m8.896s sys 0m5.610s
22:33:02 <Eddi|zuHause> with custom dep check: real 4m48.278s user 4m42.811s sys 0m4.486s
22:33:04 <Eddi|zuHause> with custom dep check, nfo output via grfcodec: real 2m50.047s user 2m45.567s sys 0m3.750s
22:36:37 <andythenorth> I thought removing a dir of 40 files might speed it up
22:36:42 <andythenorth> no difference at all :o
22:44:22 <Eddi|zuHause> planetmaker: i'm committing makefile changes now, any suggestions on how to make them in a way they "survive" a makefile update?
22:44:37 <planetmaker> change Makefile.in
22:45:17 <Eddi|zuHause> planetmaker: well, i have to remove lines from Makefile.nml
22:45:28 <Eddi|zuHause> or can i just "override" them from Makefile.in?
22:47:14 <planetmaker> I guess that doesn't work
22:47:32 <Eddi|zuHause> well, i just pushed my changes
22:47:33 <planetmaker> I suggest to just change it in place and not care about compatibility
22:47:39 <Eddi|zuHause> if you have ideas...
22:47:59 <planetmaker> I have the idea to sleep now ;-) But I said that already :-P
22:48:19 <Eddi|zuHause> you can take a look later :)
22:48:31 <planetmaker> but some speedup there is overdue. So yes
22:48:37 <planetmaker> eventually I will
23:13:18 <Belugas> [16:54] <Eddi|zuHause> "ten minutes before work ends"? <-- sadly, no... still "here"
23:13:37 <Belugas> i think i'll go home... to tired to think
23:20:38 *** Brianetta has joined #openttd
23:20:43 <Eddi|zuHause> python -m cProfile -s time ../nml/nmlc -o cets.nfo cets.nml > profile2.txt
23:20:55 <Eddi|zuHause> says that it spends 45 seconds in binop.py:reduce
23:24:01 <Eddi|zuHause> probably "-s cumulative" is more interesting
23:28:32 <Eddi|zuHause> www.informatik.uni-halle.de/~krause/profile_time.txt
23:28:40 <Eddi|zuHause> www.informatik.uni-halle.de/~krause/profile_cumulative.txt
continue to next day ⏵
