Log for #openttd on 28th May 2017:
Times are UTC Toggle Colours
00:13:49  *** Wolf01 has quit IRC
00:14:59  *** Snail has joined #openttd
00:45:39  *** HerzogDeXtEr has joined #openttd
00:51:01  *** HerzogDeXtEr1 has quit IRC
01:04:10  *** glx has quit IRC
02:00:07  *** HerzogDeXtEr has quit IRC
02:01:48  *** APTX has quit IRC
02:01:50  *** APTX has joined #openttd
03:02:18  *** Snail has quit IRC
04:22:30  *** sim-al2 has quit IRC
04:26:00  *** techmagus has quit IRC
04:27:46  *** techmagus has joined #openttd
05:28:34  *** Alberth has joined #openttd
05:28:34  *** ChanServ sets mode: +o Alberth
05:28:40  <Alberth> hi hi
05:46:06  *** cosmobird has joined #openttd
05:52:55  *** sla_ro|master has joined #openttd
06:03:07  *** Progman has joined #openttd
06:13:03  *** cHawk has joined #openttd
06:20:45  *** cosmobird_ has joined #openttd
06:21:39  *** cHawk has quit IRC
06:27:03  *** cosmobird has quit IRC
07:24:22  *** cHawk has joined #openttd
07:45:58  *** cHawk has quit IRC
07:49:33  *** tokai|noir has joined #openttd
07:49:33  *** ChanServ sets mode: +v tokai|noir
07:56:20  *** tokai has quit IRC
08:46:21  *** gelignite has joined #openttd
08:47:40  *** Wolf01 has joined #openttd
08:48:57  <Wolf01> o/
08:51:43  *** Hiddenfunstuff has joined #openttd
09:04:00  <Alberth> o/
09:13:45  *** cosmobird__ has joined #openttd
09:20:03  *** cosmobird_ has quit IRC
09:34:26  *** FR^2 has left #openttd
09:38:09  <Wolf01> newships... (still not sure how it could prevent sea sickness, as I'm having it just for looking at the gif)
09:46:41  <Alberth> less movement you didn't create I guess, but yeah "prevent" seems a bit strong
09:48:08  <Wolf01> It only weakens the impacts, the problem with motion sickness is the motion :P
09:49:05  <Alberth> I know :)
09:50:26  <Alberth> but going just straight, instead of up+down+straight does help, in my experience
09:52:10  <Wolf01> My problem is the lateral bobbing
09:53:02  <Alberth> yep, the correct term is "avoid" or "reduce" sickness, rather than "prevent"
09:55:38  <Alberth> looking at it from outside may give a wrong impression though, everything seems to move, perhaps not in the last place since the camera may not be steady either
09:56:32  <Alberth> but if things perfectly counter-acts each other, the result if you sit inside is much better than it looks
09:57:05  <Wolf01> Yeah, still not enough to let me ride it XD
09:58:26  <Alberth> pick a nice quiet day :)
09:59:49  <Alberth> these guys picked a "bad" day, otherwise it's hard to sell :p
10:12:16  *** Wormnest has joined #openttd
10:19:07  <Eddi|zuHause> "as I'm having it just for looking at the gif" <-- you can't compare that... sea sickness comes from when your brain detects mismatching movement by your eyes and your ears (balance)
10:19:30  <Eddi|zuHause> however, your ears don't detect any movement while you're watching on screen
10:24:27  <Wolf01> Ehm, ears don't, but eyes do, so there's a sensorial mismatch
10:27:33  <Eddi|zuHause> exactly, but that won't be the same mismatch as when you're actually on that boat
10:59:43  *** HerzogDeXtEr has joined #openttd
11:48:18  *** sim-al2 has joined #openttd
12:54:04  *** sla_ro|master has quit IRC
13:10:01  *** Snail has joined #openttd
13:32:11  *** Eddi|zuHause has quit IRC
13:34:41  *** Eddi|zuHause has joined #openttd
13:56:21  *** sim-al2 has quit IRC
14:03:38  *** Snail has quit IRC
14:04:23  *** FLHerne has joined #openttd
14:04:42  *** sla_ro|master has joined #openttd
14:06:45  *** chomwitt3 has quit IRC
14:20:33  <supermop_home> Alberth: I switched my switch to return (117*switch_cost/100)
14:21:19  <supermop_home> but now I get the error 'binary operator requires both operands to be integers or floats'
14:21:45  <supermop_home> so I guess there is no way to do math of the result of a different switch?
14:28:22  <Alberth> I am pretty much useless as oracle for NML :)
14:28:44  <supermop_home> haha sorry, just asked you because we were talking about it yesterday
14:29:00  <Alberth> I wonder if you could use a temporary variable for storing the switch value
14:29:11  <Alberth> but no idea if that works
14:29:13  <supermop_home> that's what I am looking at now,
14:30:01  <Alberth> another magic option is to store the 117 into a variable, and use that in the code of "switch_cost"
14:30:31  <supermop_home> but I wonder if it thinks the value of switch_x is not and int (even though the returned value is), would it think the same thing about the stored value
14:30:36  <supermop_home> hmm
14:30:48  <Alberth> and of course, duplicating the switch, once for 100*cost/100 and once for 117*cost/100  is also an option
14:31:17  <Alberth> the name "switch_cost" is not a number
14:31:43  <supermop_home> well in this switch I need to return the plain switch_cost in case A, and the increased switch_cost in case b
14:31:50  <Alberth> apparently, it wants numbers or constant expressions there
14:32:12  <supermop_home> if the name of the switch is not a number, wouldn't the name of the stored value also not be a number
14:32:45  <Alberth> sounds likely
14:33:03  <Alberth> as I said, I am pretty much useless as guide in NML
14:33:05  <Alberth> :p
14:34:51  <supermop_home> I wonder if there is some other type of block elsewhere I can do the math
14:42:46  *** Montana_ has joined #openttd
14:42:59  *** Montana_ is now known as Montana
14:48:19  <Alberth> how many switch_cost return values do you have?
14:49:42  <Alberth> hmm, never mind, has the same problem of first querying the cost value
15:43:39  <supermop_home> Alberth: in those cases, it returns switch_cost_x for each known type of electric road, else it tries to do switch_cost_x*some coefficient
15:48:30  <Alberth> I don't know how to compute a multiplication of 2 switch results, or one switch result as part of computing another switch
15:49:05  <Alberth> what will work is to expand the switches to all possible cases, and hard-code the factor, in a way
15:50:40  <Alberth> hmm, wasn't the coefficient some parameter?
15:50:59  <Alberth> that lives outside the value computations
15:51:33  <Alberth> you can select entire switches with that
15:51:37  <Alberth> (afaik)
15:54:32  *** glx has joined #openttd
15:54:32  *** ChanServ sets mode: +v glx
15:56:01  <supermop_home> the parameters set the running cost style, easy medium or hard
15:56:47  *** andythenorth has joined #openttd
15:56:52  <supermop_home> then there are swithes for each engine type - diesel, electric, dual mode, for each generation (5 for diesel, 4 for electric, 2 for dual)
15:57:30  <Alberth> too much freaking detail :p
15:57:35  <supermop_home> each of those switches returns one of three hard coded running cost factors, per parameter setting
15:57:48  <Alberth> let me try to find parameter usages that can be helpful
15:58:24  <supermop_home> then in the case of dual mode, there needs to be another switch that changes running cost based on whether it is on an electric road or not
15:58:56  <supermop_home> I feel like it must be simpler some how
15:59:16  <supermop_home> the easy/medium/hard settings are .5/1.0/1.5
15:59:55  <supermop_home> i wish I could just globally multiply all running costs by those coefficients without using so many switches
16:00:32  <supermop_home> like running_cost: (running_cost_x * param y )
16:00:39  <andythenorth> o/
16:00:43  <supermop_home> yo andy
16:00:58  <Alberth> did you try using a parameter in a computation?
16:01:00  <Alberth> o/
16:01:06  <supermop_home> no
16:01:32  <supermop_home> I wonder if I can do match right in the callback like that tho
16:01:54  <Alberth> parameters count much like a constant
16:02:07  <Alberth> I wouldn't be surprised if that just works
16:02:25  <supermop_home> or store value (xxx*param 1)
16:02:35  <supermop_home> then retrieve that value
16:03:06  *** DDR has quit IRC
16:04:08  <Alberth> I'd just put the expression with param in the computation (1 + difficulty_param) * value / 2
16:05:25  <Alberth> if parameters  are treated as constant, you have only "value" there, which you can expand in the switch to constants
16:06:44  <Alberth> ie each return case a different number for 'value'
16:07:04  *** andythenorth has quit IRC
16:07:09  <Alberth> by eandy
16:07:36  *** andythenorth has joined #openttd
16:07:49  <Alberth> wb andy :)
16:08:20  <andythenorth> looks like 4/8 wagons to me
16:08:35  <andythenorth> but the engine + tender looks like 6/8 :P
16:17:02  <Wolf01> o/
16:22:11  <andythenorth> 6 industries left to draw for FIRS v3
16:22:44  <supermop_home> does that include the 'old' papermill for 18th C games per user request?
16:26:00  <supermop_home> Alberth:
16:26:02  <supermop_home> ELRD: return ((param_runcost*205)/2);
16:26:10  <supermop_home> default: return (117*((param_runcost*205)/2)/100);
16:26:19  <supermop_home> going to try that
16:32:33  <Alberth> if param_runcost is 0, it's all quite cheap :)
16:33:10  <Alberth> parentheses aren't needed, * and / run from left to right
16:33:44  <Alberth> hmm, maybe the 117* (... )  is needed
16:34:17  <Alberth> @calc 117*205
16:34:17  <DorpsGek> Alberth: 23985
16:35:19  <Alberth> quite a lot of the 16 bits :)
16:36:32  <Alberth> hmm, it's only 15 bit, wasn't it?
16:39:49  <Alberth> 102 + param_runcost * 103  ?
16:40:12  <Alberth> assumes param_runcost to be 0 or 1
16:41:07  <Alberth> obviously, you can factor your 117/100 into those constants too
16:41:37  <Alberth> @calc 205 * 117 /100
16:41:38  <DorpsGek> Alberth: 239.85
16:42:01  <andythenorth> supermop: no ‘old’ papermill
16:42:10  <andythenorth> FIRS tends to ‘modern’ industries
16:42:48  <Alberth> (param_runcost * 240) / 2    should quite work
16:43:18  *** Gja has joined #openttd
16:48:23  <supermop_home> andythenorth was a joke
16:49:27  <supermop_home> hmm is (117/100)*X better than 117*x/100?
16:49:39  <supermop_home> at least grf compiles now
16:53:50  *** andythenorth has quit IRC
16:58:00  *** andythenorth has joined #openttd
16:58:10  <andythenorth> supermop: such jokes :)
16:58:30  <andythenorth> also such peatlands
16:58:34  <andythenorth> who wants to draw that? o_O
17:03:17  <andythenorth>
17:06:24  *** frosch123 has joined #openttd
17:07:04  *** andythenorth has quit IRC
17:11:07  <frosch123> hoin
17:14:25  <supermop_home> Alberth: things seem to be working well now
17:15:18  <supermop_home> now I need to do the same thing for capacities
17:23:31  <supermop_home> whats the difference between cargo_capacity and purchase_cargo_capacity?
17:23:42  <supermop_home> purchase is what the menu shows?
17:27:26  <frosch123> it's for the purchase list
17:27:46  <frosch123> it's different, because articulated parts are quite tricky there
17:28:06  <frosch123> since they do not really exist, so, stuff like deciding capacity based on the other parts does not work
17:30:21  <supermop_home> does a non-articulated truck need it?
17:30:54  <frosch123> in that case link both to the same switch
17:34:01  <frosch123> Wolf01: should we attempt a hostile take over of the f party? (to turn it into a ottd party)
17:36:12  <Wolf01> The idea is tempting
17:44:09  <supermop_home> i wonder
17:44:33  <supermop_home> is a semi truck twice as heavy as a typical rigid truck?
17:44:37  <supermop_home> 1.5 times?
17:47:01  *** andythenorth has joined #openttd
17:47:36  <supermop_home> seems like something andy would know
17:53:33  <andythenorth> supermop: tare weight should be about 1/3 of gross weight, for the entire combination in both cases
17:57:58  <supermop_home> going to do rigid: x, short trailer x*1.3, long trailer x*1.5
17:58:03  <supermop_home> hmm
17:58:33  *** FLHerne has quit IRC
17:58:48  <glx> next step road train ?
17:58:51  *** FLHerne has joined #openttd
17:59:07  <Wolf01> Isn't already there?
17:59:39  <supermop_home> modifying the short semi to just attach more short trailers is easy enough
18:02:46  <supermop_home> though I will probably do something like, gen 1: short, gen 2: short or long, gen 3: long or 2*short, gen 4, long or 3*short
18:03:28  <supermop_home> andy so 1/2 capacity for weight is good rule of thumb?
18:04:52  <andythenorth> yes
18:04:59  <andythenorth> 30t payload, 15t vehicle weight
18:08:43  *** tux has joined #openttd
18:09:16  *** tux is now known as Guest1105
18:14:36  *** mindlesstux has quit IRC
18:14:36  *** Guest1105 is now known as mindlesstux
18:18:15  *** cosmobird_ has joined #openttd
18:19:24  *** mindless- has joined #openttd
18:24:18  *** cosmobird__ has quit IRC
18:25:14  *** mindless- has quit IRC
18:25:32  *** Montana has quit IRC
18:26:06  *** mindlesstux has quit IRC
18:49:22  *** sla_ro|master has quit IRC
18:57:23  *** mindlesstux has joined #openttd
19:22:16  *** mindlesstux has quit IRC
19:37:25  *** mindlesstux has joined #openttd
19:38:20  <argoneus_> good evening train friends
19:38:27  *** argoneus_ is now known as argoneus
19:39:36  <Wolf01> o/
19:41:19  <argoneus> Alberth: is it alright if I ask a soft. eng. question?
19:41:26  <argoneus> I remember you've helped me a lot before when we last spoke
19:42:19  <argoneus> though others will probably know it as well, it's just something I only learned recently
19:42:54  <argoneus> the point of interfaces is to declare ahead of time what kind of functionality I demand from some module another one uses without caring about the specifics, right?
19:43:14  <Wolf01> Somewhat, yes
19:43:25  <argoneus> so like, if I have a command handler that receives a command, processes it and then sends a response
19:44:04  <argoneus> instead of hardcoding anything, this command handler will have a member object such as "ResponseInterface" with functions such as sendOK, sendMessage, etc.?
19:44:17  <argoneus> and at that point I don't care if the response is printed to a file or sent over a network
19:44:21  <argoneus> the command handler just does not care
19:44:23  <argoneus> is that the idea?
19:44:39  <argoneus> or am I overthinking/overengineering things
19:45:24  <frosch123> add "interpreted by a unittest framework" to that list
19:45:41  <argoneus> so I can just do network_protocol->send_message(Message(Client, Text))
19:45:43  <Wolf01> The interface is like a puzzle piece, where you don't have the content but only the shape
19:45:47  <argoneus> and I don't care
19:45:51  <argoneus> ?
19:46:22  <Wolf01> And you don't use the interface, but you must implement a class of that interface
19:46:31  <argoneus> frosch123: you mean... that the command handler can now have a dummy object that implements the interface?
19:46:48  <argoneus> and it's easy to unit test, because said object can just do nothing for all the functions, since the unit test doesn't care about it?
19:47:07  <argoneus> but yeah, my point, or question is
19:47:16  <argoneus> is this a *correct* usage of an interface or am I overengineering things?
19:47:19  <frosch123> the unittest provides the output interfaces and then feeds data into the input interfaces, and can check the output
19:47:35  <frosch123> argoneus: your interface sounds fine
19:47:38  <argoneus> I just see it as something like
19:47:43  <Wolf01> You can have a class with a sendOk function which returns an hardcoded output just to check if that function is called
19:47:57  <argoneus> when a class is finished with work in its own scope, and wants to send the results to an unknown recipient
19:48:03  <argoneus> which can be different protocols etc.
19:48:07  <frosch123> it's anything that divides the code, and where you can check whether some misbehaviour is before or after it
19:48:21  <frosch123> like, if you have some big software and you input something and the result is wrong
19:48:34  * andythenorth mind blown
19:48:35  <frosch123> you can check the intermediate results at all interfaces to isolate the bug
19:48:52  <argoneus> ah
19:49:05  <argoneus> so then it's good practice to have an interface for every... well, interface between .. what to call it
19:49:11  <argoneus> "logical units"?
19:49:22  * andythenorth just thought interfaces were stable methods with defined parameters and results
19:49:23  <argoneus> of the software
19:49:30  <Wolf01> Look about mockups
19:49:32  <frosch123> the idea of unitstests is to separate things which can be tested on their own
19:49:33  <andythenorth> and the upside being no private shenanigans changing state inside the object
19:49:40  <frosch123> and then fill the space inbetween with boilerplate
19:49:52  <Alberth> interfaces partition your solution in smaller pieces with known functionality
19:50:07  <argoneus> hmm, I see
19:50:09  <argoneus> because
19:50:17  <argoneus> I was doing some google tutorials for android programming
19:50:38  <andythenorth> Alberth: why bother with an interface? o_O  Surely “foo._important_data = some new value” is fine? o_O
19:50:44  <argoneus> and I downloaded the example code, and it was interface upon interface upon interface, nested interfaces inside a "Contract" interface...
19:50:50  <frosch123> another usecase of interfaces is: if you have two branches of a company work on the same software, you use the interface specificaion to figure out which branch to blame if something does not work
19:50:59  <argoneus> and I was like "oh god this is terrible", but after I wrote all the boilerplate, it was actually really nice to work with
19:51:07  <andythenorth> argoneus: if you have found Contracts, then you are in political code
19:51:21  <argoneus> political code...?
19:51:22  *** sim-al2 has joined #openttd
19:51:27  <andythenorth> it might be fine, but it’s more politics than engineering currently
19:51:46  <Alberth> andythenorth: it's a matter of scale, direct access works up to some scale / up to some number of programmers
19:51:55  <andythenorth> Alberth: 0.9?
19:52:03  <Alberth> beyond that you need more structure
19:52:04  <argoneus> hmm
19:52:09  <argoneus> actually, now that I think about it
19:52:31  <argoneus> there's no such thing as using interfaces too much, right? it's not like making classes upon classes, I have to actually implement a concrete interface anyway, so it doesn't bloat it
19:52:48  <Alberth> oh, there is
19:52:52  <argoneus> concretely implement an interface*
19:52:55  <argoneus> oh
19:52:57  <Alberth> like anything too much of it is not good :p
19:53:00  <argoneus> hm
19:53:07  <argoneus> it just suddenly made sense in my case
19:53:11  <argoneus> like
19:53:11  <Alberth> but the problem is, when is "too much" ?
19:53:18  <argoneus> when I have some part that's pluggable in/out
19:53:25  <argoneus> like network things
19:53:27  <argoneus> it seemed to make sense
19:53:48  *** FLHerne has quit IRC
19:53:54  <frosch123> argoneus: if you add interfaces you always also define what the software shall do
19:53:56  <argoneus> if I want to support 50 different protocols, it's surely a good thing to have a common interface, no?
19:54:20  <frosch123> if you add too many interfaces you may have more flexibility than is actually needed
19:54:28  <frosch123> so your software ends up more complicated than needed
19:54:39  <frosch123> or you get lost in corner cases, which actually noone needs
19:54:56  <argoneus> hmhm, that makes sense
19:55:02  <Alberth> also, changing an interface is tricky, since it gets used at many places
19:55:07  <frosch123> i..e. the more interfaces you have, the smaller each one is, which makes them more generic
19:55:26  *** FLHerne has joined #openttd
19:55:27  <argoneus> I guess like with all software engineering things
19:55:34  <argoneus> it's cool, but don't try to use it everywhere
19:55:38  <Alberth> giving total fragmentation of functionality :p
19:55:38  <argoneus> see: design patterns
19:55:41  <argoneus> right
19:56:13  <Alberth> design patterns primary use, as I see it, is that common patterns have a name
19:56:28  <Alberth> so you can talk about it, without having to draw a large class diagram
19:56:36  <argoneus> I'm just still struggling with an implementation of an IRC bot that supports plugins that add commands and have their own functionality like timers or database support and such
19:56:41  <argoneus> I'm on my 3rd iteration
19:56:45  <andythenorth>
19:56:55  <Alberth> :D andy
19:56:57  <argoneus> and again it's an abomination that works perfectly, but... there's no clear separation
19:57:00  <argoneus> like
19:57:08  <argoneus> the network functions call the non-network code
19:57:14  <argoneus> and the non-network code has direct access to sockets
19:57:19  <argoneus> stuff like that I don't know how to get rid of
19:57:38  <Alberth> something needs to connect it
19:57:50  <Alberth> or you have 2 spearate programs :p
19:58:04  <argoneus> I'll give a quick example, if that's fine
19:58:29  <argoneus> say there's an IRC bot with a... spamming plugin, for explanation purposes
19:58:39  <Wolf01> The best work about actually using interfaces in actual code has been done by the PHP standards recomendation guys
19:58:53  <Wolf01> s/actually/
19:59:01  <argoneus> the plugin defines a command !spam <text>. once someone uses this command, it will send said message as a private message to everyone in the room (my bot actually doesn't have this)
19:59:34  <argoneus> but how my bot would do it: network class receives message, sends it to parser, parser parses it, and the parser grabs a list of every user's socket and sends them the message
19:59:49  <argoneus> that last step works perfectly, but I feel like it's really really bad
19:59:53  <argoneus> but I have no clue how to eliminate it
20:00:14  <andythenorth> what bothers you about it?
20:00:31  <andythenorth> you don’t like the parser performing send?
20:00:36  <argoneus> it seems like it's a bad idea to use raw sockets inside a class that shouldn't even ideally know there's a network socket
20:00:38  <andythenorth> not the parser’s job?
20:00:42  <argoneus> yeah
20:00:50  <argoneus> I feel like the network class should be the only one working with sockets
20:00:56  <andythenorth> controller class?
20:01:03  <Wolf01> Then it's domain driven development what you are looking for
20:01:16  <andythenorth> don’t you delegate to the parser, and then handle what it returns?
20:01:20  <frosch123> argoneus: try to not make your code like a pipeline, where one class passes data to the next one
20:01:29  <argoneus> oh, is that bad?
20:01:31  <argoneus> I've always done it that way
20:01:37  <frosch123> instead always make the classes return the result to the caller
20:01:57  <argoneus> so... instead of the parser class sending messages
20:02:11  <frosch123> if needed put a class at the bottom, which calls everyone
20:02:15  <argoneus> it would return a list of Message(RecipientObject, text), and the network class would resolve RecipientObject into a socket?
20:02:27  <argoneus> or that won't work
20:02:49  <argoneus> "put a class at the bottom, which calls everyone"...?
20:03:32  <Alberth> plugin has a "main" of its own
20:03:34  <andythenorth> in python, you’d have __main__ or so
20:03:48  <argoneus> ....wait
20:03:49  <andythenorth> in a web app you might have a request controller or so
20:03:54  <argoneus> so I send the message to every plugin?
20:04:01  <argoneus> and they either return nothing or they return message(s)?
20:04:04  <argoneus> and then I just send these
20:04:10  <andythenorth> you’d have flow control inside your main class, passing state along
20:04:18  <Alberth> or all until the fuirst answrs or so
20:04:19  <frosch123> have one mani class which calls "package = receiver.receive(); parsed_package = parser.parse(package); result = command_handler.execute(parsed_package); receiver.reply(package, result)"
20:04:32  <argoneus> oh, huh
20:04:33  <Wolf01> Functionalities as services, each service is a separate class, the base class calls the services passing the data
20:04:42  <argoneus> oh, right!
20:04:48  <argoneus> there was one other problem I had with this
20:04:54  <argoneus> what exactly is "result"
20:04:54  <andythenorth> so the state in frosch’s example is ‘package’ and ‘result'
20:04:59  <argoneus> like if the command should
20:05:09  <frosch123> that main loop would also ultimatively catch all the exceptions
20:05:13  <argoneus> send a message to everyone who's an admin, and at the same time kick someone whose name starts with xyz
20:05:17  <andythenorth> and the main delegates to classes to mute state
20:05:18  <frosch123> and pass an error status to somewhere
20:05:19  <argoneus> what exactly is "result"?
20:05:23  <andythenorth> let’s not talk about Haskell here :)
20:06:12  <Wolf01> Result could be anything you want, which should make sense to the next step in the base class
20:06:13  <Alberth> I don't think you want to do 2 different things together
20:06:19  <argoneus> do I need some sort of abstraction like a Response, from this a MessageResponse, KickResponse, etc...
20:06:23  <argoneus> and result is list<Response>
20:06:29  <argoneus> and the network class evaluates these?
20:06:31  <argoneus> would that work
20:06:54  <argoneus> well, that's the thing
20:06:58  <argoneus> some of the commands can be tricky
20:07:12  <Wolf01> Usually you have one response for each request
20:07:12  <argoneus> it can even be things like "send a message to person X, then wait 5 minutes, and then send message to person Y"
20:07:15  <Alberth> make the derived Response smart
20:07:18  <argoneus> I want the plugins to be very flexible
20:07:26  <argoneus> smart?
20:07:40  <supermop_home> hmm semi trucks are showing double the real capacity in purchase menue
20:07:58  <Alberth> so it knows what the message is doing or how to send it etc
20:08:06  <andythenorth> supermop: paste your nml
20:08:16  <Alberth> but in general, you cannot be flexible in every direction.
20:08:20  <argoneus> hmm
20:08:30  <argoneus> this is kinda one of the reasons I just had raw sockets
20:08:35  <argoneus> because some commands did 4 different things at once
20:08:44  <argoneus> and I couldn't figure out how to standardize it into a response
20:08:49  <Alberth> it means you cannot have any structure, since such structure would block extensions that use a different structure
20:09:02  <Alberth> so you have to make a limit somewhere
20:09:50  <Alberth> there is a large trap in trying to over-generailize things
20:10:16  <Alberth> it seems so nice, and it nicely fits in our western belief that everything must have a box of its own
20:10:42  <argoneus> hmm
20:10:46  <argoneus> well, in the case of IRC
20:10:53  <Alberth> but in real applications, there is always these cases that won't fit
20:11:09  <argoneus> is there a problem with a command having more than one response? if I call it Action instead of response, it suddenly makes sense, no?
20:11:15  <argoneus> every command can have X actions associated with it
20:11:26  <Wolf01> Yes, but still one response
20:11:27  <argoneus> and these actions can be logged at the parser level easily
20:11:29  <Alberth> it sounds complicated at least
20:11:32  <argoneus> oh
20:11:38  <argoneus> then a Response could just be a list of Actions
20:11:43  * argoneus shrugs
20:11:43  <Alberth> it's almost a program by itself
20:12:00  <argoneus> well
20:12:07  <argoneus> the set of possible actions is limited
20:12:12  <Wolf01> You can do 100 actions and have a response which tells you if all was fine
20:12:14  <Alberth> software is so nice, there is no upper limit in adding more and more layers :)
20:12:21  <argoneus> the bot can really only do like 6 different things, but one command can do 3 of those at the same time
20:12:48  <Alberth> I'd make one command do one thing, and have more commands
20:13:31  <argoneus> well
20:13:40  <argoneus> I shouldn't have said IRC, probably
20:13:46  <Wolf01> For example you have a KickBanWhy() command, it does 3 actions: kick, ban and explain why
20:13:49  <argoneus> it's more of a game that runs over pretty-much-IRC
20:13:57  <argoneus> so a command could like reduce someone's health and move them soemwhere else
20:14:06  <argoneus> and it makes no sense for them to be separate commands
20:14:11  <Alberth> can I play chess with it?
20:14:13  <argoneus> oh, wait
20:14:17  <Wolf01> But the response is only one: has the user been kicked, banned and notified?
20:14:18  <argoneus> then I just declare this action at the network elvel
20:14:19  <argoneus> !
20:14:23  <argoneus> in the interface
20:14:41  <argoneus> oh, or what Wolf01said
20:14:45  <argoneus> that also seems nice
20:14:46  <Alberth> there is a finite number of useful actions in a game
20:14:47  <argoneus> Alberth: probably yeah
20:15:02  <argoneus> yeah, definitely
20:15:06  <argoneus> there's a finite set of actions
20:15:07  <Alberth> don't generalize beyond that, there is no point
20:15:09  <argoneus> but commands can mix them together
20:15:13  <argoneus> reasonably
20:17:53  <argoneus> anyway thanks a lot everyone
20:18:06  <Wolf01> I did this for 5 years every day... CURL APIs
20:18:12  <argoneus> the question now is whether I want to create these compound actions at the network interface level, or just have each command do multiple actions
20:18:24  <argoneus> I guess I'll just have to write down what exactly I even need
20:18:25  <Alberth> keep it simple :)
20:19:00  <Alberth> I tend to build what I need today, and not much else
20:19:16  <argoneus> I don't know how to refactor efficiently :(
20:19:22  <argoneus> I end up just deleting everything and re-writing
20:19:30  <argoneus> this is my 4th iteration of the same bot!
20:19:40  <Alberth> tomorrow is unpredictable anyway, no point in trying to prepare for it
20:19:42  <argoneus> the 3 previous ones work perfectly but I hate their design
20:19:43  <Wolf01> Learn about design atterns
20:19:47  <Wolf01> *patterns
20:19:51  <supermop_home> andythenorth:
20:20:24  <Alberth> the problem with rewriting is that you don't advance in functionality
20:20:42  * andythenorth rewrites a *lot*
20:20:52  <Wolf01> But you might be able to rewrite to advance later
20:21:04  <argoneus> I'm just a bit of a perfectionist in this aspect
20:21:20  <argoneus> even if the program works perfectly, and at decent speed, as long as there's something with it I deem as bad, I'm not happy
20:21:24  <Alberth> and efficient refactoring is very very hard, I can't do it either, I typically have 3 or 4 attempts before it works out
20:21:41  <andythenorth> supermop_home: why does purchase_cargo_capacity result differ from cargo_capacity?
20:21:49  <Alberth> what about the other parts of the program?
20:22:06  <Alberth> ie, you can consider the bot as "good enough for now"
20:22:45  <Alberth> that's basically the state of most of my code, and often it dies that way :)
20:23:06  <supermop_home> the switch for cargo capacity sets the capacity for a consist with a medium semi trailer
20:23:11  <Wolf01> Also, the best thing to do (with a lot of spare time) is to do test driven development, you write the interfaces, then the unit tests, you mockup the concrete classes, when you are happy about the functionality you can effectively implement the real concrete classes and you have already the tests
20:23:26  <argoneus> it's definitely good enough
20:23:30  <andythenorth> good interfaces let you hide horrors behind them ;)
20:23:36  <argoneus> but if I wanted to add a new feature, I can imagine it to be easier than iti s
20:23:45  <andythenorth> somewhat a peatlands
20:23:46  <argoneus> right now, adding a new command involves copypasting boilerplate code
20:23:55  <argoneus> which I think is terrible
20:23:57  <supermop_home> part 0 returns zero, part 1 returns (param_capacity*36)/2
20:24:04  <Wolf01> Nice andy
20:24:17  <andythenorth> supermop_home: ok I’ll read again
20:25:23  <andythenorth> supermop_home: you just want capacity that varies by parameter?
20:25:28  <supermop_home> yep
20:25:38  <Wolf01> argoneus, a bit of copy-pasting is always required
20:25:56  <supermop_home> its working as I want, except for the semis displaying wrong in buy menu
20:26:01  <andythenorth> supermop_home: somewhere in here :P
20:26:12  <andythenorth> I guess I should find the lines for you :)
20:27:31  <argoneus> well, I'll see what I can do
20:27:40  <argoneus> anyway, thanks a lot, train friends!
20:27:48  <andythenorth> supermop_home: it’s a semi-truck, how much capacity do you move to tractor unit? o_O
20:29:20  <supermop_home> 0
20:30:10  <Wolf01> I made a svn web interface to do some simple actions: update, export, and checkout new repositories, these were the 3 actions allowed by the interface, but each command did a lot in background, also filesystem changes, permissions, backups
20:30:27  <andythenorth> ach, I have NFI how this road hog code works
20:30:33  <andythenorth> but it has the right results
20:30:58  <supermop_home> it looks like you just use same switch for both capacity and purchase capacity
20:31:01  <andythenorth> yes
20:31:13  <andythenorth> for capacity, it doesn’t have to be moved to lead unit (unlike weight iirc)
20:31:42  <supermop_home> for some reason, my math in purchase capacity is ending up double
20:31:55  <andythenorth> what cargo is default?
20:32:02  <supermop_home> I can easily fix it by changing /2 to /4
20:32:21  <supermop_home> andythenorth: none, so copper as I am playing now
20:32:27  <andythenorth> hmm
20:32:37  <andythenorth> why is it /2?
20:32:44  <frosch123> what does switch_capacity_m4_box do?
20:32:49  <supermop_home> param value is 2
20:32:54  <supermop_home> 2 3 or 4
20:33:11  <supermop_home> /2 to get 1x, 1,5x or 2x capacity
20:33:49  <frosch123> anyway, your vehicle consists of two articulated parts
20:34:01  <frosch123> both parts are defined by the same "item"
20:34:15  <frosch123> so each part has a capacity of "purchase_cargo_capacity:    ((param_capacity*36)/2);"
20:34:18  <andythenorth> so your capacity will get summed
20:34:19  <supermop_home> frosch123: that switch sets capacity of part 0 to 0
20:34:30  <andythenorth> nah, use multiple parts
20:34:48  <andythenorth> pissing around changing properties leads to pitfalls
20:35:06  <frosch123> with two parts you then end up with a capacity of "param_capacity*36"
20:35:10  *** Alberth has left #openttd
20:35:37  <supermop_home> hm
20:42:58  *** frosch123 has quit IRC
20:45:25  <supermop_home> can I store a value at the top of the nml and then just read that value in the properties?
20:46:06  <supermop_home> or does the value in properties have to be a plain number
20:46:46  *** Hiddenfunstuff has quit IRC
20:47:51  <andythenorth> can’t remember if nml supports internal arbitrary constants
20:47:56  <andythenorth> I think it might
20:48:30  <andythenorth> FIRS has “market_tree_snow = 1793;"
20:48:53  <andythenorth> near the top of nml file, and market_tree_snow is then used elsewhere
20:49:01  <supermop_home> I have like 20 trucks that have the same values for certain properties
20:49:20  <supermop_home> would be easier to change without missing one
20:50:25  <andythenorth> and this is why templating :)
20:50:33  *** Stimrol has joined #openttd
20:55:03  <andythenorth> supermop_home: you just hit the point where ‘programming’ starts ;)
20:55:42  *** chomwitt has joined #openttd
21:05:51  *** gelignite has quit IRC
21:09:40  <andythenorth> also bedtime
21:09:41  *** andythenorth has left #openttd
21:16:37  *** tux has joined #openttd
21:17:05  *** tux is now known as Guest1115
21:21:44  *** Gja has quit IRC
21:23:06  *** mindlesstux has quit IRC
21:27:51  *** Stimrol has quit IRC
21:44:31  *** Guest1115 is now known as mindlesstux
22:10:49  *** HerzogDeXtEr has quit IRC
22:19:53  *** Wormnest has quit IRC
22:22:46  *** urdh has quit IRC
22:27:46  *** keoz has quit IRC
22:30:36  *** Snail has joined #openttd
22:35:29  *** Montana_ has joined #openttd
22:41:19  *** Progman has quit IRC
22:45:50  <Eddi|zuHause>  <andythenorth> FIRS has “market_tree_snow = 1793;" <-- that is technically not a constant, but a "parameter"
22:46:18  <Eddi|zuHause> it uses up one of the (limited) parameter slots
22:46:28  <Eddi|zuHause> and is then action6-ed into the properties
22:47:00  <Eddi|zuHause> (some limitations may apply where action6 cannot be used, but i don't know them)
22:47:18  <Eddi|zuHause> anyway, this shortcoming of nml is one of the reasons why people use preprocessing
23:10:05  <supermop_home> i don't know how to pre-process yet
23:16:03  *** cosmobird_ has quit IRC
23:24:05  <supermop_home> if i can figure out how to composite sprites for cargos I should be able to save a lot of lines
23:24:32  <supermop_home> then I could recolor steel rolls to copper, wood crates to white crates, etc
23:42:16  *** Montana_ has quit IRC

Powered by YARRSTE version: svn-trunk