Log for #openttdcoop.devzone on 6th July 2014:
Times are UTC Toggle Colours
03:26:38  *** gelignite_ has joined #openttdcoop.devzone
03:33:58  *** gelignite has quit IRC
05:58:59  *** Alberth has joined #openttdcoop.devzone
06:43:42  *** Supercheese has joined #openttdcoop.devzone
06:44:46  <V453000> planetmaker: I do not always need tiling textures, that is fine ... would have to refine the brightness/contrast and some things. Looks quite nice though, thanks... I will see if I need it sometime :)
07:28:27  *** tycoondemon has joined #openttdcoop.devzone
07:37:49  <Alberth> hmm, changing all expression code of NML is going to be very messy :(
07:49:19  <planetmaker> oi, that sounds like a hell of a lot of work
07:59:44  <Alberth> yep
08:00:19  <Alberth> it deep-clones expressions on reduction of constant expressions and rewrites etc
08:00:48  <Alberth> which of course explodes in memory use, and then garbage collection afterwards
08:01:17  <planetmaker> what does that conceptually mean? It's an expression I don't know
08:01:30  <planetmaker> 'deep clone'
08:02:08  <Alberth> say I have a number. You want to change that number, but also keep the original. That means you have to make a copy, a clone
08:02:49  <DevZone> Yippee, build fixed!
08:02:50  <DevZone> Project 2ccts build #182-push: FIXED in 1 min 28 sec:
08:03:19  <Alberth> when you have a list of numbers, you can make a copy of the list alone (and re-use the existing numbers)    this is a shallow clone of a list
08:03:49  <Alberth> of you can make a new list, and also copy the numbers     a full copy, or deep clone, in java speak
08:03:50  <planetmaker> ok
08:04:31  <Alberth> nml thus makes full copies of its expression trees when simplifying (reduce) its expressions
08:04:32  <planetmaker> hm... so copy of all single elements vs. copy of the over-laying structure?
08:04:56  <planetmaker> where the over-laying structure is then filled piecewise from the original?
08:05:10  <Alberth> it copy of the top-level structure versus copy of everything
08:05:38  <planetmaker> I see. thanks :)
08:05:44  <Alberth> the idea of shallow copying is that you can modify the upper level, the list, but not touch the numbers
08:06:38  <Alberth> in general, if you don't touch existing data, you don't need to copy it, and thus you can share it
08:07:30  <Alberth> this shifts the paradigm from changing data in-place, to making new data from existing data without modifying the existing data
08:08:00  <Alberth> the latter is often used in reference-oriented languages like Python and Java
08:08:34  <Alberth> it's quite cheap, as you only make new objects for the things you modify
08:08:45  <planetmaker> so it's similar to call-by-value (deep) vs. call-by-reference (shallow)?
08:09:23  <Alberth> yep
08:09:34  <planetmaker> aye, that's concepts I know :)
08:09:50  <Alberth> anyway, nml does deep copying of its expression trees
08:10:04  <planetmaker> that's expensive, yes.
08:10:19  <Alberth> yeah :)
08:10:34  <Alberth> so the question is why
08:11:10  <Alberth> the only valid reason is if you change arbitrary data, but you don't know what will change exactly
08:12:54  <Alberth> on the other hand, when people coming from a value-oriented language like C/C++ get used to references like used in python, they tend to a) ignore it until the code fails to work, then b) deep-copy everything, until they find it becomes too expensive, and finally c) use shallow copying
08:13:31  <Alberth> so another reason for deep-copy is that its author was in "b)" mode while writing it
08:14:02  <planetmaker> that's not unlikely. NML was - iirc - also written in python so that yexo could learn (more) python
08:15:42  <Alberth> indeed
08:16:47  <Alberth> removing deep-copying implies that you know it's safe, there is no code that modifies the shared object
08:17:12  <Alberth> the puzzle is now how to verify that
08:18:03  *** Supercheese has quit IRC
08:18:39  *** oskari89 has joined #openttdcoop.devzone
08:19:26  <planetmaker> hm :)
08:21:27  <Alberth> in a compiled language, you just change the field name, and the compiler will find the points you need to look at
08:21:42  <Alberth> no such luck with python :)
08:22:15  <Alberth> you can make an object read-only, but you need to execute the write attempts to find it
08:22:25  <Alberth> *them
08:24:06  <Alberth> so it looks like you're going to have to check and rewrite all python files for use of data members of ConstantNumeric, ConstantFloat, etc etc a 15-20 classes or so
08:24:48  <Alberth> and still you are not sure, since a ".value" without mentioning a class name nearby is easily missed
08:25:02  <Alberth> we have a zillion "value" fields in the various classes :)
08:26:13  <Alberth> so it makes me wonder whether all this trouble is worth it
08:27:12  <Alberth> it might be simpler in the end to just re-implement it all in a compiled language like c++
08:28:09  <V453000> how do I tell an industry how much to produce by a switch-like thing?
08:28:20  <V453000> I assume I just put some switch in prod_multiplier:
08:28:36  <V453000> but do i put it in []. and how does such a switch look like?
08:29:05  <V453000> for trains I had switches like switch (FEAT_TRAINS, SELF, railpax_capacity_switch, cargo_type_in_veh) { PASS: 40; MAIL: 20; VALU: 15; GOLD: 15; DIAM: 15; 15; }
08:29:13  <V453000> but does SELF apply to industry?
08:29:49  <planetmaker> outch. That sounds bad, Alberth :(
08:30:05  <Alberth>   wouldn't this be the thing you're looking for?
08:30:17  <Alberth> (no idea, I never used it )
08:30:31  <V453000> I have seen it but i have totally no clue how to apply it
08:30:33  <planetmaker> produce switch is for industry output, yes. Funny callback
08:30:45  <planetmaker> look at firs for guidance
08:30:59  <V453000> I did put produce: produce() into graphics{} block
08:31:03  <V453000> does that sound right?
08:31:08  <Alberth> planetmaker: it's totally possible I am missing some way to get it done
08:31:39  <planetmaker> hm :) I don't think I have more clue right now than you
08:31:53  <planetmaker> Also sorry, would want to continue both discussions, but I gotta leave for the day
08:32:17  <Alberth> ok, have fun planetmaker :)
08:32:27  <planetmaker> thanks, you, too :)
08:32:46  <Alberth> V453000:  the example at that page calls the produce from graphics too
08:33:08  <V453000> yua
08:33:47  <V453000> how do you think a simple produce should look for a basic secondary to produce idk, 16raw -> 16output
08:35:37  <Alberth> produce(name,   16, 0, 0,   16, 0,   1);
08:35:53  <V453000> 1?
08:36:12  <Alberth> take 16 from the first input, produce 16 at the first output, and try again
08:36:19  <V453000> aha
08:36:31  <V453000> hm I had some missing numbers there and the 0 wasnt there :)
08:36:47  <Alberth> last parameter is optional
08:37:02  <V453000> that is what I read too :D
08:37:20  <Alberth> note this can be expensive, if you dump  1600, this produce is run 100 times
08:37:32  <Alberth> or 101 times, even  :)
08:38:08  <V453000> so the less often run, the better
08:38:24  <V453000> aka better replace 16 with like 128
08:38:30  <Alberth> so the better solution is what it says below, and use industry variables to check available cargo, and compute the right amount to produce in one go
08:38:57  <Alberth> but I'd consider that a next step
08:39:03  <V453000> aye
08:40:23  <V453000> hm the refinery seems to produce something regardless :D
08:40:25  <Alberth> I have no idea how to deal with a second input cargo either with this simple produce
08:40:38  <V453000> guess I should remove prod_multiplier: [16]; ?
08:40:51  * Alberth doesn't know
08:41:28  <V453000> :D
08:41:37  <V453000> oil refinery caused an endless loop in the produce callback
08:41:41  <V453000> good newgrf
08:41:49  <V453000> XD
08:41:58  <V453000> 34425000 litres produced last month
08:41:59  <V453000> nice
08:42:13  <V453000> hm.
08:42:49  <Alberth> sounds sufficient :)
08:43:37  <V453000> hm
08:43:49  <V453000> life_type: IND_LIFE_TYPE_PROCESSING; does this make sense for a secondary?
08:43:57  <V453000> or which one should I use there?
08:48:59  <V453000> do those things produce somehow other than the [16] ?
08:49:36  <Alberth> don't know
08:49:46  <V453000> :D
08:50:03  <Alberth> when writing that code, there was nothing for transport
08:53:29  <V453000> this is hell :|
08:56:02  <Alberth> nah, it's just missing a sane tutorial :p
08:56:47  <V453000> -> hell
08:57:42  <V453000> where would you search for ${}_produce; in FIRS?
08:57:52  <V453000> seriously, the templating is just making it unreadable :D
08:59:37  <Alberth> produce (aluminium_plant_simple_produce     just look for that
08:59:57  <V453000> in which file?
09:00:03  <Alberth> firs.nml
09:00:37  <Alberth> the template is in src/templates/produce_secondary.pynml
09:00:54  <Alberth> which makes a lot of sense, if you want to have the boost production stuff
09:00:59  <V453000> ah
09:01:44  <V453000> :|
09:02:44  <V453000> but yeah I would eventually need some boosting not only in supplies but also the kind of thing "produce more if more cargo types delivered"
09:03:51  <Alberth> eventually, you'll end up with something at least this complicated :)
09:04:16  <Alberth> ah, "waiting_cargo_1" is just an industry variable
09:04:55  <V453000> guess I will have to find a coder
09:04:58  <V453000> this is totally above me
09:05:31  <Alberth> did you try with 0 for repeat of production?
09:07:25  <Alberth>  produce(waiting_cargo1, waiting_cargo_2, waiting_cargo_3,  waiting_cargo_1 + waiting_cargo_2 + waiting_cargo_3, 0)   ?
09:08:09  <Alberth> produce, by taking the waiting cargo of 1, 2, and 3, and produce the sum of the waiting cargo as first output, 0 as second output, and no repeat
09:09:30  <Alberth> boost stuff is much later :)
09:09:40  <V453000> quite :)
09:09:41  <V453000> trying now
09:10:11  <V453000> hm yeah that leaves the cargo in the waiting to be processed stockpile
09:10:35  <Alberth> hmm :(
09:11:17  <V453000> the refinery still produces independently though
09:11:23  <V453000> so delivering the cargo is just cute :D
09:11:58  <Alberth> it's definitely unique industry behavior :p
09:12:22  <Alberth> can I download your code and stuff?
09:13:09  <V453000> I dont have hg setup with yeti but I can send it
09:13:14  <Alberth> nml is dearly missing a nice step-by-step tutorial of how to use its language
09:13:39  <V453000> trains were hell but they are nice by working somehow from the start
09:13:57  <Alberth> trains are much better explained
09:14:47  <V453000> my code :)
09:16:11  <Alberth> thanks
09:16:17  <V453000> my thanhks :)
09:18:31  <Alberth> I don't know if I can make it work  yet :)
09:18:45  <V453000> me neither :) but I appreciate you trying to help
09:18:46  <V453000> a lot
09:21:48  <Alberth> it needs nuts, or the nuts in that zip?
09:28:57  <V453000> ?
09:29:11  <V453000> there is any nuts in that zip? :D
09:29:35  <V453000> :D that is probably just mistake
09:29:48  <V453000> just use the nuts from bananas
09:29:52  <V453000> oil and rfpr works
09:31:07  <Alberth> ha, works with opengfx+trains too
09:31:30  <Alberth> nuts in that zip is not recgnized for some weird reason :(
09:34:00  *** gelignite_ is now known as gelignite
09:34:14  <V453000> it probably isnt even nuts
09:34:21  <V453000> just yeti with bad grf name
09:34:25  <V453000> or something along those lines
09:43:17  <Alberth>     input multi-pliers seem to be the reason
09:43:56  <V453000> I copied that from mars things :P
09:44:11  <Alberth> substitute change is just to make the industries have a different colour in the map
09:44:22  <Alberth> right, like I know what things do :p
09:44:27  <V453000> :D
09:44:31  <V453000> I assumed so? :D
09:45:19  <Alberth> but oil refinery now produces same amount of output as amount it was given
09:47:32  <V453000> like 180 litres of oil delivered == 180 rfpr produced?
09:47:35  <V453000> that is okay I think
09:48:09  <V453000> in fact that is how I would want to do it regardless
09:48:18  <Alberth> more like 30,000 liters -> 30,000 liters, but close enough :)
09:48:26  <V453000> aye :)
09:48:31  <V453000> that is okay
09:48:48  <V453000> other secondaries which combine 3 cargoes should then get the boost-ish thingy
09:49:02  <V453000> but refinery, power plant, and steel mill should have 1->1
09:49:15  <V453000> they are just artificial extension of the chain :)
09:50:46  <Alberth> I had this crazy idea of making a loop of such industries, and have 1 industry produce very small amounts of one of the cargoes
09:50:59  <V453000> :)
09:51:04  <Alberth> ie the amount of money you make heavily depends on your delivery rates
09:51:07  <V453000> well technically yeti is a loop
09:56:31  <George> Hi. As we discussed several days agou, changing capacity of the vehicle should be safe in depot
09:57:14  <George> to be sure capacity change happens in depot, using of day_of_last_service was suggested.
09:58:30  <George> I made a test and found, that capacity is not recalculated when servied in depot, but happens some time later
09:59:21  <George> This causes OTTD to report about potencial desync, because the GRF changes capacity outside depot
09:59:56  <George> Is that intended or there is a bug with wron recalculation of cargo capacity on service
10:02:12  <V453000> I think the most important suggestion was that this is seriously too far going into realism George
10:03:21  <George>
10:03:42  <George> V453000: my current question is not about realism
10:04:06  <George> but about potencial bug in capacity calculation code
10:04:08  <V453000> not implementing such a stupid feature solves the issue as a whole.
10:04:33  <George> No, it does not in general, only in the current case
10:10:57  <Alberth> I don't think anyone that knows the answer is here at the moment
10:14:25  <George> and who can know the answer in general 9not at the moment)
10:14:47  <V453000> that is not a general solution Alberth :D
10:16:43  <Alberth> nope, and neither is talking to george not to do it. The general solution is just to drop that part of the newgrf spec
10:17:21  <Alberth> although there are probably legitimate use cases for this
10:17:35  <V453000> I cant think of one tbh
10:19:19  <George> very simple - standard legal case - defining capacity depending on year of build
10:19:38  <V453000> wtf :D
10:19:49  <V453000> why should that not be done by different vehicle
10:20:20  <Alberth> that does not change capacity, year of build is a fixed number
10:20:40  <George> define capacity on year of build
10:20:50  <V453000> but even so why should the vehicle change capacity based on YEAR :D
10:21:05  <V453000> and yeah that isnt a change
10:21:20  <George> Improved technology of build, materials, ect
10:21:32  <V453000> exactly, which is what new vehicles are for?
10:21:58  <George> no. New vehicle would get new vihilce life cycle
10:22:14  <George> While changing props does not
10:22:15  <V453000> problem with that is?
10:22:22  <George> A big one
10:22:29  <V453000> I dont see one
10:22:31  <Alberth> what I mean is that capacity becomes a function of year-of-build. It may different between different wagons, but the capacity is fixed with a wagon, forever
10:23:07  <Alberth> ie no change when you visit a depot, for example
10:23:09  <George> if you donot see something it does not mean it does not exist. It only means you look bad
10:23:25  <Alberth> which is what you seem to aim to do
10:23:30  <V453000> yes therefore I am asking you to reveal it for me ?:D
10:24:24  <George> Alberth: I'm looking for a way to forse change in depot. Currently fail
10:24:54  <George> V453000: wait a little, I'll try to show
10:25:26  <Alberth> George: I know, and I cannot help you, as I don't know the answer either.  I was commenting on your legitimate usecase, which I believe is not a proper usecase
10:25:46  <Alberth> since the capacity does not change when visiting a depot
10:26:11  <Alberth> (since year of build does not change)
10:26:59  <V453000> didnt he say he used day of last service?
10:27:03  <George> Alberth: With year of build everything works fine. It was an example of SAFE use of capacity cagnge over time
10:27:40  <George> And my current problem is that when I use date_of_last_service it does not work as intended
10:27:56  <George> V453000: have a look at
10:28:13  <V453000> I know what life cycle does
10:28:45  <George> if I provide new vehicle instead of changing props, I get 2 problems:
10:29:48  <George> 1) the new vehicle has reduced reliability for 7-38 months (up to 3 years) while in case of changing props it stays on stage 2
10:31:20  <George> 2) I have 2 vehicles with the same name for up to 5 years! I cant remove 1-st vehicle of the list when the 2-nd one appears
10:32:07  <George> and 2b) I can't say when the second one should appear, because a game adds up to 2 years to day of introduction
10:32:18  <George> Do you understand me now?
10:32:20  <V453000> while I majorly disagree with playing with breakdowns on, okay ... still, capacity is probably best done in wagons which dont care about reliability
10:32:37  <V453000> ad2) I totally think there Should be a way for newGRF authors to control that more precisely
10:33:02  <V453000> have exact date of introduction, exact date of retire, perhaps "replaces vehicle X"
10:33:22  <George>
10:33:35  <George> that was suggested long ago
10:33:41  <V453000> I know, I read that
10:33:58  <George> And it is not represented yet
10:34:23  <George> So I have to look for workarounds :(
10:35:19  <V453000> I would just introduce the new vehicle and ignore the old one
10:35:27  <V453000> if the newer vehicle is better, people will use it anyway
10:35:36  <V453000> and the old one can retire in 10 years
10:36:30  <George> And people would look for hundreds of vehicles, waiting for retiring, in a buy menu
10:36:44  <George> can't call it an elegnt solution :)
10:36:52  <V453000> it is functional
10:37:02  <Alberth> issue is stuck on handling preview, afaik
10:38:53  <V453000> which preview?
10:42:30  <Alberth> engine preview
10:42:47  <Alberth> "we have just made a new engine, would you like to try it for a year?"
10:46:00  <George> there must be some way to tel , that THIS vehicle does not require a preview
10:47:44  <Alberth> that won't solve it for the engines that need it
10:48:06  <Alberth> we need some way to say what things are needed together
10:48:28  <V453000> aha :)
10:48:39  <V453000> new news message? :D
10:49:14  <Alberth> at newgrf level :D
11:39:58  <DevZone> Project xussrset - Trains from Russia build #340-push: SUCCESS in 3 min 21 sec:
12:23:10  *** yorick has joined #openttdcoop.devzone
12:27:13  <DevZone> Project 2ccts build #183-push: SUCCESS in 1 min 22 sec:
12:33:27  <DevZone> Project 2ccts build #184-push: SUCCESS in 1 min 24 sec:
13:23:46  <DevZone> Project 2ccts build #185-push: SUCCESS in 1 min 22 sec:
16:41:25  <DevZone> Project road-hog build #239-nightlies: FAILURE in 39 sec:
16:50:58  <DevZone> Project xussrset - Trains from Russia build #341-push: SUCCESS in 3 min 30 sec:
16:51:31  <DevZone> Project Metro Track Set build #11-push: SUCCESS in 33 sec:
16:52:42  <DevZone> Project eints-test (Actual template) build #160-push: SUCCESS in 5 min 15 sec:
16:52:53  <DevZone> Yippee, build fixed!
16:52:53  <DevZone> Project Dutch Trainset build #200-push: FIXED in 1 min 21 sec:
16:53:06  <DevZone> Project termite build #36-push: SUCCESS in 23 sec:
16:54:20  <DevZone> Project 2ccts build #186-push: SUCCESS in 1 min 27 sec:
17:44:26  *** ODM has joined #openttdcoop.devzone
17:53:15  *** ODM has quit IRC
17:53:34  *** ODM has joined #openttdcoop.devzone
18:01:27  * Alberth likes #6236
18:05:40  * Alberth wonders about issue 2685, 3 years seems sufficient time to commit language changes, yes?
18:10:16  *** frosch123 has joined #openttdcoop.devzone
18:10:23  <Alberth> evenink
18:12:53  <frosch123> hai
18:18:35  *** ODM has quit IRC
18:21:16  *** ODM has joined #openttdcoop.devzone
19:43:12  *** Alberth has left #openttdcoop.devzone
20:04:50  *** ODM has quit IRC
20:09:32  <DevZone> Project xussrset - Trains from Russia build #342-push: SUCCESS in 3 min 21 sec:
20:21:53  <DevZone> Project xussrset - Trains from Russia build #343-push: SUCCESS in 3 min 16 sec:
21:27:52  *** frosch123 has quit IRC
21:47:17  *** oskari89 has quit IRC
21:48:59  *** gelignite has quit IRC
22:11:55  *** Supercheese has joined #openttdcoop.devzone
22:48:06  *** Supercheese has quit IRC
23:31:00  *** yorick has quit IRC

Powered by YARRSTE version: svn-trunk