htsserver-devel Mailing List for Holsham Traders Server
Status: Abandoned
Brought to you by:
uh1763
You can subscribe to this list here.
1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(15) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2000 |
Jan
(27) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2001 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Uwe H. <uh...@he...> - 2001-02-11 16:22:45
|
Hi folks. Yesterday I released version 0.5.9 of the Holsham Traders server. Changes include: * We use autoconf 2.49c and the latest CVS automake now. * htsserver now requires Glib 1.3.2 or better. * Rewrite of the networking code, the logging code, configfile support, the string parsing routine and much more. * We use htsprotocol 0.4.6 now. There were several changes in the protocol. See docs/PROTOCOL for details. * login_timeout and autosave_delay can now be turned off. * Removed the 'defaultgame' option and the commandline options --gamename and --creategame. * Added the commandline options --configfile, --logfile, --datadir and --savegamesdir. * Lots of documentation updates. Added the manpage htsserver.conf(5). * More verbosive and more descriptive error reports. * Removed some arbitrary limits, e.g. the length of the logging-messages is not limited anymore. * Removed the commandline options --daemonize and --stderr-device. You cannot log to stderr anymore. htsserver always runs as daemon, now. * Removed savegame support. This will be re-implemented. Savegame files will either be ASCII files or XML files. * Added configure options --with-configfile=FILE, --with-logfile=FILE, --with-datadir=DIR and --with-savegamesdir=DIR to make the game more relocatable. * htsserver is FHS compliant, now. * Fixed several format string vulnerabilities. * Lots and lots of internal improvements and of course the usual bugfixes. Get htsserver it from: http://download.sourceforge.net/htsserver/htsserver-0.5.9.tar.gz Get nhtsclient 0.5.9 from http://nhtsclient.sourceforge.net. This is a ncurses Holsham Traders client which you can use to actually play the game. Have fun. Uwe. -- Uwe Hermann <uh...@he...> http://www.hermann-uwe.de/ ----------------------------------- :wq |
From: Uwe H. <uh...@bi...> - 2000-10-06 22:21:24
|
Hi everyone. I nearly forgot to announce the release of htsserver 0.5.8 on this mailing list :-) This is the first release that is (at least in parts) playable. NEWS: ----- * Removed the config-options max_connections and max_players. Holsham Traders will feature unlimited number of players. * Every player now gets two different transporters in the beginning. * More verbosive logging. * You now have the possibility to buy and sell goods from/to a town into any of your transporters which are in that town. * htsserver now uses htsprotocol 0.4.5. * A player can now have transporters and drive them from one town to another. * Wrote some initial town-handling code. * At the beginning of the game every town gets a (randomly chosen) number of goods with random prices and amounts. * Lots of internal improvements and increased readability of the code. * Several bugfixes. * htsserver now requires GLib. Lots of functions have been replaced by Glib-equivalents which are more secure and more portable. * Upgraded to autoconf 2.49a. * Should compile on HP/UX now. * Documentation updates. Read the ChangeLog for details. Go htsserver it from: http://download.sourceforge.net/htsserver/htsserver-0.5.8.tar.gz Get nhtsclient 0.5.1 from http://nhtsclient.sourceforge.net. This is a ncurses Holsham Traders client which you can use to play the game. Have fun. Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/ -------------------------------- :wq |
From: Uwe H. <uh...@bi...> - 2000-03-21 20:52:00
|
Hi everyone. I finally managed to make another htsserver-release. I hope to have some more time for Holsham Traders in future, at least more than I did the last few weeks... New stuff in this release includes: * Added the command-line option --creategame * 'reconfig' doesn't override command-line options anymore * heavily updated the PROTOCOL * Added a Quickstart-section in the README * Portability fixes * Added the configure option --enable-debug * goodnames are read from a data-file now * implemented, among others, a 'init'-command which is sent to each client each time it logs in * bugfixes, cleanups and documentation updates, as always I also released a first version of the ncurses-client nhtsclient. You can already play around with some things... Get it from http://nhtsclient.sourceforge.net/ Get htsserver from http://htsserver.sourceforge.net/ Happy hacking. Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
From: Uwe H. <uh...@bi...> - 2000-02-08 00:00:21
|
Hi everyone. I have added a new mailing-list called htsserver-cvs. Every cvs 'commit' I make, will be automatically sent to this list, so you can use it to be notified whenever there are any changes to the code. You can subscribe at http://lists.sourceforge.net/mailman/listinfo/htsserver-cvs And I put some new screenshots of the ncurses and GTK+ clients on the Holsham Traders homepage at http://htsserver.sourceforge.net. Happy hacking. Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
From: Uwe H. <uh...@bi...> - 2000-02-04 11:58:26
|
Hi everyone. htsserver 0.5.6 is released. I did this mainly because 0.5.5 had a serious bug, which produced hundreds MB of logfiles, until your harddrive was full... As ghtsclient 0.2 is now released (the GTK+ client) people might start playing around with Holsham Traders, and I wanted to prevent this bug from occuring, which would fill your HD with logfiles... Everyone is encouraged to upgrade to 0.5.6. Get it from http://htsserver.suorceforge.net/ Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
From: Uwe H. <uh...@bi...> - 2000-01-22 22:37:47
|
On Sat, Jan 22, 2000 at 06:32:57PM +0100, Sven M. Hallberg wrote: > > How about this: > > First, yes, x and y coordinates for cities sound reasonable. ACK. First, we'd probably just have x/y coordinates, from which we calculate the time a transporter needs from one town to another. This will suffice to allow travelling between towns. Later on we can add a more complicated system... Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
From: Sven M. H. <pe...@so...> - 2000-01-22 19:02:13
|
On Sat, Jan 22, 2000 at 12:18:55AM +0100, Daniel Reutter wrote: > On Fri, Jan 14, 2000 at 12:30:16AM +0100, Piotr Esden-Tempski wrote: > > How to travel? (map, streats, storage format) > > I'd say, we store the Longitude and Altitude of the towns. After some > mathematics we should be able to calculate the route. Perhaps, with some > more mathematics, we would be able to store (dangerous) Areas on the > world by some vector calculation. For a more individual map we could > also save the map into an picture format, killing two birds with one > stone: graphical interfaces can draw the map easily and we can form the > landscape just by using different colours - which would be an easy > editing. So we only got to store the towns x- and y-coordinates and > that's all folks. Draw a line from town A to town B, look which colours > are beneath this line, calculate speed, possible hazards, etc. The only > problem would be how to explain, why the carriers dumbly fly into the > pirate's nest every time instead of shipping around... ;o) How about this: First, yes, x and y coordinates for cities sound reasonable. Then, I'd say for now we don't do any hazard/obstruction stuff so we don't use a map for now. Let's just assume the freighters fly high enough to not care about any such stuff. I'd want to have a decent system of routing the freighters if we implement such things and that will probably take up a lot of work. As far as I'm concerned, push that until later. Of course, if anyone volunteers to come up with a good solution. Fine. But I'd rather have a black map with only the cities marked than a colorful one with my freighters running into all kinds of harzards. :) Bye, Sven -- Sven M. Hallberg <pe...@gm...> PGP key available at http://www.sh-home.de/~sol [ KeyID........: 0x0F520CF9 ] [ Fingerprint..: 56 61 00 18 14 B4 01 01 06 90 D0 29 96 BD 58 6F ] return 0; |
From: Sven M. H. <pe...@so...> - 2000-01-22 15:11:41
|
On Fri, Jan 21, 2000 at 01:51:04AM +0100, Uwe Hermann wrote: > On Thu, Jan 20, 2000 at 11:22:56PM +0100, Sven M. Hallberg wrote: > > Are we talking about good_spec's?? Then it's clear, an array will suffice for > > that job. But we'll still need lists for the goods a given trader posesses. > > Not necessarily. We could store them in arrays, too. But that would be inefficient because at any time there will be loads of goods of which a given player owns an amount of zero. > > What's the advantage of having the option to "sell any amount at any time to > > an unknown entity (the base economy) at a certain price dictated by that > > entity" over having a number of AI traders possibly permanently residing in > > the town which will _be_ the base economy and of course accept stuff at a > > certain price. And by the way: I think it's not even necessary to prohibit a > > situation where a trader can't get rid of his goods because nobody wants them. > > That sort of thing happens all the time in the real world actually. > > Sure. But it's not very good for the gameplay. Of course not, I'm not saying it's going to happen often. I don't believe it will. I just don't think that it should be forbidden. People will know what they have to do in order to prevent such a situation. > > Me or you? ;-) > > Both :-) Let's write the CONTENTS first, and then distribute the work... Good idea. I'll be happy if you do the contents. Bye, Sven -- Sven M. Hallberg <pe...@gm...> PGP key available at http://www.sh-home.de/~sol [ KeyID........: 0x0F520CF9 ] [ Fingerprint..: 56 61 00 18 14 B4 01 01 06 90 D0 29 96 BD 58 6F ] return 0; |
From: Daniel R. <br...@bi...> - 2000-01-21 23:25:46
|
On Fri, Jan 14, 2000 at 12:30:16AM +0100, Piotr Esden-Tempski wrote: > How to travel? (map, streats, storage format) I'd say, we store the Longitude and Altitude of the towns. After some mathematics we should be able to calculate the route. Perhaps, with some more mathematics, we would be able to store (dangerous) Areas on the world by some vector calculation. For a more individual map we could also save the map into an picture format, killing two birds with one stone: graphical interfaces can draw the map easily and we can form the landscape just by using different colours - which would be an easy editing. So we only got to store the towns x- and y-coordinates and that's all folks. Draw a line from town A to town B, look which colours are beneath this line, calculate speed, possible hazards, etc. The only problem would be how to explain, why the carriers dumbly fly into the pirate's nest every time instead of shipping around... ;o) Phew. Enough for today, gotta work a little bit now. > P.S. don't hit me! And if, you couldn't stop us. Trust me :o) SCNR, Daniel -- Big Brother is watching you! Daniel Reutter <br...@bi...> Offizieller Buchstaben- und Realnameverwalter in dag° |
From: Uwe H. <uh...@bi...> - 2000-01-21 00:57:20
|
On Thu, Jan 20, 2000 at 11:22:56PM +0100, Sven M. Hallberg wrote: > On Thu, Jan 20, 2000 at 10:54:45AM +0100, Uwe Hermann wrote: > > On Thu, Jan 20, 2000 at 01:15:29AM +0100, Sven M. Hallberg wrote: > > > > > > > > Maybe we should even store all this data in plain arrays, as the > > > > *number* of goods won't change dynamically during the game, > > > > only the *contents* of the array will change. > > > > > > What data are we talking about here actually? > > > > The array of goods. Members like 'amount' or similar, will change during > > the game, but the number of goods won't. > > Are we talking about good_spec's?? Then it's clear, an array will suffice for > that job. But we'll still need lists for the goods a given trader posesses. Not necessarily. We could store them in arrays, too. > > Not really. AI are good and will certainly be implemented, but having a > > certain population with needs for goods makes the whole economy more > > realistic I think. > > What's the advantage of having the option to "sell any amount at any time to > an unknown entity (the base economy) at a certain price dictated by that > entity" over having a number of AI traders possibly permanently residing in > the town which will _be_ the base economy and of course accept stuff at a > certain price. And by the way: I think it's not even necessary to prohibit a > situation where a trader can't get rid of his goods because nobody wants them. > That sort of thing happens all the time in the real world actually. Sure. But it's not very good for the gameplay. > > Maybe we should add a restriction on how much depot space a trader > > can hire (?) Maybe depending on the wealth of the player (the richer, the > > more people trust in him and the more storage they offer)... > > Indirectly your storage capabilities are already limited by your wealth. If > you can't afford it, you won't be able to hire/buy the space and that's it. > Period. :) Agreed. > The towns should have some variable indicating their maximum storage capacity > or something similar. That's realistic. I don't think there are any other > aspects influencing how much storage on can get a hold of. ACK. > > > We should put together a concept draft about all this in the near future... > > > > Yep. > > Me or you? ;-) Both :-) Let's write the CONTENTS first, and then distribute the work... Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
From: Sven M. H. <pe...@so...> - 2000-01-20 20:23:29
|
On Thu, Jan 20, 2000 at 10:54:45AM +0100, Uwe Hermann wrote: > On Thu, Jan 20, 2000 at 01:15:29AM +0100, Sven M. Hallberg wrote: > > > > > > Maybe we should even store all this data in plain arrays, as the > > > *number* of goods won't change dynamically during the game, > > > only the *contents* of the array will change. > > > > What data are we talking about here actually? > > The array of goods. Members like 'amount' or similar, will change during > the game, but the number of goods won't. Are we talking about good_spec's?? Then it's clear, an array will suffice for that job. But we'll still need lists for the goods a given trader posesses. That was the primary aspect I was thinking about originally. > Yes. > > But there should be some AI-traders who will *always* accept your goods, > because else, it can easily happen that you're waiting for hours for > someone to buy your goods, and can't buy new ones, because you need the > profit from these goods noone wants to buy... Right. In effect they will pretty much do that. I don't think we need to force them to accept offers they dont "want" to accept. The player will just need to make an offer they find profitable. That will only be a matter of the right price I guess. > Not really. AI are good and will certainly be implemented, but having a > certain population with needs for goods makes the whole economy more > realistic I think. What's the advantage of having the option to "sell any amount at any time to an unknown entity (the base economy) at a certain price dictated by that entity" over having a number of AI traders possibly permanently residing in the town which will _be_ the base economy and of course accept stuff at a certain price. And by the way: I think it's not even necessary to prohibit a situation where a trader can't get rid of his goods because nobody wants them. That sort of thing happens all the time in the real world actually. What people do eventually is that they sell their stuff at very low prices. There's always someone willing to buy your stuff if the price is low enough. > Maybe we should add a restriction on how much depot space a trader > can hire (?) Maybe depending on the wealth of the player (the richer, the > more people trust in him and the more storage they offer)... Indirectly your storage capabilities are already limited by your wealth. If you can't afford it, you won't be able to hire/buy the space and that's it. Period. :) The towns should have some variable indicating their maximum storage capacity or something similar. That's realistic. I don't think there are any other aspects influencing how much storage on can get a hold of. > > We should put together a concept draft about all this in the near future... > > Yep. Me or you? ;-) Bye, Sven -- Sven M. Hallberg <pe...@gm...> PGP key available at http://www.sh-home.de/~sol [ KeyID........: 0x0F520CF9 ] [ Fingerprint..: 56 61 00 18 14 B4 01 01 06 90 D0 29 96 BD 58 6F ] return 0; |
From: Uwe H. <uh...@bi...> - 2000-01-20 15:37:44
|
On Thu, Jan 20, 2000 at 01:15:29AM +0100, Sven M. Hallberg wrote: > > > > Maybe we should even store all this data in plain arrays, as the > > *number* of goods won't change dynamically during the game, > > only the *contents* of the array will change. > > What data are we talking about here actually? The array of goods. Members like 'amount' or similar, will change during the game, but the number of goods won't. So we could say: good_t good[20]; This '20' won't change during the game, I think. goods[19].amount (for example) *will* change. > > The details of calculating the price based on demand, supply and maybe > > some other factors, is something we need to put lots of thought into, > > because this is what is the most important thing in a trading-game, I > > guess :-) > > I'm currently reading some texts about economy, price, value, markets > > etc. to get a feeling for this topic. I hope I can use some of that > > stuff in htsserver... > > What I was thinking about was not having a set price for a given good in a > given town but to generalize the entire thing through 'offers'. Because in > reality nobody sells anything to a town. Yes. But there should be some AI-traders who will *always* accept your goods, because else, it can easily happen that you're waiting for hours for someone to buy your goods, and can't buy new ones, because you need the profit from these goods noone wants to buy... > > We should do both. Have a base economy (rather statical, stays roughly > > the same over longer periods of time, normally) and AI-controlled > > traders, who behave quite like human players: > > * they drive around > > * buy/sell stuff > > etc. > > I think we could really completely substitute the 'base economy' with AI > traders. Not really. AI are good and will certainly be implemented, but having a certain population with needs for goods makes the whole economy more realistic I think. > > Separated from the server? Guess not. > > I don't really want to have to fork() 30-100 new processes which act as > > AI-traders and probably even connect via sockets and use htsprotocol... > > > > I think these AI-traders should remain in the server. > > That's right. But I pretty much like the idea of really "populating" the > world. Yes. > > > long supply; /* similarly to the above, somehow resembles > > > * how much supply of this good the market > > > * seems to be holding currently. */ > > > > This belongs in the server. The client doesn't know about supply/demand. > > It only sees the price of a good, not how much demand there is for it. > > I thought of this as the client's prediction of supply/demand based on the > movements he's seeing on the market. OK. That belongs in the client of course. > > Buying and/or hiring depots/warehouses should definately be possible. > > I think it would be practical to not explicitly hire depots. I'd do it like > this: > > If you receive goods, pick a place to put them. Dialog like this: > > Received 15 units of wheat. Store where? > - Freighter "Ilse" > - Freighter "Carmen" > - Local Depot > > If you choose depot, just bill the player a certain amount (town specific) of > money every so-long. But then, it would be nice to be able to really buy > storage for a lump sum if you want to. We might handle that case this way: > > Remember how much storage space a player owns in a specific town. Let him > buy/sell storage at some price. Let him store stuff there at no cost. If he > stores more units in "Local Depot" space than he owns, charge him a fee for > every unit exceeding his own capacity. > > Sound good? Yes. Maybe we should add a restriction on how much depot space a trader can hire (?) Maybe depending on the wealth of the player (the richer, the more people trust in him and the more storage they offer)... > We should put together a concept draft about all this in the near future... Yep. Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
From: Uwe H. <uh...@bi...> - 2000-01-19 17:43:42
|
On Tue, Jan 18, 2000 at 03:45:56PM +0100, Sven M. Hallberg wrote: > On Fri, Jan 14, 2000 at 12:31:40AM +0100, Uwe Hermann wrote: > > This is what we have at the moment: > > > > > > typedef struct good_t > > { > > char name[MAX_LEN_GOODNAME]; > > long nominal_price; /* standard price; is the same in all towns */ > > long price_paid; /* price you paid when buying the good */ > > long price; /* current price */ > > long amount; > > long demand; > > long supply; /* TODO average amount of goods in town? */ > > } good_t; > > We shouldn't save the nominal price in here, because it'll always be the same. > Rather create a list containing only goods and their respective nominal > prices. Name it good_nominals or something. ACK. Additionally there will be a file /usr/local/share/games/htsserver/worlds/medieval/goods.dat or something, where the initial values are read from. Optionally they could be created randomly. > Or wait, I have an even better Idea, name the list good_specs and also put in > it an ID number for every good. Then use the ID num in all other structs. One > could even consider saving pointers to the respective good_spec structure in > structures like good_t. That would save us loads of memory and cut down > _severely_ on cpu usage during lookups of good data. Yes, probably. Maybe we should even store all this data in plain arrays, as the *number* of goods won't change dynamically during the game, only the *contents* of the array will change. This should simplify and/or speed up several things. > Another thing: what's the price member?? It's basically just a variable to buffer the calculated price for that good in that special town, so you don't have to calculate it again and again, if you need the current price. Not really mandatory, could be removed. > I'd make it the average of all offers > for this good in the area. The details of calculating the price based on demand, supply and maybe some other factors, is something we need to put lots of thought into, because this is what is the most important thing in a trading-game, I guess :-) I'm currently reading some texts about economy, price, value, markets etc. to get a feeling for this topic. I hope I can use some of that stuff in htsserver... > It could then be described as "average market > value". The respective trader can compare it easily to his 'price_paid' and > decide whether it's worth looking into the specific offers. There should also > be a member 'price_change' or something, indicating the change of the price > since the last update of the price member. This is all client-side. If a client desires so, it can also save *all* prices it ever saw, maybe to be able to output statistics or to make market predictions, who knows :-) > Also, consider a different name for the structure. Just 'good' is a bit > misleading, especially if we introduce further stuff dealing with 'goods'. > Suggestion: Hmm.. depends. I don't think there will be that many other structs for goods... > long demand; /* somehow resembles how much has been bought > * of this good in the near past. */ Yes, but not only. It's also influenced by the current weather, time, political situation(if we introduce something like this in Holsham Traders) and several other factors. > long supply; /* similarly to the above, somehow resembles > * how much supply of this good the market > * seems to be holding currently. */ see above. > You might have noticed, how all this stuff is pretty focused on the traders, > it all seems to apply perfectly to a client, rather than to the server. This > leads me to a - rather radical - suggestion. Don't implement behaviour of > towns / AI traders in the server. Create "AI clients" which behave kind of > like the bots in popular 3D shoot-em-ups. This sounds pretty complicating, but > I think it's doable if one looks at it the following way: > We had planned the towns to act kind of like traders that a) can't move, b) > have huge storage capabilities, c) always buy/sell stuff in order to create a > base economy for human traders. The base economy is partly created by the inhabitants of the town, cause they need food, clothes, weapons and drugs :-) The more inhabitants, the higher the demand. The more farmers in the town, the fewer demand for food from other towns. The higher the crime-rate is, the more police uniforms are in demand :-) etc. etc. > If we scrap that concept and instead > "populate" the town with a really simple AI trader which does the same thing > (doesn't move away -> needs no freighters, hires storage from the town as > necessary, and monitors the market to eventually accept offers of other > traders) we have a much more flexible and realistic simulation of the economic > happenings. We should do both. Have a base economy (rather statical, stays roughly the same over longer periods of time, normally) and AI-controlled traders, who behave quite like human players: * they drive around * buy/sell stuff etc. > And it won't be more complicated, because It doesn't really have > much more to do. On the contrary, it's probably easier, because it's seperated > from the server, which will make the server application easier to overview. Separated from the server? Guess not. I don't really want to have to fork() 30-100 new processes which act as AI-traders and probably even connect via sockets and use htsprotocol... I think these AI-traders should remain in the server. Also, because the admin should be able to choose the number of AI-traders 1. dynamically during runtime 2. at the start of the game 3. in the configfile > In respect to that we must think about, what of the above actually applies to > the server, and what to the client. I'd use the above structure > 'personal_gdata_t' for the client and save only the amount of goods a client > owns in the server. ACK. > The server is not really interested in what the client > thinks about market flow and stuff like that (provided it's not concerned with > acting as the trader, mind you). All it needs to know is, whether to allow the > client to buy/sell a certain amount of goods at a given time. ACK. > in the server: > > typedef struct player_good_data player_gdata_t { > struct good_spec *good; > long amount; > } > > in the client: > > typedef struct personal_good_data personal_gdata_t { > struct good_spec *good; > long amount; > long price_paid; /* per unit */ > long price; /* average price of open offers in this area */ Nope. Price is calculated by the server. > long price_change; /* price change since last time we checked */ Yes. > long demand; /* somehow resembles how much has been bought > * of this good in the near past. */ > long supply; /* similarly to the above, somehow resembles > * how much supply of this good the market > * seems to be holding currently. */ This belongs in the server. The client doesn't know about supply/demand. It only sees the price of a good, not how much demand there is for it. > I'd display only open offers for that town. You don't usually know how much of > a good all other companies posess. I'll go into more detail about offers and > such further down in this mail. Sure. You won't know how much stuff a player has got, but only how much he offers. > > > How to travel? (map, streats, storage format) > > > > Not sure about this. Haven't really thought about it, yet. > > It is my understanding that players don't travel at all. Yes, well... but the transporters/ships/vehicles need to drive from one town to another. We need to calculate an amount of time, how long it will take a transporter to drive from town A to town B. This could be calculated based on a real map (2d or maybe even 3D), e.g. if you have to drive over some mountains, you'll be slower, etc. > They all reside in the central town of Holsham from where they monitor > the activities in different cities. Basically yes. BUT: The players can only monitor any prices/amounts etc. of towns where they have a transporter stationed. Otherwise they don't know how much something costs in that town, which other players are in that town etc. etc. I know this is not very realistic(I mean you have hoover-craft like transporters, and a very high technical standard etc.), but it is *very* important for the gameplay. > They have freighters which can be sent to these cities which > enables the trader to sell the goods contained in the freighter to others who > have storage capacity in that city. Yep. > One should be able to gain storage > capacity by stationing freighters in the city or by hiring local depot space. Yep. Buying and/or hiring depots/warehouses should definately be possible. > > Human vs. Human: > > There will be a chat-like environment, where both traders (or 3 or 4..) > > can agree on a price and amount of what they want to trade. > > > > Also see docs/FEATURES for some more stuff. > > > > > > > *let the game engine say the prices (how?) > > > > If you buy/sell from/to a town, you'll have to either pay the price the > > town asks for, or not buy at all. I don't think you will be able to > > work out price agreements with a town. > > Now here comes my suggestion: Create _one_ way of trading that applies to > everyone (humans, AI, AL (:])). ^^ artificial losers? :-) > My idea would be to have, in each town a list > of open "offers" to which anyone interested can respond. Hmm.. something like a bulletin board... yep. Or maybe 'market' is the better word. > Offers can be "buy" or "sell" offers. If a player wants to sell a particular > good, he opens a "sell offer" for a certain amount of that good. From that > moment on, he doesn't actually "have" the good anymore. However, he will of > course be able to revoke the offer, which will bring his goods back. Anyone > else can accept the offer, which will immediately gain him the offered goods > at the offered price. The money is transmitted to the originator of the offer. > You can easily imagine the same for "buy offers". Sounds nice. > If an offer doesn't seem to be of any interest to anyone, the player can of > course change the offered price. He might also have been persuaded to do this > by another human player, who might have contacted him via the standard chat > interface. Yep. > I think one should be able to mark offers as "confirm" or "no-confirm", which > means, if anyone wants to accept an offer, the player is asked to confirm the > trade, while with a no-confirm offer the trade will be initiated automatically. ACK. > I'm also thinking of the problem of a large number of traders acting > at the same time. But I think we'll be able to deal with that. Yep. I don't see any problems here. > Imagine the > following scenario: > > A player offers "wheat" for 15 creds per unit as a confirm offer. Now, this is > a real bargain and everyone else wants it. Now this poor player immediately > receives 20 requests for accepting the offer. It'll be a pain to go through > every request, but I think this can be handled quite conveniently by the > client by providing actions to the player like the following: This should be handled by the client, yes. Definately. > - accept > - deny > - deny all > - revoke offer Ack. Depends on the client you use(whether it offers such options). > Of course, if the player choses "accept", all others are implicitly denied... Yep. > Ok, I think that'll be enough for you to chew on ;-) guess so, yes :-) Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
From: Sven M. H. <pe...@so...> - 2000-01-18 15:51:14
|
On Fri, Jan 14, 2000 at 12:31:40AM +0100, Uwe Hermann wrote: > This is what we have at the moment: > > > typedef struct good_t > { > char name[MAX_LEN_GOODNAME]; > long nominal_price; /* standard price; is the same in all towns */ > long price_paid; /* price you paid when buying the good */ > long price; /* current price */ > long amount; > long demand; > long supply; /* TODO average amount of goods in town? */ > } good_t; We shouldn't save the nominal price in here, because it'll always be the same. Rather create a list containing only goods and their respective nominal prices. Name it good_nominals or something. Or wait, I have an even better Idea, name the list good_specs and also put in it an ID number for every good. Then use the ID num in all other structs. One could even consider saving pointers to the respective good_spec structure in structures like good_t. That would save us loads of memory and cut down _severely_ on cpu usage during lookups of good data. Another thing: what's the price member?? I'd make it the average of all offers for this good in the area. It could then be described as "average market value". The respective trader can compare it easily to his 'price_paid' and decide whether it's worth looking into the specific offers. There should also be a member 'price_change' or something, indicating the change of the price since the last update of the price member. Also, consider a different name for the structure. Just 'good' is a bit misleading, especially if we introduce further stuff dealing with 'goods'. Suggestion: typedef struct personal_good_data personal_gdata_t { struct good_spec *good; long amount; long price_paid; /* per unit */ long price; /* average price of open offers in this area */ long price_change; /* price change since last time we checked */ long demand; /* somehow resembles how much has been bought * of this good in the near past. */ long supply; /* similarly to the above, somehow resembles * how much supply of this good the market * seems to be holding currently. */ } You might have noticed, how all this stuff is pretty focused on the traders, it all seems to apply perfectly to a client, rather than to the server. This leads me to a - rather radical - suggestion. Don't implement behaviour of towns / AI traders in the server. Create "AI clients" which behave kind of like the bots in popular 3D shoot-em-ups. This sounds pretty complicating, but I think it's doable if one looks at it the following way: We had planned the towns to act kind of like traders that a) can't move, b) have huge storage capabilities, c) always buy/sell stuff in order to create a base economy for human traders. If we scrap that concept and instead "populate" the town with a really simple AI trader which does the same thing (doesn't move away -> needs no freighters, hires storage from the town as necessary, and monitors the market to eventually accept offers of other traders) we have a much more flexible and realistic simulation of the economic happenings. And it won't be more complicated, because It doesn't really have much more to do. On the contrary, it's probably easier, because it's seperated from the server, which will make the server application easier to overview. In respect to that we must think about, what of the above actually applies to the server, and what to the client. I'd use the above structure 'personal_gdata_t' for the client and save only the amount of goods a client owns in the server. The server is not really interested in what the client thinks about market flow and stuff like that (provided it's not concerned with acting as the trader, mind you). All it needs to know is, whether to allow the client to buy/sell a certain amount of goods at a given time. in the server: typedef struct player_good_data player_gdata_t { struct good_spec *good; long amount; } in the client: typedef struct personal_good_data personal_gdata_t { struct good_spec *good; long amount; long price_paid; /* per unit */ long price; /* average price of open offers in this area */ long price_change; /* price change since last time we checked */ long demand; /* somehow resembles how much has been bought * of this good in the near past. */ long supply; /* similarly to the above, somehow resembles * how much supply of this good the market * seems to be holding currently. */ } > Every trader(players, computer-players, towns...) will have one of > these good_t. ACK. > The goods will be stored in linked lists. Only those goods which are > available in a town will be in the list of the town, and only those will > be shown in the client. I'd display only open offers for that town. You don't usually know how much of a good all other companies posess. I'll go into more detail about offers and such further down in this mail. > > How to travel? (map, streats, storage format) > > Not sure about this. Haven't really thought about it, yet. It is my understanding that players don't travel at all. They all reside in the central town of Holsham from where they monitor the activities in different cities. They have freighters which can be sent to these cities which enables the trader to sell the goods contained in the freighter to others who have storage capacity in that city. One should be able to gain storage capacity by stationing freighters in the city or by hiring local depot space. > Human vs. Human: > There will be a chat-like environment, where both traders (or 3 or 4..) > can agree on a price and amount of what they want to trade. > > Also see docs/FEATURES for some more stuff. > > > > *let the game engine say the prices (how?) > > If you buy/sell from/to a town, you'll have to either pay the price the > town asks for, or not buy at all. I don't think you will be able to > work out price agreements with a town. Now here comes my suggestion: Create _one_ way of trading that applies to everyone (humans, AI, AL (:])). My idea would be to have, in each town a list of open "offers" to which anyone interested can respond. Offers can be "buy" or "sell" offers. If a player wants to sell a particular good, he opens a "sell offer" for a certain amount of that good. From that moment on, he doesn't actually "have" the good anymore. However, he will of course be able to revoke the offer, which will bring his goods back. Anyone else can accept the offer, which will immediately gain him the offered goods at the offered price. The money is transmitted to the originator of the offer. You can easily imagine the same for "buy offers". If an offer doesn't seem to be of any interest to anyone, the player can of course change the offered price. He might also have been persuaded to do this by another human player, who might have contacted him via the standard chat interface. I think one should be able to mark offers as "confirm" or "no-confirm", which means, if anyone wants to accept an offer, the player is asked to confirm the trade, while with a no-confirm offer the trade will be initiated automatically. I'm also thinking of the problem of a large number of traders acting at the same time. But I think we'll be able to deal with that. Imagine the following scenario: A player offers "wheat" for 15 creds per unit as a confirm offer. Now, this is a real bargain and everyone else wants it. Now this poor player immediately receives 20 requests for accepting the offer. It'll be a pain to go through every request, but I think this can be handled quite conveniently by the client by providing actions to the player like the following: - accept - deny - deny all - revoke offer Of course, if the player choses "accept", all others are implicitly denied... Ok, I think that'll be enough for you to chew on ;-) Greetings, Sven -- Sven M. Hallberg <pe...@gm...> PGP key available at http://www.sh-home.de/~sol [ KeyID........: 0x0F520CF9 ] [ Fingerprint..: 56 61 00 18 14 B4 01 01 06 90 D0 29 96 BD 58 6F ] return 0; |
From: Uwe H. <uh...@bi...> - 2000-01-16 10:53:40
|
On Fri, Jan 14, 2000 at 07:27:25PM +0100, Sven M. Hallberg wrote: > > > > It will. The server must inform all affected clients of changing prices, > > > > changing amount of goods etc. > > > > > > The key word is _affected_. > > > > ? > > Not everyone is affected. Thought must be put into how many actually are. Yep. Only those clients are informed of any changes, which do need to know these things. Example: Someone buys 20 tons of wheat in a town. Everybody in the same town will be notified that there are 20 tons less wheat available. All other players(those not in the town) will never know that the amount of wheat in that town changed. They have to travel to that town to know about the change. Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
From: Sven M. H. <pe...@so...> - 2000-01-14 20:03:05
|
On Tue, Jan 11, 2000 at 09:56:09PM +0100, Uwe Hermann wrote: > Yep, it can't be paused normally, at least not by players. > The admin-command 'pause' causes all input from any client to > be ignored, until the admin disables 'pause' again. > Don't know if it's useful at all, I just felt like implementing it :-) OK, then. > > What's a login-timeout (in this case, of course). Sorry, I'm not up-to-date on > > the source... > > If you are connected longer than 60 seconds and didn't login, you're > kicked. OK, then. > > > The chat-message is an exception, here, because important information is > > > stored in the text-part, which is not a very good solution. I'm not > > > quite sure about how to make this better, at the moment... > > > > Multi-line? > > Hmm.. no. Multi-line sucks :-) Why? I find multi-line replies to be a pretty clean thing. > How about this: > > chat [who] 144 > > and then 144 chars of text, just like in update-prices? Don't like it... but that's me... > Chat isn't really a server-reply, so it doesn't need the reply-codes, > anyway. > > Hmm.. reminds me that "type-of-reply"-group 0 (Information from server) > isn't really needed, too. Info from the server is sent as commands, not > as replies with reply-codes... Hm.. need to put some more thoughts into > this. Well, erm, grmpf... Don't like the thought of the server sending 'commands' to the client... Because all the server is giving out is information, really. The client is the only one actually commanding. It tells the server what to do. I just think we should pick a very clean representation of the reality, mirrored in the protocol. Just like to persons talking to each other. It might work other ways, too; it's just a matter of which way is neatest. Back to the point, consider this metaphor: You are working for a company which sells sofas and a customer calls you and says he wants to buy three orange sofas. You sell him three orange sofas and order the delivery dude to deliver them. However, let's say you have a colleage, who does the same job as you. You must inform him, that there's three sofas less in stock than before. You'd probably not say "Hey Joe, please decrease the number of orange sofas stored in your memory by three." but rather "Yo, I sold another three of the orange sofas, dude.". > > > It will. The server must inform all affected clients of changing prices, > > > changing amount of goods etc. > > > > The key word is _affected_. > > ? Not everyone is affected. Thought must be put into how many actually are. > OK. So let's make the line length bigger :-) How much? > > I think a rather short limit on good names should be set. That forces readable > > names. What about 32 characters (including trailing newline of course, because > > 33 is not a buflen you want (real programmers appreciate their powers of > > two!)) ;^) > > At the moment it's 20. We could change it to 32, but IMHO it's not > necessary. Ok, just leave it at 20, that's fine with me. greets, Sven -- Sven M. Hallberg <pe...@gm...> PGP key available at http://www.sh-home.de/~sol [ KeyID........: 0x0F520CF9 ] [ Fingerprint..: 56 61 00 18 14 B4 01 01 06 90 D0 29 96 BD 58 6F ] return 0; |
From: Uwe H. <uh...@bi...> - 2000-01-14 01:45:12
|
On Fri, Jan 14, 2000 at 12:30:16AM +0100, Piotr Esden-Tempski wrote: [ trading engine ] > Things that we have to know: > How to store the goods (Uwe allready has an idea in the code) This is what we have at the moment: typedef struct good_t { char name[MAX_LEN_GOODNAME]; long nominal_price; /* standard price; is the same in all towns */ long price_paid; /* price you paid when buying the good */ long price; /* current price */ long amount; long demand; long supply; /* TODO average amount of goods in town? */ } good_t; Every trader(players, computer-players, towns...) will have one of these good_t. The goods will be stored in linked lists. Only those goods which are available in a town will be in the list of the town, and only those will be shown in the client. If any goods are sold to the town, which weren't available before, a new node is added to the list, containing the respective good. > How to travel? (map, streats, storage format) Not sure about this. Haven't really thought about it, yet. > How to handle prices > *let the sellers say what do they want for their goods Human vs. Human: There will be a chat-like environment, where both traders (or 3 or 4..) can agree on a price and amount of what they want to trade. Also see docs/FEATURES for some more stuff. > *let the game engine say the prices (how?) If you buy/sell from/to a town, you'll have to either pay the price the town asks for, or not buy at all. I don't think you will be able to work out price agreements with a town. Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
From: Piotr Esden-T. <we...@bi...> - 2000-01-13 23:31:58
|
I don't know if you have allready talkde or even thought about it but some day it will be a subject so I want to be the first. :-) Let's start to implement the bluddy game engine! (please don't hit me!) I know that the transfer protocol is very importaint but I think that the Ideas are discussed inough to start at least a talk how we want to solve the problem of the trading engine. Things that we have to know: How to store the goods (Uwe allready has an idea in the code) How to travel? (map, streats, storage format) How to handle prices *let the sellers say what do they want for their goods *let the game engine say the prices (how?) and so on.... All this things will come up when we start to write the trade engine. But we have to write it so that the questions come up. chao Piotr. P.S. don't hit me! -- My e-mail adress: we...@bi... My homepage: http://www.bingo-ev.de/~pe1724/index.html LCDemu homepage: http://www.bingo-ev.de/~pe1724/lcdemu.html -Nothing to say but a lot to do. -19 (by Uwe Hermann) -Born to run kill -9 win (by Chaos Bytes (TM)) |
From: Uwe H. <uh...@bi...> - 2000-01-11 22:58:17
|
On Tue, Jan 11, 2000 at 11:24:10PM +0100, Daniel Reutter wrote: > On Mon, Jan 10, 2000 at 03:07:37PM +0100, Uwe Hermann wrote: > > > > The chat-message is an exception, here, because important information is > > stored in the text-part, which is not a very good solution. I'm not > > quite sure about how to make this better, at the moment... > > Well, with multi-line responses, it would be possible this way: > > xxx Data approaching > 000 Data-blabla > xxx end-of-data see my other mail. > > > Are we talking some kind of data transmission? What kind of data will we be > > > sending that uses so much space? > > > > prices, amounts/names of goods... > > > > > > And there must be something like an 'init'-command. Everytime the client > > logs in, it'll need to know the current prices, amounts of goods, > > positions of his/her transporters etc. etc. > > Perhaps we use another protocol for data transmission... ? > maybe even another port? No. > > It will. The server must inform all affected clients of changing prices, > > changing amount of goods etc. > > In this case, we *will* need a second protocol, No. Why should we? > therefor it could approach data before the 34 bytes are recieved. Please explain. Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
From: Daniel R. <br...@bi...> - 2000-01-11 22:32:14
|
On Mon, Jan 10, 2000 at 03:07:37PM +0100, Uwe Hermann wrote: > So: > > 441 Maximum number of connections reached. > 442 New socket descriptor greater than FD_SETSIZE. > 200 Welcome to htsserver version 0.5.5 > 451 Game is paused. Your input will be ignored. > 521 Your login-timeout has expired. Bye. > 421 You must log in first. > 422 Player is not connected. > 423 Player doesn't exist. > 000 Chat message from XXXX: "foo bar ..." > 511 Syntax error. > > > The chat-message is an exception, here, because important information is > stored in the text-part, which is not a very good solution. I'm not > quite sure about how to make this better, at the moment... Well, with multi-line responses, it would be possible this way: xxx Data approaching 000 Data-blabla xxx end-of-data > > >We still need to think of a way to transfer more than 256 bytes. > > >Maybe it's better to have protocol-commands like 'buy', 'sell', > > >'drive' etc., instead of using 'transfer 4000' and passing the 4000 > > >bytes to the trade-engine? Opinions? I think it would be appreciate to use the upper method. > > > > > > Are we talking some kind of data transmission? What kind of data will we be > > sending that uses so much space? > > prices, amounts/names of goods... > > > And there must be something like an 'init'-command. Everytime the client > logs in, it'll need to know the current prices, amounts of goods, > positions of his/her transporters etc. etc. Perhaps we use another protocol for data transmission... maybe even another port? > > I don't think we should be passing stuff directly to the trade engine > > because then we have some sort of sub-protocol which is kind of ugly IMHO. > > Agreed. In this case, another port could be a solution also... > > >Maybe the server should send > > >"000 Get list of goods from next data sent to you." > > >and then send a 4000 bytes long data-stream with all the names of the > > >goods. > > > > > > Server-side... hm... *headscratch* > > I don't think the server will need to send large lists of goods or whatever > > by itself. > > It will. The server must inform all affected clients of changing prices, > changing amount of goods etc. In this case, we *will* need a second protocol, therefor it could approach data before the 34 bytes are recieved. > > But in any case I suggest using a > > multi-line reply. That reminds me, I'd make multi-line repies have the form: > > > > xxx-blahblah > > otherblahblah > > moreblahblah > > xxx blahblah that looks (almost) like the end line > > xxx end of blahblah > > ACK > Uaa... I don't like this. Either we make the maximum line length bigger, > and/or use 'transmit'. I think, Sven's idea is good. It would save us from much trouble, I think. HTH Daniel |
From: Uwe H. <uh...@bi...> - 2000-01-11 22:29:59
|
On Tue, Jan 11, 2000 at 02:22:18PM +0100, Sven M. Hallberg wrote: > > 441 Maximum number of connections reached. > > 442 New socket descriptor greater than FD_SETSIZE. > > 200 Welcome to htsserver version 0.5.5 > > 451 Game is paused. Your input will be ignored. > > What's the purpose of a pause command? The game can't be paused, if someone > wants to leave the game, let him leave... It has no effect on his situation > when he returns. Yep, it can't be paused normally, at least not by players. The admin-command 'pause' causes all input from any client to be ignored, until the admin disables 'pause' again. Don't know if it's useful at all, I just felt like implementing it :-) > > 521 Your login-timeout has expired. Bye. > > What's a login-timeout (in this case, of course). Sorry, I'm not up-to-date on > the source... If you are connected longer than 60 seconds and didn't login, you're kicked. > > 421 You must log in first. > > 422 Player is not connected. > > 423 Player doesn't exist. > > 000 Chat message from XXXX: "foo bar ..." > > 511 Syntax error. > > > > > > The chat-message is an exception, here, because important information is > > stored in the text-part, which is not a very good solution. I'm not > > quite sure about how to make this better, at the moment... > > Multi-line? Hmm.. no. Multi-line sucks :-) How about this: chat [who] 144 and then 144 chars of text, just like in update-prices? Chat isn't really a server-reply, so it doesn't need the reply-codes, anyway. Hmm.. reminds me that "type-of-reply"-group 0 (Information from server) isn't really needed, too. Info from the server is sent as commands, not as replies with reply-codes... Hm.. need to put some more thoughts into this. > > It will. The server must inform all affected clients of changing prices, > > changing amount of goods etc. > > The key word is _affected_. ? > > Uaa... I don't like this. Either we make the maximum line length bigger, > > and/or use 'transmit'. > > I don't like 'transmit' :) OK. So let's make the line length bigger :-) > I think a rather short limit on good names should be set. That forces readable > names. What about 32 characters (including trailing newline of course, because > 33 is not a buflen you want (real programmers appreciate their powers of > two!)) ;^) At the moment it's 20. We could change it to 32, but IMHO it's not necessary. I agree that they need to be relatively short, because of readability-reasons and because the ncurses-client is limited to 80 chars/line normally, and we want to have a nice display for the ncurses-client, too :-) Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
From: Sven M. H. <pe...@so...> - 2000-01-11 20:05:43
|
----- Forwarded message from "Sven M. Hallberg" <pe...@dr...gus> ----- sorry, pressed the wrong button again... Date: Tue, 11 Jan 2000 14:19:41 +0100 From: "Sven M. Hallberg" <pe...@dr...gus> To: Uwe Hermann <uh...@bi...> Subject: Re: [htsserver-devel] D-0002.txt: Holsham Traders Server-Replies Reply-To: pe...@gm... X-Mailer: Mutt 0.95.5i In-Reply-To: <200...@bi...>; from Uwe Hermann on Mon, Jan 10, 2000 at 03:07:37PM +0100 On Mon, Jan 10, 2000 at 03:07:37PM +0100, Uwe Hermann wrote: > 441 Maximum number of connections reached. > 442 New socket descriptor greater than FD_SETSIZE. > 200 Welcome to htsserver version 0.5.5 > 451 Game is paused. Your input will be ignored. What's the purpose of a pause command? The game can't be paused, if someone wants to leave the game, let him leave... It has no effect on his situation when he returns. > 521 Your login-timeout has expired. Bye. What's a login-timeout (in this case, of course). Sorry, I'm not up-to-date on the source... > 421 You must log in first. > 422 Player is not connected. > 423 Player doesn't exist. > 000 Chat message from XXXX: "foo bar ..." > 511 Syntax error. > > > The chat-message is an exception, here, because important information is > stored in the text-part, which is not a very good solution. I'm not > quite sure about how to make this better, at the moment... Multi-line? > > > > (D|C)-xxx-yy.txt > > (D|C)-xxxx-yy.txt > > > where 'xxx' is the concept ID and 'yy' is the revision number. Note: > > changing the concept ID to a 3-digit number keeps the name fitting in MS-DOS > > style 8.3 notation. > > That's not *that* important. First, I don't think this will ever be > ported to DOS. Second, there are already lots of files in the distribution, > which don't fit in the 8.3 notation, e.g. Good point, thank you :) > transmit [count] -- client must wait for server to transmit [count] bytes. > > But we possibly won't even need this. Most of the time this could be > built in the corresponding command, e.g. > > update-prices 34 > > And then send 34 bytes containing new prices for some goods, e.g. > > Wheat 56, Wood 11, Oil 87, Gold 119 ACK. > It will. The server must inform all affected clients of changing prices, > changing amount of goods etc. The key word is _affected_. A client will only need updates on stuff that it's currently displaying on-screen. That will not be everything, so we'll actually only have stuff like 000 Price update... Wheat:25 Fluffy Rodents:104 000 End update. > > that will probably only be caused by some sort of client request > > for a complete list or something. > > Definately. But not only. The server will send data, without being > asked to, too. see above. > > But in any case I suggest using a > > multi-line reply. That reminds me, I'd make multi-line repies have the form: > > > > xxx-blahblah > > otherblahblah > > moreblahblah > > xxx blahblah that looks (almost) like the end line > > xxx end of blahblah > > > > Uaa... I don't like this. Either we make the maximum line length bigger, > and/or use 'transmit'. I don't like 'transmit' :) It kind of "bends" if not "breaks" the protocol. Let's increase maxlinelen to 512. That should be sufficient provided we don't allow good names that are too long. That however is not good anyways because then they won't find nicely into any display window. I think a rather short limit on good names should be set. That forces readable names. What about 32 characters (including trailing newline of course, because 33 is not a buflen you want (real programmers appreciate their powers of two!)) ;^) TTL expired, Sven -- Sven M. Hallberg <pe...@gm...> PGP key available at http://www.sh-home.de/~sol [ KeyID........: 0x0F520CF9 ] [ Fingerprint..: 56 61 00 18 14 B4 01 01 06 90 D0 29 96 BD 58 6F ] return 0; ----- End forwarded message ----- -- Sven M. Hallberg <pe...@gm...> PGP key available at http://www.sh-home.de/~sol [ KeyID........: 0x0F520CF9 ] [ Fingerprint..: 56 61 00 18 14 B4 01 01 06 90 D0 29 96 BD 58 6F ] return 0; |
From: Uwe H. <uh...@bi...> - 2000-01-10 15:24:02
|
On Mon, Jan 10, 2000 at 12:38:34AM +0100, Sven M. Hallberg wrote: > > >> Without the need to implement everything right away we should try to > specify > >> all replies we want in the concept file as soon as possible. > > > >Nope. The Concept file just describes how things work. > >The specific 3-digit-numbers and the text should be in the source-code. > > > No. Client developers should be given a clear view over which responses to > expect. ACK. They must know which numbers mean what. They should not rely on the text delivered, because this can change, and doesn't matter for the software anyway. > They must be specified by a set standard and not in the source. Hmmm, well OK. But, as you said, this means the Concept will be updated very often. This is what we have now: # grep send_to_client *.c net.c: send_to_client(new_conn, "Maximum number of connections reached."); net.c: send_to_client(new_conn, "New socket descriptor greater than FD_SETSIZE."); net.c: send_to_client(new_conn, "Welcome to htsserver version %s.", VERSION); net.c: send_to_client(c, "Game is paused. Your input will be ignored."); net.c:int send_to_client(conn_t *c, const char *fmt, ...) net.c: lerror("send_to_client:fprintf"); net.c: lerror("send_to_client:fflush"); net.c: send_to_client(c, tmp); net.c: send_to_client(c, tmp); net.c: send_to_client(c, "Your login-timeout has expired. Bye."); protocol.c: send_to_client(c, "You must log in first."); protocol.c: send_to_client(c, "Player '%s' is not connected.", destname); protocol.c: send_to_client(c, "Player '%s' doesn't exist.", destname); protocol.c: send_to_client(otherconn, "%s: %s", sendername, tmp); protocol.c: send_to_client(c, "Syntax error."); /* hello commodore */ So: 441 Maximum number of connections reached. 442 New socket descriptor greater than FD_SETSIZE. 200 Welcome to htsserver version 0.5.5 451 Game is paused. Your input will be ignored. 521 Your login-timeout has expired. Bye. 421 You must log in first. 422 Player is not connected. 423 Player doesn't exist. 000 Chat message from XXXX: "foo bar ..." 511 Syntax error. The chat-message is an exception, here, because important information is stored in the text-part, which is not a very good solution. I'm not quite sure about how to make this better, at the moment... Any improvements or suggestions? > [...] but any such changes must be clearly announced in a new > revision of the protocol standard (so client developers can state which > standard their client complies with). ACK. > hm... here another thing comes to mind... A concept which is outdated by a > new revision should not go to /dev/null right away. People should be able to > read it as a matter of information. ACK. Older versions will remain on the homepage. > My suggestion: Change D-0001 so the > naming specification for concept files is now > > (D|C)-xxx-yy.txt (D|C)-xxxx-yy.txt > where 'xxx' is the concept ID and 'yy' is the revision number. Note: > changing the concept ID to a 3-digit number keeps the name fitting in MS-DOS > style 8.3 notation. That's not *that* important. First, I don't think this will ever be ported to DOS. Second, there are already lots of files in the distribution, which don't fit in the 8.3 notation, e.g. configure mkinstalldirs htsserver.6.in htsserver.conf docs/README.files docs/ARCHITECTURES ... Same as htsserver-0.5.5.tar.gz is not a valid DOS-name... > >We still need to think of a way to transfer more than 256 bytes. > >Maybe it's better to have protocol-commands like 'buy', 'sell', > >'drive' etc., instead of using 'transfer 4000' and passing the 4000 > >bytes to the trade-engine? Opinions? > > > Are we talking some kind of data transmission? What kind of data will we be > sending that uses so much space? prices, amounts/names of goods... And there must be something like an 'init'-command. Everytime the client logs in, it'll need to know the current prices, amounts of goods, positions of his/her transporters etc. etc. > I don't think we should be passing stuff directly to the trade engine > because then we have some sort of sub-protocol which is kind of ugly IMHO. Agreed. So there will be 'buy', 'sell' etc. commands. from docs/PROTOCOL: buy [src] [dest] [what] [amount] -- buy stuff sell [src] [dest] [what] [amount] -- sell stuff maybe: drive [which-transporter] [dest] -- drive to the town [dest] ... > Rather - if it is necessary to send large sums of data - the protocol should > specify some sort of simple command which causes the server to await the > data whose length will be given as an argument of the initial command. Agreed. transmit [count] -- client must wait for server to transmit [count] bytes. But we possibly won't even need this. Most of the time this could be built in the corresponding command, e.g. update-prices 34 And then send 34 bytes containing new prices for some goods, e.g. Wheat 56, Wood 11, Oil 87, Gold 119 > >Maybe the server should send > >"000 Get list of goods from next data sent to you." > >and then send a 4000 bytes long data-stream with all the names of the > >goods. > > > Server-side... hm... *headscratch* > I don't think the server will need to send large lists of goods or whatever > by itself. It will. The server must inform all affected clients of changing prices, changing amount of goods etc. > that will probably only be caused by some sort of client request > for a complete list or something. Definately. But not only. The server will send data, without being asked to, too. > But in any case I suggest using a > multi-line reply. That reminds me, I'd make multi-line repies have the form: > > xxx-blahblah > otherblahblah > moreblahblah > xxx blahblah that looks (almost) like the end line > xxx end of blahblah > Uaa... I don't like this. Either we make the maximum line length bigger, and/or use 'transmit'. > However, we should forbid nested > replies (that's specified in FTP actually) because we won't need them and > their an unecessary complication. ACK. Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
From: Sven M. H. <pe...@so...> - 2000-01-10 00:30:57
|
-----Ursprüngliche Nachricht----- Von: Uwe Hermann <uh...@bi...> An: hts...@li... <hts...@li...> Datum: Sonntag, 9. Januar 2000 20:05 Betreff: Re: [htsserver-devel] D-0002.txt: Holsham Traders Server-Replies >> Without the need to implement everything right away we should try to specify >> all replies we want in the concept file as soon as possible. > >Nope. The Concept file just describes how things work. >The specific 3-digit-numbers and the text should be in the source-code. No. Client developers should be given a clear view over which responses to expect. They must be specified by a set standard and not in the source. Looking at the large number of RFCs concerning the FTP protocol, we see that yes, there will probably be several changes in the set of responses and their codes, but any such changes must be clearly announced in a new revision of the protocol standard (so client developers can state which standard their client complies with). And the place for new revisions of protocol standards are definately the concepts. hm... here another thing comes to mind... A concept which is outdated by a new revision should not go to /dev/null right away. People should be able to read it as a matter of information. My suggestion: Change D-0001 so the naming specification for concept files is now (D|C)-xxx-yy.txt where 'xxx' is the concept ID and 'yy' is the revision number. Note: changing the concept ID to a 3-digit number keeps the name fitting in MS-DOS style 8.3 notation. >We still need to think of a way to transfer more than 256 bytes. >Maybe it's better to have protocol-commands like 'buy', 'sell', >'drive' etc., instead of using 'transfer 4000' and passing the 4000 >bytes to the trade-engine? Opinions? Are we talking some kind of data transmission? What kind of data will we be sending that uses so much space? I don't think we should be passing stuff directly to the trade engine because then we have some sort of sub-protocol which is kind of ugly IMHO. Rather - if it is necessary to send large sums of data - the protocol should specify some sort of simple command which causes the server to await the data whose length will be given as an argument of the initial command. >Maybe the server should send >"000 Get list of goods from next data sent to you." >and then send a 4000 bytes long data-stream with all the names of the >goods. Server-side... hm... *headscratch* I don't think the server will need to send large lists of goods or whatever by itself. that will probably only be caused by some sort of client request for a complete list or something. But in any case I suggest using a multi-line reply. That reminds me, I'd make multi-line repies have the form: xxx-blahblah otherblahblah moreblahblah xxx blahblah that looks (almost) like the end line xxx end of blahblah that's kind of like the way FTP does it. However, we should forbid nested replies (that's specified in FTP actually) because we won't need them and their an unecessary complication. so the client will act like this: ] if I get a reply with a hyphen (-) immediately following the reply code, interpret the reply and parse the following lines accordingly ] once I hit a line which starts with the same three-digit reply code as the initial one followed by a space, treat this as the end of the reply. ] when parsing the reply line, strip any leading space This way we can send almost anything in a multi-line reply except stuff starting with spaces and I don't think we'll need that. bye, Sven |
From: Uwe H. <uh...@bi...> - 2000-01-08 22:23:46
|
On Sat, Jan 08, 2000 at 03:33:56PM +0100, Sven M. Hallberg wrote: > > > Again, my suggestion would be to use some ftp/smtp style protocol. > > > > That's what I intend to do :) > > Good. Just to clarify, then we'll have: > > - _three_ digits. Yep. <THINKING>hmm, must try to make myself clearer</THINKING> :) > - the following basic groups of replies, identified by the first digit: > (quoted from the SMTP protocol specification RFC821) > 1yz Positive Preliminary reply > 2yz Positive Completion reply > 3yz Positive Intermediate reply > 4yz Transient Negative Completion reply > 5yz Permanent Negative Completion reply > see the RFC for a detailed description of each group. > In addition however we should adopt a group with first digit 0 to designate > replies that aren't really replies to anything, just information sent by the > server as a result of changing conditions in the universe. ACK. > I'm not sure whether we should take the 2nd. digit from SMTP too, but I have > looked them over and I think they fit quite well (better than the FTP ones). > Of course we might modify them to fit our needs (especially x5z - mail > system). > > In general, again, I suggest sticking as close to the existing standards as > possible, because they have proven to work well. Basically yes. But we shouldn't stick to it just because it worked well for FTP/SMTP, but because we think it will work well for htsprotocol, too. > I further suggest a second or third digit of 0 to mean 'unspecified', so the > server is not forced to support every specified reply right away and the work > imposed on client developers to understand this is minimal. ACK. 200 would then be a general "OK" reply. > Without the need to implement everything right away we should try to specify > all replies we want in the concept file as soon as possible. Nope. The Concept file just describes how things work. The specific 3-digit-numbers and the text should be in the source-code. I attached a revised version of D-0002.txt. Comments welcome. We still need to think of a way to transfer more than 256 bytes. Maybe it's better to have protocol-commands like 'buy', 'sell', 'drive' etc., instead of using 'transfer 4000' and passing the 4000 bytes to the trade-engine? Opinions? Maybe the server should send "000 Get list of goods from next data sent to you." and then send a 4000 bytes long data-stream with all the names of the goods. Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |