IRC logs for #openttd on OFTC at 2012-11-05
⏴ go to previous day
00:38:39 *** Supercheese has joined #openttd
00:59:51 *** supermop has joined #openttd
01:05:09 *** Markavian` has joined #openttd
01:07:01 *** Jake|afk has joined #openttd
02:47:15 *** TyrHeimdal has joined #openttd
04:56:52 *** telanus has joined #openttd
05:56:16 *** Eddi|zuHause has joined #openttd
06:34:20 *** sla_ro|master has joined #openttd
06:49:44 *** Devroush has joined #openttd
07:51:32 *** valhallasw has joined #openttd
08:37:11 *** Jake|afk_ has joined #openttd
08:37:17 *** Jake|afk_ is now known as Jake|afk
08:47:34 *** valhallasw has joined #openttd
09:00:22 *** roland is now known as Guest4567
10:35:05 *** Biolunar has joined #openttd
10:47:20 *** andythenorth has joined #openttd
12:21:26 *** Jake|afk_ has joined #openttd
12:21:32 *** Jake|afk_ is now known as Jake|afk
12:46:11 *** Jake|afk_ has joined #openttd
12:46:16 *** Jake|afk_ is now known as Jake|afk
12:55:35 *** andythenorth_ has joined #openttd
12:55:35 *** andythenorth is now known as Guest4592
12:55:35 *** andythenorth_ is now known as andythenorth
13:18:50 *** andythenorth is now known as Guest4595
13:18:50 *** andythenorth has joined #openttd
13:22:45 *** andythenorth has left #openttd
13:26:57 *** argoneus has joined #openttd
13:32:51 <V453000> is there a 32bpp palette anywhere or does that just mean I can use any 256_256_256 rgb colour without palletizing the image?
13:35:45 <V453000> yes which option ? :D
13:36:59 <Eddi|zuHause> the one that makes sense :)
14:02:00 *** LordPixaII has joined #openttd
14:04:17 *** KingPixaIII has joined #openttd
14:09:42 <Flygon> Which is probaby 32-bit RGB :B
14:45:35 *** frosch123 has joined #openttd
15:04:57 <V453000> I sticked with 8bpp anyway :P
15:07:41 <frosch123> with 32bpp you can give the animation colours different brightness :p
15:08:01 <frosch123> hello sir belugas :)
15:26:36 *** sla_ro|master has joined #openttd
15:30:06 *** oskari89 has joined #openttd
15:51:09 *** DanMacK has joined #openttd
15:55:19 *** andythenorth has joined #openttd
16:18:26 *** RavingManiac has joined #openttd
16:20:07 *** AndChat-613041 has joined #openttd
16:22:43 *** AndChat-613041 is now known as DMacK
16:25:58 *** LordAro has joined #openttd
16:26:04 *** Prof_Frink has joined #openttd
16:45:00 *** Hyronymus has joined #openttd
17:12:44 *** roland is now known as Guest4626
17:37:03 <andythenorth> it's oh so quiet
17:37:13 * andythenorth will talk to himself, that always adds noise
17:50:51 <frosch123> awk syntax is insane
17:53:55 *** Djohaal has joined #openttd
17:54:40 <frosch123> just general, but especially around "|"
18:15:46 <andythenorth> anyone want to script appending '_1' to the end of every .png filename in firs/src/graphics?
18:16:42 <SpComb> for file in firs/src/graphics/*.png; do mv $file ${file/.png/_1.png}; done
18:18:00 <SpComb> for file in firs/src/graphics/*.png; do mv $file ${file%.png}_1.png; done
18:34:00 *** oskari89 has joined #openttd
18:36:29 *** valhallasw has joined #openttd
18:51:06 *** LordPixaII has joined #openttd
18:56:23 *** HerzogDeXtEr1 has joined #openttd
18:58:09 *** TheMask96 has joined #openttd
19:00:46 <andythenorth> so if I have "glass_works_snow_1.png"
19:00:53 <andythenorth> and want "glass_works_1_snow.png"
19:01:32 <andythenorth> for file in firs/src/graphics/*_snow_1.png; do mv $file ${file/.png/_1_snow.png}; done
19:03:50 * andythenorth got there in the end :P
19:07:27 <andythenorth> nml sprite cache makes a big difference to compile time btw
19:07:34 <andythenorth> only noticeable when you rename all pngs :P
19:38:03 *** Progman has joined #openttd
19:45:12 *** oskari892 has joined #openttd
19:45:51 <DorpsGek> Commit by frosch :: r24663 /trunk/src (widgets/statusbar_widget.h window_type.h) (2012-11-05 19:45:45 UTC)
19:45:52 <DorpsGek> -Codechange: Unify the naming of widget enums.
19:53:11 <DorpsGek> Commit by frosch :: r24664 /trunk/src/script/api (5 files in 3 dirs) (2012-11-05 19:53:05 UTC)
19:53:12 <DorpsGek> -Codechange: Add script to generate enums in script_window.hpp
19:56:21 <andythenorth> I need a FIRS makefile target that suppresses the python step :P
19:56:30 <andythenorth> saves me 7s on compile time ;P
19:58:04 <frosch123> take it positive, every compile gives you 7 extra seconds to chat here
19:59:03 <andythenorth> yeah, that's nice for the rest of you :)
20:02:41 <andythenorth> it's bonfire night in UK
20:02:57 <andythenorth> so how about fixing ship smoke? o_O
20:03:07 * andythenorth goes back to fixing FIRS
20:03:23 <DorpsGek> Commit by frosch :: r24665 trunk/src/script/api/script_window.hpp (2012-11-05 20:03:17 UTC)
20:03:24 <DorpsGek> -Doc [FS#5353]: [Script] Add note about the compatibility aspects of the enums in ScriptWindow.
20:06:43 *** Devroush36 has joined #openttd
20:24:10 * andythenorth has brain boggle
20:32:31 <andythenorth> is there any magic date that will serve as 'forever' ?
20:35:24 <andythenorth> is repeating spritelayouts *a lot* a problem?
20:35:46 <andythenorth> it's simpler to have varaction 2 switching layouts than doing logic in the spritelayout itself
20:36:25 <frosch123> add 32bpp sprites to firs
20:36:34 <frosch123> then the size of code will never matter again
20:36:57 <frosch123> s/32bpp/extra zoom/
20:42:55 <andythenorth> so I have "hide_sprite: !(terrain_type != TILETYPE_SNOW);"
20:43:04 <andythenorth> and I need that to also handle date conditions
20:43:17 <andythenorth> so if != snow and if between date 1 and date 2
20:43:21 <andythenorth> how do I do that?
20:44:02 <andythenorth> and in many cases date 1 may be 0, and date 2 may be omitted :P
20:44:21 <andythenorth> but I can handle the latter challenge in python
20:44:59 <Yexo> "hide_sprite: !(terrain_type != TILETYPE_SNOW);" <- please rewrite that to "hide_sprite: (terrain_type == TILETYPE_SNOW);"
20:45:25 <Yexo> how do you have the dates in python?
20:45:54 <andythenorth> as whatever we need :)
20:45:57 <andythenorth> they're not done yet
20:46:04 <Yexo> so pick what you want :)
20:46:13 <Yexo> nml has as function "date(year, month, day)"
20:46:34 * andythenorth removes the double !
20:46:39 <Yexo> so the sprite should be shown below the snowline between certain dates?
20:47:22 <andythenorth> there is an accompanying snow sprite too
20:47:38 <andythenorth> but I can manage copy and paste to that I reckon :)
20:47:57 <Yexo> hide_sprite: (terrain_type == TILETYPE_SNOW) || current_year < $(first_year) || current_year > $(last_year);
20:48:10 <Yexo> please change the python template syntax to whatever works :p
20:48:31 <Yexo> || current_year > $(last_year); <- you can leave that off if the last year is "forever"
21:02:19 <andythenorth> FIRS is getting...complex :)
21:13:27 *** DanMacK has joined #openttd
21:23:26 *** Jake|afk has joined #openttd
21:30:51 *** Chris_Booth has joined #openttd
21:32:32 *** Jake|afk is now known as Jake
21:40:50 *** Jake|afk has joined #openttd
21:40:55 *** Jake|afk is now known as Jake
21:52:15 <andythenorth> helps to put 'return' into a method if you want the value back :P
21:57:16 *** valhallasw has joined #openttd
21:59:17 <Eddi|zuHause> andythenorth: i know this problem :)
21:59:19 <krinn> AI event change names again or i lost something ?
21:59:30 *** Hyronymus has joined #openttd
22:00:31 <krinn> ah, lol ok, no that's me, i miss the new names scheme is only for the eventtype
22:07:46 <andythenorth> what kind of graphics would you like for FIRS?
22:07:57 <andythenorth> or not date sensitive?
22:08:24 <V453000> what does it mean date sensitive? like that they change with the game?
22:08:55 * Terkhen likes the current ones too
22:09:25 <andythenorth> date sensitive = change over time
22:09:35 <andythenorth> e.g. steam cranes -> diesel cranes
22:09:39 <krinn> andythenorth, anything you wish as long as an AI can detect it :)
22:10:32 <krinn> andythenorth, oh i see, you mean temporal evolution of graphism ?
22:12:14 <krinn> as einstein said, shouldn't you end-up with rocks ?
22:12:22 <MNIM> andythenorth: based on build-date with an option to disable, please?
22:13:14 <andythenorth> or to put it another way, what's the benefit ofthat?
22:14:18 <Ammler> making a setting would make the voting useless ;-)
22:14:27 <Terkhen> settings are nice, the more the merrier
22:14:33 <frosch123> i want a webinterface to click and drag my own composition of firs graphics
22:14:40 <Terkhen> proof: see OpenTTD advanced settings window
22:14:49 <andythenorth> frosch123: you can have one, it's paint.NET :)
22:14:53 <Terkhen> but yes, in this case a setting would not hurt :)
22:15:05 <Terkhen> unless it makes some huge mess in the graphics block / callbacks
22:15:12 <andythenorth> no it could be done
22:15:15 <Ammler> so the voting is for default setting
22:15:18 <andythenorth> I just don't see the gain
22:15:31 <krinn> i don't see the point of setting in newGRF as AI cannot click on them themselves
22:15:55 <Terkhen> well, honestly I don't see the gain in redrawing industries again unless it is a very low priority task :P
22:15:59 <Ammler> players can't either, usually
22:16:05 <andythenorth> it seems rather fine-grained to need to control the type of graphics used?
22:16:09 <MNIM> andythenorth: making great eyecandy monuments to my megalomane stations?
22:16:17 <andythenorth> just change the game date
22:16:28 <frosch123> krinn: you want a screenshot api? plus object recognition?
22:16:48 <andythenorth> frosch123: I could encode object information into nml :P
22:16:49 <MNIM> Hmmmh, good point. okay, so no disabling then :P
22:16:52 <andythenorth> if you provide a spec
22:17:08 <krinn> frosch123, well, it would be abuse for that usage, but many engine have extra newGRF feature we cannot choose
22:17:10 <Yexo> frosch123: just a screenshot api, let him figure out the object recognition in squirrel :p
22:17:14 <andythenorth> AIs that auto-screenshot my stuff?
22:17:17 <andythenorth> good for testing :P
22:17:22 <andythenorth> bit like selenium :P
22:18:00 <andythenorth> anyway the poll is moot :)
22:18:02 <andythenorth> the code is done
22:18:05 <frosch123> we should just give ais rcon access
22:18:15 <frosch123> then they can kick the player, if he blocks their station
22:18:18 <krinn> like a triain with 1000HP and 100spd or the same engine with 400HP and 120spd : ai cannot pickup the version they wish... So yes, the more options in newGRF is more trouble for AI as, at best they cannot use them
22:18:22 <frosch123> or they can just stop other ais :)
22:18:43 <frosch123> or move themself to the human company and transfer all money
22:18:45 <andythenorth> krinn: oh, you're going to hate FIRS economies parameter :(
22:18:52 <andythenorth> it's done by the way
22:19:01 <krinn> it's ok don't worry, i hate all newGRF
22:19:10 <Yexo> go almost bankrupt and move the human player to the AI company :p
22:19:21 <Terkhen> I think that krinn means new "models" available via refitting
22:19:45 <Yexo> andythenorth: I don't think FIRS is that bad for AIs
22:19:52 <andythenorth> krinn: do you detect industries and cargos with code, or do you have a lookup table for each newgrf?
22:19:53 <krinn> Terkhen, that's what i saw, but many other hidden stuff may exist, and ones more painful for AI i suppose
22:19:53 <Terkhen> the AIs should be able to detect all present cargos even if FIRS settings change
22:20:21 <Yexo> at least most (all?) industries have predictable cargo's (as soon as the parameter is set they don't change), there are no stockpiles
22:20:34 <Yexo> andythenorth: and it's autodetected of course
22:20:38 <krinn> by code andythenorth but passenger and mail are always problematic
22:20:40 <Terkhen> krinn: having information about all refit "models" available would help both AIs and the refit window itself, which could be improved
22:20:41 <Yexo> AIs can't even figure out which NewGRFs are in use
22:21:00 * Terkhen never liked refit models anyways
22:21:04 <andythenorth> did I mention banning subtypes?
22:21:28 <Yexo> banning subtypes is good for AIs :)
22:21:43 <krinn> Could only detect them indirectly : ikarus vehicle running show ikarus newGRF presence (and it's only assuming that engine is from that set yes)
22:22:19 <andythenorth> subtypes will never be banned; no-one wants the hassle :)
22:22:41 <Terkhen> with regard to detecting refit models, IIRC the NewGRF callbacks that define them can depend on runtime stuff
22:22:42 <andythenorth> leave AI authors to deal with it, they're quite well behaved, and they don't have a crowd of monkeys on the forums backing them up :)
22:22:56 <krinn> But seriously the "i change my length if i'm use with that loco type"... kind of options sucks balls for AI, and i would say even for me
22:23:04 <andythenorth> whereas touching person x's favourite grf causes much throwing of peanuts
22:23:22 <frosch123> just implement sandbox construction
22:23:33 <Terkhen> and therefore OpenTTD cannot check what "false models" are available just with checking the real model, it needs an specific vehicle
22:23:35 <frosch123> and consist-based replacement
22:24:10 <frosch123> wasn't there even a patch on the forums? :)
22:24:55 <andythenorth> subtypes are a social problem, not a spec problem ;)
22:25:21 <Terkhen> we should move NewGRFs to XML
22:25:49 <krinn> i don't know subtypes, but any newGRF that have "hidden" rules sucks, as it's a nuisance for human, and a real pain for AI
22:25:58 <frosch123> we have even decoding
22:26:16 <frosch123> grf2html can convert most grf into xml
22:26:20 <andythenorth> so cb36 is the problem :P
22:26:28 <Terkhen> krinn: yes, but sadly... hysterical raisins
22:27:15 <krinn> Terkhen, i know that, what i don't get is that even as human player, i hate that : you pickup a wagon, change the loco and poof, your train is too long while the wagon was of the good size just before...
22:27:44 <andythenorth> this is seen as character
22:27:51 <andythenorth> and is not about showing how clever the newgrf author is at all
22:27:59 <Terkhen> I only play with OpenGFX+ Trains
22:28:15 <Terkhen> anything else is too complex for my simple train mind :P
22:28:17 <andythenorth> and ships that change speed load / unloaded have immense gameplay benefit, and are not just andythenorth showing off ;P
22:28:26 <frosch123> does musa allow adding grfs as depenencies to ais?
22:28:41 <frosch123> then krinn's ai can depend on ogfx+trains or nuts
22:29:23 <andythenorth> the graphics for all industries of type x will all change at once, everywhere on the map
22:29:24 <Terkhen> oh, I forgot that sometimes I also use the metro part of 2cc
22:29:26 <krinn> newGRF have only create one thing : all AIs learned the magic word "blacklist"
22:29:34 <andythenorth> ^^ this might need some more thought :P
22:30:01 <Yexo> frosch123: not sure, but I don't think it places any restrictions on what can depend on what
22:30:21 <Yexo> but having a bananas dependency doesn't make sure it's only loaded with that newgrf in-game
22:30:30 <Terkhen> andythenorth: use town persistent storage to store a value that determines when will the industry type X of that certain town switch to the new graphics
22:30:34 <Yexo> only that the user has to download that particular newgrf
22:30:39 <andythenorth> Terkhen: nice idea
22:30:43 <andythenorth> or just use random()
22:30:56 <andythenorth> dunno if I can do that in a spritelayout condition
22:31:09 <Terkhen> I'm dissapointed... I was expecting all kinds of crazy stuff with town persistent storage but to my knowledge it still has not been used
22:31:21 <Yexo> if you can do it in a varaction2 chain (= switch-block), you can do it in a spritelayout
22:31:36 <Terkhen> I don't mind it much though, GS already does everything I planned to do with the stuff that requires town persistent storage
22:32:21 <Terkhen> I assume that krinn appreciates that stuff never seeing the light of the day :P
22:33:09 <andythenorth> If I can do it in a varaction2 chain, can ${someone else} write it in a spritelayout for me? :P
22:33:20 <krinn> Terkhen, right assumption : don't put thing that change rules if AI cannot get the rules
22:33:37 <andythenorth> Terkhen: store whether a town is 'progressive' or 'slow' for industry changes :P
22:33:41 <andythenorth> just an offset to dates
22:33:55 <andythenorth> if you can store the var and get it, I can template it in :P
22:34:06 <Terkhen> andythenorth: there is a program that converts nfo into nml :P
22:34:33 <krinn> i saw some have "good usage" of flexibility : i saw truck that change livery with fancy graphics a bit random, but the "i change length..." kind of abuse, are well, abusive
22:34:54 <Terkhen> krinn: yes, other people convinced me that NewGRF was not the right way to control town growth :)
22:35:01 * andythenorth has trams that change length, capacity, all sorts :P
22:35:10 <Yexo> <andythenorth> If I can do it in a varaction2 chain, can ${someone else} write it in a spritelayout for me? :P <- sure, but it's easier if you don't write nfo but very clear steps on what you want to do
22:35:42 <andythenorth> I don't actually know, the line above just sounded good ;)
22:35:56 <krinn> Terkhen, i'm not sure what is the right way, but i'm sure what is the bad way : using something that human, or openttd itself cannot see is the bad way
22:36:41 <andythenorth> give me a param to pass to the method, I'll template the randomness :P
22:36:56 <andythenorth> needs to be a single numeric offset, always same for a specific industry instance
22:37:18 <andythenorth> there are construction-time random bits, never re-randomised?
22:37:59 * andythenorth needs to sleep :)
22:38:35 <Terkhen> krinn: I don't think that the NewGRF specs original design took those goals into account :P
22:38:55 <Terkhen> or that some people would have to improve AIs in the future
22:39:35 <Terkhen> the creation of AIs was probably not even imagined :P
22:39:37 <Terkhen> good night andythenorth
22:40:17 *** supermop has joined #openttd
22:40:20 <Terkhen> there was a discussion about scrapping the NewGRF specs recently, although for different reasons
22:40:41 <krinn> some technical difficulties can be solve, but with a pain solve, like building all wagons and refit them to see their real properties when built (but it have a cost, and it's a pain to code), but some are simply undoable : how could i refit to the 800hp 100spd the engine if i don't have the API to do it ?
22:41:26 <Yexo> krinn: this and similar issues have been known since the beginning of NoAI development
22:41:39 <Yexo> however even at that time there were a vast amount of NewGRFs
22:41:48 <Yexo> breaking compatibility with the existing content wasn't very nice
22:42:37 <krinn> Well, it's because it's see as an AI problem, when it's a newGRF problem that affect openttd itself : why openttd cannot told me (a human, well, assume as human) that this wagon cannot be use with that loco until i brought it
22:43:12 <Terkhen> because OpenTTD itself does not know it either until the loco is bought and you try to attach the wagon
22:43:27 <Yexo> the newgrf specs have organically grown, there are worse issues in it than this
22:43:29 <Eddi|zuHause> given the popularity of some older newgrf sets and the length of their release cycle, it would probably a bad idea to "scrap" parts of the newgrf specs
22:43:33 <krinn> and we end with the problem : how could an AI query openttd to answer something openttd cannot answer itself :)
22:43:34 <frosch123> Terkhen: that's why you need a sandbox construction mode :)
22:43:44 <Eddi|zuHause> i won't name names *hüstel*
22:43:52 <Terkhen> frosch123: what do you mean with that?
22:44:24 <frosch123> Terkhen: imagine something like template based autoreplace. you would be able to compose consists, without actually building them
22:44:32 <krinn> Terkhen, i suppose the "build all wagons, record their properties, sell them" is a sandbox
22:44:36 <frosch123> you would see all properties of the final consist, and then build it as a whole
22:45:05 <Eddi|zuHause> why is that not included yet? was something wrong with the last implementation?
22:45:05 <frosch123> btw. don't blame the specs on everything :p i mean which ai supports gs?
22:45:19 <frosch123> Eddi|zuHause: i did not look at it
22:45:29 <krinn> more than you think (well sooner) frosch123 :)
22:46:03 <frosch123> krinn: that requires the ai to know the gs exactly
22:46:25 <frosch123> we can also just expose the grfid to ais. you can add support for all 500 newgrfs just fine
22:46:28 <frosch123> no problem at all :p
22:46:29 <krinn> no, this requiere the ai to know the api of the gs : like an ai need to know the api of openttd
22:46:44 <Eddi|zuHause> one problem with the newgrf specs is the utter uselessness of cb18
22:47:07 <frosch123> Eddi|zuHause: we don't even support that
22:47:20 <Eddi|zuHause> yes, but that's a hen-egg-problem
22:47:39 <Terkhen> frosch123: my NewGRF-fu is quite rusty so maybe I'm saying something impossible, but what if I define that a wagon cannot be attached to a consist that is carrying fruit or some other condition that does not depend on the consist itself?
22:47:42 <Yexo> we support cb18 for stations ;)
22:47:57 <krinn> we made scp using commandSet (read API there), so any GS using that commandSet will be runnable with an API handling that commandSet
22:48:20 <krinn> -> /sAPI/AI ill be runnable with an API handling that commandSet
22:49:08 <frosch123> Terkhen: imo the goal is to make ais only use stuff that humans need as well
22:49:26 <frosch123> a newgrf is unlikely to implement something which breaks something many humans want to use
22:49:36 <frosch123> however, usually they won't bother about ais
22:50:06 <Terkhen> besides crazy corner cases like the one I mentioned, that sandbox construction mode should work
22:50:13 <Eddi|zuHause> cb18 for trains could work similar to the articulated callback, i.e. the AI passes general data like train length, cargo and station distance, and the NewGRF returns vehicle IDs and refit subtypes until it returns "no more vehicles"
22:50:26 <frosch123> krinn: does it support easy integration of sillicon valley?
22:51:44 <krinn> never saw it frosch123 tbh, it depend what the GS do and what AI can do with it
22:51:47 <frosch123> Eddi|zuHause: as far as i have seens ais building trains up to now, the main problem is that we have no method to tell ais about the weight
22:51:54 <frosch123> so, all trains are usually stuck at some hill
22:52:13 <frosch123> has some screenshots
22:52:43 <frosch123> you would really impress me, if scp supports that without the ai explcitly knowing about the gs
22:52:51 <krinn> build 3 industries goal is the facto a no
22:53:28 <krinn> the 2 others are easy to do
22:53:37 <krinn> the 4rd depend on the 1st
22:54:42 *** valhallasw has joined #openttd
22:55:10 <krinn> your first goal cannot be made with an AI if i'm right, we don't own the BuildIndustry function
22:55:39 <frosch123> ais can do that for long
22:56:00 <frosch123> zuu added stuff to gs, which humans cannot do
22:56:04 <krinn> oh let me check (not something i really bother to do, building industry)
22:56:19 <frosch123> something in AIIndustryType
22:56:36 *** DanMacK has joined #openttd
22:58:29 <krinn> so frosch123 this answer your main question : yes AI can play with sillicon valley
22:58:56 <frosch123> krinn: my question was, whether an existing ai can play with gs, without knowing about the script
22:59:11 <frosch123> i.e. can ais deal with it, which were written before silliicon valley
22:59:16 <krinn> no, like any AI cannot play with knowing a new API
22:59:27 <frosch123> exactly, that's the point
22:59:38 <frosch123> you have to adapt every ai to every single gs
23:00:22 <krinn> just like you need to adapt your AI to everything that is new : closing airport will be a pain for older AI while with the new API AI can manage that
23:00:32 <glx> maybe add HasGoal() or GetGoalList()
23:00:53 <frosch123> glx: plus an english dictionary? :p
23:01:26 <frosch123> krinn: so, why is it so bad then to support 500 apis for 500 different newgrfs then :p
23:02:06 <krinn> because you have 0 API for newGRF : you cannot tell anything to AI, and worst, even openttd is foul about them
23:02:30 <frosch123> yes, just the same as for gs
23:02:48 <frosch123> gs cannot tell ais anythign about them without defining a special api
23:02:49 <krinn> if you made an API that expose possible wagon length before their creation : openttd can display that to human and AI can query that thru API
23:03:42 <frosch123> the problem is not the lack of any api, the problem is that a few grfs are just very different to others
23:03:52 <frosch123> no generic api will ever support all newgrfs
23:04:02 <frosch123> just as no generic api will ever support all gs
23:04:34 <krinn> well, for me, it looks more like anarchy than anything
23:04:45 <glx> there's a newgrf with silly industry placement requirements
23:04:48 <frosch123> it's the independency of plugins
23:04:55 <krinn> even dumb i'm sure you can build an engine that claim to be a train that once brought is a chopper and crazy things like that
23:05:17 <glx> (well not only one indeed -> ECS)
23:06:03 <glx> even for humans it's very hard to build something without looking at the docs
23:06:28 <frosch123> yeah, ecs will likely not work with sillicon valley :)
23:06:38 <frosch123> nothing bad about that, players just have to decide
23:06:46 <frosch123> ecs has basically a gs integrated
23:07:26 <glx> yes, with production variations depending on dates
23:07:46 *** tokai|noir has joined #openttd
23:07:47 *** ChanServ sets mode: +v tokai|noir
23:08:15 <frosch123> glx: well, i guess that is no problem. people who want to play with seaonsal changes, likely don't play with ais
23:08:30 <frosch123> ais don't fit the scenery of a model railway
23:08:50 <krinn> i don't see a problem with that, AI will see production change no ?
23:09:04 <krinn> even the AI cannot know the date the change occurs
23:09:17 <frosch123> krinn: it does not matter
23:09:24 <frosch123> the production changes seasonal
23:09:30 <frosch123> some industries produce only in summer
23:09:43 <frosch123> so, your trains only load half of the year, and wait the other half
23:09:46 <glx> they will see it, but without knowing the industry produces for only 3 months they will bankrupt rapidely
23:09:54 <frosch123> i actually have no idea how humans play with that :p
23:10:10 <frosch123> i doubt they send the trains to the depot every half year
23:10:15 <frosch123> or send them on a different route
23:10:17 <glx> and there are also industry chains
23:10:57 <glx> and "special" cargo increasing productions, but not required
23:11:28 <Yexo> <krinn> i don't see a problem with that, AI will see production change no ? <- try your AI in a game with ECS and see how well it copes
23:11:32 <frosch123> yup, and for such stuff there will never be an api :p
23:11:38 <Yexo> it's very hard to support
23:11:47 <frosch123> such special mechanics only work when the ai/human know exactly about the grf
23:12:38 <krinn> frosch123, like i said : if no API exist to inform the AI any fancy trick the newGRF do cannot be seen
23:13:08 <frosch123> krinn: what i am trying to tell you all the time. there will never be an generic api
23:13:20 <frosch123> it does not matter whether it is a newgrf or a script
23:13:28 <glx> IIRC ECS also use stockpiling and stop accepting cargo when full
23:13:29 <frosch123> the "language" is not the problem here
23:13:51 <frosch123> ecs and sillicon valley provide very special mechanics
23:14:06 <frosch123> an ai will only be able to cope with them, if it is explicitly coded for them
23:14:47 <frosch123> if you want an api, the only api that makes sense is one which tells, which newgrf or gs is running
23:15:00 <frosch123> then you can implement special behaviour for those you know
23:15:06 <krinn> and what i'm telling you isn't that : i'm telling you as long as you can tell the AI what is going on, an AI could be made using it
23:15:56 <frosch123> i am only interested in generic apis :)
23:16:20 <frosch123> i.e. where you can make the ai before the gs/newgrf is coded
23:17:46 <krinn> well, impossible to do, just like now: AI can only use function from API version it handle, how could it use functions that doesn't exist yet :)
23:20:08 <krinn> Take the engine simple example: if you made an API for AI that can query the engine refit properties before building them, the AI (yes after update) will be able to handle any engine with such a feature
23:20:23 <Yexo> krinn: an AI written a few years ago can cope perfectly with new vehicle NewGRFs that are written today
23:20:30 <Yexo> as long as no fancy tricks are used of course
23:20:38 <Yexo> but for the general case the existing API works
23:21:00 <krinn> Yexo, yes, but fancy tricks is the problem
23:21:21 <frosch123> i thought that's what makes it interesting :p
23:21:26 <Yexo> so you want to extend the API with a new function for every fancy trick used by one NewGRF or one GameScript?
23:22:19 <krinn> GS part is doable now, newGRF still need one
23:22:42 <Yexo> that means towards NewGRF we have two options: 1) Give them freedom like now and try to detect a lot of special cases. Hard to get right. 2) Limit the freedom of NewGRF authors by giving them only access to some well-defined functions. These functions can be exported to AIs without any problem
23:22:56 <Yexo> option 2) would make the live of AI devs a lot easier
23:23:16 <krinn> why only AI ? option 2 is good for humans too
23:23:24 <Yexo> but it's A) not backwards compatible and B) limits the freedom of NewGRF devs that has created so many nice NewGRFs until now
23:23:38 <krinn> if you don't know the newGRF you are playing with, you get bore fast with the stupid things they add in them
23:23:53 <frosch123> krinn: it's not good for humans
23:24:04 <frosch123> it means they have to wait for ecs till 2030
23:24:19 <frosch123> it's like implemeting everything directly into openttd
23:24:28 <frosch123> there would be no plugins at all
23:24:40 <krinn> i have add many vehicles for testing against my AI, and try myself play with that, and get bore to see a wagon change because of this or that magically
23:25:04 <frosch123> well, then you should not play with those :)
23:25:16 <krinn> endup with buying classic wagon and engine as i'm not an AI to test all possibilites
23:25:20 <frosch123> different players, different interests
23:25:53 <krinn> for ecs or newGRF that change gameplay yes
23:26:02 <krinn> but seriously affect gameplay with vehicle just sucks
23:26:26 <frosch123> that's a very personal opinion :)
23:26:26 <krinn> specially because openttd cannot warn me in the selection screen as itself cannot know it
23:26:57 <Yexo> others like trams that can be refit to different lengths because it keeps the list of all engines shorter
23:27:05 <Yexo> which is something that doesn't bother AIs, but does bother humans
23:27:44 <krinn> well, the problem came from not knowing: if tram of size 10 can be refit to size 8, human might like that and pickup the size he wish
23:28:33 <krinn> but if openttd don't tell the human the tram size will be 8 because of this: the human buy a tram of length 10 to endup with a 8, and it's boring
23:30:05 <krinn> so having size change with refit is a perfect example, human can see refit option and pick the one he like : it's totally different than having an option on screen telling you size 10 and when buying it because of wagon Z add to it, the size change to 8
23:30:57 <krinn> after testing 3-4 engines, i gave up with all this shit, and endup with classic engine, because they do what openttd is telling you they will do
23:31:43 <krinn> Just like the new aircraft distance limit
23:32:12 <krinn> you brought an aircraft because the prize capacity and all and : what the fuck i cannot use that because my airports are too far
23:32:49 <Yexo> again: some players like that, others don't. If you don't, disable the aircraft limits altogether
23:33:29 <krinn> i'm not sure if recent openttd change it
23:33:47 <krinn> but last time i try : it wasn't telling me the distance an aircraft could do
23:34:20 <krinn> so you cannot pickup an unknown aircraft as you cannot be sure if it have the limit or not
23:35:05 <Yexo> I thought the distance was displayed in the purchase menu, but never really bothered to check
23:35:16 <krinn> last time i try, it wasn't
23:35:31 <krinn> let me check (but i'm using 1.2 now)
23:37:13 <Yexo> it doesn't display the range
23:37:14 <krinn> i'm not sure on 1.2 it tell me refit... i don't see anything related to distance and i think it's that newgrf
23:37:36 <Yexo> something to be improved
23:37:48 <krinn> building two airport, buying an aircraft and got the error now
continue to next day ⏵