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: https://jenkins.openttdcoop.org/job/2ccts/182/ 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> http://newgrf-specs.tt-wiki.net/wiki/NML:Produce 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> http://devs.openttd.org/~alberth/ogfx-mars-industries.nml 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 ${industry.id}_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> http://dev.openttdcoop.org/attachments/download/6249/YETI.zip 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> http://paste.openttdcoop.org/show/3486/ 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> http://paste.openttdcoop.org/show/3487/ 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 http://newgrf-specs.tt-wiki.net/wiki/NML:Vehicles#Engine_life_cycle 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> https://bugs.openttd.org/task/5086?project=1 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: https://jenkins.openttdcoop.org/job/xussrset/340/ 12:23:10 *** yorick has joined #openttdcoop.devzone 12:27:13 <DevZone> Project 2ccts build #183-push: SUCCESS in 1 min 22 sec: https://jenkins.openttdcoop.org/job/2ccts/183/ 12:33:27 <DevZone> Project 2ccts build #184-push: SUCCESS in 1 min 24 sec: https://jenkins.openttdcoop.org/job/2ccts/184/ 13:23:46 <DevZone> Project 2ccts build #185-push: SUCCESS in 1 min 22 sec: https://jenkins.openttdcoop.org/job/2ccts/185/ 16:41:25 <DevZone> Project road-hog build #239-nightlies: FAILURE in 39 sec: https://jenkins.openttdcoop.org/job/road-hog/239/ 16:50:58 <DevZone> Project xussrset - Trains from Russia build #341-push: SUCCESS in 3 min 30 sec: https://jenkins.openttdcoop.org/job/xussrset/341/ 16:51:31 <DevZone> Project Metro Track Set build #11-push: SUCCESS in 33 sec: https://jenkins.openttdcoop.org/job/metrotrackset/11/ 16:52:42 <DevZone> Project eints-test (Actual template) build #160-push: SUCCESS in 5 min 15 sec: https://jenkins.openttdcoop.org/job/eints-test/160/ 16:52:53 <DevZone> Yippee, build fixed! 16:52:53 <DevZone> Project Dutch Trainset build #200-push: FIXED in 1 min 21 sec: https://jenkins.openttdcoop.org/job/dutchtrains/200/ 16:53:06 <DevZone> Project termite build #36-push: SUCCESS in 23 sec: https://jenkins.openttdcoop.org/job/termite/36/ 16:54:20 <DevZone> Project 2ccts build #186-push: SUCCESS in 1 min 27 sec: https://jenkins.openttdcoop.org/job/2ccts/186/ 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: https://jenkins.openttdcoop.org/job/xussrset/342/ 20:21:53 <DevZone> Project xussrset - Trains from Russia build #343-push: SUCCESS in 3 min 16 sec: https://jenkins.openttdcoop.org/job/xussrset/343/ 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