Lalo Martins wrote:
> All right... with the help of "crossfire traffic" and svn, I compiled a
> list of what's in the trunk and branch.
>
> http://wiki.metalforge.net/doku.php/trunkbranchchangebreakdown
>
> Comments welcome.
>
> As far as I've seen, the only change that breaks character compati
Lalo Martins wrote:
> quoth Mark Wedel as of Thu, 08 Jan 2009 22:08:38 -0800:
>> Lalo Martins wrote:
>>> As far as I've seen, the only change that breaks character
>>> compatibility is the combat rebalance. So until/unless we hear from
>>> the code leader
Hmm - I seemed to have not received some of the messages in the thread, but my
two cents (take it how you will)
Most all of the leadership roles have a fair amount of overlap and cooperation
needed, and all that gets tricky.
If we define this as the various roles:
content leader (maps, archety
Otto J. Makela wrote:
> Rick Tanner wrote:
>
>> While in DM mode, check and see what material those items are made of.
>> You'll likely find that some are "material: granite" or something along
>> those lines. AFAIK, this is what keeps the items from merging.
>
> I took a look at some "random le
Lalo Martins wrote:
> I'll make content and client releases this week. There's one open
> content bug (that I'm able to fix myself), and no open client bugs that I
> know of.
Taking a quick look at that list, some comments.
First question - is it known if these bugs still exist in 2.0 serv
Kevin R. Bulgrien wrote:
>>> This brings the usual question :-) any objections if we nuke x11 and gtk
>>> from the tree for trunk (and 1.13)?
>> It's time... the main holdout was due to the lack of another Windows
>> solution (at least until jxclient is considered complete/stable).
>
> One of the
Klaus Elsbernd wrote:
> Well, one cent from an old user:
> lalo.mart...@gmail.com said:
>> This brings the usual question :-) any objections if we nuke x11 and gtk
>> from the tree for trunk (and 1.13)?
> I would like to remark, that there are more than windows systems out
> there. For example sim
Just another notes on clients:
For the gtk-v2 client, having 3 different draw modes (pixmap, opengl, sdl)
seems like overkill and is extra maintenance work.
pixmap is no frills, but is always sure to be there, so should be kept.
I don't think we need both opengl and sdl support. I'd s
Quick notes:
Magic needs more rebalance work, and the note about destroy objects is too
true.
Changing how often (if at all) magic destroys item is one of those things to
do.
Magic should probably destroy items on occasion, but that might be limited to
things like fireball or other large
As the original write of the output sync, here is some background and my
thoughts.
That code was originally put back in before the client/server split. At that
time, any control of messages had to be done is the server - there was no
client
to do that task. This really makes it a bit of
Kevin Bulgrien wrote:
> The message types in the system are consecutive numbers from 1 to 20. They
> are:
> I would like to consider changing the message types to bit values so that it
> is easier to use masks to detect message types instead of having to do
> sequential tests for individual valu
The server has some number of tests that can be run if you have the necessary
dependencies and do a 'make check' to run them.
While many of the tests are always deterministic, some of them doing things
that are not deterministic - call treasure generation routines. The processing
of that
Nicolas Weeger wrote:
> 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 mistak
Alex Schultz wrote:
> On Mon, 16 Nov 2009 23:11:58 +0100
> Nicolas Weeger wrote:
>
>> Suggestion to change the various messages at login:
>>
>>
>>
>> What do you think? :)
>>
>
> I for one, like it. I'd say... commit time unless anyone has any
> suggestions :)
I agree - better it is now, in
Nicolas Weeger wrote:
> 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,
Kevin Bulgrien wrote:
>> 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
I was thinking about this some more, and had some other ideas.
If one thinks about it, even someone not very literate can still read
something - he isn't going to read a college level physics book, but could read
a newspaper perhaps.
If one were to go on this logic,than for any given mes
Nicolas Weeger wrote:
> 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?
Nicolas Weeger wrote:
>> 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 think we have sort of learned over t
Nicolas Weeger wrote:
> 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 tutoria
Nicolas Weeger wrote:
> 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
Nicolas Weeger wrote:
>> 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
Nicolas Weeger wrote:
>> 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 so
Andreas Kirschbaum wrote:
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?
>
> I'd rather keep the existing media tags implementation rather than
> switching to anoth
Nicolas Weeger wrote:
> 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
That is how I see it - monster level and player level
Nicolas Weeger wrote:
>> 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 doe
Nicolas Weeger wrote:
>> 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
Nicolas Weeger wrote:
> 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.
Nicolas Weeger wrote:
> 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 - includi
Nicolas Weeger wrote:
> Hello.
>> I'd almost rather just have the server dump all those to the messages
>> file, and then go through and so some cleanup.
>
> We need a way to generate messages from the archetypes, though, so when
> archetypes change we don't forget to update messages.
I agr
Alex Schultz wrote:
> On Sat, 05 Dec 2009 22:29:36 -0800
> Mark Wedel wrote:
>
>> Nicolas Weeger wrote:
>>> Then that's not "matching" :)
>>> A real match would be a level 5 monster being able to kill a level
>>> 5 players.
>> May
Nicolas Weeger wrote:
>> But I'm also not sure if your ingame comment refers to selecting a
>> character to play or creating a new one. For creating a new one, we could
>> perhaps leave the existing mechanism there since redoing is more work. But
>> making in game (map based) character selecti
Otto J. Makela wrote:
> Nicolas Weeger wrote:
>>> 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?
>>
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).
There are a few reasons for this that I found from my rebalance work:
- Going on a rough target of opponents should hit each other about 25% of the
time (fig
Nicolas Weeger wrote:
> 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.
> T
Nicolas Weeger wrote:
> 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?
Basically like spells - if you aim at something, you hit it. A
Recording for posterity a discussion in IRC about quests. I've probably
forgotten a few things, but hopefully I got most of.
One of the issues right now is that for most maps, there is no storyline.
You
have a bunch of maps which you go and kill things and serve no other purpose.
In a
Nicolas Weeger wrote:
> 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
Nicolas Weeger wrote:
>> 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
Nicolas Weeger wrote:
>> So my suggestions on this:
>> - Allow numbers in names - just the name can not start with a number.
>> - Going forward, names should be unique in a case insensitive manner. The
>> player can still choose variations on capitalization, you just can't have a
>> 'mark' and
Nicolas Weeger wrote:
> 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
Having the NPC's be unkillable is the easiest approach - all that is needed
is
set up of proper immunities, etc to do so.
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 minut
Nicolas Weeger wrote:
>> 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 dia
Otto J. Makela wrote:
> Mark Wedel wrote:
>
>> One could even see the tavern closing down (people can not enter it),
>> which
>> would force a reset sooner. Could be said that new workers need to be
>> found,
>> damage repaired, etc.
>
> I assume
Nicolas Weeger wrote:
>> 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 i
Nicolas Weeger wrote:
> 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
That sounds good.
> - in a town map, exit is applied automatically when you step on it
I take tha
Dany Talbot wrote:
> "move to Qt/C++, to not reinvent the wheel all the time; and massively
> clean the code"
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
Nicolas Weeger wrote:
>
>
>> The problems we run into is that tends not to be done/not clear what
>> 'some time' is. 6 months? 3 years?
>
> Add near your checking code:
> if (current_date() >= "may 2010") {
> LOG(llevError, "obsolete code detected!\n");
> exit(5);
> }
>
> Issue
Nicolas Weeger wrote:
>> 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
>> apply, and so on.
>
> I'd say explicit apply for all things you'd expect to use/apply in re
Nicolas Weeger wrote:
> Hello.
>
> Considering the low feedback/participation on the list, I'm totally changing
> how I work :)
>
Seems like a reasonable idea. I've made a list of stuff I plan to work on -
I
put it at:
http://wiki.metalforge.net/doku.php/user:mwedel:todo
Plus side is t
Nicolas Weeger wrote:
>> 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!
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 ex
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 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 certa
Nicolas Weeger wrote:
> 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 :)
M
Nicolas Weeger wrote:
> 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
Otto J. Makela wrote:
>
> PS. If dragons don't have hands (the logic behind "no swords", I think),
> where do they wear their rings? And why do dragon monsters often leave swords
> when you kill them?
People have suggested all sorts of places where dragons may put those rings -
tail, horns, et
Nicolas Weeger wrote:
>> 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
Alex Schultz wrote:
> On Mon, 18 Jan 2010 18:33:44 +0100
> Nicolas Weeger wrote:
>
>>> I think one change, relative to food, is for all flesh type
>>> things (which can be eaten as food) should have some time limit
>>> where they start to decompose/rot. I shouldn't be able to carry
>>> around a
Nicolas Weeger wrote:
>> 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
Otto J. Makela wrote:
> Mark Wedel wrote:
>> Alex Schultz wrote:
>>> Expand cooking to allow players to salt the meats and such? Perhaps
>>> make weight-reduction-enchanted containers have some kind of partial
>>> preservative magic? That would help trolls :)
So as noted someplace, my thoughts for login is this:
You log in with account name & password.
You then see list of characters associated with that account, and options to
add
new one.
In that list of characters, what would useful information be? My thoughts
right now:
-name (obviously)
Nicolas Weeger wrote:
>> The release methodology sort of needs to be sorted out - if we plan to do
>> a lot of cleanup (which may break things), I'd sort of like to do that
>> before the first rc - typically you make an rc when you think you are about
>> ready and are trying to sort out bugs.
>>
I'm writing this message to mostly capture ideas/thoughts from last nights
IRC
discussion before they leave my brain.
The basic idea is to communicate all face (and I think animation data) to the
client before play starts. This should improve bandwidth some (no spike in
sent
data when e
Nicolas Weeger wrote:
>> 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
Nicolas Weeger wrote:
>> Even if cursed items are impossible to identify, I suspect players will
>> just wait until they are in town to see what they are - It would such to
>> use one in a dungeon and find out you are in bad shape because you are
>> stuck wearing crappy armor.
>>
>> Live actio
Nicolas Weeger wrote:
>> In that list of characters, what would useful information be? My
>> thoughts right now:
>>
>> -name (obviously)
>> -class & race
>> -level
>> -face (not as much useful, but gives something nice for the client to show)
>>
>> Anyone have other thoughts?
>
> That seems
Nicolas Weeger wrote:
> 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 li
Nicolas Weeger wrote:
> 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.
> Cur
Nicolas Weeger wrote:
>> This probably isn't a problem until spells that use this functionality
>> become widespread - my main concern in there may be some confused/upset
>> players if there are spells that end up using valuable items.
>
> Hopefully, client will warn when selecting such a spell
Nicolas Weeger wrote:
>> Note one issue there - if I use sense curse and find cursed items, I
>> typically don't want to then identify them, as you can sell cursed (but not
>> identified) items for some nominal amount of money.
>>
>> So my standard procedure was always:
>> detect cursed and m
On 01/31/10 04:40 AM, Nicolas Weeger wrote:
>>The basic idea is to communicate all face (and I think animation data) to
>> the client before play starts. This should improve bandwidth some (no
>> spike in sent data when entering a new map to send images, etc). This also
>> simplifies a lot of
On 01/31/10 04:35 AM, Nicolas Weeger wrote:
>>But I have a feeling players will easily be able to know/defeat these
>> things.
>>
>>As said, getting stuck with a cursed item in that dungeon would be really
>> annoying. Especially if you thought it was a really good item (if it isn't
>> a g
On 03/ 1/10 05:32 PM, Alex Schultz wrote:
> I haven't been very active with things these days, but I'd be in
> agreement with a release being made. My one reservation is that of
> those options, I wouldn't want it numbered 2.0 since I don't think
> enough has happened to justify that yet.
Making
On 02/28/10 12:50 PM, Nicolas Weeger wrote:
> Hello.
>
> What about we just decide to do a release of trunk end of march?
> Whatever it is called, 1.5, 2.0, 1.9, and such :)
>
> Then let's kill branch, and work on trunk.
>
>
> Does that sound ok?
Just to follow up on this some more and other ide
On 03/15/10 12:41 PM, Nicolas Weeger wrote:
>>Target release for end of March or so. Are there any must fix bugs to be
>> dealt with? I hope to have the new account login stuff done soon, but I've
>> been saying that for months :(
>
>
> The recent object_free2() and object_free_drop_inventor
On 03/19/10 11:24 AM, Brendan Lally wrote:
> Hello,
>
> The following is a proposed addition to the crossfire protocol to
> enable the clients to show monster health bars.
Just a note, this was discussed several years back, and at that time, there
was concern that that 'gives away' information
On 03/20/10 12:55 AM, Nicolas Weeger wrote:
> Hello.
>
>>Yes, that is the ideal case, especially if there is lots of active
>> development.
>>
>>If there isn't, it is simpler to just freeze the trunk gate for anything
>> but bug fixes needed for the 1.50 release. That way quality can get
>
On 03/20/10 10:12 PM, Alex Schultz wrote:
> On Sat, 20 Mar 2010 21:14:41 -0700
> Mark Wedel wrote:
>>Just a note, this was discussed several years back, and at that
>> time, there was concern that that 'gives away' information to the
>> player that perhaps s
On 03/21/10 01:37 PM, Brendan Lally wrote:
> On Sat, 20 Mar 2010 21:14:41 -0700
> Mark Wedel wrote:
>
>> On 03/19/10 11:24 AM, Brendan Lally wrote:
>>> The following is a proposed addition to the crossfire protocol to
>>> enable the clients to show monster health
So I'm actually making some real progress on the account based login. But in
doing so, have come across a few issues I thought I'd ask for input in.
Character passwords: Legacy characters have a hash password in the .pl file.
This will be used by the new login method to associate one of the
On 03/22/10 02:00 PM, Robert Brockway wrote:
> On Sun, 21 Mar 2010, Mark Wedel wrote:
>> Format of news file: Currently, it is listed as oldest first, with
>> newest at the bottom. It seems to me that the reverse (newest at top)
>> is better - just like the Changelog - y
On 03/28/10 06:19 PM, Brendan Lally wrote:
>
> quest scorn/PortPass
> title Port Pass
> description
> Acquire a port pass to be allowed into Scorn's docks.
> end_description
> stopstep 20
> restart 0
> step 10
> description
> The guards told me that I could acquire a port pass from the Office for
On 03/29/10 10:25 AM, Brendan Lally wrote:
>>
>>Rather than having the stopstep, for each step, would it be
>> possible/better to have a keyword there to not that the quest is done?
>>
>>What I'm thinking is that for complex quests, there could be
>> several paths, and it would seem cleare
On 03/30/10 10:20 AM, Brendan Lally wrote:
>>Random question 2: For repeatable quests, is there any record that
>> the character is repeating a quest vs it being their first time?
>> Likewise, would it be worth it to note how many times a character has
>> done a quest?
>>
>> I'm thinking that
Just a heads up - I'm targeting weekend of April 10-11 to make a release,
since I should have time then (certainly won't this weekend)..
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
On 04/14/10 12:10 PM, Brendan Lally wrote:
> Hi All,
>
> As part of an overall aim to make the cf client a little more
> user-friendly, I have created a patch to add a skill window to the
> client.
>
> This may be found here:
>
> https://sourceforge.net/tracker/?func=detail&aid=2987308&group_id=138
On 04/14/10 12:29 PM, Rick Tanner wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 3/31/10 2:01 AM, Mark Wedel wrote:
>>
>>Just a heads up - I'm targeting weekend of April 10-11 to make a release,
>> since I should have time then (certainly wo
On 04/15/10 08:47 PM, Kevin Bulgrien wrote:
> Without countering Mark, I have build scripts that go all the way down to
> making
> RPMs... I'll support you in making a client release compatible with branch if
> you
> really want that. I can see part of the point of having branch for
> stabilit
On 04/17/10 12:05 AM, Nicolas Weeger wrote:
> Hello.
>
>> Quite some time ago, it was enabled on Metalforge but removed due to
>> player complaints.
>>
>> What people didn't like about it was merging issues in their inventory
>> window. They would (for instance) have 8 different Boots of Speed all
My fairly random thoughts on all of this:
- The space used up for the tab for skills & exp is minimal, so for most
layouts, the cost of keeping it in place isn't very high.
- Changes where someone else disagrees with that change are always a problem -
this can also happen in maps. In genera
On 04/18/10 11:08 AM, Nicolas Weeger wrote:
> Hello.
>
> The "gnome", and "gnome2" monsters have an attacktype of paralyze, for a level
> of 6.
>
> IMO that is too hard for new players, so I've changed the attacktype to
> physical and magic.
>
> "gardengnome" on the other hand, level 25, keeps his
On 04/19/10 05:08 PM, Kevin Bulgrien wrote:
> I do not at all like the idea of having to switch items on and off. What I
> think would be more practical would be to switch to an MDI interface and
> allow layout of the MDI to be saved and restored... either that, or figure
> out how hard it would
On 04/20/10 06:20 PM, Brendan Lally wrote:
> On Sat, 17 Apr 2010 13:00:24 +0300
> "Otto J. Makela" wrote:
>>
>> What I would like to also see is having a class "identified" (similar
>> in function to "cursed" and "magic") in the inventory, so that you
>> could more easily manipulate items which yo
On 04/23/10 04:40 PM, Kevin Bulgrien wrote:
> The GTK-V2 client gets a bad rap because the default sizing has been removed
> from the layout. People who start up the client think it is not working
> because it is all jumbled, etc. I think either the change should be reverted,
> or a different, mo
Now that 1.50 is released, I plan to start work on the new character creation
method.
This new method puts the creation in-client. This has several advantages -
better interface for the end user, removes a lot of code from the server, and
also moves some of the current character informati
On 05/ 1/10 07:40 AM, Nicolas Weeger wrote:
> Hello.
>
>>Now that 1.50 is released, I plan to start work on the new character
>> creation method.
>>
>>This new method puts the creation in-client. This has several advantages
>> - better interface for the end user, removes a lot of code
As per note in thread about new login method, figuring out what classes/races
should be present really comes down to what type of play we want to have.
I know this has been discussed before, but opinions change, so I thought I'd
restart the conversation.
This much more drives classes and
On 05/ 2/10 11:15 AM, Otto J. Makela wrote:
> Mark Wedel wrote:
>
>>This new method puts the creation in-client. This has several advantages
>> -
>> better interface for the end user, removes a lot of code from the server, and
>> also moves some of the current c
On 05/ 2/10 06:13 AM, Kevin Bulgrien wrote:
>>But perhaps this also goes back to my playing AD&D, and fact that most
>> games
>> have some for of class restriction. I also think that such a system may
>> generate more player interaction - if I can do every class really well on one
>> charact
In the discussion about races and classes, stats certainly play a role in
that.
If one looks at some games, like AD&D, stats are pretty fixed (just like
crossfire, there are some items that improve them, but the natural stats are
hard to improve or have a limited number of improvements (AD
On 05/ 3/10 12:53 PM, Nicolas Weeger wrote:
> Hello.
>
>
>>As per note in thread about new login method, figuring out what
>> classes/races should be present really comes down to what type of play we
>> want to have.
>
> Related to gameplay, I'd like to propose a shift on the "aim of the ga
801 - 900 of 1085 matches
Mail list logo
