Re: [crossfire] New plugin: citylife - help needed
If I'm running a private server and don't log in for a few days, it would be annoying for all the shops to be closed. This should not be a problem: it should be easy to only count active ticks (i.e. ticks when someone is actually logged on to the server) when considering which shops thrive and which die. Related to that you are likely to get some towns that may not be used much even on active servers - if I have a private server, I'm likely only working in one town at a time. This is more difficult. Perhaps the npcs themselves could help with this? Perhaps the npcs could be made to go to the shops as well? They might not need to buy anything, just enter and exit. Also, their influence in determining whether a shop lives or dies could be made orders of magnitude lower than players' influence. What I have in mind, is that if no player visits a shop in Scorn, the npcs can keep the shops alive, but as soon as players start visiting the shops, their vote counts so much more that if players do not go to shop A at all, the npcs' influence can't keep that alive. Some kind of differential metric between the shops, not an absolute one. An npc entering the shop is worth one life point for the shop, while a player is worth a 100. Then, whenever the lowest scoring shop is, say, 1000 points below the next lowest scoring, it dies. Also, this means that whenever the highest scoring shop is that 1000 above the next, it should expand its business... that driven more my player actions - eg, folks can by plots of lands outside of cities, etc or what not. This sounds nice. But... how do we keep track of who owns what? And how do the players find out if the beautiful spot they fancy is already owned by someone? At some level, if we let a player do it, then we could also let NPC's do it (some number of NPC's buy farms or whatever) Naturally, the npcs must basically be able to do whatever the players do. I'd like to see them enter dungeons themselves and join parties with players as well. Though the last type of npc probably would not be controlled by the sim code (if we choose to use that). (And I do not count the current hired hands in Scorn as npcs. They do nothing unless you hire them - not really very c in npc.) -Juha -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] New plugin: citylife - help needed
Out of curiosity, how hard would it be for city life to animate other things that are not NPCs? Am thinking along the lines of tumbleweed, whirlwinds, leaves and such. Not sure it is a suggestion yet. Was also thinking of objects the player might be able to walk on rather than have them be blocking. Well, you could expand the plugin to do that. Define eg trees as spawn points for leaves, maybe. If one were to do that, I'd suggest to generalize, ie define multiple spawnable lists, each with spawn zones and points. I looked a bit. The zones and points in code seem odd, but I guess probably mostly out of simplicity until it seems it catches on? It's a rough first implementation :) I didn't try that hard to adapt precisely to eg the port shape, and zones can just try to put on walls (but server won't let, of course). Feel free to change that, of course. In the suggested changes, it would probably make sense to define the zones in the maps themselves, maybe, or something not closedly linked to the server... Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Player accounts, new player creation mechanism
Hello. Here is a proposition for new player account mechanism and character management. To be clear: * player = human playing on Crossfire * character = ingame character When connecting to a server, a player can create or log in to an account. This account is linked to characters, and the player can manage (add, delete, maybe other things) them. Character creation mechanism is mostly moved to client, where the player can select race and statistics. I'd keep class to be chosen ingame for now, as it depends on maps and such. Characters can possibly be transferred between accounts. Account survives until removal by player, characters disappear on death on permadeath servers. Opinions? Suggestions? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Map logical linking
Hello. One issue I have with maps is that sometimes you have no clue what quest or thing they are linked to. Example: I was browsing (in the editor) maps in Navar, and discovered some quest spawning various maps, with keys in one or the other, but no idea where to find other maps. So I'd like to be able to easily find what maps are linked together for a quest. For this, I suggest to use the lore field in the maps, which is totally unused (it's loaded with other headers, but never displayed). Proposal for logically linking maps: * in one of the maps, probably the one with quest starting point or quest end, describe the quest in the lore field, and include what maps are linked to the quest, maybe more information like player level or reward? Minimum is the linked maps * in each quest map, add in the lore a reference to the quest and the map with all the information Since I'm (after all!) a developer, I could suggest to create an easy format for this lore field to be able to automatically extract information and make nice spoiler pages. But well, maybe not that necessarily to go that far :) Opinions? Suggestions? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] New plugin: citylife - help needed
Also spracht Juha Jäykkä (Sun, 03 Feb 2008 10:29:38 +0200): This is more difficult. Perhaps the npcs themselves could help with this? Perhaps the npcs could be made to go to the shops as well? They might not need to buy anything, just enter and exit. Also, their influence in determining whether a shop lives or dies could be made orders of magnitude lower than players' influence. What I have in mind, is that if no player visits a shop in Scorn, the npcs can keep the shops alive, but as soon as players start visiting the shops, their vote counts so much more that if players do not go to shop A at all, the npcs' influence can't keep that alive. Some kind of differential metric between the shops, not an absolute one. An npc entering the shop is worth one life point for the shop, while a player is worth a 100. Then, whenever the lowest scoring shop is, say, 1000 points below the next lowest scoring, it dies. Also, this means that whenever the highest scoring shop is that 1000 above the next, it should expand its business... Alternatively. Since the players are heroes, they could be opinion-makers and trend- setters. If they are seen favouring one shop, the NPCs will start preferring that one as well. If they avoid one, its popularity with the general populace will drop very fast... best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Player accounts, new player creation mechanism
Nicolas Weeger wrote: Hello. Here is a proposition for new player account mechanism and character management. Note that this has been discussed a lot before on mailing list on wiki - probably good to look there for some starting points on this. To be clear: * player = human playing on Crossfire * character = ingame character When connecting to a server, a player can create or log in to an account. This account is linked to characters, and the player can manage (add, delete, maybe other things) them. this is a step that is not there right now - I'd like a little more information on why to add an account that is linked to characters instead of just having the current method. Character creation mechanism is mostly moved to client, where the player can select race and statistics. I'd keep class to be chosen ingame for now, as it depends on maps and such. disagree on that - having half the character creation in the client and have still done on maps really isn't the right answer. A new player only has half the necessary information to create a character - race and stats. He chooses those, and then finds out that based on class, maybe he didn't choose good stats and race, and has to start over. Also, there really isn't much on the map related to classes - yes, there is a selection mechanism in the hall of selection, but all of those just use the generic archetype for the different classes. Just as we can send race information to the client, it should be easy enough to send class information to client. Give all those classes some unique type (if they don't have one already) so that the server can easily find all the classes and send relevant information. The data sent is really going to be in the same form as race data (stat adjustment, special notes, etc), so if we're sending one, sending the other wouldn't be much more work. If some server wants to add or remove classes, it is just a matter of changing the archetypes. Right now, if you want to change a class, you have to change the archetype and change the hall of selection, so just making it an archetype ability should make it easier to change classes. Characters can possibly be transferred between accounts. Account survives until removal by player, characters disappear on death on permadeath servers. I'd still need to see more information on what benefit/meaning accounts have here. The first that come to mind are for servers that want to be private or pay for play - they can then have some alternative mechanism to create the initial account (once I get the money, I'll create an account type of thing). Thats fine, but I'd almost say folks that want to run those servers should write and maintain that code. Second point is that it may make character management easier - I log in as mark, and I can see all the characters with my account. I say may make character management easier - this really depends on how many servers I play on, if I can get the same account name on all of them, etc. If I end up having different account names on the different servers, doesn't really make things much easier (OTOH, I suppose the client could remember different account names on different servers). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Player accounts, new player creation mechanism
When connecting to a server, a player can create or log in to an account. This account is linked to characters, and the player can manage (add, delete, maybe other things) them. this is a step that is not there right now - I'd like a little more information on why to add an account that is linked to characters instead of just having the current method. I think you partly answer your own question below, however, you might note comments about password management in my other reply, but I'll restate and reword the thoughts here in case it clarifies the point. I have many times thought how unfortunate that it is easy to use duplicate passwords from one server to another because each character needs a password... so, it is easy out of habit from typing a password on one server, to accidentally use it on another one. I don't know about you, but I don't trust admins on other people's servers. Consider especially cases where a server admin might be hostile for whatever reason. An admin should not be easily able to discern what someones password might be on another server. Naturally, you cannot protect a player from their own stupidity regarding intentional re-use of passwords, but I do think that lowering the risk of accidental re-use of a password is responsible design and indeed worth considering on that merit alone. Characters can possibly be transferred between accounts. Account survives until removal by player, characters disappear on death on permadeath servers. I'd still need to see more information on what benefit/meaning accounts have here. The first that come to mind are for servers that want to be private or pay for play - they can then have some alternative mechanism to create the initial account (once I get the money, I'll create an account type of thing). Thats fine, but I'd almost say folks that want to run those servers should write and maintain that code. Second point is that it may make character management easier - I log in as mark, and I can see all the characters with my account. I say may make character management easier - this really depends on how many servers I play on, if I can get the same account name on all of them, etc. If I end up having different account names on the different servers, doesn't really make things much easier (OTOH, I suppose the client could remember different account names on different servers). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Player accounts, new player creation mechanism
Here is a proposition for new player account mechanism and character management. To be clear: * player = human playing on Crossfire * character = ingame character When connecting to a server, a player can create or log in to an account. This account is linked to characters, and the player can manage (add, delete, maybe other things) them. See below. Character creation mechanism is mostly moved to client, where the player can select race and statistics. I'd keep class to be chosen ingame for now, as it depends on maps and such. Actually, I think this is the most difficult aspect of character creation at the moment. Without class selection in the same place as race and stats, it requires external resources to adequately design a character. If we're going to improve character creation, I'd say rolling in class to the creation process is far more important than the suggestion to have accounts on the server as it would be a major improvement for the player. Also, even if creation is pushed off to the client for execution, I think it wise to consider that the information needs to be supplied by the server to get away from some very clunky issues regarding information handling that has to do with character creation. At the moment, there are about 4 copies of the Hall of Selection with identical information about each class. This is a pain to manage, and, furthermore, if character creation is pushed to the client, then we don't want to have to maintain this information separately for each client. I was somewhat stymied by the great volume of technical nitpicks on Yann's idea about a login server as expressed on IRC. The implementation effort need not be that great, as can be determined by more carefully considering what actual work would be needed. It could centralize character creation in a way that provides both immediate and long term advantage. I saw no compelling reason to so thoroughly reject the suggestion and actually prefer that the idea of the server-side login server module be reconsidered, and integrated with this suggestion for client-side character generation. Characters can possibly be transferred between accounts. Account survives until removal by player, characters disappear on death on permadeath servers. I rather do like the use of a single password per server... that's always a pain in that I try not to reuse passwords from one server to the next in case they were to be breakable. I do not make a habit of trusting administrators on systems. Even if the same password is reused per server, it is still common for me to make the mistake of re-using a password from a different server out of typing habit. By making a login account, the password is created only once. I do see this as somewhat nice, but still it strikes me as not as much of a priority in that the value add seems somewhat low. The main reason to include it may be that if the design for a new character creation subsystem makes it easy to do, or drives development of a cleaner design, then it might be done. Kevin ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
