IRC logs for #openttd on OFTC at 2011-01-19
⏴ go to previous day
00:14:47 *** George is now known as Guest746
01:33:29 <bb10> the license doesn't allow you (as a user) to decompile/reverse engineer etc whatever is on steam, but who in his right mind would reverse engineer something that is open source? xD
01:33:47 <bb10> also, there are several open source games on steam.
01:35:05 <bb10> Aquaria, Arx Fatalis and probably some others that I don't know about
01:36:04 <bb10> Penumbra Overture and Gish too
01:36:45 <SmatZ> does steam modify those games?
01:36:53 <SmatZ> also, opensource != GPL'd
01:37:04 <Yexo> arx fatalis is gpl, but only since 14 jan 2011
01:37:11 <bb10> steam does not compile those games
01:37:44 <SmatZ> there may be a problem, that if they modify the source, they also have to publish those modifications done
01:37:48 <Yexo> aquaria's source was released as gpl on june 3, 2010
01:38:01 <Yexo> while it was uploaded to steam at december 15, 2008
01:38:06 <Yexo> all dates according to wikipedia
01:38:06 <bb10> they get binaries and upload them.
01:38:21 <SmatZ> both games I played (portal and trackmania nations) looked modified
01:38:29 <SmatZ> because they were interacting with steam
01:39:03 <Yexo> bb10: even if you "just" distribute the binaries, you still have to comply to the licence
01:39:18 <bb10> the license is for users
01:39:24 <Yexo> in fact I don't think you're allowed to distribute the binaries without distributing the source also (or a written offer for the source)
01:39:32 <Yexo> no, the license is for everyone
01:40:04 <SmatZ> simply, the licence of "openttd distributed over steam" has to be GPL-compatible, which excludes "can not modify the code"
01:41:09 <Yexo> steam is only allowed to distribute the openttd binary if they either A) also distribute the source or B) provide a written offer for the source code
01:41:26 <bb10> Yexo: they don't get the source code
01:41:39 <bb10> they get binaries and upload them
01:42:01 <Yexo> they're not allowed to upload openttd binaries without also providing the source or a written offer for the source
01:42:12 <bb10> you can add the source code if you want in a separate folder
01:42:41 <Yexo> if someone (steam included) wants to distribute openttd, they have to comply to the GPL
01:42:42 <SmatZ> bb10: the primary problem is that if steam's EULA says "you can not modify anything downloaded via steam", it violates OpenTTD's license, and so it can't be distributed over steam
01:43:01 <Yexo> which means you can't put additional restrictions on it (like: "you're not allowed to modify / reverse engineere it")
01:43:10 <bb10> though, the real question is, will they allow this free game on steam
01:43:40 <Yexo> no, the question is will they modify their subscriber agreement for it (answer almost for certain: no)
01:45:29 <bb10> "without the prior consent, in writing, of Valve." <- they could put that on the store page
01:48:20 <Yexo> could be, but I'm not sure if that's legally a valid construction
01:49:11 <Yexo> you could argue they'd still put a restriction on it: "you're not allowed to modify it without our permission, which you get here" sounds like they could revoke that permission at any time
01:49:30 <SmatZ> well, at least here, if the license isn't in the czech language, it's void
01:49:45 <SmatZ> (so it uses some "default" license given by law)
01:50:01 <Yexo> how does that work for gpl software?
01:50:14 <Yexo> not in czech -> no valid licence -> no right to use the software?
01:50:20 <SmatZ> there is official czech translation of GPL somewhere
01:50:32 <SmatZ> but hardly anything is distributed with translated version of GPL
01:50:38 <Yexo> sure, but that translation is not delivered with the product
01:56:22 <bb10> "In addition to the game, Valve will also release the complete code base for Alien Swarm."
01:56:50 <bb10> They released an open source game themselves. :P
01:56:54 <SmatZ> bb10: under what license?
01:57:43 <SmatZ> well, the copyright owner can still provide closed-source binary for steam and GPL'd version for download
01:58:04 <SmatZ> so it will work with steam's license
01:58:46 <bb10> and that is not possible with Openttd?
01:59:22 <Yexo> no, because there are a lot of people who own part of the copyright, and we won't be able to find them all to ask for permission to distribute a closed-source binary via steam
01:59:56 <bb10> aren't all binaries closed source?
02:00:30 <Yexo> ok, change that to "to ask permission to distribute a non-gpl licensed binary via steam"
02:00:54 <bb10> a binary can be licensed under gpl?
02:01:12 <SmatZ> software is licensed under GPL
02:01:17 <Yexo> why not? you'll just have to also provide the source code
02:02:12 <bb10> the source code is already provided :P
02:02:41 <Yexo> the one distributing the binary has to provide the source too (or a written offer to provide the source)
02:03:37 <bb10> would a link to the source on the store page be good?
02:04:03 <Yexo> note however that providing the source isn't really the issue why openttd is not on steam
02:04:11 <Yexo> steams user agreement is a far bigger problem
02:04:32 <SmatZ> bb10: you, as the steam's subscriber, have agreed to NOT COPY and NOT MODIFY the software you downloaded via steam, which is NOT COMPATIBLE with OpenTTD's license, so OpenTTD CAN NOT be distributed via steam
02:04:58 <SmatZ> what you don't understand there?
02:05:16 <bb10> you forgot the end of the sentence
02:05:30 <bb10> "without the prior consent, in writing, of Valve." <- they could put that on the store page
02:05:51 <Yexo> that would imply that they have a right to revoke that consent, which they don't
02:05:59 <bb10> You can copy, modify etc this bla bla
02:06:46 <SmatZ> "without the prior consent, in writing, of Valve." <== unless it means you have to ask for a written permission :)
02:07:41 <Yexo> bb10: it's basically the same problem as all mobile phone app stores have with gpl products
02:07:45 <bb10> Not if the consent is already (in writing) on the store page.
02:07:58 <Yexo> just google for "app store gpl" or anything like it and you'll find plenty of explanations
02:13:16 <bb10> but they do not have the consent thing
02:13:28 <bb10> and they only allow you to download it on 5 devices
02:18:56 <Yexo> I remember last week someone posted a link with a comparison also of other phone stores, but I can't find it anymore
03:04:07 *** tokai|mdlx has joined #openttd
05:56:17 *** Eddi|zuHause has joined #openttd
06:11:33 *** roboboy has joined #openttd
07:04:16 *** DayDreamer has joined #openttd
07:04:21 *** Br33z4hSlut5 has joined #openttd
07:27:00 *** Cybertinus has joined #openttd
07:33:06 <Terkhen> I don't see the point anyways
07:33:21 <Terkhen> they get no benefit and neither do us
07:33:33 <Terkhen> as you can always add openttd to steam as an external game
07:38:22 *** lasershock has joined #openttd
07:41:52 <Rubidium> really... how hard is the steam subscribed agreement to read. Only "you may not .... create derivative works based on ... any software accessed via Steam without prior consent of Valve" tells me enough. If accessed via Steam you're not allowed to modify it, GPL says you must not be disallowed to modify it. Clashing licenses -> OpenTTD isn't getting on Steam
07:42:20 <Rubidium> and yes... you can change the license for Steam, but that isn't going to happen
07:50:22 <planetmaker> he... steam... is nothing else than hot water and air ;-)
08:17:44 <dihedral> a little switch somewhere to simply mute / unmute sound on that event would probably be useful - yet i am not sure how simple it could be
08:18:37 <Rubidium> dihedral: as easily as 4420
08:20:44 *** George is now known as Guest782
08:25:05 <CIA-2> OpenTTD: rubidium * r21847 /trunk/src/train_cmd.cpp: -Fix [FS#4423]: slowing down of trains was done by reducing the speed by 10%, but also when you're just 1% too fast, so limit the slowdown till the new maximum speed
08:42:30 <dihedral> is there nothing event like that could get executed when the window is minimized?
08:51:28 *** Progman has joined #openttd
08:57:07 <Eddi|zuHause> dihedral: such an event could easily be added, i'm sure
08:58:40 <Eddi|zuHause> <planetmaker> he... steam... is nothing else than hot water and air ;-) <-- well, you also need some crystalisation core, otherwise steam would be invisible
08:59:30 <planetmaker> you only need that for condensation. Steam is by definition the gas phase of water. No crystallization cores needed
09:00:14 <planetmaker> it might also be visible due to the different fractive index of the hat water vapour
09:00:39 <planetmaker> like where hot air is rising from a heater you see that, too
09:00:55 <Eddi|zuHause> yes, i know what you mean ;)
09:13:03 <dihedral> what if the air has the same temperature as the water?
09:13:11 *** Kurimus has joined #openttd
09:15:18 <planetmaker> it would not change a thing
09:15:36 <planetmaker> it'd still be steam ;-)
09:18:41 <dihedral> Rubidium, are those enough patches for you :-)
09:19:03 *** andythenorth has joined #openttd
09:38:13 <Eddi|zuHause> i still wonder how the opengfx people managed to make their maglev track look even more ugly than the original
09:38:28 <Eddi|zuHause> it's an almost impossible task...
09:40:12 *** tycoondemon has joined #openttd
09:42:33 *** andythenorth has joined #openttd
09:55:11 <Terkhen> heh, yet another power plant discussion
09:55:44 <Terkhen> and it's following the usual pattern :)
09:55:58 * andythenorth introduces some truly *horrible* clipping problems into FISH
09:56:31 <andythenorth> slightly bigger than the current biggest
09:59:15 * andythenorth works on BabyTypes
09:59:23 <andythenorth> but not yet on NewBabyTypes
10:00:56 <Terkhen> are you thinking on improvements to the original BabyTypes spec?
10:01:32 <andythenorth> there are possible improvements, but the implementation would be baroque
10:01:40 <andythenorth> might as well stick with the current spec
10:01:50 <andythenorth> it's the best available in the circumstances :P
10:02:17 <andythenorth> if we wanted to improve BabyTypes, it would be best to start from scratch
10:02:25 <andythenorth> some of the legacy details are unhelpful
10:03:11 <andythenorth> Terkhen: rv-wagons?
10:03:42 <Terkhen> hmm... yes, I should do some work on that
10:03:49 <andythenorth> did we make a repo?
10:04:00 <Terkhen> no, but I'm not sure a repo is needed for now
10:04:11 <Terkhen> we should start by unifying stuff between vehicle types
10:04:22 <andythenorth> did we finish the spec?
10:04:32 <Terkhen> I made a note to start with articulated part handling
10:04:55 <Terkhen> we decided what parts of the train spec we would need, but IIRC nothing was written
10:04:59 <andythenorth> I have an irc transcript, but no document
10:06:07 <Terkhen> I was bored, so it is a good moment to start looking at the Artic functions to see how they can be unified
10:06:42 <andythenorth> the baby just woke up
10:06:51 <andythenorth> I'll see if I can copy our transcript into a document today
10:15:01 *** HerzogDeXtEr has joined #openttd
10:23:30 <andythenorth> Terkhen: spec is not very advanced :P
10:24:03 <Terkhen> yes, we will need something more clear :)
10:26:03 <andythenorth> a table of cbs and varaction 2s?
10:26:10 <andythenorth> showing which are implemented and which are needed?
10:26:31 <Terkhen> that would be good, yes :)
10:26:43 <andythenorth> I can start on that
10:26:49 <andythenorth> I'll just make a text file
10:26:57 <andythenorth> unless you're happy editing html?
10:27:04 <andythenorth> I hate wiki formatting so I'm not doing it there :P
10:27:21 <Terkhen> IIRC we needed some kind of action0 flag, right?
10:27:25 <Terkhen> a text file is fine for now
10:27:35 <andythenorth> we did need a flag
10:27:45 <andythenorth> it was to allow some behaviour if set IIRC
10:27:56 <andythenorth> was it to explicitly allow attachment?
10:28:11 <andythenorth> it was to enable cb 1D
10:28:18 <Terkhen> well... the problem was the default behaviour
10:28:19 <andythenorth> which would be ignored if not enabled
10:28:28 <andythenorth> IIRC, the thinking was
10:28:33 <Terkhen> by default, road vehicles shouldn't attach or let any other vehicles attach to them
10:28:46 <andythenorth> then action 0 enables CB1D
10:28:57 <andythenorth> CB1D default return value is 'allow attach'
10:29:11 <andythenorth> unless player chooses to handle it explicitly
10:29:17 * andythenorth wonders if that's possible :o
10:29:33 <Terkhen> hmm? allowing the player to attach anything?
10:29:56 <Terkhen> I don't think it's desirable
10:30:02 <andythenorth> it would be very irritating to a newgrf author to have to explicitly handle 1D for every vehicle
10:30:10 <andythenorth> trains don't have this issue :(
10:30:22 <andythenorth> default=attachable makes sense for trains
10:30:25 <andythenorth> no legacy problems there
10:31:06 <andythenorth> let me write a spec
10:31:10 <andythenorth> it will make more sense
10:47:21 *** tycoondemon has joined #openttd
11:10:52 *** tycoondemon has joined #openttd
11:12:14 *** andythenorth has joined #openttd
11:23:09 <peter1138> hmm, how can i set the timeout for connect() ?
11:23:52 <andythenorth> planetmaker: oil pipelines would be better as a hack on roadtypes
11:23:56 <andythenorth> no signals needed
11:24:16 <andythenorth> weird two-way flow arrangement possible :P
11:26:25 <Eddi|zuHause> crazy idea: a "subway" roadtype where you can set vehicles travelling on it to not collide with vehicles not running on it
11:26:27 <peter1138> (everything i look up says "use nonblocking i/o" which isn't really the same thing)
11:27:22 <Eddi|zuHause> (collide as in get blocked by)
11:28:15 <peter1138> ((okay, apparently you have to check yourself))
11:29:01 <Eddi|zuHause> (imagine "subway" as in "underground tram". same non-blockyness could be used for overhead-monorail)
11:30:05 *** tycoondemon has joined #openttd
11:35:13 <andythenorth> only collide with vehicles of same roadtype?
11:42:58 <SpComb> peter1138: what connect()?
11:43:18 <SpComb> peter1138: the connect() syscall doesn't have a timeout, you need to do a non-blocking connect() and then select() on it with your timeout
11:43:37 <SpComb> peter1138: after that you can go back to blocking I/O
11:44:15 <peter1138> well, not quite that simple
11:44:33 <peter1138> because that assumes you're doing nothing else in that time period :)
11:44:59 <peter1138> i have just set up a timer and which closes the connection
11:47:04 *** Eggman891 has joined #openttd
11:55:18 <SpComb> well, that assumes that you're using threads..
11:55:32 <SpComb> event loops have their own timeout mechanisms
12:11:03 *** Eddi|zuHause2 has joined #openttd
12:54:53 *** andythenorth has joined #openttd
13:17:22 *** Adambean has joined #openttd
13:24:54 *** DayDreamer has joined #openttd
13:38:33 *** JOHN-SHEPARD has joined #openttd
13:45:13 *** TrueBrain has joined #openttd
13:48:25 <dihedral> i want a public ipv6 address too :-P
13:54:41 <dihedral> i said i want a public ip not a proxy :-)
14:02:57 *** supermop has joined #openttd
14:11:01 *** z-MaTRiX_nonidentified has quit IRC
14:12:42 *** z-MaTRiX has joined #openttd
14:48:20 *** KenjiE20 has joined #openttd
15:11:19 *** Br33z4hSlut5 has joined #openttd
15:35:19 *** ZirconiumX has joined #openttd
15:35:42 <ZirconiumX> #periodfive returns
15:58:14 *** DayDreamer has joined #openttd
16:06:07 *** tycoondemon has joined #openttd
16:15:16 *** Eddi|zuHause2 is now known as Eddi|zuHause
16:15:25 <Eddi|zuHause> we really don't need to know when your period comes...
16:18:17 <ZirconiumX> It's a joke referring to Prof_Frink's comment yesterday
16:19:11 <planetmaker> yeah, his comments usually are quite on-topic
16:19:23 <planetmaker> just as yours :-P
16:22:20 <CIA-2> OpenTTD: rubidium * r21848 /trunk/src/ (cargopacket.cpp cargopacket.h): -Codechange: unification of comment style for cargopacket.*
16:25:13 <CIA-2> OpenTTD: rubidium * r21849 /trunk/src/ (cargopacket.cpp cargopacket.h): -Codechange: move merging/splitting of cargopackets into a helper function (fonsinchen)
16:27:28 <Eddi|zuHause> go on there. you're on the right track. :p
16:28:33 <Rubidium> you mean break cargodist patchability even more?
16:28:59 <Eddi|zuHause> yes. up to the point where there's nothing left to break :p
16:30:21 <CIA-2> OpenTTD: rubidium * r21850 /trunk/src/network/ (network.cpp network.h network_client.cpp network_client.h): -Codechange: move password hashing to a more general location (dihedral)
16:30:49 <Rubidium> Eddi|zuHause: nah, too much things need to be fixed/tested for that to happen
16:30:58 <Rubidium> like loads of coding style
16:31:38 <Rubidium> and documentation stuff
16:32:37 <CIA-2> OpenTTD: rubidium * r21851 /trunk/src/network/ (network.cpp network_client.cpp network_client.h): -Codechange: rename NetworkClientSetPassword to NetworkClientSetCompanyPassword (dihedral)
16:33:14 <Rubidium> got some 34K of diffdiff with coding style hints/changes/things that aren't clear
16:35:24 <CIA-2> OpenTTD: rubidium * r21852 /trunk/src/network/ (network.cpp network.h network_client.cpp): -Codechange: generalise GenerateCompanyPasswordHash (dihedral)
16:36:55 *** andythenorth has joined #openttd
16:37:19 <CIA-2> OpenTTD: rubidium * r21853 /trunk/src/network/ (5 files): -Codechange: HashCurrentCompanyPassword is only used by servers, so move it to network_server.* (dihedral)
16:42:23 <Rubidium> dihedral: 05 fails to compile without 06
16:53:49 <dihedral> oh :-( i am sorry about that
16:54:14 <dihedral> 05 should have worked, i thought, as 06 was merely the implementation in comsole_cmds
16:54:37 <Rubidium> but in 05 you change the signature of a function used in console_cmds.cpp
16:55:57 <dihedral> and thanks for the commits :-)
16:56:48 <dihedral> anything i can do for beta5? :-P
16:57:10 <Rubidium> fix any of the bugs at bugs.openttd.org?
17:01:02 <CIA-2> OpenTTD: rubidium * r21854 /trunk/src/ (9 files in 2 dirs): -Codechange: refactor the password setting methods to make it possible to change the password of other companies (on the server)
17:02:13 <CIA-2> OpenTTD: rubidium * r21855 /trunk/src/console_cmds.cpp: -Feature [FS#4368]: [Network] Console command to change the password of other companies for servers (dihedral)
17:03:20 *** Prof_Frink has joined #openttd
17:06:28 *** nicfer1 has joined #openttd
17:11:15 <CIA-2> OpenTTD: michi_cc * r21856 /trunk/ (findversion.sh projects/determineversion.vbs): -Fix (r21840): Don't fail tag detection on hg repositories that use mercurial queues. Add some safety against tags and branches with spaces as well.
17:11:16 <CIA-2> OpenTTD: michi_cc * r21857 /trunk/ (findversion.sh projects/determineversion.vbs): -Add: Revision detection for hgsubversion repositories.
17:13:16 * planetmaker wonders whether it now seems quite opportune to install hgsubversion locally ;-)
17:16:18 <Terkhen> can you do anything with mercurial over a subversion repository?
17:19:01 <planetmaker> I'll have to find out :-)
17:20:24 *** |Jeroen| has joined #openttd
17:23:19 <Terkhen> thanks for the links :)
17:23:32 *** andythenorth has joined #openttd
17:23:32 <planetmaker> well, had them open just at the moment :-)
17:28:42 <Terkhen> for me the only advantage seems to be easier and faster committing
17:28:52 <Terkhen> and that can lead to mistakes
17:30:04 <planetmaker> one other might be that you can pull the svn tags and build them (now) with the proper version info / string. Possibly
17:30:16 <andythenorth> what a lot of bits are free for water tiles :o
17:30:22 <andythenorth> how interesting...
17:30:41 <planetmaker> shooo shooo! back to road types you goooo ;-)
17:31:10 <planetmaker> (I know, very bad rhyme ;-) )
17:31:34 <andythenorth> was wondering if watertypes would be a better way to do pipelines
17:32:08 <andythenorth> was thinking about vehicle behaviour, not about liquids per se ;)
17:32:33 <planetmaker> vehicle: small | medium | big oil blob
17:32:46 <planetmaker> crash behaviour: oil spill
17:32:55 <planetmaker> so it needs also new disasters... ;-)
17:37:11 *** Progman has joined #openttd
17:39:01 *** frosch123 has joined #openttd
17:56:09 *** DanMacK has joined #openttd
17:58:16 <Rubidium> hmm, you must be very high if I can see you wave ;)
18:00:26 <Eddi|zuHause> stupid cat. this is MY chair.
18:01:03 <ZirconiumX> ...while Eddi|zuHause curses his cat.
18:01:39 <Terkhen> from his point of view it is probably his chair
18:02:35 <ZirconiumX> get another chair, with casters on - so you can push the cat out of the rooom
18:02:50 <Rubidium> Terkhen: no, it's his/her Throne
18:03:06 <Eddi|zuHause> from her point of view, it's probably a flat area that's slightly more elevated and slightly more soft than the others. both of which are benefiting factors for using it.
18:03:55 <andythenorth> cats are just cussed
18:03:58 <ZirconiumX> Cats need a hill to survey the area - we already have one - it's called our legs
18:04:02 <andythenorth> she's doing it to beat you
18:04:31 <Terkhen> cats just like to take whatever they think you might need
18:04:56 *** |Jeroen| has joined #openttd
18:05:22 <Eddi|zuHause> yeah. typically the space directly in front of your feet.
18:05:44 <Eddi|zuHause> or your sitting/sleeping places
18:05:50 <andythenorth> power lines / pipelines :P
18:05:58 * andythenorth proposed unitised cargo packet transport
18:06:16 <andythenorth> e.g. routes that have shift n units p tiles per second
18:06:28 <andythenorth> and don't need vehicles
18:06:36 <Terkhen> as long as your cats don't learn to steal your laundry... mine did
18:07:05 <Rubidium> you taught it wrong... the cat shall do your laundry
18:07:47 <Terkhen> I don't think that's even remotely possible :P
18:07:47 <ZirconiumX> I once saw a cat that did a poo inside (strike one
18:08:04 <planetmaker> I fear it'd lead to "the cat oversees you doing her laundry", Rubidium ;-)
18:09:10 <Eddi|zuHause> oh. cats love to oversee stuff.
18:09:28 <andythenorth> open pipeline tycoon!
18:09:40 <Eddi|zuHause> and every step you do, like put up new furniture, gets thoroughly inspected
18:10:35 <andythenorth> open pipeline, powerline, ski-lift, ropeway, cable car, travelator and conveyor belt tycoon!
18:11:27 <andythenorth> I am 35% serious :P
18:12:00 <ZirconiumX> andythenorth: nope OPPSLRCCTCBT
18:12:03 <Rubidium> "open too long didn't read"
18:12:16 <Rubidium> "open too long don't remember"
18:12:35 <Rubidium> like the digits of pi; too long, don't remember
18:13:03 <Eddi|zuHause> 3,1415926535898tldr?
18:13:09 <andythenorth> is there any map space for a new transportation type?
18:13:41 <Terkhen> are you planning a vehicleless transportation type?
18:13:46 <planetmaker> it needs a new tile type and could be done, I guess
18:13:48 <Eddi|zuHause> andythenorth: i think there are unused tile types, but the trouble starts when crossing with existing types
18:14:06 <andythenorth> I think it actually might need vehicles (for player and/or implementation sanity)
18:14:10 <ZirconiumX> open absolutely nothing tycoon OANT
18:14:13 <andythenorth> but all vehicles on a line are connected together
18:14:17 <planetmaker> powerlines are known to never cross streets and rails.
18:14:18 <andythenorth> and they have to have the same orders
18:14:18 <Eddi|zuHause> or bridges/tunnels, which should reuse the existing tiles
18:14:37 <andythenorth> and they all hold 1t
18:15:13 <Rubidium> 1t of electrons sounds like quite a lot
18:15:45 <planetmaker> sounds like a significant fraction of all atoms in the universe ;-)
18:15:59 <andythenorth> 1 quantum packet
18:16:03 <DanMacK> Possibly carry megawatts instead?
18:16:11 <andythenorth> each vehicle is a quantum packet :P
18:16:32 <planetmaker> look at it and it decays...
18:16:34 <andythenorth> if you entangle two of them, then check the cargo amount on one of them, the other instantly unloads :P
18:16:38 <planetmaker> and you never know where it is...
18:16:45 <andythenorth> no you do, but not quite
18:16:53 <andythenorth> and the cat dies :P
18:16:56 <ZirconiumX> Invisible cargo - 24tonnes of something
18:16:58 <planetmaker> and if you know where it is, you don't know how fast and where it travels... it's a total mess ;-)
18:17:13 * andythenorth is worried now about the cat?
18:18:32 *** Phoenix_the_II has quit IRC
18:18:38 *** Phoenix_the_II has joined #openttd
18:18:40 <Rubidium> oh, only roughly 10^33 electrons
18:19:13 <planetmaker> if you take the square of it, it's probably larger than the number of atoms in the universe ;-)
18:19:35 <planetmaker> (or my memory is faulty)
18:19:53 <andythenorth> yeah but is the cat ok?
18:19:58 <andythenorth> someone measure the cat :P
18:20:36 <Rubidium> planetmaker: wolfram says 10^80
18:20:37 <planetmaker> did you ever try that on one? It might be hard ;-)
18:20:53 <Eddi|zuHause> Rubidium: but only a small amount of electrons in the hull are actually free
18:20:55 <planetmaker> well, then be it 10^80. I recalled 10^52 ;-)
18:21:19 <Eddi|zuHause> it's not even 30 orders of magnitude... who cares :p
18:21:47 * andythenorth wonders if this idea might actually be possible :P
18:22:31 <Eddi|zuHause> a separate pipe/power/otherwise continuous transport type?
18:22:49 <planetmaker> @calc (13*10**9 * 10**16)**3
18:22:49 <DorpsGek> planetmaker: 2196999999999999946875349976678663849588536635279061293249460890373123263692800
18:22:56 <planetmaker> hm... not a handy number :-P
18:22:59 <andythenorth> that could also support things like bucket ways
18:23:09 <nicfer1> hmmm, maps bigger than 1024x1024 are unjoinable for my internet connection
18:23:21 <andythenorth> I can think of some problems :O
18:24:19 <andythenorth> for continuous transport, simply using vehicles seems to take care of actually moving the cargo
18:24:32 <andythenorth> but they'd need to all take the same orders
18:24:41 <andythenorth> and it's a non-intuitive way to add capacity
18:24:42 <planetmaker> 10**52 is too low. ^ above number gives 10**78 - and the average density of the universe is higher than the inter-galactic gas which is 1 atom / m**3
18:24:49 <andythenorth> and removing them to destroy the route would be odd
18:24:56 <andythenorth> they'd all have to go to depot :P
18:25:09 <__ln__> Inter-Galactic Tycoon Deluxe
18:26:34 <Eddi|zuHause> damn... i don't have this song...
18:26:39 <andythenorth> limiting the route would be quite easy: make it impossible to build junctions
18:27:17 <andythenorth> but how many stations are possible is an interesting question
18:28:07 *** fonsinchen has joined #openttd
18:30:24 <fonsinchen> looks indeed funny.
18:42:17 <CIA-2> OpenTTD: terkhen * r21858 /trunk/src/ (articulated_vehicles.cpp train.h vehicle.cpp vehicle_cmd.cpp): -Codechange: Give more similar names to ArticulatedPart functions.
18:43:10 <CIA-2> OpenTTD: terkhen * r21859 /trunk/src/ (ground_vehicle.hpp train.h): -Codechange: Move train subtype flags to GroundVehicle.
18:44:25 <CIA-2> OpenTTD: terkhen * r21860 /trunk/src/ (8 files in 2 dirs): -Codechange: Rename road vehicle subtype functions to match the train names.
18:45:28 <CIA-2> OpenTTD: translators * r21861 /trunk/src/lang/ (japanese.txt spanish.txt ukrainian.txt):
18:45:28 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
18:45:28 <CIA-2> OpenTTD: japanese - 92 changes by kokubunzi
18:45:28 <CIA-2> OpenTTD: spanish - 52 changes by Terkhen
18:45:28 <CIA-2> OpenTTD: ukrainian - 2 changes by Fixer
18:57:19 *** Alberth has joined #openttd
18:57:19 *** ChanServ sets mode: +o Alberth
19:12:20 *** supermop has joined #openttd
19:17:28 <dihedral> vcs.openttd.org <- 504 Gateway Time-out
19:18:55 *** andythenorth has joined #openttd
19:19:01 <andythenorth> is it done yet :P
19:19:24 * andythenorth starts filing annual tax return
19:19:30 <Eddi|zuHause> the food was delicious, yes.
19:20:04 <andythenorth> I'm still worried about the cat
19:22:52 <Eddi|zuHause> there's more where that came from :p
19:24:41 <Hirundo> fonsinchen: I noticed something (bug?) in cargodist
19:25:09 <Hirundo> When multiple vehicles are loading, the loading indicator jumps to 100% instantly
19:25:16 <jonty-comp> I set up a 1.0.5 server on a development server at work
19:25:38 <jonty-comp> but the external firewall doesn't let it through
19:26:07 <jonty-comp> for some reason tunneling localhost:2979 to remote localhost:3979 works in ubuntu on my laptop, but not in windows
19:27:01 <jonty-comp> as in doing ssh jonty@dev1.ext.blah -L 3979:localhost:3979 works fine when I do openttd -n localhost
19:27:08 <jonty-comp> but doesn't when I do it through putty
19:28:48 <fonsinchen> Hirundo: That's expected, the vehicle will still take the usual time to load the cargo
19:29:03 <fonsinchen> The 100% indicate that all the cargo has been reserved for that vehicle
19:30:10 <Hirundo> Isn't it more useful to show the actual cargo count instead of the reserved amount?
19:32:31 <fonsinchen> If I'd show the actual amount then someone would complain that the cargo disappears from the station before the vehicle loads it.
19:34:07 <fonsinchen> The reservations work differently in cargodist. If cargo is reserved for a vehicle it's actually removed from the station and stored in a temporary cache at the vehicle
19:34:14 <planetmaker> Why is loading changed to default loading behaviour?
19:34:19 <planetmaker> where it also gradually loads?
19:34:35 <fonsinchen> This saves a lot of CPU time as we don't have to recheck all the packets in each loading cycle
19:34:50 <Hirundo> So there are three lists: station, vehicle and a temporary cache in-between?
19:35:22 <planetmaker> wouldn't it make sense to just add a 'reserved' indicator to the packets at the station?
19:35:27 <fonsinchen> Also it's much more accurate like this as the planned/sent numbers are immediately updated when moving the packets to the cache
19:35:44 <fonsinchen> Then I'd still have to loop over them every turn
19:35:51 <planetmaker> how does that deal with a skip-order command?
19:35:54 <Hirundo> But stuff also has to work when CD is disabled, right?
19:36:16 <fonsinchen> It moves the packets in the reservation cache back if the vehicle leaves the station
19:36:24 <planetmaker> also it 'feels' buggy to basically make the loading indicators deprieved of their function
19:36:35 <fonsinchen> Everything works the same except for the loading indicators
19:36:46 <planetmaker> well. But they're rendered un-functional
19:37:08 <planetmaker> which many people will (IMHO correctly) complain about
19:37:10 <fonsinchen> I can change that. You'll have to live with cargo disappearing before being loaded then, though.
19:37:39 <planetmaker> and how is it handled, if I send the train away before it is completely loaded?
19:37:47 <fonsinchen> The packets are moved back
19:38:07 <planetmaker> so it has an impact on station rating as well
19:38:22 <planetmaker> as the rating with cargodist will be 'better' as cargo is moved earlier
19:38:28 <planetmaker> thus the average cargo waiting is lower
19:39:10 <fonsinchen> yes, that's probably the case.
19:39:32 <planetmaker> and what is the actual performance impact of this change?
19:39:43 <planetmaker> in PU on test games?
19:40:20 <Hirundo> Can't you store the reserved cargo somewhere in the station, so it still counted there?
19:40:40 <fonsinchen> I don't know anymore. But that was one of the changes with most impact on performance.
19:40:47 <Alberth> or continue searching where you stopped the last time?
19:41:22 <Alberth> may be less trivial than it sounds :)
19:41:32 <fonsinchen> Hirundo: Then I'd have to keep a map of vehicle to cargo and that would need to be looked up and iterated over.
19:41:35 <fonsinchen> I have tried that.
19:42:18 <Alberth> you can move the cargo, and just add some count of 'cached elsewhere' at the station
19:42:26 <fonsinchen> Don't forget that the question if a packet is to be loaded into some vehicle may be answered a different way in subsequent loading turns
19:42:28 <planetmaker> fonsinchen: what about just adding the vehID to the station cargo packets?
19:42:36 <fonsinchen> depending on the sent/planned numbers
19:43:04 <fonsinchen> One of the worst performance problems was the constant looping over lots of cargo packets
19:43:18 <Alberth> you currently also dont consider changing destinations between loading turns
19:44:42 <fonsinchen> Alberth: This can only happen if you manually change the orders. I assume that this will happen sufficiently rarely.
19:45:44 <Hirundo> Even if that does happen, you can always redo the reservations if it's really needed
19:46:47 <fonsinchen> I cannot guarantee that the cargo really arrives at the place where it wants to go. You could as well skip an order while the vehicle is already on its way. So I don't consider manual changes at all.
19:47:01 * Zuu seriously question the need for OTTDAU to be adapted to allow selection of 64-bit OpenTTD. It's not like OpenTTD will be limited by the 2 GB mem limit?
19:48:06 <Zuu> So until OTTDAU become available in 64 bit, I don't really see the point of doing any re-working to support 64bit downloads.
19:48:07 <Hirundo> Stations already have a list of loading vehicles, perhaps it's possible to maintain a list of reservation lists in the same way
19:48:27 <fonsinchen> I can extend the loading indicators to show two numbers in case something is reserved for the vehicle
19:48:28 <Hirundo> So the cargo is still accessible by the station and can be counted there
19:49:14 <Hirundo> tbh, as player Joe I don't care about reservations and whatnot
19:49:48 <Hirundo> as a side note, player Joe doesn't understand all advanced settings either
19:51:39 <planetmaker> Player Joe rather understands very few settings only ;-)
19:52:29 <fonsinchen> btw, Station::days_since_pickup is not updated until the cargo is really loaded
19:52:47 <fonsinchen> so the argument about station ratings is probably wrong.
19:53:29 <planetmaker> station rating depends on the amount waiting, too
19:53:38 <planetmaker> and that was my argument
19:54:15 <planetmaker> not any pickup time :-)
19:54:17 <fonsinchen> With cargodist you have more cargo waiting at most stations most of the time
19:54:32 <fonsinchen> so I think we can accept it to be a little forgiving there.
19:55:03 <planetmaker> yes, probably. I'm rather worried about the perceived GUI bug with the wrong loading indicators.
19:56:18 <planetmaker> Personally I quite like to see them change as they give me an indication on how busy the station is, whether I need more / less trains
19:56:18 <fonsinchen> As I said I can just show both numbers. Joe average won't have that many reservations anyway.
19:56:50 <planetmaker> another interface, numbers will be confusing. Just make them work with cargodist the same way :-)
19:56:51 <Hirundo> That'd be a misfeature IMO
19:57:25 <planetmaker> I mean... don't you move the cargo into the train the same way, be it from the station or cache?
19:57:36 <planetmaker> So... can't then the train load state be used the same way?
19:58:17 <fonsinchen> Of course I can show the "real" loading number, if you want that.
19:58:29 <planetmaker> that's what it does now. So yes, of course
19:58:38 <fonsinchen> But that means the loading indicator is not in sync with the station GUI anymore
19:58:56 <planetmaker> it's a loading indicator for the train. Not the station
19:59:12 <fonsinchen> Well, then... I'll do it like that.
20:00:01 <Hirundo> Is it possible to combine the station itself and the reservation lists into one list in the station GUI, to show the 'good' number there also?
20:00:40 <planetmaker> gui_cargo = station_cargo + temp_cargo_cache?
20:01:17 <fonsinchen> I don't want to search all the reservation lists when assembling the source-via-destination view in the station gui
20:01:35 <fonsinchen> It would be horribly complicated.
20:04:23 <CIA-2> OpenTTD: terkhen * r21862 /trunk/src/ (5 files in 2 dirs): -Codechange: Unify subtype handling between road vehicles and trains.
20:05:08 * DanMacK has tried Cargodist, but never can transport the passengers for instance
20:05:23 <Eddi|zuHause> DanMacK: there's a passenger reduction patch
20:05:27 <Hirundo> fonsinchen: Mind if I post some 'average Joe observations' to the forum topic?
20:05:47 <DanMacK> or they want to go to some out of the way village services by buses...
20:06:36 <Eddi|zuHause> fonsinchen: what if you show the "about to load" cargo in a different list?
20:06:49 <ar3k> somethings wrong with 21861 build
20:06:59 <Eddi|zuHause> fonsinchen: although i don't really see what's the problem
20:07:39 <fonsinchen> Eddi|zuHause: where should I show that? In the station GUI somewhere?
20:08:05 <ar3k> 300 tons of coal in 30t wagon
20:09:02 * ABCRic wonders off to compile before that issue is fixed
20:09:18 <fonsinchen> DanMacK: Passengers will try to go to all reachable destinations, the amounts depend on the sizes of the villages and towns and on the distances between them.
20:09:36 <fonsinchen> The amounts don't depend on the quality of your service.
20:10:29 <Wolf01> WTF? vehicles loading 158% and 163% o_o
20:11:11 <Eddi|zuHause> fonsinchen: maybe it needs some feedback? cargo that is routed through congested links reduce the generation of new cargo for their destination?
20:13:20 <fonsinchen> Eddi|zuHause: I have avoided that on purpose as cargodist should give you the extra challenge to get the cargo where it wants to go.
20:13:20 <Wolf01> 141 passengers in a 50 passengers coach :o
20:13:51 <Wolf01> looks like the Milano-Bologna route
20:14:28 <Eddi|zuHause> Wolf01: that sounds perfectly realistic :p
20:14:59 <Eddi|zuHause> maybe Rubidium made som mistaks merging fonsinchens code?
20:15:39 <Wolf01> my steel trains don't think so :P
20:15:53 <Wolf01> they can barely move :o
20:17:53 * DanMacK may have to play with a recent build to try again
20:20:30 <fonsinchen> 21857 doesn't have the problem
20:20:58 <fonsinchen> Or at least I don't see it
20:24:28 <Wolf01> maybe it's related to grfs
20:24:36 <Wolf01> or with the cargo multiplier
20:26:03 * DanMacK has played with 20 on occasion
20:26:18 <dihedral> exactly, not recently ;-)
20:30:42 <Wolf01> with 5x I need to use 2-3 engines to move a 10 tiles long steel train
20:31:14 <ar3k> i dont use anything like that
20:31:26 <ar3k> on some trains i get over 300 ton of coal
20:31:37 *** z-MaTRiX has joined #openttd
20:31:54 <Wolf01> 1750 tonnes of steel on a train
20:32:14 *** z-MaTRiX is now known as Guest850
20:34:04 <ar3k> where i can find this cargo multiplier ?
20:34:06 <fonsinchen> Eddi|zuHause: btw, the generation of cargo is actually reduced if a lot of cargo is waiting. With the "external ratings" the ratings of the source stations drop then and reduce cargo generation.
20:34:56 <Eddi|zuHause> fonsinchen: i haven't tried in a while. i was just making theoretical thoughts
20:35:57 <fonsinchen> It works quite well. I have done quite a few experiments with different ways to reduce the cargo piling and like this it's quite nice.
20:36:35 <Wolf01> ar3k: vehicles->trains->weight multiplier
20:39:07 <Rubidium> fonsinchen: is happens in r21857 as well
20:39:57 <fonsinchen> Interesting ... not with cargodist though.
20:40:08 <ABCRic> cargo loading - 0%, 48%, 58%, 238%
20:40:41 <CIA-2> OpenTTD: rubidium * r21863 /trunk/src/cargopacket.cpp: -Fix (r21849): load the amount that should be loaded instead of the amount that should not be loaded
20:42:08 <Rubidium> fonsinchen: probably because you completely ditched that function
20:44:17 *** Biolunar has joined #openttd
20:45:42 <fonsinchen> Well, that function was probably not very well tested ... :/
20:54:07 <dihedral> i may not laugh - i had a bad patch too :-P
21:07:06 <fonsinchen> The loading indicators show the "real" amount now.
21:31:39 *** ChanServ sets mode: +v tokai
21:41:10 *** andythenorth has joined #openttd
21:59:08 *** andythenorth has left #openttd
22:03:27 <Pulec> btw is there a list of recommended settings?
22:03:37 <Pulec> i mean i always turn on realistic train physics
22:03:53 <Pulec> and i mainly mean generating map
22:04:00 <Pulec> the default seems just too much cities and industry
22:04:12 <planetmaker> yes. it's recommended to use those which give a map which you like
22:04:18 <Pulec> on a bigger mapper with less players many are being closed, but thats not the case
22:04:52 <Pulec> i think its better to build less train routes and organize them properly
22:04:59 <Pulec> over time it gets supper complex
22:05:07 <Pulec> and i dont really like goal servers
22:06:15 <planetmaker> Pulec: new industries will also open again, so don't bother with them closing.
22:06:25 <planetmaker> those who you service well, won't close.
22:06:43 <planetmaker> (unless you play with newgrfs, then it might happen, depending upon them and their parameters)
22:07:15 <Pulec> but that was only on huges maps, like 2kx1k and two players
22:07:37 <Pulec> but i could use some recommended list
22:07:38 <planetmaker> just play around with the map settings. I use terragenesis, low towns, mountains and high variability
22:07:59 <planetmaker> But... I need to go to bed, too, so good night here, too :-)
22:08:10 <Pulec> good nood night european man
continue to next day ⏵
