Re: [crossfire] GTK V2 client default layout and map size
On 15/02/2008, Juha Jäykkä [EMAIL PROTECTED] wrote: For point a) please note that some people (at least me) never use full screen size windows for any purpose (except on my htpc, but that does not even have a keyboard and mouse so I won't be playing on it) and the current unability to let the window manager resize the window is simply absurd. If a user wants to resize crossfire window to 20x20 pixels, it's the user's problem when if becomes totally useless. Almost all programs scale their internal window widget sizes according to the window size (or introduce scroll bars). Why would crossfire not do this? For the map-view-widget this would probably be pointless, but at least everything else could scale. Even the map widget could scale at least is tile-size steps: if 16x16 tiles no longer fit on whatever size the user adjusted the window to, then only draw 15x15 - and leave some blank if the actual size is 15.5x15.5 or resize the info widgets to fill that space. Likewise, I prefer to place each widget in its own window, get rid of window borders for them, and just rearrange them as I see fit. This allows for easy arrangement to play on multiple monitors, as well as allowing a very flexible way of arranging the client's components to suit playing style. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Balance changes
On 31/12/2007, Mark Wedel [EMAIL PROTECTED] wrote: 2) Since the rebalance here includes scaling things up to level 100, it strikes me we can not give out new spells every level. Maybe every 5 or so, so at level 5 you get a small exploding ball and small bolt spell (maybe not at exactly same level, who knows) Sure you can. Make old spells have old strength until player learns new level of the spell. i.e. to cast lelvel 2 bullet you need to find and learn a level 2 book, and until then you will cast a level 1 bullet. This also allows to fine-tune each spell for each level, however you would want higher level versions to replace lower level versions, to keep the spells list from getting too large. Item creation classes - if someone wants to play a blacksmith and make weapons all day, who am I to say no? But with other balance changes, we can know how this works - that blacksmith needs raw ore, and the facilities and time. Maybe there is a mine near by he can go to get the ore - but if it takes 5 minutes realtime for him to get a load of stuff, that help factor out exp gain. Likewise, if he gets 50 exp for making a sword, it means he has to make a lot of swords to gain a level, and if an actual time delay is put in there (lets say it takes 10 seconds realtime to make a sword), it probably means that such a character will not gain levels any faster than any other class, so IMO would be considered in balance. The only issue here is that I think such long time (10 second) actions need to be interruptible - in a sense, it is almost like the run on stuff - the character keeps making the sword unless he chooses to do something else. And there is some chance at failure - a first level blacksmith maybe only has a 50% chance to successfully make a sword for example. I think clerics/priests are basically OK. Any other thoughts out there? Do what is already done for mages - make alchemy-like things use mana. It means the blacksmith will need rest sooner or later. If using actual mana is too unrealistic to drain by alchemy (as not strictly magical), perhaps a new type of fatigue could be introduced... However using mana would be easier for the players IMO. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Project: New Intro
On 02/07/07, Mark Wedel [EMAIL PROTECTED] wrote: Alex Schultz wrote: I propose that we focus on what content the player sees first in the game because after all, it not only is the first part to leave an impression snip First question on this: It has been suggested that the character creation get completely redone, with spiffy interface, etc, instead of the the current 'in game' method. Does this proposal address this at all, or is this more based on what the player does once the character is created, and leaves the creation aspect itself still on a TBD list? As I understand it this is different, and spiffy character creation interface is still wanted. Is this just an island for tutorial purposes (this is how you cast a spell, this is how you search for a trap, etc), or is this more designed as a low level area? Making it a tutorial island would mean new players can enjoy the temporary safety while learning to walk. In both cases, does one see a 'ship to mainland' type thing which is a one way ticket off the island to scorn (or perhaps other towns? Maybe replace the nexus with this town, and experienced players can hop right over to the ship to navar city if they really want to). Ship(s) to mainland will work well :-) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] identification skills patch
Would making a unified identify command that calls whatever skills you have to try to identify things around you make sense? That way you can just bind 'identify once and not bother with any other binds or commands. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Build command
On 14/04/07, Nicolas Weeger [EMAIL PROTECTED] wrote: Optionally, alchemy could be made to use sp, too (would emulate the build command behaviour). Interesting. This would solve a lot of problems. What do others think? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver
On 14/04/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 4) Any servers should be free and open, that is to say, not pay for use/play. I am not sure 4) is fair. If people have hardware and time they can donate to run a server that is one thing, but if a CF derivative ever becomes very popular and needs a farm to run on, it is likely a fee would have to be introduced to cover hardware costs, and possibly even hire full time admins/dms/mapmakers/artists. As long as the source code is released under GPL and anyone is free to set up their own server I would still consider that server free and open, I see no problems there. The subscribers would be paying for services that accompany the game, not the game itself. When/if pay for play servers are introduced they could send pay for play information to the metaserver, thus avoiding confusion. Then again someone could also make a new tileset and their own maps, and say do not redistribute whilst running them on their own server, for which they could charge money. I am not sure there is anything GPL can do about that. There is also a potential issue of someone creating a compatible server/client from scratch not using any GPL code, and charging for using it. Ultimately there is very little that can be done about that as far as I can see, as any proprietary server/client could be made to pretend to be one of the free ones. ___ crossfire mailing list [EMAIL PROTECTED] http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver
On 14/04/07, Yann Chachkoff [EMAIL PROTECTED] wrote: Then again someone could also make a new tileset and their own maps, and say do not redistribute whilst running them on their own server, for which they could charge money. I am not sure there is anything GPL can do about that. However, I think that any new content material (maps, graphics) should be freely redistributable as part of the Crossfire project. A server that refuses to share its content with the rest of the community should not be allowed to stay in the metaserver listing, IMHO, because it goes against the spirit of freedom that drives the project. That is a good theory, but is quite impossible to enforce in practice, for several reasons: A) There is no way the metaserver can reliably determine the license of all the content that is on a particular server. B) There is no way a human can reliably determine the license of all the content that is on a particular server. Say, I run my own server. I make a change to the source allowing all characters of level 115 to become DMs (a silly change, but then I am not too bright). I also make a series of new maps avaliable for them, to play as DM quests, i.e. things that need DM powers to complete, but are designed to be challenging even to someone who has DM powers. I do not release the code changes. I do not release the new content. Since I run the server myself, and do not distribute it, I am not required to provide the source code for my change. Since the maps I have made are not derived work, I can license them however I like. Hence, I am able to run a CF derivative without needing to disclose any of my source or the content. However, until you have a character that reaches level 115 and becomes DM, there is no effective way of telling that my server even contains closed content, and so the metaserver can not be expected to handle an issue like this. ___ crossfire mailing list [EMAIL PROTECTED] http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Getting more artists
On 11/04/07, ERACC Subscriptions [EMAIL PROTECTED] wrote: On Wednesday 11 April 2007 05:00 am Anton Oussik wrote: If we could attract an artist (or 5 or 6) who would be willing to create 3D models of things, animate them, and then produce a complete tileset of the universe from those, it would be ideal. Call me crazy if you wish. :-p I prefer the 2D version we have now. Granted we could always use more and better 2D graphics. But 3D and animation then locks out a lot of marginal graphics makers (like me for example) that could make do with the 2D tiles. Once we go 3D we would *have to* have some 3D artists on board the project to go forward. 2D reduces portability and ability to animate graphics. For example, if someone creates an animation of a running orc, and someone else creates an animation of an orc swinging an axe, given the models, some 3rd person can easily add an animation of an orc firing an arrow. Generating everything from a different perspective or of a different resolution can then also be automated, and colours can be easily be adjusted over all frames featuring the same model. A talented 3D artist should be able to get more work done, and be able to keep the work easy to change better than several 2D artists might. As a bonus, same models can be used to make CF truly 3D some day, instead of 3D-rendered snapshots as currently proposed. Since I think some day within the next 10-15 years CF needs to make a transition to 3D to stay current, this would be a natural evolving route to take. The problem with that is good 3D graphics folks are not easy to find and keep. That is true, and there are good chances that none will be attracted. The really good ones are probably working only on closed source projects for a salary. I say this based on the lack of excellent 3D graphics in the open source projects I have seen. I am willing to be proven wrong though. ;-) But I still would prefer we keep Crossfire a 2D game. 3D-rendered tileset can be provided as alternative to the 2D one, and even after transition to full 3D if the game is still tile-based there is no reason current tileset can not be used in 2D mode. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Getting more artists
At the end of the day this would be mostly up the the artist(s) contributing art. There seems to be an agreement of 2D vs 3D, so now someone able and willing to contribute needs to be found. ___ 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=detailaid=1382884group_id=13833atid=313833 ___ 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
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] 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] 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 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
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] 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] 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] 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 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] 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 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, 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] 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 xy (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 x' command could be added such that you follow player x. 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 immediately when it arrives. This sounds like a great idea for reducing lag in low latency conditions, making cf pretty much real-time for the user. I think all the people playing on private servers will want this implemented. Now if everyone could get a low latency connection... How about distributing the server? This is at the moment not viable to implement, but maybe some time in the future, could a number of servers in geographically distant points act as one super
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] 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: 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: [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
[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] 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
[crossfire] Wraith changes
Today I have posted a patch to the tracker, which can be found at https://sourceforge.net/tracker/index.php?func=detailaid=1382884group_id=13833atid=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] 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.metalforge.org/mailman/listinfo/crossfire
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 can be added is some
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 to do that), I can see two possibilities: 1 - the
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] [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] [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. (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] 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] 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] 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] 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] 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 thecharacter 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] 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] 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)
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
[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
[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
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] 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
[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
