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> https://img-9gag-fun.9cache.com/photo/aQ9W84e_460sv.mp4 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 http://www.ebay.co.uk/itm/LIFE-LIKE-TRAINS-IRON-HORSE-HO-SCALE-LARGE-SET-BRAND-NEW-USA-/162532035166?hash=item25d7aa0a5e:g:-IAAAOSwiONYKf0C 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> http://fafard.qc.ca/wp-content/uploads/2013/05/tourbiere-saint-bonaventure-quebec-bog-peatland.jpg 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> http://thecodelesscode.com/case/117?topic=interfaces 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 http://www.php-fig.org/psr/ 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: https://paste.openttdcoop.org/pdgm3zyhn 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 http://dev.openttdcoop.org/attachments/download/8446/peatlands.png 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 https://paste.openttdcoop.org/pub5u3rna 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