Log for #openttd on 22nd December 2008:
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 [] 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 [] has quit [Server closed connection]
00:14:41  *** guru3 [] 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_ [] 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] [] 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 [] has quit [Read error: Connection reset by peer]
00:32:39  *** rubyruy [] has joined #openttd
00:33:01  *** Eddi|zuHause [] has quit []
00:33:21  *** Eddi|zuHause [] 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 [] 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 [] 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 [] has quit [Quit: Zzzz...]
01:08:21  *** rubyruy [] 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 [] has quit [Ping timeout: 480 seconds]
01:20:39  *** roboboy [] has quit [Quit: ajax IRC Client]
01:22:12  *** Fuco [] has quit [Quit: Quit]
01:27:54  *** tokai [] has quit [Ping timeout: 480 seconds]
01:29:27  *** tokai [] has joined #openttd
01:29:30  *** mode/#openttd [+v tokai] by ChanServ
01:33:51  *** roboboy [] has joined #openttd
01:35:31  *** Brianetta [] has quit [Quit: TschÌß]
02:27:29  *** elmex [] has quit [Remote host closed the connection]
02:28:26  *** Ruudjah|energetic [] has quit [Read error: Connection reset by peer]
02:30:24  *** thingwath [~thingwath@] has quit [Read error: No route to host]
02:31:13  *** thingwath [] has joined #openttd
02:33:04  *** KritiK [] has quit [Quit: Leaving]
02:33:29  *** Ruudjah|energetic [] has joined #openttd
02:39:04  *** roboboy [] has quit [Quit: ajax IRC Client]
02:39:20  *** roboboy [] has joined #openttd
02:45:35  *** Ruudjah|energetic [] has quit [Ping timeout: 480 seconds]
02:51:48  *** roboboy [] has quit [Quit: ajax IRC Client]
02:56:10  *** Singaporekid [] has joined #openttd
03:00:09  *** rubyruy [] has quit [Ping timeout: 480 seconds]
03:07:13  *** glx [] has quit [Quit: bye]
03:09:25  *** roboboy [] has joined #openttd
03:12:35  *** tokai [] has quit [Ping timeout: 480 seconds]
03:13:06  *** roboboy [] has quit []

Powered by YARRSTE version: svn-trunk