IRC logs for #openttd on OFTC at 2008-12-23
⏴ go to previous day
00:06:54 <svippy> <fjb> Nobody would use an invisible bridge. they would fear to fall off. << It helps for building behind it!
00:07:13 <svippy> You can apply the same logic to transparent buildings and trees!
00:07:44 <svippy> :( They are still there.
00:08:07 <fjb> At least in the nightly build you can make them invisible, not only transparent.
00:08:08 <svippy> Also, is it an issue with replacing two-way engines?
00:11:17 <fjb> What two-way engine issue?
00:14:26 *** svippery has joined #openttd
00:33:13 *** Eddi|zuHause has joined #openttd
01:00:15 <dihedral> what happened to _network_own_client_index
01:11:39 <dihedral> i am in console_cmds.cpp
01:12:58 <Rubidium> read the svn logs and it should be clear what happened to it
01:13:04 <Rubidium> and how you can solve your problem
01:13:22 <dihedral> i am at 14711 (working backwards :-P)
01:19:35 <dihedral> hehe - should have come up with that earlier :-S
01:20:33 <dihedral> i have changed src/lang/english.txt and get an odd output from make
01:20:34 <dihedral> [LANG] Generating table/strings.h
01:20:34 <dihedral> make -C /Users/nathanael/Development/openttd/objs/lang table/strings.h
01:20:34 <dihedral> [LANG] Generating table/strings.h
01:20:35 <dihedral> [SRC] DEP CHECK (all files)
01:20:36 <dihedral> make -C /Users/nathanael/Development/openttd/objs/lang table/strings.h
01:20:38 <dihedral> [LANG] Generating table/strings.h
01:20:42 <dihedral> [SRC] Compiling console_cmds.cpp
01:20:42 <dihedral> [SRC] Compiling date.cpp
01:21:18 <dihedral> and of course it continues with the compile after that
01:23:39 <Rubidium> that shows strgen outsmarting make
01:24:12 <Rubidium> strgen is asked to regenerate table/strings.h, but refuses to do so because english.txt hasn't changed enough to require a full recompile
01:25:05 *** sigmund_ has joined #openttd
01:25:45 <Rubidium> once during compiling of objs/lang/ and once during objs/debug (or objs/release)
01:32:31 *** SacroDS has joined #openttd
01:56:43 *** LightSol has joined #openttd
01:57:17 <LightSol> can someone help me out with one thing?
01:57:48 <dihedral> depends on what the one thing is
01:58:11 <LightSol> Explaining how i can send money to other players ingame
01:58:30 <LightSol> I noticed the feature, but cant find any explenation or tooltip where it is located
01:59:08 <LightSol> ah, that would explain it
01:59:14 <LightSol> its the only place i didnt look :p
02:01:23 <dihedral> the new version of move_clients patch just needs some cleaning up to do
02:01:37 <LightSol> And now i fail at finding the client menu
02:01:46 <dihedral> and then it's possible to join other companeis while one is in the game
02:02:06 <dihedral> LightSol, company list drop down - first item
02:02:12 <dihedral> search wiki.openttd.org
02:02:29 <LightSol> i am searching the wiki
02:03:05 <LightSol> Just failing at it :P
02:03:26 <dihedral> what did you search for?
02:04:06 <dihedral> well - i must go to bed
02:04:14 <dihedral> hint: search for "give money"
02:04:25 <dihedral> then select option number 5 (Multiplayer)
02:23:33 *** svippery has joined #openttd
02:48:47 *** ChanServ sets mode: +v tokai
02:58:01 *** svippery has joined #openttd
03:50:42 *** Sionide has joined #openttd
04:07:35 *** elmex_ is now known as elmex
04:19:38 *** GoneWacko has joined #openttd
05:20:04 <eQualizer> Um what. OpenTTD eats half of my processing power. And I'm using not less than a year old Macbook Pro.
05:21:04 <George> Belugas: House ID is not extended byte. At least action 3 does not think so
06:01:29 *** roboboy has joined #openttd
06:29:36 *** Alberth has joined #openttd
06:54:18 *** LightSol has joined #openttd
06:54:18 *** lobster has joined #openttd
06:54:18 *** ccfreak2k has joined #openttd
06:54:26 *** Twofish has joined #openttd
07:00:41 *** roboboy has joined #openttd
07:37:10 *** svippery has joined #openttd
07:52:51 *** roboboy has joined #openttd
08:15:14 *** svippery has joined #openttd
08:26:29 *** XeryusTC is now known as Xeryus|bnc
08:39:43 <CIA-1> OpenTTD: rubidium * r14719 /trunk/src/network/ (7 files in 2 dirs):
08:39:43 <CIA-1> OpenTTD: -Codechange: replace DEREF_CLIENT with an instance function and replace looping
08:39:43 <CIA-1> OpenTTD: socket structs with info structs when the loop is only interested in the info
08:39:43 <CIA-1> OpenTTD: structs (i.e. not derefing the info from sockets when one can loop info directly
08:39:43 <CIA-1> OpenTTD: and the socket isn't used)
08:51:13 *** svippery has joined #openttd
08:53:39 <dihedral> Rubidium, you have a high on nice commits atm :-)
08:59:27 <Rubidium> they're quite boring commits
09:01:20 <dihedral> may i ask for you personal opinion on something?
09:02:29 *** NukeBuster has joined #openttd
09:02:45 <dihedral> i would love to know what you think, could be improved, etc.
09:02:54 <CIA-1> OpenTTD: rubidium * r14720 /trunk/src/network/ (4 files): -Codechange: s/FOR_ALL_CLIENTS/FOR_ALL_CLIENT_SOCKETS/ as the latter describes the name more precisely.
09:02:54 <dihedral> it's not 100% finished, but close to
09:02:58 <Rubidium> isn't asking the question asking for my personal opinion on said question?
09:03:18 <dihedral> i was still pushing the file to my webspace
09:03:29 <dihedral> and it was more a question of if you have the time, and wanted to
09:04:13 <dihedral> it add's a 'join' button to the company window
09:04:21 <dihedral> will prompt for a password if needed
09:04:39 <dihedral> and then the client sends a request to the server to be moved to the new company
09:05:00 <dihedral> what i still want to do (appart from removing the debug messages) is adding 'new company' to the company list
09:05:23 <dihedral> then people can join as spectator and start a game without having to reconnect (same with joining passwords)
09:05:32 <dihedral> *joining passworded companeis
09:05:39 <Rubidium> fwiw: client index != client id, client ids are 32 bits
09:07:27 <dihedral> that is good to know :-)
09:07:40 <dihedral> then i need Send_uint32
09:09:18 <Rubidium> + /* Disable any buttons in any windows the client is now not supposed to get to, and do it fast. */
09:09:22 <Rubidium> + /* If this is not done fast enough, it can cause the client to be kicked or have an assert! */
09:09:26 <Rubidium> those aren't very hope giving comments
09:09:59 <Rubidium> +void NetworkClientSendMove(CompanyID company);
09:09:59 <Rubidium> +void NetworkClientSendMove(CompanyID company, const char *pass);
09:10:00 <dihedral> it's because otherwise the client can send a wrong company_id in the packets
09:10:06 <Rubidium> that could easily become
09:10:11 <Rubidium> +void NetworkClientSendMove(CompanyID company, const char *pass = "");
09:10:20 <dihedral> oh - that is possible? perfect
09:15:58 <petern> is that the version with a gui or just the background code to enable it?
09:16:37 <dihedral> just missing 'new company' in the company list
09:16:47 <dihedral> and i would like to split up the 'move' console command
09:17:06 <dihedral> and make 'move <client_id> [<company_id>]' server only
09:17:33 <dihedral> and make a 'join <company_id|spec|spectators>' a client side command
09:17:49 <dihedral> and perhaps a 'new_company' command
09:22:01 <dihedral> the thought of a 'invite' request to the server has also crossed my mind
09:22:14 <dihedral> where in the client list one could send an invite to another client
09:22:39 <dihedral> and without having to specify a password that client (if he/she accepts the invite) will be moved by the server
09:29:48 <Rubidium> should the client be asked whether he/she accepts to be moved by the server?
09:30:17 <Rubidium> that'd mean "slapping" a player by moving him/her to specs can't really be done
09:31:33 <dihedral> well - with the move command: it's only server side, and thus i thought the prio of an admin is higher
09:31:51 <dihedral> i.e. like a kick if one does not behave, this time the client is moved to spectators
09:32:17 <dihedral> just need to find a way to forbid a client to move himself
09:32:39 <Eddi|zuHause> change the company password ;)
09:32:40 <dihedral> the clent should only be asked to accept an invite
09:33:04 <dihedral> i.e. if another client invites him to another company, then the client should confirm
09:33:52 <dihedral> but it would mean the server must keep track of the invite data
09:37:01 <dihedral> the creating a new company would be more important than an invite feature if you ask me
09:39:06 <dihedral> you have any other comments, ideas? Rubidium, petern ?
09:39:42 <Eddi|zuHause> i don't really see the need for invites
09:39:56 <Eddi|zuHause> you could instead give the person a temporary password
09:40:36 <dihedral> that is nicer, too, then the server needs not keep track of an invite + handle a timeout of if no response comes back from the client
09:47:56 <CIA-1> OpenTTD: rubidium * r14721 /trunk/src/network/ (9 files in 2 dirs): -Codechange: s/NetworkTCPSocketHandler/NetworkClientSocket/ as it's (way) more descriptive what it's used for.
09:48:18 *** Zealotus has joined #openttd
09:58:15 <dihedral> [09:59] <Rubidium> they're quite boring commits <- structure is good and important, and cleaning up stuff is too
10:01:42 <petern> just going through and closing them
10:01:50 <petern> a lot of them are just running old bc instancs :p
10:01:52 <dihedral> sounds like an odd thing to happen
10:03:19 <petern> i work something out, leave it open for next time
10:03:28 <petern> next time ... i create a new one :o
10:08:58 <dihedral> depending on the time between now and 'next time' i prob could do the same
10:23:12 <dihedral> petern, start chewing chewing gum
10:23:30 <dihedral> that gets more blood to your head, thus more oxygen :-P
10:23:56 *** TrueBrain has joined #openttd
10:24:33 <Alberth> I open many screens when the computer is not fast enough... I start something, get annoyed it takes time, think of something I can do in the mean time, switch desktop, start the program, etc. :)
10:26:57 <TrueBrain> ah, yes that is what this nagging feeling on the side is
10:42:20 <CIA-1> OpenTTD: rubidium * r14722 /trunk/src/network/ (4 files): -Codechange: s/DEREF_CLIENT/GetNetworkClientSocket/
10:49:21 *** Vikthor has joined #openttd
10:51:50 <dihedral> company_info->use_password = p->Recv_bool();
10:51:54 <dihedral> why does that cause a bus error?
10:52:02 <dihedral> wait - missing something infront
10:52:06 <dihedral> NetworkCompanyInfo *company_info = GetLobbyCompanyInfo(company_id);
10:52:26 <Rubidium> probably because company_info = NULL
10:54:51 <dihedral> sending info too soon perhaps...?
10:55:22 <Yorick> isn't the lobby cleared when downloading the map?
10:56:49 <Yorick> looking at the glitches when you start map download...
10:56:52 <Rubidium> it's very unlikely that it crashes in clean trunk
10:57:55 <dihedral> it's a patch i am sitting on
10:59:36 <Yorick> are you sure the lobby window is open?
11:01:06 <dihedral> the lobby window definitely is not open
11:01:22 <Yorick> you can't get data from the lobby window when it's not open ;)
11:07:20 <CIA-1> OpenTTD: rubidium * r14723 /trunk/src/ (10 files in 3 dirs): -Codechange: shuffling some stuff around to reduce indirect #include dependencies.
11:11:43 *** Progman has joined #openttd
11:11:56 *** |Jeroen| has joined #openttd
11:18:01 <dihedral> Rubidium, what alternative to i now have to _network_company_info ?
11:19:42 <Rubidium> and why would you need the whole struct?
11:20:00 <dihedral> i want to get to use_password
11:21:13 <dihedral> i was syncing that field before, so that the client could prompt for the password when joining a company
11:23:27 <Rubidium> but why keep 280+ bytes per company for only storing whether the company is passworded or not?
11:24:06 <dihedral> rather that than querying the server each time :-P
11:24:40 <dihedral> the space is used in the struct anyway
11:24:46 <dihedral> why not use it properly then?
11:25:10 <Rubidium> huh? what space is used? when?
11:25:36 <dihedral> NetworkCompanyInfo has bool use_password, correct?
11:25:52 <dihedral> why only have access to that data from the lobby?
11:26:07 <dihedral> why not use it in the game too
11:26:17 <Rubidium> yes, but when is NetworkCompanyInfo actually allocated?
11:26:50 <dihedral> that could be a one off, after PACKET_CLIENT_ACK
11:27:08 <dihedral> at the end, update the client with the company info
11:27:26 <dihedral> or perhaps moving use_password to the parent struct would be an idea?
11:27:37 <dihedral> would that make more sense?
11:27:59 <dihedral> then it would be accessible in _network_company_states
11:28:29 <Yorick> why would it be needed to allocate 280+ bytes per company for stuff that is already stored somewhere else (except for your password)
11:29:36 <Rubidium> company states only contains info useful for the server
11:29:52 <Rubidium> and moving it to the parent struct doesn't help you a bit
11:31:46 <Rubidium> CompanyMask _network_passworded_company; ?
11:32:26 <Rubidium> of maybe even make that static and put it in network_client.cpp
11:34:11 <dihedral> but that would mean if there are more than 8 companies (some time not in the near future) you would have to change the typedef, make a new one, or store the details differently again
11:34:44 <Yorick> the typedef can be changed then ;)
11:35:01 <Rubidium> changing a typedef isn't that hard
11:35:17 <Rubidium> and increasing the companies beyond 15 isn't quite feasible
11:36:37 <dihedral> and then all CompanyMask's will need the update anyway i take it
11:43:19 <artur> I have problem with new graphics in openttd, i have TGV-Atlantique.grf in openttd directory, when i add this file in game, still i cant buy tgv, how to fix it?
11:43:43 <CIA-1> OpenTTD: rubidium * r14724 /trunk/src/network/ (core/tcp.h network_internal.h): -Codechange: move some NetworkClientSocket related function/definitions closer together.
11:48:11 <Progman> did you have add the newgrf in your newgrf list?
11:49:12 *** Dred_furst has joined #openttd
11:50:19 *** Ridayah has joined #openttd
11:50:46 <Progman> which year is your new game?
11:53:28 <OwenS> It is in your OpenTTD/data folder?
11:54:04 <artur> what should i build to buy TGV? only standard depot?
11:54:29 <OwenS> Electrified rail depot if electrified rail is enabled I'd expect?
11:55:15 <Progman> I build it with an eletric depot
11:55:52 <artur> hmmm i have any electric depot, only standard depot, how to enable eletric?
11:56:11 <CIA-1> OpenTTD: rubidium * r14725 /trunk/src/ (5 files in 2 dirs): -Change: make it clearer why (and that) MAX_CLIENTS isn't the amount of slots in the array, but one less as a dedicated server takes a slot too.
11:56:15 <OwenS> If you can build electrified rail from the rail menu, then it's enable
11:56:24 <Progman> artur: did you start a new game or load an old one?
11:56:38 <artur> i have started neo one and saved it
11:56:58 <Progman> before or after you added the newgrf to the newgrf list?
11:58:03 <artur> when i start new game the grfs are enabled
11:58:28 <TrueBrain> man hungry, man need food!
11:58:49 <OwenS> The NewGRF list is stored in the save file
12:00:44 <artur> Progman, can you show me screenshot of the electric depot?
12:01:10 <Progman> it looks basically the same as the non-electric depot
12:01:36 *** KillaloT has joined #openttd
12:02:36 <Progman> you must add the newgrf first and then begin a new game
12:02:45 <Progman> not the other way round
12:02:50 *** DephNet[Paul] has joined #openttd
12:07:12 *** ChanServ sets mode: +v tokai
12:08:10 <artur> any ideas? Now i have loaded these files in main menu before starting new game.
12:09:14 <Progman> not sure if 0.6.3 already got the "multiple newgrf sets" option
12:09:25 <Progman> try to load only the TGV newgrf
12:11:12 <artur> maybe update to new version helps
12:13:50 <Rubidium> 0.6.3 has no multiple newgrf sets
12:13:53 <artur> but i have the lastest stable version installed
12:14:32 <artur> Rubidium, ok, but when i laod only TGV grf i have not TGV
12:15:05 <Progman> you are sure you created a new game? do you see the normal trains again? did you hit the year 1989?
12:17:26 *** mortal` has joined #openttd
12:17:34 <artur> when i create new game in 1989 i habe normal default trains.
12:18:19 <Progman> use fast forward, maybe the train is introduced in the next months of 1989
12:21:47 <Progman> then maybe this newgrf isn't supported for this openttd version
12:24:07 <Progman> no, the newgrf works in 0.6.3
12:24:53 <artur> Progman, where have you downloaded it?
12:25:20 * Rubidium doesn't want any more Pressents :(
12:27:28 <CIA-1> OpenTTD: rubidium * r14726 /trunk/src/ (company_cmd.cpp network/network_client.cpp): -Fix (r14720): making new companies in network kinda failed...
12:28:15 <artur> Progman, i have the same file
12:30:19 <Progman> loaded the newgrf, start a new game with start year 1990, build a depot and then I see the TGV in the list
12:31:34 <artur> i followed your steps, but without effects
12:35:05 <Progman> you see the SH '30' and SH '40' in the depot too?
12:36:31 <artur> Onlu Manley-Morel Dash Floss SH/Hendry SH 125 and UU 37
12:37:08 <Progman> it looks like you have electric tracks activated and you need to build an electric depot
12:37:20 <Progman> with the engines SH '30', SH '40, ... in it
12:38:14 <Progman> hold the mouse button on the rail track menu item and select "electric raisl"
12:40:40 <artur> Progman, Thanks a lot ;)
12:55:26 *** mortal` is now known as mortal
13:05:25 *** TrueBrain has left #openttd
14:07:15 *** ChanServ sets mode: +v tokai
14:11:14 * Yorick needs something small and bite-size to code
14:15:25 * Rubidium also knows something
14:19:51 <Yorick> any you are not going to tell those because of other reasons?
14:20:57 <dihedral> Yorick, go outside and play!
14:21:45 <Yorick> it's 4 degrees outsie, and raining
14:22:03 <dihedral> what are you? a wuss?
14:27:23 <dihedral> Yorick, implement erlang as console language
14:27:44 <Gekz> implement brainfuck as console language
14:33:31 <OwenS> TCL would make an awesome console language :p
14:34:40 <dihedral> what do you wonder sometimes Yorick
14:34:59 <Yorick> yesterday I was an idiot, today I should go outside and play?
14:35:16 <OwenS> Only major gripe I have with TCL is no closures
14:36:06 <OwenS> dihedral, What about it? :p
14:38:38 <dihedral> shame - i was hoping you'd get excited and do some work for me :-D
14:39:32 <OwenS> I'd be more interested if it were Lua to be honest :p
14:43:53 <OwenS> Luas a lovely language, except for the lack of curly braces
14:50:10 <Eddi|zuHause> if you are into curls and braces, that makea you a pedophile.
14:50:13 <valhallasw> what's wrong with *not* having curly braces? :P
14:52:18 <Alberth> some people like to have curly braces so they can mess up their code formatting :P
14:52:38 <Yorick> it's smaller than "then .... end"
14:53:17 <valhallasw> it's larger than ':'
14:53:27 <OwenS> Alberth, Actually I like Python also :p
14:54:48 <Belugas> [09:22] <Yorick> it's 4 degrees outsie, and raining <-- I invite you in here. It's sunny, but it's -15
14:55:40 <Belugas> George, that's another problem. in fact, there are two problems, one I can fix. that action 3, nope, at least not at the moment
14:55:44 <Yorick> valhallasw: that's why I like python
14:55:50 <Belugas> nor in the near futur :S
14:56:18 <OwenS> Then again, no language is like x86 assembly :p
14:56:41 <Eddi|zuHause> we have no lovely snow :(
14:56:45 <OwenS> Nothing can get someone confused like movl 0(%eax, %ebx, 4), %ecx :p
14:59:49 * Belugas does not like Eddi|zuHause's lovely snow
14:59:56 <Yorick> how about print map(lambda x,f=lambda x,f:(x<=1) or (f(x-1,f)+f(x-2,f)): f(x,f),
15:01:01 <OwenS> The difference is the first one has valid reason - the second is soley contrived with simpler ways to write it :P
15:01:34 <Eddi|zuHause> how can functional programming not be a "valid reason"?
15:01:59 <OwenS> What isn't valid is having nested lambdas sharing the same parameter names :p
15:02:16 <DorpsGek> Sacro: ludde was last seen in #openttd 10 weeks, 2 days, 6 hours, 17 minutes, and 8 seconds ago: <ludde> ;)
15:02:39 <Yorick> OwnS: that's perfectly valid
15:03:53 <Alberth> OwenS: I once wrote a 2 page sed script to translate assembly language between different assemblers. I don't think it had a single complete word in it. It looked like an arbitrarily placed bunch of punctation
15:04:13 <Alberth> Yorick: would you write that in a production program?
15:04:36 <Yorick> if I need all primes < 1000, possible
15:04:58 <OwenS> Would you not be better off using nested NAMED functions, so people had a clue what you were doing? :p
15:05:03 *** stillunknown has joined #openttd
15:05:58 <Alberth> I would probably factor out the inner function to a seperate variable
15:06:14 *** svippery has joined #openttd
15:06:26 <Yorick> there's a mandelbrot oneliner too
15:07:16 <Alberth> well, I can write a large OpenTTD program in one line too, but that is not exactly production code
15:11:30 <OwenS> You can write an assembly oneliner as well, but it's not recomended. Assembly mandates comments :p
15:15:36 <Alberth> you can? most assemblers assume 1 instruction per line iirc
15:16:34 <OwenS> GAS allows you to use semicolon delimiters
15:17:00 <OwenS> Primarily for people using GCC's asm() blocks
15:23:53 <CIA-1> OpenTTD: rubidium * r14727 /trunk/src/ (network/network_server.cpp settings.cpp): -Codechange: replace some magic numbers with a constant.
15:23:56 *** ChanServ sets mode: +v tokai
15:38:49 *** svippery has joined #openttd
15:39:59 <OwenS> Wtf? Why are magnets attracted to my keyboard?!
15:40:26 <Rubidium> a proper keyboard would've that effect
15:40:52 <OwenS> Aah - just noticed it's the enter, space and numpad 0 keys
15:41:06 <OwenS> As in, the wide ones with extra parts underneath to make them not rock
15:41:48 <petern> believe it or not, there is metal in a keyboard...
15:41:57 <OwenS> Steel, iron or zinc? :p
15:43:27 <Rubidium> and are actually quite heavy
16:07:03 *** benjamingoodger has quit IRC
16:20:54 *** Dr_Jekyll has joined #openttd
16:21:23 *** Dr_Jekyll is now known as wolle
16:21:31 *** Dr_Jekyll has joined #openttd
16:21:38 *** svippery has joined #openttd
16:33:00 *** Belugas has joined #openttd
16:33:00 *** ChanServ sets mode: +o Belugas
16:33:12 <dihedral> i am having issues moving a non-dedicated server to another company
16:33:26 *** mortal` has joined #openttd
16:33:42 <Eddi|zuHause> i cannot reproduce your problem :p
16:35:07 <dihedral> it works nice on dedicated games :-)
16:35:11 <Eddi|zuHause> i wouldn't see anything in there anyway... network is way too low level for me
16:35:12 *** mortal is now known as Guest926
16:35:12 *** mortal` is now known as mortal
16:35:38 <dihedral> that i cannot move a non-dedicated company
16:36:05 <Yorick> aha, non-dedicated server, you mean?
16:36:41 <dihedral> the playas on non-dedicated
16:36:45 <Yorick> did you try to implement the case?
16:37:06 <dihedral> no - i was just playing around with it in my head
16:37:20 <Yorick> if (_network_server) donotsendmovepacketbutinstantlymoveselfpossiblyneedingpassword()
16:37:38 <petern> if (_yorick) disconnect()
16:41:08 <dihedral> Yorick, forget it - i aint giving you my stuff
16:41:25 <dihedral> and yes - i know how to update the server, it just is not updating correctly!
16:41:35 <dihedral> and i know i dont send the packet
16:43:23 <Belugas> so.. Yorick, next time dihedral complains about a bug, just reply "You should know"
16:43:45 <dihedral> i'd prefer him not replying :-D
16:43:54 <dihedral> it's never really helpful anyway
16:44:20 <Yorick> it isn't if you don't listen
16:48:39 *** Zealotus has joined #openttd
16:55:35 <Belugas> Yorick, place dihedral on your ignore list ;)
16:55:52 <Yorick> Belugas: occasionally he says something nice
16:56:06 <Yorick> and I hate only seeing half converstations
16:56:21 <dihedral> curiosity is a bad friend :-D
16:56:49 <svippery> Then we wouldn't have steam engines!
16:56:56 <svippery> And then what's the fun in OpenTTD?
16:57:06 <Yorick> there wouldn't be openttd!
16:57:53 <Yorick> no one would have bought openttd, even not owen
16:58:18 <svippery> No one would ask themselves "what is this?"
16:58:19 <dihedral> and people buy games out of boredom
16:58:45 <dihedral> at least not computer games
16:58:49 <svippery> In other words you are never bored, dihedral.
16:59:04 <Belugas> [11:56] <dihedral> curiosity is a bad friend :-D <--- lol... Look who is talking !!!
16:59:05 <dihedral> Yorick, i am old enough to say that as many years ago as you are old, i used to play games
16:59:21 <orudge> Yorick: well, I bought normal TTD
17:00:47 <orudge> obviously, OpenTTD is open source
17:01:02 <orudge> but if something like TTD were to be, say, re-released on Steam for £5 or so, then I imagine a good few people would buy it
17:01:30 <orudge> (obviously in a way that has it working on modern systems)
17:09:36 <svippy> O_O Why are my oil wells disappearing!?
17:10:17 <Yorick> well...they all disappear after 1975 or so
17:10:23 <Yorick> they can't increase production
17:10:30 <Yorick> but the oil rigs are still there ;)
17:10:36 <svippy> Damn oil crises of the 1970s!
17:10:56 <svippy> But they still drill in Alaska!
17:11:03 <svippy> It is unrealistic that they disappear.
17:11:08 <svippy> They should just appear elsewhere.
17:11:26 <Yorick> but they just can't increase production
17:11:44 <Yorick> and Belugas has something with realistic
17:12:34 <CIA-1> OpenTTD: rubidium * r14728 /trunk/src/network/network_gui.cpp:
17:12:34 <CIA-1> OpenTTD: -Fix [FS#2470]: don't select anything when opening the client list.
17:12:34 <CIA-1> OpenTTD: -Fix: don't show clients that are "only" in the lobby.
17:14:41 <Belugas> shut up svippy. You are just making the point of the expression "But it's unrealistic" even more evident. As soon as you (users) feel somehow disavantaged (?) by a feature of the game, you are yelling at the unrealistic god
17:15:32 <petern> the grid is unrealistic
17:15:37 <Belugas> if you really crave about realism, why not add a feature that would make it so the bridges wold take 2-3 years to be built?
17:15:44 <petern> the fact it's a game is unrealistic!
17:15:46 <Rubidium> multiple managers per company is unrealistic!
17:16:03 <svippy> I want a reason why the oil is decreasing.
17:16:05 <petern> Rubidium, er, no it's not :D
17:16:16 <svippy> Honestly, I don't care that much about realism.
17:16:31 <petern> 17:11 < svippy> It is unrealistic that they disappear.
17:16:37 <svippy> I realise I said that.
17:16:58 <Belugas> they are programmed to disappear to leave the way for the oil rigs
17:19:09 <Rubidium> petern: well... whatever you call the highest boss of a company then
17:22:59 <Yorick> svippy: because they are and it's not going to be changed because one could do that with a newgrf
17:25:59 <Belugas> ho.. why do they dissapear that way to leave place for oil rigs... welll.. Chris Sawyer programme thm like that. It makes sens ifyou see TTD as a dynamic game and not a static one.
17:26:42 <Belugas> furthermore, oil wells do leave the place to oil rigs in reality too... although not at the rate that is programmed in TTD
17:26:55 <Belugas> and as Yorick says, it will not change, unless agrf does so
17:27:13 <petern> it does it because that's the way it is
17:39:42 *** lewymati has joined #openttd
17:41:57 <Belugas> oh... late... should grab my lunch :S
18:02:49 <svippy> Is it possible to buy ownership of a road from a town?
18:03:25 <svippy> ;-; And they won't let me remove it.
18:03:56 <Eddi|zuHause> you need to enable "allow removal of town owned roads" in the advanced settings, and have a good rating
18:08:26 <Belugas> [13:03] <svippy> Is it possible to buy ownership of a road from a town? <--- incredible.. that would be so unrealistic...
18:13:25 <Eddi|zuHause> # Ja, ja, wunderbar. Tolle Rede Mann.
18:13:40 <Eddi|zuHause> # Hört' ich dich nicht mal sagen dich läßt jede ran?
18:14:07 <Eddi|zuHause> # Und jetzt schau dich an, wo bist du hingekommen.
18:14:39 <Eddi|zuHause> # Du sagst dir, sie ist WEG. Und hat mich mitgenommen.
18:22:36 *** mortal` has joined #openttd
18:23:40 *** mortal is now known as Guest936
18:23:41 *** mortal` is now known as mortal
18:31:05 <svippy> <@Belugas> [13:03] <svippy> Is it possible to buy ownership of a road from a town? <--- incredible.. that would be so unrealistic... << Good observation.
18:37:23 *** PhoenixII has joined #openttd
18:37:33 *** Phoenix_the_II has quit IRC
18:45:55 *** mortal is now known as Guest939
18:47:34 *** mortal is now known as Guest940
18:53:02 *** thingwath has joined #openttd
19:11:16 *** svippery has joined #openttd
19:28:37 *** Yorick_ has joined #openttd
19:31:39 <George> Belugas: May be new callbacks would be asier to do?
19:33:04 <Belugas> just that i'm not in the mood to even consider starting working on it. Nor hving the patience etc etc...
19:36:01 <George> Well, It is impotant to me to choose the right direction. What about a chance to allow more than 512 houses from different GRFs, having 256 houses per GRF file?
19:36:32 <Belugas> more than 512? impossible
19:36:48 <George> what causes this limitation?
19:37:04 <Rubidium> bits on the map array
19:37:14 <Rubidium> and wasting lots of them for allowing more houses
19:38:02 <Rubidium> and 128 houses (with recolours) should be quite enough I reckon
19:38:15 <George> Well, then the callbacks are the best solution.
19:38:30 <Belugas> plus, consider the fact that you have 512 in total, including the initial 110
19:39:32 <George> Rubidium: Unless you plan to have different special houses like hotels, petrol stations, car shops, post offices and so on, using at least 9 IDs per type :(
19:39:57 <Belugas> you know, you do not really ned that kind of scheme
19:40:25 <George> Belugas: I see. So, I have to wait for callbacks and plan houses to have them in the future
19:40:36 <Eddi|zuHause> can't those be industries instead?
19:41:35 <George> Belugas: When I have name and capacity callbacks - yes, I do not nead much. But without - what to do with names?
19:41:51 <Belugas> you could specify the display based on some variables, after all, it's nothing more than displays.. agreed, the ame can be callback'ed, as well as population
19:42:11 <Belugas> oh... welll.. it might be relatively trivial to do
19:42:19 <George> Eddi|zuHause: No, please, not like that. I plan to make banks as houses :)
19:43:05 <George> Cool :) <@Belugas> oh... welll.. it might be relatively trivial to do
19:44:01 <George> When, one more thing if possible. house var 41 is byte. Could it be done word or dword?
19:51:02 *** Phoenix_the_II has joined #openttd
19:52:03 <Belugas> don't have the slightest idea right now
19:52:23 <Belugas> you'd bette add it to the opened FS callback stuff you've done lately
19:54:52 *** Yorick_ is now known as yorick
20:01:20 <Belugas> George: answer is no. Once more, becasue of the bits of the map (var41 that is)
20:03:53 <George> Belugas: I supposed that answer. Well, that only means I have to anmation stage as information holder. I hoped not to use this solution, but I see no other
20:04:46 *** yorick is now known as Guest950
20:08:08 *** Dr_Jekyll has joined #openttd
20:08:42 <George> I hope providing animation, stoping it after the house is build and setting var 16 to 63 wouuld not be the CPU eater.
20:17:18 *** Brianetta has joined #openttd
20:30:30 <Belugas> why do you need to have var41 bigger then 256 then??
20:41:17 *** sigmund has joined #openttd
20:43:33 <OwenS> Is there any way to turn off train reversing at signals?
20:44:01 <OwenS> And I mean when sitting at reds for a while
20:44:06 <Belugas> playing with planes, maybe?
20:44:22 <OwenS> Planes have too little infrastructure :p
20:45:28 <Rubidium> ofcourse there's a way to stop reversing trains... but it's unlikely that you'll like it
20:46:01 <OwenS> Other than not using them :p
20:47:53 <Rubidium> messing with the source code and compiling yourself
20:48:57 <OwenS> In that case I'm gonna have to compose a "Trains never turn arround at red signals" patch
20:49:07 <OwenS> (Switchable, of course)
20:50:21 <CIA-1> OpenTTD: rubidium * r14729 /trunk/src/settings.cpp: -Fix: writing a single char to the config file caused reading outside a buffer.
20:52:39 <CIA-1> OpenTTD: rubidium * r14730 /trunk/src/network/ (9 files in 2 dirs):
20:52:39 <CIA-1> OpenTTD: -Codechange: remove the need for networkclientsockets and networkclientinfo structs to be in a contiguous piece of memory and put them in a pool.
20:52:39 <CIA-1> OpenTTD: -Note: 255 should really be enough for now... making it any more means network protocol bumps.
20:57:38 <yorick> it does not have to be all
20:57:52 *** stillunknown has joined #openttd
20:58:17 <CIA-1> OpenTTD: rubidium * r14731 /trunk/src/network/ (network.cpp network_udp.cpp): -Fix: don't initialise UDP multiple times without closing it.
21:00:27 <Eddi|zuHause> OwenS: this functionality is implemented for the new path signals, but not for the old block signals
21:01:58 <yorick> what's the max value for an int?
21:02:11 <SmatZ> yorick: depends on your architecture
21:03:49 *** George3 has joined #openttd
21:03:55 <CIA-1> OpenTTD: rubidium * r14732 /trunk/src/ (engine.cpp graph_gui.cpp settings.cpp town.h): -Codechange: replace some magic number with less magic constants and use the proper type for a few variables.
21:05:47 <OwenS> Eddi|zuHause, The problem I have is trains at block signals reversing into a backwards path signal and getting stuck!
21:05:51 <glx> SmatZ: isn't it 2**32-1 ?
21:06:04 <OwenS> glx, Is your integer signed or unsigned? :p
21:06:06 <Eddi|zuHause> OwenS: only use path signals...
21:06:26 <OwenS> Eddi|zuHause, not a solution, block signals have uses also
21:06:45 <Eddi|zuHause> unless you convert old savegames, i have not found any need to use block signals anymore
21:06:50 <DorpsGek> yorick: 9223372036854775808
21:06:59 <OwenS> Eddi|zuHause, In combination with pre signals?
21:07:08 *** svippery has joined #openttd
21:07:10 <OwenS> Pre signals still work better than path signals in many situations
21:07:23 <Eddi|zuHause> not in my experience
21:07:38 <petern> only for stupid things like load balancers
21:07:47 <OwenS> And pre signal bypass stations
21:09:55 *** Ruudjah|energetic has left #openttd
21:09:56 <petern> anything with 'openttdcoop' in it is not likely to be a valid used of signals ;P
21:10:11 <George3> Belugas: if I code view with animation, then I use it's data instead of age data. But if not and I specify house view according to the age and current date, than a view may suddenly change (because cur_year - age will change)
21:10:55 <petern> now, when we make signals follow reachable tracks only... mwhahahaha
21:11:34 <SmatZ> petern: how is your "programmable signals" patch going?
21:11:43 <OwenS> petern, that would just be evil
21:12:02 <OwenS> Unless you develop a give priority to traffic ahead signal
21:12:03 <petern> was i writing such a thing?
21:12:04 <yorick> they did evil stuff before ;)
21:12:13 <yorick> was he writing such a thing?
21:12:14 <SmatZ> petern: I thought so...
21:12:20 <petern> (i had waypoint restrictions going, not programmable signals)
21:12:49 <petern> maybe it did but i forgot about it? :p
21:13:28 <OwenS> I ought to start developing my programmable signals patch again...
21:13:46 <OwenS> Though I'd guess path signals means the signalling infrastructure is radically different?
21:13:51 <petern> yes, if only because it would avoid those ugly constructions you have there
21:15:24 <OwenS> petern: Thats unlikely :(
21:20:00 <fjb> Hm, that pre signal bypass station is not needed with path signals. There are simply no signals at the entrance of a platform.
21:20:20 <OwenS> fjb, the problem is then two trains can't take the same route
21:20:40 <OwenS> The bypass indicates that there are stations free ahead even when the train would normally make a route red
21:21:12 <OwenS> Let me put it this way - theres no other way to slam 503 trains through one station
21:24:15 <fjb> I still see no reason for that construction with path signals. You would not have any signal right at the entrance of the platforms. So two trains follow each other at the distance of the signals.
21:25:03 <OwenS> fjb: Multiple path signals cascaded doesn't work as free platform information doesn't cascade like it does with pre signals
21:27:11 <fjb> The trains follow each other. I see no reason to cascade signals. You will have to do that when you are using presignals.
21:27:46 <OwenS> Two trains can't reserve a route over the same tile with path signals - thus they can't follow each other like they do with PSB
21:29:14 <fjb> I don't see where the same tile would be reserved in your example above.
21:29:47 <OwenS> With PSB, the bypass track allows the signals to remain green even when a train is on that path
21:30:58 <fjb> A path gets only reserved to the next signal, not to the end of the line.
21:31:25 <Aali> this is a silly argument
21:31:37 <OwenS> Yes - but if you put multiple path signals in sequence, trains can still go down the route when there are no free platforms!
21:32:20 <Aali> presignal bypass is more efficient than anything you could do with PBS
21:32:51 <Eddi|zuHause> fjb: scenario: platform 8 and 11 are free, first train reserves path to platform 8, the second train tries to reserver path to 11, but cannot, until the first train has left the entrance area
21:33:14 <Eddi|zuHause> distance between entry signal and platform 8 is much higher than regular signal distance
21:33:15 <OwenS> If you cascade the signals, trains can now try to go to platform 7 - which is occupied
21:33:45 <Eddi|zuHause> there is a quite easy solution, though
21:33:51 <Eddi|zuHause> just have multiple paths
21:34:16 <Eddi|zuHause> if you triple track the station entrance, the size of the station does not even increase
21:34:26 <OwenS> Eddi|zuHause, you now end up with a bigger station than with pre signal bypass for the same quantity of entering trains
21:35:16 <Eddi|zuHause> i don't see how this can be significantly bigger
21:35:19 <OwenS> And those paths have to cross at some point
21:35:40 <Eddi|zuHause> no, why would they?
21:35:55 <OwenS> At the point when they turn to enter the platforms
21:36:08 <Eddi|zuHause> make the left entry the one with the lowest pathfinder penalty
21:36:21 <Eddi|zuHause> trains will reserve the left entry to the first free platform
21:36:39 <Eddi|zuHause> second train cannot reserve the left entry, so it tries the next one, to the second free platform
21:37:04 <OwenS> Then, when the first one is finished, another train tries to reserve the same entry and finds it blocked by a reservation of the second or third train
21:37:24 <Eddi|zuHause> third train can still reserve the third entry to the third free platform. meanwhile the first train will have reached its platform and one of the early platforms is likely to be freed also
21:37:54 <OwenS> PSB still has a higher entrance capacity however
21:38:30 <Eddi|zuHause> you might have slight inefficiencies when filling the station, and you can remove paths from the secondary entrance to the first few platforms
21:39:02 <OwenS> And things start getting pathologically large when you have three tracks entering the station
21:39:10 <Eddi|zuHause> so once a train takes the secondary path, it is guaranteed that a significant number of platforms are available for the fourth train
21:39:39 <Eddi|zuHause> why? you have now the equivalent of three tracks for your weird signal infrastructure
21:40:50 <OwenS> But the infrastructure track can be shared
21:41:14 <Belugas> boooo.. argument of an hypothetic situation!
21:41:52 <Belugas> not even in trunk, not even debugged, not even clean..
21:42:02 * Belugas applaudes a whole fucking lot
21:42:35 <Eddi|zuHause> i have no idea what you mean by "shared"
21:42:38 <OwenS> In any case, is there actually a good reason for trains to reverse at block signals?
21:42:42 *** svippery has joined #openttd
21:43:14 <Eddi|zuHause> yes, it was, during a time where all signals were two way
21:43:36 <Eddi|zuHause> so lockups could be automatically resolved
21:43:51 <OwenS> Really that logic should be removed from 1 way signals
21:44:17 <Eddi|zuHause> anyway, this has been discussed so many times... but nobody actually provided a patch to port the new path signal setting behaviour to the block signals
21:48:02 * Belugas searches the path to his bed in the snow
21:50:33 <Aali> the solution doesn't have to be "turn off all train reversing"
21:51:28 <Aali> another solution would be to make trains in PBS blocks look both ways for a path no matter which way they're pointing
21:52:50 <OwenS> Aali, it may just be easier to turn off train reversing at 1 way signals
21:53:40 <Aali> easier, sure, but is it the right solution?
22:00:47 <Darkvater> so, what did I miss? :)
22:01:17 <SmatZ> hard to say :) not much, compared to months you were gone :-)
22:01:42 <Darkvater> I had to finish up some things first before I could get back to openttd
22:01:50 *** George3 is now known as George
22:02:04 <Darkvater> now I am in a dilemma whether I should do ottd first or create a printable album
22:03:57 <Darkvater> digital pictures > album > print
22:05:56 <Rubidium> I reckon that'd take quite a bit of time to make
22:06:48 <fjb> I vote for doing ottd first.
22:07:12 <Darkvater> it's nothing compared to creating a DVD from childhood 8mm movies
22:07:22 *** roboboy has joined #openttd
22:08:04 <Darkvater> from when Darkvater was very very small :)
22:08:13 <OwenS> I gathered it was 8mm film
22:08:28 <Darkvater> why the questionmark then? ;)
22:08:35 <OwenS> Checking it was film :p
22:08:46 <OwenS> You didn't throw away the film did you? Cause doing so would be a waste of analogue quality
22:08:52 <OwenS> (Assuming the camera was good :P )
22:08:59 <Darkvater> no, I still have it
22:09:11 <Darkvater> hoping to do a full-resolution stop-scan someday
22:09:21 <Darkvater> and transfer the whole thing to blu-ray in full-HD
22:09:58 <OwenS> I'd go for 1080p, but my CPU just can't handle H.264 1080p
22:10:06 <OwenS> Well, it can. Sometimes.
22:10:43 <OwenS> But it's pointless me watching something in 1080p when it gets downscaled to 720p anyway to fit my monitor (width)
22:10:57 <Darkvater> I didn't know but 8mm has a full resolution of some 3000x2000 pixels
22:11:18 <OwenS> Just goes to show that IMAX has insane resolution with 75mm film :p
22:12:38 <OwenS> Ever seen the bulb for one of them things? Drop it and it explodes on you
22:13:58 <OwenS> The IMAX projector technicians have to wear body armour when handling them
22:17:09 * yorick wonders how rubidium got 15 companies
22:19:48 <planetmaker> Rubidium: is that really 256 clients per server?
22:20:30 <Rubidium> something like that yes
22:21:01 <planetmaker> I love you! What a nice christmas present! :)
22:22:22 <fjb> A platonical christmas present?
22:25:22 <Darkvater> ooh; what happened?
22:25:30 <Darkvater> we can connect 255 clients now instead of 16?
22:26:14 <Rubidium> oh yorick... you shouldn't try to join a server when you don't have the patch to join it
22:26:30 <dihedral> Rubidium, that is prb his bot
22:28:34 <yorick> that one would have successfully joined
22:29:48 <dihedral> Rubidium, quite some nice work you have done
22:37:20 <petern> doesn't Rubidium always good nice work?
22:39:49 <dihedral> petern, yes, but i am dont follow noai, newgrf, economy stuff as closely
22:40:38 <Eddi|zuHause> you people had too much to drink...
22:45:09 <Rubidium> really? I'm still thirsty
22:46:05 * planetmaker hands Rubidium a bottle of cool beer
22:46:21 <planetmaker> (we're not on a small island after all ;) )
22:47:24 <dihedral> bier auf wein, das ist fein
22:47:31 <dihedral> wein auf bier, das rat' ich dir
22:47:47 <Darkvater> no updates for 2 days and +-20 commits already
22:47:55 <Eddi|zuHause> i remember that phrase differently...
22:48:35 *** roboboy has joined #openttd
22:49:13 <dihedral> i am looking forward to tomorrows nightly :-D
22:51:14 *** svippery has joined #openttd
22:51:33 * fjb is still playing r14579-noai-cargodest. :-)
22:52:39 <planetmaker> fjb: I guess for SP these commits don't change much :)
22:53:44 <fjb> Yexo's AdmiralAI changed much.
22:58:36 <Eddi|zuHause> i have not tried any of the AIs yet
22:59:50 *** Nite_Owl has joined #openttd
22:59:56 <fjb> One of the AIs in my current game is as good as I am. I bought 50% shares of that company and its value has more than doubled since then.
23:00:43 <fjb> And the game started in 1931.
23:01:16 *** Tilly14 has joined #openttd
23:02:15 *** Progman has joined #openttd
23:03:36 <Eddi|zuHause> i still do not see any sense in the shares system
23:05:27 <fjb> I can get a lot of money without doing anything.
23:06:36 <fjb> Yes, but till then the other company works for me.
23:21:18 <svippy> I am doing terrible, right?
23:22:16 <Eddi|zuHause> but what exactly do you mean?
23:22:30 <svippy> I am thinking... my station structure.
23:23:11 <Eddi|zuHause> that might be true
23:24:03 <Eddi|zuHause> i'd try smoothing out the curves first
23:24:32 <Eddi|zuHause> i try to avoid 2x45° turns
23:24:44 <Eddi|zuHause> i try to have at least 3 diagonal sections
23:24:48 <fjb> Doesn't differ that much from my first game.
23:25:04 <svippy> Yes, Eddi|zuHause, I try that, but often there isn't room.
23:25:27 <Eddi|zuHause> but in several instances in your picture it is possible
23:26:09 <svippy> I see the solution by the train depot on the right.
23:27:19 <Eddi|zuHause> the track that goes under the bridge has a switch right behind the bridge
23:27:36 <Eddi|zuHause> and the track coming over the bridge also has a narrow curve
23:28:52 <Eddi|zuHause> terminal stations are hard to get efficient without path signals
23:29:36 <Eddi|zuHause> they are a quite new development, available in the nightlies
23:30:10 <Eddi|zuHause> did you enable the signal GUI?
23:30:55 <Eddi|zuHause> there are 6 signal types in there, on the left, the basic block signals, then 3 types of block presignals, and then 2 types of path signals
23:31:48 <Eddi|zuHause> yes, that stands for "path based signals"
23:32:00 <svippy> It all makes sense now.
23:36:46 *** mortal` has joined #openttd
23:36:54 *** svippery has joined #openttd
23:37:34 <svippery> Thank you, Eddi|zuHause, that really did improve the efficiency. I totally forgot how to use them.
23:38:27 <Eddi|zuHause> you can also set that you build path signals by default
23:38:49 <Eddi|zuHause> for most mortals, they behave better in every situation
23:40:34 <svippery> Any situation where regular signals would be an advantage?
23:41:14 <Eddi|zuHause> only for non-mortals :p
23:41:17 *** mortal is now known as Guest977
23:41:18 *** mortal` is now known as mortal
23:41:27 <Eddi|zuHause> or openttdcoop, as they call themselves :p
23:43:08 <fjb> That pre signal thing reminds me of Intel Netburst architecture...
23:43:40 <OwenS> You mean, Intel's 32 stage pipeline mistake?
23:44:32 <Eddi|zuHause> i have no idea what that is
23:45:14 <OwenS> Should probably have been called Pentium 4ail
23:46:00 <fjb> No, the goal was to have the highest clock speed. And it reacched that.
23:46:09 <OwenS> It's goal was to get to 10Ghz
23:46:31 <fjb> I don't think that was their true goal.
23:46:45 <OwenS> It was said, when the Netburst architecture was designed, it would be able to reach 10Ghz
23:46:52 <Eddi|zuHause> so, what does a presignal have to do with a pentium 4?
23:46:58 <fjb> But look at the structure size at the time Netburst was invented.
23:47:10 <OwenS> It didn't - because, unbeknownst to Intel at the time, once you shrink your silicon to 90nm, leakage current goes through the roof
23:48:31 <fjb> They tried to squeeze as may instructions as possible through one core. A better solution is to divide the load to more cores.
23:49:07 <fjb> Eddi|zuHause: Is you question answered now?
23:49:41 <OwenS> Multi cores - like stupidly long pipelines - follow the law of diminishing returns
23:49:58 <fjb> Multi cores rule as soon as you have different things to do at the same time.
23:50:09 <Rubidium> they should just use multiple cores to allow to round robin cheaply and then cool it passively
23:50:44 <OwenS> Once you've reached dual core, outside of specialist applications - video encoding, compiling, some scientific stuff - not much can use them
23:50:52 <Rubidium> and multicore seems to be the perfect solution for OSes that can't properly scale CPU usage of run-away applications
23:51:25 <OwenS> I'll never understand how Windows manages it...
23:52:01 <Rubidium> OwenS: but... most applications that don't use multiple cores don't need lots of CPU either (500 MHz is more than enough for most of them)
23:52:20 <OwenS> Rubidium, you mean like most 3D games?
23:53:08 <Eddi|zuHause> those already use "multiple" cores... one CPU and one GPU
23:53:48 <OwenS> A GTX280 contains 128 shader units. But, shader units are not like CPUs very much at all
23:54:19 <fjb> But what I really tried to say is that instead of squeezing 503 trains through one station it would be better to have the load divided to more stations, preferably all over the map.
23:54:28 <Eddi|zuHause> but the number of applications itself does not say anything... it should be weighted by user time
23:54:45 <OwenS> fjb, but that would be no fun! ;-)
23:55:00 <Eddi|zuHause> how many applications need more calculation time than the user needs to react to the application's output
23:55:00 *** NukeBuster has joined #openttd
23:55:45 <fjb> I see no fun in the usual "all things go to just one industry" scenario. That looks boring.
23:56:02 <OwenS> The fun in it is shoving everything through one industry
23:56:32 <Eddi|zuHause> oh... you are talking about THAT presignal thing
23:56:44 <Eddi|zuHause> why didn't you say that right from the beginning
23:57:13 <Eddi|zuHause> now i actually understand what you meant :p
23:58:00 <OwenS> Rubidium, ships are slow
23:58:18 <Rubidium> but a gazillion can load/unload at a single tile
23:58:19 <Eddi|zuHause> says the guy with the escher-like canal system :p
23:58:20 <fjb> Eddi|zuHause: You were talking about strange ottdcoop things. :-)
23:58:43 <Eddi|zuHause> fjb: well, yes, but that was too far out of context
23:58:57 <Eddi|zuHause> fjb: my mental focus is not on this chat, currently
23:59:24 <Rubidium> so if you can't place enough stations close enough, you can always let the ships transport the last small bit to the industry
continue to next day ⏵
