If someone already brought this idea up before, my apologies.
As has been discussed many times, the current spell skills really are not
balanced, and there is sort of the problem that the wizard skills as defined
may
be very difficult to balance.
And idea I had was to change the current
Kevin R. Bulgrien wrote:
> Given a mover...
>
> Archetype mover_1, type Mover
>
> name = mover
> image = director.111
>
>
> movement speed = -0.2
> direction = north
> movement type = Walk
>
> Is it expected that spells/prayers are affected by the movement
> speed = 0.2?
>
> It has the very o
Changing topic, as this is more about skills than spells...
Nicolas Weeger wrote:
>> IMO, it is probably reasonable for skill scrolls to get removed from
>> random treasure, and used sparingly even for quests. But that really
>> doesn't fix the problem - even if the sorcery skill is buried i
Kevin R. Bulgrien wrote:
> Started an elven sorcerer a day or so ago... and have put in a
> couple of hours on him by now (mid-level 4). He has no melee
> combat skills except punching. I was very surprising/fun and
> very playable. In fact, it was almost too easy ... and resulted
> in a death o
One thought I had for high level spells:
Currently, the game world is largely immutable. I know there is buildable
buildings, etc.
But would it be unreasonable to have high level spells be able to also do
stuff like this?
For example, would a level 75 spell that allows you to destroy
Juha Jäykkä wrote:
> The idea of mana/grace regeneration needing rest is, again, one thing
> that has been used a lot in pen-and-paper RPG's over the time. I think it
> has proven itself a good solution. *BUT* in order to keep the magic users
> comparable to warriors in this kind of system, the ma
Kevin R. Bulgrien wrote:
>> Lots of discussion about spells, etc, on the slow down combat thread, but I
>> thought I'd start a topic with just general ideas on spells.
>
> A different sort of attune/repel by vocation:
>
> It is interesting how you can pick a particular spell path by vocation whe
Decided to change the subject to make it clearer what the message is about.
First, I just want to note that what I do on the tavern.santa-clara.ca.us
server should not be seen as a final product. I just think it is a good point
of experimentation - in a sense, taking something from the lab
Lots of discussion about spells, etc, on the slow down combat thread, but I
thought I'd start a topic with just general ideas on spells.
The main points to think about is that we want a spell system that is
meaningful from level 1 to 100 (in this case, meaning at higher levels you get
new
Kevin R. Bulgrien wrote:
> Remember that combat speed isn't all about how fast I hit them. The more I
> play, the more I realize that mostly what changed is I can't hit as fast. I
> am still extremely vulnerable to buffered keystrokes... maybe even more so
> now because action is so much more sl
Kevin R. Bulgrien wrote:
> I set up a character on tavern... a gnome priest because that is what I was
> trying on ailesse when I commented on this before.
As noted, nothing has been done relating to spells, so balance in those areas
gets odd - things like spells likely do need to get adjusted
Yann Chachkoff wrote:
> Some short comments about all this...
>
>> I'm concerned no one replied already, but well...
>>
> My brain is slow, and needs time to formalize thoughts :)
>
> Shortly summarized (so that those who do not like to read a lot don't need
> to): I am not convinced at all that
Nicolas Weeger wrote:
>> I think most everyone knows magic is messed up in many ways - many of the
>> top vote getters were related to magic. And certainly once melee combat is
>> done, the spell system gets redone
>
> I'd say we should try to do both. Fixing melee implies to balance monsters,
I decided to spend a little time playing with the code. The
tavern.santa-clara.ca.us server is running with these changes. Note that I've
only modified orcs, goblins, kobolds, and gnolls as far as AC goes. I also
made
some server changes as far as speed goes - it turns out that for first
Lalo Martins wrote:
> Here's a relatively simple alternative suggestion:
>
> Actions have a speed rating. Essentially, this represents how often an
> average character would be able to perform that action. So this will be
> an attribute of weapons and of skills (specially interesting for unarm
bug report 1742632 states that immolation (from ruggilli) does not work with
flame touch. I've confirmed that that is in fact true, and this is my
response.
I'm posting to the list to get some more responses/input on this, since I'm not
sure how many people actually read the bug reports.
-
Nicolas Weeger wrote:
>> It shouldn't be. It's possible that a few things or other changes were
>> outside of #ifdefs. For both client & server, having curl shouldn't be a
>> requirement.
>
> What's the point of metaserver2, then? :)
> I think curl is needed, so newer clients use newer servers
Kevin R. Bulgrien wrote:
> In short, magic use is terrible. If you choose to play a magic-use only
> player,
> you are totally and completely disadvantaged. A magic-only user will die
> very,
> very easily, and will level very, very slowly compared to a physical combat
> character.
I think
Nicolas Weeger wrote:
>> Maybe, but I think it would be very boring to play a mage in that case -
>> cast a couple spells, maybe not kill anything with them, have to rest to
>> regain mana, cast some more spells, etc. One goal is to balance things
>> such that mages and fighters are both fairly
Olivier Huet wrote:
> Hello,
>
>
> Just for SDL, there is perhaps a better chance to have hardware acceleration
> with it than with OpenGL only : I don't know SDL but looking a little
> sources and documentations, I think that it do try several ways to have
> hardware acceleration available on ho
Olivier Huet wrote:
> Hello,
>
>
> Something like a month ago, I did try some minor modifications on the
> windows gtk1 client :
> - make it compile on vs2005 (because I didn't have vs 6 installed anymore on
> my current pc)
> - activate back the sdl support (like it is in on gtk2 client, it's on
Kevin R. Bulgrien wrote:
>> I'll likely be packing up a release of 1.11 of server/client in a week or
>> two.
>> If you have fixes that you haven't committed yet, please do so.
>>
>> Also, if there are any bugs that you see as critical that need to be fixed
>> before the release, please le
I'll likely be packing up a release of 1.11 of server/client in a week or
two.
If you have fixes that you haven't committed yet, please do so.
Also, if there are any bugs that you see as critical that need to be fixed
before the release, please let me know. There's a fair number of bugs
One thought I just had about this is changing weapon speed vs normal speed.
Right now, normal speed is used for movement, and if you attack something,
what is currently your weapon speed gets moved into speed left for those extra
attacks. This also creates other odd effects, as now it is a
Nicolas Weeger wrote:
> Hello.
>
> I'm concerned no one replied already, but well...
Maybe everyone just agrees with my brilliant insights :)
>
>> This actually has some other dramatic effects - large area of effect
>> spells are less useful (if the room only has a few creatures, the spell
Nicolas Weeger wrote:
> Yes, both should be taken into account, because we're talking about
> potentially massive changes in hp/damage/speed.
> I would also consider, even if later, the implications on map. If it takes 5s
> to kill a "middle-level" monster, we probably don't want a map with 500
Kevin R. Bulgrien wrote:
> I have pretty much decided not to port the Libglade changes back onto
> branches/1.x. I've looked at it, and the volume of labor to backport it
> is not something that I want to do. Too much already has been done on
> trunk that would have to be filtered out in a merge.
I agree that they should be removed/blacklisted for not using proper
map/arch/codebase fields.
I haven't looked into their code, but if in fact they are using a
different/incompatible protocol (different format for commands, or different
commands), they should also be removed - in that cas
Yann Chachkoff wrote:
> Le mardi 11 septembre 2007, Mark Wedel a écrit :
>> Nicolas Weeger wrote:
>>> Hello.
>>>
>>> Schmorp server appears on metaserver2. But the officiel client (latest)
>>> SVN does *not* work with this server.
>>>
>>
The results of the vote were pretty overwhelming for this, so going to start
some discussions.
I'm also going to include the #2 point - "Balance magic & combat skills so
they are more equal" a little bit - I don't think slowing down combat is going
to make that all work out, but it does se
Nicolas Weeger wrote:
> Hello.
>
> Schmorp server appears on metaserver2. But the officiel client (latest) SVN
> does *not* work with this server.
>
> This server shouldn't be on metaserver2 until it supports the official
> Crossfire client, since metaserver2 is the future 2.0 version.
My $.
Not that many votes - next time it will need to get better publicized I
think.
Because I didn't say I would, I'm not going to publicize how people votes
(I
think it would be unfair since there wasn't much advanced notice). Very few
non
developers voted, which perhaps skew these result
Nicolas Weeger wrote:
>> However, at the same time, it would not be desirable for the casual
>> player to go onto one of those servers.
>>
>> So my thought is to add something like a test/expirimental server flag (T
>> or E perhaps). The client should not show those unless player clicks on
>>
We now have more official support for metaserver2 now, thanks to Leaf &
real-time (http://crossfire.real-time.com/metaserver2/meta_html.php) - shortly
I'll be putting metaserver2 support back into the 1.x branches.
While the two servers listed there right now of this writing are test
serve
We've pretty much figured out the choice of major projects, now to decide
which one to vote on. Like source control vote, we will do a ranked choice
vote. Brief list of choices below:
A) Redo races & classes
B) Re-organize the world into different difficulty areas
C) Make a new beginner are
It was brought up in another thread that monster AI needs to be improved. I
think for purpose of this discussion, monster AI pertains to the monster
killing/stealing/otherwise harrassing the player, not about NPC & scripting.
I'd like to discuss a bit more about improvements people would l
Kevin R. Bulgrien wrote:
>
> It is not possible to specify the .glade file from within the Client |
> Configure window.
> I looked at that code a bit, but have not really digested how it works if you
> want to
> save string data (path/filename) instead of a simple numeric value. I guess
> the
Kevin R. Bulgrien wrote:
> Question one is this. Mark's original gtk-v2.glade sets up a screen size of
> 1201x1010 which for some reason shows up as taller than my screen in Glade
> Designer on a 1280x1024 graphic mode. I would like to alter the _default_
> window size to 1275x945 for maximal ho
Nicolas Weeger wrote:
>> I probably wouldn't worry about that much right now - 1.x and trunk are
>> kept pretty closely in sync - at some point, that metaserver2 code is going
>> to get merged down into the 1.x branch, so that bug in the trunk needs to
>> get fixed, but I think all new/active dev
To fix the metaserver2 hanging bug, I used the libglade version.
Quick notes/thoughts:
configure.in, line 470 - think you mean 'test' not 'text'. Not sure why that
was added for the glade version
Client itself: If unable to load the glade file, it should probably just print
the error an
Nicolas Weeger wrote:
> Hello.
>
> There are currently some bugs on tracker related to the ease one has in
> leveling in inscription.
>
> I propose to fix this issue by having pen use food when used. One food per
> character for standard writing, some computed value for spell scrolls.
>
> This
Nicolas Weeger wrote:
>> 2a) Re-organize the world so there are different areas for different levels
>> (level 1-10 area, level 11-20 area, etc). Add a main quest(s) that would
>> lead a character through these areas up to high level
>
> Well, we could do some quests to have the player visit th
Kevin R. Bulgrien wrote:
>> Well, we could do some quests to have the player visit the world, that sure
>> could be fun if well done :)
>> As I said, I don't like that much the idea of having "main quest" to guide
>> you - part of the game imo is to find quests and places to level up.
>
> I may
Kevin R. Bulgrien wrote:
> It seems trunk is broken with metaserver2 code. The client hard locks on
> exit.
> It seems to be hanging at the mutex lock because the metaserver2 isn't up,
> but I'm not
>
> 172while (metaserver2_check_status()) {
> 173usleep(100);
Nicolas Weeger wrote:
>> So in very broad terms, these are high priority major projects I saw
>> discussed. Note that this is just forming a list that people will vote on,
>> so discussions like 'that is a stupid idea' or 'that is a great idea' are
>> also misplaced at this time - when the voting h
Discussions started a month ago about what the next major thing to work on in
crossfire should be. The purpose of this e-mail is to make sure I haven't
missed anything major - if this is a complete list, I'll then send it out for
voting.
Like before, these are very general guidelines - th
Lalo Martins wrote:
> On the quest to "ungeekify" the client... ;-)
Just a note - I doubt there will be any single answer that everyone will
like.
So the idea of using libglade so multiple layouts can easily be defined I
think will be a very good idea. There are just too many variations -
Yann Chachkoff wrote:
> Le samedi 4 août 2007, Kevin R. Bulgrien a écrit :
>> Hmm... So then the mumbler was really just detracting from my feeble
>> attempts to work on fixing what I felt like moaning about. Ok... I get it.
>>
> Just as a side note, my original comment was about underlining the
Quick followups:
AC: if this change is adopted, one really can't just say 'make what is
currently
AC a dodge penalty' - that will result in lots of broken items (certain items
that currently give high AC and shouldn't give that as dodge penalty). Plus,
it
becomes confusing - if I've learned
Some discussions recently have discussed that we should think fresh about
different ideas/balancing the game.
And the current wc/ac/armor got me thinking about this. Right now, AC and wc
basically follow the original AD&D model - low AC is good, armor gives an AC
bonus, and low wc is also
Kevin R. Bulgrien wrote:
> Lalo Martins wrote:
>
>> A discussion we had a while ago when the v2 client first appeared:
>>
>> Many laptops on the market today aren't able to do more than 1024x768,
>> and that isn't about to change any time soon.
>>
>> I *normally* play on my PC, but if I ever becam
The definition of what is a playable class is very broad.
A class that can only gain exp as part of a party is still quite playable, if
you are always able to play with parties.
A pure weapon smith class may also be very playable - not even needing party
support, just cooperation of othe
Nicolas Weeger wrote:
> Hello.
>
> Currently, the read_client_images() function, and supporting variables
> (everything related to faceset, including the actual png pictures), are
> located in the socket library.
>
> I'd like to move this to common (in trunk), for 2 reasons:
> 1) it isn't relat
Juergen Kahnert wrote:
>> So it may be more a thing that players should be able to cooperate on
>> a single map, and somehow share the rewards.
>
> Yes, real multiplayer maps / quests would be nice to have. I just lack
> on ideas how to create some with the current system. Some characters
> are
Note also that high level electric dragons get x-ray vision as a free bonus.
So you end up with potentially a lot of characters having that ability.
As far as color of objects through walls - that isn't something that can
really be controlled - the client makes non visible stuff grey on its
Just some quick thoughts on this:
I agree that in principle, most of the classes and races should be about
equal
in power/balance. A certain race/class shouldn't always be the best to play.
And in broad terms, fighters and spell casters should be about equal.
However, I don't think all
Juha Jäykkä wrote:
>> IMO, adding new regions when characters reach the cap is completely
>> unrealistic, so I dismiss it as an option. Sure, it sounds great, and
>> could happen, but past experience shows it won't happen. Making a
>
> Ok, you're more experienced on that, I trust your judgeme
Kevin R. Bulgrien wrote:
> The ground (/scorn/guilds/mailed_fist/ground) map in Scorn is made in such a
> way
> that if you are wearing an XRay helmet you can see behind a block view "wall"
> to
> see mechanisms that are used to make the map work. Is this expected behavior,
> and the map maker d
Juha Jäykkä wrote:
> Hm.. I still have a lengthy message from Sunday not replied to, but I'll
> chime in on this one first...
>
>>> The problem here is feature (or monster toughness) creep. It is easy
>>> enough to say 'max level for any monster should be 100'. The problem
>> The level 100 shoul
Juergen Kahnert wrote:
> On Sun, Jul 22, 2007 at 09:37:44PM -0700, Mark Wedel wrote:
>> I consider this sort of a chicken and egg party - people may not use
>> parties often because there is not much reason to form parties.
>
> The only reason I know for a CF party is, to l
Juergen Kahnert wrote:
>> And this method also works good for parties - it is unclear if a
>> party should get more reward than a single character doing a quest.
>
> To be honest, I've no idea how to make CF work well with parties. Maybe
> party support could be the topic for CF3, and for CF2
Kevin R. Bulgrien wrote:
>
> His system was using a 13-15" monitor, because that is what I had laying
> around. I had fired it up once before, and said forget it because the desktop
> was set 800x600 or so both due to screen size, but also because it is good
> for learning mouse skills. The GTK
Kevin R. Bulgrien wrote:
> A previous attempt to send this message didn't seem to work for some
> reason.
>
>> Headings
>>
>> Some title headings will not render properly at any setting. I am sure this
>> is not related to the screen resolution as mine is a dual-head 1280x1024
>> and no matter ho
Kevin R. Bulgrien wrote:
> See http://krayvin.home.att.net/metaserver.png for the proposed changes. I
> made
> the Glade changes in the Glade Designer.
>
> I would like to check in my changes. Is everyone okay with that?
That all looks/sounds fine to me.
___
ot a bad thing. I'd
also
say that the proper check would be to play every map and see how it plays - you
probably would learn virtually nothing looking at the maps in an editor - you'd
have to play it to see how hard it is now.
And if it is a case that there may be objects/creatures
Olivier Huet wrote:
> Hello,
>
>
> Some time ago, Reven did modify the gtk-v2 to make it compile for MS Windows
> (with MinGW) - see his post at
> http://forum.metalforge.net/viewtopic.php?t=1571.
>
> It was really great : slightly faster and cooler than slow (on Windows) gtk
> 1 client.
>
> I
Nicolas Weeger wrote:
> Hello.
>
>> There is also libwww. I'm sure there are others.
>>
>> So this is really just a question to see what is out there.
>
> Here is my checklist for that:
> * works under Linux, Windows, Mac (ok, no Mac client for now, but well, it'll
> come some day). The mor
Nicolas Weeger wrote:
>
> I think there is a misunderstanding, at least that's not what I meant
> with "scripting".
> I meant "you can adapt the quest reward based on the player's race / class /
> stats / time of day through scripting". So a monk would get a good monk item,
> a fireborn an item
Juha Jäykkä wrote:
>> There has been some discussion on speed/combat balance (basically:
>> reduce speed, so combats take some more time, and enable players to
>> actually flee before getting killed easily), though it isn't on the
>> page. Could this be added to the list, or is it something not eve
Nicolas Weeger wrote:
> Le mardi 17 juillet 2007 08:00, Mark Wedel a écrit :
>> As per recent e-mail and irc discussions, we need to figure out what the
>> priority things to work on in for the 2.0 release are.
>
> There has been some discussion on speed/combat balan
Juha Jäykkä wrote:
>>> First, most quest-reward and artefact items are weapons. This makes
>> Scripting, scripting. Of course need to design quests for that
>> particular reward :)
>
> Cannot we alter some existing ones as a first aid? Inventing dozens of
> new quests is quite a big task.
I'm s
As per recent e-mail and irc discussions, we need to figure out what the
priority things to work on in for the 2.0 release are.
There is a very long TODO list at
http://wiki.metalforge.net/doku.php/dev_todo_new which may give some people
starting point. There is http://wiki.metalforge.net
I'm looking/thinking about the new metaserver information, as described at:
http://wiki.metalforge.net/doku.php/dev_todo:metaserver_improvements
As mentioned in that page, using URL/HTTP for the metaserver would seem to be
the most scalable. But we need to decide on a library to use for tha
Nicolas Weeger wrote:
> Well, my opinion is that server / code / developer documentation should be in
> doxygen format, part of the sources and integrated in the doxygen-generated
> docs.
>
> It would be much easier to bundle everything together this way.
Can you give some better examples of
Nicolas Weeger wrote:
>> I'd almost argue that the docs should be pulled from the server area
>> (except those specifically related to the server, like programming and
>> protocol information) - if anything, it'd almost make more sense for them
>> to be in the client.
>
> Except then you couldn'
Kevin R. Bulgrien wrote:
>> Good grief! I think I will just blow away my svn tree and download it all
>> again (when I get to the point I can do some mapping again). What a PITA. :p
>>
>> Gene Alexander
>
> Huh? It could hardly be more painless.
>
> $ cd /home/data/svn/crossfire
> $ for file in
Andreas Kirschbaum wrote:
> Lalo Martins wrote:
>> What I think we need is a "world editor".
> [...]
>> Ideally, I'd like an UI on at least the magicmap scale, maybe farther,
>> where I can lay mountains, rivers, forests, marshes, sea/land, and
>> preferably copy large chunks right out of an older
Andreas Kirschbaum wrote:
> Mark Wedel wrote:
>> The server has no memory what it has sent to the client, save for
>> the map. To remember what it has sent to the client would require that
>> for each player, a complete copy of the spaces contents to be recorded
>> a
Nicolas Weeger wrote:
>> Now this construct is used to cover the case where the current object
>> (tmp) goes away - we have a pointer to the next object. Such operations
>> are not that uncommon, as the {do some work} block is more likely to
>> destroy tmp.
>
> Actually, you can never be sure a
Nicolas Weeger wrote:
>> In theory, make doc is supposed to do that now. By default, it doesn't
>> do the spoiler and playbook I think, because there is no good way for make
>> doc to know if they changed (since a lot of data is based on archetypes, it
>> is really if the archetypes change).
>
Andreas Kirschbaum wrote:
> Nicolas Weeger wrote:
>>> At some level, it is very easy to fix - if player is on a space, and
>>> anything (including face) on that space change, we just send all the
>>> contents of that space again to the player.
>> Why all items? Don't items on a space get a tag, tha
Andreas Kirschbaum wrote:
> Mark Wedel wrote:
>> The only really foolproof way would be to add some flag - something
>> like 'FLAG_NEEDS_TO_BE_DESTROYED'. Instead of the object actually
>> getting destroyed, that flag is set, and then there is some other
>>
Nicolas Weeger wrote:
> Hello.
>
> Kind of resurrecting this thread, but well :)
>
>
> I was wondering what people would think of "centralizing" the documentation
> in
> the doxygen format.
> Not necessarily to make links to the code, but merely to have one big
> (server-side) reference docum
Alex Schultz wrote:
> Hi,
>
> Well that the discussion on organizing efforts seems to have died down a
> bit I'll sum up that the consensus seems to be from what I have seen here:
> -The idea of organizing and focusing on a mini-project is good
> -Some kind of procedure for selecting mini-
Lalo Martins wrote:
> Also spracht Lalo Martins (Thu, 05 Jul 2007 06:41:47 +):
>>>
>
> Sorry to reply to myself, but...
>
> I thought I should say, part of the motivation for this idea was code,
> too. It cuts the work of the new character creation UI by about 20 to
> 30% in my estimate
Alex Schultz wrote:
> Mark Wedel wrote:
>> changing the cap isn't that hard.
>>
>> However, this has been done before - cap raised from 25 to 30, with a lot
>> of
>> the same discussions (too easy for any class to max gmout stats, etc).
>>
>
Just a note - I go into pretty much all discussions with some thought on the
code involved. Maybe people don't think that is quite the right approach. But
my thought is that the greatest designed system in the world is meaningless if
it is too complicated to code in a timely fashion.
Lalo
Juergen Kahnert wrote:
>> 1) skills operate the same, just harder to get levels in ones you are
>> not good at.
>
> This will end up with all characters having the same skill level, just
> takes longer to get some of them.
But it would be easy enough to put in level caps for some skills.
I
Alex Schultz wrote:
> Juergen Kahnert wrote:
>> On Wed, Jul 04, 2007 at 08:01:12AM -0600, Alex Schultz wrote:
>>
>>> One quick note about this, is that removing that hard limit isn't so
>>> simple as "just" removing it.
>>>
>> I didn't looked into the code. I just wrote down what I think w
Nicolas Weeger wrote:
> Hello.
>
> Should the players in a transport appear in the 'maps' output? Should they
> count as players in the map the transport is in?
yes and yes.
>
> Currently they don't, so there is an issue: potentially a map could be reset
> with a player in a transport on it.
Alex Schultz wrote:
> Mark Wedel wrote:
>> Having project leaders before the project is worked on/voted on makes sense.
>> And as I think about it more, it would generally be good to have the
>> detailed
>> project plan before voting, so people actually know what t
Going back to original topic now
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, but also how effective it is at teaching the player impacts
> all of their other experienc
Quickly catching up with followups:
I'm not sure we really need graphs to track dependencies - I'm not sure they
are that complex (there are not that many). What is really needed is to just
note what the dependencies are, so we can know there is no reason to bring
spell
reform to the tab
To quickly follow up on some points:
I am not adverse to all races/classes starting with all skills (save those
intrinsic ones like Nicolas mentions), but with a fair number being really poor
versions.
For example, the fighter would have good versions of things like melee
weapons, bow, pe
The original mail in question had what I really two different topics - one
for
the idea of redoing what players see when they connect, and a second about
group
efforts to get things done in a timely fashion. This mail more focuses on how
to do group efforts - ideally to come up with some s
Juergen Kahnert wrote:
>> In particular, the skills do have self contained information about how
>> much exp ones gets for the skill. So it is just a matter of creating
>> some new archetypes with different values (basic/expert/master skills?
>
> Doesn't show the level itself the knowledge about
It seems to some extent (could be wrong), that some amount of the motivation
behind this new set of guilds was to add some meaning to the classes (maybe not
the only motivation).
However, it has been discussed (and is even on the 2.0 todo list) that
classes
get redone so skills are import
Juergen Kahnert wrote:
>> However, there has been talk about making classes have more distinction.
>
> And having such guilds will offer a way to make them more distinctive.
> I don't say it has to be right this, just it could be made like this.
>
>
>> For example, a fighter gets exp in the fig
Daniel Daxler wrote:
> Balance is the key!
Much about using built in functions (and not map values) to calculate exp and
item power removed...
IMO, trying to enforce this in the code is not the right way to go. In terms
of experience, if map makers are intentionally trying to provide these
Juergen Kahnert wrote:
> I have the following idea for the new world:
>
> After character generation, you have to chose your class. As soon as you
> have chosen your class, you won't enter "start/Nexus", but the guild of
> that class.
>
> This guild will be a combination out of the newbieshouse a
401 - 500 of 1085 matches
Mail list logo
