Back to Home / #openttd / 2014 / 07 / Prev Day | Next Day
#openttd IRC Logs for 2014-07-12

---Logopened Sat Jul 12 00:00:47 2014
00:11-!-KWKdesign [~KWKdesign@pool-108-52-130-213.phlapa.fios.verizon.net] has quit [Read error: Connection reset by peer]
00:11-!-KWKdesign [~KWKdesign@pool-108-52-130-213.phlapa.fios.verizon.net] has joined #openttd
00:42-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd
00:53-!-KWKdesign [~KWKdesign@pool-108-52-130-213.phlapa.fios.verizon.net] has quit [Read error: Connection reset by peer]
00:53-!-KWKdesign [~KWKdesign@pool-108-52-130-213.phlapa.fios.verizon.net] has joined #openttd
00:53-!-DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
00:56-!-Eddi|zuHause [~johekr@p5DC660F6.dip0.t-ipconnect.de] has quit []
00:56-!-Eddi|zuHause [~johekr@p57BD4806.dip0.t-ipconnect.de] has joined #openttd
01:05-!-Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has quit [Remote host closed the connection]
01:05-!-DabuYu [DabuYu@128.250.79.238] has joined #openttd
01:07-!-HerzogDeXtEr [~flex@88.130.181.244] has quit [Quit: Leaving.]
01:18-!-DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer]
01:20-!-Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has joined #openttd
01:26-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth]
01:28<V453000>HOLY SHIT:D BREAKING SURPRISING NEWS!!! :D planetmaker , I managed to setup TortoiseHg to communicate with YETI repository :D myself, without annoying anybody else for a whole afternoon :D
01:38-!-DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
01:43-!-Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has quit [Remote host closed the connection]
01:48-!-DabuYu [DabuYu@128.250.79.238] has joined #openttd
02:16-!-DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
02:20-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd
02:21<andythenorth>V453000: been playing this game (Township) with child #1
02:21<andythenorth>http://roma-n.deviantart.com/art/Township-buildings-257183049
02:21<andythenorth>it’s a nice style
02:21<andythenorth>also moin
02:23-!-DabuYu [DabuYu@128.250.79.238] has joined #openttd
02:26-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth]
02:28<V453000>very nice buildings :)
02:31-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd
02:40-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Ping timeout: 480 seconds]
02:49-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd
02:51-!-DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
02:55<andythenorth>hmm
02:57-!-Pensacola [~quassel@h220216.upc-h.chello.nl] has joined #openttd
03:05-!-DabuYu [DabuYu@128.250.79.238] has joined #openttd
03:17-!-Yotson [~Yotson@2001:980:6ac8:1:dce2:37fa:b18f:3243] has joined #openttd
03:25<@planetmaker>moin moin
03:26<@planetmaker>V453000, congratz :)
03:27<@planetmaker>andythenorth, those buildings look like they would make an awesome townset for OpenTTD :)
03:27<@planetmaker>it looks even correct tile size
03:29-!-Pol [~quassel@h220216.upc-h.chello.nl] has joined #openttd
03:34-!-Pensacola [~quassel@h220216.upc-h.chello.nl] has quit [Read error: Operation timed out]
03:37-!-DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
03:48-!-Pensacola [~quassel@h220216.upc-h.chello.nl] has joined #openttd
03:50-!-DabuYu [DabuYu@128.250.79.238] has joined #openttd
03:56-!-Pol [~quassel@h220216.upc-h.chello.nl] has quit [Ping timeout: 480 seconds]
04:13-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
04:13<andythenorth>planetmaker: it is very visually cute, 32bpp done right imo
04:13<andythenorth>game is a standard pay-for-downloadable-content casual game
04:14<andythenorth>everything is ‘level up’, ‘get more citizens'
04:14<andythenorth>etc
04:14<@planetmaker>ah, the usual free-to-play but spend shitload of $$$ on convenience? :)
04:15<andythenorth>yup
04:15<andythenorth>gold and dollars
04:15<andythenorth>big arrows show you what to build or click next
04:15<@planetmaker>anyhow, I wonder whether they would loan the graphics to openttd :P
04:15<andythenorth>zero strategy
04:17<andythenorth>planetmaker: can I interest you in my string ID problem? :P
04:17<andythenorth>np if busy
04:17-!-Pol [~quassel@h220216.upc-h.chello.nl] has joined #openttd
04:18-!-DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
04:19<@planetmaker>I'm loosely aware of the issue, though not yet what are the obstacles. Though I fear this weekend is again quite busy, with real life
04:19<andythenorth>this is the way
04:19<@planetmaker>so what are the obstacles?
04:21<andythenorth>probably easier to explain the goal
04:21-!-Progman [~progman@p57A18B80.dip0.t-ipconnect.de] has joined #openttd
04:21<andythenorth>obstacle is andythenorth isn’t sure he’s read the code correctly
04:21<andythenorth>currently nmlc assigns strings random IDs afaict, unless it’s an ottd string
04:21<andythenorth>in action4.py
04:21<andythenorth>I want to write them to a file, using that as a cache on the next compile
04:22<andythenorth>that’s not particularly hard in python, but I need to be sure I’ve understand the ID assignment correctly
04:22-!-Pensacola [~quassel@h220216.upc-h.chello.nl] has quit [Read error: Operation timed out]
04:23<@planetmaker>I don't think nml's assignment of IDs is mathematically random. But rather it will start at the eligible range base and enumerate them sequentially, I think
04:23<andythenorth>that would make total sense
04:23<@planetmaker>probably in the order it encounters / needs them. Not sure, though
04:23<andythenorth> # ID is allocated randomly, we will output the actions later
04:23<andythenorth>but might just mean ‘sequentially'
04:24<@planetmaker>oh :)
04:24<andythenorth>I would have done sequentially, trivial to guarantee unique
04:24<andythenorth>I didn’t look at the actual assignment code yet
04:25<@planetmaker>I know what it does for (var)action2IDs: it starts at base and then pushes and pops from stack as they are needed or freed
04:26<andythenorth>makes sense
04:26<@planetmaker>and my openttd crashed on me :(
04:32-!-Pensacola [~quassel@h220216.upc-h.chello.nl] has joined #openttd
04:32-!-DabuYu [DabuYu@128.250.79.238] has joined #openttd
04:35<Rubidium>isn't the randomly more to give the user no guarantees of a particular order?
04:36<@planetmaker>Rubidium, yup :)
04:36-!-Pol [~quassel@h220216.upc-h.chello.nl] has quit [Ping timeout: 480 seconds]
04:36<@planetmaker>the ordering of items should not be exposed to the user (easily)
04:39<Rubidium>also... why am I procrastinating so much today?
04:39<@planetmaker>why not? weekend?
04:40<Rubidium>well... maybe not "today" but rather "last weeks"
04:41<@planetmaker>meh, this is annoying. I try to report a bug and the website is constantly reset when I press 'submit'
04:43-!-Alberth [~hat@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd
04:43-!-mode/#openttd [+o Alberth] by ChanServ
04:44<SpComb>the evil bit is set on your request
04:44<@Alberth>apparently
04:45<@planetmaker>anyhow... with YETI and NoCarGoal I get in roughly one out of five map generation attempts: Error: Assertion failed at line 81 of /home/planetmaker/ottd/trunk/src/script/api/../../cargomonitor.h: ctype < (1 << CCB_CARGO_TYPE_LENGTH)
04:46<@planetmaker>the flyspray bug is more reproducable, TrueBrain. It resets the connection when I try to post a bug
04:48-!-Pol [~quassel@h220216.upc-h.chello.nl] has joined #openttd
04:48-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds]
04:49<Rubidium>looks like the data from the scripts is going without ANY checks into openttd itself
04:49<Rubidium>especially a cargoid that's bigger than the highest allowed cargoid
04:50*Rubidium pokes Alberth 'bout that ;)
04:51<@Alberth>hmm, not enough coffee yet
04:52<andythenorth>it’s the middle of the day! :o
04:52<andythenorth>how can you have not drunk coffee yet!
04:53*andythenorth has been awake 5 hours or more
04:53<andythenorth>bed time soon
04:54<@planetmaker>V453000, your industries miss destinctive ground tiles quite dearly :)
04:55-!-Pensacola [~quassel@h220216.upc-h.chello.nl] has quit [Read error: Operation timed out]
04:55<@planetmaker>e.g. a rendering of them without the buildings :)
05:00<andythenorth>meh https://dev.openttdcoop.org/issues/6992
05:00-!-JGR_ [~JGR@host81-151-237-165.range81-151.btcentralplus.com] has joined #openttd
05:01<@planetmaker>he :)
05:01-!-JGR [~JGR@host81-156-244-200.range81-156.btcentralplus.com] has quit [Ping timeout: 480 seconds]
05:02-!-George|2 [~George@185.43.94.91] has joined #openttd
05:02-!-George is now known as Guest2322
05:02-!-George|2 is now known as George
05:02-!-George|2 is "(unknown)" on (unknown)
05:04<@Alberth>not enough != none :)
05:09-!-kero [~keikoz@37.175.23.202] has joined #openttd
05:17-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
05:26-!-Jomann [~abchirk@p57A099B9.dip0.t-ipconnect.de] has joined #openttd
05:47-!-tokai|mdlx [~tokai@port-92-195-42-97.dynamic.qsc.de] has joined #openttd
05:52-!-tokai|noir [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
05:52-!-Wolf01 [~wolf01@0001288e.user.oftc.net] has joined #openttd
05:53<@Alberth>hi hi
05:53<Wolf01>hello o/
06:02-!-Progman [~progman@p57A18B80.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
06:06-!-DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
06:10-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth]
06:17-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds]
06:17-!-MJP [~mjp@hq.z77.fr] has joined #openttd
06:19-!-frosch123 [~frosch@frnk-5f747724.pool.mediaWays.net] has joined #openttd
06:23-!-gelignite [~gelignite@i5387A7CA.versanet.de] has joined #openttd
06:37-!-Brumi [~quassel@78-131-41-191.pool.digikabel.hu] has joined #openttd
06:45-!-DabuYu [DabuYu@128.250.79.238] has joined #openttd
07:01-!-Pensacola [~quassel@h220216.upc-h.chello.nl] has joined #openttd
07:08-!-Pol [~quassel@h220216.upc-h.chello.nl] has quit [Ping timeout: 480 seconds]
07:12-!-Pol [~quassel@h220216.upc-h.chello.nl] has joined #openttd
07:18-!-Pensacola [~quassel@h220216.upc-h.chello.nl] has quit [Ping timeout: 480 seconds]
07:26-!-Stimrol [~Stimrol@46-239-219-51.tal.is] has joined #openttd
07:29-!-Pensacola [~quassel@h220216.upc-h.chello.nl] has joined #openttd
07:29-!-yorick [~yorick@ip51cd0513.speed.planet.nl] has joined #openttd
07:31-!-Supercheese [~Superchee@76.178.136.186] has quit [Read error: Connection reset by peer]
07:31-!-Supercheese [~Superchee@76.178.136.186] has joined #openttd
07:35-!-Pol [~quassel@h220216.upc-h.chello.nl] has quit [Ping timeout: 480 seconds]
07:37-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd
07:37-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit []
08:02-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
08:14-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds]
08:15-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
08:21<@DorpsGek>Commit by alberth :: r26684 trunk/src/cargomonitor.cpp (2014-07-12 12:21:40 UTC)
08:21<@DorpsGek>-Doc: Improve Doxygen markup with a few links to a constant and functions.
08:29-!-Pol [~quassel@h220216.upc-h.chello.nl] has joined #openttd
08:31-!-Pensacola [~quassel@h220216.upc-h.chello.nl] has quit [Read error: Operation timed out]
08:38-!-Pensacola [~quassel@h220216.upc-h.chello.nl] has joined #openttd
08:42-!-Pol [~quassel@h220216.upc-h.chello.nl] has quit [Ping timeout: 480 seconds]
08:46-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd
08:59<@Alberth>o/
09:02<andythenorth>o/
09:03<andythenorth>I could extend the lang file format to put the string IDs in
09:03<andythenorth>but it would be fugly I think
09:03<@peter1138>So... hot...
09:04<andythenorth>I could mash the string IDs into global constants somehow
09:04<andythenorth>also
09:06<@Alberth>why not just number sequentially ?
09:06<@Alberth>or use the line number or so
09:07<@Alberth>use the string name as constant ?
09:09-!-Pol [~quassel@h220216.upc-h.chello.nl] has joined #openttd
09:12<andythenorth>none of those are stable across partial compiles ;)
09:14-!-Pensacola [~quassel@h220216.upc-h.chello.nl] has quit [Ping timeout: 480 seconds]
09:16-!-Stimrol [~Stimrol@46-239-219-51.tal.is] has quit [Remote host closed the connection]
09:20<andythenorth>the only methods I can think of are (a) cache nmlc-defined IDs across compiles (b) author-defined IDs
09:21<andythenorth>maybe we could hash the string name or something, but I doubt it :)
09:24<kero>andythenorth : have you already thought about reestablishing primary industries closure ? (and eventually, even BLACK_HOLE's ?)
09:24<andythenorth>?
09:24<kero>speaking about FIRS :)
09:26<andythenorth>urgh
09:26<andythenorth>I need to branch Iron Horse
09:26<andythenorth>I hate hg branching
09:26<andythenorth>no good reason
09:26-!-Pensacola [~quassel@h220216.upc-h.chello.nl] has joined #openttd
09:29<@Alberth>you want to edit the language file between compiles?
09:29<andythenorth>possibly
09:30<andythenorth>let’s assume yes, otherwise I don’t know how to change strings :)
09:30<@Alberth>change a string, recompile all :)
09:31<andythenorth>ok, so the compile could take care of that by checking the lang file for changes
09:31<@Alberth>but if you don't move strings in the file their line number stays the same
09:31<andythenorth>this is a good point
09:32<@Alberth>unless the length of a string is also of importance but then you're probably dead with each change
09:32<andythenorth>should work across all languages too afaict
09:32-!-Pol [~quassel@h220216.upc-h.chello.nl] has quit [Ping timeout: 480 seconds]
09:32<andythenorth>I think only the ID is significant here
09:32<andythenorth>so maybe the parser could take care of this
09:33<@Alberth>just use english as the defining language
09:34<@Alberth>I would expect a line number or position or so with a STR_* name while reading a lang file
09:34*andythenorth is looking for lang file parser
09:36<@Alberth>nml/grfstrings line 1185
09:37<@Alberth>for idx, line in enumerate(f) 1198
09:37<andythenorth>pos is line number?
09:37<@Alberth>looks that way,
09:38<@Alberth>starts with line 1 though
09:38<@Alberth>and it has gaps of course, and the first string is not at line 1
09:41-!-Stimrol [~Stimrol@46-239-219-51.tal.is] has joined #openttd
09:44<andythenorth>might be best to just increment a counter for every string seen?
09:44<andythenorth>and assume the order is deterministic?
09:47<@Alberth>for loop over a file is quite deterministic :)
09:47-!-pthagnar [~pthagnar@cpc7-pres17-2-0-cust28.18-3.cable.virginm.net] has joined #openttd
09:47<andythenorth>is the file load order deterministic?
09:48<andythenorth>wondering if they get shoved in a dict or something
09:48<@Alberth>probably not, but use the default language?
09:48<@Alberth>list of files gets pulled from the disk, no idea how fixed that order is
09:48<@planetmaker>andythenorth, if you hate hg branches, you should use bookmarks. That's maybe more what you like
09:49<@planetmaker>bookmarks are not necessarily persistant while branches are
09:49<andythenorth>‘hate’ is probably unfair
09:49<@Alberth>there is only one default language
09:49<andythenorth>I think it’s because I was taught to never merge hg
09:50<@planetmaker>that's bullshit, andythenorth :) Merge like you want
09:50<@planetmaker>but for development branches, better use unnamed branches (just add another head)
09:50<@planetmaker>if they're supposed to be transient
09:51<andythenorth>in this case probably valid to be named
09:51<@planetmaker>no-merging is just for those who want an svn-linear history
09:51<andythenorth>add an unnamed head :O
09:51<@planetmaker>yeah. git is inferior
09:51<andythenorth>I thought that was the worst crime :O
09:51<@planetmaker>no need to attach a name to things ;)
09:51<@planetmaker>depends on how you want to use it really
09:52<@planetmaker>CF will get confused. It will build the newest head from default branch
09:52<@planetmaker>I usually attach a bookmark to heads I want to remember
09:52<@planetmaker>and I only use named-branches for major-versions to backport stuff to
09:53<@planetmaker>anyway: forget the no-merges thing. That's nonsense
09:53<andythenorth>:)
09:53<andythenorth>so string IDs - increment a counter for each seen, use that for ID
09:53<andythenorth>there’s some stuff for allowed ranges to handle
09:54<andythenorth>IDs will be consistent until lang file changes
09:54<andythenorth>if lang file changes, a full compile is forced (not partial)
10:01<@Alberth>you do realize that changing the contents only of a string is also a lang file change, right?
10:01<andythenorth>yes
10:01<@Alberth>ok
10:02<andythenorth>I’d probably just read the timestamps on the file
10:02<andythenorth>I already do that in places for faster compiles
10:02<@planetmaker>then you should look at make :P
10:03*planetmaker is today responsible for tangential remarks at best
10:03<andythenorth>you’re not the first person to say it
10:03<andythenorth>pretty much everyone has said it :)
10:03<andythenorth>but make involves learning make and asking for help
10:03<andythenorth>whereas doing it in python just…worked
10:03<andythenorth>in about 1 hour
10:04<@planetmaker>target: list of files it depends on
10:04<@planetmaker>\t rule line1
10:04<@planetmaker>\t rule line2
10:04<andythenorth>I’m never quite convinced by the ‘do it properly’ rule
10:04<andythenorth>seems to lead to less shipping in my experience
10:05<@planetmaker>well... make solves this in those 3 lines ;)
10:07<@planetmaker>all it does is: I shall build target. Is one of the dependencies newer than target or target non-existing? Then execute the rules to build target
10:07<@planetmaker>and syntax is bash basically
10:09<@Alberth>I already supplied a 3 step tutorial to andy once :)
10:09<@Alberth>it didn't work :)
10:10<andythenorth>maybe I could generate the makefile with python
10:10<@Alberth>lol
10:11<andythenorth>well python has the list of files
10:11<andythenorth>manually putting them all into the makefile seems a bit quaint
10:11<andythenorth>make -> python -> make ->
10:11<andythenorth>dynamically changing the makefile while it’s running will be fine, right?
10:12<@Alberth>sounds very over-complicated to me
10:15<andythenorth>anyway I should figure out this string problem
10:16<andythenorth>although I’m kind of wondering how much time to spend saving time
10:16<andythenorth>and it’s going to involve a personal fork of nml, with a load of compile farm hassle too
10:16<andythenorth>maybe a waste of time
10:20<andythenorth>is there a way to write nml to be faster?
10:20<andythenorth>can I share all the switches so that there is less to parse?
10:21<andythenorth>currently every FIRS industry has a full production chain
10:21<andythenorth>and a full snowline, location aware etc chain
10:21<andythenorth>maybe they could all be done with one set of switches, shared across industries
10:24<@Alberth>implement procedures? :)
10:25<andythenorth>maybe
10:25<andythenorth>but I never saw the point of procedures
10:25<andythenorth>varact 2 with a unique ID is global anyway
10:25<andythenorth>I’m sure I am just badly educated :)
10:26<@Alberth>newgrf has many global IDs
10:27*andythenorth thinks of horrible
10:28<andythenorth>hmm
10:28<andythenorth>FIRS uses 33s just for the python step
10:28<andythenorth>it doesn’t use any multi-processing
10:28-!-Alberth [~hat@2001:981:c6c5:1:be5f:f4ff:feac:e11] has quit [Quit: Leaving.]
10:29<andythenorth>maybe I can faster it there
10:29-!-Pol [~quassel@h220216.upc-h.chello.nl] has joined #openttd
10:29-!-Alberth [~hat@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd
10:29-!-mode/#openttd [+o Alberth] by ChanServ
10:29<andythenorth>a short break
10:29<@Alberth>more a irc program crash
10:30<andythenorth>ok 3m to compile FIRS
10:30<@Alberth>or rather an irc program kill request, as it didn't work any more
10:30<andythenorth>I can probably get about 20s off that by improving python templating phase
10:31<@Alberth>you have a PM from British trains Dave
10:31<andythenorth>a single industry compile is 17s
10:31<andythenorth>so I do
10:33-!-Pensacola [~quassel@h220216.upc-h.chello.nl] has quit [Read error: Operation timed out]
10:33<andythenorth>I guess if I want to keep working on FIRS, single industry compile is worth doing properly
10:34<andythenorth>otherwise it’s too slow to bother doing anything on
10:36-!-HerzogDeXtEr [~flex@88.130.184.189] has joined #openttd
10:45-!-DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
10:58<andythenorth>multiprocessing python templating saves 10s
10:58<andythenorth>meh
10:59-!-romazoon [romazoon@95-9.195-178.cust.bluewin.ch] has joined #openttd
11:08-!-DabuYu [DabuYu@128.250.79.238] has joined #openttd
11:11-!-efess [~Efess@c-24-61-64-170.hsd1.ct.comcast.net] has quit [Ping timeout: 480 seconds]
11:12-!-Mucht [~Martin@000128e2.user.oftc.net] has quit [Remote host closed the connection]
11:15-!-Pulec [pulec@unaffilated.amunak.net] has quit [Remote host closed the connection]
11:17-!-Pulec [pulec@unaffilated.amunak.net] has joined #openttd
11:20-!-User [~chatzilla@2a02:8070:4c0:5b00:a8bf:693f:dbb8:abd] has joined #openttd
11:21-!-User is now known as Guest2363
11:22<Guest2363>Hello, i'm started playing openttd and I like it very much. But I quested my self if there is a possibility to play city builder offline with AI opponents?
11:24-!-Pensacola [~quassel@h220216.upc-h.chello.nl] has joined #openttd
11:25<@Alberth>there are a couple of city build game scripts that you can use
11:25<@Alberth>no idea if an AI understands such a script, my guess is it doesn't
11:28<andythenorth>print [cargo for cargo in cargo_list if cargo is not "SGCN"]
11:28<andythenorth>results in
11:28-!-Pol [~quassel@h220216.upc-h.chello.nl] has quit [Read error: Operation timed out]
11:28<andythenorth>['GRAI', 'SGBT', 'SGCN']
11:28<andythenorth>which is odd
11:29<Guest2363>ok i only was able to find outdated AI threads in the forum. Can you recommend any AI for playing offline in general ?
11:29<andythenorth>this is newly introduced bug due to use of pool.map to call a function
11:29<@Alberth>value equality is not object equality
11:29<@Alberth>ie use != to compare values
11:30<@Alberth>Guest2363: http://wiki.openttd.org/Comparison_of_AIs
11:31<@Alberth>there are also game scripts that set goals for you to achieve
11:31<@Alberth>nocargoal and silicon valley at least
11:31<@Alberth>might be of interest if you are a goal player
11:32<Eddi|zuHause>andythenorth: you sure "is" is the right operator?
11:32<andythenorth>no :P
11:32<Eddi|zuHause>i'd try "!="
11:32<andythenorth>thanks
11:32<andythenorth>I like list comprehensions a lot, but doing comparisons in them feels wrong for some reason
11:32<Eddi|zuHause>also, maybe cargolist.filter()
11:32<andythenorth>anyway that works
11:33<andythenorth>I wonder why that bug only showed up with multiprocessing pool
11:33<andythenorth>it’s a year old, but has been compiling fine
11:33<Guest2363>I already saw this site, but it only give informations about the functionality of the AI's, form this point of view NoCAB is the best, but on the last page of the thread form NoCAB is written that there ware no patches in recent times
11:34<Eddi|zuHause>so?
11:34<Eddi|zuHause>what is "recent" or "outdated" in your opinion?
11:35<Guest2363>The author said other AI's had major improvements in comparison to NoCAB, so I assumed that there are better AI's
11:36<@Alberth>no idea really, I never play with or against AIs
11:36<@Alberth>just download a few and try them
11:37<@Alberth>the worst thing that can happen is that you have to play more OpenTTD
11:38<@Alberth>also "better" has many dimensions
11:40<@planetmaker>Guest2363, I haven't seen anything new with most AIs for quite some time.
11:40<@planetmaker>Those we have work, though. Better is subjective and on your game goal
11:42-!-Pensacola [~quassel@h220216.upc-h.chello.nl] has quit [Remote host closed the connection]
11:42-!-frosch123 [~frosch@frnk-5f747724.pool.mediaWays.net] has quit [Ping timeout: 480 seconds]
11:43<andythenorth>Eddi|zuHause: (in case I’m missing something obvious) did you have a trick to ensure consistent string IDs in CETS?
11:43<andythenorth>in the partial compile patch you had...
11:44<Eddi|zuHause>andythenorth: yes. i put a giant switch in the beginning that references all strings
11:44<Eddi|zuHause>well, the ones that need an ID
11:44<Guest2363>ok thanks for your advice, I will just try a few
11:44<andythenorth>and that’s deterministic as long as lang file is unchanged?
11:45-!-Guest2363 [~chatzilla@2a02:8070:4c0:5b00:a8bf:693f:dbb8:abd] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]]
11:45<Eddi|zuHause>that is deterministic, yes
11:45<andythenorth>awesome
11:45<andythenorth>I can just do that then
11:45<andythenorth>I have all the strings in scope in python anyway
11:45<Eddi|zuHause>as long as every partial file has that same switch inside it
11:45<Eddi|zuHause>and you remove it before combining
11:47-!-Progman [~progman@p57A18B80.dip0.t-ipconnect.de] has joined #openttd
11:50<andythenorth>ok so I need to split that from the nfo
11:50<andythenorth>wonder if I could just split on it
11:50<Eddi|zuHause>well you can leave it in
11:51<Eddi|zuHause>but it won't do anything useful
11:51<andythenorth>do you have to reference the switch anywhere?
11:51<andythenorth>nml will drop it otherwise? Or just warn?
11:52<Eddi|zuHause>not sure. i reference it from a dummy vehicle that i also remove
11:52<andythenorth>makes sense
11:53<andythenorth>it’s clunky, but patching nml for consistent strings got boring
11:53<andythenorth>I’ll try it
11:53<Eddi|zuHause>my method of removing involves the "comment" patch, which is included in eddi-nml
11:54<andythenorth>makes sense too
11:54<Eddi|zuHause>which i should probably update
11:54<Eddi|zuHause>but i'm afraid of python3
11:58<andythenorth>:)
12:03<andythenorth>utils.parse_base_lang() is my friend apparently
12:03<andythenorth>I should dig out my partial compile branch
12:04<@planetmaker>Eddi|zuHause, don't be afraid. Probably it works if you obtain the diff and apply it to current nml. Or merge, if you want
12:04<@planetmaker>after all... we have a dvcs. Make use of decent merges to save work ;)
12:05<Eddi|zuHause>planetmaker: it's not the merging i'm afraid
12:05<Eddi|zuHause>of
12:06<Eddi|zuHause>that's usually a "pull -u, commit, push"
12:06<Eddi|zuHause>(where pull operates on the original nml repo, and push on the eddi-nml repo)
12:07<Eddi|zuHause>i'm afraid of missing and hunting down libraries
12:07<andythenorth>I am afraid of making a new virtualenv that actually works :)
12:07<andythenorth>especially because my compile is python 2
12:08<@Alberth>virtualenv stuff is in stdlib in python3
12:08<@Alberth>didn't look at it though
12:11-!-DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
12:11<andythenorth>do we use PIL or Pillow?
12:11<andythenorth>that’s the main scare
12:11<andythenorth>building PIL can involve an adventure into breaking freetype and all kinds of crap
12:13*Alberth uses Pillow
12:14<@Alberth>but for NML either should be fine
12:15<andythenorth>ta
12:16<andythenorth>Eddi|zuHause: got a link to this switch in CETS repo? o_O
12:17<Eddi|zuHause>andythenorth: try looking for "__DUMMY_CODE"
12:18<Eddi|zuHause>"ImportError: No module named 'ply'" i was afraid of that
12:19<@Alberth>just copy the existing ones, or download a new version
12:19<@Alberth>it's pure python, and handles both 2 and 3
12:20-!-DabuYu [DabuYu@128.250.79.238] has joined #openttd
12:20<Eddi|zuHause> File "/home/johannes/.openttd/dbs/nml/nml/ast/comment.py", line 31
12:20<Eddi|zuHause> print indentation*' ' + 'Comment:'
12:20<Eddi|zuHause> ^
12:20<Eddi|zuHause>SyntaxError: invalid syntax
12:20<@Alberth>yes, I replaced all of them :)
12:21<@Alberth>generic.print_dbg(indentation, 'Assignment')
12:22<@Alberth>s/Assignment/Comment/ in your case
12:22<Eddi|zuHause>well that i figured out :p
12:22<@Alberth>:D
12:23<andythenorth>is there a reason the comments patch isn’t committed?
12:23<xintron>I'm thinking of testing out FIRS on my server. Is there any other GFR that should be used as wel lwith firs?
12:24<@Alberth>xintron: some newgrf that switches on support for other than default cargoes
12:24-!-Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has joined #openttd
12:26-!-oskari89 [oskari89@83-102-63-32.bb.dnainternet.fi] has joined #openttd
12:30<kero>andythenorth : should I conclude from you non answering, that the answer is "no" ? :) I were asking you that, because I'm changing the code of FIRS on that purpose (for me).
12:30<andythenorth>closing primary industry was available in older FIRS and removed
12:31<andythenorth>I don’t understand the black hole question
12:31<@planetmaker>Eddi|zuHause, what distru do you use? And anyhow, it didn't turn out to teach python3-nml also to debian or fedora
12:31<kero>I know. I was sad that it was removed, hence I'm putting back the functionality. As an option. I was wondering if it might interest you.
12:32<kero>About BLACK_HOLE, those are all the industries which only receives cargo and dont produce anything. Those industries also don't close.
12:32<@planetmaker>xintron, you must use FIRS with vehicle NewGRFs
12:32<@planetmaker>default vehicles won't support FIRS cargoes. So choose aircraft, road vehicles, trains and ship sets of your choice
12:33<@planetmaker>i.e. use av8 and FISH for air and sea
12:33<@planetmaker>road and rail is more diverse
12:33<kero>andythenorth : and as a side note, I noticed that Bulk Terminal, Port and Trading Post are identified as BLACK_HOLE's industries, while there are not :p Maybee a bug ?
12:34<andythenorth>might be
12:34<andythenorth>can’t remember
12:34<xintron>planetmaker, ok, thanks :)
12:34<andythenorth>closing industries is considered a BAD FEATURE
12:34<andythenorth>it breaks openttd-coop play
12:35<kero>well I suppose it can be supposed a bad feature in some game spirit, not necesserily for everyone :)
12:36<kero>Anyway, for me, I'm coding it just as an option.
12:36<andythenorth>have you found where to do it?
12:36<kero>Sure. It's already done. I'm testing the code.
12:36<andythenorth>ok
12:37<@planetmaker>closing served industries is annoying in all game types
12:37<kero>not served
12:37<Eddi|zuHause>planetmaker: what do you mean?
12:37<Eddi|zuHause>i use opensuse
12:37<kero>planetmaker : I'm reemplementing it as a way to close UNserved industries
12:37<Eddi|zuHause>not sure what the other half of the sentence means
12:37<andythenorth>kero if closure suits you, then adding it yourself is a good solution ;)
12:38<@Alberth>kero: usually that happens just after laying tracks, and before my first train with cargo arrives :)
12:38<Eddi|zuHause><andythenorth> is there a reason the comments patch isn’t committed? <-- concerns about being "the wrong thing" wrt future ability to reorder things internally for optimization purposes
12:39<kero>andythenorth : no problem about that. I was just wondering if it could interest you to add that option and in this case I would have tried to make a patch. But I think I have my answer :)
12:39<andythenorth>I wonder if I can split reliably on a dummy vehicle block?
12:39<andythenorth>kero ;)
12:40<Eddi|zuHause>andythenorth: you need something that you know the NFO output of and that cannot be generated by anything else
12:40<@Alberth>kero: I wonder why this improves game play for you
12:40<kero>it avoids having the industry number increasing all the time
12:40<andythenorth>Eddi|zuHause: a vehicle with ID supplied will result in deterministic nfo?
12:40<@Alberth>you just get the same industries back a bit later, right?
12:41<Eddi|zuHause>possibly
12:41<kero>Alberth : in the actual situation, on a long game, industries' number increases a lot
12:42<kero>I started a game with ~490 and 30 years later, I had 667. I don't like to see the map been filled to much :)
12:42<andythenorth>wtf, I thought my grfcodec was fixed :(
12:42<@planetmaker>kero, you tested that with FIRS or without any NewGRF?
12:43<andythenorth>dyld: Library not loaded: /opt/local/lib/libpng14.14.dylib
12:43<kero>planetmaker : both.
12:43<kero>the 490->667 were with FIRS
12:43<@Alberth>170 in 30 years sounds like a lot to me
12:44<kero>To me too. But I can give you the savegames if you want count it by yourself :)
12:44<@Alberth>how big is the map?
12:44<kero>1024*1024
12:44<@Alberth>firs full economy?
12:44<Eddi|zuHause>"Error: (AttributeError) "'module' object has no attribute 'Unit'"." what did i do wrong?
12:44<@Alberth>that will give you a lot of industry types
12:44<kero>But. As a side note: industries were created in scenario mode.
12:44<kero>Yes, full Firs economy
12:45<@Alberth>Eddi|zuHause: I rewrote that part
12:45<@Alberth>unit.py
12:45<@planetmaker>kero, so it's not an auto-generated amount?
12:46<@planetmaker>thus the existing amount is too low for the selected industry density
12:46<@Alberth>you didn't add some of the industries?
12:46<kero>To be clear: I created the firs 490 in scenario mode. And then, the game itself created the other ones while in game
12:46<@planetmaker>and then, if course, openttd tries to reach the selected industry density ingame
12:46<kero>planetmaker : no, its Not.
12:46<@planetmaker>possibly it sounds like you want to change openttd to allow another industry density setting. Instead of what you do now
12:46<kero>industry creation for that industry-density is 400 for a 1024*1024
12:47<@Alberth>planetmaker: not afaik, it takes the current number and continues from there
12:47<kero>I checked that.
12:47<kero>(low density)
12:47<kero>and 160 for very low industry_density
12:48<Eddi|zuHause>how to get a normal python backtrace out of nmlc again, instead of this wrapper thing?
12:48<@Alberth>the only explanation I have is that the manually added industries didn't match with the probabilities in the firs grf
12:48<@Alberth>Eddi|zuHause: -s
12:49<@Alberth>so the game tries to fix that
12:50<@Alberth>an interesting experiment could be to see what the 400 industries do in 30 years
12:51<kero>Ok. In another game, with absolutely no scenario development, with FIRS, started with industry_density = 3, the result was: 392 in 1860, 485 in 1876, and 526 in 1884.
12:51<kero>I tell you: I did a LOT of tests.
12:51<Diablo-D3>heh
12:51<Diablo-D3>it must be hard to do openttd before 1920
12:51<kero>There defintely is a huge industry increase in-game.
12:51<kero>most visible on long term games.
12:52<Eddi|zuHause>Alberth: i probably merged that file the wrong way...
12:52<kero>in that game, I did'nt to ANY change. Just sit and watch.
12:53<@Alberth>if you start with manually placed industries, you may want to use a lower industry density setting, I would think that affects growth too
12:53-!-Pereba [~UserNick@187.59.170.215] has quit [Quit: bye]
12:54-!-Pereba [~UserNick@187.59.170.215] has joined #openttd
12:55<kero>It does indeed. It even can trigger some decrease (only for closable industries, that mean, PROCESSING types)
12:56<andythenorth>Eddi|zuHause: do you happen to have CETS nml lying around on your filesystem?
12:56<Eddi|zuHause>andythenorth: ?
12:56<Eddi|zuHause>andythenorth: devzone->eddi-nml
12:57<andythenorth>sorry, I mean the actual nml file for CETS
12:57<Eddi|zuHause>oh
12:57<Eddi|zuHause>what do you need?
12:57<andythenorth>the dummy switch
12:57<Eddi|zuHause>andythenorth: that should be on devzone as well
12:57<andythenorth>I can reconstruct it by parsing the generator in my head
12:57<Eddi|zuHause>i have probably posted it on paste a while ago
12:58<andythenorth>maybe bundles has it
12:58<andythenorth>I’ll just reconstruct it, was being lazy
13:00<MTsPony>question dudes. does the savegame_format also affect runtime cpu usage of a openttd server?
13:00<MTsPony>atm the map size is like 15mb
13:00<Eddi|zuHause>MTsPony: no
13:00<MTsPony>kk
13:00<Eddi|zuHause>only during autosaves
13:01<Eddi|zuHause>(or manual saves)
13:01<MTsPony>but, someone loading into the server has to download the real time map right? isnt that a save game too?
13:01<Eddi|zuHause>(or people joining)
13:02<Eddi|zuHause>MTsPony: but the game should be paused during that phase
13:03<MTsPony>another quicky, for some reason using the savegame threaded option to true, the damn thing still wont use the second core i assigned to vmware :/ so it stalls the original openttd process till its done
13:03<Rubidium>it affects the CPU usage of a server whenever saving or loading (although then it's the format at which is was saved)
13:03<Eddi|zuHause>MTsPony: if you use a less intensive compression method, you waste more time waiting for the bigger file to go through the thin pipe
13:03<MTsPony>usin lzma:2 atm
13:03<MTsPony>i dont get why its not using my second assigned core tho :/
13:04-!-gelignite [~gelignite@i5387A7CA.versanet.de] has quit [Quit: http://bit.ly/nkczDT]
13:04<@DorpsGek>Commit by alberth :: r26685 /trunk/src (6 files in 3 dirs) (2014-07-12 17:04:14 UTC)
13:04<@DorpsGek>-Fix: Tighten parameter bound checks on GSCargoMonitor functions, and return -1 on out-of-bound parameters.
13:04<andythenorth>get_global_string_actions looks interesting
13:04<andythenorth>in nml/actions/action4.py
13:06-!-efess [~Efess@c-24-61-64-170.hsd1.ct.comcast.net] has joined #openttd
13:06<Rubidium>MTsPony: first and foremost... the saving of a game first requires cloning the whole game state before compressing it. If the compressed map size is 15 MB, then the uncompressed size is significantly larger and as such "cloning" that data takes time at which the game can't run
13:07<MTsPony>gotcha
13:07<Rubidium>to be honest, it doesn't really clone but creates an in-memory uncompressed savegame before running the compression asynchroniously. Making this in-memory savegame can just take a lot of time
13:08<MTsPony>any suggestions for threaded_saves = true refuses to work?
13:08<MTsPony>perhaps lzma issue?
13:08<Rubidium>well, it's threaded by default
13:09<MTsPony>it doesnt seem to use my second core
13:09<MTsPony> so openttd just goes maxing out 25 cpu :(
13:10<MTsPony>i remember it used to spawn a second thread
13:11<Rubidium>it should, but it could be short lived or for some reason the OS might decide that migrating the thread and its caches to the other CPU is not worth the effort
13:11<Rubidium>after all, there's also a penalty for moving a process from one CPU to another
13:12<Rubidium>but try lzma:9 and see whether you notice it then
13:12-!-Brumi [~quassel@78-131-41-191.pool.digikabel.hu] has quit []
13:12<MTsPony>true, but if it stalls the original thread and clients start to get "no data received for xx secs" its not much fun :p
13:12<MTsPony>will do
13:13<MTsPony>could it be related to having built my own build compiled ?
13:13<MTsPony>perhaps i missed something
13:14<Rubidium>for what it's worth, the network code starts sending out data as soon as the first bits come out of the savegame compression
13:14<Rubidium>so I guess the time is spent in the creating of the uncompressed savegame
13:15<MTsPony>ill try some different compression ratios
13:15<MTsPony>it is,a 4k x4k map after all
13:17<@Alberth>nice, with 16 players, each gets 1M tiles without ever seeing another player
13:17<Rubidium>also... threaded_save has NO influence on the creation of savegames for clients
13:18<Rubidium>furthermore, autosave and normal save are always unthreaded in MP
13:18<Rubidium>(autosave and normal save do not include saving of game to send to joining MP clients)
13:24-!-DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
13:30<andythenorth>puzzling undefined strings
13:30*andythenorth sad face
13:32<Eddi|zuHause>sooo... nml seems to work now. after i've learned to do merge properly :)
13:33<andythenorth>\o/
13:35<Eddi|zuHause>andythenorth: the way my partial compiles are structured is: ((header (dummy code)) (vehicle code))
13:36<andythenorth>I’ll paste mine in a minute
13:36<Eddi|zuHause>actually, there is another bit of dummy code at the end
13:36<Eddi|zuHause>but that one is only needed for gloabal action2 ids, not for strings
13:37<Eddi|zuHause>Error on sprite 65540. <-- i feel like i reported that somewhen... my grfcodec is probably out of date
13:38<Eddi|zuHause>narf
13:38<Eddi|zuHause>Übertrage nach https://Eddi@push.openttdcoop.org/eddi-nml
13:38<Eddi|zuHause>Abbruch: HTTP Error 404: Not Found
13:38<Eddi|zuHause>what was the new url again?
13:39<Eddi|zuHause>something with ssh
13:39<andythenorth>Eddi|zuHause: this is the dummy, compiles fine http://paste.openttdcoop.org/show/3497/
13:39<andythenorth>I have a borked buy menu string, irrespective of the dummy being there or not
13:39<andythenorth>so either dummy is wrong, or something else is wrong...
13:40<andythenorth>this looks right (in graphics block)?
13:40<andythenorth> additional_text: string(STR_BUY_MENU_TEXT);
13:40<Eddi|zuHause>andythenorth: feature of the dummy and other features must match, so you can't have a dummy train in an RV set
13:41<andythenorth>ok :) Well this is trains
13:41<andythenorth>but good point :)
13:41<andythenorth>lang file shows STR_BUY_MENU_TEXT :Foo
13:42<andythenorth>maybe I’m not writing the strings out?
13:42<andythenorth>will nmlc take care of writing out needed strings for me on a partial compile to nfo?
13:42<andythenorth>I can’t see any in the output
13:43<Eddi|zuHause>the dummy vehicle must be repeated in every partial output file
13:43<andythenorth>I’ve done it for every vehicle
13:43<andythenorth>but not for any of the grf header stuff
13:44<andythenorth>I should fix that
13:44<Eddi|zuHause>it must be in the header as well
13:45-!-DabuYu [DabuYu@128.250.79.238] has joined #openttd
13:45<andythenorth>any particular location?
13:45<Eddi|zuHause>typically at the end of the header, and before any of the partial files
13:46<andythenorth>to be sure we mean same thing - this is my ‘header’ https://dev.openttdcoop.org/projects/iron-horse/repository/revisions/default/entry/src/templates/header.pynml
13:46<andythenorth>the action 14 strings are turning up correctly in compiled grf
13:47<Eddi|zuHause>yes, put the dummy code at the end of that header
13:47<andythenorth>ta
13:48<andythenorth>works :D
13:48<andythenorth>ok, so I have partial compiles
13:49<andythenorth>the nml patch is limited to this funky json thing to bring in extra global_constants
13:49<Eddi|zuHause>do you even need that now?
13:49<Eddi|zuHause>oh, parameter locations and stuff
13:49<andythenorth>yes, but I’m sure parameters could be supplied as numbers?
13:50<andythenorth>also cargo table and railtype table
13:50<andythenorth>are in the json
13:50<andythenorth>but they could be dumped into every partial compile too
13:50<Eddi|zuHause>you might be able to put them as defines
13:51<andythenorth>nmlc will pick up defines? :o
13:51<Eddi|zuHause>no
13:51<Eddi|zuHause>but cpp can
13:51<andythenorth>I am -cpp :D
13:51<Eddi|zuHause>cpp -D whatever=1
13:52<andythenorth>I considered patching nmlc to directly read CTT and RTT :P
13:52<andythenorth>it would be trivial
13:52<Eddi|zuHause>well, whatever your teplate engine is
13:52<andythenorth>yes :)
13:52<andythenorth>me templating in CTT and RTT is trivial
13:53<andythenorth>this might just work
13:53<Eddi|zuHause>so instead of using GOOD as an identifier, you make $(GOOD) come from the template engine
13:54<andythenorth>shortcuts including the CTT
13:54<andythenorth>hmm
13:54<andythenorth>maybe
13:55<andythenorth>I am curious whether this is much faster for Iron Horse than a simple nml compile
13:56*andythenorth rephrases
13:57<andythenorth>specifically, for a *full* compile, I am curious if the partial-compile-with-a-16-thread-MP-pool is faster than a single nml compile
13:59<Eddi|zuHause>probably
14:04<@Alberth>for sufficient number of trains and small enough change, it will be
14:06<Eddi|zuHause>my version is probably slower, because the headers are processed multiple times. but you process the headers only once
14:10<V453000>less than 24hours till ultimate yeti mayhem 8D
14:10<andythenorth>compile kills my battery :P
14:10<andythenorth>all cores are blocked
14:11<Eddi|zuHause>that sounds probable :p
14:11<andythenorth>ok, RTT and CTT can be dumped in via dummy file
14:12<andythenorth>that just leaves parameters
14:13-!-DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
14:13<Eddi|zuHause>you probably get lots of redundant stuff in the output if you don't strip it
14:13<andythenorth>yes
14:13<andythenorth>I’ll figure that out once I have everything else done
14:14<andythenorth>urgh
14:14<andythenorth>can’t just substitute numbers for parameters in action 14
14:14<Eddi|zuHause>eddi-nml is now up-to-date, should you want to go the comment way
14:15<andythenorth>ta
14:15<andythenorth>wtf to do with params :P
14:16<Eddi|zuHause>that sounds like a missing part of the specs
14:19<andythenorth>I could dump the grf block into the dummy file
14:19-!-Brumi [~quassel@78-131-41-191.pool.digikabel.hu] has joined #openttd
14:20<Eddi|zuHause>that's probably not a bright idea
14:23-!-DabuYu [DabuYu@128.250.79.238] has joined #openttd
14:24<andythenorth>ok, well I’m stuck with json solution for now then :)
14:24<andythenorth>works
14:30*andythenorth tries to figure out what spec change would be needed
14:31<andythenorth>looks like nml won’t parse digits for <name> http://newgrf-specs.tt-wiki.net/wiki/NML:GRF_parameters
14:34-!-jrambo [~jrambo@178-222-93-92.dynamic.isp.telekom.rs] has quit [Ping timeout: 480 seconds]
14:37-!-DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has joined #openttd
14:49<Eddi|zuHause>andythenorth: leave the name, you probably want to use this bit: "Optional, you can specify in which param number this setting should be stored."
14:50<Eddi|zuHause>"param <num> {..."
14:52<andythenorth>I already have that set :)
14:53<andythenorth>the issue is that nmlc tries to expand the parameter name string to a numeric constant
14:53<andythenorth>e.g. param_adjust_vehicle_capacity
14:53<andythenorth>I wonder if I can access the param directly in a switch
14:53<andythenorth>must be possible
14:53<andythenorth>then constant expansion is irrelevant
14:54<andythenorth>param[num]
15:02-!-Alberth [~hat@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd []
15:03<andythenorth>is it wise to use —quiet with nml?
15:03<andythenorth>I am bored of seeing lang file mismatch warnings
15:03<andythenorth>it obscures actual information
15:16<andythenorth>ho ho
15:17<andythenorth>total run times:
15:17<andythenorth>- single iron-horse.nml 28s
15:18<andythenorth>- one nml file per vehicle -> nfo 28s
15:18-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds]
15:18<andythenorth>the multi-file route has 16 MP processes allocated
15:18<andythenorth>but makes bugger all difference
15:18<andythenorth>larks
15:19<andythenorth>yeah, so it will make a big difference when only one vehicle file needs compiled :)
15:19-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
15:19<andythenorth>but the MP speed up seems to be traded against overhead in the setup (repeated parsing of lang?)
15:19<andythenorth>or nmlc is blocking waiting for sprite cache or something
15:28<andythenorth>for a single MP process, the multi-file route is 53s
15:28<andythenorth>lots of overhead :)
15:33-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds]
15:38-!-Brumi [~quassel@78-131-41-191.pool.digikabel.hu] has quit []
15:43<andythenorth>hmm
15:43<andythenorth>3s for a partial compile after changing one vehicle
15:43<andythenorth>file that under win?
15:44<andythenorth>now I get to find out about marking caches dirty
15:45<andythenorth>and all the things that go wrong related to that
15:48<Eddi|zuHause>realsprites are not processed if you output to nfo
15:50<andythenorth>I have some caches of my own
15:50<andythenorth>I should probably just learn make properly tbh
15:50<andythenorth>instead of trying to write my own dep checks
15:51-!-luaduck_zzz is now known as luaduck
15:51<andythenorth>hey, what could possibly go wrong with this? o_O
15:51<andythenorth> grf_nfo.write(consist_nfo.split('\wx00FD // DUMMY_CALLBACK;')[1])
15:53-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
16:01-!-DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
16:05<andythenorth>Eddi|zuHause: are you sure realsprites are not processed?
16:05<andythenorth>nmlc is whining about broken paths for them
16:05<andythenorth>(they are broken, for grfcodec reasons that I need to fix)
16:06<Eddi|zuHause>checking whether a file exists is something different to processing the contents
16:06<andythenorth>k
16:08<andythenorth>can I teach grfcodec to use another dir other than ‘sprites’?
16:08<andythenorth>I have minor path issues :P
16:09<Eddi|zuHause>yes
16:09-!-DabuYu [DabuYu@128.250.79.238] has joined #openttd
16:09<Eddi|zuHause>just give the path name in the grfcodec command
16:10<andythenorth>oh that works for encode too :)
16:10<andythenorth>I read it as decode only
16:10<andythenorth>yay
16:11-!-Progman [~progman@p57A18B80.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
16:12<andythenorth>maybe all I need to do now is fix the makefil
16:12<andythenorth>makefile *
16:16<andythenorth>ho planetmaker
16:16*andythenorth wonders if RL will intervene
16:18<Eddi|zuHause>i think the brasilians are picking up where they left off...
16:21<Rubidium>Eddi|zuHause: :(
16:21<Rubidium>are they playing with fireworks again in Germany?
16:22<Eddi|zuHause>probably not while holland is playing :p
16:25-!-glx [~glx@000128ec.user.oftc.net] has joined #openttd
16:25-!-mode/#openttd [+v glx] by ChanServ
16:28-!-oskari89 [oskari89@83-102-63-32.bb.dnainternet.fi] has quit []
16:30-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds]
16:31<andythenorth>meh
16:31*andythenorth wonders what 2 CTTs does
16:32-!-tokai|mdlx [~tokai@port-92-195-42-97.dynamic.qsc.de] has quit [Quit: c('~' )o]
16:32<Eddi|zuHause>only the last one is active
16:33<andythenorth>all my vehicle capacities are now N/A
16:33<andythenorth>which is a new bug
16:33<Eddi|zuHause>capacities use global callbacks?
16:33<andythenorth>per vehicle
16:33-!-tokai [~tokai@00012860.user.oftc.net] has joined #openttd
16:33-!-mode/#openttd [+v tokai] by ChanServ
16:34<Eddi|zuHause>anyway, put the dummy code in "if (0) {...}" if you're worried about semantics
16:35<Eddi|zuHause>nmlc doesn't allow multiple CTTs, but NFO does
16:35<andythenorth>yeah it’s not that
16:35<andythenorth>I took one out to test
16:36<andythenorth>I broke something else
16:37<Eddi|zuHause>difference is that NML CTTs have semantics at compile time (defining identifiers) while NFO CTTs only have semantics at runtime
16:38<Eddi|zuHause>where "runtime" is the grf activation
16:38<Eddi|zuHause>not the gameplay
16:41<andythenorth>I can’t see anything obviously wrong with the vehicle nfo
16:41<Eddi|zuHause>i don't see what you're seeing
16:49<andythenorth>I just checked the default branch to be sure I’m not smoking crack
16:49<andythenorth>capacity works fine there
16:51<andythenorth>Eddi|zuHause: Iron Horse builds now without patched nml
16:52<andythenorth>if you pull the partial_compile branch you can see directly, no paste nonsense
16:52<andythenorth>there will be some obvious dumb mistake
16:55<Eddi|zuHause>url?
16:57<andythenorth>https://dev.openttdcoop.org/projects/iron-horse/repository
16:59<andythenorth>it’s something in the stupid split I did
17:00<andythenorth>L117 of src/render_nml.py
17:01<andythenorth>do dumb things, pay the price
17:01-!-Eddi|zuHause [~johekr@p57BD4806.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
17:02-!-Eddi|zuHause [~johekr@p57BD4806.dip0.t-ipconnect.de] has joined #openttd
17:04<Eddi|zuHause>"ImportError: No module named markdown"
17:04-!-kero [~keikoz@37.175.23.202] has quit [Ping timeout: 480 seconds]
17:04<andythenorth>pip install?
17:06<Eddi|zuHause>render_nml has no line 117
17:07<Eddi|zuHause>wrong branch i suppose
17:08<andythenorth>partial_compile
17:08<Eddi|zuHause>so, if you comment out this line, it works?
17:10<andythenorth>if I remove the stupid split
17:10-!-DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds]
17:13<andythenorth>nml is preserving // comments in the nfo
17:13<andythenorth>hmm, no
17:14<andythenorth>that’s annoying
17:14<Eddi|zuHause>12 "RAIL" "ELRL" "MGLV" "\00\00\00\00" "\00\00\00\00"
17:14<Eddi|zuHause>"\00\00\00\00" <-- that doesn't look right at all
17:14-!-kero [~keikoz@37.175.23.202] has joined #openttd
17:16<Eddi|zuHause>"*_articulated_cb_switch" <-- you probably don't want to split that one off?
17:17<Eddi|zuHause>oh, the 0000000 are filled out by action 6
17:17-!-DabuYu [DabuYu@128.250.79.238] has joined #openttd
17:20<andythenorth>Eddi|zuHause: nope I do *not* want to split that one off :D
17:20<andythenorth>dumb
17:27<Eddi|zuHause>well, i did tell you that the dummy stuff must be first in the nml file
17:29<andythenorth>and I did not pay attention :P
17:30<andythenorth>on the plus side, with nfo + only compiling changed files, it’s about 5s for changing one vehicle
17:30<andythenorth>previously more than 30s
17:31<andythenorth>hopefully I can apply same to FIRS
17:32<andythenorth>FIRS is currently too coupled for single industry compiles to work properly
17:32<andythenorth>fixable
17:34<andythenorth>bed for me
17:34<andythenorth>thanks for the help
17:39-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth]
17:43-!-Jomann [~abchirk@p57A099B9.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
18:02<Wolf01>'night
18:02-!-Wolf01 [~wolf01@0001288e.user.oftc.net] has quit [Quit: Once again the world is quick to bury me.]
18:03-!-Yotson [~Yotson@2001:980:6ac8:1:dce2:37fa:b18f:3243] has quit [Quit: .]
18:04-!-Brumi [~quassel@78-131-41-191.pool.digikabel.hu] has joined #openttd
18:20-!-luaduck is now known as luaduck_zzz
18:38-!-jrambo [~jrambo@178-222-4-94.dynamic.isp.telekom.rs] has joined #openttd
18:40-!-romazoon [romazoon@95-9.195-178.cust.bluewin.ch] has quit []
18:51-!-Progman [~progman@p57A18B80.dip0.t-ipconnect.de] has joined #openttd
19:25-!-Progman [~progman@p57A18B80.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
19:27-!-HerzogDeXtEr [~flex@88.130.184.189] has quit [Quit: Leaving.]
19:27-!-Brumi [~quassel@78-131-41-191.pool.digikabel.hu] has quit []
19:31-!-yorick [~yorick@ip51cd0513.speed.planet.nl] has quit [Remote host closed the connection]
21:04-!-kero [~keikoz@37.175.23.202] has quit [Quit: kero]
21:11-!-Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has quit [Ping timeout: 480 seconds]
21:41-!-MJP [~mjp@hq.z77.fr] has quit [Ping timeout: 480 seconds]
22:30-!-HerzogDeXtEr [~flex@88.130.184.189] has joined #openttd
22:42-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
22:46-!-glx [~glx@000128ec.user.oftc.net] has quit [Quit: Bye]
22:53-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds]
23:50-!-KWKdesign [~KWKdesign@pool-108-52-130-213.phlapa.fios.verizon.net] has quit [Ping timeout: 480 seconds]
23:50-!-KWKdesign [~KWKdesign@pool-108-52-130-213.phlapa.fios.verizon.net] has joined #openttd
---Logclosed Sun Jul 13 00:00:48 2014