From crossfire-devel-admin at archives.real-time.com Thu May 1 01:48:03 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:06 2005 Subject: [CF-Devel] More Lore In-Reply-To: <001c01c1f028$feddee80$0802a8c0@KAMERIA> References: <000801c1ee6d$1f48df80$0802a8c0@KAMERIA> <3EAE276B.1020101@sonic.net> <001b01c1ef65$9c4fdee0$0802a8c0@KAMERIA> <3EAF5404.8060502@sonic.net> <001c01c1f028$feddee80$0802a8c0@KAMERIA> Message-ID: <3EB0C323.9000700@sonic.net> I still think it would be better to put it in the map header and not as objects - just seems easier to do. Indications are that AV is willing to update the java editor to do this. Yes, there needs to be a minor amount of server changes to properly handle this - but that is pretty minor. I just think that having it in the map header is the right place. To answer AV's question about why multiple lore/endlore areas are desired within the map header: the probability of lore is relative to itself. For example, it may be 1% that any single lore list is chosen. Thus, if you have 5 lore lists in the map header, there is a 5% (total) chance of one of those being chosen. For most maps, this may not be much of an issue (one random area should be enough). But for some, perhaps like the cities, it may be desirable to have several such entries - just to perhaps be more maintainable and to increase likelihood of city stuff showing up. I'd also think to some extent what is within the lore field in the map header be opaque, eg, the editor will load it/save it, but just treat it as text, and let the user edit it in whatever fashion. Thus, having a maplore/endmaplore wouldn't really cost anything extra, and provides the extra flexiblity - maybe most maps only have one lore/endlore structure, but probably easier to allow that extra in case we do wnat to tie other stuff to it. _______________________________________________ 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 May 1 07:20:21 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:07 2005 Subject: [CF-Devel] More Lore References: <3EB0C323.9000700@sonic.net> Message-ID: <2546.1051791621@www60.gmx.net> Mark W. wrote: > > I still think it would be better to put it in the map header and not as > objects - just seems easier to do. Indications are that AV is willing > to update the java editor to do this. Yes, I will do this. What I'd like to do is adding a maplore textfield to the map properties dialog (that's where all map-header data shows up). Handling the lore field for arches won't be hard to do either. I also want to comment on Todd's screenshot: The lore icon is really nice, and yes one can see it easily. But think about a 50x50 map where you can't see initially where the lore is. Then, just imagine you do cut/copy/paste actions and suddenly the lore is deleted or copied to another map, or dublicated. Imagine lore moving under the floor due to fill commands..., or getting lost in a map resize action... Having maplore in the map header is really better IMO. > I'd also think to some extent what is within the lore field in > the map header be opaque, eg, the editor will load it/save it, > but just treat it as text, and let the user edit it in whatever > fashion. Thus, having a maplore/endmaplore wouldn't really cost > anything extra, and provides the extra flexiblity - maybe > most maps only have one lore/endlore structure, but probably > easier to allow that extra in case we do wnat to tie other stuff > to it. Sure, I agree to that. I will treat it as text in the editor. That's easy and also avoids troubles when there are changes in the lore syntax. Expect it to work like the message field. The editor takes care of the start/end tags, and the rest is plain text. Is there already a consens what the start/end tags are going to be? I assume it stays "lore"/"endlore" for arches. Now if we agreed on the map-header thing, what would the tags be there? AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ 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 May 2 01:51:54 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:07 2005 Subject: [CF-Devel] More Lore In-Reply-To: <001201c1f0c2$ba46ac40$0802a8c0@KAMERIA> References: <3EB0C323.9000700@sonic.net> <2546.1051791621@www60.gmx.net> <001201c1f0c2$ba46ac40$0802a8c0@KAMERIA> Message-ID: <3EB2158A.3050900@sonic.net> Todd Mitchell wrote: > > How is this different than the lore coming in from the arches? Remember if > you put lore in an orc or in a magical putter you have to be careful not to > cut and paste that to another map, (also it is still much easier to manage > than connectors and the like). Remember that lore is going to work it's way > into the maps through the arches anyway. Putting it in the header only means > you need two routines to collect it and a way to distinguish between the > lore fields in the header. That is the only benefit - that you need to > collect it from two different places in two different ways. I can't see it > provides any extra flexability or functionality. There was really not even > a need to make a special map lore arch since you could just use an orc for > the same purpose really, it just makes it easier to see if it has it's own > icon. I'd personally say that changing the lore of objects within the map is not allowed. If you want to broadcast lore about an object, put it in the lore in the map header. This fixes the problems you describe - you don't want to have to worry about cut/paste and lore getting propogated all over the place. As for the format in the header - presumably, when we collect from the archs, we turn something like : arch orc name orc .. lore ... ... endlore ... end into lore orc ... ... end In the lore file (or whatever it is called) - at some point in the collection process, the object it describes has to be preserved and put into the lore file itself. There is no reason that that the stuff within the maplore/endmaplore doesn't follow what ever format is put into that file. So you may have something like. maplore lore siegfried ... endlore lore jonas ... endlore endmaplore All that said, this discussion is taking a lot longer than it should. And that said, the person that has not submitted much code to making comments of what is hard to do or not seems a bit presumptuous. I don't mean to be rude in that statement, but given all the time and effort exerted into this discussion, I could probably have made the necessary server changes to support a maplore/endmaplore field in the map header and written a collection script (as a nice bonus, if you know the maplore will only be in the map header, collection is also much faster, and thus more likely people will run it). So that said, I'm putting me foot down here - the code will be implemented within the following rules or not implemented at all. 1) Lore information for maps will be located in the map header and only in the map header. 2) The format 'tags' for the map header will be 'maplore' and 'endmaplore' on a line by themself. All the intervening data will be copied as is into the target lore file. 3) How the lore field is still open to some discussion, but it seems the format will be: lore @chance x one or more lines of data of lore. @chance y one or more lines of data of lore @endlore It is allowable to only have one @chance field. In that case, the actual chance is pretty meaningless, but location or other keywords we decide can still be useful. In the case of lore in map headers, the first 'lore' line will instead contain an object/field the categorizes this lore (hmm - maybe we should do this for the arch as well, thus you could just group things as like 'lore armor' or 'lore sword' or whatever else). _______________________________________________ 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 May 2 08:33:48 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:07 2005 Subject: [CF-Devel] More Lore In-Reply-To: <3EB2158A.3050900@sonic.net> References: <3EB0C323.9000700@sonic.net> <2546.1051791621@www60.gmx.net> <001201c1f0c2$ba46ac40$0802a8c0@KAMERIA> <3EB2158A.3050900@sonic.net> Message-ID: <3EB273BC.9090000@sympatico.ca> Changes made to lore fields in the editor do go into the maps now, as do changes to any arch field. You'll have to fix that if you do not want any lore in the map files outside the header, and since this is the way arches are designed to work (archetypes) you are introducing new problems IMHO. I though this forum was to discuss new features fully *before* implementing them. I am sure you could have written code to implement lore much sooner, so could I. _______________________________________________ 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 May 2 21:58:20 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:07 2005 Subject: [CF-Devel] More Lore In-Reply-To: <3EB273BC.9090000@sympatico.ca> References: <3EB0C323.9000700@sonic.net> <2546.1051791621@www60.gmx.net> <001201c1f0c2$ba46ac40$0802a8c0@KAMERIA> <3EB2158A.3050900@sonic.net> <3EB273BC.9090000@sympatico.ca> Message-ID: <3EB3304C.5020007@sonic.net> Todd wrote: > Changes made to lore fields in the editor do go into the maps now, as do > changes to any arch field. You'll have to fix that if you do not want > any lore in the map files outside the header, and since this is the way > arches are designed to work (archetypes) you are introducing new > problems IMHO. The problem is that by collecting data from the maps that is used before run time, we are heading into something that was never done before. This entire premise could very well be introducing various problems. I'd really not want to far down this path - the number of things I could potentially see collected could get quite large, and quite messy (this is even true with lore, eg, map one adds some lore about 'Sam'. Map 2, completely unrelated, also has lore entries for 'Sam', and the data is unrelated or perhaps contradictory - map1: Sam is immune to magic, and needs to be hit with weapons. map2: Sam is afraid of fire and lightning, and avoids it like the plague). Is this likely? Probably not. And even that may not be terrible. But think if you go down this path and you collect treasure lists from the maps, and you have two treasurelists of the same name, etc. I'd really like to re-inforce the notion that data in the maps really won't be examine. If lore is in the map header but not in the objects, and we don't process the objects, people will quickly see it won't work. It would in fact be possible to make it impossible to modify the lore on an object level. > I though this forum was to discuss new features fully *before* > implementing them. I am sure you could have written code to implement > lore much sooner, so could I. It is. But at some point, discussion has to stop and things more along. However, in this particular case, it seems like an impasse had been reach. My belief: lore data in the map header makes more sense. Your belief: lore data should be in lore objects I didn't see any signs that these beliefs were going to change in either way. I really got the feeling we could discus this for weeks and we'd still be at the same point. And my point was sort of that putting the lore in the map header really isn't as complicate as you make it sound - 5-10 minutes to modify the load/save routine for the map header, 5-10 minutes to write a script (or modify the existing one) to collect the data. So my point on that being that having it in the map header isn't really any more complicated or more difficult to right. _______________________________________________ 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 May 2 22:18:20 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:07 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: References: Message-ID: <3EB334FC.3050304@sonic.net> Tim Rightnour wrote: > On 30-Apr-03 Mark Wedel wrote: > >> Note that live action/human moderated games have the big advantage that a >>human does moderate them. > > > Well.. Mostly my point was.. the people at TSR were smart enough to know if > you let people change bronze -> gold, you'd have a mess on your hands. Such a > spell/ability/whatever is absurd. But is there anything wrong with changing > iron to bronze? I think transmutation is a fine thing, it's just that you have > to be selective about what you let people transmute something into. > Platinum->gold seems fine to me.. lead->gold seems absurd. If we do it.. we > have to think about the results of each transmutation, thats all. Well, most live RPG's also have a balanced economy (if the GM is good). Crossfire doesn't even have that. And in fact, AD&Dv3 even has rules for how much money towns and villages would have. Thus, if you cleared out that cave and brought back 40 short swords, 18 chain mails, etc, the shop in the local village may only be wiling to buy a few before they turn you away. I really don't want to get into an 'enconomy of crossfire' discussion again. But if you thinkg of the raw number of items that players can get, then even increasing the values by 10% can mean a signifcant difference for the players. > I think it would be trivial to implement. All you need is a little chart with > some base values. Say we take iron as the "base" material.. we say iron has a > value and weight of 100. Now we just set "pine" to say, 80, 80. Now if you > wanted to transmute mithril->oak you do: > mithril->iron->pine->oak. Oh yeah, I agree. I didn't think it would be that hard. I was just noting that that information is not currently contained anyplace. And if such transmutation are allowed, I'd have some percent chance (1% maybe) that the transformation goes awry and the item destroyed. Why? Because I otherwise think there may be issues of rounding errors, eg, I transmute this way and due to the math, get a bonus that isn't taken away when the reverse conversion is done. Which means you do that 1000 times or something and get a really nice item. _______________________________________________ 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 May 3 12:52:37 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:07 2005 Subject: [CF-Devel] More Lore References: <3EB3304C.5020007@sonic.net> Message-ID: <15428.1051984357@www16.gmx.net> So, I've added the basic support for lore to the CFJavaEditor. In the map properties window (select menu "Map->Map Properties"), there now is a lore tab with a textarea for map lore. Everything which is written there gets placed into the map header enclosed by "maplore"/"endmaplore" tags. I was a bit uncertain what to do with lore from the arches. For now, arch-lore gets parsed but not displayed, which practically disables lore in map-objects. Well, I think Mark is right on that one: If lore was allowed in map-objects people are most likely going to loose the overview. Anyways, I can easily change the way the editor handles arch-lore, according to what the majority prefers. Small sidenote: The "replace" command is also new, which can be found in the edit menu. This allows to replace (or delete) all objects matching a certain name or archtype. This makes it easier to accomplish tasks like "replace all woodfloor with flagstones" or "delete all no_spell arches". AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ 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 May 4 09:45:18 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:07 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EB334FC.3050304@sonic.net> Message-ID: On 03-May-03 Mark Wedel wrote: > I'd have some percent chance (1% maybe) wow.. 1 percent.. you are *way* nicer than I am. --- 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 May 5 18: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:07 2005 Subject: [CF-Devel] misc bug fixes and weather visualization Message-ID: <20030505232513.70657.qmail@web21308.mail.yahoo.com> That attched file contains several patches and a README. The README explains the patches in detail, here is a quick summary. Inv checker bug fixes. Scroll bug fix. Weather bug fixes and tweaks. Weather visualisation system. Learning and high level tweaks. As mentioned in the README, I am working on a stand alone weather server, this has begun, and should get some testing on the cluster this wekend. The documentation said to mail patches to this address, but I'm not subscribed to the list, apologies. http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. -------------- next part -------------- A non-text attachment was scrubbed... Name: patches.tar Type: application/x-tar Size: 61440 bytes Desc: patches.tar Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030506/9a963b50/patches.tar From crossfire-devel-admin at archives.real-time.com Tue May 6 19:02:34 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:07 2005 Subject: [CF-Devel] DM Mode & non-peaceful quirk Message-ID: I noticed on Metalforge today that a player turned off peaceful so they could attack another player. As the DM, I went to summon this person into jail, but as they tried to step off the teleporter they would always walk into (attack) the DM and die. I'm not sure how to prevent or avoid this, was it an error on my side or is this a server/coding issue? - 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 May 7 14:39:52 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:07 2005 Subject: [CF-Devel] duplicate constants? References: <20030507170001.24249.34651.Mailman@pirate.real-time.com> Message-ID: Question about the stats command -- I am coding a new client in java, and I looked at newclient.h in the 1.50 code for the server, and have some confusion : For example: #define CS_STAT_RESIST_START 100 #define CS_STAT_RES_PHYS 100 #define CS_STAT_RESIST_END 117 #define CS_STAT_RES_BLIND 117 #define CS_STAT_SKILLEXP_END 129 #define CS_STAT_SKILLEXP_WILEVEL 129 Is this a mistake that these are the same numbers? Thanks, Scott _______________________________________________ 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 May 7 14:48:29 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:07 2005 Subject: [CF-Devel] duplicate constants? In-Reply-To: References: <20030507170001.24249.34651.Mailman@pirate.real-time.com> Message-ID: <20030507194829.GB2461@crystal> On Wed, May 07, 2003 at 03:39:52PM -0400, sszretter@hotmail.com wrote: > Question about the stats command -- I am coding a new client in java, and I > looked at newclient.h in the 1.50 code for the server, and have some > confusion : > > For example: > > #define CS_STAT_RESIST_START 100 > #define CS_STAT_RES_PHYS 100 > > #define CS_STAT_RESIST_END 117 > #define CS_STAT_RES_BLIND 117 > > #define CS_STAT_SKILLEXP_END 129 > #define CS_STAT_SKILLEXP_WILEVEL 129 > > Is this a mistake that these are the same numbers? Mark can correct me if I'm wrong, but this just looks like the *_START and *_END constants are merely for delimiting constants into blocks. So resistances are between 100 and 117 as a block, and within this block, the first is resist physical (RES_PHYS) and the last is resist blind (RES_BLIND). No mistake here AFAICT. T -- Life goes on... _______________________________________________ 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 May 7 19:41:46 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:08 2005 Subject: [CF-Devel] misc bug fixes and weather visualization In-Reply-To: <20030505232513.70657.qmail@web21308.mail.yahoo.com> Message-ID: On 05-May-03 David Seikel wrote: > As mentioned in the README, I am working on a stand alone weather server, > this has begun, and should get some testing on the cluster this wekend. Your patch said that the tool to make the graphics was not in the distribution. It should be in the utils directory. I think maps.c. Yours does sound like it has a few more features though.. mine was a quick hack. --- 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 May 7 22:46:08 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:08 2005 Subject: [CF-Devel] misc bug fixes and weather visualization In-Reply-To: Message-ID: <20030508034608.35079.qmail@web21306.mail.yahoo.com> I should pay more attention when replying, doh! --- Tim Rightnour wrote: > Your patch said that the tool to make the graphics was not in the > distribution. It should be in the utils directory. I think maps.c. The utils directory is the first place I looked, and I couldn't find anything to make graphics from weather data. The file probably got left out of the distribution by mistake, I didn't check CVS. > Yours does sound like it has a few more features though.. mine was a quick > hack. I didn't waste my time then B-). I hope you enjoy it. BTW, in my email I said I wasn't on this list, I now am. There is a strange bug in the browser I used that stopped me from joining earlier. The bug is still there, I just finally got around to using a different browser. The stand alone weather server is coming along well, although I seem to have stumbled on another Crossfire server bug. I'll know more after the weekend, which should be it's first test on the cluster. 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 May 8 00:42:11 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:08 2005 Subject: [CF-Devel] duplicate constants? In-Reply-To: <20030507194829.GB2461@crystal> References: <20030507170001.24249.34651.Mailman@pirate.real-time.com> <20030507194829.GB2461@crystal> Message-ID: <3EB9EE33.8000801@sonic.net> H. S. Teoh wrote: > On Wed, May 07, 2003 at 03:39:52PM -0400, sszretter@hotmail.com wrote: > >>Question about the stats command -- I am coding a new client in java, and I >>looked at newclient.h in the 1.50 code for the server, and have some >>confusion : >> >>For example: >> >>#define CS_STAT_RESIST_START 100 >>#define CS_STAT_RES_PHYS 100 >> >>#define CS_STAT_RESIST_END 117 >>#define CS_STAT_RES_BLIND 117 >> >>#define CS_STAT_SKILLEXP_END 129 >>#define CS_STAT_SKILLEXP_WILEVEL 129 >> >>Is this a mistake that these are the same numbers? > > > Mark can correct me if I'm wrong, but this just looks like the *_START > and *_END constants are merely for delimiting constants into blocks. So > resistances are between 100 and 117 as a block, and within this block, the > first is resist physical (RES_PHYS) and the last is resist blind > (RES_BLIND). > > No mistake here AFAICT. That summary is correct. Nothing wrong with having different names defined to the same value. _______________________________________________ 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 May 8 10:39:29 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:08 2005 Subject: [CF-Devel] Arch bugs Message-ID: <20030508153928.GA11883@crystal> Hi, the cathedral arch is broken: every tile has no_pass=1. Kinda defeats the purpose of a building, huh? Also, if this is fixed, one should keep in mind that in Navar, this building is next to the south wall, so you'll need at least 3 tiles with no_pass=0 for the building to be accessible. Also, the arch for darkhold might be suffering from the same problem: there is one tile which does not have no_pass set to 1, but it looks like it's inheriting the setting from the first tile, which does have no_pass=1. I've tested this on the darkhold in Santo Dominion; you can't enter the building at all. (This is in the bigworld maps.) The other multi-tile building archs should probably also be checked for accessibility issues. T -- Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry _______________________________________________ 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 May 8 22:57:17 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:08 2005 Subject: [CF-Devel] Re: CVS commit: arch/monster/elemental References: Message-ID: <000601c315df$165a1ac0$0802a8c0@KAMERIA> Oops, missed that. I had only set these in the races file. This is interesting, I assumed that these were ok because they were reset to the proper elemental race by the races file during server load. I see these settings reset in the logs actually. DOes this mean that other arches which have thier races reset by the races file do not work properly either. The other qrches that are changed however are player arches so maybe this is something different (what's up with setting the class arches to human? does this mean that an dwarven priest is set to race human?). One other thing. The earth witch is supposed to throw rocks (and sometimes somehting else), but I could never get that to work even though I copied the ability from the giants. > Module Name: arch > Committed By: avogl > Date: Thu May 8 09:32:52 UTC 2003 > > Modified Files: > arch/monster/elemental: witch_air.arc witch_earth.arc witch_fire.arc > witch_water.arc > > Log Message: > I've set the race of elemental witches to match > those of the other elementals. This is going to > make anti-elemental slayings work against them, as > they are supposed to. > > > > Start of context diffs > > > Index: arch/monster/elemental/witch_air.arc > diff -c arch/monster/elemental/witch_air.arc:1.1 arch/monster/elemental/witch_air.arc:1.2 > *** arch/monster/elemental/witch_air.arc:1.1 Thu Sep 12 23:15:09 2002 > --- arch/monster/elemental/witch_air.arc Thu May 8 02:32:51 2003 > *************** > *** 1,6 **** > Object air_witch > name air witch > ! race elemental > face witch_air.111 > color_fg light_blue > randomitems witch_air > --- 1,6 ---- > Object air_witch > name air witch > ! race air_elemental > face witch_air.111 > color_fg light_blue > randomitems witch_air _______________________________________________ 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 May 8 11: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:08 2005 Subject: [CF-Devel] Re: CVS commit: arch/monster/elemental In-Reply-To: <000601c315df$165a1ac0$0802a8c0@KAMERIA> Message-ID: On 09-May-03 Todd Mitchell wrote: > DOes this mean that other arches which > have thier races reset by the races file do not work properly either. I may be wrong.. but my understanding of the races file is that it's just used for stuff like the priest call servant stuff. --- 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 May 8 11:57:14 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:08 2005 Subject: [CF-Devel] RE: duplicate constants? References: <20030508170002.1896.39047.Mailman@pirate.real-time.com> Message-ID: oooh. ok - that makes sense - thanks for the clarification! > > > > No mistake here AFAICT. > > That summary is correct. Nothing wrong with having different names defined to > the same value. > > > _______________________________________________ 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 May 8 12:12:13 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:08 2005 Subject: [CF-Devel] speed issue - those crazy rats? References: <20030508170002.1896.39047.Mailman@pirate.real-time.com> Message-ID: Im working on a client in java, and I ran into a POSSIBLE issue that seems to happen on the linux c clients also. If you go into an area that has TONS of rats - those stupid rats that multiply like crazy and fill the entire area, things seem to slow down. For example, normally when pressing the arrow keys to move around, everything is nice and fast, but when you get to these rats, your keystrokes are delayed a lot of time. So you end up buffering like 3-8 keystrokes sometimes.... I think it partially depends on your connection to the server - locally its faster of course. SO I looked at the code some more, and it seems the map1 command is sent continuously for animation purposes - like the rats wagging their tails. At least I think that is right. Has anyone thought about this issue? I think it would be nice maybe to incorporate an anim command or something similar so that the client doesnt have to deal with tons of map1 commands coming in, so it can respond to keydowns and send those commands to the server as quick as possible, and get the new map1 commands because of movement as quick as possible... make sense, or hopefully am I missing something? -Scott _______________________________________________ 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 May 8 14:29:50 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:08 2005 Subject: [CF-Devel] Re: CVS commit: arch/monster/elemental References: <000601c315df$165a1ac0$0802a8c0@KAMERIA> Message-ID: <9672.1052422190@www23.gmx.net> > Oops, missed that. I had only set these in the races file. This is > interesting, I assumed that these were ok because they were reset to the > proper elemental race by the races file during server load. Sorry for causing confusion. I didn't really think about the races file. Probably it worked okay before, I just wanted to correct the arch entry. I'm not really competent with the races file, but wouldn't it always be better to set a correct arch entry vs. use the races file to "overrite" things? Guess I don't fully understand the point of the races file. > The earth witch is supposed to throw rocks (and > sometimes somehting else), but I could never get that to work > even though I copied the ability from the giants. I'm not sure. With the new body location code, the earth witch might require a "body_skill 1" attribute. Giants have it. A question related to that: Are the "can_use_xxx" flags still required actually? Some of them seem to have been replaced by "body_xxx" flags, at least logically. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ 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 May 9 05:14:41 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:08 2005 Subject: [CF-Devel] Re: CVS commit: arch/monster/elemental References: <000601c315df$165a1ac0$0802a8c0@KAMERIA> <9672.1052422190@www23.gmx.net> Message-ID: <000401c31613$cef29560$0802a8c0@KAMERIA> > Sorry for causing confusion. I didn't really think about the races file. > Probably it worked okay before, I just wanted to correct the arch entry. > You are too polite I was being lazy. It should have been fixed in the arches, thanks for fixing it. One reason I mentioned it was if it should also be fixed in the other places where races overides the arch setting. I think a lot of stuff shoud be cleaned up in the arches. I'd do it while I am in there too, I just don't know what is being used and what is old cruft. Should the color_fg be cleaned up (do these work with png?, can they be replaced with magicmap?) > > The earth witch is supposed to throw rocks (and > > sometimes somehting else), but I could never get that to work > > even though I copied the ability from the giants. > > I'm not sure. With the new body location code, the earth witch might > require a "body_skill 1" attribute. Giants have it. > Oh, I'll check that, great. I do know that the giants were broken but now fixed, but the witch still dosen't throw rocks so maybe... _______________________________________________ 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 May 9 01:11:50 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:08 2005 Subject: [CF-Devel] Re: CVS commit: arch/monster/elemental In-Reply-To: <9672.1052422190@www23.gmx.net> References: <000601c315df$165a1ac0$0802a8c0@KAMERIA> <9672.1052422190@www23.gmx.net> Message-ID: <3EBB46A6.3040504@sonic.net> Andreas Vogl wrote: > I'm not really competent with the races file, but wouldn't it always be > better to set a correct arch entry vs. use the races file to "overrite" > things? > Guess I don't fully understand the point of the races file. Really, it is a superfluos file. The races file should probably really get removed. I guess some of the codes use it as a summoning list. However, one could just as easily use treasure lists for that. I suppose having the races file wouldn't be that big a deal if it just contained a list of things to use as a race. Thus, you could have a race faerie, race demihuman, etc, and have elf included on multiple lists. However, as things stand now, the objects race is reset according to the race file, which IMO doesn't make a lot of sense. My personal thought is that the archetype should really be what has the definitive data. > > I'm not sure. With the new body location code, the earth witch might > require a "body_skill 1" attribute. Giants have it. > > A question related to that: Are the "can_use_xxx" flags still required > actually? > Some of them seem to have been replaced by "body_xxx" flags, > at least logically. the can_use flags are not really needed anymore. The can be used to have monsters pick stuff up but not apply it, but other than that, they have no use and probably should mostly be removed. _______________________________________________ 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 May 9 01:32:09 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:08 2005 Subject: [CF-Devel] speed issue - those crazy rats? In-Reply-To: References: <20030508170002.1896.39047.Mailman@pirate.real-time.com> Message-ID: <3EBB4B69.9010109@sonic.net> sszretter@hotmail.com wrote: > > SO I looked at the code some more, and it seems the map1 command is sent > continuously for animation purposes - like the rats wagging their tails. At > least I think that is right. > > Has anyone thought about this issue? > I think it would be nice maybe to incorporate an anim command or something > similar so that the client doesnt have to deal with tons of map1 commands > coming in, so it can respond to keydowns and send those commands to the > server as quick as possible, and get the new map1 commands because of > movement as quick as possible... > > make sense, or hopefully am I missing something? The sending of the map1 command is not likely a big issue. The number of bytes sent still isn't really large, and the packing and unpacking of the packet isn't much overhead at all (At least in C). And unless you are on a very slow connectin, the bandwidth shouldn't be much an issue. My guess is that the real hit you are seeing is the cost to redraw the different rat images. I've done timing in the C client, and the processing of the data from the server is trivial - drawing it all to the screen is what takes some measurable CPU cycle. Also, encoding animation information is tricky and may not save a lot of CPU time. Unlike the players inventory, where not much changes the animation rate of the players object, there is a lot more that can change the rate of monsters (paralyze, slow, diseases, etc). Also, keeping things synced up adds extra complication - if for example you are surrounded by rats which may be in different phases of their animation, if you kill a few and a whole bunch move some spaces, you'd still need to send all the information for those that moved to keep them with the right phase. But more to the point, the rat case is a simplest case scenario. If there are performance problems, you need to look at the issue of things like spells, which hit a whole bunch of spaces, may kill a whole bunch of creatures and destroy a whole bunch of objects. That is a case where once again you are needing to do a lot of redraws, and would not get optimized that much by having the client handle those animations, as it is a very temporary effect. _______________________________________________ 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 May 9 10:49:24 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:08 2005 Subject: [CF-Devel] speed issue - those crazy rats? In-Reply-To: <3EBB4B69.9010109@sonic.net> Message-ID: On 09-May-03 Mark Wedel wrote: > My guess is that the real hit you are seeing is the cost to redraw the > different rat images. I've done timing in the C client, and the processing > of > the data from the server is trivial - drawing it all to the screen is what > takes > some measurable CPU cycle. This would be easy for him to test in his client. Accept the command, but do not animate the rat. See if the speed improves. --- 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 May 9 12: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:08 2005 Subject: [CF-Devel] speed issue - those crazy rats? References: <20030509170002.26799.28861.Mailman@pirate.real-time.com> Message-ID: Ok, I will try that this weekend and see what happens. > This would be easy for him to test in his client. Accept the command, but do > not animate the rat. See if the speed improves. > _______________________________________________ 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 May 10 07:38:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:08 2005 Subject: [CF-Devel] Random map shops bug Message-ID: <20030510123848.GA32703@crystal> I noticed recently on metalforge that shops in random maps sometimes spills out unpaid items outside the shop. Not sure why this is happening; likely because monsters are placed inside the shop already? T -- Hello? No, I'm not home. Would you like to leave me a message? _______________________________________________ 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 May 11 14:33:47 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:08 2005 Subject: [CF-Devel] code question In-Reply-To: <3EBB4B69.9010109@sonic.net> Message-ID: in socket/info.c are these 2 functions. What is their usage? I don't understand them in the context of the other functions of info.c. Michael void flush_output_element(object *pl, Output_Buf *outputs) { char tbuf[MAX_BUF]; if (outputs->buf==NULL) return; sprintf(tbuf,"%d times %s", outputs->count, outputs->buf); print_message(NDI_BLACK, pl, tbuf); free_string(outputs->buf); outputs->buf=NULL; outputs->first_update=0; } /* Following checks the various buffers in the player structure and * other things, and stores/prints/whatever's the data, as appropriate. */ void check_output_buffers(object *pl, char *buf) { int i, oldest=0; if (pl->contr->outputs_count<2) { print_message(NDI_BLACK, pl, buf); return; } else { for (i=0; icontr->outputs[i].buf && !strcmp(buf, pl->contr->outputs[i].buf)) break; else if (pl->contr->outputs[i].first_update < pl->contr->outputs[oldest].first_update) oldest=i; } if (icontr->outputs[i].count++; if (pl->contr->outputs[i].count>=pl->contr->outputs_count) { flush_output_element(pl, &pl->contr->outputs[i]); } } else { flush_output_element(pl, &pl->contr->outputs[oldest]); pl->contr->outputs[oldest].first_update = pticks; pl->contr->outputs[oldest].count = 1; if (pl->contr->outputs[oldest].buf!=NULL) free_string(pl->contr->outputs[oldest].buf); pl->contr->outputs[oldest].buf = add_string(buf); } } } _______________________________________________ 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 May 12 06:05:29 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:08 2005 Subject: [CF-Devel] lanterns unlock/fuel Message-ID: <3EBF7FF9.75155C8D@gmx.at> Hi! Whenever I turn a (bright) lantern on or off it unlocks and is prone to be lost when I sell a bunch of stuff. I guess that's not a feature but a bug as I can (un)apply a lot of items (rings, amulets, ...) without them becoming unlocked. Bernhard -- Low end Serverhousing ab 25 e inkl. 1x 11 e/GB, etc.: http://bksys.at _______________________________________________ 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 May 12 06:14:44 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:09 2005 Subject: [CF-Devel] lanterns unlock/fuel Message-ID: <3EBF8224.3C2F2B83@gmx.at> Hi! Whenever I turn a (bright) lantern on or off it unlocks and is prone to be lost when I sell a bunch of stuff. I guess that's not a feature but a bug as I can (un)apply a lot of items (rings, amulets, ...) without them becoming unlocked. So I kept my (bright) lantern lit so it would not unlock and for a long time I thought it would burn forever. But my father who is playing more had his lantern burnt out so the problem is not solved (worked around) this way. Or is there somewhere cheap fuel available? A fuel lantern should be refillable, shouldn't it? We could buy a bottle of fuel, mark a lantern and apply the fuel or such. Bernhard -- Low end Serverhousing ab 25 e inkl. 1x 11 e/GB, etc.: http://bksys.at _______________________________________________ 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 May 12 12:09:13 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:09 2005 Subject: [CF-Devel] lanterns unlock/fuel In-Reply-To: <3EBF8224.3C2F2B83@gmx.at> Message-ID: On 12-May-03 Bernhard Kuemel wrote: > So I kept my (bright) lantern lit so it would not unlock and for a > long time I thought it would burn forever. But my father who is > playing more had his lantern burnt out so the problem is not solved > (worked around) this way. Or is there somewhere cheap fuel available? > A fuel lantern should be refillable, shouldn't it? We could buy a > bottle of fuel, mark a lantern and apply the fuel or such. No, there is no lantern fuel. There could be.. but I didn't program it. Given the rediculous amount of money in the game, buying another lantern isn't that bad. The point of them is more that they last a really long time, and can be extinguished for stealth purposes. The regular lamp lasts alot longer than the bright one, FWIW. --- 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 May 13 04:03:00 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:09 2005 Subject: [CF-Devel] lanterns unlock/fuel References: Message-ID: <000a01c3192e$75d21c80$0802a8c0@KAMERIA> You are assuming that the lanterns use oil or some such flammable substance, but actually they work just like the streetlights in the cities, and are powered by magic. If they used a flammable oil they might be used a weapons or something equally dangerous. You wouldn't want people throwing around flasks of flaming oil or tossing their lanterns into a room now would you? Thankfully, the modern day lantern (or streetlight) is powered by a tiny enchanted glowcrystal. The problem of course is that eventualy the glowcrystal becomes used up and must be replaced and of course, a lantern crystal runs out faster than a street light crystal since they are much smaller. Since most of the cost of a lantern is the price of the glowcrystal, it is more cost effective for the merchant to simply supply new lanterns than provide a service to replace the crystal. By the way, if you think lanterns are expensive, you should see the bill charged by the various magicians guilds for supplying the larger streetlight grade glowcrystals to the city of Navar... It is rumoured that there was a magician from Port Joseph who constructed a rechargable glowcystal. This is uncomfirmed however and the man has since mysteriously vanished. The Port Joseph Wizards local 233, the first and only group to have had a demonstration of his invention and reputedly the last people to have seen him, is quoted as saying, 'it was a fraud, a fake, it never happened and furthermore no one saw anything unusual later that evening.' ----- Original Message ----- From: "Tim Rightnour" To: Sent: Monday, May 12, 2003 1:09 PM Subject: RE: [CF-Devel] lanterns unlock/fuel > > On 12-May-03 Bernhard Kuemel wrote: > > So I kept my (bright) lantern lit so it would not unlock and for a > > long time I thought it would burn forever. But my father who is > > playing more had his lantern burnt out so the problem is not solved > > (worked around) this way. Or is there somewhere cheap fuel available? > > A fuel lantern should be refillable, shouldn't it? We could buy a > > bottle of fuel, mark a lantern and apply the fuel or such. > > No, there is no lantern fuel. There could be.. but I didn't program it. Given > the rediculous amount of money in the game, buying another lantern isn't that > bad. The point of them is more that they last a really long time, and can be > extinguished for stealth purposes. > > The regular lamp lasts alot longer than the bright one, FWIW. > > --- > 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 > _______________________________________________ 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 May 12 17:16:17 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:09 2005 Subject: [CF-Devel] lanterns unlock/fuel In-Reply-To: <3EBF8224.3C2F2B83@gmx.at> Message-ID: On 12-May-03 Bernhard Kuemel wrote: > Whenever I turn a (bright) lantern on or off it unlocks and is prone > to be lost when I sell a bunch of stuff. I guess that's not a feature > but a bug as I can (un)apply a lot of items (rings, amulets, ...) > without them becoming unlocked. The problem is, in order to facilitate shutting the lamp off, I used the ability of items to have an alternate arch stored within. When you activate it, it flips between the lit and unlit arches. This unfortunately clears the lock bit. It might be possible to save the bit and copy it over, similar to how it saves the fuel level and copies it over. --- 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 May 13 02: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:09 2005 Subject: [CF-Devel] code question In-Reply-To: References: Message-ID: <3EC09C59.8090106@sonic.net> Michael Toennies wrote: > in socket/info.c are these 2 functions. > > What is their usage? I don't understand them in the context > of the other functions of info.c. > Those functions take care of the things like '5 times you hit orc' instead of seeing 'you hit orc' on 5 lines. This code was probably be useful back in the days when the x11 display code was in the server. In current time, the client could take care of reducing the output messages/combining them together and what not. on the counter side, by the server doing this, it does save some bandwidth. _______________________________________________ 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 May 13 02:49:22 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:09 2005 Subject: [CF-Devel] code question In-Reply-To: <3EC09C59.8090106@sonic.net> Message-ID: On 13-May-03 Mark Wedel wrote: > Those functions take care of the things like '5 times you hit orc' instead > of > seeing 'you hit orc' on 5 lines. I don't think I've ever seen that happen.. is it at the protocol level only? --- 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 May 13 02:54:03 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:09 2005 Subject: [CF-Devel] code question In-Reply-To: ; from root@garbled.net on Tue, May 13, 2003 at 12:49:22AM -0700 References: <3EC09C59.8090106@sonic.net> Message-ID: <20030513095403.A26810@ds217-115-141-141.dedicated.hosteurope.de> On Tue, May 13, 2003 at 12:49:22AM -0700, Tim Rightnour wrote: > > On 13-May-03 Mark Wedel wrote: > > Those functions take care of the things like '5 times you hit orc' instead > > of > > seeing 'you hit orc' on 5 lines. > > I don't think I've ever seen that happen.. is it at the protocol level only? > No, you have to activate the feature by giving the command 'output-count 10 in the client (the bigger the number, the more messages will be accumulated). 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 Tue May 13 06:18:38 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:09 2005 Subject: AW: [CF-Devel] code question In-Reply-To: <3EC09C59.8090106@sonic.net> Message-ID: I missed that it was triggered by client command, so i never saw it doing anything. The idea isn't that bad - but i see only real usage for hit messages. For other messages we should not generate any floads or/and this should not packed to "x times" - or? The message packing should only work for messages generated in the same round? So, its useful for older times where we have this massive hit messages per round. Any other usage i missed? > > Michael Toennies wrote: > > in socket/info.c are these 2 functions. > > > > What is their usage? I don't understand them in the context > > of the other functions of info.c. > > > > Those functions take care of the things like '5 times you hit > orc' instead of > seeing 'you hit orc' on 5 lines. > > This code was probably be useful back in the days when the x11 > display code was > in the server. In current time, the client could take care of > reducing the > output messages/combining them together and what not. on the > counter side, by > the server doing this, it does save some bandwidth. > > > > > _______________________________________________ > 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 May 13 09:59:31 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:09 2005 Subject: AW: [CF-Devel] code question Message-ID: <20030513145931.26304.qmail@emc.com> >The message packing should only work for messages generated >in the same round? So, its useful for older times where we >have this massive hit messages per round. > >Any other usage i missed? What about "that item is too heavy" messages? I've seen hundreds of them triggered when stepping on a huge pile. And what about success or failure in disarming traps? --PC _______________________________________________ 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 May 13 13:25:51 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:09 2005 Subject: AW: [CF-Devel] code question In-Reply-To: <20030513145931.26304.qmail@emc.com> References: <20030513145931.26304.qmail@emc.com> Message-ID: <3EC138AF.7050207@sonic.net> Preston Crow wrote: >>The message packing should only work for messages generated >>in the same round? So, its useful for older times where we >>have this massive hit messages per round. >> >>Any other usage i missed? > > > What about "that item is too heavy" messages? I've seen hundreds of them > triggered when stepping on a huge pile. > > And what about success or failure in disarming traps? In quick summary, this is how it works: If NDI_UNIQUE is passed as one of the flags to the new_draw_info command, then that message is sent directly to the client, and does not get hit by the grouping logic. There are two commands which control the logic otherwise - output-sync and output-count. output-count is after how many messages of the same type get accumulated do we send it to the client. So if it is set to 10, after there have been 10 'you hit orc messages', it will send them down the line (more useful for things like pray, where you eventually want to see them). the output-sync determines the aging of messages. If it is set to 10, then once a message (or grouping of messages) has gotten 10 ticks old, it is sent down the line. For the message grouping to be most useful, you need to group beyond just the present tick, and that is what this does. However, if you stop doing something (like searching), you eventually want to see that '5 times you searched' messages pop up. The only real 'flaw' in the current system is so much of the new_draw_info stuff passes the NDI_UNIQUE flag when it really shouldn't. There are places where this is really desired (shop listings, spell listings, and many other non-recurring areas). But many actions, like using skills, attacks, etc, should not pass this, and I think some still do. _______________________________________________ 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 May 14 14:26:42 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:09 2005 Subject: [CF-Devel] cfclient 1.5.0 segmentation fault by window resizing Message-ID: <20030514192642.19964.qmail@web40412.mail.yahoo.com> Here are some details: bash-2.05b$ gdb ./cfclient GNU gdb 5.3 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-slackware-linux"... (gdb) r Starting program: /home/claudio/games/crossfire/cfclient Warning: could not convert keysym F27 into keycode, ignoring Warning: could not convert keysym F28 into keycode, ignoring Warning: could not convert keysym F29 into keycode, ignoring Warning: could not convert keysym F30 into keycode, ignoring Warning: could not convert keysym F31 into keycode, ignoring Warning: could not convert keysym F32 into keycode, ignoring Warning: could not convert keysym F33 into keycode, ignoring Warning: could not convert keysym F34 into keycode, ignoring Warning: could not convert keysym F35 into keycode, ignoring Unable to open /home/claudio/.crossfire/sounds - will use built in defaults Program received signal SIGSEGV, Segmentation fault. 0x401c6a8f in _int_free () from /lib/libc.so.6 (gdb) where #0 0x401c6a8f in _int_free () from /lib/libc.so.6 #1 0x401c585c in free () from /lib/libc.so.6 #2 0x0804fe81 in resize_list_info (l=0x88, w=125, h=1076355636) at x11.c:1802 #3 0x08051459 in check_x_events () at x11.c:2551 #4 0x08051341 in get_metaserver () at x11.c:2482 #5 0x08053505 in main (argc=1, argv=0xbffff9b4) at x11.c:3456 #6 0x40165bb4 in __libc_start_main () from /lib/libc.so.6 If you want more information let me know, though it is very easy to reproduce the fault. Regards Claudio ______________________________________________________________________ Yahoo! Mail: 6MB di spazio gratuito, 30MB per i tuoi allegati, l'antivirus, il filtro Anti-spam http://it.yahoo.com/mail_it/foot/?http://it.mail.yahoo.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 May 14 16:46:45 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:09 2005 Subject: [CF-Devel] crossfire x11 v. 1.5.0 client segmentation fault by window resizing Message-ID: <20030514214645.51280.qmail@web40409.mail.yahoo.com> another run, with symbols this time (sorry) (gdb) r Starting program: /home/claudio/games/crossfire-client-1.5.0/x11/cfclient Warning: could not convert keysym F27 into keycode, ignoring //cut// Unable to open /home/claudio/.crossfire/sounds - will use built in defaults Program received signal SIGSEGV, Segmentation fault. 0x0804fbef in draw_all_list (l=0x807e5e0) at x11.c:1739 1739 copy_name(l->names[i], ""); (gdb) where #0 0x0804fbef in draw_all_list (l=0x807e5e0) at x11.c:1739 #1 0x080515c9 in check_x_events () at x11.c:2551 #2 0x080514a9 in get_metaserver () at x11.c:2482 #3 0x080536d9 in main (argc=1, argv=0xbffff984) at x11.c:3456 #4 0x40165bb4 in __libc_start_main () from /lib/libc.so.6 (gdb) Claudio ______________________________________________________________________ Yahoo! Mail: 6MB di spazio gratuito, 30MB per i tuoi allegati, l'antivirus, il filtro Anti-spam http://it.yahoo.com/mail_it/foot/?http://it.mail.yahoo.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 May 15 03:48:43 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:09 2005 Subject: [CF-Devel] protection from paralyzation Message-ID: <3EC3546B.71C98D43@gmx.at> Hi! Is the protection from paralyzation percentage not displayed like the others on purpose? Bernhard -- Low end Serverhousing ab 25 e inkl. 1x 11 e/GB, etc.: http://bksys.at _______________________________________________ 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 May 16 01:36:18 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:09 2005 Subject: [CF-Devel] protection from paralyzation In-Reply-To: <3EC3546B.71C98D43@gmx.at> References: <3EC3546B.71C98D43@gmx.at> Message-ID: <3EC486E2.9090800@sonic.net> Bernhard Kuemel wrote: > Hi! > > Is the protection from paralyzation percentage not displayed like the > others on purpose? > No - most likely an error or something. IT appears that the server does send it to the client, so its just a display 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 Fri May 16 02:22:07 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:09 2005 Subject: [CF-Devel] cfclient 1.5.0 segmentation fault by window resizing In-Reply-To: <20030514192642.19964.qmail@web40412.mail.yahoo.com> References: <20030514192642.19964.qmail@web40412.mail.yahoo.com> Message-ID: <3EC4919F.6020306@sonic.net> Claudio Fontana wrote: > Here are some details: Does it always crash when you resize the window? Is this making the window bigger/smaller (taller/wider?) What about other options like scrollback size and what not? Easier to fix these types of bugs if I can reproduce it locally - also easier to verify that it is really fixed. _______________________________________________ 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 May 16 10:18:46 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:09 2005 Subject: [CF-Devel] cfclient 1.5.0 segmentation fault by window resizing In-Reply-To: <3EC4919F.6020306@sonic.net> References: <20030514192642.19964.qmail@web40412.mail.yahoo.com> <3EC4919F.6020306@sonic.net> Message-ID: <20030516151846.GA7059@crystal> On Fri, May 16, 2003 at 12:22:07AM -0700, Mark Wedel wrote: > Claudio Fontana wrote: > >Here are some details: > > Does it always crash when you resize the window? Is this making the > window bigger/smaller (taller/wider?) What about other options like > scrollback size and what not? > > Easier to fix these types of bugs if I can reproduce it locally - also > easier to verify that it is really fixed. [snip] This is unrelated, but since we're talking about cfclient bugs... I've consistently seen cfclient crash with Invalid GC X protocol errors. As an ugly hack, I've added code to register an Xlib error handler so that cfclient doesn't crash; but the result is that when these invalid GC's start to happen, random images on the map or the inventory start to vanish. It seems that somewhere, cfclient is somehow forgetting that a GC has already been deleted (or perhaps a GC number got corrupted?), and tries to draw a tile with an invalid GC. One observation is that when this happens, it consistently happens to the same png image (often one frame of an animated tile) until the tile is out of sight, whereupon it will start happening to another tile. Also, once it starts to happen, it never goes away, but only gets worse (more tiles start getting corrupt GC values). Any clues on what's causing this? It's getting rather annoying since I have to restart the client every once in a while so that I don't miss objects that have become invisible because their image has a bad GC. This problem happens on both the 1.5.0 release version and CVS. T -- Some days you win; most days you lose. _______________________________________________ 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 May 16 06:10:27 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:10 2005 Subject: [CF-Devel] segfault by window resizing Message-ID: <20030516111027.44711.qmail@web40413.mail.yahoo.com> The situation when the segfault occurs: 800x600 x resolution, 800x600 area cfclient 1.5.0 launched, demaximized and resized reducing the height. Sometimes instead of a segfault I receive a sigfp (but this is probably only the case when I resize to 0 height). gdb output for the sigfp: Program received signal SIGFPE, Arithmetic exception. 0x0804f1c7 in draw_list (l=0x807de80) at x11.c:1713 warning: Source file is more recent than executable. 1713 size = (long) l->bar_length * l->size / items; (gdb) where #0 0x0804f1c7 in draw_list (l=0x807de80) at x11.c:1713 #1 0x08051459 in check_x_events () at x11.c:2551 #2 0x08051341 in get_metaserver () at x11.c:2482 #3 0x08053505 in main (argc=1, argv=0xbffff9c4) at x11.c:3456 #4 0x40165bb4 in __libc_start_main () from /lib/libc.so.6 (gdb) values: l->bar_length == l->size == items == 0 Tell me if you need other information. Bye Claudio ______________________________________________________________________ Yahoo! Mail: 6MB di spazio gratuito, 30MB per i tuoi allegati, l'antivirus, il filtro Anti-spam http://it.yahoo.com/mail_it/foot/?http://it.mail.yahoo.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 Sat May 17 10:54:00 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:10 2005 Subject: [CF-Devel] Perceive self bug Message-ID: <20030517155400.GA18664@crystal> I have a warrior character who has 0 wis experience, but he follows valriel in order to uncurse potions. When I read a perceive spell scroll, though, it says "you worship no god", which is wrong. I even have the +20 confusion from valriel's aura. T -- Sometimes the best solution to morale problems is just to fire all of the unhappy people. -- despair.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 Sun May 18 05:17:48 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:10 2005 Subject: [CF-Devel] cfclient issues Message-ID: <29337.1053253068@www33.gmx.net> On some machines (like SUNs at my university), I'm still bound to use cfclient. I've noticed that cfclient has a few problems: - Darkness doesn't work. The tiles are either fully visible or pitch black. I suspect this might be due to the transparent darkness code not working or something? - Fog of war doesn't work either. Probably related, but I'm not sure how it is supposed to work. As it stands, I can't tell which squares are really visible and which are fog of war. That's quite confusing. The worst thing about it is that the fog of war tiles stay like "frozen" after moving out of sight. That means there are sometimes images of myself/spell animations/bolts etc which stay "frozen" on those tiles. - When large parts of the map view change (like when applying an exit, or casting dimesion door) there are display errors for a short moment. Some tiles go black/white for a split second, then return to normal. That's not terrible, but it didn't happen in older versions. Is cfclient kinda "out of support"? Well, I can understand if it is, but it would be really great if the issues could be improved with some minimal effort: 1. If it was possible to disable fog of war for example, that would do fine for cfclient. Fog of war is nice but really not neccessary, so instead of having a "broken" fog of war, I'd much rather disable it. 2. It would also be great if the old darkness code could be reused for cfclient, where patterns of black and transparent pixels used to "simulate" darkness. That was not perfect maybe, but good enough, and a lot better than the current state (not working). ;-) AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ 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 May 18 20:09:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:10 2005 Subject: [CF-Devel] cfclient issues In-Reply-To: <29337.1053253068@www33.gmx.net> References: <29337.1053253068@www33.gmx.net> Message-ID: <3EC82EE6.4020601@sonic.net> Andreas Vogl wrote: > On some machines (like SUNs at my university), I'm still bound to > use cfclient. > I've noticed that cfclient has a few problems: > > - Darkness doesn't work. The tiles are either fully visible or pitch black. > I suspect this might be due to the transparent darkness code not working > or something? > > - Fog of war doesn't work either. Probably related, but I'm not sure > how it is supposed to work. As it stands, I can't tell which squares are > really visible and which are fog of war. That's quite confusing. > The worst thing about it is that the fog of war tiles stay like "frozen" > after moving out of sight. That means there are sometimes images > of myself/spell animations/bolts etc which stay "frozen" on those tiles. I fixed those up - they both use stippling logic (given the opaque nature of Xpixmaps, we can't easily do clever things like adjust the color in the images themselves). I don't know what that feature was removed, but I'm the one that probably did it :) > > - When large parts of the map view change (like when applying an > exit, or casting dimesion door) there are display errors for a short > moment. Some tiles go black/white for a split second, then return > to normal. That's not terrible, but it didn't happen in older versions. I actually see it on the gtk client at times. I looked into it, but can't remember the details now. I seem to recall the problem was really that the server was sending to map commands, and thus the client re-draws the map two times. I don't remember the details on why the server sent two commands, but I recall there was a decent recent for it. I think in the case of exits, it sends the idea to scroll the map to the client (since the player moved in some direction), but the exit then transports the player to another map, so everything has to get re-drawn at that point. This is indirectly caused by the fact that the client draws the map whenever it gets new map information from the server. A smoother approach would be for the client to draw the map when what is has displayed is out of date with respect to information it has from the server, and when there is no pending data to be read from the socket from the server. This has the advantage that the display is pretty much the must cpu intensive portion of the client - thus, if you were playing on a slow machine, the map update may skip a few frames, but at least not be lagged (I'd rather see current state of things than a complete record of things that may be out of date). > > > Is cfclient kinda "out of support"? Well, I can understand if it is, but > it would be really great if the issues could be improved with some > minimal effort: > 1. If it was possible to disable fog of war for example, that would do fine > for cfclient. Fog of war is nice but really not neccessary, so instead of > having a "broken" fog of war, I'd much rather disable it. > 2. It would also be great if the old darkness code could be reused for > cfclient, where patterns of black and transparent pixels used to > "simulate" darkness. That was not perfect maybe, but good enough, > and a lot better than the current state (not working). ;-) Your wish have been met - I'll check in my changes sometime this evening. I don't remember why I didn't fully implement the display logic in the client - perhaps I forgot or lack of time. But it was ignoring things like darkness and fogofwar on the space. Now it should properly honor the -fogofwar and -nofogofwar as well as -darkness and -nodarkness flags. the support for the x11 client is so-so. The fact that it compiles and runs and use the same basic logic as the gtk client means that it is not that hard to support. However, bug fixes for it are not high on my priority list, and highly unlikely that there will be much in the way of new features added to it. _______________________________________________ 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 May 18 21:37:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:10 2005 Subject: AW: [CF-Devel] cfclient issues In-Reply-To: <3EC82EE6.4020601@sonic.net> Message-ID: > > > > - When large parts of the map view change (like when applying an > > exit, or casting dimesion door) there are display errors for a short > > moment. Some tiles go black/white for a split second, then return > > to normal. That's not terrible, but it didn't happen in older > versions. > This is a latency effect. This happens because the the mapscroll cmd and the map cmd with the map data are 2 different commands. And it can come in more as one mapscroll cmd before a map cmd comes. In the time between some scrolls, if there are big areas to update or simple lag, the scrolled map is drawn without map data - thats then the black/ white areas. After a short blink, they return to normal - thats when the map command comes in. I used for the dxclient & sdlclient the same base source, and there was the effect too. You can remove this easily when you catch the mascroll command. Instead of scrolling the map, set a static counter. Then, when the map command comes in, scroll the map with this counters at the start of the map command. So it is sure that there are no unfilled map parts. BTW, there is a same latency effect with the delinv command and the item command, for example for the look window. Even the delinv is send at the top of the item command, you will notice when you move faster over maps, that sometimes the look window flickers and/or is late updated. Thats too, because the delinv command comes as own package. Lag and other latency effects can invoke visible effects on client side. Also here, i included the delinv inside the item command. _______________________________________________ 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 May 19 22:37:55 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:10 2005 Subject: [CF-Devel] cfclient issues In-Reply-To: <29337.1053253068@www33.gmx.net> Message-ID: <20030520033755.41609.qmail@web21307.mail.yahoo.com> --- Andreas Vogl wrote: > The worst thing about it is that the fog of war tiles stay like > "frozen" after moving out of sight. That means there are sometimes images > of myself/spell animations/bolts etc which stay "frozen" on those > tiles. That happens with the GTK client as well. If my high speed character is running around a lot, he will sometimes leave a ghost image behind until the fog of war goes away. 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 May 21 08:06:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:10 2005 Subject: [CF-Devel] cfclient issues References: <3EC82EE6.4020601@sonic.net> Message-ID: <20196.1053522418@www63.gmx.net> Big thanks to Mark for repairing the darkness and fogofwar code in cfclient. Unfortunately, I have a new problem now: After a short while of play (a few minutes), all kinds of tiles start to get messed up with stipple patterns from the darkness code. I'm using SuSE linux and it happens every time I use cfclient. While continuing to play it gets worse and worse to the point where almost every tile is stippled. The effect is gone only when I disable both darkness and fogofwar, which suggests it may have to do with the stipple drawing. I would make a screenshot if I knew how to do it. :-P Anyone know how to make a screenshot in SuSE linux, KDE desktop? An other topic is the problem of wrongfully drawn objects: > > The worst thing about it is that the fog of war tiles stay like > > "frozen" after moving out of sight. That means there are sometimes > > images of myself/spell animations/bolts etc which stay "frozen" > > on those tiles. What I didn't realize at first is that this actually seems to be a problem with both cfclient and gtkclient, and disabling fogofwar does not make it go away. I'm still not sure what causes the effect, but I suspect it might have to do with changes in the map-drawing routines that came with fogofwar. What seems to happen is that the map updating logic is incorrect to the point that it sometimes allows wrong outdated objects to stay in the view without being redrawn. To describe the effect more clearly: It happens especially often when moving fast and fighting. The wrongfully drawn objects are mostly spell effects, projectiles, parts from multipart monsters and player images. The "wrongfully" drawn objects do not go away even when they are clearly in my line of sight. Sometimes I have to move over them directly to make them go away. The worst part about it is that I sometimes see monsters which don't exist. Multipart monsters often get "messed up" with parts remaining while others dissappear. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ 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 May 21 08:19:15 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:10 2005 Subject: [CF-Devel] cfclient issues In-Reply-To: <20196.1053522418@www63.gmx.net> References: <3EC82EE6.4020601@sonic.net> <20196.1053522418@www63.gmx.net> Message-ID: <20030521151915.6869a07c.philipp.currlin@ira.uka.de> On Wed, 21 May 2003 15:06:58 +0200 (MEST) Andreas Vogl wrote: > > I would make a screenshot if I knew how to do it. :-P > Anyone know how to make a screenshot in SuSE linux, KDE desktop? > Several ways. Easiest would probably be to use ksnapshot or Gimp. Both can take a shot of a single window or after a given time. Other ways are command line but I don't know the commands for that right now. Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030521/b72688fd/attachment.pgp From crossfire-devel-admin at archives.real-time.com Wed May 21 11:46:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:10 2005 Subject: [CF-Devel] cfclient issues In-Reply-To: <20196.1053522418@www63.gmx.net> Message-ID: On 21-May-03 Andreas Vogl wrote: > The worst part about it is that I sometimes see monsters which > don't exist. Multipart monsters often get "messed up" with parts > remaining while others dissappear. Actually, what happened to me once was more sinister. It started duplicating the player I was partied with, and in a moment of mass confusion, we both died. (Neither of us knew where the other was standing, things were attacking, and our coordination went to hell instantly) --- 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 May 21 18:45:08 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:10 2005 Subject: [CF-Devel] new red dragon image Message-ID: <27811.1053560708@www46.gmx.net> Hey, after a few failed attempts I finally managed to create a new red dragon image which doesn't look like a duck. :-) I've uploaded it here: When talking about images - I would very much like to restore the old sign image. Yes, that one with the thin black frame around it. The reason is that the black frame makes it stand out from the background so much better. IMO signs are fairly important and therefore should be well visible. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ 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 May 21 19:29:22 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:10 2005 Subject: [CF-Devel] new red dragon image In-Reply-To: <27811.1053560708@www46.gmx.net> Message-ID: On 21-May-03 Andreas Vogl wrote: > Hey, after a few failed attempts I finally managed to > create a new red dragon image which doesn't look like > a duck. :-) That most decidedly, does not suck. The edges seem a little sharp, but its the best dragon image I've seen yet for crossfire. I'd be curious what it looks like in different colors.. perhaps we can finally have a color set of dragons in crossfire, like nethack and D&D. If so, we should decide on what the various colors mean. NH's format is more intuitive than AD&D, IMHO. Perhaps simple modifications could be made, like wings a little bigger on a black, horns smaller/larger, neck longer, etc... to spice them up. Would it scale down well for a baby? (can you tell I'm excited about having a dragon? excellent work!) --- 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 May 21 21:06:42 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:10 2005 Subject: [CF-Devel] Images. In-Reply-To: <27811.1053560708@www46.gmx.net> Message-ID: <20030522020642.78212.qmail@web21304.mail.yahoo.com> --- Andreas Vogl wrote: > When talking about images - I would very much like to > restore the old sign image. Yes, that one with the thin black > frame around it. The reason is that the black frame makes it > stand out from the background so much better. IMO signs are > fairly important and therefore should be well visible. While on the subject of images, I have constructed a castle made entirely out of ice cubes. I was quite upset when the ice cube image changed to something a little bit smaller. My castle used to look great, now it looks a litle shabby. 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 May 21 21:11:32 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:10 2005 Subject: [CF-Devel] cfclient issues In-Reply-To: <20030521151915.6869a07c.philipp.currlin@ira.uka.de> Message-ID: <20030522021132.83891.qmail@web21310.mail.yahoo.com> --- Philipp Currlin wrote: > On Wed, 21 May 2003 15:06:58 +0200 (MEST) > Andreas Vogl wrote: > > I would make a screenshot if I knew how to do it. :-P > > Anyone know how to make a screenshot in SuSE linux, KDE desktop? > > > Several ways. Easiest would probably be to use ksnapshot or Gimp. Both > can take a shot of a single window or after a given time. There is an even easier way. KDE has a default shortcut of Alt+Print defined for screen shots. As with all KDE shortcuts, you can change that using the control centre. 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 May 21 21:17:00 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:10 2005 Subject: [CF-Devel] Images. In-Reply-To: <20030522020642.78212.qmail@web21304.mail.yahoo.com> Message-ID: On 22-May-03 David Seikel wrote: > While on the subject of images, I have constructed a castle made entirely > out of ice cubes. I was quite upset when the ice cube image changed to > something a little bit smaller. My castle used to look great, now it looks > a litle shabby. It shouldn't be too hard for you to just make a new arch like large_cube, ressurect the old image, and then do a mass replace on your arch name to use the new cube. --- 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 May 21 22:09:48 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:10 2005 Subject: [CF-Devel] Images. In-Reply-To: Message-ID: <20030522030948.11664.qmail@web21305.mail.yahoo.com> --- Tim Rightnour wrote: > It shouldn't be too hard for you to just make a new arch like large_cube, > ressurect the old image, and then do a mass replace on your arch name to > use the new cube. I thought about that, but I want to distribute my maps eventually, and I'm not sure how you should go about distributing new arches with new graphics. Also, it looks like graphics need to be compiled into some sort of file with ALL the graphics in it, something I don't want to do just to get bigger ice cubes. On the other hand, the whole concept works better if they are just standard ice cubes. So I face a trade off, non standard ice cubes that act just like ordinary ones but look different, or an ugly ice castle. For now, I choose to have an ugly ice castle. Later I will be adding a quest that involves some unique magic items that will require new graphics, then it will be worthwhile to sort out how to add images. 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 May 21 23:01:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:11 2005 Subject: [CF-Devel] Images. In-Reply-To: <20030522030948.11664.qmail@web21305.mail.yahoo.com> Message-ID: On 22-May-03 David Seikel wrote: > I thought about that, but I want to distribute my maps eventually, and I'm > not sure how you should go about distributing new arches with new graphics. > Also, it looks like graphics need to be compiled into some sort of file > with ALL the graphics in it, something I don't want to do just to get > bigger ice cubes. Right, you make up the new arch, ressurect the graphics, then post the patches here, and they get committed. Then, when you distribute your maps, they just work. > Later I will be adding a quest that involves some unique magic items that > will require new graphics, then it will be worthwhile to sort out how to > add images. Simple, you send them to us, with an arch file, and say "hey, put these in". --- 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 May 22 09:51:22 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:11 2005 Subject: [CF-Devel] RE: new red dragon image Message-ID: <8575.1053615082@www66.gmx.net> Tim Rightnour wrote: > That most decidedly, does not suck. The edges seem > a little sharp, but its the best dragon I've seen yet > for crossfire. Thanks. I'm happy that you like it so much. :-) > I'd be curious what it looks like in different colors.. > perhaps we can finally have a color set of dragons in > crossfire, like nethack and D&D. [...] Yes, we can convert it to different colors, but I would advise no to over-use the image. The red dragon alone is quite a popular monster which appears in many places. While I understand the fascination of dragon-sets, we should also consider that Crossfire already has a quite unique line of dragons: Fire (= red), cold (=chinese), elec (= blue), wyverns, chaos wyverns, ancient dragons etc. Admittedly, our dragon line might not be perfectly intuitive or complete, but I still like it somehow. I think it would be cool to add arches and images for anchient dragons. Ancient dragons became a well-known part of the CF world, so they really deserve to have an arch IMO. Especially because they fit very well in our system: The normal dragons are often too weak for players in the high-end ranges. So, I've tried to modify the red dragon slightly and create an ancient dragon. It still looks very much alike, but the ancient version has a darker red and more claws. I've updated the page: http://mids.student.utwente.nl/~avogl/crossfire/red_dragon/ > Would it scale down well for a baby? I've tried it. The size is a problem because the 96x64 doesn't fit well into 64x32. Apart from that, the dragon looks quite adultish. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ 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 May 22 10:06:44 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:11 2005 Subject: [CF-Devel] new red dragon image In-Reply-To: from "Tim Rightnour" at May 21, 2003 05:29:22 PM Message-ID: <200305221506.h4MF6ihq021240@mamia.prninfo.com> > > > > Hey, after a few failed attempts I finally managed to > > create a new red dragon image which doesn't look like > > a duck. :-) > That looks terrific, AV! > I'd be curious what it looks like in different colors.. perhaps we can finally > have a color set of dragons in crossfire, like nethack and D&D. If so, we > should decide on what the various colors mean. NH's format is more intuitive > than AD&D, IMHO. Sounds good to me, I would be glad to help, garbled. > > Perhaps simple modifications could be made, like wings a little bigger on a > black, horns smaller/larger, neck longer, etc... to spice them up. Would it > scale down well for a baby? Yeah, that sounds easy enough. > > Keep up the good work, AV. -- Ketche _______________________________________________ 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 May 22 10:25:38 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:11 2005 Subject: [CF-Devel] RE: new red dragon image In-Reply-To: <8575.1053615082@www66.gmx.net> References: <8575.1053615082@www66.gmx.net> Message-ID: <20030522152538.GB9719@crystal> On Thu, May 22, 2003 at 04:51:22PM +0200, Andreas Vogl wrote: > Tim Rightnour wrote: > > > That most decidedly, does not suck. The edges seem > > a little sharp, but its the best dragon I've seen yet > > for crossfire. > > Thanks. I'm happy that you like it so much. :-) I like it too, although I think the wings are a bit too short. Nevertheless, it's much better than the cartoonish red dragon image we currently have. [snip] > Yes, we can convert it to different colors, but I would > advise no to over-use the image. The red dragon alone is > quite a popular monster which appears in many places. I think the different images we have for different dragons are the way to go. The new electric dragon, e.g., looks very nice; so does the chinese dragon. And Todd(?)'s bone drake is a nicely done dragon image as well. I wouldn't want to see the same image with different colors for these dragons. We *could* use it for the worthless dragon (Pupland), though. The current neon-blue version of the cartoonish dragon image just looks hideously ugly. > While I understand the fascination of dragon-sets, > we should also consider that Crossfire already has a > quite unique line of dragons: > Fire (= red), cold (=chinese), elec (= blue), wyverns, > chaos wyverns, ancient dragons etc. > Admittedly, our dragon line might not be perfectly > intuitive or complete, but I still like it somehow. Yeah, I like it too. :-) It *would* be nice if we had at least one dragon type for each attacktype, though. (Excepting maybe weaponmagic and godpower, which are special and shouldn't be abused. Or ghosthit, which makes no sense for a dragon.) For one thing, I'd like to see an acid dragon, and a separation of ice and poison dragons. > I think it would be cool to add arches and images for > anchient dragons. Ancient dragons became a well-known > part of the CF world, so they really deserve to have an > arch IMO. Especially because they fit very well in our > system: The normal dragons are often too weak for > players in the high-end ranges. I second this. We could take existing dragon images and touch them up a little for the ancient dragons. E.g., change the color to be slightly darker, maybe add more prominent claws or horns to make it more fearsome. Having said that, I think the current chaos dragons should be touched up as well... maybe have a multi-colored version of the dragon images. Is there an easy way to re-create full-sized images from the arch tiles? I can do some of these color fixes if I can work with the full image instead of hacking every single tile. > So, I've tried to modify the red dragon slightly > and create an ancient dragon. It still looks very much > alike, but the ancient version has a darker red and > more claws. I've updated the page: > http://mids.student.utwente.nl/~avogl/crossfire/red_dragon/ Hmm... some suggestions: maybe give the ancient dragon longer horns, perhaps longer claws as well? > > Would it scale down well for a baby? > > I've tried it. The size is a problem because the 96x64 > doesn't fit well into 64x32. Apart from that, the dragon > looks quite adultish. [snip] I thought the current baby dragons are 32x32 only? T -- "I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. " -- swr _______________________________________________ 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 May 22 11:31:19 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:11 2005 Subject: [CF-Devel] RE: new red dragon image In-Reply-To: <20030522152538.GB9719@crystal> Message-ID: On 22-May-03 H. S. Teoh wrote: > I think the different images we have for different dragons are the way to > go. The new electric dragon, e.g., looks very nice; so does the chinese > dragon. And Todd(?)'s bone drake is a nicely done dragon image as well. I > wouldn't want to see the same image with different colors for these > dragons. The electric, chinese, and bone drakes are very nice images, even though they strike me as being in the wrong perspective. I suppose I wouldn't be so quick to get rid of them though, as they aren't awful images. However.. if you think a new dragon image is going to plop into our lap so you can make an acid dragon anytime this decade, then I might remind you we've been begging for someone to fix Mr Red for about 2+ years. I'm not suggesting that we go and change the chinese dragon to a white dragon, I'm just suggesting we come up with a panethon of dragons, and make do with what images we have. IMHO one of the most boring elements of crossfire is the extremely limited fauna of creatures. Most places you go, you fight the same old thing. I'd rather see the red dragon occasionally yellow or green, then the red one over and over and over. --- 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 May 22 12:17:22 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:11 2005 Subject: [CF-Devel] RE: new red dragon image In-Reply-To: References: <20030522152538.GB9719@crystal> Message-ID: <20030522171722.GA10291@crystal> On Thu, May 22, 2003 at 09:31:19AM -0700, Tim Rightnour wrote: > > On 22-May-03 H. S. Teoh wrote: > > I think the different images we have for different dragons are the way to > > go. The new electric dragon, e.g., looks very nice; so does the chinese > > dragon. And Todd(?)'s bone drake is a nicely done dragon image as well. I > > wouldn't want to see the same image with different colors for these > > dragons. > > The electric, chinese, and bone drakes are very nice images, even though they > strike me as being in the wrong perspective. That depends on your perspective :-) I use the alternate set images, and they are in a perfectly fine perspective in that context (relative to the other alternate set monsters, that is). > I suppose I wouldn't be so quick to get rid of them though, as they > aren't awful images. They are MUCH better than the old images we have. The old electric dragon frankly looks like a cuddly stuffed toy. > However.. if you think a new dragon image is going to plop into our lap > so you can make an acid dragon anytime this decade, then I might remind > you we've been begging for someone to fix Mr Red for about 2+ years. I think part of the problem is that the procedure for adding new animations is not well documented. For example, I still have no idea how to convert some new images I have to a tile format that CF can use, nor how to associate it with an arch. > I'm not suggesting that we go and change the chinese dragon to a white > dragon, I'm just suggesting we come up with a panethon of dragons, and > make do with what images we have. IMHO one of the most boring elements > of crossfire is the extremely limited fauna of creatures. I beg to differ... I think the problem is with bad map design, rather than lack of different creatures. There's no reason why orcs must always go with kobolds, and why goblins must always go with gnolls and ogres. Having said that, I do concede that some monster families aren't as fleshed out as they can be. Currently, the orc/kobold/etc generators already produce "leaders"; we should turn these "leaders" (which are currently the "regular" arch with a replaced image) into full-blown archs, and possibly add a few more to each family. Each of the kobold/orc/goblin families should have enough variety that you can create an interesting map with only orcs (of various types). The recent skeletal mage/skeleton captain additions are a good example of this. It's not that hard to produce more arches this way either; all you need is to take current images and add them slightly. Eg. skeletal mage is essentially a skeleton carrying a staff, and skeleton captain is essentially a skeleton wearing sword and shield. > Most places you go, you fight the same old thing. I'd rather see the > red dragon occasionally yellow or green, then the red one over and over > and over. [snip] Again, part of the responsibility lies with bad map design. The typical approach to map design goes like this: Hmm, this is my treasure room, where I have Super Duper Artifact +9. Hmm, +9 seems very powerful, I need to make it hard to reach. I know! I'll make a big room and put 25 red dragons in it. And right, having just dragons is boring, so lemme make a long map with increasingly difficult monsters. I'll start with kobolds and orcs, and then giants, and then ... . There are a few fallacies here: (1) the common perception that big monsters are harder, so big rooms with big monsters are popular. Actually, bigger is not necessarily harder, as any mid-level char who got the Shooting Star knows. (2) Large numbers makes it harder -- this is usually not true, since once you can kill 1 or 2 dragons, chances are you can kill 9 or 25 just as easily. The way most big rooms are designed, there's a doorway where the monsters can't pass ('cos they are too big) so you stand in the hallway and take them out one by one. Places like Wizard Tower that dumps you in the middle of 9 wizards with no way to back out is difficult precisely because you have to face all the wizards at once. If they were lined up in a corridor, it'd be a lot easier. (3) Catalog effect: currently, there's a rough sequence of monsters in increasing difficulty. While there's nothing wrong with this, too many maps are like monster catalogues. You always start with kobolds or one of the orc families, and then you get ogres and giants, and then undead, then beholders and dreads, and then dragons, and then titans and wizards. Oh, and throw in a green slime or two, plus a grimreaper, just to make things nasty. About 70-80% of current maps are like this; so it's no wonder you get bored quickly. For (1) and (2), mapmakers (that includes me :-P) need to put a bit more thought into the map, and design a powered-up version of an existing monster. E.g., if the map is all giants, I don't see the point in sticking a titan at the end of the map. Chances are the corridors are only 2x2 wide because of the side of giants, and the titan will almost always end up in a 3x3 room where he can't move, and makes an easy long-range target. It would be much better to have a beefed up hill giant that is unusually fast, e.g., to serve as a "boss monster" at the end of a map. Also, we should discourage maps where you basically wade through roomfuls of monsters. Better have 3-5 well-placed orcs with special attacks or movement types that makes them harder to kill, than to have 30-50 boring, vanilla-flavored orcs filling a big room. For (3), I'd *really* like to see more themed maps. E.g., a swamp map that only has acid monsters, or a dragon map that only has dragons, etc.. I still fail to see why titans and dragons occur together so frequently, or why beholders and skulls *must* occur together (they're not even the same race, dangit.) This is why in an earlier message I mentioned that it'd be nice to have different areas in bigworld, where a certain type of monster is more common. E.g., Darcap area can have a lot of elementals, whereas the mountains near dragoncave would have mainly (or only) dragons; SE of the continent could be infested with demons from Fire Temple, etc.. There should also be a central orc area where you find the most orcs; orcs in any other place should be discouraged (though not excluded; we still need variety sometimes). Then within each of these areas, we should introduce more archs for that monster family, etc.. I'm currently working on a set of swamp maps with trolls and other poisonous/acidic monsters (including at least one new monster). No orcs or goblins allowed, nor demons, and definitely no titans! :-) T -- If you compete with slaves, you become a slave. -- Norbert Wiener _______________________________________________ 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 May 23 06:19:07 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:11 2005 Subject: [CF-Devel] RE: new red dragon image References: <8575.1053615082@www66.gmx.net> <20030522152538.GB9719@crystal> Message-ID: <000e01c3211d$21445380$0802a8c0@KAMERIA> > I think the different images we have for different dragons are the way to > go. The new electric dragon, e.g., looks very nice; so does the chinese > dragon. And Todd(?)'s bone drake is a nicely done dragon image as well. I > wouldn't want to see the same image with different colors for these > dragons. If I knew dragons was where the fame was - I would have worked on them sooner. I didn't do the bone drake, so no glory there, but i could try a dragon soon too. This is a nice animation, I am itching to steal and modify it already for other applications (hmmmm bend out the spine, wrap the tail a bit, add some wing, a few nasty horns...) I would rather do this than just recolour this one >I think part of the problem is that the procedure for adding new >animations is not well documented. For example, I still have no idea how >to convert some new images I have to a tile format that CF can use, nor >how to associate it with an arch. The file format is 32x32 pixel tiles of PNG format (I personally also like 256 bit or 16 bit colour over RGB to keep the files as small as possible, but that's just me) I have heard legends of single image multi tile creatures, but never seen one - so there you go - chop em into bits. The documentation is fairly good compared to most things. It is fairly straightforeward, but a lot of precision work. You can figure it out by looking over a couple arches and reading the objects file in the server developer docs directory (Rick Tanner posted this doc on the CF site I think). Basically you add a section to the arch called anim which contains a list of the files in the animation. You can add a facings value to split the list into directional sublists (e.g. facings 2 is left-right) which comprise equal chunks of the full list. For example fo make a two part animation with two directions you would have: anim facings 2 part.131 part.132 part.171 part.172 mina so you have four animations 131 and 132 are two pics of facing left and 171 172 are two pics facing right mina closes the animation list. The 1 is the first animation frame and the 2 is the second. You can get fancier, a two part creature has two tiles per frame per direction: Object part_1 [.] anim facings 2 part.131 part.132 part.171 part.172 mina end more Object part_2 anim facings 2 part.231 part.232 part.271 part.272 mina [.] getting the arches into the game is simple, make a soft link in your server source code directory /lib folder to the location of your arch directory (or copy the arch directory inthe lib folder , you have to download the arches to do this btw) and run 'make collect' and it will generate a new set of compiled arches for you. Make sure the server is stopped so it can install them and run 'make install' to install the files into your sevver. Restart and enjoy. _______________________________________________ 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 May 23 06:31:23 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:11 2005 Subject: [CF-Devel] RE: new red dragon image References: <8575.1053615082@www66.gmx.net> <20030522152538.GB9719@crystal> <000e01c3211d$21445380$0802a8c0@KAMERIA> Message-ID: <000501c3211e$d8275e20$0802a8c0@KAMERIA> > If I knew dragons was where the fame was - I would have worked on them > sooner. > I didn't do the bone drake, so no glory there, but i could try a dragon soon > too. > This is a nice animation, I am itching to steal and modify it already for > other applications (hmmmm bend out the spine, wrap the tail a bit, add some > wing, a few nasty horns...) I would rather do this than just recolour this > one BTW by other applications I mean use for other arches in crossfire (black dragon, teal dragon, eggshell with a hint of barlycorn crackle dragon...), not other software applications. Just though I would make that clear...I am not trying to scalp your dragon Andi... _______________________________________________ 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 May 22 19:42:41 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:11 2005 Subject: [CF-Devel] RE: new red dragon image In-Reply-To: <20030522171722.GA10291@crystal> Message-ID: On 22-May-03 H. S. Teoh wrote: >> The electric, chinese, and bone drakes are very nice images, even though >> they >> strike me as being in the wrong perspective. > > That depends on your perspective :-) I use the alternate set images, and > they are in a perfectly fine perspective in that context (relative to the > other alternate set monsters, that is). Well, exactly, for the base set, they are dead wrong. >> I suppose I wouldn't be so quick to get rid of them though, as they >> aren't awful images. > > They are MUCH better than the old images we have. The old electric dragon > frankly looks like a cuddly stuffed toy. It's an interesting problem. They are in the wrong perspective, but well drawn, leading to a situation where it is hard to justify nuking them. > I think part of the problem is that the procedure for adding new > animations is not well documented. For example, I still have no idea how > to convert some new images I have to a tile format that CF can use, nor > how to associate it with an arch. Well.. to trivialize it, what I did was just start cutting and pasting 32x32 chunks. It's not easy to do. I think there is another way, though I've never tried it. Supposedly we can use non-cut images. Ask mark. > I beg to differ... I think the problem is with bad map design, rather than > lack of different creatures. There's no reason why orcs must always go > with kobolds, and why goblins must always go with gnolls and ogres. No.. thats not my point. My point is that when I go to the map A, I fight orcs and kobolds and dragons. When I go to map b, I fight orcs and kobolds and dragons. There aren't many monsters to choose from when making maps. And there are even less to choose from when you remember that you have to stick to a particular difficulty rating. So when you are level N, trying to get to N+1, you end up fighting the same damn thing over and over. I'm not saying the maps aren't perhaps poor as well, and your other points are probably correct. I'm saying that there are only a few monsters to choose from. I don't care about fighting 25 red dragons in a room. I'm sick of seeing 25 maps all with red dragons. > The recent skeletal mage/skeleton captain additions are a good example of > this. It's not that hard to produce more arches this way either; all you > need is to take current images and add them slightly. Eg. skeletal mage is > essentially a skeleton carrying a staff, and skeleton captain is > essentially a skeleton wearing sword and shield. Exactly my point.. It spices it up a little at least. --- 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 May 22 23:16:10 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:11 2005 Subject: [CF-Devel] monsters, dragons, and images In-Reply-To: <20030522152538.GB9719@crystal> References: <8575.1053615082@www66.gmx.net> <20030522152538.GB9719@crystal> Message-ID: <3ECDA08A.5040405@sonic.net> So many different points to address. Monster progression: Ideally, there'd be a somewhat nice and smooth set of races from level 1 to 25 or so. The undead example is pretty close. The dragon is pretty close (but I think there is a pretty big gap between killing wyverns/faeri dragons and killing the real dragons). Demons probably have a pretty decent list. Elementals lack things at low levels. Giants have a big jump from hill giant to troll. All it'd really take for most of these is to inject a few monsters. A beige dragon that is between wyvern and big dragon. A few more giant types (if you look at AD&D, there is a big set - hill, stone, cloud, frost, storm, fire). Maybe toss in a groll (giant/troll intermix or whatever). If at least there are several monsters that are a good match for a level 15 person, this reduces the monotony that Tim describes. However, I think there will still always be an optimization. Eg, killing grolls and beige dragons are roughly the same difficulty for this character (given his spells/resistances/whatever), but I get more exp for the groll. Guess which one I'd try to go kill more of. As a note, there are probably about 200 monsters (taking a quick look at the arch directory). However, some large portion of those are special/really high level monsters, and which are probably used rarely (as they should be), so don't help the situation with monsters for mid level maps. Some of this could perhaps be reduced by giving end of quest exp rewards - managing to kill everything and get to the end gives you a 100,000 exp bonus - many commercial games do this. However, I've yet to really see how to put this in with the skill system (best I could think of right now would be it is based on relative portions of exp in each skill. Eg, if my skill exp is: missile weapons: 40 one handed weapons 30 evocation 14 searching 3 You then taking the percentages. Eg, missile weapons is 45% of my exp total, so it the portion of the reward, one handed weapons is 34%, so it gets that reward, and so on). This would also reduce some of the things of killing all the monsters that keep generating - the bonus reward at the end might be good enough you just want to get to the end of the dungeon to get the reward, and care less about killing everything that shows up. I personally don't know if I'd like a dragon for every attacktype out there. Even if you reduce it to just the elemental attacktypes (fire, elec, cold, acid, poison). In fact, we already cover all of those but acid, and I personally don't think acid dragons would be that intereting (given that they damage equipment, either you are mostly immune so it doesn't damage your equipment, or you'd probably avoid those like the plague). If anything, mixing up the form of attack could be interesting (bolt vs cone vs exploding ball vs seeking ball). Imagine a dragon with a cone of lightning... As far as images - Todd described the forma accurate, and I believe it is accurately described in the docs. In terms of split/merged images - doing it by hand is one one. I'd imagine that it'd be pretty easy to write scripts to split/merge them (there are already scripts to merge them, as the spoiler uses it for example). However, the server and gtk client (as well as I think the x11 client) support the idea of not splitting the images - eg, it is a 64x64 block. The DX client does not support this, as I'd imagine the very old java client and some other clients out there. There may very well be some bugs in this, but like all things, that should get fixed. This functionality was added about a year ago. The doc/Developers/images I think describes this adequately. One note is that the image can be bigger than the footprint (which is defined by the arch/more). The client makes the origin of drawn images the lower right - thus they extend up and to the left. What this basically means is that you can have tall images that the overlap (think something like titans - one could stand in front of another and visually overlap the one behind it). However, it is the footprint of the object that determines what spaces it is on (thus, where you need to hit it with spells, in the case of buildings, where you can enter it, and so on). Or a simple case would be the hill giant - it should probably only have a 1x1 footprint, but still be tall. If I recall correctly, this also means that there is not a requirement for images to be multiples of 32x32. Eg, a 8' tall creature could be done as a 32x46 image for example. This works better for height than width - odd width objects will extend into the square to the left. However, you could have something like a lake that extends just a little into the neighboring space, so that the boundary is better, but the fact it is ground still looks OK. It'd probably simplify the code a bit if there were no split images - in that way, the server code doesn't have to try to deal with both cases (multipart object which is multiple images, vs a multipart object which is jsut one 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 Fri May 23 01:14:53 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:11 2005 Subject: [CF-Devel] monsters, dragons, and images In-Reply-To: <3ECDA08A.5040405@sonic.net> Message-ID: On 23-May-03 Mark Wedel wrote: > All it'd really take for most of these is to inject a few monsters. A > beige > dragon that is between wyvern and big dragon. A few more giant types (if you > look at AD&D, there is a big set - hill, stone, cloud, frost, storm, fire). > Maybe toss in a groll (giant/troll intermix or whatever). Well.. let me then make a blind proposal on dragons, and lets see what people think. This is just off the top of my head, and is no way a set in stone list. Lets corraborate on this and tweak it. First, lets start with the colors: Red: fire Blue: Lightning Chinese: Cold Yellow: Acid Green: Poison (perhaps not green, as the chinese is green.. orange?) Bone Drake: Undead Gray: Magic (MM, mana *) Now, I really like what Mark suggested about different attack types. Perhaps there is a better way to utilize it though: Young Dragon: Gets the basic attack, like cone of fire, lightning bolt, cone of cold. Normal Dragon: Gets the basic attack, and a special one, like a firebolt, ball lightning. Ancient Dragon: Gets all forms of attack. Obviously, different types will have different experience levels. In AD&D, whites are the weakest, while blacks (acid) are the most feared. In our case, the acid dragon should be worth much more in EXP than a chinese, as it is far more difficult and dangerous to kill. We should completely reorganize the exp for the dragons along with this. (personally, I think all EXP charts are garbage, and we should revise the whole thing, but thats a different subject) Chinese could be made much weaker, thus giving us the "beige" dragon, between the wyvern and the red. We can make a progression, say, chinese, green, red, blue, gray, yellow. You could possibly make this into 4 levels.. or whatever. Here is a direct example with a red dragon: Young Red: dragonbreath Red: Dragonbreath, firebolt Old Red: fireball Ancient Red: ball fire (like ball lightning) here the ancient gets a unique attack, not found in the normal game, a testament to it's true power. Dragons should also get things like fire claws, or poison claws, if they don't allready, like the dragon character class. As for the image, perhaps until someone has more time, the difference could be an enhancing of the features. Perhaps a young red starts out more pink, and grows to be a dark blood red when ancient. These images could allways be upgraded later. A re-colored wyvern will make a good young dragon. People are willing to forgive imperfections in the images, if it leads to better gameplay. More creaturetypes will provide that, IMHO. I also *adore* the idea of multiple giant types, multiple troll types, etc etc. I really think we should raid the nethack images, and bulk up our fauna. --- 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 May 23 01:37:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:11 2005 Subject: [CF-Devel] monsters, dragons, and images In-Reply-To: References: Message-ID: <3ECDC191.7030908@sonic.net> Tim Rightnour wrote: > Obviously, different types will have different experience levels. In AD&D, > whites are the weakest, while blacks (acid) are the most feared. In our case, > the acid dragon should be worth much more in EXP than a chinese, as it is far > more difficult and dangerous to kill. We should completely reorganize the exp > for the dragons along with this. (personally, I think all EXP charts are > garbage, and we should revise the whole thing, but thats a different subject) exp is very hard. For example, if you play one of the races/classes that has good fire resistances, the wyvern quest (from the hall of quests) is _much_ easier than say being a troll in that same quest. Same will be true with dragons. If you have the right items, that acid dragon may really be a piece of cake. If you don't, you might try to completely avoid it. I guess that is no different than now, but just a point it is difficult to say 'this is hard/easy'. > > Chinese could be made much weaker, thus giving us the "beige" dragon, between > the wyvern and the red. We can make a progression, say, chinese, green, red, > blue, gray, yellow. The simplest thing for difficulty would be to make differing dragon ages, and adjust the difficult from there. If all the ancient dragons are roughly the same difficulty, that isn't a big deal to me. If however there is some age category of dragons that is good for level 15, another age at 20, etc. If you have 4 dragons X 4 age categories, that is 16 combinations. We already have baby dragons, so now we're just looking at young, mature, and ancient - and the existing full grown ones probably fall into the mature catorgy. As for experience, now would be the time to talk about redoing it, as a large portion of code is getting changed for the exp stuff anyways. I'd still be tempted to make the exp you need for the first few levels even more than it is now, OTOH, I'm an experienced player so maybe I'm not the best to comment on this. OTOH, if you just tell a newby 'be careful, but kill everything in the newby tower, they will currently get to be level 3-4 from that alone, and unless you're really gung ho, you can do it pretty easily. Perhaps the problem is more that kobold, orcs, and goblins are worth relative too much exp. _______________________________________________ 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 May 23 04:25:31 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:11 2005 Subject: [CF-Devel] quest exp rewards (RE: monsters, ...) References: <3ECDA08A.5040405@sonic.net> Message-ID: <702.1053681931@www66.gmx.net> Mark W. wrote: > Some of this could perhaps be reduced by giving end of quest exp > rewards - managing to kill everything and get to the end gives you > a 100,000 exp bonus - many commercial games do this. > However, I've yet to really see how to put this in with the > skill system I had a trivial implementation in mind for this. There can be an object type like "experience_donator". When a player steps on it or otherwise activates it, he gets X points of experience in skill Y. The donator object works only once (per map reset), values for X and Y can be set as attributes in the object. The effect of this system is that mapmakers can freely decide what skill exp they award players with for solving their quest: A quest for a lost scroll can reward literacy, a quest for brewing a mystic potion can award alchemy, a quest for killing the enemies of your god can award wisdom. As long as the donators aren't badly misused I believe it will work fine. It allows players to gain experience in any kind of skill, including the exotic and hard-to-train ones like literacy or mountaineering. Note that the exp players get from quests would still be only a portion of their total gain. So if someone really wants to boost his magic skill for example, he still needs to go out and kill things with magic. The only real problem I see is that players might camp around the donator objects waiting for map reset, but that's the common problem for all kinds of treasure in CF. How to avoid this is actually a totally seperate topic. The ideal way IMO would be putting players to the StartX, StartY coordinates after a map reset (StartX, StartY are defined in the map header. If nothing is defined, let the player stay where he is.). If using StartX, StartY is too uncertain, we can define new flags for it in the map header and use those. > (best I could think of right now would be it is > based on relative portions of exp in each skill. [...] I believe that approach would allow low level players to advance more or less whatever skill they want. High level players would be bound to what they have trained before. Neither of that seems ideal to me. Besides, there would be no difference wether you just solved a mounteering quest, a wizard's quest or whatever. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ 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 May 23 07:15:03 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:11 2005 Subject: [CF-Devel] quest exp rewards (RE: monsters, ...) In-Reply-To: <702.1053681931@www66.gmx.net> References: <3ECDA08A.5040405@sonic.net> <702.1053681931@www66.gmx.net> Message-ID: <20030523121503.GA19661@crystal> On Fri, May 23, 2003 at 11:25:31AM +0200, Andreas Vogl wrote: > Mark W. wrote: > > > Some of this could perhaps be reduced by giving end of quest exp > > rewards - managing to kill everything and get to the end gives you > > a 100,000 exp bonus - many commercial games do this. > > However, I've yet to really see how to put this in with the > > skill system > > I had a trivial implementation in mind for this. > There can be an object type like "experience_donator". > When a player steps on it or otherwise activates it, he > gets X points of experience in skill Y. > The donator object works only once (per map reset), > values for X and Y can be set as attributes in the object. Once per map reset is not good. We should make the experience donator object by extending the marker object so that players can only get that exp once. I.e., player steps on object, gets marked, as well as get exp donated. This prevents problems with camping, or quest hogging. Or if that is too harsh, set the marker to expire at a large time interval, say a few (real) days or a week. > The effect of this system is that mapmakers can freely > decide what skill exp they award players with for solving their > quest: A quest for a lost scroll can reward literacy, a quest > for brewing a mystic potion can award alchemy, a quest > for killing the enemies of your god can award wisdom. This has been discussed before, and I fully agree with it. Quests will be so much more rewarding if they give special exp which doesn't just come from killing monsters. Right now, if you use tricks (like hiding, stealth, etc) to get a low-level character past high-level monsters in a high-level quest, you get no exp for it. This is not good, since the creative thinking on the part of the player *should* be rewarded. > As long as the donators aren't badly misused I believe > it will work fine. It allows players to gain experience in any > kind of skill, including the exotic and hard-to-train ones like > literacy or mountaineering. > Note that the exp players get from quests would still > be only a portion of their total gain. So if someone really > wants to boost his magic skill for example, he still needs to > go out and kill things with magic. I agree with this. > The only real problem I see is that players might camp > around the donator objects waiting for map reset, but > that's the common problem for all kinds of treasure in CF. > How to avoid this is actually a totally seperate topic. > The ideal way IMO would be putting players to the StartX, StartY > coordinates after a map reset (StartX, StartY are defined > in the map header. If nothing is defined, let the player > stay where he is.). If using StartX, StartY is too uncertain, > we can define new flags for it in the map header and use those. I think this should be done regardless of whether we add experience donator objects. Currently, if the player saved in the middle of a room which used to be full of monsters (either explicitly or implicitly by the server), if the server crashes or the player loses the network connection for a long time, when the server restarts or the player re-connects, he finds himself stuck in the middle of a room of monsters, through no fault of his. This can be bad, since he probably isn't expecting it, and will likely get killed and lose lots of exp for nothing. > > (best I could think of right now would be it is > > based on relative portions of exp in each skill. [...] I don't like that idea; it means that it's very difficult to train in neglected skill areas since most of the exp goes into the area you're already well-trained in. > I believe that approach would allow low level players to > advance more or less whatever skill they want. > High level players would be bound to what they have trained > before. Neither of that seems ideal to me. > Besides, there would be no difference wether you just solved > a mounteering quest, a wizard's quest or whatever. [snip] I still think the best way is still to let the mapmaker decide which skill area the exp should be added to. T -- And life still goes on... _______________________________________________ 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 May 23 08:20:20 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:12 2005 Subject: AW: [CF-Devel] cfclient issues In-Reply-To: <20196.1053522418@www63.gmx.net> Message-ID: I find some bad bug in player movement, which can course this client affects too. Because we track in the client now more accurate what happens on the map, this bug will come in effect - missing esrv_map_scroll(&op->contr->socket, freearr_x[dir],freearr_y[dir]); functions when the player moves. This is the right way to move a player (from move_ob() ). remove_ob(op); op->x+=freearr_x[dir]; op->y+=freearr_y[dir]; insert_ob_in_map(op,op->map,originator,0); /* Currently, assume that players will only be single space objects */ if (op->type==PLAYER) { esrv_map_scroll(&op->contr->socket, freearr_x[dir],freearr_y[dir]); op->contr->socket.update_look=1; op->contr->socket.look_position=0; } This is, how for example the shop_mat function teleports a player back in the shop when he can't pay all unpaid items: else { /* if we get here, a player tried to leave a shop but was not able * to afford the items he has. We try to move the player so that * they are not on the mat anymore */ int i = find_free_spot (op->arch, op->map, op->x, op->y, 1, 9); if(i == -1) { LOG (llevError, "Internal shop-mat problem.\n"); } else { remove_ob (op); op->x += freearr_x[i]; op->y += freearr_y[i]; rv = insert_ob_in_map (op, op->map, shop_mat,0) == NULL; } } The map scroll cmd is missed. This will bring every feature out of track, which depends on exactly map data & position data. You will notice this effect sometimes, when you get ported/moved, and a "shadow" of your player char animation stays on the position where you was before. This missing scroll cmds are numerous in the code - better to check every insert_ob_in_map() and add it when needed. _______________________________________________ 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 May 23 09:35:31 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:12 2005 Subject: [CF-Devel] new red dragon image In-Reply-To: <27811.1053560708@www46.gmx.net> References: <27811.1053560708@www46.gmx.net> Message-ID: <200305231635.57219.paco@arsfortunata.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El Jueves, 22 de Mayo de 2003 01:45, Andreas Vogl escribi?: > Hey, after a few failed attempts I finally managed to > create a new red dragon image which doesn't look like > a duck. :-) > > I've uploaded it here: > > Nice .. I just created one too sometime ago (and some other images) .. see them at http://www.geocities.com/fmunoz_/crossfire/ (The animation in the final files is improved from the gif animation show, so the extange neck moves are not there) Un saludo Paco -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+zjG8H1JosF5I3XURAsOuAJ9m921WPKpT0HpilnKDY1TSa+3BIgCfRnDF r7qaL1DadWNpBBH4hkVGtIs= =Frah -----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 May 23 10:38:23 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:12 2005 Subject: [CF-Devel] quest exp rewards (RE: monsters, ...) In-Reply-To: <20030523121503.GA19661@crystal> Message-ID: On 23-May-03 H. S. Teoh wrote: > Once per map reset is not good. We should make the experience donator > object by extending the marker object so that players can only get that > exp once. I.e., player steps on object, gets marked, as well as get exp > donated. This prevents problems with camping, or quest hogging. Or if that > is too harsh, set the marker to expire at a large time interval, say a few > (real) days or a week. If I were to implement this, I would probably make an in-memory list of the last 50-100 players to recieve the exp, per object. New players would be added to the bottom and the top player popped off. If the game reboots, everyone can try again. Only problem is.. it might encourage intentional crashing. --- 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 May 23 08:34:28 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:12 2005 Subject: [CF-Devel] quest exp rewards (RE: monsters, ...) In-Reply-To: <702.1053681931@www66.gmx.net> References: <3ECDA08A.5040405@sonic.net> <702.1053681931@www66.gmx.net> Message-ID: <86ptm9g523.fsf@cail.esc.pike.il.us> Andreas Vogl writes: > I had a trivial implementation in mind for this. > There can be an object type like "experience_donator". > When a player steps on it or otherwise activates it, he > gets X points of experience in skill Y. > The donator object works only once (per map reset), > values for X and Y can be set as attributes in the object. Would it be possible to make the donator an item like a scroll that can be collected and used later? That way a player wouldn't fight all the way to the bottom of a dungeon only to find that the big prize is useless to him because it's XP in a skill that he doesn't know. If the big treasure were a Scroll of Huge Missle-Weapon XP, for example, and the player didn't have that skill yet, he could take the scroll and save it to use after he learns the skill. If the player doesn't care about that skill, he could trade the scroll to someone who does, or sell it. (As a twist, maybe the scroll could have a very low sale value, to encourage players to trade or use them rather than just seeing them as valuable treasure.) -- Aaron abaugher@esc.pike.il.us _______________________________________________ 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 May 23 10:41:39 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:12 2005 Subject: [CF-Devel] new red dragon image In-Reply-To: <200305231635.57219.paco@arsfortunata.com> Message-ID: On 23-May-03 Francisco Muñoz wrote: > Nice .. I just created one too sometime ago (and some other images) .. see > them at > http://www.geocities.com/fmunoz_/crossfire/ > (The animation in the final files is improved from the gif animation show, > so > the extange neck moves are not there) I like the dragon, perhaps my only beef with it is that the black border is too thick. can you thin it out? The nuggets and mice are good too.. Perhaps a little re-coloration to the dragon and we will have another image to use for the different breeds. --- 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 May 23 14:54:29 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:12 2005 Subject: [CF-Devel] quest exp rewards (RE: monsters, ...) In-Reply-To: References: <20030523121503.GA19661@crystal> Message-ID: <20030523195429.GA24131@crystal> On Fri, May 23, 2003 at 08:38:23AM -0700, Tim Rightnour wrote: > > On 23-May-03 H. S. Teoh wrote: > > Once per map reset is not good. We should make the experience donator > > object by extending the marker object so that players can only get that > > exp once. I.e., player steps on object, gets marked, as well as get exp > > donated. This prevents problems with camping, or quest hogging. Or if that > > is too harsh, set the marker to expire at a large time interval, say a few > > (real) days or a week. > > If I were to implement this, I would probably make an in-memory list of the > last 50-100 players to recieve the exp, per object. New players would be added > to the bottom and the top player popped off. If the game reboots, everyone can > try again. > > Only problem is.. it might encourage intentional crashing. [snip] Yeah, I wouldn't want to do that. Intentional crashing is already being done for item duplication and stuff. We don't want to introduce more reasons for doing it. T -- Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't. _______________________________________________ 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 May 24 03:57:28 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:12 2005 Subject: [CF-Devel] quest exp rewards (RE: monsters, ...) References: <20030523121503.GA19661@crystal> <20030523195429.GA24131@crystal> Message-ID: <000601c321d2$81c7a760$0802a8c0@KAMERIA> Two problems with having a xp creator arch seem to be: a. if you hand out xp specifically for a skill and the player doesn't have the skill b. how to stop loitering around the creator I hope that there are appropriate changes to the CFPython plugin when the skill - xp system is changed so that this sort of thing can still be done with scripting. It is a lot more appropriate to do this with scripting i think since it is more customized. You can do stuff like decide if you want to put a time limit or maintain a list of players, change the xp amount or type handed out on the fly or store info in the player file with scripting. You could even prompt the player which skill they want to add the xp to or remove xp or let them choose xp vs an item vs a mountain of turnips... I think that at a certain point it is the scripting that will make the maps really interesting and allow for some of the more advanced stuff, not more complex arch objects. The arches should be as atomic as possible to facilitate this I 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 Fri May 23 16:53:52 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:12 2005 Subject: [CF-Devel] quest exp rewards (RE: monsters, ...) References: <000601c321d2$81c7a760$0802a8c0@KAMERIA> Message-ID: <18458.1053726832@www42.gmx.net> Aaron Baugher wrote: > Would it be possible to make the donator an item like a > scroll that can be collected and used later? Sorry, I'm afraid that is not an option. In crossfire there are ways to abuse server crashes for item dublicaton. Just imagine players piling up these donators in their apartments... They really have to be non-pickable. > That way a player wouldn't fight all the way to the bottom > of a dungeon only to find that the big prize is useless to > him because it's XP in a skill that he doesn't know. Your argument is true, but I think there are several ways to solve the problem. Players who get an exp reward without knowing the skill could get a very small chance (like 1%) to learn the skill instead. If that doesn't seem fit, they could get a certain amount of money dumped in their inventory, as "consolation prize". Apart from that I think current quests are not any better in regard to fairness actually: "Here is your fire sword for solving the quest. What, you don't need a fire sword? Who cares...". Okay, at least you can sell a fire sword for a few bucks, but then a consolation prize in the above case would do just as well. Todd Mitchell wrote: > Two problems with having a xp creator arch seem to be: > > a. if you hand out xp specifically for a skill and the > player doesn't have the skill > b. how to stop loitering around the creator I have presented possible solutions for both of these. However, I want to point out that named problems already apply to most treasures and quests in some way, and have existed for many years. Of course the problems should be fixed, but I don't see them as utlimate obstacles, or as reasons *not* to allow skill exp rewards. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ 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 May 23 18:49:18 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:12 2005 Subject: [CF-Devel] RE: new red dragon image References: Message-ID: <7938.1053733758@www42.gmx.net> Tim Rightnour wrote: > > > > The electric, chinese, and bone drakes are very nice images, > > > even though they strike me as being in the wrong perspective. > > > > [...] I use the alternate set images, and they are in a > > perfectly fine perspective in that context [...] > > Well, exactly, for the base set, they are dead wrong. Now I'm confused. Which dragons in which image set are wrong in which context? :-) I believe the base chinese and base elec dragon are in correct perspective for the base set. Maybe not perfectly correct but roughly. The bone drake however is flat which makes it fine for alternate set and definitly wrong for base set. > Well.. let me then make a blind proposal on dragons, and lets > see what people think. This is just off the top of my head, and > is no way a set in stone list. > Lets corraborate on this and tweak it. > > First, lets start with the colors: > [...] I fully agree with Mark's description on how to fill up gaps in the CF monster families. The idea of generally overhauling dragons goes a little bit too far IMO. By fundamentally changing the abilities of all dragons, their difficulty and behaviour will change. This again will cause an immense number of maps to change in a quite unpredictable kind of way. The idea of adding a possibly large bunch of new monsters with copied, resized or otherwise mediocre graphics also makes me feel, frankly, a bit uncomfortable. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ 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 May 23 22:37:54 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:12 2005 Subject: [CF-Devel] quest exp rewards (RE: monsters, ...) Message-ID: <20030524033754.BKEV24631.tomts15-srv.bellnexxia.net@[209.226.175.18]> > Todd Mitchell wrote: > > > Two problems with having a xp creator arch seem to be: > > > > a. if you hand out xp specifically for a skill and the > > player doesn't have the skill > > b. how to stop loitering around the creator > > I have presented possible solutions for both of these. > However, I want to point out that named problems already apply > to most treasures and quests in some way, and have existed for > many years. > Of course the problems should be fixed, but I don't see them > as utlimate obstacles, or as reasons *not* to allow skill > exp rewards. Absolutly - it applies even more for money. I was extolling the plugin, not panning xp rewards however. Xp rewards is a good idea, but it dosen't really require any new developent, if you use the python plugin I am pretty sure you can do it now (and probably better than with an xp creator arch). One of the reasons that there is so much treasure abuse is the fact that it is easly to drop big items onto the map and not so easy to create safeguards for them. This will also occur with an xp generator - good maps will make good use of it and bad maps will make abuse of it. This won't go away using scripting, but it might be easier to be more flexable. Perhaps a little library of python script 'arches' along these lines is in order... _______________________________________________ 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 May 23 23:43:20 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:12 2005 Subject: [CF-Devel] quest exp rewards (RE: monsters, ...) In-Reply-To: <20030524033754.BKEV24631.tomts15-srv.bellnexxia.net@[209.226.175.18]> References: <20030524033754.BKEV24631.tomts15-srv.bellnexxia.net@[209.226.175.18]> Message-ID: <3ECEF868.1080700@sonic.net> Various notes: Specifying a skill to award exp is completely reasonable, and easy enough to do. In the new skill system, you can have exp in a skill and still not be able to use it (this sort of has to be the case, because you have skills like praying - you may need a skill tool, or you may know it intrinsicly, but either way, the pray skill object has to hold the exp). It would be odd to have 5000 exp in a skill and still not be able to know it. but it seems completely reasonable to me that if the exp reward is noteworthy that it would teach you the skill instead of the exp reward if you don't know it. This may not be appropriate for low level (<10?) quests, but at some point, learning a skill is more about the luck of finding the appropriate skill scroll in the shops and not about resources (money). The issue of players camping out keeps coming up, and I keep repeating the same thing - look at the RESET_LOCATION_TIME in include/config.h. Setting that means you can't camp out - you'll get returned to your last savebed location. The only downside to turning it on is that players get a free word of recall. But if set to something reasonable (1800 (30 minutes)), probably not a really big deal - losing half an hour of play time to get that word of recall is probably a reasonable tradeoff. The only other issue with exp reward object is how to handle a party of adventurers - I guess that would be easy - split the reward with everyone in the party. If a player leaves the party right before he steps on the space, the other players are screwed, OTOH, they are not likely to party with him again. But if people just work together and don't actually use the party code, I'm not sure how to work it out. This could be one reason to add a force object recording player has got the reward - then, it could be usuable many times, but if the player has gotten the reward, he won't get it again (until the force expires or whatever). But it means everyone he is playing with can also get the reward. Tracking who has visited the object doesn't make a lot of sense to me. If 2 weeks have passed and for whatever reason, people haven't visited that exp object, should I get screwed out of that exp? And at least with force objects, we could perhaps have a special 'quest' tag or the like and thus have a command which shows which quests you've done and when they expire, eg, something like: quest name expires at return the scroll to grok May 28, 23:18 clear tower of foo bar May 26, 18:54 and whatever - can use the 'msg' field of the force object to hold the quest name. Thus, a player logs in and says 'ahh - I can re-do the forge sword of kram quest, as its not listed'. The only question would be should the lack of repeatability of quests be real (earth) time based, or game time (pticks) based? As far as plugins go, to me, it makes the most sense to have basic functionality within the server code itself, and use plugins to expand the functionality of the object. In this case, the object actually isn't that complicated - has walk_on/fly_on set, in the 'skill' field contains the name of the skill to add the exp to, and the exp field contains how much exp to reward. Some other flag can have something like 'player can't use this if force object is in inventory, and we add one if player doesn't have force object'. Now the plugin can expand that - do other things, do other checks (if, for example, the quest is to clear an area, then perhaps the plugin would go look and make sure there aren't any monsters in the area). To me, we shouldn't expect most map makers to write plugin scripts. Rather, we should provide the basic functionality in objects in the came, which the editor make easy to modify, and which are readily available. If the map maker has the skill and want to make plugin scripts, great. But as I've said before, the code has to be someplace - whether it is C code in the server, or python code in the plugin. IMO, basic functionality should be in the C code. I don't mean to downplay the usefulness of the plugin code - there are lots of things where you want to do some special processing, but it is used in only a few places, and thus doesn't make sense to do it as C code - the plugin is ideal for that. But the python code shouldn't replace the basic operations of the game. The other fact of the matter is that I'm sure the C code is _a lot_ faster than the python code. This isn't a big deal right now, and probably isn't a big deal for most scripts, but if using scripts for common objects became to commonplace, we'd then probably start looking at performance at that point and start implementing more of it in C anyways. I also don't think the basis of 'using plugins would be hard, thus we don't have to worry about mapmakers abusing it' is quite the right approach. If it is too hard, no one would use it at all, and we'd have the same type of maps we have right now. IMO, keeping good maps is more an issue of players/other developers reviewing the maps, saying they are good/map, making changes, and whatnot. I have a feeling a good number of 'bad' maps are not as much because the map maker didn't know what they were doing - they almost certainly did when they put that mega weapon there or whatever - they just thought it'd be cool or whatever else. If plugins are used, the same thing could happen, and now you also have to start reviewing the plugins that are submitted (what exactly is this plugin doing? Does it make sense, is it abusive, etc). _______________________________________________ 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 May 23 23:51:46 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:13 2005 Subject: AW: [CF-Devel] cfclient issues In-Reply-To: References: Message-ID: <3ECEFA62.6050906@sonic.net> Fixed in CVS. There have been some of those in the past also - slowly they get fixed as discovered, as the fix is easy. Just no one has bothered to look at all the code which could generate such cases. Michael Toennies wrote: > I find some bad bug in player movement, > which can course this client affects too. > > Because we track in the client now more accurate > what happens on the map, this bug will come in effect - > missing > > esrv_map_scroll(&op->contr->socket, freearr_x[dir],freearr_y[dir]); > > functions when the player moves. > > This is the right way to move a player (from move_ob() ). > > remove_ob(op); > op->x+=freearr_x[dir]; > op->y+=freearr_y[dir]; > insert_ob_in_map(op,op->map,originator,0); > /* Currently, assume that players will only be single space objects */ > if (op->type==PLAYER) { > esrv_map_scroll(&op->contr->socket, freearr_x[dir],freearr_y[dir]); > op->contr->socket.update_look=1; > op->contr->socket.look_position=0; > } > > This is, how for example the shop_mat function teleports a player back > in the shop when he can't pay all unpaid items: > > else { > /* if we get here, a player tried to leave a shop but was not able > * to afford the items he has. We try to move the player so that > * they are not on the mat anymore > */ > > int i = find_free_spot (op->arch, op->map, op->x, op->y, 1, 9); > if(i == -1) { > LOG (llevError, "Internal shop-mat problem.\n"); > } else { > remove_ob (op); > op->x += freearr_x[i]; > op->y += freearr_y[i]; > rv = insert_ob_in_map (op, op->map, shop_mat,0) == NULL; > } > } > > The map scroll cmd is missed. This will bring every feature out of track, > which > depends on exactly map data & position data. > > You will notice this effect sometimes, when you get ported/moved, and a > "shadow" > of your player char animation stays on the position where you was before. > > This missing scroll cmds are numerous in the code - better to check every > insert_ob_in_map() and add it when needed. > > > _______________________________________________ > 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 May 24 09: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:13 2005 Subject: AW: AW: [CF-Devel] cfclient issues In-Reply-To: <3ECEFA62.6050906@sonic.net> Message-ID: True, its some work. If you have time, look for TRAPDOOR and HOLE in the code - but i am out of patch sync for CF, so its fixed perhaps. I had done some more interesting stuff: For tiled maps, which builds a bigger meta map, it is a bad thing that teleporters can't teleport items & monster over map borders (aka to a new map) - only players. Also, the enter_map()/enter_exit() functions are player only/single arch only. I had advanced this functions to work for items & monsters (multi arch too) and it was easier as i thought. Problems are only random maps & unique maps - but there i can't see why we need it. Also, i added a "no_teleport" flag for TELEPORTERS. The i advanced them to teleport ALL whats in the spot of the TELEPORTER and don't have the flag set - also i added to teleport multi arch too when only one part is on the teleporter. This added really new features to maps. In daimonin, system objects are autosorted when put on a map (no need to put them explicit under the floor). Now, i can put some system objects or stuff like traps on the map and a invisible teleporter to it. One handle pull - and the map part is cleared - all teleported out to a save area... then you move over it, pull another handle and all is teleported back. This will allow new dynamic effects to maps and map makers. To avoid problems with old maps, just create a NEW_TELEPORTER object... > > > Fixed in CVS. > > There have been some of those in the past also - slowly they > get fixed as > discovered, as the fix is easy. Just no one has bothered to look > at all the > code which could generate such cases. > > > > Michael Toennies wrote: > > I find some bad bug in player movement, > > which can course this client affects too. > > > > Because we track in the client now more accurate > > what happens on the map, this bug will come in effect - > > missing > > > > esrv_map_scroll(&op->contr->socket, freearr_x[dir],freearr_y[dir]); > > > > functions when the player moves. > > > > This is the right way to move a player (from move_ob() ). > > > > remove_ob(op); > > op->x+=freearr_x[dir]; > > op->y+=freearr_y[dir]; > > insert_ob_in_map(op,op->map,originator,0); > > /* Currently, assume that players will only be single space > objects */ > > if (op->type==PLAYER) { > > esrv_map_scroll(&op->contr->socket, > freearr_x[dir],freearr_y[dir]); > > op->contr->socket.update_look=1; > > op->contr->socket.look_position=0; > > } > > > > This is, how for example the shop_mat function teleports a player back > > in the shop when he can't pay all unpaid items: > > > > else { > > /* if we get here, a player tried to leave a shop but was not able > > * to afford the items he has. We try to move the player so that > > * they are not on the mat anymore > > */ > > > > int i = find_free_spot (op->arch, op->map, op->x, op->y, 1, 9); > > if(i == -1) { > > LOG (llevError, "Internal shop-mat problem.\n"); > > } else { > > remove_ob (op); > > op->x += freearr_x[i]; > > op->y += freearr_y[i]; > > rv = insert_ob_in_map (op, op->map, shop_mat,0) == NULL; > > } > > } > > > > The map scroll cmd is missed. This will bring every feature out > of track, > > which > > depends on exactly map data & position data. > > > > You will notice this effect sometimes, when you get ported/moved, and a > > "shadow" > > of your player char animation stays on the position where you > was before. > > > > This missing scroll cmds are numerous in the code - better to > check every > > insert_ob_in_map() and add it when needed. > > > > > > _______________________________________________ > > 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 Sat May 24 10:25:47 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:13 2005 Subject: [CF-Devel] RE: new red dragon image In-Reply-To: <7938.1053733758@www42.gmx.net> Message-ID: On 23-May-03 Andreas Vogl wrote: > The idea of adding a possibly large bunch of new monsters > with copied, resized or otherwise mediocre graphics also > makes me feel, frankly, a bit uncomfortable. As I've stated before, the monotony of fighting the same thing over and over really gets to you. I'm not suggesting we pick crappy images, or make little stick drawings.. but perhaps we should consider which we consider to me more important, do we want perfect art, or do we want more monsters to enhance the play experience. Personally.. I'd vote for monsters.. heck.. I play nethack.. fighting little 'a's doesn't bother me. People will forgive poor graphics for a fun game. See nethack or muds. But when you get bored, the quality of the art doesn't keep you playing for long. As for the dragons.. its just one suggestion on how to divide them up.. feel free to edit that. --- 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 May 24 19:31:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:13 2005 Subject: AW: AW: [CF-Devel] cfclient issues In-Reply-To: References: Message-ID: <3ED00EC9.7020902@sonic.net> Michael Toennies wrote: > True, its some work. If you have time, look for TRAPDOOR and > HOLE in the code - but i am out of patch sync for CF, so its > fixed perhaps. Both of those call transfer_ob, which appears to do the right thing. > > I had done some more interesting stuff: > > For tiled maps, which builds a bigger meta map, it is a bad > thing that teleporters can't teleport items & monster over map > borders (aka to a new map) - only players. Also, the > enter_map()/enter_exit() functions are player only/single arch only. Yeah, the enter_map only handles single space object right now. It probably wouldn't be a bad idea to modify that to handle multi part objects, and add a flag to the exit to denote if it should transfer non player objects 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 Sat May 24 20:18:44 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:14 2005 Subject: [CF-Devel] unipart monsters Message-ID: <3ED019F4.5090504@sympatico.ca> here is a screenshot of a 4x4 ent arch done as a single tile. The overlapping parts of the graphic tend to get put behind objects on the other tiles, not infront as you would expect. Neat, sort of works anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: overlap.png Type: image/png Size: 80488 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030524/cb2fe063/overlap.png From crossfire-devel-admin at archives.real-time.com Sat May 24 20:10:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:14 2005 Subject: [CF-Devel] RE: new red dragon image References: Message-ID: <29934.1053825001@www3.gmx.net> Tim Rightnour wrote: > > As I've stated before, the monotony of fighting the same thing > over and over really gets to you. I'm not suggesting we pick > crappy images, or make little stick drawings.. but perhaps we > should consider which we consider to me more important, do we > want perfect art, or do we want more monsters to enhance the > play experience. Personally.. I'd vote for monsters.. heck.. > I play nethack.. fighting little 'a's doesn't bother me. I have witnessed over several years that mapmakers avoid badly drawn monsters like the plaque. We've also noticed that players do complain about crappy images like the old red dragon we had before. It's not true that people don't care about art. And there are those who play Crossfire exactly because they *don't* want to fight little 'a's. > People will forgive poor graphics for a fun game. That's true in theory. Just don't forget the last four words of that sentence please. I certainly don't want to forbid the addition of monsters with "mediocre" graphics, but such monsters should at least be well designed in other aspects to make up for it. I mean for example, they should fill a gap in the monster families, have a unique set of attributes/abilities, maybe have their own treasurelist, etc. Another option may be that they come along with a set of new maps. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ 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 May 24 22:44:46 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:14 2005 Subject: AW: AW: AW: [CF-Devel] cfclient issues In-Reply-To: <3ED00EC9.7020902@sonic.net> Message-ID: > > I had done some more interesting stuff: > > > > For tiled maps, which builds a bigger meta map, it is a bad > > thing that teleporters can't teleport items & monster over map > > borders (aka to a new map) - only players. Also, the > > enter_map()/enter_exit() functions are player only/single arch only. > > Yeah, the enter_map only handles single space object right now. > It probably > wouldn't be a bad idea to modify that to handle multi part > objects, and add a > flag to the exit to denote if it should transfer non player > objects or not. > Yes, i prefer 3 flags which we can stack: TRANSFER_PLAYER, TRANSFER_MONSTER, TRANSFER_OBJECTS transfer_player is clear - if set, the exit transfers player transfer_monster - for all who has monster 1 set and transfer objects - for all who are not from above This is really nice for teleporters... like object only teleporters which can use to transfer good/nasty objects from/to a map. btw, is monster 1 valid for all "creatures" the player can meet? Normal monsters, god objects, avatars,... are there all objects included exotic ones? Animated sword? _______________________________________________ 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 May 25 01:39:51 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:14 2005 Subject: [CF-Devel] unipart monsters In-Reply-To: <3ED019F4.5090504@sympatico.ca> Message-ID: On 25-May-03 Todd wrote: > here is a screenshot of a 4x4 ent arch done as a single tile. The > overlapping parts of the graphic tend to get put behind objects on the > other tiles, not infront as you would expect. Yeah.. that looks borked. Is that with gcfclient? I wonder if that has to do with how the arch is set up, or with the way the client displays these single tiled objects. --- 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 May 25 02:29:37 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:14 2005 Subject: [CF-Devel] unipart monsters In-Reply-To: References: Message-ID: <3ED070E1.8080301@sympatico.ca> not so borked, this is two ents, not one - the only thing is that the overlap on the images is over top of the ground arches, but behind objects on those tiles. Ya is gcf client. Tim Rightnour wrote: >On 25-May-03 Todd wrote: > > >>here is a screenshot of a 4x4 ent arch done as a single tile. The >>overlapping parts of the graphic tend to get put behind objects on the >>other tiles, not infront as you would expect. >> >> > >Yeah.. that looks borked. Is that with gcfclient? I wonder if that has to do >with how the arch is set up, or with the way the client displays these single >tiled objects. > > _______________________________________________ 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 May 25 02:53:21 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:14 2005 Subject: [CF-Devel] unipart monsters In-Reply-To: <3ED070E1.8080301@sympatico.ca> References: <3ED070E1.8080301@sympatico.ca> Message-ID: <3ED07671.8060301@sympatico.ca> BTW - here's the arch for that 64x64px ent graphic to prevent confusion as to what is going on in that picture. It shows two of these fellows standing beside each other tryingto beat me up just outside scorn. Notice they are overlapping properly in their primary tiles and the parts of them which is outside this is displaying ok, but stacking badly. Object ent2 randomitems giant race faerie face ent2.111 color_fg brown anim ent2.111 ent2.111 ent2.111 ent2.112 ent2.112 ent2.113 ent2.113 ent2.112 mina msg @match * Hey! Careful of my roots stranger. endmsg unaggressive 1 resist_fire -50 resist_cold 50 resist_electricity 50 exp 16000 ac -1 wc -1 dam 25 can_see_in_dark 1 hp 1500 Con 10 maxhp 1500 alive 1 speed -0.3 weight 300000 monster 1 sleep 1 Wis 15 level 12 run_away 3 can_use_weapon 1 editable 1 body_arm 2 end _______________________________________________ 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 May 25 11:44:31 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:14 2005 Subject: [CF-Devel] synchronizing multipart animation Message-ID: <15645.1053881071@www3.gmx.net> There is an age-old bug in the Crossfire server which causes multi-part animations to ge out of sunchronization. I have noticed that it happens a lot more often nowadays, to the point where it really gets annoying. I manage to reproduce it reliably when I enter scorn zoo (downstairs) repeadedly and run around there. I have no idea what is really causing the sync error, but the root problems is obvious: Multi part animations start in the same state, but they don't run synchronized. I've written a trivial change which makes all multi-tails copy the animation state from their head, instead of running their own animation cycles. I've tested it and have never again seen multi-parts getting out of synchronization. AndreasV Below is the new, modified code from the animate_object() function of "common/anim.c": void animate_object(object *op, int dir) { int max_state; /* Max animation state object should be drawn in */ int base_state; /* starting index # to draw from */ if(!op->animation_id || !NUM_ANIMATIONS(op)) { LOG(llevError,"Object lacks animation.\n"); dump_object(op); return; } if (op->head && op->head != op) { /* all multi-tail parts run synchronized with their head */ dir = op->head->direction; if (NUM_ANIMATIONS(op) == NUM_ANIMATIONS(op->head)) op->state = op->head->state; else ++op->state; } else { ++op->state; /* increase draw state */ } /* If object is turning, then max animation state is half through the * animations. Otherwise, we can use all the animations. */ max_state=NUM_ANIMATIONS(op)/ NUM_FACINGS(op); base_state=0; ... ... [rest of the funtion stay the same] -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ 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 May 25 12:45:24 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:14 2005 Subject: [CF-Devel] quest exp rewards (RE: monsters, ...) In-Reply-To: <3ECEF868.1080700@sonic.net> References: <20030524033754.BKEV24631.tomts15-srv.bellnexxia.net@[209.226.175.18]> <3ECEF868.1080700@sonic.net> Message-ID: <3ED10134.9000701@sympatico.ca> > > As far as plugins go, to me, it makes the most sense to have basic > functionality within the server code itself, and use plugins to expand > the functionality of the object. I think I said this... I am pretty sure that is what I was saying, I don't think I said dont't make a an xp giver object and I certainly never said let's *not* make xp awards... I did say that if you wanted to try this you could do it now... maybe I shouldn't say stuff like that. > In this case, the object actually isn't that complicated - has > walk_on/fly_on set, in the 'skill' field contains the name of the > skill to add the exp to, and the exp field contains how much exp to > reward. Some other flag can have something like 'player can't use > this if force object is in inventory, and we add one if player doesn't > have force object'. I would think a field for the desired skill to apply the xp to and a connect field to trigger it would be most flexable, no? If you decide not to use force objects to track usage and want to do something different then you can make it. > Now the plugin can expand that - do other things, do other checks > (if, for example, the quest is to clear an area, then perhaps the > plugin would go look and make sure there aren't any monsters in the > area). yup, it can. > > To me, we shouldn't expect most map makers to write plugin scripts. > Rather, we should provide the basic functionality in objects in the > came, which the editor make easy to modify, and which are readily > available. If the map maker has the skill and want to make plugin > scripts, great. > > But as I've said before, the code has to be someplace - whether it is > C code in the server, or python code in the plugin. IMO, basic > functionality should be in the C code. yes, you can do a number of things like this - this is what I was saying... not 'only use the plugin' or 'lets make it hard to use and force people to use the plugin.' The code does have to be someplace - an arch object is a good idea - I think I said that too. > > I don't mean to downplay the usefulness of the plugin code - there > are lots of things where you want to do some special processing, but > it is used in only a few places, and thus doesn't make sense to do it > as C code - the plugin is ideal for that. But the python code > shouldn't replace the basic operations of the game. I don't think I ever said don't make this an arch, I just said make it a simple arch, otherwise it is not as useful - you decide to have xp generators only work by marker then sontime you will have to make one that works another way. If you have a lot of little atomic arches like a list, a timer, a randomizer, a xp generator, a monster generator... you can combine them to make bigger things *or* use them with the plugin. Make the xp generator work by connect. If you want a trigger that looks for a force in a player - get a different arch that detects player forces and then connect them - voila there's your force object controlled xp generator! What you want to make one connected to a altar? - ok there you go hook this to your altar... > > The other fact of the matter is that I'm sure the C code is _a lot_ > faster than the python code. This isn't a big deal right now, and > probably isn't a big deal for most scripts, but if using scripts for > common objects became to commonplace, we'd then probably start looking > at performance at that point and start implementing more of it in C > anyways. > > I also don't think the basis of 'using plugins would be hard, thus we > don't have to worry about mapmakers abusing it' is quite the right > approach. If it is too hard, no one would use it at all, and we'd > have the same type of maps we have right now. IMO, keeping good maps > is more an issue of players/other developers reviewing the maps, > saying they are good/map, making changes, and whatnot. I have a > feeling a good number of 'bad' maps are not as much because the map > maker didn't know what they were doing - they almost certainly did > when they put that mega weapon there or whatever - they just thought > it'd be cool or whatever else. If plugins are used, the same thing > could happen, and now you also have to start reviewing the plugins > that are submitted (what exactly is this plugin doing? Does it make > sense, is it abusive, etc). > Where does all this stuff come from anyway? I am disparing from writing to this list anymore* - I can't say the sky is blue without hearing back that I am somehow against the idea of the sky and that in C it is bluer. Think I am being unreasonable? Here is what I actually said: "One of the reasons that there is so much treasure abuse is the fact that it is easly to drop big items onto the map and not so easy to create safeguards for them. This will also occur with an xp generator - good maps will make good use of it and bad maps will make abuse of it. This won't go away using scripting, but it might be easier to be more flexable." - didn't say lets take the PERL aproach and make map making harder, I didn't say map makers are stupid, I didn't say it wouldn't happen using the plugin too. I just said it is easy to put in items and hard to control access to them... If you want me, I'l be hanging around the arches mumbling bad words. *Heheheh, you should be so lucky. _______________________________________________ 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 May 25 14:45:25 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:14 2005 Subject: [CF-Devel] RE: cfclient issues Message-ID: <26734.1053891925@www67.gmx.net> I want to get back to some of the map display errors I've been talking about before. First there is the problem about tiles getting messed up with stipple patters from the fog-of-war. This happens to me always when I used cfclient. I made screenshots of the effect now, available at: http://home.in.tum.de/~vogl/crossfire/errors/stipples.html The problem does not appear when running the client both with fogofwar and darkness disabled. Note that the number of corruped images is changing while I play. Some get back to normal after a while, new ones get corrupted... The second issue I want to adress is the problem of "frozen" images which stay in view while the real object is gone. After a series of testing I have noticed that this problem occurs drastically often when fog-of-war is disabled, while it's almost gone when fog-of-war is enabled. This leads me to the impression there might be a fundamental error in the way fogofwar is disabled in the client. It is easy to reproduce: Run cfclient with "-nofogofwar", walk up to a large multipart monster so that you see only the first line of tiles. Then move forward and backward while the monster is moving sidewards. Works best in scorn zoo where the monsters are bound to stay behind fences. Screenshots and a description how to do this can be seen at: http://home.in.tum.de/~vogl/crossfire/errors/messup.html The fact that this problem does not appear with enabled fogofwar is remarkable. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ 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 May 25 17:34:24 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:14 2005 Subject: [CF-Devel] RE: new red dragon image In-Reply-To: <29934.1053825001@www3.gmx.net> References: <29934.1053825001@www3.gmx.net> Message-ID: <3ED144F0.2020501@sonic.net> Andreas Vogl wrote: > I mean for example, they should fill a gap in the monster > families, have a unique set of attributes/abilities, > maybe have their own treasurelist, etc. > Another option may be that they come along with a set of > new maps. I was about to comment - it is easy enough to old a whole bunch of new monsters, but it doesn't really do a lot of good unless they are used for something. At some level, random maps can use the new monsters, but that is probably only a subset of the 'interesting' maps that people will visit. That said, I think there is lots of room to fill gaps in monster families. The counter to the poor graphic is that images that are used tend to be more likely to get fixed up by someone, compared to images that are not used (of if a new image is being made, I'd tend to guess that people would be reluctant to make images that may not be used for anything). _______________________________________________ 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 May 25 18:38:06 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:14 2005 Subject: [CF-Devel] RE: cfclient issues In-Reply-To: <26734.1053891925@www67.gmx.net> References: <26734.1053891925@www67.gmx.net> Message-ID: <3ED153DE.90401@sonic.net> Both of these problems should now be fixed in CVS. Andreas Vogl wrote: > I want to get back to some of the map display errors I've > been talking about before. > > First there is the problem about tiles getting messed up > with stipple patters from the fog-of-war. This happens to > me always when I used cfclient. I made screenshots of the > effect now, available at: > http://home.in.tum.de/~vogl/crossfire/errors/stipples.html > The problem does not appear when running the client both > with fogofwar and darkness disabled. > Note that the number of corruped images is changing while > I play. Some get back to normal after a while, new ones > get corrupted... > > > The second issue I want to adress is the problem of "frozen" > images which stay in view while the real object is gone. > After a series of testing I have noticed that this problem > occurs drastically often when fog-of-war is disabled, while it's > almost gone when fog-of-war is enabled. > This leads me to the impression there might be a fundamental > error in the way fogofwar is disabled in the client. > > It is easy to reproduce: Run cfclient with "-nofogofwar", > walk up to a large multipart monster so that you see only > the first line of tiles. Then move forward and backward > while the monster is moving sidewards. Works best in scorn > zoo where the monsters are bound to stay behind fences. > Screenshots and a description how to do this can be seen at: > http://home.in.tum.de/~vogl/crossfire/errors/messup.html > > The fact that this problem does not appear with enabled > fogofwar is remarkable. > > > AndreasV > _______________________________________________ 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 May 25 18:49:48 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:14 2005 Subject: [CF-Devel] quest exp rewards (RE: monsters, ...) In-Reply-To: <3ED10134.9000701@sympatico.ca> References: <20030524033754.BKEV24631.tomts15-srv.bellnexxia.net@[209.226.175.18]> <3ECEF868.1080700@sonic.net> <3ED10134.9000701@sympatico.ca> Message-ID: <3ED1569C.80800@sonic.net> Todd wrote: > > I think I said this... I am pretty sure that is what I was saying, I > don't think I said dont't make a an xp giver object and I certainly > never said let's *not* make xp awards... > I did say that if you wanted to try this you could do it now... maybe I > shouldn't say stuff like that. Sorry if I went a bit overboard - from your original message, I got the idea that the exp rewarder should just be a plugin and nothing more. Most likely just a misunderstanding. That said, it seems to me the basic properties in an exp rewarder are: 1) amount of exp to reward the player. 2) Skill to award the exp to. 3) Flag to denote we should teach the player this skill if they don't have it (this is potentially interesting in that this is now a way for objects to teach skills). 4) Different ways to be activated (walk on/fly on, as well as it being activated from something that 'pushes' it (aka, magic mouth, button, etc)). In the case of another object activating it, the player would still need to be on the space the object is on. this last point actually makes party rewards potentially easier. Eg, could have something like 'put the sword in the pedestal, and everyone in the room shall receive a proper reward'. As a map maker, just cover every space in the room with the exp rewarders, connected to the pedestal that looks for the sword. 5) perhaps use the the 'slaying' field to denote that if the player has an object in their inventory with the same slaying field, they can't get a reward. The harder point on this is there are two real cases we would want here: 1) Player can only get the reward once for the lifetime of the character (thus, the marker object is permanent) 2) The marker object has some finite life. How to denote that finite life (ticks, real time, etc), is more difficult. Perhaps only worry about 5.1 in the object, and leave this point (5.2) to plugins. Anything that seems to be missing? If you want to award exp to two different skills, the simple solution is to just have two exp rewards. _______________________________________________ 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 May 26 02:32:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:15 2005 Subject: [CF-Devel] synchronizing multipart animation In-Reply-To: <15645.1053881071@www3.gmx.net> References: <15645.1053881071@www3.gmx.net> Message-ID: <3ED1C321.3090109@sonic.net> I put the below change into CVS. Andreas Vogl wrote: > There is an age-old bug in the Crossfire server which causes > multi-part animations to ge out of sunchronization. > I have noticed that it happens a lot more often nowadays, > to the point where it really gets annoying. > I manage to reproduce it reliably when I enter scorn zoo > (downstairs) repeadedly and run around there. > > I have no idea what is really causing the sync error, > but the root problems is obvious: Multi part animations > start in the same state, but they don't run synchronized. > > I've written a trivial change which makes all multi-tails > copy the animation state from their head, instead of > running their own animation cycles. > I've tested it and have never again seen multi-parts getting > out of synchronization. > > > AndreasV > > Below is the new, modified code from the animate_object() > function of "common/anim.c": > > > void animate_object(object *op, int dir) { > int max_state; /* Max animation state object should be drawn in */ > int base_state; /* starting index # to draw from */ > > if(!op->animation_id || !NUM_ANIMATIONS(op)) { > LOG(llevError,"Object lacks animation.\n"); > dump_object(op); > return; > } > > if (op->head && op->head != op) { > /* all multi-tail parts run synchronized with their head */ > dir = op->head->direction; > > if (NUM_ANIMATIONS(op) == NUM_ANIMATIONS(op->head)) > op->state = op->head->state; > else > ++op->state; > } > else { > ++op->state; /* increase draw state */ > } > > /* If object is turning, then max animation state is half through the > * animations. Otherwise, we can use all the animations. > */ > max_state=NUM_ANIMATIONS(op)/ NUM_FACINGS(op); > base_state=0; > ... > ... > [rest of the funtion stay the same] > > > _______________________________________________ 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 May 26 02:49:53 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:15 2005 Subject: [CF-Devel] spell casting times. Message-ID: <3ED1C721.7090005@sonic.net> Going into the spell code now, and found what I thought was one oddity, as well as some other questions/thoughts. The oddity is that casting time for spells is in 'ticks' and not an absolute time like most code. Thus, if a spell has a time of 2, it will take 2 game ticks whether the players speed is 1.0 or 0.1. Most thing would say 'takes 2.0 speed. If the players speed is 1.0, that is two game ticks. If the players speed is 0.1, that is 20 game ticks' I'm inclined to think that spell casting should fall into the later category - eg, what the characters speed is will determine how quickly he can cast the next spell. The way it is now, your speed doesn't really make any difference, once you get into position. The related questions I have on spell casting would be how long should using spell like objects (scrolls, wands, rods, etc) take to use. Should it be tied to the spell they are casting, or some fixed time. I sort of think it should depend more on the item (no matter what, it can only take so long to drink a potion for example). The last issue would be the general speed of casting - should it be altered? My general inclination right now is that it seems too fast, and should be slowed down a bit - exactly how much could be a matter of debate. _______________________________________________ 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 May 26 10:54:16 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:15 2005 Subject: [CF-Devel] Appartment-quit crash Message-ID: <20030526155416.GA2248@mids.student.utwente.nl> Player Ketche reports a way to crash the server: Buy a permanent appartment (the one in Scorn for example) and type quit. BOOM! Debug info is available on: http://mids.student.utwente.nl/~crossfire/cores/ Joris Bontje / mids -- PGP Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xF19326A9 Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030526/0de10e9b/attachment.pgp From crossfire-devel-admin at archives.real-time.com Mon May 26 10:59:16 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:15 2005 Subject: [CF-Devel] Shop stealing bug Message-ID: <200305261559.h4QFxHF9012063@mamia.prninfo.com> The bug when you throw a item(unpaid) out of a shop(the unpaid flag is still there) was fixed, but I found a way to bypass it. You put the unpaid item in a bag, throw the bag out of the shop, the item is still unpaid, but, it is the same bug. It would be good if this bug was fixed, because with bugs such as that make game-play poorer. (P.S. If it is fixed, make sure that you can't put a bag with unpaid item in another bag and have the same problem over again. :-P) -- Ketche _______________________________________________ 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 May 26 11:03:21 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:15 2005 Subject: [CF-Devel] Appartment-quit crash In-Reply-To: <20030526155416.GA2248@mids.student.utwente.nl> References: <20030526155416.GA2248@mids.student.utwente.nl> Message-ID: <20030526160321.GA2343@mids.student.utwente.nl> On Mon, May 26, 2003 at 05:54:16PM +0200, Joris Bontje wrote: > Player Ketche reports a way to crash the server: > > Buy a permanent appartment (the one in Scorn for example) and type quit. > BOOM! > > Debug info is available on: > http://mids.student.utwente.nl/~crossfire/cores/ Addition: you have to be in the appartment when you type quit. Joris Bontje -- PGP Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xF19326A9 Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030526/37ec613c/attachment.pgp From crossfire-devel-admin at archives.real-time.com Mon May 26 12:45:39 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:15 2005 Subject: [CF-Devel] Appartment-quit crash In-Reply-To: <20030526160321.GA2343@mids.student.utwente.nl> References: <20030526155416.GA2248@mids.student.utwente.nl> <20030526160321.GA2343@mids.student.utwente.nl> Message-ID: <20030526174539.GA25960@crystal> On Mon, May 26, 2003 at 06:03:21PM +0200, Joris Bontje wrote: > On Mon, May 26, 2003 at 05:54:16PM +0200, Joris Bontje wrote: > > Player Ketche reports a way to crash the server: > > > > Buy a permanent appartment (the one in Scorn for example) and type quit. > > BOOM! [snip] You don't even need to buy it. Just enter the apartment and quit, and the server crashes. On a related note, if you bring *any* pets at all into the Blood Well in Stoneville (while the traps haven't been disarmed yet), the server will crash too. I've unwittingly crashed metalforge twice because of this. This seems to be a bug in the pet placement code. T -- ASCII stupid question, get a stupid ANSI. _______________________________________________ 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 May 26 18:59:08 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:15 2005 Subject: [CF-Devel] Appartment-quit crash In-Reply-To: <20030526174539.GA25960@crystal> References: <20030526155416.GA2248@mids.student.utwente.nl> <20030526160321.GA2343@mids.student.utwente.nl> <20030526174539.GA25960@crystal> Message-ID: <3ED2AA4C.6080707@sonic.net> H. S. Teoh wrote: > On Mon, May 26, 2003 at 06:03:21PM +0200, Joris Bontje wrote: > >>On Mon, May 26, 2003 at 05:54:16PM +0200, Joris Bontje wrote: >> >>>Player Ketche reports a way to crash the server: >>> >>>Buy a permanent appartment (the one in Scorn for example) and type quit. >>>BOOM! > > [snip] > > You don't even need to buy it. Just enter the apartment and quit, and the > server crashes. Fixed in CVS. > > On a related note, if you bring *any* pets at all into the Blood Well in > Stoneville (while the traps haven't been disarmed yet), the server will > crash too. I've unwittingly crashed metalforge twice because of this. This > seems to be a bug in the pet placement code. Haven't confirmed, but fix for above may also have fixed this. I had some bogus logic when looking for objects that were still on the map after we called free_all_objects - it wasn't checking the FLAG_REMOVED field. _______________________________________________ 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 May 26 22:42:52 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:15 2005 Subject: [CF-Devel] Problems compiling CF... Message-ID: <20030527034252.3FCA846C5@sitemail.everyone.net> Hello Everybody! I hope this is the right mailing list for this question. I'm trying to compile Crossfire Server 1.5.0 in my Linux, but I get an error I don't know how to solve. The configure command works OK, but when I run make I get this error: In file included from Cnv.h:26, from CnvUtil.c:22: ../include/Xaw.h:33: X11/Xaw/Cardinals.h: No such file or directory ../include/Xaw.h:36: X11/Xaw/Command.h: No such file or directory ../include/Xaw.h:37: X11/Xaw/Grip.h: No such file or directory ../include/Xaw.h:38: X11/Xaw/Label.h: No such file or directory ../include/Xaw.h:39: X11/Xaw/List.h: No such file or directory ../include/Xaw.h:40: X11/Xaw/Panner.h: No such file or directory ../include/Xaw.h:41: X11/Xaw/Repeater.h: No such file or directory ../include/Xaw.h:42: X11/Xaw/Scrollbar.h: No such file or directory ../include/Xaw.h:43: X11/Xaw/StripChart.h: No such file or directory ../include/Xaw.h:44: X11/Xaw/Toggle.h: No such file or directory ../include/Xaw.h:47: X11/Xaw/MenuButton.h: No such file or directory ../include/Xaw.h:48: X11/Xaw/SimpleMenu.h: No such file or directory ../include/Xaw.h:49: X11/Xaw/Sme.h: No such file or directory ../include/Xaw.h:50: X11/Xaw/SmeBSB.h: No such file or directory ../include/Xaw.h:51: X11/Xaw/SmeLine.h: No such file or directory ../include/Xaw.h:54: X11/Xaw/AsciiText.h: No such file or directory ../include/Xaw.h:55: X11/Xaw/Text.h: No such file or directory ../include/Xaw.h:58: X11/Xaw/Box.h: No such file or directory ../include/Xaw.h:59: X11/Xaw/Dialog.h: No such file or directory ../include/Xaw.h:60: X11/Xaw/Form.h: No such file or directory ../include/Xaw.h:61: X11/Xaw/Paned.h: No such file or directory ../include/Xaw.h:62: X11/Xaw/Porthole.h: No such file or directory ../include/Xaw.h:63: X11/Xaw/Tree.h: No such file or directory ../include/Xaw.h:64: X11/Xaw/Viewport.h: No such file or directory make[2]: *** [CnvUtil.o] Error 1 make[2]: Leaving directory `/root/crossfire-1.5.0/crossedit/Cnv' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/crossfire-1.5.0/crossedit' make: *** [all-recursive] Error 1 and then it quits. I'm using Debian 3.0R1 with a Linux kernel 2.4.20, gcc 2.95.4-14. Thanks for your help. If you need more information on my system, don't hesitate on asking. Thanks, Renzo. _____________________________________________________________ TheFreeSite.com: Home of the Web's best freebies. http://www.thefreesite.com _____________________________________________________________ Select your own custom email address for FREE! Get you@yourchoice.com w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag _______________________________________________ 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 May 27 02:10:14 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:15 2005 Subject: [CF-Devel] Problems compiling CF... In-Reply-To: <20030527034252.3FCA846C5@sitemail.everyone.net> References: <20030527034252.3FCA846C5@sitemail.everyone.net> Message-ID: <20030527071014.GA5480@mids.student.utwente.nl> On Mon, May 26, 2003 at 08:42:52PM -0700, Renzo Crispieri wrote: > I hope this is the right mailing list for this question. I'm trying to > compile Crossfire Server 1.5.0 in my Linux, but I get an error I don't > know how to solve. The configure command works OK, but when I run make Short answer: install libxaw7-dev Last night I did get the same problem and it was briefly discussed on the chat channel. Because crossedit is the last it tries, getting an error isn't that terrible. But it doesn't look nice. Probably crossedit will be removed or atleast disabled by default. Joris Bontje -- PGP Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xF19326A9 Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030527/530dcbb0/attachment.pgp From crossfire-devel-admin at archives.real-time.com Tue May 27 21:26:42 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:15 2005 Subject: [CF-Devel] Problems compiling CF... References: <20030527034252.3FCA846C5@sitemail.everyone.net> <20030527071014.GA5480@mids.student.utwente.nl> Message-ID: <001b01c324c0$946e8e60$0802a8c0@KAMERIA> You can also remove the crossedit reference from the makefile so it does not build - this is useful if you don't want X on your server. There should be more info in the archives about this as I asked this a few months ago. Anyway you build the server then in the makefile you will see a line SUBDIRS = ... remove crossedit from here and all is good (unless you want crossedit installed on this server.) I still wonder if crossedit should get built by default or if it should only get built as an option since has X as a requirement while the rest of the server does not require X. X is not a small requirement. ----- Original Message ----- From: "Joris Bontje" To: Sent: Tuesday, May 27, 2003 3:10 AM Subject: Re: [CF-Devel] Problems compiling CF... _______________________________________________ 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 May 27 22: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:15 2005 Subject: [CF-Devel] Problems compiling CF... Message-ID: <20030528030425.09F467263@sitemail.everyone.net> Hello everybody! Thanks to everybody for your help. Finally I could compile the CF server without problems. Now I'm trying to compile the client to test my installation of CF server, but again I faced some problems... :-( It was just OK on the ./configure and make depend steps, but when I ran make I got this problem: making all in sound-src... make[1]: Entering directory `/root/crossfire-client-1.5.0/sound-src' gcc -g -O2 -DALSA_SOUND -Wall -I. -I.. -I../common -I. -c cfsndserv.c In file included from cfsndserv.c:87: /usr/include/sys/asoundlib.h:1: warning: #warning This header is deprecated, use instead. cfsndserv.c: In function `init_audio': cfsndserv.c:283: `snd_pcm_channel_params_t' undeclared (first use in this function) cfsndserv.c:283: (Each undeclared identifier is reported only once cfsndserv.c:283: for each function it appears in.) cfsndserv.c:283: parse error before `params' cfsndserv.c:285: `SND_PCM_OPEN_PLAYBACK' undeclared (first use in this function) cfsndserv.c:285: warning: passing arg 2 of `snd_pcm_open' makes pointer from integer without a cast cfsndserv.c:290: `params' undeclared (first use in this function) cfsndserv.c:290: `SND_PCM_CHANNEL_PLAYBACK' undeclared (first use in this function) cfsndserv.c:291: `SND_PCM_MODE_BLOCK' undeclared (first use in this function) cfsndserv.c:294: `SND_PCM_SFMT_S8' undeclared (first use in this function) cfsndserv.c:294: `SND_PCM_SFMT_U8' undeclared (first use in this function) cfsndserv.c:296: `SND_PCM_SFMT_S16_LE' undeclared (first use in this function) cfsndserv.c:296: `SND_PCM_SFMT_U16_LE' undeclared (first use in this function) cfsndserv.c:304: warning: implicit declaration of function `snd_pcm_channel_params' cfsndserv.c:318: warning: unreachable code at beginning of switch statement cfsndserv.c:342: warning: implicit declaration of function `snd_pcm_file_descriptor' cfsndserv.c:343: warning: implicit declaration of function `snd_pcm_nonblock_mode' cfsndserv.c: In function `audio_play': cfsndserv.c:350: warning: implicit declaration of function `snd_pcm_write' make[1]: *** [cfsndserv.o] Error 1 make[1]: Leaving directory `/root/crossfire-client-1.5.0/sound-src' make: *** [all] Error 2 and then it quits. I'm using the following sound modules: Module Size Used by Tainted: P snd-via82xx 11268 0 snd-ac97-codec 33360 0 [snd-via82xx] snd-mpu401-uart 3008 0 [snd-via82xx] snd-rawmidi 12928 0 [snd-mpu401-uart] snd-seq-device 4004 0 [snd-rawmidi] snd-pcm-oss 37380 0 (unused) snd-pcm 57376 0 [snd-via82xx snd-pcm-oss] snd-page-alloc 4272 0 [snd-via82xx snd-pcm] snd-timer 14528 0 [snd-pcm] snd-mixer-oss 11584 0 [snd-pcm-oss] snd 28544 0 [snd-via82xx snd-ac97-codec snd-mpu401-uart snd-rawmidi snd-seq-device snd-pcm-oss snd-pcm snd-timer snd-mixer-oss] I installed ALSA sound. Thanks for your help. If you have any question about my system, I'll gladly aswer. Thanks again, Renzo. _____________________________________________________________ TheFreeSite.com: Home of the Web's best freebies. http://www.thefreesite.com _____________________________________________________________ Select your own custom email address for FREE! Get you@yourchoice.com w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag _______________________________________________ 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 May 28 00:06:35 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:15 2005 Subject: [CF-Devel] Updating FAQ: What do I need to run Crossfire? Message-ID: I'm looking to update the following content for the Crossfire FAQ. Does anyone have anything else to add, update, remove, etc ? http://crossfire.real-time.com/faq/faq.html#2.1 2.1 What do I need to run Crossfire? You will need UNIX, X-windows and an ANSI C compiler to compile this game. Crossfire has been known to compile on the following systems (latest known version number of Crossfire that compiled on these systems is included in parantheses): * Sun3, SunOs 4.1.1, gcc (0.90.3) * DEC300AXP-500 (Alpha with OSF1 1.3) (0.90.3) * Sun4 with SunOS 4.1.3 (0.90.2) * Ultrix 4.2a (0.90.1) * PC Compatiable, with Linux (0.89.3) * IBM RS/6000 with AIX 1.2, X11R4/5 (0.91.4) * HP735, HPUX, X11R5 (0.90.2) * DEC 3100 and DEC 5000 with ULTRIX BSD 4.2 * DEC with OSF1 * VAX3100 with BSD 4.3 * IBM RT with BSD4.3 * HP9000-series (HP-UX) (very old versions of HP-UX might barf on stdarg.h) * MIPS with RISC/os * (UMIPS) 4.52 (?) It has been compiled with X11R3, X11R4 and X11R5 (the editor requires X11R5). To get directions on compilation, read the INSTALL file. I also posted this in the Crossfire Forum and will manage any cross posting between the mailing list and the Forum. http://www.metalforge.net/cfmb/viewtopic.php?p=204#204 Thanks! - Rick _______________________________________________ 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 May 28 09:10:13 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:15 2005 Subject: [CF-Devel] Apply container bug / GTK client question Message-ID: <3ED4C345.7040907@laposte.net> Hello everyone. I'm rather new on Crossfire, only played for one or 2 months, but i really enjoy the game ^.^ I'm using the GTK client under Windows, and one bug that bothers me is how containers work: non applied => applied => opened => APPLIED (instead of non applied). Meaning it's a pain for instance with foods created by gods, which can't be picked up when a sack is applied. So you have to drop the sack, then grab everything. I tracked the bug in the server code, and couldn't find anything, but browsing the GTK client, here's something that bothers me: -- gtk/gx11.c void close_container (item *op) { if (look_list.env != cpl.below) { >>> client_send_apply (look_list.env->tag); <<<<<<<<<<<<<<<<<< look_list.env = cpl.below; strcpy (look_list.title, "You see:"); draw_list (&look_list); } } Tracing the code some more, the 'client_send_apply' basically just sends an 'apply' with the name (which i assume to be the container's). So here's how i see the bug: player applies opened container to close it, server closes and unapplies, client gets update and sends an apply order straight back, meaning the container is applied again.... What do you guys think? BTW, i can't really test stuff for now, under Windows (i'll try to play with the sources anyway, but not sure if i'll succeed in compiling the client & such). Nicolas ('Ryo' on Metalforge 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 Wed May 28 11:54:29 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:16 2005 Subject: [CF-Devel] Updating FAQ: What do I need to run Crossfire? In-Reply-To: Message-ID: On 28-May-03 Rick Tanner wrote: > > I'm looking to update the following content for the Crossfire FAQ. Does > anyone have anything else to add, update, remove, etc ? Compiles on NetBSD.. umm.. just about any version.. 1.3-1.6. Last time I checked, every machine architecture. --- 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 May 29 01:16:33 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:16 2005 Subject: [CF-Devel] Apply container bug / GTK client question In-Reply-To: <3ED4C345.7040907@laposte.net> References: <3ED4C345.7040907@laposte.net> Message-ID: <3ED5A5C1.20508@sonic.net> The way to currently close open containers is to hit the 'close' button which is between the inventory and look window. It has been discussed in the past what the right behaviour is - should click on the container actually close it, or should the cloes button be used. _______________________________________________ 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 May 29 01:19:09 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:16 2005 Subject: [CF-Devel] Problems compiling CF... In-Reply-To: <20030528030425.09F467263@sitemail.everyone.net> References: <20030528030425.09F467263@sitemail.everyone.net> Message-ID: <3ED5A65D.7080604@sonic.net> Renzo Crispieri wrote: > Hello everybody! > > Thanks to everybody for your help. Finally I could compile the CF server without problems. Now I'm trying to compile the client to test my installation of CF server, but again I faced some problems... :-( > It was just OK on the ./configure and make depend steps, but when I ran make I got this problem: > > making all in sound-src... Try adding the --disable-sound when you run configure, and then re-compile. It seems about every year, alsa changes their interface specifications, so the client breaks. _______________________________________________ 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 May 29 01:45:24 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:16 2005 Subject: [CF-Devel] Apply container bug / GTK client question In-Reply-To: <3ED5A5C1.20508@sonic.net> References: <3ED4C345.7040907@laposte.net> <3ED5A5C1.20508@sonic.net> Message-ID: <3ED5AC84.9090308@laposte.net> Hi > The way to currently close open containers is to hit the 'close' > button which is between the inventory and look window. > > It has been discussed in the past what the right behaviour is - > should click on the container actually close it, or should the cloes > button be used. > I checked the mailing lists before posting, but couldn't find anything on that subject... In any case, it isn't a matter of 'close button'. If for instance i manually enter, via the command line, 'apply sack', the behaviour is: unapplied => applied => opened => applied. The only way, via the keyboard, to unapply the sack is to drop it & pick it up... IMO, the close button should indeed be used to close the container. But using the command line should also enable to unapply an item... (i'm lazy & don't want to use the mouse to close, and besides even with the mouse you can't unapply an item...) Just my 2 cents (of euro) Nicolas _______________________________________________ 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 May 29 09:24:41 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:16 2005 Subject: [CF-Devel] compile error Message-ID: <1054218281.1442.19.camel@dhcppc2> Trying to compile crossfire from crossfire-1.3.0.tar.gz (from the real-time ftp site), I got the error that follows. I included a few lines before and after, but it you need more info I can send you the whole shebang. I also got errors in the 'make depend' stage .. I'll include those after this section. I'm running RedHat 7.3 with whatever updates I've found using the Ximian Red Carpet updater. -------------------------------------------- gcc -g -O2 -I../include -I./../include -c time.c gcc -g -O2 -I../include -I./../include -c timers.c gcc -g -O2 -I../include -I./../include -c weather.c /bin/rm -f crossfire gcc -o crossfire alchemy.o apply.o attack.o ban.o c_chat.o c_misc.o c_move.o c_new.o c_object.o c_party.o c_range.o c_wiz.o commands.o daemon.o disease.o egoitem.o hiscore.o gods.o init.o login.o main.o monster.o move.o pets.o player.o plugins.o resurrection.o rune.o shop.o skills.o skill_util.o spell_effect.o spell_util.o swamp.o swap.o time.o timers.o weather.o ../common/libcross.a ../random_maps/random_map.a ../socket/socket.a -ldl -ldmalloclp -lcrypt -lm -lnsl ../socket/socket.a(metaserver.o): In function `metaserver_update': /home/bunky/crossfire-1.3.0/socket/metaserver.c:131: undefined reference to `cst_tot' /home/bunky/crossfire-1.3.0/socket/metaserver.c:131: undefined reference to `cst_tot' /home/bunky/crossfire-1.3.0/socket/metaserver.c:131: undefined reference to `cst_tot' collect2: ld returned 1 exit status make[1]: *** [crossfire] Error 1 make[1]: Leaving directory `/home/bunky/crossfire-1.3.0/server' making all in include... make[1]: Entering directory `/home/bunky/crossfire-1.3.0/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/bunky/crossfire-1.3.0/include' making all in lib... make[1]: Entering directory `/home/bunky/crossfire-1.3.0/lib' make[1]: Nothing to be done for `all'. ---------------------------------------------- Ok, now, in the 'make depend'. I seem to be missing plugin-python.h, but since it was only a warning I wasn't very concerned. This did bother me, but it seems to be unrelated since it's in crossedit. Anyway, figured you might want to know: make[1]: Entering directory `/home/bunky/crossfire-1.3.0/plugin' /usr/bin/X11/makedepend -- -g -O2 -I../include -I./../include -I./include -I../include -- plugin_python.c /usr/bin/X11/makedepend: warning: plugin_python.c, line 32: cannot find include file "plugin_python.h" not in ../include/plugin_python.h not in ./../include/plugin_python.h not in ./include/plugin_python.h not in ../include/plugin_python.h not in /usr/local/lib/gcc-include/plugin_python.h not in /usr/include/plugin_python.h not in /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/plugin_python.h make[1]: Leaving directory `/home/bunky/crossfire-1.3.0/plugin' making depend in crossedit... make[1]: Entering directory `/home/bunky/crossfire-1.3.0/crossedit' makedepend -- -g -O2 -I/usr/X11R6/include/ -I../include -I. -Iinclude -I./../include -I. -I./include -ICnv -I./Cnv -I../include -Iinclude -ICnv -I. -- crossedit.c Attr.c CrFace.c CrEdit.c CrList.c CrUtil.c Edit.c App.c Bitmaps.c Str.c xutil.c "/usr/include/assert.h":104: defined __cplusplus ? __GNUC_PREREQ (2, 6) : __GNUC_PREREQ (2, 4) ^--- expecting : (cd Cnv; make depend) make[2]: Entering directory `/home/bunky/crossfire-1.3.0/crossedit/Cnv' /usr/bin/X11/makedepend -- -I/usr/X11R6/include -I../include -I. -I../../include -- test.c CnvUtil.c CnvBrowse.c CnvNotify.c CnvMenu.c CnvFiles.c CnvPath.c CnvPrompt.c "/usr/include/assert.h":104: defined __cplusplus ? __GNUC_PREREQ (2, 6) : __GNUC_PREREQ (2, 4) ^--- expecting : make[2]: Leaving directory `/home/bunky/crossfire-1.3.0/crossedit/Cnv' make[1]: Leaving directory `/home/bunky/crossfire-1.3.0/crossedit' _______________________________________________ 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 May 30 01:19:12 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:16 2005 Subject: [CF-Devel] compile error References: <1054218281.1442.19.camel@dhcppc2> Message-ID: <000401c32673$64846a80$0802a8c0@KAMERIA> If possible (you need the 1.3.0 server specifically?) I would grab the 1.5.0 crossfire server - were lots of changes with the install think I remember including how the python plugin installs. ----- Original Message ----- From: "John Raynor" To: Sent: Thursday, May 29, 2003 10:24 AM Subject: [CF-Devel] compile error > Trying to compile crossfire from crossfire-1.3.0.tar.gz (from the > real-time ftp site), I got the error that follows. I included a few > lines before and after, but it you need more info I can send you the > whole shebang. > > I also got errors in the 'make depend' stage .. I'll include those after > this section. > > I'm running RedHat 7.3 with whatever updates I've found using the Ximian > Red Carpet updater. > > -------------------------------------------- > > gcc -g -O2 -I../include -I./../include -c time.c > gcc -g -O2 -I../include -I./../include -c timers.c > gcc -g -O2 -I../include -I./../include -c weather.c > /bin/rm -f crossfire > gcc -o crossfire alchemy.o apply.o attack.o ban.o c_chat.o c_misc.o > c_move.o c_new.o c_object.o c_party.o c_range.o c_wiz.o commands.o > daemon.o disease.o egoitem.o hiscore.o gods.o init.o login.o main.o > monster.o move.o pets.o player.o plugins.o resurrection.o rune.o shop.o > skills.o skill_util.o spell_effect.o spell_util.o swamp.o swap.o time.o > timers.o weather.o ../common/libcross.a ../random_maps/random_map.a > ../socket/socket.a -ldl -ldmalloclp -lcrypt -lm -lnsl > ../socket/socket.a(metaserver.o): In function `metaserver_update': > /home/bunky/crossfire-1.3.0/socket/metaserver.c:131: undefined reference > to `cst_tot' > /home/bunky/crossfire-1.3.0/socket/metaserver.c:131: undefined reference > to `cst_tot' > /home/bunky/crossfire-1.3.0/socket/metaserver.c:131: undefined reference > to `cst_tot' > collect2: ld returned 1 exit status > make[1]: *** [crossfire] Error 1 > make[1]: Leaving directory `/home/bunky/crossfire-1.3.0/server' > making all in include... > make[1]: Entering directory `/home/bunky/crossfire-1.3.0/include' > make[1]: Nothing to be done for `all'. > make[1]: Leaving directory `/home/bunky/crossfire-1.3.0/include' > making all in lib... > make[1]: Entering directory `/home/bunky/crossfire-1.3.0/lib' > make[1]: Nothing to be done for `all'. > > ---------------------------------------------- > > > Ok, now, in the 'make depend'. I seem to be missing plugin-python.h, > but since it was only a warning I wasn't very concerned. This did > bother me, but it seems to be unrelated since it's in crossedit. > Anyway, figured you might want to know: > > > make[1]: Entering directory `/home/bunky/crossfire-1.3.0/plugin' > /usr/bin/X11/makedepend -- -g -O2 -I../include -I./../include > -I./include -I../include -- plugin_python.c > /usr/bin/X11/makedepend: warning: plugin_python.c, line 32: cannot find > include file "plugin_python.h" > not in ../include/plugin_python.h > not in ./../include/plugin_python.h > not in ./include/plugin_python.h > not in ../include/plugin_python.h > not in /usr/local/lib/gcc-include/plugin_python.h > not in /usr/include/plugin_python.h > not in /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/plugin_python.h > make[1]: Leaving directory `/home/bunky/crossfire-1.3.0/plugin' > making depend in crossedit... > make[1]: Entering directory `/home/bunky/crossfire-1.3.0/crossedit' > makedepend -- -g -O2 -I/usr/X11R6/include/ -I../include -I. -Iinclude > -I./../include -I. -I./include -ICnv -I./Cnv -I../include -Iinclude > -ICnv -I. -- crossedit.c Attr.c CrFace.c CrEdit.c CrList.c CrUtil.c > Edit.c App.c Bitmaps.c Str.c xutil.c > "/usr/include/assert.h":104: defined __cplusplus ? __GNUC_PREREQ (2, 6) > : __GNUC_PREREQ (2, 4) > ^--- > expecting : > (cd Cnv; make depend) > make[2]: Entering directory `/home/bunky/crossfire-1.3.0/crossedit/Cnv' > /usr/bin/X11/makedepend -- -I/usr/X11R6/include -I../include -I. > -I../../include -- test.c CnvUtil.c CnvBrowse.c CnvNotify.c CnvMenu.c > CnvFiles.c CnvPath.c CnvPrompt.c > "/usr/include/assert.h":104: defined __cplusplus ? __GNUC_PREREQ (2, 6) > : __GNUC_PREREQ (2, 4) > ^--- > expecting : > make[2]: Leaving directory `/home/bunky/crossfire-1.3.0/crossedit/Cnv' > make[1]: Leaving directory `/home/bunky/crossfire-1.3.0/crossedit' > > > > _______________________________________________ > 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 May 29 17: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:16 2005 Subject: [CF-Devel] Translation request In-Reply-To: <3EAAF49C.7040404@sympatico.ca> Message-ID: On 26-Apr-03 Todd wrote: > Does any one know what *brefjell* actually means? I would like to fix > the image in the classic set since it looks odd in the hall of selection. garbled norwegian: bre = glacier, fjell = mountain http://images.google.com/images?q=tbn:ZyHWFSihPJ0C:www.hifas.no/art/DBakke/thumb nails/Brefjell.jpg It appears to be a glacier tipped fjord. --- 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 May 30 00:00:39 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:16 2005 Subject: [CF-Devel] unipart monsters In-Reply-To: <3ED07671.8060301@sympatico.ca> References: <3ED070E1.8080301@sympatico.ca> <3ED07671.8060301@sympatico.ca> Message-ID: <3ED6E577.9030604@sympatico.ca> Well, as this screenshot shows, the java editor seems to have no problem with large images. There is working windows port of the GCFClient so the DX client can finally be laid to rest (in the DX client - large creatures don't show up properly on the map window, but they do run around the interface border and in the 'look below window' - is funny). It certainly is a heck of a lot faster testing graphics and animations with large images. So...I propose a state of intention that large images are going to be phased in - not a time line or anything, there are still things to work out obviously, but an intent that this is going to happen and that any new clients or top secret 'special advanced DM live builder' clients* or what not being developed should be prepared to use them. I am not sure all what is involved in moving to unipart monsters as the standard, but I can only imagine that it would make things somewhat easier in the server code as well (no?). It does look pretty friggin cool at times as well, especially when the overlap is working as expected. The monsters have more presence - seem larger somehow when they can overlap the wall or water in the tile above them. I am not so sure about the horizontal overlap thing, but the vertical is way nice. Anyway I didn't see anything about this in the TODO. Actually maybe posting up the TODO and going over it to re-evaluate what's new, what's near, whats not even on the map and what is probably not going to happen might be fun. (note these dragons in the picture are test creatures - not new additions) *there is no such thing - really. -------------- next part -------------- A non-text attachment was scrubbed... Name: bigtile_in_jEd.png Type: image/png Size: 28086 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030530/f2f8b295/bigtile_in_jEd.png From crossfire-devel-admin at archives.real-time.com Fri May 30 04:19:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:16 2005 Subject: [CF-Devel] unipart monsters References: <3ED6E577.9030604@sympatico.ca> Message-ID: <20964.1054286366@www27.gmx.net> Todd wrote: > Well, as this screenshot shows, the java editor seems to have no > problem with large images. Yes the JavaEditor can handle large images. That's mostly because Daimonin already uses unipart images. Sidenote: These dragons look nice, but they are ripped from Ultima Online, aren't they? Anyways, I know you said they are just for testing. > There is working windows port of the GCFClient so the DX client > can finally be laid to rest. It's great to have a new working windows client. :-) Now if we also had a CF server on windows that would be perfect. I'm not sure on this, but since the CF server uses no multimeadia stuff (graphics/sound/etc) it might not be too hard to make it compatible, or would it be? We already had a ported version once... Would anyone be interested in trying to compile the CF server on windows? Back to the unipart image topic... Since I'm drawing myself sometimes, I'm all for going in the unipart image direction. However, like Todd indicated, that doesn't mean we have to switch today. We can do it step-by-step maybe. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ 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 May 30 21:56:53 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:16 2005 Subject: [CF-Devel] unipart monsters References: <3ED6E577.9030604@sympatico.ca> <20964.1054286366@www27.gmx.net> Message-ID: <001201c32725$004c9d00$0802a8c0@KAMERIA> > Sidenote: These dragons look nice, but they are ripped from > Ultima Online, aren't they? Anyways, I know you said they are just > for testing. Yes these are not going in to the game, but I was planning on using their geneticly altered 'decendants'. I never played Ultima online actually, this dragon I found on a website called Tasty Dead and it was classified as public domain, but I did suspect it was ripped off from somewhere. I have been chopping it up for hamburger but was not going to use it in the game for this reason. I did find it convient for testing however since it was nearly the right proportions already (very close to 96x96). Now as for using them in a *highly* modified form (much more clearly original than say the behemoth, the giant worm or the electric dragon), I was planning to do this --- I do mean *highly* modified. I am not interested in stealing images, but I am interested in creating new images from other images since I can't draw worth beans. You can see what I have been doing with the player animations or the cyclops or the classic ent image - an arm here, a head there...all much modified form existing crossfire graphics. Where is the acceptable (not the more narrow legal definition - but the wider, tastefully acceptable definition) line here? I'm trying for the tasteful path and so far (have added a boatload of graphics this last year...) I think it's being borne out that I am not a hooligan with poor taste and questionable motives. I think. > Would anyone be interested in trying to compile the CF server on windows? > I thought it did already, no? > Back to the unipart image topic... > Since I'm drawing myself sometimes, I'm all for going in the > unipart image direction. However, like Todd indicated, that doesn't > mean we have to switch today. We can do it step-by-step maybe. I think that some environmental considerations have to be decided on, It isn't such an issue to allow overlap in the tiles above, but should they overlap hrizontally? How much of afootprint does a 4x4 creature take up. I would say it should take up two tiles, but currently it is only one...When I have played with these images I have used a single part arch as well as a single tile, is this the correct method, or should the arch still have a part (minus the face information) for each tile the image covers? Also how many maps will break if the footprint rules change. This will not be something that can be fixed by script I think - think of the all the trolls and behemoths and dreads and dragons who will start sliding out of doorways. Perhaps this should wait until new doors are developed... (hey I did some horizontal doors - anyone have vertical ones lying around?) _______________________________________________ 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 May 30 10:38:50 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:16 2005 Subject: [CF-Devel] bug with style maps In-Reply-To: <3ED2AA4C.6080707@sonic.net> Message-ID: In the loader.l, there is the speed command where are objects excluded with MAP_STYLE macro from adjusting the object speed and putting it on the active list. But when the command "arch" is read in, the object is loaded from arch and the copied with copy_object(). But copy object put the object too on the active list (and speed_left is manipulated). So, all objects with speed in arches will come to active list when a style map is loaded - and every random map use style maps... I cloned copy_objec() and called it copy_object_data() - from it i removed the speed stuff include the update_speed(). I used this command in arch_parse from arch.c and in the loader.l. _______________________________________________ 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 May 31 11:38:45 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:16 2005 Subject: [CF-Devel] unipart monsters References: <001201c32725$004c9d00$0802a8c0@KAMERIA> Message-ID: <5255.1054399125@www50.gmx.net> Todd Mitchell wrote: > > Sidenote: These dragons look nice, but they are ripped from > > Ultima Online, aren't they? Anyways, I know you said they are just > > for testing. > > Yes these are not going in to the game, but I was planning on using > their geneticly altered 'decendants'. [...] Now as for using them in > a *highly* modified form (much more clearly original than say > the behemoth, the giant worm or the electric dragon), That's a good argument. *grin* :-) Well, when copying or "modelling" from others, the most important question is: Who is the copyright holder. For the electric dragon I have used a model which is a scanned painting. I have honestly tried to contact the author, but up to date I've been unable to figure out who the author is. It is not a professional drawing however - and there's no company behind it. Moreover, when taking the original image and scaling it down, you will notice that there is not one pixel actually matching with our dragon. I have redrawn all the detailwork by hand, including head, wings, feet and tail. We can safely use this image unless the original author turns up and tells us otherwise. Admittedly, the giant worm is not equally safe to use. It's ripped from final fantasy 2, a very old console game. In fact, you are right about this one and I'm not confident about the status of the image either. I do want to replace the image, but didn't manage to draw a worthy successor yet. The behemoth is not from me, I have no idea where it comes from. All other images I've drawn are 100% originals, with a possible exception of the medium demon which is based on a model of unknown origin. All that being said, you may call me picky for pointing out that your dragon was ripped. However, Ultima Online is a game which is still selling, and there is a big active company behind it. > I was planning to do this --- I do mean *highly* modified. I am > not interested in stealing images, but I am interested in creating > new images from other images since I can't draw worth beans. Yeah, I know your motives are honorable, and in fact I've been feeling exactly the same way in the past. What drove me away from using models for my own drawings in CF is that I was unsatisfied with the results. The size and perspecive almost never fits. And then you always have this bad aftertaste that the image isn't really yours. Those of my drawings which I personally like best are exactly the ones that I drew from scratch. It is more work indeed, but given the time, it's not as hard as I had expected. The truth is, I can't draw worth beans either. > [...] I'm trying for the tasteful path and so far (have added > a boatload of graphics this last year...) I think it's being > borne out that I am not a hooligan with poor taste and > questionable motives. I think. I really didn't mean to criticise your drawing skills or motives. You've drawn a ton of images, and most if them are great. I love the player animations for example. Please don't feel discouraged. Keep up the good work. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ 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 May 31 13:09:53 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:16 2005 Subject: [CF-Devel] unipart monsters In-Reply-To: <5255.1054399125@www50.gmx.net> References: <001201c32725$004c9d00$0802a8c0@KAMERIA> <5255.1054399125@www50.gmx.net> Message-ID: <3ED8EFF1.9010102@sympatico.ca> > > > >The behemoth is not from me, I have no idea where it comes from. >All other images I've drawn are 100% originals, with a possible >exception of the medium demon which is based on a model of >unknown origin. > > > The behemoth is from Titan - an Avalon Hill boardgame of great joy and renown. You may actually be particuarily interested in a java version of the game called Colossus (http://colossus.sourceforge.net) which is my second favorite opensource java application.... >All that being said, you may call me picky for pointing out >that your dragon was ripped. However, Ultima Online is a game >which is still selling, and there is a big active company behind it. > Actually I dont' mind - really. I was glad to know where the image was taken from. Explains why the size and perspective is so close. I was not going to use this image as initially mentioned, but I did use it to make an outline of the image for the shadowdragon arch and was hoping to use that. The profile and the wings were tempted me into a tracing experiment. I my reply was more interested in some actual feedback on what constituted good taste in the game as opposed to legal obligation. I supose the roundabout way I was making this point could be considered defensive, but I was trying to say I am acting in good faith, not trying to sneak in a hot dragon picture. >I really didn't mean to criticise your drawing skills or >motives. You've drawn a ton of images, and most if them are great. >I love the player animations for example. >Please don't feel discouraged. Keep up the good work. > Actually I didn't point out those specific animations because you did them (I didn't look up the creators actually), but because they were suspect. This is probably the best argument of all - if it looks like it came from somewhere else it probably did - even if it is totally ok rights wise - it don't really fit in. I gratefully notice you didn't mention anything about giant rodents either... I do know of which you speak. _______________________________________________ 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 May 31 12:33:43 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:17 2005 Subject: [CF-Devel] unipart monsters In-Reply-To: <5255.1054399125@www50.gmx.net> References: <001201c32725$004c9d00$0802a8c0@KAMERIA> <5255.1054399125@www50.gmx.net> Message-ID: <20030531173342.GA17864@crystal> On Sat, May 31, 2003 at 06:38:45PM +0200, Andreas Vogl wrote: [snip] > Admittedly, the giant worm is not equally safe to use. It's ripped from > final fantasy 2, a very old console game. In fact, you are right about > this one and I'm not confident about the status of the image either. > I do want to replace the image, but didn't manage to draw a worthy > successor yet. The giant worm image looks good... I'd be hard-pressed to draw another one of similar quality! > All other images I've drawn are 100% originals, with a possible > exception of the medium demon which is based on a model of > unknown origin. [snip] Are you referring to the 2x2 demon? The alternate set 2x2 demon is drawn by me, BTW... which was adapted from PeterM's greated demon. The standard set 2x2 demon looks like just a perspective edit of it. T -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel