From mwedel at sonic.net Sun Apr 3 00:18:29 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Apr 3 00:19:24 2005 Subject: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <424BEDA8.3020107@telus.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> <42497134.6060109@telus.net> <424A58B6.8070703@sonic.net> <424AAB8B.9000800@telus.net> <424BAE77.6020500@sonic.net> <424BEDA8.3020107@telus.net> Message-ID: <424F8AB5.8090906@sonic.net> Alex Schultz wrote: > >> But the issue is that the way a cone propogates, it will put multiple >> burning spell effects per space. So cone spells will become much >> brighter than before (and big spells could have upwards of 10-20 spell >> effects on a space due to the way the expand). So in these cases, >> these spells then become much brighter (this is also ignoring the fact >> that a fireball also covers a 8 space wide area) >> > Ah, so bolts some others are fine, it's just mainly the cone spells... > yes that is a problem. Wouldn't that also mean that cone spells are more > powerful at farther away distances? Is this intentional. I don't remember the details, but I don't believe they get more powerful as they get farther. However, the core of the cone certainly is more potentent than the edges, and that is intentional. > Yeah, forgot about it dropping remainders like that, however I could fix > that with some casting etc. Using floats for storing that might work > well, and adding a greater number of lighting levels like you proposed > in the other topic would fix most of these problems other than the > misnaming. right - more levels fixes the problem in a sense you just select a higher brightness for the desired effect. Also, it is worth noting that the client actually takes single byte values for the light level (range of 0-255). However, the fact that only 4 light levels are really recognized are sort of done in the calculation - there is no good reason for that, as more light levels break that. > Possibly, but I'm not sure what the best place in the code to convert it > would be. I know a couple places that it would work, but those would > recalculate it more than needed. Best place is at load time. If for example we change 'glow_radius' to be called 'brightness' or some other name (light_level?), then at load time is easiest, because you just get rid of the glow_radius field all together. If at load time, you find a line that is called 'glow_radius', you do what the necessary conversion is and store it in the light_level field of the object structure. Thus, it only needs to be recalculated _once_ whenever the original map is loaded (when the map is swapped out to disk, it won't save a glow_radius field because it won't know about it). > >> The other thought is the light levels could be precalculated, and >> thus desired light levels set up. For example, for a 3x3 light, could >> set up a table like: >> > It would be faster and many of these issues could be dealt with outside > of the code; My tests have shown that amount of processor power used by > by the formula is rather insignificant, but using a lookup table has > other merits. However a lookup table does become more cumbersome if we > implement a greater number of lighting levels as you proposed. To a minor extent, it does become a little more cumbersome. However, there has to be a finite levels of light sources. To some extent, this is just on the basis of calculations - you really don't want a '100' light level that illuminates a 50 square radius - that does become costly to calculated, and probably isn't really desirable. Also, it is worth noting that the various tables could easily be machine calculated, use those values for initially, and then refine them as needed. However, there also has to be some recognition that with brighter light levels, a bright light should fully illuminate several spaces, eg, if you have a 'brightness 10' light, then probably something like a 3 space diameter should be fully illuminated. A real life example would be a light in your house in the corner of the room - while the light isn't as bright at the other side of the room, it is effectively 'bright enough' to the extent the other area of the room isn't dark. OTOH, if we want the client to do smarter lighting, doing such things gets pretty difficult - some firm idea of how a light behaves would be necessary. From alex_sch at telus.net Sun Apr 3 09:44:56 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sun Apr 3 09:45:28 2005 Subject: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <424F8AB5.8090906@sonic.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> <42497134.6060109@telus.net> <424A58B6.8070703@sonic.net> <424AAB8B.9000800@telus.net> <424BAE77.6020500@sonic.net> <424BEDA8.3020107@telus.net> <424F8AB5.8090906@sonic.net> Message-ID: <42500168.2070106@telus.net> Mark Wedel wrote: > Alex Schultz wrote: > >> >>> But the issue is that the way a cone propogates, it will put >>> multiple burning spell effects per space. So cone spells will >>> become much brighter than before (and big spells could have upwards >>> of 10-20 spell effects on a space due to the way the expand). So in >>> these cases, these spells then become much brighter (this is also >>> ignoring the fact that a fireball also covers a 8 space wide area) >>> >> Ah, so bolts some others are fine, it's just mainly the cone >> spells... yes that is a problem. Wouldn't that also mean that cone >> spells are more powerful at farther away distances? Is this intentional. > > > I don't remember the details, but I don't believe they get more > powerful as they get farther. However, the core of the cone certainly > is more potentent than the edges, and that is intentional. Interesting... I just did some tests (with dragonbreath) and the center of the cone being more powerful at the center, it's also brighter at the center under my patch, however it is too bright overall. I was about to say that we could just tweak the spell effect's glow_radius, however that is already 1, so perhaps I should omit additive lighting from this patch and wait till we have the greater number of lighting levels (and perhaps floats should be allowed in an object's glow_radius in the process for spell effects that often overlap). Do you agree? > Also, it is worth noting that the client actually takes single byte > values for the light level (range of 0-255). However, the fact that > only 4 light levels are really recognized are sort of done in the > calculation - there is no good reason for that, as more light levels > break that. Hmm... though that's currently slightly wasteful bandwidth wise, it is a nice thing for expanding, in that less would need to be changed in the lower level protocol to add more lighting levels. >> Possibly, but I'm not sure what the best place in the code to convert >> it would be. I know a couple places that it would work, but those >> would recalculate it more than needed. > > > Best place is at load time. I agree. I just don't know exactly where in the code that is :-P as I haven't looked very far outside of where I've needed to look to make the patch so far, but it shouldn't be too hard to find. > If for example we change 'glow_radius' to be called 'brightness' or > some other name (light_level?), then at load time is easiest, because > you just get rid of the glow_radius field all together. If at load > time, you find a line that is called 'glow_radius', you do what the > necessary conversion is and store it in the light_level field of the > object structure. Thus, it only needs to be recalculated _once_ > whenever the original map is loaded (when the map is swapped out to > disk, it won't save a glow_radius field because it won't know about it). Good idea, I'll begin working on implementation this conversion soon. However one issue is whether the radius of the lit area (area that doesn't round to zero) should be as far from the center as the flat side of the old square lighting, or should the new radius be equal to the radius to the corner of the old square, or should it be inbetween? _________ | | | | | | As in, should the new circle fit inside the old box, should the old box fit inside the new circle, or somewhere inbetween? | | |_________| >>> The other thought is the light levels could be precalculated, and >>> thus desired light levels set up. For example, for a 3x3 light, >>> could set up a table like: >>> >> It would be faster and many of these issues could be dealt with >> outside of the code; My tests have shown that amount of processor >> power used by by the formula is rather insignificant, but using a >> lookup table has other merits. However a lookup table does become >> more cumbersome if we implement a greater number of lighting levels >> as you proposed. > > > To a minor extent, it does become a little more cumbersome. However, > there has to be a finite levels of light sources. To some extent, > this is just on the basis of calculations - you really don't want a > '100' light level that illuminates a 50 square radius - that does > become costly to calculated, and probably isn't really desirable. > > Also, it is worth noting that the various tables could easily be > machine calculated, use those values for initially, and then refine > them as needed. True, though I think it would be nicest to use a lookup table but have some code define it based upon the formula when the server first starts up. --Alex Schultz (aka Rednaxela) From mwedel at sonic.net Mon Apr 4 02:26:47 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Apr 4 02:27:38 2005 Subject: Lighting changes, was Re: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <42500168.2070106@telus.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> <42497134.6060109@telus.net> <424A58B6.8070703@sonic.net> <424AAB8B.9000800@telus.net> <424BAE77.6020500@sonic.net> <424BEDA8.3020107@telus.net> <424F8AB5.8090906@sonic.net> <42500168.2070106@telus.net> Message-ID: <4250EC37.4010109@sonic.net> Alex Schultz wrote: >> >> I don't remember the details, but I don't believe they get more >> powerful as they get farther. However, the core of the cone certainly >> is more potentent than the edges, and that is intentional. > > > Interesting... I just did some tests (with dragonbreath) and the center > of the cone being more powerful at the center, it's also brighter at the > center under my patch, however it is too bright overall. I was about to > say that we could just tweak the spell effect's glow_radius, however > that is already 1, so perhaps I should omit additive lighting from this > patch and wait till we have the greater number of lighting levels (and > perhaps floats should be allowed in an object's glow_radius in the > process for spell effects that often overlap). Do you agree? Not 100% sure what you're saying. If you are saying to store the intermediate results in floats, no problems there. If the idea is to change glow_radius (which really needs a new name) to a float, that could be done. Could be a little confusing what it really means however (that may just be a question of documentation). For example, if you have a 'brightness 0.2' object, what effect does it have if it is just by itself? > >> Also, it is worth noting that the client actually takes single byte >> values for the light level (range of 0-255). However, the fact that >> only 4 light levels are really recognized are sort of done in the >> calculation - there is no good reason for that, as more light levels >> break that. > > > Hmm... though that's currently slightly wasteful bandwidth wise, it is a > nice thing for expanding, in that less would need to be changed in the > lower level protocol to add more lighting levels. Well, right now, the server convers the 4 current light levels to an integer (0,64, 128, 192, 255) and sends that as the light level to the client. So right now, that is somewhat wastefull, but was forward enough thinking that the protocl doesn't need to be changed for new light levels. >> >> Best place is at load time. > > > I agree. I just don't know exactly where in the code that is :-P as I > haven't looked very far outside of where I've needed to look to make the > patch so far, but it shouldn't be too hard to find. common/loader.l - find the glow_radius line. > > Good idea, I'll begin working on implementation this conversion soon. > However one issue is whether the radius of the lit area (area that > doesn't round to zero) should be as far from the center as the flat side > of the old square lighting, or should the new radius be equal to the > radius to the corner of the old square, or should it be inbetween? > _________ > | | > | | > | | As in, should the new circle fit inside the old box, > should the old box fit inside the new circle, or somewhere inbetween? > | | > |_________| The calculated field (circle) should fit inside the square - in other words, the corners of the square won't be illuminated. IMO, that will have less bad side effects - however, there is probably no perfect answer. I could see that the scenario that the map designer selected a light level with the intention of the corner being illuminated that thus visible, and what I say above breaks that. However, there could also be a case where a map maker intentionally put something out of the light, and increase the range of light could break that. One thought I also had is that perhaps the map darkness (perhaps better renamed ambiant_light) represents just that - the ambiant light level of the map. The idea being is that something like a tavern may not be truly dark, but could have a somewhat dim overall look. You bring a torch in, you light up the area around you, but the torch range is the same as normal. An underground map could have an ambiant light level of 0, representing no light at all. currently, the darkness field in the map represents how far one can see without any other light - that is sort of an odd definition - at dusk (or during a full moon) it can be somewhat dark, but one can still see a long ways - just everything is darker during the daytime. I think the ambiant light level would be a nice way to add some atmosphere to more maps. From alex_sch at telus.net Mon Apr 4 07:40:57 2005 From: alex_sch at telus.net (Alex Schultz) Date: Mon Apr 4 07:41:40 2005 Subject: Lighting changes, was Re: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <4250EC37.4010109@sonic.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> <42497134.6060109@telus.net> <424A58B6.8070703@sonic.net> <424AAB8B.9000800@telus.net> <424BAE77.6020500@sonic.net> <424BEDA8.3020107@telus.net> <424F8AB5.8090906@sonic.net> <42500168.2070106@telus.net> <4250EC37.4010109@sonic.net> Message-ID: <425135D9.3020001@telus.net> Mark Wedel wrote: >> Interesting... I just did some tests (with dragonbreath) and the >> center of the cone being more powerful at the center, it's also >> brighter at the center under my patch, however it is too bright >> overall. I was about to say that we could just tweak the spell >> effect's glow_radius, however that is already 1, so perhaps I should >> omit additive lighting from this patch and wait till we have the >> greater number of lighting levels (and perhaps floats should be >> allowed in an object's glow_radius in the process for spell effects >> that often overlap). Do you agree? > > Not 100% sure what you're saying. If you are saying to store the > intermediate results in floats, no problems there. > > If the idea is to change glow_radius (which really needs a new name) > to a float, that could be done. Could be a little confusing what it > really means however (that may just be a question of documentation). > For example, if you have a 'brightness 0.2' object, what effect does > it have if it is just by itself? The reason you might be confused is because I was sort of asking two things: -Should I remove additive lighting from my circular lighting patch and make it a separate patch for after a greater number of lighting levels in implemented? -Or should I change glow_radius to a float and give bright cone spells a smaller glow_radius that way? Each of those is a solution to this cone spell problem, but I'm currently leaning to making glow_radius a float at the moment. A glow_radius 0.2 object wouldn't have any affect on it's own due to rounding, however a stack of 0.2 glow_radius objects would due to this additive behavior and it would be ideal to fix the additive lighting for cone spells. (btw. I don't see why glow_radius would need a new name after I put the conversion code in.) >>> Also, it is worth noting that the client actually takes single >>> byte values for the light level (range of 0-255). However, the fact >>> that only 4 light levels are really recognized are sort of done in >>> the calculation - there is no good reason for that, as more light >>> levels break that. >> >> >> Hmm... though that's currently slightly wasteful bandwidth wise, it >> is a nice thing for expanding, in that less would need to be changed >> in the lower level protocol to add more lighting levels. > > > Well, right now, the server convers the 4 current light levels to an > integer (0,64, 128, 192, 255) and sends that as the light level to the > client. So right now, that is somewhat wastefull, but was forward > enough thinking that the protocl doesn't need to be changed for new > light levels. Yup. >> >> >> I agree. I just don't know exactly where in the code that is :-P as >> I haven't looked very far outside of where I've needed to look to >> make the patch so far, but it shouldn't be too hard to find. > > common/loader.l - find the glow_radius line. Thanks, I'll get to implementing the conversion from glow_radius there as soon as I get a chance (however I am rather busy this week, so it might have to wait till next week). > The calculated field (circle) should fit inside the square - in other > words, the corners of the square won't be illuminated. > > IMO, that will have less bad side effects - however, there is > probably no perfect answer. I could see that the scenario that the > map designer selected a light level with the intention of the corner > being illuminated that thus visible, and what I say above breaks that. > > However, there could also be a case where a map maker intentionally > put something out of the light, and increase the range of light could > break that. > Yeah, though I think it's fairly safe, because pretty much every map I've saw where lights are specifically placed to illuminate a certain square, illuminate it from a straight 90 degree angle from the light, and not at a diagonal. > One thought I also had is that perhaps the map darkness (perhaps > better renamed ambiant_light) represents just that - the ambiant light > level of the map. > > The idea being is that something like a tavern may not be truly dark, > but could have a somewhat dim overall look. You bring a torch in, you > light up the area around you, but the torch range is the same as normal. > > An underground map could have an ambiant light level of 0, > representing no light at all. > > currently, the darkness field in the map represents how far one can > see without any other light - that is sort of an odd definition - at > dusk (or during a full moon) it can be somewhat dark, but one can > still see a long ways - just everything is darker during the > daytime. I think the ambiant light level would be a nice way to add > some atmosphere to more maps. Indeed, the current darkness field does have a rather odd definition. --Alex Schultz (aka Rednaxela) From mikeeusaaa at yahoo.com Mon Apr 4 11:24:34 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon Apr 4 11:26:40 2005 Subject: Lighting changes, was Re: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <4250EC37.4010109@sonic.net> Message-ID: <20050404162435.85867.qmail@web61008.mail.yahoo.com> I completley agree with the ambient light. Now should darkness be converted into the correct ambient light value at map load or should these 2 things be sepreate? --- Mark Wedel wrote: > Alex Schultz wrote: > >> > >> I don't remember the details, but I don't > believe they get more > >> powerful as they get farther. However, the core > of the cone certainly > >> is more potentent than the edges, and that is > intentional. > > > > > > Interesting... I just did some tests (with > dragonbreath) and the center > > of the cone being more powerful at the center, > it's also brighter at the > > center under my patch, however it is too bright > overall. I was about to > > say that we could just tweak the spell effect's > glow_radius, however > > that is already 1, so perhaps I should omit > additive lighting from this > > patch and wait till we have the greater number of > lighting levels (and > > perhaps floats should be allowed in an object's > glow_radius in the > > process for spell effects that often overlap). Do > you agree? > > Not 100% sure what you're saying. If you are > saying to store the intermediate > results in floats, no problems there. > > If the idea is to change glow_radius (which really > needs a new name) to a > float, that could be done. Could be a little > confusing what it really means > however (that may just be a question of > documentation). For example, if you > have a 'brightness 0.2' object, what effect does it > have if it is just by itself? > > > > >> Also, it is worth noting that the client > actually takes single byte > >> values for the light level (range of 0-255). > However, the fact that > >> only 4 light levels are really recognized are > sort of done in the > >> calculation - there is no good reason for that, > as more light levels > >> break that. > > > > > > Hmm... though that's currently slightly wasteful > bandwidth wise, it is a > > nice thing for expanding, in that less would need > to be changed in the > > lower level protocol to add more lighting levels. > > Well, right now, the server convers the 4 current > light levels to an integer > (0,64, 128, 192, 255) and sends that as the light > level to the client. So right > now, that is somewhat wastefull, but was forward > enough thinking that the > protocl doesn't need to be changed for new light > levels. > > >> > >> Best place is at load time. > > > > > > I agree. I just don't know exactly where in the > code that is :-P as I > > haven't looked very far outside of where I've > needed to look to make the > > patch so far, but it shouldn't be too hard to > find. > > common/loader.l - find the glow_radius line. > > > > > Good idea, I'll begin working on implementation > this conversion soon. > > However one issue is whether the radius of the lit > area (area that > > doesn't round to zero) should be as far from the > center as the flat side > > of the old square lighting, or should the new > radius be equal to the > > radius to the corner of the old square, or should > it be inbetween? > > _________ > > | | > > | | > > | | As in, should the new circle fit > inside the old box, > > should the old box fit inside the new circle, or > somewhere inbetween? > > | | > > |_________| > > The calculated field (circle) should fit inside > the square - in other words, > the corners of the square won't be illuminated. > > IMO, that will have less bad side effects - > however, there is probably no > perfect answer. I could see that the scenario that > the map designer selected a > light level with the intention of the corner being > illuminated that thus > visible, and what I say above breaks that. > > However, there could also be a case where a map > maker intentionally put > something out of the light, and increase the range > of light could break that. > > One thought I also had is that perhaps the map > darkness (perhaps better > renamed ambiant_light) represents just that - the > ambiant light level of the map. > > The idea being is that something like a tavern may > not be truly dark, but > could have a somewhat dim overall look. You bring a > torch in, you light up the > area around you, but the torch range is the same as > normal. > > An underground map could have an ambiant light > level of 0, representing no > light at all. > > currently, the darkness field in the map > represents how far one can see > without any other light - that is sort of an odd > definition - at dusk (or during > a full moon) it can be somewhat dark, but one can > still see a long ways - just > everything is darker during the daytime. I think > the ambiant light level > would be a nice way to add some atmosphere to more > maps. > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs From mikeeusaaa at yahoo.com Mon Apr 4 11:24:41 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon Apr 4 11:26:44 2005 Subject: Lighting changes, was Re: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <4250EC37.4010109@sonic.net> Message-ID: <20050404162441.11193.qmail@web61001.mail.yahoo.com> I completley agree with the ambient light. Now should darkness be converted into the correct ambient light value at map load or should these 2 things be sepreate? --- Mark Wedel wrote: > Alex Schultz wrote: > >> > >> I don't remember the details, but I don't > believe they get more > >> powerful as they get farther. However, the core > of the cone certainly > >> is more potentent than the edges, and that is > intentional. > > > > > > Interesting... I just did some tests (with > dragonbreath) and the center > > of the cone being more powerful at the center, > it's also brighter at the > > center under my patch, however it is too bright > overall. I was about to > > say that we could just tweak the spell effect's > glow_radius, however > > that is already 1, so perhaps I should omit > additive lighting from this > > patch and wait till we have the greater number of > lighting levels (and > > perhaps floats should be allowed in an object's > glow_radius in the > > process for spell effects that often overlap). Do > you agree? > > Not 100% sure what you're saying. If you are > saying to store the intermediate > results in floats, no problems there. > > If the idea is to change glow_radius (which really > needs a new name) to a > float, that could be done. Could be a little > confusing what it really means > however (that may just be a question of > documentation). For example, if you > have a 'brightness 0.2' object, what effect does it > have if it is just by itself? > > > > >> Also, it is worth noting that the client > actually takes single byte > >> values for the light level (range of 0-255). > However, the fact that > >> only 4 light levels are really recognized are > sort of done in the > >> calculation - there is no good reason for that, > as more light levels > >> break that. > > > > > > Hmm... though that's currently slightly wasteful > bandwidth wise, it is a > > nice thing for expanding, in that less would need > to be changed in the > > lower level protocol to add more lighting levels. > > Well, right now, the server convers the 4 current > light levels to an integer > (0,64, 128, 192, 255) and sends that as the light > level to the client. So right > now, that is somewhat wastefull, but was forward > enough thinking that the > protocl doesn't need to be changed for new light > levels. > > >> > >> Best place is at load time. > > > > > > I agree. I just don't know exactly where in the > code that is :-P as I > > haven't looked very far outside of where I've > needed to look to make the > > patch so far, but it shouldn't be too hard to > find. > > common/loader.l - find the glow_radius line. > > > > > Good idea, I'll begin working on implementation > this conversion soon. > > However one issue is whether the radius of the lit > area (area that > > doesn't round to zero) should be as far from the > center as the flat side > > of the old square lighting, or should the new > radius be equal to the > > radius to the corner of the old square, or should > it be inbetween? > > _________ > > | | > > | | > > | | As in, should the new circle fit > inside the old box, > > should the old box fit inside the new circle, or > somewhere inbetween? > > | | > > |_________| > > The calculated field (circle) should fit inside > the square - in other words, > the corners of the square won't be illuminated. > > IMO, that will have less bad side effects - > however, there is probably no > perfect answer. I could see that the scenario that > the map designer selected a > light level with the intention of the corner being > illuminated that thus > visible, and what I say above breaks that. > > However, there could also be a case where a map > maker intentionally put > something out of the light, and increase the range > of light could break that. > > One thought I also had is that perhaps the map > darkness (perhaps better > renamed ambiant_light) represents just that - the > ambiant light level of the map. > > The idea being is that something like a tavern may > not be truly dark, but > could have a somewhat dim overall look. You bring a > torch in, you light up the > area around you, but the torch range is the same as > normal. > > An underground map could have an ambiant light > level of 0, representing no > light at all. > > currently, the darkness field in the map > represents how far one can see > without any other light - that is sort of an odd > definition - at dusk (or during > a full moon) it can be somewhat dark, but one can > still see a long ways - just > everything is darker during the daytime. I think > the ambiant light level > would be a nice way to add some atmosphere to more > maps. > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs From meaje at meanspc.com Mon Apr 4 16:29:53 2005 From: meaje at meanspc.com (Jeffrey D. Means) Date: Mon Apr 4 16:45:29 2005 Subject: [crossfire] CVS and lighting patches Message-ID: <1112650193.25295.46.camel@jeff-w.meanspc.com> #1) I'm getting a strange error message about automake when trying to compile: [meaje@jeff-w crossfire]$ make cd . && /bin/sh /home/meaje/setup/crossfire/server/crossfire/utils/missing --run automake-1.9 --gnu automake-1.9: `configure.ac' and `configure.in' both present. automake-1.9: proceeding with `configure.ac'. configure.ac:7: version mismatch. This is Automake 1.9.2, configure.ac:7: but the definition used by this AM_INIT_AUTOMAKE configure.ac:7: comes from Automake 1.9.5. You should recreate configure.ac:7: aclocal.m4 with aclocal and run automake again. make: *** [Makefile.in] Error 1 How do I solve this issue? --------------------------------------------------- #2) What patch command do I need to use to apply the light_arches.diff patch? I have tried 'patch -p1 <...' and 'patch -p0<...' with no success. -- Jeffrey D. Means meaje@meanspc.com Owner / CIO for MeansPC http://www.meanspc.com/ Custom Web Development For Your Needs. (970)308-1298 My Public PGP Key ID is: 0x81F00126 and available via: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x81F00126 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050404/faabbc04/attachment.pgp From mikeeusaaa at yahoo.com Mon Apr 4 19:30:43 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon Apr 4 19:32:45 2005 Subject: [crossfire] Resignation Message-ID: <20050405003043.53854.qmail@web61006.mail.yahoo.com> I, hereby, symbolically resign from the opensource project crossfire due to the constant derision of my works from the boy known as "aaron". He constantly belittles me and what I have contributed to the game while he has given nothing but lies alluding to him someday adding something to the CF universe. AAron I hope you fall off a cliff you bitch. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From fuchs.andy at gmail.com Mon Apr 4 20:40:25 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon Apr 4 20:40:45 2005 Subject: [crossfire] Layers need to be upped from 3 In-Reply-To: <20050331151920.40896.qmail@web61006.mail.yahoo.com> References: <20050331151920.40896.qmail@web61006.mail.yahoo.com> Message-ID: On Mar 31, 2005 10:19 AM, Mitch Obrian wrote: > Currently only 3 image layers are displayed on the > screen... could this be upped? It causes visual > problems when stacking some Items to create the > desired effect. > Perhapse 5 or 6 or even more is better? Ran into this 'problem' also: >half grate wall >regular wall >half grate wall >floor added RFE: http://sourceforge.net/tracker/index.php?func=detail&aid=1176737&group_id=13833&atid=363833 -- -- Andrew Fuchs From alex_sch at telus.net Mon Apr 4 22:13:27 2005 From: alex_sch at telus.net (Alex Schultz) Date: Mon Apr 4 22:14:46 2005 Subject: [crossfire] CVS and lighting patches In-Reply-To: <1112650193.25295.46.camel@jeff-w.meanspc.com> References: <1112650193.25295.46.camel@jeff-w.meanspc.com> Message-ID: <42520257.7050307@telus.net> Jeffrey D. Means wrote: >#1) >I'm getting a strange error message about automake when trying to >compile: > [meaje@jeff-w crossfire]$ make > cd . > && /bin/sh /home/meaje/setup/crossfire/server/crossfire/utils/missing --run automake-1.9 --gnu > automake-1.9: `configure.ac' and `configure.in' both present. > automake-1.9: proceeding with `configure.ac'. > configure.ac:7: version mismatch. This is Automake 1.9.2, > configure.ac:7: but the definition used by this AM_INIT_AUTOMAKE > configure.ac:7: comes from Automake 1.9.5. You should recreate > configure.ac:7: aclocal.m4 with aclocal and run automake again. > make: *** [Makefile.in] Error 1 > >How do I solve this issue? >--------------------------------------------------- > > Weird :-/ don't know why that's happening. Don't know much about the build process, but that it's happening for me, and I don't use any library calls etc. that it doesn't already use. >#2) >What patch command do I need to use to apply the light_arches.diff >patch? I have tried 'patch -p1 <...' and 'patch -p0<...' with no >success. > > That's for the arches as in: http://cvs.sourceforge.net/viewcvs.py/crossfire/arch/ Not for: http://cvs.sourceforge.net/viewcvs.py/crossfire/crossfire/ However, the other patch already includes the changes in /crossfire/lib/archetypes stuff that corresponds to it. --Alex Schultz (aka Rednaxela) From mwedel at sonic.net Tue Apr 5 00:30:53 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Apr 5 00:31:43 2005 Subject: [crossfire] CVS and lighting patches In-Reply-To: <1112650193.25295.46.camel@jeff-w.meanspc.com> References: <1112650193.25295.46.camel@jeff-w.meanspc.com> Message-ID: <4252228D.1050103@sonic.net> Jeffrey D. Means wrote: > #1) > I'm getting a strange error message about automake when trying to > compile: > [meaje@jeff-w crossfire]$ make > cd . > && /bin/sh /home/meaje/setup/crossfire/server/crossfire/utils/missing --run automake-1.9 --gnu > automake-1.9: `configure.ac' and `configure.in' both present. > automake-1.9: proceeding with `configure.ac'. > configure.ac:7: version mismatch. This is Automake 1.9.2, > configure.ac:7: but the definition used by this AM_INIT_AUTOMAKE > configure.ac:7: comes from Automake 1.9.5. You should recreate > configure.ac:7: aclocal.m4 with aclocal and run automake again. > make: *** [Makefile.in] Error 1 > > How do I solve this issue? Easiest is to do ./autogen.sh References: <20050404162435.85867.qmail@web61008.mail.yahoo.com> Message-ID: <4252239F.5000401@sonic.net> Mitch Obrian wrote: > I completley agree with the ambient light. > Now should darkness be converted into the correct > ambient light value at map load or should these 2 > things be sepreate? There is no way to convert the existing darkness value to an ambiant light level (other than to just convert them it to ambiant_light 0, or when the case is darkness value == max darkness level). The question might really be whether this is any reason to keep the existing darkness value and/or if a different meaning of the field is desired. From mwedel at sonic.net Tue Apr 5 00:50:41 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Apr 5 00:50:48 2005 Subject: Lighting changes, was Re: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <425135D9.3020001@telus.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> <42497134.6060109@telus.net> <424A58B6.8070703@sonic.net> <424AAB8B.9000800@telus.net> <424BAE77.6020500@sonic.net> <424BEDA8.3020107@telus.net> <424F8AB5.8090906@sonic.net> <42500168.2070106@telus.net> <4250EC37.4010109@sonic.net> <425135D9.3020001@telus.net> Message-ID: <42522731.1000700@sonic.net> Alex Schultz wrote:> > The reason you might be confused is because I was sort of asking two > things: > -Should I remove additive lighting from my circular lighting patch and > make it a separate patch for after a greater number of lighting levels > in implemented? Probably best. > -Or should I change glow_radius to a float and give bright cone spells a > smaller glow_radius that way? I'm a bit reluctant to make such a change, which means changing a bunch of archs, when we sort of know that lighting will be changing (the light levels may be less an issue at that point) > > Each of those is a solution to this cone spell problem, but I'm > currently leaning to making glow_radius a float at the moment. A > glow_radius 0.2 object wouldn't have any affect on it's own due to > rounding, however a stack of 0.2 glow_radius objects would due to this > additive behavior and it would be ideal to fix the additive lighting for > cone spells. > > (btw. I don't see why glow_radius would need a new name after I put the > conversion code in.) A new name is needed because you'd never easily know if the values in the map have in fact been converted. This could easily result in the same map being converted multiple times, resulting in ever increasing glow_radius. A possible solution is to then unconvert it at map save. But if the value being used doesn't match the proper behaviour, the more proper approach would be to modify the behaviour of the formula/whatever to do the right thing, and not try to adjust the values. One case I can see this being a potential problem in general cases is if the dm creates an item - the brigthness they set won't match the one converted at load time, and thus be different. Script actions could be another case of this diferent behaviour. The other point is map makers must be allowed some variable they can set that won't be adjusted. This is a lesson that has been learned in the past - what inevitably happens is values that are auto adjusted cause more problems and confusion for map makers. From alex_sch at telus.net Tue Apr 5 07:38:47 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue Apr 5 07:38:51 2005 Subject: Lighting changes, was Re: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <42522731.1000700@sonic.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> <42497134.6060109@telus.net> <424A58B6.8070703@sonic.net> <424AAB8B.9000800@telus.net> <424BAE77.6020500@sonic.net> <424BEDA8.3020107@telus.net> <424F8AB5.8090906@sonic.net> <42500168.2070106@telus.net> <4250EC37.4010109@sonic.net> <425135D9.3020001@telus.net> <42522731.1000700@sonic.net> Message-ID: <425286D7.1020708@telus.net> Mark Wedel wrote: > Alex Schultz wrote:> > >> The reason you might be confused is because I was sort of asking two >> things: >> -Should I remove additive lighting from my circular lighting patch >> and make it a separate patch for after a greater number of lighting >> levels in implemented? > > > Probably best. Ok. >> Each of those is a solution to this cone spell problem, but I'm >> currently leaning to making glow_radius a float at the moment. A >> glow_radius 0.2 object wouldn't have any affect on it's own due to >> rounding, however a stack of 0.2 glow_radius objects would due to >> this additive behavior and it would be ideal to fix the additive >> lighting for cone spells. >> >> (btw. I don't see why glow_radius would need a new name after I put >> the conversion code in.) > > > A new name is needed because you'd never easily know if the values in > the map have in fact been converted. This could easily result in the > same map being converted multiple times, resulting in ever increasing > glow_radius. A possible solution is to then unconvert it at map save. > But if the value being used doesn't match the proper behaviour, the > more proper approach would be to modify the behaviour of the > formula/whatever to do the right thing, and not try to adjust the > values. One case I can see this being a potential problem in general > cases is if the dm creates an item - the brigthness they set won't > match the one converted at load time, and thus be different. Script > actions could be another case of this diferent behaviour. > > The other point is map makers must be allowed some variable they can > set that won't be adjusted. This is a lesson that has been learned in > the past - what inevitably happens is values that are auto adjusted > cause more problems and confusion for map makers. Ok. So should I just build the 'conversion' into the main formula? Also, should I implement a lookup table (generated at server load) right now, or should I leave it as is and add the lookup table eventually later as a separate patch? --Alex Schultz (aka Rednaxela) From andi.vogl at gmx.net Fri Apr 8 07:18:30 2005 From: andi.vogl at gmx.net (Andreas Vogl) Date: Fri Apr 8 07:19:31 2005 Subject: [crossfire] JavaEditor download site Message-ID: <20913.1112962710@www81.gmx.net> I've updated my JavaEditor download site, because the version there was running too much out of date. http://home.in.tum.de/~vogl/CFJavaEditor/index.html As you have probably noticed, I've not been very active updating that site recently, so please use it with awareness that it may run a bit out of date eventually. I can no longer update or maintain my site on mids' server, because I lost access to that account long ago. Suprising that it is still up actually: http://mids.student.utwente.nl/~avogl/ Greetings, AV -- Handyrechnung zu hoch? Tipp: SMS und MMS mit GMX Seien Sie so frei: Alle Infos unter http://www.gmx.net/de/go/freesms From mikeeusaaa at yahoo.com Fri Apr 8 15:07:22 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Apr 8 15:09:49 2005 Subject: [crossfire] Western castle_a (texture+outline added) Please upload to CVS Message-ID: <20050408200722.56869.qmail@web61006.mail.yahoo.com> (Please upload to CVS) Texture and outline added https://cat2.dynu.ca/crossfirearch/castle_a_western.arc https://cat2.dynu.ca/crossfirearch/castle_a_western.base.x11.png https://cat2.dynu.ca/crossfirearch/castle_a_western.base.x12.png __________________________________ Do you Yahoo!? Yahoo! Personals - Better first dates. More second dates. http://personals.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: castle_a_western.arc Type: application/octet-stream Size: 715 bytes Desc: castle_a_western.arc Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050408/fce4bc69/castle_a_western.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: castle_a_western.base.x11.png Type: image/png Size: 3052 bytes Desc: castle_a_western.base.x11.png Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050408/fce4bc69/castle_a_western.base.x11.png -------------- next part -------------- A non-text attachment was scrubbed... Name: castle_a_western.base.x12.png Type: image/png Size: 3054 bytes Desc: castle_a_western.base.x12.png Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050408/fce4bc69/castle_a_western.base.x12.png From fuchs.andy at gmail.com Sun Apr 10 09:44:34 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun Apr 10 09:45:58 2005 Subject: [crossfire] Latest CVS version of java editor SERIOUSLY flawed on my system Message-ID: The latest version of CFJavaEditor in CVS has destroyed 2 of my maps. When saving maps, it writes the file with null contents. -- -- Andrew Fuchs From b.t.lally at warwick.ac.uk Sun Apr 10 11:52:32 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Sun Apr 10 11:35:58 2005 Subject: [crossfire] Latest CVS version of java editor SERIOUSLY flawed on my system In-Reply-To: References: Message-ID: <200504101752.32742.b.t.lally@warwick.ac.uk> On Sunday 10 Apr 2005 15:44, Andrew Fuchs wrote: > The latest version of CFJavaEditor in CVS has destroyed 2 of my maps. > When saving maps, it writes the file with null contents. I have a horrible feeling that might be my fault. I don't know why though. I changed the writing in and out code to stop the stripping of some of the headers, when I tested the changes on my system it worked properly. Can you point to a map that causes this problem (either your own or in CVS)? The ones I tested were ok... I can't figure out what could cause the problem you describe. The only thing I can think of is that the string I am using isn't being initialised properly, so that some random pointer is being written in, but this shouldn't give the null files you describe, it should be random garbage (either that or one of java's ever-present exceptions). In the unlikely event that I am right, I /think/ the answer would look like this: Index: src/cfeditor/MapArchObject.java =================================================================== RCS file: /cvsroot/crossfire/CFJavaEditor/src/cfeditor/MapArchObject.java,v retrieving revision 1.8 diff -C5 -r1.8 MapArchObject.java *** src/cfeditor/MapArchObject.java 7 Apr 2005 23:06:35 -0000 1.8 --- src/cfeditor/MapArchObject.java 10 Apr 2005 16:19:10 -0000 *************** *** 87,97 **** private boolean ultimate_death; // permanent death with instant character deletion private boolean pvp; // PVP combat allowed private String name; // map name (this is the name that appears in the game) private String filename; // name of the map file ! private String region; // the region the map is in private String[] tile_path = new String[MAX_TILE]; // Used with map tiling. 0=north, 1=east, 2=south, 3=west /** * Constructor, set default values * --- 87,97 ---- private boolean ultimate_death; // permanent death with instant character deletion private boolean pvp; // PVP combat allowed private String name; // map name (this is the name that appears in the game) private String filename; // name of the map file ! private String region = new String(); // the region the map is in private String[] tile_path = new String[MAX_TILE]; // Used with map tiling. 0=north, 1=east, 2=south, 3=west /** * Constructor, set default values * AFAICT this runs exactly the same as the current CVS map, but if you (or anyone else experiencing the same problem) can either patch and test with this or give/point me to a test case map where the problem you describe occurs, then I can determine if that is the problem and if this is the solution. If anyone knows better what the problem is, then by all means, do tell. From tchize at myrealbox.com Sun Apr 10 14:50:59 2005 From: tchize at myrealbox.com (tchize) Date: Sun Apr 10 14:52:00 2005 Subject: [crossfire] Latest CVS version of java editor SERIOUSLY flawed on my system In-Reply-To: <200504101752.32742.b.t.lally@warwick.ac.uk> References: <200504101752.32742.b.t.lally@warwick.ac.uk> Message-ID: <200504102151.08246.tchize@myrealbox.com> Just a small java note to Brendan Lally: Uninitialized objects in java does not exist. The compiler prevent this. So you will never get 'garbage' in an Object (like a String). Inside methods, compiler stop on 'variable xy might be used uninitialized' and for class members, all members are initialized to null, unless there is an explicit initial value. If the content of map file contains one or several 'null' (the 4 letters n.u.l.l.) it just means exactly that, the code attempted to convert a null object to a String. Now i don't have time right now to investigate code on where map saving fails, but getting the name of failed maps, and possibly have a copy if not in cvs, would help. Le Dimanche 10 Avril 2005 18:52, Brendan Lally a ?crit : On Sunday 10 Apr 2005 15:44, Andrew Fuchs wrote: > The latest version of CFJavaEditor in CVS has destroyed 2 of my maps. > When saving maps, it writes the file with null contents. I have a horrible feeling that might be my fault. I don't know why though. I changed the writing in and out code to stop the stripping of some of the headers, when I tested the changes on my system it worked properly. Can you point to a map that causes this problem (either your own or in CVS)? The ones I tested were ok... I can't figure out what could cause the problem you describe. The only thing I can think of is that the string I am using isn't being initialised properly, so that some random pointer is being written in, but this shouldn't give the null files you describe, it should be random garbage (either that or one of java's ever-present exceptions). In the unlikely event that I am right, I /think/ the answer would look like this: Index: src/cfeditor/MapArchObject.java =================================================================== RCS file: /cvsroot/crossfire/CFJavaEditor/src/cfeditor/MapArchObject.java,v retrieving revision 1.8 diff -C5 -r1.8 MapArchObject.java *** src/cfeditor/MapArchObject.java 7 Apr 2005 23:06:35 -0000 1.8 --- src/cfeditor/MapArchObject.java 10 Apr 2005 16:19:10 -0000 *************** *** 87,97 **** private boolean ultimate_death; // permanent death with instant character deletion private boolean pvp; // PVP combat allowed private String name; // map name (this is the name that appears in the game) private String filename; // name of the map file ! private String region; // the region the map is in private String[] tile_path = new String[MAX_TILE]; // Used with map tiling. 0=north, 1=east, 2=south, 3=west /** * Constructor, set default values * --- 87,97 ---- private boolean ultimate_death; // permanent death with instant character deletion private boolean pvp; // PVP combat allowed private String name; // map name (this is the name that appears in the game) private String filename; // name of the map file ! private String region = new String(); // the region the map is in private String[] tile_path = new String[MAX_TILE]; // Used with map tiling. 0=north, 1=east, 2=south, 3=west /** * Constructor, set default values * AFAICT this runs exactly the same as the current CVS map, but if you (or anyone else experiencing the same problem) can either patch and test with this or give/point me to a test case map where the problem you describe occurs, then I can determine if that is the problem and if this is the solution. If anyone knows better what the problem is, then by all means, do tell. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050410/5a416c28/attachment.pgp From fuchs.andy at gmail.com Sun Apr 10 16:06:46 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun Apr 10 16:08:01 2005 Subject: [crossfire] Latest CVS version of java editor SERIOUSLY flawed on my system In-Reply-To: <200504102151.08246.tchize@myrealbox.com> References: <200504101752.32742.b.t.lally@warwick.ac.uk> <200504102151.08246.tchize@myrealbox.com> Message-ID: It happens with any map I save using the editor. I was able to create a torrent file (test java vm) with azureus (precompiled, don't want to take the time to compile kde), so it seems as the problem is in the java editor's code, or a different method of creating the file was used. Im going to test with the precompiled editor now. -- -- Andrew Fuchs From kirschbaum at myrealbox.com Sun Apr 10 15:34:46 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sun Apr 10 16:10:00 2005 Subject: [crossfire] Latest CVS version of java editor SERIOUSLY flawed on my system In-Reply-To: <200504102151.08246.tchize@myrealbox.com> References: <200504101752.32742.b.t.lally@warwick.ac.uk> <200504102151.08246.tchize@myrealbox.com> Message-ID: <20050410203446.GA25308@kirschbaum.myrealbox.com> I noticed the following by reviewing the cvs commit messages: The MapArchObject.region field is not explicitly initialized in the constructor. Therefore it will be initialized with null. But the method writeMapArch has the following code in it: | if (region.length() > 0) | stream.write("region "+region+"\n"); That could probably cause a NullPointerException when saving the map, thus leaving behind a incompletely written file. Therefore, the proposed patch seem good to me. But I'd rather write | private String region = ""; // the region the instead of | private String region = new String(); // the region the From fuchs.andy at gmail.com Sun Apr 10 16:14:12 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun Apr 10 16:16:01 2005 Subject: [crossfire] Latest CVS version of java editor SERIOUSLY flawed on my system In-Reply-To: <20050410203446.GA25308@kirschbaum.myrealbox.com> References: <200504101752.32742.b.t.lally@warwick.ac.uk> <200504102151.08246.tchize@myrealbox.com> <20050410203446.GA25308@kirschbaum.myrealbox.com> Message-ID: hmm: $ java -jar *.jar Exception in thread "main" java.lang.UnsupportedClassVersionError: cfeditor/CFJavaEditor (Unsupported major.minor version 49.0) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) at java.net.URLClassLoader.defineClass(URLClassLoader.java:251) at java.net.URLClassLoader.access$100(URLClassLoader.java:55) at java.net.URLClassLoader$1.run(URLClassLoader.java:194) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) -- -- Andrew Fuchs From b.t.lally at warwick.ac.uk Sun Apr 10 18:52:12 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Sun Apr 10 18:34:01 2005 Subject: [crossfire] Latest CVS version of java editor SERIOUSLY flawed on my system In-Reply-To: <20050410203446.GA25308@kirschbaum.myrealbox.com> References: <200504102151.08246.tchize@myrealbox.com> <20050410203446.GA25308@kirschbaum.myrealbox.com> Message-ID: <200504110052.12044.b.t.lally@warwick.ac.uk> On Sunday 10 Apr 2005 21:34, Andreas Kirschbaum wrote: > I noticed the following by reviewing the cvs commit messages: > > The MapArchObject.region field is not explicitly initialized in the > constructor. Therefore it will be initialized with null. But the method > > writeMapArch has the following code in it: > | if (region.length() > 0) > | stream.write("region "+region+"\n"); > > That could probably cause a NullPointerException when saving the map, thus > leaving behind a incompletely written file. ok, but wouldn't that leave a file with the name written on the first line, and nothing below it? > Therefore, the proposed patch seem good to me. But I'd rather write > > | private String region = ""; // the region the > > instead of > > | private String region = new String(); // the region the Forgive my ignorance but what is the difference between those two lines? From b.t.lally at warwick.ac.uk Sun Apr 10 18:51:44 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Sun Apr 10 18:34:07 2005 Subject: [crossfire] Latest CVS version of java editor SERIOUSLY flawed on my system In-Reply-To: <200504102151.08246.tchize@myrealbox.com> References: <200504101752.32742.b.t.lally@warwick.ac.uk> <200504102151.08246.tchize@myrealbox.com> Message-ID: <200504110051.44218.b.t.lally@warwick.ac.uk> On Sunday 10 Apr 2005 20:50, tchize wrote: > Just a small java note to Brendan Lally: > Uninitialized objects in java does not exist. The compiler prevent this. So > you will never get 'garbage' in an Object (like a String). Inside methods, > compiler stop on 'variable xy might be used uninitialized' and for class > members, all members are initialized to null, unless there is an explicit > initial value. This was what I figured whilst writing it initially, that the java compiler would deal with all the bits where I would normally look at calling malloc. I Should've known better than to trust the compiler I guess. I never intend to, I always set out to write java like C, but everytime it draws me in with promises of automagically working, then finds some obscure legalism in the language spec to sucker me with. There is a reason I hate java. :) > If the content of map file contains one or several 'null' (the 4 letters > n.u.l.l.) it just means exactly that, the code attempted to convert a null > object to a String. Ok, so that isn't consistant with the description AFAICT, does that mean my guess is wrong? From b.t.lally at warwick.ac.uk Sun Apr 10 19:12:47 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Sun Apr 10 18:56:03 2005 Subject: [crossfire] Latest CVS version of java editor SERIOUSLY flawed on my system In-Reply-To: <20050410203446.GA25308@kirschbaum.myrealbox.com> References: <200504102151.08246.tchize@myrealbox.com> <20050410203446.GA25308@kirschbaum.myrealbox.com> Message-ID: <200504110112.47158.b.t.lally@warwick.ac.uk> On a hunch I tried the following: grab CVS map-editor; ant; ant run open hall of selection, change region to foo, save as hallofselection2 ok open random world map with no region set, set region to foo, save ok open random world map with no region set, leave region unset, save fails changed the line mentioned, recompiled, repeated the last step, works. This explains why I thought it ok, I tested that my patch could change and set regions properly, but not that it could do nothing properly. The problem only occurs if the region is unset, and stays unset until the file is saved, so I didn't encounter it at all. I've now committed the change to CVS. (in the "" form) I'm sorry for all the hassle this has caused. From eracclists at bellsouth.net Sun Apr 10 19:19:14 2005 From: eracclists at bellsouth.net (ERACC) Date: Sun Apr 10 19:20:03 2005 Subject: [crossfire] Latest CVS version of java editor SERIOUSLY flawed on my system In-Reply-To: <200504110112.47158.b.t.lally@warwick.ac.uk> References: <20050410203446.GA25308@kirschbaum.myrealbox.com> <200504110112.47158.b.t.lally@warwick.ac.uk> Message-ID: <200504101919.14167.eracclists@bellsouth.net> On Sunday 10 April 2005 07:12 pm Brendan Lally wrote: > On a hunch I tried the following: > > grab CVS map-editor; ant; ant run > open hall of selection, change region to foo, save as hallofselection2 > ok > open random world map with no region set, set region to foo, save > ok > open random world map with no region set, leave region unset, save > fails [...] It would be quite nice if the field were a drop down list of all the regions and that field defaulted to a region. Would help with the potential problem of people submitting maps with no region set if there were a default. Or, another thought, have the editor use a drop down list that starts out with "-unset-" as the default region then refuse to save the map without a valid region set. Also, if there is not one, make a plain text file that contains the existing regions that the editor reads from to make it easy to add new regions as they occur. Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 19:12:47 up 88 days, 1:20, 8 users, load average: 0.36, 0.24, 0.19 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers From fuchs.andy at gmail.com Sun Apr 10 19:26:19 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun Apr 10 19:26:31 2005 Subject: [crossfire] Latest CVS version of java editor SERIOUSLY flawed on my system In-Reply-To: <200504101919.14167.eracclists@bellsouth.net> References: <20050410203446.GA25308@kirschbaum.myrealbox.com> <200504110112.47158.b.t.lally@warwick.ac.uk> <200504101919.14167.eracclists@bellsouth.net> Message-ID: On Apr 10, 2005 7:19 PM, ERACC wrote: > It would be quite nice if the field were a drop down list of all the > regions and that field defaulted to a region. Would help with the > potential problem of people submitting maps with no region set if > there were a default. > > Or, another thought, have the editor use a drop down list that starts > out with "-unset-" as the default region then refuse to save the map > without a valid region set. > > Also, if there is not one, make a plain text file that contains the > existing regions that the editor reads from to make it easy to add > new regions as they occur. > Maps with no region set default to the 'wilderness' region. -- -- Andrew Fuchs From b.t.lally at warwick.ac.uk Sun Apr 10 20:09:16 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Sun Apr 10 19:52:02 2005 Subject: [crossfire] Latest CVS version of java editor SERIOUSLY flawed on my system In-Reply-To: <200504101919.14167.eracclists@bellsouth.net> References: <200504110112.47158.b.t.lally@warwick.ac.uk> <200504101919.14167.eracclists@bellsouth.net> Message-ID: <200504110209.16633.b.t.lally@warwick.ac.uk> On Monday 11 Apr 2005 01:19, ERACC wrote: > It would be quite nice if the field were a drop down list of all the > regions and that field defaulted to a region. Would help with the > potential problem of people submitting maps with no region set if > there were a default. If it is unset, the server uses the region with the 'fallback' value set. currently this is the region wilderness, which seems like the sanest one to set it to, as a result, most world maps don't have a region set. The idea of a drop down list is interesting, though I don't know how to do it in java. > Or, another thought, have the editor use a drop down list that starts > out with "-unset-" as the default region then refuse to save the map > without a valid region set. given that most maps (by number, if not complexity) are currently relying on the fallback region I don't think it is needed to refuse to save them, a map out in the wilderness not belonging to any city seems perfectably reasonable. > Also, if there is not one, make a plain text file that contains the > existing regions that the editor reads from to make it easy to add > new regions as they occur. crossfire $ grep "^region \w*$" lib/regions | cut -f 2 -d " " wilderness world creation etc. is there a nice way to sync the output of that command into the map editor? or to apply the same operation to the regions file and symlink into the mapeditor repository? From kirschbaum at myrealbox.com Mon Apr 11 01:31:44 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Mon Apr 11 01:32:06 2005 Subject: [crossfire] Latest CVS version of java editor SERIOUSLY flawed on my system In-Reply-To: <200504110052.12044.b.t.lally@warwick.ac.uk> References: <200504102151.08246.tchize@myrealbox.com> <20050410203446.GA25308@kirschbaum.myrealbox.com> <200504110052.12044.b.t.lally@warwick.ac.uk> Message-ID: <20050411063144.GA26910@kirschbaum.myrealbox.com> Brendan Lally wrote: > ok, but wouldn't that leave a file with the name written on the first line, > and nothing below it? Not necessarily: the caller just does something like try { } catch(IOException e) { ... } That means that the file will not be closed if writeMapArch throws any Exception. And if the virtual machine terminates because of that (NullPointer)Exception, it could be possible that the file may not be closed at all. And since the "file" is a BufferedWriter, the already written first line(s) could be still in the (memory) buffer but not yet written to disk. > > Therefore, the proposed patch seem good to me. But I'd rather write > > > > | private String region = ""; // the region the > > > > instead of > > > > | private String region = new String(); // the region the > > Forgive my ignorance but what is the difference between those two lines? There is no difference. I just find the first alternative more readable. From mwedel at sonic.net Mon Apr 11 01:36:44 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Apr 11 01:38:07 2005 Subject: Lighting changes, was Re: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <425286D7.1020708@telus.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> <42497134.6060109@telus.net> <424A58B6.8070703@sonic.net> <424AAB8B.9000800@telus.net> <424BAE77.6020500@sonic.net> <424BEDA8.3020107@telus.net> <424F8AB5.8090906@sonic.net> <42500168.2070106@telus.net> <4250EC37.4010109@sonic.net> <425135D9.3020001@telus.net> <42522731.1000700@sonic.net> <425286D7.1020708@telus.net> Message-ID: <425A1AFC.8020305@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: > > Ok. So should I just build the 'conversion' into the main formula? > > Also, should I implement a lookup table (generated at server load) right > now, or should I leave it as is and add the lookup table eventually > later as a separate patch? The two questions are somewhat related. IF you do a lookup table, there really isn't much need for a formula then (light is offset by 2,4, so its brigthness is X). Certainly, doing the first pass without a lookup table is easier. However, if you plan to do a lookup table, may be less effort in the long term to do that now so you don't really need a formula. From mikeeusaaa at yahoo.com Mon Apr 11 02:31:48 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon Apr 11 02:32:06 2005 Subject: [crossfire] New furniature (damn you old GF-type that messed up my spelling) Message-ID: <20050411073148.72101.qmail@web61004.mail.yahoo.com> https://cat2.dynu.ca/crossfirearch/ chair_gv_1 chair_cw_1 (gold chairs with velvet cusions from the baroque period and cherry wood chairs) __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From mikeeusaaa at yahoo.com Mon Apr 11 02:56:00 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon Apr 11 02:56:06 2005 Subject: [crossfire] New furniature (damn you old GF-type that messed up my spelling) In-Reply-To: 6667 Message-ID: <20050411075600.77592.qmail@web61003.mail.yahoo.com> The gold chairs will only be found in the richest of places in the richest of kindoms ofcourse. The cherry chairs will be the choice of the wealthy :) please up to cvs if you get the chance. And use these chairs sparsly (especially the gold ones). If anyone has arch requests, I will be happy to try. --- Mitch Obrian wrote: > https://cat2.dynu.ca/crossfirearch/ > > chair_gv_1 > chair_cw_1 > > (gold chairs with velvet cusions from the baroque > period and cherry wood chairs) > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Small Business - Try our new resources site! > http://smallbusiness.yahoo.com/resources/ > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From andi.vogl at gmx.net Mon Apr 11 10:53:02 2005 From: andi.vogl at gmx.net (Andreas Vogl) Date: Mon Apr 11 10:54:10 2005 Subject: [crossfire] JavaEditor download site Message-ID: <25738.1113234782@www30.gmx.net> Obviously I had to update my JavaEditor download site once more, as I don't want to distribute the broken version (which would delete ppls maps). Just wanted to say that it's safe to download from my link again (http://home.in.tum.de/~vogl/CFJavaEditor/), unless other bugs turn up, which I hope not. -- Handyrechnung zu hoch? Tipp: SMS und MMS mit GMX Seien Sie so frei: Alle Infos unter http://www.gmx.net/de/go/freesms From mikeeusaaa at yahoo.com Tue Apr 12 00:17:24 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Apr 12 00:20:18 2005 Subject: [crossfire] New furniature (more) (damn you old GF-type that messed up my spelling) In-Reply-To: 6667 Message-ID: <20050412051724.14773.qmail@web61005.mail.yahoo.com> table_cw_3 chair_bc_2 Nice polished Cherry wood table. Blue satin covered chairs. https://cat2.dynu.ca/crossfirearch/ Please upload to CVS Also I'm taking requests. --- Mitch Obrian wrote: > The gold chairs will only be found in the richest of > places in the richest of kindoms ofcourse. > > The cherry chairs will be the choice of the wealthy > :) > > please up to cvs if you get the chance. And use > these > chairs sparsly (especially the gold ones). > > If anyone has arch requests, I will be happy to try. > > --- Mitch Obrian wrote: > > https://cat2.dynu.ca/crossfirearch/ > > > > chair_gv_1 > > chair_cw_1 > > > > (gold chairs with velvet cusions from the baroque > > period and cherry wood chairs) > > > > > > > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Small Business - Try our new resources > site! > > http://smallbusiness.yahoo.com/resources/ > > > > _______________________________________________ > > crossfire mailing list > > crossfire@metalforge.org > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - You care about security. So do we. > http://promotions.yahoo.com/new_mail > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs From leaf at real-time.com Tue Apr 12 00:39:54 2005 From: leaf at real-time.com (Rick Tanner) Date: Tue Apr 12 00:40:19 2005 Subject: Archtype requests (was Re: [crossfire] New furniature) In-Reply-To: <20050412051724.14773.qmail@web61005.mail.yahoo.com> References: <20050412051724.14773.qmail@web61005.mail.yahoo.com> Message-ID: On Mon, 11 Apr 2005, Mitch Obrian wrote: > > Also I'm taking requests. How about new alchemy graphics, like.. potion bottles balm jars dust flasks and so on .. in different shapes and colors ? From mikeeusaaa at yahoo.com Tue Apr 12 05:54:18 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Apr 12 05:56:22 2005 Subject: Archtype requests (was Re: [crossfire] New furniature) In-Reply-To: 6667 Message-ID: <20050412105418.5293.qmail@web61009.mail.yahoo.com> Ok, I'll see what I can come up with :). --- Rick Tanner wrote: > > On Mon, 11 Apr 2005, Mitch Obrian wrote: > > > > Also I'm taking requests. > > How about new alchemy graphics, like.. > > potion bottles > balm jars > dust > flasks > and so on > > .. in different shapes and colors ? > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From alex_sch at telus.net Tue Apr 12 23:27:51 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue Apr 12 23:28:31 2005 Subject: Lighting changes, was Re: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <425A1AFC.8020305@sonic.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> <42497134.6060109@telus.net> <424A58B6.8070703@sonic.net> <424AAB8B.9000800@telus.net> <424BAE77.6020500@sonic.net> <424BEDA8.3020107@telus.net> <424F8AB5.8090906@sonic.net> <42500168.2070106@telus.net> <4250EC37.4010109@sonic.net> <425135D9.3020001@telus.net> <42522731.1000700@sonic.net> <425286D7.1020708@telus.net> <425A1AFC.8020305@sonic.net> Message-ID: <425C9FC7.3000400@telus.net> Mark Wedel wrote: > IF you do a lookup table, there really isn't much need for a formula > then (light is offset by 2,4, so its brigthness is X). > > Certainly, doing the first pass without a lookup table is easier. > However, if you plan to do a lookup table, may be less effort in the > long term to do that now so you don't really need a formula. Ok... hmmm... I just did some calculations and the conversion (when build right into the formula) effectively neutralizes the inverse square law portion of the formula such that I'm just left with the pythagorean theorm (instead of the max dist in either the x or y axis) and the fixes for negative glow_radiuses and the the old code. The Pythagorean theorem itself is so simple that I don't think that the overhead will make it worth making a lookup table. I'll make a diff for this ASAP. Note however that this assumes no additive lighting again and will have to have the inverse square law code added back in when additive lighting is implemented (which is waiting for a greater number of lighting levels currently). Hopefully there isn't any problems with the upcoming diff getting into CVS. --Alex Schultz (aka Rednaxela) From alex_sch at telus.net Wed Apr 13 08:30:35 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed Apr 13 08:30:36 2005 Subject: Lighting changes, was Re: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <425C9FC7.3000400@telus.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> <42497134.6060109@telus.net> <424A58B6.8070703@sonic.net> <424AAB8B.9000800@telus.net> <424BAE77.6020500@sonic.net> <424BEDA8.3020107@telus.net> <424F8AB5.8090906@sonic.net> <42500168.2070106@telus.net> <4250EC37.4010109@sonic.net> <425135D9.3020001@telus.net> <42522731.1000700@sonic.net> <425286D7.1020708@telus.net> <425A1AFC.8020305@sonic.net> <425C9FC7.3000400@telus.net> Message-ID: <425D1EFB.4080504@telus.net> Alex Schultz wrote: > Ok... hmmm... I just did some calculations and the conversion (when > build right into the formula) effectively neutralizes the inverse > square law portion of the formula such that I'm just left with the > pythagorean theorm (instead of the max dist in either the x or y axis) > and the fixes for negative glow_radiuses and the the old code. The > Pythagorean theorem itself is so simple that I don't think that the > overhead will make it worth making a lookup table. I'll make a diff > for this ASAP. Diff updated on the SF tracker ( http://sourceforge.net/tracker/index.php?func=detail&aid=1171646&group_id=13833&atid=313833 ) Formula adjusted to match proper definition of glow_radius, which also simplified it to the point where a lookup table shouldn't really have a significant speed advantage. Additive lighting also removed (waiting on a greater number of lighting levels). I don't see any reasons now why it can't get into CVS now, but I might be missing something. --Alex Schultz (aka Rednaxela) From nicolas.weeger at laposte.net Thu Apr 14 08:19:40 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu Apr 14 08:24:49 2005 Subject: [crossfire] Strange code in server/weather.c Message-ID: Hello. Browsing weather.c code (yeah, i'm bored at work ^.^;;;), I noticed two strange things: * weathermap_to_worldmap_corner uses malloc() to get memory for the map path, but it isn't freed later on. This can lead to (small) memory leaks at each weather iteration. * in worldmap_to_weathermap( ), this code is weird: char* filename=m->path; <3 lines snipped out> while (*filename == '/') *filename++; It should probably read 'filename++'. Probably not a big issue, but still - changing the map filename is *definitely* not a good idea. If no one does it before me, I'll fix that in the next few days. Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From alex_sch at telus.net Thu Apr 14 14:38:22 2005 From: alex_sch at telus.net (Alex Schultz) Date: Thu Apr 14 14:38:52 2005 Subject: [crossfire] Strange code in server/weather.c In-Reply-To: References: Message-ID: <425EC6AE.7050106@telus.net> Nicolas Weeger wrote: >Browsing weather.c code (yeah, i'm bored at work ^.^;;;), I noticed two strange things... > > Not to mention that the weather code also has lots of // comments according to a grep I did a bit ago... From nicolas.weeger at laposte.net Thu Apr 14 14:42:58 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu Apr 14 14:44:52 2005 Subject: [crossfire] Strange code in server/weather.c In-Reply-To: References: Message-ID: <425EC7C2.1030100@laposte.net> Fixed all that, and changed some char* to const char* when applicable :) (yes, i like "clean" code) Ryo From nicolas.weeger at laposte.net Thu Apr 14 17:00:37 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu Apr 14 17:02:53 2005 Subject: [crossfire] Code (spring) cleaning Message-ID: <425EE805.20901@laposte.net> Hello. There are *many* places in the code where char* are used as arguments, when const char* would be really all right. So I'd like to clean that, to use const char* everywhere this is appropriate. This means many changes in functions in many files. I don't think that would break things. Of course some functions legitimately can use char when needed (to return arguments and so on). In the same topic, some function, many descriptive functions (for items, monsters, and such) use a static char buffer, and return char*. This too imo should be const char*, as you don't control the buffer and shouldn't change it - but that's my opinion. Any objection to the first pass cleaning (argument)? Ryo From mwedel at sonic.net Fri Apr 15 01:28:45 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Apr 15 01:28:58 2005 Subject: [crossfire] Code (spring) cleaning In-Reply-To: <425EE805.20901@laposte.net> References: <425EE805.20901@laposte.net> Message-ID: <425F5F1D.4020800@sonic.net> Nicolas Weeger wrote: > Hello. > > There are *many* places in the code where char* are used as arguments, > when const char* would be really all right. > > So I'd like to clean that, to use const char* everywhere this is > appropriate. > > This means many changes in functions in many files. I don't think that > would break things. Of course some functions legitimately can use char > when needed (to return arguments and so on). > > In the same topic, some function, many descriptive functions (for items, > monsters, and such) use a static char buffer, and return char*. This too > imo should be const char*, as you don't control the buffer and shouldn't > change it - but that's my opinion. > > Any objection to the first pass cleaning (argument)? fine by me. From nicolas.weeger at laposte.net Fri Apr 15 07:41:57 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri Apr 15 07:43:01 2005 Subject: [crossfire] Server release? Message-ID: Hello. It's been almost 3 months since last server release (1.7.0). What about starting to think of a new release? *grin* Most notable improvements is region support, but there were many bug fixes. Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From tchize at myrealbox.com Fri Apr 15 08:06:17 2005 From: tchize at myrealbox.com (tchize@myrealbox.com) Date: Fri Apr 15 08:05:00 2005 Subject: [OT] Re: [crossfire] Server release? In-Reply-To: References: Message-ID: <200504151506.17221.tchize@myrealbox.com> I' can't believe it! You really have nothing to do at work, isn't it? Tchize Le Vendredi 15 Avril 2005 14:41, Nicolas Weeger a ?crit : > Hello. > > It's been almost 3 months since last server release (1.7.0). What about > starting to think of a new release? *grin* > > Most notable improvements is region support, but there were many bug fixes. > > Ryo > > Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; > 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From nicolas.weeger at laposte.net Fri Apr 15 09:42:40 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri Apr 15 09:44:10 2005 Subject: [crossfire] A few random ideas Message-ID: Hello. Here are a few things i'd like to add to Crossfire (and which i may add soon, who knows), giving'em away to get feedback / ideas :) * items combination / use item with item Example one, use apple on knife => sliced apple. Example two, use sliced apple with base pie crust => ready to cook apple pie. Then put it in oven (alchemy-like), except if you fail you just get a burnt pie, no exploding oven! First example, knife doesn't disappear, apple is transformed. Second example, 2 items are merged to make a 3rd one. I think I could possibly do the 2nd stuff with altars - like add a special field that make them disappear when they are activated [i don't think that exists yet?]. Or i'll just make code for that, with a new item type (COMBINABLE_ITEM?), and a field to tell whether the applied item disappears or not. The shortcoming i see for that is that you can only have one single combo - apple gives sliced apple, but you can't get quarters of apple. Hum, what about treasure lists, and player tells what item to generate? Those actions would probably not give any experience, though, they would just give materials. The idea is to use items to make non buyable items, then use those with alchemy, woodsman (i'd like to add cooking, too :p), and so on. And as a side note, something like: drink bottle of water => raises food level, drop empty bottle (need to check if that can't already be done with inventory, maybe). * "harvestable" items Something along the line of "the bee hive makes honey, you can grab it if you have an empty honey pot" (need to apply it standing on / facing the square, probably). This would make it fun to go grab exotic materials for alchemy / cooking / you name it. I'd like to have different graphics/archetypes for that, so that you know when there is something to pick and when there is not, and make some maximum item holding (don't accumulate more than 5 honey units), also regenerating slowly over time with random values. This looks like adapted monster generator, no? :) It could give xp in a specialized skill ("honey harvesting"?). You could then add a difficulty-to-get level, adapted based on skill level, and with a minimum level. Example: mining. You can mine rocks to get ore, but you need to be level 50 to get gold. And the higher you are, the easiest to get ores. * enable alchemy to keep (some) used items Example i see: get melt gold ore, use a ring mould => get a gold ring + the ring mould. Need to think more about that, i guess, i'm not totally convinced myself :) Just a few tossed ideas. But I feel like implementing some soon :) Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From mikeeusaaa at yahoo.com Fri Apr 15 11:37:21 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Apr 15 11:39:03 2005 Subject: [crossfire] A few random ideas In-Reply-To: 6667 Message-ID: <20050415163721.3934.qmail@web61007.mail.yahoo.com> Gold and platinum ore should only be found in limited places in limited supply. We could have a geography/mineral map for each world map maby: Ie you dig in this spot you get x etc. --- Nicolas Weeger wrote: > Hello. > > Here are a few things i'd like to add to Crossfire > (and which i may add soon, who knows), giving'em > away to get feedback / ideas :) > > * items combination / use item with item > Example one, use apple on knife => sliced apple. > Example two, use sliced apple with base pie crust => > ready to cook apple pie. Then put it in oven > (alchemy-like), except if you fail you just get a > burnt pie, no exploding oven! > > First example, knife doesn't disappear, apple is > transformed. > Second example, 2 items are merged to make a 3rd > one. > > I think I could possibly do the 2nd stuff with > altars - like add a special field that make them > disappear when they are activated [i don't think > that exists yet?]. > Or i'll just make code for that, with a new item > type (COMBINABLE_ITEM?), and a field to tell whether > the applied item disappears or not. > The shortcoming i see for that is that you can only > have one single combo - apple gives sliced apple, > but you can't get quarters of apple. Hum, what about > treasure lists, and player tells what item to > generate? > > Those actions would probably not give any > experience, though, they would just give materials. > > The idea is to use items to make non buyable items, > then use those with alchemy, woodsman (i'd like to > add cooking, too :p), and so on. > > And as a side note, something like: drink bottle of > water => raises food level, drop empty bottle (need > to check if that can't already be done with > inventory, maybe). > > * "harvestable" items > Something along the line of "the bee hive makes > honey, you can grab it if you have an empty honey > pot" (need to apply it standing on / facing the > square, probably). > > This would make it fun to go grab exotic materials > for alchemy / cooking / you name it. > > I'd like to have different graphics/archetypes for > that, so that you know when there is something to > pick and when there is not, and make some maximum > item holding (don't accumulate more than 5 honey > units), also regenerating slowly over time with > random values. > > This looks like adapted monster generator, no? :) > > It could give xp in a specialized skill ("honey > harvesting"?). You could then add a > difficulty-to-get level, adapted based on skill > level, and with a minimum level. > > Example: mining. You can mine rocks to get ore, but > you need to be level 50 to get gold. And the higher > you are, the easiest to get ores. > > * enable alchemy to keep (some) used items > Example i see: get melt gold ore, use a ring mould > => get a gold ring + the ring mould. > Need to think more about that, i guess, i'm not > totally convinced myself :) > > Just a few tossed ideas. But I feel like > implementing some soon :) > > Ryo > > Accédez au courrier électronique de La Poste : > www.laposte.net ; > 3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 > (0,34€/mn) > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From b.t.lally at warwick.ac.uk Fri Apr 15 14:41:24 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Fri Apr 15 14:23:05 2005 Subject: [crossfire] Server release? In-Reply-To: References: Message-ID: <200504152041.24838.b.t.lally@warwick.ac.uk> On Friday 15 Apr 2005 13:41, Nicolas Weeger wrote: > Hello. > > It's been almost 3 months since last server release (1.7.0). What about > starting to think of a new release? *grin* > On a related topic, what about versioning stratagy in general? Here's an idea to consider... IMHO the new gtk2 client is probably enough of an improvement to be called crossfire 2, since it is an entirely new client frontend and (to those using it at least) a different app. However, it doesn't seem to be ready for general use yet (no autopickup controls for one thing). client release 1.7.1 doesn't include it, and there have been a few changes that have affected the old gtk client in the meantime, smoothing modifications, memory leak fixes and the extra pickup option. These changes are significant and worthwhile enough in their own right that they probably justify a 1.8 release independent of the new client. What I am thinking is that a 1.8.0 release that didn't include the new client could be done now, and then after that 1.8.x releases would be urgent bugfixes if they were needed (things like the metaserver crash bug a while back) This gives two branches (at least on the client side), with the second one containing the new client and being released when it is ready for use. There could then be a series of 2.0 CVS builds over the course of several months and maybe a 1.9 server and client release if there is the need. I do get the impression that most of the players on metalforge either build from CVS, or use the experimental deb repository or one of Ryo's windows builds anyway, how valid this impression is I am unsure. With a 2.0 release there is a good point for an official shift of naming systems for the binaries, so that things like http://www.metalforge.net/cfmb/viewtopic.php?t=1009&highlight=waiting+connections don't happen. Maybe also a discontinuation of cfclient and crossedit if they are no longer maintained and used (I'm unsure about this one, the only person I know who has used cfclient in months was someone who appeared on IRC not knowing about gcfclient - does anyone still use these by choice?). and of course having a crossfire 2.0 release may even be worth a slashdotting.... From alex_sch at telus.net Fri Apr 15 14:58:59 2005 From: alex_sch at telus.net (Alex Schultz) Date: Fri Apr 15 14:59:06 2005 Subject: [crossfire] Server release? In-Reply-To: <200504152041.24838.b.t.lally@warwick.ac.uk> References: <200504152041.24838.b.t.lally@warwick.ac.uk> Message-ID: <42601D03.705@telus.net> Nicolas Weeger wrote: >Hello. > > >It's been almost 3 months since last server release (1.7.0). What about >starting to think of a new release? *grin* > > I think that might be good, especially if my circular lighting patch that's on the verge of getting in gets into cvs in time :-) Brendan Lally wrote: >IMHO the new gtk2 client is probably enough of an improvement to be called >crossfire 2, since it is an entirely new client frontend and (to those using >it at least) a different app. > I would disagree on this point, even once the gtk2 client is fully functional. I primarily disagree because doing so would either mean we would also release a version 2 of the server at that time (which might not be warranted quite at that time), or the server and client version numbers would be somewhat disjointed which might confuse people. > >client release 1.7.1 doesn't include it, and there have been a few changes >that have affected the old gtk client in the meantime, smoothing >modifications, memory leak fixes and the extra pickup option. > >These changes are significant and worthwhile enough in their own right that >they probably justify a 1.8 release independent of the new client. > > I agree. >Maybe also a discontinuation of cfclient and crossedit if they are no longer >maintained and used (I'm unsure about this one, the only person I know who >has used cfclient in months was someone who appeared on IRC not knowing about >gcfclient - does anyone still use these by choice?). > Don't know about cfclient, but mikee is the only person I know of who still uses crossedit... I have however found cfclient a little nice to double check weather a client issue is gtk related or not. --Alex Schultz (aka Rednaxela) From fuchs.andy at gmail.com Fri Apr 15 15:16:45 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Fri Apr 15 15:17:05 2005 Subject: [crossfire] Server release? In-Reply-To: <200504152041.24838.b.t.lally@warwick.ac.uk> References: <200504152041.24838.b.t.lally@warwick.ac.uk> Message-ID: On 4/15/05, Brendan Lally wrote: > IMHO the new gtk2 client is probably enough of an improvement to be called > crossfire 2, since it is an entirely new client frontend and (to those using > it at least) a different app. However, it doesn't seem to be ready for > general use yet (no autopickup controls for one thing). Needs suppourt for lower resolutions (at 1024x768 here) > Maybe also a discontinuation of cfclient and crossedit if they are no longer > maintained and used (I'm unsure about this one, the only person I know who > has used cfclient in months was someone who appeared on IRC not knowing about > gcfclient - does anyone still use these by choice?). Still used on older systems, mikeeusa uses crossedit, not the javaeditor. > and of course having a crossfire 2.0 release may even be worth a > slashdotting.... Anyone want to to a security audit first? And give server admins a fair warning before it happens... -- -- Andrew Fuchs From fuchs.andy at gmail.com Fri Apr 15 15:22:12 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Fri Apr 15 15:23:05 2005 Subject: [crossfire] A few random ideas In-Reply-To: <20050415163721.3934.qmail@web61007.mail.yahoo.com> References: <20050415163721.3934.qmail@web61007.mail.yahoo.com> Message-ID: On 4/15/05, Mitch Obrian wrote: > Gold and platinum ore should only be found in limited > places in limited supply. We could have a > geography/mineral map for each world map maby: Ie you > dig in this spot you get x etc. How about make mines and generic caves appear randomly? Possibly only within predefined areas. -- -- Andrew Fuchs From alex_sch at telus.net Fri Apr 15 15:25:08 2005 From: alex_sch at telus.net (Alex Schultz) Date: Fri Apr 15 15:24:53 2005 Subject: Security Audit, was Re: [crossfire] Server release? In-Reply-To: References: <200504152041.24838.b.t.lally@warwick.ac.uk> Message-ID: <42602324.9080203@telus.net> Andrew Fuchs wrote: >Anyone want to to a security audit first? And give server admins a >fair warning before it happens... > > Well... I do remember seeing a little back that one person (can't remember who) was connecting to crossfire on metalforge via telnet going to the cf port, and was able to chat etc. however the server crashed when he tried to close telnet in a certain way (can't exactly remember how...) From nicolas.weeger at laposte.net Fri Apr 15 15:55:30 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri Apr 15 16:01:06 2005 Subject: [crossfire] A few random ideas In-Reply-To: References: Message-ID: <42602A42.4040408@laposte.net> > * items combination / use item with item > Example one, use apple on knife => sliced apple. > Example two, use sliced apple with base pie crust => ready to cook apple pie. Then put it in oven (alchemy-like), except if you fail you just get a burnt pie, no exploding oven! Ok, just committed code to do just that. New item type, ITEM_TRANSFORMER (163). Just a special item, that when applied grabs the marked item. 'slaying' field is checked to transform if eligible. See doc/Developers/item_transformation for explanations. Crash example: * create a 'knife' archetype, with type 163 * create 'half_apple' archetype * add to apple archetype: slaying knife:2 half_apple Now mark the apple, apply knife, you got 2 nice half-apples :) As a special case, if transformer's level is non-zero, it gets used when transforming. Example case: apply bowl on water => bowl full of water, don't have anymore bottle or empty bowl. I tested some, so I think code is all right. The use of 'slaying' is discutable, of course :) And I tweaked the item description function to not print the slaying field for food :) Nicolas From mwedel at sonic.net Fri Apr 15 23:38:42 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Apr 15 23:39:09 2005 Subject: [crossfire] A few random ideas In-Reply-To: References: <20050415163721.3934.qmail@web61007.mail.yahoo.com> Message-ID: <426096D2.3090707@sonic.net> Andrew Fuchs wrote: > On 4/15/05, Mitch Obrian wrote: > >>Gold and platinum ore should only be found in limited >>places in limited supply. We could have a >>geography/mineral map for each world map maby: Ie you >>dig in this spot you get x etc. > > > How about make mines and generic caves appear randomly? > Possibly only within predefined areas. Making mines appear randomly on the world maps gets a little trickier, in that presumably, you'd new ones created and old ones to go away. However, making it so that an old one goes away when no one is using it gets harder. PRobably easier to just make random maps, and have something like a minestyle. The mines could use special destroyable walls (with pickaxe/shovel or something), and have random spaces that have ore (or more clever, have special mine type code that actually does the ore in veins). With a random map, it would have a set location, which IMO isn't really a problem. And it'd periodically reset, so people could go mining again. From mwedel at sonic.net Fri Apr 15 23:42:03 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Apr 15 23:45:10 2005 Subject: [crossfire] A few random ideas In-Reply-To: <42602A42.4040408@laposte.net> References: <42602A42.4040408@laposte.net> Message-ID: <4260979B.8090101@sonic.net> Nicolas Weeger wrote: >> * items combination / use item with item >> Example one, use apple on knife => sliced apple. >> Example two, use sliced apple with base pie crust => ready to cook >> apple pie. Then put it in oven (alchemy-like), except if you fail you >> just get a burnt pie, no exploding oven! > > > Ok, just committed code to do just that. > New item type, ITEM_TRANSFORMER (163). Just a special item, that when > applied grabs the marked item. 'slaying' field is checked to transform > if eligible. > > See doc/Developers/item_transformation for explanations. > > Crash example: > * create a 'knife' archetype, with type 163 > * create 'half_apple' archetype > * add to apple archetype: > slaying knife:2 half_apple > > Now mark the apple, apply knife, you got 2 nice half-apples :) My one minor quibble is that people may get knives and say 'hey, why can't I use this as a weapon'. Which is somewhat valid I suppose. However, more relevantly, I wonder if there is a way to make these complex operations easier than having to mark an object? I'd think that perhaps the client could implement drag and drop for inventory and maybe figure that out on its own (user drags torches to the flint, or vice versa, etc). From mwedel at sonic.net Sat Apr 16 00:01:26 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Apr 16 00:03:09 2005 Subject: [crossfire] object key-value lists. Message-ID: <42609C26.5090801@sonic.net> This is perhaps vaguely related to the 'A few random ideas' thread, but something that I don't think is that hard, but I haven't had time to work on yet. The basic idea is define a structure like: struct key_value { char *key; char *value; struct key_value *next; }; And add that to the object structure. Whenever the object loader gets a line it doesn't understand, it stores it in the key_value list (key being the first word of the line, value being the rest). The object saver would then save out this key_value list. things like copy_object would need some updating, etc. This then allows arbitrary addition of new fields to the object definition without any changes to the loader/saver, and without any increase in object space. This would reduce the overloading of various fields for sets of infrequently used objects. Storing as key/value pairing makes it so that it is only parsed once during loading - this makes accessing data much faster than if it was just a free block of text that needed parsing each time something might need to get a key. there would be a pair of helper functions like: char *get_ob_value(object *op, char *key) which returns the value parameter for the right key, or null if nothing found, and int set_ob_value(object *op, char *key, char *value, int add_key) Which sets the value for the given key. if add_key is true, it will add the key if not defined, otherwise, it only updates existing keys. Returns true/false based on success. The question then probably comes up 'when to use those key/values, and when to add new fields', of which this is my thought: 1) If the access to the key/value is not in an often used loop such that it is time sensitive. For example, if the only time the key/value would need to be used is by player activating the object, that doesn't happen all that often, so good option. If however the key/value would be examined for map updates (say glow_radius) probably not a good option. 2) If the number of objects/archetypes using it is relatively small (this being an imprecise term, but right now, there are about 30 vlaues that are used by less than 10 archetypes) 3) If this isn't closely related to a field already set as a field (eg, it would make sense to have something like op->foo and then have something like get_ob_value(op, maxfoo) From mwedel at sonic.net Sat Apr 16 00:18:22 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Apr 16 00:19:09 2005 Subject: [crossfire] Server release? In-Reply-To: References: Message-ID: <4260A01E.5010303@sonic.net> Since I tend to make the releases, I'll note my strategies: In terms of numbering, I want to try to keep the server and client close in sync. That way, I can make a statement like 'if your client version is newer than the server version, you can be sure that your client support all the features of the server'. that is a lot easier than saying something like 'if server is 1.5, need client 1.6, if server 1.7, need client 1.9, if server is 2.0, need client 2.5, etc'. This is the reason that the last client release was a 1.7.1 - just to sync up those numbers. In terms of whats in the release, generally, if its in CVS, its in the source release at least. In a sense, the source code releases are basically snapshots of CVS, ideally based on some time when the code was more stable or something. I'm reluctant to do multiple trees/release trains - I just don't see a particular compelling reason. Likewise, as long as cfclient and crossedit are easy to maintain/keep working, I see no compelling reason for them to be removed. That said, one shouldn't really expect much in the way of new features for either of those either. From tchize at myrealbox.com Sat Apr 16 05:51:03 2005 From: tchize at myrealbox.com (tchize) Date: Sat Apr 16 05:53:14 2005 Subject: Security Audit, was Re: [crossfire] Server release? In-Reply-To: <42602324.9080203@telus.net> References: <42602324.9080203@telus.net> Message-ID: <200504161251.09845.tchize@myrealbox.com> I fixed this a few time ago (i think). This was related to server dying on a sigpipe on abrupt connection close. Just one note, on security. Every part of the code is subject to strings overflows. I have seen countless calls to sprintf instead of snprintf, which is inherently unsecure. Some parts of those calls involve datas provided by client. Le Vendredi 15 Avril 2005 22:25, Alex Schultz a ?crit : Andrew Fuchs wrote: >Anyone want to to a security audit first? And give server admins a >fair warning before it happens... Well... I do remember seeing a little back that one person (can't remember who) was connecting to crossfire on metalforge via telnet going to the cf port, and was able to chat etc. however the server crashed when he tried to close telnet in a certain way (can't exactly remember how...) _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- David Delbecq d.delbecq@laposte.net Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net:11371/pks/lookup?op=index&search=tchize http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x5436C17C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050416/1a0906bc/attachment.pgp From alex_sch at telus.net Sat Apr 16 09:32:41 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sat Apr 16 09:33:16 2005 Subject: Lighting changes, was Re: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <425D1EFB.4080504@telus.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> <42497134.6060109@telus.net> <424A58B6.8070703@sonic.net> <424AAB8B.9000800@telus.net> <424BAE77.6020500@sonic.net> <424BEDA8.3020107@telus.net> <424F8AB5.8090906@sonic.net> <42500168.2070106@telus.net> <4250EC37.4010109@sonic.net> <425135D9.3020001@telus.net> <42522731.1000700@sonic.net> <425286D7.1020708@telus.net> <425A1AFC.8020305@sonic.net> <425C9FC7.3000400@telus.net> <425D1EFB.4080504@telus.net> Message-ID: <42612209.6050300@telus.net> Alex Schultz wrote: > ... I don't see any reasons now why it can't get into CVS now, but I > might be missing something. > > --Alex Schultz (aka Rednaxela) It just got into CVS however, just as it did (I tried to catch mwedel on irc as he was putting it in, however it didn't look like he looked at his irc since ), I noticed a small mistake to due with the recent 'conversion' to make the name glow_radius accurate again. In the changes I made to deal with the "conversion" from glow_radius, I accidentally made it so negative glow radiuses aren't working again. The circular lighting is working, it's just that negative glow radiuses won't be working. I've attached a small diff to fix that. (negetivefix.diff) --Alex Schultz (aka Rednaxela) -------------- next part -------------- A non-text attachment was scrubbed... Name: negetivefix.diff Type: text/x-patch Size: 1187 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050416/846dc807/negetivefix.bin From mikeeusaaa at yahoo.com Sat Apr 16 11:32:26 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Apr 16 11:33:16 2005 Subject: [crossfire] A few random ideas In-Reply-To: 6667 Message-ID: <20050416163226.63549.qmail@web61006.mail.yahoo.com> /me notes that mlab has mines... --- Mark Wedel wrote: > Andrew Fuchs wrote: > > On 4/15/05, Mitch Obrian > wrote: > > > >>Gold and platinum ore should only be found in > limited > >>places in limited supply. We could have a > >>geography/mineral map for each world map maby: Ie > you > >>dig in this spot you get x etc. > > > > > > How about make mines and generic caves appear > randomly? > > Possibly only within predefined areas. > > Making mines appear randomly on the world maps > gets a little trickier, in that > presumably, you'd new ones created and old ones to > go away. However, making it > so that an old one goes away when no one is using it > gets harder. > > PRobably easier to just make random maps, and have > something like a minestyle. > The mines could use special destroyable walls > (with pickaxe/shovel or > something), and have random spaces that have ore (or > more clever, have special > mine type code that actually does the ore in veins). > > With a random map, it would have a set location, > which IMO isn't really a > problem. And it'd periodically reset, so people > could go mining again. > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide From mikeeusaaa at yahoo.com Sat Apr 16 11:33:41 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Apr 16 11:35:18 2005 Subject: [crossfire] A few random ideas In-Reply-To: 6667 Message-ID: <20050416163342.54662.qmail@web61008.mail.yahoo.com> Knives should definatly be usable as weapons. --- Mark Wedel wrote: > Nicolas Weeger wrote: > >> * items combination / use item with item > >> Example one, use apple on knife => sliced apple. > >> Example two, use sliced apple with base pie crust > => ready to cook > >> apple pie. Then put it in oven (alchemy-like), > except if you fail you > >> just get a burnt pie, no exploding oven! > > > > > > Ok, just committed code to do just that. > > New item type, ITEM_TRANSFORMER (163). Just a > special item, that when > > applied grabs the marked item. 'slaying' field is > checked to transform > > if eligible. > > > > See doc/Developers/item_transformation for > explanations. > > > > Crash example: > > * create a 'knife' archetype, with type 163 > > * create 'half_apple' archetype > > * add to apple archetype: > > slaying knife:2 half_apple > > > > Now mark the apple, apply knife, you got 2 nice > half-apples :) > > My one minor quibble is that people may get knives > and say 'hey, why can't I > use this as a weapon'. Which is somewhat valid I > suppose. > > However, more relevantly, I wonder if there is a > way to make these complex > operations easier than having to mark an object? I'd > think that perhaps the > client could implement drag and drop for inventory > and maybe figure that out on > its own (user drags torches to the flint, or vice > versa, etc). > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide From mikeeusaaa at yahoo.com Sat Apr 16 11:38:46 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Apr 16 11:40:14 2005 Subject: [crossfire] Server release? In-Reply-To: 6667 Message-ID: <20050416163846.20967.qmail@web61009.mail.yahoo.com> Viva le crossedit. --- Mark Wedel wrote: > > Since I tend to make the releases, I'll note my > strategies: > > In terms of numbering, I want to try to keep the > server and client close in > sync. That way, I can make a statement like 'if > your client version is newer > than the server version, you can be sure that your > client support all the > features of the server'. > > that is a lot easier than saying something like > 'if server is 1.5, need client > 1.6, if server 1.7, need client 1.9, if server is > 2.0, need client 2.5, etc'. > > This is the reason that the last client release > was a 1.7.1 - just to sync up > those numbers. > > In terms of whats in the release, generally, if > its in CVS, its in the source > release at least. In a sense, the source code > releases are basically snapshots > of CVS, ideally based on some time when the code was > more stable or something. > > I'm reluctant to do multiple trees/release trains > - I just don't see a > particular compelling reason. > > Likewise, as long as cfclient and crossedit are > easy to maintain/keep working, > I see no compelling reason for them to be removed. > That said, one shouldn't > really expect much in the way of new features for > either of those either. > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide From mikeeusaaa at yahoo.com Sat Apr 16 11:42:15 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Apr 16 11:43:16 2005 Subject: [crossfire] Can someone give me a material -> number lookup table Message-ID: <20050416164215.83087.qmail@web61004.mail.yahoo.com> What are the materials (that java applet dosn't work on my box... and the lookup table has been deleted?! on that site that has said applette) numbers? __________________________________ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide From mikeeusaaa at yahoo.com Sat Apr 16 12:54:07 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Apr 16 12:55:16 2005 Subject: [crossfire] New Archtypes: vials, empty bottles, empty vial (please up to CVS) Message-ID: <20050416175407.43836.qmail@web61005.mail.yahoo.com> https://cat2.dynu.ca/crossfirearch https://cat2.dynu.ca/crossfirearch/emptybottles.arc https://cat2.dynu.ca/crossfirearch/potion_empty.base.111.png https://cat2.dynu.ca/crossfirearch/vial_empty.base.111.png https://cat2.dynu.ca/crossfirearch/wbottle_empty.base.111.png https://cat2.dynu.ca/crossfirearch/vials.arc https://cat2.dynu.ca/crossfirearch/vial_blue.base.111.png https://cat2.dynu.ca/crossfirearch/vial_cyan.base.111.png https://cat2.dynu.ca/crossfirearch/vial_green.base.111.png https://cat2.dynu.ca/crossfirearch/vial_magenta.base.111.png https://cat2.dynu.ca/crossfirearch/vial_red.base.111.png https://cat2.dynu.ca/crossfirearch/vial_water.base.111.png https://cat2.dynu.ca/crossfirearch/vial_yellow.base.111.png __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaaa at yahoo.com Sat Apr 16 14:30:53 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Apr 16 14:31:17 2005 Subject: Security Audit, was Re: [crossfire] Server release? In-Reply-To: 6667 Message-ID: <20050416193053.64238.qmail@web61001.mail.yahoo.com> A security audit would be good. No fun getting HAZZ()3D! --- tchize wrote: > I fixed this a few time ago (i think). This was > related to server dying on a > sigpipe on abrupt connection close. > > Just one note, on security. > Every part of the code is subject to strings > overflows. I have seen countless > calls to sprintf instead of snprintf, which is > inherently unsecure. Some > parts of those calls involve datas provided by > client. > > Le Vendredi 15 Avril 2005 22:25, Alex Schultz a > écrit : > Andrew Fuchs wrote: > >Anyone want to to a security audit first? And give > server admins a > >fair warning before it happens... > > Well... I do remember seeing a little back that one > person (can't > remember who) was connecting to crossfire on > metalforge via telnet going > to the cf port, and was able to chat etc. however > the server crashed > when he tried to close telnet in a certain way > (can't exactly remember > how...) > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -- > -- > David Delbecq > d.delbecq@laposte.net > Public PGP KEY FINGERPRINT: > F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 > C17C > Public PGP KEY location: > > http://wwwkeys.pgp.net:11371/pks/lookup?op=index&search=tchize > > http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x5436C17C > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide From nicolas.weeger at laposte.net Sat Apr 16 15:49:36 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat Apr 16 15:55:19 2005 Subject: [crossfire] A few random ideas In-Reply-To: <4260979B.8090101@sonic.net> References: <42602A42.4040408@laposte.net> <4260979B.8090101@sonic.net> Message-ID: <42617A60.1070102@laposte.net> > My one minor quibble is that people may get knives and say 'hey, why > can't I use this as a weapon'. Which is somewhat valid I suppose. Then let's make a 'knife for kitchen' :) > However, more relevantly, I wonder if there is a way to make these > complex operations easier than having to mark an object? I'd think that > perhaps the client could implement drag and drop for inventory and maybe > figure that out on its own (user drags torches to the flint, or vice > versa, etc). Well, drag & drop would be nice. But you'd need some way to tell the server what to do anyway - or have a command "use item1 on item2" with item identifiers. I didn't want to modify client for my thing in the first place. But indeed, now we could think of doing drag & drop. Only thing is to keep the command usable from the command line - like all other commands. Ryo From mwedel at sonic.net Sat Apr 16 18:58:45 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Apr 16 18:59:21 2005 Subject: Security Audit, was Re: [crossfire] Server release? In-Reply-To: <200504161251.09845.tchize@myrealbox.com> References: <42602324.9080203@telus.net> <200504161251.09845.tchize@myrealbox.com> Message-ID: <4261A6B5.5040407@sonic.net> tchize wrote: > I fixed this a few time ago (i think). This was related to server dying on a > sigpipe on abrupt connection close. > > Just one note, on security. > Every part of the code is subject to strings overflows. I have seen countless > calls to sprintf instead of snprintf, which is inherently unsecure. Some > parts of those calls involve datas provided by client. Yes - using sprintf, strcpy, etc are not safe. Unfortunately, some number of those calls are on data passed in, where it would require changing the function prototype to denote how large the buffer is. There are still a lot of calls to sprintf/strcpy in the code - fixing those is no smaller matter. On the bright side, the server requires no special privileges to run, so could be run in a jail/zone/chroot environment to mitigate the risks. From mwedel at sonic.net Sat Apr 16 19:07:29 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Apr 16 19:09:20 2005 Subject: [crossfire] A few random ideas In-Reply-To: <42617A60.1070102@laposte.net> References: <42602A42.4040408@laposte.net> <4260979B.8090101@sonic.net> <42617A60.1070102@laposte.net> Message-ID: <4261A8C1.7080703@sonic.net> Nicolas Weeger wrote: >> However, more relevantly, I wonder if there is a way to make these >> complex operations easier than having to mark an object? I'd think >> that perhaps the client could implement drag and drop for inventory >> and maybe figure that out on its own (user drags torches to the flint, >> or vice versa, etc). > > > Well, drag & drop would be nice. But you'd need some way to tell the > server what to do anyway - or have a command "use item1 on item2" with > item identifiers. I didn't want to modify client for my thing in the > first place. But indeed, now we could think of doing drag & drop. Only > thing is to keep the command usable from the command line - like all > other commands. The apply command could certain be extended to have something like a 'on' keyword (or similar name). So you could do something like 'apply knife on apple' or 'apply flint and steel on torch' and so on. For low level client communication, the apply command would need to be extended or something. So instead of: C->S: apply Tells the server that I want to apply the object . Like examine, is a text representation of an integer tag. Have something like: C->S: apply2 Tells the server that I want to apply the object . If is non zero, then is applied onto . if is zero, then the object is applied on its own. Like examine, the s are a text representation of an integer tag. For drag on drop purposes, and to be consistent with the text commands, you'd drag the object that does the applying to the other (eg, drag the flint and steel to the torchs, or the knife to the apple). From mikeeusaaa at yahoo.com Sun Apr 17 11:33:50 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun Apr 17 11:35:26 2005 Subject: Security Audit, was Re: [crossfire] Server release? In-Reply-To: 6667 Message-ID: <20050417163350.34441.qmail@web61006.mail.yahoo.com> Still can steal users pass hashes and delete all your CF data. Bad. --- Mark Wedel wrote: > tchize wrote: > > I fixed this a few time ago (i think). This was > related to server dying on a > > sigpipe on abrupt connection close. > > > > Just one note, on security. > > Every part of the code is subject to strings > overflows. I have seen countless > > calls to sprintf instead of snprintf, which is > inherently unsecure. Some > > parts of those calls involve datas provided by > client. > > Yes - using sprintf, strcpy, etc are not safe. > > Unfortunately, some number of those calls are on > data passed in, where it > would require changing the function prototype to > denote how large the buffer is. > > There are still a lot of calls to sprintf/strcpy > in the code - fixing those is > no smaller matter. > > On the bright side, the server requires no special > privileges to run, so could > be run in a jail/zone/chroot environment to mitigate > the risks. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From alex_sch at telus.net Sun Apr 17 13:17:38 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sun Apr 17 13:19:30 2005 Subject: Security Audit, was Re: [crossfire] Server release? In-Reply-To: <20050417163350.34441.qmail@web61006.mail.yahoo.com> References: <20050417163350.34441.qmail@web61006.mail.yahoo.com> Message-ID: <4262A842.8040005@telus.net> He said mitigate (as in, make somewhat less severe), not get rid of the risks. Mitch Obrian wrote: >Still can steal users pass hashes and delete all your >CF data. Bad. > >--- Mark Wedel wrote: > > >> On the bright side, the server requires no special >>privileges to run, so could >>be run in a jail/zone/chroot environment to mitigate >>the risks. >> >> From david.Delbecq at myrealbox.com Sun Apr 17 13:49:56 2005 From: david.Delbecq at myrealbox.com (David Delbecq) Date: Sun Apr 17 14:00:57 2005 Subject: Security Audit, was Re: [crossfire] Server release? In-Reply-To: <20050417163350.34441.qmail@web61006.mail.yahoo.com> References: <20050417163350.34441.qmail@web61006.mail.yahoo.com> Message-ID: <200504172050.02466.david.Delbecq@myrealbox.com> A few times ago, i tried to fix this by changing char* manipulation to some macros. This made operations like strcat faster because we kept a track on the lenght of buffer, but i dropped. This was taking me a huge amount of time to code and the various changes in server occuring during that period made a lot of conflict. The good point was 'it was working', the bad point was 'lots of prototype changes'. Maybe i should retry but this time work on something like commiting one clean file per week. --- Mark Wedel wrote: > Unfortunately, some number of those calls are on > data passed in, where it > would require changing the function prototype to > denote how large the buffer is. > > There are still a lot of calls to sprintf/strcpy > in the code - fixing those is > no smaller matter. > > On the bright side, the server requires no special > privileges to run, so could > be run in a jail/zone/chroot environment to mitigate > the risks. > -- -- David Delbecq david.delbecq@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050417/5e6f1ef9/attachment.pgp From michtoen at daimonin.net Sun Apr 17 14:15:12 2005 From: michtoen at daimonin.net (Michael Toennies) Date: Sun Apr 17 14:15:30 2005 Subject: AW: Security Audit, was Re: [crossfire] Server release? In-Reply-To: <4261A6B5.5040407@sonic.net> Message-ID: <0504172114574500@mail.trenz.de> You should have in mind that there is no need to have a "total" control over every sprintf(). The server has only very few different buffer sizes and the code is really bugfree - the only real problem are the client->server communication. But - all that communication has to pass the socket/command interface. There must be the control. It must be there so or so. Because its a good idea not only to avoid the buffer overflow but also to find the hacked client & player - and remove him. > tchize wrote: > > I fixed this a few time ago (i think). This was related to server > > dying on a sigpipe on abrupt connection close. > > > > Just one note, on security. > > Every part of the code is subject to strings overflows. I have seen > > countless calls to sprintf instead of snprintf, which is inherently > > unsecure. Some parts of those calls involve datas provided > by client. > > Yes - using sprintf, strcpy, etc are not safe. > > Unfortunately, some number of those calls are on data > passed in, where it would require changing the function > prototype to denote how large the buffer is. > > There are still a lot of calls to sprintf/strcpy in the > code - fixing those is no smaller matter. > > On the bright side, the server requires no special > privileges to run, so could be run in a jail/zone/chroot > environment to mitigate the risks. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mwedel at sonic.net Sun Apr 17 15:58:58 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Apr 17 15:59:30 2005 Subject: Security Audit, was Re: [crossfire] Server release? In-Reply-To: <200504172050.02466.david.Delbecq@myrealbox.com> References: <20050417163350.34441.qmail@web61006.mail.yahoo.com> <200504172050.02466.david.Delbecq@myrealbox.com> Message-ID: <4262CE12.4070902@sonic.net> David Delbecq wrote: > A few times ago, i tried to fix this by changing char* manipulation to some > macros. This made operations like strcat faster because we kept a track on > the lenght of buffer, but i dropped. This was taking me a huge amount of time > to code and the various changes in server occuring during that period made a > lot of conflict. The good point was 'it was working', the bad point was 'lots > of prototype changes'. Maybe i should retry but this time work on something > like commiting one clean file per week. Yes - such a smaller approach may make sense. It may not be bad just for developers to look at files they have not written and give them a once over? Something look really odd? dangerous? It may just be a matter of updating comments, in other cases, poor code could be discovered/fixed. From alex_sch at telus.net Sun Apr 17 16:19:46 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sun Apr 17 16:21:31 2005 Subject: Lighting changes, was Re: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <42612209.6050300@telus.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> <42497134.6060109@telus.net> <424A58B6.8070703@sonic.net> <424AAB8B.9000800@telus.net> <424BAE77.6020500@sonic.net> <424BEDA8.3020107@telus.net> <424F8AB5.8090906@sonic.net> <42500168.2070106@telus.net> <4250EC37.4010109@sonic.net> <425135D9.3020001@telus.net> <42522731.1000700@sonic.net> <425286D7.1020708@telus.net> <425A1AFC.8020305@sonic.net> <425C9FC7.3000400@telus.net> <425D1EFB.4080504@telus.net> <42612209.6050300@telus.net> Message-ID: <4262D2F2.50502@telus.net> Alex Schultz wrote: > I noticed a small mistake to due with the recent 'conversion' to make > the name glow_radius accurate again. In the changes I made to deal > with the "conversion" from glow_radius, I accidentally made it so > negative glow radiuses aren't working again. The circular lighting is > working, it's just that negative glow radiuses won't be working. I've > attached a small diff to fix that. (negetivefix.diff) > Aurg... I must have been asleep or something when I made those 'conversion' changes. Here's another fix to my stupidity when doing that. Server Admins: If you update to the very latest cvs without this fix, then your player will find that monsters will almost always detect them even in complete darkness when the monster doesn't have night vision. I highly suggest you either wait till this fix is in CVS (should be some time within 24 hours), or apply this patch yourself. --Alex Schultz (aka Rednaxela) -------------- next part -------------- A non-text attachment was scrubbed... Name: monsterfix.diff Type: text/x-patch Size: 1619 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050417/9961d6cd/monsterfix.bin From mwedel at sonic.net Mon Apr 18 02:14:47 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Apr 18 02:15:37 2005 Subject: Lighting changes, was Re: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <4262D2F2.50502@telus.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> <42497134.6060109@telus.net> <424A58B6.8070703@sonic.net> <424AAB8B.9000800@telus.net> <424BAE77.6020500@sonic.net> <424BEDA8.3020107@telus.net> <424F8AB5.8090906@sonic.net> <42500168.2070106@telus.net> <4250EC37.4010109@sonic.net> <425135D9.3020001@telus.net> <42522731.1000700@sonic.net> <425286D7.1020708@telus.net> <425A1AFC.8020305@sonic.net> <425C9FC7.3000400@telus.net> <425D1EFB.4080504@telus.net> <42612209.6050300@telus.net> <4262D2F2.50502@telus.net> Message-ID: <42635E67.1000509@sonic.net> Alex Schultz wrote: > Alex Schultz wrote: Applied to CVS. > >> I noticed a small mistake to due with the recent 'conversion' to make >> the name glow_radius accurate again. In the changes I made to deal >> with the "conversion" from glow_radius, I accidentally made it so >> negative glow radiuses aren't working again. The circular lighting is >> working, it's just that negative glow radiuses won't be working. I've >> attached a small diff to fix that. (negetivefix.diff) >> > Aurg... I must have been asleep or something when I made those > 'conversion' changes. Here's another fix to my stupidity when doing that. > > Server Admins: If you update to the very latest cvs without this fix, > then your player will find that monsters will almost always detect them > even in complete darkness when the monster doesn't have night vision. I > highly suggest you either wait till this fix is in CVS (should be some > time within 24 hours), or apply this patch yourself. > > --Alex Schultz (aka Rednaxela) > > > ------------------------------------------------------------------------ > > Index: crossfire/server/monster.c > =================================================================== > RCS file: /cvsroot/crossfire/crossfire/server/monster.c,v > retrieving revision 1.75 > diff -c -5 -r1.75 monster.c > *** crossfire/server/monster.c 17 Apr 2005 04:25:55 -0000 1.75 > --- crossfire/server/monster.c 17 Apr 2005 21:11:51 -0000 > *************** > *** 1889,1909 **** > > > /* Check the spaces with the max light radius to see if any of them > * have lights, and if any of them light the player enough, then return 1. > */ > ! for (x = op->x - (2*MAX_LIGHT_RADII); x< op->x + (2*MAX_LIGHT_RADII); x++) { > ! for (y = op->y - (2*MAX_LIGHT_RADII); y< op->y + (2*MAX_LIGHT_RADII); y++) { > m = op->map; > nx = x; > ny = y; > > if (get_map_flags(m, &m, nx, ny, &nx, &ny) & P_OUT_OF_MAP) continue; > > x1 = abs(x - op->x)*abs(x - op->x); > y1 = abs(y - op->y)*abs(y - op->y); > ! if (isqrt(x1 + y1) > 0) return 1; > } > } > } > return 0; > } > --- 1889,1909 ---- > > > /* Check the spaces with the max light radius to see if any of them > * have lights, and if any of them light the player enough, then return 1. > */ > ! for (x = op->x - (MAX_LIGHT_RADII); x< op->x + (MAX_LIGHT_RADII); x++) { > ! for (y = op->y - (MAX_LIGHT_RADII); y< op->y + (MAX_LIGHT_RADII); y++) { > m = op->map; > nx = x; > ny = y; > > if (get_map_flags(m, &m, nx, ny, &nx, &ny) & P_OUT_OF_MAP) continue; > > x1 = abs(x - op->x)*abs(x - op->x); > y1 = abs(y - op->y)*abs(y - op->y); > ! if (isqrt(x1 + y1) < GET_MAP_LIGHT(m, nx, ny)) return 1; > } > } > } > return 0; > } > > > ------------------------------------------------------------------------ > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From fuchs.andy at gmail.com Tue Apr 19 17:28:22 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Tue Apr 19 17:29:58 2005 Subject: [crossfire] Gtk client, and theme issues Message-ID: gcfclient uses gtk1 to draw widgets, so it dosn't pick up themes set with gnome, and newer versions of gtk (gcfclient2 won't work at the resolution im using) >From irc: aaronf0 question: why doesnt the gtk client pick up my gtk themes? Ryo_ because it's gtk1, probably? aaronf0 damn aaronf0 any reason why? techII gtk1 doesn't support themes? techII or uses a different system aaronf0 no, why its in gtk1, and not gtk 2 Ryo_ the client is gtk1, that's all Ryo_ unless you udner windows, where it is gtk2 *g* aaronf0 odd aaronf0 any hacks to compile the client with gtk 2 in linux? Ryo_ (because gtk2 has good win32 support, compared to gtk1) aaronf0 lol Ryo_ just look at the windows part, the flags it uses, that should be enough aaronf0 any reason why its not using gtk2 in linux? aaronf0 stablility? compadablity? techII none aparently -- -- Andrew Fuchs From mwedel at sonic.net Wed Apr 20 00:34:48 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Apr 20 00:36:02 2005 Subject: [crossfire] Gtk client, and theme issues In-Reply-To: References: Message-ID: <4265E9F8.1010205@sonic.net> Here are the compile errors I get when trying to compile against gtk 2: gcc -ggdb -Wall -DALSA9_SOUND -DOSS_SOUND -I. -I/usr/include/SDL -D_REENTRANT -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/X11R6/include -I.. -I../common -I../pixmaps -c gx11.c config.c: In function `configdialog': config.c:413: error: `GTK_WINDOW_DIALOG' undeclared (first use in this function) config.c:413: error: (Each undeclared identifier is reported only once config.c:413: error: for each function it appears in.) make: *** [config.o] Error 1 make: *** Waiting for unfinished jobs.... gx11.c: In function `info_text_button_press_event': gx11.c:1249: warning: implicit declaration of function `GTK_TEXT' gx11.c:1249: error: invalid type argument of `->' gx11.c: In function `get_info_display': gx11.c:1314: warning: implicit declaration of function `gtk_text_new' gx11.c:1314: warning: assignment makes pointer from integer without a cast gx11.c:1315: warning: implicit declaration of function `gtk_text_set_editable' gx11.c:1322: error: invalid type argument of `->' gx11.c:1331: warning: implicit declaration of function `gtk_text_freeze' gx11.c:1350: warning: assignment makes pointer from integer without a cast gx11.c:1358: error: invalid type argument of `->' gx11.c:1379: warning: implicit declaration of function `gtk_text_insert' gx11.c:1389: warning: implicit declaration of function `gtk_text_thaw' gx11.c: In function `draw_prompt': gx11.c:1470: error: `GTK_WINDOW_DIALOG' undeclared (first use in this function) gx11.c:1470: error: (Each undeclared identifier is reported only once gx11.c:1470: error: for each function it appears in.) gx11.c: In function `draw_info': gx11.c:2009: warning: implicit declaration of function `gtk_text_set_point' gx11.c:2010: warning: implicit declaration of function `gtk_text_forward_delete' gx11.c:2011: warning: implicit declaration of function `gtk_text_get_length' gx11.c:2031: warning: implicit declaration of function `GTK_TEXT_INDEX' gx11.c: In function `aboutdialog': gx11.c:3289: error: `GTK_WINDOW_DIALOG' undeclared (first use in this function) gx11.c:3312: warning: assignment makes pointer from integer without a cast gx11.c:3317: error: invalid type argument of `->' gx11.c:3341: error: invalid type argument of `->' gx11.c: In function `createBugTracker': gx11.c:3351: warning: assignment makes pointer from integer without a cast gx11.c: In function `bugdialog': gx11.c:3378: error: `GTK_WINDOW_DIALOG' undeclared (first use in this function) gx11.c:3402: warning: assignment makes pointer from integer without a cast gx11.c:3409: error: invalid type argument of `->' gx11.c:3422: error: structure has no member named `font' gx11.c:3423: error: structure has no member named `font' gx11.c:3430: error: invalid type argument of `->' gx11.c:3451: error: invalid type argument of `->' gx11.c: In function `shelpdialog': gx11.c:3500: error: `GTK_WINDOW_DIALOG' undeclared (first use in this function) gx11.c:3514: warning: assignment makes pointer from integer without a cast gx11.c:3519: error: invalid type argument of `->' gx11.c: In function `create_splash': gx11.c:4350: error: `GTK_WINDOW_DIALOG' undeclared (first use in this function) gx11.c: In function `create_windows': gx11.c:4416: error: structure has no member named `font' gx11.c:4417: error: structure has no member named `font' gx11.c: In function `draw_info_windows': gx11.c:4865: warning: implicit declaration of function `gtk_text_set_adjustments' gx11.c: In function `draw_magic_map': gx11.c:4936: error: `GTK_WINDOW_DIALOG' undeclared (first use in this function) make: *** [gx11.o] Error 1 From nicolas.weeger at laposte.net Wed Apr 20 02:28:07 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Apr 20 02:30:03 2005 Subject: [crossfire] Gtk client, and theme issues Message-ID: > > Here are the compile errors I get when trying to compile against gtk 2: That's because GTK client uses GTK1 functions (obviously) which are deprecated in GTK2. So you need a GTK flag to tell GTK2 to actually use GTK1 things. >From memory, the flag is 'GTK_ENABLE_BROKEN'. I can check tonight with the Win32 specific flags, which of course include all required flags as it builds against GTK2. (or you can check yourself: check the 'win32.h' include, and the contents of 'gtkclient.dsp', which should contain defines) Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From nicolas.weeger at laposte.net Thu Apr 21 12:55:17 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu Apr 21 12:58:24 2005 Subject: [crossfire] Gtk client, and theme issues In-Reply-To: <4265E9F8.1010205@sonic.net> References: <4265E9F8.1010205@sonic.net> Message-ID: <4267E905.7010603@laposte.net> The settings used for the Windows versions are: * #define GTK_ENABLE_BROKEN * #define GTK_WINDOW_DIALOG GTK_WINDOW_TOPLEVEL * #define GC GdkGC Ryo From b.t.lally at warwick.ac.uk Sat Apr 23 19:52:09 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Sat Apr 23 19:33:00 2005 Subject: [crossfire] channels Message-ID: <200504240152.09906.b.t.lally@warwick.ac.uk> I've attached a rather bulky patch to casper's RFE at http://sourceforge.net/tracker/index.php?func=detail&aid=1183961&group_id=13833&atid=363833 It is now at a state that it can be considered ready for wider review/testing. If there is anyone who has time on their hands, there are two versions, one is the patch itself, one is a diff of only the files that have code changes, and is therefore sane to attempt to read. (as well as being less likely to break next server code update :) ) Any comments would be greatly appreciated. From tchize at myrealbox.com Sun Apr 24 10:04:48 2005 From: tchize at myrealbox.com (tchize) Date: Sun Apr 24 10:05:09 2005 Subject: [crossfire] channels In-Reply-To: <200504240152.09906.b.t.lally@warwick.ac.uk> References: <200504240152.09906.b.t.lally@warwick.ac.uk> Message-ID: <200504241704.54239.tchize@myrealbox.com> Hello, i saw this in channels, file c_chat.c: {"literature", 5, "The contents of signs, scrolls, and other written texts.",1}, I admit, have not yet tested your patch, and specially it's integration with the one am currently writing about readables. However, looks like the suggested change is may conflict, in the literature part, with the one am working on. Let me explain. Reading of signs, books, monuments, letters, aso, is a pain to manipulate for client as there is no specialized way of sending those. If you want you client to show you a nice book picture with the text written on it, you have to parse server message and catch all the 'you open the ? and start reading.', same problem if you want to draw a scroll, a letter, a sign, and so on. The patch am working on is based on a subscribe/notify paradigm, not made to handle channels like yours, as i think this is a different part and you are doing quite well in it, but made to identify all kinds of readables send to client by sending them with another command than draw_info. The client subscribe to the server for the send of specialized data. Client can subscribe to receiving books in a special way, subscribe to receiving signs in a special way, subscribe to receiving motd in a special way, ... Now, if your patch, in this part, is just about telling server 'send me or do not send me literature' there will be no conflict in code logic and there will in fact be complementarity. But if your patch is about 'send me literature in a way so client can identify it as literature' there will be a conflict of use. According to the messages on the bugtrack, you are in the first case (replacing the listen level to let client tell server what may and what may not be send), but i just want to be sure about it before your patch make his way to the cvs :) Regards, Tchize -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html Le Dimanche 24 Avril 2005 02:52, Brendan Lally a ?crit : I've attached a rather bulky patch to casper's RFE at http://sourceforge.net/tracker/index.php?func=detail&aid=1183961&group_id=138 33&atid=363833 It is now at a state that it can be considered ready for wider review/testing. If there is anyone who has time on their hands, there are two versions, one is the patch itself, one is a diff of only the files that have code changes, and is therefore sane to attempt to read. (as well as being less likely to break next server code update :) ) Any comments would be greatly appreciated. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050424/7c576f0e/attachment.pgp From b.t.lally at warwick.ac.uk Sun Apr 24 12:23:19 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Sun Apr 24 12:04:19 2005 Subject: [crossfire] channels In-Reply-To: <200504241704.54239.tchize@myrealbox.com> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504241704.54239.tchize@myrealbox.com> Message-ID: <200504241823.19997.b.t.lally@warwick.ac.uk> On Sunday 24 Apr 2005 16:04, tchize wrote: > Hello, i saw this in channels, file c_chat.c: > {"literature", 5, "The contents of signs, scrolls, and other written > texts.",1}, Yeah, this is one of the system channels I have defined. The system channels are where all the server coded messages should go to, messages from other players are going to be handled with a different set of channels. (shout and chat are going to disappear as 'commands' they would appear as 'channels' that have no owner but are postable. > The patch am working on is based on a subscribe/notify paradigm, not made > to handle channels like yours, as i think this is a different part and you > are doing quite well in it, but made to identify all kinds of readables > send to client by sending them with another command than draw_info. The > client subscribe to the server for the send of specialized data. Client can > subscribe to receiving books in a special way, subscribe to receiving signs > in a special way, subscribe to receiving motd in a special way, ... Ok then, that shouldn't overlap at all, although it would be quite straightforward to have two seperate channels, a literature and a 'literature2' channel. That way the player could turn on both, neither or either channel as they chose. instead of new_draw_info(NDI_UNIQUE | NDI_NAVY, COMM_LITERATURE, op, tmp->msg); have new_draw_info(NDI_UNIQUE | NDI_NAVY, COMM_LITERATURE, op, tmp->msg); tchize's_new_shiney_function(arguments, it, takes, COMM_LITERATURE2, op); however, I don't know how well that would match up with what you describe, which sounds more powerful and flexible. > Now, if your patch, in this part, is just about telling server 'send me or > do not send me literature' there will be no conflict in code logic and > there will in fact be complementarity. Yeah, it is, in order to have your books work seemlessly with this, you would merely need to check that get_channel_state(pl,COMM_WHATEVER) is 1 somewhere in your alternate new_draw_info function (wherever it is you are checking for the existing listen levels currently.) > But if your patch is about 'send me literature in a way so client can > identify it as literature' there will be a conflict of use. client identification I haven't looked at yet, mostly because that is a client side thing and my patch is about server side support for filtering channels more easily. However, a way to get the gtk2 client to parse the channels command and allow their assignment to tabs would be an interesting thing for someone who knows gtk well to play with. In any event it will involve altering the comm protocol to send pri, which doesn't occur atm (probably calls for a 'newer_draw_info' command.....) From tchize at myrealbox.com Sun Apr 24 13:10:47 2005 From: tchize at myrealbox.com (tchize) Date: Sun Apr 24 13:11:13 2005 Subject: [crossfire] channels In-Reply-To: <200504241823.19997.b.t.lally@warwick.ac.uk> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504241704.54239.tchize@myrealbox.com> <200504241823.19997.b.t.lally@warwick.ac.uk> Message-ID: <200504242010.52345.tchize@myrealbox.com> Thanks for clarifications. So have nothing against your patch (if you except the fact i don't have time to test it;) Le Dimanche 24 Avril 2005 19:23, Brendan Lally a ?crit : Yeah, it is, in order to have your books work seemlessly with this, you would merely need to check that get_channel_state(pl,COMM_WHATEVER) is 1 somewhere in your alternate new_draw_info function (wherever it is you are checking for the existing listen levels currently.) -- Quite easy to add when you patch get in CVS. Thanks for informations. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- David Delbecq d.delbecq@laposte.net Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net:11371/pks/lookup?op=index&search=tchize http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x5436C17C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050424/3e151853/attachment.pgp From mwedel at sonic.net Sun Apr 24 22:43:44 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Apr 24 22:45:18 2005 Subject: [crossfire] channels In-Reply-To: <200504240152.09906.b.t.lally@warwick.ac.uk> References: <200504240152.09906.b.t.lally@warwick.ac.uk> Message-ID: <426C6770.3000709@sonic.net> Brendan Lally wrote: > I've attached a rather bulky patch to casper's RFE at > http://sourceforge.net/tracker/index.php?func=detail&aid=1183961&group_id=13833&atid=363833 > > It is now at a state that it can be considered ready for wider review/testing. > > If there is anyone who has time on their hands, there are two versions, one is > the patch itself, one is a diff of only the files that have code changes, and > is therefore sane to attempt to read. (as well as being less likely to break > next server code update :) ) > > Any comments would be greatly appreciated. Looking at the patch, it in no way extends or lets the client know what is on what channel. The patch filters the different levels on the server and nothing more. IMO, that is of limited usefulness (I'd argue in many cases, a potentially bad thing as a player could inadvertently turn of notification of relatively important events). The client itself still won't know what channel a message belong to, so doesn't help in the case of different tabs for different messages. So from the original RFE, really only implements a portion of it. What I'd much rather see is a changing of the NDI values to be descriptive of the message (the com levels you describe would make good new NDI values). If we're going to change all the new_draw_info_.. calls, less change them to that. This then does give the client the info on what the command is then about (reply, literature, kills, etc) and so the client can decide what to do with it. That could include deciding not to display it. The client would have to communicate to the server (in form of a setup command) that it understands these new NDI values. For the case that the client doesn't, it wouldn't be hard to have a simple mapping table of old to new (eg, NDI_TELL should be orange, NDI_CHAT is ...). Now there is some wastefullness in the server sending something to the client that the client then will not display, but IMO, I don't see that as much an issue - I can't see the bandwidth wastage being at all significant. what I describe is IMO what the original requestor is really looking for. Changing the NDI levels has been on the TODO list for a long time - it also has other advantages: 1) Lets user customize which window/tab messages go into (Described above) 2) Lets user customize color and font of messages 2b) Lets us use fixed width fonts for messages that would display better that way (shop listings, who, map, other commands that try to put things in tables) 3) Makes it easier for client to grab certain messages if it wants to (I can't really see much reason, but perhaps scripts might want to). So all that said, while very quickly glancing over your patch, I don't see anything particularly wrong with it, overall, it isn't moving things in the direction they need to move, so I don't see much point in applying it. some day, NDI levels will get redone, making the change of listen levels pretty much moot (as important can be gleaned from the NDI message type). > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mwedel at sonic.net Sun Apr 24 22:56:50 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Apr 24 22:57:18 2005 Subject: [crossfire] channels In-Reply-To: <200504241704.54239.tchize@myrealbox.com> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504241704.54239.tchize@myrealbox.com> Message-ID: <426C6A82.6040302@sonic.net> tchize wrote: > > The patch am working on is based on a subscribe/notify paradigm, not made to > handle channels like yours, as i think this is a different part and you are > doing quite well in it, but made to identify all kinds of readables send to > client by sending them with another command than draw_info. The client > subscribe to the server for the send of specialized data. Client can > subscribe to receiving books in a special way, subscribe to receiving signs > in a special way, subscribe to receiving motd in a special way, ... > > Now, if your patch, in this part, is just about telling server 'send me or do > not send me literature' there will be no conflict in code logic and there > will in fact be complementarity. > But if your patch is about 'send me literature in a way so client can identify > it as literature' there will be a conflict of use. > According to the messages on the bugtrack, you are in the first case > (replacing the listen level to let client tell server what may and what may > not be send), but i just want to be sure about it before your patch make his > way to the cvs :) what I said in my other email sounds like it will conflict with what you are suggesting. But in a project with multiple people developing, that is bound to happen. I'd also think the amount of conflict would be minor, as all I'm saying is changing things like NDI_BLUE to NDI_LITERATURE. I'd like more details on what you are thinking/trying to do. Attaching/sending images for scrolls (in forms of maps) is a very nifty idea. However, to me, it seems that either the client will support displaying this alternate form of data or not. It seems unlikely to me that the client could display an image that is part of a scroll but not a map, so having a different subscription method for all the possible types of messages seems like over complication. I'd suggest that there be some form of caching/client requesting the additional info. That is because one could envision something like a map being on a scroll - you really don't want to have to download the image every time the player reads the scroll - the client could certainly store a copy of the image away someplace, and thus next time, quickly pull it from cache. I say this because I'd think that things like map images will likely be in the several hundred pixel by several hundred pixel range, and thus take significantly more time to transmit than most data generated. I'd be interested in seeing your proposal and storing/associating this data with the objects in question. > From mwedel at sonic.net Sun Apr 24 23:36:45 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Apr 24 23:37:17 2005 Subject: [crossfire] Gtk client, and theme issues In-Reply-To: <4267E905.7010603@laposte.net> References: <4265E9F8.1010205@sonic.net> <4267E905.7010603@laposte.net> Message-ID: <426C73DD.5090105@sonic.net> Nicolas Weeger wrote: > The settings used for the Windows versions are: > * #define GTK_ENABLE_BROKEN > * #define GTK_WINDOW_DIALOG GTK_WINDOW_TOPLEVEL > * #define GC GdkGC Tried adding those to the gx11.h file, still get bunches of errors. That said, this is something someone probably can fix, but I'll happily be using the GTKv2 client, so isn't a high priority on my list of things to do. From b.t.lally at warwick.ac.uk Mon Apr 25 00:11:22 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Sun Apr 24 23:53:18 2005 Subject: [crossfire] channels In-Reply-To: <426C6770.3000709@sonic.net> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <426C6770.3000709@sonic.net> Message-ID: <200504250611.22165.b.t.lally@warwick.ac.uk> First point I'm going to make is that I posted an updated diff on the tracker. On Monday 25 Apr 2005 04:43, Mark Wedel wrote: > Looking at the patch, it in no way extends or lets the client know what > is on what channel. Yeah, I mostly haven't got round to that bit yet. I've been focusing more on player created channels. However, I have already absorbed that in the process of implementing shout and chat as channels. > The patch filters the different levels on the server and nothing more. > IMO, that is of limited usefulness (I'd argue in many cases, a potentially > bad thing as a player could inadvertently turn of notification of > relatively important events). good point, initialstate 2 should mean mandatory. and be used for COMM_RESPOND this can be a TODO... > The client itself still won't know what channel a message belong to, so > doesn't help in the case of different tabs for different messages. So from > the original RFE, really only implements a portion of it. In the latest version of it, which I have been playing with today, the channels are linked to NDI values too. I'm using this for chat and shout at the moment, as well as letting custom channels have their colour altered. > What I'd much rather see is a changing of the NDI values to be > descriptive of the message (the com levels you describe would make good new > NDI values). If we're going to change all the new_draw_info_.. calls, less > change them to that. ok then, so if I alter new_draw_info to remove (or at least ignore) the 'colour' flag (and then fetch from the channel def) then that will achieve what you describe. it is then merely a case of adding a NDI_FIXED_FONT define, and including it in the flags for COMM_RESPOND and COMM_LITERATURE > This then does give the client the info on what the command is then about > (reply, literature, kills, etc) and so the client can decide what to do > with it. That could include deciding not to display it. If it is server side (as it is at the moment) then it is possible to have a dm command to check that a player recieved a message. and for a channel owner to see who is listening to them. It is also needed for the channel names to become commands. (as they now do). If all the channels set their own NDI flags, then client filtering would still be possible too (things like Tchize's books). > some day, NDI levels will get redone, making the change of listen levels > pretty much moot (as important can be gleaned from the NDI message type). it does seem very much like we are looking at the same problem from opposite directions. You want to replace listen levels with NDI flags, I want to (and mostly have, bar a few minor modifications to the array in init_channels, and a small tweak in new_draw_info) absorb NDI flags into listen levels. From mwedel at sonic.net Mon Apr 25 01:20:57 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Apr 25 01:21:20 2005 Subject: [crossfire] channels In-Reply-To: <200504250611.22165.b.t.lally@warwick.ac.uk> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <426C6770.3000709@sonic.net> <200504250611.22165.b.t.lally@warwick.ac.uk> Message-ID: <426C8C49.2020005@sonic.net> Brendan Lally wrote: > >> The client itself still won't know what channel a message belong to, so >>doesn't help in the case of different tabs for different messages. So from >>the original RFE, really only implements a portion of it. > > > In the latest version of it, which I have been playing with today, the > channels are linked to NDI values too. I'm using this for chat and shout at > the moment, as well as letting custom channels have their colour altered. Yes, that helps out. Problem is, the client still can't differentiate between it being a channel by color vs other messages. For example, if one of the colors is light blue, this works pretty good most of the time, but the client doesn't easily have a way to filter out the chat type messages compared to changes in resistance. > > >> What I'd much rather see is a changing of the NDI values to be >>descriptive of the message (the com levels you describe would make good new >>NDI values). If we're going to change all the new_draw_info_.. calls, less >>change them to that. > > > ok then, so if I alter new_draw_info to remove (or at least ignore) the > 'colour' flag (and then fetch from the channel def) then that will achieve > what you describe. it is then merely a case of adding a NDI_FIXED_FONT > define, and including it in the flags for COMM_RESPOND and COMM_LITERATURE > The long term model here is that the NDI_color values go away (except for compatibility with older cleans) and the NDI values are instead meaningful relative to the content they are providing (eg, NDI_ATTACK, NDI_DEATH, NDI_MENU, etc). Basically, instead of changing the listen levels, change the NDI values. A range of values could be used for the channels (there has to be some relatively small (<30) limit of channels I'd think). > >> This then does give the client the info on what the command is then about >>(reply, literature, kills, etc) and so the client can decide what to do >>with it. That could include deciding not to display it. > > > If it is server side (as it is at the moment) then it is possible to have a dm > command to check that a player recieved a message. and for a channel owner to > see who is listening to them. It is also needed for the channel names to > become commands. (as they now do). If all the channels set their own NDI > flags, then client filtering would still be possible too (things like > Tchize's books). True. However, DM can only really check that the message was sent to the client - still no way of knowing if the player actually read it. So for the chat related channels, it probably does make sense that they are subscriber based. But for the rest (another generated by the code), they should just be sent pretty much no matter what the listen level is. > > >>some day, NDI levels will get redone, making the change of listen levels >>pretty much moot (as important can be gleaned from the NDI message type). > > > it does seem very much like we are looking at the same problem from opposite > directions. You want to replace listen levels with NDI flags, I want to (and > mostly have, bar a few minor modifications to the array in init_channels, and > a small tweak in new_draw_info) absorb NDI flags into listen levels. The thing is, from a protocol standpoint, much easier to do it the way I'm talking about. For all messages sent to the client, 1 byte is already used for the NDI value. Of which there are only actually 12 values being used, leaving 240 other values that can be used without any changes to the protocol. The only change is the adjustment for the client to do something meaningful with those newly defined NDI values. What you haven't addressed is how you get the listen level info to the client, because that is what is needed for the client to do anything meaningful. Without know your plans on that, hard to really say for sure, but my impression would be you'd send the listen level to the client, which means a new protocol command. The other thing I'm think about here is simplicity. Having both channel values and colors being passed to new_draw_info commands just seems complicated on both sides. On the client side, it makes things much more complicated in letting the user set their prefs (you now have 12 * num channel possiblities). For example, you oculd have both blue and black attack messages, so now potentially letting a user choose a style for both of those. Now certainly, a large number of combinations would never be used, but there is no simple way of knowing that (and nothing preventing that from not being in the case in the future). So what I'm saying, is I'd like to have just one value associated with each new_draw_info call which determines the info sent to the client - either the channel number or an NDI value. And directly related, only one of those should be getting passed into the draw_info calls. If you want to use the channels, that fine, but then remove all the NDI values and write up a basic channel->conversion routine for old clients. I just don't want to see both values there, because only one is really needed, and it would have to get cleaned up at some point - I'd rather it be done now vs later, because experience shows that it won't be done later From b.t.lally at warwick.ac.uk Mon Apr 25 13:00:35 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Mon Apr 25 12:41:27 2005 Subject: [crossfire] channels In-Reply-To: <426C8C49.2020005@sonic.net> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504250611.22165.b.t.lally@warwick.ac.uk> <426C8C49.2020005@sonic.net> Message-ID: <200504251900.35517.b.t.lally@warwick.ac.uk> On Monday 25 Apr 2005 07:20, Mark Wedel wrote: > Yes, that helps out. Problem is, the client still can't differentiate > between it being a channel by color vs other messages. > > For example, if one of the colors is light blue, this works pretty good > most of the time, but the client doesn't easily have a way to filter out > the chat type messages compared to changes in resistance. Ok then, I've posted another patch where this is resolved. all channels have NDI_ values attached to them, and new_draw_info fetches colour info from the channel instead of the flags argument. > > If it is server side (as it is at the moment) then it is possible to have > > a dm command to check that a player recieved a message. and for a channel > > owner to see who is listening to them. It is also needed for the channel > > names to become commands. (as they now do). If all the channels set their > > own NDI flags, then client filtering would still be possible too (things > > like Tchize's books). > > True. However, DM can only really check that the message was sent to the > client - still no way of knowing if the player actually read it. but at least the 'I have it filtered' excuse doesn't work.... > So for the chat related channels, it probably does make sense that they > are subscriber based. But for the rest (another generated by the code), > they should just be sent pretty much no matter what the listen level is. well, you could do filtering client side, but if that is the case then there are two different means of filtering comms. I intend to have a total of 3 different classes of channel. system server and player. system channels are the ones defined in c_chat.c currently. server ones are ones that the server admin would be able to define. (shout and chat would be two of these, which would be the default, but big servers like mf and cat2 might want a 'helpme' channel, or a trade channel, or an announce channel, or a off-topic channel, or a roleplay channel, or what have you). player ones are the ones I had working as of yesterday, they are simply for players to use as they see fit. In IRC terms then, system messages are NOTICES, server messages are channel traffic, and player messages are actually kinda a cross between /msg and IM 'chat's > What you haven't addressed is how you get the listen level info to the > client, because that is what is needed for the client to do anything > meaningful. Without know your plans on that, hard to really say for sure, > but my impression would be you'd send the listen level to the client, which > means a new protocol command. I'd send the colour value attached to the listen level to the client, which there is already support for. > On the client side, it makes things much more complicated in letting the > user set their prefs (you now have 12 * num channel possiblities). For > example, you oculd have both blue and black attack messages, so now > potentially letting a user choose a style for both of those. er, blue messages would be on their own channel, seperate from black ones. If that is needed something like a COMM_DANGER channel could be used, just decide what messages should go there. > If you want to use the channels, that fine, but then remove all the NDI > values and write up a basic channel->conversion routine for old clients. I > just don't want to see both values there, because only one is really > needed, and it would have to get cleaned up at some point - I'd rather it > be done now vs later, because experience shows that it won't be done later I'm not quite sure what you mean by a conversion routine. There are 2 bytes in new draw info. the first is used by the function, the second is sent. in hexidecimal that is 4 characters. currently; 1 2 3 4 F F F F 4 is the colour hint. (default colour if you want to make the client be able to override it), all bar 3 of these are already used. 2 is the special flags, they combine with 4. 3 and 1 are unused. (though 3 is in the colour mask). however, with only 15 system channels, they can each have a value in byte 3. (and colour mask can be changed to 0x0F rather than 0xFF). Do you mean then that I should somehow strip out the high nybble if the client isn't recent enough? (how do you propose to tell?) In any event, new_draw_info still needs to have its arguments changed, but that is merely something easy and long-winded for when I have better things to avoid doing (unfortunatly I have rather too many things that meet that description over the next month....). From mwedel at sonic.net Tue Apr 26 01:41:10 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Apr 26 01:41:35 2005 Subject: [crossfire] channels In-Reply-To: <200504251900.35517.b.t.lally@warwick.ac.uk> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504250611.22165.b.t.lally@warwick.ac.uk> <426C8C49.2020005@sonic.net> <200504251900.35517.b.t.lally@warwick.ac.uk> Message-ID: <426DE286.3030200@sonic.net> Brendan Lally wrote: > > well, you could do filtering client side, but if that is the case then there > are two different means of filtering comms. > > I intend to have a total of 3 different classes of channel. > > system > server > and player. > > system channels are the ones defined in c_chat.c currently. > server ones are ones that the server admin would be able to define. (shout and > chat would be two of these, which would be the default, but big servers like > mf and cat2 might want a 'helpme' channel, or a trade channel, or an announce > channel, or a off-topic channel, or a roleplay channel, or what have you). > player ones are the ones I had working as of yesterday, they are simply for > players to use as they see fit. > > In IRC terms then, system messages are NOTICES, server messages are channel > traffic, and player messages are actually kinda a cross between /msg and IM > 'chat's I guess the issue I see is that you add channels to basically every draw_info call, without there really being a need to do so. IMO, it would be sufficient to have channels just for the chat related stuff - that would have been a much more modest patch and probably basically given the level of functionality needed. From your list of defined COMM channels, there is either the case of the channel being vary narrowly focused (COMM_JOINQUIT) and in other cases, very broad (COMM_EFFECT, COMM_ACTION). There is nothing inherently wrong with the patch. I just look at it and think "it's taken a lot of work to change all the new_draw_info() calls, but doesn't go far enough to actually fix up the client preference/styling side of things". So with all those changes, the following item from the TODO list basically remains: - Change draw_info so that server tells client what type of message it is instead of the color. Client can then decide what color to draw it or other special handling. which will have to get done in the future. and I still don't like the fact that you have added subscribe ability to many messages which are currently priority 0 (you always get them). I just don't see any compelling reason why those were put into channels - as said before, the problem is sure to arise that smeone will unsubscribe, and all sorts of problems arise. At some level, you don't give users the choice to disable basic functionality, and IMO this falls into the case. The obvious fix is then to make it some certain channels can't be unsubscribed, but then the question is what is the purpose of those channels. I'm just stuck looking at patch and thinking that to handle that TODO point above, most of the changes you make will be undone/redone, which does't make me really happy. But probably isn't a reason to necessary not do the patch - it just doesn't make me really happy. Also, just as another note, the reason the newclient.h file (and NDI_ values exist) is because both the client and server must have a common reference for what values mean. So if you send the channel info along the draw info (which I agree there is space in the value to do so), it does limited good unless the newclient.h file is updated to know what the values mean (the reason they are all in that file is that file can then just be copied to the client.) That is also one reason I like the idea if extending the NDI flags, since that mechanism and definition already are established in the protocl and file itself. From nicolas.weeger at laposte.net Tue Apr 26 04:37:11 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Apr 26 04:37:37 2005 Subject: [crossfire] Items that evolve all the time Message-ID: Hello. I'd feel like implementing growing stuff, ie for instance plant an apple tree seed and it becomes a nice apple tree, then yields apples. Or a beehive which generates honey at a certain rythm. No planting for now (but that may come!), but still i'd like to have items generated from time to time. Note that I probably won't use a creator, as I don't want items inserted into the map, but items stored into the "growing item" that you could collect with special tools. The trouble I'm being confronted to is that I need to have those items "move"/grow even when their map is not loaded, so that everything grows correctly - this makes the game more interesting imo. The other option of course is for players to wait for map reset, but somehow I think it's less interesting - or put a short reset time for that kind of maps, but still you could loot much stuff each time. So I'm wondering how to achieve that. I see 2 options: * do something like the weather code. Store "growing" items somewhere, parse that regularly, update maps accordingly. Drawback: you can potentially have many different maps containing growing items, not only the outside world. Thus beware the number of maps that need to be taken into account. * store items like an overlay / unique tile, with tickcount. Then when loading make them run for elapsed period since being saved. Drawback is that it may take some time at map loading - though I don't expect the growing behaviour that hard, more like 'for each tick add some random food amount, when it reaches some value there is a new item to collect'. The 2nd approach feels the best, but then I need to store tick count somehow. Note that potentially items could change based on whether they have collectable items or not (ie tree with apple(s), bare tree), so there'll be some tweaking too. Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From tchize at myrealbox.com Tue Apr 26 05:21:31 2005 From: tchize at myrealbox.com (tchize@myrealbox.com) Date: Tue Apr 26 05:21:38 2005 Subject: [crossfire] Items that evolve all the time In-Reply-To: References: Message-ID: <200504261221.31764.tchize@myrealbox.com> Was awaiting a growing world for long :) I already thought about it and i concluded making items grows at map opening was the lowest cpu consuming process. Perhaps we could add a tag to object like isAlwaysActive. Then at map loading time, all object (not only growing ones) with isAlwaysActive at 1 will get their pending moves counts (there is already such a thing and it's at the core of the object activity code) increased by the nubmer of turn they would have accumulted if the server did lag for the whole time the map was swapped out. The advantage of such a process is that you only have to implement classical 'move' of your growing object, the disavatage is that if a map was swapped ou for a very long time, player could see a seed suddently become a dead tree. But this should not be a problem as, in my mind, the fastest growing objects (honey making thingie) should get more than one play turn per 5 minutes and so, to get a really strange result of a growing object, this would mean having a map swapped out for about 20 to 30 turns, which represent 100 to 150 minutes swap out. Most of map get reset before this happen. On the other hand , sever could give map object the time to do their 'pending turn' just before inserting the player, and so player won't see anything special (and since map was loaded from swap, there is nobody else in there) So to conclude: - no need for an extra storing tag for the last time it got a turn. There is already logic for that (the tag is named lastxxx don't have code here) - giving isAlwaysActive objects the opportunity to do their accumulated turns since last map swap out (can be done in loading code using timestamp in the map struct). This could apply to things other than growables - handle the growing process in the object move code - no need for such things as an overlay map Now concercing weather interaction. This is abvious values like humidity and temperature, when available, should influence the growing process :) And the type of ground too! Le Mardi 26 Avril 2005 11:37, Nicolas Weeger a ?crit : > Hello. > > I'd feel like implementing growing stuff, ie for instance plant an apple > tree seed and it becomes a nice apple tree, then yields apples. Or a > beehive which generates honey at a certain rythm. No planting for now (but > that may come!), but still i'd like to have items generated from time to > time. Note that I probably won't use a creator, as I don't want items > inserted into the map, but items stored into the "growing item" that you > could collect with special tools. > > The trouble I'm being confronted to is that I need to have those items > "move"/grow even when their map is not loaded, so that everything grows > correctly - this makes the game more interesting imo. The other option of > course is for players to wait for map reset, but somehow I think it's less > interesting - or put a short reset time for that kind of maps, but still > you could loot much stuff each time. > > So I'm wondering how to achieve that. I see 2 options: > * do something like the weather code. Store "growing" items somewhere, > parse that regularly, update maps accordingly. Drawback: you can > potentially have many different maps containing growing items, not only the > outside world. Thus beware the number of maps that need to be taken into > account.. * store items like an overlay / unique tile, with tickcount. Then > when loading make them run for elapsed period since being saved. Drawback > is that it may take some time at map loading - though I don't expect the > growing behaviour that hard, more like 'for each tick add some random food > amount, when it reaches some value there is a new item to collect'. > > The 2nd approach feels the best, but then I need to store tick count > somehow. Note that potentially items could change based on whether they > have collectable items or not (ie tree with apple(s), bare tree), so > there'll be some tweaking too. > > Ryo > > Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; > 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- David Delbecq Royal Meteorological Institute of Belgium From b.t.lally at warwick.ac.uk Tue Apr 26 06:53:03 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Tue Apr 26 06:35:39 2005 Subject: [crossfire] channels In-Reply-To: <426DE286.3030200@sonic.net> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504251900.35517.b.t.lally@warwick.ac.uk> <426DE286.3030200@sonic.net> Message-ID: <200504261253.03906.b.t.lally@warwick.ac.uk> On Tuesday 26 Apr 2005 07:41, Mark Wedel wrote: > I guess the issue I see is that you add channels to basically every > draw_info call, without there really being a need to do so. > > IMO, it would be sufficient to have channels just for the chat related > stuff - that would have been a much more modest patch and probably > basically given the level of functionality needed. it wouldn't have tied in so nicely with the listen levels though, because the listen levels would all be different, ranging from 0 to 15. numerous assumptions are made that they are now > From your list of defined COMM channels, there is either the case of the > channel being vary narrowly focused (COMM_JOINQUIT) and in other cases, > very broad (COMM_EFFECT, COMM_ACTION). Well, pretty much comm_effect is something that should be on always unless you are running a script or long keybinding. comm_action is a buffered comm_effect. bots will want to turn these channels (and almost all others) off. > There is nothing inherently wrong with the patch. I just look at it and > think "it's taken a lot of work to change all the new_draw_info() calls, > but doesn't go far enough to actually fix up the client preference/styling > side of things". So with all those changes, the following item from the > TODO list basically remains: > > - Change draw_info so that server tells client what type of message it is > instead of the color. Client can then decide what color to draw it > or other special handling. > > which will have to get done in the future. yeah, except that instead has roughly mutated into 'as well' (at least temporarily). I can use the high nybble of new_draw info for the channel number. That gives 16 values immediatly, so I budge the existing system messages into 13 of those values (16*channel_number) with 0 used for custom channels. (shout and chat would be 'server' channels under the new definition). then the client can check only the high nibble and assign colours to those messages in it's own little dialog. the colour value definitions would remain as a way to not affect old clients, noticably and 6-12 months later get removed. (which would make old clients display everything in black....). At that point custom channels could take the low nibble values. with channel number value being defined as.... mod(15)+(value-mod(15)) (no, probably isn't the nicest thing to do, but it will break the least.) (optional) at that point add a get_channel_name in the protocol, to let the client label the tabs better. > and I still don't like the fact that you have added subscribe ability to > many messages which are currently priority 0 (you always get them). > > I just > don't see any compelling reason why those were put into channels - as said > before, the problem is sure to arise that smeone will unsubscribe, and all > sorts of problems arise. At some level, you don't give users the choice to > disable basic functionality, and IMO this falls into the case. > > The obvious fix is then to make it some certain channels can't be > unsubscribed, but then the question is what is the purpose of those > channels. actually, setting listen 0 currently will turn them all off (I guess that has just never been done by accident before). It could probably be counted as a bug, but if so it is one that is relied on occasionally. comm_respond should probbably be fixed on though. arguably so should comm_ext. > I'm just stuck looking at patch and thinking that to handle that TODO > point above, most of the changes you make will be undone/redone, which > does't make me really happy. But probably isn't a reason to necessary not > do the patch - it just doesn't make me really happy. er, I'd only really need to 1) change the arguments of new_draw_info (I've changed the function itself already, so literally just 1a) backup and make a seperate copy of c_chat.c 2) for i in $(ls server/*); do cat server/$i | sed s/NDI_UNIQUE \|/ / >$i.new; cat server/$i | sed s/NDI_[:alpha:]\,/ / > $i (I'll need to check the syntax on that) 3) compile and manually change some corner cases (and c_chat.c). 4) set the colour value in the channels as described earlier. removing infomation is much easier than adding it.... From nicolas.weeger at laposte.net Tue Apr 26 06:47:29 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Apr 26 06:47:39 2005 Subject: [crossfire] Items that evolve all the time Message-ID: > Was awaiting a growing world for long :) That'll add, imo, much fun to the game, and many opportunities to do other things than monster-bashing :) (which *is* fun, but sometimes you need some rest from that) > So to conclude: > - no need for an extra storing tag for the last time it got a turn. There is > already logic for that (the tag is named lastxxx don't have code here) Didn't know that tag, will look for it. > - no need for such things as an overlay map I'll disagree here. Imagine a beehive generating honey, at approx 1 volume per 10 minutes (random thoughts), holding max 10 volumes. When first time map is loaded, you'll have nothing - wait 10 minutes, 1 volume. Map gets swapped out, you need to remember that 1 volume, even if you happen to run all turns. Oh, I forgot to say that: the idea is that growth is randomized (ie for instance need 500 food for 1 volume, growth rate 5 to 10 food units per turn). So you can't just fastforward from the initial settings, you need to remember a few values. > Now concercing weather interaction. This is abvious values like humidity and > temperature, when available, should influence the growing process :) > And the type of ground too! I'm not that far in the thinking yet :) That could be done, but I'll first do a basic thing, then we'll think about new more behaviours (*gets ready to make a 'plant' file in lib *) Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From tchize at myrealbox.com Tue Apr 26 07:41:15 2005 From: tchize at myrealbox.com (tchize@myrealbox.com) Date: Tue Apr 26 07:41:38 2005 Subject: [crossfire] Items that evolve all the time In-Reply-To: References: Message-ID: <200504261441.15682.tchize@myrealbox.com> Le Mardi 26 Avril 2005 13:47, Nicolas Weeger a ?crit : > > Was awaiting a growing world for long :) > > That'll add, imo, much fun to the game, and many opportunities to do other > things than monster-bashing :) (which *is* fun, but sometimes you need some > rest from that) > Indeed, time to open some fish & chips at scorn square central > > So to conclude: > > - no need for an extra storing tag for the last time it got a turn. There > > is already logic for that (the tag is named lastxxx don't have code here) > > Didn't know that tag, will look for it. This tag is increased by the object speed at each server tick. When it reach a fixed amount, that fixed amount is substracted and the object plays on turn. (simply one call to move(ob) i think) > > > - no need for such things as an overlay map > > I'll disagree here. Imagine a beehive generating honey, at approx 1 volume > per 10 minutes (random thoughts), holding max 10 volumes. When first time > map is loaded, you'll have nothing - wait 10 minutes, 1 volume. Map gets > swapped out, you need to remember that 1 volume, even if you happen to run no need to remember them in an overlay map. and remembering the tree has one apple is as simple as putting an apple in the tree inventory. sure you need a may to configure your bee hive as having a max of 15 volumes of honey, but that need to be set in the object not in an overlay map. It would be like creating an overlay map to say a chest has content xy and has a max weight of 5000. Hey wait, i found out where to state your growable can produce a max of ten volumes. > all turns. Oh, I forgot to say that: the idea is that growth is randomized > (ie for instance need 500 food for 1 volume, growth rate 5 to 10 food units > per turn). So you can't just fastforward from the initial settings, you > need to remember a few values. I never said the opposite. Let's say each turn an apple tree has a probability of one to ten of producing an apple and the tree gets a turn every 3 minutes. Statistically, the tree would produce one apple about every 15 minutes but it could produce three apples in 9 minutes like it could produce no apple for 30 minutes. Concerning the fast forward, i probably wasn't clear. The idea was, at map loading time, you make a quick calculation on every 'alwaysactive' to count the number of turn it should have 'moved'. Let's say the map was swapped out for 30 minutes and there is my tree in it. Player enter map, server calculate, for the tree and using the informations in the map structure used for reset, a gap of 10 turns (or it add the number of missed 'server ticks' to the lastxxxx i don't remember the name), and so the object will get, immediatly, from the main server loop, 10 executions of the move(ob) functions. This is just a matter of executing n times in a row a function which would have have been executed n times but not in a row if map was still active instead of being swapped out. The result would be the same. What i *never* meaned to say was 'ok tree was out for 30 minutes, so give it 2 apples'. Indeed i had randomizing in head too :) > > > Now concercing weather interaction. This is abvious values like humidity > > and temperature, when available, should influence the growing process :) > > And the type of ground too! > > I'm not that far in the thinking yet :) > That could be done, but I'll first do a basic thing, then we'll think about > new more behaviours (*gets ready to make a 'plant' file in lib *) > Yes, one step at a time, but i fear to see player planting tree seeds in the scorn square :) > Ryo > > Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; > 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire Ok, need to do real work -- David Delbecq Royal Meteorological Institute of Belgium From nicolas.weeger at laposte.net Tue Apr 26 08:17:09 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Apr 26 08:17:39 2005 Subject: [crossfire] Items that evolve all the time Message-ID: > Indeed, time to open some fish & chips at scorn square central And have shops players could own & run :) > This tag is increased by the object speed at each server tick. When it reach a > fixed amount, that fixed amount is substracted and the object plays on turn. > (simply one call to move(ob) i think) Oh, that one. Yes, of course I'll use it, growing items will have a speed & such, and a movement consisting of growing. > no need to remember them in an overlay map. and remembering the tree has one > apple is as simple as putting an apple in the tree inventory. sure Except when map gets reset you lose that. And the aim would be to *not* lose that on map reset :) Unless i'm mistaking, what you suggest would work when swapping a map, but not for reset. > Concerning the fast forward, i probably wasn't clear. That's exactly what I was thinking to do, indeed. But the catch is that there is a flag indicating when the map was swapped, I think, but no flag to say when the map was reset last time. > Yes, one step at a time, but i fear to see player planting tree seeds in the > scorn square :) There won't be seeds at first, I guess :) Just fields & such. Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From tchize at myrealbox.com Tue Apr 26 12:18:20 2005 From: tchize at myrealbox.com (tchize) Date: Tue Apr 26 12:19:42 2005 Subject: [crossfire] Items that evolve all the time In-Reply-To: References: Message-ID: <200504261918.25546.tchize@myrealbox.com> Look like i misundertood you. Didn't know you were planning to get this survive to resets. So overlay is the persistence thingie and the ticks is the fast forward thingie. We now agree ;) The last active moment could be saved on the persistence thingie. Btw, it could be usefull to have some kind of generic overlay system, which would be used by weather, grows and perhaps other things in future. A kind of permanent map alteration system (and btw, have really lots of fun with the random maps) Le Mardi 26 Avril 2005 15:17, Nicolas Weeger a ?crit : > Indeed, time to open some fish & chips at scorn square central And have shops players could own & run :) > This tag is increased by the object speed at each server tick. When it > reach a fixed amount, that fixed amount is substracted and the object plays > on turn. (simply one call to move(ob) i think) Oh, that one. Yes, of course I'll use it, growing items will have a speed & such, and a movement consisting of growing. > no need to remember them in an overlay map. and remembering the tree has > one apple is as simple as putting an apple in the tree inventory. sure Except when map gets reset you lose that. And the aim would be to *not* lose that on map reset :) Unless i'm mistaking, what you suggest would work when swapping a map, but not for reset. > Concerning the fast forward, i probably wasn't clear. That's exactly what I was thinking to do, indeed. But the catch is that there is a flag indicating when the map was swapped, I think, but no flag to say when the map was reset last time. > Yes, one step at a time, but i fear to see player planting tree seeds in > the scorn square :) There won't be seeds at first, I guess :) Just fields & such. Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050426/569265b1/attachment.pgp From tchize at myrealbox.com Tue Apr 26 12:58:16 2005 From: tchize at myrealbox.com (tchize) Date: Tue Apr 26 12:59:42 2005 Subject: [crossfire] channels In-Reply-To: <200504261253.03906.b.t.lally@warwick.ac.uk> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <426DE286.3030200@sonic.net> <200504261253.03906.b.t.lally@warwick.ac.uk> Message-ID: <200504261958.21983.tchize@myrealbox.com> Ok, to resume the analysis, your patch makes the server able to split message in 'channels' and client to choose 'ok send me this channel, but i don't need this channel , this one and this one'. It also allow users to create their own chat room. However your patch is limited in the realm of client identification of channels. It is based on slight modification of the old draw_info command, embedding informations inside the color parameter. Now i have on my computer a draft patch which allow client to request certain datas to be identifiable. If server doesn't support identification, all goes in main channel. If client doesn't request a special treatment for a specific information category, it goes to the main channel. If client connect to an old server, which doesn't support the separation of data, it receive information thru main channel. What i name the 'main channel' is simply draw_info Seems i do the part you patch behave poorly on (according to various post on this thread i did not test it, neither go in details) and you do the part my patch never thought about (my purpose was not to filter out informations but to clearly identify it's type) for now, server on my side behave like this, in pseudo code: -- if (client requested out of bound data for information type MSG_TYPE_BOOK) send out of bound data (player, MSG_TYPE_BOOK, message flavor(book), book title + book content) else draw_info (player, color, "you open the book and start reading..."+book content) -- This could be easy to add a new type MSG_TYPE_CHANNEL as this is made to be extensible. on the wire, the following command is send: draw_info_ext so for channel, i could easily add draw_info_ext : draw_info_ext : draw_info_ext :: draw_info_ext :: Really, the message part is mainly dependent on the msg_type, but not on the flavor, because client request a msg_type, but not a specific flavor. Client is supposed, for each message type requested, to implement a default flavor. This is quite easily done as , client side, main work is already done in common. All the ui has to do is register to the common part a textmanager for type MSG_TYPE_CHANNEL Ha yes, a last argument for using draw_info_ext instead of the old draw_info, this command is supposed to handle media tags, inside []s. This way a book can contain [i]italic[i] and [b]bold[/b] character, [u]underlined[/u] ones are supported too. [color=green]colored text[color=black], [fixed] fixed fonts [arcane] magical fonts [strange]undecipherable fonts [normal] and the normal fonts :) of course, [hand] hand written letter are also available [normal] impressive? Perhaps i'll had also support for ingame images like below [image=beholder.111] which was suggested as useful on monster description books. Perhaps in future, motd could also contain [url=http://crossfire.metalforge.net/rules.html:Marvelous rules links]! Media tags are just an hint to the ui, it is allowed to drop them or only understand a part of them, but this allows for richer content. For old client, server would use the classical draw_info and drop the [] parts of text. So here is my proposition: you finalize your patch to handle filterout of channel. But you drop the client identification of channels part. You just keep sending information the classical way with draw_info, so special play with colors. When my change is ready (a matter of days) you integrate an new MSG_TYPE_CHANNEL and put channels using them. What do you think about it? -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050426/41f3ddc5/attachment.pgp From b.t.lally at warwick.ac.uk Tue Apr 26 20:22:51 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Tue Apr 26 20:03:48 2005 Subject: [crossfire] channels In-Reply-To: <200504261958.21983.tchize@myrealbox.com> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504261253.03906.b.t.lally@warwick.ac.uk> <200504261958.21983.tchize@myrealbox.com> Message-ID: <200504270222.51377.b.t.lally@warwick.ac.uk> On Tuesday 26 Apr 2005 18:58, tchize wrote: > Ok, to resume the analysis, your patch makes the server able to split > message in 'channels' and client to choose 'ok send me this channel, but i > don't need this channel , this one and this one'. It also allow users to > create their own chat room. > However your patch is limited in the realm of client identification of > channels. It is based on slight modification of the old draw_info command, > embedding informations inside the color parameter. Yes. > Now i have on my computer a draft patch which allow client to request > certain datas to be identifiable. > If server doesn't support identification, all goes in main channel. > If client doesn't request a special treatment for a specific information > category, it goes to the main channel. > If client connect to an old server, which doesn't support the separation of > data, it receive information thru main channel. > What i name the 'main channel' is simply draw_info > > Seems i do the part you patch behave poorly on (according to various post > on this thread i did not test it, neither go in details) and you do the > part my patch never thought about (my purpose was not to filter out > informations but to clearly identify it's type) But if it can be used for both purposes, then that would seem like the way to go.... > for now, server on my side behave like this, in pseudo code: > > -- > if (client requested out of bound data for information type MSG_TYPE_BOOK) > send out of bound data (player, MSG_TYPE_BOOK, message flavor(book), > book title + book content) > else > draw_info (player, color, "you open the book and start reading..."+book > content) > -- > > This could be easy to add a new type MSG_TYPE_CHANNEL as this is made to be > extensible. ah, so to apply that to what I have done, the call would be send_out_of_bound_data (pl, CHAN_FOO, messageflavour "channel", playername, message). am I understanding you corrrectly here? (I'm not sure what you mean by 'out of bound' data, it isn't forbidden in some way is it?) > on the wire, the following command is send: > draw_info_ext > > so for channel, i could easily add > draw_info_ext player>: > draw_info_ext player>: > draw_info_ext color?black?> :: > draw_info_ext > :: ok, that looks more complicated, I think I'll just trust that you have the networking bit sorted :) > Really, the message part is mainly dependent on the msg_type, but not on > the flavor, because client request a msg_type, but not a specific flavor. > Client is supposed, for each message type requested, to implement a > default flavor. This is quite easily done as , client side, main work is > already done in common. All the ui has to do is register to the common part > a textmanager for type MSG_TYPE_CHANNEL > > Ha yes, a last argument for using draw_info_ext instead of the old > draw_info, well I thought you were doing reasonably well with the whole 'me not needing to change the client bit' tbh.... > this command is supposed to handle media tags, inside []s. > > This way a book can contain [i]italic[i] and [b]bold[/b] character, > [u]underlined[/u] ones are supported too. > [color=green]colored text[color=black], > [fixed] fixed fonts > [arcane] magical fonts > [strange]undecipherable fonts > [normal] and the normal fonts :) > of course, [hand] hand written letter are also available > [normal] impressive? > Perhaps i'll had also support for ingame images like below > [image=beholder.111] which was suggested as useful on monster description > books. > Perhaps in future, motd could also contain > [url=http://crossfire.metalforge.net/rules.html:Marvelous rules links]! > > Media tags are just an hint to the ui, it is allowed to drop them or only > understand a part of them, but this allows for richer content. For old > client, server would use the classical draw_info and drop the [] parts of > text. and having some of these in normal chat would be [i]nice[/i]... (probably not the pictures though, that would seem rather abusable....) > So here is my proposition: you finalize your patch to handle filterout of > channel. But you drop the client identification of channels part. ok then, excellent, I can stop trying to abuse hexadecimal arithmatic then.... > You just > keep sending information the classical way with draw_info, so special play > with colors. When my change is ready (a matter of days) you integrate an > new MSG_TYPE_CHANNEL and put channels using them. > > What do you think about it? This idea I like. one check though, If I understand you correctly there is a function draw_info_ext() in addition to new_draw_info? shouldn't this be folded into the same function, with the check for which to use done there? Also should I still ignore the colour information in each call and fetch from channel, or should I revert that and leave in the hardcoded channel info? From mwedel at sonic.net Wed Apr 27 00:19:08 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Apr 27 00:19:50 2005 Subject: [crossfire] Items that evolve all the time In-Reply-To: <200504261918.25546.tchize@myrealbox.com> References: <200504261918.25546.tchize@myrealbox.com> Message-ID: <426F20CC.2080700@sonic.net> A few notes: Storing tick counts is not reliable. If the server resets, tick count restarts at zero I believe, so that value won't do any good. The last_ values, are I believe, used only when the object is in memory. This is used to refine things like regeneration times (eg, you don't want a character to get a hp back every tick they go, so last_heal is decremented each time the player gets an action, and if zero, player gets a hp, and last_heal is set to the regen rate). Similar oddness is used for monster regeneration. However, monsters don't get HP back when the map is swapped out. This has long been a known fact, and often used by experienced player (if the time it takes you to heal is greater than map swapout time, then it doesn't matter how long it takes you to heal). The only way I can see for the object to survive map resets is to either store it on the overlay map, like weather, or make it unique, so it gets stored on the unique object maps. So the next step is know how long since last activated - the best way is to store the results of time() into the object. If the object is in memory, let the normal speed processing do its logic. Add some flag so that when it is saved, the time() value is automatically stored into some field. Then at load time, you can at least know how long the object has been inactive. Probably need to add something in ready_map_map() that processes these object (fix_auto_apply is only called when a map is reset, not when swapped back in.) In terms of processing, it'd make the processing more smart. Eg, if hte object has been out of memory for 5000 seconds, instead of calling process object that many times for that object, make it more clever - figure out what it would have done in that time (eg, produced 30 apples, died off, whatever). That will make processing then not very costly at load time. If that isn't possible (because object may go through bunches of states), then doing it more like weather code probably makes sense. From mwedel at sonic.net Wed Apr 27 00:50:56 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Apr 27 00:51:50 2005 Subject: [crossfire] channels In-Reply-To: <200504261253.03906.b.t.lally@warwick.ac.uk> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504251900.35517.b.t.lally@warwick.ac.uk> <426DE286.3030200@sonic.net> <200504261253.03906.b.t.lally@warwick.ac.uk> Message-ID: <426F2840.7030407@sonic.net> Brendan Lally wrote: > > er, I'd only really need to > 1) change the arguments of new_draw_info (I've changed the function itself > already, so literally just > 1a) backup and make a seperate copy of c_chat.c > 2) for i in $(ls server/*); do cat server/$i | sed s/NDI_UNIQUE \|/ / >$i.new; > cat server/$i | sed s/NDI_[:alpha:]\,/ / > $i > (I'll need to check the syntax on that) > 3) compile and manually change some corner cases (and c_chat.c). > 4) set the colour value in the channels as described earlier. > > removing infomation is much easier than adding it.... But the problem I see is that you don't add enough new channels that all the NDI_... is now redundant. I estimated that there'd be around 20-30 different NDI_ fields. And the problem then leads into a huge combination of NDI values * channel values, making handling on the client a much more complicated mess. I was thinking about this some more, and we may be addressing it from the wrong side of things - the server side. What really counts is the interface to the player - if the interface isn't good, all of this is basically meaningless because no one will ever use it. My personal thought is that I probably want a max of 5 different message tabs in my client - anything more than that seems excessive for the number of messages I typically see while playing on metalforge. My vision on how to handle this is to have a selection window that lists all the different message types/channels, and lets you select the font, color, and tab it goes into. For purposes of this discussion, we'll let the type/channel info be non specific - could be NDI code or channel value. This, I might set something up that lets all attack related messages go into one tab. As an additional ability, any kill messages show up in that tab in red. In another tab, set it for all readable type messages. In third tab, set it for all chat/shout/tell type messages. In fourth tab, set it for whatever is left over (level gain messages, people joining/leaving/etc). Maybe set a fifth tab to cover everything else. I certainly _don't_ want 1 tab per channel - I don't want to have 30 tabs in my client. I also don't want something like 'if you don't have that specific tab, everything gets dumped into a default tab'. That is one problem I have with both having channels and colors - from a user perspective, how do I control preferences then? For example, suppose the preference I describe is based on channels. How do you handle messages that come in on that channel in a different color? You can't really have a selection for all those posibilities, so the client has to assume some behaviour. does it just use the defaults the user selects (tab, font, color)? Does it use the color it comes in as, but otherwise use same tab and font? etc. That is why having only 1 attribute for all draw_info calls makes things much easier to handle - if there is only 30 message types, easy to present all those in a window to the user to choose their defaults. Note that these preferences are also stored client side. So this makes dynamic channels harder to handle - channel 25 may change its meaning run to run, or perhaps even server to server. I don't have a good solution for that one. What is also the expected plan for people actually chatting on these channels? I'm presuming there will need to be some command to do so, but I don't see that in your patch right now, so not sure how that will be handled. Keep in mind you need to provide some way for players with older clients to both see and chat on these new channels. From mwedel at sonic.net Wed Apr 27 02:12:31 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Apr 27 02:13:50 2005 Subject: [crossfire] titan_quest map not solvable anymore? Message-ID: <426F3B5F.4090000@sonic.net> I recently tried to do the titan quest (archduke of scorn quest) map and was unable to finish it. I'm not sure if its because I'm just missing something, or as I think might be the case, server behavior has changed. My guess looking at the map is that the player is supposed to dimension door into the small chambers, and then get the final key that gives access to megalopos. Before the spell code was redone, this was actually possible. With the redone spell code, it is no longer possible to teleport through solid (those that block sight) walls. The walls in the the titan quest do block sight, thus no dimension door. I can't remember the rationale, but I seem to recall it was discussed at the time, and did make sense. To me, there are perhaps a couple possible solutions: 1) remove the need of dimension door - you already get keys, just put doors in those blocks that the keys use. 2) Change the walls to be the gate style walls that you can see through (and thus dimension door) 3) perhaps some third option I can't think of. I personally prefer #1. By the time you get to that map, you're pretty high level - requiring dimension door is like robbing Fort Knox and finding the last door has a padlock purchased at the hardware store. My other thought on this is it would be really annoying to get to that stage and not have a way to dimension door (in my adventures, I used a wand of dimension door to get to the castle, but that has finite charges). The real gotcha is that it can certainly take long enough to work your way through those maps that you just can't go back to down and come back again - the first maps may have reset, so you'd have to do the entire quest again. From tchize at myrealbox.com Wed Apr 27 07:19:48 2005 From: tchize at myrealbox.com (tchize@myrealbox.com) Date: Wed Apr 27 07:19:54 2005 Subject: [crossfire] Items that evolve all the time In-Reply-To: <426F20CC.2080700@sonic.net> References: <200504261918.25546.tchize@myrealbox.com> <426F20CC.2080700@sonic.net> Message-ID: <200504271419.48374.tchize@myrealbox.com> Le Mercredi 27 Avril 2005 07:19, Mark Wedel a ?crit : > A few notes: > > Storing tick counts is not reliable. If the server resets, tick count > restarts at zero I believe, so that value won't do any good. Did not speak of storing tick count but measuring tick counts from the time since last map swap out or last time the overlay map saved. > > The last_ values, are I believe, used only when the object is in memory. > This is used to refine things like regeneration times (eg, you don't want a > character to get a hp back every tick they go, so last_heal is decremented > each time the player gets an action, and if zero, player gets a hp, and > last_heal is set to the regen rate). They all are restored at reaload. Whas i was suggesting is to modify those value like if n server ticks did happens, n being calculed from the last map save. I already used to prefill such fields in a map so to desynchonize all animations (i gave this way to items a random number of moves to do at load time and so the animation of various items did get a random desync with neighbors items. Was used for a lava like ground). > > Similar oddness is used for monster regeneration. However, monsters > don't get HP back when the map is swapped out. This has long been a known > fact, and often used by experienced player (if the time it takes you to > heal is greater than map swapout time, then it doesn't matter how long it > takes you to heal). > > The only way I can see for the object to survive map resets is to either > store it on the overlay map, like weather, or make it unique, so it gets > stored on the unique object maps. I opt for a general overlay system, as the unique object is, well, some kind of unique system. This way you can easily process with such pseudo alogrithm: load: - if no overlay-map exist, load the map from share/ - else - load map from share but drop any persistent thingie (add a is_persistent tag to object?) - load the overlay-thingie save: simply save non persistent thiniges in swap and persistent ones in overlay > > So the next step is know how long since last activated - the best way is > to store the results of time() into the object. If the object is in > memory, let the normal speed processing do its logic. Add some flag so > that when it is saved, the time() value is automatically stored into some > field. Then at load time, you can at least know how long the object has > been inactive. Probably need to add something in ready_map_map() that > processes these object (fix_auto_apply is only called when a map is reset, > not when swapped back in.) Objects don't need to get the time. The time is the same for whole map being loaded, that's why this informations should be map related. > > In terms of processing, it'd make the processing more smart. Eg, if hte > object has been out of memory for 5000 seconds, instead of calling process > object that many times for that object, make it more clever - figure out > what it would have done in that time (eg, produced 30 apples, died off, > whatever). That will make processing then not very costly at load time. > i don't think processing would be that costy. If you assume something like '30' apple, the problem is , well, if someone picked up all apple before last swap out, all tree would have same number of apple. But we can do something like move(object,missedturns) be smart and do a general probability, like saying ok, produce between 20 and 40 apples. > If that isn't possible (because object may go through bunches of states), > then doing it more like weather code probably makes sense. > That mean do the move of object on idle times, objects which perhaps will never be used again because of map reset. Please note i'd like to dissociate problem of object needing to get turns while not in memory and proble of objects needing to survive map resets; Sure growables will have both caracteristics. But There could be non growables needing turns when out of memory like there could be non growables needing to stay persistent, while we don't want the map it is in to be permanent. Perhaps if such a generic overlay make his way in code, it must be used by weather too. > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- David Delbecq Royal Meteorological Institute of Belgium From b.t.lally at warwick.ac.uk Wed Apr 27 12:28:17 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Wed Apr 27 12:09:58 2005 Subject: [crossfire] channels In-Reply-To: <426F2840.7030407@sonic.net> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504261253.03906.b.t.lally@warwick.ac.uk> <426F2840.7030407@sonic.net> Message-ID: <200504271828.17410.b.t.lally@warwick.ac.uk> On Wednesday 27 Apr 2005 06:50, Mark Wedel wrote: > But the problem I see is that you don't add enough new channels that all > the NDI_... is now redundant. ok then, suggest some more to add, and I'll add them. The problem is that much NDI information now is redundent, or at least bears little relation to message content. > I estimated that there'd be around 20-30 different NDI_ > fields. well, how about if I actually count them? from a clean CVS checkout this morning... bear in mind that this first count includes the colour definitions: crossfire/colour_count/crossfire $for i in NDI_BLACK NDI_WHITE NDI_NAVY NDI_RED NDI_ORANGE NDI_BLUE NDI_DK_ORANGE NDI_GREEN NDI_LT_GREEN NDI_GREY NDI_BROWN NDI_GOLD NDI_TAN NDI_UNIQUE NDI_ALL; do echo $i $(grep -R $i * | wc -l); done NDI_BLACK 24 NDI_WHITE 15 NDI_NAVY 31 NDI_RED 19 NDI_ORANGE 8 NDI_BLUE 17 NDI_DK_ORANGE 9 NDI_GREEN 2 NDI_LT_GREEN 5 NDI_GREY 2 NDI_BROWN 3 NDI_GOLD 1 NDI_TAN 1 NDI_UNIQUE 1376 NDI_ALL 25 also we will check for all those messages that combine a colour and NDI_UNIQUE crossfire/colour_count/crossfire $for i in NDI_BLACK NDI_WHITE NDI_NAVY NDI_RED NDI_ORANGE NDI_BLUE NDI_DK_ORANGE NDI_GREEN NDI_LT_GREEN NDI_GREY NDI_BROWN NDI_GOLD NDI_TAN NDI_UNIQUE NDI_ALL; do echo NDI_UNIQUE $i $(grep -R $i * | grep NDI_UNIQUE | wc -l); done NDI_UNIQUE NDI_BLACK 2 NDI_UNIQUE NDI_WHITE 4 NDI_UNIQUE NDI_NAVY 28 NDI_UNIQUE NDI_RED 13 NDI_UNIQUE NDI_ORANGE 7 NDI_UNIQUE NDI_BLUE 13 NDI_UNIQUE NDI_DK_ORANGE 8 NDI_UNIQUE NDI_GREEN 1 NDI_UNIQUE NDI_LT_GREEN 4 NDI_UNIQUE NDI_GREY 0 NDI_UNIQUE NDI_BROWN 2 NDI_UNIQUE NDI_GOLD 0 NDI_UNIQUE NDI_TAN 0 NDI_UNIQUE NDI_UNIQUE 1376 NDI_UNIQUE NDI_ALL 20 from this I conclude that the vast majority of messages are unique black text (that is default) TAN and GOLD are unused (only defined) GREY is used uniquely once. in polymorph melt (so it never appears anymore). (spell_effect.c 224) NDI_BROWN is used twice, in relation to keyrings (one of these is an odd call, it sets the listen level not the colour - probably a bug). (player.c 1842 and 1876) - possibly one channel. NDI_GREEN is used only for the MOTD which Tchize is in the process of replacing anyway. (player.c 94) NDI_LT_GREEN is used soley for dm leave/quit messages. (I used COMM_JOINQUIT on these, which turns the DK_ORANGE, but you could have another channel here too I guess) (scattered through c_wiz.c) - possibly another channel NDI_DK_ORANGE is used soley for joining and quitting messages (all NDI_UNIQUE | NDI_ALL) - already a channel NDI_ORANGE is used for tell, by unmuzzling messages (but curiously not for muzzling ones) and by the python code, it is also abused to provide a listen level. (I use it in COMM_TELL). - possibly another channel, COMM_PLUGIN I guess you could have COMM_UNMUZZLE too if you really wanted..... that leaves 5 colours, of which two, NDI_BLACK and NDI_WHITE, are the same anyway (they just appear in different places). the calls to coloured messages that aren't unique are effectively so anyway, since they occur so rarely. oh, one more thing, global messages. for i in NDI_BLACK NDI_WHITE NDI_NAVY NDI_RED NDI_ORANGE NDI_BLUE NDI_DK_ORANGE NDI_GREEN NDI_LT_GREEN NDI_GREY NDI_BROWN NDI_GOLD NDI_TAN NDI_UNIQUE NDI_ALL; do echo NDI_ALL $i $(grep -R $i * | grep NDI_ALL | wc -l); done NDI_ALL NDI_BLACK 0 NDI_ALL NDI_WHITE 0 NDI_ALL NDI_NAVY 0 NDI_ALL NDI_RED 2 NDI_ALL NDI_ORANGE 0 NDI_ALL NDI_BLUE 0 NDI_ALL NDI_DK_ORANGE 8 NDI_ALL NDI_GREEN 0 NDI_ALL NDI_LT_GREEN 4 NDI_ALL NDI_GREY 0 NDI_ALL NDI_BROWN 0 NDI_ALL NDI_GOLD 0 NDI_ALL NDI_TAN 0 NDI_ALL NDI_UNIQUE 20 NDI_ALL NDI_ALL 25 DK_ORANGE and LT_GREEN messages here are currently COMM_JOINQUIT, the red messages are dm banishment and kick messages, I guess they could have their own channels too.... - (possibly 1 more channel?) so 5 colours, NDI_BLACK is already covered by several channels, that leaves 4. so 4 more channels. that is a total of 15 already + 4 (main colours) +5 (corner cases.). = 24 > I was thinking about this some more, and we may be addressing it from the > wrong side of things - the server side. What really counts is the > interface to the player - if the interface isn't good, all of this is > basically meaningless because no one will ever use it. agreed > My personal thought is that I probably want a max of 5 different message > tabs in my client - anything more than that seems excessive for the number > of messages I typically see while playing on metalforge. > > I certainly _don't_ want 1 tab per channel - I don't want to have 30 tabs > in my client. I also don't want something like 'if you don't have that > specific tab, everything gets dumped into a default tab'. AFAICT that is something that tchize will address with his draw_info_ext() function. > That is one problem I have with both having channels and colors - from a > user perspective, how do I control preferences then? For example, suppose > the preference I describe is based on channels. How do you handle messages > that come in on that channel in a different color? You can't really have a > selection for all those posibilities, so the client has to assume some > behaviour. does it just use the defaults the user selects (tab, font, > color)? Does it use the color it comes in as, but otherwise use same tab > and font? etc. That is why having only 1 attribute for all draw_info > calls makes things much easier to handle - if there is only 30 message > types, easy to present all those in a window to the user to choose their > defaults. hmm, a thought that occurs is that one way that could work is if I changed the way the value was stored in pl->listening, so that the player could store their own colour for it there. -1 would be off, -2 banned >=0 would be on in the appropriate colour. 255 would be 'use what you are told to use' then if the player has a colour preference defined, their choice of colour is sent, otherwise, the channel one is. this could be parsed client side (by a script maybe?), so that you have a window to list the channels with an on/off button and an override colour option. do you want me to do that instead? > Note that these preferences are also stored client side. So this makes > dynamic channels harder to handle - channel 25 may change its meaning run > to run, or perhaps even server to server. I don't have a good solution for > that one. which was why I was doing it server side. > What is also the expected plan for people actually chatting on these > channels? I'm presuming there will need to be some command to do so, but I > don't see that in your patch right now, so not sure how that will be > handled. Keep in mind you need to provide some way for players with older > clients to both see and chat on these new channels. That's the point, I've dealt with that already. It works now, it maybe isn't where you might think though. I modified execute_new_server command. in c_new.c when a command is run, if (and only if) it can't find it in the command arrays, instead of getting 'no such command' it checks the channels that exists, and if channel->canpost is at a value that the player can post to the channel, then they send the message. if they have a channel called that, and they can't post there, they get an explanation as to why. this means each channel is posted to by using its name as the send command. so certainly Redbot (which has been on #crossfire-bs and now works) would probably find itself modified to login channel create irc then send 'irc (whatever is said on #crossfire-bs)' which the command parser will convert to a message on the IRC channel, so anyone who has done listen irc will hear it. the thing I have to do still is put a check in channel creation to stop someone creating a channel called 'quit' :) That isn't overly complex to do however. From mikeeusaaa at yahoo.com Wed Apr 27 14:37:51 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed Apr 27 14:40:00 2005 Subject: [crossfire] titan_quest map not solvable anymore? In-Reply-To: 6667 Message-ID: <20050427193751.2206.qmail@web61003.mail.yahoo.com> I agree. I also wonder why a titan's castle would have "wizard tricks" built into itself. I think the castle would be much more utilitarian and the Megapolis would eschew the desired archtecture the "foolish intellectual wizards" beg him for... "by golly we have strength... no need for trickery". --- Mark Wedel wrote: > > I recently tried to do the titan quest (archduke > of scorn quest) map and was > unable to finish it. I'm not sure if its because > I'm just missing something, or > as I think might be the case, server behavior has > changed. > > My guess looking at the map is that the player is > supposed to dimension door > into the small chambers, and then get the final key > that gives access to megalopos. > > Before the spell code was redone, this was > actually possible. With the redone > spell code, it is no longer possible to teleport > through solid (those that block > sight) walls. The walls in the the titan quest do > block sight, thus no > dimension door. I can't remember the rationale, but > I seem to recall it was > discussed at the time, and did make sense. > > To me, there are perhaps a couple possible > solutions: > > 1) remove the need of dimension door - you already > get keys, just put doors in > those blocks that the keys use. > > 2) Change the walls to be the gate style walls that > you can see through (and > thus dimension door) > > 3) perhaps some third option I can't think of. > > I personally prefer #1. By the time you get to > that map, you're pretty high > level - requiring dimension door is like robbing > Fort Knox and finding the last > door has a padlock purchased at the hardware store. > My other thought on this is > it would be really annoying to get to that stage and > not have a way to dimension > door (in my adventures, I used a wand of dimension > door to get to the castle, > but that has finite charges). The real gotcha is > that it can certainly take > long enough to work your way through those maps that > you just can't go back to > down and come back again - the first maps may have > reset, so you'd have to do > the entire quest again. > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tchize at myrealbox.com Wed Apr 27 15:08:30 2005 From: tchize at myrealbox.com (tchize) Date: Wed Apr 27 15:10:00 2005 Subject: [crossfire] channels In-Reply-To: <200504270222.51377.b.t.lally@warwick.ac.uk> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504261958.21983.tchize@myrealbox.com> <200504270222.51377.b.t.lally@warwick.ac.uk> Message-ID: <200504272208.36216.tchize@myrealbox.com> First 'out of bound' is a bad word, sorry, i suppose it shouldn't write mail when my eyes want to close. I just mean data are send with another server->client command than draw_info. Just a matter of slight protocol improvement. This is working great here with all combinaison of old/new client/server, finalizing code for commit today or tomorrow. Backward compatible. Now to explain the 'flavor'. Client request a to get a 'type of data' send using the new command instead of the old draw_info one. a 'type of data' is, for example, books. a 'type of data' in its conception regroups all textual datas which can be graphically presented using a common scheme client side. Books could be written inside a picture showing a book. Letters& scrolls is another type of data, written on top of a flat piece of paper. signs is a thrid type, with left, right, square signs. messages of the day in another one. And so on. and channel, obviously, is another 'type of data' too :) Now, to give more flexibility for client, each type can be separated in 'flavors' (or subtype if you prefer the coder way to speak). Books, for example, have a flavor for nice red book, a flavor for claps, a flavor blue magical books ,and so on. There is enough space to add new book style easily. If client don't understand the flavor, it just has to fall back to a default. As i am bad at coding gtk, currently all books falls back to default which is a tab in a books windows, without graphicals improvements, but this way, the path is open in the protocol. MOTD have only one flavor yet coded because, well, i see no use of flavor there, anyway, let's use the common scheme. Here, the motd is shown inside the 'type username' dialog window as suggested on irc as it will force players to read the motd a bit. Other main type values have been reserved but are not yet coded (scrolls, monuments, signs). Now, in case of speaking channels, i obviously see a main type MSG_TYPE_CHANNEL with various flavor: SHOUT the main speaking flavor SAY the map speaking flavor TELL this one will be able have, as first line, the name of speaking player then the message, so client can open a new tab for each speaking player PARTY_SAY perhaps for this flavor first line would be party name, second line speaker name, and the rest the message itself CHANNEL this one will get message directe to any channel. Could have similar behaviour as PARTY_SAY DM_CHANNEL a flavor dedicated to the dm? ... whatever you speak about. The flavor is coded as a 16bits int, there is much freedom to define lots of flavors and you can handle the way you want. The content of the textual message part just has to be somewhat consistent inside a given main type ;) And because flavor is just an information, server does not do anything based on the flavor. All it does is check client request to get the main MSG_TYPE and, if so, send all flavors message when they are generated. Hope i was clear. Anyway, when code gets in, it will be much more clear ;) To give an idea of easyness this give to client implementation, here is a part of code from MOTD handling in gtk on my desk: at application startup, gx11 does this call: setTextManager(MSG_TYPE_MOTD,motd_callback); not at all difficult :) and to manage this MOTD, here is the content of motd_callback: char* last_motd=NULL; void motd_callback(int color, int type, int subtype, char* message){ if(last_motd) free(last_motd); last_motd = malloc(strlen(message)+1); if (last_motd==NULL) LOG(LOG_ERROR,"gtk::motd_callback","Outa memory, no save of motd"); else strcpy(last_motd,message); } the book version is a bit more lenghty because it manipualtes gtk windows and extract the first line of 'message' to consider it as a title. >ok then, excellent, I can stop trying to abuse hexadecimal arithmatic > then.... Poor abused hexadecimal child! >Also should I still ignore the colour information in each call and fetch from >channel, or should I revert that and leave in the hardcoded channel info? The new command get a message, a message type, a message flavor and a color, though in case of book and motd this is ignored by the message handler. I kept colors as it only take up a very small additional bandwidth compared to the text following most of the time. >one check though, If I understand you correctly there is a function >draw_info_ext() in addition to new_draw_info? yep, in case of books, this is how it is used for now, msgtype is a common structure i use to split various readables like scrolls, books, aso in a typ,flavor pair. It is of no use for channels so don't care about:) draw_ext_info(NDI_UNIQUE | NDI_NAVY, 0, op, msgType->message_type, msgType->message_subtype, buf, nicebuf); buf may contains this: "You open the necronomicon and start reading...\nYour soul is mine, player!" while nicebuf may contains this. "necronomicon\nYour soul is mine, player!" the draw_ext_info will check if client requested msgType->message_type to be send using the new command, and if so issue a draw_info_ext on the wire with a nicebuf. If this is not the case, it will issue a classical draw_info. I did not put the logic inside draw_info because, as you see, there are cases were messages to send are to be different in the two protocols. Not to mention there are places in code were a single operation (like reading a book) ends in a series of draw_info, so there has to be some work to be done function caller side anyway. Now i wrote this long email and have no more time to code today. cleanup will be for tomorrow ;) >shouldn't this be folded into the same function, with the check for which to >use done there? Le Mercredi 27 Avril 2005 03:22, Brendan Lally a ?crit : On Tuesday 26 Apr 2005 18:58, tchize wrote: > Ok, to resume the analysis, your patch makes the server able to split > message in 'channels' and client to choose 'ok send me this channel, but i > don't need this channel , this one and this one'. It also allow users to > create their own chat room. > However your patch is limited in the realm of client identification of > channels. It is based on slight modification of the old draw_info command, > embedding informations inside the color parameter. Yes. > Now i have on my computer a draft patch which allow client to request > certain datas to be identifiable. > If server doesn't support identification, all goes in main channel. > If client doesn't request a special treatment for a specific information > category, it goes to the main channel. > If client connect to an old server, which doesn't support the separation of > data, it receive information thru main channel. > What i name the 'main channel' is simply draw_info > > Seems i do the part you patch behave poorly on (according to various post > on this thread i did not test it, neither go in details) and you do the > part my patch never thought about (my purpose was not to filter out > informations but to clearly identify it's type) But if it can be used for both purposes, then that would seem like the way to go.... > for now, server on my side behave like this, in pseudo code: > > -- > if (client requested out of bound data for information type MSG_TYPE_BOOK) > send out of bound data (player, MSG_TYPE_BOOK, message flavor(book), > book title + book content) > else > draw_info (player, color, "you open the book and start reading..."+book > content) > -- > > This could be easy to add a new type MSG_TYPE_CHANNEL as this is made to be > extensible. ah, so to apply that to what I have done, the call would be send_out_of_bound_data (pl, CHAN_FOO, messageflavour "channel", playername, message). am I understanding you corrrectly here? (I'm not sure what you mean by 'out of bound' data, it isn't forbidden in some way is it?) > on the wire, the following command is send: > draw_info_ext > > so for channel, i could easily add > draw_info_ext player>: > draw_info_ext player>: > draw_info_ext color?black?> :: > draw_info_ext > :: ok, that looks more complicated, I think I'll just trust that you have the networking bit sorted :) > Really, the message part is mainly dependent on the msg_type, but not on > the flavor, because client request a msg_type, but not a specific flavor. > Client is supposed, for each message type requested, to implement a > default flavor. This is quite easily done as , client side, main work is > already done in common. All the ui has to do is register to the common part > a textmanager for type MSG_TYPE_CHANNEL > > Ha yes, a last argument for using draw_info_ext instead of the old > draw_info, well I thought you were doing reasonably well with the whole 'me not needing to change the client bit' tbh.... > this command is supposed to handle media tags, inside []s. > > This way a book can contain [i]italic[i] and [b]bold[/b] character, > [u]underlined[/u] ones are supported too. > [color=green]colored text[color=black], > [fixed] fixed fonts > [arcane] magical fonts > [strange]undecipherable fonts > [normal] and the normal fonts :) > of course, [hand] hand written letter are also available > [normal] impressive? > Perhaps i'll had also support for ingame images like below > [image=beholder.111] which was suggested as useful on monster description > books. > Perhaps in future, motd could also contain > [url=http://crossfire.metalforge.net/rules.html:Marvelous rules links]! > > Media tags are just an hint to the ui, it is allowed to drop them or only > understand a part of them, but this allows for richer content. For old > client, server would use the classical draw_info and drop the [] parts of > text. and having some of these in normal chat would be [i]nice[/i]... (probably not the pictures though, that would seem rather abusable....) > So here is my proposition: you finalize your patch to handle filterout of > channel. But you drop the client identification of channels part. ok then, excellent, I can stop trying to abuse hexadecimal arithmatic then.... > You just > keep sending information the classical way with draw_info, so special play > with colors. When my change is ready (a matter of days) you integrate an > new MSG_TYPE_CHANNEL and put channels using them. > > What do you think about it? This idea I like. one check though, If I understand you correctly there is a function draw_info_ext() in addition to new_draw_info? shouldn't this be folded into the same function, with the check for which to use done there? Also should I still ignore the colour information in each call and fetch from channel, or should I revert that and leave in the hardcoded channel info? _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050427/618be1f7/attachment-0001.pgp From b.t.lally at warwick.ac.uk Wed Apr 27 19:32:49 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Wed Apr 27 19:14:02 2005 Subject: [crossfire] channels In-Reply-To: <200504272208.36216.tchize@myrealbox.com> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504270222.51377.b.t.lally@warwick.ac.uk> <200504272208.36216.tchize@myrealbox.com> Message-ID: <200504280132.49024.b.t.lally@warwick.ac.uk> On Wednesday 27 Apr 2005 21:08, tchize wrote: > First 'out of bound' is a bad word, sorry, i suppose it shouldn't write > mail when my eyes want to close. > > I just mean data are send with another server->client command than > draw_info. Just a matter of slight protocol improvement. This is working > great here with all combinaison of old/new client/server, finalizing code > for commit today or tomorrow. Backward compatible. > > Now to explain the 'flavor'. Client request a to get a 'type of data' send > using the new command instead of the old draw_info one. > > a 'type of data' is, for example, books. > a 'type of data' in its conception regroups all textual datas which can be > graphically presented using a common scheme client side. Books could be > written inside a picture showing a book. > Letters& scrolls is another type of data, written on top of a flat piece of > paper. > signs is a thrid type, with left, right, square signs. > messages of the day in another one. And so on. > > and channel, obviously, is another 'type of data' too :) ah, I like this idea.... > Now, in case of speaking channels, i obviously see a main type > MSG_TYPE_CHANNEL > with various flavor: > SHOUT the main speaking flavor > SAY the map speaking flavor > TELL this one will be able have, as first line, the name of speaking player > then the message, so client can open a new tab for each speaking player > PARTY_SAY perhaps for this flavor first line would be party name, second > line speaker name, and the rest the message itself > CHANNEL this one will get message directe to any channel. Could have > similar behaviour as PARTY_SAY > DM_CHANNEL a flavor dedicated to the dm? > ... whatever you speak about. The flavor is coded as a 16bits int, there is > much freedom to define lots of flavors and you can handle the way you want. > The content of the textual message part just has to be somewhat consistent > inside a given main type ;) > And because flavor is just an information, server does not do anything > based on the flavor. All it does is check client request to get the main > MSG_TYPE and, if so, send all flavors message when they are generated. > > Hope i was clear. Anyway, when code gets in, it will be much more clear ;) the only thing with this is that it might be a bit of a bandwidth leech, since some messages can be sent quite frequently. (still shouldn't be too much if buffering is kept though...) > To give an idea of easyness this give to client implementation, here is a > part of code from MOTD handling in gtk on my desk: > > at application startup, gx11 does this call: > setTextManager(MSG_TYPE_MOTD,motd_callback); > > not at all difficult :) > > and to manage this MOTD, here is the content of motd_callback: > > char* last_motd=NULL; > void motd_callback(int color, int type, int subtype, char* message){ > > if(last_motd) > free(last_motd); > last_motd = malloc(strlen(message)+1); > if (last_motd==NULL) > LOG(LOG_ERROR,"gtk::motd_callback","Outa memory, no save of motd"); > else > strcpy(last_motd,message); > } ok then, great, the server can set the tabs as it wants, and can even use regexps to assign to tabs if needed (don't think it is). the client will know exactly what channel has been sent, so knows just what to do. type of channel can even be encoded there, so whilst a number (base 36 char?) would be best for the system channels (bandwidth concerns) the full title can be used for other channels, and tabs can be assigned as needed. > the book version is a bit more lenghty because it manipualtes gtk windows > and extract the first line of 'message' to consider it as a title. /me wonders about tabs which have a pane with the people on the channel in.... > >Also should I still ignore the colour information in each call and fetch > > from channel, or should I revert that and leave in the hardcoded channel > > info? > > The new command get a message, a message type, a message flavor and a > color, though in case of book and motd this is ignored by the message > handler. I kept colors as it only take up a very small additional bandwidth > compared to the text following most of the time. well then, the channel can send it and the client can ignore or not as needed. so everything should be fine :) From b.t.lally at warwick.ac.uk Wed Apr 27 22:55:42 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Wed Apr 27 22:38:05 2005 Subject: [crossfire] large numbers of parties causes weirdness Message-ID: <200504280455.42567.b.t.lally@warwick.ac.uk> Well, there was a mention of a security audit a while back, here's a result from it, and even a sample exploit code :) The party that a person is a member of is stored in a 'partyid' in the player struct. This is an sint16. each party gets an sint16 as the party number, and The following code, run as a script by a player is enough to cause breakages in the party system that crossfire uses. #!/bin/bash for i in $(seq 1 1 65536); do echo "issue 1 1 party form $i" sleep 0.05 done there are three issues. 1) when it gets above about 1800 it causes clients to crash when doing party list. 2) when it gets above 32768 the parties stop being functional (they can be joined, but aren't considered to be joined by any aspect of the game code). 3) when it gets above 65535, the partyid (which is stored as a sint16) will wrap around, allowing parties to be joined by the one 65536 places after them on the list. This avoids the password check. This would allow, for example someone to run that script and then join the party that corresponds to party dm on metalforge, without needing the password. with regards to the third one a possible solution is (this compiles, haven't tested yet, but it should work.). Index: server/c_party.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/c_party.c,v retrieving revision 1.10 diff -C5 -r1.10 c_party.c *** server/c_party.c 25 Dec 2004 18:09:29 -0000 1.10 --- server/c_party.c 28 Apr 2005 03:19:30 -0000 *************** *** 452,461 **** --- 452,466 ---- "You are already a member of party: %s" ,tmpparty->partyname); return 1; } else { + if(find_party_struct(tmpparty->partyid)!=tmpparty) { + new_draw_info_format(NDI_UNIQUE, 0, op, + "ERROR Detected, party numbers are inconsistant, can't join party %s",params); + return 1; + } if(tmpparty->passwd[0] == '\0') { new_draw_info_format(NDI_UNIQUE, 0, op, "You have joined party: %s",tmpparty->partyname); op->contr->party_number = tmpparty->partyid; snprintf( buf, MAX_BUF, "%s joins party %s", op->name, tmpparty->partyname ); other options include extending pl->party_number and partylist->partyid to be sint32's (that will make the exploit take longer to occur, but doesn't fix the underlying problem). This also adresses point 2. Index: include/player.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/player.h,v retrieving revision 1.37 diff -C5 -r1.37 player.h *** include/player.h 15 Aug 2004 17:03:07 -0000 1.37 --- include/player.h 28 Apr 2005 03:33:18 -0000 *************** *** 170,181 **** time_t last_save_time; #endif /* SAVE_INTERVAL */ #ifdef AUTOSAVE uint32 last_save_tick; #endif ! sint16 party_number; /* Party number this player is part of */ ! sint16 party_number_to_join; /* used when player wants to join a party */ /* but we will have to get password first */ /* so we have to remember which party to */ /* join */ char search_str[MAX_BUF]; /* Item we are looking for */ sint16 encumbrance; /* How much our player is encumbered */ --- 170,181 ---- time_t last_save_time; #endif /* SAVE_INTERVAL */ #ifdef AUTOSAVE uint32 last_save_tick; #endif ! sint32 party_number; /* Party number this player is part of */ ! sint32 party_number_to_join; /* used when player wants to join a party */ /* but we will have to get password first */ /* so we have to remember which party to */ /* join */ char search_str[MAX_BUF]; /* Item we are looking for */ sint16 encumbrance; /* How much our player is encumbered */ *************** *** 190,200 **** } player; /* not really the player, but tied pretty closely */ typedef struct party_struct { ! sint16 partyid; char * partyleader; char passwd[9]; struct party_struct *next; char *partyname; --- 190,200 ---- } player; /* not really the player, but tied pretty closely */ typedef struct party_struct { ! sint32 partyid; char * partyleader; char passwd[9]; struct party_struct *next; char *partyname; This still doesn't deal with point 1 though, which may be more an issue with the network code. possible things to do; limit the number of parties a player can create (but without party removal that may be considered bad). limit the global number of parties (that could mean the list could be spammed stopping party formation). have party removal (harder to implement, though possible), and autoremove parties that no longer have active members (but then if they all log off, their party will go). have a party player counter, which only changes when the party a player is a member of does, use this for party removal, and save the current party in the save file (but then there are abuses involving parties that gain passwords, or newly formed parties after a server reset). From mwedel at sonic.net Thu Apr 28 00:55:09 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Apr 28 00:56:05 2005 Subject: [crossfire] Items that evolve all the time In-Reply-To: <200504271419.48374.tchize@myrealbox.com> References: <200504261918.25546.tchize@myrealbox.com> <426F20CC.2080700@sonic.net> <200504271419.48374.tchize@myrealbox.com> Message-ID: <42707ABD.1030208@sonic.net> The complication is that if the map resets, there is no easy measure to know how long the objects in question have not been accessed. For maps swapped out and swapped back in, I agree that is a much easier problem, as you can easily know how long the map has been swapped. But for maps that reset, this is more a problem, because neither the overlay map nor the unique item maps contain any map header. Thus, there is no convenient way right now to store when the map was saved out, and thus know how long the map has been swapped out. From mwedel at sonic.net Thu Apr 28 01:32:23 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Apr 28 01:34:06 2005 Subject: [crossfire] large numbers of parties causes weirdness In-Reply-To: <200504280455.42567.b.t.lally@warwick.ac.uk> References: <200504280455.42567.b.t.lally@warwick.ac.uk> Message-ID: <42708377.2060704@sonic.net> Brendan Lally wrote: > Well, there was a mention of a security audit a while back, here's a result > from it, and even a sample exploit code :) > > The party that a person is a member of is stored in a 'partyid' in the player > struct. This is an sint16. each party gets an sint16 as the party number, and > The following code, run as a script by a player is enough to cause breakages > in the party system that crossfire uses. > > #!/bin/bash > for i in $(seq 1 1 65536); > do > echo "issue 1 1 party form $i" > sleep 0.05 > done > > there are three issues. > 1) when it gets above about 1800 it causes clients to crash when doing party > list. IMO, that is the only one that really needs to be fixed - unless old parties are deleted, there will be problems, because the party list won't fit in the output buffer, and the server will close the connection to the client. If old parties are cleaned up, then wrapping could be pretty easily handled (add a little check that does handle the wrapping properly, and another little check to make sure the party number is unique). If those two are done, then having party be in a 16 bit value (or probably even 8 bit) wouldn't be a problem. The right approach is to probably delete parties that don't have any members in them. If everyone logs off, tough luck. If I create a party and log off, that party shouldn't stick around for 2 weeks anyways. If a player saves and joins again, they have to rejoin the party - I don't consider that a big deal. If the server crashes right now, all the party info is lost anyways. Adding a periodic call to do_specials to handle party cleanup is probably the easiest way to go. Also, if the player is a member of a party and tries to start a new one, should see if they are the sole member of the party they are currently in - if so, then delete it (thus to try and pollute the party listing, it would require a bunch of players all on at the same time). From mwedel at sonic.net Thu Apr 28 01:43:40 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Apr 28 01:44:07 2005 Subject: [crossfire] channels In-Reply-To: <200504280132.49024.b.t.lally@warwick.ac.uk> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504270222.51377.b.t.lally@warwick.ac.uk> <200504272208.36216.tchize@myrealbox.com> <200504280132.49024.b.t.lally@warwick.ac.uk> Message-ID: <4270861C.4030105@sonic.net> Few quick notes: >> I estimated that there'd be around 20-30 different NDI_ >>> fields. > > > well, how about if I actually count them? I don't mean how many there are right now. I mean how many different unique ones there should be. The item on the TODO list is to redo these messages, so like most things on the TODO list, bears little relation to what is there now. >> That is one problem I have with both having channels and colors - from a >>> user perspective, how do I control preferences then? For example, suppose >>> the preference I describe is based on channels. How do you handle messages >>> that come in on that channel in a different color? You can't really have a >>> selection for all those posibilities, so the client has to assume some >>> behaviour. does it just use the defaults the user selects (tab, font, >>> color)? Does it use the color it comes in as, but otherwise use same tab >>> and font? etc. That is why having only 1 attribute for all draw_info >>> calls makes things much easier to handle - if there is only 30 message >>> types, easy to present all those in a window to the user to choose their >>> defaults. > > > hmm, a thought that occurs is that one way that could work is if I changed the > way the value was stored in pl->listening, so that the player could store > their own colour for it there. -1 would be off, -2 banned >=0 would be on in > the appropriate colour. 255 would be 'use what you are told to use' > > then if the player has a colour preference defined, their choice of colour is > sent, otherwise, the channel one is. > > this could be parsed client side (by a script maybe?), so that you have a > window to list the channels with an on/off button and an override colour > option. > > do you want me to do that instead? If a channel only will use one color and only one color, that isn't much a problem. The problem right now is that your both have channels and colors, eg, attack channel messages may come in several colors. This makes handling preferences very difficult. >> Note that these preferences are also stored client side. So this makes >>> dynamic channels harder to handle - channel 25 may change its meaning run >>> to run, or perhaps even server to server. I don't have a good solution for >>> that one. > > > which was why I was doing it server side. > Which I'm not sure is the right approach. IMO, client appearance issues should be stored with the client, not on the server. One way to think about this is that if I do set prferences for those 30 channels, I really don't want to have to do that again for each player I may start, and/or each server I play on. The general design philosphy is that anything that can be done on the client should be done on teh client. Only stuff that can't be done on the client securely should be done on the server (securely in this context means not giving the client info it shouldn't have). there are several reasons behind this philosphy, but mostly it boils down to trying to keep the server code as simple as possible (reduces CPU usage, less likely to be exploits, etc). But the problem, IMO, is beyond just storing it on the server. Since channels are dynamic, a channel that exists one time I am playing may not exist (or may exist with a completely different purpose) the next day when I play. So storing that on the client or server doesn't really make any difference - either way, the preferences I set before may no longer apply. But I don't have a good solution to that either way - my real point that trying to set preferences on such dynamic channels will be very hard to deal with. From mwedel at sonic.net Thu Apr 28 02:10:54 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Apr 28 02:12:07 2005 Subject: [crossfire] channels In-Reply-To: <200504272208.36216.tchize@myrealbox.com> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504261958.21983.tchize@myrealbox.com> <200504270222.51377.b.t.lally@warwick.ac.uk> <200504272208.36216.tchize@myrealbox.com> Message-ID: <42708C7E.3030401@sonic.net> tchize wrote: > > Now, in case of speaking channels, i obviously see a main type > MSG_TYPE_CHANNEL > with various flavor: > SHOUT the main speaking flavor > SAY the map speaking flavor > TELL this one will be able have, as first line, the name of speaking player > then the message, so client can open a new tab for each speaking player > PARTY_SAY perhaps for this flavor first line would be party name, second line > speaker name, and the rest the message itself > CHANNEL this one will get message directe to any channel. Could have similar > behaviour as PARTY_SAY > DM_CHANNEL a flavor dedicated to the dm? > ... whatever you speak about. The flavor is coded as a 16bits int, there is > much freedom to define lots of flavors and you can handle the way you want. > The content of the textual message part just has to be somewhat consistent > inside a given main type ;) > And because flavor is just an information, server does not do anything based > on the flavor. All it does is check client request to get the main MSG_TYPE > and, if so, send all flavors message when they are generated. This is a little more than I was thinking, but was along the idea I was thinking with the NDI_.. redo. So flavors like spell listing, shop listing, level gains, etc could also be added as flavors then? > > buf may contains this: > "You open the necronomicon and start reading...\nYour soul is mine, player!" > while nicebuf may contains this. > "necronomicon\nYour soul is mine, player!" > the draw_ext_info will check if client requested msgType->message_type to be > send using the new command, and if so issue a draw_info_ext on the wire with > a nicebuf. If this is not the case, it will issue a classical draw_info. I'm a little concerned about this - my fear is that the nicebuf things won't get updated in any timely fashion, or people will be updating only one, and the two will be completely out of sync (support for this alternate msgbuf obviously would need to be put into the editors that people use). However, it also seems like you are doing 2 things here: 1) telling client types of messages so it could draw pretty frames, etc 2) extending the text field to include tags for color, bold, etc. I hope on #2 you are using the formatting features the GTK already has built in. If so, then it makes life much easier (it'd be really stupid to have to write our own parser for that when GTK provides one for us) I'd personally like to see full documentation for the 'drawinfo_ext' command - the docs that will make it into the protocol file. Coding practices for crossfire are that the protocol changes are to have been properly documented and sent to the mailing list for discussion with plenty of advance notice before such changes are made to CVS. That said, in my ideal scenario, it would look something like: drawinfo2 where formattype descirbes the format of the message (text, binary data, text formatted in 3 rows, text formatted for ...) msgtype helps identify the type of message for sorting and preference purposes. msgsubtype is finer control. color is color of message - probably obsolete because that will be a client preference based on previous fields. The advantage of having formattype as the key value is that there probably isn't a need to have too many different format types. And regardless of the remaining fields, the client could display the data if it understands the format type (if it doesn't, it probably shouldn't try). From b.t.lally at warwick.ac.uk Thu Apr 28 08:25:31 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Thu Apr 28 08:06:10 2005 Subject: [crossfire] channels In-Reply-To: <4270861C.4030105@sonic.net> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504280132.49024.b.t.lally@warwick.ac.uk> <4270861C.4030105@sonic.net> Message-ID: <200504281425.32061.b.t.lally@warwick.ac.uk> On Thursday 28 Apr 2005 07:43, Mark Wedel wrote: > >> Note that these preferences are also stored client side. So this makes > >> > >>> dynamic channels harder to handle - channel 25 may change its meaning > >>> run to run, or perhaps even server to server. I don't have a good > >>> solution for that one. > > > > which was why I was doing it server side. > > Which I'm not sure is the right approach. IMO, client appearance issues > should be stored with the client, not on the server. One way to think > about this is that if I do set prferences for those 30 channels, I really > don't want to have to do that again for each player I may start, and/or > each server I play on. this is true, however certainly on a server-by-server basis, there may well be reason to ignore different channels, so simply saying that one solution from the client is correct for all servers may not be the right thing to do either. having said that, I am now inclined to leave the default appearance as it is, and use Tchize's new call, since that will allow me to send the information that is needed, and provides a good solution to the issue. 3 major channel types - system server and personal, each will be a type under his approach, each will have a subtype corresponding to channel number. Since the number of server channels will be fixed, the numbers will be stored client side and interpreted there (less bandwidth, since there can be a /lot/ of messages). since the messages on the system channels will all be fixed anyway, formatting can be done based on the number sent (channel foo is red, channel bar is blue) For the others, the channel name is sent as the first part of the message, the name of the person as the second, and the message as the rest. Chat channels are less noisy than the 'nty-one times you search the area style messages anyway' and the increase in data sent is only a handful of bytes anyway. what the client should do with that I'm not to bothered, if it wants tabs, then assign tabs based on the name (since the numbers of the dynamic channels might alter, but the system ones would be fixed (with maybe some added, but not taken away), it can do as it chooses with channels, I'm not too bothered. If it has an easy way that as an abstract thing I could see how it might maybe draw messages from different people in different colours or have /ignore (for players) done client side really easily. in this case then, the colours that are sent are really only for legacy client support, so that maybe how many there are is less important, and the only issue server side is whether to handle the channel or not. > The general design philosphy is that anything that can be done on the > client should be done on teh client. Only stuff that can't be done on the > client securely should be done on the server (securely in this context > means not giving the client info it shouldn't have). there are several > reasons behind this philosphy, but mostly it boils down to trying to keep > the server code as simple as possible (reduces CPU usage, less likely to be > exploits, etc). At the moment what I do is store the channels that are not on their default setting in the player file, then when someone reconnects, it tries to alter all channels that are listed. The ones that are non-default cause a message to be printed. (actually thinking about it that is the wrong way round, I should make it list the channels that no longer exist, this way the player will know when a channel they listen too is no longer available). However, wrt the system channels, thinking that at some point there might be 30+ people on a server (metalforge gets close at times), the traffic requirements could get quite high on the global channels, COMM_KILLS especially. if 20 of them were killing monsters at a rate of 2 a second, then there would be 40 messages sent a second, each of these would be about 50bytes, that is 2KB a second. That isn't a whole lot, except that now modem users are unable to play the game at anything like a sane speed. for the server, you have 100-200KB a second being sent, which is a fair amount, and something that it would be nice to reduce/remove. In addition to this, unless server subscription is server side, there is no way to enforce kicking (which I have already implemented) or banning (which I have mostly implemented), I'm not sure yet whether to have invite only channels, that is another instance where server side knowledge of the channels a player is subscribed to is needed. In that case then, since there have to be some channels monitored server side, it is probably best to do them all that way. In fact the only disadvantage with this approach that I can see is that it requires me to change all the new_draw_info commands again, but I should be able to do that next wednesday. In the meantime, I have some other commitments that are going to try and keep me away from cf over the rest of this week/weekend, so I'll wait until Tchize's patch is in and then try and fit what I have done around that. From tchize at myrealbox.com Thu Apr 28 09:32:46 2005 From: tchize at myrealbox.com (tchize@myrealbox.com) Date: Thu Apr 28 09:32:11 2005 Subject: [crossfire] channels In-Reply-To: <42708C7E.3030401@sonic.net> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504272208.36216.tchize@myrealbox.com> <42708C7E.3030401@sonic.net> Message-ID: <200504281632.46186.tchize@myrealbox.com> Le Jeudi 28 Avril 2005 09:10, Mark Wedel a ?crit : > This is a little more than I was thinking, but was along the idea I was > thinking with the NDI_.. redo. So flavors like spell listing, shop > listing, level gains, etc could also be added as flavors then? > Any flavor you like :) > I'm a little concerned about this - my fear is that the nicebuf things > won't get updated in any timely fashion, or people will be updating only > one, and the two will be completely out of sync (support for this alternate > msgbuf obviously would need to be put into the editors that people use). > nope, peoples only have one field to update it's the book->msg field. The server just present data differently depending on the command used to send data (draw_info or draw_info_ext) in fact server does this: strncpy(buf,sizeof(buf),"You open the %s and star reading... \n%s",ob->name,ob->msg); Something similar is done for nicebuf. The server will also have to strip out media tags before sending using the draw_info command (for old clients) > However, it also seems like you are doing 2 things here: > > 1) telling client types of messages so it could draw pretty frames, etc > 2) extending the text field to include tags for color, bold, etc. > > I hope on #2 you are using the formatting features the GTK already has > built in. If so, then it makes life much easier (it'd be really stupid to > have to write our own parser for that when GTK provides one for us) working with gtk1, all i saw was samething called gtk-html, which is an extension not include with the main gtk code, and i doubt it will work for windows version :/ i choos to use something easy to handle (no closing tag, a tag just set a value, there is no such thing as [normal]blabla[hand]foo-bar[/hand]other blabla[/normal] Parsing is quite straight forward anddoesn't involve complicated things. > > I'd personally like to see full documentation for the 'drawinfo_ext' > command - the docs that will make it into the protocol file. Coding > practices for crossfire are that the protocol changes are to have been > properly documented and sent to the mailing list for discussion with plenty > of advance notice before such changes are made to CVS. > sure, there are descriptions in protocol file > That said, in my ideal scenario, it would look something like: > > drawinfo2 > > where formattype descirbes the format of the message (text, binary data, > text formatted in 3 rows, text formatted for ...) > > msgtype helps identify the type of message for sorting and preference > purposes. msgsubtype is finer control. > color is color of message - probably obsolete because that will be a client > preference based on previous fields. > > The advantage of having formattype as the key value is that there > probably isn't a need to have too many different format types. And > regardless of the remaining fields, the client could display the data if it > understands the format type (if it doesn't, it probably shouldn't try). > msgtype, because it regroups things presenting the same way, does inherently have a format. Client must request deliberatly a setup for each msgtype it support to be send by server, so no suprises in format. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- David Delbecq Royal Meteorological Institute of Belgium From eracclists at bellsouth.net Thu Apr 28 10:46:49 2005 From: eracclists at bellsouth.net (ERACC) Date: Thu Apr 28 10:48:10 2005 Subject: [crossfire] titan_quest map not solvable anymore? In-Reply-To: <426F3B5F.4090000@sonic.net> References: <426F3B5F.4090000@sonic.net> Message-ID: <200504281046.49794.eracclists@bellsouth.net> On Wednesday 27 April 2005 02:12 am Mark Wedel wrote: > I recently tried to do the titan quest (archduke of scorn quest) map and was > unable to finish it. I'm not sure if its because I'm just missing something, or > as I think might be the case, server behavior has changed. > > My guess looking at the map is that the player is supposed to dimension door > into the small chambers, and then get the final key that gives access to megalopos. [...] No, the cyclops and titans in the side chambers are carrying keys for the "small chambers". Pick those keys up first. Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 10:45:01 up 17:33, 7 users, load average: 0.27, 0.33, 0.20 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers From delbd at oma.be Thu Apr 28 09:34:42 2005 From: delbd at oma.be (delbd) Date: Thu Apr 28 11:51:25 2005 Subject: [crossfire] Items that evolve all the time In-Reply-To: <42707ABD.1030208@sonic.net> References: <200504271419.48374.tchize@myrealbox.com> <42707ABD.1030208@sonic.net> Message-ID: <200504281634.42258.delbd@oma.be> Le Jeudi 28 Avril 2005 07:55, Mark Wedel a ?crit : > The complication is that if the map resets, there is no easy measure to > know how long the objects in question have not been accessed. > > For maps swapped out and swapped back in, I agree that is a much easier > problem, as you can easily know how long the map has been swapped. > > But for maps that reset, this is more a problem, because neither the > overlay map nor the unique item maps contain any map header. Thus, there > is no convenient way right now to store when the map was saved out, and > thus know how long the map has been swapped out. > Am sorry, but there is a thing we can use, the lastmodified information from filesystem which tells us the last time overlay was saved to disk. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- David Delbecq Royal Meteorological Institute of Belgium From krudat at iinet.net.au Thu Apr 28 18:06:07 2005 From: krudat at iinet.net.au (Kevin Rudat) Date: Thu Apr 28 17:22:03 2005 Subject: [crossfire] Extending apply commands Message-ID: <20050428230607.GA6101@localhost.localdomain> Some old discussions suggest * moving the apply command (text-command, not protocol-command) to the client, * adding an apply_below to search only the floor, * adding some more verbs, e.g. 'eat' to search only food. Questions: * Did someone write an apply_below already? * What if I wrote a patch for adding client_types for a number of applyable things that don't have one? Moving these things to the client: * Does anyone know why (who decided) when you've got a lot of things on the floor, you can only see fifty of them? Makes it impossible to search the entire floor (not important enough to worry about? Have any script authors run into this?) (The limits are implemented in socket/item.c::esrv_draw_look(); scrolling's in socket/item.c::ApplyCmd().) * common/arch.c::item_matched_string checks against a number of things that aren't sent to the client (in the same way that the client doesn't get a shop inventory, just a bunch of lines). Strings to be sent: * material, where applicable (#ifdef NEW_MATERIAL_CODE, possibly) * op->name, op->name_pl, * the flags, title, level, et cetera generated by query_*_name() * The '* (open)' status string added by query_name() (The client can generate this for itself, though.) * op->custom_name. Alternately, not moving these things to the client: * I haven't thought this through completely, but what about a very general apply protocol command: apply_specific ... ... player types apply: apply_specific 1 0 '' player types apply foo: apply_specific 1 0 'foo' apply_below foo: apply_specific 1 0 'foo' sleep: apply_specific 1 1 '' drink power: apply_specific 1 2 'power' From krudat at iinet.net.au Thu Apr 28 18:06:07 2005 From: krudat at iinet.net.au (Kevin Rudat) Date: Thu Apr 28 17:22:07 2005 Subject: [crossfire] Extending apply commands Message-ID: <20050428230607.GA6101@localhost.localdomain> Some old discussions suggest * moving the apply command (text-command, not protocol-command) to the client, * adding an apply_below to search only the floor, * adding some more verbs, e.g. 'eat' to search only food. Questions: * Did someone write an apply_below already? * What if I wrote a patch for adding client_types for a number of applyable things that don't have one? Moving these things to the client: * Does anyone know why (who decided) when you've got a lot of things on the floor, you can only see fifty of them? Makes it impossible to search the entire floor (not important enough to worry about? Have any script authors run into this?) (The limits are implemented in socket/item.c::esrv_draw_look(); scrolling's in socket/item.c::ApplyCmd().) * common/arch.c::item_matched_string checks against a number of things that aren't sent to the client (in the same way that the client doesn't get a shop inventory, just a bunch of lines). Strings to be sent: * material, where applicable (#ifdef NEW_MATERIAL_CODE, possibly) * op->name, op->name_pl, * the flags, title, level, et cetera generated by query_*_name() * The '* (open)' status string added by query_name() (The client can generate this for itself, though.) * op->custom_name. Alternately, not moving these things to the client: * I haven't thought this through completely, but what about a very general apply protocol command: apply_specific ... ... player types apply: apply_specific 1 0 '' player types apply foo: apply_specific 1 0 'foo' apply_below foo: apply_specific 1 0 'foo' sleep: apply_specific 1 1 '' drink power: apply_specific 1 2 'power' From pc-crossfire04 at crowcastle.net Thu Apr 28 17:31:22 2005 From: pc-crossfire04 at crowcastle.net (Preston Crow) Date: Thu Apr 28 17:33:15 2005 Subject: [crossfire] Extending apply commands In-Reply-To: <20050428230607.GA6101@localhost.localdomain> References: <20050428230607.GA6101@localhost.localdomain> Message-ID: <1114727482.6884.10.camel@hawk> On Thu, 2005-04-28 at 19:06, Kevin Rudat wrote: > * Does anyone know why (who decided) when you've got a lot of things on the floor, > you can only see fifty of them? > > Makes it impossible to search the entire floor (not important enough to > worry about? Have any script authors run into this?) > > (The limits are implemented in socket/item.c::esrv_draw_look(); > scrolling's in socket/item.c::ApplyCmd().) I believe that the problem was that with a huge stack, moving onto it sent enough data to the client to cause the client to disconnect. It was also a source of lag for other players. Yes, it does make implementing pickup modes on the client difficult, but it was already impractical, as by the time the client sees an object, the player may have already sent a command to move (especially if running). --PC From mwedel at sonic.net Fri Apr 29 22:27:29 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Apr 29 22:28:31 2005 Subject: [crossfire] titan_quest map not solvable anymore? In-Reply-To: <200504281046.49794.eracclists@bellsouth.net> References: <426F3B5F.4090000@sonic.net> <200504281046.49794.eracclists@bellsouth.net> Message-ID: <4272FB21.2060309@sonic.net> ERACC wrote: > On Wednesday 27 April 2005 02:12 am > Mark Wedel wrote: > > >> I recently tried to do the titan quest (archduke of scorn quest) map and was >>unable to finish it. I'm not sure if its because I'm just missing something, or >>as I think might be the case, server behavior has changed. >> >> My guess looking at the map is that the player is supposed to dimension door >>into the small chambers, and then get the final key that gives access to megalopos. > > [...] > > No, the cyclops and titans in the side chambers are carrying keys for > the "small chambers". Pick those keys up first. I did that. The small chambers are within small rooms. There is a door needing the key to the small chambers, but there are no doors into the small room, so one can't get to the door where you need to use the keys. From mwedel at sonic.net Sat Apr 30 01:14:21 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Apr 30 01:14:33 2005 Subject: [crossfire] Extending apply commands In-Reply-To: <20050428230607.GA6101@localhost.localdomain> References: <20050428230607.GA6101@localhost.localdomain> Message-ID: <4273223D.6030009@sonic.net> Kevin Rudat wrote: > Some old discussions suggest > * moving the apply command (text-command, not > protocol-command) to the client, > > * adding an apply_below to search only the floor, > > * adding some more verbs, e.g. 'eat' to search only food. > > Questions: > > * Did someone write an apply_below already? Depending how this is done, this is problematic. One real problem right now is that objects in the ground are in a specific order. This means that whenever an object on the ground is changed, the entire stack of objects has to be resent. The ideal case would be to not make this the case - handle the floor just like the inventory is handled, and let the client order the objects as needed - this then means if an object on the ground changes, only that object has to change. An apply_below on the client side coudl be done, which could just send a list of objects (in the order the client knows them at) to the server. Eg, something like: apply ... And the apply just stops once it gets one it can actually apply. Then, it'd be easy to write a 'bottom up apply' as well as a 'top down' apply. As well as interacting better with the 50 item groupings. > > * What if I wrote a patch for adding client_types for a number of > applyable things that don't have one? I don't have a problem with that. Be aware that the client_type shouldn't give away any information the player wouldn't know (generally not a problem, as most objects are pretty obvious for what they are). > > Moving these things to the client: > > * Does anyone know why (who decided) when you've got a lot of things on the floor, > you can only see fifty of them? > > Makes it impossible to search the entire floor (not important enough to > worry about? Have any script authors run into this?) > > (The limits are implemented in socket/item.c::esrv_draw_look(); > scrolling's in socket/item.c::ApplyCmd().) Preston basically got it right. There are limits to the amount of data that can be sent to the client at once - sending more than that fills up the buffer, and the server drops the connection once it gets full. The other problem is related to what I mention above - since objects have to be in a specific order, it gets to be a problem to try to send the data as multiple packets. The client/script could of course do the apply to get the next group of items. there is also an item in the TODO list to have objects spell over. Eg, if you have a pile of 5000 coins, it'd spill over to other spaces, so that one space maybe has 2000 coins, and the neighboring spaces 1000 each (or something like that). This imposes additional load on the server, and almost certainly, has to be done on a per different (non mergable) object - otherwise, could have problems activating altars. > > > * I haven't thought this through completely, but what about a very general apply > protocol command: > > apply_specific ... > ... > > > player types apply: apply_specific 1 0 '' > player types apply foo: apply_specific 1 0 'foo' > apply_below foo: apply_specific 1 0 'foo' > sleep: apply_specific 1 1 '' > drink power: apply_specific 1 2 'power' But there is no reason that couldn't be done on the client right now. IMO, the only reason that some matching/pickup is done on the server is simply synchronization issue as Preston describes. For things like apply, there shouldn't be that issue - certainly not for anything in the players inventory. The client knows the environments, knows the names, knows client_id types, so it would seem to me that could easily be done on the client - client just parses the options, and then figures out what item(s) actually match. But this would go a bit above with allowing apply to operate on multiple objects and stops once it gets one in can apply. From mwedel at sonic.net Sat Apr 30 01:18:16 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Apr 30 01:20:05 2005 Subject: [crossfire] channels In-Reply-To: <200504281425.32061.b.t.lally@warwick.ac.uk> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504280132.49024.b.t.lally@warwick.ac.uk> <4270861C.4030105@sonic.net> <200504281425.32061.b.t.lally@warwick.ac.uk> Message-ID: <42732328.8020504@sonic.net> Brendan Lally wrote: > > However, wrt the system channels, thinking that at some point there might be > 30+ people on a server (metalforge gets close at times), the traffic > requirements could get quite high on the global channels, COMM_KILLS > especially. if 20 of them were killing monsters at a rate of 2 a second, then > there would be 40 messages sent a second, each of these would be about > 50bytes, that is 2KB a second. That isn't a whole lot, except that now modem > users are unable to play the game at anything like a sane speed. for the > server, you have 100-200KB a second being sent, which is a fair amount, and > something that it would be nice to reduce/remove. Just because the preference is stored on the client doesn't mean the client can't tell the server what its preference is. In fact, this is already done for all sorts of things (map size, sound, image set, and so on). So for channels, same thing could be done - as part of setting up the connection, the client can get the channel listing from the server, and for ones it knows about, send back whether it wants to subscribe to those channels or not. From mwedel at sonic.net Sat Apr 30 01:38:43 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Apr 30 01:40:35 2005 Subject: [crossfire] channels In-Reply-To: <200504281632.46186.tchize@myrealbox.com> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504272208.36216.tchize@myrealbox.com> <42708C7E.3030401@sonic.net> <200504281632.46186.tchize@myrealbox.com> Message-ID: <427327F3.4070605@sonic.net> tchize@myrealbox.com wrote: > > nope, peoples only have one field to update it's the book->msg field. > The server just present data differently depending on the command used to send > data (draw_info or draw_info_ext) > in fact server does this: > strncpy(buf,sizeof(buf),"You open the %s and star reading... > \n%s",ob->name,ob->msg); > > Something similar is done for nicebuf. The server will also have to strip out > media tags before sending using the draw_info command (for old clients) This has to be done at load time then - if we have to examine every message we send to a client to see if it has tags and then strip out those tags, I'd see this quickly become a very costly operation. >> I hope on #2 you are using the formatting features the GTK already has >>built in. If so, then it makes life much easier (it'd be really stupid to >>have to write our own parser for that when GTK provides one for us) > > > working with gtk1, all i saw was samething called gtk-html, which is an > extension not include with the main gtk code, and i doubt it will work for > windows version :/ > > i choos to use something easy to handle (no closing tag, a tag just set a > value, there is no such thing as [normal]blabla[hand]foo-bar[/hand]other > blabla[/normal] > > Parsing is quite straight forward anddoesn't involve complicated things. I think I was looking at the pango parser: http://www.gtk.org/api/2.6/pango/PangoMarkupFormat.html This is a bit more complicated in its format, but then integrates very simply into the client. It just strikes me as stupid to write our own parser when there are perfectly good ones out there. Aside from the initial effort, you are then likely to get into the case of features people perhaps want in the future, so what is right now a simple parser may in the end become pretty complicated. > > >> I'd personally like to see full documentation for the 'drawinfo_ext' >>command - the docs that will make it into the protocol file. Coding >>practices for crossfire are that the protocol changes are to have been >>properly documented and sent to the mailing list for discussion with plenty >>of advance notice before such changes are made to CVS. >> > > > sure, there are descriptions in protocol file There is nothing in the protocol file right now about your drawinfo_ext command. Updating that file the same time you commit the rest of the changes is not considered advanced notice and is not acceptable practice. >> >>drawinfo2 >> >> where formattype descirbes the format of the message (text, binary data, >>text formatted in 3 rows, text formatted for ...) >> >> msgtype helps identify the type of message for sorting and preference >>purposes. msgsubtype is finer control. >>color is color of message - probably obsolete because that will be a client >>preference based on previous fields. >> >> The advantage of having formattype as the key value is that there >>probably isn't a need to have too many different format types. And >>regardless of the remaining fields, the client could display the data if it >>understands the format type (if it doesn't, it probably shouldn't try). >> > > > msgtype, because it regroups things presenting the same way, does inherently > have a format. > Client must request deliberatly a setup for each msgtype it support to be > send by server, so no suprises in format. The problem with that is I can certainly see new msgtypes added with a format that is very simple and every client would understand. Yet if the client has to explicity understand all the msgtypes, it means it has to get the information in the old format (while the client may not know the msgtype, and thus not have any real idea of what tab to put it into, it is perfectly capable in knowing how to display it). So to me, it makes sense to seperate those two pieces - have a formattype that says how to display this, and a msgtype that says what type of message it is so the client knows what tab to display it in (or other special operations). From krudat at iinet.net.au Sat Apr 30 03:22:06 2005 From: krudat at iinet.net.au (Kevin Rudat) Date: Sat Apr 30 02:24:34 2005 Subject: [crossfire] Extending apply commands In-Reply-To: <4273223D.6030009@sonic.net> References: <20050428230607.GA6101@localhost.localdomain> <4273223D.6030009@sonic.net> Message-ID: <20050430082206.GA4528@localhost.localdomain> Thanks for your replies so far, Mark and Preston. :) Hmm. So that's: Submit a patch adding client_type to apply-able things without client_type. ---------------------------------------------------------------------------- It'd also put this extra bit in doc/Developers/objects: 25000-25999 Non-inventory items that can be applied. 25001 Magic portals (66) 25002 Exits, doors, buildings (66) 25011 Ordinary signs (98) 25012 Shop menu (150) 25021 Postbox 25031 Slot machines 25032 Trigger (27), levers (93) 25091 Bed to reality (106) (I tweaked the server to find such archetypes. ... cheeseburger. :) ) Implement apply_below and item-type-specific commands as a client-script. -------------------------------------------------------------------------- Particularly, as Mark mentioned, automatically apply the 'scrolling items' when searching the floor. Mental note: look up what apply_below was supposed to do before thinking about implementing it. (The item-verbs come from Adam Ashenfelter, but I can't remember who suggest an apply_below.) If apply_below sticks to what's on the floor, apply_below with no argument is equivalent to apply with no argument, so it's only interesting *with* an argument, so searching through items by name is important. Also, Adam's 'sleep', which took no arguments, can just scroll through the 50-item groups until it finds a client_type 25901. 'eat' with an argument needs to check names. Client-side item name matching ------------------------------- Looking at the code of common/arch.c::item_matched_string(), I'm not sure the client can imitate it completely with the available information. The flags are easy, and the client can guess at op->name by chopping at the first 'of' or '(', and knowing material names (and not to take away mithril from mithril chainmail). However, if an item has been given a custom name, the client doesn't get the ordinary information; esrv_draw_look() and friends send only the custom_name. ... If I propose a protocol extension to send finer-grained item names, should I also add a persistent client-set object tag? ;) [1] Thanks for your time, and any critiquing -- Kevin [1] http://shadowknight.real-time.com/pipermail/crossfire/2004-September/002743.html Last quote-comment pair. From tchize at myrealbox.com Sat Apr 30 05:11:00 2005 From: tchize at myrealbox.com (tchize) Date: Sat Apr 30 05:12:37 2005 Subject: [crossfire] channels In-Reply-To: <427327F3.4070605@sonic.net> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504281632.46186.tchize@myrealbox.com> <427327F3.4070605@sonic.net> Message-ID: <200504301211.05688.tchize@myrealbox.com> Le Samedi 30 Avril 2005 08:38, Mark Wedel a ?crit : >tchize@myrealbox.com wrote: >> nope, peoples only have one field to update it's the book->msg field. >> The server just present data differently depending on the command used to >> send data (draw_info or draw_info_ext) >> in fact server does this: >> strncpy(buf,sizeof(buf),"You open the %s and star reading... >> \n%s",ob->name,ob->msg); >> >> Something similar is done for nicebuf. The server will also have to strip >> out media tags before sending using the draw_info command (for old >> clients) > > This has to be done at load time then - if we have to examine every > message we send to a client to see if it has tags and then strip out those > tags, I'd see this quickly become a very costly operation. > agree >>> I hope on #2 you are using the formatting features the GTK already has >>>built in. If so, then it makes life much easier (it'd be really stupid to >>>have to write our own parser for that when GTK provides one for us) >> >> working with gtk1, all i saw was samething called gtk-html, which is an >> extension not include with the main gtk code, and i doubt it will work for >> windows version :/ >> >> i choos to use something easy to handle (no closing tag, a tag just set a >> value, there is no such thing as [normal]blabla[hand]foo-bar[/hand]other >> blabla[/normal] >> >> Parsing is quite straight forward anddoesn't involve complicated things. > > I think I was looking at the pango parser: >http://www.gtk.org/api/2.6/pango/PangoMarkupFormat.html > > This is a bit more complicated in its format, but then integrates very > simply into the client. lib pango is gtk2, not gtk1. And the format is indeed more complicated. This sure simplifies to writing of gtk2 client, but it's a problem with other clients (gtk1, opengl client, sdl client). Also there is a problem for fonts, i want 5 fonts to be availabe, corresponding to normal text, hand written text, magical text, undecipherable text and fixed width text and the attribute does not . I can't really see how the pango markup will be of help on that. Not to mention it has no support for including pictures in text. Also, am not sure it's a good idea to have client/common have a permanent dependency on libPango > > It just strikes me as stupid to write our own parser when there are > perfectly good ones out there. Aside from the initial effort, you are then > likely to get into the case of features people perhaps want in the future, > so what is right now a simple parser may in the end become pretty > complicated. > >>> I'd personally like to see full documentation for the 'drawinfo_ext' >>>command - the docs that will make it into the protocol file. Coding >>>practices for crossfire are that the protocol changes are to have been >>>properly documented and sent to the mailing list for discussion with >>> plenty of advance notice before such changes are made to CVS. >> >> sure, there are descriptions in protocol file > > There is nothing in the protocol file right now about your drawinfo_ext >command. Updating that file the same time you commit the rest of the > changes is not considered advanced notice and is not acceptable practice. > >>>drawinfo2 >>> >>> where formattype descirbes the format of the message (text, binary data, >>>text formatted in 3 rows, text formatted for ...) >>> >>> msgtype helps identify the type of message for sorting and preference >>>purposes. msgsubtype is finer control. >>>color is color of message - probably obsolete because that will be a >>> client preference based on previous fields. >>> >>> The advantage of having formattype as the key value is that there >>>probably isn't a need to have too many different format types. And >>>regardless of the remaining fields, the client could display the data if >>> it understands the format type (if it doesn't, it probably shouldn't >>> try). >> >> msgtype, because it regroups things presenting the same way, does >> inherently have a format. >> Client must request deliberatly a setup for each msgtype it support to be >> send by server, so no suprises in format. > > The problem with that is I can certainly see new msgtypes added with a > format that is very simple and every client would understand. Yet if the > client has to explicity understand all the msgtypes, it means it has to get > the information in the old format (while the client may not know the > msgtype, and thus not have any real idea of what tab to put it into, it is > perfectly capable in knowing how to display it). > > So to me, it makes sense to seperate those two pieces - have a formattype > that says how to display this, and a msgtype that says what type of message > it is so the client knows what tab to display it in (or other special > operations). > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050430/be0d2817/attachment-0001.pgp From eracclists at bellsouth.net Sat Apr 30 14:38:41 2005 From: eracclists at bellsouth.net (ERACC) Date: Sat Apr 30 14:40:40 2005 Subject: [crossfire] titan_quest map not solvable anymore? In-Reply-To: <4272FB21.2060309@sonic.net> References: <426F3B5F.4090000@sonic.net> <200504281046.49794.eracclists@bellsouth.net> <4272FB21.2060309@sonic.net> Message-ID: <200504301438.41936.eracclists@bellsouth.net> On Friday 29 April 2005 10:27 pm Mark Wedel wrote: > ERACC wrote: > > On Wednesday 27 April 2005 02:12 am > > Mark Wedel wrote: > > > > > >> I recently tried to do the titan quest (archduke of scorn quest) map and was > >>unable to finish it. I'm not sure if its because I'm just missing something, or > >>as I think might be the case, server behavior has changed. > >> > >> My guess looking at the map is that the player is supposed to dimension door > >>into the small chambers, and then get the final key that gives access to megalopos. > > > > [...] > > > > No, the cyclops and titans in the side chambers are carrying keys for > > the "small chambers". Pick those keys up first. > > I did that. The small chambers are within small rooms. There is a door > needing the key to the small chambers, but there are no doors into the small > room, so one can't get to the door where you need to use the keys. Think "false wall" and try it again. I have "solved" the Titan Quest over and over for experience points since February at least. So, I know it can be done without dimension door at the end. One has to use dimension door to GET there and start but that is a Good Thing. ;-) Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 14:34:02 up 2 days, 21:22, 6 users, load average: 0.03, 0.03, 0.00 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers