IRC logs for #openttd on OFTC at 2014-07-12
⏴ go to previous day
01:24:16 *** tokai|noir has joined #openttd
01:24:16 *** ChanServ sets mode: +v tokai|noir
01:56:20 *** luaduck is now known as luaduck_zzz
02:03:04 *** tokai|noir has joined #openttd
02:03:04 *** ChanServ sets mode: +v tokai|noir
04:11:32 *** KWKdesign has joined #openttd
04:42:29 *** andythenorth has joined #openttd
04:53:47 *** KWKdesign has joined #openttd
04:56:16 *** Eddi|zuHause has joined #openttd
05:20:13 *** Hazzard has joined #openttd
05:28:50 <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
06:20:47 *** andythenorth has joined #openttd
06:21:12 <andythenorth> V453000: been playing this game (Township) with child #1
06:21:25 <andythenorth> it’s a nice style
06:28:17 <V453000> very nice buildings :)
06:31:43 *** andythenorth has joined #openttd
06:49:46 *** andythenorth has joined #openttd
06:57:01 *** Pensacola has joined #openttd
07:26:07 <planetmaker> V453000, congratz :)
07:27:00 <planetmaker> andythenorth, those buildings look like they would make an awesome townset for OpenTTD :)
07:27:10 <planetmaker> it looks even correct tile size
07:48:52 *** Pensacola has joined #openttd
08:13:04 *** Myhorta has joined #openttd
08:13:41 <andythenorth> planetmaker: it is very visually cute, 32bpp done right imo
08:13:53 <andythenorth> game is a standard pay-for-downloadable-content casual game
08:14:08 <andythenorth> everything is ‘level up’, ‘get more citizens'
08:14:51 <planetmaker> ah, the usual free-to-play but spend shitload of $$$ on convenience? :)
08:15:04 <andythenorth> gold and dollars
08:15:12 <andythenorth> big arrows show you what to build or click next
08:15:13 <planetmaker> anyhow, I wonder whether they would loan the graphics to openttd :P
08:17:34 <andythenorth> planetmaker: can I interest you in my string ID problem? :P
08:19:00 <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
08:19:42 <planetmaker> so what are the obstacles?
08:21:00 <andythenorth> probably easier to explain the goal
08:21:05 *** Progman has joined #openttd
08:21:09 <andythenorth> obstacle is andythenorth isn’t sure he’s read the code correctly
08:21:36 <andythenorth> currently nmlc assigns strings random IDs afaict, unless it’s an ottd string
08:21:56 <andythenorth> I want to write them to a file, using that as a cache on the next compile
08:22:23 <andythenorth> that’s not particularly hard in python, but I need to be sure I’ve understand the ID assignment correctly
08:23:06 <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
08:23:21 <andythenorth> that would make total sense
08:23:41 <planetmaker> probably in the order it encounters / needs them. Not sure, though
08:23:47 <andythenorth> # ID is allocated randomly, we will output the actions later
08:23:54 <andythenorth> but might just mean ‘sequentially'
08:24:39 <andythenorth> I would have done sequentially, trivial to guarantee unique
08:24:51 <andythenorth> I didn’t look at the actual assignment code yet
08:25:55 <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
08:26:43 <planetmaker> and my openttd crashed on me :(
08:32:16 *** Pensacola has joined #openttd
08:35:36 <Rubidium> isn't the randomly more to give the user no guarantees of a particular order?
08:36:46 <planetmaker> the ordering of items should not be exposed to the user (easily)
08:39:04 <Rubidium> also... why am I procrastinating so much today?
08:39:48 <planetmaker> why not? weekend?
08:40:47 <Rubidium> well... maybe not "today" but rather "last weeks"
08:41:10 <planetmaker> meh, this is annoying. I try to report a bug and the website is constantly reset when I press 'submit'
08:43:36 *** Alberth has joined #openttd
08:43:36 *** ChanServ sets mode: +o Alberth
08:44:03 <SpComb> the evil bit is set on your request
08:45:39 <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)
08:46:33 <planetmaker> the flyspray bug is more reproducable, TrueBrain. It resets the connection when I try to post a bug
08:49:00 <Rubidium> looks like the data from the scripts is going without ANY checks into openttd itself
08:49:22 <Rubidium> especially a cargoid that's bigger than the highest allowed cargoid
08:50:07 * Rubidium pokes Alberth 'bout that ;)
08:51:30 <Alberth> hmm, not enough coffee yet
08:52:47 <andythenorth> it’s the middle of the day! :o
08:52:56 <andythenorth> how can you have not drunk coffee yet!
08:53:20 * andythenorth has been awake 5 hours or more
08:54:58 <planetmaker> V453000, your industries miss destinctive ground tiles quite dearly :)
08:55:19 <planetmaker> e.g. a rendering of them without the buildings :)
09:02:22 *** George|2 has joined #openttd
09:02:22 *** George is now known as Guest2322
09:02:22 *** George|2 is now known as George
09:04:06 <Alberth> not enough != none :)
09:17:40 *** Myhorta has joined #openttd
09:47:34 *** tokai|mdlx has joined #openttd
10:19:58 *** frosch123 has joined #openttd
10:23:03 *** gelignite has joined #openttd
11:01:32 *** Pensacola has joined #openttd
11:26:47 *** Stimrol has joined #openttd
11:29:36 *** Pensacola has joined #openttd
11:31:44 *** Supercheese has joined #openttd
11:37:10 *** andythenorth has joined #openttd
12:02:43 *** Myhorta has joined #openttd
12:15:05 *** Myhorta has joined #openttd
12:21:45 <DorpsGek> Commit by alberth :: r26684 trunk/src/cargomonitor.cpp (2014-07-12 12:21:40 UTC)
12:21:46 <DorpsGek> -Doc: Improve Doxygen markup with a few links to a constant and functions.
12:38:52 *** Pensacola has joined #openttd
12:46:39 *** andythenorth has joined #openttd
13:03:14 <andythenorth> I could extend the lang file format to put the string IDs in
13:03:19 <andythenorth> but it would be fugly I think
13:04:10 <andythenorth> I could mash the string IDs into global constants somehow
13:06:18 <Alberth> why not just number sequentially ?
13:06:28 <Alberth> or use the line number or so
13:07:04 <Alberth> use the string name as constant ?
13:12:08 <andythenorth> none of those are stable across partial compiles ;)
13:20:43 <andythenorth> the only methods I can think of are (a) cache nmlc-defined IDs across compiles (b) author-defined IDs
13:21:09 <andythenorth> maybe we could hash the string name or something, but I doubt it :)
13:24:21 <kero> andythenorth : have you already thought about reestablishing primary industries closure ? (and eventually, even BLACK_HOLE's ?)
13:26:17 <andythenorth> I need to branch Iron Horse
13:26:24 <andythenorth> I hate hg branching
13:26:41 *** Pensacola has joined #openttd
13:29:19 <Alberth> you want to edit the language file between compiles?
13:30:11 <andythenorth> let’s assume yes, otherwise I don’t know how to change strings :)
13:30:35 <Alberth> change a string, recompile all :)
13:31:10 <andythenorth> ok, so the compile could take care of that by checking the lang file for changes
13:31:36 <Alberth> but if you don't move strings in the file their line number stays the same
13:31:53 <andythenorth> this is a good point
13:32:07 <Alberth> unless the length of a string is also of importance but then you're probably dead with each change
13:32:28 <andythenorth> should work across all languages too afaict
13:32:46 <andythenorth> I think only the ID is significant here
13:32:56 <andythenorth> so maybe the parser could take care of this
13:33:07 <Alberth> just use english as the defining language
13:34:17 <Alberth> I would expect a line number or position or so with a STR_* name while reading a lang file
13:34:53 * andythenorth is looking for lang file parser
13:36:21 <Alberth> nml/grfstrings line 1185
13:37:10 <Alberth> for idx, line in enumerate(f) 1198
13:37:17 <andythenorth> pos is line number?
13:38:13 <Alberth> starts with line 1 though
13:38:36 <Alberth> and it has gaps of course, and the first string is not at line 1
13:41:55 *** Stimrol has joined #openttd
13:44:14 <andythenorth> might be best to just increment a counter for every string seen?
13:44:32 <andythenorth> and assume the order is deterministic?
13:47:23 <Alberth> for loop over a file is quite deterministic :)
13:47:24 *** pthagnar has joined #openttd
13:47:49 <andythenorth> is the file load order deterministic?
13:48:04 <andythenorth> wondering if they get shoved in a dict or something
13:48:11 <Alberth> probably not, but use the default language?
13:48:39 <Alberth> list of files gets pulled from the disk, no idea how fixed that order is
13:48:54 <planetmaker> andythenorth, if you hate hg branches, you should use bookmarks. That's maybe more what you like
13:49:05 <planetmaker> bookmarks are not necessarily persistant while branches are
13:49:41 <andythenorth> ‘hate’ is probably unfair
13:49:49 <Alberth> there is only one default language
13:49:56 <andythenorth> I think it’s because I was taught to never merge hg
13:50:29 <planetmaker> that's bullshit, andythenorth :) Merge like you want
13:50:42 <planetmaker> but for development branches, better use unnamed branches (just add another head)
13:50:51 <planetmaker> if they're supposed to be transient
13:51:07 <andythenorth> in this case probably valid to be named
13:51:10 <planetmaker> no-merging is just for those who want an svn-linear history
13:51:18 <andythenorth> add an unnamed head :O
13:51:26 <planetmaker> yeah. git is inferior
13:51:32 <andythenorth> I thought that was the worst crime :O
13:51:41 <planetmaker> no need to attach a name to things ;)
13:51:50 <planetmaker> depends on how you want to use it really
13:52:07 <planetmaker> CF will get confused. It will build the newest head from default branch
13:52:28 <planetmaker> I usually attach a bookmark to heads I want to remember
13:52:52 <planetmaker> and I only use named-branches for major-versions to backport stuff to
13:53:14 <planetmaker> anyway: forget the no-merges thing. That's nonsense
13:53:34 <andythenorth> so string IDs - increment a counter for each seen, use that for ID
13:53:47 <andythenorth> there’s some stuff for allowed ranges to handle
13:54:20 <andythenorth> IDs will be consistent until lang file changes
13:54:35 <andythenorth> if lang file changes, a full compile is forced (not partial)
14:01:36 <Alberth> you do realize that changing the contents only of a string is also a lang file change, right?
14:02:23 <andythenorth> I’d probably just read the timestamps on the file
14:02:41 <andythenorth> I already do that in places for faster compiles
14:02:47 <planetmaker> then you should look at make :P
14:03:12 * planetmaker is today responsible for tangential remarks at best
14:03:30 <andythenorth> you’re not the first person to say it
14:03:35 <andythenorth> pretty much everyone has said it :)
14:03:43 <andythenorth> but make involves learning make and asking for help
14:03:53 <andythenorth> whereas doing it in python just…worked
14:04:01 <planetmaker> target: list of files it depends on
14:04:14 <andythenorth> I’m never quite convinced by the ‘do it properly’ rule
14:04:28 <andythenorth> seems to lead to less shipping in my experience
14:05:45 <planetmaker> well... make solves this in those 3 lines ;)
14:07:06 <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
14:07:18 <planetmaker> and syntax is bash basically
14:09:27 <Alberth> I already supplied a 3 step tutorial to andy once :)
14:10:23 <andythenorth> maybe I could generate the makefile with python
14:11:09 <andythenorth> well python has the list of files
14:11:22 <andythenorth> manually putting them all into the makefile seems a bit quaint
14:11:35 <andythenorth> make -> python -> make ->
14:11:47 <andythenorth> dynamically changing the makefile while it’s running will be fine, right?
14:12:30 <Alberth> sounds very over-complicated to me
14:15:56 <andythenorth> anyway I should figure out this string problem
14:16:09 <andythenorth> although I’m kind of wondering how much time to spend saving time
14:16:34 <andythenorth> and it’s going to involve a personal fork of nml, with a load of compile farm hassle too
14:16:40 <andythenorth> maybe a waste of time
14:20:10 <andythenorth> is there a way to write nml to be faster?
14:20:21 <andythenorth> can I share all the switches so that there is less to parse?
14:21:10 <andythenorth> currently every FIRS industry has a full production chain
14:21:18 <andythenorth> and a full snowline, location aware etc chain
14:21:33 <andythenorth> maybe they could all be done with one set of switches, shared across industries
14:24:20 <Alberth> implement procedures? :)
14:25:13 <andythenorth> but I never saw the point of procedures
14:25:30 <andythenorth> varact 2 with a unique ID is global anyway
14:25:59 <andythenorth> I’m sure I am just badly educated :)
14:26:36 <Alberth> newgrf has many global IDs
14:27:43 * andythenorth thinks of horrible
14:28:46 <andythenorth> FIRS uses 33s just for the python step
14:28:52 <andythenorth> it doesn’t use any multi-processing
14:29:04 <andythenorth> maybe I can faster it there
14:29:18 *** Alberth has joined #openttd
14:29:18 *** ChanServ sets mode: +o Alberth
14:29:41 <Alberth> more a irc program crash
14:30:14 <andythenorth> ok 3m to compile FIRS
14:30:19 <Alberth> or rather an irc program kill request, as it didn't work any more
14:30:25 <andythenorth> I can probably get about 20s off that by improving python templating phase
14:31:29 <Alberth> you have a PM from British trains Dave
14:31:32 <andythenorth> a single industry compile is 17s
14:33:42 <andythenorth> I guess if I want to keep working on FIRS, single industry compile is worth doing properly
14:34:01 <andythenorth> otherwise it’s too slow to bother doing anything on
14:36:24 *** HerzogDeXtEr has joined #openttd
14:58:12 <andythenorth> multiprocessing python templating saves 10s
14:59:24 *** romazoon has joined #openttd
15:21:14 *** User is now known as Guest2363
15:22:16 <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?
15:24:17 *** Pensacola has joined #openttd
15:25:13 <Alberth> there are a couple of city build game scripts that you can use
15:25:29 <Alberth> no idea if an AI understands such a script, my guess is it doesn't
15:28:34 <andythenorth> print [cargo for cargo in cargo_list if cargo is not "SGCN"]
15:28:41 <andythenorth> ['GRAI', 'SGBT', 'SGCN']
15:29:07 <Guest2363> ok i only was able to find outdated AI threads in the forum. Can you recommend any AI for playing offline in general ?
15:29:09 <andythenorth> this is newly introduced bug due to use of pool.map to call a function
15:29:16 <Alberth> value equality is not object equality
15:29:31 <Alberth> ie use != to compare values
15:31:11 <Alberth> there are also game scripts that set goals for you to achieve
15:31:30 <Alberth> nocargoal and silicon valley at least
15:31:57 <Alberth> might be of interest if you are a goal player
15:32:04 <Eddi|zuHause> andythenorth: you sure "is" is the right operator?
15:32:45 <andythenorth> I like list comprehensions a lot, but doing comparisons in them feels wrong for some reason
15:32:51 <Eddi|zuHause> also, maybe cargolist.filter()
15:32:52 <andythenorth> anyway that works
15:33:28 <andythenorth> I wonder why that bug only showed up with multiprocessing pool
15:33:39 <andythenorth> it’s a year old, but has been compiling fine
15:33:43 <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
15:34:49 <Eddi|zuHause> what is "recent" or "outdated" in your opinion?
15:35:51 <Guest2363> The author said other AI's had major improvements in comparison to NoCAB, so I assumed that there are better AI's
15:36:44 <Alberth> no idea really, I never play with or against AIs
15:36:56 <Alberth> just download a few and try them
15:37:18 <Alberth> the worst thing that can happen is that you have to play more OpenTTD
15:38:06 <Alberth> also "better" has many dimensions
15:40:35 <planetmaker> Guest2363, I haven't seen anything new with most AIs for quite some time.
15:40:53 <planetmaker> Those we have work, though. Better is subjective and on your game goal
15:43:44 <andythenorth> Eddi|zuHause: (in case I’m missing something obvious) did you have a trick to ensure consistent string IDs in CETS?
15:43:58 <andythenorth> in the partial compile patch you had...
15:44:24 <Eddi|zuHause> andythenorth: yes. i put a giant switch in the beginning that references all strings
15:44:42 <Eddi|zuHause> well, the ones that need an ID
15:44:47 <Guest2363> ok thanks for your advice, I will just try a few
15:44:47 <andythenorth> and that’s deterministic as long as lang file is unchanged?
15:45:15 <Eddi|zuHause> that is deterministic, yes
15:45:24 <andythenorth> I can just do that then
15:45:32 <andythenorth> I have all the strings in scope in python anyway
15:45:35 <Eddi|zuHause> as long as every partial file has that same switch inside it
15:45:57 <Eddi|zuHause> and you remove it before combining
15:47:59 *** Progman has joined #openttd
15:50:44 <andythenorth> ok so I need to split that from the nfo
15:50:57 <andythenorth> wonder if I could just split on it
15:50:59 <Eddi|zuHause> well you can leave it in
15:51:05 <Eddi|zuHause> but it won't do anything useful
15:51:27 <andythenorth> do you have to reference the switch anywhere?
15:51:38 <andythenorth> nml will drop it otherwise? Or just warn?
15:52:41 <Eddi|zuHause> not sure. i reference it from a dummy vehicle that i also remove
15:53:08 <andythenorth> it’s clunky, but patching nml for consistent strings got boring
15:53:47 <Eddi|zuHause> my method of removing involves the "comment" patch, which is included in eddi-nml
15:54:19 <Eddi|zuHause> which i should probably update
15:54:26 <Eddi|zuHause> but i'm afraid of python3
16:03:18 <andythenorth> utils.parse_base_lang() is my friend apparently
16:03:28 <andythenorth> I should dig out my partial compile branch
16:04:30 <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
16:04:44 <planetmaker> after all... we have a dvcs. Make use of decent merges to save work ;)
16:05:39 <Eddi|zuHause> planetmaker: it's not the merging i'm afraid
16:06:06 <Eddi|zuHause> that's usually a "pull -u, commit, push"
16:06:56 <Eddi|zuHause> (where pull operates on the original nml repo, and push on the eddi-nml repo)
16:07:18 <Eddi|zuHause> i'm afraid of missing and hunting down libraries
16:07:38 <andythenorth> I am afraid of making a new virtualenv that actually works :)
16:07:48 <andythenorth> especially because my compile is python 2
16:08:07 <Alberth> virtualenv stuff is in stdlib in python3
16:08:17 <Alberth> didn't look at it though
16:11:34 <andythenorth> do we use PIL or Pillow?
16:11:38 <andythenorth> that’s the main scare
16:11:55 <andythenorth> building PIL can involve an adventure into breaking freetype and all kinds of crap
16:14:10 <Alberth> but for NML either should be fine
16:16:12 <andythenorth> Eddi|zuHause: got a link to this switch in CETS repo? o_O
16:17:19 <Eddi|zuHause> andythenorth: try looking for "__DUMMY_CODE"
16:18:28 <Eddi|zuHause> "ImportError: No module named 'ply'" i was afraid of that
16:19:04 <Alberth> just copy the existing ones, or download a new version
16:19:53 <Alberth> it's pure python, and handles both 2 and 3
16:20:23 <Eddi|zuHause> File "/home/johannes/.openttd/dbs/nml/nml/ast/comment.py", line 31
16:20:24 <Eddi|zuHause> print indentation*' ' + 'Comment:'
16:20:27 <Eddi|zuHause> SyntaxError: invalid syntax
16:20:45 <Alberth> yes, I replaced all of them :)
16:21:40 <Alberth> generic.print_dbg(indentation, 'Assignment')
16:22:16 <Alberth> s/Assignment/Comment/ in your case
16:22:26 <Eddi|zuHause> well that i figured out :p
16:23:35 <andythenorth> is there a reason the comments patch isn’t committed?
16:23:37 <xintron> I'm thinking of testing out FIRS on my server. Is there any other GFR that should be used as wel lwith firs?
16:24:13 <Alberth> xintron: some newgrf that switches on support for other than default cargoes
16:24:21 *** Hazzard has joined #openttd
16:26:33 *** oskari89 has joined #openttd
16:30: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).
16:30:51 <andythenorth> closing primary industry was available in older FIRS and removed
16:31:00 <andythenorth> I don’t understand the black hole question
16:31:26 <planetmaker> Eddi|zuHause, what distru do you use? And anyhow, it didn't turn out to teach python3-nml also to debian or fedora
16:31:57 <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.
16:32:28 <kero> About BLACK_HOLE, those are all the industries which only receives cargo and dont produce anything. Those industries also don't close.
16:32:30 <planetmaker> xintron, you must use FIRS with vehicle NewGRFs
16:32:56 <planetmaker> default vehicles won't support FIRS cargoes. So choose aircraft, road vehicles, trains and ship sets of your choice
16:33:06 <planetmaker> i.e. use av8 and FISH for air and sea
16:33:13 <planetmaker> road and rail is more diverse
16:33:53 <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 ?
16:34:24 <xintron> planetmaker, ok, thanks :)
16:34:36 <andythenorth> closing industries is considered a BAD FEATURE
16:34:50 <andythenorth> it breaks openttd-coop play
16:35:36 <kero> well I suppose it can be supposed a bad feature in some game spirit, not necesserily for everyone :)
16:36:06 <kero> Anyway, for me, I'm coding it just as an option.
16:36:30 <andythenorth> have you found where to do it?
16:36:45 <kero> Sure. It's already done. I'm testing the code.
16:37:06 <planetmaker> closing served industries is annoying in all game types
16:37:15 <Eddi|zuHause> planetmaker: what do you mean?
16:37:37 <kero> planetmaker : I'm reemplementing it as a way to close UNserved industries
16:37:40 <Eddi|zuHause> not sure what the other half of the sentence means
16:37:47 <andythenorth> kero if closure suits you, then adding it yourself is a good solution ;)
16:38:02 <Alberth> kero: usually that happens just after laying tracks, and before my first train with cargo arrives :)
16:38:54 <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
16:39:37 <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 :)
16:39:39 <andythenorth> I wonder if I can split reliably on a dummy vehicle block?
16:40:24 <Eddi|zuHause> andythenorth: you need something that you know the NFO output of and that cannot be generated by anything else
16:40:31 <Alberth> kero: I wonder why this improves game play for you
16:40:47 <kero> it avoids having the industry number increasing all the time
16:40:48 <andythenorth> Eddi|zuHause: a vehicle with ID supplied will result in deterministic nfo?
16:40:49 <Alberth> you just get the same industries back a bit later, right?
16:41:21 <kero> Alberth : in the actual situation, on a long game, industries' number increases a lot
16:42:36 <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 :)
16:42:52 <andythenorth> wtf, I thought my grfcodec was fixed :(
16:42:56 <planetmaker> kero, you tested that with FIRS or without any NewGRF?
16:43:10 <andythenorth> dyld: Library not loaded: /opt/local/lib/libpng14.14.dylib
16:43:28 <kero> the 490->667 were with FIRS
16:43:38 <Alberth> 170 in 30 years sounds like a lot to me
16:44:04 <kero> To me too. But I can give you the savegames if you want count it by yourself :)
16:44:47 <Eddi|zuHause> "Error: (AttributeError) "'module' object has no attribute 'Unit'"." what did i do wrong?
16:44:47 <Alberth> that will give you a lot of industry types
16:44:51 <kero> But. As a side note: industries were created in scenario mode.
16:45:10 <Alberth> Eddi|zuHause: I rewrote that part
16:45:28 <planetmaker> kero, so it's not an auto-generated amount?
16:46:01 <planetmaker> thus the existing amount is too low for the selected industry density
16:46:05 <Alberth> you didn't add some of the industries?
16:46:16 <kero> To be clear: I created the firs 490 in scenario mode. And then, the game itself created the other ones while in game
16:46:22 <planetmaker> and then, if course, openttd tries to reach the selected industry density ingame
16:46:30 <kero> planetmaker : no, its Not.
16:46:47 <planetmaker> possibly it sounds like you want to change openttd to allow another industry density setting. Instead of what you do now
16:46:51 <kero> industry creation for that industry-density is 400 for a 1024*1024
16:47:04 <Alberth> planetmaker: not afaik, it takes the current number and continues from there
16:47:49 <kero> and 160 for very low industry_density
16:48:25 <Eddi|zuHause> how to get a normal python backtrace out of nmlc again, instead of this wrapper thing?
16:48:50 <Alberth> the only explanation I have is that the manually added industries didn't match with the probabilities in the firs grf
16:49:43 <Alberth> so the game tries to fix that
16:50:29 <Alberth> an interesting experiment could be to see what the 400 industries do in 30 years
16:51:08 <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.
16:51:16 <kero> I tell you: I did a LOT of tests.
16:51:30 <Diablo-D3> it must be hard to do openttd before 1920
16:51:41 <kero> There defintely is a huge industry increase in-game.
16:51:54 <kero> most visible on long term games.
16:52:25 <Eddi|zuHause> Alberth: i probably merged that file the wrong way...
16:52:27 <kero> in that game, I did'nt to ANY change. Just sit and watch.
16:53:34 <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
16:55:39 <kero> It does indeed. It even can trigger some decrease (only for closable industries, that mean, PROCESSING types)
16:56:27 <andythenorth> Eddi|zuHause: do you happen to have CETS nml lying around on your filesystem?
16:56:59 <Eddi|zuHause> andythenorth: devzone->eddi-nml
16:57:13 <andythenorth> sorry, I mean the actual nml file for CETS
16:57:22 <Eddi|zuHause> what do you need?
16:57:26 <andythenorth> the dummy switch
16:57:35 <Eddi|zuHause> andythenorth: that should be on devzone as well
16:57:38 <andythenorth> I can reconstruct it by parsing the generator in my head
16:57:57 <Eddi|zuHause> i have probably posted it on paste a while ago
16:58:08 <andythenorth> maybe bundles has it
16:58:48 <andythenorth> I’ll just reconstruct it, was being lazy
17:00:18 <MTsPony> question dudes. does the savegame_format also affect runtime cpu usage of a openttd server?
17:00:27 <MTsPony> atm the map size is like 15mb
17:00:41 <Eddi|zuHause> only during autosaves
17:01:07 <Eddi|zuHause> (or manual saves)
17:01:12 <MTsPony> but, someone loading into the server has to download the real time map right? isnt that a save game too?
17:01:19 <Eddi|zuHause> (or people joining)
17:02:21 <Eddi|zuHause> MTsPony: but the game should be paused during that phase
17:03:00 <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
17:03: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)
17:03:15 <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
17:03:55 <MTsPony> i dont get why its not using my second assigned core tho :/
17:04:20 <DorpsGek> Commit by alberth :: r26685 /trunk/src (6 files in 3 dirs) (2014-07-12 17:04:14 UTC)
17:04:21 <DorpsGek> -Fix: Tighten parameter bound checks on GSCargoMonitor functions, and return -1 on out-of-bound parameters.
17:04:38 <andythenorth> get_global_string_actions looks interesting
17:04:48 <andythenorth> in nml/actions/action4.py
17:06:38 <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
17:07:43 <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
17:08:09 <MTsPony> any suggestions for threaded_saves = true refuses to work?
17:08:32 <Rubidium> well, it's threaded by default
17:09:20 <MTsPony> it doesnt seem to use my second core
17:09:35 <MTsPony> so openttd just goes maxing out 25 cpu :(
17:10:16 <MTsPony> i remember it used to spawn a second thread
17:11:10 <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
17:11:41 <Rubidium> after all, there's also a penalty for moving a process from one CPU to another
17:12:16 <Rubidium> but try lzma:9 and see whether you notice it then
17:12:26 <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
17:13:05 <MTsPony> could it be related to having built my own build compiled ?
17:13:16 <MTsPony> perhaps i missed something
17:14:17 <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
17:14:39 <Rubidium> so I guess the time is spent in the creating of the uncompressed savegame
17:15:11 <MTsPony> ill try some different compression ratios
17:15:22 <MTsPony> it is,a 4k x4k map after all
17:17:02 <Alberth> nice, with 16 players, each gets 1M tiles without ever seeing another player
17:17:02 <Rubidium> also... threaded_save has NO influence on the creation of savegames for clients
17:18:20 <Rubidium> furthermore, autosave and normal save are always unthreaded in MP
17:18:52 <Rubidium> (autosave and normal save do not include saving of game to send to joining MP clients)
17:30:13 <andythenorth> puzzling undefined strings
17:32:31 <Eddi|zuHause> sooo... nml seems to work now. after i've learned to do merge properly :)
17:35:54 <Eddi|zuHause> andythenorth: the way my partial compiles are structured is: ((header (dummy code)) (vehicle code))
17:36:12 <andythenorth> I’ll paste mine in a minute
17:36:32 <Eddi|zuHause> actually, there is another bit of dummy code at the end
17:36:57 <Eddi|zuHause> but that one is only needed for gloabal action2 ids, not for strings
17:37:39 <Eddi|zuHause> Error on sprite 65540. <-- i feel like i reported that somewhen... my grfcodec is probably out of date
17:38:43 <Eddi|zuHause> Abbruch: HTTP Error 404: Not Found
17:38:50 <Eddi|zuHause> what was the new url again?
17:39:00 <Eddi|zuHause> something with ssh
17:39:40 <andythenorth> I have a borked buy menu string, irrespective of the dummy being there or not
17:39:48 <andythenorth> so either dummy is wrong, or something else is wrong...
17:40:39 <andythenorth> this looks right (in graphics block)?
17:40:40 <andythenorth> additional_text: string(STR_BUY_MENU_TEXT);
17:40:48 <Eddi|zuHause> andythenorth: feature of the dummy and other features must match, so you can't have a dummy train in an RV set
17:41:08 <andythenorth> ok :) Well this is trains
17:41:11 <andythenorth> but good point :)
17:41:24 <andythenorth> lang file shows STR_BUY_MENU_TEXT :Foo
17:42:02 <andythenorth> maybe I’m not writing the strings out?
17:42:49 <andythenorth> will nmlc take care of writing out needed strings for me on a partial compile to nfo?
17:42:53 <andythenorth> I can’t see any in the output
17:43:30 <Eddi|zuHause> the dummy vehicle must be repeated in every partial output file
17:43:39 <andythenorth> I’ve done it for every vehicle
17:43:57 <andythenorth> but not for any of the grf header stuff
17:44:02 <andythenorth> I should fix that
17:44:43 <Eddi|zuHause> it must be in the header as well
17:45:05 <andythenorth> any particular location?
17:45:24 <Eddi|zuHause> typically at the end of the header, and before any of the partial files
17:46:40 <andythenorth> the action 14 strings are turning up correctly in compiled grf
17:47:25 <Eddi|zuHause> yes, put the dummy code at the end of that header
17:48:49 <andythenorth> ok, so I have partial compiles
17:49:03 <andythenorth> the nml patch is limited to this funky json thing to bring in extra global_constants
17:49:34 <Eddi|zuHause> do you even need that now?
17:49:47 <Eddi|zuHause> oh, parameter locations and stuff
17:49:58 <andythenorth> yes, but I’m sure parameters could be supplied as numbers?
17:50:04 <andythenorth> also cargo table and railtype table
17:50:17 <andythenorth> but they could be dumped into every partial compile too
17:50:42 <Eddi|zuHause> you might be able to put them as defines
17:51:02 <andythenorth> nmlc will pick up defines? :o
17:51:39 <Eddi|zuHause> cpp -D whatever=1
17:52:35 <andythenorth> I considered patching nmlc to directly read CTT and RTT :P
17:52:37 <andythenorth> it would be trivial
17:52:39 <Eddi|zuHause> well, whatever your teplate engine is
17:52:52 <andythenorth> me templating in CTT and RTT is trivial
17:53:08 <andythenorth> this might just work
17:53:32 <Eddi|zuHause> so instead of using GOOD as an identifier, you make $(GOOD) come from the template engine
17:54:13 <andythenorth> shortcuts including the CTT
17:55:26 <andythenorth> I am curious whether this is much faster for Iron Horse than a simple nml compile
17:57:16 <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
18:04:00 <Alberth> for sufficient number of trains and small enough change, it will be
18:06:02 <Eddi|zuHause> my version is probably slower, because the headers are processed multiple times. but you process the headers only once
18:10:02 <V453000> less than 24hours till ultimate yeti mayhem 8D
18:10:07 <andythenorth> compile kills my battery :P
18:10:10 <andythenorth> all cores are blocked
18:11:07 <Eddi|zuHause> that sounds probable :p
18:11:53 <andythenorth> ok, RTT and CTT can be dumped in via dummy file
18:12:06 <andythenorth> that just leaves parameters
18:13:36 <Eddi|zuHause> you probably get lots of redundant stuff in the output if you don't strip it
18:13:51 <andythenorth> I’ll figure that out once I have everything else done
18:14:29 <andythenorth> can’t just substitute numbers for parameters in action 14
18:14:52 <Eddi|zuHause> eddi-nml is now up-to-date, should you want to go the comment way
18:15:05 <andythenorth> wtf to do with params :P
18:16:25 <Eddi|zuHause> that sounds like a missing part of the specs
18:19:36 <andythenorth> I could dump the grf block into the dummy file
18:20:33 <Eddi|zuHause> that's probably not a bright idea
18:24:19 <andythenorth> ok, well I’m stuck with json solution for now then :)
18:30:23 * andythenorth tries to figure out what spec change would be needed
18:49:18 <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."
18:50:27 <Eddi|zuHause> "param <num> {..."
18:52:40 <andythenorth> I already have that set :)
18:53:04 <andythenorth> the issue is that nmlc tries to expand the parameter name string to a numeric constant
18:53:07 <andythenorth> e.g. param_adjust_vehicle_capacity
18:53:33 <andythenorth> I wonder if I can access the param directly in a switch
18:53:35 <andythenorth> must be possible
18:53:46 <andythenorth> then constant expansion is irrelevant
19:03:20 <andythenorth> is it wise to use —quiet with nml?
19:03:30 <andythenorth> I am bored of seeing lang file mismatch warnings
19:03:35 <andythenorth> it obscures actual information
19:17:43 <andythenorth> total run times:
19:17:58 <andythenorth> - single iron-horse.nml 28s
19:18:11 <andythenorth> - one nml file per vehicle -> nfo 28s
19:18:25 <andythenorth> the multi-file route has 16 MP processes allocated
19:18:30 <andythenorth> but makes bugger all difference
19:19:09 <andythenorth> yeah, so it will make a big difference when only one vehicle file needs compiled :)
19:19:20 *** Myhorta has joined #openttd
19:19:41 <andythenorth> but the MP speed up seems to be traded against overhead in the setup (repeated parsing of lang?)
19:19:50 <andythenorth> or nmlc is blocking waiting for sprite cache or something
19:28:11 <andythenorth> for a single MP process, the multi-file route is 53s
19:28:16 <andythenorth> lots of overhead :)
19:43:28 <andythenorth> 3s for a partial compile after changing one vehicle
19:43:31 <andythenorth> file that under win?
19:44:53 <andythenorth> now I get to find out about marking caches dirty
19:45:10 <andythenorth> and all the things that go wrong related to that
19:48:39 <Eddi|zuHause> realsprites are not processed if you output to nfo
19:50:09 <andythenorth> I have some caches of my own
19:50:19 <andythenorth> I should probably just learn make properly tbh
19:50:27 <andythenorth> instead of trying to write my own dep checks
19:51:32 *** luaduck_zzz is now known as luaduck
19:51:40 <andythenorth> hey, what could possibly go wrong with this? o_O
19:51:40 <andythenorth> grf_nfo.write(consist_nfo.split('\wx00FD // DUMMY_CALLBACK;')[1])
19:53:05 *** Myhorta has joined #openttd
20:05:16 <andythenorth> Eddi|zuHause: are you sure realsprites are not processed?
20:05:25 <andythenorth> nmlc is whining about broken paths for them
20:05:52 <andythenorth> (they are broken, for grfcodec reasons that I need to fix)
20:06:15 <Eddi|zuHause> checking whether a file exists is something different to processing the contents
20:08:08 <andythenorth> can I teach grfcodec to use another dir other than ‘sprites’?
20:08:16 <andythenorth> I have minor path issues :P
20:09:37 <Eddi|zuHause> just give the path name in the grfcodec command
20:10:06 <andythenorth> oh that works for encode too :)
20:10:11 <andythenorth> I read it as decode only
20:12:40 <andythenorth> maybe all I need to do now is fix the makefil
20:16:23 * andythenorth wonders if RL will intervene
20:18:50 <Eddi|zuHause> i think the brasilians are picking up where they left off...
20:21:52 <Rubidium> are they playing with fireworks again in Germany?
20:22:11 <Eddi|zuHause> probably not while holland is playing :p
20:31:54 * andythenorth wonders what 2 CTTs does
20:32:08 <Eddi|zuHause> only the last one is active
20:33:22 <andythenorth> all my vehicle capacities are now N/A
20:33:25 <andythenorth> which is a new bug
20:33:43 <Eddi|zuHause> capacities use global callbacks?
20:33:58 *** ChanServ sets mode: +v tokai
20:34:46 <Eddi|zuHause> anyway, put the dummy code in "if (0) {...}" if you're worried about semantics
20:35:33 <Eddi|zuHause> nmlc doesn't allow multiple CTTs, but NFO does
20:35:55 <andythenorth> yeah it’s not that
20:35:59 <andythenorth> I took one out to test
20:36:09 <andythenorth> I broke something else
20:37:35 <Eddi|zuHause> difference is that NML CTTs have semantics at compile time (defining identifiers) while NFO CTTs only have semantics at runtime
20:38:14 <Eddi|zuHause> where "runtime" is the grf activation
20:38:31 <Eddi|zuHause> not the gameplay
20:41:27 <andythenorth> I can’t see anything obviously wrong with the vehicle nfo
20:41:57 <Eddi|zuHause> i don't see what you're seeing
20:49:48 <andythenorth> I just checked the default branch to be sure I’m not smoking crack
20:49:56 <andythenorth> capacity works fine there
20:51:58 <andythenorth> Eddi|zuHause: Iron Horse builds now without patched nml
20:52:12 <andythenorth> if you pull the partial_compile branch you can see directly, no paste nonsense
20:52:33 <andythenorth> there will be some obvious dumb mistake
20:59:49 <andythenorth> it’s something in the stupid split I did
21:00:06 <andythenorth> L117 of src/render_nml.py
21:01:00 <andythenorth> do dumb things, pay the price
21:02:22 *** Eddi|zuHause has joined #openttd
21:04:06 <Eddi|zuHause> "ImportError: No module named markdown"
21:06:06 <Eddi|zuHause> render_nml has no line 117
21:07:44 <Eddi|zuHause> wrong branch i suppose
21:08:58 <Eddi|zuHause> so, if you comment out this line, it works?
21:10:27 <andythenorth> if I remove the stupid split
21:13:37 <andythenorth> nml is preserving // comments in the nfo
21:14:14 <Eddi|zuHause> 12 "RAIL" "ELRL" "MGLV" "\00\00\00\00" "\00\00\00\00"
21:14:16 <Eddi|zuHause> "\00\00\00\00" <-- that doesn't look right at all
21:16:22 <Eddi|zuHause> "*_articulated_cb_switch" <-- you probably don't want to split that one off?
21:17:11 <Eddi|zuHause> oh, the 0000000 are filled out by action 6
21:20:21 <andythenorth> Eddi|zuHause: nope I do *not* want to split that one off :D
21:27:47 <Eddi|zuHause> well, i did tell you that the dummy stuff must be first in the nml file
21:29:00 <andythenorth> and I did not pay attention :P
21:30:02 <andythenorth> on the plus side, with nfo + only compiling changed files, it’s about 5s for changing one vehicle
21:30:09 <andythenorth> previously more than 30s
21:31:46 <andythenorth> hopefully I can apply same to FIRS
21:32:01 <andythenorth> FIRS is currently too coupled for single industry compiles to work properly
21:34:11 <andythenorth> thanks for the help
22:20:00 *** luaduck is now known as luaduck_zzz
22:51:06 *** Progman has joined #openttd
continue to next day ⏵