Hello.
Currently, Crossfire is the kind "many monsters, much loot, fast gameplay".
Wouldn't it make sense to change that?
Have less monsters, with combats not so fast, so strategy/tactics do play a
role - put a trap, try to lure the monster? use a dagger for close combat,
versus a sword for lo
> As an add-on to that, I'd still like to see a quest management system
> that also provides rewards in exp or spells or the like, so that the only
> way to get that isn't by killing monsters (this can also be done now just
> by updating maps).
Yet again I'll remind you: YOU CAN ALREADY GIVE EXP
Hello.
I've just committed an archetype, a test map and some server code enabling to
have transports that don't occupy the same space depending on the facing.
Check arch/transport/turningboat.* for an example, or maps/test/boat to see it
into action.
Warning: this only works for a transport th
Hello.
I do plan to have a C++/Qt (core only, no X dependency) version of the server,
with advanced stuff (dynamic archetype loading, ...).
I do expect / want this version to become the official server ("winning" on
features, hopefully :)).
But I definitely don't want a fork, so I'd like to wo
> I have seen C++ messes that I would hate to see in CF, but then it is well
> known that you see current CF code as a mess in itself, so perhaps it has
> potential for cleaning up the code...
Well, that is one of the points of the rewrite I'm proposing, indeed...
> I depend on trunk not being br
> Seems like a sort of odd decision since most recent conversations have
> seemed to have decided that more content and less code work is what is
> really needed to be done, but this seems to be a big code project...
Yes, it has the potential to be ambitious.
> And just given the size and cha
> From past experience, I'd tend to lean towards writing a server code "from
> scratch", possibly recycling various elements by cut'n'paste, instead of
> evolving a codebase that is already of questionable cleanliness.
Yes, that's indeed a solution I can see, and it may be the choice I (and
other
> Well, one thought, is there any reason Qt-core as opposed Boost C++
> perhaps? If I understand correctly, they provide similar faculties but
> Boost C++ also provides some rather nice looking python bindings that
> may make it far easier to move cfpython to a C++ code style.
>
> I'm not saying an
> I see two good reasons for Nicolas favouring Qt over Boost:
>
> - He's more familiar with Qt, and having to learn another toolkit,
> especially something as complex as Boost, would be somewhat of a waste of
> time;
This is true, but I'm hopefully not the only one writing the server code :)
There
Hello.
Ok, from what I gather, people aren't against massive changes on the server.
Reminder, though: content goes first, always :)
So feel free to ignore all the technical aspects if you only want to make
content :D
So here is what we'll do:
- put on a wiki page what kind of game we want (quic
Hello.
I've put a first basic draft at
http://wiki.metalforge.net/doku.php/dev%3Aserver_design
The first step, though, would be to define the exact kind of game we want,
obviously :)
Feel free to tweak the page and add stuff you think is missing!
(note: the dates are informative, can be cha
Le jeudi 04 décembre 2008, Kevin R. Bulgrien a écrit :
> The trunk GTK-V2 client is considered fixed as of SVN 10827. This
> client is compatible with branch servers (metalforge).
>
> Some additional attempt will be made to verify/reproduce/fix problem
> in the GTK-V1 client. Branch client code i
Hello.
Reminder, the page http://wiki.metalforge.net/doku.php/dev%3Aserver_design and
specifically the 'player-wise' section is waiting for you and your ideas! :)
Nicolas
--
http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de
l'aléatoire !]
signature.asc
Description:
Hello.
Here are some propositions to make CF a different but hopefully funnier
game :)
1) Don't give out stats to players. Don't give HP/SP/GR/ whatever. Only give
hints about the health ("you feel very bad", "you bleed a lot") and such
things ("with great effort you take the armor, but fall o
> If the human players were spending bunch of time doing calculations (like
> in live action games), then simplifying such things may make more sense.
That is the point, I think: a fun game isn't a calculation game. So why put
calculations we don't need? :)
> Likewise, if the game was much m
Hello.
> All GTK clients on trunk and branch are now considered free of the
> infamous and elusive double-character bug. i586 clients were tested
> at SVN r11002, and x86_64 clients were tested at SVN r11012.
Nice, thanks for the fixes.
> Whomever builds the Windows client might want to rebuild
Hello.
> I'd like to propose that, before we set off on major rewrites, we
> officially give up on the previous 2.0 effort, and release what's
> currently on trunk as 1.12. (Which probably means either merge the
> branch, or abandon it and just use trunk...)
>
> There are major improvements on tr
> Whomever builds the Windows client might want to rebuild a new
> snapshot.
Done and published.
Nicolas
--
http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de
l'aléatoire !]
___
crossfire mailing list
crossfire@metalforge.org
> > Given that we don't have anyone wishing to coordinate content and maps
> > and make them coherent and fun, I have no intention to do massive
> > changes to the code, so that question is probably rhetoric :) (unless
> > someone else feels like doing such work, obviously)
>
> That's not true... I
> quoth Nicolas Weeger as of Mon, 22 Dec 2008 08:39:42 +0100:
> > Yann dropped the project. And I didn't know you volunteered :)
>
> I told him, and Alex, and I thought I told you too, but maybe I
> didn't :-) let's make it official then. If nobody objects until
Hello.
> I want the world to have a distinct personality and a
> clearly-defined history. Common people (and beginning
> characters) don't know the whole of this history of course, but
> if you play every single quest, you should learn it to the extent
> that an average cultured modern person kno
Hello.
> =
> Core history of the new Crossfire world
> =
Based on your history, I wonder:
- will we have research lab on magic/technology, aimed at improving the powers
of this new world?
- where is the super tech
Happy new year everyone!
> Actually, I think I'm over-reaching here. All considerations of *how* to
> deal with gameplay, especially game mechanics, are just IMHO and
> suggestions. I'll say what I think, reply on threads when asked, but in
> the end, go with whatever the coders decide :-)
No.
to actually decide when
needed - so a gameplay leader, and a content leader, both are needed.
And I don't worry for technical leadership - there are enough people willing
to code for Crossfire, besides the code is enough for now for most things
planned in the next releases.
Nicolas
Le m
Hello.
I'd like to suggest a [img name="xxx"] tag for client-side rich tags, as
defined in "mediaTags".
As implied, the tag would display a picture from its name :)
Uses:
- illustrate a text
- show a bigger picture of something (map, illustration, ...).
What do you think?
Nicolas
--
htt
Hello.
How would one integrate old (as some hundred years old) in-game stories in the
gameplay flow?
Right now, we have kind of the "Know-It-All" sage who will conveniently know
everything of things that happened hundred years ago, without any mistake or
such.
Things I could envision:
- o
Hello.
Suggestion to change the various messages at login:
"Hello you nice soul, and welcome to this world.
My memory is slightly blurred lately, could you tell me your name, again?"
[prompt for name]
If new player:
"Ha, you're not on my registers, so you just had the authorisation to
inc
> If one were to go on this logic,than for any given message, it would be
> reasonable for what the player sees to vary based on literacy.
I was thinking of script-based text garbling, actually, but your approach
works too.
> I do agree that some way for the player to handle/deal with these
> A segue to something that has bothered me a bit: there are no longer any
> closed houses in Scorn, having been replaced with randomly generated ones.
>
> However, there is not much point in visiting them, as they are only single-
> level places with the randomly-generated paraphernalia. If you ar
Hello.
> Off the top of the head, I could imagine some quick cases, like:
> - Book containing information about a monster, and containing a picture of
> that monster
> - Same for other objects (more likely artifacts or unique rare stuff).
> However, from a tutorial perspective, displaying the d
> One question would be: What do you do on wrong password? A not too
> uncommon situation is you have a new player who is trying to use the name
> of an existing character. We probably want something that is clear that
> the existing name is in use, but at the same time isn't too confusing if
> It seems these kinds of ideas are good, though I'm not to sure about
> "wrong" information without some not insanely hard to find way to validate
> wrong data. Of the listed ideas, the first seems most likely to enhance
> play. The last seems reasonable, though perhaps better done by having the
Hello.
Right now there are many houses / maps in the various towns which have
monsters.
What about moving all that outside the towns (which after all have guards and
such, and should probably be "safe" places?), and putting them in the country
side?
Except maybe some mice or dogs here and th
Hello.
> Suggestion to change the various messages at login:
Apparently, those messages are part of the motd / server rules / news.
So they could be changed as part of the default installation, but not that
useful for existing servers.
It's probably more a client-side modification.
Or maybe
> Obviously real maps would be the best solution. However, I think the random
> map generator does a fair job, specially on the multi-level dungeons;
> IMHO the different Scorn quest maps turn out nice and exciting.
>
> The fact that it does as reasonable a job as it does means that it might be
> w
> More likely want to have something like an img tag with hints, for things
> like popup, desired size, etc.
Then let's do the whole trick and use some XHTML subset?
> Note that anything that deals with popups can be annoying in some areas.
> If you read some scroll and it suddenly popped u
> I think we have sort of learned over time that coding in such solutions
> tends to lack flexibility we generally desire, or don't give as good
> results as we might hope.
>
> We could certainly have script based text garbling, but having it do it
> so that it doesn't look like something that
> Fair enough. I think my point may be more that the spec (for lack of
> better work) should be aware we may want to add extra specifiers, and while
> they client has not requirement to handle them (since we don't know what
> they are), it shouldn't suddenly break if they show up.
>
> It could
> While you may jest, I still think that last comment is true.
>
> As a very basic level, the client could request both the username &
> password at once for login, with another button with something like 'create
> new character'
>
> Depending on what the user does, gets appropriate results -
> Certainly for scorn, as that is a starting area, it makes a lot of sense.
> And a lot of the monster maps in scorn don't make a lot of sense.
>
> For navar city, there are several quest lines that sort of go with some
> of the maps in the town (old wizards tower, smuggling operation, etc).
Hello.
How should the monster level relate to the player level?
What is the meaning of the monster level?
What I can think of:
- monster level is (roughly) the level the player should be to kill it
- monster level 1 has some characteristics ; each level can improve a skill /
competence / max h
Hello.
> Yeah, but as said, that looks likely script based garbling. In a more
> real sense, if the character is not literate enough, they might not
> understand the message or in fact misread it. And randomly replacing some
> words may not do much - you could probably replace a fair number of
Hello.
> I agree that you probably want other text - only popping up an image is
> not useful.
Up to the map designer putting the text :)
> Older clients pose more an issue. If you are doing something like maps,
> it seems fairly difficult to try to support that with old clients (you
> cou
Hello.
> Should some game things maybe be made account wide properties and not
> character properties? Off the top of my head, I could think of things like
> apartments.
KISS for now. Let's just make an account, we'll think about shared apartments
later.
Though I'd rather have shared apartmen
> That is how I see it - monster level and player level should roughly
> match. But in this context, I'd sort of say a group of monsters and player
> level should roughly match.
>
> For example, at first level, the character will be fighting typically
> large groups of level 1 monsters, it's no
> Well, Scorn also has an explanation on why neglected houses have monsters
> in them: the situation with Old Town.
Talking about that quest, would anyone have a description? That is what items
one can find, clues there are, and so on?
:)
Nicolas
--
http://nicolas.weeger.org [Mon p'tit coin du
Hello.
On trunk, an interesting issue: a dragon praying on an altar to become
follower of a god will lose burning hands / medium fireball abilities.
The issue seems to be "become_follower" (server/gods.c), which removes the
FLAG_STARTEQUIP spells - including those abilities.
I'd say to exclud
Hello.
Here are two proposals for spells. They are not totally incompatible, but
well, even only one could fun IMO :)
The aim is to reduce the number of spells, and also make it more customizable
for players;
I'll use the fireball spell as an example.
Spells with options.
--
Hello.
> That seems a correct solution. If that doesn't work for some reason, the
> key/value lists could be used to denote the source of such spells instead
> of overloading FLAG_STARTEQUIP meaning.
Hopefully fixed, and cleaned/tweaked some related code.
Nicolas
--
http://nicolas.weeger.o
> Its a different topic than this, but having such a pluggable interface
> would be nice. The biggest pain would be having to emulate it if a real
> database is not available (emulation would probably mean a flat file with
> fields separated by something or another)
>
> I can think of all sort
Hello.
> One thing I did think of might be DM access - maybe the dm_file should
> use account name instead of/in addition to character name?
>
> It strikes me that if you are going to trust a player with dm access, you
> probably don't really care what character they are playing.
Yes, makes s
Hello.
> Like above, balancing that can be tricky - have to be careful what you
> let them tweak to once again not get overpowered stuff.
>
> Here is an idea I have, which takes some of these ideas into
> consideration. This is sort of an amalgam of the custom spell creation in
> the elder s
Hello.
> With the recent discussions on spells and this or that, tossing out this
> one - get rid of AC and WC (one goes with the other really).
So what is the rule for hitting/defending?
Will there still be sword+2? +3? what about armor?
What is the difference between a chain mail and a pla
Hello.
> Basically like spells - if you aim at something, you hit it. Aim in this
> context may just mean standing next to a monster and moving in that
> direction. For arrows it would be a lot like bullets, etc. One could think
> of it like always rolling a 20 on the attack roll (there is spe
> Looking at the code, something vaguely related here is character naming
> standards.
>
> Right now, character names are limited to letters and - or _, and the -
> or _ can not be the first letter.
>
> Spaces and numbers are not allowed. I can certainly understand spaces,
> as on unixlike s
> Maybe. Or just say that the level basing is that a character of level X
> can reasonably take on a group of 5 monsters also of level X.
>
> But as said, I think some of the failure is the AI in crossfire, so the
> make up for stupid monsters, there are just more of them.
That's part of the
> I haven't played it for a while, but one thing I recall is that the level
> range is pretty broad.
>
> Some of the undercity maps are suitable for low level characters (less
> than 5), while others are much tougher, with things like wyverns. So I'd
> probably say the level range is 0-20, but
Hello.
> Recording for posterity a discussion in IRC about quests. I've probably
> forgotten a few things, but hopefully I got most of.
Seems ok for me.
Some steps:
- check existing quests, required level, existing hints
- fix stuff so there is a real storyline
- add hints at many places
Hello.
I'm currently tweaking Darcap, to add some (I hope) interesting things to the
town.
My plans include:
- move quest-related stuff outside the town
- no monsters in town houses (but maybe through wells or holes)
- linked characters, based on player's behaviour
- improved NPC interaction
Merry Christmas to everyone :)
Nicolas
--
http://nicolas.weeger.org [Mon p'tit coin du web]
signature.asc
Description: This is a digitally signed message part.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/
> Toi aussi! J'ai vu qu'il y avait pas mal d'activitée récemment sur la
> liste de distribution, je crois qu'il va y avoir pas mal de
> changements dans les nouvelles versions de crossfire... Bonne chance!
Hum, pourrais-tu me rappeler ton pseudonyme ? ^.^;;;
(je suis mauvais en « vrais » nom, des
Hello.
> Sounds like a good test city to work with.
>
> Does, or will, your work also include /darcap/town2/* maps?
Yes, probably.
Rewriting the elemental quest could be on my TODO list.
> If your changes will have a major impact on the existing guilds in
> Darcap for the trunk servers already
Hello.
> Not sure what that means - do you mean linked quests, or something else.
Linked characters. So you'll only get hints from T if you talked beforehand to
Z. Or things like that.
> I'm presuming/hoping this plugin will not be darcap specific, and can be
> used for other maps as the
Happy New Year to all the members of the team!
May 2010 bring you inspiration to tweak maps, add content, write (and
implement) good stories, and such things ;)
Nicolas
--
http://nicolas.weeger.org [Mon p'tit coin du web]
signature.asc
Description: This is a digitally signed message part.
_
Hello.
I'd like to propose a (menu-driven) dialog mode for players.
Something like what you can find in various RPG games.
Description:
- started when player says something to a NPC, like now
- player is presented with text and options, and a free text zone (to not have
all options visible/obvi
Hello.
I'm wondering about NPC (not monsters, but "real" NPC the player can interact
with) respawning when killed.
If for instance you kill the owner of a tavern, should she respawn?
I can see three options:
- keep the same way it is now, respawn at map reset
- make (some) NPCs unkillable
- ge
> So the tavern owner would never respawn .. ever?
That's the subject of this thread :)
> What about making the NPC un-attackable or immune to all attacks?
=> unkillable.
> Going with you preferred option listed above.. what happens when that
> NPC dies for some reason? Another nearby NPC is
> Would the dialog system (at least, initially) work like it does now?
>
> Meaning, NPC response is based on key word(s) from the player character?
Yes, probably keywords.
Though the player wouldn't use the 'say' command, but click on the selected
reply in the dialog.
Game-wise the player will se
> True - there is no migration plan/support. However, there are some
> number of servers right now that running trunk bits.
>
> But maybe we just state all trunk servers must convert over, and let them
> deal with any conflicts they have on their own.
As I see it, first will be server-side su
> > I assume this would apply also to stores where the merchant is
> > represented by a NPC inside the store (for example in Pupland)?
>
> I would think so.
Actually I haven't thought of that. Or at least killing the merchant wouldn't
close the shop.
> Some mechanism to relocate players, et
> I like it. I've never really liked the somewhat random approach right
> now of trying to figure out what keywords the NPC is looking for.
>
> Do you imagine do this by scripts, or extending the msg/endmsg logic?
Right now there is some support for that already.
So it would be a matter of ex
> Having new ones spawn is reasonable, but I then start wondering what do
> we really get from that vs making them unkillable? If the bar tender is
> killed and in a minute a new one shows up with all the same information,
> not sure what letting them kill gains us. Sure, it may be more realist
Hello.
To have some coherence in maps in town, I'd like to suggest the following
rules for exits:
- in the world map, you need to apply an exit to enter the map
- in a town map, exit is applied automatically when you step on it
Does that sound ok?
Nicolas
--
http://nicolas.weeger.org [Mon p't
> Yep - that is my next step or work.
>
> The only complication in all of this is player name uniqueness. If we go
> by the idea of storing player files as lower case names, so there can only
> be one 'Mark' player on a server, regardless of capitalization (mark, mArk,
> etc), ideally you want
> I'd say this depends on how the town sub-map you are exiting is built,
> either including the house surroundings or just an interior view.
>
> If there is a door icon, you would obviously want it to work only
> when applied, but if there is an "whirlwind" exit (or an hidden exit,
> for example un
> I think as much as anything else, the meaning of the exit (based on
> appearance) should be consistent.
Yes, indeed.
> For example, stairs no matter where they are, should require an explicit
> apply to use them
>
> Oak doors could always be auto apply, etc. Buildings are always explicit
Hello.
Considering the low feedback/participation on the list, I'm totally changing
how I work :)
I've put my plans for the future at
http://wiki.metalforge.net/doku.php/user:ryo:todo and I intend to do them,
except maybe the "Various" ones.
If you have questions, feel free to ask me (this l
> I know someone sort of looked into doing crossfire in C++ several years
> back. Their opinion was it was probably easier to start writing the code
> from scratch vs trying to convert the existing code. I haven't looked at
> it enough to say for sure, but I could certainly see it may be easier
> I wonder if you could do that if #ifdef's :)
Why #ifdef's?
Just put the check in the code, at least it won't be forgotten!
> Yeah, no account support isn't hard, because that basically just uses the
> code that is there instead of the new code. So very simple, it is just
> having some leg
console?
> >
> > On Fri, Jan 15, 2010 at 1:16 PM, Nicolas Weeger
> >
> > wrote:
> > >> I know someone sort of looked into doing crossfire in C++ several
> > >> years back. Their opinion was it was probably easier to start writing
> > >> t
Hello.
I've dumped at
http://wiki.metalforge.net/doku.php/user:ryo:todo#quest_mechanism some ideas
for quests mechanisms.
I'll first just do the low-level tracking mechanism, then I'll see how to
handle things.
Comments and ideas welcome :)
Nicolas
--
http://nicolas.weeger.org [Mon p'tit
Hello.
I added 3 fields for alchemy formulae, 'min_level', 'failure_arch'
and 'failure_message'.
Description is in related file.
I also changed the recipe of 'mushroom of Gourmet' to yield ashes instead of
blowing up or other nasty things in case of failure.
Min_level isn't used yet.
Nicolas
Hello.
I just added a basic low-level quest state information storage mechanism
(whao, *that* is a great name for a poor code :))
From the documentation:
***
Quest support information
-
Current quest suppo
Hello.
Proposed change for 'use_skill' behaviour for alchemy-like skills:
- remove the item identification part; use_skill only attempts alchemy (or
equivalent)
- add a new 'identify' command, that will identify based on (alchemy-like)
skills the player knows
Comments? Opinions?
Nicolas
--
> I don't know a lot about Qt, but it looks like the big bonus is better
> cross platform stuff. POSIX doesn't define everything we use, as evidenced
> by a fair number of #idef
Forgot but you also gain multilinguage support through a nice mechanism -
tr("Your text with %1").args(parameter),
> I don't like the idea of putting an actual exit in the code or something
> - that could be pretty annoying if it is a section of code not executed
> very often, but someone runs into and causes the server to exit (really
> annoying for server admins who servers suddenly start exiting through no
> - Yes, there should be some in game mechanism to see quests I've signed up
> for. This is purely a convenience function - sure, in real life, there
> isn't a list floating about saying everything I have to do, but this is a
> game. If there is no such list, then more likely I'll end up having to
> I'm presuming you are saying that the same skill, like now, has multiple
> ways to be used, and different commands should be used.
I'm talking about alchemy-like spells, actually.
The proposed change is for those skills to only do alchemy and not
identification, and add a new 'identify' *glob
> I'm not quite sure how to fix that - I had suggested in the distant past
> that spellbooks could be cursed, and if you read them, you'll lose that
> spell (as a problem right now is that trying to read a spellbook is an easy
> way to identify it) - but with that change, I suspect players will j
Hello.
I just committed the framework for player knowledge management.
For now it only tracks alchemy formulas, but it shouldn't be hard (or I made a
design mistake!) to extend to monsters, and other information thought to be
relevant to track.
This commit introduces the new 'knowledge' comm
Hello.
Right now, implementing quests can be pretty hard, since it can mean
scripting / coding, things like that.
Therefore I hereby volunteer to implement, totally or partially, quest ideas
you could have :)
My conditions:
- I'll implement only if and when I feel like it, obviously ;)
- I
> I submitted as patch 2934041 to sourceforge the micro-change to add
> an exit lever to the alcove in the Devourer's temple lower level.
Applied to SVN trunk, thanks :)
(if someone could close the patch on SF:
https://sourceforge.net/tracker/?func=detail&aid=2934041&group_id=13833&atid=313833
)
> Even the old method of just releasing something every few months with
> version number++ worked out reasonably good.
>
> There was never a perfect version, but new features got out there, bugs
> would be found, etc.
>
> I might be more inclined to call it version 1.50 - the trunk has moved
> Ok - in a sense, it is somewhat acting as a predefined binding, but also
> using an alternative use for the skills.
Correct.
> Are there any skills out there that only identify objects?
Detect magic / curse. So the logic for "use_skill" for those will just be
changed for "no specific use
> That might be simpler. But a general evaluation of the skills, what they
> do, and if they can/should be adjusted/made more useful could be in order.
>
> Things like woodsmen doesn't have any skill levels IIRC, because there is
> no proper way to gain exp. As such, you gain it, and that is
Hello.
There is a bug / incoherent behaviour with multiface items which are not
monsters.
Best illustration: /scorn/misc/castle_kitchen
Check the tables - sometimes the item will be on top, sometimes under.
And the object_fix_multipart() function doesn't really concern with the exact
layer to
Hello.
I just committed to trunk a small patch making NPCs stand still for a few (3
to 9 of their moves) ticks after being talked to.
Only applies to NPCs.
Could probably be smarter, feel free to fix it :)
Nicolas
--
http://nicolas.weeger.org [Mon p'tit coin du web]
signature.asc
Descripti
Hello.
I just committed a small patch enabling spells to require and consume items
when cast.
The patch uses a 'casting_requirements' key (in the spell object itself) to
enforce restrictions.
The value should be a list of items, like the alchemy uses.
Currently it is restricted to 10 items (har
Hello.
I just added a small protocol extension.
"spellmon" setup command can now take a value of "2", resulting in more spell
information sent (including required items to send, and if the spell needs
arguments to be used - text for rune of marking, things like that).
Hopefully JXClient will
> Even if the spell (and skill) were removed, it probably wouldn't mean
> much so long as the detect curse tables still exist.
Unless the tables aren't infaillible and cost a lot?
If it's 10 000 diamonds each detect, and it can fail (or curse the item?),
then it gets really expensive to check :
401 - 500 of 930 matches
Mail list logo
