From crossfire-devel-admin at archives.real-time.com Tue Jul 1 13:08:13 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:31 2005 Subject: [CF-Devel] speculations about the floor (elevation) In-Reply-To: <20030701023114.67639.qmail@web21308.mail.yahoo.com> References: <20030701023114.67639.qmail@web21308.mail.yahoo.com> Message-ID: <3F01CE0D.50800@sympatico.ca> > > > >I just had an evil thought. If we are going to remove per tile elevations, >we don't really need a per map value either. For big world, we just need >to specify that the border between ocean and land is at elevation zero, and >calculate from there across the world. > > > I didn't think of the sea level. I was trying to address the idea of realtivity in the arch elevations. Per map elevation lets you easily set up a base elevation map to plot things from anyway. All forests should not be between 1000 and 3000 ft, all swamps shouldn't be near sealevel. If you have ever gone outside you know this is not the case. But you bring up a neat question, what if the map elevation is set to 20000 but all the arches on the map are deep ocean? >LOS really should use elevation information. Stand on the north side of a >mountain, to the south all you can see is the side of the mountain one tile >away. To the north you should be able to see a great distance. Unless you >are also standing in the middle of a forest off course B-). > > Elevation and LOS would be neat, but the visible map is pretty small for this to really pay off don't you think? > > >>As far as what the elevation stuff is in, when I first did it, I was >>thinking feet. While it would be fine to describe it as whatever, I >> >> >think > > >>it would be useful as developers to be able to map it easily into earth >>measurements, so if someone says that is 1000', you could more easily >>grasp what that really means. >> >> > >I ask specifically so that I could make sure that the elevation to >temperature calculation actually matched reality. I have a formula at home >that is something like 100 meters of elevation subtracts 1 degree >centigrade or something like that. Since the temperature calculations are >in metric, I assumed that the elevation would also be in metric. > > > I assumed it was ft not metres because of the scales shown, since some mountains would otherwise be 15, 20 or even 30 km high... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 2 00:04:51 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:31 2005 Subject: [CF-Devel] recent improvements Message-ID: <3F0267F3.9010402@sympatico.ca> I am now getting an error during compile in line 1117 of loader.l "initializer element is not constant" I am still waiting for any feedback on the recent change to AC_PREREQ([2.54]) in the aclocal.m4 file which hasen't been explained as either necessary or desirable since it will cause some problems (well I edited it to AC_PREREQ([2.52]) and it seems to compile it with warnings) on stock Debain systems.... I think it's all a plot to drive me away... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 2 03:44:12 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:31 2005 Subject: [CF-Devel] speculations about the floor (elevation) In-Reply-To: <3F01CE0D.50800@sympatico.ca> Message-ID: <20030702084412.73221.qmail@web21307.mail.yahoo.com> --- Todd wrote: > sealevel. If you have ever gone outside you know this is not the case. I do a lot of bush walking B-). > Elevation and LOS would be neat, but the visible map is pretty small for > this to really pay off don't you think? Maximum was 25 by 25 last time I checked, that gives you 12 tiles to the "horizon". Great views would be nice, but it would be more usefull at the other end of the scale. "I have to climb to the top of that hill a few tiles away before I can see over it." > I assumed it was ft not metres because of the scales shown, since some > mountains would otherwise be 15, 20 or even 30 km high... Mars is a much smaller planet than Earth, but it has much higher mountains B-). Everest is 9km high, Olympus Mons is 24km. This link gives a quick overview of why Mars can have mountains higher then Earth - http://www.asa3.org/archive/asa/199608/0047.html Seems like the original elevation coder was thinking in feet though. As mentioned before, temperature is in metric, so we really should try to be a bit more consistant, and document what the actual units are. http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 2 06:06:21 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:31 2005 Subject: [CF-Devel] recent improvements In-Reply-To: <3F0267F3.9010402@sympatico.ca> References: <3F0267F3.9010402@sympatico.ca> Message-ID: <200307021306.21648.tchize@myrealbox.com> Le Mercredi 2 Juillet 2003 07:04, Todd a ?crit : > I am now getting an error during compile in line 1117 of loader.l > "initializer element is not constant" > > I am still waiting for any feedback on the recent change to > AC_PREREQ([2.54]) in the aclocal.m4 file which hasen't been explained as > either necessary or desirable since it will cause some problems (well I > edited it to AC_PREREQ([2.52]) and it seems to compile it with warnings) > on stock Debain systems.... > > I think it's all a plot to drive me away... > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel Perhaps am quilty, i dunno. The fact is i had to recreate one week ago the Makefiles to add a file in the installation list when i did add the smoothing code. I used automake 1.7 and autoheader/autoconf 2.50 on a Debian with unstable configuration. What concern your error, am going to fix it as soon as possible. The offending line is has follow. static int eol_size=strlen("\n"); Here gcc 3.3 doesn't warn since, according to C standards strlen("\n") can be guessed at compile time. However i'll move this line to an initialisation routine somewhere. Sorry for conveniences. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 2 13:21:29 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:31 2005 Subject: [CF-Devel] save client settings on server Message-ID: <32810.192.168.0.8.1057170089.squirrel@s> Hi crossfire-devel! I have different characters and sometimes others play on my computer and sometimes I play on different machines. This is rather annoying when the keybindings are wrong. The solution would be to save keybindings for each player on the server. Hmm, dunno if there might be problems/weirdos with different keymaps (us, german, dvorak) or such. The window positions might better be stored on the client machines so they better serve different monitors and screen resolutions. Bernhard _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 2 15:18:06 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:31 2005 Subject: [CF-Devel] save client settings on server In-Reply-To: <32810.192.168.0.8.1057170089.squirrel@s> References: <32810.192.168.0.8.1057170089.squirrel@s> Message-ID: <2075.64.233.58.3.1057177086.squirrel@cgiserver.gazellevillage.com> I actually thought of modifying the server to save keybindings. I chose not to go that route because different machines will have different keybindings. The win32 gtk port that I put up has seperate keybindings for each character. Right now, they are saved in a folder together. This means that if you have a character with the same name on a different server, you'll be using the same keybindings. By rights, all of the character keymappings should be maintained in seperate server folders. I haven't had any time to work on the client, but the source is available if you'd like to take a look at it. :) > Hi crossfire-devel! > > I have different characters and sometimes others play on my computer and > sometimes I play on different machines. This is rather annoying when the > keybindings are wrong. The solution would be to save keybindings for each > player on the server. Hmm, dunno if there might be problems/weirdos with > different keymaps (us, german, dvorak) or such. > > The window positions might better be stored on the client machines so they > better serve different monitors and screen resolutions. > > Bernhard > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > ----------------------------------------- This email was sent using GazelleMail. http://www.gazellevillage.com/ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 3 02:40:33 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:31 2005 Subject: [CF-Devel] save client settings on server In-Reply-To: <2075.64.233.58.3.1057177086.squirrel@cgiserver.gazellevillage.com> References: <32810.192.168.0.8.1057170089.squirrel@s> <2075.64.233.58.3.1057177086.squirrel@cgiserver.gazellevillage.com> Message-ID: <3F03DDF1.2030404@sonic.net> Before the client was seperated into the client, the keybindings were stored as part of the character. However, this has its own problem - start a new character, and you need to re-do all your keybindings. Play on a different server? Redo all your keybindings. And there are certainly platform/keyboard specific problems). Given that I tend not to shift around computers I play on, I may not see as much an issue of tieing keybindings to characters. If you know you are going to play on different computers, the keybindings (and all preferences for that matter) are stored as simple text files, and easy to copy/move about. i really don't like the idea of storing this information on the server/with player file. It adds a bunch of complications, for IMO not a lot of gain. That said, I could certainly see a case to be made to be able to have various configuration/keybinding files (all stored client side), and being able to select the ones you want to use. Thus, you may say 'I want to load by fighter keybindings file' or my 'cleric' file or whatever else (I personally think it also being based on character name would be bad, although perhaps handy just so you don't have to say what binding file to load). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 3 03:44:39 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:31 2005 Subject: [CF-Devel] speculations about the floor (elevation) In-Reply-To: <20030702084412.73221.qmail@web21307.mail.yahoo.com> References: <20030702084412.73221.qmail@web21307.mail.yahoo.com> Message-ID: <3F03ECF7.6030403@sonic.net> Elevation is relative. I'm not sure what they use on Mars as a baseline for example. But I'd also tend to venture that places without atmosphere would have more extreme ranges (no erosion to wear down high peaks/fill in low valleys with sendiment). LOS & elevation: While it may not make a huge difference, it might be noticable. Eg, you get to the top of the mountain and see 12 spaces instead of 2. However, changing this should probably go with a complete LOS revamp (partial blocking, eg, each forest square blocks 1/3'rd your view for your example, so you can see up to 3 forest spaces away, but not farther than that). As far as elevation: I'm not concerned about elevation for worldmaps other people come up with. It is their responsibility to come up with elevation values for that. To follow your example - if you scan in a map of france, presumably you want your elevations to match the real elevation of france. Having calculated values certainly do it - it is up to the map maker to figure out how they fill in that elevation data. Perhaps the biggest issue I have with a per map base elevation is that it really doesn't seem like a good solution - suppose you have a north/south running mountain range. Now suppose you have two tile maps, connected on that vertical seem. The right map is complete mountain range, so should have a good base height. That left map has 5 spaces of mountains along it right edge, going down to hills/forest/plain/ocean (near coastal range). This obviously has a much lower base map height. if I understand your (Todd) plan correctly, the idea here would be that the server/elevation generator runs, sees those discrepencies, and files in the data, so the mountains on the left map aren't 5000' below those on the right because of the base elevation change? I suppose that works. It would, however, seem to create a relatively smooth elevation table (no rolling hills for example). It would also seem difficult in such a situation for the the road that goes through the mountains to be lower (eg, it is going through the pass, and not over the top of the mountains). I unfortunately don't have a great solution to this. I can see the difficulty of keeping the elevation current in the existing world maps. OTOH, doing so would also seem to be one of the easiest solutions - mapmaker then has complete control over elevation of any particular space. Some of this elevation stuff has problems just in the fact of the terrains being played with. One can certainly have forest mountains, forested hills, etc. I think I sort of had the vision of 1 space = 1 mile (obviously, isn't accurate for towns, but if you figure that the 'island' is 1000 or so spaces in diameter, not really far off the mark - I suppose you could increase/decrease that based on your perceived idea of how big th continent is. I mention this in the sense of what type of granularity one may look at. One oculd reasonably expect there to be many more lakes about (a 1 mile diameter lake probably isn't that uncommon). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 3 04:17:53 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:31 2005 Subject: [CF-Devel] speculations about the floor (elevation) In-Reply-To: <3F03ECF7.6030403@sonic.net> Message-ID: On 03-Jul-03 Mark Wedel wrote: > I unfortunately don't have a great solution to this. I can see the > difficulty > of keeping the elevation current in the existing world maps. OTOH, doing so > would also seem to be one of the easiest solutions - mapmaker then has > complete > control over elevation of any particular space. I actually have an idea.. but it would require work on the java editor end. First, if at all possible, the java editor should retain elevation when replacing squares on a map. Just keep the old elevation, nothing fancy. Second. the editor could possibly display the elevation in the square, like have a tiny font "1000" in the upper corner of the square, so you can see at a glance all the elevations. I would assume one would want this to be toggleable. Third, if the editor had a elevation mode, where it simply displayed a color gradient for the various elevations, say slowly rising to 10k being white, it would make it easy to flip to elevation mode, and see the grade of the land. Now.. I say all this, knowing full well I can't implement it.. so AV, if you think this is a good idea, I'd appreciate it, if not.. your call. I know this won't fix all cases, but it should make dealing with elevation a tad easier for most mapmakers, which I assume, use the java editor these days. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 3 09:05:40 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:31 2005 Subject: [CF-Devel] save client settings on server References: <32810.192.168.0.8.1057170089.squirrel@s> <2075.64.233.58.3.1057177086.squirrel@cgiserver.gazellevillage.com> <3F03DDF1.2030404@sonic.net> Message-ID: <000c01c3416c$3042bf60$813ae940@nbcusa.net> The philosophy behind my approach back when I did that port w/ per-character bindings is that the keybindings are, like you pointed out, part of the character. I agree that the keybindings should not be kept on the server since different computers will have different keymappings. The reason I chose to use the character's name as the name for the keybinding was that the character name is unique on each server. The issue that crops up is: what happens when someone uses the SAME character name on other servers? That's why I recommended that anyone who has the time to modify the code to: 1. check to see if a folder with the server name exists if not, create that folder 2. store the character keybindings in that folder under the character's name shouldn't be that hard. Just don't have the time w/ the projects at work. ----- Original Message ----- From: "Mark Wedel" To: Sent: Thursday, July 03, 2003 2:40 AM Subject: Re: [CF-Devel] save client settings on server > > Before the client was seperated into the client, the keybindings were stored > as part of the character. > > However, this has its own problem - start a new character, and you need to > re-do all your keybindings. Play on a different server? Redo all your > keybindings. And there are certainly platform/keyboard specific problems). > > Given that I tend not to shift around computers I play on, I may not see as > much an issue of tieing keybindings to characters. If you know you are going to > play on different computers, the keybindings (and all preferences for that > matter) are stored as simple text files, and easy to copy/move about. > > i really don't like the idea of storing this information on the server/with > player file. It adds a bunch of complications, for IMO not a lot of gain. > > That said, I could certainly see a case to be made to be able to have various > configuration/keybinding files (all stored client side), and being able to > select the ones you want to use. > > Thus, you may say 'I want to load by fighter keybindings file' or my 'cleric' > file or whatever else (I personally think it also being based on character name > would be bad, although perhaps handy just so you don't have to say what binding > file to load). > > > > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 3 11:49:02 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:31 2005 Subject: [CF-Devel] speculations about the floor (elevation) References: Message-ID: <32326.1057250942@www66.gmx.net> Tim Rightnour wrote: > > I actually have an idea.. but it would require work on the > java editor end. > > First, if at all possible, the java editor should retain > elevation when replacing squares on a map. [...] > Second. the editor could possibly display the elevation > in the square [...] > Third, if the editor had a elevation mode, where it simply > displayed a color gradient for the various elevations, [...] > would make it easy [...] Well, my concern about it is that this creates another menu, another GUI - yet another feature that CF mapmakers need to learn, understand and spend their time on. "Fixing" problems in the editor should be seen as a last resort. I'm not convinced that the weather/elevation problem is worth having it's own built-in GUI in the editor. A 50x50 worldmap tile has 2500 squares. Even with a colored heightmap like you suggested, that is a non-trivial amount of work you are asking from mapmakers. All that for rain puddles and snow drifts on the floor? I know that the weather code was meant to have more impact, but there's nothing you couldn't do in a much easier way: Grow random plants? - We can use treasurelists for that. Snow? - Let the mapmaker set it. Weaker fire spells in cold places? - Define it in the map header. Seasonal effects? - Can be global, and defined in the arches. The current approach to weather forces mapmakers to set a lot of elevations, which then get summed up to create more or less random effects. That serves no purpose. Let mapmakers define their own effects directly. That is much easier, faster, better to control, and gets the mapmaker what he really wants. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Jetzt ein- oder umsteigen und USB-Speicheruhr als Pr?mie sichern! _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 3 18:01:44 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:31 2005 Subject: [CF-Devel] speculations about the floor (elevation) In-Reply-To: References: Message-ID: <3F04B5D8.5070407@sonic.net> Tim Rightnour wrote: > > I actually have an idea.. but it would require work on the java editor end. > > First, if at all possible, the java editor should retain elevation when > replacing squares on a map. Just keep the old elevation, nothing fancy. This obviously needs to be toggleable. Eg, if your wiping out a bunch of spaces to replace by something different, you may really not want to keep the old elevation. > > Second. the editor could possibly display the elevation in the square, like > have a tiny font "1000" in the upper corner of the square, so you can see at a > glance all the elevations. I would assume one would want this to be toggleable. Would seem reasonable. > > Third, if the editor had a elevation mode, where it simply displayed a color > gradient for the various elevations, say slowly rising to 10k being white, it > would make it easy to flip to elevation mode, and see the grade of the land. Might be easier to just do simple color ranges than gradiants. I'd presume there is no smoothing, eg, this is an alternate map display, where high squares are simply white, low squares are blue, and other squares have whatever color. Eg, don't try to smooth finer than a square, and even then, maybe just have a dozen colors that show elevation. AV wrote: > Well, my concern about it is that this creates another menu, > another GUI - yet another feature that CF mapmakers need to > learn, understand and spend their time on. IMO, offering more tools is never a bad thing. After all, the editor is really there to make things easier. IMO, the best place for elevation information is in the object, so if we can make it easier to see that information in the editor, that is a good thing. the preserving elevation of a space is a bit of a hack. One could certainly ask where does that lead (do we start preserving other values, etc). While one can certainly make the case that elevation data, and what it is used for, is not great, I think we have to acknowledge that elevation data is there. And if we ignore the weather effects, and say do use it for line of sight, or something else interesting, it would be nice for the editor to support it. Perhaps the easiest, and least controversial of Tim's suggested bits would be the ability to have the elevation displayed on the tile. That at least makes it easy to see what the elevation is, and what spaces are missing elevation. One could load up an older version of the map (before the elevation is clobbered), and then see what they elevations are, what needs to be updated. The storing of elevation is quite a bit trickier, in that now you'd need to shadow those values someplace in the map (not in the object), and also deal with putting it back in when an object is added. And you get trickiness in what happens if there are multiple objects on the space (do you add elevation to all of them?). And thus all operations that make such updates need to be modified. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 3 18:07:54 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:31 2005 Subject: [CF-Devel] save client settings on server In-Reply-To: <000c01c3416c$3042bf60$813ae940@nbcusa.net> References: <32810.192.168.0.8.1057170089.squirrel@s> <2075.64.233.58.3.1057177086.squirrel@cgiserver.gazellevillage.com> <3F03DDF1.2030404@sonic.net> <000c01c3416c$3042bf60$813ae940@nbcusa.net> Message-ID: <3F04B74A.5030403@sonic.net> Yua CaVan wrote: > The philosophy behind my approach back when I did that port w/ per-character > bindings is that the keybindings are, like you pointed out, part of the > character. I agree that the keybindings should not be kept on the server > since different computers will have different keymappings. The reason I > chose to use the character's name as the name for the keybinding was that > the character name is unique on each server. The issue that crops up is: > what happens when someone uses the SAME character name on other servers? > That's why I recommended that anyone who has the time to modify the code to: > 1. check to see if a folder with the server name exists > if not, create that folder > 2. store the character keybindings in that folder under the character's name > > shouldn't be that hard. Just don't have the time w/ the projects at work. Your approach is reasonable. My comment is that often, I'll want to use the same keybindings for different characters of the same general type. Eg, for majors, I'll want to set up the same keybindings for casting spells and whatnot - they'll learn the same spells, and it easier for me to remember that universally, for my wizard characters, that f12 is bound to 'cast fireball'. This is why I was suggesting that not tieing keybindings to characters may be useful - for any wizard, I might want the same keybindings - I may not want to have to set them up again just for the new character. But if you do want one for each character, there is nothing preventing that (my idea would be an option to load keybindings from a file, and save keybindings to a file, so you'd have an unlimited number of choices). With this, one could also set up their generic keybinding file they use for all characters, and then add appropriate keybindings for the character they are playing, and save it to a new file. Perhaps have some option in the editor to 'load keybindings based on character name' or the like so that the player doesn't actually have to explicitly load the keybindings each time. Doing this probably wouldn't be that difficult - just a matter of passing a filename to the dialogue/file selector box. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 3 18:56:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:31 2005 Subject: [CF-Devel] speculations about the floor (elevation) In-Reply-To: <3F04B5D8.5070407@sonic.net> References: <3F04B5D8.5070407@sonic.net> Message-ID: <3F04C2C1.1010303@sympatico.ca> > > Perhaps the easiest, and least controversial of Tim's suggested bits > would be the ability to have the elevation displayed on the tile. > That at least makes it easy to see what the elevation is, and what > spaces are missing elevation. One could load up an older version of > the map (before the elevation is clobbered), and then see what they > elevations are, what needs to be updated. Elevation is already clearly visible in the editor and easily changed, it is just not realistic to modify the values by hand - there can be hundreds or thousands of elevation edits required for even a small change. If the values aren't modified to reflect changes in the map during editing then there is little point in having them. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 3 18:17:57 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:32 2005 Subject: [CF-Devel] speculations about the floor (elevation) In-Reply-To: <3F04B5D8.5070407@sonic.net> Message-ID: On 03-Jul-03 Mark Wedel wrote: >> Third, if the editor had a elevation mode, where it simply displayed a color >> gradient for the various elevations, say slowly rising to 10k being white, >> it >> would make it easy to flip to elevation mode, and see the grade of the land. > > Might be easier to just do simple color ranges than gradiants. I'd presume > there is no smoothing, eg, this is an alternate map display, where high > squares > are simply white, low squares are blue, and other squares have whatever > color. > Eg, don't try to smooth finer than a square, and even then, maybe just have a > dozen colors that show elevation. Basically by gradient, I meant that for values ranging from -5000 to 0, you would go from dark to light blue.. not that the individual tiles be gradiants. And I think AV misunderstood my color bit.. I didn't mean to have a large overview map thing.. All I wanted was a toggle "show elevation" that would show colored squares instead of the tile graphics. The image sizes and whatnot would stay the same, nothing spectacular or complex. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 3 22:26:29 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:32 2005 Subject: [CF-Devel] speculations about the floor (elevation) In-Reply-To: <3F03ECF7.6030403@sonic.net> Message-ID: <20030704032629.18720.qmail@web21302.mail.yahoo.com> --- Mark Wedel wrote: > etc. I think I sort of had the vision of 1 space = 1 mile (obviously, > isn't accurate for towns, but if you figure that the 'island' is 1000 or > so spaces in diameter, not really far off the mark - I suppose you could > increase/decrease that based on your perceived idea of how big th > continent is. The weather code puts the north and south poles at the top left and bottom right corners, with the equator running from the top right to bottom left corners of the big world map. This implies that the 'island' is in fact a major continent taking up most of one side of the planet. While the pole and equator placement where not my idea, I had to think these things through when adding the Coriolis effect to the weather code. Just for fun, I decided to spin the Crossfire planet in the reverse direction to Earth. All these things make for a very strange planet B-). Is making this planet more realistic a priority? I don't think so. I didn't add the Coriolis effect and sea breezes to add realism, but because the weather system produced boring weather. Before I tweaked things, it would always rain in the same places, and mostly near the water. On the other hand, it would be good to make a decision, document it, and stick to it, so that we are all on the same page. As I mentioned before, even the USA is officially metric (since 1866), so I say lets make things metric. Current elevations are within the bounds of reality for a small planet with little tectonic activity if they are in meters. Temperatures are already in metric, as is the air pressure (I think). Given the position of the poles a quick bit of maths says that squares 5km on a side results in a planet about the size of Mars. Do we want a bigger planet or a smaller planet? Smaller can explain why the tops of mountains are impassable wastelands, they are probably above the atmosphere. http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 4 02:44:04 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:32 2005 Subject: [CF-Devel] smoothing code. Message-ID: <3F053044.60805@sonic.net> First, I'd like to thank tchize for updating the protocol to give a better idea on how that code works. I do have some questions/comments. First, is it expected/thought that the smoothing (blending) of tiles is likely to be turned on/off at and object level? this may be more for the mapmakers - do you see cases where you woudl say 'I really don't want this grass tile smoothed with the neighboring tile'. In a sense, this comes up because if the answer is 'not really', then the smoothing attribute could be tied to the face and not object. That could simplify a bunch of things. If there was a case where smoothing was not desired, that would result in a copy of the image however. As a note, I also postulated that such smoothing could be done all in the client. Having the server know something about it may not be all that bad however. I also have some comments about the code as documented: > S->C: smooth ! > All parameters are space separated plain text integers. > This command informs the client on how to smooth a face, when it will > need it. Following are the facenbr of the different pictures involved > in the smoothing algorithm. See doc on smoothing on how to use them. > (TODO) This info may be send automatically from server but could also > be requested by client using the asksmooth The general convention is that S->C communication is done in binary format. This is done for several reasons - it is more efficient cpu wise (easier to pack in integers vs converting to strings), and it is also more efficient bandwidth wise. A lot of C->S communication is string based, not for any particular good reason, but there is a lot less communication in that direction. I'd also like clarification on the comment 'this info may be sent automatically'. It strikes me that either this information will be sent (if some parameters are met, like client has enabled smoothing or whatever, or it won't be sent. In other words, this should really be clarified what the behaviour would be. > C->S: toggleextendedinfos .... > Ask the server to send some additionnal informations about the map. Is there a reason this can't be handled in the setup protocol command that already exists? the current setup options handle all sorts of options, some related to map (size of map, darkness), and other areas (sound, what capabilities the client supports). > S->C: mapextended [data1a][data1b][data1c]... I can understand the need to send the smoothing information someplace (presuming we are wanting the information on the server). However, sending it as an additional/extra block of data to the map command doesn't seem right. To me, the right approach would be to make a 'map2' command to include this. This is for a few reasons. one is efficiency - this mapextended command has a lot of redundant information to the actual map command we send - 2 bytes for the coordinate, and then followed by layering information. If we are on an outdoor map, with say 200 spaces available, this is 400 bytes of redundant information (coordinates). I'd much rather see a map2 command - toss in another byte for other flags (like what layering info is being sent. This gives space for 8 more flags. If when that is filled up, a map3 command could be done. I also am not sure how useful the extensibly of the mapextended command as documented would really be. IT doesn't really match the current communication model, which is 'if the client sends it in a setup command, we will send the data the client wants, and assume it knows how to handle the data'. Thus, having a field saying how large each block is so that the client can skip over it if it doesn't understand seems of marginal usefulness - if the client doesn't understand, we're just wasting resources by sending it to the client. And things can be very extensible by using setup commands and minor variations of the map commands. EG, a map2 command could presumably be written using most of the same code for the map1 and map1a commands. There'd just be a few spots in there for certain checks, like an 'if using map2, add extra flag byte'. And another 'if using map2, and smoothing enabled, set up the smoothing data'. The reason to make a new protocol command (map2) vs just adding extra data to an existing command is simplicity - it is much simpler on the client to do something like 'a map2 command - I know the format of this data' vs a 'map1. Depending on what flags are set, the data could vary widely'. Much easier to also track down bugs. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 4 03:01:13 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:32 2005 Subject: [CF-Devel] speculations about the floor (elevation) In-Reply-To: <3F04C2C1.1010303@sympatico.ca> References: <3F04B5D8.5070407@sonic.net> <3F04C2C1.1010303@sympatico.ca> Message-ID: <3F053449.8020601@sonic.net> Todd wrote: > > Elevation is already clearly visible in the editor and easily changed, > it is just not realistic to modify the values by hand - there can be > hundreds or thousands of elevation edits required for even a small > change. If the values aren't modified to reflect changes in the map > during editing then there is little point in having them. I recall right now you have to click on an object/space to see the elevation, correct? If so, I wouldn't really call that clearly visible. Imagine you want to look at a map and quickly see what the elevation is doing - that's a lot of pain there. Your point of massive map changes is valid. How often is that likely to happen? (honest question). And we are talking about the existing bigworld maps here - if someone scratch builds a new world, that is a different can of worms I'm not trying to solve, and I don't think there is a good way to solve that (I think any automatic elevation generation system is likely to have problems/issues also that would make it less than ideal). But it seems there are two cases here, which are not easy to solve and mostly opposite: 1) I make massive changes, and I want to keep the existing elevation (in which case an elevation backfill script would work just fine). 2) I make massive changes, and all the elevations for the new objects/spaces also need to change, so a backfill script won't work. #1 seems to already be mostly solved, as I believe elevation backfill scripts exist, and if not, it'd be easy to write one. #2 is a bit more effort. To me, filling in the data algorithmicly would be less than ideal. However, one could certainly write something that does that - but if that was done, I'd just as well have it update the objects on the map itself vs writing elevation to yet some other file/location. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 4 12:25:13 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:32 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <3F053044.60805@sonic.net> References: <3F053044.60805@sonic.net> Message-ID: <3F05B879.2010308@sympatico.ca> Is this the transitional graphic set we are going for? This is more akin to the shaggy tile. This appears to be the inverse of single tile smoothing (if your reading this and don't know what I'm talking about you can research in the archives...) than the full transitions proposed by Mark and Tim based on the legendary document. I thought we had decided to go with the larger number of transitions for greater visual appeal. I ask because I am working on some smoothing graphics and don't want to redo them. The reason I ask is because these seem to have the same issues as the 'shaggy tile' scenerio. Also I really want to get the layering sorted out. I understood it that water was to be lowest level then we would work up such as : water -> sand (and desert), marsh, and cobbles (roads) -> grass and swamp -> trees (different types of forest) and hills ->mountain Where more tiles could be added to the appropriate 'layer' as they come on line. This method would allow for the eventual retirement of the river and lake arches, which are a royal pain, with appropriate water arches. Also is there any consideration being given to extending this (leaving the door open anyway?) to do stuff like health/magic auras over top of objects and players or special effects or weather animations? > First, is it expected/thought that the smoothing (blending) of tiles > is likely to be turned on/off at and object level? this may be more > for the mapmakers - do you see cases where you woudl say 'I really > don't want this grass tile smoothed with the neighboring tile'. This is part of leaving the door open no? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 4 12:51:35 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:32 2005 Subject: [CF-Devel] speculations about the floor (elevation) In-Reply-To: <3F053449.8020601@sonic.net> References: <3F04B5D8.5070407@sonic.net> <3F04C2C1.1010303@sympatico.ca> <3F053449.8020601@sonic.net> Message-ID: <3F05BEA7.6060901@sympatico.ca> > I recall right now you have to click on an object/space to see the > elevation, correct? > > If so, I wouldn't really call that clearly visible. Imagine you want > to look at a map and quickly see what the elevation is doing - that's > a lot of pain there. well not so much pain as entering a good value. It isn't having the value that is the issue, it is having a good value. I can't come up with enough good pseudo slopeing numbers for a 10x10 map. Now if you want to do something in the editor, make a elevation fill command where you set the eleavtion for two points and it 'fills' in values on selected squares in between... Even then it will be choppy and unnatural values, but better than some other methods. > > Your point of massive map changes is valid. How often is that likely > to happen? (honest question). And we are talking about the existing > bigworld maps here - if someone scratch builds a new world, that is a > different can of worms I'm not trying to solve, and I don't think > there is a good way to solve that (I think any automatic elevation > generation system is likely to have problems/issues also that would > make it less than ideal). > Often. Almost any change to the worldmap (and it's empty right now...) I've done it a few times in the last few months since I seem to be the only one making the attempt. The change does not have to be that large at all to cause a large number of changes - adding a small town or a road of any length or a lake or cutting away at a bit of mountain happens all the time and is a royal pain to fix the elevation. I have used the backfil script when the changes didnt really *have to* address the elevation (re-arranging hills and forest a bit adding of swamp, although I wonder aboutthe swamp) and I wrote a script that would assign likely ranges when the changes were entirely elevation specific (Andy's mountains arounf Brest, adding a lake, mountains around Scorn...). Both ways are not really sustainable for reasons I have mentioned. What good is having the weahter code look up the elevation if the value has no relation to the map (like if you add some lakes to a mountain but do not smoooth out the lake elevation or if you change so9me ocean to an island). Retaining the existing elevaiotn is usually pointless except for the most minor changes (even roads should be smoother then surrounding areas). This is double if you start talking about using elevaition for LOS or other game value. I agree that how it is generated (initailly or ongoing) is really a seperate issue than how it is stored. One thing that just keeps coming back to me (the more I read too...) however is that elevation can still be *in* an object even if it is stored in a seperate file... I just thought if it was in a seperate file it would be easier to slice, dice, generate or ignore. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 4 16:30:43 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:32 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <3F05B879.2010308@sympatico.ca> References: <3F053044.60805@sonic.net> <3F05B879.2010308@sympatico.ca> Message-ID: <3F05F203.4070202@sonic.net> Todd wrote: > Is this the transitional graphic set we are going for? This is more > akin to the shaggy tile. This appears to be the inverse of single tile > smoothing (if your reading this and don't know what I'm talking about > you can research in the archives...) than the full transitions proposed > by Mark and Tim based on the legendary document. I thought we had > decided to go with the larger number of transitions for greater visual > appeal. I ask because I am working on some smoothing graphics and don't > want to redo them. > The reason I ask is because these seem to have the same issues as the > 'shaggy tile' scenerio. I agree. A URL tchize sent me on some examples is http://users.skynet.be/am248983/smooth/index.html. To me, the only one that would need improvement is the corners (L shaped pieces). Look at: http://www.gamedev.net/reference/articles/article934.asp What is missing is the U (tile around 3 sides) and L (tiles along to adjacent edges). Its unclear to me right now how those are handled with the current tiles - my only guess is that they are layered on top, but that certainly isn't as good as a properly drawn L or U (ore so because in the L and U, you probably want to curve in the corner more than for just a simple side). > > Also I really want to get the layering sorted out. I understood it that > water was to be lowest level then we would work up such as : > water -> sand (and desert), marsh, and cobbles (roads) -> grass and > swamp -> trees (different types of forest) and hills ->mountain > > Where more tiles could be added to the appropriate 'layer' as they come > on line. I think as tchize did it, there is a single byte for what layer something is on. This is probably overkill, but does make things easy - if you space things out (water = 0, grass = 10, tree = 20, hills = 30, mountain = 40 for example), that leaves a lot of space if you get into a case of 'I need to make a layer between hill and trees'. Put that in at 25, and you're all set, and still have room in case something needs to be put between your new object and the hill. > > This method would allow for the eventual retirement of the river and > lake arches, which are a royal pain, with appropriate water arches. River I think will always be tricky - if you want to run a diagonal river, I'm not sure you could ever really do it without special archs. I think putting a line of single space water arch's diagonally would result in a bunch of small lakes/ponds. And if you something like: RR RR RR RR I think with the blending you'd get a river that seems to snake a lot, simply because there isn't a straigh diagonal that would get used for blending - even if real L shapes are done, that still curves. > > Also is there any consideration being given to extending this (leaving > the door open anyway?) to do stuff like health/magic auras over top of > objects and players or special effects or weather animations? It's just a simple matter of extending the protocol/making a new map command. This isn't really hard. It is very difficult to predict what information may need to be sent. Adding on/making new map commands isn't a big deal - the old one still exists in the server, so old clients work. New clients just ask to use the new command with better features. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 4 16:43:15 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:32 2005 Subject: [CF-Devel] speculations about the floor (elevation) In-Reply-To: <20030704032629.18720.qmail@web21302.mail.yahoo.com> References: <20030704032629.18720.qmail@web21302.mail.yahoo.com> Message-ID: <3F05F4F3.5070208@sonic.net> David Seikel wrote: > The weather code puts the north and south poles at the top left and bottom > right corners, with the equator running from the top right to bottom left > corners of the big world map. This implies that the 'island' is in fact a > major continent taking up most of one side of the planet. While the pole > and equator placement where not my idea, I had to think these things > through when adding the Coriolis effect to the weather code. Just for fun, > I decided to spin the Crossfire planet in the reverse direction to Earth. I was never really happy with the north and south poles being at the corners. IT just isn't that intuitive. I can understand the reason (want the poles to be relative small areas). but I also wonder if the map as given should be seen as covering the entire world, or just some part of it (eg, one of the continents in the northern hemisphere, for example, such that the equator is near the south edge of the map, and the north pole would effectively be a few hundred spaces still farther to the north) > On the other hand, it would be good to make a decision, document it, and > stick to it, so that we are all on the same page. As I mentioned before, > even the USA is officially metric (since 1866), so I say lets make things > metric. Current elevations are within the bounds of reality for a small > planet with little tectonic activity if they are in meters. Temperatures > are already in metric, as is the air pressure (I think). Would metric actually increase the effective elevations? Eg, that 'elevation 12000' mountain would now be 36000 feet (about), meaning we have a bunch of really tall peaks. > > Given the position of the poles a quick bit of maths says that squares 5km > on a side results in a planet about the size of Mars. Do we want a bigger > planet or a smaller planet? Smaller can explain why the tops of mountains > are impassable wastelands, they are probably above the atmosphere. As said, I never envisioned when making the continent that it would be an entire hemisphere, rather, it is just part of something bigger. I suppose when the north and south poles were added, that added to the idea that it was an entire hemisphere, but I didn't do that bit :) Do I expect new continents to be added? Not really. However, when putting down the towns/roads, I did put up signs which basically amounted to 1 space = 1 mile (eg, scorn, 764 miles north or something). One could obviously make the case that a crossfire mile isn't the same as a human mile. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 4 17:17:40 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:32 2005 Subject: [CF-Devel] speculations about the floor (elevation) In-Reply-To: <3F05BEA7.6060901@sympatico.ca> References: <3F04B5D8.5070407@sonic.net> <3F04C2C1.1010303@sympatico.ca> <3F053449.8020601@sonic.net> <3F05BEA7.6060901@sympatico.ca> Message-ID: <3F05FD04.1030607@sonic.net> Todd wrote: > well not so much pain as entering a good value. It isn't having the > value that is the issue, it is having a good value. I can't come up > with enough good pseudo slopeing numbers for a 10x10 map. Now if you > want to do something in the editor, make a elevation fill command where > you set the eleavtion for two points and it 'fills' in values on > selected squares in between... Even then it will be choppy and > unnatural values, but better than some other methods. > It may be a little easier for some of those. But extracting elevation from the maps wouldn't be hard. Ignoring data, no matter where it comes from, is quite easy. I'd think as far as the server is concerned, having it in the object is simpler, because this now isn't a seperate file that needs to get loaded. One disadvantage of seperate files is a greater likelihood of it getting out of date. Eg, user modifies a map, even going so far as to update elevations, but doesn't run the appropriate commands or whatever to cause that other file to get updated information. This is one reason I like the idea of keeping it with the object/map - no such issues, and just seems simpler. I guess one thing I'm still trying to understand is exactly what needs to be done to fix this. Preserving elevation doesn't seem to be the answer, because big changes mean the objects elevations would change. Perhaps a script that does the following, either: 1) Backfills elevation for spaces that have zero elevation. 2) Calculates elevation for spaces that have zero elevation. Option #2 could be relatively primitive, eg, I have a line of spaces with zero elevation - I'll take the two spaces to either side, average them, and then adjust the elevation of this space by ?10% (or whatever), just so big fills aren't perfectly smooth. Maybe a third option that that fills in elevations based on expected elevations of the arch, so that in the case of adding a bunch of high peaks, those get filled in appropriately. Although, at a some point, I wonder why dont' we jsut add some default elevations to some of these objects in the archetypes. The automated fills don't have to be perfect - and in fact, I think it would be impossible to make it so that they are perfect. Rather, make them good enough to cover the big cases. There will always be cases that come up which can't easily be done by automation and still get good results. In those cases, hand updates should be done. Just as the existing world was computer generated, it is getting improved upon by hand edits. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 4 17:56:07 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:32 2005 Subject: [CF-Devel] speculations about the floor (elevation) References: <3F04B5D8.5070407@sonic.net> Message-ID: <28634.1057359367@www9.gmx.net> Mark Wedel wrote: > > While one can certainly make the case that elevation data, > and what it is used for, is not great, I think we have to > acknowledge that elevation data is there. And if we ignore > the weather effects, and say do use it for line of sight, or > something else interesting, it would be nice for the editor > to support it. I don't like the argument "it exists", because it supports those who put code on CVS without asking. If we want to get somewhere, it shoud be as easy to fix something broken, as it is adding a broken feature. Let's talk about the LOS code with elevations then. Our maps are flat, players don't see elevations and they are not going to understand them. Imagine a player standing on a large field of grass. Do you think he will understand why he can see to the left but can't see to the right? - No he won't. Instead of thinking "wow I'm on top of a mountain", he will much more likely think: "wow the LOS code is broken". Apart from the fact that elevations don't make sense on a flat map, let's face it: They are nothing better than a bunch of random values. And the maintenance problem will make it even worse. What good can you do with such values? Take the example of growing random plants based on weather, which boils down on elevation and water. This may sound tremendously exciting, but chances are high that the most rare plants grow right next to scorn. - Because you have no control over the system. There's no "greater meaning" behind it. IMO it is not fair when mapakers have to set thousands of values, just because someone thought it is cool, or "there may be plans for it". AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Jetzt ein- oder umsteigen und USB-Speicheruhr als Pr?mie sichern! _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 5 01:27:37 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:32 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <3F05F203.4070202@sonic.net> Message-ID: On 04-Jul-03 Mark Wedel wrote: > What is missing is the U (tile around 3 sides) and L (tiles along to > adjacent > edges). Its unclear to me right now how those are handled with the current > tiles - my only guess is that they are layered on top, but that certainly > isn't > as good as a properly drawn L or U (ore so because in the L and U, you > probably > want to curve in the corner more than for just a simple side). > Agreed. I think part of the problem is that the smoothing tiles tchize provided in the example images, just aren't that great to be honest. It could be that what we are seeing is simply that the poor quality of the smoothing tiles make it look worse than it really is. It's too regular and blocky.. I'd want to see his code with some quality tiles before I really judged it. I agree that it won't look as good as properly done U corners.. but how hard would it be to extend it to provide U's? >> >> Also I really want to get the layering sorted out. I understood it that >> water was to be lowest level then we would work up such as : >> water -> sand (and desert), marsh, and cobbles (roads) -> grass and >> swamp -> trees (different types of forest) and hills ->mountain >> >> Where more tiles could be added to the appropriate 'layer' as they come >> on line. IMHO this is the wrong order. The road should be almost at the bottom, as everything should overgrow roads. I say swamp just above road, because I would think that the swamp would encroach. Keeping the roads from looking blocky should be the most important. Also, one could theoretically work inside each of these, for example, transitions on the roads could lead to where the road goes from yellow to gray, having an assortment of cobbles, fading the edge out. Just looking at the weather right now.. here is what I would do, changes would probably need to be made to this for the bigtrees too. This is just off the top of my head.. so some tweaking might be in order. water road swamp deep_swamp desert dunes stone browngrass browngreengrass grass grassmedium grassdark brush evergreens fernssparse forestsparse fernsdense woods4 woods5 steppelight steppe hills hills_rocky mountain mountain2 mountain4 mountain5 --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 5 07:59:13 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:32 2005 Subject: [CF-Devel] CVS problems. Message-ID: <20030705125913.59759.qmail@web21305.mail.yahoo.com> As suggested, I've been trying to checkout the CVS version of crossfire. Sourceforge keeps timing out during the login. Is there any other CVS server that could be used from behind a firewall? http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 5 10:02:47 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:32 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <3F053044.60805@sonic.net> References: <3F053044.60805@sonic.net> Message-ID: <200307051702.57672.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 4 Juillet 2003 09:44, Mark Wedel a ?crit : > First, I'd like to thank tchize for updating the protocol to give a > better idea on how that code works. > > I do have some questions/comments. > > First, is it expected/thought that the smoothing (blending) of tiles is > likely to be turned on/off at and object level? this may be more for the > mapmakers - do you see cases where you woudl say 'I really don't want this > grass tile smoothed with the neighboring tile'. it' controlled a object level ot know the 'smoothing level' of an object. If you don't want a particular grass (let's say you want a map with extremly strict separation betwee the road an the map, cause there are a lot of gardeners working at this (eg: a castle)), simply lower it's smoothlevel to 0 (will smooth on nothing) at the object level. So mapmaker have control on smoothing. > > In a sense, this comes up because if the answer is 'not really', then the > smoothing attribute could be tied to the face and not object. That could > simplify a bunch of things. If there was a case where smoothing was not > desired, that would result in a copy of the image however. > > As a note, I also postulated that such smoothing could be done all in the > client. Having the server know something about it may not be all that bad > however. I first tried only client side, but dropeed 6 months ago. too manny issues to resolve, no control for mapmakers, difficulties for having 'names' associated with images under certain configuration. The client server protocol extension is still the cleanest way. > > I also have some comments about the code as documented: > > S->C: smooth > > ! All parameters are space separated plain text integers. > > This command informs the client on how to smooth a face, when it > > will need it. Following are the facenbr of the different pictures > > involved in the smoothing algorithm. See doc on smoothing on how to use > > them. (TODO) This info may be send automatically from server but could > > also be requested by client using the asksmooth > > The general convention is that S->C communication is done in binary > format. This is done for several reasons - it is more efficient cpu wise > (easier to pack in integers vs converting to strings), and it is also more > efficient bandwidth wise. A lot of C->S communication is string based, not > for any particular good reason, but there is a lot less communication in > that direction. I understand this is a bad choice for the protocol. Am sorry. But this command is not frequent (like images, server keep a list of smoothing sequences already send to client, for now ther are only 6 smoothing sequences i think) and the client/server have already been updated in cvs, i could switch to binary form if you agree to break client / server which have been checked out during the past few day when this was not binary. > > I'd also like clarification on the comment 'this info may be sent > automatically'. It strikes me that either this information will be sent > (if some parameters are met, like client has enabled smoothing or whatever, > or it won't be sent. In other words, this should really be clarified what > the behaviour would be. > Like for images, if client asked the smoothing from server, server will send the smoothing sequence when this is a new one for client and this sequence is visible in the current map. So this work of sending is done automatically when sending the mapextend command to client. > > C->S: toggleextendedinfos .... > > Ask the server to send some additionnal informations about the > > map. > > > > Is there a reason this can't be handled in the setup protocol command > that already exists? the current setup options handle all sorts of > options, some related to map (size of map, darkness), and other areas > (sound, what capabilities the client supports). see coment on mapextended below before reading this part. This help separate things. Since a lot of infos may be, in the future, associated with map coordinates, this command tells the client what in the map coordinates it want. And it also respond by telling what actually are the options activated. Thought it simply easier to handle. > > > S->C: mapextended > > [data1a][data1b][data1c]... > > > > I can understand the need to send the smoothing information someplace > (presuming we are wanting the information on the server). > > However, sending it as an additional/extra block of data to the map > command doesn't seem right. To me, the right approach would be to make a > 'map2' command to include this. > > This is for a few reasons. one is efficiency - this mapextended command > has a lot of redundant information to the actual map command we send - 2 > bytes for the coordinate, and then followed by layering information. If we > are on an outdoor map, with say 200 spaces available, this is 400 bytes of > redundant information (coordinates). > > I'd much rather see a map2 command - toss in another byte for other flags > (like what layering info is being sent. This gives space for 8 more flags. > If when that is filled up, a map3 command could be done. > > I also am not sure how useful the extensibly of the mapextended command > as documented would really be. mapextended will contain, in the end, a lot of informations. This command has been developped so it is easily extendable without breaking the clients and / or old server. For now this contains only smoothing. Work will be done next so when text message are used, for example from NPC, they will be send according to the location. Moreover, the bit fields at the begin of command allow, from case to case, the server to send only a small part of the info. (eg, if a nps speak, no need to send smoothing infos with the localized text). When i decided to send smoothing informations, i saw all those different map commands. And i though if we have to add commands, or use tricky code to upgrade old commands each time we need to send other informations related to the map from the server to the client, think will get even worse. So i prefered to create from zero a new command which is extensible. However, in the near future, nothing prevents from having a command from client to server saying the server we prefer the 'classical' map informations to be send with mapextended and not map2 or map2a. Moreover, i need to > > IT doesn't really match the current communication model, which is 'if the > client sends it in a setup command, we will send the data the client wants, > and assume it knows how to handle the data'. Thus, having a field saying > how large each block is so that the client can skip over it if it doesn't > understand seems of marginal usefulness - if the client doesn't understand, > we're just wasting resources by sending it to the client. The fact is some datas may perhaps, in the future, variate in size. let's say i want to tell the client a NPC said 'Hello' at coordinates dx,dy. I could send a packet from server, with only the 'TEXT' flag (which doesn't exist for now, but will exist in future, i hope) and size helping know length of text. Moreover, server may send additionnal informations the client doesn't know about, without having to take care 'may i put those 4 additionnal bits inside the packet?' 'is the client using the old 1 byte or the new 2 byte ways of sending smoothing?' etc. The server knows in advance the client will skip what it doesn't understand, while still reading what he does understand. This could help a lot, IMO, in the future the readability of server code > > And things can be very extensible by using setup commands and minor > variations of the map commands. EG, a map2 command could presumably be > written using most of the same code for the map1 and map1a commands. > There'd just be a few spots in there for certain checks, like an 'if using > map2, add extra flag byte'. And another 'if using map2, and smoothing > enabled, set up the smoothing data'. brings up tricky code, and doesn't help in all case, see above. > > The reason to make a new protocol command (map2) vs just adding extra > data to an existing command is simplicity - it is much simpler on the > client to do something like 'a map2 command - I know the format of this > data' vs a 'map1. Depending on what flags are set, the data could vary > widely'. Much easier to also track down bugs. see mapextended as a map2 command with more future extensibility without the pain of handling 'old cases' in the server and guessing eveyrtime what the version of client is. > > > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/BuieHHGOa1Q2wXwRAupyAKDhVBG85rCbqFxXu3UXWi6BuTXGTwCg6TPs 527//f/PmZ936UCSkOtllv4= =wd+k -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 5 10:24:45 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:33 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <3F05B879.2010308@sympatico.ca> References: <3F053044.60805@sonic.net> <3F05B879.2010308@sympatico.ca> Message-ID: <200307051725.02621.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 4 Juillet 2003 19:25, Todd a ?crit : > Is this the transitional graphic set we are going for? This is more > akin to the shaggy tile. This appears to be the inverse of single tile > smoothing (if your reading this and don't know what I'm talking about > you can research in the archives...) than the full transitions proposed > by Mark and Tim based on the legendary document. I thought we had > decided to go with the larger number of transitions for greater visual > appeal. I ask because I am working on some smoothing graphics and don't > want to redo them. As far has i remember those document (about way to make a tiled game appear more untiled). The article was speaking about a way, using 8 different pictures, to smooth all cases. I haven't yet made the doc on smoothing (sorry). But some basic infos can be reached at the following address: http://users.skynet.be/am248983/smooth/index.html Or you are speaking of another discussion so i'l be gald to have references since doesn't have all cf-devel mails here and mailman web page doesn't allow searching. > The reason I ask is because these seem to have the same issues as the > 'shaggy tile' scenerio. ? Well if ther is a problem i didn't think about, we can still change the way things work, the code is fresh and not well spread. > > Also I really want to get the layering sorted out. I understood it that > water was to be lowest level then we would work up such as : > water -> sand (and desert), marsh, and cobbles (roads) -> grass and > swamp -> trees (different types of forest) and hills ->mountain Well the order you show is the natural 'altitude' order. However, for graphical reasons, i think the order shouldn't be done according to altitude. Even if it's natural to see moutains over grass or forest, it is unnatural to see grass or see grow over the sea :) so the order is suggest, using your case would be something like: roads at the bottom (case roads are straight and it's unnatural to see a paved road over the sea or a swamp or perhaps natural over a swamp, need to see what this give graphically) then grass then sand and deserts, than hills, mountains, and then forest. Cause, ther may be a small tree about the border of a mountain, but it's stupid to think it would look ok if a mountain was to cover half-trees in a forest. > > Where more tiles could be added to the appropriate 'layer' as they come > on line. > > This method would allow for the eventual retirement of the river and > lake arches, which are a royal pain, with appropriate water arches. > Are they a pain? I can't see a good way to remove thsi case, axcept at the 'corners' (you see when you have a diagonal and need to put thos 2 ugly little things at the corner. Those 2 litlle things could be take off and replaced by smoothing. But don't except the code to allow thing like transforming roads in the bigworld to straight line of 3 or 17 ? inclinaision. Smoothing works locally by altering the tiles next to the smoothed tile. No durther, no line or curves interpolations. > Also is there any consideration being given to extending this (leaving > the door open anyway?) to do stuff like health/magic auras over top of > objects and players or special effects or weather animations? Right, code in the protocol was made to allow thing like localized special effects or a like. I planned to replace the auras with a bueatifull client side drawed aura. with transparency and so on. Some people talke about rain falls and snow falls. This is also possible. > > > First, is it expected/thought that the smoothing (blending) of tiles > > is likely to be turned on/off at and object level? this may be more > > for the mapmakers - do you see cases where you woudl say 'I really > > don't want this grass tile smoothed with the neighboring tile'. > > This is part of leaving the door open no? The door is not open. The room behind it is already build :) since it's already the case. - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD4DBQE/Bu3JHHGOa1Q2wXwRAtv0AJiiDqdrDK5ZqBvXrMBZjP82NrwMAKCbGq61 2WLKRr6tWomx48+BQ4fEaQ== =WkR9 -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 5 10:42:34 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:33 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <3F05F203.4070202@sonic.net> References: <3F053044.60805@sonic.net> <3F05B879.2010308@sympatico.ca> <3F05F203.4070202@sonic.net> Message-ID: <200307051738.20423.d.delbecq@laposte.net> Le Vendredi 4 Juillet 2003 23:30, Mark Wedel a ?crit : > Todd wrote: > > Is this the transitional graphic set we are going for? This is more > > akin to the shaggy tile. This appears to be the inverse of single tile > > smoothing (if your reading this and don't know what I'm talking about > > you can research in the archives...) than the full transitions proposed > > by Mark and Tim based on the legendary document. I thought we had > > decided to go with the larger number of transitions for greater visual > > appeal. I ask because I am working on some smoothing graphics and don't > > want to redo them. > > The reason I ask is because these seem to have the same issues as the > > 'shaggy tile' scenerio. > > I agree. A URL tchize sent me on some examples is > http://users.skynet.be/am248983/smooth/index.html. > > To me, the only one that would need improvement is the corners (L shaped > pieces). Look at: > http://www.gamedev.net/reference/articles/article934.asp > > What is missing is the U (tile around 3 sides) and L (tiles along to > adjacent edges). Its unclear to me right now how those are handled with > the current tiles - my only guess is that they are layered on top, but that > certainly isn't as good as a properly drawn L or U (ore so because in the L > and U, you probably want to curve in the corner more than for just a simple > side). For now, a L shaped border is handled like this divide you destination picture in 4 the uperleft part is made of the upertleft part the 'left I' case the upperight part is made of the uperright part of the 'nothing' case the bottomleft part is made of the bottomleft part of the 'O' case the bottomright part is made of the bottomright part of the '=' case This all limit needs for drawing to 8 pictures. I did this choice cause, when you look at "Figure 4: Artifact Grassland Transitions" on gamedev, you'll see most pictures share some parts. I didn't think about the possibility, in L shaped case, people might want to convert to a straight line. I wanted to save time from pictures drawers. However, th? 32 pictures case presented seems better. If the crossfire gfxers are ready to do the 32 pictures for each transition, am ready to convert the code to use the Cases shown in document. > > > Also I really want to get the layering sorted out. I understood it that > > water was to be lowest level then we would work up such as : > > water -> sand (and desert), marsh, and cobbles (roads) -> grass and > > swamp -> trees (different types of forest) and hills ->mountain > > > > Where more tiles could be added to the appropriate 'layer' as they come > > on line. > > I think as tchize did it, there is a single byte for what layer something > is on. This is probably overkill, but does make things easy - if you space > things out (water = 0, grass = 10, tree = 20, hills = 30, mountain = 40 for > example), that leaves a lot of space if you get into a case of 'I need to > make a layer between hill and trees'. Put that in at 25, and you're all > set, and still have room in case something needs to be put between your new > object and the hill. > > > This method would allow for the eventual retirement of the river and > > lake arches, which are a royal pain, with appropriate water arches. > > River I think will always be tricky - if you want to run a diagonal > river, I'm not sure you could ever really do it without special archs. I > think putting a line of single space water arch's diagonally would result > in a bunch of small lakes/ponds. And if you something like: > > RR > RR > RR > RR > > I think with the blending you'd get a river that seems to snake a lot, > simply because there isn't a straigh diagonal that would get used for > blending - even if real L shapes are done, that still curves. > > > Also is there any consideration being given to extending this (leaving > > the door open anyway?) to do stuff like health/magic auras over top of > > objects and players or special effects or weather animations? > > It's just a simple matter of extending the protocol/making a new map > command. This isn't really hard. It is very difficult to predict what > information may need to be sent. Adding on/making new map commands isn't a > big deal - the old one still exists in the server, so old clients work. > New clients just ask to use the new command with better features. > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 5 10:45:46 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:33 2005 Subject: [CF-Devel] CVS problems. In-Reply-To: <20030705125913.59759.qmail@web21305.mail.yahoo.com> References: <20030705125913.59759.qmail@web21305.mail.yahoo.com> Message-ID: <200307051745.46165.tchize@myrealbox.com> Le Samedi 5 Juillet 2003 14:59, David Seikel a ?crit : > As suggested, I've been trying to checkout the CVS version of crossfire. > Sourceforge keeps timing out during the login. Is there any other CVS > server that could be used from behind a firewall? > > > http://mobile.yahoo.com.au - Yahoo! Mobile > - Check & compose your email via SMS on your Telstra or Vodafone mobile. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel MM dunno if it's you firewall. If you used anonymous login, be aware that the sourceforge cvs is under heavy loads and anonymous connection are dropped for now (seems to be for allowing comfortable access to developper). This has nothing to do with crossfire, rather with sourceforge, who is waiting for new hardware. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 5 10:38:20 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:33 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <3F05F203.4070202@sonic.net> References: <3F053044.60805@sonic.net> <3F05B879.2010308@sympatico.ca> <3F05F203.4070202@sonic.net> Message-ID: <200307051738.20423.d.delbecq@laposte.net> Le Vendredi 4 Juillet 2003 23:30, Mark Wedel a ?crit : > Todd wrote: > > Is this the transitional graphic set we are going for? This is more > > akin to the shaggy tile. This appears to be the inverse of single tile > > smoothing (if your reading this and don't know what I'm talking about > > you can research in the archives...) than the full transitions proposed > > by Mark and Tim based on the legendary document. I thought we had > > decided to go with the larger number of transitions for greater visual > > appeal. I ask because I am working on some smoothing graphics and don't > > want to redo them. > > The reason I ask is because these seem to have the same issues as the > > 'shaggy tile' scenerio. > > I agree. A URL tchize sent me on some examples is > http://users.skynet.be/am248983/smooth/index.html. > > To me, the only one that would need improvement is the corners (L shaped > pieces). Look at: > http://www.gamedev.net/reference/articles/article934.asp > > What is missing is the U (tile around 3 sides) and L (tiles along to > adjacent edges). Its unclear to me right now how those are handled with > the current tiles - my only guess is that they are layered on top, but that > certainly isn't as good as a properly drawn L or U (ore so because in the L > and U, you probably want to curve in the corner more than for just a simple > side). For now, a L shaped border is handled like this divide you destination picture in 4 the uperleft part is made of the upertleft part the 'left I' case the upperight part is made of the uperright part of the 'nothing' case the bottomleft part is made of the bottomleft part of the 'O' case the bottomright part is made of the bottomright part of the '=' case This all limit needs for drawing to 8 pictures. I did this choice cause, when you look at "Figure 4: Artifact Grassland Transitions" on gamedev, you'll see most pictures share some parts. I didn't think about the possibility, in L shaped case, people might want to convert to a straight line. I wanted to save time from pictures drawers. However, th? 32 pictures case presented seems better. If the crossfire gfxers are ready to do the 32 pictures for each transition, am ready to convert the code to use the Cases shown in document. > > > Also I really want to get the layering sorted out. I understood it that > > water was to be lowest level then we would work up such as : > > water -> sand (and desert), marsh, and cobbles (roads) -> grass and > > swamp -> trees (different types of forest) and hills ->mountain > > > > Where more tiles could be added to the appropriate 'layer' as they come > > on line. > > I think as tchize did it, there is a single byte for what layer something > is on. This is probably overkill, but does make things easy - if you space > things out (water = 0, grass = 10, tree = 20, hills = 30, mountain = 40 for > example), that leaves a lot of space if you get into a case of 'I need to > make a layer between hill and trees'. Put that in at 25, and you're all > set, and still have room in case something needs to be put between your new > object and the hill. > > > This method would allow for the eventual retirement of the river and > > lake arches, which are a royal pain, with appropriate water arches. > > River I think will always be tricky - if you want to run a diagonal > river, I'm not sure you could ever really do it without special archs. I > think putting a line of single space water arch's diagonally would result > in a bunch of small lakes/ponds. And if you something like: > > RR > RR > RR > RR > > I think with the blending you'd get a river that seems to snake a lot, > simply because there isn't a straigh diagonal that would get used for > blending - even if real L shapes are done, that still curves. > > > Also is there any consideration being given to extending this (leaving > > the door open anyway?) to do stuff like health/magic auras over top of > > objects and players or special effects or weather animations? > > It's just a simple matter of extending the protocol/making a new map > command. This isn't really hard. It is very difficult to predict what > information may need to be sent. Adding on/making new map commands isn't a > big deal - the old one still exists in the server, so old clients work. > New clients just ask to use the new command with better features. > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 6 00:13:10 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:33 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <200307051738.20423.d.delbecq@laposte.net> References: <3F053044.60805@sonic.net> <3F05B879.2010308@sympatico.ca> <3F05F203.4070202@sonic.net> <200307051738.20423.d.delbecq@laposte.net> Message-ID: <3F07AFE6.8030100@sonic.net> tchize wrote: > Le Vendredi 4 Juillet 2003 23:30, Mark Wedel a ?crit : > > divide you destination picture in 4 > the uperleft part is made of the upertleft part the 'left I' case > the upperight part is made of the uperright part of the 'nothing' case > the bottomleft part is made of the bottomleft part of the 'O' case > the bottomright part is made of the bottomright part of the '=' case > This all limit needs for drawing to 8 pictures. I did this choice cause, > when you look at "Figure 4: Artifact Grassland Transitions" on gamedev, > you'll see most pictures share some parts. I didn't think about the > possibility, in L shaped case, people might want to convert to a straight > line. I wanted to save time from pictures drawers. However, th? 32 pictures > case presented seems better. If the crossfire gfxers are ready to do the 32 > pictures for each transition, am ready to convert the code to use the Cases > shown in document. Note that it really isn't 32 more images. From the gamedev article (http://www.gamedev.net/reference/articles/article934.asp), the bottom 16 images are already done (single corners). And 8 of the top 16 images are already there. So that is really 8 images that woudl need to be added (4 L's and 4 U's). Even if those aren't done immediately, I really think support for them should be added, as people are bound to want to draw such images at some point. I also wonder if instead of having a bunch of seperate images for each tile if it would be easier to instead have 1 larger smoothing tile of a set layout, and the client just copies the bits over it needs. This reduces overhead a little bit - presumably, if the client is going to need one smoothing tile for a terrain, it is likely it will need all the combos. The one problem I have with the existing graphics, is that they don't really have any curves. When I look at the examples you have on your web page, things don't look a lot smoother - the grass still has pretty much straight lines - they just spill over a little into the neighboring spaces. This may be a fault of the graphics - if you look at the gamedev article, it seems the simple cases of the straight lines which are not through lines (eg, one of your 001 cases) that the graphic has a more pronounced bow show to the overlapping terrain. But that is just the typical matter of improving graphics. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 6 01:06:14 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:33 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <200307051702.57672.tchize@myrealbox.com> References: <3F053044.60805@sonic.net> <200307051702.57672.tchize@myrealbox.com> Message-ID: <3F07BC56.2090909@sonic.net> tchize wrote: > > I first tried only client side, but dropeed 6 months ago. too manny issues to > resolve, no control for mapmakers, difficulties for having 'names' associated > with images under certain configuration. The client server protocol extension > is still the cleanest way. Ok. Fair enough. >>>S->C: smooth > > I understand this is a bad choice for the protocol. Am sorry. But this > command is not frequent (like images, server keep a list of smoothing > sequences already send to client, for now ther are only 6 smoothing sequences > i think) and the client/server have already been updated in cvs, i could > switch to binary form if you agree to break client / server which have been > checked out during the past few day when this was not binary. This is of course one of the reasons that changes should be discussed/posted prior to committing. Given how recently this was put in, and the fact no official release have been made, I'd say update this and potentially break backwards compatibility. Alternatively, this could be replaced/enabled by a different request command, so that the command is at least different. > > Like for images, if client asked the smoothing from server, server > will send the smoothing sequence when this is a new one for client > and this sequence is visible in the current map. So this work > of sending is done automatically when sending the mapextend command to client. Ok. I'd just write that into the protocol, like 'the server with send a smooth command the first time a smooth graphic is sent to the client if the client wants smoothing information'. > > > >>>C->S: toggleextendedinfos .... >>> Ask the server to send some additionnal informations about the >>>map. > see coment on mapextended below before reading this part. > This help separate things. Since a lot of infos may be, in the future, > associated with map coordinates, this command tells the client what > in the map coordinates it want. And it also respond by telling > what actually are the options activated. Thought it simply easier to handle. It really seems this is just a setup command, just more related to map data. The setup command returns the value that the server will be used, so that bit doesn't seem a lot different. It seems that setup, combined perhaps with requestinfo, would cover whatever mapextended woudl be. Since the setup command already covers a wide range of possible options, I just don't see the need for this command. If perhaps there are some specific examples of what this command would do that can't be done with setup/requestinfo, that is a different matter. I just don't really see that right now. > mapextended will contain, in the end, a lot of informations. This command has > been developped so it is easily extendable without breaking the clients and / > or old server. For now this contains only smoothing. Work will be done > next so when text message are used, for example from NPC, they will > be send according to the location. Moreover, the bit fields at the begin of > command allow, from case to case, the server to send only a small part > of the info. (eg, if a nps speak, no need to send smoothing infos > with the localized text). > When i decided to send smoothing informations, i saw all those different > map commands. And i though if we have to add commands, or use tricky code to > upgrade old commands each time we need to send other informations related to > the map from the server to the client, think will get even worse. So i > prefered to create from zero a new command which is extensible. However, > in the near future, nothing prevents from having a command from client to > server saying the server we prefer the 'classical' map informations to be > send with mapextended and not map2 or map2a. The right approach is a map2 command. Updating the current map command is only tricky because all the bits are currently in use (no spare capacitity). Adding another flag byte gives plenty of capacity for additional fields to be set. IMO, having yet another function/protocol command is more of a pain than extending an existing one. And only one new command (map2) would be needed. Updating the map1 or map1a command certainly isn't needed. The client would do something like 'setup map2cmd', and the server uses the map2 command, which would be 90% the same as the map1/map1a command. You have to be careful/think about what information woudl be included in the map commands. Sound information, for example, is not. One reason is the way it is generated - it is generated through some other event, and isn't persistent. Text messages are the same way. So if you want to send them in this command, you then need to tuck away that 'xyz was said on space a,b', send the map for all the players, and then clear that this information in on this space so we don't send it every tick. One can see that it is almost certainly see it easier to do text messages the way sound is done - when a text message is generated, client does something like 'sendtext x,y Moreover, server may send additionnal informations the client doesn't know > about, without having to take care 'may i put those 4 additionnal bits inside > the packet?' 'is the client using the old 1 byte or the new 2 byte ways of > sending smoothing?' etc. The server knows in advance the client will skip > what it doesn't understand, while still reading what he does understand. This > could help a lot, IMO, in the future the readability of server code I still consider this a bad idea. Send data the client expect. Sure, there are a few more if's in the server code (if client wants text messages, send it). Such code is really trivial, and also more efficient. Because I also forsee that if this just gets extended to the extent that a bunch of extra data is being sent, and the client/player doesn't want it, they will say this is bogus - send me the info I want - I have limited bandwidth/cpu power/whatever, don't send all this extra stuff. But more over, the protocol tends not to get updated too often. But talking about confusing code, the code for the extended info is already embedded in the same code that generates the map1 command. To me, that is more confusing than just putting the data in the map routine - now one has to pay more attention to where this attribute is being used. > > see mapextended as a map2 command with more future extensibility without the > pain of handling 'old cases' in the server and guessing eveyrtime what the > version of client is. There is _never_ and issue of guessing what the client supports - the client always tell us via setup command if it supports smoothing, text messages, whatever. It is just a matter of having a few if's in the code to handle if the client supports it or not. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 6 03:59:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:33 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <3F07AFE6.8030100@sonic.net> References: <3F053044.60805@sonic.net> <200307051738.20423.d.delbecq@laposte.net> <3F07AFE6.8030100@sonic.net> Message-ID: <200307061059.38034.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Dimanche 6 Juillet 2003 07:13, Mark Wedel a ?crit : > tchize wrote: > > Le Vendredi 4 Juillet 2003 23:30, Mark Wedel a ?crit : > > > > > divide you destination picture in 4 > > the uperleft part is made of the upertleft part the 'left I' case > > the upperight part is made of the uperright part of the 'nothing' case > > the bottomleft part is made of the bottomleft part of the 'O' case > > the bottomright part is made of the bottomright part of the '=' case > > This all limit needs for drawing to 8 pictures. I did this choice cause, > > when you look at "Figure 4: Artifact Grassland Transitions" on gamedev, > > you'll see most pictures share some parts. I didn't think about the > > possibility, in L shaped case, people might want to convert to a straight > > line. I wanted to save time from pictures drawers. However, th? 32 > > pictures case presented seems better. If the crossfire gfxers are ready > > to do the 32 pictures for each transition, am ready to convert the code > > to use the Cases shown in document. > > Note that it really isn't 32 more images. > > From the gamedev article > (http://www.gamedev.net/reference/articles/article934.asp), the bottom 16 > images are already done (single corners). > > And 8 of the top 16 images are already there. So that is really 8 images > that woudl need to be added (4 L's and 4 U's). Right > > Even if those aren't done immediately, I really think support for them > should be added, as people are bound to want to draw such images at some > point. > ok > I also wonder if instead of having a bunch of seperate images for each > tile if it would be easier to instead have 1 larger smoothing tile of a set > layout, and the client just copies the bits over it needs. This reduces > overhead a little bit - presumably, if the client is going to need one > smoothing tile for a terrain, it is likely it will need all the combos. > still right. So will work with a 512x64 tile (32*16x32*2) > > The one problem I have with the existing graphics, is that they don't > really have any curves. Still right > When I look at the examples you have on your web > page, things don't look a lot smoother - the grass still has pretty much > straight lines - they just spill over a little into the neighboring spaces. > > This may be a fault of the graphics - if you look at the gamedev article, > it seems the simple cases of the straight lines which are not through lines > (eg, one of your 001 cases) that the graphic has a more pronounced bow show > to the overlapping terrain. But that is just the typical matter of > improving graphics. Am not a drawer. The pics i provided were just example waiting for better graphics. Howerver, i'll follow the way proposed by gamedev, exactly. This will break the few client having my messed way of doing thing. But users could still uncheck their smoothing selection box. Lemme go to the code now :P > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/B+TgHHGOa1Q2wXwRAqWkAKCQtt3i1Cw7K8lTeavb+elsvIXxrQCeJdqU fMi68pstE6d0ZunRn9eXM4U= =EZi1 -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 6 09:13:19 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:33 2005 Subject: [CF-Devel] Pictures Message-ID: <1057500798.32635.3.camel@debian> Hello. I want to offer myself for redrawing some pictures. Thought i need any software for uncompressing/compressing the image package. I don't know if this is the list where i should ask, if don't, tell me :P if so, ask me for example sprites... Btw, i don't think those "sparks" on the swords might be drawed... they look so unreallistic :P Sorry for my bad english. LZ (elezeta@eresmas.com) (Xeon at metalforge's server) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 6 10:59:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:33 2005 Subject: [CF-Devel] Pictures In-Reply-To: <1057500798.32635.3.camel@debian> References: <1057500798.32635.3.camel@debian> Message-ID: <200307061759.58918.tchize@myrealbox.com> Le Dimanche 6 Juillet 2003 16:13, LZ a ?crit : > Hello. > > I want to offer myself for redrawing some pictures. Good > Thought i need any > software for uncompressing/compressing the image package. You don't. Y must downlaod 2 thing: 1st the crossfire server, available at sourceforge, from CVS 2nd the archetype files (not the crossfire.0 and crossfire.1 files, you need the full arch directory which is used to build the crossfire.0 and .1 files). 3rd go to the crossfire discussion channel for help you will surely need (we all needed help to start handling drawing/coding under crossfire) #crossfire at irc.freenode.net >I don't know > if this is the list where i should ask, if don't, tell me :P if so, ask > me for example sprites... Let's discuss on irc channel > > Btw, i don't think those "sparks" on the swords might be drawed... they > look so unreallistic :P > > > Sorry for my bad english. Mine is worse > > LZ (elezeta@eresmas.com) > (Xeon at metalforge's server) > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 6 12:38:43 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:33 2005 Subject: [CF-Devel] Pictures In-Reply-To: <1057500798.32635.3.camel@debian> References: <1057500798.32635.3.camel@debian> Message-ID: <200307061938.45182.yann.chachkoff@myrealbox.com> Le Dimanche 6 Juillet 2003 16:13, LZ a ?crit : > Hello. > > I want to offer myself for redrawing some pictures. Thought i need any > software for uncompressing/compressing the image package. I don't know > if this is the list where i should ask, if don't, tell me :P if so, ask > me for example sprites... > The Crossfire-devel is the correct list to submit new stuff like GFX. Just don't post your work directly as attachments, but rather as URLs. If you want to get return for players, you may want to post an article on the Crossfire Forum. And the irc channel #crossfire is also a good way to get real-time impressions. > Sorry for my bad english. > No problem... We're in the same team :) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 6 13:57:23 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:33 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <3F07AFE6.8030100@sonic.net> References: <3F053044.60805@sonic.net> <200307051738.20423.d.delbecq@laposte.net> <3F07AFE6.8030100@sonic.net> Message-ID: <200307062057.29578.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok here is status. I will add to the CVS the new version of smoothing code when i have finnished the cleanup. (perhaps in one day, still some code to do server side). People interested might want tot take a look at http://users.skynet.be/am248983/smooth/smooth2.png and compare with old version http://users.skynet.be/am248983/smooth/smooth.png Yet, the result may seems worse, but i did the picture of grass border in 10 minutes while last time is spend 2 hours on it, and i am a bad drawer. There is need for someone to draw better than me. Now, the client will use one picture and not 8 different ones. However, this picture will be larger and contains all the 32 cases present in the "legendary document" at http://www.gamedev.net/reference/articles/article934.asp To get an idea how to draw the border, here is a link to a 'canvas' for the border. Each square is 32x32 in size. http://users.skynet.be/am248983/smooth/canvas_smooth.png As you may notice i draw very badly :P good night everyone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/CHEYHHGOa1Q2wXwRAoTNAJ4xtsMpraW+/q7vo7xZ/afZ2DVBWgCgl6gm MeDbgdVzzzGrd5euuBTqgEE= =/iXe -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Jul 7 01:37:43 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:33 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <200307062057.29578.tchize@myrealbox.com> Message-ID: On 06-Jul-03 tchize wrote: > Yet, the result may seems worse, but i did the picture of grass border in 10 > minutes while last time is spend 2 hours on it, and i am a bad drawer. There > is need for someone to draw better than me. Actually.. I think it looks alot better. Your lack of artistic ability is obvious.. but I can see in these drawings what I've been hoping to see in this. Namely, that it has begun to become difficult to distinguish the border between the tile boundaries. Specifically, if you look at where the mountains pinch the grass, you can see that it becomes difficult to make out the tile boundaries. If it wasn't for the fact that the underlying grass tile is imperfectly bordered, you would have a very hard time determining what is a border there. That IMHO, is perfect. The seacoast looks much better too. From crossfire-devel-admin at archives.real-time.com Mon Jul 7 21:35:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:33 2005 Subject: [CF-Devel] smoothing code. References: Message-ID: <000401c344f9$8b8376e0$1d76e2d1@KAMERIA> > > On 06-Jul-03 tchize wrote: > > Yet, the result may seems worse, but i did the picture of grass border in 10 > > minutes while last time is spend 2 hours on it, and i am a bad drawer. There > > is need for someone to draw better than me. > > Actually.. I think it looks alot better. Yes, and if the hills overlapped the grass it would be nicer even. (why on earth did you use the blackstone for a demo?) Once you see a few layers here it will look much better. I have made a start on some of these tiles. >Your lack of artistic ability is > obvious.. Hehe, such tact... ;) > That IMHO, is perfect. The seacoast looks much better too. > > From this I can see that the results of your code are exactly what I was hoping > for.. only the art needs to catch up now. Yup, I agree. Hopefully I can get some done quickly, over the next few days (but no promises). I am going to work on grass, sand, mountain and hills for a starting point just in case anyone wanted to know - these should be applicable for multiple ground types (the mountain should work for all mountain, the hill for all hills...). If anyone else is doing some of these - let me know so I don't waste my time ok... p.s - the perhaps the layer order should be water->roadtypes/stonetypes->sand/swamp->grass->hills->mountains->trees? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Jul 7 13:30:42 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:34 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <000401c344f9$8b8376e0$1d76e2d1@KAMERIA> Message-ID: On 08-Jul-03 Todd Mitchell wrote: > p.s - the perhaps the layer order should be > water->roadtypes/stonetypes->sand/swamp->grass->hills->mountains->trees? I'll buy that. I have a hard time with water overlapping anything.. I can imagine a road fading out into the water, like cobblestones built on the side of a lake. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Jul 7 18:18:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:34 2005 Subject: [CF-Devel] CVS problems. In-Reply-To: <200307051745.46165.tchize@myrealbox.com> Message-ID: <20030707231849.72639.qmail@web21305.mail.yahoo.com> --- tchize wrote: > Le Samedi 5 Juillet 2003 14:59, David Seikel a ?crit : > MM dunno if it's you firewall. If you used anonymous login, be aware that > the sourceforge cvs is under heavy loads and anonymous connection are > dropped for now I was trying anonymous login, so that will be why I couldn't get in. Guess I have to wait for a while before I can grab the latest from CVS. http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Jul 7 22:31:34 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:34 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: References: Message-ID: <3F0A3B16.2090508@sympatico.ca> To get the ball rolling here are some graphics to work with. That template sure sped things up. I can ditch the grey checkers if necessary, but they make it much easier to manage/edit so if you can make them transparent via the smoothing engine it would be swell. Let me know if these are usable- I haven't built a smoothing server yet. http://abraxis.sytes.net/games/cfstuff/smooth _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Jul 7 22:20:23 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:34 2005 Subject: [CF-Devel] CVS problems. In-Reply-To: <20030707231849.72639.qmail@web21305.mail.yahoo.com> References: <20030707231849.72639.qmail@web21305.mail.yahoo.com> Message-ID: <3F0A3877.20105@sonic.net> David Seikel wrote: > --- tchize wrote: > >>Le Samedi 5 Juillet 2003 14:59, David Seikel a ?crit : >>MM dunno if it's you firewall. If you used anonymous login, be aware that >>the sourceforge cvs is under heavy loads and anonymous connection are >>dropped for now > > > I was trying anonymous login, so that will be why I couldn't get in. Guess > I have to wait for a while before I can grab the latest from CVS. > Just a note, I tried last night (Sunday) to do an update, using my real sourceforge login, and never did anything. So there may very well have been some problems with all account types on sourceforge. Seems OK now, but I haven't tried anonymous access. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Jul 7 22:30:20 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:34 2005 Subject: [CF-Devel] Developing for Crossfire. Was: Pictures In-Reply-To: <200307061759.58918.tchize@myrealbox.com> Message-ID: <20030708033020.97323.qmail@web21309.mail.yahoo.com> --- tchize wrote: > 3rd go to the crossfire discussion channel for help you will surely need > (we all needed help to start handling drawing/coding under crossfire) > #crossfire at irc.freenode.net It should be obvious by now that I want to do some Crossfire coding, and I want to do it right. Do I really need to chat on IRC? One of the firewalls I am behind blocks all but HTTP and HTTPS ports, but at least it proxies FTP via HTTP. The other firewall is at work, and they probably won't allow me to IRC from work. So I am stuck with Yahoo's web based mail and whatever I can point a browser at. Are there other mailing lists or whatever I should be on? Also, as has been pointed out to me recently, there is no point telling people to try anonymous CVS from sourceforge, they won't allow it for now. Personally, I don't like sourceforge as the primary source for things, it tends to be flaky and inconvenient. http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 02:15:17 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:34 2005 Subject: [CF-Devel] Developing for Crossfire. Was: Pictures In-Reply-To: <20030708033020.97323.qmail@web21309.mail.yahoo.com> Message-ID: On 08-Jul-03 David Seikel wrote: > Do I really need to chat on IRC? One of the No, but one on one conversation makes discussion of your ideas go much faster. > Are there other mailing lists or whatever I should be on? Not really.. there is a web forum somewhere.. but it's not mandatory. This is the official discussion list. IRC and the forum are informal discussion areas.. but alot of stuff does end up happening on the IRC bit. > Also, as has been pointed out to me recently, there is no point telling > people to try anonymous CVS from sourceforge, they won't allow it for now. > Personally, I don't like sourceforge as the primary source for things, it > tends to be flaky and inconvenient. About that.. is there a way we could perhaps build CVS snapshots occasionally.. in tarball format? Just a thought. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 02:38:39 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:34 2005 Subject: [CF-Devel] invisible spells. Message-ID: <3F0A74FF.6000404@sonic.net> I'm slowly working my way, converting the old spell stuff to spell objects. I got to invisibility, of which there are currently 3 varieties - invisible, invisible to undead, and improved invisible. For the first 2, if you attack, the spell is lost. I was think that this could perhaps get abstracted more, eg, invisible to kobolds, invisible to plants, etc. Most likely, this would use a field in the object to say what this makes one invisible against. The obvious question is whether this would seem that useful - currently, the undead is a special case, because undead is not effected by normal invisibility (this goes back to the case that thinks like skeletons obviously don't have eyes, so sense creatures through some other means than just light). Does anyone see much a need beyond undead/non undead invisibility? As I type this up, I don't really see any, unless we add yet more special cases of race/creatures that are immune to invisiblity, but since I have typed this up, I figured I would send it out. Given the code, it would be easy to make something like an 'improved invisiblity to undead' any way that I go. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 03:17:28 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:34 2005 Subject: [CF-Devel] Developing for Crossfire. Was: Pictures In-Reply-To: Message-ID: <20030708081728.43099.qmail@web21307.mail.yahoo.com> --- Tim Rightnour wrote: > > About that.. is there a way we could perhaps build CVS snapshots > occasionally.. > in tarball format? Just a thought. According to the web site it used to be done. http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 03:19:40 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:34 2005 Subject: [CF-Devel] invisible spells. In-Reply-To: <3F0A74FF.6000404@sonic.net> Message-ID: <20030708081940.55948.qmail@web21302.mail.yahoo.com> --- Mark Wedel wrote: > > Does anyone see much a need beyond undead/non undead invisibility? > As I type this up, I don't really see any, unless we add yet more > special cases of race/creatures that are immune to invisiblity, but > since I have typed this up, I figured I would send it out. Invisibility to your gods enemy race? http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 03:26:15 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:34 2005 Subject: [CF-Devel] speculations about the floor (elevation) In-Reply-To: <3F05F4F3.5070208@sonic.net> Message-ID: <20030708082615.56699.qmail@web21302.mail.yahoo.com> --- Mark Wedel wrote: > I was never really happy with the north and south poles being at the > corners. IT just isn't that intuitive. I can understand the reason > (want the poles to be relative small areas). but I also wonder if the map > as given should be seen as covering the entire world, or just some part of > it (eg, one of the continents in the northern hemisphere, for example, > such that the equator is near the south edge of the map, and the north > pole would effectively be a few hundred spaces still farther to the north) Sounds good to me, as I said - > > On the other hand, it would be good to make a decision, document it, > > and stick to it, so that we are all on the same page. To keep things interesting, we should ensure that there is a portion of the map that is ice bound at least part of the year. And let people walk on the ice, at least until it melts... > Do I expect new continents to be added? Not really. However, when > putting down the towns/roads, I did put up signs which basically amounted > to 1 space = 1 mile (eg, scorn, 764 miles north or something). One could > obviously make the case that a crossfire mile isn't the same as a human > mile. At least call them something different to avoid confusion. http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 07:49:50 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:34 2005 Subject: [CF-Devel] invisible spells. In-Reply-To: <3F0A74FF.6000404@sonic.net> References: <3F0A74FF.6000404@sonic.net> Message-ID: <200307081449.50952.tchize@myrealbox.com> Le Mardi 8 Juillet 2003 09:38, Mark Wedel a ?crit : > I'm slowly working my way, converting the old spell stuff to spell > objects. > > I got to invisibility, of which there are currently 3 varieties - > invisible, invisible to undead, and improved invisible. For the first 2, > if you attack, the spell is lost. > > I was think that this could perhaps get abstracted more, eg, invisible > to kobolds, invisible to plants, etc. Most likely, this would use > a field in the object to say what this makes one invisible against. > > The obvious question is whether this would seem that useful - currently, > the undead is a special case, because undead is not effected by normal > invisibility (this goes back to the case that thinks like skeletons > obviously don't have eyes, so sense creatures through some other means > than just light). > > Does anyone see much a need beyond undead/non undead invisibility? > As I type this up, I don't really see any, unless we add yet more > special cases of race/creatures that are immune to invisiblity, but > since I have typed this up, I figured I would send it out. > > Given the code, it would be easy to make something like an 'improved > invisiblity to undead' any way that I go. > > > Invisibility to flying creatures? > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 08:02:29 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:34 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <3F0A3B16.2090508@sympatico.ca> References: <3F0A3B16.2090508@sympatico.ca> Message-ID: <200307081502.39247.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Mardi 8 Juillet 2003 05:31, Todd a ?crit : > To get the ball rolling here are some graphics to work with. That > template sure sped things up. > I can ditch the grey checkers if necessary, but they make it much easier > to manage/edit so if you can make them transparent via the smoothing > engine it would be swell. Let me know if these are usable- I haven't > built a smoothing server yet. > > http://abraxis.sytes.net/games/cfstuff/smooth > > Ahem! Sorry for the misunderstanding. The grey checker was there for example reasons. It represent a lot of work to remove it from the picture 'on the fly' Could you remove this from your pics and replace it with an alpha layer? Perhaps submitting the grey checker alone so drawers can, work time, slide it behind the picture could be easier. Apart from the grey checkers, your picture are useable :P i just submitted the server and client with the smoothing code associated with this way of doing things (i submitted pictures 2 days ago but couldn't commit code at that time since unstable ....) Still need to test your pictures ingame to have a really good idea in what it will result :P > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/CsDqHHGOa1Q2wXwRAib/AJ9LQnTE8EhlFny6AVXrwbm1AON3NwCfXPCH a2gQXo9jhKj2YLP8myZzwMU= =MOGS -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 08:57:10 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:34 2005 Subject: [CF-Devel] Gfx Message-ID: <1057672629.21693.0.camel@debian> Look at those graphics i already drawed: http://www.ayuda-es.net/~lz/newgfx1.png http://www.ayuda-es.net/~lz/newgfx2.png http://www.ayuda-es.net/~lz/newgfx3.png LZ/Elezeta (elezeta@eresmas.com). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 21:29:45 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:34 2005 Subject: [CF-Devel] Gfx References: <1057672629.21693.0.camel@debian> Message-ID: <001b01c345c1$f7b75de0$96dfd1d8@KAMERIA> The water is nice and the marble (I would consider using these and making the existing ones classic...), but I still like the existing cobblestones better. The Flagstone is interesting, but I would rather add yours to the classic set than replace the existing one. The wood floors are pretty busy, but would be nice for the classic set. As for grass - if you replace grass you have to replace many of the other tiles which use it as a base (trees, forest, hills...). If you just replace grass all those other tiles look a bit off. Don't take this critique the wrong way however, I am glad you are lending a hand. ----- Original Message ----- From: "LZ" Sent: Tuesday, July 08, 2003 9:57 AM Subject: [CF-Devel] Gfx > Look at those graphics i already drawed: > > http://www.ayuda-es.net/~lz/newgfx1.png > http://www.ayuda-es.net/~lz/newgfx2.png > http://www.ayuda-es.net/~lz/newgfx3.png > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 09:35:50 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:34 2005 Subject: [CF-Devel] Gfx In-Reply-To: <1057672629.21693.0.camel@debian> References: <1057672629.21693.0.camel@debian> Message-ID: <200307081635.50709.tchize@myrealbox.com> Le Mardi 8 Juillet 2003 15:57, LZ a ?crit : > Look at those graphics i already drawed: > > http://www.ayuda-es.net/~lz/newgfx1.png > http://www.ayuda-es.net/~lz/newgfx2.png > http://www.ayuda-es.net/~lz/newgfx3.png > > > LZ/Elezeta (elezeta@eresmas.com). > > Just some comments. First, good job! Second. The 3rd item on second column in first screenshot looks like a mushroom. Is is normal? or is it something elese than a mushroom? Third. Concerning the grounds, i think your grass lack a bit of relief. Looks too much unnatural. Grass in real live have little flowers in it, it's not this soft. On the other hand, i think the existing grass has too much relief and contrast in it. I also note your blackmarble lower right in last screenshot, lack the continuity needed by floor pictures. It looks to much like white square parts bordered by black parts. Your lower left white marble is far better. But once again, good job :) > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 10:01:39 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:34 2005 Subject: [CF-Devel] Gfx In-Reply-To: <001b01c345c1$f7b75de0$96dfd1d8@KAMERIA> References: <1057672629.21693.0.camel@debian> <001b01c345c1$f7b75de0$96dfd1d8@KAMERIA> Message-ID: <1057676499.21699.11.camel@debian> @Todd Mitchell: Hmmm, i have resedigned the ponds too (you can see some there), and i'm redrawing the trees. Actually i have just redrawn all the /river branch, so they look like the sea, and it's working fine. I still think my cobblestones are a lot clearer than the actual ones (just compared them) @tchize: It's the bonecrusher, might have look like a warhammer... Hmm, about the grass, look at the houses sizes, you think you could see big flowers there? them'd be sized as a person... noticed the blackmarble fault, ouch :/ i'll fix it BTW also fixed the lakes (didn't know there might be a north/south/etc. zones, lol). Some people asked me why did i "darked" some of the tiles (the center ones)... hmmm that's pretty logical, where could you find REALLY CLEAN tiles? :? At the moment i'm redrawing trees/grounds and weapons. Whatever, hmm, i'll try to redraw everything. tchize and me just were discussing at IRC if all my images could fit in a newer image set (or maybe moving .base as .old, and placing mine at .base) :P Thanks you both =P LZ (elezeta@eresmas.com) El mi? 09-07-2003 a las 04:29, Todd Mitchell escribi?: > The water is nice and the marble (I would consider using these and making > the existing ones classic...), but I still like the existing cobblestones > better. The Flagstone is interesting, but I would rather add yours to the > classic set than replace the existing one. The wood floors are pretty > busy, but would be nice for the classic set. > As for grass - if you replace grass you have to replace many of the other > tiles which use it as a base (trees, forest, hills...). If you just replace > grass all those other tiles look a bit off. > > Don't take this critique the wrong way however, I am glad you are lending a > hand. > > ----- Original Message ----- > From: "LZ" > Sent: Tuesday, July 08, 2003 9:57 AM > Subject: [CF-Devel] Gfx > > > > Look at those graphics i already drawed: > > > > http://www.ayuda-es.net/~lz/newgfx1.png > > http://www.ayuda-es.net/~lz/newgfx2.png > > http://www.ayuda-es.net/~lz/newgfx3.png > > > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 21:55:41 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:35 2005 Subject: [CF-Devel] smoothing code. References: <3F0A3B16.2090508@sympatico.ca> <200307081502.39247.tchize@myrealbox.com> Message-ID: <002801c345c5$967798c0$96dfd1d8@KAMERIA> >Ahem! >Sorry for the misunderstanding. The grey checker was there >for example reasons. It represent a lot of work to >remove it from the picture 'on the fly' >Could you remove this from your pics and replace it with an >alpha layer? >Perhaps submitting the grey checker alone so drawers >can, work time, slide it behind the picture could be easier. Ya, not a misunderstanding, I was expecting this but was hopefull for some last minute magic. I will make an overlay template for design use. >Apart from the grey checkers, your picture are useable :P usable eh... These fine works of art are 'usable' he says... >Still need to test your pictures ingame to have a really good idea in what it >will result :P Ya, I excect they will need changes but this is a start so that the code can be eyeballed. I am not too sure how the little floaty bits will show up on some backgrounds. Do you have any name standard suggestions? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 10:02:32 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:35 2005 Subject: [CF-Devel] Gfx In-Reply-To: <001b01c345c1$f7b75de0$96dfd1d8@KAMERIA> References: <1057672629.21693.0.camel@debian> <001b01c345c1$f7b75de0$96dfd1d8@KAMERIA> Message-ID: <200307081702.42790.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Mercredi 9 Juillet 2003 04:29, Todd Mitchell a ?crit : > The water is nice and the marble (I would consider using these and making > the existing ones classic...), but I still like the existing cobblestones > better. The Flagstone is interesting, but I would rather add yours to the > classic set than replace the existing one. The wood floors are pretty > busy, but would be nice for the classic set. > As for grass - if you replace grass you have to replace many of the other > tiles which use it as a base (trees, forest, hills...). Well Speaking of all tiles using grass as a base. Shouldn't we replace all of them with 2 tiles, one having a alpha layer? I want you to take into account this, speaking back of smoothing: If i have a tree ontop of grass, should it smooth as grass or as a tree? If it smooth as grass, mountains should overlap over it. This means we will get the feeling that the moutains grows on top of tree (quite unnatural, you'll agree). If it is smoothed like a tree, what graphics will see in the border? Small young trees without grass? The grass at the bottom will end abruptly and we will lose the advantages of smoothing. So we would put, perhaps, small young trees and a bit of grass below. But all those would be drawn at level of tree and so the grass associated will overlap the mountains, which is in contradiction with the fact mountains should go over grass. And the result will also be ugly (abruptly ended mountain and grass over the mountain). The only solution i see is transforming on map a tree with grass as 2 objects, grass and a tree on top (same with forest over grass, forest over hills, aso.) This problem is not new. The weather code, as i can remember, has this problem when you need to put snow above the grass but below the trees. The code than replace, on the fly, this object by a pair of object (grass and tree) and then put the snow. I understand we comes to a problem as client only knows 3 layers of a square map. If you put grass+snow+tree+player on a square, one of them must disappear. But this is already the case due to on the fly manipulations of weather code, and i think we should consider replace those object in maps (a script could be created which does the work.) A solution concerning snow could be to create a 'snowed grass' object, but am not sure this is needed. What do you think about it? This could save a lot of time for drawers when dealing with smoothing or other, future maybe, updates of graphics. > If you just > replace grass all those other tiles look a bit off. > > Don't take this critique the wrong way however, I am glad you are lending a > hand. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Ct0NHHGOa1Q2wXwRApIRAJ9LwOwHbsJrMRHrw021s5pbGCnmwQCfRTyX C2Kss8ghH0N4PPHHt9Y9KvA= =gp+f -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 10:22:31 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:35 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <002801c345c5$967798c0$96dfd1d8@KAMERIA> References: <200307081502.39247.tchize@myrealbox.com> <002801c345c5$967798c0$96dfd1d8@KAMERIA> Message-ID: <200307081723.08781.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Mercredi 9 Juillet 2003 04:55, Todd Mitchell a ?crit : > >Ahem! > >Sorry for the misunderstanding. The grey checker was there > >for example reasons. It represent a lot of work to > >remove it from the picture 'on the fly' > >Could you remove this from your pics and replace it with an > >alpha layer? > >Perhaps submitting the grey checker alone so drawers > >can, work time, slide it behind the picture could be easier. > > Ya, not a misunderstanding, I was expecting this but was hopefull for some > last minute magic. I will make an overlay template for design use. > > >Apart from the grey checkers, your picture are useable :P > > usable eh... These fine works of art are 'usable' he says... Ho, THIS is *art*? No just kidding :) Am not going on a discussion about what art is and what fine art is. Anyway, it's your fault, you wandered is they were useable and i answered you. If you are not ok with my answer take your pencil and... No i stop kidding here, you have already gone too far in your argumentations :P > > >Still need to test your pictures ingame to have a really good idea in what > > it > > >will result :P > > Ya, I excect they will need changes but this is a start so that the code > can be eyeballed. I am not too sure how the little floaty bits will show > up on some backgrounds. Do you have any name standard suggestions? > > I used this standard here for grass.base.111.png i named the pic sgrass.base.111.png i put the picture in arch/ground/smooth/grasslike quite easy to understand a simple 's' at the beginning :) You could also be interested in doc i send along with my last server update. go to doc/developer/smooth.pdf - -- Tchize (David Delbecq) tchize@myrealbox.com Cause am the best, at least for the surrounding 50 centimeters region. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/CuG8HHGOa1Q2wXwRArY8AJ40Q6QWWQ9IkRfOaC6rKpV8eCNQKgCePWB2 Z1uCE5bek6uWdtQnq+GJvTU= =RYVI -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 11:54:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:35 2005 Subject: [CF-Devel] Gfx In-Reply-To: <1057676499.21699.11.camel@debian> References: <1057672629.21693.0.camel@debian> <001b01c345c1$f7b75de0$96dfd1d8@KAMERIA> <1057676499.21699.11.camel@debian> Message-ID: <200307081711.13664.d.delbecq@laposte.net> Le Mardi 8 Juillet 2003 17:01, LZ a ?crit : > @Todd Mitchell: > Hmmm, i have resedigned the ponds too (you can see some there), and i'm > redrawing the trees. > > Actually i have just redrawn all the /river branch, so they look like > the sea, and it's working fine. > > I still think my cobblestones are a lot clearer than the actual ones > (just compared them) > > @tchize: > > It's the bonecrusher, might have look like a warhammer... > Hmm, about the grass, look at the houses sizes, you think you could see > big flowers there? them'd be sized as a person... I don't ask for big flowers (or perhaps player eating ones but that's another story). I was just thinking your grass picture is too homogenous, too soft. Could be used on a golf course. Don't forget the grass is supposed to be used also on wild areas, where noone cut it regulary. If i look at meadow from my window here, even at the distance is see contrasts in the grass. From time to time there is a pack of lighter grass, and so on. I don't mean you need to do eveything is see from my windows (could you draw a cow? it lacks in crossfire) but am still saying your grass pic is too soft. > noticed the blackmarble fault, ouch :/ i'll fix it > > > > BTW also fixed the lakes (didn't know there might be a north/south/etc. > zones, lol). > > Some people asked me why did i "darked" some of the tiles (the center > ones)... hmmm that's pretty logical, where could you find REALLY CLEAN > tiles? :? > > At the moment i'm redrawing trees/grounds and weapons. Whatever, hmm, > i'll try to redraw everything. tchize and me just were discussing at IRC > if all my images could fit in a newer image set (or maybe moving .base > as .old, and placing mine at .base) :P > > > Thanks you both =P > > LZ (elezeta@eresmas.com) > > El mi? 09-07-2003 a las 04:29, Todd Mitchell escribi?: > > The water is nice and the marble (I would consider using these and making > > the existing ones classic...), but I still like the existing cobblestones > > better. The Flagstone is interesting, but I would rather add yours to > > the classic set than replace the existing one. The wood floors are > > pretty busy, but would be nice for the classic set. > > As for grass - if you replace grass you have to replace many of the other > > tiles which use it as a base (trees, forest, hills...). If you just > > replace grass all those other tiles look a bit off. > > > > Don't take this critique the wrong way however, I am glad you are lending > > a hand. > > > > ----- Original Message ----- > > From: "LZ" > > Sent: Tuesday, July 08, 2003 9:57 AM > > Subject: [CF-Devel] Gfx > > > > > Look at those graphics i already drawed: > > > > > > http://www.ayuda-es.net/~lz/newgfx1.png > > > http://www.ayuda-es.net/~lz/newgfx2.png > > > http://www.ayuda-es.net/~lz/newgfx3.png > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 10:11:13 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:35 2005 Subject: [CF-Devel] Gfx In-Reply-To: <1057676499.21699.11.camel@debian> References: <1057672629.21693.0.camel@debian> <001b01c345c1$f7b75de0$96dfd1d8@KAMERIA> <1057676499.21699.11.camel@debian> Message-ID: <200307081711.13664.d.delbecq@laposte.net> Le Mardi 8 Juillet 2003 17:01, LZ a ?crit : > @Todd Mitchell: > Hmmm, i have resedigned the ponds too (you can see some there), and i'm > redrawing the trees. > > Actually i have just redrawn all the /river branch, so they look like > the sea, and it's working fine. > > I still think my cobblestones are a lot clearer than the actual ones > (just compared them) > > @tchize: > > It's the bonecrusher, might have look like a warhammer... > Hmm, about the grass, look at the houses sizes, you think you could see > big flowers there? them'd be sized as a person... I don't ask for big flowers (or perhaps player eating ones but that's another story). I was just thinking your grass picture is too homogenous, too soft. Could be used on a golf course. Don't forget the grass is supposed to be used also on wild areas, where noone cut it regulary. If i look at meadow from my window here, even at the distance is see contrasts in the grass. From time to time there is a pack of lighter grass, and so on. I don't mean you need to do eveything is see from my windows (could you draw a cow? it lacks in crossfire) but am still saying your grass pic is too soft. > noticed the blackmarble fault, ouch :/ i'll fix it > > > > BTW also fixed the lakes (didn't know there might be a north/south/etc. > zones, lol). > > Some people asked me why did i "darked" some of the tiles (the center > ones)... hmmm that's pretty logical, where could you find REALLY CLEAN > tiles? :? > > At the moment i'm redrawing trees/grounds and weapons. Whatever, hmm, > i'll try to redraw everything. tchize and me just were discussing at IRC > if all my images could fit in a newer image set (or maybe moving .base > as .old, and placing mine at .base) :P > > > Thanks you both =P > > LZ (elezeta@eresmas.com) > > El mi? 09-07-2003 a las 04:29, Todd Mitchell escribi?: > > The water is nice and the marble (I would consider using these and making > > the existing ones classic...), but I still like the existing cobblestones > > better. The Flagstone is interesting, but I would rather add yours to > > the classic set than replace the existing one. The wood floors are > > pretty busy, but would be nice for the classic set. > > As for grass - if you replace grass you have to replace many of the other > > tiles which use it as a base (trees, forest, hills...). If you just > > replace grass all those other tiles look a bit off. > > > > Don't take this critique the wrong way however, I am glad you are lending > > a hand. > > > > ----- Original Message ----- > > From: "LZ" > > Sent: Tuesday, July 08, 2003 9:57 AM > > Subject: [CF-Devel] Gfx > > > > > Look at those graphics i already drawed: > > > > > > http://www.ayuda-es.net/~lz/newgfx1.png > > > http://www.ayuda-es.net/~lz/newgfx2.png > > > http://www.ayuda-es.net/~lz/newgfx3.png > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 15:14:12 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:35 2005 Subject: [CF-Devel] CVS problems. In-Reply-To: <20030707231849.72639.qmail@web21305.mail.yahoo.com> References: <20030707231849.72639.qmail@web21305.mail.yahoo.com> Message-ID: <200307082214.37565.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Mardi 8 Juillet 2003 01:18, David Seikel a ?crit : > --- tchize wrote: > > Le Samedi 5 Juillet 2003 14:59, David Seikel a ?crit : > > MM dunno if it's you firewall. If you used anonymous login, be aware that > > the sourceforge cvs is under heavy loads and anonymous connection are > > dropped for now > > I was trying anonymous login, so that will be why I couldn't get in. Guess > I have to wait for a while before I can grab the latest from CVS. > > http://mobile.yahoo.com.au - Yahoo! Mobile > - Check & compose your email via SMS on your Telstra or Vodafone mobile. > I dunno if it is really of any help, but i provide a snapshot of CVS at the following page: http://users.skynet.be/am248983/snap/index.html Since those snapshot have a size of 24M, it is bandwidth consumming to upload them to my website. Anyway i'll try to have a snapshot every 2 days, so until the sourceforge anonymous cvs is back online, you should be able to download most important things there. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/CyYZHHGOa1Q2wXwRAkmiAKDajgeiI7aGy/kKazV6pPqpHYPmBQCfU0KX AeqRpqWaxvo0zWyx8IjoIXE= =2CXE -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 8 19:14:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:35 2005 Subject: [CF-Devel] Gfx In-Reply-To: <200307081702.42790.tchize@myrealbox.com> References: <1057672629.21693.0.camel@debian> <001b01c345c1$f7b75de0$96dfd1d8@KAMERIA> <200307081702.42790.tchize@myrealbox.com> Message-ID: <3F0B5E4D.4080703@sympatico.ca> tchize wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Le Mercredi 9 Juillet 2003 04:29, Todd Mitchell a ?crit : > > >>The water is nice and the marble (I would consider using these and making >>the existing ones classic...), but I still like the existing cobblestones >>better. The Flagstone is interesting, but I would rather add yours to the >>classic set than replace the existing one. The wood floors are pretty >>busy, but would be nice for the classic set. >>As for grass - if you replace grass you have to replace many of the other >>tiles which use it as a base (trees, forest, hills...). >> >> > >Well Speaking of all tiles using grass as a base. Shouldn't we replace all of >them with 2 tiles, one having a alpha layer? I want you to take into account >this, speaking back of smoothing: >If i have a tree ontop of grass, should it smooth as grass or as a tree? >If it smooth as grass, mountains should overlap over it. This means we will >get the feeling that the moutains grows on top of tree (quite unnatural, >you'll agree). > > You know, what we should do is not smooth the trees at all. We should fix the overlap issue with large images and make trees slightly taller than 32 px tall - then you could actually walk *in* a forest. This would mean replacing the 'map type' forest look and moving to a more *tree type* forest look, but I would be down working on that. I think that would be swell but of course everyone is going to now tell me what a stupid idea it is... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 9 01:43:34 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:35 2005 Subject: [CF-Devel] Gfx In-Reply-To: <3F0B5E4D.4080703@sympatico.ca> References: <1057672629.21693.0.camel@debian> <001b01c345c1$f7b75de0$96dfd1d8@KAMERIA> <200307081702.42790.tchize@myrealbox.com> <3F0B5E4D.4080703@sympatico.ca> Message-ID: <3F0BB996.5080500@sonic.net> Todd wrote: > > You know, what we should do is not smooth the trees at all. We should > fix the overlap issue with large images and make trees slightly taller > than 32 px tall - then you could actually walk *in* a forest. This > would mean replacing the 'map type' forest look and moving to a more > *tree type* forest look, but I would be down working on that. I think > that would be swell but of course everyone is going to now tell me what > a stupid idea it is... Well, it is a little more complicated, in the sense you need to get some tree variation that is side to side. From your description, what I would envision would be a vertical line of trees nicely overlapping the one above it, but then you'd have vertical lines of the base terrain that these are not overlapping. So for this to work, you'd also need graphics with trees that spill over side to side. I don't think this could be done with simply one graphic - your talking multiple graphics, or at minimum some graphics to deal with the edge cases, so making an image that properly tiles like some of the ones right now probably makes just as much sense. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 9 01:56:20 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:35 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <200307081723.08781.tchize@myrealbox.com> References: <200307081502.39247.tchize@myrealbox.com> <002801c345c5$967798c0$96dfd1d8@KAMERIA> <200307081723.08781.tchize@myrealbox.com> Message-ID: <3F0BBC94.9030405@sonic.net> tchize wrote: > I used this standard here > for grass.base.111.png i named the pic sgrass.base.111.png > i put the picture in arch/ground/smooth/grasslike I'd personally probably prefer it to be something like grass_sm.base.111.png or the like, and have these smoothed graphics in the same location as the graphics they smooth (and not all dumped into one directory that is only indirectly associated with the graphics they smooth). I just think that is a little easier to deal with/maintain. If necessary, create new subdirectories, but since there is only one smooth graphic per image, that probably isn't necessary. I just find it easier to know that if I do something like a 'mv grass*' that I'm getting all the relevant data for an object, and not that some pieces may be missing. it'd probably also be nice to be able to put the 'smooth' line in the arc or face file vs using a file in the lib directory - same thing - locality of information. Just have the collect script pull out the smooth lines as it processes the arc's (As it does for animatinos now). This isn't that big an issue, but I'd think it make things easier to maintain. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 9 03:00:36 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:35 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <200307081723.08781.tchize@myrealbox.com> Message-ID: >> >Still need to test your pictures ingame to have a really good idea in what I attempted to use a newly built gcfclient against a newly built server.. I enabled the smoothing code. not happy things resulted: Program received signal SIGSEGV, Segmentation fault. 0x80612d9 in gtk_draw_map (redraw=0) at map.c:571 571 src_x = pixmaps[the_map.cells[mx][my].heads[layer].face]->map_width - map_image_size; (gdb) where #0 0x80612d9 in gtk_draw_map (redraw=0) at map.c:571 #1 0x805dc21 in display_map_doneupdate (redraw=0) at gx11.c:5413 #2 0x8064e6c in map1_common (data=0x8a5a008 "", len=936, rev=1) at commands.c:1098 #3 0x8064ea2 in Map1aCmd (data=0x8a5a008 "", len=936) at commands.c:1113 #4 0x8062991 in DoClient (csocket=0x81b2020) at client.c:151 #5 0x804f207 in do_network () at gx11.c:356 #6 0x4821d425 in gdk_io_invoke () from /usr/X11R6/lib/libgdk.so.12 #7 0x4824ba7e in g_io_unix_dispatch () from /usr/pkg/lib/libglib.so.13 #8 0x4824cf8f in g_main_dispatch () from /usr/pkg/lib/libglib.so.13 #9 0x4824d54f in g_main_iterate () from /usr/pkg/lib/libglib.so.13 #10 0x4824d6cd in g_main_run () from /usr/pkg/lib/libglib.so.13 #11 0x4817876d in gtk_main () from /usr/X11R6/lib/libgtk.so.12 #12 0x804f27e in event_loop () at gx11.c:390 #13 0x805de6f in main (argc=1, argv=0xbfbfd7ac) at gx11.c:5618 #14 0x804cf70 in ___start () (gdb) This happened as soon as I connected. I assume from it trying to smooth the mountains on the hall of selection. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 9 22:27:08 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:35 2005 Subject: [CF-Devel] smoothing code. References: Message-ID: <000301c34693$25d41a20$8ddfd1d8@KAMERIA> I assume this is client crash... I also compiled both client and server clean and didn't see any problems running, but I didn't see any smoothing happening either. I did see a reference to smoothing in the server log initial load up (smoothing 22 something or other). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 9 22:54:46 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:35 2005 Subject: [CF-Devel] smoothing code. References: <200307081502.39247.tchize@myrealbox.com> <002801c345c5$967798c0$96dfd1d8@KAMERIA> <200307081723.08781.tchize@myrealbox.com> <3F0BBC94.9030405@sonic.net> Message-ID: <000401c34697$020fc5e0$8ddfd1d8@KAMERIA> ----- Original Message ----- From: "Mark Wedel" > I'd personally probably prefer it to be something like grass_sm.base.111.png > or the like, and have these smoothed graphics in the same location as the > graphics they smooth (and not all dumped into one directory that is only > indirectly associated with the graphics they smooth). > When I added some of these smoothing sets, I took it on myself to change the name like: S_grass.base.111.png and removing the grasslike directory so that all the images are in one directory. I think this is more along the lines you mention. > it'd probably also be nice to be able to put the 'smooth' line in the arc or > face file vs using a file in the lib directory - same thing - locality of > information. Just have the collect script pull out the smooth lines as it > processes the arc's (As it does for animatinos now). > > This isn't that big an issue, but I'd think it make things easier to maintain. If you mean having a smooth field in the arch so archmakers can set the smoothing they want to apply to that new object (or if they make a new smoothing set for it), rather than having to update the server, then that does sound like a good idea. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 9 23:07:59 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:35 2005 Subject: [CF-Devel] Gfx References: <1057672629.21693.0.camel@debian> <001b01c345c1$f7b75de0$96dfd1d8@KAMERIA> <200307081702.42790.tchize@myrealbox.com> <3F0B5E4D.4080703@sympatico.ca> <3F0BB996.5080500@sonic.net> Message-ID: <000901c34698$da5ff180$8ddfd1d8@KAMERIA> > So for this to work, you'd also need graphics with trees that spill over side > to side. I don't think this could be done with simply one graphic - your > talking multiple graphics, or at minimum some graphics to deal with the edge > cases, so making an image that properly tiles like some of the ones right now > probably makes just as much sense. I am just speaking of not having smoothlevel values for trees, not of not smoothing the tiles... The trees are on grasslike tiles now, so I would just make a tree picture on grass that was 44 px high and use grass smoothlevel values to get smoothing. Hopefully the extra 12 px on top would overlap the smoothing as well... But the tops of the trees would overlap the mountains behind the trees (or the water or the walls or the player or the coins...) even though the mountain smoothing would overlap the grass. Of course if you wanted trees in a swamp you would make a new tile with a tree (a creepy tree) in a swamp and set the smoothlevel to swamp. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 9 23:29:09 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:35 2005 Subject: [CF-Devel] Gfx References: <1057672629.21693.0.camel@debian> <001b01c345c1$f7b75de0$96dfd1d8@KAMERIA> <200307081702.42790.tchize@myrealbox.com> <3F0B5E4D.4080703@sympatico.ca> <3F0BB996.5080500@sonic.net> <000901c34698$da5ff180$8ddfd1d8@KAMERIA> Message-ID: <001901c3469b$d000e2a0$8ddfd1d8@KAMERIA> Of course now that I start working on this I can see it isn't going to work so well... > > I am just speaking of not having smoothlevel values for trees, not of not > smoothing the tiles... > The trees are on grasslike tiles now, so I would just make a tree picture on > grass that was 44 px high and use grass smoothlevel values to get smoothing. > Hopefully the extra 12 px on top would overlap the smoothing as well... But > the tops of the trees would overlap the mountains behind the trees (or the > water or the walls or the player or the coins...) even though the mountain > smoothing would overlap the grass. Of course if you wanted trees in a swamp > you would make a new tile with a tree (a creepy tree) in a swamp and set the > smoothlevel to swamp. > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 9 16:03:17 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:36 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <3F0BBC94.9030405@sonic.net> References: <200307081723.08781.tchize@myrealbox.com> <3F0BBC94.9030405@sonic.net> Message-ID: <200307092303.24879.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Mercredi 9 Juillet 2003 08:56, Mark Wedel a ?crit : > tchize wrote: > > I used this standard here > > for grass.base.111.png i named the pic sgrass.base.111.png > > i put the picture in arch/ground/smooth/grasslike > > I'd personally probably prefer it to be something like > grass_sm.base.111.png or the like, and have these smoothed graphics in the > same location as the graphics they smooth (and not all dumped into one > directory that is only indirectly associated with the graphics they > smooth). > > I just think that is a little easier to deal with/maintain. If > necessary, create new subdirectories, but since there is only one smooth > graphic per image, that probably isn't necessary. > > I just find it easier to know that if I do something like a 'mv grass*' > that I'm getting all the relevant data for an object, and not that some > pieces may be missing. > > it'd probably also be nice to be able to put the 'smooth' line in the arc > or face file vs using a file in the lib directory - same thing - locality Well the problem is that 1 the pic used for smoothing is not dependent on object but on it's face (an animated object will have several smooths, one for each step of animation), so i can't put it in the arc file. 2 I assumed what you call the face file is the .png file (like grass.base.111.png). I can't see a way to put this in the picture I understand the actual location of smooth datas is a bit innapropriate, but until someone has a better usable suggestion. 3 suggestion: i could put a file at the root of the arch directory which would be copied directly to the lib dir by the collect script. > of information. Just have the collect script pull out the smooth lines as > it processes the arc's (As it does for animatinos now). > > This isn't that big an issue, but I'd think it make things easier to > maintain. > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/DIMbHHGOa1Q2wXwRAsGWAJ4lbhpxzRDPr8JHU9sEAeF6f7LOEwCdGx0m lRd7lOJK9DJECXNxGaszo9o= =HlFi -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 9 16:08:46 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:36 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: References: Message-ID: <200307092309.04378.d.delbecq@laposte.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Mercredi 9 Juillet 2003 10:00, Tim Rightnour a ?crit : > >> >Still need to test your pictures ingame to have a really good idea in > >> > what > > I attempted to use a newly built gcfclient against a newly built server.. > I enabled the smoothing code. not happy things resulted: > > Program received signal SIGSEGV, Segmentation fault. > 0x80612d9 in gtk_draw_map (redraw=0) at map.c:571 > 571 src_x = > pixmaps[the_map.cells[mx][my].heads[layer].face]->map_width - > map_image_size; (gdb) where > #0 0x80612d9 in gtk_draw_map (redraw=0) at map.c:571 > #1 0x805dc21 in display_map_doneupdate (redraw=0) at gx11.c:5413 > #2 0x8064e6c in map1_common (data=0x8a5a008 "", len=936, rev=1) > at commands.c:1098 > #3 0x8064ea2 in Map1aCmd (data=0x8a5a008 "", len=936) at commands.c:1113 > #4 0x8062991 in DoClient (csocket=0x81b2020) at client.c:151 > #5 0x804f207 in do_network () at gx11.c:356 > #6 0x4821d425 in gdk_io_invoke () from /usr/X11R6/lib/libgdk.so.12 > #7 0x4824ba7e in g_io_unix_dispatch () from /usr/pkg/lib/libglib.so.13 > #8 0x4824cf8f in g_main_dispatch () from /usr/pkg/lib/libglib.so.13 > #9 0x4824d54f in g_main_iterate () from /usr/pkg/lib/libglib.so.13 > #10 0x4824d6cd in g_main_run () from /usr/pkg/lib/libglib.so.13 > #11 0x4817876d in gtk_main () from /usr/X11R6/lib/libgtk.so.12 > #12 0x804f27e in event_loop () at gx11.c:390 > #13 0x805de6f in main (argc=1, argv=0xbfbfd7ac) at gx11.c:5618 > #14 0x804cf70 in ___start () > (gdb) > > This happened as soon as I connected. I assume from it trying to smooth > the mountains on the hall of selection. > > > --- > Tim Rightnour > NetBSD: Free multi-architecture OS http://www.netbsd.org/ > NetBSD supported hardware database: > http://mail-index.netbsd.org/cgi-bin/hw.cgi > Well unless you added smooth to mountains or water, there is no smoothed area (yet) in the hall of selection, which is why i find it so wierd. Note that i fixed a bug in server which appeared during add of smoothing code and which laid to transmitting from srever to client invalid face numbers (an sigsegv when referencing pixmaps[]). This is probably what happened. Could you check you have the latest version of server? Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/DIRtHHGOa1Q2wXwRAjgNAJ40W+lrrWAayzxYyZDFakE3EeFMCQCgygr3 aj1jWhWgn8oVg7RQh5qsU1s= =ECC/ -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 9 17:25:27 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:36 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <200307092309.04378.d.delbecq@laposte.net> Message-ID: On 09-Jul-03 David Delbecq wrote: > Well unless you added smooth to mountains or water, there is no smoothed area > (yet) in the hall of selection, which is why i find it so wierd. > Note that i fixed a bug in server which appeared during add of smoothing code > and which laid to transmitting from srever to client invalid face numbers (an > sigsegv when referencing pixmaps[]). This is probably what happened. Could > you check you have the latest version of server? Todd did add smoothing to mountains.. thats why I brought it up. I just now updated the server, rebuilt, updated the client again, and rebuilt it. and still instant crash on connect. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 10 01:40:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:36 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <200307092303.24879.tchize@myrealbox.com> References: <200307081723.08781.tchize@myrealbox.com> <3F0BBC94.9030405@sonic.net> <200307092303.24879.tchize@myrealbox.com> Message-ID: <3F0D0A45.3070308@sonic.net> tchize wrote: > Well the problem is that > 1 the pic used for smoothing is not dependent on object but on it's face (an > animated object will have several smooths, one for each step of animation), > so i can't put it in the arc file. Why not? There is no reason you couldn't have multiple smooth lines that the collect script pulls out. Storing it in the arc is only a convenience - the collection of the data would just strip it out of the arch. Basically, the same thing as what happens to the animations. > 2 I assumed what you call the face file is the .png file (like > grass.base.111.png). I can't see a way to put this in the picture no, a face file is one with a .face extension. There aren't a lot of them out there - they are basically used when there are png files out there that aren't used in an arch (but may be used in maps or other places to override the image). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 10 01:41:14 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:36 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <000401c34697$020fc5e0$8ddfd1d8@KAMERIA> References: <200307081502.39247.tchize@myrealbox.com> <002801c345c5$967798c0$96dfd1d8@KAMERIA> <200307081723.08781.tchize@myrealbox.com> <3F0BBC94.9030405@sonic.net> <000401c34697$020fc5e0$8ddfd1d8@KAMERIA> Message-ID: <3F0D0A8A.2080609@sonic.net> Todd Mitchell wrote: > ----- Original Message ----- > From: "Mark Wedel" > >> I'd personally probably prefer it to be something like > > grass_sm.base.111.png > >>or the like, and have these smoothed graphics in the same location as the >>graphics they smooth (and not all dumped into one directory that is only >>indirectly associated with the graphics they smooth). >> > > > When I added some of these smoothing sets, I took it on myself to change the > name like: S_grass.base.111.png and removing the grasslike directory so that > all the images are in one directory. I think this is more along the lines > you mention. yeah - I'd actually prefer grass_S.., simply so that they are together alphabetically. > If you mean having a smooth field in the arch so archmakers can set the > smoothing they want to apply to that new object (or if they make a new > smoothing set for it), rather than having to update the server, then that > does sound like a good idea. yep - that is the idea. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 10 03:11:35 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:36 2005 Subject: [CF-Devel] CVS problems. In-Reply-To: <200307082214.37565.tchize@myrealbox.com> Message-ID: <20030710081135.68237.qmail@web21303.mail.yahoo.com> --- tchize wrote: > I dunno if it is really of any help, but i provide a snapshot of CVS at > the following page: > http://users.skynet.be/am248983/snap/index.html Thanks, I'm downloading it now. http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 10 03:40:03 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:36 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <3F0D0A45.3070308@sonic.net> References: <200307092303.24879.tchize@myrealbox.com> <3F0D0A45.3070308@sonic.net> Message-ID: <200307101040.16545.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Jeudi 10 Juillet 2003 08:40, Mark Wedel a ?crit : > tchize wrote: > > Well the problem is that > > 1 the pic used for smoothing is not dependent on object but on it's face > > (an animated object will have several smooths, one for each step of > > animation), so i can't put it in the arc file. > > Why not? There is no reason you couldn't have multiple smooth lines that > the collect script pulls out. K i could put the actual lines in the lib/smooth file in the concerned .arc files. Gime some time to adapt the script (first is garbled's bug ti fix.) > > Storing it in the arc is only a convenience - the collection of the data > would just strip it out of the arch. Basically, the same thing as what > happens to the animations. > > > 2 I assumed what you call the face file is the .png file (like > > grass.base.111.png). I can't see a way to put this in the picture > > no, a face file is one with a .face extension. There aren't a lot of > them out there - they are basically used when there are png files out there > that aren't used in an arch (but may be used in maps or other places to > override the image). What's the point? I didn't reference my smoothing pictures in any .arc or any .face file and the collect script did collect them, along with all other pngs. > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/DSZvHHGOa1Q2wXwRAl8YAJ0Y0xLZgLdpZYlL0KWKFeybYTYrVgCgiM7S dhXTh12jhIbOPsYfm6ylaFY= =KINH -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 10 04:59:59 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:36 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: References: Message-ID: <200307101200.05839.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Jeudi 10 Juillet 2003 00:25, Tim Rightnour a ?crit : > On 09-Jul-03 David Delbecq wrote: > > Well unless you added smooth to mountains or water, there is no smoothed > > area (yet) in the hall of selection, which is why i find it so wierd. > > Note that i fixed a bug in server which appeared during add of smoothing > > code and which laid to transmitting from srever to client invalid face > > numbers (an sigsegv when referencing pixmaps[]). This is probably what > > happened. Could you check you have the latest version of server? > > Todd did add smoothing to mountains.. thats why I brought it up. > > I just now updated the server, rebuilt, updated the client again, and > rebuilt it. and still instant crash on connect. > Strange i can't reproduce it. Anyway, seems Todd di make mistakes in the smooth file concerning mountains (no the right face name used, corrected it). Perhap this had lead to client crash, but am not sure at all. I just rebuild the arch file and commit along with the correct smooth file. May be this will help. If not, please send us the content of your ~/.crossfire/gdefault file so i could test with exact same configuration as you. Thanks a lot > --- > Tim Rightnour > NetBSD: Free multi-architecture OS http://www.netbsd.org/ > NetBSD supported hardware database: > http://mail-index.netbsd.org/cgi-bin/hw.cgi > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/DTkkHHGOa1Q2wXwRAos3AKDsYpfmwLXOqbw721wvTztNbK+OxgCdGf2t 9bnnGOzTNq0ZxTmi8mwkawc= =ow0n -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 10 11:44:28 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:36 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <3F053044.60805@sonic.net> References: <3F053044.60805@sonic.net> Message-ID: <200307101844.36492.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For eyes pleasure (notice the trees problem): http://users.skynet.be/am248983/smooth/mountains1_flat.png http://users.skynet.be/am248983/smooth/mountains1_smooth.png Notice also that some maps might need some slight modifications. This is the case in previous pic with this awfull hole in the mountains. I have the feeling some mountains borders seems to be sourrounded by unnatural black border http://users.skynet.be/am248983/smooth/mountains2_flat.png http://users.skynet.be/am248983/smooth/mountains2_smooth.png same impression about the black border. Anyway, nice job. Moutains was the most awfull thing to see squared. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/DZfwHHGOa1Q2wXwRAh9BAKDcyeaNaf/381/KQ04pWisGP2dSTQCeOMsJ TgT2QJqeKCRwwAJUHDD/STc= =Dvpa -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 11 00:15:06 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:36 2005 Subject: [CF-Devel] smoothing code. References: <3F053044.60805@sonic.net> <200307101844.36492.tchize@myrealbox.com> Message-ID: <000401c3476b$658b3300$6e76e2d1@KAMERIA> >Notice also that some maps might need some slight modifications. >This is the case in previous pic with this awfull hole in the mountains. >I have the feeling some mountains borders seems to be sourrounded by >unnatural black border Hmm, not bad - I will touch up the mountains. It is hard to do this blind. I assume I can compile a server now to get smoothing working? I have a few more sets to post now as well, but rebuilding my system (perhaps tonight I'll add them.) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 10 17:01:06 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:36 2005 Subject: [CF-Devel] New GFX Package 01 Message-ID: <1057874465.25571.6.camel@debian> This package replaces: - All the water (except grassponds and Blake_0 (an 1x1 lake) - All the mountains (smoother now) - All the shields (except "small shield" and "shield", "Belzebub's" just got smoothed) - Some swords: - Defender - Dragonslayer (Dragonbane). - Excalibur. - Firebrand (Flametongue). - Frostbrand. You can see a screenshot here: http://www.ayuda-es.net/~lz/01_package.png In this order: Demonspawn shield, dragon scale shield, eye shield, high shield holy shield, reflector, round shield, spiked shield Belzebub's shield, white dragon scale shield, defender, dragonbane excalibur, firebrand, frostbrand You can get the package here: http://www.ayuda-es.net/~lz/elezeta01.tar.gz Just uncompress it over your arch files (it'll overwrite the graphics). LZ (elezeta@eresmas.com). P.S: If anyone wants to open a test server, please notify me at IRC when i'm not away :P @Todd: Tell me when you replace the actual ones by the ones you like :) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 11 01:31:03 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:36 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <200307101040.16545.tchize@myrealbox.com> References: <200307092303.24879.tchize@myrealbox.com> <3F0D0A45.3070308@sonic.net> <200307101040.16545.tchize@myrealbox.com> Message-ID: <3F0E59A7.3040306@sonic.net> tchize wrote: > What's the point? I didn't reference my smoothing pictures in any .arc or any > .face file and the collect script did collect them, along with all other > pngs. > the .face files aren't need for the smoothing images. However, there are properties to images beyond just the data - magic mapping being the key one. The principle behind the face file is that there is a way to set magic mapping color for an image that is not in an archetype. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 11 07:07:23 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:36 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <000401c3476b$658b3300$6e76e2d1@KAMERIA> References: <3F053044.60805@sonic.net> <200307101844.36492.tchize@myrealbox.com> <000401c3476b$658b3300$6e76e2d1@KAMERIA> Message-ID: <200307111407.36990.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 11 Juillet 2003 07:15, Todd Mitchell a ?crit : > >Notice also that some maps might need some slight modifications. > >This is the case in previous pic with this awfull hole in the mountains. > >I have the feeling some mountains borders seems to be sourrounded by > >unnatural black border > > Hmm, not bad - I will touch up the mountains. It is hard to do this blind. > I assume I can compile a server now to get smoothing working? I have a few > more sets to post now as well, but rebuilding my system (perhaps tonight > I'll add them.) > Smoothing code seems stable enough since have corrected the bug noticed by garbled. Still have to do the relocation of the content of lib/smooth to somewhere else. I will suggest the following. adapt the collect script so it will notice line in the form smoothface XXXXX YYYYYY rip it away from object and put a line in lib/smooth in the form XXXXX YYYYYY Since some objects have animations, i think the script should be able to read several time the smoothface instruction from one object. The counter part would be, if i put the same smoothface XXX YYY in two different files, or i write in 2 different files smoothface XXX YYY and smoothface XXX ZZZ The pic the server will choose to smooth XXX (either YYY or ZZZ), will be choosen randmoly according the the behaviour of the bsearch instruction on the system (no duplicata detection). One last note, the smoothface instruction would be interpreted ONLY by collect.pl, server will still rely on the lib/smooth file to get it's instructions. It won't be possible to change the smoothface for an object (i never intended to do it since it would consume to many bandwidth for now) Does this way conform to crossfire standards (info will be located in object's .arc file, lib/smooth would be generated at the same time as the archetype and face files, and it would be possible to have several smoothface entries concerning the different faces involved in an archetype.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/DqiFHHGOa1Q2wXwRAiVcAKDfdpWf9NH8hdew5TvqqGoD6om7lgCfZpqU icTgFwazT5ZHDE8MocBHRk0= =a+pb -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 11 06:55:10 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:36 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: References: Message-ID: <200307111355.17187.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I attempted to use a newly built gcfclient against a newly built server.. > I enabled the smoothing code. not happy things resulted: <--snip--> Fixed the bug. It appeared when smoothing was activated and not images cache, which led to the client trying to draw the pixmap zero, which is a transparent one when cache is activated but a null pointer when cache is not. Corrected this so never tries to draw the pixmap 0 Have a nice day. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/DqWjHHGOa1Q2wXwRAqQEAJsHop4g6zTO+8ytdttkDy3ba3tOgACfZYdw Qk5E+FNahe5P7sqK7OeocMo= =U71S -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 11 09:34:29 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:36 2005 Subject: [CF-Devel] Compiling the server on a non-X machine Message-ID: <3F0ECAF5.8050306@komcept.com> I have a server sitting on a fast internet connection, which has been running for years, and I would like to run a crossfire server on it. It doesn't have X, or any X development libraries, but it does have many other devel libs on it. I would like to either compile the server on this machine, or compile the server remotely and staticly, so it will run on this machine. My progress so far is: ./configure ran fine from the machine itself, I used: CFLAGS="-march=i686 -O2-march=i686 -O2" CXXFLAGS="" ./configure --prefix=/home/mal/cfs No problem so far. However, make spews out this after a short time: make[2]: Entering directory `/home/mal/active/crossfire-1.5.0/crossedit/Cnv' source='CnvUtil.c' object='CnvUtil.o' libtool=no \ depfile='.deps/CnvUtil.Po' tmpdepfile='.deps/CnvUtil.TPo' \ depmode=gcc3 /bin/sh ../../utils/depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I./../include -I../../include -g -O2 -c `test -f 'CnvUtil.c' || echo './'`CnvUtil.c In file included from Cnv.h:26, from CnvUtil.c:22: ../include/Xaw.h:30:27: X11/Intrinsic.h: No such file or directory ../include/Xaw.h:31:23: X11/Shell.h: No such file or directory ../include/Xaw.h:32:28: X11/StringDefs.h: No such file or directory ../include/Xaw.h:33:31: X11/Xaw/Cardinals.h: No such file or directory ../include/Xaw.h:36:29: X11/Xaw/Command.h: No such file or directory ../include/Xaw.h:37:26: X11/Xaw/Grip.h: No such file or directory ../include/Xaw.h:38:27: X11/Xaw/Label.h: No such file or directory ../include/Xaw.h:39:26: X11/Xaw/List.h: No such file or directory ../include/Xaw.h:40:28: X11/Xaw/Panner.h: No such file or directory ../include/Xaw.h:41:30: X11/Xaw/Repeater.h: No such file or directory ../include/Xaw.h:42:31: X11/Xaw/Scrollbar.h: No such file or directory ../include/Xaw.h:43:32: X11/Xaw/StripChart.h: No such file or directory ../include/Xaw.h:44:28: X11/Xaw/Toggle.h: No such file or directory ../include/Xaw.h:47:32: X11/Xaw/MenuButton.h: No such file or directory ../include/Xaw.h:48:32: X11/Xaw/SimpleMenu.h: No such file or directory ../include/Xaw.h:49:25: X11/Xaw/Sme.h: No such file or directory ../include/Xaw.h:50:28: X11/Xaw/SmeBSB.h: No such file or directory ../include/Xaw.h:51:29: X11/Xaw/SmeLine.h: No such file or directory ../include/Xaw.h:54:31: X11/Xaw/AsciiText.h: No such file or directory ../include/Xaw.h:55:26: X11/Xaw/Text.h: No such file or directory ../include/Xaw.h:58:25: X11/Xaw/Box.h: No such file or directory ../include/Xaw.h:59:28: X11/Xaw/Dialog.h: No such file or directory ../include/Xaw.h:60:26: X11/Xaw/Form.h: No such file or directory ../include/Xaw.h:61:27: X11/Xaw/Paned.h: No such file or directory ../include/Xaw.h:62:30: X11/Xaw/Porthole.h: No such file or directory ../include/Xaw.h:63:26: X11/Xaw/Tree.h: No such file or directory ../include/Xaw.h:64:30: X11/Xaw/Viewport.h: No such file or directory make[2]: *** [CnvUtil.o] Error 1 make[2]: Leaving directory `/home/mal/active/crossfire-1.5.0/crossedit/Cnv' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/mal/active/crossfire-1.5.0/crossedit' make: *** [all-recursive] Error 1 I would be hard pressed to install any additional libraries on this machine, but still please let me know if that is indeed what is missing. On a side note, is crossfire development still going strong? The mailing list archives seem vacant to say the least! Cheers people, MAL _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 11 09:57:55 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:36 2005 Subject: [CF-Devel] Compiling the server on a non-X machine In-Reply-To: <3F0ECAF5.8050306@komcept.com> References: <3F0ECAF5.8050306@komcept.com> Message-ID: <200307111658.01795.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 11 Juillet 2003 16:34, MAL a ?crit : > I have a server sitting on a fast internet connection, which has been > running for years, and I would like to run a crossfire server on it. > > It doesn't have X, or any X development libraries, but it does have many > other devel libs on it. > > I would like to either compile the server on this machine, or compile > the server remotely and staticly, so it will run on this machine. > > My progress so far is: ./configure ran fine from the machine itself, I > used: > > CFLAGS="-march=i686 -O2-march=i686 -O2" CXXFLAGS="" ./configure > --prefix=/home/mal/cfs > > No problem so far. > > However, make spews out this after a short time: > > make[2]: Entering directory > `/home/mal/active/crossfire-1.5.0/crossedit/Cnv' source='CnvUtil.c' > object='CnvUtil.o' libtool=no \ > depfile='.deps/CnvUtil.Po' tmpdepfile='.deps/CnvUtil.TPo' \ > depmode=gcc3 /bin/sh ../../utils/depcomp \ > gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I./../include > -I../../include -g -O2 -c `test -f 'CnvUtil.c' || echo './'`CnvUtil.c > In file included from Cnv.h:26, > from CnvUtil.c:22: > ../include/Xaw.h:64:30: X11/Xaw/Viewport.h: No such file or directory > make[2]: *** [CnvUtil.o] Error 1 > make[2]: Leaving directory `/home/mal/active/crossfire-1.5.0/crossedit/Cnv' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/mal/active/crossfire-1.5.0/crossedit' > make: *** [all-recursive] Error 1 > > > I would be hard pressed to install any additional libraries on this > machine, but still please let me know if that is indeed what is missing. > > On a side note, is crossfire development still going strong? The > mailing list archives seem vacant to say the least! > > Cheers people, > MAL Crossedit is the crossfire maps editor. I comes along with the server, but it may be interesting if somone on the mailing list could remove it from the default target (perhaps adding a make crossedit to the Makefiles). Concerning your compilation, here is 2 suggestion: - - 1st if you have tools such that automake autoconf autoheader installed, edit the file Makefile.am and, in the line SUBDIRS = common random_maps socket server include lib utils doc plugin devel crossedit and remove the crossedit part of the line. Then run the script autogen.sh and rerun configure - - 2nd possibility is not to use the toplevel Makefile but instead those in subdirectories. Follow this order, everything should go well if configure script went alright: go in include directory run make; make install go in common directory run make; make install go in random_maps directory run make; make install go in socket directory run make; make install go in server directory run make; make install if you want also the python plugin and have python library go in plugin directory run make; make install if you want also the logger plugin (web interface with server stats) go in plugin_logger directory read the INSTALL file in details. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/DtB4HHGOa1Q2wXwRAi/kAJ0RB2bcxQntTA0yyPKUIsWugALYWQCg0ywF JQXEtDEO+R+k7Hffcv6gudo= =YxIE -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 11 10:04:52 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:37 2005 Subject: [CF-Devel] New GFX Package 01 In-Reply-To: <1057874465.25571.6.camel@debian> References: <1057874465.25571.6.camel@debian> Message-ID: <200307111705.04066.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 11 Juillet 2003 00:01, LZ a ?crit : > This package replaces: > - All the water (except grassponds and Blake_0 (an 1x1 lake) > - All the mountains (smoother now) > - All the shields (except "small shield" and "shield", "Belzebub's" just > got smoothed) > - Some swords: > - Defender > - Dragonslayer (Dragonbane). > - Excalibur. > - Firebrand (Flametongue). > - Frostbrand. > > You can see a screenshot here: > http://www.ayuda-es.net/~lz/01_package.png > > In this order: > > Demonspawn shield, dragon scale shield, eye shield, high shield > holy shield, reflector, round shield, spiked shield > Belzebub's shield, white dragon scale shield, defender, dragonbane > excalibur, firebrand, frostbrand Good graphics. Just a comment: I don't like the dragon scale shields. They look too common to me (this could be a wodden shield, it would be the same to me). Perhaps drawing it as made of 2 or three rows of overlapping scales would look far better. That's just my point of view. I dunno if somone shares it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/DtIaHHGOa1Q2wXwRAo28AKC4O3PXb5/Tuh1cwKY2OsGdfY1eugCfRkUG O27D6cmKr82nlhsKNu+MrwY= =Rqch -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 11 10:32:51 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:37 2005 Subject: [CF-Devel] Compiling the server on a non-X machine In-Reply-To: <200307111658.01795.tchize@myrealbox.com> References: <3F0ECAF5.8050306@komcept.com> <200307111658.01795.tchize@myrealbox.com> Message-ID: <3F0ED8A3.7010506@komcept.com> tchize wrote: > Le Vendredi 11 Juillet 2003 16:34, MAL a ?crit : > > Crossedit is the crossfire maps editor. I comes along with the server, but it > may be interesting if somone on the mailing list could remove it from the > default target (perhaps adding a make crossedit to the Makefiles). Thanks very much for your useful info. It turns out that the versions of automake/autoconf are too old to correctly rebuild configure for crossfire. Simply editing the top level Makefile to omit crossedit, did the trick. IMO, this is a bug however, because the configure script detects that no X libs are available, and should therefore disable building of crossedit. Cheers, MAL _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 11 22:33:57 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:37 2005 Subject: [CF-Devel] Compiling the server on a non-X machine References: <3F0ECAF5.8050306@komcept.com> Message-ID: <000e01c34826$6e29dbe0$6c76e2d1@KAMERIA> You should be able to edit out the reference to the crossedit directory in the Makefile - the server should actually compile and run even with these errors which is why crossedit is last in the make order... I like removing the crossedit reference personally since it is cleaner IMHO. I still think there should be a switch that doesn't do crossedit unless you specify you want to build it (or perhaps checks if the X headers is installed...) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 11 10:42:55 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:37 2005 Subject: [CF-Devel] New GFX Package 01 In-Reply-To: <200307111705.04066.tchize@myrealbox.com> Message-ID: On 11-Jul-03 tchize wrote: > I don't like the dragon scale shields. They look too common to me (this could > be a wodden shield, it would be the same to me). Perhaps drawing it as made > of 2 or three rows of overlapping scales would look far better. > That's just my point of view. I dunno if somone shares it. I have to agree with you on the dragon shields. My main problem with some of the shields here is that they are too square. They need to be taller than wide to look right. I think the swords are without question great, and should go straight in, as are the round shields and the high shield. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 11 10:44:37 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:37 2005 Subject: [CF-Devel] Compiling the server on a non-X machine In-Reply-To: <000e01c34826$6e29dbe0$6c76e2d1@KAMERIA> Message-ID: On 12-Jul-03 Todd Mitchell wrote: > I still think there should be a switch that doesn't do crossedit unless you > specify you want to build it (or perhaps checks if the X headers is > installed...) It should definately not attempt to build if X11 cannot be found. Perhaps an additional switch to configure, like --no-crossedit. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 11 22:48:06 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:37 2005 Subject: [CF-Devel] New GFX Package 01 References: <1057874465.25571.6.camel@debian> <200307111705.04066.tchize@myrealbox.com> Message-ID: <001701c34828$6817fc80$6c76e2d1@KAMERIA> Where did the axes go? those were cool. I really wanted to add then to the classic set. I would also like to add the shields and swords here to the classic set. Just a note on graphics. I hope that the classic set is not considered second string or something. The classic set is actually nicer in many ways since it has a more colourful and defined look (usually the key points of interest are exaggerated and they have a black outline). I think that many of the graphics here are perfect for the classic set since they are colourful and have outlines and a larger presence than the ones in the standard set (which is more subdued and often without a defined outlined border.) I think part of the perception problem is the names standard and classic. The other problem is the player graphics inthe classic set are not as good (although I have been trying to improve them.) So I just want to say that the classic set is not second rate and I would hope that it isn't taken as an insult, but as a compliment when I say I would like to add these to the classic set. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 11 11:13:10 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:37 2005 Subject: [CF-Devel] New GFX Package 01 References: <001701c34828$6817fc80$6c76e2d1@KAMERIA> Message-ID: <26413.1057939990@www5.gmx.net> In reply to Elezeta: The graphics are okay, but I prefer the originals in the base set. Of course I'm biased because I've drawn some of the artifact shields & weapons there. :oP What I don't like about your shields and weapons is that they look too flat and a bit unreal, at least in context with the base set drawings. The mountains have the black lines thickened and rock patterns smoothed out which also makes me slightly prefer the originals. Your water is quite nice, but somewhat too solid blue. It looks promising though. Maybe you could shape out the waves more, add some contrast and a little foam... I'm only speaking for the base set however. Due to the drawing style I think these graphics would fit better in the alternate aka classic set. While I wouldn't judge on it (because I'm no expert for classic set and not drawing for it) I also have no objections against putting the images there. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Jetzt ein- oder umsteigen und USB-Speicheruhr als Pr?mie sichern! _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 11 14:31:30 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:37 2005 Subject: [CF-Devel] Compiling the server on a non-X machine In-Reply-To: <3F0ECAF5.8050306@komcept.com> Message-ID: On Fri, 11 Jul 2003, MAL wrote: > On a side note, is crossfire development still going strong? The > mailing list archives seem vacant to say the least! IMO, the archives are not exploding with activity but I wouldn't call them vacant.. ;) -- Rick Tanner | Phone : (952) 943-8700 http://www.real-time.com | Fax : (952) 943-8500 _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 11 14:32:39 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:37 2005 Subject: [CF-Devel] speculations about the floor (elevation) In-Reply-To: <20030708082615.56699.qmail@web21302.mail.yahoo.com> Message-ID: On Tue, 8 Jul 2003, David Seikel wrote: > --- Mark Wedel wrote: > > Do I expect new continents to be added? Not really. However, when > > putting down the towns/roads, I did put up signs which basically amounted > > to 1 space = 1 mile (eg, scorn, 764 miles north or something). One could > > obviously make the case that a crossfire mile isn't the same as a human > > mile. > > At least call them something different to avoid confusion. IIRC, there's a sign outside of Scorn on the small world maps that reference a city/map location as being 1 space = 1 league. -- Rick Tanner | Phone : (952) 943-8700 http://www.real-time.com | Fax : (952) 943-8500 _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 11 16:57:07 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:37 2005 Subject: [CF-Devel] Request Message-ID: <3F0F32B3.6040400@komcept.com> Hi, I have just started running a server (mal.sh), on a machine with 32 IP aliases. The domain I wish to use for the server is mal.sh, which maps to one of the aliases, not the first IP of the network device. When my crossfire server contacts the metaserver, it does so through the first IP, (194.153.169.96), instead of the IP that mal.sh points to, (194.153.169.107). Would it be possible to add outgoing interface binding to the metaserver code in the crossfire server? The server could lookup the IP of the domain in 'metaserver_host', and then bind outgoing requests to that IP. Alternatively, an extra option could be added, maybe 'metaserver_ip', to specify the IP that crossfire should use to make connections out. The reason I mention this, is because with the current state of things, (check my server out.. it's on the public list), you cannot connect to my server by simply typing it's number, (at least from the gtk client). I assume this is because the metaserver is getting confused because the IP it has been given is .96, but mal.sh maps to .107 I can provide the code to bind outgoing connections to a specific IP, if needed. Cheers ppl, MAL _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 11 23:18:15 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:37 2005 Subject: [CF-Devel] smoothing code. In-Reply-To: <200307111407.36990.tchize@myrealbox.com> References: <3F053044.60805@sonic.net> <200307101844.36492.tchize@myrealbox.com> <000401c3476b$658b3300$6e76e2d1@KAMERIA> <200307111407.36990.tchize@myrealbox.com> Message-ID: <3F0F8C07.1060205@sonic.net> tchize wrote: > I will suggest the following. adapt the collect script so it will notice line > in the form > smoothface XXXXX YYYYYY > rip it away from object and put a line in lib/smooth in the form > XXXXX YYYYYY That looks good. > Since some objects have animations, i think the script should be able to read > several time the smoothface instruction from one object. That also seems fine. > The counter part would be, if i put the same > smoothface XXX YYY > in two different files, or i write in 2 different files > smoothface XXX YYY > and smoothface XXX ZZZ > The pic the server will choose to smooth XXX (either YYY or ZZZ), will be > choosen randmoly according the the behaviour of the bsearch instruction on > the system (no duplicata detection). Should look at some of the code in the collect.pl that deals with things like the magicmap fields. It does duplicate detection, and prints an error. After all, a case like: smoothface XXX YYY in one file, and the same entry in another file is perfectly fine. It is only a problem if there is then a: smoothface XXX ZZZ but those are easy to detect. The collect script should just throw out the duplicate (after logging an error). The person runing collect should really notice that error and fix it. Much easier to actually have error checking so that developers can more easily find these errors. > > One last note, the smoothface instruction would be interpreted ONLY by > collect.pl, server will still rely on the lib/smooth file to get it's > instructions. It won't be possible to change the smoothface for an object (i > never intended to do it since it would consume to many bandwidth for now) Yep, that is fine, and just like some of the existing fields. > > Does this way conform to crossfire standards (info will be located in object's > .arc file, lib/smooth would be generated at the same time as the archetype > and face files, and it would be possible to have several smoothface entries > concerning the different faces involved in an archetype.) It all looks fine to me. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 12 04:52:40 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:37 2005 Subject: [CF-Devel] smoothing screenshots Message-ID: <1058003559.435.16.camel@oberon.Kameria> Well things progress. I put up a wack of screen shots up at http://abraxis.sytes.net/games/cfstuff/smooth for your edification. It's not perfect, but things are improving rapidly. The biggest problem is the trees right now. Since lava works fine, next should be the waters I suppose. As you can see (#9 inside the 'lake' is a 'lake') lakes arches are pretty much dead with smoothing, they aren't needed anymore. We could start phasing them out once the code is considered reliable. Rivers maybe will be around longer (at least the narrow ones). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 13 02:34:56 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:38 2005 Subject: [CF-Devel] java editor glitch Message-ID: <1058081696.2686.6.camel@oberon.Kameria> Ah, I spoke too soon about large images being fully supported in the java editor. Here is an artifact I noticed in the map window... This is handled fine in the other panels however. -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-2.png Type: image/png Size: 145042 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030713/72049b56/Screenshot-2.png From crossfire-devel-admin at archives.real-time.com Sun Jul 13 03:36:13 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:38 2005 Subject: [CF-Devel] GTK client container apply bug patch submission Message-ID: <3F1119FD.7030200@laposte.net> Hello everyone. I made a small patch to correct the odd 'apply' behaviour on the GTK client, mainly that you can't unapply a container (switches from applied/opened to applied). What i did is simple (i'll explain even if code is pretty straightforward): I split gtk/gx11.c:close_container into 2 functions, close_container & do_close_container The first one is the reply to the server event 'container closed', sent to signal a container goes from opened to closed (and unapplied, actually). This one just clears locally the display list. The second handles the mouse click on the 'close' button, and just sends a client command 'apply ' to the server to ask for container close (this will generate a server event 'container closed', thus close_container gets called right after that). Ok, important point: I couldn't test that patch. Running under Windows, and i didn't want to mess with mingw/cygwin to try to compile the code. I do think my patch is valid (even some tabs may be weird), though. If i'm wrong on that, just kick me :-) Oh, and something else: if you look at the X11 client code, you'll see the 'close_container' is exactly how i made the GTK like, just local changes. Also the Gnome client prolly has the same bug as the GTK, since the close_container handles both the server event & the client button click. Finally, i'm sorry if the patch is weird, i couldn't find the correct diff option to strip first directory name... Thanks to all developers for the game ^_- Nicolas 'Ryo' -------------- next part -------------- diff -r crossfire-cvs-original/client/gtk/gx11.c crossfire-cvs/client/gtk/gx11.c 2761c2761 < void close_container (item *op) --- > void do_close_container (item *op) 2764a2765,2769 > } > } > > void close_container (item *op) > { 2768d2772 < } 3044c3048 < GTK_SIGNAL_FUNC(close_container), --- > GTK_SIGNAL_FUNC(do_close_container), From crossfire-devel-admin at archives.real-time.com Sun Jul 13 14:45:54 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:38 2005 Subject: [CF-Devel] java editor glitch References: <1058081696.2686.6.camel@oberon.Kameria> Message-ID: <5347.1058125554@www1.gmx.net> Todd Mitchell wrote: > Ah, I spoke too soon about large images being fully supported > in the java editor. Here is an artifact I noticed in the > map window... This is handled fine in the other panels however. The support for large images came from the Daimonin stuff. I hadn't implemented it for CF specifically, so no wonder it didn't work. Now I've updated the map drawing logic to do this correctly. Hope it works. :-) I don't know much about the big image code, so it's possible that there are exceptional cases where the editor still doesn't handle it correctly. I'll try to fix such cases when they turn up. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Jetzt ein- oder umsteigen und USB-Speicheruhr als Pr?mie sichern! _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 13 15:28:18 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:38 2005 Subject: [CF-Devel] smoothing screenshots In-Reply-To: <1058003559.435.16.camel@oberon.Kameria> Message-ID: On 12-Jul-03 Todd Mitchell wrote: > Well things progress. I put up a wack of screen shots up at So I've tried using the smoothing code, and it slows my client to an absolute crawl. So bad, that shutting it off takes 2 minutes, for all the clicks to register and the little menu to come up. I have a 1.4Ghz Athlon, so somthing isn't right here. Once it finishes smoothing an area.. it's ok for a few seconds.. but most of the time it's unusable. Admittedly though, it looks gorgeous. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 13 17:55:46 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:38 2005 Subject: [CF-Devel] Developing for Crossfire. Was: Pictures In-Reply-To: Message-ID: <20030713225546.832.qmail@web21308.mail.yahoo.com> --- Tim Rightnour wrote: > > On 08-Jul-03 David Seikel wrote: > > Do I really need to chat on IRC? One of the > > No, but one on one conversation makes discussion of your ideas go much > faster. > > > Are there other mailing lists or whatever I should be on? > > Not really.. there is a web forum somewhere.. but it's not mandatory. > This is the official discussion list. IRC and the forum are informal > discussion areas.. but alot of stuff does end up happening on the IRC bit. Since I am trapped behind these firewalls, I will have to confine my discussions to the mailing list. > About that.. is there a way we could perhaps build CVS snapshots > occasionally.. in tarball format? Just a thought. Some one is doing that, there was a URL posted to the list. So I have grabbed the most recent snapshots and looked at them on the weekend. I noticed that the bug fixes I posted a while back have not made it into CVS. Are they being looked at by the appropriate people? Did I post them correctly? What is the status of my posted bug fixes? http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 13 18:10:02 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:38 2005 Subject: [CF-Devel] Ice Castle in the Large Forest. In-Reply-To: <19307.1056187436@www67.gmx.net> Message-ID: <20030713231002.48268.qmail@web21301.mail.yahoo.com> I had to track down this old message, but it is the most appropriate. --- Andreas Vogl wrote: > David Seikel wrote: > > forest.pl is the script that creates the large forest from the Big > > World maps from the 1.5 release. > > Your forest is nice, I looked at the image you posted earlier. > Personally I found it is really a huge forest, but okay why not. > > Unfortunately there were recent changes in the area where you > put it: Brest got a mountain ring, there is a new direct road > to lake country and mountain tops generally changed from wasteland > to the white moutains. > Maybe you can check out latest cvs and try merging the forest > in there without discarding the new things. I looked at the CVS snapshot on the weekend. Since forest.pl only changes the arch used for certain types of arch, and only does so on certain maps, it looks very much as if it could be applied unmodified to the latest maps with no problems. I will actually run the script soon, to check that. The forest will end up a little smaller. Mountain amd wasteland arches are not modified by the script, so no problem there. Road arches are also not modified, and the new road still makes sense with the presence of the forest. Two of the very small patches of woodlands just inside the mountain ring may get promoted to forest by the script. http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 13 19:37:44 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:38 2005 Subject: [CF-Devel] smoothing screenshots In-Reply-To: References: Message-ID: <1058143064.3580.1.camel@oberon.Kameria> > So I've tried using the smoothing code, and it slows my client to an absolute > crawl. So bad, that shutting it off takes 2 minutes, for all the clicks to > register and the little menu to come up. I have a 1.4Ghz Athlon, so somthing > isn't right here. Once it finishes smoothing an area.. it's ok for a few > seconds.. but most of the time it's unusable. > > Admittedly though, it looks gorgeous. hmm, I didn't notice any performance problems. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Jul 14 02:37:59 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:38 2005 Subject: [CF-Devel] Ice Castle in the Large Forest. References: <20030713231002.48268.qmail@web21301.mail.yahoo.com> Message-ID: <23179.1058168279@www62.gmx.net> David Seikel wrote: > The forest will end up a little smaller. Mountain amd wasteland arches > are not modified by the script, so no problem there. Road arches are > also not modified, and the new road still makes sense with the presence > of the forest. Two of the very small patches of woodlands just inside the > mountain ring may get promoted to forest by the script. If it's easy for you, maybe you could move the forest upwards a notch. That's not terribly important, but I would prefer if there was a small space between brittany mountains and the forest. Not much, something like 20-30 tiles on average would do. The reason for this is that eventually I might want to put some small things to the north side of brittany mountains (like a tavern, mine entrance and stuff). OTOH, if you allow me to clear the forest in that area where I need it, that'd be just fine as well. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Jetzt ein- oder umsteigen und USB-Speicheruhr als Pr?mie sichern! _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Jul 14 03:09:06 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:38 2005 Subject: [CF-Devel] Ice Castle in the Large Forest. In-Reply-To: <23179.1058168279@www62.gmx.net> Message-ID: <20030714080906.63185.qmail@web21302.mail.yahoo.com> I'm doing this from the office, where I don't have a copy of my Large Forest stuff, so some of the script details are from memory. --- Andreas Vogl wrote: > If it's easy for you, maybe you could move the forest upwards a notch. > That's not terribly important, but I would prefer if there was a small > space between brittany mountains and the forest. Not much, something > like 20-30 tiles on average would do. The current size and placement is almost entirely the result of trying to automate it with the script. If my forest makes it into CVS, then I can throw the script away. While writing the script, I choose most of the southern area simply to aviod large straight lines along the edge of the forest (the script converts whole map files). Moving the entire thing would not be easy, since the script just converts existing non forest tiles (desert, grass, etc) to forest type tiles by changing the arch used. All this would be lot clearer if you look at the script, it is not complex. > OTOH, if you allow me to clear the forest in that area where I need it, > that'd be just fine as well. I'm really only interested in the northern half, clear away as much as you want in the south. As for me allowing it, didn't know I had that much power B-). If no one objects, someone with CVS write access should just run the script, commit the resulting maps to CVS, and throw away the script. Then we can all get on with editing the large forest down to size B-). I don't have CVS write access myself, or even a read only account (hint hint). One possibly usefull change to the script before running it and throwing it away would be to have some of the grass and tree type tiles not converted on a random basis. This would break up the forest a little, giving us clearings and things. Or clearings could be added manually afterwards. The other usefull change would be to remove some southern maps from the maps that are converted to give you room, but then you will have to manually unstraighten the long straight forest edges you will get from the script. Let me know what happens. http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 15 05:04:52 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:38 2005 Subject: [CF-Devel] someone did try his code? Message-ID: <200307151205.00563.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just cheked out the latest cvs version of server to apply the corrections made recently to a bug. After a cvs update, where ther was any apparent problems, at compile time i receive this error: if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include - -DDATADIR=\"/home/crossfire//share/crossfire\" - -DCONFDIR=\"/home/crossfire//etc/crossfire\" - -DLIBDIR=\"/home/crossfire//lib/crossfire\" - -DLOCALDIR=\"/home/crossfire//var/crossfire\" -DPLUGIN_SUFFIX=\".so\" -g - -O2 -MT weather.o -MD -MP -MF ".deps/weather.Tpo" \ -c -o weather.o `test -f 'weather.c' || echo './'`weather.c; \ then mv ".deps/weather.Tpo" ".deps/weather.Po"; \ else rm -f ".deps/weather.Tpo"; exit 1; \ fi weather.c: In function `smooth_wind': weather.c:2561: error: `WIND_FACTOR' undeclared (first use in this function) weather.c:2561: error: (Each undeclared identifier is reported only once weather.c:2561: error: for each function it appears in.) make[1]: *** [weather.o] Error 1 So to be sure this was not some local modification on mids, staying around, i deleted the file weather.c and run cvs update again. I still got the same error but at line 2560. I know this is not possible to test all possibilites around a modified code, and that sometimes bug may still hide somewhere. But could developpers at least check code compile and run just a bit. And before commiting new or modified code, do always a checkout of less than 2 minutes ago, and if cvs did patch some files in the checkout process, do a make clean ; make to check it still compiles. thanks for not having this kind of problem in the future! - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/E9HKHHGOa1Q2wXwRAlZ9AJ0eTK6Z9oCUYwio74cBGzkNkcvJ3wCeJ82w JnILk0rqqtkICyalimU9ZdU= =U0tz -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 15 07:04:24 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:38 2005 Subject: [CF-Devel] smoothing screenshots In-Reply-To: <1058003559.435.16.camel@oberon.Kameria> References: <1058003559.435.16.camel@oberon.Kameria> Message-ID: <200307151404.32117.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Samedi 12 Juillet 2003 11:52, Todd Mitchell a ?crit : > Well things progress. I put up a wack of screen shots up at > http://abraxis.sytes.net/games/cfstuff/smooth for your edification. > It's not perfect, but things are improving rapidly. The biggest problem > is the trees right now. > > Since lava works fine, next should be the waters I suppose. > > As you can see (#9 inside the 'lake' is a 'lake') lakes arches are > pretty much dead with smoothing, they aren't needed anymore. If you are speaking of the lake bug in the town hall, this is a problem related to the sea face. That's why i suggested to have the sea at top level with an empty smooth face. So sea border will not be softened. Sure we could remove lake items and use the smoothing code to achieve same results (like for the rivers), but i think the smoothing should be kept as optionnal for the client. Moreover this mean redrawing parts of the map, which may take time. There is an additionnal problem. At some places, we have sea covering another item. This was not visible until smoothing was there. Let's say a mapmaker did put a sea block ontop of a grass block. This is a mistake which is invisible. But if there is no grass block below the neighbor sea blocks, we will see grass border appear from nowhere. This may have been the case with lots of other objects, but i realize the issue is more important with sea. Seems some mapmaker have done thing like putting grass then sea blocks to create lake than decided to extend a bit the lake on top of grass. This operation end up as a mess in smoothing operations, as you could have seen in city hall in Scorn. I strongly recommend to put sea at toplevel, at least on a temporary basis. This is, i think, the best way, for now, to work around the problem until maps have been fixed. > We could > start phasing them out once the code is considered reliable. Rivers > maybe will be around longer (at least the narrow ones). We should be sure there is no more speed problems related with smoothing code client side. > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/E+3NHHGOa1Q2wXwRArdRAKCzSbN6lu2DJMTjCw0Z/7h/cvCa/wCgwtwd ULzQp5yiy0iBiUc1XhiyTY8= =Adqu -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 15 07:36:56 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:38 2005 Subject: [CF-Devel] smoothing work in progress Message-ID: <200307151437.03137.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 i have converted the script collect.pl to extract smoothing informations from the archetype to give an example, here is a line extracted from the grass.arc file: smoothface grass.111 grass_S.111 I have updated the archetype file so they now contain the information which was present in the smooth file. Now GFXers shouldn't bother about editing lib/smooth, since it will be generated from archetype files. Instead they should add the appropriate smoothface entries in the archetype to indicated the smooth pictures. During the process, i noticed that pstone_1 was considered as having a smoothlevel but there was no entries in lib/smooth neither was there a file named pstone_1_S. This is most obviously an error. Or perhaps work still in progress, who knows. Could it be corrected? - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/E/VuHHGOa1Q2wXwRAmPRAKDL+AvXFqCQo6u0VWIPOvHxfuuWdgCfdy/4 Io//GOLCwlX17E8iQ0jea7o= =Jwnd -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 15 07:51:11 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:38 2005 Subject: [CF-Devel] smoothing screenshots In-Reply-To: References: Message-ID: <200307151451.17101.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Dimanche 13 Juillet 2003 22:28, Tim Rightnour a ?crit : > On 12-Jul-03 Todd Mitchell wrote: > > Well things progress. I put up a wack of screen shots up at > > So I've tried using the smoothing code, and it slows my client to an > absolute crawl. So bad, that shutting it off takes 2 minutes, for all the > clicks to register and the little menu to come up. I have a 1.4Ghz Athlon, > so somthing isn't right here. Once it finishes smoothing an area.. it's ok > for a few seconds.. but most of the time it's unusable. > The fact is, in the worst cases, when drawing a square of the system, smoothing need to draw 8 times more than the classical way. This is because in the worst case a square is surrounded by 8 different smoothing squares. However, checks here show, in some case where half the picture is made of identical sea (this mean cases where on half the picture ther is no smoothing to do) a high peak in XFree86 CPU consumption. I investigate it to see if i didn't make something wrong. Don't forget the client uses gtk, which is not known to be a fast always changing pictures, library. SDL client should work far better. Anyway, there is perhaps someting to fix there. up to 15% CPU consumption on a 2Ghz processor is too much. > Admittedly though, it looks gorgeous. > > --- > Tim Rightnour > NetBSD: Free multi-architecture OS http://www.netbsd.org/ > NetBSD supported hardware database: > http://mail-index.netbsd.org/cgi-bin/hw.cgi > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/E/jEHHGOa1Q2wXwRAkwnAJ9qd8qG4nriDmC1snofrdavnCnnIwCfXBfw iTT+M5BGX5ljWkgYJ2780Z8= =tFYY -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 15 10:28:32 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:38 2005 Subject: [CF-Devel] Developing for Crossfire. Was: Pictures In-Reply-To: <20030713225546.832.qmail@web21308.mail.yahoo.com> References: <20030713225546.832.qmail@web21308.mail.yahoo.com> Message-ID: <200307151728.40760.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I noticed that the bug fixes I posted a while back have not made it into > CVS. Are they being looked at by the appropriate people? Did I post them > correctly? What is the status of my posted bug fixes? > I suppose you are speaking about the bug fixes pack you send containing weather tweaks, inv_checkers bugs fix and weather visualisation system... I'll take a look > > http://mobile.yahoo.com.au - Yahoo! Mobile > - Check & compose your email via SMS on your Telstra or Vodafone mobile. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/FB2lHHGOa1Q2wXwRAjg0AKDn4Wer4rgaZDZxQIw9BUom7EwQMQCg5nPw kz+HDZa7QyvdMKHoxjY31b4= =7N5v -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 15 22:47:11 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:38 2005 Subject: [CF-Devel] smoothing screenshots References: <1058003559.435.16.camel@oberon.Kameria> <200307151404.32117.tchize@myrealbox.com> Message-ID: <001801c34b4c$f16f3260$6c76e2d1@KAMERIA> >If you are speaking of the lake bug in the town hall, this is a >problem related to the sea face. That's why i suggested to have the >sea at top level with an empty smooth face. So sea border will not be >softened. I still don't agree, I am having better results with the water being low although I have rethought it a bit to make a couple things lower than water (an arch for beaches - this mainly because if the wave thing I am playing with). If water is not very low then you will have a problem with chopping off every bridge and pier or building on the water edge. The way lakes are done represents an attempt at smoothing which should be replaced by this new method of smoothing. The way lakes are done now is half assed and prone to error as you point out - requiring two arches to get the same effect as here. If the client turns off smoothing the lakes should have square borders. It looks a bit worse, but no worse than any other tiled object without smoothing. The solution is to fix the lakes, not have two types of landscape smoothing. Rivers are another story... >I strongly recommend to put sea at toplevel, at least on a temporary basis. >This is, i think, the best way, for now, to work around the problem until >maps have been fixed. Like I said - this will wreck things like bridges and docs and buildings... Also if the water is higher the edges are passable because you are overlapping ground, where if the water is lower, the edges are not passable since it is land overlapping water - having the water lower will be less work to fix maps than having it higher... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 15 11:20:16 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:39 2005 Subject: [CF-Devel] smoothing screenshots In-Reply-To: <001801c34b4c$f16f3260$6c76e2d1@KAMERIA> References: <1058003559.435.16.camel@oberon.Kameria> <200307151404.32117.tchize@myrealbox.com> <001801c34b4c$f16f3260$6c76e2d1@KAMERIA> Message-ID: <200307151820.24249.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Mercredi 16 Juillet 2003 05:47, Todd Mitchell a ?crit : > >If you are speaking of the lake bug in the town hall, this is a > >problem related to the sea face. That's why i suggested to have the > >sea at top level with an empty smooth face. So sea border will not be > >softened. > > I still don't agree, I am having better results with the water being low > although I have rethought it a bit to make a couple things lower than water > (an arch for beaches - this mainly because if the wave thing I am playing > with). If water is not very low then you will have a problem with chopping > off every bridge and pier or building on the water edge. The way lakes are > done represents an attempt at smoothing which should be replaced by this > new method of smoothing. The way lakes are done now is half assed and > prone to error as you point out - requiring two arches to get the same > effect as here. If the client turns off smoothing the lakes should have > square borders. It looks a bit worse, but no worse than any other tiled > object without smoothing. The solution is to fix the lakes, not have two > types of landscape smoothing. Rivers are another story... > > >I strongly recommend to put sea at toplevel, at least on a temporary > > basis. This is, i think, the best way, for now, to work around the > > problem until maps have been fixed. > > Like I said - this will wreck things like bridges and docs and buildings... > Also if the water is higher the edges are passable because you are > overlapping ground, where if the water is lower, the edges are not passable > since it is land overlapping water - having the water lower will be less > work to fix maps than having it higher... > > You don't understand my point. water wouldn't overlap anything since it has a transparent border. So sea will still keep it's ugly squared border (can be worked around since the real sea coast if made of shallow_sea, not deep sea) and nothing would overlap it (correct problem in town hall) if you look at http://abraxis.sytes.net/games/cfstuff/smooth/trans9.png you may notice this is not a problem which appear from time to time but it is regular. And the port in Scorn now look weird now (well i suppose you intend to raise the roads level above the sea) And i suggested it could be set as temporary. Cause reworking all maps to track those problems may be a pain and will need time. > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/FCnGHHGOa1Q2wXwRAikGAKCU2n82BXTBno4u4OJtiZ4shkjThACgnbvd XOjXcS8iR0P7nHMZflihpqM= =QCQ6 -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 15 23:18:19 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:39 2005 Subject: [CF-Devel] smoothing screenshots In-Reply-To: <200307151820.24249.tchize@myrealbox.com> References: <1058003559.435.16.camel@oberon.Kameria> <200307151404.32117.tchize@myrealbox.com> <001801c34b4c$f16f3260$6c76e2d1@KAMERIA> <200307151820.24249.tchize@myrealbox.com> Message-ID: <1058329099.442.6.camel@oberon.Kameria> > You don't understand my point. water wouldn't overlap anything since it has a > transparent border. So sea will still keep it's ugly squared border (can be > worked around since the real sea coast if made of shallow_sea, not deep sea) > and nothing would overlap it (correct problem in town hall) > if you look at http://abraxis.sytes.net/games/cfstuff/smooth/trans9.png you > may notice this is not a problem which appear from time to time but it is > regular. And the port in Scorn now look weird now (well i suppose you intend > to raise the roads level above the sea) > And i suggested it could be set as temporary. Cause reworking all maps to > track those problems may be a pain and will need time. > > I wonder if the default behaviour of arches without a smoothing level should be to float to the top instead of getting covered by objects with smoothing levels. Say something has not smoothing level maybe it should get set to 255 by default. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 16 01:53:00 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:39 2005 Subject: [CF-Devel] Developing for Crossfire. Was: Pictures In-Reply-To: <20030713225546.832.qmail@web21308.mail.yahoo.com> References: <20030713225546.832.qmail@web21308.mail.yahoo.com> Message-ID: <3F14F64C.5060201@sonic.net> David Seikel wrote: > --- Tim Rightnour wrote: > > >>On 08-Jul-03 David Seikel wrote: >> >>> Do I really need to chat on IRC? One of the >> >>No, but one on one conversation makes discussion of your ideas go much >>faster. >> >> >>>Are there other mailing lists or whatever I should be on? >> >>Not really.. there is a web forum somewhere.. but it's not mandatory. >>This is the official discussion list. IRC and the forum are informal >>discussion areas.. but alot of stuff does end up happening on the IRC > > bit. > > Since I am trapped behind these firewalls, I will have to confine my > discussions to the mailing list. The irc mailing list is most useful to ask quick opinions/questions (how do I do this, what do you think of this idea, what do you think of this graphic). The mailing list must still be used to mention 'big' changes to the code. the definition of 'big' is of course a matter of opinion. But there are probably lots of people who read the mailing list and can provide input than those that are on irc. > > >>About that.. is there a way we could perhaps build CVS snapshots >>occasionally.. in tarball format? Just a thought. > > > Some one is doing that, there was a URL posted to the list. So I have > grabbed the most recent snapshots and looked at them on the weekend. It looks like you can also grab tarballs of all of the crossfire stuff at: http://cvs.sourceforge.net/cvstarballs/crossfire-cvsroot.tar.gz Note this is the _complete_ tarball of everything - maps, server, client, editor, as well as histories and so on. As such, it comes in at 110 MB. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 16 06:21:56 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:39 2005 Subject: [CF-Devel] smoothing screenshots In-Reply-To: <1058329099.442.6.camel@oberon.Kameria> References: <1058003559.435.16.camel@oberon.Kameria> <200307151820.24249.tchize@myrealbox.com> <1058329099.442.6.camel@oberon.Kameria> Message-ID: <200307161322.02851.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Mercredi 16 Juillet 2003 06:18, Todd Mitchell a ?crit : > > You don't understand my point. water wouldn't overlap anything since it > > has a transparent border. So sea will still keep it's ugly squared border > > (can be worked around since the real sea coast if made of shallow_sea, > > not deep sea) and nothing would overlap it (correct problem in town hall) > > if you look at http://abraxis.sytes.net/games/cfstuff/smooth/trans9.png > > you may notice this is not a problem which appear from time to time but > > it is regular. And the port in Scorn now look weird now (well i suppose > > you intend to raise the roads level above the sea) > > And i suggested it could be set as temporary. Cause reworking all maps to > > track those problems may be a pain and will need time. > > I wonder if the default behaviour of arches without a smoothing level > should be to float to the top instead of getting covered by objects with > smoothing levels. Say something has not smoothing level maybe it should > get set to 255 by default. > > This lead to a problem concerning the smoothlevel 0. Should things at smoothlevel 0 being set to level 0 only to say they can be overlapped? Should i use your idea but instaed of using level 255 use level 0? If it is we report the problem to smoothlevel 1 which couldn't spread over smoothlevel 0 due to exception law and could over other smoothlevel since it's not higher than them. However idea to check, i'll try to see wht it give. This will mean loosing 1 smoothlevel, but only one is not important. This could solve the sea problem too. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/FTVYHHGOa1Q2wXwRAhfXAJ9J2DLP3rrjiXvHD5NnbdZRihBFOACg1J53 x+T0w+or4h8CyJBkQ7oZO2Y= =8TmZ -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 16 21:48:47 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:39 2005 Subject: [CF-Devel] smoothing screenshots References: <1058003559.435.16.camel@oberon.Kameria> <200307151820.24249.tchize@myrealbox.com> <1058329099.442.6.camel@oberon.Kameria> <200307161322.02851.tchize@myrealbox.com> Message-ID: <001001c34c0d$f3179280$5976e2d1@KAMERIA> >> if the default behaviour of arches without a smoothing level >> should be to float to the top instead of getting covered by objects with >> smoothing levels. Say something has not smoothing level maybe it should > >get set to 255 by default. >This lead to a problem concerning the smoothlevel 0. Should things at >smoothlevel 0 being set to level 0 only to say they can be overlapped? Should >i use your idea but instaed of using level 255 use level 0? If it is we >report the problem to smoothlevel 1 which couldn't spread over smoothlevel 0 >due to exception law and could over other smoothlevel since it's not higher >than them. 0 or 255 doesn't matter to me, just if the default behaviour is that if there is no smoothlevel value it is on top. >However idea to check, i'll try to see wht it give. This will mean loosing 1 >smoothlevel, but only one is not important. This could solve the sea problem >too. It would solve the problem with one off arches getting covered anyway, perhaps someone makes a special kind of swamp or tree or road or something, they wouldn't need to worry about smoothlevels. Meanwhile all the commoinly used arches still have proper order assigned. BTW - I think things are starting to look very nice with the smoothing, still a lot of tweeking yet to go, but I spent some time just looking around and liked how it's turning out. The marshes are particularily nice looking. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 16 11:42:14 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:39 2005 Subject: [CF-Devel] smoothing screenshots In-Reply-To: <001001c34c0d$f3179280$5976e2d1@KAMERIA> References: <1058003559.435.16.camel@oberon.Kameria> <200307161322.02851.tchize@myrealbox.com> <001001c34c0d$f3179280$5976e2d1@KAMERIA> Message-ID: <200307161842.21573.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Jeudi 17 Juillet 2003 04:48, Todd Mitchell a ?crit : > >> if the default behaviour of arches without a smoothing level > >> should be to float to the top instead of getting covered by objects with > >> smoothing levels. Say something has not smoothing level maybe it should > >> > > >get set to 255 by default. > > > >This lead to a problem concerning the smoothlevel 0. Should things at > >smoothlevel 0 being set to level 0 only to say they can be overlapped? > > Should > > >i use your idea but instaed of using level 255 use level 0? If it is we > >report the problem to smoothlevel 1 which couldn't spread over smoothlevel > > 0 > > >due to exception law and could over other smoothlevel since it's not > > higher than them. > > 0 or 255 doesn't matter to me, just if the default behaviour is that if > there is no smoothlevel value it is on top. > > >However idea to check, i'll try to see wht it give. This will mean loosing > > 1 > > >smoothlevel, but only one is not important. This could solve the sea > > problem > > >too. > > It would solve the problem with one off arches getting covered anyway, > perhaps someone makes a special kind of swamp or tree or road or something, > they wouldn't need to worry about smoothlevels. Meanwhile all the > commoinly used arches still have proper order assigned. > > BTW - I think things are starting to look very nice with the smoothing, > still a lot of tweeking yet to go, but I spent some time just looking > around and liked how it's turning out. The marshes are particularily nice > looking. > first tests looks bad. however, this is probably due to the fact most ground items have, for now, the default smoothlevel of 0 since not yet done. Second, this does not automagically remove the lakes problem. Perhaps editing the lake arch to put it's smoothlevel back to 0 or editing all buggy maps to set 'law of exception' on their lake by lowering their lake objects to smoothlevel 0. However, the idea you present is interresting. This will prevent future buggy behaviour with, for example, new trees and so on. I don't commit the code immediatly since, until all floors objects have a resonnable smoothlevel, using zero as on top without smotthing case brings more problems than it solve. When enoug floor object have their smoothlevel, i'll submit the change. For now, the only result is going back to the old blocky picture almost eveyrwhere. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/FYBrHHGOa1Q2wXwRAhM+AKDE37Yslqsh2URWDxJtxo02Bn7n0wCgue79 sGsl0VnGW3JLgeYx0rGJTi0= =TAxB -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 16 23:10:10 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:39 2005 Subject: [CF-Devel] smoothing screenshots In-Reply-To: <200307161842.21573.tchize@myrealbox.com> References: <1058003559.435.16.camel@oberon.Kameria> <200307161322.02851.tchize@myrealbox.com> <001001c34c0d$f3179280$5976e2d1@KAMERIA> <200307161842.21573.tchize@myrealbox.com> Message-ID: <3F1621A2.6080208@sonic.net> Haven't been paying tons of attention to this, but just a note - If your wanting objects by default to have some behaviour, then the value you should rely on for a default is zero. Eg, if you want objects with no smoothlevel value specifically set to be on top, then that value should be 0. Because it isn't all that reasonable to expect that 255 by a default for all objects (because by definition, you are now having to change all the archs to have a smoothlevel 255 in them). IT just makes more sense for default values to be zero. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 16 23:51:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:39 2005 Subject: [CF-Devel] speculations about the floor (elevation) In-Reply-To: References: Message-ID: <3F162B35.8040900@sonic.net> Rick Tanner wrote: > On Tue, 8 Jul 2003, David Seikel wrote: > > >> --- Mark Wedel wrote: >> >>>Do I expect new continents to be added? Not really. However, when >>>putting down the towns/roads, I did put up signs which basically amounted >>>to 1 space = 1 mile (eg, scorn, 764 miles north or something). One could >>>obviously make the case that a crossfire mile isn't the same as a human >>>mile. >> >>At least call them something different to avoid confusion. > > > IIRC, there's a sign outside of Scorn on the small world maps that > reference a city/map location as being 1 space = 1 league. We could certianly use the term 'league' on the big world maps also. A crossfire league could be most any distance. For that matter, webster defines leagues as being from 2.4 to 4.6 statue miles. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 17 01:21:30 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:39 2005 Subject: [CF-Devel] Compiling the server on a non-X machine In-Reply-To: References: Message-ID: <3F16406A.1020503@sonic.net> Tim Rightnour wrote: > On 12-Jul-03 Todd Mitchell wrote: > >>I still think there should be a switch that doesn't do crossedit unless you >>specify you want to build it (or perhaps checks if the X headers is >>installed...) > > > It should definately not attempt to build if X11 cannot be found. Perhaps an > additional switch to configure, like --no-crossedit. Well, there is a reason that crossedit is last in the list of things it builds - that way, if you are missing the libraries, the failure to compile doesn't prevent anything else from compiling. I unfortunately think that such conditional compilation for that is less easy than most things. It's very easy to put in #ifdef HAVE_FEATURE #endif blocks. The problem here is this is an entire directly you want to skip if you don't have X, and a directory to process if you do have it. The current way the automake files are set up makes this less than easy I think. And since automake is in use, it presumes that when you say the target is 'crossedit', you will always want to compile it. I don't know - there may be some way to deal with this in automake. But I don't know how, and given how often this comes up, and the fact it is really only an annoyance and not a significant problem, it isn't really worth my time to figure it out. Having a flag to configure doesn't really change the complexity of this - if configure could do the right thing on a flag, it could also do the right thing if it is missing the libraries. The reason that the client can be clever about not compiling differnt things based on libraries is that it doesn't use automake - it only uses autoconf. Thus, more of the makefile is written by hand (vs automake), so it is possible to put in more checks/controls. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 17 01:56:03 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:39 2005 Subject: [CF-Devel] smoothing screenshots In-Reply-To: <3F1621A2.6080208@sonic.net> References: <1058003559.435.16.camel@oberon.Kameria> <200307161842.21573.tchize@myrealbox.com> <3F1621A2.6080208@sonic.net> Message-ID: <200307170856.12781.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Jeudi 17 Juillet 2003 06:10, Mark Wedel a ?crit : > Haven't been paying tons of attention to this, but just a note - > > If your wanting objects by default to have some behaviour, then the value > you should rely on for a default is zero. > > Eg, if you want objects with no smoothlevel value specifically set to be > on top, then that value should be 0. Because it isn't all that reasonable > to expect that 255 by a default for all objects (because by definition, you > are now having to change all the archs to have a smoothlevel 255 in them). > > IT just makes more sense for default values to be zero. > > That's what i thought too. Since, by default loader.l put a zero value for smoothlevel. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/FkiJHHGOa1Q2wXwRAjJHAJ0fR6t3Lox3yuo5Sjx/CaH4Ek6legCg2ppN NPu1Hw7O6PNQX1DeoBV2X7Q= =1nuv -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 17 02:27:41 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:39 2005 Subject: [CF-Devel] smoothing screenshots, feature request In-Reply-To: <200307170856.12781.tchize@myrealbox.com> References: <1058003559.435.16.camel@oberon.Kameria> <200307161842.21573.tchize@myrealbox.com> <3F1621A2.6080208@sonic.net> <200307170856.12781.tchize@myrealbox.com> Message-ID: <3F164FED.9050803@laposte.net> Hey guys/gals. Been more or less looking at smoothing screenshots, sound like nice things. But please, can't you make smoothing a client option? I mean, that's prolly something that eats some CPU, right? And my poor computer is already having troubles with CF, sometimes.... specially with ball lightning producing a zillion lines in a few secs... So i agree for smoothing, but please put a way to disable it ^_^ Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 17 04:33:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:39 2005 Subject: [CF-Devel] smoothing screenshots, feature request In-Reply-To: <3F164FED.9050803@laposte.net> References: <1058003559.435.16.camel@oberon.Kameria> <200307170856.12781.tchize@myrealbox.com> <3F164FED.9050803@laposte.net> Message-ID: <200307171134.05719.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Jeudi 17 Juillet 2003 09:27, Nicolas Weeger a ?crit : > Hey guys/gals. > > Been more or less looking at smoothing screenshots, sound like nice things. > But please, can't you make smoothing a client option? > I mean, that's prolly something that eats some CPU, right? > And my poor computer is already having troubles with CF, sometimes.... > specially with ball lightning producing a zillion lines in a few secs... > So i agree for smoothing, but please put a way to disable it ^_^ > > Nicolas 'Ryo' Mmmmmm, it IS a client option since the beginning. It is not activated by default go to configure -> map & image to change it. > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Fm2LHHGOa1Q2wXwRApydAJ4oMsuSQMzQ1q36bLp6dGMwJQl5cgCgn/DJ TLQld0HVy2sxOTQvxUvjFOA= =cDHt -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 17 05:55:31 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:40 2005 Subject: [CF-Devel] Error in CFJavaEditor Message-ID: <200307171255.38832.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I wanted to update the pictures drawn by the CFJavaEditor. So i run the collect.pl script on the arch/ directory and then copied the crossfire.0 archetype and treasures to /resource/conf. when i run the editor, which is configured to load arch from collection, i get the following error in console: [java] ###### [java] # Some image-paths contain illegal characters in your [java] # collected png file 'crossfire.0'! Re-collect the arches [java] # for better loading performance. [java] ###### i located in source file where this comes from and printed wrong face names. It appear the face names looks something like: [java] face-path contained '.': 333 [java] PNG [java] ? [java] [java] IHDR Tg?tEXtCreation Time*tIME,\A pHYs [java] ? [java] ?B?40PLTE???+)%9)@3+t$ [java] hVEssw????????????????????tRNS????????????????#]?IDATx??? [java] @?? [java] ??B?YB_@??H.>HH There are a lot of them. i lost about half of picture in the editor due to those read error. Since recente changes in arch involved creating 512x64 png pictures, which may be a lot, could it be possible the editor did only load a part of thisbig picture than seeing the rest as a face name, leading to those error? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/FoCnHHGOa1Q2wXwRAqP1AKDzxhg3I9JrEB9E8z1CDQVKTclToQCg4Jvt Wb/SW6ozx1C/sBwpFukVyDc= =Un8j -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 17 07:38:36 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:40 2005 Subject: [CF-Devel] smoothing screenshots In-Reply-To: <1058003559.435.16.camel@oberon.Kameria> References: <1058003559.435.16.camel@oberon.Kameria> Message-ID: <200307171438.42851.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 New screenshot with new pictures. http://users.skynet.be/am248983/smooth/smooth3.png -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/FpjRHHGOa1Q2wXwRAmu9AKCLJ9qeFlZATm5v12SWK/fW12lTJgCfXOoR q1iMEQ16UHUbLVG6+Ta3eKU= =zvH8 -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 17 09:59:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:40 2005 Subject: [CF-Devel] Error in CFJavaEditor References: <200307171255.38832.tchize@myrealbox.com> Message-ID: <22534.1058453945@www58.gmx.net> tchize wrote: > > I wanted to update the pictures drawn by the CFJavaEditor. So i run > the collect.pl script on the arch/ directory and then copied the > crossfire.0 archetype and treasures to /resource/conf. when i > run the editor, which is configured to load arch from collection, > i get the following error in console: > [...] > Since recente changes in arch involved creating 512x64 png > pictures, which may be a lot, could it be possible the editor > did only load a part of thisbig picture than seeing the rest > as a face name, leading to those error? By the time I wrote the parser there were no images bigger than square 32. I think the problem lies in the following line in ArchObjectStack.java: stream.getBufferedStream().mark(10000); // mark position This limits the stream buffer to 10000 chars which is probably not enough for your large images. Increase the value to something like 100000 and see if it works then. Will you put these large images in the game, or are they for testing only? AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Jetzt ein- oder umsteigen und USB-Speicheruhr als Pr?mie sichern! _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 17 22:03:20 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:40 2005 Subject: [CF-Devel] smoothing screenshots References: <1058003559.435.16.camel@oberon.Kameria> <200307161842.21573.tchize@myrealbox.com> <3F1621A2.6080208@sonic.net> <200307170856.12781.tchize@myrealbox.com> Message-ID: <003301c34cd9$25f17060$42f7d1d8@KAMERIA> >> IT just makes more sense for default values to be zero. >That's what i thought too. Since, by default loader.l put a zero value for >smoothlevel. This is the right way yes, I misspoke. But my point being that the *default* action should be "nothing overlaps me". If arches without a specified smoothlevel are assigned smoothlevel 0 then I would want smoothlevel zero to mean no overlaping this tile (which does not seem to be the case currently.) Once again I am not precise enough in my communication, I mentioned smoothlevel 255 as a metaphor for this behaviour since it is the highest smoothlevel which cannot be overlapped (?), not as an actual value for the arches. >> Should > >i use your idea but instaed of using level 255 use level 0? If it is we > >report the problem to smoothlevel 1 which couldn't spread over smoothlevel 0 > I yes this is the right way to do it. The initial proposal mentioned using 0 as a 'off switch' for smoothing no? That is the behaviour I would like to see anyway - smoothlevel 0 (or no smoothlevel) means 'do not smooth me' and 'do not overlap me'. I think this is actually what you are planning to do - so I'll shutup now. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 17 22:12:57 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:40 2005 Subject: [CF-Devel] Error in CFJavaEditor References: <200307171255.38832.tchize@myrealbox.com> <22534.1058453945@www58.gmx.net> Message-ID: <003801c34cda$7d65a220$42f7d1d8@KAMERIA> > By the time I wrote the parser there were no images bigger > than square 32. > > I think the problem lies in the following line > in ArchObjectStack.java: > stream.getBufferedStream().mark(10000); // mark position > > This limits the stream buffer to 10000 chars which is probably > not enough for your large images. > Increase the value to something like 100000 and see if it works then. > > Will you put these large images in the game, or are > they for testing only? > Even if the smoohting templates aren't directly incorporated (the editor wouldn't need to display them to mapmakers but it might use them to do smoothing...), I expect some of the larger pictures will eventually get reconsolodated into a single PNG. The larger ones will be done first likely since they are hardest to maintain in sections. They may not be quite 512x64 but they will be large. Actually that brings up a question - how big can things get? How about a 512x64 giant worm? This is especially interesting line of thought when you see some of the newer clients with really large map display areas. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 17 22:41:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:40 2005 Subject: [CF-Devel] smoothing screenshots References: <1058003559.435.16.camel@oberon.Kameria> <200307171438.42851.tchize@myrealbox.com> Message-ID: <004101c34cde$6a641360$42f7d1d8@KAMERIA> > > New screenshot with new pictures. > http://users.skynet.be/am248983/smooth/smooth3.png This isn't the best representation of the smoothing code since it is missing a lot of stuff that has smoothing, has a lot of stuff that isn't getting smoothed yet and the layout doesn't seem to capture the more interesting interactions between them. I have seen some pretty nice landscape on my local server (the beaches around Port Joseph, the forests and marshlands near Hermes' Inn, the narrow mountain passes along the imperial highway...) I'll try to update the screenshots at http://abraxis.sytes.net/games/cfstuff/smooth tonight with some newer vacation photos... One thing to mention however, untill you see the waves rolling in you havent gotten the full picture. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 17 13:56:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:40 2005 Subject: [CF-Devel] Error in CFJavaEditor In-Reply-To: <003801c34cda$7d65a220$42f7d1d8@KAMERIA> References: <200307171255.38832.tchize@myrealbox.com> <22534.1058453945@www58.gmx.net> <003801c34cda$7d65a220$42f7d1d8@KAMERIA> Message-ID: <200307172056.11836.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 18 Juillet 2003 05:12, Todd Mitchell a ?crit : > > By the time I wrote the parser there were no images bigger > > than square 32. > > > > I think the problem lies in the following line > > in ArchObjectStack.java: > > stream.getBufferedStream().mark(10000); // mark position > > > > This limits the stream buffer to 10000 chars which is probably > > not enough for your large images. > > Increase the value to something like 100000 and see if it works then. > > > > Will you put these large images in the game, or are > > they for testing only? > > Even if the smoohting templates aren't directly incorporated (the editor > wouldn't need to display them to mapmakers but it might use them to do > smoothing...), I expect some of the larger pictures will eventually get > reconsolodated into a single PNG. The larger ones will be done first > likely since they are hardest to maintain in sections. They may not be > quite 512x64 but they will be large. Actually that brings up a question - > how big can things get? How about a 512x64 giant worm? This is especially > interesting line of thought when you see some of the newer clients with > really large map display areas. > > This doesn't solve the problem. Today's crossfire.0 file can't be used with the CFJavaEditor > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/FvFJHHGOa1Q2wXwRAnsnAKDqn1V3KRYa/oY+is4MIElhOefjtgCgu1C6 gTxfULWOnTkfOLC/EOgam4g= =vLjg -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 17 14:58:22 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:40 2005 Subject: AW: [CF-Devel] Error in CFJavaEditor In-Reply-To: <003801c34cda$7d65a220$42f7d1d8@KAMERIA> Message-ID: Remember thats the server has to send this pictures too and he has buffer ranges too. Not sure but it was something about 15-20k when i remember right. > > > > By the time I wrote the parser there were no images bigger > > than square 32. > > > > I think the problem lies in the following line > > in ArchObjectStack.java: > > stream.getBufferedStream().mark(10000); // mark position > > > > This limits the stream buffer to 10000 chars which is probably > > not enough for your large images. > > Increase the value to something like 100000 and see if it works then. > > > > Will you put these large images in the game, or are > > they for testing only? > > > > Even if the smoohting templates aren't directly incorporated (the editor > wouldn't need to display them to mapmakers but it might use them to do > smoothing...), I expect some of the larger pictures will eventually get > reconsolodated into a single PNG. The larger ones will be done > first likely > since they are hardest to maintain in sections. They may not be quite > 512x64 but they will be large. Actually that brings up a > question - how big > can things get? How about a 512x64 giant worm? This is especially > interesting line of thought when you see some of the newer clients with > really large map display areas. > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 17 15:54:24 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:40 2005 Subject: [CF-Devel] Error in CFJavaEditor References: <200307172056.11836.tchize@myrealbox.com> Message-ID: <31985.1058475264@www26.gmx.net> tchize wrote: > This doesn't solve the problem. Today's crossfire.0 file can't be > used with the CFJavaEditor I had no idea the problem occured with current crossfire.0. Didn't realize that from your first mail somehow. Anyways, the problem was caused by the images paths in crossfire.0. The pathes used to start with "./arch/...", but in the latest collect file they're just "arch/...". Well, it's not easy to pick the face names as character-data out of the byte-data from the pngs. Especially because, as you see, I really had no idea on which parts of the format I can rely on and on which I cannot. So I fixed it now on cvs and hope it works. Also increased the buffer size to make larger images work, hopefully. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Jetzt ein- oder umsteigen und USB-Speicheruhr als Pr?mie sichern! _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 17 19:46:34 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:40 2005 Subject: AW: [CF-Devel] Error in CFJavaEditor In-Reply-To: References: Message-ID: <1058489194.395.4.camel@oberon.Kameria> On Thu, 2003-07-17 at 15:58, Michael Toennies wrote: > Remember thats the server has to send this pictures too and he > has buffer ranges too. Not sure but it was something about 15-20k > when i remember right. I actually ran into this too when doing a 96x96x4 dragon animation - I think it was along 12k lines, but cant remember exactly. In this case converting it to 8bits dropped it below the threshold, but as you imply, it will come up if the graphics are reintegrated. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 18 00:08:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:40 2005 Subject: [CF-Devel] updates to smoothing Message-ID: <1058504938.395.15.camel@oberon.Kameria> More on the smoothing: I reworked the numbers, moved some items around a bit in the ordering based on how things seem to look. I think it is coming along much nicer than expected. Here is a sketch outline of the numbering I used: swamp - 5 beach - 10 sea - 20 floors/roads - 30 grass - 40 hills - 60 mountains - 100 forests - 125 trees - 140 I updated the screenshots at http://abraxis.sytes.net/games/cfstuff/smooth to show off some more interesting landscape features. Except for the river shot, these are real bigworld maps (although some with minor modifications like beaches and removing the existing lake 'corners'...) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 18 01:05:54 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:40 2005 Subject: [CF-Devel] icons Message-ID: <1058508354.431.25.camel@oberon.Kameria> Hi, I thought someone out there might like to have a copy of the icons I am using for the Java editor and the crossfire client on my system. They're quick and dirty, but like the man says, "they have spiwit". -------------- next part -------------- A non-text attachment was scrubbed... Name: javaeditor_icon.png Type: image/png Size: 5695 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030718/dc94daf5/javaeditor_icon.png -------------- next part -------------- A non-text attachment was scrubbed... Name: CFicon.png Type: image/png Size: 4599 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030718/dc94daf5/CFicon.png From crossfire-devel-admin at archives.real-time.com Fri Jul 18 01:41:06 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:40 2005 Subject: [CF-Devel] Error in CFJavaEditor In-Reply-To: <003801c34cda$7d65a220$42f7d1d8@KAMERIA> References: <200307171255.38832.tchize@myrealbox.com> <22534.1058453945@www58.gmx.net> <003801c34cda$7d65a220$42f7d1d8@KAMERIA> Message-ID: <3F179682.2060601@sonic.net> Todd Mitchell wrote: > > Even if the smoohting templates aren't directly incorporated (the editor > wouldn't need to display them to mapmakers but it might use them to do > smoothing...), I expect some of the larger pictures will eventually get > reconsolodated into a single PNG. The larger ones will be done first likely > since they are hardest to maintain in sections. They may not be quite > 512x64 but they will be large. Actually that brings up a question - how big > can things get? How about a 512x64 giant worm? This is especially > interesting line of thought when you see some of the newer clients with > really large map display areas. There are two real limits: 1) The size of the image itself. For practical purposes, this would be a bit less than 64k (max packet size is 64k, and you need a few bytes for other data). In addition to that, I believe that when the server sends an image to the client, it only uses 2 bytes for how big the image is. So having a bigger packet size doesn't fix that problem. Note that such big images could still have a problem in other regards (if such a large image was sent during play, that could create a bit of latency). But if the user downloads all the images first, that isn't a big deal. 2) The number of spaces the image expands. This is currently defined to be 6 spaces (really 7 - it is 6 off the edge of the map). So this effectively means a 192x192 image. At some level, images bigger than that may not make a lot of sense - after all, the player may not run with the full 25x25 map, and at some level, scale is relative - some of the very big monsters right now can even seem a bit big. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 18 03:18:14 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:41 2005 Subject: [CF-Devel] icons In-Reply-To: <1058508354.431.25.camel@oberon.Kameria> References: <1058508354.431.25.camel@oberon.Kameria> Message-ID: <200307181018.21353.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 18 Juillet 2003 08:05, Todd Mitchell a ?crit : > Hi, > I thought someone out there might like to have a copy of the icons I am > using for the Java editor and the crossfire client on my system. > They're quick and dirty, but like the man says, "they have spiwit". Hey i like them :P -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/F61LHHGOa1Q2wXwRAqVlAJ9wXmZynXi0pur0CPV69N9Eseu38gCgwZdr W0du4wMoC+1bclWvO1TAZzA= =moDk -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 19 00:29:36 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:41 2005 Subject: [CF-Devel] feature request: change character password Message-ID: Per popular request, and a generally good idea (IMO) - what about adding the capability for players/characters to change their own password? Since this will also attribute to forgotten passwords, what about the ability for a person with DM access to reset a player's password? This is beyond my coding ability, so I'm posting it on here to see if anyone else can implement it. Thanks. -- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 19 01:47:54 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:41 2005 Subject: [CF-Devel] someone did try his code? In-Reply-To: <200307151205.00563.tchize@myrealbox.com> Message-ID: <20030719064754.3048.qmail@web21309.mail.yahoo.com> --- tchize wrote: > I just cheked out the latest cvs version of server to apply the > corrections > made recently to a bug. After a cvs update, where ther was any apparent > problems, at compile time i receive this error: > weather.c: In function `smooth_wind': > weather.c:2561: error: `WIND_FACTOR' undeclared (first use in this > function) That answers part of my question about my weather patches. WIND_FACTOR is a define I created that should be defined in include/tod.h. Looks like my weather patch was partially applied, or I forgot to include the tod.h patch. At any rate - /* This is a multiplier for the wind caused by pressure differences. * The type of overal climate you get depends on this. * Too little wind, and the rain hugs the coast. * Too much wind, and there are hurricanes and blizzards everywhere. * 1 is too little. */ #define WIND_FACTOR 4.0 http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 19 01:51:07 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:41 2005 Subject: [CF-Devel] Developing for Crossfire. Was: Pictures In-Reply-To: <200307151728.40760.tchize@myrealbox.com> Message-ID: <20030719065107.3303.qmail@web21309.mail.yahoo.com> --- tchize wrote: > > I noticed that the bug fixes I posted a while back have not made it > > into CVS. Are they being looked at by the appropriate people? Did I > > post them correctly? What is the status of my posted bug fixes? > > I suppose you are speaking about the bug fixes pack you send containing > weather tweaks, inv_checkers bugs fix and weather visualisation system... Yep. > I'll take a look Thanks. http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 19 21:20:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:41 2005 Subject: [CF-Devel] updates to smoothing In-Reply-To: <1058504938.395.15.camel@oberon.Kameria> References: <1058504938.395.15.camel@oberon.Kameria> Message-ID: <1058667648.5799.0.camel@debian> > I updated the screenshots at > http://abraxis.sytes.net/games/cfstuff/smooth to show off some more > interesting landscape features. Except for the river shot, these are > real bigworld maps (although some with minor modifications like beaches > and removing the existing lake 'corners'...) Hmmm, the clearer water seems to be ice, make it darker... just a bit clearer than the "sea" _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 19 22:59:03 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:41 2005 Subject: [CF-Devel] updates to smoothing In-Reply-To: <1058667648.5799.0.camel@debian> References: <1058504938.395.15.camel@oberon.Kameria> <1058667648.5799.0.camel@debian> Message-ID: <1058673543.3383.14.camel@oberon.Kameria> fair enough, I made it bluer. See bluewaters.jpg > > I updated the screenshots at > > http://abraxis.sytes.net/games/cfstuff/smooth to show off some more > > interesting landscape features. Except for the river shot, these > are > > real bigworld maps (although some with minor modifications like > beaches > > and removing the existing lake 'corners'...) > > Hmmm, the clearer water seems to be ice, make it darker... just a bit > clearer than the "sea" > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 20 17:03:52 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:41 2005 Subject: [CF-Devel] updates to smoothing In-Reply-To: <1058673543.3383.14.camel@oberon.Kameria> References: <1058504938.395.15.camel@oberon.Kameria> <1058667648.5799.0.camel@debian> <1058673543.3383.14.camel@oberon.Kameria> Message-ID: <1058738632.16892.0.camel@debian> El dom, 20-07-2003 a las 05:59, Todd Mitchell escribi?: > fair enough, I made it bluer. See bluewaters.jpg > > > > I updated the screenshots at > > > http://abraxis.sytes.net/games/cfstuff/smooth to show off some more > > > interesting landscape features. Except for the river shot, these > > are > > > real bigworld maps (although some with minor modifications like > > beaches > > > and removing the existing lake 'corners'...) > > > > Hmmm, the clearer water seems to be ice, make it darker... just a bit > > clearer than the "sea" > > > > Still seems to be ice for me :/ Make it a mixture 50% of the clearer and the normal... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 20 18:43:25 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:41 2005 Subject: AW: [CF-Devel] Error in CFJavaEditor In-Reply-To: References: Message-ID: <1058744605.393.203.camel@oberon.Kameria> Here is a definite word on the subject. During server startup I got this message when I made the University into one image (was a 10k image - 160x128 256 colours)... read_client_images: length not valid 10256 > 10000 So it looks like 10000 bytes is the image size limit. So I dropped it down to 128 colours and squeeked it in. BTW this causes the server to abort, something to keep in mind for all you RGB jockies out there... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Jul 21 05:18:00 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:41 2005 Subject: [CF-Devel] updates to smoothing References: <1058738632.16892.0.camel@debian> Message-ID: <28250.1058782680@www66.gmx.net> LZ wrote: > > > Hmmm, the clearer water seems to be ice, make it darker... just a bit > > > clearer than the "sea" > > > > > Still seems to be ice for me :/ Make it a mixture 50% of the clearer and > the normal... > That new water is nice. I think the shallow water looking too "white" is a result of the lightness being turned up. To counter this effect, increase both contrast and saturation. That will leave your image with a light color but with full contrast and "color strength". AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Jetzt ein- oder umsteigen und USB-Speicheruhr als Pr?mie sichern! _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 22 08:35:16 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:41 2005 Subject: [CF-Devel] Trap suggestions Message-ID: <3F1D3D94.6060301@laposte.net> Hello everyone. Here's a simple suggestion concerning runes/traps. When disarming, say the name of the rune you disarm / fail to disarm. It'll be more fun than seeing 'you successfully disarm it!' or 'you fail to disarm it!'. And it's not that as if we are giving information away, if the player really wants to see what runes s/he disarmed, search before, disarm, search after & do a mental diff of the rune list ^_^ Just my 2 cents of ? Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 25 00:01:50 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:41 2005 Subject: [CF-Devel] banish command Message-ID: <1059109309.2458.9.camel@oberon.Kameria> OK, so I wrote a command so that DM's can banish players which is basically kicking them off the server and putting their IP into the ban_file. It's all good and works except for the fact that when you kick a player it goes into the play_again function so they aren't really disconnected - this means they bypass the ban_file as long as they don't disconnect their client. I think that command_kick should disconect the player that is kicked myself, but am not sure how to best change that (or if I should). I would rather change kick than write an new player ending routine since I am guessing that program exit points like this should be few and well maintained... So I'm putting this up for criticism since it is a bit more complex than the no_shout thing and involves writing to a file and other stuff which is pretty new to me in CF. If it's ok, I'll put it up. Here is the command: int command_banish (object *op, char *params) { player *pl; FILE *bannedfile; char buf[MAX_BUF]; if (!params) { new_draw_info(NDI_UNIQUE, 0,op,"Usage: ban ."); return 1; } pl = get_other_player_from_name(op, params); if (!pl) return 1; sprintf (buf, "%s/%s", settings.confdir, BANFILE); if ((bannedfile = fopen(buf, "a")) == NULL) { LOG (llevDebug, "Could not find file Banned file.\n"); new_draw_info(NDI_UNIQUE,0,op,"Could not find file Banned file."); return(0); } fprintf(bannedfile,"*@%s\n",pl->socket.host); LOG (llevDebug, "! %s banned %s from IP: %s.\n", op->name, pl->ob->name, pl->socket.host); new_draw_info_format(NDI_UNIQUE | NDI_RED, 0,op,"You banish %s", pl->ob->name); new_draw_info_format(NDI_UNIQUE | NDI_ALL | NDI_RED, 5, op, "%s banishes %s from the land!", op->name, pl->ob->name); command_kick(op, pl->ob->name); fclose(bannedfile); return 1; } _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 25 01:39:36 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:41 2005 Subject: [CF-Devel] banish command In-Reply-To: <1059109309.2458.9.camel@oberon.Kameria> References: <1059109309.2458.9.camel@oberon.Kameria> Message-ID: <3F20D0A8.9060704@sonic.net> Todd Mitchell wrote: > OK, so I wrote a command so that DM's can banish players which is > basically kicking them off the server and putting their IP into the > ban_file. One problem the code as written (or other code as written) is that the ban_file doesn't sit in the /var tree, but instead /etc (these are really derived from configure directories - I think /etc is considered the configuration duration, and /var is the dynamic directory). This may be an issue in that I believe that files in /etc (and /share) are not required to be writable by a running server. This may not actually be an issue for any server that actually runs, but if the ban_file is writable from a running server, it should probably get moved into the var tree. As for killing off a socket, just set pl->socket->status = Ns_Dead (might not have all the variable names set right there, but that should be a good approximation). The socket code will see the socket is marked dead, and do appropriate cleanup (disconnect, save player, etc). The actual socket code doesn't really care why the socket is now dead - Ns_Dead can also be set if the socket falsl too far behind in processing information from the server. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 25 02:01:27 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:41 2005 Subject: AW: [CF-Devel] Error in CFJavaEditor In-Reply-To: <1058744605.393.203.camel@oberon.Kameria> References: <1058744605.393.203.camel@oberon.Kameria> Message-ID: <3F20D5C7.8030309@sonic.net> Todd Mitchell wrote: > Here is a definite word on the subject. During server startup I got > this message when I made the University into one image (was a 10k image > - 160x128 256 colours)... > > read_client_images: length not valid 10256 > 10000 > > So it looks like 10000 bytes is the image size limit. > > So I dropped it down to 128 colours and squeeked it in. > > BTW this causes the server to abort, something to keep in mind for all > you RGB jockies out there... As a note, I'd say that one should always make the file as small as possible, presuming it doesn't effect image quality. Eg, if only using 64 colors, save it as a 64 color image. There are benefits everyplace for doing so. Now I'm not sure how PNG stores its data. I'd guess that reducing to 128 colors made it small enough because it eliminated some number of colors, not because it was a more efficient image format. BTW, the 10000 byte limit is just a define - MAX_IMAGE_SIZE in socket/image.c. I'd expect that could be increased with no issues at all. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 25 05:12:54 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:41 2005 Subject: [CF-Devel] banish command In-Reply-To: <3F20D0A8.9060704@sonic.net> References: <1059109309.2458.9.camel@oberon.Kameria> <3F20D0A8.9060704@sonic.net> Message-ID: <200307251213.00025.d.delbecq@laposte.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 25 Juillet 2003 08:39, Mark Wedel a ?crit : > Todd Mitchell wrote: > > OK, so I wrote a command so that DM's can banish players which is > > basically kicking them off the server and putting their IP into the > > ban_file. > > > > One problem the code as written (or other code as written) is that the > ban_file doesn't sit in the /var tree, but instead /etc (these are really > derived from configure directories - I think /etc is considered the > configuration duration, and /var is the dynamic directory). This may be an > issue in that I believe that files in /etc (and /share) are not required to > be writable by a running server. This may not actually be an issue for any > server that actually runs, but if the ban_file is writable from a running > server, it should probably get moved into the var tree. > > As for killing off a socket, just set pl->socket->status = Ns_Dead (might > not have all the variable names set right there, but that should be a good > approximation). > > The socket code will see the socket is marked dead, and do appropriate > cleanup (disconnect, save player, etc). The actual socket code doesn't > really care why the socket is now dead - Ns_Dead can also be set if the > socket falsl too far behind in processing information from the server. > > I think the ban file in /etc should be a permanent ban file used for problems like crossfire hacking attempt and so on. This sohuld contain only ip we really would NEVER want again in crossfire. The bans used in crossfire as dm should be able to be on a temporal bassi (like for 24 hours), this would prevent a ban file containing a complete listing of ips from a specific user's ISP, which would prevent other users from this ISP to connect (do not underestimate a kid wanting to bring problems). To do this an additionnal file in /var which would be maintained in crossfire and updated from time to time to delete old enties could be usefull. This may be easily done my maintaining those in memory, read the file only at server lunch (eg after a crash) and to writte to it only when the list in memory has changed. What do you think about this? (a bit more complex but also more flexible) Perhaps a 'remove character' command could be usefull but i would find it more funny to send the player in jail with a no_shout call too :) Concerning the problem of kick command, i think simply closing the associated socket should be enough, since this would force client to reconnect. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/IQKqHHGOa1Q2wXwRAh6BAJ9X81qtlvWRN1tGJyBvLF3kW6CZYACeJa1z 0cKRItYlcsNZ6zpx74+BSro= =apze -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 25 05:16:52 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:41 2005 Subject: [CF-Devel] banish command In-Reply-To: <3F20D0A8.9060704@sonic.net> References: <1059109309.2458.9.camel@oberon.Kameria> <3F20D0A8.9060704@sonic.net> Message-ID: <200307251213.00025.d.delbecq@laposte.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 25 Juillet 2003 08:39, Mark Wedel a ?crit : > Todd Mitchell wrote: > > OK, so I wrote a command so that DM's can banish players which is > > basically kicking them off the server and putting their IP into the > > ban_file. > > > > One problem the code as written (or other code as written) is that the > ban_file doesn't sit in the /var tree, but instead /etc (these are really > derived from configure directories - I think /etc is considered the > configuration duration, and /var is the dynamic directory). This may be an > issue in that I believe that files in /etc (and /share) are not required to > be writable by a running server. This may not actually be an issue for any > server that actually runs, but if the ban_file is writable from a running > server, it should probably get moved into the var tree. > > As for killing off a socket, just set pl->socket->status = Ns_Dead (might > not have all the variable names set right there, but that should be a good > approximation). > > The socket code will see the socket is marked dead, and do appropriate > cleanup (disconnect, save player, etc). The actual socket code doesn't > really care why the socket is now dead - Ns_Dead can also be set if the > socket falsl too far behind in processing information from the server. > > I think the ban file in /etc should be a permanent ban file used for problems like crossfire hacking attempt and so on. This sohuld contain only ip we really would NEVER want again in crossfire. The bans used in crossfire as dm should be able to be on a temporal bassi (like for 24 hours), this would prevent a ban file containing a complete listing of ips from a specific user's ISP, which would prevent other users from this ISP to connect (do not underestimate a kid wanting to bring problems). To do this an additionnal file in /var which would be maintained in crossfire and updated from time to time to delete old enties could be usefull. This may be easily done my maintaining those in memory, read the file only at server lunch (eg after a crash) and to writte to it only when the list in memory has changed. What do you think about this? (a bit more complex but also more flexible) Perhaps a 'remove character' command could be usefull but i would find it more funny to send the player in jail with a no_shout call too :) Concerning the problem of kick command, i think simply closing the associated socket should be enough, since this would force client to reconnect. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/IQOZHHGOa1Q2wXwRAs3mAKDX6jtEPN1Y5yNKy/Yn4zdGW0AnOgCfTQCJ PD040TrJuauO0jB7R4hNIyU= =ranb -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 25 05:32:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:41 2005 Subject: [CF-Devel] Adding improvments Message-ID: <200307251232.13551.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would like to add the following improvement to the crossfire client/server protocol: 1) Using the new mapextended command add a new sub command which would allow server to send the NPC dialogs and the say/shout commands localized on the mp when possible or (if it is simpler, not yet checked) to modify a bit the current NDI_* command to include relative localisation when possible. 2) Add new entries to the current command used to request for username/password. This command is supposed to ask the client to draw data in a specific dialog. This is used in username requesting, password, magic map, and i think the stats changing at the creation of player. I would like to be able to send the text read from scroll and book in a specific dialog so client could be able to put a scroll or a book in front of player in which he could read and turn the pages (little work for server, more impressive client side :P ). This could be extended to monuments and signs, to motd and letters. 3) The client now handles the animations in inventory windows. I would like to use the mapextended command to send animations informations to the client concerning the map too. This could prevent to have the server send a big part of the map at each sea animation change or each time the fire in your burning hands change. The server would just send the animation of the object and the speed of animation. The client could easily calculated the current step of anilmation using this information. And this should correct to problem of animation desynchro at map borders in the big world :). All this work could be done on the client and the protocol level so the different guis would only see the classical 'mapredraw' commands. If you have any suggestions/comment before i start the work, i ask you to send them during this week-end (since am not here to receive them ;-) ) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/IQcqHHGOa1Q2wXwRAtCSAJ9raIMq0tpRK+0HCCAabo2XkUTregCdFfIE l7ffWyzVGM8KN6upW0egGeA= =NoIy -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 25 07:01:18 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:41 2005 Subject: [CF-Devel] Adding improvments Message-ID: <1059134478.cad92fe0yann.chachkoff@myrealbox.com> >I would like to add the following improvement to the >crossfire client/server protocol: >1) Using the new mapextended command add a new sub >command which would allow >server to send the NPC dialogs and the say/shout >commands localized on the mp >when possible or (if it is simpler, not yet checked) >to modify a bit the >current NDI_* command to include relative >localisation when possible. Such work is already under way on my side (alongside the matching client implementation in the new SDL client). Strategy used: Add a new setting parameter. If the parameter is activated, send a new command instead of drawinfo. New command listing: extmessage Type is the type of message, as 16bits. Maybe a bit large and could probably be reduced to 8. Parms are the message parameters. Includes things like DX,DY,Volume for local messages ("say" and the likes). Content and length vary according to Type. Message is the message text itself. >2) Add new entries to the current command used to >request for >username/password. This command is supposed to ask >the client to draw data in >a specific dialog. This is used in username >requesting, password, magic map, >and i think the stats changing at the creation of >player. I would like to be >able to send the text read from scroll and book in a >specific dialog so >client could be able to put a scroll or a book in >front of player in which he >could read and turn the pages (little work for >server, more impressive client >side :P ). This could be extended to monuments and >signs, to motd and >letters. If you're thinking about some kind of extended query/reply pair of commands, well, such work is already under way on my side alongside with the matching client implementation (Yes, again the SDL new client code). Strategy used: setting activating the new command set instead of the old ones. New command listing: extquery Follows the same spirit as extmessage above. >3) The client now handles the animations in inventory >windows. I would like to >use the mapextended command to send animations >informations to the client >concerning the map too. This could prevent to have Such work is already under way on my side alongside the matching client implementation (In the new SDL client code). >If you have any suggestions/comment before i start >the work, i ask you to send >them during this week-end (since am not here to >receive them ;-) ) It is said that great minds always cross each other. Looks specially true in that case. Point (1) and (2) are at the beta-test stage already (the GTK backport has yet to be done, and the current client implementation doesn't (yet) open a new window to display specific things - instead it uses different colors) Point (3) was about 50% done; however, since I didn't yet attempted to recover those source files from the dying hard drive, I currently cannot tell if it is still available or if it will have to be written again. Don't expect answers before Monday if I'm lucky with data hunting. (Yes, I was working without telling anyone. And before someone else asks, there's also some re-attempt around custom dungeon building, and maybe an implementable way to adapt CF to smooth moves. So now you know what I'm doing during my holidays) (Oh, and I nearly forgot some new pictures for the logger as well) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 25 07:36:25 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:42 2005 Subject: [CF-Devel] Adding improvments In-Reply-To: <1059134478.cad92fe0yann.chachkoff@myrealbox.com> References: <1059134478.cad92fe0yann.chachkoff@myrealbox.com> Message-ID: <200307251436.33223.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 25 Juillet 2003 14:01, Yann Chachkoff a ?crit : > >I would like to add the following improvement to the >crossfire > > client/server protocol: > > > > > >1) Using the new mapextended command add a new sub >command which would > > allow server to send the NPC dialogs and the say/shout >commands > > localized on the mp when possible or (if it is simpler, not yet checked) > > >to modify a bit the current NDI_* command to include relative > > >localisation when possible. > > Such work is already under way on my side (alongside the matching client > implementation in the new SDL client). > > Strategy used: Add a new setting parameter. If the parameter is activated, > send a new command instead of drawinfo. > > New command listing: > > extmessage > > Type is the type of message, as 16bits. Maybe a bit large and could > probably be reduced to 8. > > Parms are the message parameters. Includes things like DX,DY,Volume for > local messages ("say" and the likes). Content and length vary according to > Type. Message is the message text itself. > > >2) Add new entries to the current command used to >request for > >username/password. This command is supposed to ask >the client to draw > > data in a specific dialog. This is used in username >requesting, > > password, magic map, and i think the stats changing at the creation of > > >player. I would like to be able to send the text read from scroll and > > book in a >specific dialog so client could be able to put a scroll or a > > book in >front of player in which he could read and turn the pages > > (little work for >server, more impressive client side :P ). This could be > > extended to monuments and >signs, to motd and letters. > > If you're thinking about some kind of extended query/reply pair of > commands, well, such work is already under way on my side alongside with > the matching client implementation (Yes, again the SDL new client code). > > Strategy used: setting activating the new command set instead of the old > ones. > > New command listing: > > extquery In fact i thought about using the actual one since there is already a 'type' parameter followed by the data itself. Could you think about sending your actual stage of work so i could take a look at it and make suggestion/changes (is there a way to identify the type of book the user is reading so we could change the pages pictures, ...?) > > Follows the same spirit as extmessage above. > > >3) The client now handles the animations in inventory >windows. I would > > like to use the mapextended command to send animations >informations to > > the client concerning the map too. This could prevent to have > > > Such work is already under way on my side alongside the matching client > implementation (In the new SDL client code). > > >If you have any suggestions/comment before i start >the work, i ask you to > > send them during this week-end (since am not here to >receive them ;-) ) > > It is said that great minds always cross each other. Looks specially true > in that case. Point (1) and (2) are at the beta-test stage already (the GTK > backport has yet to be done, and the current client implementation doesn't > (yet) open a new window to display specific things - instead it uses > different colors) > > Point (3) was about 50% done; however, since I didn't yet attempted to > recover those source files from the dying hard drive, I currently cannot > tell if it is still available or if it will have to be written again. Don't > expect answers before Monday if I'm lucky with data hunting. And once again, no backups (neither back cups) :) > > (Yes, I was working without telling anyone. And before someone else asks, > there's also some re-attempt around custom dungeon building, and maybe an > implementable way to adapt CF to smooth moves. So now you know what I'm > doing during my holidays) interresting about smooth moves (want to take a look) > > (Oh, and I nearly forgot some new pictures for the logger as well) > > > Am out of work? So i think i'll buy a microphone a squeak a bit. This should makes better sounds than the actual ones. I really would like a copy of your server/SDL client so i could work on it too (Want to check the skinnable part, or do it if it's not yet done). By the way, for saturday, the train is at 9:40 with possible delay of 5 to 15 minutes due to some guys working somewhere along the way. (just didn't want to send an additionnal mail). And little brother brings his *thing* so we need 3 seats in car (well if there's less seats, the *thing* can walk or take the bus :P ) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/ISROHHGOa1Q2wXwRAmkkAJ9pCSEwsimqgaRk/arCBMgL/EEcbQCfRiUk UizzFoJaUqduyBwjklZvIAU= =Rr2d -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 25 07:40:36 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:42 2005 Subject: [CF-Devel] banish command In-Reply-To: <200307251213.00025.d.delbecq@laposte.net> References: <1059109309.2458.9.camel@oberon.Kameria> <3F20D0A8.9060704@sonic.net> <200307251213.00025.d.delbecq@laposte.net> Message-ID: <20030725124036.GA2343@ds217-115-141-205.dedicated.hosteurope.de> On Fri, Jul 25, 2003 at 12:16:52PM +0200, tchize wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Le Vendredi 25 Juillet 2003 08:39, Mark Wedel a ?crit : > > Todd Mitchell wrote: > > > OK, so I wrote a command so that DM's can banish players which is > > > basically kicking them off the server and putting their IP into the > > > ban_file. > > Since many players are using DSL lines, it's trivial to go offline and online again to get another IP from the provider's IP range. So the ban_file is useless here. I would rather prefer sending them to jail. Or if the _player_ should be banned (not his _host_), then some ban_flag should be set and saved in the player file, to prevent logins. Bye Jochen -- Jochen Suckfuell --- http://www.suckfuell.net/jochen/ --- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 25 07:46:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:42 2005 Subject: [CF-Devel] =?iso-8859-1?Q?Features_suggestions?= Message-ID: Hi. I've been playing with alchemy lately, and thus writing down (using 'inscription' skill) the stuff i find. But the list is now too long & won't fit on a scroll, so i must use 2. Hence this feature suggestion: ability to rename an item. This way I'll make 'formuleas in A', 'formuleas in B' and so on. Having 10+ 'scroll' with different things isn't exactly fun to handle ^_^ But since some parts of the CF code use the name (for instance weapon enchantment by a god), i suggest only the following items may be renamed: * containers (so you can have a 'quiver of fire arrows' and a 'quiver of cold arrows'). This would potentially include bookshelves too (maybe by picking'em up first, to 'mark' the item you wanna rename?), so you can sort your junk more easily, and more precisely FIND it again easily :-) * non-magical scrolls/books where you can write what you want What do you think of that? I may just attempt to code that if no one does it (though i'd hafta kick myself first to actually find a way to compile & test the server, either under w32 or using some emulators to run linux...). Nicolas '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-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 25 21:55:34 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:42 2005 Subject: [CF-Devel] banish command References: <1059109309.2458.9.camel@oberon.Kameria> <3F20D0A8.9060704@sonic.net> <200307251213.00025.d.delbecq@laposte.net> <20030725124036.GA2343@ds217-115-141-205.dedicated.hosteurope.de> Message-ID: <001e01c35321$632b15a0$8ef7d1d8@KAMERIA> > Since many players are using DSL lines, it's trivial to go offline and > online again to get another IP from the provider's IP range. So the > ban_file is useless here. Yes and it is almost just as trivial to get a new IP using dialup. Well I only have a few things to reply to that: 1. It is anoying to the player to banish them since they have to get a new IP - hopefully anoying enough to to make them rethink their behaviour. It is not supposed to be security, it is just to give the DM more effective police power. > I would rather prefer sending them to jail. Or if the _player_ should be > banned (not his _host_), then some ban_flag should be set and saved in > the player file, to prevent logins. 2. Jailing the player's character (PC) is preferable but serves a different purpose. Kicking a player is ok but they can just instantly reconnect. Banishing a player is a stronger way to kick a player off the server. If you want to set a ban on a PC is is better to just send them to jail. Banish is more for dealing with players than for PCs, if you have some goon constanly loggin in and making new characters just to make trouble at least with Banish you can make it harder for them to do this. Slow them down and hopefully they will go away. It is not meant to replace server admin role in setting up blocks of banned IPs and the DM does not see the player's IP. The server logs will show if there is a problem. From crossfire-devel-admin at archives.real-time.com Fri Jul 25 10:36:51 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:42 2005 Subject: [CF-Devel] Adding improvments In-Reply-To: <200307251232.13551.tchize@myrealbox.com> Message-ID: On 25-Jul-03 tchize wrote: > 2) Add new entries to the current command used to request for > username/password. This command is supposed to ask the client to draw data in > a specific dialog. This is used in username requesting, password, magic map, > and i think the stats changing at the creation of player. I would like to be > able to send the text read from scroll and book in a specific dialog so > client could be able to put a scroll or a book in front of player in which he > could read and turn the pages (little work for server, more impressive client > side :P ). This could be extended to monuments and signs, to motd and > letters. As long as it's optional. Having a window pop up every time I walked over a sign would make me have to kill someone. As a side note.. it would be nice if there was a simple text edit widget, something that could be used to allow players to create complex scrolls/books/signs, or edit a post on a message board. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 25 22:38:59 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:42 2005 Subject: [CF-Devel] Adding improvments References: <200307251232.13551.tchize@myrealbox.com> Message-ID: <002d01c35327$738c2460$8ef7d1d8@KAMERIA> 2) Add new entries to the current command used to request for username/password. This command is supposed to ask the client to draw data in a specific dialog. This is used in username requesting, password, magic map, and i think the stats changing at the creation of player. I would like to be able to send the text read from scroll and book in a specific dialog so client could be able to put a scroll or a book in front of player in which he could read and turn the pages (little work for server, more impressive client side :P ). This could be extended to monuments and signs, to motd and letters. I was playing with the password stuff to implement a passwd command. It was pretty easy to do but not so easy to do it nicely and reuse the existing code (the dialogue windows mostly). The problem is that the Password thing is so tied up with the player states and the player states are so interconnected with the player creation system. It would be nice to unknot this out a bit from player creation to support reuse of the existing code to allow players to change their passwords. While doing this I thought it might be neat to have a generic player state like ST_INPUT which could be reused for various routines soliciting player input longer than a single character. This could be used for stuff like a dialogue for allocating unassigned quest experience (the 'Prince says "I will increase your ability in the skill of your choice..."), a way for NPCs to solicit an answer to a question (at least a start towards this anyway), or to make other new features that relied on more than a single character response. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 25 22:50:18 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:42 2005 Subject: [CF-Devel] Adding improvments References: <200307251232.13551.tchize@myrealbox.com> <002d01c35327$738c2460$8ef7d1d8@KAMERIA> Message-ID: <003601c35329$08b5c2c0$8ef7d1d8@KAMERIA> So what I forgot to say about this is that although it isn't a necessary component of having a ST_INPUT state, it would be a nice feature to be able to send text out to the dialogue as mentioned here. > 2) Add new entries to the current command used to request for > username/password. This command is supposed to ask the client to draw data > in > a specific dialog. This is used in username requesting, password, magic map, > and i think the stats changing at the creation of player. I would like to be > able to send the text read from scroll and book in a specific dialog so > client could be able to put a scroll or a book in front of player in which > he > could read and turn the pages (little work for server, more impressive > client > side :P ). This could be extended to monuments and signs, to motd and > letters. > > I was playing with the password stuff to implement a passwd command. It was > pretty easy to do but not so easy to do it nicely and reuse the existing > code (the dialogue windows mostly). The problem is that the Password thing > is so tied up with the player states and the player states are so > interconnected with the player creation system. It would be nice to unknot > this out a bit from player creation to support reuse of the existing code to > allow players to change their passwords. While doing this I thought it > might be neat to have a generic player state like ST_INPUT which could be > reused for various routines soliciting player input longer than a single > character. This could be used for stuff like a dialogue for allocating > unassigned quest experience (the 'Prince says "I will increase your ability > in the skill of your choice..."), a way for NPCs to solicit an answer to a > question (at least a start towards this anyway), or to make other new > features that relied on more than a single character response. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 25 23:21:30 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:43 2005 Subject: [CF-Devel] banish command References: <1059109309.2458.9.camel@oberon.Kameria> <3F20D0A8.9060704@sonic.net> Message-ID: <000401c3532d$645dabc0$8ef7d1d8@KAMERIA> > As for killing off a socket, just set pl->socket->status = Ns_Dead (might not > have all the variable names set right there, but that should be a good > approximation). > > The socket code will see the socket is marked dead, and do appropriate cleanup > (disconnect, save player, etc). The actual socket code doesn't really care why > the socket is now dead - Ns_Dead can also be set if the socket falsl too far > behind in processing information from the server. So anyone have a problem if I change command_kick to kill the socket rather than call play_again? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 25 14:01:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:43 2005 Subject: [CF-Devel] Adding improvments Message-ID: <1059159718.c0328f80yann.chachkoff@myrealbox.com> >In fact i thought about using the actual one since >there is already a 'type' >parameter followed by the data itself. I don't like recycling old commands for new stuff; it tends to make things more difficult to track down, and renders backward compatibility messier to maintain. But I'm not a reference in programming either :) >Could you think about sending your >actual stage of work so i could take a look at it and make suggestion/changes Yes. Keep in mind that my WE is already busy, and that my top priority is restoring my system from its HD crash. >(is there a way to identify the type of book the user >is reading so we could >change the pages pictures, ...?) I tweaked the code somewhat so it distinguishes the books according two factors: - The book type itself (spellbook, skill scroll, standard book); - The book cover (ie the picture used). >And once again, no backups (neither back cups) :) I do have regular backups for most of my data, and luckily the server-side code wasn't damaged. But it is currently somewhere in one of the hard disks lying on my desktop, waiting for the machine to be rebuilt. >interresting about smooth moves (want to take a look) No working code yet - just the theory needed to implement it. If I get enough time this WE, I'll post a summary here so we can discuss about this. > Am out of work? There are plenty of other things that can be done - Maps to make, bugs to hunt, and some little things to implement, like intelligent NPCs, mass-strategy of computer opponents, better random map generator, raw material digging, repairing the logger, updating the animator, tax perception for the King of Scorn, ... (Just what I can currently remind, probably much more stuff left) >So i think i'll buy a microphone a squeak a bit. This should makes better sounds than the actual ones. Too easy, isn't it :) >I really would like a copy of your server/SDL client so i could work on it too (Want to check the skinnable part, or do it if it's not yet done). As I said, first let me recover my machine back on line (I'm forced to type this from a Win2k box !). > By the way, for saturday, This is no place for personnal communication. Quite impolite for other people. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 26 04:45:42 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:43 2005 Subject: [CF-Devel] remove IP from who command Message-ID: <000a01c3535a$af8fba20$939dacce@KAMERIA> I believe that the IP display should be removed from the who command when used by non DM players. On a mostly unrelated note it would be an idea if the location portion of Who was removed from non DM players as well and replaced with a spell that locates other players, perhaps even a spell that checks against the other players level to locate them. Of course another twist would be items/spells that obscure this information, making you harder to locate. I mean they can always tell you where they are if they really want you to know... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030726/ca6f58f8/attachment.htm From crossfire-devel-admin at archives.real-time.com Fri Jul 25 21:40:08 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:43 2005 Subject: [CF-Devel] remove IP from who command In-Reply-To: <000a01c3535a$af8fba20$939dacce@KAMERIA> References: <000a01c3535a$af8fba20$939dacce@KAMERIA> Message-ID: <1059187208.470.4.camel@oberon.Kameria> I want to destroy Outlook express -it does not stay in plaintext mode, it will not properly quote messages and it is as secure as swiss cheese - Monday I start using mozilla mail on my loaner laptop, standards or no standards. Here is the message I sent in plain text: On Sat, 2003-07-26 at 05:45, Todd Mitchell wrote: > I believe that the IP display should be removed from the who command > when used by non DM players. > > On a mostly unrelated note it would be an idea if the location portion > of Who was removed from non DM players as well and replaced with a > spell that locates other players, perhaps even a spell that checks > against the other players level to locate them. > > Of course another twist would be items/spells that obscure this > information, making you harder to locate. > > I mean they can always tell you where they are if they really want you > to know... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 25 21:11:02 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:43 2005 Subject: [CF-Devel] remove IP from who command In-Reply-To: <000a01c3535a$af8fba20$939dacce@KAMERIA> Message-ID: On Sat, 26 Jul 2003, Todd Mitchell wrote: > I believe that the IP display should be removed from the who command > when used by non DM players. I can agree with this, with one "minor" detail.. Player IP's are not displayed by default. However, a server admin has the ability to specify which players can view player IP's with the who command. I know from experience that it's been helpful in tracking down hacked password issues with a character - I was able to login and ask certain players what IP connected from and then proceed from there. Basically, it saved me alot of time and did not force me to camp online. Whow knows, with a feature like this it might lead to more of a sub-DM status for people to help or assist other players. ;) > On a mostly unrelated note it would be an idea if the location portion > of Who was removed from non DM players as well and replaced with a spell > that locates other players, perhaps even a spell that checks against the > other players level to locate them. > Of course another twist would be items/spells that obscure this > information, making you harder to locate. An interesting and amusing idea! - Rick leaf@real-time.com -- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Jul 25 23:59:07 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:43 2005 Subject: [CF-Devel] banish command In-Reply-To: <001e01c35321$632b15a0$8ef7d1d8@KAMERIA> References: <1059109309.2458.9.camel@oberon.Kameria> <3F20D0A8.9060704@sonic.net> <200307251213.00025.d.delbecq@laposte.net> <20030725124036.GA2343@ds217-115-141-205.dedicated.hosteurope.de> <001e01c35321$632b15a0$8ef7d1d8@KAMERIA> Message-ID: <3F220A9B.4020304@sonic.net> Well, having a banish_file in the var directory seems reasonable. Shouldn't be too much effort to have the check_ban or whatever the function is called to check two files. One could certainly add a time (in epoch seconds) of when the ban expires, and have the check_ban ignore any that have past. If I recall correctly, check_ban reads the file everytime it is called. I see no reason to change that - having an in memory table gets trickier. But even then, if desired to actually have an 'effective until' time, it wouldn't be hard to have some code that clears out those old entries. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 26 00:23:51 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:44 2005 Subject: [CF-Devel] Adding improvments In-Reply-To: <1059159718.c0328f80yann.chachkoff@myrealbox.com> References: <1059159718.c0328f80yann.chachkoff@myrealbox.com> Message-ID: <3F221067.8090301@sonic.net> Going to catch up with this thread quickly. First, if you are going to extend existing protocol commands, please just add a version number to the protocol command (eg, drawinfo1, query1, map3, etc) instead of adding 'ext' to an existing command. Adding a number makes it clearer that this is a revision to an existing command. It is also more forward thinking. Suppose that extmessage command needs to be expanded down the road. Do you call it extextmessage? A few specific notes: Using any map command to send text information is probably going to be trickier than you think, and not much a gain. Your probably just better off having the drawinfo2 command take a coordinate offset. Presuming you want to draw this on the map, you need special handling anyways (the information has to last longer than 1 tick on the map display, for example, so the client has to store this away and some how age it). This is apparantly how Gros has done it, so that is good there. Note that type should be well defined. A long time back, I put something into the TODO file that messsages should be sent by type of message, and not by color like it is done now. Ideally, this is a reasonable number of types based on what the player may want to see, but not so unique that it would be impossible for players to be able to control the different message characters. Eg, if there are 20 message types, not too unreasonable for a player to set up their client with different fonts and color for each message type. However, if there are 300 message types, that obviously isn't feasible. One big thing to be added would be handling for the client to know if it is something that should be displayed in a fixed width font (eg, like a shop menu or spell listing). Long back I mentioned that the entire character creation system should be redone. One can probably search back in the past for that, but IMO, the ideal thing would be to give player some number of points to distribute between stats, let them choose race, class, etc. When player has all done this, client then sends something like 'newplayer ... This then allows the cient to have a nice interface for creating characters. And eliminates a whole mss of the ask/reply stuff. Animations for the map: This has been discussed before. Large stretches of ocean is worst case scenario. However, a few things to think about: 1) animation speed can be variable for the same object/face. Thus, two orcs on a map could be moving at different speeds, and thus be animated differently. This potentially means that for every image on the map that is animated, you are sending some number of bytes to contain the animation speed. 2) There are some images/archetypes that should be locked to the same animation sequence (water), and others that should vary (eg, monsters). You don't want the monsters to animate all at the same time - that looks a bit cheesy. 3) No one has done an analysis to really see how much map side animations would save in bandwidth. Even for things like burning hands, it is a very transient operation, so if the overhead to send information about animation for it is more than the cost of animations, you don't gain a whole bunch As for why there are different ST_ states: This is because the code has to know somehow who is expecting that input. If you just have a ST_INPUT state, you then need somehow to know 'does this go to a script? Go to the players login name? etc." The best thing to add to the client would be a dialogue box that always takes anything entered in it and returns it as 'say' command. Thus, communication is then just a matter of typing into that box and hitting return. I do agree that dialogues for some things could be better. However, I'd say this is more a feature on the client, eg, the client could have a special option of 'type stuff into this box, and I'll send it to the server as a 'cast marking rune of ' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 26 00:27:42 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:44 2005 Subject: [CF-Devel] Features suggestions In-Reply-To: References: Message-ID: <3F22114E.9070406@sonic.net> nicolas.weeger@laposte.net wrote: > Hi. > > I've been playing with alchemy lately, and thus writing down > (using 'inscription' skill) the stuff i find. > But the list is now too long & won't fit on a scroll, so i > must use 2. > Hence this feature suggestion: ability to rename an item. > This way I'll make 'formuleas in A', 'formuleas in B' and so > on. Having 10+ 'scroll' with different things isn't exactly > fun to handle ^_^ > > But since some parts of the CF code use the name (for instance > weapon enchantment by a god), i suggest only the following > items may be renamed: > * containers (so you can have a 'quiver of fire arrows' and a > 'quiver of cold arrows'). This would potentially include > bookshelves too (maybe by picking'em up first, to 'mark' the > item you wanna rename?), so you can sort your junk more > easily, and more precisely FIND it again easily :-) > * non-magical scrolls/books where you can write what you want > > What do you think of that? > I may just attempt to code that if no one does it (though i'd > hafta kick myself first to actually find a way to compile & > test the server, either under w32 or using some emulators to > run linux...). Best way to do this would be to add somethimg like a 'custom_name' field to the object. If it is sent, it is used instead of the normal naming, if it is not set, then normal naming is used. That is the easiest, and also most flexible (you can thus rename any object with no problems). Something like the examing command could be something like: That is a firebrand of mostrai +3. You call it firemos. it does ... If the object is dropped on a non unique space, then that custom name should probably get cleared, so the next player that runs accross it sees the normal name. (the not renaming on unique space is so that players could drop it in their apartment and have it keep its name). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 26 00:34:09 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:44 2005 Subject: [CF-Devel] remove IP from who command In-Reply-To: <000a01c3535a$af8fba20$939dacce@KAMERIA> References: <000a01c3535a$af8fba20$939dacce@KAMERIA> Message-ID: <3F2212D1.6080403@sonic.net> Todd Mitchell wrote: > I believe that the IP display should be removed from the who command > when used by non DM players. Is there a reason why? > > On a mostly unrelated note it would be an idea if the location portion > of Who was removed from non DM players as well and replaced with a spell > that locates other players, perhaps even a spell that checks against > the other players level to locate them. I think the original idea was to see where other players are, to assist in playing together. However, I could certainly see a feature like 'cloak' which hides where you are or whatever. Only DM's could penetrate the cloak. I don't see much point to adding a complete set of spells to find players, and spells to make it harder to find. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 26 02:58:27 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:44 2005 Subject: [CF-Devel] Features suggestions In-Reply-To: <3F22114E.9070406@sonic.net> References: <3F22114E.9070406@sonic.net> Message-ID: <3F2234A3.5000007@laposte.net> Mark Wedel wrote: > Best way to do this would be to add somethimg like a 'custom_name' > field to the object. If it is sent, it is used instead of the normal > naming, if it is not set, then normal naming is used. Wouldn't that require some changes to the function finding items by name? (used in 'apply' for instance) The aim of name changing would of course be to use that name for apply / other commands. > If the object is dropped on a non unique space, then that custom name > should probably get cleared, so the next player that runs accross it > sees the normal name. (the not renaming on unique space is so that > players could drop it in their apartment and have it keep its name). > Hum, but there should be a way maybe for players to trade items with custom name, no? Like I wanna show to someone alchemy recipes i have starting in 'A', it'd be a pain to drop the scroll & have to rename it after... Ok, you can copy & paste in say command (multiline works correctly, btw? think i tried but can't remember), but it isn't the same :-) Just my 2 cents of ? Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 26 10:39:43 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:44 2005 Subject: [CF-Devel] Adding improvments In-Reply-To: <3F221067.8090301@sonic.net> Message-ID: On 26-Jul-03 Mark Wedel wrote: > The best thing to add to the client would be a dialogue box that always > takes > anything entered in it and returns it as 'say' command. Thus, communication > is > then just a matter of typing into that box and hitting return. I think Todd was trying to do something more specific, where a NPC would ask you a pointed question, and you would have to answer it. I'm not sure I want NPC's locking me into conversation. I think what you really want there, is the ability for an NPC to lock step through a conversation, not just respond to various keywords in any order. This might not be very difficult, but fixing it so that if someone walks out in the middle of the conversation might need to get covered. > I do agree that dialogues for some things could be better. However, I'd > say > this is more a feature on the client, eg, the client could have a special > option > of 'type stuff into this box, and I'll send it to the server as a 'cast > marking > rune of ' That would probably be sufficient. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 26 10:43:18 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:44 2005 Subject: [CF-Devel] remove IP from who command In-Reply-To: <3F2212D1.6080403@sonic.net> Message-ID: On 26-Jul-03 Mark Wedel wrote: > I think the original idea was to see where other players are, to assist in > playing together. One problem I have with removing location from who, is that there are certain areas that are usually prime spots for players to hang out. Right now you can look at the who list and see if there is an unoccupied area for you to go to. If you remove this, I think there will be alot more bumping into one another, which will probably annoy people more than not. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 26 10:47:57 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:44 2005 Subject: [CF-Devel] Compiling server for w32 Message-ID: <3F22A2AD.8070409@laposte.net> Hello. I don't know if someone in particular is maintaining the Win32 stuff for the server, but current (ok, maybe 5 or 6 days ago) CVS snapshot won't build (using the MSCV project). Anyone taking care of that? If not, I may just volunteer... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 26 15:09:03 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:44 2005 Subject: [CF-Devel] Adding improvments In-Reply-To: References: Message-ID: <1059250143.521.58.camel@oberon.Kameria> > I think Todd was trying to do something more specific, where a NPC would ask > you a pointed question, and you would have to answer it. I'm not sure I want > NPC's locking me into conversation. I was actually trying to get my mind around something more generic so that I wouldn't have to write a new player state for every time you wanted to query the player. I don't want NPC's locking you into a conversation per/se, but can think of times when you would want to initiate getting input rather than having to doing everything statelessly. At he moment I don't know enough to see how it would work, but my thought was that you would have a recieve_input function that would be like a clearing house and just grab op->contr->write_buf and put it somewhere that the calling function that initiated the query could pick it up from... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 26 16:25:44 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:44 2005 Subject: [CF-Devel] remove IP from who command In-Reply-To: <3F2212D1.6080403@sonic.net> References: <000a01c3535a$af8fba20$939dacce@KAMERIA> <3F2212D1.6080403@sonic.net> Message-ID: <1059254744.521.123.camel@oberon.Kameria> On Sat, 2003-07-26 at 01:34, Mark Wedel wrote: > Todd Mitchell wrote: > > I believe that the IP display should be removed from the who command > > when used by non DM players. > > Is there a reason why? > A few reasons: It is not 'atmospheric' information. It is not really game related information. It is subject to abuse by goonish players (do you want your IP written on a truckstop bathroom somewhere in Kentucky?). > > > > On a mostly unrelated note it would be an idea if the location portion > > of Who was removed from non DM players as well and replaced with a spell > > that locates other players, perhaps even a spell that checks against > > the other players level to locate them. > > I think the original idea was to see where other players are, to assist in > playing together. > > However, I could certainly see a feature like 'cloak' which hides where you > are or whatever. Only DM's could penetrate the cloak. > > I don't see much point to adding a complete set of spells to find players, and > spells to make it harder to find. > I think that by giving out player location 'for free' we are mising the chance to add some nifty functionality. It is always possible to shout and to ask/tell your location to others so I don't think it's a big loss for interplayer co-operation because if people want to be found they can easily make their presence known. If you log in and want to see where every one is hanging out you can shout 'where is everyone at?'. BUT if there is a system for locating and hiding you have a bunch of new game dynamics to play with. It would be fun. I remember playing on a mud and getting to the level where I got the 'where' command ability. It was great, I felt as if I had really gained something, not just leveled up. It was so much better and game-immersive to have it as an personal ability I earned than a generic command like drop or attack. It also would make it possible to do stuff like play manhunter and hide and seek and stuff. High level players are always saying there's nothing to do, it would be possible to play with the knowledge of the game you've gained in a good world spanning manhunt. Even if instead of a spell/scroll, there was just a 'where' command that compared the level of the user vs the level of the person being sought it would be more interesting than having it in 'who'. On the other hand, you could have a lot of fun in the game with a complex system for locating any unique object or other players which took into account stuff like levels, skills (tracking, divination), spells (scrolls and rings and stuff too...) and other modifiers like inate inscrutability. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Jul 26 18:31:48 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:44 2005 Subject: [CF-Devel] remove IP from who command In-Reply-To: <1059254744.521.123.camel@oberon.Kameria> References: <000a01c3535a$af8fba20$939dacce@KAMERIA> <3F2212D1.6080403@sonic.net> <1059254744.521.123.camel@oberon.Kameria> Message-ID: <1059262307.10825.9.camel@debian> So, we could add some more client-side functionality as a complex chat system, in gtk client it could be tabbed, it might offer: an "INFO" channel, where you see what happens in the game (life loses, kills, signs readings, etc.) a "SAY" channel, where you hear what people on your same room is, and, by typing while in there, you don't need to type 'say. (interesting for quests/talking with npc's). a "GENERAL CHAT" channel, where you can talk with everybody without typing 'shout a "PARTY CHANNEL" channel, where you can party chat without typing 'party say and, i'd add some more client commands, like 'query NICKNAME, which opens a tab (that you can close in any moment you want) to anyone, him messages will be showed there, and you won't need to write 'tell NICKNAME for telling him anything, there. They might blink when there are messages and you haven't read them That would be a xchat/mIRC look that would make easier chatting, therefore roleplaying, in the game :) El s?, 26-07-2003 a las 23:25, Todd Mitchell escribi?: > On Sat, 2003-07-26 at 01:34, Mark Wedel wrote: > > Todd Mitchell wrote: > > > I believe that the IP display should be removed from the who command > > > when used by non DM players. > > > > Is there a reason why? > > > > A few reasons: > > It is not 'atmospheric' information. > It is not really game related information. > It is subject to abuse by goonish players (do you want your IP written > on a truckstop bathroom somewhere in Kentucky?). > > > > > > > > On a mostly unrelated note it would be an idea if the location portion > > > of Who was removed from non DM players as well and replaced with a spell > > > that locates other players, perhaps even a spell that checks against > > > the other players level to locate them. > > > > I think the original idea was to see where other players are, to assist in > > playing together. > > > > However, I could certainly see a feature like 'cloak' which hides where you > > are or whatever. Only DM's could penetrate the cloak. > > > > I don't see much point to adding a complete set of spells to find players, and > > spells to make it harder to find. > > > > I think that by giving out player location 'for free' we are mising the > chance to add some nifty functionality. It is always possible to shout > and to ask/tell your location to others so I don't think it's a big loss > for interplayer co-operation because if people want to be found they can > easily make their presence known. If you log in and want to see where > every one is hanging out you can shout 'where is everyone at?'. > BUT if there is a system for locating and hiding you have a bunch of new > game dynamics to play with. It would be fun. I remember playing on a > mud and getting to the level where I got the 'where' command ability. > It was great, I felt as if I had really gained something, not just > leveled up. It was so much better and game-immersive to have it as an > personal ability I earned than a generic command like drop or attack. > It also would make it possible to do stuff like play manhunter and hide > and seek and stuff. > High level players are always saying there's nothing to do, it would be > possible to play with the knowledge of the game you've gained in a good > world spanning manhunt. > > Even if instead of a spell/scroll, there was just a 'where' command that > compared the level of the user vs the level of the person being sought > it would be more interesting than having it in 'who'. > > On the other hand, you could have a lot of fun in the game with a > complex system for locating any unique object or other players which > took into account stuff like levels, skills (tracking, divination), > spells (scrolls and rings and stuff too...) and other modifiers like > inate inscrutability. > > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 27 00:02:08 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:44 2005 Subject: [CF-Devel] remove IP from who command In-Reply-To: <1059254744.521.123.camel@oberon.Kameria> References: <000a01c3535a$af8fba20$939dacce@KAMERIA> <3F2212D1.6080403@sonic.net> <1059254744.521.123.camel@oberon.Kameria> Message-ID: <3F235CD0.50700@sonic.net> Todd Mitchell wrote: > On Sat, 2003-07-26 at 01:34, Mark Wedel wrote: > A few reasons: > > It is not 'atmospheric' information. > It is not really game related information. > It is subject to abuse by goonish players (do you want your IP written > on a truckstop bathroom somewhere in Kentucky?). If a trucker cares about my ip address, he is more than welcome to know it. I really don't care too much one way or the other. And I could certainly see that anonymonity being a good thing (you don't want the players to know that you are also the person that played some character when you make a new one up). I'm pretty sure the log files do pretty accurately record that information, or it could certainly be added. It could be argued that having the log files available for public review (as well as core files) sort of bypasses that security. I wonder if metalforge (and other servers that make their core/log files available) should password protect them and give the password to developers so not any yahoo can see them. As far as player information, if decided that making it hidden is a good idea, I'd rather just see a simple comparision (eg, cast 'locate player' spell or the like), and not make it even more confusion with ways for the player to obscure it. If so desired, make it so that caster level of the spell is significant, but lets no go beyond there. However, if you're talking atmospheric/game related info, the availability of the shout and other commands that can bypass any distance bounds isn't all that realistic. I can understand its use. But one just has to be careful how much one uses such an arguement for/against features. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 27 00:23:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:44 2005 Subject: [CF-Devel] Adding improvments In-Reply-To: <1059250143.521.58.camel@oberon.Kameria> References: <1059250143.521.58.camel@oberon.Kameria> Message-ID: <3F2361CE.2080900@sonic.net> Todd Mitchell wrote: >>I think Todd was trying to do something more specific, where a NPC would ask >>you a pointed question, and you would have to answer it. I'm not sure I want >>NPC's locking me into conversation. > > > I was actually trying to get my mind around something more generic so > that I wouldn't have to write a new player state for every time you > wanted to query the player. I don't want NPC's locking you into a > conversation per/se, but can think of times when you would want to > initiate getting input rather than having to doing everything > statelessly. At he moment I don't know enough to see how it would work, > but my thought was that you would have a recieve_input function that > would be like a clearing house and just grab op->contr->write_buf and > put it somewhere that the calling function that initiated the query > could pick it up from... My take: If an NPC is awaiting input, that input should still come from a 'say' command. I don't see any issue with NPC's having stateful conversations, nor initiating the conversation (presumably, both of these could pretty easily be done with scripts). The npc script would determine what state it is in (simple variable). It could also hold a variable for hte last time it was 'talked' to, so that if the player wander away for 5 minutes or whatever, the conversation would start from scratch. As far as your first statement about 'new player state every time you want to query the player', that won't get changed above. I imagine this is because your working on the change player password stuff, which would entail new states. However, such changes are actually quite rare, and arguable could be handled mostly by the client. Eg, have something like a 'changepassword ' command. You could have a client dialogue for that - something that has three boxes - enter your old password, enter your new password, enter your new password (confirm). Client would confirm that the new passwords do in fact match, and if so, then send that changepassword command. This may not fix everything, but would probably fix most of them - there will always be a few cases where you need to add a new state, but I really can't think of any. Giving the client more responsibility (for player creation) actually reduces the number of states. And also provides a better interface to the user. > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 27 00:32:39 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:44 2005 Subject: [CF-Devel] Features suggestions In-Reply-To: <3F2234A3.5000007@laposte.net> References: <3F22114E.9070406@sonic.net> <3F2234A3.5000007@laposte.net> Message-ID: <3F2363F7.4070800@sonic.net> Nicolas Weeger wrote: > Mark Wedel wrote: > >> Best way to do this would be to add somethimg like a 'custom_name' >> field to the object. If it is sent, it is used instead of the normal >> naming, if it is not set, then normal naming is used. > > > Wouldn't that require some changes to the function finding items by > name? (used in 'apply' for instance) > The aim of name changing would of course be to use that name for apply / > other commands. It would require some changes, but I believe a common function (or functions) is used for matching names, so it wouldn't be that much harder. My motto in terms of development is 'do the correct implementation, not the fast/easy implementation'. This is largely because in the end, the correct implementation will almost certainly be done. If you start with just allowing some subset of items to be renamed, almost certainly players will ask/want to be able to rename all objects. And almost certainly, having it not be the official name will sort out some obscure bugs. One I can immediately think of is sacrifices on altars - if I'm able to rename an object in my inventory to anything I want, and it updates the official name, I've now just about come up with a way to do the sacrifice on any altar in the game, even if that would normally require very rare/hard to find objects. > Hum, but there should be a way maybe for players to trade items with > custom name, no? > Like I wanna show to someone alchemy recipes i have starting in 'A', > it'd be a pain to drop the scroll & have to rename it after... > Ok, you can copy & paste in say command (multiline works correctly, btw? > think i tried but can't remember), but it isn't the same :-) Well, another way might to do clear the custom name at load or save time. Thus, two players on the same maps could exchange stuff all the way, and have the custom names stick. But if someone drops something on a floor, and it is a while before someone else finds it (map was saved out), reasonable to think that its special name shouldn't stick. There would of course have to be some exception handling for unique maps/apartments, so that the custom name doesn't get stripped for items that should legitamately keep their name. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 27 02:37:15 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:44 2005 Subject: [CF-Devel] Features suggestions In-Reply-To: <3F2363F7.4070800@sonic.net> References: <3F22114E.9070406@sonic.net> <3F2234A3.5000007@laposte.net> <3F2363F7.4070800@sonic.net> Message-ID: <3F23812B.6020009@laposte.net> > It would require some changes, but I believe a common function (or > functions) is used for matching names, so it wouldn't be that much > harder. From what i remember of the code (ok i don't know it by heart, but have browsed it some), indeed... and actually one is partly broken somewhere, since sometimes 'apply Thei' (for apply ring of Thieves <- note the typo) can result in apply a haggis... > My motto in terms of development is 'do the correct implementation, > not the fast/easy implementation'. This is largely because in the > end, the correct implementation will almost certainly be done. Nice point. > If you start with just allowing some subset of items to be renamed, > almost certainly players will ask/want to be able to rename all > objects. And almost certainly, having it not be the official name > will sort out some obscure bugs. But are functions actually checking an item's name that many? I think for instance the god enchanting weapon one (to punish you if you have an item of another god), but are there others? Also, i'll point out that the prepare weapon actually changes the name (weapon->name) of the prepared item, so changing an item's name isn't that bad apparently ^_^ > One I can immediately think of is sacrifices on altars - if I'm able > to rename an object in my inventory to anything I want, and it updates > the official name, I've now just about come up with a way to do the > sacrifice on any altar in the game, even if that would normally > require very rare/hard to find objects. To avoid that kind of bugs, i was thinking of 1) only allowing containers & freely writable scrolls to be renamed (not something you often sacrifice i'm sure) 2) adding in front the item's type, like 'scroll: alchemy list A' or 'quiver: Fire Arrows'. This will ensure the name mentions the original item's type. Of course maybe putting dots is bad, don't know > There would of course have to be some exception handling for unique > maps/apartments, so that the custom name doesn't get stripped for > items that should legitamately keep their name. Would introducing that exception be all right? I'm afraid it'd somewhat make the code less readable, having too much special stuff... Just my 2 cents... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 27 16:21:07 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:45 2005 Subject: [CF-Devel] Patch submission: name of (failed to be) disarmed runes Message-ID: <3F244243.8030301@laposte.net> Hello everyone. Here's a small patch (based on current CVS version) related to runes disarming. I changed the text that appears when you successfully disarm or fail to disarm a rune to display the name. Pretty straightforward change, and i tested it to make sure it works... Feel free to either put it into CVS or trash it :-) Note that it doesn't show more information than what the player can see, since (s)he can only disarm runes spotted (of course if you use the disarm spell you can disarm without spotting first, but whether you disarm it or not you know there is a rune, and the name doesn't matter imo). Nicolas 'Ryo' -------------- next part -------------- diff -r1.31 rune.c 378a379 > char buf[MAX_BUF]; 389c390,391 < new_draw_info(NDI_UNIQUE, 0,disarmer,"You successfuly disarm it!"); --- > sprintf(buf,"You successfuly disarm the %s!",trap->name); > new_draw_info(NDI_UNIQUE, 0,disarmer,buf); 401c403,404 < new_draw_info(NDI_UNIQUE, 0,disarmer,"You fail to disarm the trap."); --- > sprintf(buf,"You fail to disarm the %s!",trap->name); > new_draw_info(NDI_UNIQUE, 0,disarmer,buf); From crossfire-devel-admin at archives.real-time.com Sun Jul 27 17:07:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:45 2005 Subject: [CF-Devel] Patch submission: name of (failed to be) disarmed runes In-Reply-To: <3F244243.8030301@laposte.net> References: <3F244243.8030301@laposte.net> Message-ID: <3F244D3E.5050303@sonic.net> Nicolas Weeger wrote: > Hello everyone. > > Here's a small patch (based on current CVS version) related to runes > disarming. > I changed the text that appears when you successfully disarm or fail to > disarm a rune to display the name. > > Pretty straightforward change, and i tested it to make sure it works... > > Feel free to either put it into CVS or trash it :-) > > Note that it doesn't show more information than what the player can see, > since (s)he can only disarm runes spotted (of course if you use the > disarm spell you can disarm without spotting first, but whether you > disarm it or not you know there is a rune, and the name doesn't matter > imo). Note that you don't need to declare a 'buf' value - you can instead use new_draw_info_format, which takes the usual printf type stuff. Probably would have been better to call that new_draw_printf or something, but oh well. Otherwise, looks fine. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Jul 27 17:19:46 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:45 2005 Subject: [CF-Devel] Features suggestions In-Reply-To: <3F23812B.6020009@laposte.net> References: <3F22114E.9070406@sonic.net> <3F2234A3.5000007@laposte.net> <3F2363F7.4070800@sonic.net> <3F23812B.6020009@laposte.net> Message-ID: <3F245002.6060505@sonic.net> Nicolas Weeger wrote: > >> It would require some changes, but I believe a common function (or >> functions) is used for matching names, so it wouldn't be that much >> harder. > > > From what i remember of the code (ok i don't know it by heart, but have > browsed it some), indeed... and actually one is partly broken somewhere, > since sometimes 'apply Thei' (for apply ring of Thieves <- note the > typo) can result in apply a haggis... Well, the code that does matching (for player specified subnames) tries to get the best match, through a bunch of different criteria (exact object name match, substring, and some other ones I think). I don't know why a Thei would match a haggis, but probably some reason. It could be nice for player to specify how loosely a match could be, but since the match routine basically uses non well defined values, that would be a bit harder to document well. > > But are functions actually checking an item's name that many? I think > for instance the god enchanting weapon one (to punish you if you have an > item of another god), but are there others? > Also, i'll point out that the prepare weapon actually changes the name > (weapon->name) of the prepared item, so changing an item's name isn't > that bad apparently ^_^ Difference in this case is that the player is being given a lot more leeway in terms of what the name of the object may be. With existing code, the player really can't control what the item will be named that much. It is basically 'weapon of ', where x is the player name or the god name. > To avoid that kind of bugs, i was thinking of > 1) only allowing containers & freely writable scrolls to be renamed (not > something you often sacrifice i'm sure) > 2) adding in front the item's type, like 'scroll: alchemy list A' or > 'quiver: Fire Arrows'. This will ensure the name mentions the original > item's type. Of course maybe putting dots is bad, don't know I can say with a high degree of certainty, that at some point #1 won't be sufficient - players will want to be able to rename any object in their inventory. I personally don't think it would be that much more difficult to just add another field to the object which is a custom name for the object. It's a bit more work, but not a whole bunch. Note that the other advantage of a new field is that the original name is always available (for example, if someone did make a quest where you had to sacrifice the bag of valhalla, which is a special item, but a player renamed the bag of valhalla, he could be somewhat screwed). Since sacrifices would still deal with the items real name, that wouldn't be an issue. > >> There would of course have to be some exception handling for unique >> maps/apartments, so that the custom name doesn't get stripped for >> items that should legitamately keep their name. > > > Would introducing that exception be all right? I'm afraid it'd somewhat > make the code less readable, having too much special stuff... I'd think it'd be alright. The unique map/floor code already has some number of special behaviour, and adding another one wouldn't seem like that big an issue. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Jul 28 00:59:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:45 2005 Subject: [CF-Devel] Features suggestions In-Reply-To: <3F245002.6060505@sonic.net> References: <3F22114E.9070406@sonic.net> <3F2234A3.5000007@laposte.net> <3F2363F7.4070800@sonic.net> <3F23812B.6020009@laposte.net> <3F245002.6060505@sonic.net> Message-ID: On Sun, 27 Jul 2003, Mark Wedel wrote: > > > > But are functions actually checking an item's name that many? I think > > for instance the god enchanting weapon one (to punish you if you have an > > item of another god), but are there others? Altars and alchemy at least. > > Also, i'll point out that the prepare weapon actually changes the name > > (weapon->name) of the prepared item, so changing an item's name isn't > > that bad apparently ^_^ > Even this restricted naming can be abused : 1. Calculate the hash value of a formula with rare ingredients. 2. Calculate the hash value of cheap weapon eg. club. 3. Make character with appropriate name. Now you can make this formula with 1 club, 1 gem, 1 prepare weapon. > Note that the other advantage of a new field is that the original name is > always available (for example, if someone did make a quest where you had to > sacrifice the bag of valhalla, which is a special item, but a player renamed the > bag of valhalla, he could be somewhat screwed). Since sacrifices would still > deal with the items real name, that wouldn't be an issue. > Even worse: some player might rename some crap (eg. scroll) "bag of valhalla" . The altar would accept the item if it can't know the real name. Even allowing to set the title would be extremely abusive concerning alchemy. So, i think, the extra field is necessary. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Jul 28 07:56:59 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:45 2005 Subject: [CF-Devel] Stats adjudication In-Reply-To: <3F2361CE.2080900@sonic.net> References: <1059250143.521.58.camel@oberon.Kameria> <3F2361CE.2080900@sonic.net> Message-ID: <1059397019.26071.7.camel@debian> I'd like to start a discussion about stats adjudication, as i've already readed that stats rolling might be took out. Since the max you could have at the moment is 15*7=105 statpoints... We could give a player 1 point in each stat, then 98 points for adjudicating (max in a stat is 18). Then, we might think of a way, like you need at least 18 points on a stat so you could get it increased up to 30 with potions. Thought people won't want Charisma... That way most common configurations would be: Str 18 Dex 18 Con 18 Int 15 Pow 15 Wis 15 Cha 9 or: Str 18 Dex 18 Con 17 Int 18 Pow 18 Wis 18 Cha 1 That would be pretty unfair... So, we could get it to be: the higher stat points might be LESS OR EQUAL than 5 points minor than the lesser one. So you could get: Str 18 Dex 15 Con 15 Int 15 Pow 15 Wis 14 Cha 13 or: Str 18 Dex 18 Con 17 Int 13 Pow 13 Wis 13 Cha 13 If you think, you wouldn't be able to get a VERY COOL character, neither a bad one :) There might be client preconfiguration for those (as warrior, mage, priest, merchant, etc.) (same than in UO preconfigurations) :) What do you, people, think? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Jul 28 08:37:36 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:45 2005 Subject: [CF-Devel] Stats adjudication Message-ID: <1059399456.dafb0900yann.chachkoff@myrealbox.com> > What do you, people, think? I don't like the idea of a difference of at most 5 points between the highest and the lowest stat - Unbalanced characters are much funnier to play. Here's my own suggestion: Give the player 100 PC to make the character. Each stat starts with a score of 1. To increase the score of a stat by 1, you have to spend: - 1 PC, if the new stat level is between 1 and the maximum racial value/2; - 2 PCs, if the new stat level is between MRV/2 and MRV*3/4; - 3 PCs, if the new stat level is between MRV*3/4 and MRV. Note that giving 100PCs is just an idea - this could be fine-tuned, maybe as a server option. Whatever, if I play a human (MRV=20 for everything), I can make a decent warrior with: S:16, Co:15, D:15, I:10, P:13, W:8, Ch:10 Or a more wizard-like one: S:7, Co:10, D:10, I:17, P:16, W:15, Ch:10 Remaining points could for example be converted in money. Comments ? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Jul 28 11:14:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:45 2005 Subject: [CF-Devel] Stats adjudication In-Reply-To: <1059399456.dafb0900yann.chachkoff@myrealbox.com> References: <1059399456.dafb0900yann.chachkoff@myrealbox.com> Message-ID: <1059408897.1238.1.camel@debian> If you notice, in your way every newer character will be HARDER to play than the actual ones. In my way they're alike the actual ones, but you save up all the weird time rolling the stats ;P > - 1 PC, if the new stat level is between 1 and the maximum racial value/2; > - 2 PCs, if the new stat level is between MRV/2 and MRV*3/4; > - 3 PCs, if the new stat level is between MRV*3/4 and MRV. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 29 00:08:09 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:45 2005 Subject: [CF-Devel] Stats adjudication References: <1059399456.dafb0900yann.chachkoff@myrealbox.com> <1059408897.1238.1.camel@debian> Message-ID: <000601c3558f$684bfac0$1076e2d1@KAMERIA> You make HARDER sound like a bad thing... Stats are almost a joke right now - you can expect to have at least a couple *very* high stats to start and it does not take long to raise them. Where does this leave stuff like stat increasing magic? Potions? Make the stats way lower and you make all the stat raising spells and potions, rings and stuff more valuable. There may be a trend in that the game is getting harder to play lately (more XP required, item power requirements, less money lying around) but IMHO these are *good* things because there were serious problems before. Games are about challange, it would be really easy to make a game where if you pressed the enter key a screen came up saying "You Win!". If it takes a lot longer to build up your stats, then I bet you'll have more fun doing it... > If you notice, in your way every newer character will be HARDER to play > than the actual ones. In my way they're alike the actual ones, but you > save up all the weird time rolling the stats ;P > > > - 1 PC, if the new stat level is between 1 and the maximum racial value/2; > > - 2 PCs, if the new stat level is between MRV/2 and MRV*3/4; > > - 3 PCs, if the new stat level is between MRV*3/4 and MRV. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 29 00:14:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:45 2005 Subject: [CF-Devel] Stats adjudication References: <1059399456.dafb0900yann.chachkoff@myrealbox.com> <1059408897.1238.1.camel@debian> Message-ID: <000b01c35590$3986e820$1076e2d1@KAMERIA> I know everyone will likely hate this idea, but what about all players start with the *same* initial stats + race/class modifiers? It's simple, it's fair and likely is close to what happens anyway except this way the initial stats would be lower. For the faint of heart who think that's too draconian, maybe give the player 4-5 points to spread around on top :). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Jul 28 12:45:35 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:45 2005 Subject: [CF-Devel] Stats adjudication References: <1059399456.dafb0900yann.chachkoff@myrealbox.com> <1059408897.1238.1.camel@debian> <000b01c35590$3986e820$1076e2d1@KAMERIA> Message-ID: <003c01c35530$0d78af30$693ae940@nbcusa.net> It does sound like a good idea, Todd. I'd take it one step further, though, and allow players to subtract from existing stats to increase others -- within racial boundaries, of course. I would also recommend limiting the max that can be subtracted from a given stat... eg 3 - 5 points. ----- Original Message ----- From: "Todd Mitchell" To: Sent: Tuesday, July 29, 2003 12:14 AM Subject: Re: [CF-Devel] Stats adjudication > I know everyone will likely hate this idea, but what about all players start > with the *same* initial stats + race/class modifiers? It's simple, it's > fair and likely is close to what happens anyway except this way the initial > stats would be lower. For the faint of heart who think that's too > draconian, maybe give the player 4-5 points to spread around on top :). > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Jul 28 19:15:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:45 2005 Subject: [CF-Devel] bug/fix: creators and multi-square objects Message-ID: <20030729001501.GD22513@laranja.org> Hello, I've been hacking crossfire a lot recently, I have a private server at home for the family and it serves as my testbed. I mostly hang around on IRC when I'm connected (only happens at work) and the message board. I've been told I should submit reports and patches to sourceforge, so that's what I'm doing. My first two are in, pretty simple stuff: http://sourceforge.net/tracker/?func=browse&group_id=13833&atid=113833 a straightforward fix to sorig.arc (am I the only priest of Sorig in the net?) and an improvement to the creator object. If someone could please spare a few minutes to review and possibly integrate these fixes, I'd be very glad. I'll tell you about the other things I've been trying tomorrow when I get to work... []s, |alo +---- -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://www.laranja.org/pessoal/pgp Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ GNU: never give up freedom http://www.gnu.org/ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 29 00:23:43 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:45 2005 Subject: [CF-Devel] Stats adjudication In-Reply-To: <003c01c35530$0d78af30$693ae940@nbcusa.net> References: <1059399456.dafb0900yann.chachkoff@myrealbox.com> <1059408897.1238.1.camel@debian> <000b01c35590$3986e820$1076e2d1@KAMERIA> <003c01c35530$0d78af30$693ae940@nbcusa.net> Message-ID: <3F2604DF.7010108@sonic.net> I'll note that if we decide to go to a point based system, one could start re-thinking much more than just points for stats. For example, most of the races are tried to be balanced by stat adjustments. If a race is much better, may we say 'that race costs 8 character points'. Or that race really sucks, and we'll give you 5 character points if you play it. As for stat system, presumably the idea of 'all players start with the same stats' is meaning something like, you get 18, 17, 16, 15, 14, 13, 12 (or whatever) and let the players arrange them? that seems a bit boring to me - one could look at one of the other proposed systems and say 'well, that system basically costs X points. So why not just give them X points to do as they want?' Now if one was going to re-do the stats, one could even take it further and re-do the stat tables. Right now high stats are very important, because at around 20, the bonus really start jumping up (for grace, for example, a 21 gets you a 10 bonus. a 24 gets you a 20 bonus. From 11 to 20, the grace bonus just goes up one at a point. One could just completely smooth the tables, ala AD&Dv3. If that was done, you could remove all stat limits (90 strength? Fine.) This would probably make things a bit more interesting in fact - do you get for that 34 int but only 26 pow, or do you go for 30 int and 30 pow? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 29 01:13:55 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:45 2005 Subject: [CF-Devel] Stats adjudication Message-ID: <1059459235.c90d1640yann.chachkoff@myrealbox.com> > If you notice, in your way every newer character will be HARDER to play than the actual ones. In my way they're alike the actual ones, but you save up all the weird time rolling the stats ;P Not only I noticed, but I also had that purpose in mind. Note that you can make things easier by giving more points to the player - the only rule my mechanism creates is: the higher you want to go, the more it costs (something that sounds logical to me). As for the idea of making the stats tables closer to AD&Dv3, I'm not too sure. The current tables are working quite decently - I think the real problem lies in the too high availability of means to increase your stats, not in the rules themselves. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 29 21:42:13 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:45 2005 Subject: [CF-Devel] Stats adjudication References: <1059399456.dafb0900yann.chachkoff@myrealbox.com> <1059408897.1238.1.camel@debian> <000b01c35590$3986e820$1076e2d1@KAMERIA> <003c01c35530$0d78af30$693ae940@nbcusa.net> <3F2604DF.7010108@sonic.net> Message-ID: <001901c35644$311aa320$749dacce@KAMERIA> > > I'll note that if we decide to go to a point based system, one could start > re-thinking much more than just points for stats. > Are you on the road to Crossfire 2.0 here? I'm not advocating this, just pointing out that if you are going to do some breaking it is beter to do a big break cleanly than a bunch of little breaks. > > As for stat system, presumably the idea of 'all players start with the same > stats' is meaning something like, you get 18, 17, 16, 15, 14, 13, 12 (or > whatever) and let the players arrange them? > Well I meant more like 12 12 12 12 12 12 12 (this is two points above average if natural max is 20 BTW)and get say 5 points to add and I like that idea of limited point transfer idea where you can move an additional 10 or so existing points around. This could give you 15 8 15 16 10 17 9 or 20 16 15 9 12 8 9 > that seems a bit boring to me - one could look at one of the other proposed > systems and say 'well, that system basically costs X points. So why not just > give them X points to do as they want?' > No real reason. This way might be quicker and have a nicer interface is all. I think that it amounts to the same thing really - assigning the initial points just saves you a bit of time I think - you should still be able to get the same results you want depending on how many points you let people move around. Presumably if the maximum is 20 few people will want stats much lower than 5 (if they do then the penalties for low stats aren't good enough). > Now if one was going to re-do the stats, one could even take it further and > re-do the stat tables. Right now high stats are very important, because at > around 20, the bonus really start jumping up (for grace, for example, a 21 gets > you a 10 bonus. a 24 gets you a 20 bonus. From 11 to 20, the grace bonus just > goes up one at a point. > > One could just completely smooth the tables, ala AD&Dv3. If that was done, > you could remove all stat limits (90 strength? Fine.) This would probably make > things a bit more interesting in fact - do you get for that 34 int but only 26 > pow, or do you go for 30 int and 30 pow? > On the one hand if you remove or raise the limit you will extend the value of all stat altering objects and the value of stat bonuses in the game which is good. On the other hand if you allow player to use these higher values initially then you lower the value of these. I would say you would want to lower starting values and raise the limit to get maximum game play value. A long career of gaining stats is good for business... Now on the topic of starting out, I am a big fan of using the race faces and not the class faces. I know that many people like the class faces so I won't advocate only using the race ones (but come on people- race is visible, class is just your skills....what if you are in your leisure clothes?) and would like to see a starting option to be able to choose to keep the race face or use the class one (hmnnn, or maybe a command to be able to switch between them in game perhaps?) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 29 09:45:30 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:45 2005 Subject: [CF-Devel] Stats adjudication References: <1059399456.dafb0900yann.chachkoff@myrealbox.com> <1059408897.1238.1.camel@debian> <000b01c35590$3986e820$1076e2d1@KAMERIA> <003c01c35530$0d78af30$693ae940@nbcusa.net> <3F2604DF.7010108@sonic.net> <001901c35644$311aa320$749dacce@KAMERIA> Message-ID: <003101c355e0$0f5834a0$693ae940@nbcusa.net> As far as race/class faces. I would agree that race is visible and should be used over class. I'm also thinking, though, if we can get the artists together -- have different faces for each race/class combination. just my $0.02. ----- Original Message ----- From: "Todd Mitchell" To: Sent: Tuesday, July 29, 2003 9:42 PM Subject: Re: [CF-Devel] Stats adjudication > > > > I'll note that if we decide to go to a point based system, one could > start > > re-thinking much more than just points for stats. > > > > Are you on the road to Crossfire 2.0 here? I'm not advocating this, just > pointing out that if you are going to do some breaking it is beter to do a > big break cleanly than a bunch of little breaks. > > > > > > As for stat system, presumably the idea of 'all players start with the > same > > stats' is meaning something like, you get 18, 17, 16, 15, 14, 13, 12 (or > > whatever) and let the players arrange them? > > > > Well I meant more like 12 12 12 12 12 12 12 (this is two points above > average if natural max is 20 BTW)and get say 5 points to add and I like that > idea of limited point transfer idea where you can move an additional 10 or > so existing points around. > This could give you 15 8 15 16 10 17 9 or 20 16 15 9 12 8 9 > > > that seems a bit boring to me - one could look at one of the other > proposed > > systems and say 'well, that system basically costs X points. So why not > just > > give them X points to do as they want?' > > > > No real reason. This way might be quicker and have a nicer interface is > all. I think that it amounts to the same thing really - assigning the > initial points just saves you a bit of time I think - you should still be > able to get the same results you want depending on how many points you let > people move around. Presumably if the maximum is 20 few people will want > stats much lower than 5 (if they do then the penalties for low stats aren't > good enough). > > > Now if one was going to re-do the stats, one could even take it further > and > > re-do the stat tables. Right now high stats are very important, because > at > > around 20, the bonus really start jumping up (for grace, for example, a 21 > gets > > you a 10 bonus. a 24 gets you a 20 bonus. From 11 to 20, the grace bonus > just > > goes up one at a point. > > > > One could just completely smooth the tables, ala AD&Dv3. If that was > done, > > you could remove all stat limits (90 strength? Fine.) This would > probably make > > things a bit more interesting in fact - do you get for that 34 int but > only 26 > > pow, or do you go for 30 int and 30 pow? > > > > On the one hand if you remove or raise the limit you will extend the value > of all stat altering objects and the value of stat bonuses in the game which > is good. On the other hand if you allow player to use these higher values > initially then you lower the value of these. I would say you would want to > lower starting values and raise the limit to get maximum game play value. A > long career of gaining stats is good for business... > > > Now on the topic of starting out, I am a big fan of using the race faces and > not the class faces. I know that many people like the class faces so I > won't advocate only using the race ones (but come on people- race is > visible, class is just your skills....what if you are in your leisure > clothes?) and would like to see a starting option to be able to choose to > keep the race face or use the class one (hmnnn, or maybe a command to be > able to switch between them in game perhaps?) > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 29 06:32:31 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:46 2005 Subject: [CF-Devel] patch: Repeated line supression for the gtk client. Message-ID: <20030729113231.GC3019@hogia.net> Hi there. I've made a patch to the gtk client that changes repeated lines in the info window into lines prefixed with number saying how many times it has been repeated. Ie: Instead of: You pray. You pray. You pray. You pray. it says: (4) You pray. There is a new command line option: -repeat that tells how many lines back it should look for repeated info, default is ten, zero turns off the feature. The code also has a hard limit set (ten in this patch, just change MAX_LINES). If a line is found to be repeated, the code will only prefix/change the line to have the new "(X) " string in front of it, it will not move the old line to the bottom. I found that to be easier to read compared to having the messages move around. Please commit it to CVS if it is acceptable. ----------------8<---------------- Index: common/client.h =================================================================== RCS file: /cvsroot/crossfire/client/common/client.h,v retrieving revision 1.12 diff -u -r1.12 client.h --- common/client.h 8 Jul 2003 12:52:35 -0000 1.12 +++ common/client.h 29 Jul 2003 11:16:39 -0000 @@ -163,7 +163,8 @@ #define CONFIG_RESISTS 27 #define CONFIG_SMOOTH 28 #define CONFIG_SPLASH 29 -#define CONFIG_NUMS 30 +#define CONFIG_REPEAT 30 +#define CONFIG_NUMS 31 /* CONFIG_LIGHTING can have several possible values - set them accordingly */ #define CFG_LT_TILE 1 Index: common/init.c =================================================================== RCS file: /cvsroot/crossfire/client/common/init.c,v retrieving revision 1.12 diff -u -r1.12 init.c --- common/init.c 25 Jun 2003 17:13:58 -0000 1.12 +++ common/init.c 29 Jul 2003 11:16:39 -0000 @@ -42,7 +42,7 @@ "mapscale", "popups", "sdl", "showicon", "tooltips", "sound", "splitinfo", "split", "show_grid", "lighting", "trim_info_window", "map_width", "map_height", "foodbeep", "darkness", "port", -"grad_color_bars", "resists", "smoothing", "nosplash" +"grad_color_bars", "resists", "smoothing", "nosplash", "repeat" }; sint16 want_config[CONFIG_NUMS], use_config[CONFIG_NUMS]; @@ -192,6 +192,7 @@ want_config[CONFIG_RESISTS] = 0; want_config[CONFIG_SMOOTH] = 0; want_config[CONFIG_SPLASH] = TRUE; + want_config[CONFIG_REPEAT] = 10; for (i=0; i MAX_LINES) { + use_config[CONFIG_REPEAT] = MAX_LINES; + } + strcpy (last_str, str); + + /* Freeze it */ + if (use_config[CONFIG_SPLITINFO] && color != NDI_BLACK) { - if (!draw_info_freeze2){ - gtk_text_freeze (GTK_TEXT (gtkwin_info_text2)); - draw_info_freeze2=TRUE; + info_text = gtkwin_info_text2; + if (!draw_info_freeze2) { + gtk_text_freeze (GTK_TEXT (gtkwin_info_text2)); + draw_info_freeze2=TRUE; + } + } else { + info_text = gtkwin_info_text; + if (!draw_info_freeze1) { + gtk_text_freeze (GTK_TEXT (gtkwin_info_text)); + draw_info_freeze1=TRUE; } + } + + /* Less then five characters is probably a prompt... */ + if (use_config[CONFIG_REPEAT]) { + if(strlen(str) > 5 && !strchr(str, '\n')) { + for(i = 0; i < use_config[CONFIG_REPEAT]; i++) { + if (!strcmp(str, old_lines[i].str)) { + char small_buffer[10]; + int old_size; + + gtk_text_set_point(GTK_TEXT(info_text),old_lines[i].start); + + if(old_lines[i].num == 1) { + old_size = 0; + } else { + sprintf(small_buffer, "(%i) ", old_lines[i].num); + old_size = strlen(small_buffer); + gtk_text_forward_delete(GTK_TEXT(info_text), old_size); + } + + sprintf(small_buffer, "(%i) ", ++(old_lines[i].num)); + gtk_text_insert (GTK_TEXT (info_text), NULL, + &root_color[old_lines[i].color], NULL, + small_buffer , -1); + if(strlen(small_buffer) != old_size) { + int j; + for(j = i+1; j < use_config[CONFIG_REPEAT]; j++) { + old_lines[j].start += + strlen(small_buffer) - old_size; + } + } + + info2_num_chars = gtk_text_get_length(GTK_TEXT(info_text)); + gtk_text_set_point(GTK_TEXT(info_text), info2_num_chars); + return; + } + } + + memmove(&old_lines[0], &old_lines[1], + sizeof(old_lines[1]) * (use_config[CONFIG_REPEAT]-1)); + strcpy(old_lines[use_config[CONFIG_REPEAT]-1].str, str); + old_lines[use_config[CONFIG_REPEAT]-1].length = strlen(str); + old_lines[use_config[CONFIG_REPEAT]-1].start = + gtk_text_get_length(GTK_TEXT(info_text)); + old_lines[use_config[CONFIG_REPEAT]-1].color = ncolor; + old_lines[use_config[CONFIG_REPEAT]-1].num = 1; + } else { + /* Move the oldest line out of the buffer anyway */ + memmove(&old_lines[0], &old_lines[1], + sizeof(old_lines[1]) * (use_config[CONFIG_REPEAT]-1)); + *old_lines[use_config[CONFIG_REPEAT]-1].str = 0; + old_lines[use_config[CONFIG_REPEAT]-1].length = strlen(str); + old_lines[use_config[CONFIG_REPEAT]-1].start = + gtk_text_get_length(GTK_TEXT(info_text)); + old_lines[use_config[CONFIG_REPEAT]-1].color = ncolor; + old_lines[use_config[CONFIG_REPEAT]-1].num = 1; + } + } + + if (use_config[CONFIG_SPLITINFO] && color != NDI_BLACK) { if (use_config[CONFIG_TRIMINFO]) { info2_num_chars += strlen(str) + 1; /* Limit size of scrollback buffer. To be more efficient, delete a good @@ -1917,20 +2004,16 @@ if (info2_num_chars > info2_max_chars ) { gtk_text_set_point(GTK_TEXT(gtkwin_info_text2),0); gtk_text_forward_delete(GTK_TEXT(gtkwin_info_text2), (info2_num_chars - info2_max_chars) + 5000); + for(i=0; i < use_config[CONFIG_REPEAT]; i++) { + old_lines[i].start -= (info2_num_chars - info2_max_chars) + 5000; + } info2_num_chars = gtk_text_get_length(GTK_TEXT(gtkwin_info_text2)); gtk_text_set_point(GTK_TEXT(gtkwin_info_text2), info2_num_chars); fprintf(stderr,"reduced output buffer2 to %d chars\n", info1_num_chars); } } - gtk_text_insert (GTK_TEXT (gtkwin_info_text2), NULL, &root_color[ncolor], NULL, str , -1); - gtk_text_insert (GTK_TEXT (gtkwin_info_text2), NULL, &root_color[ncolor], NULL, "\n" , -1); - } else { /* all nootes in the above section apply here also */ - if (!draw_info_freeze1){ - gtk_text_freeze (GTK_TEXT (gtkwin_info_text)); - draw_info_freeze1=TRUE; - } if (use_config[CONFIG_TRIMINFO]) { info1_num_chars += strlen(str) + 1; if (info1_num_chars > info1_max_chars ) { @@ -1941,6 +2024,9 @@ to_delete++; gtk_text_set_point(GTK_TEXT(gtkwin_info_text),0); gtk_text_forward_delete(GTK_TEXT(gtkwin_info_text), to_delete); + for(i=0; i < use_config[CONFIG_REPEAT]; i++) { + old_lines[i].start -= (info2_num_chars - info2_max_chars) + 5000; + } info1_num_chars = gtk_text_get_length(GTK_TEXT(gtkwin_info_text)); gtk_text_set_point(GTK_TEXT(gtkwin_info_text), info1_num_chars); fprintf(stderr,"trim_info_window, deleted %d characters, %d remaining\n", to_delete, info1_num_chars); @@ -1955,10 +2041,10 @@ } } - - gtk_text_insert (GTK_TEXT (gtkwin_info_text), NULL, &root_color[ncolor], NULL, str , -1); - gtk_text_insert (GTK_TEXT (gtkwin_info_text), NULL, &root_color[ncolor], NULL, "\n" , -1); } + gtk_text_insert (GTK_TEXT (info_text), NULL, &root_color[ncolor], NULL, str , -1); + gtk_text_insert (GTK_TEXT (info_text), NULL, &root_color[ncolor], NULL, "\n" , -1); + } @@ -5121,6 +5207,7 @@ puts("-triminfowindow - Trims size of information window(s)"); puts("-notriminfowindow - Do not trims size of information window(s) (default)"); puts("-updatekeycodes - Update the saved bindings for this keyboard."); + puts("-repeat - How many lines back we look for repeated text."); exit(0); } @@ -5353,6 +5440,14 @@ } else if (!strcmp(argv[on_arg],"-nosplash")) { want_config[CONFIG_SPLASH] = FALSE; + continue; + } + else if (!strcmp(argv[on_arg],"-repeat")) { + if (++on_arg == argc) { + fprintf(stderr,"-repeat requires a value\n"); + return 1; + } + want_config[CONFIG_REPEAT]=atoi(argv[on_arg]); continue; } else { ----------------8<---------------- /Sebastian -- .oooO o,o Oooo. ( ) \_/ ( ) (o_ "Life is not fair, but root \ ( /|\ ) / (o_ //\ password helps!" -- The BOFH \_) (_/ (/)_ V_/_ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 29 12:41:47 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:46 2005 Subject: [CF-Devel] Stats adjudication In-Reply-To: <001901c35644$311aa320$749dacce@KAMERIA> References: <1059399456.dafb0900yann.chachkoff@myrealbox.com> <1059408897.1238.1.camel@debian> <000b01c35590$3986e820$1076e2d1@KAMERIA> <003c01c35530$0d78af30$693ae940@nbcusa.net> <3F2604DF.7010108@sonic.net> <001901c35644$311aa320$749dacce@KAMERIA> Message-ID: <20030729144147.5ba6963a.kstenger@montevideo.com.uy> > Well I meant more like 12 12 12 12 12 12 12 (this is two points above > average if natural max is 20 BTW)and get say 5 points to add and I like that > idea of limited point transfer idea where you can move an additional 10 or > so existing points around. > This could give you 15 8 15 16 10 17 9 or 20 16 15 9 12 8 9 Thinking on that, we could also try this... - initial 7d12 roll. We can arrange the stats values here (or maybe we leave them in the order they were rolled since the player can add points later and this will mostly avoid chars like 18 18 18 18 18 9 1). So we would have a total average of 45.5 points here. Lets say: 9 2 12 3 6 3 11 (sum 46) - apply race/class modifiers - give 54 points to spend so we had 99.5 total average, 20 maximum each skill Could give us: 19 17 20 10 11 12 11 (sum 100) Here we could ask for two or three points in order to let the player raise a stat from 19 to 20 so that will be less used (but still 19 is pretty good). My points here are: 1) don't let the stats be totally made up by the player and be sure to make them half random half choosen. This way they wont have to worry too much about rolls cause they can change them later. 2) give the points after we choose class and race so the player will be working on the final stats of his char without worrying about later midifiers beeing applied. Just a thought :-) What do you think? Katia. -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 30 03:21:31 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:46 2005 Subject: [CF-Devel] Stats adjudication References: <1059399456.dafb0900yann.chachkoff@myrealbox.com><1059408897.1238.1.camel@debian><000b01c35590$3986e820$1076e2d1@KAMERIA><003c01c35530$0d78af30$693ae940@nbcusa.net><3F2604DF.7010108@sonic.net><001901c35644$311aa320$749dacce@KAMERIA> <20030729144147.5ba6963a.kstenger@montevideo.com.uy> Message-ID: <001e01c35673$95f51300$39f7d1d8@KAMERIA> - give 54 points to spend so we had 99.5 total average, 20 maximum each skill Could give us: 19 17 20 10 11 12 11 (sum 100) Here we could ask for two or three points in order to let the player raise a stat from 19 to 20 so that will be less used (but still 19 is pretty good). - a 19 17 and a 20 and with no stats below 10 seems rather high for a starting point, no? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 29 16:00:56 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:46 2005 Subject: race and class faces (Re: [CF-Devel] Stats adjudication) In-Reply-To: <003101c355e0$0f5834a0$693ae940@nbcusa.net> References: <1059399456.dafb0900yann.chachkoff@myrealbox.com> <1059408897.1238.1.camel@debian> <000b01c35590$3986e820$1076e2d1@KAMERIA> <003c01c35530$0d78af30$693ae940@nbcusa.net> <3F2604DF.7010108@sonic.net> <001901c35644$311aa320$749dacce@KAMERIA> <003101c355e0$0f5834a0$693ae940@nbcusa.net> Message-ID: <20030729210056.GG22513@laranja.org> I've been giving this some thought too recently, I favor the race+class approach (c'mon, elf wizard should look different than elf pirate) but I couldn't yet come up with a technically viable way of doing this. Only one I imagined that works (this doesn't mean it's the only one that exists, just the only one I found yet): use different archs for classes, so there is a warlock (human), warlock_elf, warlock_dragon etc class. The race field is used to determine if a combination is valid, which is a feature we don't have currently. Then the HallOfSelection would probably need to become more automated, I fear. (much hoping to see a dragon wizard face...) On Tue, Jul 29, 2003 at 09:45:30AM -0500, Yua CaVan wrote: > As far as race/class faces. I would agree that race is visible and should > be used over class. I'm also thinking, though, if we can get the artists > together -- have different faces for each race/class combination. just my > $0.02. > > > > Now on the topic of starting out, I am a big fan of using the race faces and > > not the class faces. I know that many people like the class faces so I > > won't advocate only using the race ones (but come on people- race is > > visible, class is just your skills....what if you are in your leisure > > clothes?) and would like to see a starting option to be able to choose to > > keep the race face or use the class one (hmnnn, or maybe a command to be > > able to switch between them in game perhaps?) []s, |alo +---- -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://www.laranja.org/pessoal/pgp Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ GNU: never give up freedom http://www.gnu.org/ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 29 16:39:33 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:46 2005 Subject: [CF-Devel] FTP mirrors Message-ID: Hi, the download mirror on ftp.ifi.uio.no has not been updated for years. I think it should be removed from the mirror list. Also, I would suggest some auto-qa, like a script checking if all the ftp's are being updated... In addition, the pages don't render well in Opera7/Linux. -- Jan Kroken (xeno) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 29 17:56:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:46 2005 Subject: [CF-Devel] Stats adjudication In-Reply-To: <001e01c35673$95f51300$39f7d1d8@KAMERIA> References: <1059399456.dafb0900yann.chachkoff@myrealbox.com> <1059408897.1238.1.camel@debian> <000b01c35590$3986e820$1076e2d1@KAMERIA> <003c01c35530$0d78af30$693ae940@nbcusa.net> <3F2604DF.7010108@sonic.net> <001901c35644$311aa320$749dacce@KAMERIA> <20030729144147.5ba6963a.kstenger@montevideo.com.uy> <001e01c35673$95f51300$39f7d1d8@KAMERIA> Message-ID: <20030729195605.4cb45a61.kstenger@montevideo.com.uy> > - give 54 points to spend so we had 99.5 total average, 20 maximum each > skill > Could give us: 19 17 20 10 11 12 11 (sum 100) > Here we could ask for two or three points in order to let the player > raise a stat from 19 to 20 so that will be less used (but still 19 is > pretty good). > > - a 19 17 and a 20 and with no stats below 10 seems rather high for a > starting point, no? Thats true, but this can be fixed by giving less points (54 was just my first aproach), or charge 2 points for a 19, and 3 points for a 20 ;-) -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Jul 29 18:30:51 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:46 2005 Subject: [CF-Devel] FTP mirrors In-Reply-To: Message-ID: On Tue, 29 Jul 2003, Jan Kroken wrote: > the download mirror on ftp.ifi.uio.no has not been updated for > years. I think it should be removed from the mirror list. > Removed it from the website for now.. can always add it again later or when necessary. > > In addition, the pages don't render well in Opera7/Linux. Resolved - browser was not loading the (CSS) Style Sheets. Essentially showing the "lynx" or "text" version of the website. - Rick Tanner leaf@real-time.com -- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 30 02:00:13 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:46 2005 Subject: [CF-Devel] Stats adjudication In-Reply-To: <20030729195605.4cb45a61.kstenger@montevideo.com.uy> References: <1059399456.dafb0900yann.chachkoff@myrealbox.com> <1059408897.1238.1.camel@debian> <000b01c35590$3986e820$1076e2d1@KAMERIA> <003c01c35530$0d78af30$693ae940@nbcusa.net> <3F2604DF.7010108@sonic.net> <001901c35644$311aa320$749dacce@KAMERIA> <20030729144147.5ba6963a.kstenger@montevideo.com.uy> <001e01c35673$95f51300$39f7d1d8@KAMERIA> <20030729195605.4cb45a61.kstenger@montevideo.com.uy> Message-ID: <3F276CFD.4050107@sonic.net> IMO, a set of points vs random rolls is the way to go. The reason can be seen in the current method - if by re-rolling, you can get better stats, you'll re-roll to maximize your characters. This is one reason I prefer just some set number of points. As for selection of stats, it then comes down to more interface of the client. Eg, it may be easier to have all the stats start at 12, and let players adjust them up or down. that's really more an issue of refinement of the interface probably, and less about the system itself (unless you do want to limit adjustements within some value of the base stats). As for penalties, depnds on the character. Arguably, most characters will care not a whole bunch about charisma. But if your playing a fighter, you might be willing to also have a crummy pow score for example. IMO, the discussion at current time should really be about what a fair system (in terms of points or whatever is), and not about the interface. If the handling is mostly done on the client, the interface can be much more flexible than right now, and also a whole bunch better. For example, the stats could have some column, like 'racial adjustment' and 'class adjustment', and thus make it very easy to see how the race and class adjusts the stats for example _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 30 10:08:39 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:46 2005 Subject: [CF-Devel] Features suggestions & questions In-Reply-To: <3F22114E.9070406@sonic.net> References: <3F22114E.9070406@sonic.net> Message-ID: <3F27DF77.5060209@laposte.net> Hello. I've been starting to check how to implement a custom name for items. As I see it, I need to tweak loader.l to correctly load/save the custom name, object.c for copy/free, and arch.c:item_matched_string to handle it. Custom name will of course appear in the 'examine' result, and will be used for name matching on apply/mark/and so on (through item_matched_string). I got a question related to client side, though: would it be better to see the custom name in inventory window? or keep original name? I'd rather see the custom name, so you don't have to examine items to know their custom name. But maybe that would break some things? As i see the code, it's just a matter of replacing 'name' with the custom name in the sending code (at least 3 times [almost] the same code, btw...). Also should name be saved when dropping the object? I'd say yes so you can exchange stuff with others. And also don't lose the name by simply dropping ^_^ Of course that may cause troubles if a player sees an item with a custom name & doesn't check the real name... What do you think of that? Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 30 10:16:39 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:46 2005 Subject: [CF-Devel] Question on c_object.c:sack_can_hold Message-ID: <3F27E157.5060206@laposte.net> Hello. Browsing randomly through the code, i checked sack_can_hold in c_object.c As the implementation is, the 'You can't put the %s into itself.' message may be erased when putting a container into itself, mainly if the container is specific (pouch, quiver, ...). In that case, op == sack indeed, but sack->race is set and op->type == CONTAINER, thus erasing the message. Maybe it'd be better to switch the tests? Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 30 10:26:52 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:46 2005 Subject: [CF-Devel] Re: Repeated line supression for the gtk client. Message-ID: <20030730172652.C3461@diegeekdie.com> After playing with the patch on another computer, I got hit by some bug in gtk, making the program crash while gtk was removing text from the info text widget. Both machines were running debian's libgtk1.2-1.2.10-11. Searching the net gives more examples of gtk crashing if one uses gtk_text_forward_delete while the widget is frozen. So this patch should probably not be applied to cvs yet, or the default value (want_config[CONFIG_REPEAT]) should be changed to 0. Regards, /Sebastian _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 31 03:31:45 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:46 2005 Subject: [CF-Devel] Stats adjudication References: <1059399456.dafb0900yann.chachkoff@myrealbox.com> <1059408897.1238.1.camel@debian> <000b01c35590$3986e820$1076e2d1@KAMERIA> <003c01c35530$0d78af30$693ae940@nbcusa.net> <3F2604DF.7010108@sonic.net> <001901c35644$311aa320$749dacce@KAMERIA> <20030729144147.5ba6963a.kstenger@montevideo.com.uy> <001e01c35673$95f51300$39f7d1d8@KAMERIA> <20030729195605.4cb45a61.kstenger@montevideo.com.uy> <3F276CFD.4050107@sonic.net> Message-ID: <001601c3573e$2dfdc320$9f9dacce@KAMERIA> > IMO, a set of points vs random rolls is the way to go. > > The reason can be seen in the current method - if by re-rolling, you can get > better stats, you'll re-roll to maximize your characters. This is one reason I > prefer just some set number of points. > Yup. Folks will just roll until the cows come home. > As for selection of stats, it then comes down to more interface of the client. > Eg, it may be easier to have all the stats start at 12, and let players adjust > them up or down. that's really more an issue of refinement of the interface > probably, and less about the system itself (unless you do want to limit > adjustements within some value of the base stats). > Yup - it just seemed to me faster and easier to preallocate and modify than to assign points from scratch. Totally an interface issue. In the case I suggested it would amount to 12x7+5 = 89~90 points with a arbitrary limit on how much you can transfer. Being that 20 is normal maximum, 10 is dead average so 70 points represents the average character, but as adventurers are not average they get an additional 20 or so points to spread around. Racial modifiers make some sense, but I wonder if we should really be doing the stat modifiers for classes as well. > As for penalties, depnds on the character. Arguably, most characters will > care not a whole bunch about charisma. But if your playing a fighter, you might > be willing to also have a crummy pow score for example. If players don't care at all about a particular stat then maybe that is an indication that the stat needs to be looked at and game adjustments made. It should be possible to get a real high in exchange for a really low stat if you want to play it, but it should be difficult to play it (the character with the one of 20 and another of 4 can be fun, but it shouldn't be standard for every PC to do this because some stats are only useful in narrow applications (like if POW is only useful for spell use). I wouldn't want to see stat plundering where less useful stats become a source of easy starting points. A charisma of 6 or 7 may be very crummy, a charisma of 3 or 2 should be debilitating to the point that most people wouldn't want to play it even if it was not relevant to their class. A lot of this sort of thing could be fixed/fine-tuned over time by incorporating more stat based calculation into skills and functions rather than limiting the interface, but until there are really good penalties for really low stats, it would be easy and perhaps quicker to make a minimum stat requirement in the creation interface or put a cap on the amount of points you can transfer between stats... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 30 15:08:56 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:46 2005 Subject: [CF-Devel] Stats adjudication In-Reply-To: <3F2604DF.7010108@sonic.net> Message-ID: On 29-Jul-03 Mark Wedel wrote: > One could just completely smooth the tables, ala AD&Dv3. If that was done, > you could remove all stat limits (90 strength? Fine.) This would probably > make > things a bit more interesting in fact - do you get for that 34 int but only > 26 > pow, or do you go for 30 int and 30 pow? If we were going to do that, might I suggest we intead go with a modified version of the moria stats system? For those not familiar.. Moria uses the 1-18, then 18/1 -> 18/100. Similar to strength in adndV2. I think in moria, a STR potion will buy you an increase of 1 point up to 18, then you get like 5/100 for each one after that, up to around 30, where it slowly goes down to 1:1. You end up needing like 50-60 potions to go up to max 18/100. We could twiddle this a bit.. perhaps make it so you can go from 18/100 -> 19, and so on, but you need a super strength potion to do so. Super str potions would be an alchemically derrived potion only, which could be something like 20 str potions : 1 super potion. Or you could just record the number of times you drank a regular one after 18/100, and when you've had 20, you suddenly go to 19. Then after 30 more, you go to 20, and so on. So you can get ultra-high stats, it just becomes a more difficult challenge to do so. Or, we could make super str potions, and only make them available in some difficult quest treasure hoards. So you have to get up to 18/100 with regular ones, then you have to hunt down the hard to find ones. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 30 18:25:42 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:46 2005 Subject: [CF-Devel] Stats adjudication In-Reply-To: Message-ID: On Wed, 30 Jul 2003, Tim Rightnour wrote: > If we were going to do that, might I suggest we intead go with a modified > version of the moria stats system? > > For those not familiar.. Moria uses the 1-18, then 18/1 -> 18/100. Similar to > strength in adndV2. I think in moria, a STR potion will buy you an increase of > 1 point up to 18, then you get like 5/100 for each one after that, up to around > 30, where it slowly goes down to 1:1. You end up needing like 50-60 potions to > go up to max 18/100. How does Moria handle items that modify abilities? For instance, how would a ring of Str+2 effect the character strength score? Base STR of 16 becomes 18 (right?) Base STR of 18 becomes 18/02 or 18/20 or 20? Just wondering.. - Rick leaf@real-time.com _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 30 19:03:15 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:46 2005 Subject: [CF-Devel] Stats adjudication In-Reply-To: Message-ID: On 30-Jul-03 Rick Tanner wrote: > How does Moria handle items that modify abilities? > > For instance, how would a ring of Str+2 effect the character strength > score? > > Base STR of 16 becomes 18 (right?) > > Base STR of 18 becomes 18/02 or 18/20 or 20? > > Just wondering.. IIRC, and it's been a while, but they modify it just like a potion of str would. So for example, if you were 18, and drank 2 potions of str, you become 18/10. So the +2 would do the same. Conversely, if you were 18/90, and drank 2, I think it puts you at 18/92, the +2 should do the same. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Jul 30 23:56:42 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:46 2005 Subject: [CF-Devel] Features suggestions & questions In-Reply-To: <3F27DF77.5060209@laposte.net> References: <3F22114E.9070406@sonic.net> <3F27DF77.5060209@laposte.net> Message-ID: <3F28A18A.8010206@sonic.net> Nicolas Weeger wrote: > Hello. > > I've been starting to check how to implement a custom name for items. > > As I see it, I need to tweak loader.l to correctly load/save the custom > name, object.c for copy/free, and arch.c:item_matched_string to handle it. CAN_MERGE would also need to be updated. > I got a question related to client side, though: would it be better to > see the custom name in inventory window? or keep original name? > I'd rather see the custom name, so you don't have to examine items to > know their custom name. But maybe that would break some things? As i see > the code, it's just a matter of replacing 'name' with the custom name in > the sending code (at least 3 times [almost] the same code, btw...). I can't see how sending the custom name to the client would break anything. Presumably, if the player sets a custom name for an object, he wants to see it. Perhaps add a new F_ value (F_CUSTOM_NAME) in the newclient.h so the client can easily know it is a custom name and do something clever with it. Looks like the flag field is 4 bytes, so no problem there. > > Also should name be saved when dropping the object? I'd say yes so you > can exchange stuff with others. And also don't lose the name by simply > dropping ^_^ > Of course that may cause troubles if a player sees an item with a custom > name & doesn't check the real name... > What do you think of that? I think the name has to be stripped in some cases. Certainly, anything sold to a store should lose its custom name. do you really want to see a store with all sorts of misnamed objects? I agree that you want to be able to exchange things. But at the same time, I don't think custom names should persist for ever. That is why I suggested that if a map is being saved, it strips the custom name at that point unless the item is being saved to a 'permanent' map, like an apartment. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 31 00:02:37 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:46 2005 Subject: [CF-Devel] Re: Repeated line supression for the gtk client. In-Reply-To: <20030730172652.C3461@diegeekdie.com> References: <20030730172652.C3461@diegeekdie.com> Message-ID: <3F28A2ED.9090900@sonic.net> Sebastian Andersson wrote: > After playing with the patch on another computer, I got hit by some bug > in gtk, making the program crash while gtk was removing text from the > info text widget. Both machines were running debian's libgtk1.2-1.2.10-11. > Searching the net gives more examples of gtk crashing if one uses > gtk_text_forward_delete while the widget is frozen. > So this patch should probably not be applied to cvs yet, or > the default value (want_config[CONFIG_REPEAT]) should be changed to 0. Yes - known bug, which is why 'trim info window', which tries to keep size of that window to a reasonable size. However, a bigger level, I consider the patch superfluous. The server already does message collapsing. There are many places where messages are not being properly reduced, but that is a pretty trivial change to the server (just remove the NDI_UNIQUE tag from the message). But that code (draw_info) on the server should be cleaned up as I said in a previous message - instead of passing color informatin (and other flags), it should instead pass a content flag (list, say, shout, etc), and the client could then do things change font, use color based on player preference, etc. Much more flexible. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 31 00:37:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:47 2005 Subject: [CF-Devel] Stats adjudication In-Reply-To: References: Message-ID: <3F28AB16.4040602@sonic.net> Actually, if the tables are smoothed out (eg, you get just as much in terms of added bonus from 20 to 25 and you do from 25 to 30), a more linear advancement system would also make sense. The system you describe in moria would probably make more sense for the current system, where going from an 18 to 19 makes a whole bunch more difference than from say 14 to 15. Anyways, the idea of increase the max stat and smoothing out the bonuses was just a random idea. But I guess what you're really saying was that it was relatively easy to get to your racial maximum, and then going beyond that is quite difficult, but still possible. Note that with the current stat gen system, average is I think around 13 (it uses the roll 4d6, keep best 3 method). I also note that code is place that will automatically re-roll if the sum of stats is less than 82 or greater than 116. This would be an average of 11.7 to 16.5. I agree it doesn't make a lot of sense for class to change stats. Classes should really deal with starting skills, and starting equipment in most cases (spellbooks for spellcasters for example). As for stats, its tough. Cha is always of limited usefulness (it gets you better prices in stores, but the simple way around this is to make up a first level character with a high charisma just for this purpose). fighter types have it easier - str, dex, con are useful for them. Int, Wis, Pow are arguably less useful, until they want to pick up some spells. But spell casters have it harder. Con is still useful for hp, str and dex for movement, but perhaps not as important. So spell casters don't really have any stats they could toss something really low into, while other classes do. I don't really have any solution to that problem. However, one could certainly argue that we should just get rid of charisma, make buying/selling fixed rate, and leave it that unless someone has something better to do with cha. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 31 03:59:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:47 2005 Subject: [CF-Devel] Re: Repeated line supression for the gtk client. In-Reply-To: <3F28A2ED.9090900@sonic.net>; from Mark Wedel on Wed, Jul 30, 2003 at 10:02:37PM -0700 References: <20030730172652.C3461@diegeekdie.com> <3F28A2ED.9090900@sonic.net> Message-ID: <20030731105926.D3461@diegeekdie.com> On Wed, Jul 30, 2003 at 10:02:37PM -0700, Mark Wedel wrote: > However, a bigger level, I consider the patch superfluous. The server already > does message collapsing. There are many places where messages are not being > properly reduced, but that is a pretty trivial change to the server (just remove > the NDI_UNIQUE tag from the message). I've never liked the way the server does message collapsing right works now, from a playing point of view. First of all "1 times You pray". The "1 times" should be removed, probably an easy fix, it looks really ugly. Then the annoying time delay until you see the first message makes one think the server is lagging, the key binding doesn't work or something. It can of course be made smaller by changing the default value, but then it collapses fewer messages. A better fix would be to send the first collapsable message immediatly, then start to collapse it. Thirdly, it doesn't work when you mix two messages, does it? Like: "1 times The ball of lightning zaps dragon" "1 times The ball of lightning electrocutes dragon" "1 times The ball of lightning zaps dragon" "1 times The ball of lightning electrocutes dragon" After playing some more with my patch, I changed my patch to move the collapsed lines down to the bottom again so the latest message is always closest to the bottom. It is usually easier to read when there are not too many different messages comming in (like the usual case for low level characters). If one looks at it from a system point of view, the messages should be collapsed on the server to save bandwidth. But the server can't (yet) update old messages in the client and that is needed if one wants more info to fit on the screen (like the ball lightning example). The best thing is probably to combine output-sync with my patch (if gtk was working that is). The "X times" could be removed in the client and then my new patch could further collapse the messages. Even better would be a way for the server to send a shorter message, telling which message was repeated and let the client repeat it, but I don't know if the few bytes it would save (and further client/server complication) would be worth it. Regards, /Sebastian _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 31 03:39:09 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:47 2005 Subject: [CF-Devel] Stats adjudication In-Reply-To: <3F28AB16.4040602@sonic.net> Message-ID: On 31-Jul-03 Mark Wedel wrote: > Actually, if the tables are smoothed out (eg, you get just as much in terms > of > added bonus from 20 to 25 and you do from 25 to 30), a more linear > advancement > system would also make sense. > > The system you describe in moria would probably make more sense for the > current system, where going from an 18 to 19 makes a whole bunch more > difference > than from say 14 to 15. Well, my proposal accomplishes a few things: 1) We get a smoother ramp, as you said, we smooth the tables out. 2) We add a bunch more work to maxing out one's stats. It's no longer a matter of finding a few potions, you now have alot more to find. It extends the challenge a bit that way. 3) You get diminishing returns on potions as you get closer to perfection. This reflects the fact that really high stats, are an abberation, and require alot of magic to obtain, not just 7 stat potions. > I don't really have any solution to that problem. However, one could > certainly argue that we should just get rid of charisma, make buying/selling > fixed rate, and leave it that unless someone has something better to do with > cha. Charisma is one of those stats that is never truly useful in most games. I think our problem is that we instananeously nullify it with the bargaining skill. Random ideas follow: 1) AD&Dv2 says that negative charisma can cause fear, and charisma over 19 can cause awe. (for gods only, but we can extend/fiddle that) 2) What if charisma affected pets/followers. Perhaps you can only control N followers with a charisma of 18. Or, your range of control is higher, like, a person with low charisma can't control a pet beyond a certain distance, or perhaps the amount of time they remain pets is limited. 3) I saw one game that used appearance as a stat, rather than charisma. The game took into account everything.. and assigned a number between like 1-300 or so. You had a base appearance, and as you wore items, that changed. The golden armour made you look better than the iron armour. If you wore all the same material, vs some of each, you got bonuses for matching. You could tie appearance to shops, rather than charisma. In addition, the game had a board, where players would register. It was a top 30 list of the most beautiful people. It was an interesting diversion. The "registration" process took a snapshot of your appearance score, meaning you could twiddle around with it, take the high score, and then revert to useful armour for fighting. 4) Perhaps occasionally you get a nasty cut that scars, you could lose charisma (or gain it).. Meaning you might have to occasionally maintain it with potions. 5) Maybe charisma potions should not exist. You can raise your charisma by becoming a prince/hero/noble of scorn, or other quests, or by the things listed in #4. If it were up to me, I'd say we implement #3, and tie in the ideas in #2 as well. Charisma could be the base stat for appearance, and your equipment gets added to that for the overall appearance score. Shopping would be based on appearance. Maybe some shops/towns only let beautiful people in. Perhaps if you are ugly, shops will randomly screw you on prices at time of sale. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Jul 31 23:58:47 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:47 2005 Subject: [CF-Devel] Stats adjudication References: <3F28AB16.4040602@sonic.net> Message-ID: <001401c357e9$983c7000$1c9dacce@KAMERIA> > Actually, if the tables are smoothed out (eg, you get just as much in terms of > added bonus from 20 to 25 and you do from 25 to 30), a more linear advancement > system would also make sense. > I am not a big fan of the 18/00 thing you can get the same effect with whole numbers. I do like the idea of twiddling the amount or type of magic/potions you need to raise stats as you approach the ends of the distribution curve (some loose idea like one potion per standard deviation). Actually if it is harder to raise really high *and* really low stats this partly addresses the issue of players plundering less useful stat values into really low ranges to get more points in their prime stats since it becomes much harder to recover from this behaviour. > But I guess what you're really saying was that it was relatively easy to get > to your racial maximum, and then going beyond that is quite difficult, but still > possible. > I wouldn't change the difficulty of raising the stat based on race either, if a race start with 22 then it should be just as hard to raise the stat to 23 as if they were human starting at 20, raised to 21,22 and raising it to 23. Having the racial bonus should only be applicable to starting, not a ongoing bonus throughout the game. > Note that with the current stat gen system, average is I think around 13 (it > uses the roll 4d6, keep best 3 method). > > I also note that code is place that will automatically re-roll if the sum of > stats is less than 82 or greater than 116. This would be an average of 11.7 to 16.5. > Yes but as you say players will roll until they get the 116... A stat average of ~12.5 seems reasonable to me. Of course it all depends on the basic maximum and the bonuses you get for the stats. > I agree it doesn't make a lot of sense for class to change stats. Classes > should really deal with starting skills, and starting equipment in most cases > (spellbooks for spellcasters for example). Ya, skills - not to say an exception can't be made, to balance some other large factor (perhaps like for monks) or whatever, but *most* classes should not have stat modifiers. However I think that currently with races and classes that both get an stat bonus for the same reason (like no armor) this is being abused. > I don't really have any solution to that problem. However, one could > certainly argue that we should just get rid of charisma, make buying/selling > fixed rate, and leave it that unless someone has something better to do with cha. > Keep Charisma! I think that just working the stats into more things over time (especially more skills) would fix this sort of thing - Crossfire already does a pretty good job of using the stats compared to many games- although the system may need some value adjustments. Anyway there is always lots of ways to work existing stats into the game more, especially with a new skills system. Imagine if NPC's would not speak as much to player with low CHA (lots of work...), or if it impacted your summoning skills or number and duration of pets or such. Then again if CHA and POW were merged into one stat that would be interesting... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel