From anmaster at tele2.se Sun Jun 1 03:03:04 2008 From: anmaster at tele2.se (AnMaster) Date: Sun, 01 Jun 2008 10:03:04 +0200 Subject: [crossfire] FAQ on website needs updating In-Reply-To: <4841E5F5.1050001@real-time.com> References: <4841C5BB.9010700@tele2.se> <4841E5F5.1050001@real-time.com> Message-ID: <484257B8.9000309@tele2.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Rick Tanner wrote: | AnMaster wrote: |> Who got access to edit the page? | | I do. | |> Whoever that is: please update the FAQ. | | Update the webpage to say what, exactly? | | Your post lacks clarification and content. ;-) | |> Maybe also migrate it to the wiki? | | It is, and has been since Dec-2006. | | http://wiki.metalforge.net/doku.php/faq | Maybe the link on the website should refer to that FAQ then rather than the one I mentioned. Regards, Arvid Norlander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEAREKAAYFAkhCV7cACgkQWmK6ng/aMNlAqACgnCVY/smUkNZhVUvWWSRWr9SR Fi4AnA7hrZnq85bQWl4mQKHXtgXa09O0 =3N0g -----END PGP SIGNATURE----- From mwedel at sonic.net Wed Jun 4 10:51:40 2008 From: mwedel at sonic.net (mwedel at sonic.net) Date: Wed, 4 Jun 2008 08:51:40 -0700 Subject: [crossfire] Things to fix Message-ID: <8700.1212594700@sonic.net> On Thu 29/05/08 1:37 PM , Nicolas Weeger nicolas.weeger at laposte.net sent: > The combat rebalance needs to be finished. Mark, how can we help you > on that? > Also, do people have comments about the current hand to hand combat > rebalance? > Can be seen on the Ailesse servers (one permadeath, the other non > permadeath). > What about general item/monster fixing/balance? I plan to start working on that once I get back from vacation in another week and a half or so. Excuse the mistakes - Austrian kezboards have the kezs in the wrong places... For combat, most useful information is existing feedback, as well as some reference characters at different levels to see how what thez look like. As I've been rebalancing things, I've also been doing monsters, but less so items. Some depends on more overall plaz feel - combat is slowed down, but is still largelz hack up a bunch of monsters. Some redesign of maps maz be in order to have fewer monsters, but those that do exist are tougher. For most of the normal monsters, I've been trzing to give them stats closer to that of the plazer - in that waz, plazer vs plazer combat, whether intentional or not, is also more balanced. But that isn't to saz that the big boss monster can't have 5 times the hp of the plazer for example. From anmaster at tele2.se Tue Jun 10 12:57:51 2008 From: anmaster at tele2.se (AnMaster) Date: Tue, 10 Jun 2008 19:57:51 +0200 Subject: [crossfire] Challenge-Response login, proof of concept implementation ready Message-ID: <484EC09F.7040107@tele2.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I have locally a proof of concept challenge-response login for use in crossfire (HMAC-SHA256). However how should it be added to server protocol exactly, setup command? I'd prefer upgrading protocol version. Backward compatibility would be supported by plain text login once and then upgrade password in player file to store the "shared secret", then HMAC-SHA256 would be used in future to log in. I feel that it is less of an issue storing an unencrypted shared secret on the server than, as we currently do, sending it in plain text over network. However I need some help from protocol experts here. As a bonus longer passwords than the current 8 chars will be possible. If no one objects within a week (or a bit more as I will be away then, on a trip to another part of Sweden) I'd like to go ahead with my fully own implementation even at protocol level. This in order to avoid the whole thing just stalling and dying out. Regards, Arvid Norlander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEAREKAAYFAkhOwJ0ACgkQWmK6ng/aMNkY3gCfaEipKeE06iH0pXBzIxnZTo6I UMgAoJOTzrYMY8tCpm4QTSqJWTQ8brQf =nBP+ -----END PGP SIGNATURE----- From leaf at real-time.com Tue Jun 10 13:06:40 2008 From: leaf at real-time.com (Rick Tanner) Date: Tue, 10 Jun 2008 13:06:40 -0500 Subject: [crossfire] Challenge-Response login, proof of concept implementation ready In-Reply-To: <484EC09F.7040107@tele2.se> References: <484EC09F.7040107@tele2.se> Message-ID: <484EC2B0.2020003@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 AnMaster wrote: | | Backward compatibility would be supported by plain text login once and then upgrade | password in player file to store the "shared secret", then HMAC-SHA256 would be used in | future to log in. I feel that it is less of an issue storing an unencrypted shared secret | on the server than, as we currently do, sending it in plain text over network. What about password resets in cases where a player returns from a long hiatus and can't remember their password? Under the current system, a person with server/shell access can reset that players password. Would this new system prevent this? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFITsKwhHyvgBp+vH4RAthXAKCzC1s71VgPmWgAsbDvC9ihpd2rkwCfUs0D wqG6V+F7Ogz+nPpZnX0RHnI= =USLK -----END PGP SIGNATURE----- From anmaster at tele2.se Tue Jun 10 13:13:53 2008 From: anmaster at tele2.se (AnMaster) Date: Tue, 10 Jun 2008 20:13:53 +0200 Subject: [crossfire] Challenge-Response login, proof of concept implementation ready In-Reply-To: <484EC2B0.2020003@real-time.com> References: <484EC09F.7040107@tele2.se> <484EC2B0.2020003@real-time.com> Message-ID: <484EC461.8010407@tele2.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Rick Tanner wrote: | AnMaster wrote: | | | | Backward compatibility would be supported by plain text login once and | then upgrade | | password in player file to store the "shared secret", then HMAC-SHA256 | would be used in | | future to log in. I feel that it is less of an issue storing an | unencrypted shared secret | | on the server than, as we currently do, sending it in plain text over | network. | | What about password resets in cases where a player returns from a long | hiatus and can't remember their password? | | Under the current system, a person with server/shell access can reset | that players password. Would this new system prevent this? | No. As it is a shared secret, it would actually have to be stored in plain text on the server, (still less of an issue than sending it unencrypted, or if that is considered a very bad issue, I could use a more sophisticated protocol, like that SSH uses). And yes resetting password on server would be possible both ways. Regards, Arvid Norlander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEAREKAAYFAkhOxGAACgkQWmK6ng/aMNkfnQCfUaqPsCqIOaSzNStCdSOfH+Eh S5EAoLf77b3C1TyQqO7BYvv7D150cH0K =O4wC -----END PGP SIGNATURE----- From anmaster at tele2.se Tue Jun 10 13:38:42 2008 From: anmaster at tele2.se (AnMaster) Date: Tue, 10 Jun 2008 20:38:42 +0200 Subject: [crossfire] Challenge-Response login, proof of concept implementation ready In-Reply-To: <484EC2B0.2020003@real-time.com> References: <484EC09F.7040107@tele2.se> <484EC2B0.2020003@real-time.com> Message-ID: <484ECA32.1030209@tele2.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Seems this didn't get through first time so trying again. Rick Tanner wrote: | AnMaster wrote: | | | | Backward compatibility would be supported by plain text login once and | then upgrade | | password in player file to store the "shared secret", then HMAC-SHA256 | would be used in | | future to log in. I feel that it is less of an issue storing an | unencrypted shared secret | | on the server than, as we currently do, sending it in plain text over | network. | | What about password resets in cases where a player returns from a long | hiatus and can't remember their password? | | Under the current system, a person with server/shell access can reset | that players password. Would this new system prevent this? | No. As it is a shared secret, it would actually have to be stored in plain text on the server, (still less of an issue than sending it unencrypted, or if that is considered a very bad issue, I could use a more sophisticated protocol, like that SSH uses). And yes resetting password on server would be possible both ways. Regards, Arvid Norlander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEAREKAAYFAkhOyjAACgkQWmK6ng/aMNkHLACfff9dwQCC2u/7ILwLzKStkGII Bw4AoKPghXqt4L2WYuPSIWMIuYp9AJW3 =XBxi -----END PGP SIGNATURE----- From crossfire at suckfuell.net Tue Jun 10 15:17:18 2008 From: crossfire at suckfuell.net (Jochen =?ISO-8859-1?Q?Suckf=FCll?=) Date: Tue, 10 Jun 2008 22:17:18 +0200 Subject: [crossfire] Challenge-Response login, proof of concept implementation ready In-Reply-To: <484EC461.8010407@tele2.se> References: <484EC09F.7040107@tele2.se> <484EC2B0.2020003@real-time.com> <484EC461.8010407@tele2.se> Message-ID: <20080610221718.7df67d26@chox.suckfuell.net> Hello! AnMaster wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Rick Tanner wrote: > | AnMaster wrote: > | | > | | Backward compatibility would be supported by plain text login > once and | then upgrade > | | password in player file to store the "shared secret", then > HMAC-SHA256 | would be used in > | | future to log in. I feel that it is less of an issue storing an > | unencrypted shared secret > | | on the server than, as we currently do, sending it in plain text > over | network. > | > | What about password resets in cases where a player returns from a > long | hiatus and can't remember their password? > | > | Under the current system, a person with server/shell access can > reset | that players password. Would this new system prevent this? > | > No. As it is a shared secret, it would actually have to be stored in > plain text on the server, (still less of an issue than sending it > unencrypted, or if that is considered a very bad issue, I could use a > more sophisticated protocol, like that SSH uses). > > And yes resetting password on server would be possible both ways. There's no reason to store a plaintext password. You can apply the hash function right away when the password was entered. This would be done both in the client when the player logs in and in on the server side when the password is reset (e.g. by using a DM command). Of course someone with shell access could still steal that hash sum. But he still doesn't know the password to log in (using an unpatched client). OTOH it's out of the scope here to implement a protection from someone that has a shell access to the server. Jochen From mwedel at sonic.net Sat Jun 14 15:11:57 2008 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 14 Jun 2008 13:11:57 -0700 Subject: [crossfire] Challenge-Response login, proof of concept implementation ready In-Reply-To: <484EC09F.7040107@tele2.se> References: <484EC09F.7040107@tele2.se> Message-ID: <4854260D.9010609@sonic.net> AnMaster wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > I have locally a proof of concept challenge-response login for use in crossfire (HMAC-SHA256). > > However how should it be added to server protocol exactly, setup command? I'd prefer > upgrading protocol version. Depends on a few things. Do you expect this change to only be in the trunk, or also backport to the stable release? If only in the trunk, then perhaps increasing the protocol version, and making that the only supported authentication method in fairly short order may be the right thing to do. For the trunk, we are not guaranteeing a lot of backwards compatibility. However, the stable release does guarantee some level of backwards compatibility. The problem with the protocol version (and why setup is often used instead) is that with just a number, it is not clear what has changed and if in fact and old client can operate on that newer server. Also, before committing any changes, the proposed protocol changes should be documented (like the current protocol commands - what does the server & client send to each other. That provides more concrete examples of how the changes will be implemented, and allows for better/more meaningful conversation. > > Backward compatibility would be supported by plain text login once and then upgrade > password in player file to store the "shared secret", then HMAC-SHA256 would be used in > future to log in. I feel that it is less of an issue storing an unencrypted shared secret > on the server than, as we currently do, sending it in plain text over network. Almost certainly true - file access controls on the server itself can still be used to prevent unauthorized folks from looking at the player files. And for many systems, the password actually is stored in plain text (look at the #if in crypt_string()) From anmaster at tele2.se Sat Jun 14 17:44:05 2008 From: anmaster at tele2.se (AnMaster) Date: Sun, 15 Jun 2008 00:44:05 +0200 Subject: [crossfire] Challenge-Response login, proof of concept implementation ready In-Reply-To: <4854260D.9010609@sonic.net> References: <484EC09F.7040107@tele2.se> <4854260D.9010609@sonic.net> Message-ID: <485449B5.5000905@tele2.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Mark Wedel wrote: | AnMaster wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA512 |> |> I have locally a proof of concept challenge-response login for use in crossfire (HMAC-SHA256). |> |> However how should it be added to server protocol exactly, setup command? I'd prefer |> upgrading protocol version. | | Depends on a few things. Do you expect this change to only be in the trunk, | or also backport to the stable release? | | If only in the trunk, then perhaps increasing the protocol version, and making | that the only supported authentication method in fairly short order may be the | right thing to do. For the trunk, we are not guaranteeing a lot of backwards | compatibility. Yes trunk only, however existing player files need to be supported. | | However, the stable release does guarantee some level of backwards | compatibility. The problem with the protocol version (and why setup is often | used instead) is that with just a number, it is not clear what has changed and | if in fact and old client can operate on that newer server. | | Also, before committing any changes, the proposed protocol changes should be | documented (like the current protocol commands - what does the server & client | send to each other. That provides more concrete examples of how the changes | will be implemented, and allows for better/more meaningful conversation. Agreed it got some issues so I need to rework parts, however I'm on vacation without internet and without computer for a few days from tomorrow morning (just finished packing, late night now), so work will continue in a bit. | |> Backward compatibility would be supported by plain text login once and then upgrade |> password in player file to store the "shared secret", then HMAC-SHA256 would be used in |> future to log in. I feel that it is less of an issue storing an unencrypted shared secret |> on the server than, as we currently do, sending it in plain text over network. | | Almost certainly true - file access controls on the server itself can still be | used to prevent unauthorized folks from looking at the player files. And for | many systems, the password actually is stored in plain text (look at the #if in | crypt_string()) Yes, however my freebsd system will use des_crypt it seems. And my linux uses crypt(). | | | _______________________________________________ | crossfire mailing list | crossfire at metalforge.org | http://mailman.metalforge.org/mailman/listinfo/crossfire | -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEAREKAAYFAkhUSbQACgkQWmK6ng/aMNnZPACglgat+bD7fDKNL0a2NVeLKBGK qDgAoJLuD7bdZUcRc0nUkd+EHvpLo0UQ =lJ77 -----END PGP SIGNATURE----- From bogus@does.not.exist.com Mon Jun 16 10:37:07 2008 From: bogus@does.not.exist.com () Date: Mon, 16 Jun 2008 15:37:07 -0000 Subject: No subject Message-ID: v2 and jx shouldn't be *too* hard. >> - "Rebootworld" will start with current faces, but 4 pixels per >> cell and "tall faces". So we can design better arches, especially >> buildings, without drawing anything. That will kind of kill >> smoothing, I guess, but we'll see how it goes. (I don't know if >> smoothing + tall faces has been though of yet...) > > If I follow this right, it does mean that in many cases, the number o= f > objects would need to be increased considerable. > > I gather that in the context above, a cell would be > equivalent to a map space (otherwise, we don't get anything be > subdividing it). Right, cell =3D=3D=3D map space. Not equivalent; the same thing :-) > So while we now have each cell use 32x32 pixels, the basic idea > is divide that cell in 64. Em, no. Ok. A human is currently 1x1x1 cells (let's assume tall faces are already supported), 32x32 pixels. On rebootworld with the "small" faceset (which uses the same PNGs as the current "standard" faceset), the same human will be 2x2x4 cells (meaning, for those not up-to-date with tall faces, it's rendered as 2x4 cells, but occupies a 2x2 area on the ground), and 16x32 pixels, so it would use (basically) the same image. So yes, there would be more map positions to keep track of. Not really more objects in the sense of cf objects. But yes more tails. > Such a major division is likely to have many impacts on map > handling. I think further investigation is needed. > > Certainly subdividing is a good thing, and does make for a smoother > interface/look. I just think impact/way to do it needs some additional > details. Did I now explain it enough? Yes, impact needs though. Especially in things like speed, and having all those tails around, and how many map cells the client and the protocol can reasonably handle. > How big of a viewable areas do you envision the client to display? > > For example, existing client supports up to 25x25, and I > think the jxclient uses 25x19. From quick calculations, it > would seem that increase the detail by a factor of 3 will > result in either less cells being viewable, or in almost all > cases, the end user actually downscaling the images. I disagree, I think larger images and less visible objects makes for a better game. OTOH, what I think of as the "ideal" range is between 9 and 15, so yes, maybe increasing by 3 or 4 is too much. Maybe only 2. Another thing to consider is that maps built for tall objects will look more "compact". Like, the human character's image is being scaled by 4, but the size of a corridor or chair it fits in only goes up by 2. (Or to rephrase that with the "small" tileset: the human image is staying the same size, but the human object's map footprint is going down by half. So those 800 pixels in the client go a LONG way, object-wise.) Again, the fact that some people prefer a wider view with crappier images is a reason I prefer to keep both "small" and "enhanced" tilesets around. But that's academic until such a time as I have graphic artist volunteers :-) for now "small" is all we'll have. >> Technical >> =3D=3D=3D=3D=3D=3D=3D=3D=3D > >> Then of course, I found that people expect that clicking on a monster >> will attack it. > > This would be more useful for directional attacks - I > shouldn't need to be perfectly lined up on a monster to shoot > an arrow at it - if it is one space over, I should still be > able to do so (and likewise, it to me) Very good point. >> True multi-scale >> ---------------- > > One time in the past, someone toyed with the idea of there > not being multiple scales - there is just one scale. You don't > enter buildings, but rather they are just there on the map. > > That idea has some appeal to me, especially for towns - then > everyone is logically on the same map (so you'd see other > players about more, etc). I don't know if that is something > you considered, or how it would work out, but if you're going > to do a completely new world... I have considered it long, and FWIW it's still on the table as a possibility, but I'm afraid it may cause "the bigworld fail"; as in, going from home (or the inn) to the restaurant or the dungeon you want to hit takes ages, assuming you can even find it, until people get bored of the game and leave. But it's up for discussion :-) (Like everything else... I'm running for content leader, not dictator) >> This is really two different features on the server side: >> >> - All movement is slowed down proportional to the "scale" >> attribute of the map. (If you think moving 10x slower on the city >> than indoors is annoying, bear in mind you'll probably move a little >> faster indoors, and outdoors you'll have transports, which I want to >> use more heavily.) > > This doesn't appeal to me much, and probably not much to > other people. I remember when we went from smallworld to > bigworld, some people complained about how long it took to get > from one town to another (which is still just a minute or two > if you know where you're going) This is to me a matter of fairness; walking across town shouldn't take as long as across the room. But this is a game, so the proportion doesn't need to be realistic; walking outdoors should be a *little* slower, not necessarily a lot. OTOH, I do *want* to make walking to another city annoyingly slow. Why? Because you just shouldn't do that. Yes, walk to the town nearby, but then expect that to take a while. But to go to a different kingdom, you'll want a horse at least. You'll probably want to camp along the way. And there may be goblins. Or bandits. Or goblin bandits. Or bandit zombie pirate goblin cultists. Or you take a ship, or the dragon, and get there faster and with no stress. But it costs money. Or you're ridiculously high level and you teleport there, or fly on your pegasus or pet dragon, or... you get the picture :-) Again, there will be only one kingdom for at least a year. >> - Objects can have different faces depending on the "scale" >> attribute. I suppose if there isn't a match a default could be used= . >> Those faces can have different (cell) sizes. >> >> That doesn't mean you'd look 10x smaller outdoors, but a little >> smaller. Then I'd go for making the "enhanced" tiles 16 pixels >> rather than 12. > > Is it worth it to have different faces, or just have the client do > rescaling? > > My concern here is that making up lots of images is a big resource > sink. I've seen it through 2 times (from XBM to XPM, and then > from 24x24 to 32x32 image size). In both of of those cases, an > automatic conversion is done as the first pass, but > cleanup/colorization is needed to make them proper. I prefer to have the *possibility* of different faces and mass-resize stuff with bash+gimp (or bash+imagemagick) than lay an edict that it will be done by the client :-) Also, most objects (and I mean almost every single object in the game) will only ever appear on one scale level. Only living things appear on all two (or three)... maybe a few other objects, but I can't think of any right now. (Yes, there is the question of equipment dropped outdoors. I guess I'd just build one single image representing "stuff", and you have to actually look at it so know what it is. And maybe if it's too small, you just simply lose it.) > From what I've seen above, I see a lot of 'new images' > needed. I'm not sure how much work gros has done - maybe there > isn't a lot left to do. But at some point, I start wondering > if instead of having folks work on 3 or 4 new different image > sets if that effort wouldn't be better focused elsewhere (like > having those folks make maps). I'm trying to plan things so that as few new images as possible are needed, and those that are can be made from the existing default set. >> The rationale here is that we're trying to make both movement and >> window size work for what are two almost entirely different games; >> dungeon exploring is one thing and requires one UI, walking around the >> city or road or forest is something else. > > I don't know - I personally don't really have much problem > with 2 different games/scales. Maybe that is just me. The UI > needs are perhaps more different based on the action - selling > items needs a different interface than when I'm adventuring. Let's think in terms of non-game software development. Doing a dungeon, or walking in your house, or interacting in the tavern, working on the workshop, etc, is a "task" UI; you're actually doing something, and the UI needs to support you optimally at that. Walking around outdoors is really a "menu" UI; what you're there for is to select a place to go, to select a task to do. So presenting more choices, in a way that's reasonable, accessible and "rememberable", is the optimal thing to do. And I guess that, really, is the whole motivation for the multi-scale idea. But after this conversation I'm more and more tempted to make it a zoom button on the client. >> We could even go back to Smallworld ways and use 3 scales rather than >> two, I'll put that up for discussion. > > The problem I had with smallworld is that it was just too > small - it started to get to the point that with the number of > dungeons, there was one almost every 5 spaces - it just didn't > feel that good. I get that. But that's what "scale visibility" is for. So those dungeons would simply not be visible on scale level 3 (travel). How you actually get to the dungeon depends... - If doing per-map scale attribute: then you'll walk around in scale 3, until you find an entrance to a "forest" map, which is scale 2, and in this forest there may be one or more dungeons. - Or if doing client zoom button... then scale 3 will simply help you find the forest more easily, at which point you zoom to 2 in order to find the actual dungeon. (Cool side effect: there could be some abandoned treasure just lying around, which you only find if you zoom in to 1 in unexpected places...) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/