[crossfire] Reimplementing seasonal weather.
I just had a conversation on IRC with Raphaël Quinet, relating to seasonal changes to the world. I was thinking about making an ice dungeon in the middle of a lake, that, by using the existing scripts relating to time, would only 'exist' during winter when the lake freezes over. Raphaël brought up the point, that if such a dungeon existed, it would make sense to have most of the world change to visually indicate the current season to players. Think about trees loosing their leaves, snow appearing on the ground, and lakes freezing over. A few ways for this to be implemented came up: * Allow the scripts that replace objects based on time to be attached to regions. However, this could affect indoor maps unless they are excluded by the code. * Create (or modify) archetypes that would change, based on the season. This could be done with C code or by attaching scripts. * Have attributes that specify how such objects change. A few things should be considered if this is done: * It would also be nice to allow various 'climates' to be specified by region. * Regardless of the implementation, special care should probably be taken to preserve special attributes of the objects being replaced or modified. If this is not done, exits and other objects can break. * If lakes and rivers are to freeze over, attention should be paid to areas where water is used to block players (such as the lake south of Brest). However, if we solve these issues, it also allows us to give pilot-able boats to players. Possible solutions include, not freezing certain parts of lakes, or the creation blocking tiles such as slush or very thin ice. -- Andrew Fuchs fuchs.andy AT gmail.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Build command
On Tue, 2007-04-17 at 08:12 +0100, Anton Oussik wrote: On 14/04/07, Nicolas Weeger [EMAIL PROTECTED] wrote: Optionally, alchemy could be made to use sp, too (would emulate the build command behaviour). Interesting. This would solve a lot of problems. What do others think? Good idea for general alchemy, IMO. Stuff like general cooking or smithing (non magical) shouldn't have to use sp though. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Getting more artists
On Wed, 2007-04-11 at 20:15 +0100, Anton Oussik wrote: On 11/04/07, ERACC Subscriptions [EMAIL PROTECTED] wrote: On Wednesday 11 April 2007 05:00 am Anton Oussik wrote: If we could attract an artist (or 5 or 6) who would be willing to create 3D models of things, animate them, and then produce a complete tileset of the universe from those, it would be ideal. Call me crazy if you wish. :-p I prefer the 2D version we have now. Granted we could always use more and better 2D graphics. But 3D and animation then locks out a lot of marginal graphics makers (like me for example) that could make do with the 2D tiles. Once we go 3D we would *have to* have some 3D artists on board the project to go forward. 2D reduces portability and ability to animate graphics. For example, if someone creates an animation of a running orc, and someone else creates an animation of an orc swinging an axe, given the models, some 3rd person can easily add an animation of an orc firing an arrow. Generating everything from a different perspective or of a different resolution can then also be automated, and colours can be easily be adjusted over all frames featuring the same model. A talented 3D artist should be able to get more work done, and be able to keep the work easy to change better than several 2D artists might. As a bonus, same models can be used to make CF truly 3D some day, instead of 3D-rendered snapshots as currently proposed. Since I think some day within the next 10-15 years CF needs to make a transition to 3D to stay current, this would be a natural evolving route to take. Agreed. These two, are the only advantages that I see for going with 3D models. Also, as noted in one of Rick Tanner's emails, we would need to create standards to ensure that all the graphics fit together. This is especially true since we are using pre-rendered tiles. The problem with that is good 3D graphics folks are not easy to find and keep. That is true, and there are good chances that none will be attracted. I might be able to do some work, though I probably won't have much time to do so. The really good ones are probably working only on closed source projects for a salary. I say this based on the lack of excellent 3D graphics in the open source projects I have seen. I am willing to be proven wrong though. ;-) But I still would prefer we keep Crossfire a 2D game. ... As for finding artists, there are a lot of people who do 3d work as a hobby. Although I don't have a clue about what they do for their normal work. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire bots
On Sun, 2007-01-21 at 00:40 +0100, Nicolas Weeger (Laposte) wrote: Hello. Concerning feature request Newbie Bot - help those noobs :) https://sourceforge.net/tracker/index.php?func=detailaid=765770group_id=13833atid=363833 is there such a bot currently? I know of 2 bots scripts at least, Seer and Zebulon. Could they be adapted to such a request? (this request, at least of a bot giving advice, is quite interesting imo) Possibly Seer, but your other idea seems a bit more user friendly. Of course, we could make the newbie area more mandatory, too :) I would rather see this happen, than to have a bot do it. Possibly evolve the tutorial map into a quest (more in the sense of role playing). It would also be nice if we used the animator plugin to give the player a little bit of back story about the game world (an other suggestion in that feature request), after someone finishes setting their character up. Players who seem to have a difficult time after the tutorial, could be marked (through the use of a script, and a logger), while various npcs distributed across the world attempt to give tips to the player loosely relating to the problem the player was marked with. -- Andrew Fuchs [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Release of 1.10 soon.
On Sat, 2006-12-30 at 00:26 +0100, Yann Chachkoff wrote: I do. I'd like to have enough time to solve at least the following bugs before the next release: - #1612838 : Problem with item_power code; - #1539120 : Talisman of Evocation grants wrong skill; - #1528525 : Sometimes bad initial items are created. I think it would also be nice to wait until #1522796, #1551398, #1556723 and #1605033, which are all marked as probably fixed, are verified and closed. Given that a significant amount of bugs can be adressed in a relatively short time, and that the GTK2 client as only 5 priority 5 bugs pending, none of which being overly difficult to solve, I think it is best to wait until those are pushed into the Pit of Oblivion before making a release. After all, there is no deadline to follow, no need to rush something out - so trading one week or two for a cleaner result would definitely be a good choice, IMHO. Agreed, we could put more focus on fixing known bugs, IMO. -- Andrew Fuchs [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Client-side scripting
On 10/29/06, Nicolas Weeger (Laposte) [EMAIL PROTECTED] wrote: ... Removing existing scripting, well, I'm not too eager, I think people are used to it... I have a strange feeling that this might evolve into a plugin system. :-/ -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] About a bug (or feature?)
On 10/22/06, Nicolas Weeger (Laposte) [EMAIL PROTECTED] wrote: ... On tracker there's a bug about bombs and shops, at https://sourceforge.net/tracker/index.php?func=detailaid=1571556group_id=13833atid=113833 Basically, a player can with bombs destroy unpaid items in shops (even in non magic areas). Ive seen this done a few times. Now the question is whether this is something we want to allow or not. ... Personnally I'd say we keep the behaviour as is, letting players destroy stuff if they want :) I would say the same, except that it becomes very irritating when you can't buy something because the shop is blown up every time it resets. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] draw_ext_info/message update/redo
On 9/24/06, Mark Wedel [EMAIL PROTECTED] wrote: ... The main advantages I see of the drawextinfo is this: - Support for the media tags (bold text, different fonts, etc). I'd expect these to be infrequently used, as in general the global tag/attribute should be used. But I think use in NPC messages giving clues what can be discussed with them by doing bold or underline would be very good (we should probalby decide what the form for that syntax highlighting it is, so that it is consistent accross all the maps/NPCs) Or we could make a new tag like [triggerword]. The server then could decide on it's formatting. Also, if it is passed to the client, the client could make the hilighted phrase clickable. - Instead of the server telling the client the color to use and the client blindly following it, the client now knows the type of messages. So with some extra logic, I could decide that I want the level gain message to be in a specific font in bright green, even though the server says those should be in red. It would also allow for easier filtering (if chat/say/shout have their own types, easier to have a conversation pane, etc). Very useful in my opinion. I really like the colors that me chats: uses. Though that could be considered a bug. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Making maps easier to maintain, by creating custom archetypes for duplicated objects.
There are several instances in the maps, where custom objects where copied and pasted from other maps. An example to this is the guidebooks in the post offices. Recently the guide books in Scorn's post office where modified, but not the ones in other post offices. This lead me to think about what requirements have to be met for it to become practical to replace duplicated custom objects with new archetypes. I'm thinking that having two or more of similar objects that appear on separate maps would be enough warrant a new archetype. Anyone want to write a script to find duplicate custom objects in maps, or intergrate it into a map checking script? -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] stat loss and highly specialized players
As what i could skim off of I440r__'s rant on IRC, players that are highly specialized (high level) in only a few skills can loose an unreasonable amount levels in skills that they are trying to develop from low levels. His general point was that it should take longer to gain levels, but players should lose less when they die. Now, does the limit on experience lost from the death penalty apply to individual skills? If it doesn't, does anyone see any issues related to l440r__'s rant? Should the death penalty apply to individual skills? -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Proposal: Alchemy spell changes
On 9/10/06, Lalo Martins [EMAIL PROTECTED] wrote: On Sun, 10 Sep 2006 15:45:25 -0700, Mark Wedel wrote: ... OTOH, perhaps the weight of the nuggets should be seen as a way of limiting amount of wealth removed from dungeons IMO that's a non-issue, on such a high level you'll probably have town portal. Thus the desire of some developers to add an attributes to regions, that disable spells like town portal, and word of recall. On 9/10/06, Alex Schultz [EMAIL PROTECTED] wrote: ... Ok, I'll probably have it implemented in the next 48 hours or so :) Btw, does anyone have any objections to renaming it to gold touch (was thinking of transmute to gold but that seems too long), to avoid current confusion with the alchemy skill? Renaming it is probably a good idea. IIRC, players have used the spell on cauldrons before. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Idea: class has an effect on the amout of experience gained from certian skills
I came up with an idea that would add significance to a player's choice of class, and be an other way to tweak experience. What if skills associated with a class give the player more experience when they are used? This could also be taken in the other direction by limiting the experience players gain with skills not associated with their class. For example, an evoker will level up more quickly if they use evocation, than if they used sorcery, bows, or melee attacks. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] About a feature request
On 8/21/06, Raphaël Quinet [EMAIL PROTECTED] wrote: ... To be frank, I do not like this idea very much, especially for spellbooks. ... The only players that would be significantly affected by such a change are the low-level characters or the players who are just starting to learn how the game works. And they would probably be affected negatively more than positively. For those players, finding a spellbook is like finding a major treasure because they probably do not know many spells yet. If their stats (Int/Wiz) are not very high, they already have a disadvantage because there is a high risk that they fail to learn the spell. A cursed spellbook would not only be a piece of treasure that becomes worthless, but it would be even worse: they would lose one of their hard-earned spells. Having blessed spellbooks would probably not compensate the negative effect that cursed ones could have. Agreed. For a beginning player, loosing a spell can be a major set back. The best alternative I can think of would be a small experience penalty. The role-playing explanation of this would be that the misinformation from the book has been learned by the player. I think that crossfire is already too hard and too complex for many new players. Adding cursed spellbooks would not really improve that aspect of the game. Adding cursed scrolls may be a bit more reasonable if the ill effects are not too severe, but I would prefer to avoid them as well. Also agreed. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Clothing
On 8/21/06, Lalo Martins [EMAIL PROTECTED] wrote: On Sun, 20 Aug 2006 21:01:23 -0700, Mark Wedel wrote: ERACC Subscriptions wrote: I propose that robes and other cloth items (not cloaks) should be a new class of item called clothing not armor. A new body spot created for that and archetypes updated. Special robes that may impart armor-like characteristics could then be adjusted in the archetypes for prevention of abuse (if that appears to become a problem). Having more general clothing in the game, would add more depth for role playing (formal whatevers). If it's armor, set it's type to armor. technically, this is pretty easy to do. But balance wise, this is more an issue. Whenever new body positions are added, it basically means the player becomes more powerful. I think the solution to the problem eracc described on irc is not new body spots, but just a new type. I don't think you can wear gloves and gauntlets at the same time, or a robe over a breastplate. (You can wear a breastplate over a shirt, and usually you'll want to, but for game purposes, let's say that's, er, a different kind of shirt.) Yes. Then flags like can_use_armor only need to check the type -- which I believe is the way it is already. yes-lets-stop-the-disgusting-naked-Rugillites-ly yours, THANK YOU. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Spell path balance - Summoning
On 8/21/06, Alex Schultz [EMAIL PROTECTED] wrote: Raphaël Quinet wrote: Something needs to be done to re-balance this skill (and also some other skills). However, some of the solutions that have been proposed so far would only make charm monsters useless or dangerous to use, which would not solve the other part of the problem: this skill is too difficult to use at low levels. Well, note though, that past level 20 or so, summoning is *completely* useless *except* for charm monster. Summoned monsters are far too weak to have any use at level 30 and up, and sure there's animate weapon, however the only things strong enough to be worth animating are not worth the risk of loosing. Personally I think there are four things that could be done to balance summoning properly: - Make charmkilling not so powerful without completely making it useless. (personally I think requiring line of sight and limited range might be a good method, possibly in addition to making 'killpets' not always work) Agreed. For modifying killpets, I'd change it to dismisspets. Then code it so summoned monsters are killed and charmed monsters are set to be peaceful. However, this doesn't address the issue of what happens when a monster is charmed, then taken to another map. - Add more powerful types of summoned creatures at higher levels (Possibly just more things for 'summon creature' or possibly (a) new spell(s) like 'summon greater creature') There is Magehound, but I think it was added more as an example. Someone would have to check for balance issues before it is actually made available to players. - Make the first few levels more practical to use it with, possibly by making the summoned creatures faster or more powerful. Agreed. - Not as needed to balance as the other notes, but somehow reducing the risk of loss of a weapon used with animate weapon. Can't think of anything other than giving it temporary immunity to being damaged (burnt up, icecubed, etc) or making the weapon come back to the player after the spell's effect ends. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Where would you put...
On 8/20/06, Nicolas Weeger (Laposte) [EMAIL PROTECTED] wrote: Hello. After some fun chat on the irc channel, I'm creating a talking fireplace which'll tell stories to players. Small Python scripts, that'll be all :) Now the question is, where should we put the stories? IMO, a good place is in the share directory, maybe in a 'stories' subdirectory. A story could be quite long, so using the msg field isn't the best way imo. Im thinking maps-bigworld/python/talkingfireplace and a data or stories directory inside that for the stories, unless someone objects. Latter it may be a good idea to tie the fireplace into lore/story colleciton scripts. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] crossfire source code control systems
I would like to bring up another issue regarding the sf.net webspace and Mercurial. The last time I checked (looking into running a wiki on it) all scripts run without a sandbox and as the same user. This creates a large security issue, where it may be possible for someone else that has access to a sf.net webspace to screw around with the repository. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] create earth wall totally nerfed ...
On 8/11/06, Mark Wedel [EMAIL PROTECTED] wrote:
...
a new movement type for jump? I suppose that could be done - OTOH, I'm not
sure how many movement types we want.
One theory, and what I originally envisioned, was keeping them fairly broad
-
walking, fly low, fly high (spells vs say flying on a dragon), swimming, boat.
The other side is that you have a movement type for every particular way of
moving - crawl, run, jump, swim, skip, etc.
The later provides lots of way to control movement. OTOH, if movement types
are automatic, it may not mean much (ok, you have to crawl in that low
passage,
but since you will crawl automatically, what difference does it make?), etc.
It depends. Can everyone and everything crawl, or only a few races or monsters?
That said, looking at the actual problem at hand, I think this is the commit
that changed the behaviour:
revision 1.4
date: 2006/06/01 17:24:00; author: akirschbaum; state: Exp; lines: +1 -0
Make earthwalls block all movement types. This makes the spell earth to dust
wor
k again.
Yet all the earth to dust code looks for is:
if (GET_MAP_MOVE_BLOCK(m, sx, sy)) {
...
}
So the move_block for earthwalls could be changed to just block move_walk,
and
you could jump over the earthwalls and earth to dust would still work.
The downside is that spells then go over earthwalls, since most spells fly.
I
think letting spells go over (through) earthwalls would cause problems on
some maps.
One possibility is to make a new earthwall archetype that only blocks
walking
and have the spell use that new archetype, so earthwalls created by the spell
only block walking, but those on maps block everything. Map makers could of
course change behaviour of earthwalls on maps to match what they want it to
do.
Yes, if you can jump over earthwalls, they are probably low enough to fly over.
I'm not sure if that causes any problems - letting players fire spells or
other attacks over earthwalls at monsters may cause problems, as I'm not 100%
sure all monsters are smart enough to try and break through the earthwall (but
that could then be considered a different problem).
Flying mobs would be able to get over too, but every spell has its
limits, right? Though i don't think that most mobs would fly over
one, unless they are able to see a target (possible redo of the line
of site code for everything).
Earthwalls are general used by players for protection, either by
limiting the movement of monsters, or blocking spells and other
projectiles. On the other hand, mobs don't cast spells unless they
have a target, so another player or a friendly mob would have to be
visible to the hostile mobs. This would additionally stop players
hiding behind earthwalls from exploiting charm monsters in most
situations. Whether this is desirable or not is up for debate.
However it will not fix every instance of charm-killing.
--
Andrew Fuchs
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] create earth wall totally nerfed ...
On 8/7/06, ERACC Subscriptions [EMAIL PROTECTED] wrote: ... Alright, if a player could JUMP on and over her/his own earth walls that would be better than now. That way my maps are not going to be TOO hard just very, very challenging. I want people to survive the quest and the earth walls are the best way (if a player can figure that out). Please see what you can do to fix this at least for jumping on and over created earth walls. I will be more than willing to do any testing and provide feedback. Thanks. I'm thinking that adding a new movement type, then redoing the jumping code to use it, would probably be the best way to go. Anyone want to comment or impliment this? -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
This is starting too look like the discussion on implimenting LUA for scripting. http://mailman.metalforge.org/pipermail/crossfire/2005-July/008844.html Also, IIRC, there is nothing stopping someone from putting scripts anywhere in the map tree. Every hook into a script that i've seen uses a full path (with the map directory as root). -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Some pending patches on tracker
On 7/29/06, Nicolas Weeger (Laposte) [EMAIL PROTECTED] wrote: Hello. Here are some patches i'd like opinions on: - https://sourceforge.net/tracker/index.php?func=detailaid=1389033group_id=13833atid=313833 New coins. I see no reason to not commit'em, it makes it easier to carry money :) The new coins where not meant to be given out by stores as change (except possibly if the store is very rich), which happens with this patch. Before the new coins can be used someone has to modify the code so the new coins are not normaly given out by stores. https://sourceforge.net/tracker/index.php?func=detailaid=1428566group_id=13833atid=313833 new face for booze. Looks ok to me, though maybe we want items to be seen from left/horizontally, instead of top-down like monsters? Items with a top-down perspective look good in the inventory, but look a bit weird IMO on the map. https://sourceforge.net/tracker/index.php?func=detailaid=1389432group_id=13833atid=313833 per-race hall of selection I like the idea, and think it should be committed (note that patch doesn't work, conflict in main.c, but shouldn't be hard to fix) I'd say commit it, then somebody design the halls. --- https://sourceforge.net/tracker/index.php?func=detailaid=1497089group_id=13833atid=313833 fix for some random items Indeed a weapon from Gaea is kind of weird :) I say commit. Gaea is supposed to be peaceful, and AFAIK there is no role playing background to this. For the alchemy recipes that reference the items removed from the game, change it to some other comparable item. -- https://sourceforge.net/tracker/index.php?func=detailaid=1526745group_id=13833atid=313833 new serpentman images They look much better than the ones we got, i'm for'em!! I would commit. -- https://sourceforge.net/tracker/index.php?func=detailaid=1073461group_id=13833atid=313833 pshop floor2 Now that's an old one, but should be committed imo The original mapper has some plans for floor2 (an actual shop), so I wouldn't commit this. Instead, set it to either pending or closed. --- https://sourceforge.net/tracker/index.php?func=detailaid=1216811group_id=13833atid=313833 send more detailed information to client It's broken apparently Also there was no consensus on whether we do want to send more information to client or not This would make scripting, and bots (except for implementing the protocol) a bit easier. Otherwise it makes the protocol more complex. - https://sourceforge.net/tracker/index.php?func=detailaid=1382884group_id=13833atid=313833 changes to wraith race Anyone tried it, and noticed any unwanted effect? I think this was still under debate. Looks fine to me though, but it may upset some existing players. Also make sure that the player description is changed for wraiths, so the new features are noted. ... -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Deleting DM players, wasRe: Server setup an Debian - newbie
On 7/23/06, Penbrock [EMAIL PROTECTED] wrote: ... I do have one other issue now. I have one player I use just for DM. How ever when I log him off the server crashes every time and I have to go restart it. Is there an easy was to delete that one? I tried to just quit the player but it does not delete it. This is how I would normaly do it on my machine: Erase the player's name off of the dm list if it is on there (should be somewhere in /etc/crossfire/ or /etc/games/crossfire or something like that). Then delete the player's directory (should be in /var/crossfire/players/ or /var/games/crossfire/players, etc). I have no idea why its crashing, exept possibly some library or something that wasn't installed just like the plugins. Also I want to note that there are some scripts included with the source code that automaticly restart the server after it crashes (along with dumping it's core, and doing a traceback). -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Ideas to make DM quests easier to manage and setup, was Re: 2.0 release
On 7/22/06, Nicolas Weeger (Laposte) [EMAIL PROTECTED] wrote: I am also doubtful that changing game mechanisms is the top issue for a stronger community - rather, that's making the game attractive and fun, by proposing events in and around them. Many MMORPGs feature special events around their games (contests, one-time special quests, etc). I think that should be investigated for Crossfire. IMO, we need more of these. Adding some way for mappers to use the date to control events on their maps could have a somewhat similar effect, but would be less interesting to players. We did that on Metalforge a few times, a few DMs. Drawbacks: * it takes time to plan * it takes time to actually eg put items, create stuff, and so on I don't have the time to do this, but would some semi-standardized quest types, and premade maps (containing objects requiring minimum modification, and/or a script to check player's status) to aid with those quests help? * it takes time to run, because people will connect to the game and want to play Possibly make the event last for a day or two, but that would make things harder to plan. * it takes many people to handle everything Would some premade scripts to manage dm quests help? * also note time zone issue, too Another reason to make events that last a few days. But i'd be ready (and eager!) to help do some events from time to time. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Server setup an Debian - newbie
On 7/22/06, Penbrock [EMAIL PROTECTED] wrote: Good morning all. I have installed the server from the Debian apt-get and it installed fine, or so I thought. It seems that the .deb package does not install the plugins. Weird, usually the plugins are includes with the server, and run by default. It could be that they where placed in another package, but I doubt that (only packages that look like they would logically include them are crossfire-server and crossfire-common). Where can I find the doc's for an old fart just learning Linux to get the plugins compiled? No such documentation exists AFAIK (plugins are application specific most of the time). Also I don't know of anywhere to get a individual plugin, except for the source code. So ultimately the easiest solution (for those who know how to) would probably be to compile the server from source. P.S.: Anyone want to get hold of the maintainer of the crossfire Debian packages, and see what he knows? -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Server setup an Debian - newbie
Ok, it seems like the package has been fixed, and is waiting to be uploaded to the debain servers/mirrors. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=379348 -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Metaserver reporting and accuracy
On 7/18/06, Mark Wedel [EMAIL PROTECTED] wrote: Alex Schultz wrote: Either way, perhaps another thing that would be good on servers, would be automatically setting the afk flag if they are idle for more than a certain amount of time, and if they become active again, it will unset the afk flag, unless they turned it on manually. IMHO that behavior would make not including afk players in the count, much more useful. That would almost go into yet another category - 'idle'. I'm not sure how true it is, but I can certainly envision that there are players online who are idle - they are waiting for something interesting to happen, partake in chatting, etc. So while idle, they are effectively around. But that may be over thinking this problem here. IMO, a timer for AFK status is probably the only way that the whole afk thing will get used by most people. Another thing is, should an other status be implemented to tell if the player is actually playing, or just logged in to chat. This could be taken farther to add commands to the protocol so connections to the server can be set so the player can't do anything but chat and check other player's statuses, since oldsocketmode uses food iirc. The result of this may be a larger player community, but it could eventualy turn crossfire into more of a chat protocol than a game. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
What I'm inferring, and my op pinions: Summary: While 2.0 should be a significant release, the majority opinion is that it should not take years. This makes it difficult to implement what everyone wants, etc. I think 2.0 should be the point at which most issues that we have known about, but haven't fixed, should be fixed. Additionally, the game should be made easier to use (more graphical interfaces on the client side instead of typing in commands constantly), and have a significant amount of balance issues fixed IMO. Another thing is that, I think we should do something to encourage developers to join the project. Finally, a stronger community of players could help this game gain popularity, which would result in more developers. Gaining developers: To get new developers, we first have to have them gain interest in the game, this would fall under building a stronger community. Second, I think reorganizing/restructuring the code into a more logical form, as it is been discussed, and revising/creating more documentation will make it easier for anyone interested in contributing to the project to contribute. Strengthening the community: On the community side, we need to encourage player interaction, both in and out of the game. One way to boost in game interaction would be bolstering the player economy. However, that will probably not be done in time for cf2.0. For the community out of game, make it easier to find resources like the forums, and the wiki. Additionally, make it easier to join irc channels, possibly by putting a java applet somewhere. Another thing that could be done to aid the community, both in-game and outside of the game, would be to setup a method to connect to servers, just for the purpose of chatting with people who are playing (oldsocketmode uses food iirc). Another topic of communication between players, would be the inter-server chat discussed a while ago. My opinion on release numbers: Once we have more developers and enough are willing to volunteer, it may be a good idea to appoint some people to maintain the stable branches. Micro releases: bug fixes, and addition of small features Minor releases: Features involving significant changes Major releases: Huge changes in game play, major overhauls, milestones in development Finally, i just want to note that our next release could be 1.10.0 instead of 2.0 if we need more time for cf2.0. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] on the delay of sending on ground list when player is moving
Just dumping this here: On the forum, Monger has suggested that the list of items on the floor, be delayed from updating while the player is moving. http://forum.metalforge.net/viewtopic.php?t=1492 He also suggested that this could have the potential of saving resources on the server. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
On 6/9/06, Nicolas Weeger (Laposte) [EMAIL PROTECTED] wrote: Hello. I'm feeling ambitious, so here's a quest management system proposal :) Of course, whether I (or someone) will actually implement it isn't yet sure ^_- Quests should be finite state automates. Meaning different states, with transitions between states, with conditions for those transitions, etc. Each state would specify special behaviour for NPCs, texts so the player knows the quest status and what to do (or at least some hints). Also there would be the rewards for completing that state, everything needed. Transitions should describe what the player should do to actually change states. Good idea to keep branches, and subquests (which you can't do after the quest is over), etc. My idea is to have quest files. Each quest would be one file, describing all states, transitions, including all information on what NPC's behaviour to change, rewards, and so on. If required, a quest file could be accompanied by some special maps, archetypes, anything specific. The quest engine would, at start time, read those files, and process them. It would then, at map loading time, add revelant hooks to NPCs, or track global events (for instance follow player movement to know if they do what is required to complete a task). It would also keep, for each player, quest status, and such. Advantages I see: * quest's information is in one file, it's easy to see globally how it works, versus today's dispatched in maps, making it hard to look at, and check whether it's broken or not * as a correlary, adding/turning off a quest means moving one file (or a directory) Can get a bit wierd if done just on one server. * it wouldn't not rely on the hacks i did for the first basic quest system. I don't really like'em anyway :) * we can think of DM commands to look at quests, know what quest a player did, reset quest status. Maybe even dynamically alter quests! *g* * we can add a quest editor, probably included in the map one :) Drawbacks, opened questions: * one could change a map without updating a quest, thus it could be become broken - server should try to handle that graciously, and report it in any case * to have a really powerful quest system, and fun transitions (from bashing a specific monster to having 3 players do a special dance at a certain time), the conditions / transitions will require a full scripting language. So either reuse an existing one (Python, maybe? Or LUA? Or anything else?), or make our own - I'd favor reuing existing one, to avoid making Yet Another Script Language. Though of course if we use Python the Python plugin would become mandatory. Some sort of scripting language being mandatory on the server side will probably encourage it's use by mapers. It may be a good idea to discuss implimenting LUA, since it has a smaller footprint, over using the existing python plugin. * this quest system could be done either at server's core level, or as a plugin. Last option would require some changes in plugin architecture (basically move plugin handling from server part to common lib part, to add hooks at a basic level. Also add interplugin communication). * tracking player behaviour could be resource intensive - that will need testing and addressing if required :) I like the idea of using it as a plugin. Heck, I may just start working on that soon if I'm feeling in a good mood :) I'll add that proposal to the wiki when it's back up, of course, so everyone can poke it ^_- -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Partial transparency
Just want to note that one trick used by mikeeusa and inycino on cat2 (mikeeusa was letting players customize their gfx if they reached a certian level), was to use a checkerboard pattren of transparent/nontransparent pixels, to achive a ghostly effect. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] lighting LOS redo.
On 5/22/06, Lalo Martins [EMAIL PROTECTED] wrote: ... Having spent most of my last two working days implementing a colour picker :-P I must say I like the idea of hue/saturation; it's perfect for this purpose, as it completely describes a light colour. And you can use one byte, wasting no bits, and have great resolution; 4 bits of hue and 4 of saturation is pretty good. Of course, people don't know how to write their favourite colours as hue/saturation pairs :-) but they can open up the gimp and get the correct values from the colour picker therein. Or an implementation in the map editors. This will probably be requested frequently once the lighting code is redone. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] lighting LOS redo.
Just want to bring up the possibility of mirrors in the game (in terms of the general lighting level) and ways to make lights move to create more visual effect (could the animator plugin work?). -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] New bot flag
On 5/20/06, Nicolas Weeger (Laposte) [EMAIL PROTECTED] wrote: Hello. I just added a bot flag, for players. To activate it, a client just has to send bot 1 (or anything atoi will recognize as non zero) through the setup command. When activated, this flag will make the player have a proeminent [BOT] in who output, and more important this player will not be counted in statistics sent to metaserver. Both will probably help players a lot, once the bots adapt the flag. This lets us send only relevant information to metaserver, real players :) Unfortunately, some servers seem to purposely boost their player count, so new players will connect to their server. This IMO should be taken care of at the metaserver. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] server commit for map2 support.
I would like to ask a few questions in terms of making maps and archetypes. There are currently archetypes for chandeliers, would it require more code to make these appear above players? Same for elevated parts of towers, and the back of some buildings. Second, what are the chances of some sort of vertical tiling being introduced? (even though this is unlikely) -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Re]Player Owned Shops
On 3/22/06, Mark Wedel [EMAIL PROTECTED] wrote: One thought that was expressed, but I don't ever think developed, was to have these naturally occuring ingredients actually show up in the wild. Thus, on the world map, in the right places, you could find the various vegetation. Likewise, in dungeons, there would be some means of of digging for the raw elements. This doesn't completely fix the problem, but finding the basic ingredients should probably be a lot easier than it is now. There is something like this in the weather code i think. (yet an other reason to fix it) As for in dungeons, new code will be needed, or maps would have to be modified, so some walls can be destroyed by a mining tool of some sort. I think one problem is that if you play honestly, finding all the recipes within the game is pretty darn hard. Even finding basic recipes seems pretty hard. One fix might be to increase the amount of readable books that show up a bit (you can do 20 levels of a dungeon and only get a few recipe books). One other problem, which I think was discussed, is that the formulae file only has a basic 'diff' field to denote difficulty. These really should perhaps be broken out a bit, like: success_chance: base chances of success, in percentage success_increase: % increase/level above min_level your success goes up. min_level: minimum level you need to be to have any chance of success Thus, you could have formula set up that requires you to be at least 5th level, but once there, you can have a pretty good chance of success. Or you could set up formula that even at 20th level, your chance is pretty low, and it doesn't go up very fast. That could also make adjustment of the formula better. Two words: Dynamic Alchemy... If a quest should be required to create an object, the quest should probably include a rare ingredient or tool that is required to make the formulae. For example; a extremely rare metal ore, a spoon that doesn't melt or disolve when used to make some type of potion, or posibly a rare metal that is used to make a special tool used for a few recipies. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] CVS commit: maps-bigworld/scorn/shops
It is possible to obtain unpaid items from the scorn sale shop. Simpily sell them on the seccond floor in the booths , then pick up what you just sold. After that just go downstairs and WoR out. The only other soulution i can think of other than blocking spells in the back, would be to put more shop mats on the seccond floor Module Name: maps-bigworld Committed By: eracc Date: Fri Feb 24 03:58:02 UTC 2006 Modified Files: maps-bigworld/scorn/shops: scorn.sale1 Log Message: One is /supposed/ to be able to cast spells in the back of the shop. I designed it that way on purpose in the last edit I made. The mats already prevent one from using Word of Recall to remove unpaid items. I am changing it back. The following files had too many changes to show the context diffs here: cvs rdiff -r1.10 -r1.11 maps-bigworld/scorn/shops/scorn.sale1 -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] wrong cvs checkout command for world map
On 2/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: hi, the checkout command cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/crossfire co maps-bigworld on http://crossfire.real-time.com/world_map/index.html should perhaps be changed to cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/crossfire co maps-bigworld at least the second works for me and the first does not. I aggree with changing it, i doubt cvs.crossfire.sourceforge.net resolves to anything, while cvs.sourceforge.net is sourceforge's cvs server(s). -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Transport, monster, player sizes
On the topic of transports, and if they should be let through some exits, i think it would be a good idea to use a size field, in the exit, and object to be moved. This seems to have more advantages, and more ease of matinance than using a list of arches/races to exclude from using the exit. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
I have added a page to the wiki, where crossfire 2.0 features could be tracked. http://wiki.metalforge.net/doku.php/dev_todo/cf2.0 -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Polymorph etc
On 1/16/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: About polymorph, I'd like that spell to be fixed/redone rather then removed. Would this be possible? (I suggest doing it the nethack way, the users doesn't have controll of what he morphs into and he morphs into a few things during the course of the spell). Players are unable to morph with the spell in its current state afaik. The spell can morph monsters and objects, and changes them into an other random arch (that is a monster or object respectively). It currently only morphs what it was casted on only once. I also see no point in making working things plugins, it will make things slow, break things (and then it will be like most servers (IE: not MF) don't use this, it's broken, let's chuck it). I would think that would be more of an issue of if it is used in the maps distributed with the game. As a side note, cat2 and MF seem to have around the same amount of active players (excluding bots) atm. If Ryo etc want to work on something, as it seems he's itching to do, how about add a alchaholpercent variable and add the ability to get drunk? I wonder if that would be a good test case for moving things to plugins... Or perhapse fix earthwall and the invisiblity spell ( tracker)? Better to fix what's broken then fix what's working (rather then break it and slow the server down). Its broken? Going to check when my brother gets off of the other box. If someone want's to write plugin stuff how about add perl to the list of CF scripting languages? Any of these things would be a much more usefull waste of time, rather then breaking the server and slowing it down. Umm, afaik scripts slow the server down, when used. I think it may be a good idea to only have one or two scripting languages availibe for use with crossfire. (at least without a 3rd party plugin/patch) If two are used one should be made to execute more quickly and efficiently, but doesn't have to have many features, the other would have more capabilities. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] alchemy/alchemy
I don't mind renaming the spell. Another issue, if i recall correctly is that some book(s) tell the player to use the alchemy spell on their cauldron, not the skill; this has caused some trouble to beginning players before. Refferences in these books should be changed. On 11/5/05, Brendan Lally [EMAIL PROTECTED] wrote: Currently there are two concepts within the game world called 'alchemy', the first is a skill for the transformation of items, the second (which I was just reminded of today, having forgotten of it due to its general uselessness) is the spell alchemy which transforms items into gold. These two things having the same name is confusing, so I propose that one of them change their name. since alchemy.c is a file that deals with the skill alchemy, it would be more consistent to rename the spell. I propose the name 'aura of midas' although if someone else has another idea then that would be fine too. If it were the case that it were decided to keep the name alchemy for the spell, then notwithstanding the comment about source file names, it would be equally straightforward to rename the alchemy skill. In this case I would suggest something like apothecary as a suitable replacement name. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Changing Python scripts for global events
On 11/1/05, Yann Chachkoff [EMAIL PROTECTED] wrote: Le Mardi 1 Novembre 2005 17:42, Nicolas Weeger a écrit : ... I was wondering if it wouldn't be interesting to make the /python/event/python_xxx scripts simply run all scripts in a subdir eg /python/event/born/, or have the plugin do that itself. Sounds good. Sounds indeed like a good idea. I'd prefer to see the plugin do the job itself - it looks somewhat more logical to me. Agreed. ... -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Looking for volunteer wiki editors
On 10/26/05, Rick Tanner [EMAIL PROTECTED] wrote: Please contact me /offlist/ if you are interested in becoming an editor on the new Crossfire wiki ( which is running DokuWiki, http://wiki.splitbrain.org/wiki:dokuwiki) Nice, however there are, IMO, some issues with navigation, with the default template/theme that dokuwiki uses. For those interested, your responsibilities include: Importing and organizing the existing content from the freezope wiki located at http://crossfire.freezope.org/ Why? The new wiki will support revision tracking and revision control - which will allow users to decide what needs to be removed, revised, updated, etc. Creating a new site index of content for others to update and contribute to. Why? The current wiki as a sections Lore Legends and another section for Facts. Is that still necessary? Does those sections and their content need a different directory structure (or tree?) to follow? I don't think separate sections are needed. Most myths are originally based off of facts, right? What would be useful though, would be a method of obscuring spoilers. For that, a note pointing to a rot-13 encoder/decoder would probably work. Maintain the agreed upon or specified layout, flow and formatting going forward. Hmm, should start a discussion on that. Why? Well, neatness and organization counts! ;-) How quickly and how things move forward will depend on how many people contact me to volunteer. Thanks. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Wiki organization.
Since it seems like we are getting a new wiki, it seems as the format, and organization of it is up for discussion. Should in-game (map guide, etc) be seperated from out of game stuff (client help)? Should there be a section describing each server? Should there be a section describing each server's guilds? What to do about spoilers? (rot-13?) I am thinking something along the lines of this: main page - basic game info - newbie guide - world (includes lore in here) --- Place 1 --- Place 2 --- Place 3 - out of game help How to use client How to setup server - misc stuff about servers --- some server - some guild on that server (lore, etc) -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] noalchemy tile, to prevent repetitions of recent events
On 10/23/05, Nicolas Weeger [EMAIL PROTECTED] wrote: Probably simplest to just make it that if the space is no magic, can't do alchemy. That will break the guild alchemy room (no magic), and probably the alchemy shop too. Yes, it will break the guild's alchemy room, and several other areas. It may also be a good idea to prevent the use of alchemy on shop tiles. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] noalchemy tile, to prevent repetitions of recent events
As I write this, several characters on metalforge are performing alchemy in places like, the Hall of Sellection, /start/Nexus, and in the middle of scorn. Basicly, I think we could really use a tile, that prevents the use of alchemy. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] chat-embeddable in webpage
On 10/20/05, Lord Youkai [EMAIL PROTECTED] wrote: I've been wondering if there was a way to embed a read-only view of chat into a server's webpage. For example, DeviantArt has a readonly view of the shoutbox in a sidebar, when your not logged in. It updates only when you refresh (unless your in the shoutbox itself) the page. Perhaps a neat feature to add along with inter-server chat could be an ability to embed a view of the current chats on a server. Server - web page communication has been done, as Mikee has proved with his Most richest players list.. Just wondering. Not quite. Those are static pages from scripts, that prases the player, and unique-map data. There is one script in the server distribution, that generates a page, showing player's scores. To implement this, you would need to store recent chats somewhere. Most likely this would be in a file. Ultimately, implementing this seems kind of hackish, but may be posible to use scripts for the python plugin, that can be installed on a per-server basis. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] chat-embeddable in webpage
On 10/20/05, Joshua Wilson [EMAIL PROTECTED] wrote: ... Unless the server implemented a sort of light client interface? I'm not a client person so I can't really comment here, but could we have a client similar to an old telnet client that only subscribed to chat/shout messages? i.e. some form of bot that may or may not even need to login? Such exists, just send oldsocketmode without the usual bytecount, when you first connect. then you can see shouts, and chats, and use the who command. You can't easily use this interface for much more though, since it has become somewhat broken (you can log in, but the shout command won't work, chat will though; also when loged in, food usage applies). Additionaly, there is the posibility that it will be removed in the future, because of it being broken. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: New movement code. (Wraith stuff) (Please don't implement)
On 10/19/05, Anton Oussik [EMAIL PROTECTED] wrote: On 19/10/05, Todd Mitchell [EMAIL PROTECTED] wrote: I would also put forth an addition to the suggestions, the idea that etheral travelers would not be able to pass 'iron' either so it would only work against wood walls and stone and the like. That may work. That would make some areas completely inaccessible to an ethereal player unless aided by someone corporial. Many maps may need changing as the result if this is implemented, but I can see this working. I would suggest preventing such players from passing walls that have nomagic set on one of the items on those squares. This would highly reduce the amount of maps that would have to be changed, to prevent abuse of this feature. Where map makers want to restrict players from passing through walls, the nomagic flag is used already, to hinder Dimension Door. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Unban me
On 10/10/05, Vernon T Rhyne [EMAIL PROTECTED] wrote: ... laughs That hasn't, and will never be the case. Rule enforcement at all levels is by whim and mood, as with most clique-managed open-source communities. It's undoubtedly a major reason that the wordlwide crossfire player count is in the hundreds (or less), rather than thousands or more. I grant that I'm a largely outside observer, but the general politics of crossfire ensured I'd never step inside. ... Can you please elaborate on this, and give examples? -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Bandwith ussage too high?
There has been a discussion on IRC about Crossfire's band with usage. One suggestion, is to store the information about static objects in maps, client side. Every time an animation changes state, data is resent to the client. This supposedly uses a large amount of bandwidth, compared with everything else. Why not send the animation once, and have the client repeat it by itself? How would glowing crystals, and gates be handled? -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Summon pet monster
On 9/29/05, ERACC [EMAIL PROTECTED] wrote: ... Isn't this what 'invoke is meant to do? If 'cast will do it now then why have 'invoke? Seems to me we should either leave 'cast as is or make that change and remove 'invoke. There is no reason to have both. I vote to leave 'cast as is because I have an oodle of key bindings using 'invoke. :-) Cast readys the spell for use, while invoke imediatly uses the spell. Bolth have their place, but cast doesn't accept arguments like invoke does. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Extensions to building
On 8/16/05, Mark Wedel [EMAIL PROTECTED] wrote: unique floors in random maps will basically do nothing at all, or worse, really screw things up. Here [INSTALLROOT]/var/crossfire/maps is used for saving overlays to maps (dm made, or from weather). Though there are some issues I have seen with overlays. Namely, if weather is enabled and a dm tries to save an overlay (I forgot what the result was, crash, or just didn't work). Another problem I experienced is a crash resulting when maps, which just had an overlay saved for reset. I also think that there are issues determining what created each overlay. I think that this is probably what should be used for saving these maps. Though the code for overlays needs improvement. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] treasure chests wealth
On 7/10/05, Mitch Obrian [EMAIL PROTECTED] wrote: Is difficulty calculated by the server or must it be set in the headers btw? AFAIK, if it isn't set in the map, the server prases the map, and guesses it. -- -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] new characters unable to use skills
Some players have reported that in rare cases, characters they just created (inculding going through the hall of sellection), are unable to use most of their skills. I don't have any information useful for debuging this, except that the objects for the skills seem to be in the player's inventory. (listed by commands, etc), and that once they die, they can use those skills. Tracker item: http://sourceforge.net/tracker/index.php?func=detailaid=1224351group_id=13833atid=113833 -- -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
