From kbulgrien at worldnet.att.net Mon Dec 10 07:28:49 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Mon, 10 Dec 2007 07:28:49 -0600 Subject: [crossfire] Arch repository: layered art files? Message-ID: <200712100728.50164.kbulgrien@worldnet.att.net> While working on a couple new graphics (based on existing ones), I made heavy use of layers. I could grab elements from other arch tiles, put them on a layer (reuse), and then use layers to add unique features. In one case, I drew a tile from scratch, but used layers to hold particular components of the tile so that it was easy to rework different aspects of the tile... especially those involving curves, filters, randomness, etc. Putting only the .png in SVN feels like putting a pre-compiled object into the repository... useful... but... not exactly conducive to facilitating any type of rework. Does anyone else think that putting the source files into SVN is a good idea, or just extra clutter? I realize, for example, my source files are likely GIMP-specific, and I suppose each artist's favorite editor uses a different format. That might be the biggest obstacle. The next, perhaps, that artists come few and far between, so the likelihood of actual use may be very low, Beyond that, if it seems a good idea to various people, what file format preferences are out there? Kevin From mwedel at sonic.net Tue Dec 11 00:35:50 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 10 Dec 2007 22:35:50 -0800 Subject: [crossfire] Arch repository: layered art files? In-Reply-To: <200712100728.50164.kbulgrien@worldnet.att.net> References: <200712100728.50164.kbulgrien@worldnet.att.net> Message-ID: <475E2FC6.10307@sonic.net> Kevin R. Bulgrien wrote: > Does anyone else think that putting the source files into SVN is a good idea, > or just extra clutter? I realize, for example, my source files are likely > GIMP-specific, and I suppose each artist's favorite editor uses a different > format. That might be the biggest obstacle. The next, perhaps, that artists > come few and far between, so the likelihood of actual use may be very low, > > Beyond that, if it seems a good idea to various people, what file format > preferences are out there? Putting the source files in their seems reasonable to me. I think this was done in the past when some folks where using 3d models for make some objects, and put the source 3d files into the repository. I'd also say that putting in the gimp .xcf files might be the best standard. I know that is what I use when editing images - and I suspect that is probably what most people, at least those using a unixy type system, probably use. The other thing is that it is freely available and crossplatform - you can get gimp for windows and macos. There may be other applications with similar features - in fact, I'm sure there are, but they probably are not as standard. From mwedel at sonic.net Tue Dec 11 02:13:57 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 11 Dec 2007 00:13:57 -0800 Subject: [crossfire] combat notes In-Reply-To: <4750E794.6030305@sonic.net> References: <474D280F.3060807@sonic.net> <474FC7AE.6010801@sonic.net> <200711300638.27697.kbulgrien@worldnet.att.net> <4750E794.6030305@sonic.net> Message-ID: <475E46C5.8090102@sonic.net> So I did some more tweaks. I made a quick change so that some of the generators only make 5 monsters and then disappear (I'll have to commit that change) works pretty good - I didn't try many places, but in the few I did, that is enough to bulk up the monsters in the area to respectable level. I also have not reduced the exp for generators. So from a pure standpoint, if you're tough enough, you'll get more exp by rushing in and killing the generators than waiting for all the monsters to pop out. But this is on a time basis - a generator may be worth 2-3 times as much exp as the monsters it produce - the main point is that you can kill a generator in about the same time as it takes to kill a monster, so if you can get to them, you're exp gain rate is faster. By them disappearing when they are used up, it removes some exp source from the game. I think that is a good improvement - you can't camp out killing monsters forever, and if the monster is a good challenge, eventually you can kill all of them and make it to the next room. So I'm tempted to make that a default. IMO, making that change is really only effective if it becomes the default for archetypes, as going through all the maps by hand and fixing it would be very time consuming. OTOH, some maps certainly would need to get adjusted manually - things like training centers which are supposed to have unlimited monsters. From tchize at gmail.com Tue Dec 11 07:32:18 2007 From: tchize at gmail.com (David Delbecq) Date: Tue, 11 Dec 2007 14:32:18 +0100 Subject: [crossfire] combat notes In-Reply-To: <475E46C5.8090102@sonic.net> References: <474D280F.3060807@sonic.net> <474FC7AE.6010801@sonic.net> <200711300638.27697.kbulgrien@worldnet.att.net> <4750E794.6030305@sonic.net> <475E46C5.8090102@sonic.net> Message-ID: <475E9162.8010105@gmail.com> En l'instant pr?cis du 11/12/07 09:13, Mark Wedel s'exprimait en ces termes: > you can't camp out killing > monsters forever, and if the monster is a good challenge, eventually you can > kill all of them and make it to the next room. > That good imho > things like training centers > which are supposed to have unlimited monsters. > > That bad, if you want to remove map camping, sorry but there must be a way to avoid it also in training maps. Tranings maps concept is a "buy XP" concept that should be removed from game as is. Having generators disappear in training room is not that bad, that will for players to enter real dungeons :) Btw: did you ever asked your self *how* the training center could have such a delivery of monster, it's not like they are easy to find, but maybe closing training center will mean there will be less npc hunter that catches wild monster, and means ther will be wild monster in bigworld outdoor? :D > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From tchize at gmail.com Tue Dec 11 07:36:33 2007 From: tchize at gmail.com (David Delbecq) Date: Tue, 11 Dec 2007 14:36:33 +0100 Subject: [crossfire] Arch repository: layered art files? In-Reply-To: <200712100728.50164.kbulgrien@worldnet.att.net> References: <200712100728.50164.kbulgrien@worldnet.att.net> Message-ID: <475E9261.7080505@gmail.com> Agree with you, thought most my pictures i submitted to cf where direct pixel art-> no layers :) For the motivated ones, another possibility is to put a source .svg file. We could even have the build process convert them to png :p Inkscape is a good vectorial editor that is also crossplatform. The interrest of vectorial graphic can be limited for arch files, but can be veryuseful for icon making for clients (resizeable icons). Think about it artists :D En l'instant pr?cis du 10/12/07 14:28, Kevin R. Bulgrien s'exprimait en ces termes: > While working on a couple new graphics (based on existing ones), I made heavy > use of layers. I could grab elements from other arch tiles, put them on a > layer (reuse), and then use layers to add unique features. > > In one case, I drew a tile from scratch, but used layers to hold particular > components of the tile so that it was easy to rework different aspects of > the tile... especially those involving curves, filters, randomness, etc. > > Putting only the .png in SVN feels like putting a pre-compiled object into > the repository... useful... but... not exactly conducive to facilitating any > type of rework. > > Does anyone else think that putting the source files into SVN is a good idea, > or just extra clutter? I realize, for example, my source files are likely > GIMP-specific, and I suppose each artist's favorite editor uses a different > format. That might be the biggest obstacle. The next, perhaps, that artists > come few and far between, so the likelihood of actual use may be very low, > > Beyond that, if it seems a good idea to various people, what file format > preferences are out there? > > Kevin > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From juhaj at iki.fi Tue Dec 11 08:08:32 2007 From: juhaj at iki.fi (Juha =?utf-8?q?J=C3=A4ykk=C3=A4?=) Date: Tue, 11 Dec 2007 16:08:32 +0200 Subject: [crossfire] combat notes In-Reply-To: <475E9162.8010105@gmail.com> References: <474D280F.3060807@sonic.net> <475E46C5.8090102@sonic.net> <475E9162.8010105@gmail.com> Message-ID: <200712111608.33166.juhaj@iki.fi> > mean there will be less npc hunter > that catches wild monster, and means ther will be wild monster in > bigworld outdoor? :D Hey! This is a wonderful idea: training centers must be filled by players. For a price, of course. Put big notices in central Scorn (and other cities): "TCI will pay 5 gold for a goblin, 10 gold for an ogre etc upon delivery to the relevant TCI installation." Something like this is already done with guilds' second floor which need a Spectre to "open", so the functionality definitely is there. All that needs to be added is a persistent repository of monsters and the "monster-for-money" -exchange facility. No need for generators and easy way to make some little money if you know how to bring about big numbers of monsters. There might even be some monster infestations here and there around bigworld and some NPCs hunting them. A totally autonomous bot might be too difficult to code, but if the infested areas do not move around (which they optimally should!), the bot could just walk from TCI to infestation, charm some goblins and walk back with them. That would add some depth to the world. -Juha From crossfire at ailesse.com Wed Dec 12 04:36:42 2007 From: crossfire at ailesse.com (Lauwenmark Akkendrittae) Date: Wed, 12 Dec 2007 11:36:42 +0100 Subject: [crossfire] Arch repository: layered art files? In-Reply-To: <200712100728.50164.kbulgrien@worldnet.att.net> References: <200712100728.50164.kbulgrien@worldnet.att.net> Message-ID: <200712121136.48735.crossfire@ailesse.com> Le lundi 10 d?cembre 2007, Kevin R. Bulgrien a ?crit : > Does anyone else think that putting the source files into SVN is a good > idea, or just extra clutter? Sounds like a good idea. > I realize, for example, my source files are > likely GIMP-specific, and I suppose each artist's favorite editor uses a > different format. That might be the biggest obstacle. The next, perhaps, > that artists come few and far between, so the likelihood of actual use may > be very low, > > Beyond that, if it seems a good idea to various people, what file format > preferences are out there? > The Gimp's xcf is a good contender. However, it is also true that there are many artists who are using Photoshop, Painter, or Open Canvas; so I'd suggest not defining any specific file format, and let each artist use whatever he prefers. Maybe it would be nice to put those elsewhere than in the arch subdir, so that artists who wouldn't require the rest can only download those, and non-artists can grab the arches without the (possibly heavy) graphic "source" files that would be of no use for them ? Lauwenmark. ------------ "Drive defensively: buy a tank." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20071212/48100fa3/attachment.pgp From nicolas.weeger at laposte.net Wed Dec 12 16:56:42 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 12 Dec 2007 23:56:42 +0100 Subject: [crossfire] Arch repository: layered art files? In-Reply-To: <200712121136.48735.crossfire@ailesse.com> References: <200712100728.50164.kbulgrien@worldnet.att.net> <200712121136.48735.crossfire@ailesse.com> Message-ID: <200712122356.47714.nicolas.weeger@laposte.net> > > Does anyone else think that putting the source files into SVN is a good > > idea, or just extra clutter? > > Sounds like a good idea. Agreed on that. Having all the sources is nice, and makes it easier to fix things later on :) > The Gimp's xcf is a good contender. However, it is also true that there are > many artists who are using Photoshop, Painter, or Open Canvas; so I'd > suggest not defining any specific file format, and let each artist use > whatever he prefers. Agreed, many formats can be used. Of course open formats should be encouraged when possible :) > Maybe it would be nice to put those elsewhere than in the arch subdir, so > that artists who wouldn't require the rest can only download those, and > non-artists can grab the arches without the (possibly heavy) graphic > "source" files that would be of no use for them ? Agreed on that too, maybe put in a arch_src tree duplicating the arch structure? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20071212/fe5bcf91/attachment.pgp From mwedel at sonic.net Wed Dec 12 23:22:39 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 12 Dec 2007 21:22:39 -0800 Subject: [crossfire] Arch repository: layered art files? In-Reply-To: <200712122356.47714.nicolas.weeger@laposte.net> References: <200712100728.50164.kbulgrien@worldnet.att.net> <200712121136.48735.crossfire@ailesse.com> <200712122356.47714.nicolas.weeger@laposte.net> Message-ID: <4760C19F.4010101@sonic.net> Nicolas Weeger wrote: >> The Gimp's xcf is a good contender. However, it is also true that there are >> many artists who are using Photoshop, Painter, or Open Canvas; so I'd >> suggest not defining any specific file format, and let each artist use >> whatever he prefers. > > Agreed, many formats can be used. Of course open formats should be encouraged > when possible :) I'm a bit less sure if having a bunch of formats sitting about in the arch directory would be a good thing. A concern I have is of formats which no one can easily use, and there is not certainty if anyone in fact is still using those images (hypothetical case here is someone adds some new images in some image format, and then disappears from the crossfire world. Two years later ability for anyone else to read the originals may be gone, and not certain if anyone would care if they were removed). Having everyone use a same format may not work. But at the same time, if the format being used is obscure enough that only that single developer uses it, having that source checked in really gains nothing. As a compromise, I'd suggest that in principal, any format may be allowed, but has to be approved/discussed on a case by case basis. For fairly popular formats or programs, that should pretty much be a rubber stamp. But if someone pops up and wants to add a format no one has ever heard of, answer is probably no. Last note would be licensing - I don't know if it would be an issue or not, but crossfire is GPL, and thus all files so checked in must be comformant with that license. If adobe or other software has restrictions on what can be done with the data files, etc, that would be another reason to disallow software (an example could be the file format itself is patented, and thus freely redistributing files in that format requires some licensing or permission) > >> Maybe it would be nice to put those elsewhere than in the arch subdir, so >> that artists who wouldn't require the rest can only download those, and >> non-artists can grab the arches without the (possibly heavy) graphic >> "source" files that would be of no use for them ? > > Agreed on that too, maybe put in a arch_src tree duplicating the arch > structure? I guess it depends on the size of the source files. In practical terms, unless they change often, there is just a one time cost to download them in the initial checkout. For the official arch distributions, they should likely be stripped out. Before having them in a different area (which is likely to cause headaches folks actually using those images), I'd be more interested in seeing size and the impact that has. My concern here is syncrhonization and/or conflicting updates. For example, developers make gimp image of monsters. .xcf file is in arch_src/monster/..., and artist wrote out the png in the expected place. Someone at a later point makes some adjustments, perhaps quite minor, to the monster. Maybe not aware, they edit the png file directly. Now if someones goes back to the xcf and makes a new png, those previous changes are lost. I think this is much more likely to happen if the source files are in some other repostory. If I see monster.111.png and monster.111.xcf in the same directory, that should be clue enough. But this also leads into another question - how do we handle cases where the source file is in a format that the end user doesn't have? Lets suppose in that case above, instead of the source being gimp, it is adobe photoshop. I don't have any way to edit that. But I want to make a change to that monster. Do I just modify the png? I'd also note that I could certainly see with layering, etc, that there may be some number of source image files that do not have any clear association with an archetype (generic images for example). In that case, they should probably also go in some directory in the arch tree just for that purpose - misc_images or something. From mwedel at sonic.net Thu Dec 13 01:49:06 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 12 Dec 2007 23:49:06 -0800 Subject: [crossfire] combat notes In-Reply-To: <475E9162.8010105@gmail.com> References: <474D280F.3060807@sonic.net> <474FC7AE.6010801@sonic.net> <200711300638.27697.kbulgrien@worldnet.att.net> <4750E794.6030305@sonic.net> <475E46C5.8090102@sonic.net> <475E9162.8010105@gmail.com> Message-ID: <4760E3F2.8040105@sonic.net> To some extent, the rebalancing of monsters may eliminate the need for training centers. One thing I noticed when going through and fixing up the monsters is that the exp rewards for monsters were all over the place. One monster may be worth a lot, and another, of similar difficulty, worth just a fraction of that other one. This certainly lead to there being some monsters which are good to kill for exp, and others which were not so good. I have a feeling that the training centers for the most part took monsters on the high end of exp reward. With the monsters better balanced, it should be easier to find monsters of appropriate challenge and reward in the various maps. While I agree the ecology of training centers probably do not make much sense, there is an overall lack of ecology in game. Where is all that iron for weapons coming from (there really are not any iron mines). How do the 50 orcs live in the newbie tower with no food? Why do maps reset in the first place? I have no problems changing things so they do make sense, but we do have to keep in mind that crossfire is a game, and not a whole work simulation, so some things probably do not make sense. From tchize at gmail.com Thu Dec 13 01:26:37 2007 From: tchize at gmail.com (David Delbecq) Date: Thu, 13 Dec 2007 08:26:37 +0100 Subject: [crossfire] Arch repository: layered art files? In-Reply-To: <4760C19F.4010101@sonic.net> References: <200712100728.50164.kbulgrien@worldnet.att.net> <200712121136.48735.crossfire@ailesse.com> <200712122356.47714.nicolas.weeger@laposte.net> <4760C19F.4010101@sonic.net> Message-ID: <4760DEAD.8040901@gmail.com> En l'instant pr?cis du 13/12/07 06:22, Mark Wedel s'exprimait en ces termes: > > > I'm a bit less sure if having a bunch of formats sitting about in the arch > directory would be a good thing. A concern I have is of formats which no one > can easily use, and there is not certainty if anyone in fact is still using > those images (hypothetical case here is someone adds some new images in some > image format, and then disappears from the crossfire world. Two years later > ability for anyone else to read the originals may be gone, and not certain if > anyone would care if they were removed). > Well, either someone change that arch in future without being able to open source format, then he removes the old source file (eg caril draw 69.2.0.44) and provide his own one (gimp) matching the new arch picture. Then the old format disappear by itself from repository. Since svn handles deletion of files/directory properly, this is not a problem. Either no one change the arch, then i see no problem with keeping the source file. It's in accordance to GPL (you know, the provide source section) and maybe that guy will come 2 years later to redo some of his art work :D > Having everyone use a same format may not work. But at the same time, if the > format being used is obscure enough that only that single developer uses it, > having that source checked in really gains nothing. > But it cost nothing too, if we keep sopurce arch in a separate folder. When you want to edit arch monsters/kobold_111.png, you just have to list content of svn repository src/arch/monsters and checkout the source file you need. > As a compromise, I'd suggest that in principal, any format may be allowed, but > has to be approved/discussed on a case by case basis. For fairly popular > formats or programs, that should pretty much be a rubber stamp. But if someone > pops up and wants to add a format no one has ever heard of, answer is probably no. > Do we have yet a formal general approval process? If yes am ok with it, if no, that would just mean the commiter will have final word. > Last note would be licensing - I don't know if it would be an issue or not, > but crossfire is GPL, and thus all files so checked in must be comformant with > that license. If adobe or other software has restrictions on what can be done > with the data files, etc, that would be another reason to disallow software (an > example could be the file format itself is patented, and thus freely > redistributing files in that format requires some licensing or permission) Am not aware of such restriction. What you produce with a tool, in europe, afaik, can not subject to conditions coming from tool itself. The only problem i might see is general scurity and exportation laws, that could restrict distribution of a format that uses heavy cryptography but a crypted file in src is useless :) The licensing rules of a format (patents, etc) apply to algorithms uses to create / read that format, that mean someone might be required to acquire a commercial software to open the source file, but that's hardly agains the gpl license. From subs at eracc.com Thu Dec 13 14:11:56 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Thu, 13 Dec 2007 14:11:56 -0600 Subject: [crossfire] combat notes In-Reply-To: <4760E3F2.8040105@sonic.net> References: <474D280F.3060807@sonic.net> <475E9162.8010105@gmail.com> <4760E3F2.8040105@sonic.net> Message-ID: <200712131411.57709.subs@eracc.com> On Thursday 13 December 2007 Mark Wedel wrote: > While I agree the ecology of training centers probably do not make much > sense, there is an overall lack of ecology in game. ?Where is all that iron > for weapons coming from (there really are not any iron mines). ?How do the > 50 orcs live in the newbie tower with no food? ?Why do maps reset in the > first place? I have been cogitating on the map reset issue. Mainly we have maps resetting because at the time that was done someone could not come up with a better way of making an area usable again after someone else had cleaned it out. For my part I think once you kill the Zorn family how would they arise from the dead? Well, the players do (at least they do on non-permanent death servers) so the NPCs do as well. Currently to do this we have maps reset all at once (if no one visits them for ## amount of time) back to a pristine state. Perhaps a method could be used to have them gradually reset back to the pristine state. Of course this would take a lot more resources on the server as the maps could not be gradually resetting while swapped out. Maybe to mitigate this a resetting daemon could run and load + check each swapped map every X seconds (tunable by the server owner) and manage the gradual reset then swap each map back out. This daemon would have a referent of the original map and use some smart programmer's algorithm to gradually clean it up and re-add the NPCs while no players are on it. If a player comes to the partially redone map and messes it up again no big deal as the daemon will use the same process to start gradually cleaning the map again once the player leaves. (I am not the smart programmer that can do this, but perhaps this idea can be a starting point for one of you who is a smart programmer :) ). Also, quest rewards are in specific maps. Perhaps having a reward generator that can be tied to specific NPCs, altars or whatever would help. That could also be done with forces and inventory checker. Have force A, B and C but not D, E and F? You have halfway done with the quest. Once finished and going over the inventory checker that triggers the reward the forces are removed and the reward is generated. This means quests will need more thought and effort on the part of the persons making quests. However, I think this is worth a little more thought and effort. I am toying with doing this in the Zorn scrolls quest that will be beneath the Zorn dungeon. IMO forces and inventory checkers are under-utilized in crossfire. Gene Alexander -- ERA Computers & Consulting Preloaded computers - eComStation, Linux and Unix Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From mwedel at sonic.net Thu Dec 13 23:20:57 2007 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 13 Dec 2007 21:20:57 -0800 Subject: [crossfire] Arch repository: layered art files? In-Reply-To: <4760DEAD.8040901@gmail.com> References: <200712100728.50164.kbulgrien@worldnet.att.net> <200712121136.48735.crossfire@ailesse.com> <200712122356.47714.nicolas.weeger@laposte.net> <4760C19F.4010101@sonic.net> <4760DEAD.8040901@gmail.com> Message-ID: <476212B9.6070001@sonic.net> David Delbecq wrote: > En l'instant pr?cis du 13/12/07 06:22, Mark Wedel s'exprimait en ces > termes: >> >> I'm a bit less sure if having a bunch of formats sitting about in the arch >> directory would be a good thing. A concern I have is of formats which no one >> can easily use, and there is not certainty if anyone in fact is still using >> those images (hypothetical case here is someone adds some new images in some >> image format, and then disappears from the crossfire world. Two years later >> ability for anyone else to read the originals may be gone, and not certain if >> anyone would care if they were removed). >> > Well, either someone change that arch in future without being able to > open source format, then he removes the old source file (eg caril draw > 69.2.0.44) and provide his own one (gimp) matching the new arch picture. > Then the old format disappear by itself from repository. Since svn > handles deletion of files/directory properly, this is not a problem. > Either no one change the arch, then i see no problem with keeping the > source file. It's in accordance to GPL (you know, the provide source > section) and maybe that guy will come 2 years later to redo some of his > art work :D Fair enough. But suppose someone checks something in using adobe photoshop format, and a month later I want to change the image, but don't have photoshop. Is it OK then for me to remove the original (source) photoshop image and just have a PNG? Even if the original author is still around, maybe he doesn't have time to make the change in the near future. I don't really mean belabor this point, but it is something that is going to come up. The person that did the photoshop image may be upset that his source has been removed, but the person making the change didn't really have much choice. Now it may be that the answer is simply 'if the original artist is unable to make the change, no matter the reason, that the source file gets removed' is the rule, and I'd be fine with that. But we just need to state that upfront so no one is surprised. And gimp's .xcf files are another odd case here. Pretty much every linux distro will have gimp, but folks using windows or mac would need to download it. Should it be considered proper that the mac/windows person download gimp and update the .xcf file, or is it ok for them to just write out a png and remove the .xcf source? >> Having everyone use a same format may not work. But at the same time, if the >> format being used is obscure enough that only that single developer uses it, >> having that source checked in really gains nothing. >> > But it cost nothing too, if we keep sopurce arch in a separate folder. > When you want to edit arch monsters/kobold_111.png, you just have to > list content of svn repository src/arch/monsters and checkout the source > file you need. Disagree - it costs something here. I'm not really concerned about the space - that is trivial. But more the case of whenever I want to modify an png file, these are potential steps: 1) Check to see if the is a 'source' version of that file in the other repository. 2) If so, is it a format I can currently read & write? 3) If not, is it in a format I can easily get a program that can read/write it (or maybe we don't care about this, depending on comment above) 4) If can't get software & can't write it, now need to remove it from repository Now all that looks fairly trivial. But if things got to the point where there was a dozen different formats out there, and there was some change you wanted to make to a bunch of image (lets take layering/animation - maybe you want to add an bow layer to a bunch of monsters), that could start to get annoying. OTOH, it could just be left as a free for all. images are not changing that much, and you can always pull out old versions if someone overwrote a png you modified because they used the source that you weren't able to edit. >> As a compromise, I'd suggest that in principal, any format may be allowed, but >> has to be approved/discussed on a case by case basis. For fairly popular >> formats or programs, that should pretty much be a rubber stamp. But if someone >> pops up and wants to add a format no one has ever heard of, answer is probably no. >> > Do we have yet a formal general approval process? If yes am ok with it, > if no, that would just mean the commiter will have final word. I'd think in most cases, it would be fairly clear cut. Everyone readily agreed to gimp .xcf If the quick vote is less clear cut, a more formal vote like has been done in the past could be done. Note that inability to commit the source image files is unlikely to be a time sensitive issue - you could still commit the png files generated from them, so if it just turned out it was a few weeks before you could commit the source files, not likely an issue. And depending on what we decide in terms of image formats that users can't read, I'd guess that would clarify voting. For example, if the rule is something like 'if you don't have the program to deal with the source image, just update the png and delete the source image', I have a feeling most formats would quickly get accepted - I'd have no problems letting photoshop images be committed in that case, as it doesn't affect me much - just means I have to svn delete the source each time I modify an image. >> Last note would be licensing - I don't know if it would be an issue or not, >> but crossfire is GPL, and thus all files so checked in must be comformant with >> that license. If adobe or other software has restrictions on what can be done >> with the data files, etc, that would be another reason to disallow software (an >> example could be the file format itself is patented, and thus freely >> redistributing files in that format requires some licensing or permission) > Am not aware of such restriction. What you produce with a tool, in > europe, afaik, can not subject to conditions coming from tool itself. > The only problem i might see is general scurity and exportation laws, > that could restrict distribution of a format that uses heavy > cryptography but a crypted file in src is useless :) The licensing rules > of a format (patents, etc) apply to algorithms uses to create / read > that format, that mean someone might be required to acquire a commercial > software to open the source file, but that's hardly agains the gpl license. I wasn't sure on that one. I'd tend to guess images formats that are patented are less likely to be readable in other programs, but that isn't as much an issue. From agschult at ucalgary.ca Thu Dec 13 23:47:50 2007 From: agschult at ucalgary.ca (Alex Schultz) Date: Thu, 13 Dec 2007 22:47:50 -0700 Subject: [crossfire] Arch repository: layered art files? In-Reply-To: <476212B9.6070001@sonic.net> References: <200712100728.50164.kbulgrien@worldnet.att.net> <200712121136.48735.crossfire@ailesse.com> <200712122356.47714.nicolas.weeger@laposte.net> <4760C19F.4010101@sonic.net> <4760DEAD.8040901@gmail.com> <476212B9.6070001@sonic.net> Message-ID: <20071213224750.433fba0e@alzerion> On Thu, 13 Dec 2007 21:20:57 -0800 Mark Wedel wrote: > Fair enough. But suppose someone checks something in using adobe > photoshop format, and a month later I want to change the image, but > don't have photoshop. Well, just a note: In the case of the adobe photoshop format, at least with regards to layers and most layer types, GIMP is able to handle reading/writing photoshop files. So long as nothing fancy is going on it should be fine. Alex Schultz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20071213/57c02ef8/attachment.pgp From tchize at gmail.com Fri Dec 14 03:54:17 2007 From: tchize at gmail.com (David Delbecq) Date: Fri, 14 Dec 2007 10:54:17 +0100 Subject: [crossfire] Arch repository: layered art files? In-Reply-To: <476212B9.6070001@sonic.net> References: <200712100728.50164.kbulgrien@worldnet.att.net> <200712121136.48735.crossfire@ailesse.com> <200712122356.47714.nicolas.weeger@laposte.net> <4760C19F.4010101@sonic.net> <4760DEAD.8040901@gmail.com> <476212B9.6070001@sonic.net> Message-ID: <476252C9.8000201@gmail.com> En l'instant pr?cis du 14/12/07 06:20, Mark Wedel s'exprimait en ces termes: > Fair enough. But suppose someone checks something in using adobe photoshop > format, and a month later I want to change the image, but don't have photoshop. > > Is it OK then for me to remove the original (source) photoshop image and just > have a PNG? Even if the original author is still around, maybe he doesn't have > time to make the change in the near future. > Well, you can't open the photoshop file, you remake a file using, example, gimp and commit png, gimp, remove photoshop. The source is now gimp. If the final file is similar to original one and original author wants to restart from his photoshop file, fair engouh. He retrieve it from the svn history, manipulate it and commit this: new png, removed gimp, new photoshop. As i said, to the opposite of cvs, svn does handle properly deletions. Original file is still available in history. > And gimp's .xcf files are another odd case here. Pretty much every linux > distro will have gimp, but folks using windows or mac would need to download it. > Should it be considered proper that the mac/windows person download gimp and > update the .xcf file, or is it ok for them to just write out a png and remove > the .xcf source? > It's probably less work for them to download the xcf / edit / save as png then open png in photoshop, extract elements, remakes some layers, save both. > Disagree - it costs something here. I'm not really concerned about the space > - that is trivial. But more the case of whenever I want to modify an png file, > these are potential steps: > > 1) Check to see if the is a 'source' version of that file in the other repository. > 2) If so, is it a format I can currently read & write? > 3) If not, is it in a format I can easily get a program that can read/write it > (or maybe we don't care about this, depending on comment above) > 4) If can't get software & can't write it, now need to remove it from repository > > As usage go on, maybe we will discover we need to regulate things a bit more. Let's get a free for all for now and see what's popular. >>> As a compromise, I'd suggest that in principal, any format may be allowed, but >>> has to be approved/discussed on a case by case basis. For fairly popular >>> formats or programs, that should pretty much be a rubber stamp. But if someone >>> pops up and wants to add a format no one has ever heard of, answer is probably no. >>> >>> >> Do we have yet a formal general approval process? If yes am ok with it, >> if no, that would just mean the commiter will have final word. >> > > I'd think in most cases, it would be fairly clear cut. Everyone readily > agreed to gimp .xcf > Ok, which version of gimp? That may not matter for xcf, but am pretty sure for adobe, for example we must settle the format (adobe) *and* the version :/ I think the main question is "do we comply to GPL to the point we must give *all* sources, including those of our png? If yes, then if someone modify something with an obscure program, he must commit the source too :/ From tchize at gmail.com Fri Dec 14 04:03:30 2007 From: tchize at gmail.com (David Delbecq) Date: Fri, 14 Dec 2007 11:03:30 +0100 Subject: [crossfire] combat notes In-Reply-To: <200712131411.57709.subs@eracc.com> References: <474D280F.3060807@sonic.net> <475E9162.8010105@gmail.com> <4760E3F2.8040105@sonic.net> <200712131411.57709.subs@eracc.com> Message-ID: <476254F2.2010604@gmail.com> En l'instant pr?cis du 13/12/07 21:11, ERACC Subscriptions s'exprimait en ces termes: > > Perhaps a method could be used to have them gradually reset back to the > pristine state. Of course this would take a lot more resources on the server > as the maps could not be gradually resetting while swapped out. Maybe to > mitigate this a resetting daemon could run and load + check each swapped map > every X seconds (tunable by the server owner) and manage the gradual reset > then swap each map back out. This daemon would have a referent of the > original map and use some smart programmer's algorithm to gradually clean it > up and re-add the NPCs while no players are on it. If a player comes to the > partially redone map and messes it up again no big deal as the daemon will > use the same process to start gradually cleaning the map again once the > player leaves. (I am not the smart programmer that can do this, but perhaps > this idea can be a starting point for one of you who is a smart > programmer :) ). This is a *very* complicated way of handling things that is, imho, not worth the troubles. Imagine map X with access to treasure Y, currently existing. Now you gradually reset map X and map Y. Istead of 5 electric dragons guarding access to map Y, you only get 1. Easier to kill, you get thru and have direct access to map Y :/ I think an easier way would be to add rules for *new* developped map so that they simply should themself repopulate. You just use generator to recreate progressively monsters. Maybe we could add to pixmap a special generator already configured for this (hidden, not disappearing, etc). Another solution would be to do some operation when swaping in a map, based on the time map was swapped out. (>50 minutes, just a reset, else for each 5 minutes it was out, do a run of that special generators.) From subs at eracc.com Fri Dec 14 15:03:55 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Fri, 14 Dec 2007 15:03:55 -0600 Subject: [crossfire] combat notes In-Reply-To: <476254F2.2010604@gmail.com> References: <474D280F.3060807@sonic.net> <200712131411.57709.subs@eracc.com> <476254F2.2010604@gmail.com> Message-ID: <200712141503.57314.subs@eracc.com> On Friday 14 December 2007 David Delbecq wrote: > En l'instant pr?cis du 13/12/07 21:11, ERACC Subscriptions s'exprimait > en ces termes: > > > Perhaps a method could be used to have them gradually reset back to the > > pristine state. Of course this would take a lot more resources on the > > server as the maps could not be gradually resetting while swapped out. > > Maybe to mitigate this a resetting daemon could run and load + check each > > swapped map every X seconds (tunable by the server owner) and manage the > > gradual reset then swap each map back out. This daemon would have a > > referent of the original map and use some smart programmer's algorithm to > > gradually clean it up and re-add the NPCs while no players are on it. If > > a player comes to the partially redone map and messes it up again no big > > deal as the daemon will use the same process to start gradually cleaning > > the map again once the player leaves. (I am not the smart programmer that > > can do this, but perhaps this idea can be a starting point for one of you > > who is a smart programmer :) ). > > This is a *very* complicated way of handling things that is, imho, not > worth the troubles. Imagine map X with access to treasure Y, currently > existing. Now you gradually reset map X and map Y. Istead of 5 electric > dragons guarding access to map Y, you only get 1. Easier to kill, you get > thru and have direct access to map Y :/ > > I think an easier way would be to add rules for *new* developped map so > that they simply should themself repopulate. You just use generator to > recreate progressively monsters. Maybe we could add to pixmap a special > generator already configured for this (hidden, not disappearing, etc). > Another solution would be to do some operation when swaping in a map, > based on the time map was swapped out. (>50 minutes, just a reset, else > for each 5 minutes it was out, do a run of that special generators.) Hi David, Glad you responded! :) I was simply tossing out an idea to get the discussion begun on this problem. I think it eventually needs to be solved however it is done. If my idea is unworkable or too complicated then finding a workable and less complicated method is absolutely fine with me. After all, I already stated I can't do it. ;) Gene Alexander -- ERA Computers & Consulting Preloaded computers - eComStation, Linux and Unix Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From mwedel at sonic.net Fri Dec 14 20:24:19 2007 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 14 Dec 2007 18:24:19 -0800 Subject: [crossfire] Arch repository: layered art files? In-Reply-To: <476252C9.8000201@gmail.com> References: <200712100728.50164.kbulgrien@worldnet.att.net> <200712121136.48735.crossfire@ailesse.com> <200712122356.47714.nicolas.weeger@laposte.net> <4760C19F.4010101@sonic.net> <4760DEAD.8040901@gmail.com> <476212B9.6070001@sonic.net> <476252C9.8000201@gmail.com> Message-ID: <47633AD3.4060005@sonic.net> David Delbecq wrote: > En l'instant pr?cis du 14/12/07 06:20, Mark Wedel s'exprimait en ces > termes: >> Fair enough. But suppose someone checks something in using adobe photoshop >> format, and a month later I want to change the image, but don't have photoshop. >> >> Is it OK then for me to remove the original (source) photoshop image and just >> have a PNG? Even if the original author is still around, maybe he doesn't have >> time to make the change in the near future. >> > Well, you can't open the photoshop file, you remake a file using, > example, gimp and commit png, gimp, remove photoshop. > The source is now gimp. If the final file is similar to original one and > original author wants to restart from his photoshop file, fair engouh. > He retrieve it from the svn history, manipulate it and commit this: new > png, removed gimp, new photoshop. As i said, to the opposite of cvs, svn > does handle properly deletions. Original file is still available in history. Ok - I have no problem with that being the method used. People will just need to make sure they svn delete the source file - otherwise there is real risk of someone seeing the source file and overwriting the modified png. OTOH, the changes lost are those that the folks who wrote the png made, so there is real incentive for them to make sure they remove that source file - it is their changes being lost, not someone else. >> And gimp's .xcf files are another odd case here. Pretty much every linux >> distro will have gimp, but folks using windows or mac would need to download it. >> Should it be considered proper that the mac/windows person download gimp and >> update the .xcf file, or is it ok for them to just write out a png and remove >> the .xcf source? >> > It's probably less work for them to download the xcf / edit / save as > png then open png in photoshop, extract elements, remakes some layers, > save both. Not sure I understand your explanation. Wouldn't it be less work for them to just open the PNG in photoshop, and not deal with the xcf files at all? > I think the main question is "do we comply to GPL to the point we must > give *all* sources, including those of our png? If yes, then if someone > modify something with an obscure program, he must commit the source too :/ The meaning of a 'source' for an image is somewhat misleading. For one, it is hard to prove that there even is a source (someone could be using some basic image manipulation program that just reads and writes pngs and doesn't have any meaningful native format). This has been the case - certainly when mass changes have been done (like xbm -> xpm -> png conversion, as well as 24x24->32x32 conversion, things like netpbm have been used). But I also use the term meaningful format here, because I think that is relevant. There are lots of good examples why having xcf data could be useful - if the layers are separate, can manipulate those to different images, etc. However, there are also lots of cases where having the xcf image may really not be useful. For example, if I take an image and it needs some cosmetic changes, I'm not likely to do that on a layer, I'm likely to do that on the base image itself. All the xcf image would get the next developer is potential to undo the changes from within gimp (I think gimp saves the undo history, but not sure). Is it really worthwhile then to have the xcf then? I'd say probably not. From mwedel at sonic.net Fri Dec 14 20:32:08 2007 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 14 Dec 2007 18:32:08 -0800 Subject: [crossfire] combat notes In-Reply-To: <200712141503.57314.subs@eracc.com> References: <474D280F.3060807@sonic.net> <200712131411.57709.subs@eracc.com> <476254F2.2010604@gmail.com> <200712141503.57314.subs@eracc.com> Message-ID: <47633CA8.3070203@sonic.net> I think map resets really have to be seen as a game mechanic, and not try to explain it too much in terms of real life. Doing incremental resets is really hard, as was noted. Aside from the issue of chained maps, to do incremental resets you'd need some form of logic which denotes what stuff resets on the map when (these monsters show up first, then these, then treasure, etc). From a gameplay perspective, it could be really annoying to go to a map that looks like it is fresh, only to find out the tough monsters/good treasure still hasn't reset yet. I'm not even sure I like the idea for maps to repopulate. While that could be done, there is still the issue of treasure (getting treasure to repopulate is harder). And ideally, the map should repopulate when folks are not around. Other than from the 'does it make sense category', I don't think maps resetting is much an issue - I haven't really seen much in the way of users complaining about it - often times, they'd want he maps to reset even faster. The idea of player instance dungeons is probably more relevant - just have to figure out how to deal with parties on that one. From tchize at gmail.com Sat Dec 15 07:41:44 2007 From: tchize at gmail.com (David Delbecq) Date: Sat, 15 Dec 2007 14:41:44 +0100 Subject: [crossfire] Arch repository: layered art files? In-Reply-To: <47633AD3.4060005@sonic.net> References: <200712100728.50164.kbulgrien@worldnet.att.net> <200712121136.48735.crossfire@ailesse.com> <200712122356.47714.nicolas.weeger@laposte.net> <4760C19F.4010101@sonic.net> <4760DEAD.8040901@gmail.com> <476212B9.6070001@sonic.net> <476252C9.8000201@gmail.com> <47633AD3.4060005@sonic.net> Message-ID: <4763D998.8090700@gmail.com> Mark Wedel a ?crit : > >> It's probably less work for them to download the xcf / edit / save as >> png then open png in photoshop, extract elements, remakes some layers, >> save both. >> > > Not sure I understand your explanation. Wouldn't it be less work for them to > just open the PNG in photoshop, and not deal with the xcf files at all? > > > It's less for to download gimp and install it to edit xcf, than open png in photoshop and redo the layers. > > However, there are also lots of cases where having the xcf image may really > not be useful. For example, if I take an image and it needs some cosmetic > changes, I'm not likely to do that on a layer, I'm likely to do that on the base > image itself. All the xcf image would get the next developer is potential to > undo the changes from within gimp (I think gimp saves the undo history, but not > sure). Is it really worthwhile then to have the xcf then? I'd say probably not. > > Of course, when there are no layers or alike, the png can be seen as being it's own source. The notion of source is irrelevant when it come to pixel-level work :) I don't want to see a svn full of pointless sourcefile that are just another encoding of png (no layers) > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From kbulgrien at worldnet.att.net Sat Dec 15 12:13:11 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 15 Dec 2007 12:13:11 -0600 Subject: [crossfire] Arch repository: layered art files? A bigger picture. In-Reply-To: <200712100728.50164.kbulgrien@worldnet.att.net> References: <200712100728.50164.kbulgrien@worldnet.att.net> Message-ID: <200712151213.12116.kbulgrien@worldnet.att.net> I have de-vaporwared the Graphics Guide on the wiki. Feel free to use this page to focus graphic design: http://wiki.metalforge.net/doku.php/graphics_guide The replies to this thread are appreciated. My sources are .xcf, so comments relating to that are useful, however, the discussion about deletion of prior works seems to indicate that to some extent, I failed to communicate some of the thought behind committing layered graphic sources. Namely, I found that creative use of layers let me re-use portions of some base graphic to form different views of a graphical set. Take the mine wall arch for instance. The front or side views of the wall contain portions that are useful for drawing diagonal views (making possible the fix of the Scorn Port Gate). This spawned an idea that I could actually combine the whole arch set into one .xcf file. Each tile could be reconstructed by turning some layers off and on. If a complete set of graphics was not needed, the source image would facilitate re-use of the pre-existing elements of graphics needed to render the other views at some time in the future. To counter one argument against layers for trivial operations, I did find it very useful to use a separate layer to add bit noise to add features like cracks, etc. Some of the reason for this was to let me experiment with different effects without trashing the underlying art that was already completed. This concept may not be practical for open development environments, but it did seem to imply some side-effect benefits could be realized by embracing use of layers. 1) Graphical element re-use. Not a primary rationale for layered files, since copy/paste from the png format is possible, but also not without plausible benefit. Simple "effect overlays" now possible. Consider Leaf's old idea about adding more images with scorch marks... Why redo the art from scratch? Simply make a scorch mark overlay... Similarly, a "weak" version of a wall, for instance, might easily be made with an overlay layer that would turn on/off. Animation sequences would all be in the same file for quick/easy reference where the animation is created by a methodical turning on/off of layers. 2) Size consistency. When "thinking out loud" on IRC today, I made a comment about producing more art. Ryo asked if I meant things like plates, etc. That, and the wiki page: http://wiki.metalforge.net/doku.php/dev_todo:gfx_needing_fixing gave me an idea. What if, for example, all food was in one source file, that contained dinnerware? It could help to keep guide the development of consistent sizes for similar objects. 3) Templates. For items where perspective or other attributes are important, template layers could assist the artist. Relevant reference layers could inserted into the source file, not for display when exporting to png, but for future re-work. Template layers might not be saved with each work, but might reside in special template source files. 4) Standard overlays could actually be created for use in maps on aa stand-alone basis. For example, perhaps squiggly line fumes could be used to indicate an odorous map element, or burning, glowing, and other effects (using transparency) could be separately placed on maps to reduce the number of unique redrawn views of standard items... Such overlays could be put into the layered source file for effective "pre-view" of the result and tweaking of the graphic design so it works with such an overlay. Seeing the banter on the simple saving of layered sources and thought about deleting prior works does make one wonder if it is futile to think that such an organized plan for producing graphics can succeed when people appear/disappear from the project - not a criticism as much as an admission that the above ideas might be a bit too far on the side of being a utopian idealism. Long Live Crossfire! From mwedel at sonic.net Sat Dec 15 22:42:18 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 15 Dec 2007 20:42:18 -0800 Subject: [crossfire] Arch repository: layered art files? In-Reply-To: <4763D998.8090700@gmail.com> References: <200712100728.50164.kbulgrien@worldnet.att.net> <200712121136.48735.crossfire@ailesse.com> <200712122356.47714.nicolas.weeger@laposte.net> <4760C19F.4010101@sonic.net> <4760DEAD.8040901@gmail.com> <476212B9.6070001@sonic.net> <476252C9.8000201@gmail.com> <47633AD3.4060005@sonic.net> <4763D998.8090700@gmail.com> Message-ID: <4764ACAA.4080806@sonic.net> David Delbecq wrote: > Mark Wedel a ?crit : >>> It's probably less work for them to download the xcf / edit / save as >>> png then open png in photoshop, extract elements, remakes some layers, >>> save both. >>> >> Not sure I understand your explanation. Wouldn't it be less work for them to >> just open the PNG in photoshop, and not deal with the xcf files at all? >> >> >> > It's less for to download gimp and install it to edit xcf, than open png > in photoshop and redo the layers. True, but it depends on the editing the person is doing. If they do not need to manipulate the layers, but instead just manipulate some pixels in the image, they don't care about the layers and could just open up the png to correct the pixels. But if they are dealing with layers, then it is pretty clear doing whatever to use that source image is better than trying to recreate the layers. From mwedel at sonic.net Sat Dec 15 23:03:50 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 15 Dec 2007 21:03:50 -0800 Subject: [crossfire] Arch repository: layered art files? A bigger picture. In-Reply-To: <200712151213.12116.kbulgrien@worldnet.att.net> References: <200712100728.50164.kbulgrien@worldnet.att.net> <200712151213.12116.kbulgrien@worldnet.att.net> Message-ID: <4764B1B6.3010709@sonic.net> Kevin R. Bulgrien wrote: > This spawned an idea that I could actually combine the whole arch set > into one .xcf file. Each tile could be reconstructed by turning some > layers off and on. If a complete set of graphics was not needed, the > source image would facilitate re-use of the pre-existing elements of > graphics needed to render the other views at some time in the future. That's an interesting thought. But from a managability point of view, I'm not sure if having 3000 layers would be very useful. But things could certainly be done on smaller scale - all the walls of one type put in as different layers. I'm not sure how well gimp deals with layers of different size when you then export the image as a png. That is to say, if the image itself is 64x64 (say a big monster), but the chosen layer is only 32x32, if you save as a png, do you get a 32x32 image or 64x64? Also, can you copy layers between images? If so, that does mean to some extent that you don't necessarily need to put everything in one one image - you just copy the layers as needed. In fact, it is probably pretty clear the case that putting everything in one image does not make much sense - the overlays for monsters are almost certainly different than overlays for walls (monsters would be items, walls would be things like cracks (weak walls), or perhaps moss or other effects). > This concept may not be practical for open development environments, > but it did seem to imply some side-effect benefits could be realized > by embracing use of layers. > > 1) Graphical element re-use. Not a primary rationale for layered > files, since copy/paste from the png format is possible, but also > not without plausible benefit. > > Simple "effect overlays" now possible. Consider Leaf's old idea > about adding more images with scorch marks... Why redo the art > from scratch? Simply make a scorch mark overlay... > > Similarly, a "weak" version of a wall, for instance, might easily > be made with an overlay layer that would turn on/off. > > Animation sequences would all be in the same file for quick/easy > reference where the animation is created by a methodical turning > on/off of layers. Yep - all that sounds good. > > 2) Size consistency. When "thinking out loud" on IRC today, I made a > comment about producing more art. Ryo asked if I meant things like > plates, etc. That, and the wiki page: > > http://wiki.metalforge.net/doku.php/dev_todo:gfx_needing_fixing > > gave me an idea. What if, for example, all food was in one source > file, that contained dinnerware? It could help to keep guide the > development of consistent sizes for similar objects. I think size consistency is a hard thing to do in crossfire, especially given the size of images. If a character is 32x32 pixels, that means a carrot should be somehint like 1x4 pixels for proper scale, but an image that small really isn't very useful. If I had a choice between images being in proper scale but hard to distinguish, or images being of incoherent scale but easy to distinguish, I'd take the easy to distinguish any day. As an aside, when images were redone at one point, it was found certain images on certain backgrounds are hard to see (most weapons are grey, and a fair number of dungeon backgrounds are also grey). There were are least a few people to bring up that it was hard to see them, and wanting them more visible. My take was more that maybe grey items on grey background should be hard to see, but more that it would be very hard to make every possible item visible on every possible background. The point here is more that if images are changed so that they are less easy to see, I think you may get some number of folks complaining. > > 3) Templates. For items where perspective or other attributes are > important, template layers could assist the artist. Relevant > reference layers could inserted into the source file, not for > display when exporting to png, but for future re-work. > > Template layers might not be saved with each work, but might > reside in special template source files. Thats reasonable. Note in the case of base (starting images), a function of layers isn't really needed. An example could be a generic humanoid with the different facings - while easier to do in a single file with layers, I'd also say that is more a starting point - once someone started making a new monster, there probably isn't a reason to keep the template layers in the image they are working on - rather they may just modify the different templates (OTOH, it may be easier to keep that template and draw over it). I certainly think templates would be useful. > > Seeing the banter on the simple saving of layered sources and thought > about deleting prior works does make one wonder if it is futile to > think that such an organized plan for producing graphics can > succeed when people appear/disappear from the project - not a > criticism as much as an admission that the above ideas might be a bit > too far on the side of being a utopian idealist. That's sort of why I was trying to sort out rules/standard for this. That makes it easier for a future person to pick things up if things were done in a somewhat standard method. If things were done more at random, much harder for someone to pick up work. As an aside, if someone actually wants to make graphics, I'd live graphics for the following: 1) The different skills (one handed weapons, 2 handed, praying, etc) 2) The different protections/attacktypes (fire, cold, poison, magic, etc) With icons, instead of current text in the client, which is too long, a simple icon could be used. These could perhaps also get used in the game somehow, perhaps to denote training areas for the skills, or as symbols on the floor. From nicolas.weeger at laposte.net Sun Dec 16 05:04:37 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 16 Dec 2007 12:04:37 +0100 Subject: [crossfire] Music and ambient sound In-Reply-To: <4745645A.1010808@gmail.com> References: <4745645A.1010808@gmail.com> Message-ID: <200712161204.40898.nicolas.weeger@laposte.net> Hello. Just committed changes to sound (not background music) system. Check doc/Developers/sound for more details. It quite certainly isn't perfect, but I guess that's a start. The design idea is to have arbitrary sounds, and also specific sounds for specific item / monsters. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20071216/087f0cc6/attachment.pgp From kbulgrien at worldnet.att.net Wed Dec 19 22:55:31 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Wed, 19 Dec 2007 22:55:31 -0600 Subject: [crossfire] Archetype properties and multi-tile buildings, etc. Message-ID: <200712192255.31783.kbulgrien@worldnet.att.net> Consider the following from server/doc/Developers/objects or note on 25012 at http://wiki.metalforge.net/doku.php/dev:objects?s=type#client_types_client_type 896 : mwedel 3553 25000-25999 Non-inventory items, stuff stuck to the floor, that can be applied. 897 : 25011 Town portal (66) 898 : 25012 Exits, doors, buildings - much more mundane exits (66) 899 : Note to arch writers; only need to set the client_type on 900 : the head (this is the case for all other properties as 901 : well). I'd like clarification on the "Note to arch writers" that appears here. I wrote a new arch and copied an existing tower, but then read the above note and modified the arch as follows. It appears to work just fine: --- Object lighthouse name lighthouse face lighthouse.x11 type 66 no_pick 1 magicmap grey glow_radius 4 visibility 100 client_type 25012 end More Object lighthouse_2 face lighthouse.x11 y 1 end --- Contrast though, with the tower arch (like many other multi-tile buildings) in that all the properties are duplicated through all the tiles. --- Object city_tower name tower type 66 face city-tower.x11 no_pick 1 visibility 100 magicmap grey client_type 25012 end More Object city_tower_2 name tower type 66 face city-tower.x11 no_pick 1 y 1 visibility 100 magicmap grey end --- Could we get some clarification. The lighthouse has been lightly tested. No, I didn't test with magic map, but otherwise it seems to work fine. Are the other arches that duplicate data just bloated? Kevin From mwedel at sonic.net Wed Dec 19 23:17:35 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 19 Dec 2007 21:17:35 -0800 Subject: [crossfire] Archetype properties and multi-tile buildings, etc. In-Reply-To: <200712192255.31783.kbulgrien@worldnet.att.net> References: <200712192255.31783.kbulgrien@worldnet.att.net> Message-ID: <4769FAEF.2070907@sonic.net> Kevin R. Bulgrien wrote: > Consider the following from server/doc/Developers/objects or note on 25012 at > http://wiki.metalforge.net/doku.php/dev:objects?s=type#client_types_client_type > > 896 : mwedel 3553 25000-25999 Non-inventory items, stuff stuck to the > floor, that can be applied. > 897 : 25011 Town portal (66) > 898 : 25012 Exits, doors, buildings - much more mundane exits (66) > 899 : Note to arch writers; only need to set the client_type on > 900 : the head (this is the case for all other properties as > 901 : well). > > I'd like clarification on the "Note to arch writers" that appears here. > > I wrote a new arch and copied an existing tower, but then read the above note > and modified the arch as follows. It appears to work just fine: That comment there should be correct. It is intended that the head of the object controls most all aspects of the object, and all code should pretty much be of the nature 'if (op->head) op = op->head' type of thing so that all operations work on the had. That said, I can't see that everyplace in the code does that, but IMO it should, so if it doesn't, that would really be a bug. > --- > > Could we get some clarification. The lighthouse has been lightly tested. > No, I didn't test with magic map, but otherwise it seems to work fine. > Are the other arches that duplicate data just bloated? Almost certainly the extra data is just bloated. OTOH, other than a little extra disk space, it doesn't really cost much - those fields use the same amount of memory in the running server, whether or not they are actually set to anything, so setting more of those fields in the object doesn't cause extra ram to be used From crossfire at ailesse.com Sat Dec 22 19:38:50 2007 From: crossfire at ailesse.com (crossfire at ailesse.com) Date: Sun, 23 Dec 2007 02:38:50 +0100 Subject: [crossfire] User-defined plugin events and the 'give' command Message-ID: <20071223013850.GA20633@ailesse.com> Hi, Here is a short summary of what my latest commit is about. Note that the following is only valid for the trunk code. 1.User-defined plugin events ============================ User-defined events are events that are triggered by plugins themselves, and are not hardcoded in the server "core" code. Useful if you want to create a new kind of event that is generated from a Python script, for example. In CFPython, a user-defined event is triggered on an object by calling its Event() method. Event takes the following parameters: - activator (object): The activator of this event; - other (object): A third object involved in the action; - message (string): A freeform text that will be used by the target to determine what kind of event it is; - fix (int): Tells if the target will need to be fixed automatically or not after the event execution. Event returns an int; the event implementer is free to do whatever it wants with it. The archetype to put into the inventory of an object to make it listen to user-defined events is event_user. 2. The "give" command ===================== This command allows one player to give an item to an NPC. The command triggers a user-defined "give" event on the target, supplying the object given as a parameter. Give is meant to be used for "show me the key" quests, in which the character must show a given item to a "guardian" to be allowed to continue. Syntax: give The Mad Mage has been adapted so it can react to give commands. Note that since the quest related to it is not yet into the SVN (it will be soon, though :)), the old grumbling mage will currently accept nothing :). That's all for now folks :). From kbulgrien at worldnet.att.net Tue Dec 25 00:19:46 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Tue, 25 Dec 2007 00:19:46 -0600 Subject: [crossfire] Arch category... wall dressing? Message-ID: <200712250019.46728.kbulgrien@worldnet.att.net> After some IRC discussion, it occurred to me that Crossfire is devoid of sewer themes that are so prevalent in dungeon type games from the family that CF hails from. This, alongside some discussion about a brewery got me thinking about creating graphic overlays of pipes, manhole covers, spouts, moss, etc. that could be used to "dress up" existing walls. Tonight I created a "wall spout" graphic that does indeed overlay most wall types, though probably a second drawing will be needed to make it usable on the walls that have a fairly short front face. The arch/wall directory already seems a bit cluttered, even sporting non-wall items like roadways, but seems a reasonable home for such wall dressings. Consider this a call for ideas on a directory structure for storing archetypes of this nature. These aren't going to be walls, but probably will sit on a layer just above the wall so as to appear part of the wall. It is doubtful they would be used for anything except redecorating wall tiles. Kevin From nicolas.weeger at laposte.net Wed Dec 26 16:41:45 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 26 Dec 2007 23:41:45 +0100 Subject: [crossfire] Arch category... wall dressing? In-Reply-To: <200712250019.46728.kbulgrien@worldnet.att.net> References: <200712250019.46728.kbulgrien@worldnet.att.net> Message-ID: <200712262341.50128.nicolas.weeger@laposte.net> Hello. > Consider this a call for ideas on a directory structure for storing > archetypes of this nature. These aren't going to be walls, but > probably will sit on a layer just above the wall so as to > appear part of the wall. It is doubtful they would be > used for anything except redecorating wall tiles. *votes for /wall/overlay directory* Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20071226/e72669cb/attachment.pgp From tchize at gmail.com Wed Dec 26 16:54:23 2007 From: tchize at gmail.com (David Delbecq) Date: Wed, 26 Dec 2007 23:54:23 +0100 Subject: [crossfire] Arch category... wall dressing? In-Reply-To: <200712262341.50128.nicolas.weeger@laposte.net> References: <200712250019.46728.kbulgrien@worldnet.att.net> <200712262341.50128.nicolas.weeger@laposte.net> Message-ID: <4772DB9F.8080905@gmail.com> +1 Nicolas Weeger a ?crit : > Hello. > > >> Consider this a call for ideas on a directory structure for storing >> archetypes of this nature. These aren't going to be walls, but >> probably will sit on a layer just above the wall so as to >> appear part of the wall. It is doubtful they would be >> used for anything except redecorating wall tiles. >> > > *votes for /wall/overlay directory* > > Nicolas > > ------------------------------------------------------------------------ > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From kbulgrien at worldnet.att.net Wed Dec 26 17:54:09 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Wed, 26 Dec 2007 17:54:09 -0600 Subject: [crossfire] Arch category... wall dressing? In-Reply-To: <200712250019.46728.kbulgrien@worldnet.att.net> References: <200712250019.46728.kbulgrien@worldnet.att.net> Message-ID: <200712261754.10074.kbulgrien@worldnet.att.net> > After some IRC discussion, it occurred to me that Crossfire is devoid of > sewer themes that are so prevalent in dungeon type games from the family > that CF hails from. This, alongside some discussion about a brewery got > me thinking about creating graphic overlays of pipes, manhole covers, > spouts, moss, etc. that could be used to "dress up" existing walls. > > Tonight I created a "wall spout" graphic that does indeed overlay most > wall types, though probably a second drawing will be needed to make it > usable on the walls that have a fairly short front face. > > The arch/wall directory already seems a bit cluttered, even sporting > non-wall items like roadways, but seems a reasonable home for such > wall dressings. > > Consider this a call for ideas on a directory structure for storing > archetypes of this nature. These aren't going to be walls, but > probably will sit on a layer just above the wall so as to > appear part of the wall. It is doubtful they would be > used for anything except redecorating wall tiles. Actually, come to think of it, such tiles would also affect flooring, and that probably explains why arch/wall contains flooring. The "roadways" are simply floors reused as pavement. Also, consider that pipe arches would naturally include a new kind of switch (valve). The manhole cover would be a new sort of door, and probably a number of other door styles could be made that are appropriate to an underground sewer theme. Regarding other possible wall treatments... banners, coat-of-arms, torches, lamps, windows, etc. come to mind. Why draw unique wall pieces for these items when crossfire supports layers? While some of these items might be naturally associated with arch/wall, I can see that the variety might make that directory somewhat more cluttered. arch/wall/ From mwedel at sonic.net Thu Dec 27 00:23:35 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 26 Dec 2007 22:23:35 -0800 Subject: [crossfire] Arch category... wall dressing? In-Reply-To: <200712261754.10074.kbulgrien@worldnet.att.net> References: <200712250019.46728.kbulgrien@worldnet.att.net> <200712261754.10074.kbulgrien@worldnet.att.net> Message-ID: <477344E7.1090407@sonic.net> The fact that they may be usable without walls (and as floors) suggests that maybe arch/wall isn't the best place. I'm not sure why things like the roadways are in the wall directory and not floor directory. It is probably because those used auto join functionality like the walls (to make laying them out easier), and not that it was necessarily the right place for it. I'd also say that depending on number of objects, further refinement of just a overlay directory may be desirable - for example, could have: arch/overlay/plumbing arch/overlay/carpets arch/overlay/... I'd tend to suggest a top level directory as last I looked, the editor grouped things by top level directory name, and I'd think it may be more useful to find/use them if one didn't have to look in wall. And from a place expecting to find those things, wall might not be the intuitive place to look. From kbulgrien at worldnet.att.net Sat Dec 29 10:24:39 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 29 Dec 2007 10:24:39 -0600 Subject: [crossfire] New manhole archetype WIP (accepting help) Message-ID: <200712291024.39359.kbulgrien@worldnet.att.net> I have committed a work-in-progress archetype for a multi-tile manhole. To test the animation, and as a starter, the manhole is implemented as a HOLE (object type 94) so that I could learn how to do animations and could work off of a working example. The archetype is a 64 x 64 bit graphic. I have also include a .xcf source file that is layered and has even more elements to produce additional manholes once the animation problem is able to be worked around. My archetypes are based on arch/trunk/connect/Hole/pit.arc, but I had to mangle the manhole_closed_1 archetype to get a working animation. This is all documented in arch/trunk/dev/wip/manhole/README, and a test case is set up as arch/trunk/dev/wip/manhole/world_105_115.patch. It appears I may be the first to try creating a multi-tile HOLE, and possibly the first to try to create any multi-tile connected animation. I could use some help determining if I have borked the .arc file in some way, or if perhaps the system just does not support such use of multi- tile graphics in animations. Any takers? Kevin Bulgrien From kbulgrien at worldnet.att.net Sun Dec 30 19:16:07 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 30 Dec 2007 19:16:07 -0600 Subject: [crossfire] New manhole archetype WIP (accepting help) In-Reply-To: <200712291024.39359.kbulgrien@worldnet.att.net> References: <200712291024.39359.kbulgrien@worldnet.att.net> Message-ID: <200712301916.07855.kbulgrien@worldnet.att.net> > I have committed a work-in-progress archetype for a multi-tile manhole. > To test the animation, and as a starter, the manhole is implemented as > a HOLE (object type 94) so that I could learn how to do animations and > could work off of a working example. > > The archetype is a 64 x 64 bit graphic. I have also include a .xcf > source file that is layered and has even more elements to produce > additional manholes once the animation problem is able to be > worked around. > > My archetypes are based on arch/trunk/connect/Hole/pit.arc, but I had > to mangle the manhole_closed_1 archetype to get a working animation. > > This is all documented in arch/trunk/dev/wip/manhole/README, and a test > case is set up as arch/trunk/dev/wip/manhole/world_105_115.patch. > > It appears I may be the first to try creating a multi-tile HOLE, and > possibly the first to try to create any multi-tile connected animation. > > I could use some help determining if I have borked the .arc file in some > way, or if perhaps the system just does not support such use of multi- > tile graphics in animations. Any takers? Ryo pointed out I didn't actually say the animation did not work properly. Say the anim is set up like this: anim manhole.111 manhole.112 manhole.113 manhole.114 mina Then the only case where animation occurs is for the normally closed case where the head face starts as manhole.114. One would think that the non- head pieces should also be set to manhole.114 so that they form a correct picture, but when this is done, no animation is possible. The non-head pieces must be set to manhole.111 for the animation to work. Since the non-head pieces do not match the head, however, the 64 x 64 bit graphic is incorrect. Also, say the head and hole are at x,y, when in the configuration where the animation works, the head, and animated manhole, is displayed at at x-1,y-1 though the hole function still operates at x,y. In cases where the animation does not work, the hole function and the manhole are both at x,y. I cannot seem to get the animation to work at all for the normally open case where the head is manhole.111. The test case in SVN does show both a functional normally closed hole with an incorrect animation, and a functional normally open hole with no working animation. Kevin From kbulgrien at worldnet.att.net Sun Dec 30 22:03:18 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 30 Dec 2007 22:03:18 -0600 Subject: [crossfire] New manhole archetype WIP (accepting help) In-Reply-To: <200712301916.07855.kbulgrien@worldnet.att.net> References: <200712291024.39359.kbulgrien@worldnet.att.net> <200712301916.07855.kbulgrien@worldnet.att.net> Message-ID: <200712302203.18568.kbulgrien@worldnet.att.net> > > I have committed a work-in-progress archetype for a multi-tile manhole. > > To test the animation, and as a starter, the manhole is implemented as > > a HOLE (object type 94) so that I could learn how to do animations and > > could work off of a working example. > > > > The archetype is a 64 x 64 bit graphic. I have also include a .xcf > > source file that is layered and has even more elements to produce > > additional manholes once the animation problem is able to be > > worked around. > > > > My archetypes are based on arch/trunk/connect/Hole/pit.arc, but I had > > to mangle the manhole_closed_1 archetype to get a working animation. > > > > This is all documented in arch/trunk/dev/wip/manhole/README, and a test > > case is set up as arch/trunk/dev/wip/manhole/world_105_115.patch. > > > > It appears I may be the first to try creating a multi-tile HOLE, and > > possibly the first to try to create any multi-tile connected animation. > > > > I could use some help determining if I have borked the .arc file in some > > way, or if perhaps the system just does not support such use of multi- > > tile graphics in animations. Any takers? > > Ryo pointed out I didn't actually say the animation did not work properly. > > Say the anim is set up like this: > > anim > manhole.111 > manhole.112 > manhole.113 > manhole.114 > mina > > Then the only case where animation occurs is for the normally closed case > where the head face starts as manhole.114. > > One would think that the non- head pieces should also be set to manhole.114 > so that they form a correct picture, but when this is done, no animation is > possible. The non-head pieces must be set to manhole.111 for the animation > to work. Since the non-head pieces do not match the head, however, the > 64 x 64 bit graphic is incorrect. > > Also, say the head and hole are at x,y, when in the configuration where the > animation works, the head, and animated manhole, is displayed at at x-1,y-1 > though the hole function still operates at x,y. In cases where the > animation does not work, the hole function and the manhole are both at x,y. > > I cannot seem to get the animation to work at all for the normally open > case where the head is manhole.111. > > The test case in SVN does show both a functional normally closed hole with > an incorrect animation, and a functional normally open hole with no working > animation. If non-head tiles are blank.111, or have no face specified, the animation works perfectly for both normally-open and normally-closed arches, but in-game, the manhole is still not aligned with the hole function, and, Gridarta's display is not in agreement with how the game renders the manhole, but, I'd say it's not Gridarta that's wrong. I might add that I have been testing with crossfire-client-gtk2 2.0-dev-r8063, but crossfire-client-gtk 2.0-dev-r8063M, gcfclient 1.9.1 and gcfclient 1.10.0-r6738 all have the same issues. Kevin From mwedel at sonic.net Sun Dec 30 23:02:15 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 30 Dec 2007 21:02:15 -0800 Subject: [crossfire] Next release Message-ID: <477877D7.3000201@sonic.net> Had mentioned several months back I was going to do a new stable release in the near future. Between getting sidetracked and waiting for some changes to get put back, I never got around to making a release. So its almost start of a new year, so I'm going to do a release around Jan 12/13 - gives folks about 2 weeks for any changes. and this time I really mean it - I'll actually do a 1.11 release this release. so get your changes in. Remember that this is the stable branch, so major changes really should only be in the trunk. From mwedel at sonic.net Sun Dec 30 23:22:46 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 30 Dec 2007 21:22:46 -0800 Subject: [crossfire] Plan to commit combat changes to trunk Message-ID: <47787CA6.9050405@sonic.net> I've been playing with the rebalance of melee combat for crossfire for a while, and while not 100% done, I think it is complete enough to warrant committing it to the trunk and hopefully getting more exposure. Now for folks running trunk servers, while the change will not cause anything to actually break (or it shouldn't), it will cause a change in game play, so folks may find combat tougher. In particularly, I have not rebalanced the high (20+) level monsters, so they may still be quite deadly. I also have not rebalanced the spells (next step), and balancing the high level monsters sort of goes hand in hand with balancing spells. I've also created a new exp table (table D), which has slower progression. While not a requirement to use that table, I think it makes for a better play experience. I think it should be the default, and I'm not really sure how well a game can be balanced if there are 4 different exp tables out there, but I suppose this is more an effect of balance between the classes. I have also limited the generators, via arch change, to only generate 5 monsters before the generator dies. I'm sure some maps need updating - that 5 monster limit is actually a pretty good compromise - it tends to fill up those empty dungeons that rely on generators to fill them up, but also keeps monsters at a reasonable level. I could do all this work in a branch - I'm just don't think that is really worthwhile - the main point of the trunk is to work on the big projects like this. I'd say that where things are now, it has moved beyond expiremental code to code that will be used, but some more work is still needed. I'll start another thread about future changes for balancing. But I'm willing to discuss, and for folks to see this as a heads up if you are running a trunk server. From mwedel at sonic.net Sun Dec 30 23:49:32 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 30 Dec 2007 21:49:32 -0800 Subject: [crossfire] Balance changes Message-ID: <477882EC.1090704@sonic.net> As noted in another message, I think the melee combat balance changes are about 90% there, with the remaining 10% being tweaking and adjustments (some monsters maybe too easy for the exp, some too hard, etc). While I haven't adjusted bow combat, from the basic uses I've done so far, it seems to be somewhat reasonable - the fire/kill rate is somewhat close to to melee - big advantage is that you're not right next to creature. Big disadvantage is you need to carry thousands of arrows about. A thought here is to greatly reduce the odds of arrows (at least non special ones) being destroyed, so you can at least get back most of the arrows you fire (special ones, like the assassinating whatever should still be one shot). Spells are the next thing to tackle. I think I'll go down the route of elemental spells, as discussed. Some additional quick thoughts: 1) Each element has a first level cone spell and first level bullet spell (the bullet is like magic bullet - it doesn't explode, just does damage). The bullet spells does more damage, but only hits a single target, the cone gets many targets. You also get a protection spell. 2) Since the rebalance here includes scaling things up to level 100, it strikes me we can not give out new spells every level. Maybe every 5 or so, so at level 5 you get a small exploding ball and small bolt spell (maybe not at exactly same level, who knows) 3) In order to make these low level spells effectively, I think the damage on them needs to ramp up pretty quickly (creatures hp goes up about 10/creature level, so level 1 creatures have 20 hp, level 5 about 50 hp, level 10 around 150 hp). To counter this, max damage/range/whatever type things are added, so at level 15 (lets say) that firebullet you get a first level doesn't get any better. 4) Related to this, better version of low level spells can be put in the game. At level 10, maybe give out 'medium bullet' type of thing, which costs more than the small one, but does more damage and also scales up to higher level. I've also had some thoughts on other classes: Thief/Rogue - crossfire doesn't really have much like this. One thought to make this a more viable class is to remove the search and disarm traps from other classes - most game systems does not allow a mage to disarm traps. This doesn't help as much in standalone, but helps in party play (having that thief to find and disarm traps would be useful). I think the trap exp needs to be adjusted for this to be more playable. We should probably also allow thieves to make traps, and if they kill a monster with that trap, get the appropriate exp for it. I also think traps should probably be made deadlier. A trapped door or trapped chest isn't all that dangerous if a character at full hit points will never die from it (an alternative is maybe longer term affects - we have discussed the idea of some spells lasting hours of real time. Imagine you get hit with a trap which depletes a stat or slows the character that that lasts half an hour - you can't just run out of the dungeon and wait it out, like you can with most cases of poison or damage). The last is hiding and sneak attacks - if player is hidden and attacks a creature, give them extra damage, and if they kill the creature, maybe split exp between hiding and the weapon skill?) Likewise, letting rogues steal from shops should perhaps be allowed, but if caught, they are tossed in the town jail for some amount of time. Item creation classes - if someone wants to play a blacksmith and make weapons all day, who am I to say no? But with other balance changes, we can know how this works - that blacksmith needs raw ore, and the facilities and time. Maybe there is a mine near by he can go to get the ore - but if it takes 5 minutes realtime for him to get a load of stuff, that help factor out exp gain. Likewise, if he gets 50 exp for making a sword, it means he has to make a lot of swords to gain a level, and if an actual time delay is put in there (lets say it takes 10 seconds realtime to make a sword), it probably means that such a character will not gain levels any faster than any other class, so IMO would be considered in balance. The only issue here is that I think such long time (10 second) actions need to be interruptible - in a sense, it is almost like the run on stuff - the character keeps making the sword unless he chooses to do something else. And there is some chance at failure - a first level blacksmith maybe only has a 50% chance to successfully make a sword for example. I think clerics/priests are basically OK. Any other thoughts out there?