IRC logs for #openttd on OFTC at 2015-07-03
⏴ go to previous day
00:02:44 <Eddi|zuHause> <andythenorth> is it weird to build tram networks, then be forced to rebuild to roads? <- yes. (but you probably won't read the log)
00:32:20 *** Teskham_ has joined #openttd
00:33:02 *** Teskham_ has joined #openttd
00:33:51 <Teskham_> Hate to jump in here for tech support but does anyone known how to allocate more memory to 1.5.1 on osx?
00:40:08 *** Hiddenfunstuff has quit IRC
01:25:50 *** Biolunar has joined #openttd
01:47:31 *** ChanServ sets mode: +v tokai
03:52:38 *** supermop has joined #openttd
04:28:03 *** Biolunar_ has joined #openttd
06:56:16 *** Eddi|zuHause has joined #openttd
07:39:51 *** KenjiE20 has joined #openttd
08:37:42 *** Flygon_ has joined #openttd
08:44:38 *** zeknurn has joined #openttd
08:50:00 *** Flygon__ has joined #openttd
09:19:48 *** Celestar has joined #openttd
09:44:25 *** JacobD88 has joined #openttd
09:51:17 *** roidal_ has joined #openttd
10:22:16 *** Supercheese has joined #openttd
10:57:56 *** Flygon__ has joined #openttd
11:01:12 *** Hiddenfunstuff has joined #openttd
11:03:05 *** JacobD88 has joined #openttd
11:18:47 *** urdh is now known as Guest3824
11:45:50 *** fjb_mobile has joined #openttd
12:12:49 *** Flygon__ has joined #openttd
12:15:37 *** SkeedR is now known as Guest3839
13:13:29 *** sla_ro|master has joined #openttd
13:31:39 *** fjb_mobile is now known as Guest3842
13:31:40 *** fjb_mobile has joined #openttd
13:31:53 *** Supercheese has joined #openttd
13:33:10 *** fjb_mobile has joined #openttd
13:54:34 *** jottyfan has joined #openttd
14:05:20 *** meaneye has joined #openttd
14:05:42 <meaneye> Hey folks. I am having this issue on Linux where cursor is hidden while am moving it.
14:06:27 <meaneye> Anyone knows if there is a way to make OpenTTD fullscreen only on one display?
14:13:33 *** andythenorth has joined #openttd
14:13:38 <andythenorth> I have worked it out
14:13:47 <andythenorth> Baldy’s Boss is a relatively advanced lingua bot
14:13:54 <andythenorth> with a very specific focus
14:13:55 <planetmaker> that depends really on your setup, meaneye... on how you configured your system to use the two monitors
14:14:16 <planetmaker> write a counter-bot :)
14:14:37 <planetmaker> meaneye, e.g. on my system 'full screen' only covers one monitor
14:15:32 <planetmaker> thus it's more a config issue with your graphics card (driver) on how full screen is handled
14:16:24 <planetmaker> I can't look-up my config right now... fedora20 default setup, tho
15:24:27 *** shirish has joined #openttd
15:32:15 *** andythenorth has joined #openttd
15:46:28 <argoneus> do you guys use design patterns?
15:46:33 <argoneus> or do you just write whatever makes sense
15:47:22 * planetmaker sometimes designes patterns :P
15:47:42 *** frosch123 has joined #openttd
15:56:13 <frosch123> taking a short break before fighting the massive photon attack again
15:56:21 *** Alberth has joined #openttd
15:56:21 *** ChanServ sets mode: +o Alberth
15:56:40 <V453000> I am taking a massive break instead :P
15:57:09 <Alberth> yeah, me too, work doesn't cooperate today
15:57:37 * andythenorth is disgusted by European productivity
15:57:41 <andythenorth> I am here working hard
15:57:57 <Alberth> no worries, I will too, I am sure
15:59:05 <SpComb> we're more productive because we're less productive
15:59:21 * andythenorth might produce ice cream
15:59:37 <andythenorth> what do we think about trams?
16:00:34 <andythenorth> frosch hates trams :(
16:01:41 <Alberth> he's having a summer sleep, which is not such a bad idea
16:08:47 <Eddi|zuHause> <argoneus> do you guys use design patterns? <- you don't "use" design patterns. patterns are things that just show up, because they are the logical consequence of some stuff
16:09:03 <argoneus> Eddi|zuHause: yeah but you should be able to recognize common solutions to common problems
16:09:30 <argoneus> like I wanted to write a simple IRC bot, but all code ended up being in 1 class and I don't know how to split it up properly
16:09:32 <Eddi|zuHause> you get better at spotting patterns by spotting more patterns
16:09:46 <argoneus> and I don't know how to find out how to split it properly
16:09:55 <argoneus> it seems that everything relies on everything else
16:10:10 <Eddi|zuHause> that does sound like an antipattern :p
16:10:25 <argoneus> when I look at sources of existing irc bots
16:10:36 <argoneus> they have classes for everything, commandhandlers, eventhandlers, connectionfactories, etc.
16:10:49 <argoneus> it's maybe needlessly overengineered but it's flexible and the responsibilities are clearly split
16:10:56 <argoneus> but I don't know how to get on that level
16:11:07 <Alberth> why would you want to?
16:11:08 <Eddi|zuHause> by taking one (refactoring) step at a time
16:11:27 <argoneus> Alberth: it lets you add new things without killing yourself
16:11:34 <argoneus> and change existing things
16:11:46 <argoneus> if designed correctly that is
16:11:56 <Alberth> you cannot prepare for all possible extensions
16:11:57 <argoneus> it's better than a super powerful 1 class
16:12:24 <Alberth> so no matter what overengineered thing you have, there are always points that you cannot extend easily
16:12:46 <argoneus> how do I learn how to engineer things :(
16:12:55 <Eddi|zuHause> argoneus: the point is: you cannot ever "design" from the first go. you may have a rough structure in mind from when you started, but with every expansion, that structure gets more and more whithered down
16:13:00 <argoneus> experimenting doesn't seem to help, even if I recognize shitcode, I don't know what to do about it
16:13:02 <Alberth> extend it in some way
16:13:09 <Eddi|zuHause> argoneus: the trick is to review the structure and refactor as you go along
16:13:15 <argoneus> and reading books with generic diagrams isn't helping either
16:13:34 <argoneus> Eddi|zuHause: so I write that one superclass and then figure out how to split it?
16:13:39 <argoneus> instead of starting out with 10 different classes
16:14:07 <argoneus> so the idea is to first prototype something that works
16:14:12 <argoneus> and then make it not only work but also be manageable
16:14:26 <Alberth> since in the general case, your extension is not going to fit in what you have
16:14:34 <Eddi|zuHause> argoneus: of course, the earlier you notice that you are going to have to split, the easier it is to do
16:14:36 <Alberth> so you need to rework the code
16:14:43 <argoneus> I still don't know what refactoring really is though
16:14:47 <argoneus> for me it's just renaming variables
16:14:52 <argoneus> I never used anything else
16:15:05 <Alberth> any form of changing the code without functional changes
16:15:17 <argoneus> so it's not a specific process
16:15:21 <Eddi|zuHause> argoneus: "refactoring" is turning a*c+b*c into (a+b)*c
16:15:35 <argoneus> there are no steps to refactoring
16:15:39 <argoneus> I just look at my code and make it not shit
16:15:55 <Eddi|zuHause> you try to express the same functionality with less shit code
16:16:24 <Alberth> there are steps, in the official book: 1) make tests 2) run tests to verify correctness 3) make change (small steps is better) 4) run tests again
16:16:56 <Alberth> ie tests are used to ensure you don't miss edge cases
16:16:58 <argoneus> this magical thing called unit tests
16:17:01 <argoneus> that I never figured out how to use either
16:17:16 <Alberth> most test-ideas are also over-engineered, imho
16:17:28 <Eddi|zuHause> argoneus: as for how to split "one superclass", the first step may be to DUPLICATE the superclass
16:17:33 <peter1138> Unit test your unit tests.
16:17:51 <Eddi|zuHause> argoneus: then you can chop away at the second class to make it less super
16:17:52 <Alberth> we have arrived at the point where it becomes useful to skip some tests
16:19:00 <argoneus> I don't even know what tests are really supposed to test
16:19:03 <Eddi|zuHause> argoneus: and once that was successful, chop away at the first class by the functions that are now done by the second class
16:19:15 <argoneus> like I have a class that does something weird
16:19:28 <argoneus> and then I write a use case that tries to do something weird using the class, and I make sure the results are what I want
16:19:47 <Alberth> test are intended to check the outcome of a function is according to the requirement
16:20:07 <argoneus> for example in the specific case of an irc bot/client
16:20:18 <argoneus> I have a class that connects to freenode and sends NICK, USER, etc
16:20:24 <argoneus> how the hell am I supposed to test something like that
16:20:25 <Alberth> tomorrow you change the code, run the test, and have verification you didn't mess up
16:21:01 <Alberth> yeah, that's where testing becomes more pain than use, imho :)
16:21:17 <Alberth> but opinions differ on that, greatly :)
16:21:38 <Alberth> you can connect to a dummy node, for example
16:22:03 <Alberth> or take out the network part, and just check you do "send" call with the right values
16:22:34 <Eddi|zuHause> simulate a receiving end, and compare the received string with a sample
16:22:35 <argoneus> that seems kinda meaningless though :(
16:22:52 <argoneus> but that takes longer to write than the connection part
16:23:00 <argoneus> and probably won't break out of nowhere
16:23:26 <Alberth> depending on how religious you are about tests, opinions vary :p
16:24:42 <argoneus> I never saw myself thinking
16:24:57 <argoneus> "It wuld be great if I had an NetworkSocketConnectionFactory in here"
16:25:47 <Alberth> well, you do have one, it's just not named that way
16:26:26 *** JacobD88 has joined #openttd
16:26:49 <Eddi|zuHause> argoneus: most of the patterns are trivial and obvious
16:26:52 <Alberth> but if you have one, you can replace it with a different implementation, eg for testing, or connecting to a different network
16:27:20 <Alberth> patterns are also a religion :)
16:27:34 <Eddi|zuHause> argoneus: that is because no theoretical computer scientist ever sat down and said "hm, let me design some pattern". instead people reviewed real world code and checked out how people commonly solve problems
16:28:09 <Alberth> patterns are only useful to talk about how you solved something
16:28:34 <Alberth> you don't sit down and make a design as a set of patterns
16:29:14 <Eddi|zuHause> most of the time you use a pattern without realizing that it is a pattern
16:47:32 <andythenorth> you are doing patterns wrong
16:47:45 <andythenorth> the correct way is to make a bingo card of patterns
16:47:54 <andythenorth> and then make sure you use at least one of each in your design
16:48:06 <argoneus> if I get a bingo do I get a certificate
16:48:31 <andythenorth> certified devloloper
16:48:46 <andythenorth> also you can call it enterprise architecture
16:48:51 *** ChanServ sets mode: +v tokai
16:49:10 * andythenorth not trolling now
16:49:27 *** fjb_mobile has joined #openttd
16:49:38 <andythenorth> integration tests get you the most return on time spent
16:50:00 <andythenorth> "with respect to”
16:50:14 <andythenorth> integration tests are automating testing of the app that you (or someone) would otherwise spend time doing manually
16:53:00 *** ChanServ sets mode: +v tokai
16:53:16 <andythenorth> what kind of app is it?
16:54:42 <andythenorth> how is it controlled?
16:55:00 <argoneus> basically I'm not sure how to split responsibilities into classes (so I have 1 superclass) and I don't know how to test it
16:55:05 <argoneus> with commands I Guess
16:55:10 <andythenorth> what’s the user interface
16:55:27 <argoneus> it's a bot not a client
16:55:32 <argoneus> it only reacts to in channel commands
16:55:45 <Alberth> you don't start the program, it has no options, settings, etc
16:56:15 <argoneus> there's a config file
16:56:17 <Alberth> that's also user interface
16:56:49 <argoneus> IRCBot, BotConfig, and IRCConnection
16:56:58 <argoneus> IRCBot loads BotConfig and starts IRCConnection
16:57:03 <argoneus> and IRCConnection kinda... does everything
16:57:07 <argoneus> including parsing commands etc
16:57:11 <argoneus> because I don't know how to split it
16:57:17 <argoneus> without making it into a larger mess than before
16:57:40 <Alberth> read a line, parse into stuff you recognize, decide how to react, write output
16:58:30 <argoneus> like, I wanted to write something like an onMessage event, that lets people listen to it and react
16:58:33 <argoneus> but I didn't figure out how
17:01:33 <argoneus> I wanted to make some sort of MessageParser, but when I tried to split the message from my while recv loop and send it to the parser, it became a mess
17:02:05 <Alberth> sounds like a refactoring puzzle :)
17:02:09 <argoneus> because suddenly I had to pass an instance of MessageParser to IRCConnection, but the connection itself shouldn't care about parsing messages
17:02:33 <argoneus> and then I probably want to make the messages observable and have pluggable observers, but I didn't figure out how to make that either
17:02:41 <argoneus> so now I have a bot that works but whenever I want to add something it's a pain
17:03:05 <Alberth> did you try starting from the other end?
17:03:23 <argoneus> you mean writing use cases and then implementing them?
17:03:46 <Alberth> make a sort-of scheme how things should hook up with a new version?
17:03:55 <Alberth> nah, use cases are too low level
17:04:02 <argoneus> so like a UML diagram?
17:04:23 <Alberth> just rectangles and lines on a piece of paper
17:04:30 <argoneus> I didn't try that :<
17:04:39 <argoneus> but that's mostly because
17:04:43 <Alberth> with little blocks of functionality
17:04:46 <argoneus> I didn't know what I would want before I started writing the rough prototype
17:04:56 <andythenorth> I am not a programmer
17:05:00 <argoneus> I was just like okay I'll write the basic connection code now and worry about other things later
17:05:08 <argoneus> but then I ended up with the connection code being the whole bot
17:05:09 <Alberth> that's why you write a prototype
17:05:15 *** Hiddenfunstuff has quit IRC
17:05:24 <andythenorth> but I always work out the top-level (primary, first class) and secondary entities
17:05:34 <andythenorth> and they tend to form classes
17:05:42 <argoneus> Alberth: so to speak frankly
17:05:48 <argoneus> I'm supposed to break my nose first and then write it again but better?
17:05:50 <Alberth> so it has served its function, 'throw' it away
17:06:01 <andythenorth> Write One To Throw Away
17:06:09 * andythenorth would suggest the C2 wiki, but that’s your afternoon gone
17:06:13 <Alberth> you cannot design what you don't understand what you want
17:06:33 <argoneus> so basically what Eddi|zuHause said
17:06:37 <argoneus> now I have a working superclass
17:06:45 <argoneus> and now I want to refactor it and figure out how to split stuff?
17:07:03 <Alberth> that still assumes you know where you should go
17:07:18 <Alberth> refactoring in itself gives you no direction
17:07:38 <Alberth> it's just a process to do it nicely without ending up with a 1000 pieces
17:08:02 <Alberth> you need to decide where you want to end up first
17:08:21 <argoneus> so drawing diagrams is a good idea?
17:08:26 <Alberth> and then there are several options to go there
17:08:36 <andythenorth> if your mind responds to diagrams, diagrams are a good idea
17:08:51 <Alberth> whatever works for you, different people have different ways of structuring their thoughts
17:08:54 <andythenorth> some people seem to be able to fully-form architectures in their heads
17:08:58 <andythenorth> some people like bullet points
17:09:12 <argoneus> I should put my thoughts on paper
17:09:13 * andythenorth draws boxes for entities, then hangs properties off them with lines
17:09:32 <andythenorth> I don’t write things like irc bots very often, but it strikes me as a pipeline
17:09:35 <Alberth> you need to get a clear idea of the structure of the thing you want to make
17:09:37 <andythenorth> pipelines tend to have a flow
17:09:43 <andythenorth> and processing modules
17:09:49 <andythenorth> pixa is pipelined :P
17:09:51 <Eddi|zuHause> argoneus: writing stuff down is certainly something that could help you
17:09:53 <Alberth> it doesn't need to be on paper, unless that works for you
17:10:12 <Eddi|zuHause> argoneus: either write down the state you have currently, or better the state that you want to have in the future
17:10:26 <Eddi|zuHause> argoneus: and then figure out steps how to get to that state
17:10:34 <argoneus> so I just imagine the life of my program
17:10:34 <andythenorth> pipelines often have a parse component to handle initial input, then n processing components, then some kind of final output component
17:10:47 <argoneus> which is connect, get messages, parse them, respond to them, disconnect
17:10:54 <argoneus> and then I try to somehow scheme out how my program will do those
17:10:59 <argoneus> and try to do it properly
17:11:01 <andythenorth> ok so you have a messages entitity
17:11:03 <Alberth> public final OutputComponent = new OutputComponent();
17:11:08 <Eddi|zuHause> that sounds like a plan
17:11:34 <andythenorth> and you might have a response entity, or response is just a type of transformed message
17:11:38 <andythenorth> you have to decide :)
17:12:02 <Eddi|zuHause> argoneus: opposite to OO fundamentalists, not all of these steps need to be in classes
17:12:34 <argoneus> the point of OO is to throw away performance but get flexibility, no?
17:12:48 <argoneus> who am I kidding, the point is to be able to get a customer on your side to buy your shit
17:13:04 <Alberth> yes, but taking it beyond the sweet point it works against you
17:13:24 <Alberth> as with every technology
17:13:39 <argoneus> I envy funcprog people
17:13:39 <andythenorth> the point of OO is to sell books
17:13:45 <argoneus> they just tell it "make an irc bot" and it works
17:13:46 <andythenorth> the point of funcprog is to sell books
17:14:01 <Alberth> argoneus: believe me, funcprog is not ideal too :)
17:15:01 * andythenorth misses BBC Basic
17:15:15 <andythenorth> 10 print “hello andy”
17:15:34 <andythenorth> we used 10 and 20 because you would inevitably need to add 11, 12, 15 and 18
17:15:48 * andythenorth has just realised how this distorts my entire approach to programming :O
17:16:50 <argoneus> but when you wanted to make 11
17:16:53 <Alberth> dijkstra wasn't that wrong :p
17:16:59 <argoneus> wouldn't it be better to make it 20 instead, and move the next ones up by 10
17:17:18 <andythenorth> by typing your entire program again? :o
17:17:42 <andythenorth> oh there was renumber
17:17:42 <Alberth> I had the BASIC editor by Acorn which was really great here
17:18:08 <argoneus> I heard an anecdote from the punched card era
17:18:15 <argoneus> that you made the holes
17:18:18 <argoneus> brought it to the lab
17:18:23 <argoneus> and they compiled it until the next day and gave you results
17:18:35 <argoneus> not sure how real that is but sounds like a pain
17:18:58 <Alberth> never actually did it, but I'd sure like to try that once
17:19:04 <andythenorth> not vastly different to doing, e.g. commercial printing
17:19:12 <andythenorth> where you send proofs off on disk
17:19:16 <andythenorth> and get the results
17:19:32 <andythenorth> and realise that the CMYK layers have too much bleed or whatever
17:23:16 <andythenorth> or even just a slow test run on jenkins :(
17:23:30 <andythenorth> if your test suite runs overnight, you don’t know if you can ship until the next day
17:23:36 <andythenorth> and if you failed, you go round again
17:23:52 *** fjb_mobile has joined #openttd
17:24:14 <argoneus> even if I scheme out my program
17:24:18 <argoneus> I don't know how to scheme out tests :(
17:24:33 <argoneus> do I basically want to make sure every class gives right output given an arbitrary input?
17:24:43 <argoneus> and that every class is self contained to a degree
17:24:47 <Eddi|zuHause> my computer science professor said that we should all learn programming the punchcard way, where the feedback only comes a day later, so you have to focus more on getting it right the first time
17:25:03 <Alberth> classes do not give output
17:25:41 <Alberth> basically you want to make sure they do what you think they should do, in particular in corner cases
17:26:13 <Alberth> empty lines, long lines, single word lines, etc
17:26:47 <Eddi|zuHause> argoneus: whether you allow arbitrary input and do sanity checking in the class, or whether you require sanity in the first place (and do the sanity checking in some earlier step), is part of the class contract
17:27:09 <Eddi|zuHause> argoneus: particularly with user input, it's better to make more sanity checking
17:28:31 <argoneus> so for example a MessageParser class that takes messages from irc and parses them doesn't really need testing
17:28:42 <argoneus> because the messages irc servers send you are always the same format?
17:28:56 <Alberth> what does "parses" mean?
17:29:14 <Eddi|zuHause> when you know the format, testing gets easier
17:29:16 <argoneus> like figures out if it's ctcp, of a pm, or a channel message, then splits it into parts and spits it out
17:29:20 <andythenorth> presumably splits them for command keywords and such?
17:29:33 <Alberth> ok, so how do you know it works?
17:29:39 <andythenorth> and possibly cleans input for possible attacks
17:29:45 * andythenorth doesn’t know how to attack an irc bot
17:29:53 <argoneus> andythenorth: from my experience
17:30:02 <argoneus> you can crash many irc bots by sending random bytes to a channel
17:30:03 <Eddi|zuHause> argoneus: the point of a test suite is to test it every time you made a change
17:30:08 <argoneus> because they try to force it into utf8
17:30:08 <andythenorth> run it on a disposable VM with no external connections :P
17:30:35 <argoneus> but what client lets you send bytes into a channel, right
17:30:40 <Alberth> argoneus: you make a change elsewhere, how do you know the parser still works?
17:30:59 <argoneus> Alberth: well, it gets messages from the irc server
17:31:03 <argoneus> so it's not my fault if it breaks
17:31:14 <argoneus> testing networked things is tricky :<
17:31:24 <Alberth> you don't have code that gives stuff to the parser?
17:31:35 <argoneus> I don't have any code yet >_>
17:31:50 <Alberth> you will not have code that gives stuff to the parser?
17:32:33 <argoneus> but it will probably be a direct pipe from socket
17:32:52 <Alberth> so why do you think the parser will only get data in the right format?
17:33:08 <Alberth> you may mess up somewhere without realizing
17:33:21 <Eddi|zuHause> argoneus: that is how security vulnerabilities are made
17:33:45 <argoneus> so I want to write a test
17:33:48 <argoneus> that parses a proper message
17:33:51 <argoneus> and a test that parses gibberish
17:33:53 <argoneus> and they both should pass?
17:34:06 <argoneus> now to figure out how ._.
17:34:10 <andythenorth> there are still industry debates on test methodologies
17:34:11 <argoneus> I should look up existing examples
17:34:12 <Alberth> and probably more than 2 :)
17:34:19 <andythenorth> but I would focus on tests that fail
17:34:22 <argoneus> I'm still not sure if I want to test the class as a whole
17:34:25 <argoneus> or test method by method
17:34:35 <andythenorth> green lights are actually not information
17:34:39 <andythenorth> red lights are information
17:35:00 <argoneus> so my test does something like
17:35:05 <Alberth> andythenorth: yep, trying to convince my co-worker of that, but it's not quite working
17:35:06 <argoneus> instantiate the class I want to test
17:35:13 <argoneus> feed it arbitrary info
17:35:15 <argoneus> and assert various methods?
17:35:16 <andythenorth> Alberth: I have seen some really dumb shit in tests
17:35:38 <Alberth> you feed it known data, and thus know how it should react
17:36:02 <andythenorth> setattr(foo, ‘bar’, 1)
17:36:08 <andythenorth> asset(foo.bar == 1)
17:36:16 <andythenorth> wtf is the point in that :)
17:36:18 <Eddi|zuHause> argoneus: basically you want to check for whether the result of each method is the same as in the previous run
17:37:04 <argoneus> but then if I make a change to the class
17:37:07 <argoneus> I need to change the tests too
17:37:20 <andythenorth> ideally you want to run it without changing the tests
17:37:27 <andythenorth> and check that the expected tests fail
17:37:35 <andythenorth> then change the tests
17:37:45 <argoneus> really makes me feel like I should sketch things out and consult someone experienced what he thinks
17:37:47 <Alberth> argoneus: only if the functionality of the method changes, if all is correct
17:37:49 <Eddi|zuHause> argoneus: but if you make non-functional changes like refactoring, you want to keep the test the same
17:37:51 <argoneus> at least until I get a feel for it
17:38:02 <andythenorth> jumping into test-driven development is a big step
17:38:12 <andythenorth> you have to know how to have a test-runner framework
17:38:20 <andythenorth> and how to break up classes for tests and all that
17:38:28 <Eddi|zuHause> argoneus: or if you extend the functionality by a different command, then you want the tests for the existing commands to not change
17:38:31 <andythenorth> it’s like climbing a wall imo
17:38:48 * andythenorth would figure out what manual testing you’re going to do
17:39:02 <andythenorth> do it once, then use scripting or gui automation app to write yourself some tests
17:39:09 <andythenorth> then find your common mistakes and failure points
17:39:18 <andythenorth> and write simple guards against them directly into your code
17:39:36 <andythenorth> testing at the unit level is boatloads of work for possibly limited result
17:40:48 <andythenorth> (automating your repetitive manual testing is one thing; writing guards in your code is another thing, totally unrelated) :)
17:41:50 <planetmaker> asserts are a good invention :)
17:41:50 <Eddi|zuHause> andythenorth: guards in your code is for when the real world is more complicated than your tests could predict
17:42:08 <Eddi|zuHause> which is more common than you would think :p
17:46:08 <andythenorth> I have written guards for dumb stuff like “andythenorth has assigned duplicate IDs to vehicles"
17:46:19 <andythenorth> which nmlc will find, but my guard finds it in 5s, not 1 min :P
17:46:32 <andythenorth> Alberth: do we have tests for eints? o_O
17:47:35 <Alberth> unless you wrote them
17:48:17 <planetmaker> it probably would be suitable for some tests... but then... there's a big test running anyway 24/7 :P
17:49:45 <Alberth> we do have 66 asserts
17:50:20 <Eddi|zuHause> andythenorth: i have a check like that as well
17:50:55 <Alberth> planetmaker: I think it's mostly idling :)
17:50:55 <Eddi|zuHause> andythenorth: and also a check that says "you left some IDs empty"
17:51:03 <Eddi|zuHause> andythenorth: but that is not an error, just a hint
17:51:20 <Alberth> nah, one should use all IDs :p
17:52:15 *** TheMask96 has joined #openttd
17:54:29 <andythenorth> so I thought for Road Hog: freight trams until 1920s -> trucks after that
17:54:40 <andythenorth> but that’s only because Realism
17:54:52 <andythenorth> and it’s boring being forced to rebuild route types
17:55:07 * andythenorth thinks maybe trams -> always
17:55:10 <andythenorth> trucks -> always
17:55:34 <andythenorth> realism can whistle
17:55:43 <planetmaker> for exactly the reason you said: boring to be forced to rebuild
17:55:59 <planetmaker> realism people can still play it realistically. No need to use every vehicle
17:57:15 <Eddi|zuHause> andythenorth: it's like omiting a wagon for livestock
17:57:41 <andythenorth> also they can use ‘hide'
17:58:01 <andythenorth> also I can differentiate between the two types
17:58:02 <Eddi|zuHause> also, freight trams existed way later than 1920s
17:58:09 <andythenorth> not in Realistic Britain
17:58:16 * andythenorth does Unrealistic Britain
17:58:33 <andythenorth> this way, trams don’t have to progress nicely to trucks
17:59:25 * andythenorth should have thought of this ages ago
17:59:32 <andythenorth> it’s obvious in retrospect :(
17:59:38 <andythenorth> and it’s how Iron Horse does it
18:00:10 <Alberth> good ideas always happen after you have exhausted all the less-good ideas
18:01:36 <andythenorth> if we had roadtypes...
18:01:50 <andythenorth> we could repeat this discussion for each type :P
18:06:47 <argoneus> I wonder if it's bad that #openttd became #programminghelp to me
18:07:45 <Alberth> argoneus: as long as you don't mind people talking off-topic about some weird old game, every now and then :)
18:09:17 <argoneus> I wouldn't be here if it weren't for that game
18:45:08 *** ChanServ sets mode: +v tokai
19:42:54 *** Progman has joined #openttd
20:19:57 *** andythenorth has joined #openttd
20:21:19 <andythenorth> so narrow gauge trains are slow and low power, but cheap for track and vehicle costs (buy and run)
20:21:31 <andythenorth> metro trains are slow, but insanely high capacity, and accelerate fast
20:21:49 <andythenorth> electric trains are high power and expensive
20:21:58 <andythenorth> all relative to ‘normal’ trains
20:22:06 <andythenorth> so how do trams and RVs differ?
20:22:25 *** JacobD88 has joined #openttd
20:26:06 <Alberth> or being cheaper, I guess
20:26:34 <Alberth> although I rarely care about costs, as long as the sum is not negative
20:36:32 <andythenorth> for RVs and trams, the costs are probably a narrow range anyway
20:36:48 <andythenorth> speed, capacity, power are the interesting dimensions I guess
20:37:09 <andythenorth> also sensitivity to slopes (TE)
20:40:23 <Alberth> high capacity and fast acceleration sounds expensive to me
20:49:18 *** fjb_mobile is now known as Guest3872
20:49:19 *** fjb_mobile has joined #openttd
20:58:13 *** smoke_fumus has joined #openttd
21:03:11 *** fjb_mobile has joined #openttd
21:20:14 *** fjb_mobile is now known as Guest3876
21:20:15 *** fjb_mobile has joined #openttd
21:23:56 *** tokai|mdlx has joined #openttd
21:30:08 <Eddi|zuHause> andythenorth: trams are higher capacity
21:31:53 <andythenorth> so the trucks are 30-40t depending on generation
21:31:58 <andythenorth> which I have tested in game and is good
21:32:07 <andythenorth> trams - 80t, or 120t?
21:32:25 <andythenorth> seems a bit high actually
21:33:17 <Eddi|zuHause> 80-120 sounds good, actually
21:33:32 <andythenorth> means they need quite high HP
21:33:35 <andythenorth> to reach a decent speed
21:34:04 <Eddi|zuHause> speed should be low, 20-60km/h
21:34:33 <Eddi|zuHause> meaning trucks will always outperform trams in speed
21:34:52 <andythenorth> I’m balancing against I
21:35:02 <andythenorth> ...IH narrow gauge
21:35:08 <andythenorth> which is 40-55mph
21:35:12 <Eddi|zuHause> no idea how that works
21:35:38 <andythenorth> be weird to have trams that outperform the trains
21:42:39 *** Riestat2 has joined #openttd
21:44:00 <Riestat2> hey guys anyone have any info on why the auto generated letters that are manditory for joining this site are not working? Keep receiving an error message :(
21:44:51 *** jottyfan has joined #openttd
21:48:12 <blathijs> Riestat2: Seems like they worked now? I'm assuming you mean the blurry image you have to type in to access the webchat? :-)
22:11:37 *** supermop has joined #openttd
22:45:48 *** Defaultti has joined #openttd
22:51:25 *** andythenorth has left #openttd
23:49:43 *** JacobD88 has joined #openttd
23:55:26 *** Progman has joined #openttd
continue to next day ⏵