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