Re: [crossfire] Re: In-game games
On 7/3/05, Nicolas Weeger <[EMAIL PROTECTED]> wrote: > Also, I see those games as optional (player says whether to do'em or > use skill the current way). So old clients retain the current > behaviour, and new versions let players play mini games when they want > (so you can pick a lock every now and then). I like the idea of minigames, but if you make it optional (and more time consuming) what would be the benefit of doing it manually? Also what advantage levelling up in the skill would give you in the manual game? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: In-game games
On 7/4/05, Nicolas Weeger <[EMAIL PROTECTED]> wrote: > It could be the fun. Also, maybe the skill could give more exp > if done manually. > For instance lock-picking : more time, less rare picks to be > used, better chance to actually correctly use the pick, and so on. Sounds good to me! ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] In-game games
On 7/4/05, Sebastian Andersson <[EMAIL PROTECTED]> wrote: > On the other hand, it would be fun with social, multiplayer, mini games, > like chess, go, checkers, kalaha and what not to be played against > other players in the guild houses or special game houses. There is already a chess club in Scorn. Implementing similar board games in the same way should be quite trivial. > If the clients could show a second map with smaller tiles (almost like > the magic mapping spell) and one can send mouse clicks from that map > to the server, most boardgames could be implemented on top of that. That approach is perhaps less trivial but can allow more complex games to exist. Anyone feel like implementing monopoly? :P ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Random ideas.
> Andrew Fuchs wrote: > > That brings in the question, of if there should be a cartography > > skill, and if map makers should be able to restrict it's use on some > > maps. Thus brings out an interesting idea - map shops. You buy a map set in a shop, and when you enter a map, if a map for it is on a map set you have, you get a map of it! ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: Random ideas.
On 7/5/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > I'm inclined not to raise the cap. It's basically a never ending max if we > do. Raising the cap (or, indeed, removing it alltogeter) would change the way the game is played. It's an interesting idea, but I feel it would cause more problems than it will solve. If someone wants to try it and test it out It'd be interesting to see the effects though. As for getting rid of stat potions, they are already useful for raising stats. Casper's headcutter gives bonuses along the lines of (int +8) (str +3) as a lot of stat potions were spent improving it (courtesy Mith/Wumpus). Perhaps allowing weapons to be improved further or more easily (changing a single value in the config file) would do a better job at getting rid of the stat potion buildup. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] RFC: Wild idea to make experience more interesting
On 7/5/05, Lalo Martins <[EMAIL PROTECTED]> wrote: > What I thought is, by mass-slaughter, you can, as reported in that > thread, get to level 90 quite fast. This makes it more or less > mechanical for the level-seekers - and a mechanical game gets boring > quick. It also makes it uninteresting for the game-explorer-types, who > will try each of those dungeons once then leave in disgust, back to > their alchemy labs. > > So I thought... a very-very-high-level character should, supposedly, > have a wide range of skills, no? It's weird that someone is level 90 > and only have three or four skills with levels above 10. I recall a while ago cavehippo proposed an interesting modification to the skills system. Instead of contributing to a specific skill every cast contributes to sevearl skills (by a positive or negative amount). This will result in an overall more balanced characters IMO, but would require a rewrite of most of the current skills and experience system. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: Random ideas. (topic split to resistance caps and interaction with )
On 7/5/05, Alex Schultz <[EMAIL PROTECTED]> wrote: > > Yeah, now that I think about it, keeping the the cap at 30 except making an > exception for equipment where equipment can raise the stat up to a higher > value > (I personally thing 35 would be sufficent, 40 or 50 seem too extreme) Although everyone seems to like it personally I can't say I like the idea very much. First you raise the stats to 35, then to 40, then to 45, and so on. I think stat limit should either: * stay where it is, and stat potions be found some other use, or * remove the limit alltogether, but make the chances of gaining the next stat lower with every new stat gained. (if this is done stats should also be fixed not to wrap around to negative too early or someone will complain) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] RFC: Wild idea to make experience more interesting
On 7/6/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > At higher levels, the traps don't give much exp, but also aren't dangerous. > Is there really any traps out there (save for perhaps rune of death) that are > of > any danger to a level 10 player with full hp (disarming traps when you are at > 10% of your hp is pretty stupid after all). And I think the answer is > basically > 'no'. At the same time, the amount of exp you get get at that time for > finding > and disarming traps certainly doesn't keep up what you get for killing things. I agree. However many maps (e.g. Humanoid TC) currently increase the danger by having several traps. It is quite easy to trip several of them when disarming the chests there. Forgetting about them and just opening a chest around levels 25-30 is just dumb even for a lvl 100 character. Maps/random maps would need to be searched and changed to replace maps with many small traps to have one large high level trap. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Client display issue
On 7/6/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > However, on corrupted maps, that does not fix the problem... It happens very infrequently, but from time to time the server poisons the maps with black tiles, which looks alike to a gap in the fabric of space. Although it's a good effect, and goes a great way of showing that the universe we live in is fragile, I don't think it's intentional. Has anyone else noticed this or knows why it happens? I'd hate something like this to happen to my apartment/guild. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] RFC: Wild idea to make experience more interesting
On 7/7/05, Robert Brockway <[EMAIL PROTECTED]> wrote: > In real life some people are highly specialised (eg their work and play > both largely revolve around computers) while some of their co-workers may > have boarder skills (they paraglide or play a musical instrument as well) > while others are true generalists. I think the game is modelling this > very well at the moment - you get good at the skills you exercise. Actually I was thinking the opposite... All high level players end up becoming very good at almost everything. In a way this is benificial if there is only one person playing, since it allows the player to do far more than he would otherwise be able to. Also this approach is very powerful and flexible. It doesn't matter what class you are, you can always pick up a new skill (from a scroll or similar) and start developing a new skill. On the other hand this does not encourage cooperation between players. Most online multiplayer RPGs have character classes set up in a way that limits the development of a character. For example you end up with some classes that are damage dealers - they are able to quickly kill. Some others are damage absorbers - they are able to absorb a lot of damage without dying. Yet others are healers - they repair the hurt players. These classes are limited, and strongly encourage development along the class line. A generalist on the other hand will just end up being not very good at anything. That way players are encouraged to play with each other, not "as well as",as most of crossfire seems to do. I don't know of a good way of doing this without ruining single-player mode, or even if it is something that would be liked, but I feel a change like this would improve player interaction and would result in player communities emerging. If such a change is implemented it should definately be there as an option. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Alchemy classroom map
Hi, I submitted a patch to the tracker (1255825) adding a basement map to the potionshop in scorn. It is an alchemy classroom map, and costs 2000 platinum to enter. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Metalforge down?
On 8/8/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > I suppose it could be a malicous player casting hundreds of runes on some > space which some player sets off. but otherwise, if anyone has a clue, let > me know. Instead of processing each effect individually, would a better approach not be to have a single spell effect per tile and add to it? For example instead of having a stack of fireballs from meteor swarm or banishment on one square, have one that has "Time To Live" foo. Damage dealt can then be deduced from how long it has to live (a spell that has longer to live should cause more damage as it is more powerful?). It can then decay in strength with time, and if any more of the same spell is cast on it, the new spell can simply increase the time to live, and therefore strength and damage dealt. Other spread, damage, and decay-related parameters could then be added to make this more customisable. If needed it could possibly be made to decay along some decay curve, but that would be more CPU-intensive. I know this approach is very different from what is being done now and will proably require substantial changes, but it should prevent single players from being able to grind the server to a halt, as after the initial explosion it will not matter if you have one fireball going off or a thousand. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Alchemy classroom map
On 8/12/05, Robert Brockway <[EMAIL PROTECTED]> wrote: > 2000 platinum for a course? Outrageous. Don't you know poor students > save for months (or take the money from a bunch of silly ogres) so they > can take these courses. They just want to get an education so they > can get a job as the alchemist to a rich king. It is expected that anyone experienced enough to teach will be able to easily afford it. As for the students the entrance is free. I think it may be a good idea to evenually move the map out of scorn to brest, and add some more classes and tradeskill training centres. Or maybe navar? I recall some town had a University that was not linked against anything? Some day... ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quests ideas, continued
> * when the quest is completed, keep tasks for later referral. Or maybe > remove some? I like the idea of having a quest journal someone proposed earlier, which is a container eith entries you can read, which will tell you about a quest. This should cater the "explorer" type of player, who wants to collect every completed quest entry in the game, as it will give them something to remember the completed quests by. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quests ideas, continued
Also there should be the ability to abandon a quest, so players don't end up with 50 or so quests building up which they no longer can or want to do. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] What did I do wrong?
Yesterday I completely removed old copies, and checked out CVS maps, server, and client using developer CVS, and compiled them all. I had to configure the server --without-x, but otherwise no special options were passed, and I was found to have all necessary tools and libraries needed for compillation. Upon logging in I saw this picture: http://antz.uwcs.co.uk/cf_duplicates.png Other tiles were not as bad, but there were usually 1-3 copies of everything on every tile, and things like boulder mechanics broke. I assume this is something silly that I did, but don't seem to find out what. Does anyone have a clue? Casper ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Map cache
This is an idea I had for a while now, but never had time to implement. If someone has some spare time and wants something to code something for CF they can try this. When the server comes across maps containing large amounts of items it takes a long time to load. While it is loading the whole server freezes for other players, and on very large maps (like the scorn sale shop or some apartments) this can take in excess of 10 seconds on metalforge. A solution I propose is to pre-load large maps and keep them around in memory in case they are needed. Whilst this option would improve the performance of the server like metalforge, it would cause servers with small physical memory size to start swapping the cached maps, and it would then not be beneficial. Therefore the map caching should be optional and off by default if implemented. Casper ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Map cache
> The file accessing code would need rewritten a little, although, if > you allow one thread to do all file loading, then it doesn't need to > be done in parrallel, Thread creation and destruction is cheap. If it is to be done it might as well be done properly. With one map loading thread the server will scale up to 2 processors. With m maploading threads, where m is the number of maps loaded, it will scale up to n processors, where n <= m+1. If a multi-threading of the server is to be done another aspect that may be looked into is the actual object processing. If there were several threads working away at object processing each tick they would be able to do the job much quicker on a parallel system. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Map cache
On 8/26/05, tchize <[EMAIL PROTECTED]> wrote: > And also, limiting the number of object on a specific square sould be a good > thing too. > It's such bizzare to be able to put 600 axes on one appartment square :s > Maybe, but how do you impose a restriction? Can I store 50 cauldrons? 10,000 platinum? 30,000 diamonds? Restriction by nrof would not work very well. Another approach is to restrict by weight, but that would not work either, as some things are small and heavy, whilst others are bulky and light. On the other hand if implemented people would be more willing to pay more for more appartments, would explore more, stockpile less, and maybe would even start using banks and imperial notes. I'm open to ideas. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Item stacking (was: Map cache)
On 8/26/05, Brendan Lally <[EMAIL PROTECTED]> wrote: > one way of dealing with this might be to check whether the item uses a > body slot, and make a determination based on that, but it doesn't help > much with things like books, which probably should stack in that way. I don't really like junk losing the properties of original junk. Sure, lying in a pig pile it seems like junk, but you are occisionally able to extract useful items from piles of things if you look hard enough. Also if you are keeping a shop you probably would stock a few axes and would want to be able to sell one axe at a time from the stock you have. As for things spilling over to neighbouring squares it makes sense, as there is only so high you can make a stack (the cieling being a natural limit), after which things have to spill over to adjecent space. But when that should happen is a complete mystery to me, and I can't think of a nice way of doing this vesides introducing a "volume" property to every item, and restrict players by volume as well as weight, and restrict squares by volume. Volume brings up the question of how big are things? Outside towns one square is one mile. Inside a town one square is half a building or a small house. Inside a building one square is somewhere between the size of a ring and the size of a dragon. This is not a complaint or anything like that, stylised representation of items is needed for playability and works very well, but it still leaves the question of how big things are and how many of them you can put on one tile. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Map cache
On 8/26/05, adam ashenfelter <[EMAIL PROTECTED]> wrote: > On 8/26/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > > > > > > Better long term would be for each map to have its own thread. With multi > > core/thread cpu's, this makes more and more sense. > > > > However, that requires some prety significant changes. First being that > > any > > function that declares any variables as static is not thread safe. > > > I agree, but what about multi process? That would require huge changes, but is actually a very good idea. If done really well it could even introduce load balancing where maps (processess) are transferred from busy servers to more free servers as needed. On a side note having a central dispatcher would be a design fault as: 1) It is a HUGE (and I can not stress enough how big the HUGE is there) bottleneck and will slow the whole thing down to the speed of I/O of the dispatcher 2) If the thing goes down (and it will go down) all other computers participating in running the server would become orphaned. If the server is modified in a more flexible fashion one node going down should not be critical to all the clients not currently on maps governed by that server. This is the scheme I propose for a distributed set of servers: First server to come up runs like an ordinary server. All other servers connect to an already known server, get a list of servers and their loads. A new server then takes half of the maps governed by the busyest server (servers would need to somehow measure how busy they are, either themselves or by election by other servers) and associates itself with all exits to the server, and transfers all players that are now governed by the new server. The new issuses to consider here would be player transfer and general server-to-server communication. Servers would need to communicate to each other everything a player is able to hear (deaths, says, chats, joins, leaves, etc), as well as be able to migrate players when they travel between servers, and agree on who controlls what area. This also brings up the question of trust, as it is a bad thing to allow a malicious player (with perhaps modified maps) to smuggle items into the game by connecting their own server. This general approach does have an advantage of not needing to be tread-safe though - if it runs too slowly just add another server :) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Map cache
Oh, and I wanted to add to that that when a server goes down, another server could take over its load, but states of maps and players on the server would be lost. They could send each other "alive" packets, and when a server has not replied for a while consider it dead and either hold election or decide from server loads who should take over the maps. Also when transferring a player server should be sure the server they are transferring the player to is there, otherwise report the exit as closed. Unique items, player files, and maps would also need to be distributed form server to server, which raises another problem. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Item stacking (was: Map cache)
And this is what happens when you allow developers from England to post to the mailing lists ;) Yes, your estimates seem very good. If others agree it would probably be a good idea to document all this somewhere and update the signs and so on in the game and maps. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Map cache
On 8/27/05, Mark Wedel <[EMAIL PROTECTED]> wrote: Catching up on various points: I have no plans, no do I expect to see any work on making crossfire multiserver distributed. The work to do that would be huge. At minimum, the gamealmost needs to be thread safe, so why not just do that? With multi thread/core processors hitting the market soon, it makes more sense (sun's 32 thread cpuwill be out sometime soon for example).For item stacking, since the issue here is related to performance, it would beraw number of items that don't merge. This may be hokey, but the goal here is to improve efficiency by reducing number of objects on the space, so we don'tcare actual nrof, weight, volume, whatever. We just care if the number ofobjects is above X, objects should spill over. This also helps out on the client interface aspect. In that case restricting the height of the stack to 3-5 objects or so, and then use "falling over" to adjacent squares that have 2 less objects or more (this will cause nice mountains of junk to form that have peaks, similar to how items stack in the real world), and not counting no_pick and weight 0 objects should work speeding up the server. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Server map redo: movement types
On 8/30/05, Brendan Lally <[EMAIL PROTECTED]> wrote: Additionally MOVE_HORSE, being much faster than walking, but lessand MOVE_WAGON, which would be able to carry vast amounts of items, And your face should change to a mounted figure or horse driven carriage. Maybe also include MOVE_SHIP when you get a ship, which can travel very fast, but can only dock in ports. Then you have to navigate between ports, or perhaps have director-driven shipping routes, so you get on he route and your ship sails itself using directors to your destination. Finally, instead of dragons teleporting you from A to B you could also get on a dragon (with a face change) and fly (maybe along flying routes like ships?) to other places. This idea is somewhat questionable though, as being able to hire a dragon and just fly anywhere seems like a far too easy way to travel. Also, it would be nice to change the face of the player under somemovement modes (raise the player a few pixels, and add shadow beneath them if they are flying, have only part of them visible above water ifthey are swimming), or the character on a horse if they are riding,this would give visual cues as to the state of each player.Also swimming should probably act like swamps, rolling to see if you are about to drown. Speaking of image transformations, when something moves from a square A to a square B it currently stays in A all the way until it jumps to B. Could the new protocol provide a way for the transition to take n seconds (or ticks or frames), so arrows would really fly, and monsters would walk at you instead of jumping, the land would scroll by as player walks on it, and spells would propogate more smoothly? I don't know if this is even vaguely possible given that currently CF is completely tile-based. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] fatigue
On 9/1/05, Mark Wedel <[EMAIL PROTECTED]> wrote: tchize wrote:>> You get fatigue by doing strenous things (swimming, flying via skill,>>attacking, moving a lot).>>> Or just being awake ? or it will not be fatigue but stamina :) Idea was more physical fatigue not mental. I personally don't want to have torest my character if I'm still wanting to play. I like the idea of fatigue, but in CF days are so short that battles often last for weeks, and players can happily survive on 2-3 meals a week. If fatigue is introduced in the same way, that you only need to sleep (use_skill rest) once in a while it would be acceptable. >> You lose fatigue by resting - this can basically be measured by the>>character having an action and not actually doing anything. Certain magic >>potions could also reduce fatigue. But should be temporary improvement followed by getting very fatigued after that. Overdosing should eventually make you so fatigued you die. Also fatigue effects should be incremental with time. So when fully fresh you start at full stats. Then, after about 30 minutes of play you lose a stat, after another 15 minutes another stat, then after 8, 4, 2, and then 1 for every other minute of play. When all stats get to 1 you should start losing hp, until you die from fatigue or use_skill rest. Resting on a bed should speed up recovery (or perhaps change how much you can recover, so sleeping on the ground will not get you very good rest?) > apply bed to reality? could be, but you'd have to record how long it was saved for (if I save and reload immediately, shouldn't be any advantage). IMO bed of reality should not change in functionality. That said, if the character is doing nothing - just standing there, I'd expect fatigue should drop pretty darn faster - it should drop faster than you get HPback for example. Staying awake is an effort. If you don't believe me try doing it for a week. So basically, fatigue would really come in to play if your doing continuous work, eg, combat all the time, flying around the world as dragon, etc. But onceyou stop doing those things, you'd get back to 0 fatigue relatively quickly. Although it seems what is being discusses here is physical tirednes like from running or lifting weights and so on, which is a different tirednes than that from staying awake. Perhaps they could be combined together so total_fatigue = waking_fatigue + active_fatigue >> If not carrying much, you wouldn't get much fatigue - thus, a lightly >>equipped person could run around all day and not have to rest much.>>> Race dependent? One could certainly add more variation - different races weighing differentamount, different carrying capacities, etc. But one issue is that armor is one size fit all - a halfling should rightfully have smaller and lighter armor thana human. Race and class items deserver their own thread, and IMO a very good idea if someone has the time to create new archetypes and add race/class restrictions to items. Other thoughts:One could give chairs and non savebeds some meaning - sit in one of those, fatigue goes down faster. This goes back to my use_skill rest idea In some states, even when idle, you can't get back fatigue. EG, if you'reswimming or flying, you can't be resting - if you just staying in one place, maybe you fatigue just doesn't go up quite as fast. A good observation. If anything flying and swimming should increase fatigue unless you are a firebourne and are flying (or a lizard person and swimming?) and you should only be able to use skill rest when on the ground. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: fatigue
This should be plain text. Sorry, gmail decided it wanted to send html emails for some strange reason and did not tell me. On 9/2/05, Robert Brockway <[EMAIL PROTECTED]> wrote: > On Fri, 2 Sep 2005, Lalo Martins wrote: > > > (My wife made a character who, by choice, lived off only alcoholic > > drinks. Yeah, a swashbuckler. I used to pile cups of coffee in front > > of her bed in the guild.) > > That's cool :) While we are on the subject of drinkings having effects > (such as coffee reducing fatigure) I've always thought that anyone who > over-indulges in booze should realy suffer a loss of Dex. Yes there is a > bit of coding in there. Drinking booze should cast confusion on the drinker. I have been unable to make a booze like that though despite trying, as confusion always seems to get cast in some direction from or around the player. > On the topic of armour types, rather than having Halfling armour, Human > armour, etc, we could assign a size attributed to all races and have the > character required to use armour of the right size. So halflings and > gnome would require small armor, trolls large armour and most other races > medium armour. This would reduce the complexity and would mean less work > when we add new races in the future. That is true. Maybe make weapons have race bonuses then? If an armour is specifically made to fit around a halfling, a gnome would not find it as comfortable despite being able to wear it. This would make adding races more difficult though. Also when (if?) sexes are added, male/female armour are different, although wearable by the opposite sex. Perhaps add a penalty for wearing armour of the wrong sex (as it is not suited well for your build)? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] International talk like a Pirate day.
> wtf is international talk like a pirate day? A day in the year when you talk like a pirate. Yarr! http://www.yarr.org.uk/ http://www.talklikeapirateday.com/ I think putting social clothing into its own section is a good idea. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Buildable Land Plots
On 9/21/05, Alex Schultz <[EMAIL PROTECTED]> wrote: > ISSUES: > -Where should land plots be buildable? I would say allow anywhere, on world map, but not in a city. I would also introduce some sort of land tax for every plot you have built up. Also when you first build on the plot, you "buy" it, so you pay the money, and get get a permit to build there. This raises some new issues: - Where/how to pay to buy a plot - How to determine who owns a given plot, and who the tax should be charged to - How to accomplish the previous two and keep the maps sellable between players If you do not pay up the land tax your most expensive plot wil be demolished, and the money salvaged used to pay tax for remaining properties. This carries on until there are no more plots to sell. I can see several ways of calculating the tax for a given plot. Either per region (so in scorn charges 800gold/plot/day, brest may charge 300, and navar 450. This approach would work but be inflexible. Another approach I can think of is to have a base price of plot, and then raise price for every nearby developed plot within surrounding 5-9 squares or so. Additionally extra tax could be imposed for every object stored in a plot as a way of cutting down on clutter on maps. If it was really wanted the object tax (or land use tax) could be made exponential after some time. > -When a map maker builds over a land plot entrance, what happens to > the land plot? Do not allow building over the entrance. That is a silly thing to do and would only be attempted by accident. > -What (if anything) should be done about the potential issue of > players trapping eachother in buildable areas. I can see this could become a major DM pain, but can not see much that can be done - there is already word of recall. Perhaps someone else can come up with a better idea for this. Additionally I have a few more ideas/issues to add to this. - Buildable altars - Buildable map entrances/exits? - When a plot is developed change the face on world map to reflect that. - (this one is harder) If a player buys a 2x2 set of plots, should they be able to build a house 4 times as big, and should the world map introduce a large building into itself whaen that happens? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Unbalanced spell types
On 9/26/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > That said, one thing I said long ago and hasn't been done is the idea that a > monster (or other object) no longer needs an archetype to cover the extent of > its image. With the big image support, a hill giant can be changed so that it > is only 1 square, but still appears 2 spaces tall. > > Likewise, demon lords could be greatly reduced in size - their full height > doesn't have to be set. So that can be done to also reduce the footprint of > many monsters, also fixing the problem to some extent. > > That said, some monsters, like dragons, can't really be fixed in that way. I can't really see how this would work in practice without confusing the player. When they are "behind" the monster in melee combat they would a) not be dealing damage unless running down, b) not be able to tell where they are as they would be obscured by the monster, c) be confused which part of the monster they can run into to deal damage, and why some monsters you can run into the whole of it, whist with others only into certain parts of them. Over time they would develop a habit of only hitting the bottom row of tiles for the fear of "missing" the monster and running into a room full of them. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Buildable Land Plots
Not tying down a deed to a space certainly makes it easier. Also combining building plans with deeds seems sensible, since a player would know what sort of thing they would want to buy. If I understand correctly, those deeds (like a tower deed) would only provide a base building which can then be expanded/improved using things from building shop. Another small idea - ability to name the map entrance as it will appear on the world map, like "Casper's home". This would allow players to easily find the right plot. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Buildable Land Plots
On 26/09/05, Nicolas Weeger <[EMAIL PROTECTED]> wrote: > Also could be based on local traffic in shops (ie if magic > shop gets much commerce, you don't have to pay much to sustain > it, but if no one comes, then you get to pay a lot, they don't > want to have too much losses!). Should the shops etc. not be player-run? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Buildable Land Plots
On 26/09/05, Nicolas Weeger <[EMAIL PROTECTED]> wrote: > > Should the shops etc. not be player-run? > > I guess we could have both. > But then, you'd need to have a drawback for running your own > shop (high rental fee? need to be there for the shop to be > opened?), else players could make much money... The drawback is that players would have to control what the shop buys and at what price - otherwise someone could dump a lot of useless stuff they can not sell on them and make them bancrupt. A player-run shop will not buy something they will not be able to sell for a higher price. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Buildable Land Plots
On 26/09/05, Brendan Lally <[EMAIL PROTECTED]> wrote: > On 9/26/05, Anton Oussik <[EMAIL PROTECTED]> wrote: > > The drawback is that players would have to control what the shop buys > > and at what price - otherwise someone could dump a lot of useless > > stuff they can not sell on them and make them bancrupt. > > I don't think that is the right approach either. Personally I would > favour the creation of an auction house, when an item or number of > items could be dropped by a player, and given a lot number, a reserve > price, and a time limit. What I propose is not too different, but has the advantage of scaling better with the number of users, and being more flexible. For example you can have a weapons shop which sells things a blacksmith makes. Therefore the same player can own a house of a blacksmith pattern which has its own smithery, and its own shop, which players can visit and buy weapons from. This can also be extended to other shops, like potion shops, clothes, armour, food, furniture, and so on. If (as a seperate patch) something like a cookery skill is introduced you could get bakeries, restaraunts, and taverns that are player-run too. Then the economy would regulate itself, without the need of artificially setting prices. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Buildable Land Plots
I agree there, but what happens when you want to build up (or down)? I guess you place a staircase up (or down), and end up on a new floor, which is unbuilt, and located above (or below) the previous map. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Buildable Land Plots
It seems there are two camps here: the "Players should build their own as it is a fun thing to do" and "players should get a pre-built map as it will make their life easier". I will propose a third, contradictory method, which sits in between, and will probably get ignored, as it will be more difficult to implement, but here we go anyways. A player buys a plot, and it starts off randomly generated. They can build the house themselves, or get themselves a house by contracting another player to build it. Something like "construction" skill would need to be introduced, so people can be professional builders and gain levels by offering their services as builders. Being high at the skill should probably decrease material cost to them, and maybe open up better construction materials (eg lvl 10 can make windows, at 20 you can place doors, at 20 stairs, and at 50 can build complex connected things). This way, a player not interested in construction can stay away from it, and for a player interested in architecture design will have a purpose in building things, and will want to get hired if not for the money, then for the ability to gain xp building the house. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Diseases question
On 04/10/05, Nicolas Weeger <[EMAIL PROTECTED]> wrote: > Hello. > > I fixed a bug concerning diseases that had a negative "value", but got a > question concerning maxhp: according to the doc, negative means > "permanent outside the host". And positive "max ticks the disease > stays". So the obvious question is: what about 0? Should the disease > stay permanent? Disappear right away? Disappear seems to make sense. (as in it has 0 time to live left) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Word of recall on another player?
On 16/10/05, Nicolas Weeger <[EMAIL PROTECTED]> wrote: > Hello. > > Right now you can't cast word of recall on another player, it's always > applied on casting player. > What would you think of enabling casting on someone else? > Of course, as Rednexela pointed out, you could annoy another player by > sending him home forcibly :) > Maybe then put a restriction, players must be in same party? IMO there is no real need for this. It is already possible to make a scroll of recall, and to carry a balm around to help others get back. Also, since the activation of the rod is not instant, it is possible for several people to use the same rod to go home. To do this use the rod, and drop it. You then go home, and the rod stays for the next person to use. This can be considered a bug, although I feel it is consistent with something one would want to do were they real adventurers. This feature also makes low level rods more desirable. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Love and marriage, love and marriage...
On 16/10/05, Lalo Martins <[EMAIL PROTECTED]> wrote: > Here's a small list of things I think marriage could do in CF: Some very good ideas, I'd like to see them implemented in CrossFire. Also adding gender at the same time would seem like a good idea. This does bring up a few questions though: I persume you would get married in a church, which means you would need to worship a god of some sort. - Should the couple worship the same god for marriage to work? Maybe allow marriages between worshipers of different gods as long as they are not enemies and there is no conflict with any of the gods? - Do we allow same sex marriges (I can see valriel rejecting them)? Should it be god dependant? Should some gods not allow marriage alltogether (like devourers, since the primary goal of getting married is having children, and this seems to go against the principles of devourers) - Divorces. Let's face it, relationships do not last for ever, and you may decide to go your own ways. Should there be a mechanism for terminating a marriage? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [IDEA] Reagents for cast magic
IMO this would make spellcasting less useful, as it would be easier to take a dragon and claw through armies of monsters, picking up reagents as you go. You can then sell the reagents to the poor spellcasters struggling to get enough for a zombie-killing cast. It does seems like an interesting idea though. It is sort of like alchemy but the kind you take around with you and needs less ingredients. If we are heading this way, why not just change the alchemy ingredients so they are easier to make? This seems to be the main reason it is not used too widely - ingredients are rare enough not to bother with it and look for ready-made things in shops instead. Maybe decrease the weight of potions too so you can carry many around with you and be a pure alchemy-based damage dealer. Cavehippo/mwedel's idea about long term food benefits seems good too, although not related to this thread as such. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Call for (new) high level (115+) monsters.
On 17/10/05, Mitch Obrian <[EMAIL PROTECTED]> wrote: > So the solution is that once you are lvl 115 you can > charm everything, yay, game is over. I disagree, a lvl 115 character is likely to be unbalanced, so there are still things to do, like raising your one handed and two handed if you are a caster, or vice versa. If worst comes to worst, you can sit at home levelling the hiding skill, or learning more about alchemy and such. Perhaps non-combat aspects of the game that may appeal to the player should be explored instead? Buildable land plots being one... building up, maintaining a social structure, starting clans, guilds, cities, countries, waging wars against other countries, etc. If the game allows for that it will be far more appealing to high level characters as oposed to "some new monster" which may or may not kill you, and if killed will not give any real benefit. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: New movement code.
Returning to original thread topic momentarily, ethereal movement should be allowed to all undead who are naked. This will only make the movement type useful for quests and will not give any combat advantage to most players (dragons being a partial exception). Maybe wraiths should get a special "wraith touch" attack skill (melee skill which deals level dependant damage, dealing ghosthit, drain, life stealing, and depletion)? As a counterbalance undead should not be allowed to swim or fly. I don't know why, but it seems more balanced that way. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: New movement code.
On 19/10/05, Anton Oussik <[EMAIL PROTECTED]> wrote: > Returning to original thread topic momentarily, ethereal movement > should be allowed to all undead who are naked. This will only make the > movement type useful for quests and will not give any combat advantage > to most players (dragons being a partial exception). Maybe wraiths > should get a special "wraith touch" attack skill (melee skill which > deals level dependant damage, dealing ghosthit, drain, life stealing, > and depletion)? I know this is now going off topic, but also if wraiths when naked could become stealthed and invisible it would add an interesting game style, where you would hide in walls, sneak up to victims, and suck their life away, one by one. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Love and marriage, love and marriage...
On 19/10/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > Most of the initial suggestions could for lack of better term best be > described as new party spells. Married characters, being what they are, > should > perhaps always be in the same party, so the spells work for them. > > In terms of sharing apartments, I'd think the guild idea, or buildable > houses > work in that area. That way, I can just as easily share a spot with friends. Having read the discussion which followed my previous post to this thread I have to afree with Mark here. Party spells and buildable land plots will allow enough flexibility to provide for most things suggested, and without any of the social problems we may run into as the result. If two players want to decide they are married they can get a plot and build there, and party together. If they want to get divorced it is up to them how they do it. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [IDEA] Reagents for cast magic
On 19/10/05, Brendan Lally <[EMAIL PROTECTED]> wrote: > On 10/19/05, Anton Oussik <[EMAIL PROTECTED]> wrote: > > IMO this would make spellcasting less useful, as it would be easier to > > take a dragon and claw through armies of monsters, picking up reagents > > as you go. You can then sell the reagents to the poor spellcasters > > struggling to get enough for a zombie-killing cast. > > You make an assumption that it can't be balanced in game. OK, but you would have to do it so as not to make alchemy even less useful - would you either carry about one easy to find reagent or find an easy to find ingredient, then a cauldron, and then risk your life making something that can cast the spell for you? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: New movement code.
On 19/10/05, Brendan Lally <[EMAIL PROTECTED]> wrote: > On 10/19/05, Anton Oussik <[EMAIL PROTECTED]> wrote: > > I know this is now going off topic, but also if wraiths when naked > > could become stealthed and invisible it would add an interesting game > > style, where you would hide in walls, sneak up to victims, and suck > > their life away, one by one. > > Would banishment also move through walls then? > > this is an interesting question, if you answer yes, then many undead > levels become too easy, if you answer no, then wraith become (almost?) > invincible. No, it can not, and no, it would not make the wraith almost invincible. Let me clarify what I have in mind then. (I have very little clue how that is implementable, this is just a concept thought) Upon creating a wraith gets a skill caleld ethereal_mode, which is only activatable when the wraith is not wearing or holding anything. When activated the wraith becomes invisible, stealthy, can move through walls, and can not cast spells, or hold items in inventory (except invisible ones of course), The only attack then avaliable is wraith touch, which deals ghosthit, depletion, drain, and life slealing. Without clothes wraiths are not very strong, so I do not see how it will make them overpowered. Running for the nearest wall will often be the best choice, only preying on the weak, but that will be the only way of surviving, since you would die from three hits by a powerful monster, if you can not life steal them as fast as they are hitting you. While in this mode the wraith ca not pick anything up, or interact with the environment, like push switches, buttons, or anything like that. This would also mean players can not take stuff out of treasure rooms... they can get in, fly though it, and then walk out again leaving treasure behind. They would not be able to steal it without completing the quest. Also you should not be able to go into void squares to get to other "floors" or mechanic sections of the map. You should be able to apply exits though, to get around between maps. There is howerver a case of the player going into the mode sneaking up to a switch opening treasure room, and then taking it out. The only way out of this I see is to only provide one way of leaving the mode once entered: by visiting some well defined set of points (like an altar of devourers, or a graveyard to posess a new body). This way it will be impossible for a player to either cheat in the quest or help other players cheat. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [IDEA] Reagents for cast magic
On 19/10/05, Brendan Lally <[EMAIL PROTECTED]> wrote: > On 10/19/05, Anton Oussik <[EMAIL PROTECTED]> wrote: > > On 19/10/05, Brendan Lally <[EMAIL PROTECTED]> wrote: > > > On 10/19/05, Anton Oussik <[EMAIL PROTECTED]> wrote: > > > > IMO this would make spellcasting less useful, as it would be easier to > > > > take a dragon and claw through armies of monsters, picking up reagents > > > > as you go. You can then sell the reagents to the poor spellcasters > > > > struggling to get enough for a zombie-killing cast. > > > > > > You make an assumption that it can't be balanced in game. > > > > OK, but you would have to do it so as not to make alchemy even less > > useful - would you either carry about one easy to find reagent or find > > an easy to find ingredient, then a cauldron, and then risk your life > > making something that can cast the spell for you? > > Ok, lets consider the following model as a starting point; > > there are 5 magic skills, let each of them have their own reagent. > > also allow 3 extra (general) reagents of varying price, call these > expensive1, expensive2, and expensive3 > > now, each spell would be able to belong to certain skills (more than one) > the 5 base reagents would only be usable by someone who could use the > associated skill. The 3 expensive ones would be usable by anyone but > no spell would use only them. > > The base reagents would all be cheap and plentiful (alters to generate > them for a couple of plat) > > I'm inclined to say that expensive 1 would probably be directly > purchasable (for 50-100 plat maybe) > > expensive 2 might be creatable with alchemy with ingredients costing > 500-1000 plat (ish) > > expensive 3 would be very rare, and not used or sold lightly. > > each spell then would need different combinations. > > firebolt might need 1 pyro token > burning hands 2 pyro + expensive 1 > faery fire 2 pyro + 1 evocation + expensive 1 > icebolt would be 1 evocation > icestorm 5 evocation + 1 sorcery + 1 expensive 2 > coldfront (a spell to replace icestorm at low levels, without the same > damage and range progression) 2 evocation + 1 sorcery > magic missile would be 1 sorcery + 1 summoning > small lightning 1 pyro + 1 evocation > steambolt 2 pyro + 2 sorcery +1 expensive 1 > charm monster 5 summoning + 1 sorcery + 1 expensive2 > comet 50 pyro + 10 evocation + 1 expensive3 > meteor swarm 100 pyro + 20 evocation + 3 expensive3 > > done properly, this would start to look like a periodic table, with > the start of the table having every possible combination of tokens, so > that mixing various combinations of reagents, the effects might be > guessable (ie, a spell needing 2 pyro + 2 summoning would probably be > summon fire elemental or something like that.) > > This could also make the spells easier to document (a diagram rather > than a big list as it is currently. > > The other nice bit about doing that, is that exp could be shared based > on the ratio of base tokens used, so it would be possible to level up > sorcery more easily. (in game terms it would make the different forms > of magic more integrated, and it far easier to have crossover spells.) > > If there are only 8 different reagents, then the easiest way to use > them is to equip them. If there are 'spell reagent' body slots, then > they can be equipped, and used if equipped. Yes, this seems conceptually easier than the currenly existing model. This could also be extended into alchemy so that it is just an extension of the reagent formula + fixing agent. A different fixing agent should be used depending on what you want to create, so if you want a potion you use water, other fixing agents for other things. This would fit in very nicely into existing alchemy model since only the formulae will need to be modified, existing code and unrelated formulae can be left untouched. Another issue I'd like to bring up is grace. getting rid of spellpoints will make grace stand out. If you ask me the model works, but it will stand out now that spellpoints are going away. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: New movement code.
On 19/10/05, Brendan Lally <[EMAIL PROTECTED]> wrote: > On 10/19/05, Anton Oussik <[EMAIL PROTECTED]> wrote: > > When activated the wraith becomes invisible, stealthy, can move > > through walls, and can not cast spells, or hold items in inventory > > (except invisible ones of course), The only attack then avaliable is > > wraith touch, which deals ghosthit, depletion, drain, and life > > slealing. > > > > Without clothes wraiths are not very strong, so I do not see how it > > will make them overpowered. Running for the nearest wall will often be > > the best choice, only preying on the weak, but that will be the only > > way of surviving, since you would die from three hits by a powerful > > monster, if you can not life steal them as fast as they are hitting > > you. > > Will direct attacks hit wraith stood in a wall (like they do in ADOM > with ghosts)? I believe they will with the current code. I have killed monsters stuck in walls before. > Will rings/amulets remain wearable? No. They can not pass through walls as they are, and therefore you can not take them with you. I say again, nothing worn, nothing carried. If it shows up in inventory, you can not take it with you. > I'm inclined to say that at least there should be a /big/ hit points > penalty as well (maybe 50% - though with a small ac bonus too ?) Create a naked wraith, try using it to fight something, and say that again. > > While in this mode the wraith ca not pick anything up, or interact > > with the environment, like push switches, buttons, or anything like > > that. > > Ok, so their weight would have to be zero too. I am not sure the server will like that, but yes, essentially. > Would you change the face as well, to give some clue they are in this mode? Being invisible will change the face automatically. It will be like wearing god finger. > > This would also mean players can not take stuff out of treasure > > rooms... they can get in, fly though it, and then walk out again > > leaving treasure behind. They would not be able to steal it without > > completing the quest. > > You need to deal with switching out of this mode inside the treasure > room (you try to adress this later) I think I do. > > Also you should not be able to go into void squares to get to other > > "floors" or mechanic sections of the map. You should be able to apply > > exits though, to get around between maps. > > not all boulder layouts are seperated by squares with no tiles on. True, but I do not see this as a huge problem if sometimes you can wander into a mechanism. x-ray vision allows you to see many of them, and that is not much of a problem. > > There is howerver a case of the player going into the mode sneaking up > > to a switch opening treasure room, and then taking it out. The only > > way out of this I see is to only provide one way of leaving the mode > > once entered: by visiting some well defined set of points (like an > > altar of devourers, or a graveyard to posess a new body). This way it > > will be impossible for a player to either cheat in the quest or help > > other players cheat. > > Alter of devourers might work, but there are maps that have alters in > dungeons, and these might get placed in areas where a player could get > stuck. > > Also what about a wraith that doesn't worship devourers? > > There are similar issues with graveyard placement, plus it is a little > illogical that a graveyard corpse should work, but a 'fresh' one > should not. Yes, I dislike both examples I gave myself. It seems something new needs to be introduced into the game, and placed around towns to allow wraiths get new bodies. Something not already found anywhere. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [IDEA] Reagents for cast magic
On 19/10/05, Brendan Lally <[EMAIL PROTECTED]> wrote: > On 10/19/05, Anton Oussik <[EMAIL PROTECTED]> wrote: > > Another issue I'd like to bring up is grace. getting rid of > > spellpoints will make grace stand out. If you ask me the model works, > > but it will stand out now that spellpoints are going away. > > Would spell points go away? > > To my mind they do different things, reagents limit the total number > of spells cast, spellpoints limit the rate they can be cast at. That is how I thought it would work. Otherwise it gets too complicated. In effect this is like having several large mana pools, I see no need to complicate it further by still having spellpoints. Also this will be a very significant change to the game magic works and I imagine a while before things will be worked out (like improvement potions, npc magic, and so on). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: New movement code.
On 19/10/05, Brendan Lally <[EMAIL PROTECTED]> wrote: > On 10/19/05, Anton Oussik <[EMAIL PROTECTED]> wrote: > > On 19/10/05, Brendan Lally <[EMAIL PROTECTED]> wrote: > > > I'm inclined to say that at least there should be a /big/ hit points > > > penalty as well (maybe 50% - though with a small ac bonus too ?) > > > > Create a naked wraith, try using it to fight something, and say that again. > > A lvl 100 wraith with high level karate is still reasonably powerful. Yes, but I want it to be playable like this, so someone might want to change to this mode and stay in it... for ever? A problem I see with staying in non-corporial form for ever is food. You would still use up food but have no way to replenish it. When feeding off others with wraith_touch food should go up as well as hp. Would this need a new attack type food_steal? Maybe wraith in this mode should also see invisible? > > > Would you change the face as well, to give some clue they are in this > > > mode? > > > > Being invisible will change the face automatically. It will be like > > wearing god finger. > > on a related but tangential point, would it be possible to make > invisible characters appear on their controller's screen? I am > thinking with the face having a medium alpha value, so that it appears > to be partially seethrough. I often find it hard when controlling an > invisible character to know where they are. I thought of that before, and then you will not be able to tell if someone cast reveal invisible on you. Maybe set to 75% transparrency for own invisible character? > > > > Also you should not be able to go into void squares to get to other > > > > "floors" or mechanic sections of the map. You should be able to apply > > > > exits though, to get around between maps. > > > > > > not all boulder layouts are seperated by squares with no tiles on. > > > > True, but I do not see this as a huge problem if sometimes you can > > wander into a mechanism. x-ray vision allows you to see many of them, > > and that is not much of a problem. > > yes, but there are maps designed so that x-ray vision won't let you > see them, where as your walking through walls would (scorn gatehouse > is an example of this). I still do not see this as a huge cheat to be able to see some mechanisms. I imagine ghosts in ancient castles could too! > > Yes, I dislike both examples I gave myself. It seems something new > > needs to be introduced into the game, and placed around towns to allow > > wraiths get new bodies. Something not already found anywhere. > > taxidermists? I imagine this should be a relatively big thing to shed one's body, so taking a physical form should require a ritual of some sort to be performed. Maybe a map with a large pentagram, with lots of people reading some prayers, and if wraith steps over the body and stays there for half an hour they get re-incarnated? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: New movement code.
On 19/10/05, Mitch Obrian <[EMAIL PROTECTED]> wrote: > Please do NOT make anyone able to go through walls. > Why is this idea being considered? It would make maps > useless. How would this make maps useless? ___ 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 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. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: New movement code.
On 20/10/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > But I do think giving someone permanent or at will ethereal travel will be > very powerful, even with some of the limitations. The fact is that lots of > maps > have enough wall space where an ethereal creature could effectively hide out > away from any attackers. I'd certainly much rather temporary items (potions) > be added first and see what that breaks. There is already a map which does that. You can find it in Lake Country , in the training tower, if you go up 3-4 floors. You can then apply a dust and gain ability to walk through walls on that map for a while. I imagine it does it with a force and checkinv in every space that looks like a wall. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] weather, lattitude, town location, and the world
On 11/11/05, Lalo Martins <[EMAIL PROTECTED]> wrote: > Now that some people seem to be working on salvaging the weather system... > > I remember one thing that was somewhat polemic about it, was the choice > of two *corners* of the map for the poles (nw and se IIRC), rather than > the north and south as would seem more reasonable. Yes, it made the poles smaller, and the equator larger, as should be on a circle-shaped thing it tried to emulate. Of course if you stuck the diagonal ends together you would end up with something relembling two cones put end to end, but it is a far better approximation to a globe than a cyllinder. > This does incidentally work remarkably well for Wolfsburg, which ends up > a hot, but miserably rainy town - as would be expected of a pirate port. > Scorn is also suitably temperate, and the "mushroom peninsula" is > tropical enough for its swamp. However, it can be argued that > Brest/Britany is warmer than it should. And I haven't yet seen > mikeusa's new region. > > Of use here could be Brendan's recent mathematical unit rationalization: > - 1 outdoor square = 1 chain > - the continent is approximately 1500 chains from N to S and from W to > E; about 18 miles, or 30 km. > - Earth (for comparison) is about 992716 chains from N to S (12409 > miles, 19970 km), and 1992112 chains around the equator (24901 miles, > 40075 km). > - So if Bigworld is more or less the same size as Earth (and Brendan is > correct), then this continent occupies about 0.075% of the W-E > circumference, and about 0.15% of the distance between poles. > - For another comparison, the Hawaiian island of O'ahu (where Honolulu > is located) is about 2500 chains W-E (32 miles, 51km) and 3280 chains > (41 miles, 66km). Since it's not as neatly square-ish as "our" > continent, we can say they have roughly the same area. I agree that Brendan's calculations make a lot of sense, and we are pretending that we live on a planet whilst hardly occupying an island, unless the planet is very very small, which means it is very dense and quite close to the sun to get its heat. Since there is a lot of radiation on it, there are many mutations, which lead to some strange monsters we seem to be encountering. As for an athmosphere... the planet is probably very dense. :) > Hmm. Maybe "bigworld" is not big at all :-P Brendan's calculations > still make sense to me generally, except that now I'm thinking about > one-chain-wide mountains and finding them a bit silly. But that can > pass, since those are relatively rare. Such rock formations may actually be possible, wih a hard surface and wind and such. Since the planet is not Earth and since we are willing to accept teleportation and beds to reality, then why not small naturally occuring rock formations? > On the other hand, fantasy worlds don't *have* to be the same size as > Earth. (They don't even have to be the same shape... a disc, with the > "pole" at the center, or a ring, or even the "normal" shape but with us > in the inside rather than outside, are all heard of; and many fantasy > worlds are simply flat - some discoid, some rectangular. So there. But > we'd better stick with almost-spherical, if for no other reason, because > changing the shape would probably require rethinking part of the weather > code. On the other hand, a rectangular flat world avoids problems of > projection, in case we end up mapping the whole surface.) On a scale a player would be playing at a 2D approximation would suffice. If a whole surface is mapped, it would probably be best to store tiles as 2D polar coordinates on the surface of a sphere, and when a player enters worldmap extract and send the appropriate coordinate tiles to the player. That way only the parts of the hugemap that players are on would need to be stored in memory. On the other hand the data structure we would need to store tile coordinates and code to approximate them to generate a 2D projection of what player sees may be both CPU and memory consuming. Then seas could be auto-generated depending on the altitude, and global warming/cooling flooding/deserting/freezing could take its normal cause. Having a true globe would open up new weather and other effects, such as calculating weather by determining the amount of light that hits the surface by using ray tracing algorithm, and from there calculating how weather changes. This could result in a very realistic weather model, but probably too computationally intensive for an adventure game (not a weather, economy, eco-system simulator with elements of real time strategy, sim city, the sims, and tux racer). However you would then be able to set rotation speed, sun brightnes, and planetary mass to inflence all other game elements in a consistent fashion. Umm, you probably can already with minor modifications. > For consistency reasons (since we don't have contact with other > continents, and what with dragons and magic, I believe we have more than > enough "technology"
Re: [crossfire] alchemy ideas (was: Idea for skills)
On 28/11/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > Nicolas Weeger wrote: > > Btw, it could be used for "secondary" skills (alchemy, woodsman, ...) > > skills only, not main combat ones. This way no penalty for > > fighters/wizards, just for players wanting to do other things than combat :) > > But I then wonder if an actual cap on exp/skills is needed, or if it would > be > good enough to give exp bonuses in specific skills for specific quests. Now that you say it, it seems like a plausable idea. Alchemy, woodsman, etc. are all closer to knowlege than to something else, so players can level in them like they do with academic subjects in real life. At the moment the main problem with it is: Eiher it is very very tedious to level, and takes many months to get to making simple potions, as you try to stockpile some ingredients, then eventually after dying several times and spending several thousand on extra ingredients, cauldron access, etc, make something that is cursed, and costs 4 platinum to sell. Or you can spend a few very tedious days iding altar ingredients and get to the point of making something usable. First approach is far too boring for anyone to seriously consider, and I think second approach is a cheat in a way, and needs substantial financial backing. Either way there is not much incentive to do so apart from selling the items for wealth, as by the time you can make the items you can either find them in dungeons, or can afford to buy them in shops. So, I suggest some interesting changes to how these skills can work, some alchemy-related changes in group A, and some general change in gorup B, which are not essential, but would complement alchemy changes. By "alchemy" here I mean alchemy and all related skills. A Alchemy related changes: 1. Do not award experience for identifying items. I find the fact that you can make summoned water (or get things from altar) and then say "What is it here? Ah, yes, here is a bottle of water! I now know more! What is it here? Ah, yes, here is a bottle of water! I now know more! What is it here? ..." quite silly, and would have complained about it long ago if it was not the only plausable way of raising experience at lower levels. 2. Players should only recieve more experience for alchemy by making formulae that are of difficulty comparable to that of their alchemy level. This is explained by the fact that you do not learn more by doing something you can already do well again and again. It is not challenging, and does not teach you anything new. 3. Players would only recieve experience up to a point (say, level 19, 39, 59, ...), after which they need to do an "exam" (I propose a combination of oral and practical, I was never much of a fan of written exams) to get the next level (and academic title), after which they would be able to get into the next institution, be able to make cooler stuff, and earn more experience and wealth. If institutions that taught them were dotted around world (so to level alchemists would have to move from place to place throughout their life) players would also be encouraged to explore. 4. However this does not encourage interaction between players, as you would end up having the alchemy crowd completely ignore the normal people, and so to compensate I propose that alchemy generated items do not sell well in shops (if at all?), and so to generate wealth alchemists would need to sell the items to other players. However if shops and altars continue to readily sell the items, or items are plentiful in the wild, this idea would never succeed, and so alchemy-generatable items should be removed from auto-replenished shops and altars, and be made rare in the dungeons. 5. Also, the institutions can act like hubs to alchemy-centered quest hubs, which would be mostly puzzle solving or humorous (eg. deriving ingredients to the next formula you are learning by solving a puzzle, and then getting an xp bonus when you succeed, or "Our neighbours complained to the city authorities that our emissions are dangerous to the health. They reported the smoke causes mutations with some other magical side effects. Go clean it up." for a more combat-oriented quest.). Since these quests should offer substantial experience in alchemy awarded (extra bonus that mwedel suggested), they should only be allowed to completed once. I'm not sure if the current quest system can accomodate this readily. 6. To compensate for the difficulty of advancing formulae should be changed to use more findable ingredients, as at the moment people simply do not bother - to level up making complicated potions you will never find enough ingredients, no matter how much you look and even hire others to look for you. If difficult potions are made difficult only by their difficulty it will add much more incentive for people to do them, especially now that most "alternative" formulae have been cursed to failure by the forces above... 7. Another incentive that c
Re: [crossfire] Tweaking alchemy
On 04/12/05, Andrew Fuchs <[EMAIL PROTECTED]> wrote:
> On 12/4/05, Nicolas Weeger <[EMAIL PROTECTED]> wrote:
> > Hello.
> >
> > I'd like to extend alchemy-like skills, probably with a 'cooking' skill.
>
> Aaronf0 said he would work on a more dynamic alchemy system, however,
> I have no idea if he has even started it.
>
> > What i'd like to do is:
> > * add a way for formulaes to never blow up, and just yield a specific
> > item when failed ('burnt cake'). This will make it safer and more fun,
> > of course this would be for low exp recipes (or for a skill having a low
> > skill => overall percentage)
>
> I think this has been needed for a long time. Though IMO the
> distinction between recipes that can be fatal should be made on the
> premises that the recipe has some magical quality to it.
Seems like a sensible idea, and one that is easy to implement.
However, you need lots of new foods archetypes (and corresponding
graphics), as these formulae should have normal food ingredients as
ingredients, so you now need flour, tomatoes, ham, milk, cheese (made
from milk), and so on.
This could also be a good time to include a farming skill.
Milk can be mined from a cow, and flour can be obtainable by using
some wheat in a mill, and wheat can be collectable growing in fields
(gaining the person some farming exp) and plantable using the farming
skill. The higher the farming skill, the more wheat should grow when
planted.
Milk can also use farming skill, and I guess one would get better at
it with practice, and be able to milk more milk from a cow if you are
good at farming.
However this needs cows, pigs, goats, rabbits, wheat, apple trees,
maybe some magical farm animals from which magical foods can be made
(like flying pigs for levitation food). We already have sheep and
chickens and geese, so that can be a start. Farm animals should be
able to asexually reproduce over time to account for cullings, so they
can be kept in captivity and reproduce. However they should not
reproduce too quickly (much much slower than mice) and maybe die of
old age after a while.
Charm monster can probably be adapted to have farm_mode, which will
make farm animals in the area to become your farm_pets and follow you,
until you get them into a closure of some sort and release the cows,
so they will roam within the bounds of the closure and be milked or
killed for food.
If this is to be a viable economic device cows should be scarce, and
be almost a currency of their own (Ukranian currency is theoretically
based on the value of a horse, so this is not far-fetched). Since they
reproduce on their own and can be sold, this should be the primary
means of generating farm animals, and they should not occur often in
the wild. Maybe make a farm market that sells very expensive farm
animals, far above the in-game market value.
Also things like summoned food and golden unicorn horn should be
changed, since they effectively make cooking skill useless by giving
infinite supply of infinite supply of food.
> > * add a 'min_level' for a recipe, which you couldn't do if you're not
> > high-level enough (or with a *really* low probability). Just to feel the
> > meaning of 'experience' :) And to prevent just trying a high exp recipe
> > over and over again.
>
> If a level 1 player tries a level 110 recipe repeatedly, maybe give
> him a few warnings, if he ignores those kill him if the recipe is
> magical.
Maybe add an IsMagical flag to recipes, and treat magical recipes in
the old dangerous ways, but things like cooking, carpenting, and so on
in safe ways?
> > * then i'd like to add food-related recipes, like pizzas (yummy!),
> > bread, cakes, things like that. Of course i'll add matching archetypes.
> > And thinking of making use of 'keycode' field and using quests to learn
> > recipes.
>
> And add some "fancy" high level recipes. Preferably that don't blow
> up, but a loss of cash from expensive ingredients used in the recipe
> would be desirable.
Using quests to learn recipes? Does this make recipes spell-like (so
you enter 'cookbook list to view the recipes you know, and 'cookbook
make pizza to make a pizza?) or you just encounter cookbooks from time
to time?
> > Unrelated to alchemy, but I'm thinking on using the 'on_apply_yield'
> > field to eat (apply) food by parts (cake => 3/4 of cake => half cake =>
> > 1/4 of cake => nothing).
>
> Probably a good idea to allow the use of item transformers on these.
> (slicing knife)
Yes, a good idea. Needs yet more archetypes though.
> On an other note, more items that can only be obtained through
> alchemy, would be interesting.
Which need even more graphics. If someone made lots and lots of
different graphics it would be excellent (for sword-like things,
shields, cloaks, rings, armours, bows, amulets, potions, and so on).
Many of them could then be made into alchemyable items.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalf
Re: [crossfire] Tweaking alchemy
On 05/12/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > > As far as alchemy is concerned, an easy first pass would be to extend the > general store (maybe rename it grocery store or something) to include raw food > items, eg, wheat, milk, hunks of meat, etc. That still requires graphics, but > but doesn't a whole set of farms, etc, where one can go and gather this. Yes, in the short run this is a much better idea. However, a long term goal of a self-supporting economy based on inter-player interaction (where government-owned shops do not exist except to maybe provide some very basic food and weapons at time of war/famine/natural disaster) is IMO desirable. Then a community of about 200 players would be completely self-sufficient > The real question, I suppose, is whether there is a large number of players > that actually want to play farmers. Only if food is scarce enough for people to buy it, and people need to eat to survive. Currently many dungeons have a lot of food in them, there is the golden unicorn horn, and other sources of infinite food like summoning. Since low level characters need food as much as high level characters, but have far less means to afford it I am not sure how low level characters can survive other than by begging until they can afford to pay for food. Therefore as a skill farming is probably doomed to failure unless it is made very easy (generic ever-lasting self-reproducing cows, that can be milked every few minutes, etc.), in which case it would be more of a means of survival than a source of profit. So, you can farm your food yourself at any level, but if you are too lazy you can pay others to farm your food. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Wraith changes
Today I have posted a patch to the tracker, which can be found at https://sourceforge.net/tracker/index.php?func=detail&aid=1382884&group_id=13833&atid=313833 Repeating the patch description, it does the following to wraiths: >1 Wraith characters gain no food or health regeneration >by eating normal food. > >2 Wraith characters do not regenerate health naturally >at any noticable rate. > >3 Wraith characters deal more damage with life_stealing >than other players do. > >4 Wraith characters also gain food when they attack >using life_stealing. > >5 Wraith characters start with an extra skill called >wraith_feed, which deals life_stealing attack and >paralysis attack. > >6 life_stealing only works on living things now, and >specifically not on doors. > >If these patches are applied to a running server, old >wraith characters will be affected by change 1, 3, and >4, but are not affected by changes 2 and 5. Change 6 >affects all characters. The patch seems to work, but my biggest concern is game balance. On one hand, a wraith should be strong enough to suck life from victim faster than victim sucks blood from it, since if it is losing hp it will die. I feel a few more people should try the new wraith out before the patch is applied to the main tree, as it is a sifnificant change to how the race is played, and may not agree with other people's perceptions of what this race should be like. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Wraith changes
On 17/12/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > Quick question - does this mean the only way a wraith gets food is by life > stealing attacks? Yes, although magical means (like golden unicorn horn) will also work. Also food that restores hp has no restoration effect, although food that restores mana works as with any other characters (but restoring mana only). > If so, I'd think they need to get given a very high sustenance type of > value - > otherwise, I'd think you'd get a lot of starving wraiths at certain times, eg, > you're hauling your loot of the dungeon and don't have anything convenient to > attack. Restoration -100 and sust +60 that was already there give the wraith incredibly high sustenance. When idling they seem to lose about 5 food per hour, which means they can live for up to 8 real life days of playing without needing to feed. Also, although restoration -100 means they do not heal naturaly very well, they still do heal over time. The wraith I left overnight had 14/22 health, and in the morning it was fully healed. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Wraith changes
On 17/12/05, Brendan Lally <[EMAIL PROTECTED]> wrote: > On 12/16/05, Anton Oussik <[EMAIL PROTECTED]> wrote: > > a wraith should be strong enough to suck life from victim > > faster than victim sucks blood from it, since if it is losing hp it > > will die. > > But surely this point is only true for creatures that are weaker than it? Quite right, you gain levels in feeding like you do in anything else. You start off being able to feed to weak feeble things, but then get better and are able to feed off stronger enemies. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Wraith changes
On 20/12/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > Anton Oussik wrote: > > > Also, although restoration -100 means they do not heal naturaly very > > well, they still do heal over time. The wraith I left overnight had > > 14/22 health, and in the morning it was fully healed. > > random thought then - if you're a low level wraith and get beat up (say down > to 1-2 hp), is your only real hope then healing devices (potions, staves, > spells)? First I'd like to note that the third version of the patch makes wraith not heal at all by sensing for a wraith in do_some_living in player.c. Restoration -100 was a bit of a hack, and is no longer needed (and is therefore also removed from latest patch). Actually wraith scaled up life stealing works remarkably well. Perhaps too well and needs scaling down. The reason I scaled it up in the first place was that it did not work at all at low levels as after reducing the damage done by it in the code, as done for all other players, the resulting damage was always 0 at low levels. However, scaled up, it quite easily kills through goblins at level 1, and enables the player to run through a goblin infested room by level 3, which I think a player should not be able to do until level 10-15. What I could do with no difficulty is to make the wraiths eat until they reach, say, level 15, and only then give them the feeding skill. The current patch currenly does that to old wraiths - it treats them as if patch was not there until they try eating, and when they eat, it senses for an old wraith and converts them to a new wraith, after which they behave like new wraith. Another thing that could be done is to reduce the feding speed. What is the proper way of reducing weapon speed of a skill? I looked around briefly, but could not find it. > If so, I wonder if it may be nice to give starting wraiths some like a staff > of minor healing just so they can use it to get enough hp to go kill wimpy > things. As it stands now, a newborn wraith at 0hp can quite happily clear a room of kobolds and come out with full hp. I feel it is too powerful, so perhaps doing both, scaling down the feeding speed (probably about 5-10fold), and also not giving the wraith the skill until they reach level 15 would be appropriate to balance the race. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [patch] Large-denomination coins
On 24/12/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > Lalo Martins wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Just submitted a patch to the tracker. > > > > It adds two high-denomination coins: jade (after > > Chinese history and many Chinese-themed RPGs such as > > Exalted) and amberium (a Zelazny reference, although > > this material doesn't exist on his books). One jade > > coin = 100 plat; one amb = 100 jade. I would have thought that a patch to make Imperial notes accepted as shop payment would be more useful, but adding new coins is also good. Thanks! > Don't know if this is still a concern/issue. But at one time, there was a > strong inclination not to do this - instead, the players were supposed to buy > gems, etc for easy transportation. Yes, some of the more expensive items were currently unbuyable unless one used a bug, as they cost more in platinum than the strongest person could lift. I also have some concerns that this will cause inflation, and "platinum is the new silver". Could map and item makers please avoid making items that cost that much unless there is a very good reason for doing so? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Banking system
Thinking about lalo's patch, an interesting idea would be to make a patch that makes the banking system more useful by introducing the following changes to the banks: - Gain interest on money deposited - introducing chequebooks. If you attempt to leave a shop, and have unbought items, and have not enough cash to pay for it, and you have a chequebook, then if you have sufficient funds in the Imperial bank, and the chequebook belongs to you, then have the money deducted straight from your account. else have a message displayed saying that you try to pay with a cheque, but the shopkeeper does not trust it. In my opinion this will encourage people to use the banking system to store money. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
On 24/12/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > At some level, it becomes a question of why not just make money a 'stat'. > Instead of gold pieces, silver, platinum, etc, floating in your inventory, > something just says you have 123456 gold pieces. > All this starts to get away from the discussion at hand, but is food for > thought No, it is very much on topic - the main issue here is to avoid the need to have large piles of money lying about in apartments and having to carry more than your own weight in platinum in order to go outside to the shop (perhaps the subject is misnamed though ;-) ). Your idea seems more sensible. Perhaps make all players carry a special wallet/money pouch item, which is a container into which money automatically go and become weightless (or near enough so), which will say "you have foo gold" when clicked, and from which you can drop money? This could also be implemented as a property and interfaced by adding new server commands and adding a UI pouch... but that is for version 2 of CrossFire. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: [patch] Large-denomination coins
On 25/12/05, Lalo Martins <[EMAIL PROTECTED]> wrote: > And so says Anton Oussik on 24/12/05 18:40... > > I also have some concerns that this will cause inflation, and > > "platinum is the new silver". Could map and item makers please avoid > > making items that cost that much unless there is a very good reason > > for doing so? > > If I understand the code correctly, a small change in shop.c can make > these coins pretty much "invisible" - they will still be accepted in > shops, but price evaluations will remain in plat, and shopkeepers will > not give you jade/amber. > > Would that be better? Having shops give the high value coins is better, for the following reason: Currently the shops will give you the platinum for a sold item regardless of the weight of platinum. This means, for example, you can go and sell something worth 50,000,000, then the shop keeper will give you 50,000,000 in plat, even knowing this is way more than your carry limit. Under the new system this is merely 5,000 of the highest denomination thing, which should be liftable. Now it is possible to fix the bug of shop keepers giving too much weight in money without adversly effecting gameplay if it is still an issue, although in general it should not be any more. What I was against is the introduction of super-expensive items to make use of the coins. 5,000 jade coins should remain to be worth a small fortune. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
On 25/12/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > Anton Oussik wrote: > > On 24/12/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > >> At some level, it becomes a question of why not just make money a > >> 'stat'. > > As said, this wouldn't be really hard. > > Add a uint64 field to the player object. I suspect this would also fix the client bug when the client crashes when it steps on a tile where something has nrof > 2^32. > The biggest issue is making sure it works - having a bug and wiping out > peoples gold would be a pain. I agree, it would need a lot of testing before being put into "production" use. > That said, it would seem an easy fix right now is just change the current > weight of coins - the weight is currently 10 - it could be reduced to 1, and > increase carrying capacity tenfold. Yes, one can do that, but then it would only be a workaround, and one that would not fix all money carrying related problems. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
On 27/12/05, Nicolas Weeger <[EMAIL PROTECTED]> wrote: > So if we want to change things, i'd go for a credit card / checkbook > system, but only for small amounts - like under 1000 platinum. > This way you wouldn't need to carry money for usual things, but only for > high-priced ones. > Rationale is that shopkeepers don't have any way to check whether your > bank account really has all that money, so prefer to get the real hard > coins :) Also replying to several posts. Firstably card vs chequebook: I don't think there is plastic in CF, and so things should not be made out if it. For all purposes chequebook would work like one, since you would implicitly make a cheque in a shop. Secondly about dropping money in shops have the amount deposited to your account - this is not really how banking works - how will the money get to the bank? If I found some cash, I would not walk into a random shop, and give it to them (unless I was feeling especially nice that day). Thirdly about the amount alowed to use in shops - I was thinking the racist shopkeeper system could be extended to work with cheque books - the amount you can buy would depend on your race, religeon, and the type of chequebook you have. If you are not trustworthy enough, output a message along the lines of "the shopkeeper laughs at your cheque". Since Mikee said he was making some archetypes, it might be a good idea to make several, and once the amount you have reaches some number, say 1,000, 10,000, 100,000, 1,000,000, and 10,000,000, send out a new book to the player. Making them primary colours would also be a good idea, so something like white, red, green, blue, black would work. It is unclear if bank should charge for using the service or pay you interest. In the interests of deflating the economy I'd say they should charge something like 10plat/day for the basic card, 200/day once you get over 10,000, 3,000/day once you get over 100,000, 30,000/day to those entrusting their millions to the bank and, 400,000/day once you have more money than you know what to do with. I'n not entirely sure I like this idea though, and I think it will meet heavy resistance from others in this list, since it introduces a charge for a fixed amount of time, which a player may or may not actually spend in the game. Perhaps charging a one time payment when money are deposited would appeal to more people, but that can be exploited by dropping many small deposits (unless you argue that if you pay in a silver coin it should not be credited to your account). Allowing a player to inscribe a cheque to another player, which can be paid in at a bank by the player in question, or exchanged for cash at a bank would be a good idea. Also banks sending bank statements to the players every day/week is an interesting though. This all relies on a system that can send items through the post (I assume that is how people would get their cheque books? I guess the banks could also be arranged to do give out new books, by refusing to deposit money over a certain amount until you purchase the next expensive card. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
On 25/12/05, Brendan Lally <[EMAIL PROTECTED]> wrote: > On 12/25/05, Anton Oussik <[EMAIL PROTECTED]> wrote: > > I suspect this would also fix the client bug when the client crashes > > when it steps on a tile where something has nrof > 2^32. > > Wouldn't stepping on non-money items which have a sufficiantly high > nrof also trigger such a crash? Yes, it does. However you seldom encounter anything else in such quantities. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Wraith changes
On 31/12/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > Anton Oussik wrote: > > > Another thing that could be done is to reduce the feding speed. What > > is the proper way of reducing weapon speed of a skill? I looked around > > briefly, but could not find it. > > I don't know if there is actually a way to do this - it may be hardcoded > right > now, but there must be some diffrence, as I know karate is faster than dragon > clawing even at the same level. I will have a look in a couple of weeks when I have time, when I have the time. Maybe I can just hardcode the actual hp adding code to only add hp randomly and sometimes as opposed to always. That will effectively slow down the skill. > > > >> If so, I wonder if it may be nice to give starting wraiths some like a > >> staff > >> of minor healing just so they can use it to get enough hp to go kill wimpy > >> things. > > > > As it stands now, a newborn wraith at 0hp can quite happily clear a > > room of kobolds and come out with full hp. I feel it is too powerful, > > so perhaps doing both, scaling down the feeding speed (probably about > > 5-10fold), and also not giving the wraith the skill until they reach > > level 15 would be appropriate to balance the race. > > but my original point was also that if I'm at 0 (or near zero hp) and low > level, what can I do? Arguably, fighting anything should have some danger, > and > given that hp level, a stray hit could kill me. Yet if I don't get hp back by > waiting, I'm sort of stuck - I basically have to risk death to get the hp > back. Yes, as the patch stands that is the risk of being a wraith - you suck monsters dry with ease, yet you are very weak, so to keep alive you have to suck all the time. If you bump into a wall for 3-4 seconds your hp drops from full to 0 and next thing you know you are in a bed of reality. I guess it is wrong in a way, but a level 8 dragon I made to compare could do the same... just it had to run away when it got injured not turn around and start sucking at a kobold. > I wonder if level should also come into play? I could otherwise see more > moderate level wraiths who have very few hp thinking 'hey, I should go to the > newbie dungeon to suck up some hp', which probably isn't what we really want. > That 8th level wraith probably shouldn't get nearly as many hp back fighting > kobolds if we want to try and discourage that behaviour. That would be a quite easy thing to do - if you feed on something lower level than you you would not get any hp for it, and a message saying that this monster is too weak for you to feed on. This would also make it interesting at high level, as either you have to know where the high level "feeding grounds" - areas of easy to kill high level monsters are, or you start to rely on healing potions (and therefore a way of spending your disposable income :-D ) to survive. Also as a wraith I found when I played that you run from zombies and skeletons as if it were banishment itself. Since you can not feed on a zombie you have to use something that does not replenish you in combat, and so I imagine even at level 30 wraith running into something like a zombie tc would be equivalent to a suicide. It is an interesting side effect of the patch, but you automatically have to avoid killing your race. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: Lalo's Bigworld pupland :D
I'm jumping in completely off-topic, but since there is now more water, and parts only reachable by sea, it would be a good idea to add player driven boats to replace the merchant ones. Maybe some sea monsters too? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] ...shouldn't one get drunk from wine and booze in CF?
I'm pretty sure making an alcoholic drink would need server code changes. I have tried before to make a booze that casts confusion on the drinker, but the best I could manage is a booze that would get everyone around you drunk (confused) when consumed. Another interesting potion/disease that could be introduced is amnesia - a random forgetting of a spell, and if you know no spells, of a skill. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: [crossfire] Moving server towards a modularized system?
Throwing in my two pennies: In general modularisiation of the code will improve maintainability, as the core will be smaller, and tidier. Modules can then be compiled in or left out as the person running the server wishes. This would make debugging easier if anything, as then as long as the core is stable (which should not be too hard if it is made small) it will be always possible to isolate the modules that are causing trouble and either fix them or not use them until they are made more stable. On the other hand modularising the code will result in many changes, may introduce new bugs into the code, and is in general a lot of work whilst the benefits are questionable (this will only be useful if core is really small and most things are out in modules which can be configured at configure stage). If someone has a desire to do all that they are welcome to (it is an open source project :-) ), but in my opinion implementing new features would be more beneficial to the project. If you are going to go ahead with it, before you do anything to the code you will need to define what goes out to what modules, and what depends on what. Since CF was not designed to be modular you may also find recursive dependancies which will need resolving first. But I suspect you knew this already... ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Re: Polymorph etc
On the note of adding/fixing spells, could some high level spells be added into CF, which need higher levels (like 40, 60, 80, 100) in a skill to be able to cast them? At the moment there is little point in levelling things like sourcery beyond level 15, when you can cast town portal. Either re-shuffling spells about or adding some more spells to fill the gaps would be needed for that. Adding fighting levels to weapons would also make sense, and in my opinion would be more consistent for things like swords and bows than item power is. Thoughts/comments? On 17/01/06, tchize <[EMAIL PROTECTED]> wrote: > Le Lundi 16 Janvier 2006 23:06, Nicolas Weeger a écrit : > > > > Sure, i'll do it - lemme just confirm the money has correctly been > > transferred from your account to mine :) > > > > OMG, i think it ended in my account. Well better luck next time ryo. > > /me going out to buy a new ipod with that money > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Re: gcfclient options deathlist
Yes, it asks you something like "Are you sure you want want to quit the character?", not "WARNING: You are about to delete the character! Are you sure you want to completely delete the character and entirely and irreversably remove all evidence that the character ever existed for ever and ever?". I think what Mikee was referring to is that the comfirmation message does not look threatening enough. I agree, it is how I lost my first ever two characters. :-) Mark, would it be possible to make the "-split" option work on gtk-v2 client? It effectively allows the client to run on any screen resolution, and allows users to position controls the way they like it. I think the main reason so many people are still using gtk-v1 client is because it is able to better fit their needs. On 18/01/06, Mark Wedel <[EMAIL PROTECTED]> wrote: > Miguel Ghobangieno wrote: > > Yes, it would be best to remove that option from the > > menu IMHO. > > Could we also make quit ask the person if they really > > want to delete their character (and then ask again for > > confirmation)? (server side). > > I just tried this out. If I select the 'Quit Character' option from the > file > list, it does ask if I want to quit or not. > > > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Re: Moving server towards a modularized system?
On 18/01/06, Yann Chachkoff <[EMAIL PROTECTED]> wrote: > > I for one frown on the idea of making the server slower > > There is no reason that it would be slower than it is now. There are no > reason for a modularized system to be slower than the current version. The > only overhead would be when connecting callbacks to objects - and that's > hardly something you'd notice, unless if you're running Crossfire on a > [EMAIL PROTECTED] Actually, this will depend on how modular the code will be. Going back to Hurd analogy for a second, one of the reasons has not become widely used yet is not because it is modular, but because being so modular makes IPC (Inter-Process Communication) slow (using the GNUMach microkernel), as processes are forced to make frequent calls to the kernel, and therefore the whole thing runs about 66% slower [than Linux]. There is a theoretical design with will make it only 15% slower or so (Hurd on L4), but it seems to have other problems, so the project is no longer sure what kernel it will run on when the Hurd gets released. Effectively, most of the development is spent looking for an architecture that is both modular and fast, and therefore it may look like real "development" is not happening. The same thing can be done to Crossfire, making one "core" module, which will be tasked with starting up, parsing command line arguments, and starting up all other things as modules, provide a way of synchronising them and provide Inter-Module communication. If a message is sent to a module that is not currently there the core would then try to load that module before failing, so the random map generator only gets loaded after someone decides to enter a random map. This feature will also make handling errors easier, so if a person enters a random map, and random map generator is not avaliable, it will be possible to display an error to the player, like "The total chaos inside prevents you from entering". The player could then decide to build and install just the random map generator, and the server would not need to be restarted to apply the changes. Likewise for all other components, so applying a security update will not mean restarting the server. Also if some module segfaults, it will not need a restart of the whole server, but simply of that module. This should aid the server stability, as "something wrong when casting meteor swarm resulting in the spell not working" will not disturb someone else killing dragons in a dungeon. Having the code highly modular also will mean each module can be started as a seperate process (or thread, but that is slightly less portable, if somewhat faster), making it possible to run the server usefully on SMP systems (or even clusters), and therefore potentially much faster than the speed at which the current server runs. I don't know if this is what is wanted, but the advantages seem tempting to me. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: Polymorph etc
On 19/01/06, Mark Wedel <[EMAIL PROTECTED]> wrote: > Anton Oussik wrote: > > On the note of adding/fixing spells, could some high level spells be > > added into CF, which need higher levels (like 40, 60, 80, 100) in a > > skill to be able to cast them? At the moment there is little point in > > levelling things like sourcery beyond level 15, when you can cast town > > portal. Either re-shuffling spells about or adding some more spells to > > fill the gaps would be needed for that. > > Reshuffling of spells may make sense. The current spell levels where set > back > in the days when I believe max level was much lower. > > I'd be a bit concerned about adding new spells that are even more powerful > - a > fair number of the spells are already pretty powerful at high levels, and > adding > more powerful spells doesn't necessarily seem like it would help things out > much. And I think most spells already have pretty large areas of effect - > making even bigger fireballs/cones are likely to get to the point where one > spell covers the entier map. I did not necessarily mean more powerful spells. Some existing spells can get moved up the chain, and intermediate "interesting" spells can be added to fill the gaps, so a player always has a new spell "just within reach". Either that, or spell could be made to not get more powerful with level, and then players could learn more powerful versions of a spell they already know, which would exist every 5-10 levels. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Lag
When a player moves, there is currently a delay of one round trip until anything starts happening. Whilst for most modern Internet connections this does not pose a significant problem, when interacting with other players the lag seems to accumulate. They have 900ms lag, I have 1200ms lag, now between us we suddenly have 2100ms lag. Since a player can cover many tiles in 2100ms, it becomes very difficult to keep track of any other player when travelling, and in general to coordiante with others successfuly. This limits the useful multiplayernes of crossfire. Parties 5-6 players in size start to fall apart as players can not keep track of each other. Similar problems exist for persise stopping of movement. Laggy connections tend to make you overrun your destination. For example if I am running, and want to stop, it will take another 3-4 screens (at 20x20 tiles) before I come to a halt. Is there anything that can be done to improve movement on laggy connections? Could the server send the client a matrix of what tiles on the map can be moved to, and send updates of that as they change for example? Any better ideas? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Lag
On 26/01/06, Mark Wedel <[EMAIL PROTECTED]> wrote: > Brendan Lally wrote: > > On 1/26/06, Anton Oussik <[EMAIL PROTECTED]> wrote: > >> Is there anything that can be done to improve movement on laggy > >> connections? Could the server send the client a matrix of what tiles > >> on the map can be moved to, and send updates of that as they change > >> for example? Any better ideas? > > I'm not sure that helps out. What it gains is that the client can 'move' > the > player to the space they are attempting to go to so that client is slightly > more > up to date. However, you will get syncrhonization issues - if your lag is 500 > ms, any update on that array of spaces is still 4 ticks out of date. So you > can > certainly get the case where the client thinks it can move to some space, but > someone else has already moved there, and thus what the client displays is not > just out of date, but erroneous. Yes, I too see that flaw. However most other online RPGs deal with that issue in a similar way to this, using server updates as the reference, and it seems to work for them. > > > > One thing that might work for this, is something I have been idling > > toying with concerning movement. > > > > I was looking a few weeks ago at adding a 'goto' command so that the > > player could send a command goto (relative to the player) and > > then, as long as they had no further commands sent, they would go > > towards that point. I like that idea. > The slightly more complicated part is that ideally, you'd want the server to > send the client the proposed route (so the client could display it in some > format, so if it is completely bogus, the player can interrupt it and re-route > manually. Is there really much point in this? Clicking anywhere you can see should (travelling in more-less straight line) get you there in about a second, which is not enough time to cancel a route. > One consideration is the case of alternate routes. One tricky part also, > relative to players using that code, is you don't want the player to cheat too > much. IF the player is in a maze, they shouldn't be able to click some spaces > away and the server now routes them there even though as a player they had no > clue. Maybe limit the length of route to 20 or 30 tiles? > > In any case if that became the defacto standard way of moving (as it > > is in most graphical RPGs), then it would be possible to figure out > > what route the player would take, and send the moves they would make > > to the other players in the room early. - this would still lead to the > > ocassional de-sync issue (when they change direction, or something > > moves in the way) but it would be a noticable improvement over what is > > currently there. (the extension to that would be to have an attackto > > command (or a flag to goto) so that monsters could be targeted to get > > the player to follow them and attack when they are in range. - > > probably such advance telling of commands should only occur if the > > ping time is bigger than the tick time though. Sounds like a good idea, but complicated. > > In general though, if your ping time is over a second, you need a > > better internet connection, most games are difficult to play when you > > are that laggy. Runescape and AO work wel over my connection... > Yes, but here are some other random thoughts: > 1) Player movement is perhaps to fast - with most all players moving about 1 > space/tick, this obviously results in keeping in sync harder. Slowing down players is a bad idea. Slower movement gives the impression of lag, as players see no notification that their character intends to move for a while. This is to do with the fact that movements in cf are quantum, and therefore there is no smooth transition when moving from tile to tile. Maybe one solution to that would be to make all tiles one pixel, and all objects into multi-tile things? Then speed up all movement speeds 30-fold or so, and maybe one day you end up with something with nice smooth movement, and appearance of no lag. > 2) A 'follow ' command could be added such that you follow player . > Maybe > just allow it in parties, with commands like 'lead party' and 'follow party'. > Everyone who did 'follow' follows the 'lead'er. The leader would > automatically > slow down as needed so as not to get too far ahead. I'm sure pet code could be used for that... > 3) Currently, the server processes all the objects/players, sleeps for 120 ms, > then does that again. > > Lag could be reduced by some amount (average 60 ms) if we process data from > players i
Re: [crossfire] Crossfire 2.0+ features/priorities
On 29/01/06, Mark Wedel <[EMAIL PROTECTED]> wrote: > One of the things that have been on my wishlist a long time is a better > character creation method. I'd say that a character creation window would work best - where you can select the name, roll and re-roll stats, chose your race, sex, and class, and see how it changes your character (as well as seeing how the character looks themselves). Race/Class descriptions can then go into textboxes under pulldown selection controls, and starting items/skills should be viewable. Another thing I can propose is to replace the listen level with channels, and be able to toggle/redirect individual channels between different tabs in the client. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
On 31/01/06, Mark Wedel <[EMAIL PROTECTED]> wrote: > When aboard a transport, the player will be in the inventory of the transport. I would say that transport should also point to a map containing the inside of the transport. Therefore two actions are requared as regards to a transport: "enter" it, and "drive" it. Only the owner should be able to drive the transport, but anyone in the same party should be able to enter it. This way a transport ship or a cart will be able to transport people and goods. This would not make much sense for a horse or a dragon though, which would not be able to carry goods, but be only used to transport the owner. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] crossfire traffic
Great idea! Now make the URL to that widely known, and easily findable, so the user base will easily find it. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
On 29/01/06, Brendan Lally <[EMAIL PROTECTED]> wrote: > - an extension to the extension above, send health status along with > monsters (probably as a percentage to not give away total hp), they > can then have clients draw health bars above their heads. As extension to your extension to the extension above, or even on its own, some re-balancing of the game could be performed. Last month I set my girlfriend lose on CF, and her biggest negative feedback was that exploring was very difficult. You either go into a new map and can kill everything without taking any damage, or you die by the end the map finishes loading. Either outcome is not very exciting. Therefore a re-balancing to increase the margin between "that does not even tickle" and "what was that which just killed me?" is needed. In order to achieve that I propose starting with 3 changes: * DRASTICALLY reduce the hp regeneration (something like 10-fold) * Significantly increase hp of players and monsters (3-10 fold) * Significantly lower resistances given by items (so a player can get up to 25% resistance or so with several items) That way there will be less reliance on item resistances, and it will be easier to match a map difficulty to a specific level. Also a player that enters a difficult area will not be killed before they have a good chance to run away. As a side effect healing potions and healing spells will then become useful. Monster combat will also take longer, so running through a pack of enemies much weaker than you to gain lots of experience will not be as useful. Perhaps a balancing test server should be set up to allow finding the right balance. As an extension to the aboce extension a new family or party spells can be introduced. These will aid parties in combat by providing spells like party heal, and party word of recall. Possibly party strength, party wisdom, and so on can be introduced. They would be high level spells that would act on all of the party, and will belong to different magic schools. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
On 01/02/06, Brendan Lally <[EMAIL PROTECTED]> wrote: > On 2/1/06, Alex Schultz <[EMAIL PROTECTED]> wrote: > > Well, IMHO this may not add too much for the player to use, but I can > > see it as something that would add alot of depth to the gameplay. Not > > sure how worth it it would be to do though, as it is indeed alot of > > complication, though I would say it would certainly improve the player > > experience. > > The small ships would be fine I think, as long as they can still > 'attack' each other and have such an event create a 'battle' map, > where there are two ships with all their occupants, plus cannons, etc > to fight each other. (there could then be pirate ships patrolling just > outside the main shipping lanes, and on PVP servers, groups of players > could be pirates themselves). By seperate map I meant something more along the lines of "pocket dimension" that a large transport will have, without any representation of the surrounding world. Yes, it would add a lot of complexity, so perhaps it would be best to leave that as a possible extension for the transport system in the future, and get a working transport system first. Also, how about setting up shipping routes and roads by placing directors for transport on them? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
On 02/02/06, Mark Wedel <[EMAIL PROTECTED]> wrote: > > > > > Also, how about setting up shipping routes and roads by placing > > directors for transport on them? > > Is the point here to have boats automatically sail from point A to B, or to > give players a clue? Have boats/carts/horses sail automatically between crossings of routes or roads when on a road. There would need to be routes going in different directions, and sea routes would probably not be optimal (so a person doing it manually could get there faster). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
On 02/02/06, Mark Wedel <[EMAIL PROTECTED]> wrote: > That said, if the smooth movement stuff is a high priority item, I'd think > that would completely redo movement and actions, and that could be the time to > fix it then. I would say that a smooth moving slowed down crossfire where it takes time to kill things (with health bars over monsters, etc.) is a good general direction for the project. However the CrossFire of today seems quite different from that. I have very little understanding of the movement/map code, but I would guess changing that would be very close to a re-write. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gtkv2 client vs gtk client gap list.
My biggest obstacle (grudge?) against using gtk-v2 client is no -split option. It is good for big/small/multiple screens, and I find playing without quite restrictive. Also (last I tried) it fails to compile on cygwin, but that is probably easily fixable if I were to seriously consider using it. I also use the GUI keybinding interface. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] RFC: gtk client with gtk2
On 09/02/06, Andreas Kirschbaum <[EMAIL PROTECTED]> wrote: > Lalo Martins wrote: > > I've been running the gtk client compiling with gtk2 for about 3 > > months now; it works beautifully (better than with gtk1), sdl and all. > > > > The problems I know about seem to be: > > > > - SDL doesn't work for some people. I couldn't find one of those people > > to comment, though. It works for me. > > If you cannot actually find somebody having these problems, I don't > think it should prevent you from applying the patch: if there really is > a problem, "those people" will (hopefully) complain and we can fix the > bug then. SDL in CVS gcfclient has been broken for me for a long time now, producing this crash when connecting to a server with SDL enabled: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1081633664 (LWP 5070)] 0x403637c6 in SDL_LowerBlit () from /usr/lib/libSDL-1.2.so.0 (gdb) bt #0 0x403637c6 in SDL_LowerBlit () from /usr/lib/libSDL-1.2.so.0 #1 0x40363ae2 in SDL_UpperBlit () from /usr/lib/libSDL-1.2.so.0 #2 0x0806e342 in display_mapcell (ax=5, ay=7, mx=249, my=251) at sdl.c:806 #3 0x0806e4bc in sdl_gen_map (redraw=0) at sdl.c:932 #4 0x0807262b in map1_common (data=0x8477398 "", len=1798, rev=1) at commands.c:958 #5 0x08072791 in Map1aCmd (data=0x840c2b8 "", len=138461880) at commands.c:973 #6 0x080701f0 in DoClient (csocket=0x83985a0) at client.c:156 #7 0x08054c29 in do_network () at gx11.c:320 #8 0x401a98ce in gdk_get_show_events () from /opt/gnome/lib/libgdk-1.2.so.0 #9 0x083985a0 in style_fixed () #10 0x000c in ?? () #11 0x0001 in ?? () #12 0x401f3130 in ?? () from /opt/gnome/lib/libglib-1.2.so.0 #13 0x in ?? () #14 0x083b1ac0 in ?? () #15 0xbfc22b38 in ?? () #16 0x401dea36 in g_io_add_watch () from /opt/gnome/lib/libglib-1.2.so.0 #17 0x401dea36 in g_io_add_watch () from /opt/gnome/lib/libglib-1.2.so.0 #18 0x401e03cf in g_get_current_time () from /opt/gnome/lib/libglib-1.2.so.0 #19 0x401e0f69 in g_main_add_poll () from /opt/gnome/lib/libglib-1.2.so.0 #20 0x401e126f in g_main_run () from /opt/gnome/lib/libglib-1.2.so.0 #21 0x400e2b4f in gtk_main () from /opt/gnome/lib/libgtk-1.2.so.0 #22 0x08054d31 in event_loop () at gx11.c:372 #23 0x080648f1 in main (argc=138461880, argv=0x840c2b8) at gx11.c:5290 (If you want more info about the crash poke me on IRC or reply to this) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
On 27/02/06, Mark Wedel <[EMAIL PROTECTED]> wrote: > OTOH, I'm firmly in the camp that I'd like a nice popup window on the client > where the player chooses his stats, race, class, and if we want to go in the > direction of choosing skills, that also. Me too, but then followed by two introductory maps, one for the race, where the player goes through a course learning about their race, its advantages and disadvantages and how to use it effectively, and another about their class, learning about its advantages and disadvantages and how to use it effectively. That does however requires some map making to make it interesting. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Ideas needed to fix exploit
On 28/02/06, Mark Wedel <[EMAIL PROTECTED]> wrote: > One question I have is why even need a force. Is there any potential abuse > just saying a player can't die when on his savebed? This would most likely cause most players to take unopened chests to bed with them, and practice bedroom alchemy. Going to bed when diseased would seem consistent with real life behaviour though :) Overall I agree that awarding experience based on exp loss is the best way of fixing this, although exp gained should be slightly lower than exp lost. This will prevent two players from levelling by repeatedly taking turns to kill each other. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Ideas needed to fix exploit
A special case also has to be made for suicide. training up an easy to train skill and then killing yourself with a hard skill should not make training a hard skill too easy... Perhaps not gain any experience for a suicide, since it is conceptually a stupid thing to do. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
In that case it would make sense to make a big noobie map, with buildings, each of which contains a course to do some thing. If each of these noobie maps was personal to the player, the players could learn about playing cf without anyone else spoiling their fun. This would also enable them to come back later to complete learning if they can not be bothered with advanced stuff just yet. I propose each building award the player some experience towards the skill at the end to make it worthwhile. These are the general buildings I can think of: - Basics 1: Moving, applying things, reading signs, notes, etc. - Basics 2: Wearing, equipping, making active, opening/closing, marking, 'body command - Basics 3: Changing/learning skills, commands like 'statistics, 'skills, experience system - Traps 1: Finding/disarming traps (on the floor, in doors, on chests) - Traps 2: Setting traps - Melee combat 1: Attack things with punching/karate/etc. - Melee combat 2: If you can hold a weapon, how to use it to do things in 1, run attack - Ranged combat 1: How to pick up and equip bow, arrows, and shoot - Ranged combat 2: bowmode and arrow quivers - Spell casting 1: How to see what spells you have, select a spell you have, and fire a spell. - Spell casting 2: Learning new spells, types of spells (schools), sp requirement, spell level. - Spell casting 3: Different kinds of spells (cone/bolt/etc) and casting them - Identifying: List different ways of identify items - Healing: List different ways of healing different things - Alchemy: How to use alchemy-like things - Stealing: How to steal ...and possibly a few more buildings for things like oratory, climbing, jumping, literacy (scroll making?). Then there could be specific houses for the races like dragons explaining the whole food/focus thing, a house for firebournes explaining the whole "you are a ball of fire, don't get put out" thing, and a house for wraith explaining "You are dead - you don't digest food or heal" (when I make the patch balanced enough to be applied to the source tree) thing. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] RFC: dynamic alchemy
On 27/03/06, Wim Villerius <[EMAIL PROTECTED]> wrote: > Shadow alchemy is an exploit, used to create items that are > impossible to create with dynamic alchemy. (It is impossible to have > items with resist_something > 99 - and this limit could even be set > lower) To those unfamiliar with it, shadow alchemy generally involves finding hash collisions for the recipes, fooling the alchemy code into thinking you are doing something else entirely. Since the hashing function is (on purpose) very weak, there is no easy way of making shadow alchemy impossible short of entirely changing the way traditional alchemy works. It is currently hard enough to discourage most people though (thanks to some safeguards in the code). For most purposes, however, it currently does what dynamic alchemy will do, but without the much needed game balancing, and very scarce documentation. I like your idea about dynamic alchemy, but creating a resistance table seems like a lot of work, and so does messing with the arches. Instead, why not make a semi-random roll on what to add/subtract, partially based on the hash value of the ingredient? This means that only the alchemy.c file will need changing, and dynamic alchemy will have a much better chance of actually happening (+working). These are the things I can think of adding/subtracting to items: resistances stats speed weight value ? <-- careful not to make this one exploitable ac wc luck ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] RFC: dynamic alchemy
On 22/05/06, Raphaël Quinet <[EMAIL PROTECTED]> wrote: > On Thu, 18 May 2006 10:34:25 +0200, Wim Villerius <[EMAIL PROTECTED]> wrote: > > On Tue, 2006-04-11 at 21:21 +0100, Anton Oussik wrote: > > > To those unfamiliar with it, shadow alchemy generally involves finding > > > hash collisions for the recipes, fooling the alchemy code into > > > thinking you are doing something else entirely. Since the hashing > > > function is (on purpose) very weak, there is no easy way of making > > > shadow alchemy impossible short of entirely changing the way > > > traditional alchemy works. It is currently hard enough to discourage > > > most people though (thanks to some safeguards in the code). For most > > > purposes, however, it currently does what dynamic alchemy will do, but > > > without the much needed game balancing, and very scarce documentation. > > AFAIK shadow alchemy is indeed in desperate need of game balancing and > > since it is by no means documentated (except that it's written 'in the > > code') it is almost never practised (anymore). At least on MF, I know no > > active players that do anything with it. (Are there any active players > > anyway?) > Once this full list of all items is available, it is not very > difficult to perform a "brute force attack" on the alchemy hashes. This > would be easy to do because the large but finite list of all named items > that can be picked up in the game can now be generated easily. And I am > sure that once I publish my map checking script, it will not take long until > someone does exactly that and publishes the full list of hash collisions for > the alchemy code. Then the problems of the shadow alchemy code will become > even more apparent. The full list of items is not really needed nor preferred. What you want is a list of easily avaliable ingredients (things you can get in large quantities from altars, money, and summonable items), and generate hash collisions using those. A couple of summers ago I wrote a short C program that parsed formulae file and generated collisions using these ingredients in O(n^2), it worked quite well. I also saw a Windows collision seeking program that would find a collision that was very profitable and generate a client side script repeatedly doing it. In my opinion shadow alchemy is not widely used because it is so obscure, not because it is impractical. The actual number of collisions is huge though - publishing (and generating) a full list of collisions is quite pointless. Removing shadow alchemy alltogether would only work by not allowing recipes not found in formulae file at all, in which case there is no point in having a hash value representing the recipe, and the way alchemy works needs redoing entirely. Dynamic alchemy IMO can replace what is used today, but I think it should work thus: If the recipe matches one in formulae file, use that. else use dynamic alchemy: Resistances: Max resistance that can flow in/out of an item is the level of the player in alchemy up to 100%. One can argue that this is too high, but it is already possible to get 100% resist items from traditional alchemy without shadow alchemy - on of the failures generates the desired item with stats doubled. Stats: Max stat that can flow in/out of an item is up to 5, and also depends on alchemy level, where lvl 1-20 is +/-1, lvl 21-40 +/-2, ... for each item in the device for each non-zero property (affected by alchemy) in the item find a random item in inventory get a random number between 0 and the max level allows if the number is greater than the amount in the original item reduce it accordingly transfer the property if amount in the new item is greater than level allows reduce to max level allows effectively alchemy will then have reproducible and yet random behaviour, and will act as a method to transfer properties between objects. Although this method will allow high resistance items in theory, they will be very very rare. This approach also does not need to build up any aditional tables, and so can be entirely implemented within alchemy.c. Also IMO traditional alchemy recipes should be made easier to do. By the time you find ingredients, you can already find/buy the target item. Perhaps ingredient shop should extract ingredients straight from the formulae file, and stock those, in large quantities. This way alchemist would be able to buy ingredients without spending ages looking for them in the wild. I know ingredient list is supposed to encourage exploration, but if you go exploring you will find the target more easily than find and collect all the ingredients. There also needs to be more medium and high level alchemy-only items that require high (100+) level to generate. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] RFC: dynamic alchemy
Could someone explain how potion making and similar magic where the result is nothing like what you start off with will work? Will you need to put in a water bottle as part of the recipe? What about balms? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] RFC: dynamic alchemy
On 24/05/06, Raphaël Quinet <[EMAIL PROTECTED]> wrote: > On Wed, 24 May 2006 14:56:16 +0200, Wim Villerius <[EMAIL PROTECTED]> wrote: > > On Mon, 2006-05-22 at 20:50 +0200, Raphaël Quinet wrote: > > > Also, shadow alchemy is player knowledge and not character knowledge: > > > this gives an unfair advantage to experienced players regardless of > > > their character level. > > Yes, shadow alchemy is player knowledge, not character knowledge. But > > the same goes for current alchemy, maps (passwords), where to find > > artifacts, how to beat monsters, etc etc. In other words, (almost) the > > whole game is player knowledge. > Well, it is worse for shadow alchemy: it is player knowledge that is very > hard to acquire while playing, but easy to remember (or write down) once > someone or some program tells you how to do it. So it is a bit like "cheat > codes" for the game. The shadow formulas are of very little use for the > normal players. Which is why I proposed the dynamic dynamnic alchemy - there are no formulae, and a beginner player has the same knowlege as an experienced player, and the result is bounded only by their level at the skill. It will allow a huge amount of new items to exist, since generally it will be possible to create any item at all, which can not be obtained otherwise, thus encouraging trade and inter-player interaction. If you further want to restrict it, you can say that ingredient foo is needed for max transferred property to be 40%, bar for 60%, and so on, but I don't think it is a good idea since it will make alchemy too troublesome to use again. If you see a problem with overpowered items, perhaps created items need their item_power adjusted, so any super-times will be unwieldable because of the item_power requirements. > On the other hand, the most powerful recipes should be > locked because they are quest items. Even if I remember how to create the > potion of fire immunity, I do not expect to be able to use it immediately > when I create a new character: I know that I have to go through the fire > temple first. Although I do not think recipes should be locked as it restricts players, I see a better way of locking them, if that is what everyone wants. Recipe learning can be made to work just like spell books. I.E. you apply a recipe book, and memorise the recipe. After that you should be able to recite it, and when you try performing it, alchemy code should check if you have learnt the recipe in the past. This approach will be much more consistent with the rest of C.F. than arbritrarily locking some recipes. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
You need to also consider inter-quest relationships. Completion of one quest may be necessary pre-condition for starting another quest, or could deny you a quest alltogether. You could make all related quests fit into one file I guess as one big quest, or add a way to add FA links across quests, which would be nicer. Another proposal related to quests I was thinking of for some time now is randomly generated quests (dynamic quests?). A random map generator is already present, so it is possible to produce random dungeons. An interesting extension to that would be to produce random quests. They would hugely extend the size of CF, and overcome the map contention issue, since there would be an almost limitless supply of maps and quests of all kinds and levels open to players. Random quests would work by linking the to several NPCs (in taverns, inns, etc. throughout the world), and by talking to an NPC a random quest gets generated on big world suitable for the player level, with an appropriate reward item at the end, and a randomly generated storyline. The players are told by the NPC how to find the entrance. To control access the NPC would give player(s) taking part the key(s) to the entrance. Quest types I can think of right now are: - Kill something - powerful boss at the end, drops the reward loot - Find something - useless (randomly generated?) item somewhere in the dungeon, need to find and bring back to NPC to get the quest reward item or experience. You can also have non-fighting oriented quests, but ones encouraging exploration, by making the player go to a remote part of the world. - Deliver something - give item (letter) to another NPC somewhere in CF - Deliver something and bring back something else - extension of previous one Another quest class could be quests that develop secondary skills: - Sneak into a dungeon and steal something (NPC awards stealing/hiding xp) - Bring back a rare useless item (NPC awards some alchemy-like xp) - Get an item from a dungeon full of traps (NPC awards finding and disarming traps xp) Finally you can have thinking (puzzle solving) oriented quests: - Move the boulders to get past and get to the item - Arrange boulders in the right places to open the door to the item - Pull the right levers - similar to above - Step on the right floor tiles ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Client-side scripting
> So, no one has any comment? :) > > Does that mean it's wonderful (so everyone's speechless), and I can commit it? > *evil grin* Seems that way! :-) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
> Standardize on 19x19 map size. Good idea, and scale tiles accordingly otherwise. Would probably want to make a 16x16, 64x64, and possibly a 128x128 tileset in that case. Or just try to use OpenGL to scale tiles appropriately. > Make client fullscreen. I have mixed feelings about this one. I would run it windowed, but I know for a fact that many Windows-using people expect a full screen app from a "game" they would consider playing. I experimented on some Windows users and a private server a few months back, and they all wanted full screen and preferred gtk-v1 client, as it could display more information to the user at the same time. So, if the game UI is "geeky", it is only in the sense that CF uses the OSes standard UI elements, and users expect shiny UI in a game. > Improve client UI >From observing the Windows users I found they liked as much info displayed as possible, with often needed info in easy to look at locations, and less often needed info in less easy to look at locations. Perhaps some often unused inventory tabs could be converted to a "body" tab, which graphically shows what equipment is worn and what slots are free? Or a resistances tab that shows slidebars of the resistances from 0 on a scale between -100 and 100? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Wraith patch committed. Please test.
The wraith patch has been merged into the source tree. It will most likely need some tweaking to make it balanced, most notably the strength of the feed skill and proportion of that returned to the player as hp/food: on one hand we want it to be possible to survive by feeding off things, on the other hand we do not want to be able to go run-feeding through hordes of orcs at level 1. Please test it and comment on changes to it you would like to see. The details of the patch and the patch itself can be found here: https://sourceforge.net/tracker/index.php?func=detail&aid=1382884&group_id=13833&atid=313833 ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Undead flag
On 10/04/07, Nicolas Weeger <[EMAIL PROTECTED]> wrote: > AFAIK, undead dragons and such recover when leaving Devourers. > Or am I mistaking? Yes, but when the dragons are undead, they are no longer dragons, they are just undead. This means any dragon-specific checks will fail on them, such as access to the dragons guild to change focus. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
