IRC logs for #openttd on OFTC at 2013-07-15
⏴ go to previous day
00:34:54 *** HerzogDeXtEr1 has joined #openttd
01:46:39 <Supercheese> "if they haven't died, they still live today" sounds like a meaningless truism
01:47:10 *** montalvo has joined #openttd
02:12:39 *** montalvo is now known as secretname
02:53:35 *** roboboy has joined #openttd
03:11:40 *** SamanthaD has joined #openttd
03:17:44 *** supermop has joined #openttd
04:56:16 *** Eddi|zuHause has joined #openttd
05:26:47 *** kais58|A1K has joined #openttd
05:37:13 *** secretname is now known as montalvo
06:07:26 *** andythenorth has joined #openttd
06:17:08 *** andythenorth has joined #openttd
06:29:28 *** andythenorth has joined #openttd
07:07:18 *** ntoskrnl has joined #openttd
07:21:22 *** Pensacola has joined #openttd
07:44:01 *** sla_ro|master has joined #openttd
08:20:15 *** Ristovski has joined #openttd
08:40:59 *** Mielipuoli has joined #openttd
08:41:30 *** Mielipuoli is now known as MatrixCL
08:57:31 *** Midnightmyth has joined #openttd
09:25:28 *** oskari89 has joined #openttd
09:43:11 *** andythenorth has joined #openttd
10:08:30 *** Polleke has joined #openttd
10:21:52 <KenjiE20> o.O official TT on mobile O.o
10:22:20 <KenjiE20> that was my reaction
10:22:22 <Xaroth|Work> I doubt there's anything 'official' about it
10:22:35 <Xaroth|Work> unless it's posted on openttd.org ;)
10:22:48 <KenjiE20> Xaroth|Work: it's not OpenTTD, its TT
10:22:50 <planetmaker> (not openttd. ttd)
10:23:39 <andythenorth> wonder if he'll support newgrf? :P
10:24:05 <andythenorth> "at last, after many years, TT on an iPad"
10:25:32 <zeknurn> Hopefully they will release it for Windows as well
10:26:08 <zeknurn> I'd buy a touch optimised version of TT.
10:27:30 <planetmaker> you have a quite improved version for windows ;-)
10:27:48 <planetmaker> if you think it's worth money, you should donate then
10:29:05 <peter1139> it sucks on small devices
10:29:14 <planetmaker> windows and small devices?
10:29:27 <peter1139> Arriving 2013 on iOS and Android platforms
10:29:35 <peter1139> of course there are tablets, but
10:29:37 <andythenorth> stupid iPad is not small :P
10:29:56 * andythenorth has the less stupid, smaller iPad
10:30:11 <andythenorth> no point having a device that is both large *and* a crippled computer
10:30:14 <peter1139> that's my idea of an ipad
10:30:32 <andythenorth> if I'm going to have a crippled computer, I want a smallish one
10:30:58 <__ln__> but i thought ipad and android do not run x86 machine code.
10:31:03 <andythenorth> nice weather app on iPhone though
10:31:09 <andythenorth> and it makes phone calls sometimes
10:31:34 <KenjiE20> you can talk to people on a phone? who knew?
10:31:36 <__ln__> and x86 assembly is the language that Sawyer codes his games in.
10:32:04 <andythenorth> KenjiE20: on my phone, only if you buy bumpers so it can get a signal...
10:35:32 <zeknurn> planetmaker. I'd rather have a version that's built ground up for touch on a tablet. Also if it sells enough it could encourage Sawyer to return to making tycoon games.
10:35:42 <andythenorth> that's bad for us :P
10:35:51 <andythenorth> incentives lawyers :(
10:36:17 <planetmaker> obviously someone finally found the copyright holder for those games again
10:36:35 <planetmaker> when some people asked no-one seems to recall or find themselves in the position to say "I hold the copyright"
10:36:52 <zeknurn> usually the case with left for dead ips
10:37:20 <zeknurn> I guess Sawyer bought it
10:37:31 <KenjiE20> well since atari went all weird, I guess sawyer claimed it back?
10:38:44 <zeknurn> Yeah, Atari US has been selling of IPs since they went bankrupt.
10:38:44 <planetmaker> I specifically looked. I didn't see TT(D) up for sale. But possibly still, yes
10:39:05 <KenjiE20> he could've gone direct
10:40:13 <__ln__> maybe he has just acquired the trademark, and the trademark owner was always known. the game itself must be a rewrite in any case.
10:40:25 <planetmaker> btw, andythenorth I attached to FISH an updated makefile patch for you to test
10:40:56 <planetmaker> I want to make a bit cleanup before comitting, but... test before :-)
10:42:37 <planetmaker> it gave me the idea how to make it modular with plug-in capability without actually ripping the Makefile into many parts :-)
10:42:55 <andythenorth> no longer runs nml twice :)
10:43:33 <andythenorth> I ran make clean
10:43:38 <andythenorth> now it can't find fish.nml :)
10:43:50 <andythenorth> so maybe another round? :)
10:50:23 <planetmaker> hm, shouldn't a call to build_fish.py generate fish.nml?
10:51:35 <Eddi|zuHause> <V453000> fish will go purr <-- is that like "all pigs will fly up"?
10:52:12 <Eddi|zuHause> (is that game even known anywhere else?)
10:53:54 <planetmaker> I see... I bugged it
10:54:50 <planetmaker> andythenorth, in scripts/render_nml.py undo the path change I applied in line 26
10:57:01 <V453000> Anything can happen Eddi
10:57:10 <V453000> but I dont know flying pigs yet
10:57:40 <andythenorth> planetmaker: seems to work
10:57:57 <planetmaker> sweet. Then I'll tidy Makefile.config and commit
10:58:21 <Eddi|zuHause> (the game goes like this: a bunch of kids sit around the table, and everyone slaps their hands on the table. the leader of the game, usually a parent or teacher, will shout out the phrase "All <x> fly up" and puts his hands in the air. if <x> is actually able to fly, everyone must also put their hands in the air.)
10:58:56 <V453000> omg :) how much alcohol is needed?
10:59:01 <V453000> do the rules state that?
10:59:19 <Eddi|zuHause> only if you're an adult which is not a parent :p
11:00:59 *** ntoskrnl11 has joined #openttd
11:01:31 <Eddi|zuHause> "1 Table, many hands, quick responses"
11:01:58 <V453000> I can only assume that alcohol is the default and does not need to be mentioned
11:02:05 <andythenorth> planetmaker: poke me when I should pull :)
11:02:41 <V453000> OR the page is strongly alternative and obsesses with uncommon game practice without alcohol
11:02:45 <V453000> which would be weird but you never know
11:05:10 <Eddi|zuHause> V453000: the point of the game is the humiliation if you put your hands up at the wrong time (or less commonly: if you don't put your hands up) .p
11:05:42 <V453000> of course, so you would e.g. have to humiliately drink a beer as a punishment
11:05:56 <planetmaker> andythenorth, pull
11:06:52 <andythenorth> and I don't have to run make clean every time
11:07:57 <andythenorth> planetmaker: next thing... src/FISH.cfg is deprecated :) So I want to change makefile.in to ignore it
11:08:09 <andythenorth> ignore / use something more appropriate
11:10:17 <Eddi|zuHause> didn't we already discuss that?
11:10:48 <Eddi|zuHause> just remove it from the dependencies
11:11:01 <Eddi|zuHause> and instead put all .py files into the GENERATE= line
11:11:47 <andythenorth> why wasn't that necessary for FIRS?
11:11:54 <andythenorth> FIRS uses a phony target
11:12:37 <Eddi|zuHause> FIRS took the easy way out, to redo everything every time
11:12:53 <Eddi|zuHause> but it's ... phony :p
11:13:33 <Eddi|zuHause> anyway, i wanted to dig out my python stuff to see if one easily can make a "pydep.py" out of it :)
11:13:49 <andythenorth> scan files in recursive dirs?
11:13:53 <andythenorth> store to a file?
11:14:00 <andythenorth> or something better?
11:14:10 *** ntoskrnl has joined #openttd
11:14:45 <Eddi|zuHause> parse file -> search all "Import" nodes, see if that matches a file/package, output a dep line, recurse
11:14:48 <planetmaker> Eddi|zuHause, FISH does that, too, now. basically
11:15:31 <Eddi|zuHause> about 30LOC estimated
11:15:38 <andythenorth> try it for FISH :)
11:15:43 <andythenorth> it's a nice simple repo :)
11:15:51 <V453000> loc loc locomotive :>
11:16:23 <planetmaker> andythenorth, yes, just like eddi said: remove it from dependencies in Makefile.in
11:16:35 <planetmaker> and possibly replace it by a list of appropriate files
11:16:43 *** TheMask96 has joined #openttd
11:16:53 <planetmaker> alternatively, replace it by a phony, but empty target
11:16:58 <planetmaker> then it re-builds everytime
11:17:13 <planetmaker> for instance the target could be "pnml" without quotes
11:17:18 <andythenorth> fish-nml: $(GENERATE) appears to work?
11:17:22 <planetmaker> as that already exists and does nothing
11:17:55 <planetmaker> I fear it won't re-generate, if you change source but not src/build_fish.py
11:18:09 <andythenorth> probably not without a make clean
11:18:18 <planetmaker> thus: add an empty, phony target
11:18:28 <andythenorth> does seem to work with just make
11:19:22 <planetmaker> or... simply remove $(GENERATE) from that line, too
11:19:28 <planetmaker> that's better even
11:19:54 <planetmaker> so that line 8 simply reads
11:20:19 <planetmaker> unconditional re-build
11:20:48 <planetmaker> if build time is too long, the unconditional could be changed to re-build only what is needed. But... meh
11:20:59 <andythenorth> so not today's problem :)
11:21:07 <planetmaker> it needs anyway compiling the whole NewGRF. Thus I consider that pointless in most cases
11:21:14 <planetmaker> Which does not warrant complications today
11:21:57 <planetmaker> with eddi's partial compilation on CETS that's a different issue :-)
11:23:49 * andythenorth just enabled chameleon templating cache
11:23:54 <andythenorth> cuts 4s off the python step
11:24:07 <planetmaker> from how many in total?
11:24:24 <andythenorth> it's about 6-7s now to compile
11:24:54 <planetmaker> he... my total for FISH is user 0m5.112s
11:25:10 <andythenorth> let me commit this
11:27:21 <andythenorth> planetmaker: pull and try?
11:30:22 <planetmaker> trallala, I tested wrong repo before :D 0m7.604s without and 0m4.352s with caching. Nice
11:30:42 <andythenorth> it's fast enough
11:31:01 <andythenorth> python step is 0.2s with the caching
11:31:07 <andythenorth> I could make it faster with multiprocessing
11:31:15 <andythenorth> but meh, nml uses the rest of the time :)
11:32:46 <planetmaker> nml should use multi-processing
11:32:58 <planetmaker> wonder whether it does :-)
11:33:17 <andythenorth> *if* the slow step is parsing the varaction 2 ids, then it won't help afaik
11:33:23 <andythenorth> assuming that is what makes it slow
11:33:35 <planetmaker> that's what I assume, too, yes
11:33:38 <andythenorth> I have no idea who profiled it to find that out though :)
11:34:16 <planetmaker> though definitely yexo and hirundo did some profiling
11:44:36 *** HerzogDeXtEr has joined #openttd
11:46:45 <andythenorth> wonder if I could hack my own nasty linker for FIRS
11:47:52 <planetmaker> what you want to link there?
11:47:56 <andythenorth> partial compiles
11:48:03 <andythenorth> compile per-industry
11:48:07 <andythenorth> then concatenate
11:48:21 <andythenorth> it's a crappy idea
11:48:40 <planetmaker> yes. and no. Depends ;-)
11:49:40 <planetmaker> preferentially that should go in NML, I think
11:49:46 <andythenorth> I am thinking that too
11:50:07 <planetmaker> it's also python. Feel free to give it a stab
11:50:36 <andythenorth> I wonder if it is too hard for nml?
11:50:53 <andythenorth> how does nml know what can safely be isolated, except by scanning entire file?
11:51:06 <andythenorth> whereas makefile or build script for a project can know that safely
11:52:17 <planetmaker> you could introduce syntax to indicate that. Would be a valid requirement
11:53:51 <andythenorth> oh, that's a point
12:09:35 *** Tom_Soft has joined #openttd
12:43:43 *** kais58|A1K is now known as kais58__4
13:00:06 *** andythenorth has joined #openttd
13:03:03 <andythenorth> carbon monoxide alarm is going off here
13:06:43 <Eddi|zuHause> if you can't smell it, it can't be dangerous :p
13:12:22 *** Ristovski has joined #openttd
13:15:52 *** zeknurn has joined #openttd
13:16:20 <Zuu> Hmm... tt-forums seems to be down
13:16:55 <Elukka> more tracks more better
13:17:06 *** lobster has joined #openttd
13:18:00 <Eddi|zuHause> so why is this wirdly rescaled instead of a plain screenshot?
13:18:33 <Eddi|zuHause> besides of wasting bandwidth because the file gets 4 times larger, this is also unreadable
13:19:06 <Elukka> you have to click it or you get dropbox's additionally rescaled blurry version
13:19:10 <Elukka> which sucks, but what can you do
13:19:21 <Eddi|zuHause> i can't click on it
13:19:39 <Elukka> nothing i can do about dropbox rescaling it unfortunately
13:19:44 <Elukka> photobucket does the same except you can't get the real version
13:20:47 <Eddi|zuHause> i think you're not using it correctly...
13:21:04 <Eddi|zuHause> obviously dropbox must have ways to provide unaltered binary files
13:42:59 <Elukka> well, it's clickable for others apparently
13:45:52 <Elukka> can't really see an issue with 'wasting bandwidth'... if that was a concern it'd make sense not to click image links
13:46:11 <Elukka> interestingly though i haven't found a very good image format for sharp pixel graphics like openttd's
13:46:19 <Elukka> jpg is terribly artifacty, png is huge
13:46:31 <Xaroth|Work> png works just fine for openttd screenshots
13:47:21 <Xaroth|Work> but as i said, try uploading it to something like imgur
13:47:32 <Xaroth|Work> that should give you a rather intact image
13:48:07 <Elukka> my only beef with imgur is that you apparently can't have subalbums
13:48:11 <Elukka> guess i should make an account anyway
13:48:16 <Elukka> usually i use it for thoraway images
13:50:18 <Elukka> png works but it doesn't feel ideal
13:50:28 <Elukka> might not be a better way to complex pixel art now that i think about it
13:51:03 <Elukka> for more complex graphics, or photos, jpg gets the file size for a largeish screenshot down to 200ish kb with no real loss in quality
13:51:25 <Elukka> for something with sharp edges and limited complexity png is about the same size or even smaller and obviously has no artifacts
13:52:06 <Elukka> a fullscreen openttd screenshot in png will be about 1-2 mb though
13:52:16 <Eddi|zuHause> only if you use 32bpp
13:55:03 <planetmaker> @calc 1920*1200*8 / 1024/1024
13:55:03 <DorpsGek> planetmaker: 17.578125
13:55:56 <planetmaker> add the zlib compression intrinsic to png it will be smaller than 17.5/8
14:24:51 *** y2000rtc has joined #openttd
14:27:18 *** andythenorth has joined #openttd
15:38:39 *** permagreen has joined #openttd
15:41:56 <Xaroth|Work> Linux for Workstation ?
15:42:29 <Rubidium> guess you're too young to appreciate that pun
15:42:56 <Xaroth|Work> I guess you assume a wee bit too much here
16:06:11 *** LordAro has joined #openttd
16:14:04 <planetmaker> yes. And hi LordAro
16:26:18 *** Midnightmyth has joined #openttd
16:36:37 *** TheMask96 has joined #openttd
16:36:45 *** andythenorth has joined #openttd
16:47:27 *** SamanthaD has joined #openttd
16:47:34 *** frosch123 has joined #openttd
16:48:13 *** Progman has joined #openttd
17:13:19 <andythenorth> python: any equivalent to get() for object props?
17:13:27 <andythenorth> I could use hasattr, but that's ugly in this context
17:17:06 *** permagreen has joined #openttd
17:21:53 * andythenorth did search first :P
17:32:16 *** gelignite has joined #openttd
17:45:15 <DorpsGek> Commit by translators :: r25613 trunk/src/lang/german.txt (2013-07-15 17:45:08 UTC)
17:45:16 <andythenorth> refactored to deal with it
17:45:17 <DorpsGek> -Update from WebTranslator v3.0:
17:45:18 <DorpsGek> german - 5 changes by Jogio
17:53:51 <frosch123> how to tell you are in the year 2013?
17:54:10 <frosch123> online shops cannot handle umlauts in shipping addresses
17:54:31 <Rubidium> they're probably still using Windows for Workgroups
17:54:43 <Kjetil> Linux for Workgroups you mean :P
17:54:58 <frosch123> i am sure linux for workgroups can handle unicode quite well
17:55:02 <Rubidium> Kjetil: no, because that can generally handle those things quite effortlessly
17:55:28 <Kjetil> *writes a patch to break the support for win 3.11 compatability*
18:05:28 *** MatrixCL has joined #openttd
18:19:33 <DorpsGek> Commit by rubidium :: r25614 /trunk/src/script/api (3 files in 3 dirs) (2013-07-15 18:19:26 UTC)
18:19:34 <DorpsGek> -Fix [FS#5651]: [Script] Give a slightly less generic error when removing inexisting rail
18:19:35 <DorpsGek> -Fix [FS#5650]: [Script] Be more specific that a non-NewGRF station can be built when asking for a NewGRF station
18:37:26 <LordAro> hullo, fellow redditor :)
18:41:01 *** andythenorth has joined #openttd
18:43:07 <V453000> I give up on commenting landscape sprites because I know how much hell it is to make them look nice
18:43:26 <V453000> but I think it looks quite good
18:43:39 <V453000> the grid version should probably have the grid a lot less visible though
18:44:44 <planetmaker> Please feel free to also comment more. This is just 30 minutes of copy & paste and 30 minutes of compiling the grf :D
18:45:22 <planetmaker> Just grabbed Wesnoth's desert sprite, rotated and skewed it. That's it
18:45:59 <Rubidium> the while one definitely is too repetitive ;)
18:46:09 <V453000> I would try to remove the dark dot
18:46:56 <planetmaker> hm, I see. Yeah... that might be too much
18:47:12 <andythenorth> planetmaker: sprucing up ogfx? o_O
18:47:22 <planetmaker> eventually, maybe
18:47:36 <Eddi|zuHause> planetmaker: i think for the repetitiveness it has too much contrast
18:49:04 <V453000> yeah perhaps reducing that a little bit could help too
18:49:19 *** kais58__5 has joined #openttd
18:50:41 <Eddi|zuHause> it's less obvious with the grid, but then what V453000 said applies, the grid is too wide
18:50:47 <planetmaker> I think the contrast is not larger than others. But the location frequency is (much) lower
18:51:24 <planetmaker> the grid is not too wide. It's exactly the grid lines as found also now on all sprites. But drawn by the grid line patch ;-)
18:51:27 <V453000> grid is too obvious, both making it less wide, or less "opaque" would help
18:51:46 <V453000> if less wide is not the option, then less contrasty :P
18:51:53 <planetmaker> the gridline patch is slightly darker than current grid lines, though
18:52:15 <Eddi|zuHause> in the gridless version, you have too obvious vertical lines
18:55:24 <Xaroth|Work> planetmaker: looks like white spice from opendune
18:58:30 <planetmaker> hm, I should first design the terrain in 32bpp-file. Then copy the result to 8bpp file... easier
19:00:30 <andythenorth> python: multiple inheritance = bad?
19:00:54 <Xaroth|Work> depends on what you're trying to do
19:01:01 <Rubidium> multiple inheritance is good for evolution
19:01:06 *** kais58__5 is now known as kais58|AFK
19:02:35 <Xaroth|Work> andythenorth: got a public repo somewhere perchance?
19:12:57 <Xaroth|Work> right, time to check it out
19:17:51 * andythenorth might be reinventing mixins :(
19:18:03 <Xaroth|Work> chameleon as templating engine?
19:19:11 <andythenorth> wrong tool, but I know how to use it
19:19:58 <Xaroth|Work> it looks absolutely horrible :P
19:20:04 * Xaroth|Work is used to django/jinja-style templating
19:20:38 <andythenorth> templating is templating :)
19:21:34 *** Alberth has joined #openttd
19:21:34 *** ChanServ sets mode: +o Alberth
19:26:28 <Alberth> LordAro: next time, don't tell RCT2 runs under Wine, it's not good for other projects ;p
19:27:36 <Alberth> although one weekend is probably enough for some time, the game is pretty simple :)
19:29:58 <andythenorth> Xaroth|Work: so does it build for you? o_O
19:30:59 <Xaroth|Work> andythenorth: not tried building it
19:31:02 <Xaroth|Work> rummaging through code
19:31:18 <andythenorth> it's midway through a tidy up :P
19:32:04 <andythenorth> removing lots of 'if foo == eggs: ham" stuff
19:32:16 <andythenorth> and replacing it with straightforward handler in subclass
19:34:15 <Alberth> isn't it lovely? so many ways to write the same thing, yet they are all slightly different :)
19:34:33 <Xaroth|Work> something with standards
19:35:05 <andythenorth> one and only one way :P
19:35:45 <Xaroth|Work> your render bit could use some OO love
19:37:31 <andythenorth> ¿ template = templates[(self.template)]
19:38:30 *** kais58|A1K has joined #openttd
19:39:26 <Xaroth|Work> also, I personally don't prefer the notation you use for your ships.. another method could be to make it a class that inherits stuff like GeneralCargoVessel
19:39:43 <andythenorth> which notation? o_O
19:39:43 <Eddi|zuHause> this should be a "standard" link :p
19:41:24 <andythenorth> so each ship is a class, instead of an instance of a class?
19:41:36 <Xaroth|Work> that way you can have similar boats inherit from eachother
19:42:23 <andythenorth> other than being easier to read, what is the gain?
19:42:47 <andythenorth> also fewer commas :P
19:43:14 <Xaroth|Work> and you can use properties, though I doubt you'll need those
19:43:22 <Alberth> class large_saint_marie_barge_tug(saint_marie_barge_tug): capacity_cargo_holds = 1000
19:43:53 <andythenorth> that use case is probably overengineering tbh
19:43:59 <andythenorth> but I can see why you don't like the notation
19:44:04 <andythenorth> it looks odd now
19:44:18 <Xaroth|Work> now it's a giant function call
19:44:30 <Xaroth|Work> and passing 23 args to a single function
19:45:01 <andythenorth> but the function is __init__ :P
19:45:04 <Xaroth|Work> you can apply mixins :)
19:45:34 <Xaroth|Work> apply specific rules for specific items
19:46:31 <Xaroth|Work> also, you can use tricks to register your ships in a central list/dict/whatever
19:48:24 <Xaroth|Work> every packet marked with @receive.packet or @send.packet
19:48:36 <Xaroth|Work> is added to send/receive's _packets dict
19:48:40 <Xaroth|Work> which is indexed by their packetID
19:48:47 <Xaroth|Work> i can then use send[packetID]
19:48:59 <Xaroth|Work> (or, even, send[packetClass])
19:50:06 <andythenorth> ok so how does the magic work? o_O
19:50:18 <andythenorth> we have a decorator?
19:50:26 <Xaroth|Work> everything can be a decorator
19:50:31 <Xaroth|Work> it's nothing more than a function being caleld
19:51:07 <Xaroth|Work> PacketRegistry's packet(packetID, [klass]) gets called
19:51:14 <Xaroth|Work> there's 3 ways you can accomplish that
19:51:41 <Xaroth|Work> the if magic there shows what to do in each case
19:51:54 <Xaroth|Work> in fact, there's even a small bug in that :P
19:52:50 <Xaroth|Work> i can call @send.packet(1) before it
19:52:54 <Xaroth|Work> @send.packet before it
19:53:03 <Xaroth|Work> or @send.packet() (which has the bug)
19:53:18 <Xaroth|Work> or even send.packet(1, AdminJoin)
19:54:54 *** bertieb has joined #openttd
19:55:33 <andythenorth> is this magic I should be using?
19:56:31 <andythenorth> I mean, would it improve FISH code? o_O
19:56:37 <andythenorth> and how do I do it?
19:58:50 <Xaroth|Work> it can replace Ship.register
20:00:06 <Xaroth|Work> also, get_X_speed can technically be replaced by properties
20:01:40 <Xaroth|Work> same with a few more get_*
20:02:44 *** TomyLobo2 has joined #openttd
20:03:14 *** Extrems1 has joined #openttd
20:03:45 *** MatrixCL2 has joined #openttd
20:03:51 *** andythenorth_ has joined #openttd
20:04:05 <Xaroth|Work> then again, you can use 0.8 if self.sea_capable else 1.0
20:04:10 <Xaroth|Work> instead of using a tuple
20:04:37 <andythenorth_> someone taught me that odd tuple method once
20:04:40 *** TrueBrain_ has joined #openttd
20:04:44 <andythenorth_> and it's stuck with me ever since
20:05:11 <Xaroth|Work> that explains much more what's happening
20:05:55 <andythenorth_> ach, I've just removed the function def entirely
20:06:05 <andythenorth_> don't know why I did it ;)
20:06:21 <andythenorth_> premature handling of unknown future case probly
20:06:38 *** andythenorth_ is now known as andythenorth
20:06:38 *** TomyLobo2 is now known as TomyLobo
20:08:03 <andythenorth> so if every ship gets its own class...
20:08:11 <Xaroth|Work> you can do magics :)
20:08:13 <andythenorth> where would I create an instance of that class?
20:08:35 <Xaroth|Work> well, in my case, my decorator does that for me
20:08:58 <Xaroth|Work> that way i introduce a tiny bit of extra magic in a decorator
20:09:12 <andythenorth> ok, so that makes sense
20:09:26 <Xaroth|Work> and don't have to add instantiation to every file
20:09:28 <andythenorth> I don't like ship = ClassName(Ship) args
20:09:29 *** wolfmitchell has joined #openttd
20:09:43 <andythenorth> or whatever it is I have
20:09:53 <andythenorth> ship = ClassName(args)
20:09:53 *** planetmaker has joined #openttd
20:09:54 *** ChanServ sets mode: +o planetmaker
20:10:28 <Xaroth|Work> also, since we're nitpicking
20:10:38 <Xaroth|Work> you have .ship and .ships.<stuff>
20:10:50 <Xaroth|Work> the base classes from .ship should really be with .ships
20:11:05 <Xaroth|Work> i tend to use .module.base for that
20:11:23 <andythenorth> dep for package should travel in package?
20:11:24 <Xaroth|Work> then i can use from .base import <base class>
20:11:54 <andythenorth> from .base import Belong
20:12:04 <Xaroth|Work> well it's not logical, if you want to change the base ships property you should be looking in the ships module
20:12:26 <Xaroth|Work> not somewhere between the rest of the stuff
20:14:34 <andythenorth> I suppose __base__ is all wrong?
20:14:51 <andythenorth> puts it at the top of my file browser hierarchy :P
20:14:55 <Xaroth|Work> underscore files are for pyhon builtin magic, usually
20:15:36 <andythenorth> I could just declare all the base stuff in the init for the module?
20:15:39 <andythenorth> I've done that before :P
20:15:48 <Xaroth|Work> also, not really relevant if you move to classes for ships, but your Ship.__init__ code can technically be reduced to 5-6-ish lines :)
20:15:57 <Xaroth|Work> for a simple reason
20:16:02 <Xaroth|Work> you want to import all your ships in __init__
20:16:27 <Xaroth|Work> 1) you can then do: from ships import *
20:16:47 <Xaroth|Work> 2) when you do that, -all- your ships get loaded, decorators get run,e tc
20:17:01 <Xaroth|Work> and when you add your base class in __ini__
20:17:11 <Xaroth|Work> you can't do from ships import baseclass
20:17:17 <Xaroth|Work> because that would lead to circular imports
20:17:33 <Xaroth|Work> (init wanting to load the ship, ship wanting to load init)
20:17:41 *** permagreen has joined #openttd
20:18:13 <Xaroth|Work> (also, it looks nicer: from ships import altamira_freighter vs from ships.altamira_freighter import altamira_freighter )
20:18:20 *** Progman has joined #openttd
20:18:58 <andythenorth> you prefer the second method?
20:19:08 <Xaroth|Work> I prefer from ships import altamira_freighter
20:19:36 <Xaroth|Work> in ships.__init__ i'd then have: from .altamira_freighter import altamira_freighter
20:19:39 <Xaroth|Work> ugly once, but still
20:19:44 *** zeknurn has joined #openttd
20:19:59 <andythenorth> I am unconvinced about making each ship its own class
20:20:02 <andythenorth> seems like a class too far
20:20:12 <andythenorth> I think they're instances
20:20:34 <Xaroth|Work> what if you want to have a ship that doesn't stick to inland/sea speeds ?
20:20:43 <Xaroth|Work> now your only 2 options are yes/no
20:20:49 <Xaroth|Work> if you have a class
20:20:52 <Xaroth|Work> you can overload the property
20:20:57 <Xaroth|Work> do your own magic just for that ship
20:21:04 <Alberth> make a new class for that type of ship
20:21:17 <andythenorth> cherry-picking use cases is hard :)
20:21:27 <andythenorth> that particular one is not a valid case
20:21:31 <andythenorth> as spec doesn't allow it
20:22:39 <Xaroth|Work> also, a -lot- of your ships have the same values for a fair few properties
20:31:52 <andythenorth> wtf were those extra () chars doing in render() function? :P
20:32:02 <andythenorth> template = templates[(self.template)]
20:32:46 <andythenorth> it used to be a more complicated statement
20:32:50 <andythenorth> I missed them when refactoring
20:34:27 <andythenorth> ok so I see how making each ship its own class reduces the __init__ in Ship
20:34:39 <andythenorth> and avoids passing around 1 bazillion args in **kwargs
20:35:06 <andythenorth> I'm not sure about magic for registration
20:35:13 <andythenorth> magic is *usually* bad
20:35:38 <Alberth> make a few base classes with sane defaults, and instantiate + modify them for a specific ship?
20:36:27 <Alberth> you can also have some code that computes some values at the end
20:36:59 <andythenorth> I'd have class -> subclass -> subclass -> instance
20:37:01 *** Prof_Frink has joined #openttd
20:37:06 <andythenorth> which seems overkill for 30 ships in a newgrf?
20:37:38 <andythenorth> duck tape (sic) seems appropriate for templating newgrfs?
20:38:23 <Alberth> extreme solutions are rarely the optimum
20:38:51 <andythenorth> this would be more sensible if I'd subclassed from day 0
20:39:11 <andythenorth> right now, I'm grafting subclasses in to sanitise a lot of messy if / else crap
20:39:49 <Alberth> that seems like a good reason
20:40:30 <Xaroth|Work> er, missed removing a line
20:40:33 <Alberth> and quite likely you'll end up at a different point due to the history, but that's fine, many solutions are good
20:40:58 <andythenorth> Xaroth|Work: I'd probably just remove all "foo = None" declarations
20:41:45 <andythenorth> I can see it's a kind of documentation this way :P
20:42:02 <Xaroth|Work> well, it's your base class now
20:42:04 <Xaroth|Work> so it should have it
20:42:10 <Xaroth|Work> unless it's ship-specific
20:42:37 <andythenorth> nah these are all generic props
20:43:13 <andythenorth> so the @property decorator just makes a method callable without ()?
20:43:47 <Xaroth|Work> property decorator :)
20:44:01 <Xaroth|Work> you can also do x = property(fget, fset, fdel, fdoc)
20:44:17 <Xaroth|Work> where fget/set/del/doc are the getter, setter, deleter and the func-doc
20:44:30 <Xaroth|Work> or you can do @property <func>
20:44:34 <Xaroth|Work> then @funcname.setter
20:44:57 <andythenorth> I can cut all the get_ crap as well
20:45:13 <andythenorth> just reminds me to call it when writing the templates
20:45:14 <Xaroth|Work> get_* with no params can usually be done in a property
20:46:12 <Xaroth|Work> if you set a class property to something
20:46:18 <Xaroth|Work> all class instances will have that by default
20:46:27 <Xaroth|Work> keep in mind with mutable objects, like list/tuple/dict
20:46:30 <andythenorth> yeah that much is obvious :)
20:46:40 <andythenorth> been there done that
20:46:46 <Xaroth|Work> it's like putting a list/tuple as a default arg for a function
20:46:52 <andythenorth> deep vs. shallow copy was a suprising lesson last year :P
20:53:49 <andythenorth> didn't answer my original question though ;)
20:54:03 <Xaroth|Work> too much spam in here :P
20:54:09 <andythenorth> should I add an additional subclass for ' ShipWithRefittableCapacity' ?
20:54:14 <andythenorth> which subclasses ship
20:54:22 <andythenorth> instead of having 'if foo' conditional crap
20:54:29 <Xaroth|Work> or a Refittable mixin?
20:54:35 <andythenorth> mixin is preferable
20:54:40 <andythenorth> I didn't know about mixins in python
20:54:48 <Xaroth|Work> Refittable applies to more than just ships
20:54:49 <andythenorth> only seen them in Less css etc
20:55:11 <Xaroth|Work> a mixin is, in essence, a class
20:56:27 <Xaroth|Work> inheritance goes right to left
20:56:39 <Xaroth|Work> bit odd, then again.. using spaces for code blocks is as well :P
20:56:51 <andythenorth> wouldn't have guessed right to left
20:56:55 <andythenorth> but it's correct imo
20:57:04 <andythenorth> once you understand scopes :P
20:57:19 <andythenorth> look in nearest scope first
21:01:34 <andythenorth> toddler has been playing in 'bubble land'
21:02:59 <andythenorth> that's exactly what I wanted
21:03:08 <andythenorth> not a horrible spaghetti nest of subclasses
21:04:12 <Alberth> I find them hard to understand what you have, at the end, but in your case I can imagine they are useful
21:04:28 <andythenorth> I do not want to think about calling super() with mixins :(
21:04:35 <andythenorth> too much baggage
21:05:44 <andythenorth> it just looks in the hierarchy for the method
21:05:49 <Alberth> the other option is to split your bag of variables in a number of smaller bags, make separate class/instances of them, then treat those objects as variables
21:06:05 <andythenorth> as per BANDIT graphics generator
21:06:09 <andythenorth> I like that method too
21:06:15 <andythenorth> overkill here I think :)
21:06:55 <Alberth> doing the same thing more than one time is boring :)
21:07:18 * Alberth is inventing a good way to write a state machine in C++ :)
21:08:10 <Alberth> except I have a lot of methods in each state :)
21:18:46 *** Ristovski has joined #openttd
21:20:01 <LordAro> Alberth: roller coasters?
21:20:49 <Alberth> or rather, the user interaction while building one
21:21:23 <Alberth> ie what happens when you click a button etc, just like the path build interaction
21:21:52 <Alberth> except I am not happy with that code, it's very hard to read
21:24:13 *** DarkAce-Z is now known as DarkAceZ
21:25:37 <Xaroth|Work> using super() too much can be avoided though
21:30:02 <Eddi|zuHause> at one time i had existing classes bac, baf, bar and baz, and made a "def foo()" followed by bac.foo=foo, bar.foo=foo etc.
21:35:08 <Alberth> looks like the C code I converted to classes :)
21:38:08 *** andythenorth has left #openttd
22:04:43 *** tokai|noir has joined #openttd
22:04:43 *** ChanServ sets mode: +v tokai|noir
22:36:14 *** TrueBrain_ is now known as TrueBrain
23:16:08 *** Superuser has joined #openttd
23:30:17 *** Midnightmyth has joined #openttd
23:51:37 *** DarkAceZ has joined #openttd
continue to next day ⏵
