IRC logs for #openttd on OFTC at 2011-08-06
⏴ go to previous day
00:00:05 <Ammler> well, that might require patching...
00:00:50 <Ammler> always force to https for logged in users is ok
00:01:19 <Ammler> the issue is how to detect if someone is logged in
00:01:48 <duckblaster> how do you know who the user is?
00:02:15 <Ammler> you speak to me like I am dev of redmine :-P
00:02:58 <duckblaster> got server access?
00:03:37 <duckblaster> should be only about 2 lines to add i expect
00:03:42 <Ammler> ok, not helpful, but thanks :-)
00:04:27 <duckblaster> i'll grab a copy of the code
00:04:35 <Ammler> well, it is fine, I will ask upstream first anyway
00:04:50 <Ammler> but would be cool, if ypu provide a patch :-P
00:04:57 *** variable has joined #openttd
00:05:00 <Eddi|zuHause> <Ammler> well, does that happen because you need to login? <- no, i'm already logged in, just submit the comment and suddenly it leaves https
00:05:55 <Eddi|zuHause> Ammler: if i follow the link in the emails, i get to https
00:06:37 <Eddi|zuHause> Ammler: once i am on https, nothing should lead me back to http, but it does.
00:16:01 <Ammler> another issue is, that google adsense aren't available for ssl
00:16:32 <Ammler> so some browsers do error, if you mix ssl with non-ssl content
00:21:30 <Ammler> Eddi|zuHause: added #2931, too late for now :-)
02:26:27 *** rhaeder1 has joined #openttd
04:56:22 *** Eddi|zuHause has joined #openttd
05:03:44 *** Kurimus has joined #openttd
06:13:08 *** sla_ro|master has joined #openttd
06:26:32 *** andythenorth has joined #openttd
06:26:45 <andythenorth> none of my grfs build
06:27:44 <Rubidium> new grfcodec/nforenum on a BE architecture?
06:27:56 <andythenorth> just about 5 minor arsey things
06:28:12 <andythenorth> I didn't copy grfcodec over
06:28:19 <andythenorth> I can't build it because I don't have boost
06:28:35 <andythenorth> I haven't symlinked nmlc
06:28:41 <andythenorth> other crappy stuff
06:28:59 <andythenorth> I knew I should have rsynced /bin and other such
06:35:02 *** Cybertinus has joined #openttd
06:43:16 <andythenorth> so where should I symlink things grfcodec etc from?
06:43:39 <andythenorth> it's apparently bad to do it from /bin
06:44:04 <andythenorth> should I use /usr/bin?
06:52:04 * andythenorth permits himself first "yay" of today
06:52:17 <andythenorth> each day should have >1 "yays" in it
06:52:24 <andythenorth> a zero-yay day is a bad day
06:52:35 <andythenorth> but a day that has too many "yays" is a day that contained too many problems
06:53:19 <andythenorth> 3-7 is probably about right
06:53:27 <andythenorth> 20 would certainly be too many
07:12:52 <andythenorth> planetmaker: hello
07:13:00 <andythenorth> can you run the buildout for nml?
07:20:19 <planetmaker> I never tried so far
07:21:09 <planetmaker> how would I do that?
07:21:32 <planetmaker> or you mean... the CF?
07:28:16 <andythenorth> planetmaker: in your nml checkout - run 'python bootstrap.py' then 'bin/buildout'
07:28:37 <andythenorth> it's all failing horribly for me :P
07:29:22 <planetmaker> uhm... that'll install NML somewhere, won't it?
07:30:38 <andythenorth> this is a fun morning :(
07:30:45 <andythenorth> bootstrap.py is broken
07:30:48 <andythenorth> PIL won't install
07:31:00 <andythenorth> setuptools can't be upgraded on Snow Leopard
07:31:14 <andythenorth> Snow Leopard apparently ships with a broken version of python 2.6.1
07:31:18 <planetmaker> regressions work here
07:31:53 <andythenorth> do you recall how you got PIL to install?
07:32:28 <andythenorth> apparently compiler flags are set wrong - OS X is trying build PIL for PowerPC
07:32:38 <andythenorth> (according to the internet)
07:32:39 <planetmaker> port install py-pil or something
07:32:51 <andythenorth> planetmaker: you have the output I want :P
07:33:34 <andythenorth> so it's clearly possible
07:33:45 <andythenorth> you have 10.6.8?
07:33:57 <andythenorth> and python 2.6.1?
07:36:38 *** Kurimus has joined #openttd
07:44:18 *** DayDreamer has joined #openttd
07:46:03 *** DayDreamer has left #openttd
07:54:16 *** Alberth has joined #openttd
07:54:16 *** ChanServ sets mode: +o Alberth
07:54:40 <andythenorth> that was an *arse*
07:56:05 <andythenorth> don't use OS X :P
07:56:34 <andythenorth> now I broke my mercurial
07:59:38 <planetmaker> sudo port install mercurial ;-)
08:00:36 *** andythenorth is now known as Guest4911
08:00:36 *** andythenorth_ has joined #openttd
08:00:37 *** andythenorth_ is now known as andythenorth
08:28:02 <andythenorth> there is *zero* chance that we'd trust a newgrf author to mark some parameters as "safe to change during game" (via a14)?
08:28:19 <andythenorth> for example, running & purchase costs
08:28:45 <andythenorth> or climate availability of vehicles
08:29:06 <Rubidium> climate availability is not safe by definition I'd say
08:29:17 <Rubidium> after all, it allows removing vehicles from a climate
08:29:29 <andythenorth> only from the buy menu
08:29:46 <andythenorth> it's the route I use to deprecate vehicles without breaking savegame
08:29:54 <planetmaker> climate availability only removes it from purchase list afaik
08:30:18 <andythenorth> but would we trust newgrf authors to mark up some items as 'safe'?
08:30:29 <Rubidium> so it depends on the implementation; I assumed you'd just jump over the 'not for this climate' vehicles
08:30:48 <planetmaker> Rubidium: not action7. The availability property
08:31:31 * Alberth ponders a newgrf test environment
08:31:34 <andythenorth> I figured it would be unsafe :P
08:31:50 <Rubidium> planetmaker: to me it'd be easier to just set the 'all climate available' bits for all vehicles and then jump over the vehicles that are not 'selected' for a particular climate
08:32:02 <andythenorth> then you'd break savegames :P
08:32:06 <andythenorth> and people would tell you off
08:32:50 <planetmaker> it's easy but not update-safe ;-)
08:33:18 <planetmaker> same as it was easy for isr to re-shuffle tileIDs from somewhere between 0.6 and 0.8
08:33:21 <Alberth> it is easy and wrong :)
08:35:01 <planetmaker> I try to be cautious with the word 'wrong' - but it's definitely not "best practise"
08:35:14 <Rubidium> there you see that a 'noob' in NewGRF coding can easily make something that'd break, but he saw that andythenorth marked it as safe so he does as well. Because... if the experienced dev says it's safe, then the same feature should be safe in his NewGRF as well.
08:35:26 <andythenorth> that's what I figured :P
08:35:49 <andythenorth> I am still poking at things that cause you to have to restart your game
08:36:57 <Rubidium> though it would be interesting to know what things 'you' (plural) would like to be able to change
08:37:25 <andythenorth> 'safe' things <- that much is obvious
08:37:27 <planetmaker> - update to newer version of newgrf
08:37:40 <andythenorth> ^ assuming action 14 says it's ok
08:37:49 <Alberth> add new grfs that were forgotten
08:37:53 <planetmaker> yes, that's what we have comp. version for
08:37:59 <andythenorth> Alberth: too complicated
08:38:10 <planetmaker> forgotten as in 'missing vehicles' mostly
08:38:11 <andythenorth> update is valid - especially where the newgrf has bugs
08:38:19 <andythenorth> adding can never happen
08:38:28 <andythenorth> unless the spec is changed
08:38:40 <andythenorth> disable disabling, then talk about it :P :)
08:38:42 <planetmaker> andythenorth: updating the version is the same
08:38:52 <Alberth> or we detect 'bad' things in some way
08:38:56 <planetmaker> FIRS for example queries TTRS version and changes behaviour accordingly
08:38:57 <andythenorth> true. only if the author is toxic though
08:39:03 <andythenorth> and if it's FIRS :P
08:39:05 <planetmaker> thus it's of the same level of un-safe-ness
08:39:44 <Rubidium> then just make the test environment for NewGRF changes ;)
08:39:46 <andythenorth> so those examples are same as every other time we debated it
08:39:53 <andythenorth> safe things should include:
08:39:57 <andythenorth> - run & buy costs
08:40:03 <andythenorth> - climate availability
08:40:28 <andythenorth> actually none of the above
08:40:49 <andythenorth> newgrf A can check the value of parameters in newgrf B?
08:40:58 <andythenorth> in which case all bets are off
08:41:13 <andythenorth> end of discussion? :P
08:41:25 <Alberth> perhaps it is easier to start at the other end, what can you do that is always safe?
08:41:29 <Rubidium> no, only one answer to the discussion
08:41:53 <andythenorth> changing *anything* is like lighting the fuse on a bomb
08:42:03 <andythenorth> no newgrf author can determine that their grf is 'safe'
08:42:16 <andythenorth> because it is (almost) indeterministic
08:42:21 <andythenorth> due to combination of other grfs
08:42:21 <Alberth> duh, that's what happens if you give people atomic bombs to play with
08:42:34 <Rubidium> "refactor OpenTTD so it can load a second set of NewGRFs; after that use a heuristics whether anytime changed for the 'bad'. If it is proven to not cause anything bad: allow making the changes."
08:42:58 <andythenorth> or - similar - handle disabling better
08:43:08 <andythenorth> which might require same approach
08:43:26 <andythenorth> i.e. dry-run the change; if any newgrf disables itself, forbid the change
08:43:49 <Rubidium> andythenorth: but... that might not be 'for the bad'
08:43:50 <planetmaker> that might be the only call we really have, a dry-run sandbox for testing
08:43:51 <Alberth> Rubidium: refactor such that we create a 2nd map from the first one, copying/creating things from scratch?
08:44:15 <andythenorth> hmm clone pattern
08:44:24 <Rubidium> e.g. if one such NewGRF is a translation NewGRF. Disabling that because the new version of the translated NewGRF contains said translation is not bad.
08:44:35 <andythenorth> forbid starting / updating any game with disabled newgrfs
08:44:36 <Alberth> but we have zillions of global variables :(
08:44:50 <Rubidium> Alberth: you don't need to do it for the whole map
08:44:58 <Rubidium> just load the spec variables.
08:45:44 * andythenorth has like...5 line idea
08:45:46 <Alberth> hmm, what about making a kind of contract with the newgrf? "I will behave in this and this way" ?
08:45:47 <Rubidium> if vehicle length changes: return bad, if vehicle is removed: return bad, if ...
08:45:56 <andythenorth> currently the direction we're heading is that the community will start turning on newgrf developer tools
08:46:03 <Alberth> it still needs checking :(
08:46:04 <andythenorth> which means I have to start handling invalid bug reports again
08:46:39 <andythenorth> and the suggestion to forbid starting game with disabled grfs was nixed by some people here who want to use same grf config in every game
08:46:56 <andythenorth> what if starting with disabled grfs was forbidden, unless developer tools are on
08:47:35 <planetmaker> that is IMHO not sufficiently justified
08:47:37 <Alberth> andythenorth: disabled newgrfs are not a problem. they are clearly labeled as 'i am not doing anything'.
08:47:50 <andythenorth> I guess we disagree about them being a problem
08:47:53 <andythenorth> I find them a problem
08:48:04 <andythenorth> I can't prove everyone does :P
08:49:43 <Alberth> I can see the case that you want the same configuration every time. It takes ages to make it all working properly. I invariably forget some newgrf which I of course discover only after starting
08:49:45 <andythenorth> what happens if I update my newgrf with bananas, then load a savegame
08:49:56 <andythenorth> and grf A is updated, so grf B disables itself?
08:49:59 <andythenorth> do I lose my game?
08:50:19 <Alberth> save game itself has the version
08:50:27 <Alberth> so it loads the old one
08:50:48 <Alberth> (which is why people want to be able to update their newgrfs in the game)
08:50:50 <andythenorth> and if I manually delete the old one?
08:51:36 <Alberth> then you have a missing newgrf file which you can pull from bananas, or the game doesn't run (I think, I'd have to test that)
08:52:11 <Alberth> but here you get the compability stuff into play, which I know nothing about :)
08:52:48 <planetmaker> The game will load a compatible NewGRF
08:53:03 <planetmaker> the one with the newest version - or a random one with the newest version
08:53:18 <planetmaker> only if no compatible newgrf is found it'll fail to load
08:53:19 <andythenorth> in which case - boom
08:53:30 <planetmaker> not fail but resist ;-)
08:53:41 <andythenorth> grf A is modified in some subtle way, grf B disables itself
08:53:51 <planetmaker> of course, can happen
08:54:00 <andythenorth> FIRS will probably do that with TTRS if I try hard enough
08:54:36 <planetmaker> it *should* not be possible - or it's a min_version error in TTRS
08:54:53 <andythenorth> *because* you've provided TTRS in a proper way
08:55:07 <andythenorth> I reckon I could code this case if I could be bothered :P
08:55:20 <planetmaker> version downgrade is never considered compatible
08:56:51 <andythenorth> recently someone else suggested a solution I thought was nice
08:57:11 <andythenorth> if there are disabled grfs when starting game, show the newgrf window before map gen
08:57:29 <andythenorth> giving player chance to address issue
08:57:39 <andythenorth> dunno if that's necesary or sufficient
08:58:23 <Alberth> ie how do you decide about disabledness based on climate at that point?
08:58:36 <andythenorth> you know the climate?
08:59:01 <planetmaker> well, on map generation one does
08:59:22 <planetmaker> though... you only know about disabled newgrfs after the map is initialized - as newgrf initialization is part of it
08:59:22 <Alberth> depending on when "before" exactly is
08:59:52 <andythenorth> even if possible, seems like a sticking plaster
08:59:56 <Alberth> but I fear it is after the map is already generated
09:00:22 <planetmaker> I'm not sure... you need to know newgrfs during map creation
09:01:11 <andythenorth> removing 'disable self' from newgrf spec is unworkable
09:02:01 * Alberth believes the newgrf spec needs rigorous cleanup before even trying to solve things in the program
09:02:06 *** frosch123 has joined #openttd
09:02:11 <andythenorth> Alberth: godwin :P
09:02:19 <andythenorth> that's where this conversation always goes
09:02:33 <andythenorth> and yet we've established that cleaning up newgrf spec is also unworkable :P
09:02:36 <andythenorth> for legacy support
09:03:01 <Alberth> there are 2 ways out of it.
09:03:12 * andythenorth thinks of a third :P
09:03:27 <Alberth> 2. treat newgrfs as unsafe in the program
09:03:39 <andythenorth> 2 is the current situation
09:03:54 <Alberth> no, they are treated as 'safe', that's why accidents happen
09:04:04 <Alberth> ie we trust what you say
09:04:08 <andythenorth> but we've put a lock on them
09:04:44 * andythenorth just put a child lock on the cupboard where the mains fuses are
09:04:47 <duckblaster> new spec, different format, but keep newgrf support?
09:05:24 <andythenorth> same issue would reappear, but we'd incur *lots* of work to get there
09:05:25 <Alberth> 'keep newgrf as legacy' means you have to build & maintain 2 openttd programs. Unworkable
09:05:33 <andythenorth> doesn't solve the issue
09:05:40 <andythenorth> it's valid for a newgrf to disable itself
09:05:48 <andythenorth> and therefore this is conceptually unresolvable
09:05:49 <duckblaster> keep loader part only?
09:05:58 <duckblaster> or is it too intergrated
09:06:08 <Alberth> it is *completely* integrated
09:06:42 <duckblaster> rewrite openttd in c++ and object oriented system?
09:06:54 <Alberth> openttd just copies the data straight out the newgrf, and uses all data as trusted values
09:07:15 * andythenorth doesn't particularly *want* to allow things like adding newgrf. The current locked-down situation is ok-ish
09:07:19 <Alberth> duckblaster: how does that solve things?
09:07:20 <andythenorth> but the user experience sucks
09:07:24 <duckblaster> so newgrf is just a memory dunp?
09:07:39 <duckblaster> exact copy of memory?
09:07:48 <Alberth> in a bit nicer format, but mostly
09:08:11 <Alberth> ie some wrapper stuff is around it to know where to put what
09:08:20 <andythenorth> you can rewrite it in Whatever Framework Is Flavour Of The Month, but the issue will persist
09:08:21 <Alberth> so it is not straight memory dump
09:08:22 <duckblaster> "in a bit nicer format"? so it goes through something to get frmo disk to memory?
09:08:34 <duckblaster> insert new loader there
09:08:44 <andythenorth> the only solution I can see is proper domain
09:08:59 <andythenorth> each newgrf declares explicitly which features it wishes to change
09:09:01 <Alberth> duckblaster: loading is not the problem, trusting the data is
09:09:07 <andythenorth> only one newgrf can make changes to that features
09:09:15 <andythenorth> newgrfs have to bid in an auction
09:09:25 <duckblaster> what are the things that crash?
09:09:45 <andythenorth> so only one newgrf can change houses
09:09:53 <andythenorth> only one newgrf can change industries
09:09:58 <andythenorth> only one newgrf can change cargos
09:10:01 <Alberth> duckblaster: everything can crash if you feed it values you trust blindly
09:10:05 <andythenorth> vehicles are pooled, so probably safe
09:10:12 <duckblaster> with sensible values i mean
09:10:27 <duckblaster> if it's changed mid game
09:10:35 <andythenorth> even with this explicit domain idea, the problem persists
09:10:44 <andythenorth> basically I think OzTrans actually is doing it write
09:10:53 <andythenorth> write / right /s
09:11:06 <andythenorth> OnlyOneTrueNewGRF
09:11:17 <andythenorth> instead of newgrf list, you get to choose one newgrf
09:11:35 <duckblaster> not going to work
09:11:53 <duckblaster> firs + fish + aviator + trains
09:11:55 <Alberth> it is at least clearing up the mess of finding out what newgrfs you need to use :p
09:12:38 <andythenorth> duckblaster: you don't get that choice in the new system
09:12:43 <duckblaster> with good newgrfs, if they are changed mid game, what could cause a crash?
09:12:44 <andythenorth> you pick OzTrans.grf
09:12:50 <andythenorth> or andythenorth.grf
09:13:14 <Alberth> duckblaster: the problem is how to recognize 'good'
09:13:27 <andythenorth> the crash problem is a straw man
09:13:39 <andythenorth> so the game crashed. that sucks. but you have autosave
09:13:49 <duckblaster> firs, fish, aviators, other big popular ones
09:14:06 <Alberth> what are the units for airport noise level?
09:14:17 <andythenorth> what's annoying is playing a game for an hour before discovering it's broken due to changed (or missing) newgrfs
09:14:23 <Alberth> ie what is a 'sane' value for that property?
09:14:36 <duckblaster> why would it crash when switching mid game? what would cause the crash?
09:14:48 <duckblaster> missing vehicles?
09:15:48 <andythenorth> (1) ditch newgrf spec, try a new one (same problem re-emerges)
09:15:52 <andythenorth> (2) do nothing, it's all ok
09:16:03 <andythenorth> (3) allow only one newgrf to be loaded
09:16:23 <duckblaster> (5) make a newgame?
09:16:57 * Alberth is very tired of this discussion
09:17:29 <andythenorth> it's more of a monologue
09:18:03 <duckblaster> anyone interested in a rct clone?
09:18:21 <duckblaster> theme park builder 3d
09:18:43 <planetmaker> Alberth: arbitrary units for noise level
09:18:52 * Alberth doesn't want 3d, it is not even working at my machine
09:19:03 <Alberth> planetmaker: useful :)
09:19:23 * Alberth picks random number 5
09:19:52 <andythenorth> newgame or New game?
09:21:11 <Alberth> open is good, it's 2d isometric then :p
09:21:12 <planetmaker> hm... for separate building sprites I cannot choose separately "show / no show" in sprite layouts?
09:21:47 <planetmaker> we should call it DttNepo
09:22:31 *** Progman has joined #openttd
09:23:23 <planetmaker> if the first "hide_sprite" returns "true" then the 2nd will always return "true", too, thus be hidden
09:24:14 <andythenorth> you're trying to make the perfect layout with transparency on?
09:24:26 *** Alexdddd has joined #openttd
09:24:31 <planetmaker> no. the "hide_sprite" doesn't deal with transparency
09:24:44 <planetmaker> it allows to decide "show yes/no" depending on parameter
09:24:47 * andythenorth is a dunce at nml :P
09:25:00 <planetmaker> transparency is handled by "always_draw" ;-)
09:25:16 <andythenorth> one day I will learn this magic
09:25:32 <Alexdddd> This a developer chat channel?
09:25:36 <planetmaker> but I just try to figure out what 'hide_sprite' relates to
09:25:46 <planetmaker> this is a general channel related to OpenTTD, Alexdddd
09:25:54 <planetmaker> but yes, developers are also sometimes here
09:26:34 <Alexdddd> Just found Open TTD - played the original years ago
09:27:15 <Alexdddd> And IRC too... havent used this for years either ;)
09:33:44 *** andythenorth is now known as Guest4914
09:33:44 *** andythenorth_ has joined #openttd
09:33:44 *** andythenorth_ is now known as andythenorth
09:33:59 *** Biolunar has joined #openttd
09:34:36 <planetmaker> andythenorth: solving this issue would solve auto-fencing for arbitrary slopes ;-)
09:35:42 <andythenorth> today is not a good day for learning nml
09:39:03 <planetmaker> frosch123: my understanding is correct that I can several parent sprites in one sprite layout, right?
09:41:37 <andythenorth> planetmaker: wrt FIRS - 37 errors? Do you see those?
09:41:48 * andythenorth is checking it's not a localised issue
09:42:00 <andythenorth> unreferenced sprite blocks mostly
09:44:05 <Hirundo> andythenorth: those errors (warnings, actually) are relatively harmless, as those unused sprites aren't copied to the actual grf
09:45:03 <Hirundo> It's just a hint that your nml contains dead code
09:46:17 <andythenorth> they can mask real errors though :)
09:47:44 <Eddi|zuHause> [06.08.2011 08:43] <andythenorth> so where should I symlink things grfcodec etc from? <-- at least on linux, you usually do manual changes to the system in /usr/local/bin, sometimes also ~/bin is allowed
09:48:37 <andythenorth> seems that /opt/local is acceptable on OS X
09:49:49 *** andythenorth is now known as Guest4916
09:49:49 *** andythenorth_ has joined #openttd
09:49:50 *** andythenorth_ is now known as andythenorth
09:52:44 <frosch123> planetmaker: yes, every parent sprite is a bounding box
09:53:12 <frosch123> usually you have one bounding box per industry tile, and two per traversable station tile (one in front and one behind the train)
09:53:27 <frosch123> you can use more, but usally grfauthors just mess up :p
09:53:44 <frosch123> why do you need multiple bounding boxes?
09:55:06 <planetmaker> I want to separately hide / not hide the fences on the adjacent tile's object type
09:56:06 <planetmaker> thus my idea was to use a separate building sprite for each fence
09:56:31 <planetmaker> then I can in an adv. sprite layout hide / not hide it. Or so my idea
09:56:40 <frosch123> well, basically you can do all that stuff with child sprites, just that the positioning of child sprites is relatively to the topleft of the parent sprite, i.e. it depends on the size, relx and rely of the parent sprite
09:57:17 <frosch123> however, for airports fences cause glitching between aircraft and foundation
09:57:33 <planetmaker> I'm currently doing NewObjects
09:57:39 <frosch123> that's why ottd draws them as ground sprites
09:58:28 <frosch123> planetmaker: if you want generic code, make all object use the bouding box at position <1,1,0> with size <14,14,maxz>
09:58:41 <frosch123> then you can put the fences on the edges 0 and 15
09:59:12 <planetmaker> yes... but the hiding / not hiding is my problem. It doesn't work quite as I expect / want it to work...
10:00:46 <planetmaker> one the childsprite approach, the other the building one
10:01:29 <planetmaker> it works perfect for the first fence, but the subsequent ones seem to be hidden, if a previous one gets hidden.
10:02:12 <andythenorth> it remains amusing that the weight of Goods varies according to the vehicle it's travelling in :P
10:02:20 <planetmaker> and I at least need to make sure I understood what I can do before I start assuming it's a bug somewhere in NML or OpenTTD ;-)
10:02:24 <frosch123> planetmaker: did you enable any transparency settings?
10:03:18 <frosch123> smatz did some 'optimisation' that when the first sprite is invisible due to transparency settings, it will not draw the rest of the layout as well
10:03:51 <planetmaker> that might explain it, that's how it looks like
10:04:23 <frosch123> try changing the 'return' in sprite.cpp:52 to a 'continue'
10:04:27 <planetmaker> but it looks like check first || draw first, check 2nd || draw 2nd, check 3rd || draw 3rd, check 4th || draw 4th
10:05:31 <andythenorth> Eddi|zuHause: forklift will have generations with improving stats over time
10:05:42 <andythenorth> so how fast at introduction (1936)
10:05:52 <Eddi|zuHause> andythenorth: what kind of improving stats?
10:06:03 <andythenorth> rest will be the same
10:06:21 <Eddi|zuHause> andythenorth: but make it a new model, so autoreplace can be used.
10:06:33 <andythenorth> nah, that's not the pattern used in HEQS
10:07:43 <frosch123> hmm, might want to look up in the logs whether that was actually meant as optimisation
10:11:50 <frosch123> everytime i pull a new project from devzone, i need to pull nml as well :p
10:12:30 <frosch123> wow, ogfx-landscape takes quite long to build :o
10:12:51 <frosch123> planetmaker: any diff i need to apply to tip?
10:14:45 <planetmaker> mind that you have both versions there, buildings or child sprites. Comment out the one you don't want / need
10:16:20 <planetmaker> the fences are not supposed to be slope-aware yet
10:17:52 <frosch123> hmm, the object gui lacks a colour string code
10:19:22 <frosch123> yeah, but first i want to moan about noone else mouning
10:20:12 * planetmaker confesses to not have noticed
10:20:21 <frosch123> planetmaker: the wind turbine?
10:20:34 <planetmaker> the "invisible" one
10:20:50 <planetmaker> I don't actually know why it is invisible...
10:20:58 <frosch123> yeah, did not notice it :p
10:21:06 <planetmaker> but that's another thing to take care of separately
10:21:40 <planetmaker> frosch123: company land is best viewed with transparency = on (but not invisible)
10:23:58 <planetmaker> hm, mind that one of the fences (SE) is not well placed when using the 'building' approach
10:27:05 <andythenorth> what happens if I run out of D0 texts?
10:28:52 <Hirundo> How many do you currently use?
10:29:08 <frosch123> andythenorth: use D1 to D3 texts :p
10:29:54 <Eddi|zuHause> that's only 1024 strings
10:31:40 * andythenorth assumes a forklift always costs same, no matter hp/speed
10:31:52 <andythenorth> Eddi|zuHause: want a test grf?
10:33:48 <Alberth> where is the list of airport tile types to use for override? (property 8 of action 0) ?
10:35:07 <Alberth> although they are probably of no use anyway :p
10:36:27 <Eddi|zuHause> andythenorth: not in the mood for testing right now
10:36:57 * andythenorth thinks the audience participation is lacking :P
10:37:03 <frosch123> planetmaker: looks like a bug in ottd
10:37:35 <planetmaker> he... thanks for looking into it :-)
10:38:45 <frosch123> yeah, works now (except for se)
10:38:47 <planetmaker> I assume you already meanwhile have an idea where?
10:39:03 <planetmaker> except for SE? How is that different?
10:39:36 <frosch123> it draws the fence on the ne edge
10:39:42 <frosch123> didn't you said that yourself?
10:39:59 <planetmaker> :-D I understood SE = scenario editor :-)
10:40:27 <planetmaker> it draws the NW fence twice
10:40:35 <planetmaker> you see it in transparent view
10:40:39 <andythenorth> I'm thinking of applying it, but I am not in the mood for testing it either :P
10:40:51 <andythenorth> i.e. I'm not sitting watching trams go round for 30 mins :D
10:41:05 <andythenorth> so I'm inclined to just trust your code
10:41:11 <planetmaker> andythenorth: setup a webcam and stream it. Someone will watch :-P
10:41:45 <frosch123> planetmaker: well, if the nw is hidden due to adjacent tile, the se one is still drawn at nw
10:43:21 <andythenorth> planetmaker: how about I just ship it :D
10:43:29 <andythenorth> someone else found the original bugs
10:44:01 <andythenorth> frick: patch: **** Only garbage was found in the patch input.
10:44:27 <Eddi|zuHause> andythenorth: curl -L
10:45:05 <andythenorth> doesn't resolve it :(
10:45:42 <andythenorth> attachment != download in redmine
10:46:34 <Alberth> andythenorth: but causing a traffic jam should be simple to do
10:46:53 <andythenorth> planetmaker: wtf fast forward on snow leopard?
10:47:07 <andythenorth> maybe it's a bug in a specific ottd version
10:47:16 <Eddi|zuHause> andythenorth: i don't seem to have an actual game using these changes, but i did test them in a test game
10:47:29 <planetmaker> andythenorth: hu?
10:47:44 <frosch123> planetmaker: try again
10:47:47 <CIA-2> OpenTTD: frosch * r22721 /trunk/src/newgrf_commons.cpp: -Fix (r22518): Conditionally hiding a sprite caused subsequent items of the spritelayout to use wrong registers.
10:47:50 <andythenorth> I'll see if it's specific to an ottd rev later
10:48:05 <Eddi|zuHause> andythenorth: fast forward is always as fast as your computer can go
10:48:18 <andythenorth> in which case, this computer is insanely faster than the previous
10:48:27 <andythenorth> despite only marginal nominal spec difference
10:48:46 <Eddi|zuHause> depends on map size, amount of vehicles, etc.
10:49:42 <Alberth> and video driver performance
10:50:15 <planetmaker> \o/ cookie and / or cold beverage for frosch :-)
10:51:15 <Eddi|zuHause> meh, i can't get newgrf-information from a savegame if it has "invalid chunksize" or "newer version"...
10:51:25 <Eddi|zuHause> how about a "game developer" setting? ;)
10:51:53 <andythenorth> I don't have lzma
10:51:57 <planetmaker> Eddi|zuHause: it's called 'developer'
10:51:59 * andythenorth now hates moving computer
10:52:39 * Alberth gives andythenorth a hammer and some nails
10:52:51 <Eddi|zuHause> planetmaker: i think that is mislabeled
10:53:14 <planetmaker> lool @ Alberth :-)
10:53:23 <Eddi|zuHause> planetmaker: afair that setting just sets redirection of output
10:53:30 <andythenorth> I should have just copied what I thought I should copy, instead of listening to others :P
10:54:36 <planetmaker> + cheat shortcuts iirc
10:55:12 <andythenorth> planetmaker: I assume you can compile ottd on snow leopard?
10:55:18 <andythenorth> no surprise - I can't :P
10:55:25 <andythenorth> do I need to build my own gcc?
10:55:53 <planetmaker> actually my self-built gcc does NOT compile openttd
10:56:19 <planetmaker> the requirements on snow leopard are no different than on tiger
10:56:29 <planetmaker> so it applies most probably to leopard as well
10:56:40 <planetmaker> you'll need of course all the deps
10:57:56 <andythenorth> next time I'll just do a migration the correct way :(
10:58:12 <planetmaker> did you do any fancy configure?
10:58:38 <planetmaker> if not, try ./configure --enable-universal="i386"
10:58:55 <planetmaker> it's not a fix, but a workaround...
10:59:29 <andythenorth> fails, same error
10:59:57 * andythenorth is basically an edge case
11:00:09 <planetmaker> maybe not. Maybe I am
11:00:24 <Hirundo> Anyone knows, what happens if a 7E procedure call fails (no CB result is returned) in TTDPatch?
11:01:03 <Hirundo> In OpenTTD, it's always CALLBACK_FAILED right?
11:01:05 <andythenorth> which gcc version should I be using?
11:01:49 *** fire1299 has joined #openttd
11:01:49 <planetmaker> andythenorth: both, gcc4.0 and 4.2 work for me
11:01:59 <planetmaker> default on 10.6 is gcc 4.2
11:02:06 <andythenorth> that's what I have
11:02:10 <planetmaker> maybe try a gcc_select 4.0
11:02:18 <planetmaker> it defaults to i386 as architecture
11:02:28 <planetmaker> sudo gcc_select gcc40
11:02:53 <andythenorth> first I have to get gcc_select and gcc4.0
11:03:07 <planetmaker> isn't it installed with the developer tools?
11:03:22 <planetmaker> forget the gcc from macports ;-)
11:03:38 <frosch123> Hirundo: "jb .gotfn // this'll give us a semi-random value, but it's invalid to do this anyway"
11:03:50 <planetmaker> what does gcc_select -l tell you?
11:04:05 <andythenorth> gcc_select: command not found
11:04:14 <andythenorth> same with python_select actually
11:04:35 <frosch123> Hirundo: "semi-random" as in "whatever is written in bx currently"
11:04:38 <planetmaker> hm, right. gcc_select is a macports thingy
11:04:42 <planetmaker> so install that :-)
11:04:45 <andythenorth> yeah, I've done that
11:04:58 <andythenorth> I've installed quite a bit from macports this morning that's not working
11:05:08 <Hirundo> frosch123: that is really nice :S
11:05:16 <planetmaker> define "not working"
11:05:23 <planetmaker> gcc_select: command not found?
11:05:26 <andythenorth> not in the path < is my best guess
11:05:56 <frosch123> Hirundo: well, what should happen?
11:06:02 <planetmaker> you have to add /opt/local/bin to your search bath
11:06:07 <planetmaker> when using macports
11:06:16 <andythenorth> they're in opt/local/var
11:06:17 <frosch123> ottd just givex 0x7fff
11:06:26 <frosch123> i.e. just some value
11:06:27 <andythenorth> opt/local/bin is in my path but not the other
11:07:11 <Hirundo> frosch123: 0xFFFF afaik
11:08:24 <planetmaker> that's not needed
11:09:11 <frosch123> Hirundo: yeah, indeed, so the only 7e result which is not 15 bits :p
11:09:12 <Hirundo> At least, it's not a valid CB result, so I can check for that (in NML) and for example let the entire CB fail
11:09:24 <planetmaker> what does the output look like if you try: set | grep '^PATH='
11:09:35 <planetmaker> adding it there without sourcing it doesn't help
11:09:41 <andythenorth> PATH=/opt/local/Library/Frameworks/Python.framework/Versions/2.4/bin:/opt/local/bin:/Library/Frameworks/Python.framework/Versions/Current/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
11:10:21 <planetmaker> and: which gcc_select
11:10:46 <planetmaker> port list gcc_select
11:11:16 <andythenorth> gcc_select @0.1 sysutils/gcc_select
11:11:54 <planetmaker> and the output of "which gcc_select"?
11:12:19 * andythenorth checks it's not driver error
11:12:34 <andythenorth> it's driver error
11:12:42 <andythenorth> wrt openttd failing to compile
11:12:47 <andythenorth> dunno wtf is going on with ports
11:13:03 <andythenorth> but not using make mrproper was my idiocy
11:14:09 <CIA-2> OpenTTD: frosch * r22722 /trunk/src/sprite.cpp: -Fix: Skip invisible parent and child sprites due to transparency settings using the same logic as skipping due to grf-defined invisibility.
11:14:30 <andythenorth> the intel i7 is a 2x2 cpu?
11:14:42 <andythenorth> that's unexpected
11:14:47 <andythenorth> so I have 4 CPU meters :P
11:14:56 <Eddi|zuHause> i have 6 cores ;)
11:15:51 <frosch123> Eddi|zuHause: does that increase the chance for a meltdown?
11:16:26 <Eddi|zuHause> frosch123: i have installed additional cooling
11:16:50 <planetmaker> just connect directly to the Saale
11:17:08 <Eddi|zuHause> planetmaker: that's a few km away ;)
11:17:08 <andythenorth> so the hyper-speed is not an ottd bug :P
11:17:18 * andythenorth will now find more problems to moan about
11:17:23 <Eddi|zuHause> andythenorth: openttd uses only one core
11:17:41 <frosch123> Eddi|zuHause: up to two
11:17:48 <andythenorth> still seems to be about 3x faster on ffwd
11:18:34 <planetmaker> :-) maybe for concurrent network connections and autosave
11:18:42 <andythenorth> it's either using 2 on my box, or the OS is offloading all tasks to the other cores
11:18:55 <andythenorth> ffwd ottd causes two cores to spike usage
11:19:20 <planetmaker> autosave enabled?
11:19:41 <frosch123> well, using the sdl backend it does the drawing of the ottd internal buffer to the screen in a separate thread
11:19:56 <Eddi|zuHause> sdl is not used on OSX
11:20:03 <andythenorth> maybe the OS is just being smart
11:20:08 <frosch123> and if you have a composing window manager, it might do the composing on a different core as well
11:20:27 <Alberth> OS may be moving ottd back and forth between cores
11:20:45 <frosch123> andythenorth: every os needs to be at least smatz enough to deal with the crappy hardware
11:21:07 <andythenorth> anyone working on FIRS?
11:21:13 <frosch123> though maybe they are the same :)
11:21:14 * andythenorth is wondering what to work on
11:21:52 <Hirundo> if 'improving NML to make coding FIRS easier' counts as 'working on FIRS', then yes :)
11:22:36 <andythenorth> is this a bug? Or a feature request?
11:22:46 <andythenorth> the guy annoys me
11:26:51 <planetmaker> as heqs is not designed (IMHO) as stand alone set: feature request
11:28:51 <Ammler> I guess, the guy just isn't able to distinguish the trackers...
11:29:43 <frosch123> heavy equipment for oil seeds?
11:30:35 <frosch123> i don't think heqs is meant for any transport of organic stuff, is it?
11:30:36 <Alberth> andythenorth: ask clarification
11:31:53 <planetmaker> andythenorth: can you try compilation again after you set
11:31:54 <planetmaker> CFLAGS="-isystem/opt/local/include ${CFLAGS}"
11:32:00 <planetmaker> in your ~/.bash_profile?
11:32:24 <andythenorth> planetmaker: sorry - it does compile
11:32:28 <andythenorth> it was my stupid mistake
11:33:03 <planetmaker> but what made it fail in the first place?
11:33:11 <andythenorth> not using make mrproper
11:33:15 <planetmaker> and what did you change?
11:33:20 <andythenorth> I used make mrproper :)
11:33:23 <planetmaker> ah... you copied from your old machine?
11:33:26 <planetmaker> and then just compiled?
11:33:32 <planetmaker> ok, yes, that must fail :-)
11:33:35 <planetmaker> been there, seen that
11:40:17 <Hirundo> (note: tested to the extent that it looks sane to my rather untrained eyes)
11:40:52 <planetmaker> andythenorth: today I'm not working on it. or currently
11:41:35 * andythenorth does other stuff
11:41:41 <andythenorth> which is easier to understand:
11:41:48 <frosch123> Hirundo: there is an /// instead of an //
11:41:53 <andythenorth> "Running costs vary with capacity"
11:42:01 <andythenorth> or "Higher capacities cost more to run"
11:42:06 <frosch123> looks fine to me, but it will for sure cause some discussion about the "right" value :p
11:42:36 <planetmaker> what does that patch? ttdp?
11:42:46 <Hirundo> of course MB will disagree :P just because he can
11:43:21 <andythenorth> MB: grinch, or force for good?
11:43:22 <Hirundo> planetmaker: provide a defined result for failed 7E procedure calls in TTDP
11:44:08 * andythenorth thinks force for good
11:45:28 *** TWerkhoven has joined #openttd
11:46:53 <Pulec> is there a dedicated ottd server for debian?
11:47:19 <frosch123> Hirundo: so would eis_os. and the other patchdevs will most likely not understand what it is about, unless you explain it to them. the only one who could deal with it from ttdp would be dalestan
11:48:54 <Ammler> Pulec: not from openttd.org, you might need to build it self
11:48:54 <Hirundo> What's the best way of reaching them? Are they around on IRC often, or is it best to create a forum post?
11:49:18 <frosch123> on irc you will only catch lakie
11:50:12 <frosch123> and reaching the other "them" would first need defining who "them" is
11:50:42 *** JVassie has joined #openttd
11:50:44 <Pulec> thats a bit more complicated, so the easiset way is to run ottd on some xwindows
11:50:47 <frosch123> you can put it on the forum and wait for some trolls though :)
11:52:10 <planetmaker> Pulec: the default binary can work as dedicated
11:52:13 <Hirundo> ah well, I'll do so and see what happens :)
11:52:14 <Ammler> Pulec: well, you could install the build-dep of openttd
11:52:19 <planetmaker> ./openttd -D and you're set
11:52:22 <Ammler> planetmaker: no, they can't
11:53:29 <Hirundo> As a side note, what was the 'correct' way of failing a callback again?
11:53:48 <Eddi|zuHause> Ammler: so what's easier, installing the build-deps or installing sdl?
11:54:09 <Ammler> Eddi|zuHause: I guess, it depends on the guy who installs :-)
11:54:34 <Hirundo> Do a real action2->action1, with action1 containing 1 set with 0 sprites?
11:54:45 <Ammler> Pulec: we provide dedicated rpms :-)
11:56:08 <Pulec> thx, will see what linux friend will try
11:57:02 <planetmaker> now the slopes ;-)
11:58:36 <planetmaker> minimum version requirement r22721 :-P
11:59:44 <Eddi|zuHause> planetmaker: that should be default for company owned land
11:59:44 <planetmaker> hm... ok, possibly 1.1.3-RC1...
11:59:59 <planetmaker> Eddi|zuHause: you mean this fencing?
12:00:18 <frosch123> planetmaker: rather 1.2 beta 1
12:00:30 <frosch123> advsprlayout is not 1.1 stuff, is it?
12:00:45 <planetmaker> hm, yes, probably
12:01:00 <planetmaker> well, no new opengfx+landscape then for anyone playing stables :-P
12:01:21 <andythenorth> Eddi|zuHause: 'spose you want load sprites for your forklift?
12:01:58 <Eddi|zuHause> andythenorth: that'd be good, but a generic box might suffice
12:02:07 <andythenorth> I'll have to find one :P
12:02:20 <Ammler> planetmaker: fyi: ottdc@games:~> openttd -D
12:02:21 <Ammler> openttd: error while loading shared libraries: libSDL-1.2.so.0: cannot open shared object file: No such file or directory
12:03:03 <planetmaker> but that's only because it's not installed via package manager, right?
12:03:19 <Ammler> I installed it via rpm with --nodeps
12:03:21 <frosch123> it was not compiled as dedicated-only
12:03:37 <Ammler> so it didn't install the whole sdl
12:04:00 <planetmaker> Ammler: well, then it's no surprise, is it?
12:04:12 <Ammler> well, you expected it to work
12:04:28 <planetmaker> when installed properly
12:04:36 <Ammler> maybe you aren't the only openttd dev doing that, that is why you don't provide dedicated bundles
12:04:58 <Ammler> what is the point of building dedicated version, when you have sdl installed?
12:05:55 <Ammler> I am not sure, if it would be possible to make openttd loading sdl only, if available
12:05:58 <Eddi|zuHause> Ammler: we used to provide dedicated-only binaries, but there simply was not enough demand
12:07:10 <Ammler> Eddi|zuHause: I know, it is aounrd one per year asking for it :-)
12:07:34 <Ammler> better to provide 10 different formats of the same
12:12:34 <Rubidium> frosch123, Eddi|zuHause: OpenTTD can use more than 2 threads (by itself): main thread, background save thread and... SDL drawing thread. Then there's also the other auxiliary threads such as sound playback and IP address resolution, though those are out of OpenTTD's control
12:14:17 <Eddi|zuHause> "Der Pwnie für den "Most Epic FAIL" ging an Sony, was wenig überrascht"
12:43:43 <planetmaker> hm... I now have a newgrf which 100% crashes OpenTTD on trying to start a game with it
12:44:28 <Hirundo> nice :P is it because of an incompatible version, or should it actually work?
12:44:51 <Eddi|zuHause> you know where the bugtracker is :p
12:48:23 <planetmaker> must be reading invalid memory or so...
12:54:00 <planetmaker> no other is supposed to work anyway ;-)
12:55:30 <frosch123> finally someone is testing advsprlayout :)
12:57:03 <andythenorth> frosch123: I tested it
12:57:10 <andythenorth> but I found that it failed :P
12:57:32 <andythenorth> about 2 months ago :)
12:58:42 <planetmaker> see, people just don't listen to you ;-)
12:58:49 <andythenorth> signal to noise ratio is bad
12:59:19 <frosch123> planetmaker, Hirundo: more than 256 operations in an advvaract2?
12:59:38 <planetmaker> not sure... possible?
13:01:18 <frosch123> it works if i change byte to uint :)
13:01:30 <frosch123> nml entered a new dimension :p
13:01:50 <planetmaker> It's not the first time I run into that...
13:01:58 <planetmaker> Hirundo and Yexo will know :-P
13:02:07 <frosch123> we will need to implement runtime scheduling and multi-threaded advact2
13:02:49 <Hirundo> or... more operators, so NML doesn't need so many arcane workarounds :)
13:04:46 <planetmaker> this auto-fencing really stretches the VarAction2 limits...
13:05:00 <planetmaker> First it was just for level ones - that was sorted.
13:05:11 <planetmaker> Now... going for the arbitrary slope, we're there again ;-)
13:08:55 <Hirundo> frosch123: It might be best to put those adjusts in a SmallVector, to reduce the endless reallocing
13:09:14 <frosch123> yup, just doing that :)
13:12:21 *** ar3k is now known as ar3kaw
13:17:20 <CIA-2> OpenTTD: frosch * r22723 /trunk/src/newgrf_spritegroup.h: -Fix: Do not restrict AdvVarAct2 to 255 operations.
13:22:39 <Eddi|zuHause> i'm sure CETS will hit one or two limits in the near future as well :p
13:23:12 <planetmaker> I'm quite sure of that, too ;-)
13:23:23 <planetmaker> like the articulated vehicle limit
13:24:42 <Eddi|zuHause> planetmaker: well, there are workarounds for that
13:24:58 <planetmaker> many limits can be worked around one way or another...
13:25:05 <Eddi|zuHause> just not sure i can teach them to nml yet
13:27:44 <Eddi|zuHause> right, what i wanted to ask: i used some undocumented feature like "var[0x45,0, 0x000F0F0F]", is there some similar undocumented feature for var6x?
13:29:21 <Eddi|zuHause> how does that handle the parameter?
13:29:34 <planetmaker> IIRC as 4th parameter
13:30:21 <planetmaker> STORE_TEMP(value, 256+0x10), STORE_TEMP(value, 256+0x18)
13:30:26 <planetmaker> as the callback variables
13:30:48 <planetmaker> hm... or just a value beyond 255
13:30:57 <planetmaker> FIRS did something like that
13:32:05 <planetmaker> switch(FEAT_INDUSTRYTILES, SELF, action2_6811, var[0x60, 0, 255, 0]) {
13:32:18 <planetmaker> so 4th parameter it was
13:33:46 <Eddi|zuHause> "action2_6811" sounds very autoconversion-y :)
13:34:58 <planetmaker> you need that for the yet not existing parameters, right?
13:35:05 <planetmaker> not for the existing ones?
13:35:30 <planetmaker> a very good reason to keep it, although undocumented :-)
13:36:02 *** douknoukem has joined #openttd
13:36:24 <Hirundo> Eddi|zuHause: Do you use other hard coded (var[...]) variables, except not yet existing ones and var 45 ?
13:37:13 * Hirundo puts var[0x45,0, 0x000F0F0F] on the NML feature list
13:38:33 <Eddi|zuHause> this autoconverted FIRS is full of these things, though ;)
13:39:05 <planetmaker> Eddi|zuHause: yes, it is. But they easily are converted to proper calls.
13:39:10 <planetmaker> And many (most?) are
13:39:18 <planetmaker> it was an old rev I linked
13:39:26 <Hirundo> hmm... do you need the triplet info in this case?
13:39:58 <planetmaker> curv_info_prev_cur and friends?
13:40:53 <Hirundo> I mean in var[0x45,0, 0x000F0F0F], does the triplet part add any useful information?
13:40:56 <Eddi|zuHause> Hirundo: yes, the cases are 0x000F0F00, 0x000F000F, 0x00010100, 0x00010001 and default
13:41:31 <Hirundo> You could distinguish these cases with var[0x45, 0, 0x00000F0F] also, right?
13:41:48 <Eddi|zuHause> Hirundo: not really
13:42:45 <Hirundo> Isn't triplet just the same as front + back? ergo, it adds no information entropy
13:42:46 <Eddi|zuHause> Hirundo: i have to know that when the front one is curved, the back one is straight
13:43:24 <Hirundo> that's 0x0001 resp 0x000F, no need to use the triplet info for that
13:44:01 <Eddi|zuHause> Hirundo: there might be some corner cases i'm overlooking
13:47:56 <Hirundo> I'm not sure though, how a unified variable would work w.r.t. sign extension
13:49:24 <Hirundo> currently negative values (0x0C - 0x0F) are sign extended to -4 .. -1, you can't just stick two (or more) of such values into a single dword
13:51:59 <Eddi|zuHause> can you do operations in the case-constants? like "((-1 & 0xF) << 8) | ((-1 & 0xF) << 16)"?
13:52:16 <Eddi|zuHause> or you need tuples ;)
13:52:37 <Eddi|zuHause> "raw" var45 then returns a 3-tuple
13:54:30 <Hirundo> tuples are about a dozen bridges further :)
13:55:15 <Hirundo> We could do something akin to relative_pos for objects etc.
13:55:54 <CIA-2> OpenTTD: frosch * r22724 /trunk/src/newgrf.cpp: -Codechange: Reduce number of realloc calls when loading VarAct2s.
13:56:04 <Hirundo> that var returns 0xYYXX, and you get a helper function relative_coord(x, y) that does the bit magic for you
13:56:29 <CIA-2> OpenTTD: frosch * r22725 /trunk/src/ (industry_gui.cpp object_gui.cpp): -Fix: Always draw NewGRF supplied texts with a default colour.
13:59:15 <Eddi|zuHause> i thought lots of variables have that kind of bitstuffing
14:00:04 <Hirundo> yes, but in most cases the variables are just split in parts and reading them as one isn't really useful
14:01:14 <Hirundo> relative_pos is an exception, as a whole it turned out to be really useful to decide on graphics within an industry/object/airport
14:01:28 <Hirundo> separate variables relative_x and relative_y are still available, though
14:03:12 <Eddi|zuHause> hm, i think i never properly checked 90° curves for my vehicles...
14:07:12 <Pulec> anybody can do restart comand via console? or is just wrongly sert permission
14:09:33 <planetmaker> rcon is your friend
14:09:44 <planetmaker> set an rcon password
14:16:19 <Pulec> damn i dont like all the sounds off factories when zoomed out max
14:17:10 <Eddi|zuHause> use running sounds for train, then you hit the simultaneous sound limit :p
14:59:05 * andythenorth has a tram moving inside a road depot :P
14:59:53 <Eddi|zuHause> by changing newgrfs ingame? :p
15:03:12 *** supermop has joined #openttd
15:03:54 <andythenorth> by changing the type of an RV + reloading the grf :P
15:09:24 *** ZirconiumX has joined #openttd
15:09:38 <ZirconiumX> Long time, no see - as they say.
15:12:01 * ZirconiumX is being minimalist.
15:12:05 <Eddi|zuHause> don't believe what THEY say.
15:12:47 <ZirconiumX> Only they would say it.
15:12:54 *** ZirconiumX is now known as they
15:13:24 <they> The nickname they is protected...
15:13:41 *** they is now known as ZirconiumX
15:14:02 <Eddi|zuHause> it must be capitalised
15:14:21 *** ZirconiumX is now known as THEY
15:15:20 *** They is now known as ZirconiumX
15:19:25 * ZirconiumX is wondering if you could implement a minimalist AI
15:19:50 * ZirconiumX thinks you'd need an alias command - or something of the sort
15:21:02 <Eddi|zuHause> more minimalist than "Idle" or "IdleMore"?
15:21:17 <ZirconiumX> Much shorter is AIEEP.C(e).AEP compared to AIEventEnginePreview.Convert(event).AcceptEnginePreview
15:21:44 <ZirconiumX> Openttd squirrel is very easy to read - unfortunately
15:22:25 <Eddi|zuHause> as an AI i'd rather decline the offer by default...
15:22:35 <planetmaker> wooo... andythenorth, we can have fenced meadows now :-)
15:22:53 <planetmaker> even in Norway ;-)
15:25:05 * ZirconiumX is messing around with a computer chess engine
15:25:29 * ZirconiumX is using a lot of /me commands
15:29:48 <planetmaker> to me it sounds like a lot of on-topic talk
15:30:48 * ZirconiumX detects sarcasm in that comment
15:32:01 <ZirconiumX> @Eddi|zuHause, (apologies) minimalist as in it works, but is very small and has limited functionality
15:32:50 <ZirconiumX> A guy implemented a chess program in less than 2KB of non-blank source
15:32:58 <ZirconiumX> think that sort of thing
15:33:27 <Eddi|zuHause> oh, you mean like obfuscated c contest
15:35:17 <ZirconiumX> You could hold a contest fro it
15:41:40 *** Adambean has joined #openttd
16:39:22 <andythenorth> HEQS 1.2.0 released.
16:39:28 <andythenorth> done, done, onto the next one....
16:52:27 <Noxbru> hi, may I ask you some questions about AITile.GetCargoAcceptance/Production ?
16:52:57 <DorpsGek> frosch123: Don't ask to ask, just ask
16:53:56 <andythenorth> at least he was specific :)
16:54:12 <Noxbru> my problem is that i'm trying to sort some tiles by its passengers acceptance, and building a bus stop at the top one, but the AI puts the station at the last tile
16:54:39 <Noxbru> I have told my AI to write at the log the acceptances of the tiles, and it says 0s and -1s
16:55:23 <Noxbru> so I wanted to ask how more or less does AITile.GetCargoAcceptance/Production works
16:55:46 <frosch123> something is wrong about the arguments to the fnuction
16:56:08 <frosch123> take a look at the preconditions for that function
16:57:06 <Noxbru> AIMap.IsValidTile, width and height > 1 and radius >= 0
16:57:06 <Noxbru> in my case is true, 1, 1, 5
16:58:19 <frosch123> then the function shall not return -1
16:59:06 <Noxbru> I am generating the tile list with: "tiles.AddRectangle(town + AIMap.GetTileIndex(-10,-10), town + AIMap.GetTileIndex(10,10));"
16:59:18 <Noxbru> then, keeping the roads
16:59:19 <frosch123> you can use the landscape info tool on the very right of the toolbar (the '?') to check the acceptance of indiviudal tiles
16:59:39 <Noxbru> and checking their acceptance of passengers
17:00:59 <Noxbru> AILog.Info(AITile.GetCargoProduction(tile,AICargo.CC_PASSENGERS,1,1,5) + "");
17:01:33 <frosch123> AICargo.CC_PASSENGERS is no cargo type
17:02:12 <frosch123> it's a cargoclass, but actually that should not matter in this case
17:02:21 <Noxbru> ups... then, that's the error
17:04:21 <frosch123> ah, it checks for coal acceptance that way :)
17:08:25 <Noxbru> then, how I should pass the CargoID? at the AICargo there isn't any function that returns CargoID
17:10:17 <frosch123> i assume you want to build a busstop
17:11:09 <Noxbru> yes I wanted some kind of function which you can pass the town_id and the type of station and looks for the best place to build it
17:11:10 <frosch123> take AICargoListe, filter it by cargoclass, and then process those cargos
17:12:24 <frosch123> you even pointed me on a bug in ottd :)
17:14:17 * andythenorth wonders if it's time for FIRS
17:16:16 <andythenorth> 89 tickets is a lot :|
17:20:43 <CIA-2> OpenTTD: frosch * r22726 /trunk/src/ai/api/ (ai_rail.cpp ai_rail.hpp ai_tile.cpp ai_tile.hpp): -Fix: AITile::GetCargoAcceptance, AITile::GetCargoProduction and AIRail::BuildNewGRFRailStation did not check the cargo argument for validity.
17:24:38 *** ar3k is now known as ar3kaw
17:42:39 *** andythenorth has joined #openttd
17:45:14 <Noxbru> see you, thanks for the help
17:45:24 <CIA-2> OpenTTD: translators * r22727 /trunk/src/lang/russian.txt:
17:45:24 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:24 <CIA-2> OpenTTD: russian - 1 changes by Lone_Wolf
17:50:04 *** douknoukem has joined #openttd
18:02:53 <planetmaker> 19:12 Noxbru: really? :-[ <-- don't be afraid to point out those :-)
18:03:07 <planetmaker> better they're known (and fixed) than... lurking there forever :-)
18:03:51 <planetmaker> good bug reports are hard to come by. And we have to rely on people telling us about problems - we cannot detect them all ourselves
18:04:05 <frosch123> are you sure he reads logs?
18:04:23 <planetmaker> skimming over them
18:05:05 <planetmaker> and it seems he did the same to you as I did this afternoon to you ;-) - oh :-)
18:09:05 <planetmaker> or given the temperature and humidity here right now: refreshing
18:10:07 *** Born_Acorn has joined #openttd
18:12:20 <planetmaker> I wonder still why the purchase list sprite for the company land does not show...
18:13:26 <frosch123> are you checking fences in the purchase list?
18:22:17 <frosch123> planetmaker: the purchase list chain results in an callback result
18:22:48 <planetmaker> hm... I wonder why
18:23:10 <planetmaker> It works similar for the wind mill
18:23:35 <planetmaker> I even don't get an image when I link to the simplest sprite layout I can think of: a normal ground tile
18:27:08 <Eddi|zuHause> planetmaker: have a stray "return"?
18:28:24 <planetmaker> not that I know... but I'm going to double-check
18:31:01 <frosch123> that's the number of operations in that advvaract2 :p
18:32:03 <frosch123> planetmaker: you are triggering the variable-not-available case
18:32:16 <frosch123> so i guess you try to check adjacent tiles
18:37:35 <frosch123> well, i tested the grf you gave me earlier
18:38:39 <frosch123> whats' GROUNDSPRITE_NORMAL ?
18:38:47 <planetmaker> flat, green grass tile
18:39:11 <planetmaker> errm.. not A. But default TTD sprite
18:50:18 <frosch123> planetmaker: it works if you put the purchase layout also in the default case of the main graphics item
18:50:24 <frosch123> so, looks like nml bug to me
18:54:38 <frosch123> the purchase list case results in a callback switch which then ends up in a huge veract2 checking an not-available variable
18:55:58 *** Adambean has joined #openttd
18:56:21 <planetmaker> hm... yes... that makes sense
18:57:03 <planetmaker> I'll try the other way to use that callback
18:58:28 <andythenorth> 512GB SSD drives
18:58:36 <andythenorth> price makes your eyes bleed :o
18:58:59 * andythenorth votes against SSD
19:00:15 <Alberth> lol, you can store my entire HD 3 times at that disk :)
19:00:27 <andythenorth> you clearly aren't stacking up baby pictures :P
19:00:36 <andythenorth> or HD video of amusing toddler incidents
19:01:05 <Alberth> sugar refineries do not explode normally, do they?
19:01:34 <andythenorth> like flour mills
19:01:41 <planetmaker> depends on properties set, I guess
19:01:45 <andythenorth> flour mills explode with huge force
19:01:58 <andythenorth> I'm going to close it
19:03:47 <planetmaker> that works actually remarkably well...
19:04:42 <planetmaker> hm... NML doesn't like cargo type 0xFF for objects...
19:42:26 *** George is now known as Guest4964
19:46:14 *** supermop_ has joined #openttd
19:50:38 <andythenorth> are there any good RV sets yet? :P
19:50:48 <andythenorth> is there a hungarian RV set?
19:52:06 *** Twerkhoven[L] has joined #openttd
19:52:33 <Rubidium> andythenorth: ANYRV set?
19:52:53 * andythenorth tries hungarian set
19:54:19 <Eddi|zuHause> andythenorth: there's an ikarus set, yes
20:02:08 <andythenorth> I have to restart my game
20:02:15 <andythenorth> UKRS 2 disabled itself due to grf order :P
20:02:38 <Eddi|zuHause> ... or you could use developer settings :p
20:03:26 <andythenorth> I forgot that I can do that :o
20:11:45 <George> Hi. A small question. Can towns above snow line/in desert grow when food/water are not defined?
20:14:44 <George> Thanks. Then I'll give goods the food effect in case food is not defined
20:17:10 <Eddi|zuHause> alpine has that problem
20:17:44 *** duckblaster has joined #openttd
20:21:04 *** DayDreamer has joined #openttd
20:23:32 <George> One more question. About CB 14B
20:24:41 *** DayDreamer has left #openttd
20:25:53 *** George|2 has joined #openttd
20:25:54 *** George is now known as Guest4966
20:25:54 *** George|2 is now known as George
20:26:45 <frosch123> that question did not arrive
20:26:54 <George> Prop 11 of action 0 for industries supports this situation fine
20:27:15 <George> [00:24:09] <George> What would happen, if the returned cargo is not defined?
20:27:15 <George> [00:24:39] <George> Should CB fail or next run will happen?
20:28:05 <George> (the situation is the case of the cargo, defined by other GRF)
20:28:44 <George> Property 11 holds it fine. it works well when only the 3-d cargo is available
20:29:04 <George> But would it be the same with CB 14B
20:29:35 <frosch123> currently it fills the slot with "invalid cargo"
20:29:46 <frosch123> so the slot will be disabled
20:30:02 <frosch123> it will not fill up those slots with the 4th or 5th call
20:30:05 <George> would it pass to the next cargo?
20:30:22 <frosch123> it queries all 3 slots
20:33:34 *** andythenorth has joined #openttd
20:34:41 * andythenorth is once again getting slaughtered by a YACD game :(
20:35:10 <andythenorth> no PAX RVs in 1890 makes it *hard*
20:35:21 *** andythenorth has left #openttd
20:43:36 <George> BTW, would during CB 14B var 86 be Number of the selected layout, according to property 0A? (starting from 0?)
20:45:09 <frosch123> ah, 86 is only for cb 28
20:45:46 <George> Industry is already build while CB 14B?
20:46:01 <frosch123> almost, the tiles are not yet planted, but the rest is set up
20:48:34 *** George|2 has joined #openttd
20:48:34 *** George is now known as Guest4969
20:48:34 *** George|2 is now known as George
20:48:50 <George> [00:46:52] <George> so testing var 44 is safe?
20:54:57 <__ln__> np: Leonard Nimoy - Ballad of Bilbo Baggins
20:57:14 <pjpe> is a network made using only path signals slower in cpu than the same network using only block signals?
21:00:03 <Eddi|zuHause> pjpe: there are factors that slow down and other factors that speed up
21:03:16 <Rubidium> having to make the reservation takes time
21:03:33 <Rubidium> but once the reservation is there it simple follows that as if there are no junctions in the rail
21:04:03 <Eddi|zuHause> pjpe: the state of block signals is calculated by breadth-first-search, so large crossings must be fully traversed every time a train is entering or leaving the block, while with path signals, the path finder marks the tracks as it would touch them anyway, also with path signals, generally fewer pathfinder runs are necessary, which takes less time. on the other hand, with path signals, stuck trains must repeatedly check whether the track
21:04:04 <Eddi|zuHause> became free, which takes more time
21:04:18 <Rubidium> when there is no reservation, each switch results in a call to the pathfinder
21:05:05 <pjpe> stuck trains as in stuck at a light?
21:05:05 <Rubidium> so it's balancing amount of reservations vs amount of pathfinder calls
21:06:07 <pjpe> it's better to have block signals normally but path signals in front of say
21:06:21 <Eddi|zuHause> pjpe: if you have straight track with signals, path signals will probably be marginally slower than block signals
21:06:36 <pjpe> really pisses me off seeing that too
21:07:48 <Eddi|zuHause> maybe someone should do a profiling session to determine how much it is actually slower/faster
21:08:00 *** duckblaster1 has joined #openttd
21:12:31 * Rubidium wonders how often openttdcoop.org pings out; seems to be somewhat daily
21:28:36 <Eddi|zuHause> aye, probably a bad idea to check devzone tickets right now :p
21:32:07 *** HerzogDeXtEr1 has joined #openttd
21:38:58 *** ^Spike^ has joined #openttd
21:39:50 *** planetmaker has joined #openttd
21:39:50 *** Terkhen has joined #openttd
21:39:50 *** ChanServ sets mode: +o Terkhen
21:39:50 *** ChanServ sets mode: +o planetmaker
21:41:20 *** Hirundo has joined #openttd
21:41:30 *** George|2 has joined #openttd
21:41:30 *** George is now known as Guest4975
21:41:31 *** George|2 is now known as George
21:41:31 *** XeryusTC has joined #openttd
21:41:50 *** V453000 has joined #openttd
21:42:50 *** DJNekkid has joined #openttd
21:45:27 *** George is now known as Guest4977
22:19:20 *** George is now known as Guest4979
22:19:54 *** perk111 has joined #openttd
22:26:16 *** Illegal_Alien has joined #openttd
22:33:24 *** Brianetta has joined #openttd
22:51:41 *** bellows has joined #openttd
23:43:50 *** Polygon has joined #openttd
23:56:13 *** George is now known as Guest4984
continue to next day ⏵
