Back to Home / #openttd / 2015 / 01 / Prev Day | Next Day
#openttd IRC Logs for 2015-01-10

---Logopened Sat Jan 10 00:00:20 2015
00:29-!-quorzom_ [~quorzom@cable-78-35-98-177.netcologne.de] has quit [Remote host closed the connection]
00:35-!-Pereba [~UserNick@179.179.23.201] has joined #openttd
00:38-!-luaduck_zzz is now known as luaduck
00:56-!-Eddi|zuHause [~johekr@p57BD5F96.dip0.t-ipconnect.de] has quit []
00:56-!-Eddi|zuHause [~johekr@p57BD5AAC.dip0.t-ipconnect.de] has joined #openttd
01:36-!-supermop [~supermop@d110-33-179-139.sun801.vic.optusnet.com.au] has joined #openttd
02:06-!-DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer]
02:36-!-Pensacola [~quassel@c80094.upc-c.chello.nl] has joined #openttd
02:47-!-supermop [~supermop@d110-33-179-139.sun801.vic.optusnet.com.au] has quit [Ping timeout: 480 seconds]
03:04<V453000>XD
03:08-!-Flygon [~Flygon@147.18.214.218.sta.commander.net.au] has quit [Read error: Connection reset by peer]
03:18-!-Flygon [~Flygon@147.18.214.218.sta.commander.net.au] has joined #openttd
03:36-!-Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd
03:36-!-mode/#openttd [+o Alberth] by ChanServ
03:45-!-supermop [~supermop@d110-33-179-139.sun801.vic.optusnet.com.au] has joined #openttd
03:49-!-Wolf01 [~wolf01@0001288e.user.oftc.net] has joined #openttd
03:50<Wolf01>hi o/
03:57-!-sla_ro|master [slamaster@95.76.27.245] has joined #openttd
03:58-!-HerzogDeXtEr [~flex@88.130.180.71] has joined #openttd
03:59-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd
04:00<andythenorth>o/
04:00<andythenorth>Alberth: I started a BB game
04:00<@Alberth>moin
04:00<andythenorth>only 2 years in
04:00<Wolf01>o/
04:00<Wolf01>bed & breakfast? :D
04:01<@Alberth>OpenTTD can do that? :)
04:02<Wolf01>if you play on the laptop while in bed and eating your breakfast, why not?
04:03<@Alberth>hmm, never done either of those :)
04:07<andythenorth>Alberth: do you want to release it? 0_O
04:07<@Alberth>sure, needs some small stuff added, doesn't it?
04:09<andythenorth>gpl license.txt, readme?
04:09<@Alberth>makefile
04:09<andythenorth>I’m out for a couple of hours, could do it when I get back
04:09<@Alberth>ok, haven't decided what I'll do to day yet :)
04:10<andythenorth>my decision are made for me :)
04:10<andythenorth>ha
04:10<andythenorth>anyway bbl
04:10-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth]
04:16-!-supermop [~supermop@d110-33-179-139.sun801.vic.optusnet.com.au] has quit [Ping timeout: 480 seconds]
04:21-!-liq3 [liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] has quit []
04:29-!-Yotson [~Yotson@2001:980:6ac8:1:2c9d:199a:48c9:8080] has quit [Ping timeout: 480 seconds]
04:46-!-Yotson [~Yotson@2001:980:6ac8:1:4ccd:9876:25ca:1380] has joined #openttd
04:52-!-Pereba [~UserNick@179.179.23.201] has quit [Quit: AdiIRC 1.9.6 Disequilibrium http://www.adiirc.com/]
04:57-!-Suicyder [~Suicyder@86.92.59.88] has joined #openttd
05:31-!-MTsPony [~MTsPony@008-086-128-083.dynamic.caiway.nl] has quit []
05:41<@Alberth>but but.... your game?
05:47-!-Lucky89666 [~oftc-webi@89.147.78.201] has joined #openttd
05:47<Lucky89666>helló segít valaki?
05:47<Lucky89666>hy
05:47<Lucky89666>hi
05:48<Lucky89666>my name is adam help me?
05:48<Lucky89666>nincs magyar
05:48<Lucky89666>?
05:49-!-Lucky89666 [~oftc-webi@89.147.78.201] has quit []
06:02<@Alberth>not so lucky?
06:09-!-Progman [~progman@p57A1BBA1.dip0.t-ipconnect.de] has joined #openttd
06:11-!-Suicyder [~Suicyder@86.92.59.88] has quit [Read error: Connection reset by peer]
06:11-!-Extrems1 [borgs@modemcable204.141-177-173.mc.videotron.ca] has quit [Read error: Connection reset by peer]
06:11-!-Wolf01 [~wolf01@0001288e.user.oftc.net] has quit [Read error: Connection reset by peer]
06:11-!-Suicyder [~Suicyder@86.92.59.88] has joined #openttd
06:12-!-Wolf01 [~wolf01@host44-14-dynamic.31-79-r.retail.telecomitalia.it] has joined #openttd
06:12-!-Extrems [borgs@modemcable204.141-177-173.mc.videotron.ca] has joined #openttd
06:31-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
06:38-!-gelignite [~gelignite@i528C3A79.versanet.de] has joined #openttd
06:51-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has quit [Ping timeout: 480 seconds]
07:05-!-frosch123 [~frosch@frnk-4d01b043.pool.mediaWays.net] has joined #openttd
07:06<@Alberth>moin
07:06<frosch123>Elyon: spritesets can have different sizes
07:07<frosch123>but possibly nml does not allow that yet, since it is a newer generalisation
07:07<frosch123>hai Alberth :)
07:07<@planetmaker>moyen :)
07:08<@Alberth>time for coffee!
07:09<@Alberth>or rather, liquid of otherwise unspecified nature, to allow automagic transformation to desired drinks
07:10<@planetmaker>:D
07:14-!-Quatroking [~Quatrokin@ip226-139-211-87.adsl2.static.versatel.nl] has joined #openttd
07:22<frosch123>Elyon: https://dev.openttdcoop.org/issues/3739 <- for further context
07:22<frosch123>there is even a diff, not sure what it actually implements though
07:24-!-Progman [~progman@p57A1BBA1.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
07:26-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd
07:29<@Alberth>o/
07:31<andythenorth>I think it works well, so far :)
07:31<andythenorth>might redeem FIRS Full
07:32<andythenorth>makes it less overwhelming + stupid
07:32<@Alberth>+1
07:32-!-Supercheese is now known as Guest1385
07:32-!-Supercheese [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has joined #openttd
07:33<V453000>what did you come up with? :D
07:33<andythenorth>I tried on a FIRS Basic economy first, but that was a bit boring, not enough cargo variety
07:33<andythenorth>V453000 Busy Bee, it just assigns n simple cargo goals
07:33<andythenorth>default is 5, with 10 years to complete
07:33<V453000>that doesnt change anything ._:
07:34<andythenorth>it reduces choice
07:34<@Alberth>V453000: http://dev.openttdcoop.org/projects/busy-bee-gs
07:34<V453000>the real choice is metal/oil already ._.
07:35<V453000>and assuming you want to win some gs, you need to grow industries, so you need metal/oil again
07:35<andythenorth>nah
07:35<andythenorth>there’s no win condition
07:35<V453000>xd
07:35<V453000>what is it about then
07:36<@Alberth>make connection, make stuff
07:36<@Alberth>*transport
07:36<andythenorth>build routes
07:36<andythenorth>watch trains
07:36<@Alberth>next goal: make connection, move stuff
07:36<@Alberth>next goal: make connection, move stuff
07:37<@Alberth>until bored :)
07:37<V453000>ahhh
07:37<andythenorth>when bored, make new GS
07:37<V453000>that isnt so bad then :)
07:37<andythenorth>it’s a stepping stone, not the Best GS Ever
07:37<@Alberth>well, 6,400 mail in 10 years? :p
07:38<andythenorth>the ratio of “talk about GS” to “actual GS you can play” is unsuitable currently
07:38<@Alberth>but if you fail, no problem, you just get a new goal
07:38<V453000>that is quite nice
07:38<andythenorth>make GS, play GS, make better GS
07:38<@Alberth>until bored :p
07:39-!-Guest1385 [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has quit [Ping timeout: 480 seconds]
07:39<andythenorth>I started in 1870
07:39<V453000>when bored, create YETI :P
07:39<andythenorth>going to see if I can make it to 2010
07:40<@Alberth>that's a long time :)
07:40<andythenorth>yeah
07:41<andythenorth>full date range of Iron Horse, Squid, Road Hog
07:41<andythenorth>it’s actually in later game that I hope it makes a difference
07:42<@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
07:42<@Alberth>(completely :p )
07:43<@planetmaker>:D
07:44-!-stefkos [~stefkos@pc11-226.chomiczowka.waw.pl] has joined #openttd
07:44<stefkos>lo
07:44<@Alberth>o/
07:44<stefkos>anyone can help with OpenTTD code for MorphOS?
07:45<stefkos>It crash somewhere in thread_morphos.cpp
07:47<@Alberth>build with debugging symbols, play until crash, analyze the post-mortem?
07:47<stefkos>doing that now
07:49<stefkos>thx anyway
07:49<@Alberth>don't think there are many MorphOS users here besides yourself
07:49<stefkos>yeah I know
07:50<@Alberth>you could try a MorphOS specific channel perhaps?
07:50<stefkos>will do
07:50<@Alberth>they may know more how threads work at that OS
07:53<@Alberth>if it crashes at a device, you could also try the channel about the library that is used
07:54<stefkos>well as I see only native functions are called
07:54<@Alberth>maybe they have some known morphOS issues
07:54<stefkos>to create/work with threads
07:56<@Alberth>yeah, c/c++ tends to have extremely thin wrappers to system calls :)
07:58<stefkos>I will find and kill that bug:)
07:58<stefkos>just need some time
07:59<stefkos>atm I think that 1 msg structure is unallocated/wrong or 2 pointer to function is wrong
08:02<stefkos>cya
08:02<stefkos>thx
08:02-!-stefkos [~stefkos@pc11-226.chomiczowka.waw.pl] has quit [Quit: Leaving]
08:06-!-shirish [~quassel@117.222.7.30] has joined #openttd
08:07<frosch123>oh, he left
08:08<frosch123>there were very recently changes to morphos threading in trunk/1.5
08:08<frosch123>so, we have 3 morph os users :p
08:14<andythenorth>bbl
08:14-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth]
08:24<skrzyp>frosch123: I know those mos developers (as I had one mos machine with license)
08:24<skrzyp>they are very wird persons
08:24<skrzyp>with very big hate to everything "unixy"
08:25<skrzyp>(they are even called openttd devteam as "linux guys")
08:26<skrzyp>working with them are extremely hard, because they didn't care about updating, compatibility and portability
08:26<skrzyp>(except this portability means their own PPC machines)
08:28<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
08:29<@Alberth>thanks for forwarding
08:29-!-smoke_fumus [~smoke_fum@188.35.176.90] has quit [Read error: Connection reset by peer]
08:29<skrzyp>it probably doesn't changed everything
08:30<skrzyp>http://stefkos.amigazeux.net/openttd1.png http://stefkos.amigazeux.net/openttd.png - he said "it works", but look at version number :D :D
08:32<@peter1138>Ancient...
08:32<skrzyp>I know.
08:32-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds]
08:33<Rubidium>... and locally modified
08:33<skrzyp>But he probably event can't imagine this
08:33<skrzyp>even*
08:34<skrzyp>It's funny that MorphOS userland situation looks exactly the same in all 3rd party projects
08:34<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.
08:35<skrzyp>It's a reason why I sold my MacMini G4 with morphos keyfile
08:36<skrzyp>Devs are totally uncommunicative, I've tried to port Atari800 emulator and they're told me it's a "linux crap"
08:37<skrzyp>Probably because I've used HOME veriable to put settings into applications' bundle folder - MorphOS doesn't have home directory and multiuser capabilities.
08:38<frosch123>hmm, oh, lol, i actually confused morphos with os/2
08:38<frosch123>the recent changes were to os/2 :p
08:38<Rubidium>frosch123: so, two os/2 users and one morphos user?
08:38<frosch123>yeah :)
08:39<skrzyp>OS/2 is called eComStation today (and quite actively developed)
08:39-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
08:45-!-Zeetherdroid [~AndChat68@user-0c6t3g5.cable.mindspring.com] has joined #openttd
09:01-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds]
09:27-!-sla_ro|master [slamaster@95.76.27.245] has quit []
09:34-!-gelignite [~gelignite@i528C3A79.versanet.de] has quit [Quit: http://bit.ly/nkczDT]
09:40-!-shirish [~quassel@0001358e.user.oftc.net] has quit [Read error: Connection reset by peer]
10:01-!-Haube [~Michi@ip25048c11.dynamic.kabel-deutschland.de] has joined #openttd
10:05-!-gelignite [~gelignite@i528C3A79.versanet.de] has joined #openttd
10:07-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd
10:13-!-Phoenix_the_II [~ralph@13-17-191-195.ftth.glasoperator.nl] has joined #openttd
10:24-!-Zeetherdroid [~AndChat68@user-0c6t3g5.cable.mindspring.com] has quit [Ping timeout: 480 seconds]
10:32-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
10:37-!-gelignite [~gelignite@i528C3A79.versanet.de] has quit [Quit: http://bit.ly/nkczDT]
11:08*andythenorth considers a dumbed-down parameter for FIRS
11:18<andythenorth>hmm
11:18<andythenorth>stupid docks on rivers
11:19<andythenorth>really, fix that, and we’re done
11:19<andythenorth>the game is finished
11:30<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?
11:31<Elyon>frosch123: also, I added a wall of text on issue 2746
11:37<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?
11:38<andythenorth>I think they should be made more difficult to build
11:38<andythenorth>this construction is too simple and elegant https://dev.openttdcoop.org/attachments/download/3179/river_dock.png
11:39<andythenorth>and also realisms
11:39<andythenorth>I think they should require at least 15 tiles or so
11:39<andythenorth>9 is not enough
11:39<V453000>xd
11:39<V453000>is proportional to 2x3 industry :P
11:39<V453000>SENSE IT MAKES
11:40<andythenorth>this is much better https://dev.openttdcoop.org/attachments/download/5621/dock.png
11:40<andythenorth>we need to enforce that
11:40<b_jonas>andythenorth: add a depot to it
11:41<b_jonas>oh, you already have in that second image
11:41<b_jonas>great
11:41<andythenorth>the idea of 2x1 docks that can be built on flat tiles simply appalls me
11:41<andythenorth>that’s just not TTD
11:42<V453000>looks nice
11:42<andythenorth>oh wait
11:42*andythenorth is doing that thing again
11:42<andythenorth>lying?
11:42<V453000>XD
11:44<NGC3982>That looks wonderful.
11:45-!-Pereba [~UserNick@179.179.23.201] has joined #openttd
11:46<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
11:48-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth]
11:49<NGC3982>and.. Why does he not use a bouncer or shell or something.
11:49<NGC3982>Quits are not for IRCs.
11:49<NGC3982>:|
11:49<V453000>he will be back before you know it :P
11:50<NGC3982>Hehe, as usual.
11:50<NGC3982>Can flat-tile docks be possible with NewGRF?
11:50<Elyon>frosch123, ie. the station spritelayout could benefit from varying sizes of spritesets but I am not sure how to provide these
11:50-!-Pereba [~UserNick@179.179.23.201] has quit [Quit: AdiIRC, write down this name. [www.adiirc.com]]
11:50<V453000>NGC3982: newGRF probably cant do that
11:52<frosch123>Elyon: since ottd 1.3 or something you can split defintion of spritsets over multiple action1
11:53<frosch123>the patch in #3739 adds the action1 writer for that
11:54<frosch123>def __init__(self, feature, first_set, num_sets, num_ent): <- define sets [first_set, first_set + num_sets) containing num_ent sprites each
11:54<frosch123>by using multiple action1 you can define a series of spritesets with different amount of sprites
11:54<Elyon>but the patch does not use multiple action1s I believe
11:55<frosch123>no, it's only a partial implementation
11:55<Elyon>ah, right
11:55<frosch123>+ actions = [Action1(self.feature, 0, len(self.spritesets), self.num_sprites_per_spriteset)] <- it always passes 0
11:55<Elyon>indeed
11:55<Elyon>well, I can take a look at it but it isn't strictly necessary and not really related to stations
11:55<Elyon>it's just a nice feature to support
11:56-!-Nothing4You [N4Y@nothing4you.w.tf-w.tf] has quit [Quit: Gone...]
11:56<frosch123>sure, for now you can just add dummy sprites to fill the sets to the same amount
11:56<Elyon>yeah :)
11:56<Elyon>also ... how do you feel about `AbstractLayout` ?
12:00<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?
12:00<Elyon>no new NML syntax
12:00<Elyon>http://dev.openttdcoop.org/issues/2746#note-8
12:01<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
12:01<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
12:01<Elyon>that is the idea exactly
12:01<Elyon>the syntax is exactly the same once you reach the actual layouts
12:01<Elyon>I think?
12:03<frosch123>well, ottd also uses a common function to read them :)
12:03<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`
12:03<Elyon>ah :p
12:03<frosch123>though it also has to handle the deprecated syntax forms
12:04<Elyon>what deprecated syntax forms?
12:04<Elyon>I guess NML shouldn't worry about those
12:04<frosch123>yup, no need to
12:05<frosch123>i only was looking at the ottd source and the conditional parameters for parsing spritelayout format
12:05<Elyon>ah, okay ... hmm
12:06<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`
12:08<frosch123>Elyon: nml naming schema seems to use "Base" prefixes instead of "Abstract"
12:08<+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).
12:08<Elyon>frosch123, ah, I will call it `BaseLayout` and have it reside in "./actions/base_layout.py" then
12:09<NGC3982>michi_cc: I see.
12:09<frosch123>yup, that fits
12:09<NGC3982>I have never understood what TTDPatch is.
12:09<NGC3982>Is it a version of the game? A script? Am i using it right now?
12:09<@Alberth>it's the original TTD executable, patched with extensions
12:09<+michi_cc>http://www.ttdpatch.net/Manual/ttdpatch.html#Introduction
12:10<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
12:10<NGC3982>Since it describes 7*7 stations and mammoth trains, i guess it is no longer a viable way of playing OpenTTD?
12:10-!-gigglebla [~chatzilla@c-24-147-16-182.hsd1.ma.comcast.net] has joined #openttd
12:11<NGC3982>In comparison with current vanilla version of the game.
12:11<gigglebla>hey do you guys know about setting up servers
12:11<+michi_cc>NGC3982: There is not relation at all to OTTD.
12:11<NGC3982>Oh, allright.
12:11<gigglebla>my friend and I have been trying but it doesn't show up
12:11<NGC3982>Do people still play with it?
12:12<Elyon>gigglebla: port forward? advertised?
12:12<gigglebla>hold on let me get him
12:12<+michi_cc>Allegedly yes.
12:12<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?
12:13<Elyon>1) done and done
12:13<@Alberth>interestingly, "advertise fails" is not a FAQ :)
12:13<Elyon>2) duplicate 1As containing all layouts for all stations?
12:13<+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.
12:13<Elyon>3) so no support for station+non-station-spritelayouts?
12:14<NGC3982>michi_cc: I see.
12:16<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
12:17<frosch123>3: as you describe [] for non-stations, it is no array, for a list of instructions as in nml switches
12:17<frosch123>giving [] different meanings in station and non-station layouts i would call a bad thing
12:17<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)
12:18<frosch123>so, no idea whether anyone uses [] currently in spritelayouts, but i would forbid it
12:19<+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.
12:19<b_jonas>michi_cc: I see
12:20<Elyon>okay, hmm ... so spritelayouts with array values are inherently station-only, whereas spritelayouts without array values can be both station and non-station
12:20-!-MTsPony [~MTsPony@008-086-128-083.dynamic.caiway.nl] has joined #openttd
12:28-!-Mucht [~Martin@000128e2.user.oftc.net] has joined #openttd
12:30-!-gigglebla [~chatzilla@c-24-147-16-182.hsd1.ma.comcast.net] has left #openttd []
12:46<@DorpsGek>Commit by translators :: r27116 /trunk/src/lang (esperanto.txt slovak.txt) (2015-01-10 17:46:35 UTC)
12:46<@DorpsGek>-Update from WebTranslator v3.0:
12:46<@DorpsGek>esperanto - 1 changes by polluks
12:46<@DorpsGek>slovak - 15 changes by Blayss
12:48<Elyon>how would I add an entirely new file with mq?
12:48<Elyon>to a patch, I mean
12:49<Eddi|zuHause>with hg add?
12:49<Elyon>but that adds it to the commit, no?
12:49<Elyon>the "real" commit, I mean
12:49<Eddi|zuHause>if you're currently in a patch, it should add it to that patch
12:50<Eddi|zuHause>the patch is a "real" commit, as far as your local working copy is concerned
12:50<Elyon>`hg status` => "? nml/actions/base_layout.py"
12:50<Elyon>`hg qrefresh`
12:50<Elyon>`hg status` => "? nml/actions/base_layout.py"
12:51<Elyon>aooh nevermind okay, will try
12:51<Elyon>Eddi: yup, it worked flawlessly. I still have a few things with mq I need to wrap my head around, it seems :3
13:00-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd
13:05<@Alberth>o/
13:06<@Alberth>added some coloury goals http://devs.openttd.org/~alberth/goal_window.png
13:07<andythenorth>do we have news for completing a goal?
13:07<andythenorth>I know, I could read the code :P
13:07<Sylf>I don't remember a thing about news related class or functions in GS
13:07<@Alberth>no
13:07<@Alberth>I wondered whether to add it
13:08<andythenorth>I think so
13:08<andythenorth>and for new goal
13:08-!-Pereba [~UserNick@179.179.23.201] has joined #openttd
13:11-!-glx [~glx@000128ec.user.oftc.net] has joined #openttd
13:11-!-mode/#openttd [+v glx] by ChanServ
13:14-!-Zuu [~Zuu@h-114-162.a98.priv.bahnhof.se] has joined #openttd
13:16-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds]
13:19-!-sla_ro|master [slamaster@95.76.27.245] has joined #openttd
13:20<@Alberth>andythenorth: when you remove or move strings, the minimal version number to load needs to be incremented, I found
13:23<Elyon>hm, /some/ restructuring will have to take place as every spritelayout is assumed to correspond to one action 2
13:25<frosch123>Sylf: nocargoal gives monthly stats via news
13:26<frosch123>though since news are global, i prefer the company specific goal gui for that stuff
13:27<Sylf>which stats does it show?
13:27<frosch123>amount transported, months left, percentages
13:27<frosch123>however, i have no idea how it works with multiple companies
13:27<Zuu>IIRC you send news to a company in GS
13:28<frosch123>hmm, true, some news are also company specific in ottd
13:28<Sylf>I remember classes about story books etc, but nothing about news
13:28<frosch123>so, nevermind :)
13:28<Sylf>hm
13:28<frosch123>Sylf: http://nogo.openttd.org/api/trunk/classGSNews.html
13:28<Sylf>http://nogo.openttd.org/docs/trunk/classGSNews.html
13:28<frosch123>:p
13:29<Zuu>GSNews has been there ever since GS was introdueced. :-)
13:29<frosch123>i believe news are older than goal gui :)
13:29<Zuu>I think the goal GUI was in the first stable offering GS. But the story book came later.
13:29<Sylf>so you can introduce new goal for a company via news message if we want
13:30<frosch123>yeah, but news are inferior
13:30<frosch123>you cannot link a location and such
13:30<frosch123>and players will miss them anyway :p
13:30<frosch123>or have them turned off :p
13:30<Sylf><--
13:30<Zuu>You should stick the goal into the goal GUI and then you can also inform them about it in the news.
13:30<andythenorth>Alberth: does the string change break my savegame then? :)
13:30<@Alberth>yes
13:31<@Alberth>it looks like it stores the string number to use in the goal window
13:31<Sylf>ok good, GSNews is included in paste.o.o syntax highlighter
13:32<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.
13:32<@Alberth>/me ponders annoyingGS :p
13:33<Zuu>Yeah reordering strings break save/load :-)
13:33<Zuu>I've learned the hard way :-)
13:34<Eddi|zuHause>is that not fixable through after load handling?
13:35<@Alberth>gs has no afterload function afaik
13:35<frosch123>scripts are not updateable
13:35<frosch123>you have to treaten it to even reload your lang files
13:35<Zuu>GSes can fix it by rebuilding the goal list and story book content upon load
13:35<frosch123>normally it reuses the translations stored in the save
13:35-!-MTsPonyZzZ [~MTsPony@008-086-128-083.dynamic.caiway.nl] has joined #openttd
13:35<Zuu>Also re-setting town description text etc.
13:36<Eddi|zuHause>frosch123: "officially" :)
13:36<Zuu>That assumes the GS as an in-memory copy of all parameters etc. to update all strings.
13:37-!-MTsPony [~MTsPony@008-086-128-083.dynamic.caiway.nl] has quit [Ping timeout: 480 seconds]
13:37<frosch123>Eddi|zuHause: scripts are a lot more complicated than newgrf there
13:37<frosch123>they store the lang files inside the savegame
13:38<frosch123>the script otoh is not stored in the save
13:38<frosch123>so you easiyl end up with a newer script than texts
13:38<frosch123>the script will use a textid, but the text will be something entirely different
13:39<Eddi|zuHause>that sounds weird
13:39<frosch123>as said: scripts are not updateable
13:39<frosch123>not only "officially", it's really broken resp. not implemented at all
13:40<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.
13:40<frosch123>you can reload the script via the debug gui, but that will clear all script data
13:41<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.
13:47<frosch123>hmm, maybe we fixed that
13:48<Zuu>I don't know.
13:51<Zuu>Both cases still means that script developers should preferable not delete or reorder strings unless min compatible version is updated.
13:51<frosch123>no, i found the working copy with the partial fix
13:51<frosch123>so, the new lang files are loaded, but the new STR_XXX constants are not registered
13:52<frosch123>so, scripts cannot use new STR_XXX constants, and if they were inserted in the middle, the printed texts will differ
13:55-!-glx [~glx@000128ec.user.oftc.net] has quit [Ping timeout: 480 seconds]
13:56<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?
13:56-!-glx [~glx@000128ec.user.oftc.net] has joined #openttd
13:56-!-mode/#openttd [+v glx] by ChanServ
13:56<Elyon>(it only needs the action2layout injection for non-stations)
13:57<Elyon>(stations will probably need to retain a station_layout_list in "base_layout.py")
13:58<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
14:00<frosch123>for non-stations the spritelayout references the action1, but stations it could also reference a spritegroup
14:01<frosch123>so, for stations the spritelayout does not create the action1, instead it inserts a spritegroup or something
14:01<Elyon>hmm ...
14:01<frosch123>unless you also handle the spritegroup in the spritelayout
14:01<Elyon>so nonstation => action1 -> action2layout -> varaction2s
14:02<Elyon>and station => spritegroup -> varaction2s?
14:02<Elyon>well spritegroup -> varaction2(var10) -> varaction2(var0C) -> varaction2s
14:02<Elyon>s/->/<-/g
14:02<frosch123>yes
14:04<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()`
14:04<Elyon>so `base_layout.get_layout_actions` only really gets the varaction2s
14:05-!-DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has joined #openttd
14:05<Elyon>in light of that, `get_layout_varaction2s` is probably a better name for the function
14:06<Elyon>why are stations so weird and inconsistent with everything else? T_T
14:06-!-liq3 [~liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] has joined #openttd
14:10<frosch123>it's the little/lots thingie :)
14:10<frosch123>industries/objects do not show cargo
14:10<frosch123>vehicles do
14:11<frosch123>stations combine the properties of industries/objects and stations, so they are the most complicated
14:11<Elyon>s/and stations/and vehicles
14:11<Elyon>?
14:11<frosch123>yes :)
14:12<Elyon>well, it shouldn't be too bad. We just have to be /super careful/ when implementing station support
14:12<frosch123>vehicles have loading stages, industries have layouts, stations have both :p
14:12<Elyon>I am beginning to see why it has been postponed for years
14:12<@Alberth>original developers leaving is also not helping :)
14:12<Elyon>huh, nml devs?
14:13<frosch123>yes, neither yexo nor hinundo have been seen for 2 years
14:13<@Alberth>*hirundo
14:13<frosch123>albert, pm and me have started doing some stuff, but only in some areas
14:13<Elyon>oh, okay ... hm. I was of the impression that NML was pm's brainchild
14:13<Elyon>but apparently not :p
14:13<frosch123>pm is the marketing guy :p
14:14<Elyon>:D :D
14:14<Elyon>well, to be honest nml-stations is not /completely/ out-of-reach, I would say
14:14<V453000>:D
14:14<@Alberth>and selling great cheap planets too :)
14:14<Elyon>:p
14:14<Elyon>hiya V453000
14:14<V453000>hi :)
14:15<Elyon>if feature == 0x04: make_stations_work()
14:15<V453000>1
14:15<V453000>Elyon: 000101000101010010010101
14:15<V453000>;
14:16<Elyon>name 'make_stations_work' is not defined
14:16<Elyon>T_T
14:16<V453000>just testing whether you are fully a robot yet or not
14:16<Elyon>hmm, that's not ascii
14:16<Elyon>what is it?
14:16<V453000>random shit :D
14:16<Elyon>ah :D
14:16<Elyon>random shit is a cryptanalyst's worst nightmare
14:16<V453000>XD
14:16<V453000>yeah
14:16<V453000>thats me
14:17<Elyon>that field has TONNES of false positives
14:18-!-FLHerne [~flh@dsl-217-155-24-22.zen.co.uk] has joined #openttd
14:19<V453000>hmmm in landscape, when does the 2nd set of rocks appear?
14:19<V453000>I cant seem to find it ingame :D
14:20<frosch123>it's random
14:20<V453000>like randomly chosen rocks 1 or 2?
14:21<V453000>that is strange, I just tried to visually overwrite rocks 1 as grass, rocks 2 as rocks ... never seen rocks then
14:21<frosch123>_landscape_clear_sprites_rough[GB(ti->x ^ ti->y, 4, 3) <- there are 5 different flat tiles for rocks
14:21<frosch123>depending on the tile position
14:22<V453000>I identified that as rough
14:22<V453000>but yeah that is something different
14:22<frosch123>make a long stretch of rocks, like 128 tiles, and you should find 5 types
14:22<V453000>there are 2 sets of rocky land
14:22<V453000>aha
14:23<V453000>hm
14:23<V453000>:)
14:23<frosch123>oh, rocks, not rough
14:23<frosch123>hmm
14:23<V453000>yeah
14:24<frosch123>does not look like they are used at all :p
14:25<V453000>exactly what I thought XD is wtf.
14:25-!-quorzom [~quorzom@cable-78-35-98-177.netcologne.de] has joined #openttd
14:26<frosch123>so, more tto only sprites
14:26<frosch123>i thought there were only 6 unused sprites, now it's 25
14:27<frosch123>let's see what they actually look like
14:27<V453000>in ogfx they seem to be just duplicate of rocks1
14:31<frosch123>they also pretty much look the same in original
14:31<V453000>hm :)
14:32<V453000>use them? :) RAWR could supply 2 various kinds of rocks
14:32<V453000>am assuming that if ogfx has them, zbase does as well
14:33<frosch123>i guess two types would always look silly/repetive
14:34<frosch123>ah, they are not 100% the same
14:35<frosch123>ROCK1 has some more transparent pixels/grass
14:36<V453000>xd
14:37<V453000>well one type is definitely more repetitive than 2 :P
14:38<frosch123>http://devs.openttd.org/~frosch/rocks.png <- do you see the difference? :)
14:39<V453000>yeah
14:39<V453000>tiny but is
14:39<V453000>https://dl.dropboxusercontent.com/u/20419525/RAWR/asdf2.png :P
14:40<@Alberth>:o nice!
14:40<Eddi|zuHause>"we have put 5 errors in this picture"
14:41<V453000>it needs a lot of making-nicer Alberth but yeah, wip :(
14:41<V453000>:)
14:41<V453000>Eddi|zuHause: ? :D
14:41<Eddi|zuHause>i meant frosch123's picture. yours doesn't quite load
14:41<V453000>is just big as fuck
14:41<Eddi|zuHause>either it's huge, or slow
14:42<frosch123>V453000: how does the slope edge make it onto the stone?
14:42<frosch123>is it only a texture? no modelled stone?
14:42<V453000>the brigtness difference?
14:42<Eddi|zuHause>V453000: with "slow" i mean "uses about 5% of my available bandwidth"
14:43<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
14:43<frosch123>V453000: the SLOPE_E tiles definitely look weird
14:43<frosch123>with the brightness cut over the stone :p
14:43<V453000>wtf is slope_e
14:43<V453000>yes
14:43<V453000>I will see what can be done about it
14:43<frosch123>EAST corner raised
14:44<V453000>if nothing else then I can always move stones away from the edge
14:44<Eddi|zuHause>at least where i come from, slopes are described from the lowest side
14:44<Zuu>What is wierd about SLOPE_E? small stones not rolling down?
14:44<V453000>the render simply does not output clear enough images for gameplay ... but I will see what can be done
14:45<frosch123>V453000: you need to learn the snow tricks from ogfx
14:45<V453000>yeah the snow looks quite bad so far
14:45<frosch123>partially snowy slopes should have more snow on the higher parts
14:45<V453000>yeah
14:45<frosch123>that's something which ogfx does way better than original graphics :p
14:45<V453000>good point
14:45<Eddi|zuHause>Zuu: there is a vertical line through the stone
14:46-!-luaduck is now known as luaduck_zzz
14:46<V453000>am actually setting up a new texture infrastructure right now, so will do that :P good idea, thanks
14:46<frosch123>though, i think someone made a grf for original graphics before ogfx existed
14:46<V453000>yeah
14:46<V453000>I think so too but doesnt matter
14:47<Eddi|zuHause>yeah, there was a "smooth snow transition grf" which i guess was simply absorbed into opengfx
14:47<Zuu>Oh.. yeah zooming in, now I see the vertical line.
14:49<Eddi|zuHause>OpenGFX was a lot of "there is already this stuff, we just combine it to a complete base set"
14:50<frosch123>i think the smooth snow transition grf matched original snow on flat tiles though
14:50<frosch123>ogfx has a different hue
14:51<Eddi|zuHause>i've never used opengfx
14:51<@Alberth>and it's much less than 5% bandwith, even!
14:52<@Alberth>*bandwidth
14:54-!-glx_ [~glx@2a01:e35:2f59:c7c0:587b:5a81:d1a4:d41] has joined #openttd
14:54-!-mode/#openttd [+v glx_] by ChanServ
14:54-!-glx is now known as Guest1432
14:54-!-glx_ is now known as glx
14:55<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
14:56-!-Guest1432 [~glx@000128ec.user.oftc.net] has quit [Ping timeout: 480 seconds]
14:56<V453000>there will be a lot of texture edits still ... and grid is not out of the question either :)
14:56<V453000>at least some hinted texture
14:56<frosch123>i mean, your flat tiles have a somewhat rectangular repetitiveness, that looks like a grid, but it is not on the tile grid
14:56<V453000>I basically just got some first version working, need moar
14:56<V453000>yeah
14:56<V453000>I know
14:57<frosch123>well, you won't achieve non-repetetiveness :) that only works with actual 3d lightning, not with sprites
14:57<frosch123>so, i think the better strategy is to make a intentionally-looking repetetiveness
14:57<frosch123>i.e. a grid :p
15:01<frosch123>https://paste.openttdcoop.org/p4dzjy7cq?/p4dzjy7cq <- so, what to do with that?
15:01<frosch123>i don't fancy coming up with a more advanced "randomness"
15:01<frosch123>the existing basesets look almost the same anyway
15:01<Eddi|zuHause>frosch123: use pseudorandom like for rails?
15:01<V453000>yeah :)
15:02<frosch123>that diff already is pseudorandom?
15:02<frosch123>GB(ti->x ^ ti->y, 4, 3) <- rough tiles use the same iteration
15:02<frosch123>but there are 5 types at least
15:04-!-gelignite [~gelignite@i528C3A79.versanet.de] has joined #openttd
15:04<Eddi|zuHause>frosch123: that doesn't look very random to me.
15:05<Eddi|zuHause>actually, that's decidedly periodic
15:05<frosch123>the house-randomness is also mostly periodic
15:05<frosch123>railtype randomness is slightly more complicated
15:06<frosch123>but with 1 random bit, there is not much randomness anyway
15:06<Eddi|zuHause>there are perfectly random binary numbers...
15:06<__ln___>e.g. 0
15:07<Eddi|zuHause>each digit has only 1 bit
15:07<frosch123>i like unary numbers
15:07<Eddi|zuHause>__ln___: i think you'd find it very hard to prove even the most basic randomness conditions in that number :p
15:08<frosch123>fine, i'll use the house randomness
15:08<frosch123>good enough for 1 bit
15:09<frosch123>it's not even rfc conform
15:09<andythenorth>so…docks
15:09<andythenorth>iirc, the newgrf spec provides for flat docks?
15:10<Eddi|zuHause>andythenorth: allegedly, TTDPatch has some sort of flat docks
15:10<andythenorth>can anyone start it and confirm?
15:10<andythenorth>I have never seen a TTDPatch
15:10<@DorpsGek>Commit by frosch :: r27117 trunk/src/clear_cmd.cpp (2015-01-10 20:10:51 UTC)
15:10<@DorpsGek>-Fix/Feature: Make use of both rocky tile sets from the base graphics.
15:11-!-Mucht [~Martin@000128e2.user.oftc.net] has quit [Remote host closed the connection]
15:15<frosch123>hmm, so ottd is not that slow to start up
15:15<frosch123>ttdp is just as slow
15:16<@Alberth>delete all newgrfs?
15:16<frosch123>nah, not the grf scan, i mean actually loading the shared libs and such
15:16<frosch123>if i start ottd the first time after reboot, it takes ages to load shared libs
15:17<@Alberth>you need ssd
15:17<frosch123>hmm, does not look like this revision works
15:17<@Alberth>or add openttd to the kernel :p
15:19<frosch123>r1995 started
15:23<frosch123>andythenorth: http://devs.openttd.org/~frosch/ttdp_r1995_docks.png
15:23<frosch123>selecting the tile between the two canals areas selects the northern one
15:24<frosch123>actually it says "site unsuitable" when trying to build
15:24<frosch123>though i can add canal afterwards
15:25<andythenorth>ho flat docks :)
15:26<andythenorth>high level of graphical fidelity there :P
15:26<andythenorth>the land dock has water around it
15:26<frosch123>maybe i am missing a grf or something
15:26<frosch123>andythenorth: anyway, get dosbox and enjoy :p
15:26<andythenorth>'enjoy'
15:27<frosch123>dosbox has a built-in 2x mode
15:31-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
15:32<Elyon>frosch123: the generated `Action6` in `get_layout_action2s` of "./actions/action2layout" is meant for non-stations only I think ... do you know?
15:36<frosch123>Elyon: it's used to write the value, if you use a parameter in the spritenumber
15:38<frosch123>there are 3 types of values in grfs: compile-time constants, load-time constants and dynamic values
15:38<frosch123>load-time constants are constant after loading the grf in ottd
15:38<frosch123>stuff like spritenumbers from other grfs and such
15:39<frosch123>compile-time constants are directly processed by nml, load-time constants are applied using action6, dynamic values reference registers
15:40<frosch123>or in short: any value from the nml source, which is an expression, needs to be passed through actionD.write_action_value
15:42<frosch123>anyway, you also need it for stations, but likely in the action0 :p
15:49-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has joined #openttd
16:00<Elyon>so I need to use an action6 to modify the action0?
16:01<frosch123>the exiting action0 should already do similar things
16:02<Elyon>hmm ... I will have to look into that. For now, though, the `action6` is entirely different between stations and non-stations, yes?
16:02<frosch123>i don't think so
16:03<Elyon>oh, hmm
16:05<Elyon>the offset will be different, but the modifications should be the same, I guess
16:06<Elyon>also, the action6 will go before the action2 for non-stations, but before the action0 for stations. Hmm ...
16:06<frosch123>it belongs to the layout
16:06-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds]
16:07<Elyon>quite
16:07<Elyon>wait
16:07<Elyon>huh
16:07<frosch123>maybe don't consider action6 a separate action, it is more like an addendum to any output data
16:07<Elyon>issue, though. action0 prop 1A is not a layout, but a collection of layouts
16:08<frosch123>action0 is a collection of many things
16:08<frosch123>but why does that matter?
16:08<Elyon>because the current action6-for-action2layout assumes one layout
16:09<frosch123>well, you cannot reuse the layout output on an action level
16:10<Elyon>no... What I mean is, the current layout generates a single-layout-action2 possibly modified by an action6
16:10<Elyon>for stations, an arbitrary-layout-action0-prop1a is generated and will possibly be modified by a single action6 as well
16:11<Elyon>but /that/ action6 has to apply modifications to all prop1a-layouts that need modifications
16:11<frosch123>it even has to apply modifications to all other properties of the action0
16:11<Elyon>hmm
16:11<frosch123>so, whatever writes the code, the action6 need to be passed as parameter to that method
16:12<Elyon>the action0-modifying action6 already exists, right?
16:13<Elyon>so wherever that is generated needs to have modifications added, /or/ as you say, that action6 can be passed to .. hmmm
16:13<Elyon>alternatively, we make a separate action0 that just defines prop1a
16:14<frosch123>parse_property_block creates an action6
16:15<frosch123>parse_property returns a tuple with both the stuff to write and the stuff to append to the action6
16:15<Elyon>okay, hmm ...
16:15<frosch123>so, following that example, the layout writing function should return the bytes for the layout, and a list of action6 stuff
16:16<frosch123>the action0 then writes the bytes, adds a positional offfset to the action6 stuff, and appends it to the rest of the action6
16:16<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?
16:16<Elyon>ah, hmm
16:16<Elyon>the former would be neater
16:17-!-oskari89 [oskari89@83-102-63-32.bb.dnainternet.fi] has joined #openttd
16:19<frosch123>the latter seems to be done in multiple places already
16:19<frosch123>the more complicated action0 (which i guess 1A qualifies for) are written separately
16:20<Elyon>which approach would be preferred in this case, then?
16:20<Elyon>given equal opportunity
16:20<frosch123>i guess a separate action0 is better
16:21<frosch123>the layouts do not have a particular relation to the other properties, so it does not look useful to mix them
16:21<Elyon>this action0 has to come after the station-class setting action0 though
16:22<Elyon>but as said, for non-stations the action6 only modifies one spritelayout, whereas for stations it needs to modify all the spritelayouts
16:22<frosch123>but for stations you also need to write multiple layouts
16:23<Elyon>yes
16:23<frosch123>so, why do you focus so much on the action6?
16:23<Elyon>because all the layout action6-modifications need to be coerced into a single action6
16:23<frosch123>so do the layouts into a single action0
16:23<Elyon>that is required anyway
16:23-!-Buntunub [~quassel@c-24-126-85-103.hsd1.va.comcast.net] has quit [Read error: Connection reset by peer]
16:24<frosch123>well, the action6 and the action0 belong together, they are one thing, not two separate
16:24<Elyon>yes
16:25<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
16:25<Elyon>:p
16:26<frosch123>ah, well you are allowed to complain :)
16:26<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
16:27<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
16:27<Elyon>alternatively, I can just check `if feature == 0x04` in the abstract base class
16:29<Elyon>tl;dr `if feature == 0x04: """iterate layouts and add modifications to action6""" else: """add modifications to action6"""
16:29<Elyon>`
16:30<frosch123>did you look at action0?
16:30<Elyon>yes?
16:30<Elyon>oh action0.py -- yes, but not recently
16:31<Elyon>what of it?
16:32-!-Nothing4You [N4Y@nothing4you.w.tf-w.tf] has joined #openttd
16:32<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)
16:32<frosch123>e.g parse_property()
16:32<frosch123>the caller concatenates the stuff to append to action0, adds a offset to the returned a6 stuff and then adds that
16:33-!-Buntunub [~quassel@c-24-126-85-103.hsd1.va.comcast.net] has joined #openttd
16:34-!-smoke_fumus [~smoke_fum@188.35.176.90] has joined #openttd
16:34<Elyon>you mean parse_property_block?
16:34<Elyon>wait, hmm ...
16:36<Elyon>you're hinting that the action6 generation is already implemented for action0 anyway, so I should just set prop1A for the item?
16:38<Elyon>as the parsing should generate act6 modifications according to what the property values require?
16:39<frosch123>i am not sure whether parse_property_block is the right thing to hook into
16:39<frosch123>that parses the "property" block after all :p
16:39<frosch123>you said, you wanted to trigger it via the stationclass property though
16:39<Elyon>yes
16:39<frosch123>so, that could be an option
16:39<Elyon>what
16:40<Elyon>ideally I would want to put prop1A with the other properties
16:40<frosch123>well, you registered the stationclass property somewhere in action0properties.py
16:40<Elyon>so if I just generate and append prop1A before it is parsed, it should work automagically
16:40<Elyon>frosch123, I did yes
16:41<frosch123>if you register a 'custom_function' you can also add the layouts
16:41<Elyon>I did that as well
16:41<Elyon>it just needs to not be an NML-settable property
16:41<frosch123>no, i mean writing it together
16:42-!-Pensacola [~quassel@c80094.upc-c.chello.nl] has quit [Remote host closed the connection]
16:42<Elyon>yes, that's what I want as well
16:42<frosch123>register a custom method for the stationclass
16:42<frosch123>but do not only write the stationclass but also the layouts with the same method
16:42<Elyon>why the stationclass?
16:42<Elyon>because it's guaranteed to be there?
16:42<Elyon>or must be, anyway
16:43<frosch123>huh?
16:44<frosch123>you wanted to write it together with stationclass, didn't you?
16:44<Elyon>I don't know, this is getting confusing
16:44<Elyon>uhm ... yeah. Yes. And all the other properties ideally
16:44<Elyon>which already happens for all properties so-far-defined
16:44<Elyon>it is an error not to specify stationclass anyway, so that makes sense I think
16:45<frosch123>so, i suggested that you register a 'custom_function' for writing stationclass
16:45<frosch123>but make that custom function not only write the stationclass, but also the layouts
16:45<frosch123>the registered functions can write more than one property
16:45<Elyon>seems hackish though
16:45<Elyon>seems hackish, I'd rather have a StationSpritelayoutsProp and use that to write the property?
16:45<Elyon>s/seems hackish, //
16:45<frosch123>yes :p i would write the layouts with the "graphics" block
16:46<frosch123>not with the "stationclass"
16:46<Elyon>but the graphics block is not an action0
16:46<frosch123>why is that important?
16:46<Elyon>because;
16:47<frosch123>also, why does using 'custom_function' prevent you from using StationSpritelayoutsProp?
16:47<Elyon>the graphics block actions are written before action0prop08, but action0prop08 /must/ be set in the first action0 for that station
16:48<frosch123>are you sure about that?
16:48<frosch123>i am pretty sure action3 is written after the action0
16:48<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."
16:48<Elyon>action3 is written after the action0, yes
16:49<frosch123>actually, the ideal place to add the stationlayout action0 is action3.py:357
16:49<frosch123>right after inserting the action0 for the callback flags
16:49<frosch123>so, i would recommend that place :p
16:49<Elyon>I haven't looked at action3.py yet
16:50<frosch123>you need to modify that place anyway, to enable callback 14
16:51<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
16:53<Elyon>wouldn't it be easier to just generate a "property 1A" for the station before it is written?
16:54<Elyon>that way, the existing property handling code does all the work
16:55<frosch123>no idea, i consider using the existing property handling code not particulary useful for writing 1A
16:55<frosch123>action3.py looks way better to me, and the same is done for other automatically generated properties, like callback flags
16:55<Elyon>I will make it so
16:55<Elyon>:p
16:55<frosch123>so, i would not add 1A after the other action0, but in front of a3
16:56<Elyon>you're still on separate action0 for the layouts, yes?
16:56<frosch123>but, well, i only know details of nml as i find them :p
16:56<Elyon>because I was talking about adding 1A /in/ the other action0
16:56<Elyon>since now is the time to decide to do that
16:56<Elyon>it's one less action in the GRF :p
16:56<frosch123>yes, but looking at action3.py and seeing how callback are done, a separate a0 looks better :)
16:57<Elyon>two less, actually
16:57<Elyon>frosch123, roger; in that case (where other stuff is handled with separate action0s) I will do so as well
16:57<Elyon>and then in two years time submit a patchset that coerces every single action0prop into single action0s
16:58<Elyon>s/years/years'
17:00-!-dreck [~oftc-webi@166.62.182.125] has joined #openttd
17:00<dreck>hi
17:01<@Alberth>o/
17:02<Elyon>long story short: I will not abstract the current action6-for-action2layout out then, as it is completely separate from action0/action3
17:09-!-Yotson [~Yotson@2001:980:6ac8:1:4ccd:9876:25ca:1380] has quit [Quit: .]
17:12-!-sla_ro|master [slamaster@95.76.27.245] has quit []
17:15*Elyon is tempted to make a `BaseLayoutActionGroup` to wrap around action1/action6 for non-stations
17:16<Elyon>that would save me passing the results of one function as a parameter to the next
17:18<frosch123>it's not only action6, there are also actionD :p
17:19<frosch123>and possibly action7 and more
17:19<Elyon>the temptation is still strong
17:19<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
17:21<Elyon>but the wrapper would save us from duplicating the header/footer around the action1/6/7/Ds for non-stations, and stations
17:21<Elyon>for now it is a chain of methods that each take the parameters of the last
17:21<Elyon>s/parameters/return values
17:21<Eddi|zuHause>you forgot action9
17:22<Eddi|zuHause>and i never ever remember what that actually is for...
17:22<Elyon>action[^02] then
17:22<Elyon>:p
17:22<Eddi|zuHause>you probably don't want actionF :p
17:22<Elyon>but I do want action14
17:22<Elyon>so
17:22<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
17:23<Elyon>that it outside the scope of this particular patch
17:23<frosch123>yup :p
17:23<Elyon>which /just/ deals with abstracting whatever makes sense from Action2Layout
17:23-!-Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd []
17:23<Eddi|zuHause>but, you can't action6 an action2 anyway
17:24<frosch123>Eddi|zuHause: stop talking bollocks
17:24<Elyon>:D
17:24<Elyon>I'll action6 your action2
17:24<Elyon>wait ... that's actually ...
17:24<Eddi|zuHause>the specs were wery vocal about that
17:24<Elyon>a euphemism
17:25<frosch123>you possibly cannot action6 the action2ids
17:25<frosch123>but you likely need a debuger the figure that out
17:25<frosch123>a ttdp debugger that is
17:26<andythenorth>bye
17:26-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has left #openttd []
17:28<Eddi|zuHause>frosch123: well, my understanding is that because action2s are evaluated during execution, and action6s during activation, they can not have an effect
17:29<frosch123>go back to 21:38
17:29<frosch123>read about the concept of compile-time and load-time constants
17:30<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
17:30<Elyon>'Action2LayoutActionGroup' or 'BaseLayoutActionGroup' or what should I call it? o_O
17:31<Elyon>actually I will just leave it as functions instead of methods and attributes
17:32*Elyon has a hard time focusing on single issues when there are plenty others to solve
17:33<Eddi|zuHause>frosch123: i'm not sure how this applies
17:33<frosch123>action6 is about load-time constants
17:35<frosch123>that's even a equivalency
17:35-!-glx [~glx@000128ec.user.oftc.net] has quit [Read error: Connection reset by peer]
17:35<frosch123>some people think they can also do load-time constants using var 7F, but that limits the total number of constants quite hard
17:35<Eddi|zuHause>yes. but i always assumed that the data is read and applied during loading/activation, and then discarded
17:35-!-glx [~glx@2a01:e35:2f59:c7c0:587b:5a81:d1a4:d41] has joined #openttd
17:36<frosch123>it's not discarded, it's processed
17:36<Eddi|zuHause>but that would mean you need to keep the whole grf in memory
17:36<frosch123>action6 is like putting ketchup on your fries
17:37<frosch123>you cannot do that after you ate them
17:37<Elyon>:D
17:37<frosch123>Eddi|zuHause: yes, all pseudo sprites are kept in memmory
17:37-!-supermop [~supermop@d110-33-179-139.sun801.vic.optusnet.com.au] has joined #openttd
17:37<dreck>frosch tell that to the silly boy in Zits comic...
17:37<frosch123>ottd copies them (parsed) into real structures
17:37<frosch123>ttdp overwrites some integer values in the grf with pointers
17:38<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
17:38<Eddi|zuHause>frosch123: then, why is it dangerous to skip action2 with action7/9?
17:39<frosch123>because ttdp replaces the action2ids with pointers in the init-stage
17:39<frosch123>if you skip them with action9, that does not happen
17:39<frosch123>so if they are used later, ttdp crashes
17:40<frosch123>skipping them with action7 later has no effect, since the pointers to them are already resolved
17:40<Eddi|zuHause>so, that action6 works is rather pure coincidence than actual spec?
17:40<frosch123>i have no idea what spec you are refering to
17:41<frosch123>i know about a7/9, but restrictions to a6 are undocumented
17:41<frosch123>still ttdp crashes if you overwrite a pointer with a6 with a different value
17:41<frosch123>it likely works if you skip the a6 using a9 after init-stage though :p
17:41<Eddi|zuHause>maybe i just always assumed that action6 had the same restrictions as 7/9
17:42<frosch123>a6 has only the ketchup restriction
17:42<frosch123>you can overwrite anything, except after it is already processed
17:43<frosch123>a9 can skip anything, but you must not skip certain processings
17:43<frosch123>a7 can skip anything, but it may not matter anyway, since it is already processed
17:43<frosch123>so a7 also has the ketchup rule
17:43<Elyon>ketchup rule
17:43<Elyon>reminds me of "asparagus staging" in kerbal
17:43<frosch123>it does not matter whether you skip the ketchup, after you already ate the fries
17:44<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
17:46<dreck>ketchup + mustard + small fork/knife = orange spread over your hotdog :)
17:46<dreck>someone used to do that once in a while
17:47<Eddi|zuHause>they have taken this "cloud" metaphor to a new level: http://uk.businessinsider.com/amazon-data-center-fire-2015-1?r=US
17:50<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?
17:50<frosch123>what's the point of that news?
17:51<Eddi|zuHause>no idea
17:51<frosch123>Eddi|zuHause: anyway, about cloud services you should search for the "chaos monkey"
18:03-!-dreck [~oftc-webi@166.62.182.125] has left #openttd []
18:19-!-Suicyder [~Suicyder@86.92.59.88] has quit [Quit: HydraIRC -> http://www.hydrairc.com <- s0 d4Mn l33t |t'z 5c4rY!]
18:24-!-FLHerne [~flh@dsl-217-155-24-22.zen.co.uk] has quit [Quit: There's a real world out here!]
18:27-!-HerzogDeXtEr [~flex@88.130.180.71] has quit [Quit: Leaving.]
18:30-!-MTsPonyZzZ [~MTsPony@008-086-128-083.dynamic.caiway.nl] has quit [Remote host closed the connection]
18:31-!-MTsPony [~MTsPony@008-086-128-083.dynamic.caiway.nl] has joined #openttd
18:46-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
18:47-!-supermop [~supermop@d110-33-179-139.sun801.vic.optusnet.com.au] has quit [Ping timeout: 480 seconds]
18:50-!-frosch123 [~frosch@frnk-4d01b043.pool.mediaWays.net] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
19:06-!-oskari89 [oskari89@83-102-63-32.bb.dnainternet.fi] has quit []
19:07-!-NewNub [~oftc-webi@ac230029.ppp.asahi-net.or.jp] has joined #openttd
19:08<NewNub>Hello, i'm new to this game and both me and some friends of mine who tried to play cannot understand how to follow what people are doing as specators
19:08<NewNub>I there something we don't know about the client gui?
19:09<Zuu>You will have to communicate on the chat where to look
19:09<Zuu>You can also place signs and use the sign list window to find the spot you talk about.
19:09<NewNub>as spectators?
19:10<ST2>I guess NewNub is talking about this: http://www.tt-forums.net/viewtopic.php?f=33&t=45221
19:10<Zuu>Spectators can't place signs. But the perosn on the company can create signs.
19:10<Zuu>Anyway if you play a game, why not join a company?
19:11<NewNub>i'd like to watch first
19:11<NewNub>yeah that link look like what i was serching for
19:11<NewNub>searching for
19:12<NewNub>so that says that some tool to watch companies has been removed? :|
19:12<Zuu>It is a patch that has never been included in the official OpenTTD version.
19:13<ST2>still a link to download a patch file in last page: http://www.tt-forums.net/viewtopic.php?f=33&t=45221&hilit=watch+window&start=60
19:13<NewNub>oh i see
19:13<NewNub>i there any special reson for not including in the client?
19:15<NewNub>because without something who helps following the game is really frustrating
19:15<@planetmaker>it's very easy to follow what s/o is doing by communicating and referencing sprites
19:15<@planetmaker>but being able to actually track s/o by the tile is an extreme griefing opportunity.
19:15<@planetmaker>And I don't speak from theory, I tried such patch as admin of a server
19:16<@planetmaker>the sign list is easily accessible, every player can use it and click to jump where a sign is. Dead easy
19:16<@planetmaker>similar with station and industry lists
19:17<NewNub>so you agree with me?
19:17<@planetmaker>dunno. I will never support such patch
19:17<ST2>viewports too, if you want to keep an eye in a particular spot ^^
19:17<Zuu>Station list allow you to find stations of a company if the map is insanely large and just moving around doesn't find you anything to look at.
19:17<@planetmaker>I wrote a similar one once and concluded its poisonous for the game
19:18<NewNub>oh so you don't agree :|
19:19<Zuu>I don't really have an opinion on if such a patch is good or bad.
19:19<@planetmaker>you can click on sign/station/industry list and jump there. If a place is communicated, you can easily follow anything
19:19<Zuu>But there are facilities to communicate with players and browse what they have built.
19:20<NewNub>i don't understand how to easily communicate with people
19:20<NewNub>and also why a spec should bother players to see what they are doing
19:20<Zuu>Press T or Enter to open chat window
19:20<@planetmaker>type in chat?
19:21<NewNub>so players start teching? i don't understand
19:21<@planetmaker>teaching other players works like a charm on the coop servers. And on others, too.
19:21<@planetmaker>They just read what others type. And write back. In public chat... how easier can it be?
19:21<@planetmaker>there's even auto-complete for townnames
19:22<NewNub>i believe it for expert players but for new one first time playing is kind of complicated to think that way at beginning
19:23<NewNub>'cause everyone expect to watch what's happening independently
19:23<Elyon>what, human interaction is kind of complicated for humans? :p
19:24<NewNub>without need to type stuff or bother anyone
19:24<NewNub>yes imo is complicated
19:24<Elyon>oh, hmm
19:24<Elyon>check out the tutorial game, then join and check out how stuff has been built?
19:24-!-Progman [~progman@p57A1BBA1.dip0.t-ipconnect.de] has joined #openttd
19:25<Zuu>So instead of typing to a human in game, you type to humans on IRC :-)
19:25<Elyon>speak for yourself, Zuu :3
19:25<NewNub>i do 'cause i put effort to understand things
19:25<NewNub>but i'm just suggesting about the random player behaviour
19:26<Zuu>In-game tutorial: http://wiki.openttd.org/In-game_tutorial
19:26<Zuu>wiki tutorial: http://wiki.openttd.org/Tutorial
19:26<Elyon>openttdcoop tutorial savegame: http://wiki.openttdcoop.org/Tutorial_Savegame
19:27<NewNub>i think that would be top priority patch to improve confidence of new players on this game
19:28<Elyon>what, self-confidence of new players? What is the difference from just joining and checking out what has been built?
19:29<NewNub>tracking difficulty
19:30<Elyon>you mean track placing?
19:30<NewNub>and gives people more sense that people are doing something
19:30<Zuu>You can look at youtube for videos with people building stuff in OpenTTD and commenting what they do.
19:31<Zuu>And for MP, try a smaller map, or #openttdcoop public server on busy times.
19:31<NewNub>ok
19:32<NewNub>by the way i hope i could contribute with my opinion :D
19:32<Elyon>definitely, it's always nice knowing the new player perception, as that is difficult to sample yourself
19:32<Zuu>I once played a 64x64 MP with 3-4 people. :-D
19:33<Zuu>Then you had good overview over what the others did. :-)
19:33<Elyon>while you're at it, NewNub, you should start developing newgrfs as well :D
19:34<NewNub>what is that?
19:34<NewNub>newgrfs?
19:35<Elyon>plugins/mods/addons/something like that
19:35<Myhorta>I don't know what you could learn from just watching. It feels empty for me. Most of the times you won't even understand why the builder took such decisions. At most what you will learn is building patterns. And, IMO, it is better explained in tutorials like the ones mentioned above
19:35<Elyon>or through full duplex communication
19:36<Myhorta>y
19:36<Elyon>also, PHEW
19:37<Elyon>that was spritelayouts abstracted. Now, on to stations!
19:37<NewNub>well.... i'm already involved in another project
19:37<NewNub>this would be too much for me i guess
19:37<Elyon>it was mostly a joke
19:38<Elyon>:)
19:38<NewNub>:)
19:39<NewNub>oh there are other clients too? D:
19:39<Elyon>huh?
19:39<NewNub>what's this btpro? is that official?
19:39<Elyon>never heard of it
19:40<NewNub>http://openttd.btpro.nl/
19:40<Elyon>no, it is not official
19:40<Elyon>and it has snowflakes on the website so I wouldn't get it
19:41<NewNub>lol
19:41<Myhorta>:D
19:41<NewNub>but what is that? is that safe or some fake stuff?
19:41<Elyon>probably safe but specific to the btpro community
19:41<Elyon>if you're not part of that, I doubt there's much use
19:42<Myhorta>it is safe. It includes some extras features they think it enhances the gameplay for their servers
19:42<Elyon>just get vanilla openttd, possibly plop in some newgrfs, and start playing :)
19:42<Wolf01>'night
19:42-!-Wolf01 [~wolf01@0001288e.user.oftc.net] has quit [Quit: Once again the world is quick to bury me.]
19:43<Myhorta>y. For newcomers vanilla is the way to go
19:43<NewNub>where is that?
19:43<Elyon>http://openttd.org/
19:44<NewNub>so the standard client?
19:44<Elyon>'vanilla' should be understood as 'plain, unmodified'.
19:44<Elyon>this goes for everything related to software
19:44<Elyon>yes, the standard client
19:44<NewNub>i already have it
19:44<Elyon>good. :)
19:45<NewNub>that's why i was asking that question at beginning :D
19:47<NewNub>'cause after we joined a server the first time we couldn't understand a thing of what was happening :|
19:48-!-Zuu [~Zuu@h-114-162.a98.priv.bahnhof.se] has quit [Quit: Leaving]
19:49<Elyon>which server?
19:49<Elyon>and if you want, I'll do a 64x64 with you just to get you started :)
19:56-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Read error: Connection reset by peer]
19:58<NewNub>really thank you Elyon but i got to go now
19:58<NewNub>maybe in some of the next few days
19:59<NewNub>thank you guys for support
19:59<NewNub>see ya
19:59-!-NewNub [~oftc-webi@ac230029.ppp.asahi-net.or.jp] has quit [Quit: Page closed]
20:17-!-Quatroking [~Quatrokin@ip226-139-211-87.adsl2.static.versatel.nl] has quit [Read error: Connection reset by peer]
20:20<Elyon>"Stations (0x04) are not yet fully implemented" <- well that's an understatement
20:25<@planetmaker>Elyon, it's not that much of an understatement: https://hg.openttdcoop.org/nml/files/5ad310ff3742a28eb10206a7d9a16e2dd089f49a/nml/actions/action2var_variables.py#L272
20:26<@planetmaker>most (or all?) variables for stations are there
20:26<@planetmaker>actually even line 246 following
20:27<@planetmaker>anyway... sleep time. good night :)
20:28<Eddi|zuHause>that's like saying "the house is not fully constructed yet", when you bought some shovels and ordered a truckload of concrete to fill in the foundation :p
20:38-!-Progman [~progman@p57A1BBA1.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
21:07<Elyon>pm, goodnight :)
21:08<Elyon>Eddi, :D
21:52-!-Flygon [~Flygon@147.18.214.218.sta.commander.net.au] has quit [Read error: Connection reset by peer]
21:57-!-Flygon [~Flygon@147.18.214.218.sta.commander.net.au] has joined #openttd
22:03-!-glx [~glx@000128ec.user.oftc.net] has quit [Quit: Bye]
22:40-!-Pereba [~UserNick@179.179.23.201] has quit [Ping timeout: 480 seconds]
22:45-!-gelignite [~gelignite@i528C3A79.versanet.de] has quit [Quit: http://bit.ly/nkczDT]
23:40-!-quorzom [~quorzom@cable-78-35-98-177.netcologne.de] has quit [Read error: Connection reset by peer]
23:47-!-smoke_fumus [~smoke_fum@188.35.176.90] has quit [Read error: Connection reset by peer]
---Logclosed Sun Jan 11 00:00:22 2015