IRC logs for #openttd on OFTC at 2015-01-10
⏴ go to previous day
01:51:19 <Gather> hmm i experience connection drops while saving
02:04:48 *** supermop has joined #openttd
02:17:54 <Elyon> humm, not allowing spritesets with different sizes in spritelayouts seems an unfortunate limitation for station layouts
02:19:41 <Elyon> it would be quite useful ie. for compositing platforms, buildings, cargo, fluff sprites in the same layout
02:36:08 *** Quatroking has joined #openttd
04:49:23 <Elyon> why is the newgrf specs for stations so inconsistent with the specs from every other feature? T_T
05:38:27 *** luaduck_zzz is now known as luaduck
05:56:16 *** Eddi|zuHause has joined #openttd
06:36:16 *** supermop has joined #openttd
07:36:06 *** Pensacola has joined #openttd
08:36:38 *** Alberth has joined #openttd
08:36:38 *** ChanServ sets mode: +o Alberth
08:45:20 *** supermop has joined #openttd
08:57:41 *** sla_ro|master has joined #openttd
08:58:08 *** HerzogDeXtEr has joined #openttd
08:59:04 *** andythenorth has joined #openttd
09:00:18 <andythenorth> Alberth: I started a BB game
09:01:27 <Alberth> OpenTTD can do that? :)
09:02:26 <Wolf01> if you play on the laptop while in bed and eating your breakfast, why not?
09:03:47 <Alberth> hmm, never done either of those :)
09:07:00 <andythenorth> Alberth: do you want to release it? 0_O
09:07:25 <Alberth> sure, needs some small stuff added, doesn't it?
09:09:01 <andythenorth> gpl license.txt, readme?
09:09:13 <andythenorth> I’m out for a couple of hours, could do it when I get back
09:09:33 <Alberth> ok, haven't decided what I'll do to day yet :)
09:10:27 <andythenorth> my decision are made for me :)
09:57:52 *** Suicyder has joined #openttd
10:41:04 <Alberth> but but.... your game?
10:47:02 *** Lucky89666 has joined #openttd
10:47:14 <Lucky89666> helló segít valaki?
10:48:08 <Lucky89666> my name is adam help me?
11:09:44 *** Progman has joined #openttd
11:11:54 *** Suicyder has joined #openttd
11:12:37 *** Extrems has joined #openttd
11:31:24 *** Myhorta has joined #openttd
11:38:18 *** gelignite has joined #openttd
11:51:42 *** itsatacoshop247 has quit IRC
12:05:22 *** frosch123 has joined #openttd
12:06:54 <frosch123> Elyon: spritesets can have different sizes
12:07:23 <frosch123> but possibly nml does not allow that yet, since it is a newer generalisation
12:09:40 <Alberth> or rather, liquid of otherwise unspecified nature, to allow automagic transformation to desired drinks
12:14:11 *** Quatroking has joined #openttd
12:22:13 <frosch123> there is even a diff, not sure what it actually implements though
12:26:16 *** andythenorth has joined #openttd
12:31:46 <andythenorth> I think it works well, so far :)
12:31:57 <andythenorth> might redeem FIRS Full
12:32:38 <andythenorth> makes it less overwhelming + stupid
12:32:52 *** Supercheese is now known as Guest1385
12:32:58 *** Supercheese has joined #openttd
12:33:17 <V453000> what did you come up with? :D
12:33:31 <andythenorth> I tried on a FIRS Basic economy first, but that was a bit boring, not enough cargo variety
12:33:44 <andythenorth> V453000 Busy Bee, it just assigns n simple cargo goals
12:33:52 <andythenorth> default is 5, with 10 years to complete
12:33:59 <V453000> that doesnt change anything ._:
12:34:23 <andythenorth> it reduces choice
12:34:55 <V453000> the real choice is metal/oil already ._.
12:35:26 <V453000> and assuming you want to win some gs, you need to grow industries, so you need metal/oil again
12:35:45 <andythenorth> there’s no win condition
12:35:59 <V453000> what is it about then
12:36:17 <Alberth> make connection, make stuff
12:36:47 <Alberth> next goal: make connection, move stuff
12:36:59 <Alberth> next goal: make connection, move stuff
12:37:12 <andythenorth> when bored, make new GS
12:37:15 <V453000> that isnt so bad then :)
12:37:28 <andythenorth> it’s a stepping stone, not the Best GS Ever
12:37:36 <Alberth> well, 6,400 mail in 10 years? :p
12:38:12 <andythenorth> the ratio of “talk about GS” to “actual GS you can play” is unsuitable currently
12:38:16 <Alberth> but if you fail, no problem, you just get a new goal
12:38:44 <andythenorth> make GS, play GS, make better GS
12:39:48 <andythenorth> I started in 1870
12:39:50 <V453000> when bored, create YETI :P
12:39:54 <andythenorth> going to see if I can make it to 2010
12:40:11 <Alberth> that's a long time :)
12:41:18 <andythenorth> full date range of Iron Horse, Squid, Road Hog
12:41:39 <andythenorth> it’s actually in later game that I hope it makes a difference
12:42:21 <Alberth> I pondered making BLOCKy some time, all industries look like blocks of different colours, and they produce small blocks in the same colour to transport. You can configure the industry chains
12:44:00 *** stefkos has joined #openttd
12:44:46 <stefkos> anyone can help with OpenTTD code for MorphOS?
12:45:18 <stefkos> It crash somewhere in thread_morphos.cpp
12:47:46 <Alberth> build with debugging symbols, play until crash, analyze the post-mortem?
12:49:40 <Alberth> don't think there are many MorphOS users here besides yourself
12:50:08 <Alberth> you could try a MorphOS specific channel perhaps?
12:50:39 <Alberth> they may know more how threads work at that OS
12:53:40 <Alberth> if it crashes at a device, you could also try the channel about the library that is used
12:54:18 <stefkos> well as I see only native functions are called
12:54:19 <Alberth> maybe they have some known morphOS issues
12:54:25 <stefkos> to create/work with threads
12:56:06 <Alberth> yeah, c/c++ tends to have extremely thin wrappers to system calls :)
12:58:35 <stefkos> I will find and kill that bug:)
12:59:35 <stefkos> atm I think that 1 msg structure is unallocated/wrong or 2 pointer to function is wrong
13:06:59 *** shirish has joined #openttd
13:08:18 <frosch123> there were very recently changes to morphos threading in trunk/1.5
13:08:49 <frosch123> so, we have 3 morph os users :p
13:24:23 <skrzyp> frosch123: I know those mos developers (as I had one mos machine with license)
13:24:31 <skrzyp> they are very wird persons
13:24:55 <skrzyp> with very big hate to everything "unixy"
13:25:20 <skrzyp> (they are even called openttd devteam as "linux guys")
13:26:09 <skrzyp> working with them are extremely hard, because they didn't care about updating, compatibility and portability
13:26:28 <skrzyp> (except this portability means their own PPC machines)
13:28:26 <skrzyp> frosch123: lol, I've copied your messages to stefkos, and he said something like "I see someone works on it, so I don't care about this game", and left
13:29:01 <Alberth> thanks for forwarding
13:29:36 <skrzyp> it probably doesn't changed everything
13:33:00 <Rubidium> ... and locally modified
13:33:12 <skrzyp> But he probably event can't imagine this
13:34:06 <skrzyp> It's funny that MorphOS userland situation looks exactly the same in all 3rd party projects
13:34:52 <skrzyp> they're using old MPlayer, ancient GCC (2.95 and 4.4 changeable), new browser based on old WebKit, some early MAME version, etc., etc.
13:35:40 <skrzyp> It's a reason why I sold my MacMini G4 with morphos keyfile
13:36:42 <skrzyp> Devs are totally uncommunicative, I've tried to port Atari800 emulator and they're told me it's a "linux crap"
13:37:42 <skrzyp> Probably because I've used HOME veriable to put settings into applications' bundle folder - MorphOS doesn't have home directory and multiuser capabilities.
13:38:15 <frosch123> hmm, oh, lol, i actually confused morphos with os/2
13:38:28 <frosch123> the recent changes were to os/2 :p
13:38:42 <Rubidium> frosch123: so, two os/2 users and one morphos user?
13:39:28 <skrzyp> OS/2 is called eComStation today (and quite actively developed)
13:39:54 *** Myhorta has joined #openttd
13:45:06 *** Zeetherdroid has joined #openttd
15:05:36 *** gelignite has joined #openttd
15:07:49 *** andythenorth has joined #openttd
15:13:09 *** Phoenix_the_II has joined #openttd
15:32:23 *** Myhorta has joined #openttd
16:08:49 * andythenorth considers a dumbed-down parameter for FIRS
16:18:49 <andythenorth> stupid docks on rivers
16:19:10 <andythenorth> really, fix that, and we’re done
16:19:13 <andythenorth> the game is finished
16:30:44 <Elyon> frosch123: ah, hmm, so what do you suggest I do for the time being regarding spritesets referenced by spritelayouts? Just add dummy sprites while developing?
16:31:58 <Elyon> frosch123: also, I added a wall of text on issue 2746
16:37:36 <b_jonas> what about docks on rivers? are they just ugly because they cover the whole width of the river? or is there a bigger problem?
16:38:42 <andythenorth> I think they should be made more difficult to build
16:39:02 <andythenorth> and also realisms
16:39:26 <andythenorth> I think they should require at least 15 tiles or so
16:39:51 <V453000> is proportional to 2x3 industry :P
16:40:34 <andythenorth> we need to enforce that
16:40:45 <b_jonas> andythenorth: add a depot to it
16:41:10 <b_jonas> oh, you already have in that second image
16:41:49 <andythenorth> the idea of 2x1 docks that can be built on flat tiles simply appalls me
16:41:53 <andythenorth> that’s just not TTD
16:42:19 * andythenorth is doing that thing again
16:44:59 <NGC3982> That looks wonderful.
16:46:02 <Elyon> frosch123: "The block of data that always follows after action 01 should consist of num-sets * num-ent RealSprites or RecolorSprites." <- hmm, I think action1s have to be restructured a bit to support multiple actual spritesets in the same action1
16:49:07 <NGC3982> and.. Why does he not use a bouncer or shell or something.
16:49:13 <NGC3982> Quits are not for IRCs.
16:49:54 <V453000> he will be back before you know it :P
16:50:24 <NGC3982> Can flat-tile docks be possible with NewGRF?
16:50:28 <Elyon> frosch123, ie. the station spritelayout could benefit from varying sizes of spritesets but I am not sure how to provide these
16:50:53 <V453000> NGC3982: newGRF probably cant do that
16:52:49 <frosch123> Elyon: since ottd 1.3 or something you can split defintion of spritsets over multiple action1
16:53:30 <frosch123> the patch in #3739 adds the action1 writer for that
16:54:03 <frosch123> def __init__(self, feature, first_set, num_sets, num_ent): <- define sets [first_set, first_set + num_sets) containing num_ent sprites each
16:54:24 <frosch123> by using multiple action1 you can define a series of spritesets with different amount of sprites
16:54:49 <Elyon> but the patch does not use multiple action1s I believe
16:55:04 <frosch123> no, it's only a partial implementation
16:55:14 <frosch123> + actions = [Action1(self.feature, 0, len(self.spritesets), self.num_sprites_per_spriteset)] <- it always passes 0
16:55:51 <Elyon> well, I can take a look at it but it isn't strictly necessary and not really related to stations
16:55:55 <Elyon> it's just a nice feature to support
16:56:12 <frosch123> sure, for now you can just add dummy sprites to fill the sets to the same amount
16:56:38 <Elyon> also ... how do you feel about `AbstractLayout` ?
17:00:02 <frosch123> i have no idea what you mean with that? are you talking about the implemetation, or do you have a new nml syntax in mind?
17:01:05 <Elyon> NML syntax stays the same, this is just a suggestion for reducing the amount of code duplication in the NML source, when implementing spritelayouts-as-property
17:01:19 <frosch123> iirc the syntax within the station property 1A and within spritelayout action2 is mostly the same, so i guess a base class which writes the layout should work
17:01:32 <Elyon> that is the idea exactly
17:01:43 <Elyon> the syntax is exactly the same once you reach the actual layouts
17:03:35 <frosch123> well, ottd also uses a common function to read them :)
17:03:42 <Elyon> anyway, how do you feel about the name `AbstractLayout` for this base class? Then we can do => `class Action2Layout(action2.Action2, abstract_layout.AbstractLayout):`, and the same for `StationSpritelayoutsProp`
17:03:53 <frosch123> though it also has to handle the deprecated syntax forms
17:04:04 <Elyon> what deprecated syntax forms?
17:04:14 <Elyon> I guess NML shouldn't worry about those
17:05:24 <frosch123> i only was looking at the ottd source and the conditional parameters for parsing spritelayout format
17:06:19 <Elyon> alright then! I have abstracted most things except `def get_layout_action2s` into the abstract layout class. Great care must be taken to abstract `get_layout_action2s`
17:08:22 <frosch123> Elyon: nml naming schema seems to use "Base" prefixes instead of "Abstract"
17:08:48 <michi_cc> NGC3982: Flat-tile docks are already possible with NewGRF, just not implemented in OTTD (and maybe neither in TTDPatch, I've only ever seens the specs entry and a screenshot).
17:08:51 <Elyon> frosch123, ah, I will call it `BaseLayout` and have it reside in "./actions/base_layout.py" then
17:09:17 <NGC3982> I have never understood what TTDPatch is.
17:09:28 <NGC3982> Is it a version of the game? A script? Am i using it right now?
17:09:52 <Alberth> it's the original TTD executable, patched with extensions
17:10:54 <Elyon> INFO: `get_layout_action2s` gets both the expression-varaction2s, and the actual layout-action2. The former can (and imho should) be abstracted into "base_layout.py" as the expression-varaction2s are needed for layouts as action2 as well as layouts as property 1A
17:10:57 <NGC3982> Since it describes 7*7 stations and mammoth trains, i guess it is no longer a viable way of playing OpenTTD?
17:10:58 *** gigglebla has joined #openttd
17:11:10 <NGC3982> In comparison with current vanilla version of the game.
17:11:32 <gigglebla> hey do you guys know about setting up servers
17:11:37 <michi_cc> NGC3982: There is not relation at all to OTTD.
17:11:50 <gigglebla> my friend and I have been trying but it doesn't show up
17:11:57 <NGC3982> Do people still play with it?
17:12:05 <Elyon> gigglebla: port forward? advertised?
17:12:13 <gigglebla> hold on let me get him
17:12:33 <frosch123> Elyon: so, to answer your questions: 1: BaseLayout in actions/base_layout.py 2: no 09, only 1A; 0A definitely not in the first version 3: arrays for non-stations should be a syntax error?
17:13:40 <Alberth> interestingly, "advertise fails" is not a FAQ :)
17:13:42 <Elyon> 2) duplicate 1As containing all layouts for all stations?
17:13:45 <michi_cc> It certainly doesn't help TTDPatch though that most references on the homepage (and the main advertised download link) refer to a truly outdated version instead of the what people should use.
17:13:57 <Elyon> 3) so no support for station+non-station-spritelayouts?
17:16:42 <frosch123> Elyon: using 0A is a bonus for later; if you really want to, you can add it; but i would just skip it for now
17:17:17 <frosch123> 3: as you describe [] for non-stations, it is no array, for a list of instructions as in nml switches
17:17:42 <frosch123> giving [] different meanings in station and non-station layouts i would call a bad thing
17:17:49 <b_jonas> michi_cc: well, openttd is sort of like that too. the screenshots on the homepage are for old versions, and the wiki talks mostly about signals in old versions (before path signals)
17:18:01 <frosch123> so, no idea whether anyone uses [] currently in spritelayouts, but i would forbid it
17:19:38 <michi_cc> b_jonas: TTDPatch 2.0 to 2.5 beta whatever is something like OTTD 0.3 to now, which is a lot more than just path signals.
17:20:03 <Elyon> okay, hmm ... so spritelayouts with array values are inherently station-only, whereas spritelayouts without array values can be both station and non-station
17:20:46 *** MTsPony has joined #openttd
17:30:53 *** gigglebla has left #openttd
17:46:44 <DorpsGek> Commit by translators :: r27116 /trunk/src/lang (esperanto.txt slovak.txt) (2015-01-10 17:46:35 UTC)
17:46:45 <DorpsGek> -Update from WebTranslator v3.0:
17:46:46 <DorpsGek> esperanto - 1 changes by polluks
17:46:47 <DorpsGek> slovak - 15 changes by Blayss
17:48:36 <Elyon> how would I add an entirely new file with mq?
17:49:37 <Elyon> but that adds it to the commit, no?
17:49:42 <Elyon> the "real" commit, I mean
17:49:56 <Eddi|zuHause> if you're currently in a patch, it should add it to that patch
17:50:23 <Eddi|zuHause> the patch is a "real" commit, as far as your local working copy is concerned
17:50:41 <Elyon> `hg status` => "? nml/actions/base_layout.py"
17:50:47 <Elyon> `hg status` => "? nml/actions/base_layout.py"
17:51:01 <Elyon> aooh nevermind okay, will try
17:51:48 <Elyon> Eddi: yup, it worked flawlessly. I still have a few things with mq I need to wrap my head around, it seems :3
18:00:34 *** andythenorth has joined #openttd
18:07:00 <andythenorth> do we have news for completing a goal?
18:07:05 <andythenorth> I know, I could read the code :P
18:07:34 <Sylf> I don't remember a thing about news related class or functions in GS
18:07:49 <Alberth> I wondered whether to add it
18:08:12 <andythenorth> and for new goal
18:19:56 *** sla_ro|master has joined #openttd
18:20:36 <Alberth> andythenorth: when you remove or move strings, the minimal version number to load needs to be incremented, I found
18:23:04 <Elyon> hm, /some/ restructuring will have to take place as every spritelayout is assumed to correspond to one action 2
18:25:56 <frosch123> Sylf: nocargoal gives monthly stats via news
18:26:46 <frosch123> though since news are global, i prefer the company specific goal gui for that stuff
18:27:06 <Sylf> which stats does it show?
18:27:18 <frosch123> amount transported, months left, percentages
18:27:32 <frosch123> however, i have no idea how it works with multiple companies
18:27:52 <Zuu> IIRC you send news to a company in GS
18:28:27 <frosch123> hmm, true, some news are also company specific in ottd
18:28:32 <Sylf> I remember classes about story books etc, but nothing about news
18:29:07 <Zuu> GSNews has been there ever since GS was introdueced. :-)
18:29:21 <frosch123> i believe news are older than goal gui :)
18:29:56 <Zuu> I think the goal GUI was in the first stable offering GS. But the story book came later.
18:29:58 <Sylf> so you can introduce new goal for a company via news message if we want
18:30:13 <frosch123> yeah, but news are inferior
18:30:21 <frosch123> you cannot link a location and such
18:30:27 <frosch123> and players will miss them anyway :p
18:30:32 <frosch123> or have them turned off :p
18:30:49 <Zuu> You should stick the goal into the goal GUI and then you can also inform them about it in the news.
18:30:49 <andythenorth> Alberth: does the string change break my savegame then? :)
18:31:18 <Alberth> it looks like it stores the string number to use in the goal window
18:31:54 <Sylf> ok good, GSNews is included in paste.o.o syntax highlighter
18:32:18 <Zuu> There is no API for opening the goal GUI. But there is one to open the Story book which should be used with care as players cannot disable you opening that window.
18:32:46 <Alberth> /me ponders annoyingGS :p
18:33:06 <Zuu> Yeah reordering strings break save/load :-)
18:33:27 <Zuu> I've learned the hard way :-)
18:34:22 <Eddi|zuHause> is that not fixable through after load handling?
18:35:04 <Alberth> gs has no afterload function afaik
18:35:05 <frosch123> scripts are not updateable
18:35:36 <frosch123> you have to treaten it to even reload your lang files
18:35:39 <Zuu> GSes can fix it by rebuilding the goal list and story book content upon load
18:35:48 <frosch123> normally it reuses the translations stored in the save
18:35:52 *** MTsPonyZzZ has joined #openttd
18:35:52 <Zuu> Also re-setting town description text etc.
18:36:13 <Eddi|zuHause> frosch123: "officially" :)
18:36:51 <Zuu> That assumes the GS as an in-memory copy of all parameters etc. to update all strings.
18:37:38 <frosch123> Eddi|zuHause: scripts are a lot more complicated than newgrf there
18:37:47 <frosch123> they store the lang files inside the savegame
18:38:11 <frosch123> the script otoh is not stored in the save
18:38:22 <frosch123> so you easiyl end up with a newer script than texts
18:38:39 <frosch123> the script will use a textid, but the text will be something entirely different
18:39:22 <Eddi|zuHause> that sounds weird
18:39:34 <frosch123> as said: scripts are not updateable
18:39:51 <frosch123> not only "officially", it's really broken resp. not implemented at all
18:40:14 <Zuu> Hmm, I though it was that it would use the lang files of the script found upon load. And the conflict was that the string IDs stored in the save game may not match the ones computed from the new lang files.
18:40:20 <frosch123> you can reload the script via the debug gui, but that will clear all script data
18:41:49 <Zuu> But if it store translation strings in the save and use those instead of those provided by the (new) script, then the GS will be unable to work around it by passing all strings to OpenTTD again.
18:47:32 <frosch123> hmm, maybe we fixed that
18:51:16 <Zuu> Both cases still means that script developers should preferable not delete or reorder strings unless min compatible version is updated.
18:51:22 <frosch123> no, i found the working copy with the partial fix
18:51:50 <frosch123> so, the new lang files are loaded, but the new STR_XXX constants are not registered
18:52:23 <frosch123> so, scripts cannot use new STR_XXX constants, and if they were inserted in the middle, the printed texts will differ
18:56:17 <Elyon> `SpriteLayout#get_action_list` needs to have a spritelayout-action2 injected between the `Action1` and the `VarAction2`s. Would it be frightfully bad form to traverse the spritelayout-action2-lacking list of action1+varaction2s, and inject the action2layout after the action1 this way?
18:56:39 <Elyon> (it only needs the action2layout injection for non-stations)
18:57:05 <Elyon> (stations will probably need to retain a station_layout_list in "base_layout.py")
18:58:54 <Elyon> on the other hand, stations need to have varaction2(var0C) and varaction2(var10) injected anyway, so some form of injection will have to take place between the action1 and the varaction2s
19:00:47 <frosch123> for non-stations the spritelayout references the action1, but stations it could also reference a spritegroup
19:01:15 <frosch123> so, for stations the spritelayout does not create the action1, instead it inserts a spritegroup or something
19:01:34 <frosch123> unless you also handle the spritegroup in the spritelayout
19:01:43 <Elyon> so nonstation => action1 -> action2layout -> varaction2s
19:02:08 <Elyon> and station => spritegroup -> varaction2s?
19:02:32 <Elyon> well spritegroup -> varaction2(var10) -> varaction2(var0C) -> varaction2s
19:04:38 <Elyon> okay. Bearing that in mind, I can probably just skip the entire "action1 <- action2layout" for in the `base_layout.get_layout_actions()` and instead move these to `def action2layout.get_layout_actions: """action1 <- action2layout""" base_layout.get_layout_actions()`
19:04:59 <Elyon> so `base_layout.get_layout_actions` only really gets the varaction2s
19:05:41 <Elyon> in light of that, `get_layout_varaction2s` is probably a better name for the function
19:06:23 <Elyon> why are stations so weird and inconsistent with everything else? T_T
19:10:41 <frosch123> it's the little/lots thingie :)
19:10:47 <frosch123> industries/objects do not show cargo
19:11:14 <frosch123> stations combine the properties of industries/objects and stations, so they are the most complicated
19:11:38 <Elyon> s/and stations/and vehicles
19:12:09 <Elyon> well, it shouldn't be too bad. We just have to be /super careful/ when implementing station support
19:12:12 <frosch123> vehicles have loading stages, industries have layouts, stations have both :p
19:12:17 <Elyon> I am beginning to see why it has been postponed for years
19:12:41 <Alberth> original developers leaving is also not helping :)
19:13:09 <frosch123> yes, neither yexo nor hinundo have been seen for 2 years
19:13:24 <frosch123> albert, pm and me have started doing some stuff, but only in some areas
19:13:28 <Elyon> oh, okay ... hm. I was of the impression that NML was pm's brainchild
19:13:58 <frosch123> pm is the marketing guy :p
19:14:27 <Elyon> well, to be honest nml-stations is not /completely/ out-of-reach, I would say
19:14:30 <Alberth> and selling great cheap planets too :)
19:15:20 <Elyon> if feature == 0x04: make_stations_work()
19:15:52 <V453000> Elyon: 000101000101010010010101
19:16:01 <Elyon> name 'make_stations_work' is not defined
19:16:10 <V453000> just testing whether you are fully a robot yet or not
19:16:35 <Elyon> random shit is a cryptanalyst's worst nightmare
19:17:00 <Elyon> that field has TONNES of false positives
19:18:56 *** FLHerne has joined #openttd
19:19:53 <V453000> hmmm in landscape, when does the 2nd set of rocks appear?
19:19:58 <V453000> I cant seem to find it ingame :D
19:20:47 <V453000> like randomly chosen rocks 1 or 2?
19:21:16 <V453000> that is strange, I just tried to visually overwrite rocks 1 as grass, rocks 2 as rocks ... never seen rocks then
19:21:35 <frosch123> _landscape_clear_sprites_rough[GB(ti->x ^ ti->y, 4, 3) <- there are 5 different flat tiles for rocks
19:21:44 <frosch123> depending on the tile position
19:22:44 <V453000> I identified that as rough
19:22:48 <V453000> but yeah that is something different
19:22:52 <frosch123> make a long stretch of rocks, like 128 tiles, and you should find 5 types
19:22:56 <V453000> there are 2 sets of rocky land
19:23:28 <frosch123> oh, rocks, not rough
19:24:59 <frosch123> does not look like they are used at all :p
19:25:35 <V453000> exactly what I thought XD is wtf.
19:25:47 *** quorzom has joined #openttd
19:26:31 <frosch123> so, more tto only sprites
19:26:48 <frosch123> i thought there were only 6 unused sprites, now it's 25
19:27:19 <frosch123> let's see what they actually look like
19:27:46 <V453000> in ogfx they seem to be just duplicate of rocks1
19:31:44 <frosch123> they also pretty much look the same in original
19:32:03 <V453000> use them? :) RAWR could supply 2 various kinds of rocks
19:32:36 <V453000> am assuming that if ogfx has them, zbase does as well
19:33:43 <frosch123> i guess two types would always look silly/repetive
19:34:40 <frosch123> ah, they are not 100% the same
19:35:35 <frosch123> ROCK1 has some more transparent pixels/grass
19:37:08 <V453000> well one type is definitely more repetitive than 2 :P
19:40:50 <Eddi|zuHause> "we have put 5 errors in this picture"
19:41:13 <V453000> it needs a lot of making-nicer Alberth but yeah, wip :(
19:41:41 <Eddi|zuHause> i meant frosch123's picture. yours doesn't quite load
19:41:55 <Eddi|zuHause> either it's huge, or slow
19:42:01 <frosch123> V453000: how does the slope edge make it onto the stone?
19:42:46 <frosch123> is it only a texture? no modelled stone?
19:42:47 <V453000> the brigtness difference?
19:42:57 <Eddi|zuHause> V453000: with "slow" i mean "uses about 5% of my available bandwidth"
19:43:19 <V453000> it is modelled stone, but i hack brightness in postproduction to make it more clear for gameplay ... I will make the borders less visible
19:43:32 <frosch123> V453000: the SLOPE_E tiles definitely look weird
19:43:40 <frosch123> with the brightness cut over the stone :p
19:43:52 <V453000> I will see what can be done about it
19:44:16 <V453000> if nothing else then I can always move stones away from the edge
19:44:44 <Eddi|zuHause> at least where i come from, slopes are described from the lowest side
19:44:46 <Zuu> What is wierd about SLOPE_E? small stones not rolling down?
19:44:59 <V453000> the render simply does not output clear enough images for gameplay ... but I will see what can be done
19:44:59 <frosch123> V453000: you need to learn the snow tricks from ogfx
19:45:30 <V453000> yeah the snow looks quite bad so far
19:45:30 <frosch123> partially snowy slopes should have more snow on the higher parts
19:45:45 <frosch123> that's something which ogfx does way better than original graphics :p
19:45:53 <Eddi|zuHause> Zuu: there is a vertical line through the stone
19:46:01 *** luaduck is now known as luaduck_zzz
19:46:08 <V453000> am actually setting up a new texture infrastructure right now, so will do that :P good idea, thanks
19:46:14 <frosch123> though, i think someone made a grf for original graphics before ogfx existed
19:46:31 <V453000> I think so too but doesnt matter
19:47:17 <Eddi|zuHause> yeah, there was a "smooth snow transition grf" which i guess was simply absorbed into opengfx
19:47:24 <Zuu> Oh.. yeah zooming in, now I see the vertical line.
19:49:16 <Eddi|zuHause> OpenGFX was a lot of "there is already this stuff, we just combine it to a complete base set"
19:50:08 <frosch123> i think the smooth snow transition grf matched original snow on flat tiles though
19:50:13 <frosch123> ogfx has a different hue
19:51:00 <Eddi|zuHause> i've never used opengfx
19:51:43 <Alberth> and it's much less than 5% bandwith, even!
19:54:53 *** ChanServ sets mode: +v glx_
19:54:53 *** glx is now known as Guest1432
19:55:47 <frosch123> V453000: since you do not have grid lines, i would recommend to shift the texture a bit, so that the slightly emphasised parts are on the grid
19:56:19 <V453000> there will be a lot of texture edits still ... and grid is not out of the question either :)
19:56:23 <V453000> at least some hinted texture
19:56:33 <frosch123> i mean, your flat tiles have a somewhat rectangular repetitiveness, that looks like a grid, but it is not on the tile grid
19:56:36 <V453000> I basically just got some first version working, need moar
19:57:30 <frosch123> well, you won't achieve non-repetetiveness :) that only works with actual 3d lightning, not with sprites
19:57:48 <frosch123> so, i think the better strategy is to make a intentionally-looking repetetiveness
20:01:23 <frosch123> i don't fancy coming up with a more advanced "randomness"
20:01:32 <frosch123> the existing basesets look almost the same anyway
20:01:40 <Eddi|zuHause> frosch123: use pseudorandom like for rails?
20:02:04 <frosch123> that diff already is pseudorandom?
20:02:25 <frosch123> GB(ti->x ^ ti->y, 4, 3) <- rough tiles use the same iteration
20:02:40 <frosch123> but there are 5 types at least
20:04:14 *** gelignite has joined #openttd
20:04:54 <Eddi|zuHause> frosch123: that doesn't look very random to me.
20:05:14 <Eddi|zuHause> actually, that's decidedly periodic
20:05:41 <frosch123> the house-randomness is also mostly periodic
20:05:51 <frosch123> railtype randomness is slightly more complicated
20:06:02 <frosch123> but with 1 random bit, there is not much randomness anyway
20:06:29 <Eddi|zuHause> there are perfectly random binary numbers...
20:07:01 <Eddi|zuHause> each digit has only 1 bit
20:07:48 <frosch123> i like unary numbers
20:07:58 <Eddi|zuHause> __ln___: i think you'd find it very hard to prove even the most basic randomness conditions in that number :p
20:08:35 <frosch123> fine, i'll use the house randomness
20:08:39 <frosch123> good enough for 1 bit
20:09:10 <frosch123> it's not even rfc conform
20:09:57 <andythenorth> iirc, the newgrf spec provides for flat docks?
20:10:26 <Eddi|zuHause> andythenorth: allegedly, TTDPatch has some sort of flat docks
20:10:40 <andythenorth> can anyone start it and confirm?
20:10:47 <andythenorth> I have never seen a TTDPatch
20:10:57 <DorpsGek> Commit by frosch :: r27117 trunk/src/clear_cmd.cpp (2015-01-10 20:10:51 UTC)
20:10:58 <DorpsGek> -Fix/Feature: Make use of both rocky tile sets from the base graphics.
20:15:44 <frosch123> hmm, so ottd is not that slow to start up
20:15:46 <frosch123> ttdp is just as slow
20:16:17 <frosch123> nah, not the grf scan, i mean actually loading the shared libs and such
20:16:43 <frosch123> if i start ottd the first time after reboot, it takes ages to load shared libs
20:17:14 <frosch123> hmm, does not look like this revision works
20:17:28 <Alberth> or add openttd to the kernel :p
20:23:39 <frosch123> selecting the tile between the two canals areas selects the northern one
20:24:34 <frosch123> actually it says "site unsuitable" when trying to build
20:24:40 <frosch123> though i can add canal afterwards
20:25:49 <andythenorth> ho flat docks :)
20:26:07 <andythenorth> high level of graphical fidelity there :P
20:26:15 <andythenorth> the land dock has water around it
20:26:44 <frosch123> maybe i am missing a grf or something
20:26:51 <frosch123> andythenorth: anyway, get dosbox and enjoy :p
20:27:27 <frosch123> dosbox has a built-in 2x mode
20:31:25 *** Myhorta has joined #openttd
20:32:46 <Elyon> frosch123: the generated `Action6` in `get_layout_action2s` of "./actions/action2layout" is meant for non-stations only I think ... do you know?
20:36:35 <frosch123> Elyon: it's used to write the value, if you use a parameter in the spritenumber
20:38:09 <frosch123> there are 3 types of values in grfs: compile-time constants, load-time constants and dynamic values
20:38:31 <frosch123> load-time constants are constant after loading the grf in ottd
20:38:40 <frosch123> stuff like spritenumbers from other grfs and such
20:39:27 <frosch123> compile-time constants are directly processed by nml, load-time constants are applied using action6, dynamic values reference registers
20:40:27 <frosch123> or in short: any value from the nml source, which is an expression, needs to be passed through actionD.write_action_value
20:42:00 <frosch123> anyway, you also need it for stations, but likely in the action0 :p
20:49:12 *** itsatacoshop247 has joined #openttd
21:00:57 <Elyon> so I need to use an action6 to modify the action0?
21:01:36 <frosch123> the exiting action0 should already do similar things
21:02:25 <Elyon> hmm ... I will have to look into that. For now, though, the `action6` is entirely different between stations and non-stations, yes?
21:05:01 <Elyon> the offset will be different, but the modifications should be the same, I guess
21:06:11 <Elyon> also, the action6 will go before the action2 for non-stations, but before the action0 for stations. Hmm ...
21:06:38 <frosch123> it belongs to the layout
21:07:13 <frosch123> maybe don't consider action6 a separate action, it is more like an addendum to any output data
21:07:36 <Elyon> issue, though. action0 prop 1A is not a layout, but a collection of layouts
21:08:06 <frosch123> action0 is a collection of many things
21:08:15 <frosch123> but why does that matter?
21:08:34 <Elyon> because the current action6-for-action2layout assumes one layout
21:09:21 <frosch123> well, you cannot reuse the layout output on an action level
21:10:20 <Elyon> no... What I mean is, the current layout generates a single-layout-action2 possibly modified by an action6
21:10:51 <Elyon> for stations, an arbitrary-layout-action0-prop1a is generated and will possibly be modified by a single action6 as well
21:11:13 <Elyon> but /that/ action6 has to apply modifications to all prop1a-layouts that need modifications
21:11:27 <frosch123> it even has to apply modifications to all other properties of the action0
21:11:44 <frosch123> so, whatever writes the code, the action6 need to be passed as parameter to that method
21:12:09 <Elyon> the action0-modifying action6 already exists, right?
21:13:30 <Elyon> so wherever that is generated needs to have modifications added, /or/ as you say, that action6 can be passed to .. hmmm
21:13:49 <Elyon> alternatively, we make a separate action0 that just defines prop1a
21:14:09 <frosch123> parse_property_block creates an action6
21:15:07 <frosch123> parse_property returns a tuple with both the stuff to write and the stuff to append to the action6
21:15:59 <frosch123> so, following that example, the layout writing function should return the bytes for the layout, and a list of action6 stuff
21:16:19 <frosch123> the action0 then writes the bytes, adds a positional offfset to the action6 stuff, and appends it to the rest of the action6
21:16:27 <Elyon> then; should I aim to add prop1A to the already-generating action0 (and extend the preceding action6 with required modifications to the layouts), /or/ generate a new action0prop1A for simplicity?
21:16:46 <Elyon> the former would be neater
21:17:17 *** oskari89 has joined #openttd
21:19:26 <frosch123> the latter seems to be done in multiple places already
21:19:49 <frosch123> the more complicated action0 (which i guess 1A qualifies for) are written separately
21:20:10 <Elyon> which approach would be preferred in this case, then?
21:20:23 <Elyon> given equal opportunity
21:20:35 <frosch123> i guess a separate action0 is better
21:21:06 <frosch123> the layouts do not have a particular relation to the other properties, so it does not look useful to mix them
21:21:10 <Elyon> this action0 has to come after the station-class setting action0 though
21:22:31 <Elyon> but as said, for non-stations the action6 only modifies one spritelayout, whereas for stations it needs to modify all the spritelayouts
21:22:55 <frosch123> but for stations you also need to write multiple layouts
21:23:04 <frosch123> so, why do you focus so much on the action6?
21:23:24 <Elyon> because all the layout action6-modifications need to be coerced into a single action6
21:23:41 <frosch123> so do the layouts into a single action0
21:23:57 <Elyon> that is required anyway
21:24:30 <frosch123> well, the action6 and the action0 belong together, they are one thing, not two separate
21:25:21 <Elyon> I am just complaining about the added complexity of modifying /all/ spritelayouts in one action6, as opposed to the modification of the /one/ spritelayout for non-stations
21:26:20 <frosch123> ah, well you are allowed to complain :)
21:26:21 <Elyon> I guess the approach is the same except instead of a single layout I just do `for layout in layout_list:` and then add each modification
21:27:33 <Elyon> my point being, the action6 generation should probably not be abstracted out as it is modifications to a list of layouts for action0, and a single layout for action2
21:27:52 <Elyon> alternatively, I can just check `if feature == 0x04` in the abstract base class
21:29:46 <Elyon> tl;dr `if feature == 0x04: """iterate layouts and add modifications to action6""" else: """add modifications to action6"""
21:30:18 <frosch123> did you look at action0?
21:30:40 <Elyon> oh action0.py -- yes, but not recently
21:32:07 *** Nothing4You has joined #openttd
21:32:14 <frosch123> there the functions return a tuple: list of stuff to add to action0, list of actions to put in front (before a6 and a0), list of stuff to add to action6, list of actions to put at end (after a0)
21:32:20 <frosch123> e.g parse_property()
21:32:53 <frosch123> the caller concatenates the stuff to append to action0, adds a offset to the returned a6 stuff and then adds that
21:33:46 *** Buntunub has joined #openttd
21:34:21 *** smoke_fumus has joined #openttd
21:34:27 <Elyon> you mean parse_property_block?
21:36:34 <Elyon> you're hinting that the action6 generation is already implemented for action0 anyway, so I should just set prop1A for the item?
21:38:34 <Elyon> as the parsing should generate act6 modifications according to what the property values require?
21:39:22 <frosch123> i am not sure whether parse_property_block is the right thing to hook into
21:39:30 <frosch123> that parses the "property" block after all :p
21:39:46 <frosch123> you said, you wanted to trigger it via the stationclass property though
21:39:54 <frosch123> so, that could be an option
21:40:07 <Elyon> ideally I would want to put prop1A with the other properties
21:40:31 <frosch123> well, you registered the stationclass property somewhere in action0properties.py
21:40:36 <Elyon> so if I just generate and append prop1A before it is parsed, it should work automagically
21:41:03 <frosch123> if you register a 'custom_function' you can also add the layouts
21:41:24 <Elyon> it just needs to not be an NML-settable property
21:41:42 <frosch123> no, i mean writing it together
21:42:10 <Elyon> yes, that's what I want as well
21:42:11 <frosch123> register a custom method for the stationclass
21:42:21 <frosch123> but do not only write the stationclass but also the layouts with the same method
21:42:35 <Elyon> because it's guaranteed to be there?
21:44:09 <frosch123> you wanted to write it together with stationclass, didn't you?
21:44:09 <Elyon> I don't know, this is getting confusing
21:44:25 <Elyon> uhm ... yeah. Yes. And all the other properties ideally
21:44:35 <Elyon> which already happens for all properties so-far-defined
21:44:58 <Elyon> it is an error not to specify stationclass anyway, so that makes sense I think
21:45:01 <frosch123> so, i suggested that you register a 'custom_function' for writing stationclass
21:45:13 <frosch123> but make that custom function not only write the stationclass, but also the layouts
21:45:27 <frosch123> the registered functions can write more than one property
21:45:47 <Elyon> seems hackish, I'd rather have a StationSpritelayoutsProp and use that to write the property?
21:45:56 <frosch123> yes :p i would write the layouts with the "graphics" block
21:46:01 <frosch123> not with the "stationclass"
21:46:18 <Elyon> but the graphics block is not an action0
21:46:45 <frosch123> why is that important?
21:47:28 <frosch123> also, why does using 'custom_function' prevent you from using StationSpritelayoutsProp?
21:47:30 <Elyon> the graphics block actions are written before action0prop08, but action0prop08 /must/ be set in the first action0 for that station
21:48:01 <frosch123> are you sure about that?
21:48:10 <frosch123> i am pretty sure action3 is written after the action0
21:48:28 <Elyon> "The only property you must set for each station ID is 08 (in addition to defining an action 3 for it), anything else can be left at the default. It must be the first property you set for each station ID, because the station ID is actually undefined until it has been assigned a class through property 08."
21:48:56 <Elyon> action3 is written after the action0, yes
21:49:00 <frosch123> actually, the ideal place to add the stationlayout action0 is action3.py:357
21:49:08 <frosch123> right after inserting the action0 for the callback flags
21:49:17 <frosch123> so, i would recommend that place :p
21:49:39 <Elyon> I haven't looked at action3.py yet
21:50:19 <frosch123> you need to modify that place anyway, to enable callback 14
21:51:41 <Elyon> ah, right. Also, adding an action0 for prop1A /just after/ the "primary" action0, we might as well just add prop1A to the primary action0
21:53:53 <Elyon> wouldn't it be easier to just generate a "property 1A" for the station before it is written?
21:54:06 <Elyon> that way, the existing property handling code does all the work
21:55:01 <frosch123> no idea, i consider using the existing property handling code not particulary useful for writing 1A
21:55:33 <frosch123> action3.py looks way better to me, and the same is done for other automatically generated properties, like callback flags
21:55:58 <frosch123> so, i would not add 1A after the other action0, but in front of a3
21:56:15 <Elyon> you're still on separate action0 for the layouts, yes?
21:56:25 <frosch123> but, well, i only know details of nml as i find them :p
21:56:32 <Elyon> because I was talking about adding 1A /in/ the other action0
21:56:44 <Elyon> since now is the time to decide to do that
21:56:58 <Elyon> it's one less action in the GRF :p
21:56:59 <frosch123> yes, but looking at action3.py and seeing how callback are done, a separate a0 looks better :)
21:57:28 <Elyon> frosch123, roger; in that case (where other stuff is handled with separate action0s) I will do so as well
21:57:57 <Elyon> and then in two years time submit a patchset that coerces every single action0prop into single action0s
22:02:21 <Elyon> long story short: I will not abstract the current action6-for-action2layout out then, as it is completely separate from action0/action3
22:15:57 * Elyon is tempted to make a `BaseLayoutActionGroup` to wrap around action1/action6 for non-stations
22:16:23 <Elyon> that would save me passing the results of one function as a parameter to the next
22:18:50 <frosch123> it's not only action6, there are also actionD :p
22:19:01 <frosch123> and possibly action7 and more
22:19:08 <Elyon> the temptation is still strong
22:19:41 <Elyon> for non-stations it would wrap `action(1|6|7|D)s`, and for stations it wouldn't wrap anything as those are handled elsewhere
22:21:03 <Elyon> but the wrapper would save us from duplicating the header/footer around the action1/6/7/Ds for non-stations, and stations
22:21:44 <Elyon> for now it is a chain of methods that each take the parameters of the last
22:21:50 <Elyon> s/parameters/return values
22:21:51 <Eddi|zuHause> you forgot action9
22:22:09 <Eddi|zuHause> and i never ever remember what that actually is for...
22:22:32 <Eddi|zuHause> you probably don't want actionF :p
22:22:49 <frosch123> the 6/7/D is common in many places, so i may make sense to put the tuple from above (pre-actions, a6, actually content, post-actions) into a class
22:23:09 <Elyon> that it outside the scope of this particular patch
22:23:25 <Elyon> which /just/ deals with abstracting whatever makes sense from Action2Layout
22:23:47 <Eddi|zuHause> but, you can't action6 an action2 anyway
22:24:06 <frosch123> Eddi|zuHause: stop talking bollocks
22:24:19 <Elyon> I'll action6 your action2
22:24:30 <Elyon> wait ... that's actually ...
22:24:31 <Eddi|zuHause> the specs were wery vocal about that
22:25:18 <frosch123> you possibly cannot action6 the action2ids
22:25:49 <frosch123> but you likely need a debuger the figure that out
22:25:59 <frosch123> a ttdp debugger that is
22:26:43 *** andythenorth has left #openttd
22:28:31 <Eddi|zuHause> frosch123: well, my understanding is that because action2s are evaluated during execution, and action6s during activation, they can not have an effect
22:29:35 <frosch123> read about the concept of compile-time and load-time constants
22:30:02 <Elyon> I will possibly make a class for the pre/post actions of the action2layout for now. Hopefully that can be further abstracted in the future
22:30:35 <Elyon> 'Action2LayoutActionGroup' or 'BaseLayoutActionGroup' or what should I call it? o_O
22:31:46 <Elyon> actually I will just leave it as functions instead of methods and attributes
22:32:21 * Elyon has a hard time focusing on single issues when there are plenty others to solve
22:33:33 <Eddi|zuHause> frosch123: i'm not sure how this applies
22:33:52 <frosch123> action6 is about load-time constants
22:35:02 <frosch123> that's even a equivalency
22:35:40 <frosch123> some people think they can also do load-time constants using var 7F, but that limits the total number of constants quite hard
22:35:48 <Eddi|zuHause> yes. but i always assumed that the data is read and applied during loading/activation, and then discarded
22:36:20 <frosch123> it's not discarded, it's processed
22:36:44 <Eddi|zuHause> but that would mean you need to keep the whole grf in memory
22:36:53 <frosch123> action6 is like putting ketchup on your fries
22:37:04 <frosch123> you cannot do that after you ate them
22:37:27 <frosch123> Eddi|zuHause: yes, all pseudo sprites are kept in memmory
22:37:30 *** supermop has joined #openttd
22:37:32 <dreck> frosch tell that to the silly boy in Zits comic...
22:37:37 <frosch123> ottd copies them (parsed) into real structures
22:37:46 <frosch123> ttdp overwrites some integer values in the grf with pointers
22:38:07 <dreck> he throws food into mouth... then pour sauce bottle content into mouth ... and shake his head .. then gulps the whole thing and go AHH :) .... silly comic I tell you
22:38:55 <Eddi|zuHause> frosch123: then, why is it dangerous to skip action2 with action7/9?
22:39:20 <frosch123> because ttdp replaces the action2ids with pointers in the init-stage
22:39:31 <frosch123> if you skip them with action9, that does not happen
22:39:36 <frosch123> so if they are used later, ttdp crashes
22:40:11 <frosch123> skipping them with action7 later has no effect, since the pointers to them are already resolved
22:40:27 <Eddi|zuHause> so, that action6 works is rather pure coincidence than actual spec?
22:40:55 <frosch123> i have no idea what spec you are refering to
22:41:08 <frosch123> i know about a7/9, but restrictions to a6 are undocumented
22:41:30 <frosch123> still ttdp crashes if you overwrite a pointer with a6 with a different value
22:41:43 <frosch123> it likely works if you skip the a6 using a9 after init-stage though :p
22:41:44 <Eddi|zuHause> maybe i just always assumed that action6 had the same restrictions as 7/9
22:42:06 <frosch123> a6 has only the ketchup restriction
22:42:16 <frosch123> you can overwrite anything, except after it is already processed
22:43:02 <frosch123> a9 can skip anything, but you must not skip certain processings
22:43:20 <frosch123> a7 can skip anything, but it may not matter anyway, since it is already processed
22:43:26 <frosch123> so a7 also has the ketchup rule
22:43:43 <Elyon> reminds me of "asparagus staging" in kerbal
22:43:46 <frosch123> it does not matter whether you skip the ketchup, after you already ate the fries
22:44:54 <Eddi|zuHause> yeah, my friend always takes neither ketchup nor mayo, and i always remember afterwards that i should have told him to take mayo, so i can combine it with my ketchup
22:46:14 <dreck> ketchup + mustard + small fork/knife = orange spread over your hotdog :)
22:46:21 <dreck> someone used to do that once in a while
22:50:36 <frosch123> Eddi|zuHause: what's that? the fire did not cause any server outage because the server center was still under construction and there were no servers anyway?
22:50:42 <frosch123> what's the point of that news?
22:51:03 <frosch123> Eddi|zuHause: anyway, about cloud services you should search for the "chaos monkey"
23:31:13 *** MTsPony has joined #openttd
23:46:55 *** Myhorta has joined #openttd
continue to next day ⏵
