Times are UTC Toggle Colours
00:00:07 <Ruudjah|energetic> :P 00:00:27 <benjamingoodger> good night, TrueBrain 00:02:25 <dihedral> Rubidium, it would only need 'syncing' if it changed from true to false or vice versa 00:02:32 <dihedral> not though if the password changes 00:03:42 <dihedral> i am trying to work on the move clients patch in a way that clients can join companies, and was wanting to avoid the server having to request a password 00:03:56 <dihedral> but the client doing that check and then sending the password in the same packet or not 00:04:49 <Rubidium> that'd require storing the network seed of the server too 00:05:28 <dihedral> you do, dont you? 00:05:35 <dihedral> how else does the client set a company password? 00:05:51 <dihedral> i hashes, and sends the hash to the server 00:06:10 <dihedral> does not ask the server for the unique_id and seed and then hash and send back to the server, right? 00:07:08 <Rubidium> the server only sends the unique ID when it's needed, i.e. when the client needs to enter a company password 00:07:22 <Rubidium> hmm 00:07:29 <Rubidium> oh... also in the welcome packet 00:07:43 <dihedral> when i am already in the game, and set a password, the client does not request that data again 00:08:01 <Rubidium> yup... it's stored at client side 00:08:19 * Rubidium is tired and hasn't looked at the network code for a while 00:08:20 <dihedral> thought i was going bonkers for a second :-P 00:08:52 <dihedral> now i am writing a move patch, where clients can be moved by the server, or clients can request the server to move them 00:09:34 <dihedral> if they want to be moved to a pw protected company, i was hoping for them to not have to query the server for that bit 00:09:44 *** Nite_Owl [~Nite_Owl@c-76-109-60-185.hsd1.fl.comcast.net] has quit [Quit: Read You Soon] 00:10:28 <dihedral> would it be reasonable to sync that one boolean flag, or would it be better practice to let the client request the move, and the server request the password if needed 00:12:40 <SmatZ> the latter :) 00:13:00 <dihedral> if the client knows of companies requiring a password or not, it's easier to 'cancel' the join 00:13:00 <Rubidium> SmatZ: rather not... that requires keeping state at the server 00:13:31 <dihedral> aye 00:14:12 <dihedral> you would have to keep, which company the client is trying to join, which company the client is in right now, and have a timeout for accepting the password 00:14:13 <SmatZ> Rubidium: then I didn't understand the question correctly, but the server already knows if there is a password for given company - or am I that wrong? 00:14:21 <Rubidium> SmatZ: yes 00:14:22 *** guru3 [~guru3@81-235-164-45-no21.tbcn.telia.com] has quit [Server closed connection] 00:14:41 *** guru3 [~guru3@81-235-164-45-no21.tbcn.telia.com] has joined #openttd 00:15:00 <dihedral> SmatZ: _network_company_info[index].use_password is a boolean flag 00:15:10 <dihedral> which is not a lot of data to also keep synced 00:15:24 <SmatZ> Rubidium: ah ok... I should go to bed, I am so tired today :-x 00:15:26 <SmatZ> good night 00:15:32 <dihedral> nice SmatZ 00:15:39 <dihedral> sweet dreams 00:15:40 * dihedral grins 00:17:52 <dihedral> haha! it's already being sent 00:18:01 <dihedral> probably just not kept up to date 00:18:05 <Rubidium> Ruudjah|energetic: I think the replace vehicle every week problem should be solved and not that new vehicles get a higher rating; just make it more expensive to buy-sell-buy-sell-buy-sell than using the vehicle for a while 00:18:24 <Rubidium> dihedral: after getting the lobby it's never updated 00:18:37 <Rubidium> so at "join" it's already out-of-sync 00:18:42 <dihedral> oh 00:18:43 <dihedral> ok 00:19:00 <dihedral> so i just need to update all clients with PACKET_SERVER_COMPANY_INFO 00:19:19 <dihedral> or is that a overkill 00:19:22 <Eddi|zuHause> Rubidium: how about "after a vehicle left the depot, it immediately loses 20% of its value"? 00:19:42 <Rubidium> Eddi|zuHause: that's the idea for a few months already 00:19:48 <Eddi|zuHause> (which is actually realistic, e.g. if you buy a car) 00:20:17 <Rubidium> but then... I reckon I've written it down before somewhere 00:22:32 <Eddi|zuHause> i'd like a more complex system of "new" and "used" vehicle pools 00:23:25 <Eddi|zuHause> where "new" vehicles represent the amount the factories could produce, and "used" vehicles represent a pool of previously owned vehicles (possibly by virtual companies that are not present on the map) 00:23:56 *** paul_ [~paul@host86-150-1-27.range86-150.btcentralplus.com] has joined #openttd 00:24:05 <Eddi|zuHause> the prices of "new" vehicles could then rise significantly, if the number of requests exceeds the production capacity 00:25:06 <Eddi|zuHause> and production capacity could be subject to similar modifiers as model reliability 00:26:07 <Eddi|zuHause> i.e. start out low with the prototypes. then rise to a higher value, where really popular models can reach high availability, and then drop towards the end of the model life time 00:27:26 <Eddi|zuHause> second market availability would start out at 0 during prototype phase, then slowly rise during the model life, and reach its peak before the end of the first prototype's vehicle life 00:28:27 <Eddi|zuHause> so even if vehicles are not available as "new" anymore, there would still be availability from the "used" market, with decreased vehicle life, but cheaper 00:28:54 <Ruudjah|energetic> sorry, was afk. Rubidium: awesome. I think so too. As I noted already in the topic, CBV goal games dont care about 75% value of new trains bought. Btw, it would make the company value bad 00:29:14 <Ruudjah|energetic> since every train brought makes the company value devaluate 25% of train value 00:29:19 <Ruudjah|energetic> *bought* 00:29:53 *** DephNet[Paul] [~paul@host86-150-1-27.range86-150.btcentralplus.com] has quit [Ping timeout: 480 seconds] 00:30:05 <Eddi|zuHause> imho, bank money should not count to company value 00:30:11 <Rubidium> but a trip would gain "income - running cost - 20 % of new vehicle value" 00:30:20 *** Dr_Jekyll is now known as wolle 00:31:16 <Eddi|zuHause> a two market model like my suggestion would even increase that 20% margin for people who use that tactics extensively 00:31:26 <Ruudjah|energetic> yes, but ncv is caluclated of train worth. having 100K, and spending this on trains now still gets u ncv of 100K. Then it would be different. 00:31:51 <Eddi|zuHause> the new price would grow insanely high, while the second market gets flooded with vehicles, so the selling value drops 00:32:07 *** Dred_furst [~Dred_furs@user-5af263fd.tcl122.dsl.pol.co.uk] has quit [Read error: Connection reset by peer] 00:32:39 *** rubyruy [~ruy@S0106000c6e57c851.vf.shawcable.net] has joined #openttd 00:33:01 *** Eddi|zuHause [~johekr@p54B74E11.dip.t-dialin.net] has quit [] 00:33:21 *** Eddi|zuHause [~johekr@p54B77D9F.dip.t-dialin.net] has joined #openttd 00:35:53 <Eddi|zuHause> money that is not spent has no value 00:36:42 <Ruudjah|energetic> i believe in ottd it does. 00:36:42 <Eddi|zuHause> company value should be calculated purely from the company's property (vehicles, stations, infrastructure) 00:36:55 <Eddi|zuHause> yes, and that is flawed 00:37:23 <Ruudjah|energetic> yes 00:37:38 <Ruudjah|energetic> that is why Kurt developed his own company value, NCV, Net Company Value 00:37:39 <Eddi|zuHause> especially during times where the company has bank loan 00:38:10 <Rubidium> but then buying unused vehicles can just artificially increase your company value 00:38:31 <Rubidium> or making many stations 00:38:47 *** Terkhen [~Terkhen@155.69.220.87.dynamic.jazztel.es] has quit [] 00:39:29 <Eddi|zuHause> if the game was properly balanced, the company would always run on bank loan 00:40:38 <Eddi|zuHause> part of the balance problem currently is, that net income grows linearly with number of vehicles 00:40:43 <Rubidium> then it'd be unplayable for Ruudjah|energetic's mother 00:40:47 <Eddi|zuHause> it should grow sublinearly 00:41:52 <Eddi|zuHause> there should be company management maintenance 00:42:13 <Eddi|zuHause> not just running costs of individual vehicles 00:43:12 <Eddi|zuHause> something that has little effect on companies with 10 vehicles, but huge effect on companies with 1000 vehicles 00:43:41 <Eddi|zuHause> and if you want to grow even further, you'll have to "outsource" part of your network 00:43:53 <Eddi|zuHause> that'll be a nice challenge for the coop people :p 00:45:55 <dihedral> Rubidium, if say the company name changes, how is that data transfered to all clients? 00:46:12 <Eddi|zuHause> i'd imagine something in O(n^2) in the amount of vehicles owned 00:47:15 <Eddi|zuHause> where you could also give different weights to vehicles 00:47:34 <Eddi|zuHause> e.g. 1 for train wagons, 2 for trucks, 5 for train engines, 10 for aircraft 00:48:06 <Eddi|zuHause> so 1 aircraft would cause the same management proplems as a train with 5 wagons 00:50:30 <Eddi|zuHause> a business model like this can also introduce "realistic" behaviour of closing down small branch lines 00:51:27 <Rubidium> dihedral: CMD_CHANGE_COMPANY_NAME (or something like that) 00:51:49 <dihedral> oh - so it's handled as a command in the queue 00:52:14 *** mortal [~mortal@0x573a3da2.odnqu1.static.dsl.tele.dk] has quit [Quit: Checking whether build environment is sane ... build environment is grinning and holding a spatula. Guess not.] 00:52:34 <dihedral> so i would either need to add a new packet to sync some company details or let the server keep the state... 00:52:37 <Rubidium> yup... as it isn't network specific 00:52:59 <dihedral> hmmmm 00:54:02 <dihedral> that would be a very small network packet if all it had to do was update a boolean flag 00:54:04 <dihedral> :-S 00:54:28 <dihedral> little amount of data - huge overhead :-P 00:56:21 <dihedral> sounds too yucky imo 00:56:45 <Rubidium> not syncing's also yucky 00:57:10 <dihedral> perhaps there is more data that needs syncing 00:57:24 <dihedral> and that could be combined 00:57:52 <dihedral> btw, while i think of it 00:57:58 <dihedral> console_cmds.cpp 00:58:08 <dihedral> in the ConCompanies 00:58:15 <dihedral> there is a beautiful line: /* protected */ StrEmpty(npi->password) ? "un" : ""); 00:58:37 <dihedral> why not use npi->use_password ? "un" : "" ); instead? 00:59:07 <Rubidium> as servers don't set the use_password bool 00:59:18 <dihedral> oh? 00:59:33 <dihedral> why not? 00:59:40 <dihedral> (just out of curiosity) 01:00:00 <Rubidium> cause it's unneeded maintaince of variables 01:00:27 <dihedral> they must set it! 01:00:34 <Rubidium> why? 01:00:39 <dihedral> else they could not send the details to the clients in the lobby 01:01:01 <Rubidium> technically use_password is for clients and password is for servers and warrants a base class with subclasses 01:01:11 <Rubidium> dihedral: every read the sending part? 01:01:32 <Rubidium> just search for use_password in e.g. network_server.cpp 01:01:47 <dihedral> yep its used in PACKET_SERVER_COMPANY_INFO 01:02:18 <dihedral> oh 01:02:47 <dihedral> never said a thing 01:07:21 *** rubyruy [~ruy@S0106000c6e57c851.vf.shawcable.net] has quit [Quit: Zzzz...] 01:08:21 *** rubyruy [~ruy@S0106000c6e57c851.vf.shawcable.net] has joined #openttd 01:08:26 <dihedral> well - i shall head to bed 01:08:38 <dihedral> thank you Rubidium for your help 01:18:40 *** stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has quit [Ping timeout: 480 seconds] 01:20:39 *** roboboy [3aad2910@webchat.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client] 01:22:12 *** Fuco [~dota.keys@ip-105.imafexbb.sk] has quit [Quit: Quit] 01:27:54 *** tokai [~tokai@p54B81116.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 01:29:27 *** tokai [~tokai@p54B83F44.dip0.t-ipconnect.de] has joined #openttd 01:29:30 *** mode/#openttd [+v tokai] by ChanServ 01:33:51 *** roboboy [3aad2910@webchat.mibbit.com] has joined #openttd 01:35:31 *** Brianetta [~brian@client-82-20-12-90.brhm.adsl.virgin.net] has quit [Quit: TschÃŒÃ] 02:27:29 *** elmex [~elmex@e180078222.adsl.alicedsl.de] has quit [Remote host closed the connection] 02:28:26 *** Ruudjah|energetic [~a@ip82-139-118-117.lijbrandt.net] has quit [Read error: Connection reset by peer] 02:30:24 *** thingwath [~thingwath@147.251.200.254] has quit [Read error: No route to host] 02:31:13 *** thingwath [~thingwath@morana.sks2.muni.cz] has joined #openttd 02:33:04 *** KritiK [~Maxim@78-106-158-82.broadband.corbina.ru] has quit [Quit: Leaving] 02:33:29 *** Ruudjah|energetic [~a@ip82-139-118-117.lijbrandt.net] has joined #openttd 02:39:04 *** roboboy [3aad2910@webchat.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client] 02:39:20 *** roboboy [3aad2910@webchat.mibbit.com] has joined #openttd 02:45:35 *** Ruudjah|energetic [~a@ip82-139-118-117.lijbrandt.net] has quit [Ping timeout: 480 seconds] 02:51:48 *** roboboy [3aad2910@webchat.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client] 02:56:10 *** Singaporekid [~notme@cm45.psi140.maxonline.com.sg] has joined #openttd 03:00:09 *** rubyruy [~ruy@S0106000c6e57c851.vf.shawcable.net] has quit [Ping timeout: 480 seconds] 03:07:13 *** glx [glx@bny93-6-82-245-156-124.fbx.proxad.net] has quit [Quit: bye] 03:09:25 *** roboboy [3aad2910@webchat.mibbit.com] has joined #openttd 03:12:35 *** tokai [~tokai@p54B83F44.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 03:13:06 *** roboboy [3aad2910@webchat.mibbit.com] has quit []