Re: [crossfire] Linux and Python code crashes
quoth Otto J. Makela (Fri, 08 May 2009 12:23:40 +0300): > James Lopeman wrote: >> This issue is well know on fedora (32 and i think 64 ).. the fix is >> already in SVN, no server release since > > Great to hear this. Is the fix expected to be pushed into updates? The 1.12 release is "in progress"; the client has already been released, and the server was on the verge of getting released, but then my computer broke, and the laptop I'm using has no disk or memory to even have a full source tree, let alone build and test it :-( I should be back to normal life next week or so, and then there will be a content and server release. -- I'm using a laptop and forgot to copy my signature file. For the moment, whatever info you want is probably at http://lalomartins.info/ or thereabouts... ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] clients
Ok. Feedback gotten and digested.
So here's my semi-official decree as not-really-project-leader:
We'll remove old gtk from trunk. I'd like opinions on whether v2 should
be renamed to gtk, or even renamed to just crossfire-client.
The SDL rendering is scheduled for removal, but removing it is not a
priority. If someone feels like doing it, go ahead.
The x11 client will be left in the tree, and on each release from here
on, I (or the release manager) will test if it builds and runs. But
there are no promises that it will actually be updated, unless someone
steps up and volunteers to maintain it.
As long as x11 doesn't have a maintainer, it will be considered
unsupported, and disabled by default in configure (you'll have to pass an
explicit --enable argument to build it). Binaries will not be included
in releases.
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
[crossfire] [ANNOUNCE] Client 1.12 released
The 1.12 clients are released. Source tarball and Windows binaries are
at https://sourceforge.net/project/showfiles.php?group_id=13833 as
usual. Deb packages for Ubuntu can be found at our new PPA at
https://launchpad.net/~crossfire/+archive/ppa (I'm not sure whether or
not they'd work on Debian, let me know if you try). RPMs weren't made,
but if someone makes them I'll upload them :-)
Although I'm making the release, I'd like to take a moment to say that
this release is largely the work of Kevin R. Bulgrien, who refuses to be
called the client maintainer but is the de facto person who does the
work. Kevin is responsible for the level of stability the v2 client
reached in this release, as well as the Glade layout support, and a
number of other cool new features.
A number of other people who made significant contributions also get our
thanks (Mark Wedel, as usual, showed up to add some cool stuff, like
themes and on-the-fly map resizing.)
Keep tuned to this channel for the content and server 1.12 releases.
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] clients
quoth Mark Wedel as of Sat, 04 Apr 2009 21:55:43 -0700: > Kevin R. Bulgrien wrote: >> >> One of the arguments I had for GTK-V1 back in the day was the font >> size... It was nice and small compared to GTK-V2. I think that is >> still an issue for small screens. It would be nice to be able to do >> something about that in GTK-V2 without making someone change the font >> for GTK2 system-wide. Not changing the reply here, just making note of >> one thing GTK-V1 still has over GTK-V2 despite the layout capability in >> GTK-V2 > > I believe (but could be wrong) that both the gtk and gtk-v2 client > basically > use the standard system font - they are not going through extra hoops to > mess with font size. > > That said, the default system font may very well not be usable on a > low > resolution screen. > > Note that a while back, I added theme support to the gtk-v2 client. > So using > a different font may just be as simple as making a new theme with > different font settings. Ah, that would be correct :-) The themes (not to be confused with layouts) are just gtkrc files. As such, you can set a font. I'll play around with that later and tell you if/how it works. (Or you can.) 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] clients
quoth Kevin R. Bulgrien as of Sat, 04 Apr 2009 22:03:22 -0500: >> > 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 arguments I had for GTK-V1 back in the day was the font > size... It was nice and small compared to GTK-V2. I think that is still > an issue for small screens. It would be nice to be able to do something > about that in GTK-V2 without making someone change the font for GTK2 > system-wide. Not changing the reply here, just making note of one thing > GTK-V1 still has over GTK-V2 despite the layout capability in GTK-V2. I kinda-almost-know-at-the-edge-of-my-head how to do that in gtk... I'll take a look after the release, if nobody beats me to it :-) 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
[crossfire] clients
Well, gtk-v2 is now successfully built and packaged for Windows.
This brings the usual question :-) any objections if we nuke x11 and gtk
from the tree for trunk (and 1.13)?
Actually, I don't really care about objections. Let's put this a
different way. Any volunteers to maintain those? ;-) They haven't been
touched in a looong time, so unless someone steps up, I'll be nuking them
right after the release nightmare is over.
(Last time we talked about it, there were two objections; v1 was better
on smaller screens, and easier to build on windows. Kevin solved the
former with glade; v2 is now actually better on small screens. And I
worked out building it with msys. So I don't really see a benefit to
keeping that unmaintained codebase around.)
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
[crossfire] About to release 1.12
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.
One of the reasons this is so much later than I wanted is because,
apparently, my head isn't big enough to contain all of content, server,
and client information (especially what with also doing other crossfire-
related work on the side, and then work work...). So I've wasted most of
my crossfire-time on the last 3 months trying to understand server
dynamics and open bugs... and mostly failed. Meanwhile, I could have
fixed and released content/client three times over instead.
Even so, and despite my uselessness, the server bug count is apparently
reduced to 6, mostly thanks to anmaster and mwedel:
http://sourceforge.net/tracker/?
func=browse&group_id=13833&atid=113833&status=1&category=312237&artgroup=897591
(if your mail|news client wrapped that, you know the drill, copy it and
paste it as one line). If you can fix or at least understand one of
those, your help would be appreciated. I have a clue I'm following on
the godenchant bug (gods are one of the two parts of the server I
understand reasonably well :-P).
Hopefully, the server can be released in two weeks or so. May Lythander
be on our side ;-)
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] Change default perm exp values ?
quoth James Lopeman as of Tue, 20 Jan 2009 11:39:48 -0700:
> Any such settings Metalforge uses should become the default IM-NS-HO. In
> the end metaforge behaviour is the "expected behaviour" and makes less
> work for you.
Agreed... any server admin who wants things different than MF is free to,
you know, actually edit the configuration :-)
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
[crossfire] Oh noes, my checkout disappeared!
Leaf has pointed out to me that some people may have checkouts of an 1.x branch (eg client/branches/1.x). If you do, this message is for you. Since the branch layout has changed last weekend, doing an update in such a checkout would simply fail, with the not so helpful message: svn: Target path does not exist (Leaf actually asked me to try and find a way to keep 1.x checkouts working, but there isn't anything like a redirect or auto-switch feature in svn, and I don't want to keep a whole branch around that has no real purpose but saving one command.) So if you use a checkout like that, here's the recommended thing to do: First you should make a choice. Do you want to follow the supported, released version, and get eventual bugfixes for that? Or do you want to follow the work-in-progress for the next release? If you want to follow the supported, released version, do this: svn switch https://crossfire.svn.sourceforge.net/svnroot/crossfire/ $COMPONENT/branches/1.11 . where $COMPONENT is the thing you're following -- server, client, arch, maps. So for example: % cd server % svn switch https://crossfire.svn.sourceforge.net/svnroot/crossfire/ server/branches/1.11 . But it would probably be even better to remove your checkout, and instead create one from the "stable" export: svn co https://crossfire.svn.sourceforge.net/svnroot/crossfire/stable/ crossfire This will get all the components, on the supported version. It has the significant benefit that when 1.12 is released, you don't have to run "switch" again; you will automatically start following that one. On the other hand, if you want to follow the work-in-progress 1.x release (more or less equivalent to the old branches/1.x): svn switch https://crossfire.svn.sourceforge.net/svnroot/crossfire/ $COMPONENT/branches/1.12 . for example: % cd server % svn switch https://crossfire.svn.sourceforge.net/svnroot/crossfire/ server/branches/1.12 . But it would probably be even better to remove your checkout, and instead create one from the "next" export: svn co https://crossfire.svn.sourceforge.net/svnroot/crossfire/next/ crossfire-alpha This will get all the components, on the supported version. It has the significant benefit that when 1.12 is released, you don't have to run "switch" again; you will automatically start following 1.13 instead. Note, none of the svn commands above include a line break, but you will probably see them with line breaks because, well, it's email. If you can't figure out how to join them, look them up on the wiki instead: http://wiki.metalforge.net/doku.php/downloading 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
[crossfire] 1.12 branch cut
Okay. To reflect the new 1.x plan, and to avoid the branch problem we've
had this last year, I'll go ahead and phase out the 1.x branch in favour
of specific 1.11, 1.12, etc branches.
An 1.12 branch was cut out from trunk a few minutes ago. I'll have to
revert mwedel's rebalance from server and arch, and then it will become
1.12 alpha. From that point it's bugfixes only. At some point in late
February, it will become 1.12RC, and from then on it's *critical*
bugfixes only. (Even after the release; so it is also possible that an
1.12.x release happens, if we screw up too bad. Let's hope not.)
Immediately after 1.12 going bugfixes only, an 1.13 branch will be
added. I'd recommend/encourage new feature development to still happen
on trunk and then be backported. Currently the plan for 1.13 is 1.12 +
rebalance, and an August release so we can get in October Ubuntu/Fedora.
(1.12 will probably be late for April distros, but we'll try.)
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] Leaderships(s?) (was Re: Platform statement)
quoth Nicolas Weeger as of Wed, 14 Jan 2009 19:01:13 +0100: > As you said, this isn't a democracy, and latest discussions (and the > lack of conclusions) should show that we need someone to actually decide > when needed I have never seen a Free or Open Source project that actually reaches conclusions in the mailing list on a regular basis. Still, most do get things done. Also, I haven't said it isn't a democracy. It is. What I have said is that it isn't a representative democracy. We don't elect our officials and then just sit back and expect things to work. FOSS is not driven by consensus. It's driven by "rough consensus". There is someone (and I'm saying this in agreement with you, not in disagreement) that looks at the discussion in the mailing list, IRC, etc, and makes a decision based on that. Usually, based on what he or she believes is the consensus, but sometimes, the leader decides something based on his or her own judgement, ignoring what other people said. > so a gameplay leader, and a content leader, both are needed. No, sorry, but no. A gameplay leader and a content leader, both WOULD BE NICE. They're not needed. Honestly, this would all be good if we had people to take all these roles. But do we? This leadership discussion has been going on for quite a while, and we still don't have someone firmly taking the code leadership, which was the first such position to be proposed. What do you *really* want, without fancy discourse? You want to be responsible only for technical coding decisions, and have someone else take the heat for everything else? If that's what it takes to see work start getting done, I'm fine with being that person. And we still have Mark, who volunteered to remain as a final-instance arbiter. 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] Leaderships(s?) (was Re: Platform statement)
quoth Kevin R. Bulgrien as of Tue, 13 Jan 2009 21:56:05 -0600: > I have not enough SVN access to do a release. It feels like after all > this time waiting without help to get my client work out its only > natural to not flip out over someone else' urgency of the day, but, I > was ready for a release a long time ago... no point in wondering what I > am willing to do. I've probably made that quite clear to anyone who > felt inclined to notice. That said, I have a real life, kids, high > urgency project that is running over two years old now and ready to pop > in a month or so... Not a lot of leftover bandwidth for thinking CF with > that going on, and I suspect I'm not alone there. I'll be glad to crank > up the scripts and chunk something out. You have commit access. That's enough access :-) if you want to do this, what I'd expect you to do is decide what will go in the release, and merge anything that needs to be merged. (If you just decree that your client release == trunk, then your work is done.) If you *do* have time you want to spend on it, then any amount of building, testing, and fixing bugs is welcome. If something happens to draw you away, I'll handle it, or someone else will, or we'll be late. If I feel adventurous and work allows me, I may try to set up the windows build environment, and see if I can convince gtkv2+glade to compile. But from what I heard of people who did try, probably not ;-) Of course, once the alphas/betas are out and bug reports start popping in, someone has to fix them before we dare make a "final" release. Since not many people are actively doing client development, I'd say there's about a 35% chance that someone would be you anyway; but if real life keeps you away from doing it, or even makes us miss the target date? It doesn't matter at all. What matters is that a release eventually happens, and that it's the best quality we can do. I do believe regular releases on a fixed timeline are a good thing. However, I'm not expecting *this* release to be the first of those. We have a lot of accumulated work to catch up to, and we have to figure out our own workflow, so that will take some time. Better do it well than fast. Then the next one can be on time. The other good thing about volunteering to lead the client are that, well, you get to make decisions. Want to drop the x11 client? The gtkv1 client? Go ahead. Change the whole thing to C++, or, I don't know, Erlang? It's your baby. The last few decisions you did make (glade, layouts, themes) have been successes so far, so I don't think there's any reasonable justification for objecting to you making future ones. I suppose, in the interest of fairness, I should say that I've been half- secretly writing a "libcfclient" in C++, using boost and asio. I have no intention of rewriting the desktop client using this lib, or of competing with it, though; the lib was meant for other things, including bots and maybe portable (phone/pda/pmp/ds/psp) clients. 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
[crossfire] Leaderships(s?) (was Re: Platform statement)
quoth Nicolas Weeger as of Tue, 13 Jan 2009 19:17:18 +0100: > - content leader => handles the story part of the game, maps that are ok > or not story wise, and such > - gameplay leader => handles combat mechanisms, has a say on quest > rewards and such, works on non combat stuff, ... > - technical leader => ensures needs of content/gameplay leaders are met, > and maybe planifies development and such > > PS: to reply to someone's mail, no, I don't want to be technical leader > as long as we don't have a gameplay leader - and even so, I'm not sure > I'd accept. Okay, sorry, but this is not going to work. For years, we had just one project leader. That worked in its time, then as Mark got busy with real life, things slowed down. Recently it has been proposed to have separate leaders for code and content. A volunteer appeared for code, but then the need for a content leader was played; quite reasonably, one volunteer claimed he didn't want to go far as code leader unless there was a content leader. So I volunteered to take the job. But now there's a third position that has to be filled as well? And even then we may find we still don't have a coding leader? Come on, people, we're getting nowhere this way. At this point in time, I don't think we even have enough people working on it to be talking about leadership. These are the important questions that need to be asked with regards to people resources: - Who will make content releases? (me, I guess.) - Who will make server releases? - Who will make gtk client releases? - Who will make java client releases? - Who will fix content bugs? - Who will fix server bugs? - Who will fix gtk client bugs? - Who will fix java client bugs? Only after those are answered, are we prepared to talk about adding new content, new features, or even massive rewrites. Oh sure, we could just declare 1.x abandoned; but considering all the cool stuff we have in svn, that would be a waste and a pity. All right then, to Gorokh with this. Here's my new proposal. Short term: I'm naming myself "release manager" for the 1.12 mini- project. I'll get a release out, code and content. The extra work in carrying the code release through childbirth may (probably will) mean missing the March 1st deadline, but I'll give it my best. I will *not* attempt to release clients, though. If someone wants to coordinate a client release, I'd be very happy and lend my support. (Kevin?) Medium term: I think the best thing to do, as far as separation of work is concerned, is to view this as a number of separate sub-projects: - Server (code and content) for 1.x - GTK/glade client (based on v2 I assume) - Java client - Gridarta for CF - Server (code and content) for 2.x (possibly later) Each of those should have someone taking responsibility. (Gridarta already does, and the Java client unofficially does too.) The necessity of a "master overseer" over the whole project is arguable; I think the sub-project leaders can work things out between them. But for now, let's concentrate on a release. My hope is that the work involved in doing that will wake us up, and that the right people for each position will rise up in the process. Frankly... this whole thing is silly. Free/Open Source projects aren't representative democracies; it makes no sense to be arguing about who will lead what when there's work to do and nobody to lead. Let's go get this release out. Please. 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] Release 1.12
quoth Rick Tanner as of Tue, 13 Jan 2009 13:55:12 -0600: > Lalo Martins wrote: >> http://wiki.metalforge.net/doku.php/trunkbranchchangebreakdown > > I've added about 10 new points of difference to the wiki page. > > During the next couple of days, I will go through all the maps again and > post the any more differences I find between Trunk and Branches/1.x Thanks! > There are some (infamous) cosmetic changes I've made and will merge back > in to Branch which should not have an impact on functionality. Oakdoors? :-) > Lalo - How do things look for the Jan-20th target date? Well. Actually cutting an alpha is about one day's worth of work for me, so meeting the target date isn't hard. The reason I set the date so far was, rather, to give other people time to act on it. If anyone wanted some particular changes in the release, or out of the release, they had time to speak up. And I also was hoping to see a decision on whether there will be a corresponding code release, although the lack of any comments about it does mean there won't ;-) at least not in the same timeframe. I'm not saying the release is easy work, I'm just saying cutting the alpha is the easy part. Then the real work begins -- lots of testing and fixing for the March 1st target. 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] Release 1.12
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 leadership, let's assume the rebalance won't be in the >> release. > > As far as I know, the combat rebalance does not break character > compatibility - old characters can get loaded and played fine. > > The main issue is that the play experience is radically different, and > so players not ready/aware of these changes my incur many deaths. Okay... a few questions, then, as you're the one who knows those changes best :-) - Won't old characters be excessively strong (or weak) compared to rebalanced ones? Or will the differences balance out in the bottom line? - Won't old characters be excessively strong (or weak) when fighting rebalanced monsters? Or will the differences balance out in the bottom line? - Can the changes be easily calculated without human intervention? If so, I could just write a script to do that. - Do you feel it's worth shipping this in 1.12 without the magic rebalance (which, if you have the time, would follow in 1.13)? Or is it better to wait and ship both in the same release? - How well would the (archetype) rebalance work without the corresponding server changes? Would it work at all? 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] Release 1.12
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 compatibility
is the combat rebalance. So until/unless we hear from the code
leadership, let's assume the rebalance won't be in the release.
It seems a lot of those changes require code changes... as seen on other
posts to this thread by Leaf and Kevin.
So the question of whether there will be a server 1.12 release becomes
somewhat important. If there won't, then it would be better to base the
content release on the branch, and manually merge each set of changes
that are compatible. Significantly more work... but doable.
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] Release 1.12
quoth Rick Tanner as of Tue, 06 Jan 2009 20:35:13 -0600: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Lalo Martins wrote: >> >> Content changes that require trunk code are another matter. I'd like >> to have a list of those if someone who knows about it has the time to >> compile it; > > One that I am aware of, r10699 through r10701 > > Re-enable cfpython to change player's title > > Allow player dragons to pick metabolism focus in the hallofselection, > also change player title LOL guilty as charged... I wrote those! I have no problem reverting them in 1.12 if there won't be an 1.12 server release. > As far as changes/differences from between trunk and branch from a > player perspective, a list was started on the wiki: > > http://wiki.metalforge.net/doku.php/trunk Cool, thanks. 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] Release 1.12
quoth Lalo Martins as of Wed, 07 Jan 2009 00:22:52 +: > Can you make a list, either here or the wiki, of known points where 1.12 > would break backwards compatibility? I don't mind required that content > is updated in step, but breaking character compatibility I'd prefer not > to (last time that happened people were pretty mad, and with 2.0 in the > horizon... no need to aggravate people too much.) Actually, let me rephrase that :-) Under the premise that current trunk arches and maps will be a 1.12 content release, I already expressed that I'd like those tested. I'm now saying that any changes in trunk maps or arches that make 1.11 characters unusable, with the exception of Mark's rebalance (which we don't know yet if we'll include in 1.12), are to be considered bugs and reported accordingly. (Of course, the "fix" will be simply to not merge those changes.) Anyone who knows about them can report them here, or on the tracker, or the wiki. Content changes that require trunk code are another matter. I'd like to have a list of those if someone who knows about it has the time to compile it; but it's unclear whether these are bugs, until the code leader decides about a 1.12 code release. I'll be putting a few hours this week into getting acquainted with all differences between trunk and branch content, and I'll do the work above alone if necessary, but it will be faster if people already in the know can contribute :-) 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] Release 1.12
quoth Rick Tanner as of Tue, 06 Jan 2009 16:58:11 -0600: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Lalo Martins wrote: >> - As suggested earlier on this thread, current trunk will become >> further 1.x releases. I remind you, that's for content; the decision >> whether or not to do the same wrt server and clients will be left to >> the people who take charge of code. > > Going with the assumption that this takes place... > > Some sort of clear notification or announcement will need to be included > that that player files and content from 1.11 servers are incompatible > with the 1.12 release. > > AFAIK, there are maps in trunk that require (as in will only work > with..) archetypes and server code changes in trunk. So, migrating just > map(?) content from trunk will likely cause complications or break > things. > > Or, has this been addressed and I missed such a post? Maps and arch are "content". The fact that the server ships with collected archetypes is a bit confusing there, as is the fact that the artifacts, recipes, etc files are in the server tree; I'd like those bits of confusion to be cleared up in 2.x. On the other side, there are scripts in maps that can be considered both code and content :-) Can you make a list, either here or the wiki, of known points where 1.12 would break backwards compatibility? I don't mind required that content is updated in step, but breaking character compatibility I'd prefer not to (last time that happened people were pretty mad, and with 2.0 in the horizon... no need to aggravate people too much.) If we can boil the incompatibility to only the combat rebalance, then I suppose I could write a script that fixes characters. Or we leave the rebalance to 1.13 and then include said script. 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] Release 1.12
quoth Lalo Martins as of Mon, 22 Dec 2008 14:24:28 +: > :-) let's make it official then. If nobody objects until 2009, I hereby > proclaim myself "content leader". Well. I've seen discussions about the fine points of my plans, but no objections to my proclamation proper. So I'm assuming the post as of today. I'd strongly suggest someone (*cough*) do the same for the code... potentially, if you prefer, different people for client and server (I think it's pretty clear who those would be today). Here are my first acts and plans as content leader: - Codename "rebootworld" will progress at whatever speed I'm able to implement it, as outlined in the "attack plan" thread, with the target of being the official content for 2.x. - As suggested earlier on this thread, current trunk will become further 1.x releases. I remind you, that's for content; the decision whether or not to do the same wrt server and clients will be left to the people who take charge of code. - I'll be using launchpad for release planning and stuff. Feel free to use it too. It's not really worth the trouble to move bugs from sourceforge to malone for 1.x, especially since launchpad is more than able to integrate with sf bugs; but I'll use malone for 2.x (which is a separate project on launchpad). For "blueprints", the best is still the metalforge wiki; again, launchpad is able to link and integrate those in its process. (The 2.x "attack plan" has already been entered in the form of launchpad milestones, coded "drs" for Developer Release - Scorn. It's still unclear how much content constitutes a "releaseable" 2.0; offhand I'd say three kingdoms.) - By January 20th I'd like to merge all trunk changes that are sufficiently tested into branch and cut a RC1. Since I haven't been following everything that happened in the last year and a half, I kindly ask people to tell me which changes are known good, which are known bad, and the rest we'll make an effort to test in this time window. - After the RC please test thoroughly and report any bugs; I'd like us to have a clean release. - There may be an RC2 and even if necessary an RC3 in February. - Between January 20th and whenever the 1.12 release happens, the branch is to be considered bugfixes only. - The 1.12 release is planned for March the 1st. That may be a pipe dream but I intend to make it happen. - I think the great 1.12 question is: do mwedel's rebalances go in or not? Assuming he does have time to do the magic rebalance, will we have enough time to test it? If we don't, or if he doesn't, should we release combat rebalance without its magic counterpart? Personally I'd like them in 1.12, but if the people who have played with it more (especially mwedel proper) think it's not mature enough, I wouldn't mind waiting for 1.13. (For those confused: the changes were mainly to archetypes, so yes, they do go in the content release.) - After the release, the 1.x flow should be: radical new features or major changes in a "feature branch", somewhat experimental or in-progress new features or major changes in trunk, bugfixes in the branch; new features and major changes to be integrated from trunk to branch as they're tested and deemed stable. - I'd like to put out two 1.x releases per year until about a year after 2.0 happens. (By which time if anyone else wants to go on maintaining 1.x I won't object.) Early February and early August should get us into Ubuntu and Fedora releases, so that's what we'll be aiming for from 1.13 on. - Of course if server and client do *not* decide to cut 1.x releases out of trunk, it will be part of my job to make sure these content releases are compatible with whatever server versions are available at the time. What I shall *not* be doing for 1.x is deciding whether new content is consistent, fits the story, etc; or quality. New content will be checked for balance and whether it fits the place where it's located. Changes to existing content, of course, are expected to make it better than before. ;-) 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] [Rebootworld] The true (hi)story
quoth Nicolas Weeger as of Tue, 30 Dec 2008 09:02:46 +0100: > Hello. > > Based on your history, I wonder: > - will we have research lab on magic/technology, aimed at improving the > powers of this new world? The science of the world-yet-to-be-renamed is too far beyond what the younger peoples can understand. Magic labs, yes, sure. There seem to be a bunch of those around in the 1.x world, no? ;-) > - where is the super technology that was used to create the new world? Most of it was the gods, actually. As for the people-yet-to-be-renamed, I'm not sure yet, still pondering their fate. Maybe they're travelling the nothingness trying to locate worlds where the Devourers are reaching into and combat their influence before it's too late; when that fails, it becomes necessary to contact the local gods and bring a sample to "New World". Maybe they're preparing the people to be able to share their magic/ science. And it's a difficult to understand plan that will take a long time; maybe too long, if the Anti-Gods arrive first. Or maybe they believe the way to do that is to pick a select few, and that's part of what the "hero project" is really about. Or maybe they have their own agenda. > - why do inhabitants of this world fighting, instead of cooperating > to become more powerful? For a number of silly reasons. Many (most) don't believe this story; remember, it happened a long time ago, for most of them, and exactly how and why it happened, they have only the words of the people-yet-to-be-renamed and the elves. A subset of those who don't believe is those who, even if they heard the story, would be too simple to understand it, or those who would understand it and blame it on you; that's a large portion of the monsters in the game. Others know all about it, but don't expect the consequences will reach them in their lifetimes. After all, in our world, every Christian supposedly believes in the Judgement, but how many do you see preparing for it? A lot, but hardly the majority. Many simply don't believe there's anything they can do about it; those are, if you will, the fatalists. When the Anti-Gods come, it's over, so I'd better take as much as I can from life. I'd expect that to be a rather common view in the Church of Gorokh, for example. Finally, some are on the side of the Anti-Gods. Some think the worlds *should* be destroyed, for either philosophical or emotional reasons, or passed-down doctrine, or simply insanity. Some are in it out of interest; reaping the benefits they get as cultists, and knowing that these benefits will grow the stronger the Devourers influence gets, until a day when it abruptly ends ;-) > - why aren't inhabitants formed to this history during their childhood, > and left in ignorance? you'd definitely want "endoctrined" people to > work together and don't waste time fighting each other In the first few generations, yes. Then people start finding more pressing things to do. Then things degenerate into myth and the younger ones stop believing it. And when the unbelievers grow up they choose not to tell the story to *their* children. And in a few centuries life is pretty much back to what it was before the Fall, except with stranger neighbours. 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] [Rebootworld] The true (hi)story
quoth Lauwenmark Akkendrittae as of Mon, 29 Dec 2008 14:09:04 +0100:
> Hi (and Merry Xmas to all those to which I haven't had the opportunity
> to say so yet :) ),
>
> Just a small note: please find replacements to coin for the term
> Khelens. The original name relates to a setting that is not specifically
> related to Crossfire and existed long before it. Given that you are not
> in sync with that universe but elected to write your own one, I
> respectfully request that you use another name instead.
>
> If to ever be reused, I'd also ask the terms of Normania ("The Biggest
> Port of the Old World after Khelens"), Mäossis ("Those Who live in the
> Great Forest with us Fenxes"), Fax ("the Fenx that travelled far from
> the Great Forest"), Altamira ("The Ship that Roamed Seven Skies") and
> Sannista ("The Flying Ship") to also be changed. They all came from
> various short novels or fantasy stories, and would obviously clash with
> the events described in Rebootworld if changed the way described.
All right, thanks for the heads-up; I don't want to re-use any terms that
we don't have the rights to.
(Sadly, that also means that Mithrandir and others will be gone as well.)
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
[crossfire] [Rebootworld] Plan of attack
These are general stages in the plan to take over ^W^W reboot the world and content. The stages/milestones have no schedule or anything, because this is my free time and AFAIK I'm doing this alone, so they're done when they're done, faster if you help :-) Of course there's one more major point that has been talked about and I'm ignoring here: character creation. I think most active contributors have at one point or another proposed ideas of a better way. So what I'll do is I'll just ignore it; I'll stick to in-game creation exactly as in 1.x until the alternative exists. That implies I'll be doing a HallOfSelection-like thing... I don't mind wasting that work, shouldn't take more than a few hours. 0: Preparation == Write stories, make notes about the layout and "personality" of the kingdom and city of Scorn. This ends when both: 1. I have enough notes that I'm comfortable with going on (should have in a week or so). 2. A decision is made on tall faces and stuff; and server, client, and gridarta are able to edit and test content using whatever system was decided upon. Not rushing the coders or anything, I have no problem with doing this for months if that's how things turn out :-) 1: Basic Scorn == Arches and maps for a map of Scorn city and vicinities that you can walk around and chat in. Possibly an inn and tavern. 2: Dangerous Scorn == Add a few "dungeons" and generally threatening areas, so that people who already play Crossfire can find something to do :-) 3: Amenities Civic buildings, shops, temples, apartments, castle. 4: Super-quest == Before we get to this point we should have an agreement on things like world persistence and large changes to gameplay. This milestone consists on a number of maps, NPCs, and backstory woven in a large over-arching quest, Pupland-style. It's not really discrete; this will take a long time, and may start during or even before 3, and continue through other milestones, ending much later, if ever ;-) Maps from 1.x should be re-used/adapted as much as possible. 5: Magic-user stuff === Introduce the magic-using classes and skills, make sure it all balances out, add magic shops, equipment, maybe magic-oriented dungeons. 6: Priestly stuff = Introduce the priestly classes, prayers, equipment, "branch" cults, make sure it all balances out. 7: Tutorial === A collection of low-level quests or mini-quests that teach the basics of the game, branching at appropriate points for class, and eventually chaining into the super-quest. 8: The next kingdom === Repeat steps 0, 1, 2, 3, 4, 7 and 8 for the next kingdom. Guidelines == The motto: believability. The two kinds of quest/activity: getting on with life (like, keeping the city safe, procuring food, pleasing your god(s), etc) and the big picture (fighting cultists, acquiring better weapons...). The three pillars of believability: internal consistency, depth, and detail. The four basic kinds of player: gamer, H&Ser, explorer, RPer; qualify that some players in all kinds will be more interested in the social aspect, but that's more a spectrum than a division. The five primary kinds of character: basher, magic-user, priest, rogue (thief, assassin, pirate), worker (producer, artificer, trader). 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] [Rebootworld] Priests and prayers and cults
quoth Mark Wedel as of Wed, 24 Dec 2008 14:41:59 -0800: > Lalo Martins wrote: >> Some thoughts on Rebootworld religion. This is mostly to set priestly >> types further away from magic-users. > > Quick question - how does this affect non priests? Does it make > sense for a fighter to decide to worship a good just for the cool > bonuses but otherwise never do anything for that good? One thought > may be the bonuses adjust based on priest level (so a level 1 > follower gets very little resistance bonus or other benefits, while > that level 100 follower gets really good bonuses?) In-story I think that makes most sense; as most religions in history or fiction have both priests and followers :-) I don't know if we need to change the code though. Maybe the resistances are good enough as they are, and higher level priests are rewarded with altar gifts, such as is already the case, for example, for Valkyrie and Mostrai at least. (And Gaea, Gorokh, Devourers and IIRC Rugilli get nifty spells.) Also with "branch cults" that is kind of handled as well... as you get initiated in higher and higher orders you get cooler bonuses. >> - No prayerbooks. Prayers will be learned in the temple and >> different for each cult. (Sometimes it will be the exact same spell >> but with different name; same internal spell code but different >> archetype.) The only spell off the top of my head I see pretty much >> every cult having is Cult Monsters (which will probably have a better >> name though). Maybe Word of Recall. > > What about the healing spells? One things that make priests somewhat > specialized is they get healing, and wizards don't. I don't think *all* cults should have healing. Even in 1.x it's denied for some. But it does make sense for both the Imperial cult and Valrielianism, which I think will account for the majority of players... if you want to play something advanced, then you probably understand that things will be different :-) One question wrt healing: if a player really wants to focus as a healer, how would he level up? In the pre-skill days, he could just join a party and get his share of exp. Now that still works, in a way (he gets more HP), but his praying level won't go up. > In the past, there has been discussions about some form of > reputation. It may make sense to revisit it. A starting character > would have a reputation of 0 in their home city, and perhaps a > negative reputation in foreign cities (foreign in this context could > be elf or dwarf). So the character would actually have many > reputations - one for each well defined region. Yes, I like this idea and it would be very enriching to the content. >> - I don't really think orcs, goblins, etc should have an >> organized religion. I'd like at least one species to scoff at gods >> in general. Others should be more shamanic or animistic. > > Most all intelligent societies tend to have some religion. That > said, reasonable that in some cases it may not be organized, or even > none at all. I'd say "some sort of spirituality", in some cases it may be something that we wouldn't recognize as religion. And I believe all historical civilizations started on that path through some form of animism; personally, I don't see, say, ogres or kobolds, being able to elaborate much more than that. >> It would be cool if there was some kind of reputation/gossip system >> so that if your allegiances got out, soon everyone would know it. >> But that's coding, and not top priority, so let's shelve it for now. > > Hmm. See my note above. > > Note that for many things, actions may speak louder than an item. > Not a lot of weight should be given to someone wearing a holy symbol > if anyone can pick them up for a few silver. Things like skill > level may be recognized - that tends to suggest you've done enough > that folks may recognize you as a hero of Gaea or something. Ideal is a reputation system as you proposed. You'd get minor cult reputation simply by being seen regularly in the temple... wearing a holy symbol could have a minor influence as well. Cult-related quests could do a lot more (although I'm not too sure what those quests would look like). I suppose known membership in a restricted sub-order could also impress people, as it implies a minimum level in the parent cult, but that requires further thought and it has exceptions (being known as a Gorokhist certainly doesn't make you look better with Valrielians, even though it's a restricted sub-cult). > Likewise, one has to be careful about just being able to hide ones > affiliation. If someone is a level 50 priest of Gorokh, they've > probably do
[crossfire] [Rebootworld] The true (hi)story
e hurtful and an abomination, and made a vow to put an end to it. So after devouring Khelens, its world, and its gods, they moved onto the Three Worlds. We wanted to resist, but in our primitive state, we were unable to even fully comprehend the nature of the threat. The Dragons responded the only way they knew; with violence. And some contend that it may have even been the correct response, but with insufficient preparedness. For even, for the first time in their long history, fighting all together as allies, led by their dragon-god and his court of demigods, they had no chance. And the Elves, with their advanced knowledge and their keenly sharp martial skill, immediately understood the odds, and despaired. The Escape == But all wasn't lost. The few remaining Khelentians — the ones who had been in one of the Three Worlds when Khelens fell — seeked out our gods and outlined a plan. And so the gods and Khelentians took a city from our Empire, and the surrounding areas; a minor city, that hadn't yet been targeted by the invaders, but a city with a long, proud history, for it was the birthplace of the great Skud. And likewise, the elven gods took some of their followers, and same with the dragon world. And the three pantheons together, aided by Khelentian techry, built a whole new world, far away where the Others would take a long time to find. They also sealed off the five worlds the Anti-Gods knew about behind a barrier; while the techno/magic says nothing is impossible, in theory it should take thousands of years for them to actually beach it. However, they can reach beyond it. Just like our gods can hear our prayers even when in their houses beyond the world, so can the Others from many worlds away. And they quickly discovered that; they'll extend their tendrils into a new world, and slowly influence some of its people, until they become followers of the Anti-Gods; and as the number and power of these followers grows, the barrier weakens... or maybe it is that the world is pulled inside the barriers... until they are able to claim it whole. But we knew nothing of this. For many centuries, we lived in our New World, learning to coexist and moving on with our lives. And this story gradually became legend and then myth. Until, a little over a hundred years ago, we made contact with the Dwarves. Apparently, they had been taken to New World quite a bit before that, and had been living in secret, underground, wary of contacting the noisy, absurdly tall surface dwellers. Not long after that, arrived Navar; an entire kingdom, taken from a world of science beyond ours but almost no magic, a world of humans identical to us and yet such a strange world; with their miserable peasants and rich noblemen, with their castles and knights, their rich, fortified, yet tiny city, and their strange one-god religion. And only a few years ago, the half-breeds arrived, from a world that, by the looks of them, must have been interesting; the Serpentmen, the fox-like Fendrakis, the Mewmet cat-people, and the Werewolves. Reaction But now, the high priests and archmages finally got news from the gods. As it turns out, we're not here only to escape and survive. As it has been revealed to us, we're brought here to grow and become stronger; to gain power, until one day we're able to take on the Anti-Gods themselves. This day isn't today and it isn't tomorrow, but it will come. 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] Platform statement
quoth Mark Wedel as of Fri, 26 Dec 2008 21:40:25 -0800: > I find most games that make up new terms for money or other game > aspects instead of using already well known words just annoying, > and not really in any way more immersive than those that do use the > standard words. After all, everything else in the game is in English > (or local language of your choice), and to just take out certain terms > almost seems more noticable than not. I still don't agree with this... but in a way, I think we're both right on different aspects. Maybe the right solution is to call the coins something other than gold and silver, and still keep them in your inventory, BUT also keep a total account as you suggested, display that directly in the client, and work with that for most sales. In fact -- and this is coding, not content, so read it as a low-priority suggestion rather than a plan -- I think it would be best if buying and selling had a separate user interface. Local currency... I still think it would be cool, but in practise, it's a moot point; because I look at the story I'm working on, and really, it doesn't make sense to have different currencies there. >>>> (discussion on tall faces) I'll leave that one for the coders, although I need a decision before I start actually making arches and maps. However, I'll repeat what I said before: I believe tall faces are already implemented, at least partially, and that would make that, by definition, a simpler solution than any alternative :-) (If I'm wrong, then ok... but either way it's not up to me. I'll just make arches and maps using any system the coding people tell me to.) > As you noted in another messsage, your idea of amount of spaces > viewable was lower - if 12x12 matches, no problem. But if you are > looking for something equivalent of 15x15, then that would require > protocol changes. That's a point worth considering. Again, it's not up to me, though. > That part is simple enough to understand. But how the player gets > from scorn village is now the question - is the player effectively > just playing on the zoomed out map? What about monsters, etc? And > does he move faster? He would not move faster, that's why I wanted movement to slow down proportionally. Or then again he could move *a little* faster but not too much; so if zoom out is 10x and you move the same "apparent" speed, then you're really moving 10x faster, and I think that's unfair. But maybe you could move 2x faster (5x slower apparently), on the excuse that you're paying less attention to your surroundings. Combine that with a transport (horse) that moves 3x faster, and you're moving 6x faster. Monsters is a good point, I suppose at some point there should be objects (ground?) that force a zoom out. But this is getting too deep, and it involves both coding and content. So here's what I propose: let's postpone this whole aspect. I'll start the content on the assumption that there is a single scale (hugeworld as you say), and if we decide that's unplayable, we think about how to do zooming and how many levels and what the UI will be. Even if we end up doing it exactly as I envisioned it, we'll all be able to fine-tune it better by having actual content to test against. 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] Platform statement
quoth Nicolas Weeger as of Sat, 27 Dec 2008 23:27:58 +0100: > And I for one would go for adjusting existing lore rather than throwing > perfectly good stories that aren't integrated ingame like they should. > > Also I'd rather try to match Yann's story level than "reduce the level" > and be content with something common. The existing lore doesn't work for me. So if it's me doing the work, I have to start over, in order to get something usable out of it. If something else were to do it, then that person would do it the way it works for them... the way it works for me is building a new story from the ground up. Recycling elements yes; many names, places, and even entire tales will be there. But the existing lore, especially the world history and mythology, is not something I'm able to work with. 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] Platform statement
onder if there may be better ways to deal with this. In > any case, we're not really going on design here, but general > goals. But my quick thinking is that it could be more > efficient not to use all those head/tail archetypes and instead > have some form of footprint in the archetype. When some action > happens, look for nearby archetypes and check that footprint. Sorry, I don't follow. >> Yes, impact needs though. Especially in things like speed, and having >> all those tails around, and how many map cells the client and the >> protocol can reasonably handle. >> > I thought one of Ryo's goals was to remain protocol > compatible. This change sort of seems to go away from that. Again, I believe this work has already been done at least partially. > Most of the CRPGs I've played have pretty much had a single > scale - even if there were indoors, they would be same scale as > outside. Hmm, my experience is different... most 2d CPRGs I played, at least this century, have 2 or 3 scales. > I guess it depends on how the outdoors is done. If outdoors > is really just a time sink to get from town to a dungeon (or > other town), then maybe a different interface is needed. It's not a time sink, it's a, hmm, progressive multi-level menu. For a metaphor, try to find something on Google Maps without changing the zoom level. The idea is that I want to make a "dense" (as opposed to sparse) world; not add 1000 miles of nothing in one direction and then a city. So let's say you go out of Scorn to find that dungeon in the forest, or a village. There will be a lot of interesting things around. There's also a chance that many (most?) of those aren't interesting to *you*, so you'd rather not have to think about them too much. So you zoom out to the big picture; Ah, all right, there's a forest here, there's a village there. You go to the forest, then zoom back in to find the grotto... or go to the village and zoom back in to find the house you want. That's not realistic. Realistic would be forcing you to wander around, maybe follow the road, maybe consult a map, and hope for the best. But IMO having a "zoom out" would improve gameplay. >> - Or if doing client zoom button... then scale 3 will simply help >> you find the forest more easily, at which point you zoom to 2 in >> order to find the actual dungeon. (Cool side effect: there could be >> some abandoned treasure just lying around, which you only find if you >> zoom in to 1 in unexpected places...) > > But it seems this zoom of the client still has some relation > to movement - so how do you handle that? In a sense, are you > just adding multiple levels of maps? We can think of this as a sort of mipmapping. When you zoom out, you're essentially making the images smaller, without changing anything else in the map. However, some objects may have optimized images for the new zoom level, so we use those instead. And some images are configured to disappear below a given zoom (or in some cases, above a given zoom -- think a "village" or "forest" object, smallworld-style). The thing with simply scaling things on the client is that if zoom 3 is 10x farther than zoom 2, then things like grass and mountains will look stupid. But then again maybe not. 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
[crossfire] [Rebootworld] Priests and prayers and cults
doing what they see as evil. Gnargites are, of course, to be found between thieves and assassins, and if there is such a thing as a guild of thieves or a structure of organized crime, it will be strongly tied to this cult, although probably with "religious tolerance" towards the other "evil" cults. This concept is a pretty good source of villains and quests. - Elves and dwarves should have their distinct cultures and religions, although of course many Elves and Dwarves are tenth-generation Scornians or more, so they may have converted to other religions. I'd like to make dwarves monotheistic, just because I'm really in love with the dwarven creation myth I wrote years ago. Elves I'll leave for later... maybe someone will chip in while I'm doing other stuff :-) - More and more interesting options should be available as well. Some shamanistic option sounds reasonable, native-American style or Taoistic. Some form of ancestor worship/Shinto. - No meta-fiction. No Builders, no legends that reflect the history of the game itself. If you want to introduce homages, like making Skud an ancient hero or, say, Peter M. a god, do so in a way that fits the setting, the "believability" rule. - Make the cult more present on character life. One thing could be a reaction modifier depending on how "far" apart your cult is to that of an NPC. This modifier could be made stronger by an attribute (on the NPC's praying skill?), so that for example, a stout Valrielist may decide to deny service to a Mostrai follower. But that requires not simply being in the cult, but showing it. Maybe by wearing some kind of holy symbol/emblem. (So that people can be Devourer cultists or Gorokhists in secret.) It would be cool if there was some kind of reputation/gossip system so that if your allegiances got out, soon everyone would know it. But that's coding, and not top priority, so let's shelve it for now. 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] Platform statement
quoth Mark Wedel as of Tue, 23 Dec 2008 21:55:33 -0800: > Lalo Martins wrote: > (various bits snipped here and there) >> Gameplay >> >> >> (use attacktypes more, add more attacktypes) > > Like so many things done in crossfire, the discrete damage > changes is something that was never followed up to fruition. > (...) > I'd make a strong case that every 'attacktype' line get > removed and replaced with appropriate discrete damage name. > The complication here is that if we do use AND logic, automatic > conversion isn't as easy (but for items with only 1 attacktype, > still would be). Since I'm proposing going manually through every single arch anyway for other reasons, I don't think adding this to the task list would be a problem. Or here's a crazy one. How about doing away with the percentage-based resistances, and making resistances an absolute value? That would allow items to keep improving more or less indefinitely, and would greatly help making higher-level characters more powerful. (Dragon logic would probably need adjustments, I guess.) To me it makes sense that someone with a super-duper Mostrai armor takes no damage at all from an Orc's club but takes some from a Holy Avenger or whatever. > The entire magic attacktype is also odd, because for lots of > things it is used to denote a magical affect (thus magic > resistant creatures take less damage). Maybe we just do away > with that logic? Yeah magic is different... have to think about that. > As far as new attacktypes - are you talking physical types, > or other ones? Both I guess. I have a list somewhere that I compiled for a different game... I wouldn't be able to use it directly > For physical, the mix of slashing/blunt/piercing is popular. Yes, I like that idea. Maybe replace physical with these three new types, reusing the physical code for blunt. >> An important point that was raised in the list is that when you meet >> something way above your level, it should hurt you badly but not kill >> you instantly, so you can run away. Of course if the monster is TOO >> MUCH above your level (let's say 4x to keep consistent with the >> definition of extra), then it's reasonable that you die without ever >> knowing what hit you. > > That's reasonable. I'd make a strong case that in general, > it should be difficult for characters to wander into places in > which the enemy is 4x your level (low level dungeons are sort > of an exception - if you're level 2, 4x is level 8 - not as > unreasonable, as level 10 vs 40) Agreed. Again, since every map will be edited for the reboot, that's not unreasonable to ask. Although I'd argue there are cases where an exception is part of the story look at my Valk temple for a good example :-) (the excessively hard monster is used to mark "hey, this is the wrong way, and the seemingly easy path is not the one Valkyrie approves of"). > I think the slower combat has helped this out already - > monsters generally do less damage per hit, so less likely one > hit will take a character out, unless there is a real high > level difference. Yes, I think the slower combat made things a lot better in this aspect. >> What I think the gameplay lacks most in 1.x is goals. (...) > > I agree that more goals are needed, and this can also help > change the H&S focus - some goals may not be kill everything in > a dungeon, but rather get some item, transport and item, etc. Yes but that's not what I meant :-) I'm thinking higher level. Why are you doing that dungeon? In Pupland, for every dungeon you finish, you're presented with the next thing to do for one quest. For every quest you finish, you're given the next quest in the meta-quest. So you have fun and you know what's next. Sometimes what's next is beyond your abilities, but you know what you need to improve in order to continue, so you go find a way to do that. This way you have more fun and before you know it, 40, 60 levels have gone by. >> Generally I tend to go with Nicolas' idea of making the world truly >> dynamic and persistent. > > I'm not completely adverse to this idea, but I think it needs > to be fleshed out more. How do you deal with those > goals/quests when the dungeon(s) related to them might have > been cleared out. How fast does stuff repopulate, etc. As > said before, my biggest concern is that the various maps are > cleared out and haven't been repopulated. True, and that's a decision to be made now before the rebootworld starts being built, because it results in a radically different world. It's a wholly different game design. Bear in mind also... with a persiste
Re: [crossfire] Platform statement
chnical" seems pretty thin on detail. > there are far a lot more aspects of Crossfire that need technical focus > and depth... Sure... but those belong on Nicolas' yard :-) I'm running for "content" leader, not project leader. That, I believe, remains mwedel. > :-) Ok, though "marketing" seems an odd thing to focus on. All the > marketing in the world won't fix what lack of releases breaks in the > free and open source world... Build a good, fun game, make regular > releases (that are timed at basically around the release frequency of > several main OS distributions, be responsible about fixing issues, and > it is doubtful that marketing will be much of an issue. Imbalances in > bug-fixing/releasing/feature/content are all well known problem in > Crossfire. IMO, releasing is the big ticket item in addressing the > community issues. The rest is small potatoes (IMO). If every home gnu/linux/bsd/solaris/etc user who is also a gamer played crossfire, we'd still have a ridiculously small user base. And by simply having quality and regular releases, we wouldn't be anywhere near those results. The problem is that a lot of people who would love the game even as it is now, have never heard of it. But I'm not focusing on marketing, not now. Just wanted to mention it, because I do plan to focus on it... later. > The main personal priority I have is that I believe one of Crossfire's > best qualities is that one can play it off and on... for years. I am > not sure I can put my finger on why, but it is the only game I keep > coming back to. Agreed :-) Well for me not the only... like an addict I'll play every new gameboy pokemon game that nintendo and gamefreak put out... what can I do, it's my dirty little vice. 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] Platform statement
quoth Lalo Martins as of Tue, 23 Dec 2008 09:55:19 +:
> forks, (c) it's too dark to see (or for or whatever), or (d) the
^^^ fog
damn, and I did proofread this thing :-P I blame the cold, my fingers
don't want to behave.
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
[crossfire] Platform statement
he whole redesign project was based on the premise that Yann was going to, if not draw all of them, at least enough to motivate other people. I'm not a graphics artist and I can't promise the same, so unless someone steps up, I think this subproject will have to be shelved. WRT how to do it, I like the "tallworld" idea: don't increase the face size to 64, rather make the objects use more cells, which would reduce the "klunky" feel of the gameplay. I'd even go so far as reducing the cells to 16 or 8 pixels. So here's the plan: - Facesets can have different pixel-per-cell sizes. I think that's already the case, right? - "Rebootworld" will start with current faces, but 4 pixels per cell and "tall faces". So we can design better arches, especially buildings, without drawing anything. That will kind of kill smoothing, I guess, but we'll see how it goes. (I don't know if smoothing + tall faces has been though of yet...) - Then a new "Enhanced" tileset will be started, using 12 pixels per cell. (Hey, no reason to keep to powers of 2.) This will grow as fast as it does. Anyone who feels adventurous is free to start their own tileset. - A benefit of keeping the "basic" tileset around is that it would probably look good on a small-screen client (mobile phone, NDS, PSP, netbook). Technical = See in "Gameplay" for comments on combat system and leveling up. I'd like to request two huge features that I think would improve the feel: Re-hauled movement UI - Moving around with arrows only is so last century! I'd like PCs to have basic pathfinding, so you can click where you want to go and the character will get there. Then of course, I found that people expect that clicking on a monster will attack it. Finally, I'd like to add a "follow this road" mode; basically you set your character on a road and he will go on until (a) it ends, (b) it forks, (c) it's too dark to see (or for or whatever), or (d) the character is too tired/hungry to proceed. (We don't have "tired", but a time limit on using this feature would work. Not sure what happens then, it's up for discussion.) Maybe "follow" is only available to transports... that would be fine if that's how we think it should be. True multi-scale This is really two different features on the server side: - All movement is slowed down proportional to the "scale" attribute of the map. (If you think moving 10x slower on the city than indoors is annoying, bear in mind you'll probably move a little faster indoors, and outdoors you'll have transports, which I want to use more heavily.) - Objects can have different faces depending on the "scale" attribute. I suppose if there isn't a match a default could be used. Those faces can have different (cell) sizes. That doesn't mean you'd look 10x smaller outdoors, but a little smaller. Then I'd go for making the "enhanced" tiles 16 pixels rather than 12. The rationale here is that we're trying to make both movement and window size work for what are two almost entirely different games; dungeon exploring is one thing and requires one UI, walking around the city or road or forest is something else. We could even go back to Smallworld ways and use 3 scales rather than two, I'll put that up for discussion. Alternatively, this could add a zoom UI to the client proper. But in this case I'd change the rule to, if an object doesn't have a face in the right scale, it isn't displayed; that would mean, for example, you can't find the hidden cave on "traveling" zoom, you must go to the right region then zoom in to "outdoors" and search there. Community = Even in its current state, this game seriously rocks, especially compared with a lot of online games I've been playing recently. It amazes me that it doesn't have more players and that nobody has heard of it. We need more marketing, and I have a few ideas in this direction, although I'll keep those for later, to avoid drawing the discussion away from the points above. 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] GTK-V2 "Critical Messages" Pane content improvement
I'd go for a chat pane as well. I remember seeing one in some client,
but I don't remember which one; I've been told on irc jxclient has one,
but I never actually played on it :-) maybe I've only seen it in
screenshots? Anyway. I think a chat pane is the best solution.
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] Release 1.12
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 2009, I hereby proclaim myself "content leader". > To be honest, not some fun part, I'm afraid, but something requires IMO > to ensure a correct game experience. It's fun for me... yeah maybe I'm weird... but that's the part that appeals to me. More than coding, more than actually editing maps, heck even more than playing. 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] Release 1.12
quoth Nicolas Weeger as of Sat, 20 Dec 2008 13:22:50 +0100:
>
> 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 thought gros was going to do that... if he won't for
some reason I already said I'll volunteer too.
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
[crossfire] Release 1.12
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 trunk, notably an actually usable gtk
client; since trunk is no longer going to be the basis for 2.0, there's
no point sticking to the 1.x branch any longer.
(Maybe there should be a vote on rolling back / not merging the rebalance
changes. Personally I love them. But I've seen some people claim
they're not finished enough for release.)
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
[crossfire] Release 1.12
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 trunk, notably an actually usable gtk
client; since trunk is no longer going to be the basis for 2.0, there's
no point sticking to the 1.x branch any longer.
(Maybe there should be a vote on rolling back / not merging the rebalance
changes. Personally I love them. But I've seen some people claim
they're not finished enough for release.)
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] Seeking life...
quoth Marc Lehmann as of Fri, 12 Dec 2008 22:55:54 +0100: > On Sat, Nov 01, 2008 at 01:32:22PM +0100, Nicolas Weeger > wrote: >> So, anyone working on something? Anyone having plans for working on CF? >> Or can we close the shop down? > > I know, it's a bit late for a reply, but I found it rather satisfying > and funny. No, it's just late, really. After 1.5 months of a lot of activity happening, your reply just came of whiny and clueless. Or did you completely miss the server rewrite thread, the news about having code and content leaders, the discussions about Tallworld? Ah, you probably did. Ok then. > The crossfire/metalforge folks are *actively* driving away everybody who > is willing to do work, and you still seem to wonder about it. Now that's > weird. Whatever helps you sleep at night, dude. > Contrast this to Deliantra. You got some stuff working? Good for you. Ranting and flaming about it won't get you anywhere, though, except for losing any scraps of respect some people (me included) still had for you and your project. Please don't post to this list anymore. 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
[crossfire] not yanttf (Re: C++/Qt server version)
quoth Lalo Martins as of Wed, 26 Nov 2008 18:31:12 +: > I'm now strongly opposed to using Qt. Strongly opposed as in: if Qt is > chosen, I'll stop contributing, because I don't want to learn it. And > I'll probably end up forking as well, if the uses I have in mind for the > server require code changes. kbulgrien pointed out on irc this came of as yanttf (yet another threat to fork). So let me clarify. I wouldn't fork for the sake of forking, just because I disagree with the code leader's decision. Next year, I intend to use the crossfire server code for a different project. My original plan was to use the upstream code, contributing any improvements I need to make that work, which means both projects get a richer server and there's less code to maintain. But that was before the whole C++ conversation started. To be fair I'm happier with a TrollC++ server than the current C server, from the POV of a Crossfire player, and if that's the path chosen, I wouldn't stop contributing to content or clients, or stop playing. But as a developer, a TrollC++ server would be unsuitable for my project, so I'd base it off the latest C version; therefore, it's technically a fork. 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] C++/Qt server version
quoth Lauwenmark Akkendrittae as of Wed, 26 Nov 2008 17:18:45 +0100: >> Also, here's something I forgot before: would use Qt imply using >> Trolltech's bastard C++ dialect, and MOC? >> > There we hit your real issue, don't we? Short answer: yes, you have to > use MOC, and yes, it implies using its language extensions. I see no > point in commenting the "bastard" qualifier here - I care about the > efficiency of a dialect, not about its possibly illegitimate origins. Sorry, but I do care about its illegitimate origins, for the same reason that I care about future versions of C++. This project will probably take at least an year, more realistically three or four, to complete; it would be silly if in five years, or ten, it was already difficult to maintain due to tool/language obsolescence. >> Or is that already dead and outdated? >> > This simple question tends to demonstrate your quite superficial > knowledge of Qt, else you wouldn't even have asked. Maybe you should > evaluate both libraries before actually placing a judgement of their > respective qualities/flaws ? No, the word is not superficial, but outdated. I gave up on Qt years ago and haven't checked again (before even Qt3), one of the reasons being MOC. And I assumed there was a chance it would be gone by now, since IMO an idea so clearly idiotic as language extensions and pre-compiling couldn't stay around for too long in a library used by so many people. Apparently, I was wrong. Oh well. I'm now strongly opposed to using Qt. Strongly opposed as in: if Qt is chosen, I'll stop contributing, because I don't want to learn it. And I'll probably end up forking as well, if the uses I have in mind for the server require code changes. 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] C++/Qt server version
quoth Lauwenmark Akkendrittae as of Mon, 24 Nov 2008 20:02:49 +0100: > Le lundi 24 novembre 2008, Lalo Martins a écrit : > 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; Agreed. > - Although you mentioned several things that integrate nicely with > Boost, providing Internationalization or a crossplatform building > system, the whole point is that all of this is provided inside the Qt > tool suite, and requires no external/3rd party dependency. This is a > significant advantage to me. That's true for ICU, but not Jam; Jam *is* part of the Boost tool suite. > My own, personal tastes lean towards Qt more than Boost, mostly for the > way Qt extended the C++ language to make some fundamental mechanisms > more accessible. It provides a level of simplicity more in touch with > the capabilities of my old braincells :). Hmm... the same could be said for Boost, and the improvements in Boost are more likely to be in future versions of the C++ standard, since there's a huge overlap in membership between the C++ committee and the Boost project. That's one of the main reasons I favour Boost. Also, here's something I forgot before: would use Qt imply using Trolltech's bastard C++ dialect, and MOC? Or is that already dead and outdated? If we'll have to code in a C++ dialect and require a toolset that not many people will already have installed, then I'm strongly opposed to Qt. 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] C++/Qt server version
Before anyone gets the impression I'm turning this into a Boost holy war... let me reiterate I don't feel that strongly about it, just answering Nicolas' questions here. quoth Nicolas Weeger as of Mon, 24 Nov 2008 16:57:50 +0100: > I'm not a Boost specialist either (and that can have an impact on my > preference for Qt), but from what I gather, here are Qt features Boost > doesn't have (someone will correct me if I'm wrong): > - multilanguage support Meaning? Like gettext? It *seems* most non-Qt people use ICU for i18n and l10n, although I do have a bit of a problem with that, in that ICU has its own string object, with an API different from the STL string... It does integrate nicely with Boost though. > - GUI classes - modular, so you can disable if not needed, and if you > need you're using the same base classes It doesn't, and that's a good thing in my book ;-) > - image manipulation http://www.boost.org/doc/libs/1_37_0/libs/gil/doc/index.html > - crossplatform build system Jam, one of the best crossplatform build systems out there at the moment, used by a lot of non-boost-related projects. > Note that C++/Qt and Python interact decently with some tests, there > doesn't seem to be any issue there. Well, you *can* simply use libpython from C++. But Boost::Python is a whole new level of integration, it allows you to directly wrap classes and other cool magic. That may not be an issue for us, though, since we're filtering our Python stuff through the plug-in API anyway. Depends, I guess, on how C++ we want to convert the plug-in API to. It may also turn out that once everything is classes, there's no need for the plug-in isolation API anymore. 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] C++/Qt server version
quoth Nicolas Weeger as of Mon, 24 Nov 2008 16:50:17 +0100:
> So why Qt:
> - cross-platform
> - well tested through KDE and many applications - has all the basics we
> need: strings (including shared strings for memory reduction unless I'm
> mistaking), sockets, file / directory, threads and locks, multilanguage
> support
> - modular so we can only use what we need (no GUI for server,
> definitely) - easy to plug in GUI if needed with class coherence -
> signal/slot mechanism that could be used for plugins or archetype
> reloading - existing unit test framework (not that advanced, but enough
> for almost all our needs I think)
All your arguments are also true of Boost, thought ;-) with the added
benefit (IMHO) that probably more people already have Boost installed
than Qt. (Probably more people already know it, too.)
Then again, as I said before, whatever you pick is fine... you're the one
writing the code!
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] C++/Qt server version
quoth Nicolas Weeger as of Mon, 24 Nov 2008 16:24:02 +0100: > Doesn't matter. Current C code builds in C++ easily, so no "is that C or > C++?" philosophical question :) > (and that's not a theoritical reply, I did test a few months ago - code > didn't change enough to warrant another test) That was my argument for doing it on trunk. As I see it, steps are: 1. convert build system to use C++ without any real code changes 2. interactively and concurrently: 2a. document how things work 2b. convert discrete parts of the code to C++ 3c. write tests if the code you converted didn't have them yet 3. until you reach a point where we're happy with the design as a C++ app 4. refactor: now that we're fully C++, I'm sure there are many simplifications that can be made to the codebase 5. happiness, peace on earth, cure for cancer/HIV, end of hunger, and no more reality shows Also, since the plan is gradual and interactive, other people than Nicolas can help here and there, which will certainly help it move forward a lot faster. 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] C++/Qt server version
quoth Nicolas Weeger (Mon, 17 Nov 2008 20:07:37 +0100): > So two options: > - I work directly on trunk - my preferred option, considering it's > "unstable" since some years, and doesn't seem to be soon stable, not > much work going on it > - I make a branch and work there - and if needed / when we want we merge > to trunk I'd like to propose that the best alternative is a third one: You work on trunk, but tag (or even branch) the last revision before the C++ transition. -- I'm using a laptop and forgot to copy my signature file. For the moment, whatever info you want is probably at http://lalomartins.info/ or thereabouts... ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Pupland branch
No, the branch is dead. I've been meaning to delete it or something. It
turns out I did something wrong when re-creating it on svn, so it doesn't
really have the changes that were on the old cvs branch. And I don't
have time to work on it now.
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
Also spracht Robert Brockway (Sun, 03 Feb 2008 12:52:50 -0500): > Dead characters on permadeath servers can still return from the dead via > resurrection so they shouldn't be deleted. For that matter, I have a feeling an account system like that could make permadeath more appealing... 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] 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] New plugin: citylife - help needed
Also spracht Nicolas Weeger (Sat, 02 Feb 2008 10:26:17 +0100): >> Sim City (classic) has been just GPLed under the name "Micropolis", and >> the automata that runs the "sims" in the game is available as a library >> within the source tree. > > Well, I'm not totally sure it's nice to control NPCs, because as far as > I know it manages more shops/buildings than individual characters :) Really? From the description, I thought it did control the sims too -- be born, grow up, go from home to work and back, and so on, I love watching them on SC (although it's much more interesting in the later games of the series). > It could be used to control the general town development, though. But > I'd rather see something based in part on player activity (players don't > use at all a shop => it disappears) > > Of course, we could use some algorithms and ideas from that! 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] New plugin: citylife - help needed
Also spracht Nicolas Weeger (Sun, 27 Jan 2008 09:11:31 +0100):
> Hello.
>
> I just committed (to trunk) the first version of a plugin named
> "citylife" that aims to add NPCs to towns.
(...)
> Behaviour is for now totally dumb, NPCs will just move around randomly.
I don't know if you already know this, already use it, already plan to
use it, whatever, but:
Sim City (classic) has been just GPLed under the name "Micropolis", and
the automata that runs the "sims" in the game is available as a library
within the source tree.
http://www.donhopkins.com/home/micropolis/
When that happened, one of the first things I thought was, how awesome it
would be to use it to control NPCs in a game like Crossfire!
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] Spell idea: Elemental skills
Also spracht Mark Wedel (Fri, 26 Oct 2007 23:24:24 -0700): > 1) Create a fifth skill, probably something like 'pure magic', which > would cover the manabolts, detect magic, and other misc spells. Problem > I perhaps see is that this dilutes the spell skills even more, and if > does include some of the bread & butter spells (like detect magic), may > be a case that every spell caster needs this skill. That sounds good to me. > One issue with a general magic skill is how it interacts or is limited > by the > others. I said in my first message that the earth/fire/wind/water have > diametric forces, so one can reasonably limit a character to 3 spell > casting skills. One would sort of envision that pure magic is in the > middle of that circle - does that mean if someone chooses fire as their > speciality, they now have 4 skills (fire, earth, air, general?) And > what about someone that chooses general magic - do they now get all 5, > since the skill they take is in the middle? No. What I'd do is 4 elemental classes, each "attuned" to one elemental skill and "blocked" from the opposite one. All of them would start with the "attuned" skill plus what I'm calling "sorcery". Then they could learn the other two if they want, but not the "opposing" skill. Could we want a "sorcerer" class that starts only with "sorcery" (and maybe alchemy and thaumaturgy?), but can learn all 4, with the price of not having any attunement? Maybe. I think it would be reasonably balanced, by not having any bonuses. Specially if the elemental skills aren't easy to get. 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Spell idea: Elemental skills
Another possibility would be to go for 5 skills: the 4 elements, plus
"sorcery", which would include things like "Detect magic", mana bolts,
and all the chaos stuff. It would start out much weaker than the others,
which might be an interesting challenge for some.
Re Earth: I used to have a spell on my server which essentially throws
rocks at enemies. It was intended as a way to do physical damage with
magic. I never balanced it enough for submitting, but it might be a
reasonable idea.
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.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Project: Slow down combat
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 unarmed combat skills), and possibly spells. A special case is walking. Either just decide that this is a constant value, or make that an attribute of the living creature. Then, on top of that, every living creature has a speed modifier: a multiplier that is applied to every action's speed. While I call that "speed", we could just as well do the opposite and call it "time" (T for the purposes of this email), meaning how many seconds, ticks, or whatever the action takes. Or call it "speed" to make archetype writing easier to understand, but internally convert that to T. So when your "turn" arrives, if you have an action queued, you perform that action, and then your next "turn" is after this action finishes, T ticks(/seconds/...) later. If there is no action queued, you're assumed to take the default action of "wait", which has a (low) constant T. I believe this is simple to implement, easy for map/arch writers to grok, and easy for new players to understand. 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] branches/gtk-v2-libglade created (and already obsolete?)
Also spracht Kevin R. Bulgrien (Sat, 11 Aug 2007 23:12:43 -0500): > http://blogs.gnome.org/johan/2007/06/15/gtkbuilder-has-landed/ > > Interesting... though GtkBuilder is apparently not for Glade-2. Well... here are a number of reasons why your work is still useful: * the v2 client's UI was *already* done with glade * I believe there aren't any GUI tools yet that fully support the GtkBuilder format * and while we're on that, I believe the library doesn't yet have all the functionality offered by libglade, although I'm not sure we're using any of the missing features * we have been promised migration tools in the future to convert Glade files into GtkBuild ones; there is some prototype stuff, but not, I believe, yet production quality. Which means, when GtkBuilder does mature, we can convert our files * and conversely, we've been told migration from libglade to GtkBuilder won't be very hard; in particular, it will be easier than migrating a "normal" gtk+ app which uses glade 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] GTK2-v2 Client - Big Inv, All Msgs, 4 Stat Tabs
Also spracht Kevin R. Bulgrien (Wed, 08 Aug 2007 02:35:56 -0500):
> I did a libglade tutorial... Not ready to try on the crossfire client
> yet, but am tempting myself.
Here's a thought: when you feel comfortable enough to start, create a
branch (/client/branches/libglade) and hack on. If you stumble, ask here
or on irc, and I'll lend a hand. (I suspect others will too.) This is
IMHO a very worthwhile project.
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.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Client proposal: redo inventory/look widgets
Also spracht Mark Wedel (Sat, 04 Aug 2007 23:42:46 -0700): > Lalo Martins wrote: > >> So here's the proposal: Currently we have an inventory notebook and a >> "look" table. I propose to replace them with two other widgets: what I >> call the "stuff notebook", and the "shortcut area". > > Are you combind what is currently the two separate look & inventory > areas into > 1 widge, that you are then subdividing into these 2 new widgets? I'm > just having troubles visualizing the layout here. Yes. Or to describe it differently -- I'm combining the separate areas into 1 widget, and introducing another widget based on your "shortcut area" idea. >> The "shortcut area"... > > That seems reasonable. Note that dealing with numbers requires a > little bit > of extra work - currently, whenever you enter a number into the client, > it presumes that is the count of how many items you want to drop or pick > up. Oh... I forgot about that. I use it all the time, for dropping money and for alchemy. Then again, those are two things that have no urgency; I suppose it would be OK if on 2.0 you were required to click on a textbox first, before typing the number. > I also wonder if there is some practical limit to number of useful > quick item > keys - at some level, you'd get so many, that it could be a pain to > remember what is there. I'd think that because of space constraints, > those quick items would have to be just icon views, and not names > (unless you hover the mouse) - but if you have to hover the mouse, that > sort of looses the ability for it to be a quick view. I was imagining an icon view, yes. I don't really care for it to be a quick view; its purpose is really binding keys. > I'd have to play around a bit to see if having to switch back and > forth > between ground view and inventory view would be OK, or if it would be > annoying. > The GTK2 client contains different support for containers (displayed > inside > normal inventory, not look area), so that may not be quite so bad. Of course, the answer will be different from person to person; but the glade layout I did for my laptop did have look and inventory as tabs, and it didn't bother me too much, except when I needed to equip or eat or drink something very fast. Which I solved by using bindings, which leads to the shortcut area :-) > I'd probably suggest another tab there, which is filtered inventory, > but let > the character define the filter how they want - probably simple > checkboxes (like the newpickup) - unpaid, magical, etc. This is > probably better than current system, as it is more flexible, and matches > my current method of play better - go to dungeon, get loads of crap, > come back, do detect curse, drop that, do detect magic, drop non > magical, then do identify, drop unlocked stuff I don't want. I did think of something like that, but it sounds like a lot of work, and I'm already biting a rather large chunk with my ideas. >> The third tab deserves its own paragraph :-) what I'm proposing here is >> a "body diagram" similar to what many computer adventure games have... > It would seem to me that the only purpose of such a body view if you > can't > really interact with it (or at least equip items directly on it) is > somewhat limited. Its informative to tell you where you have open > spots, and another way to see what stuff you have equipped (but the show > equipped items filter would probably give a more detailed information). > > It always seems to me the value of such body diagrams is 'ah, I have > nothing > on my feet - let me drag some boots there' type of thing, and/or as an > easy way to equip/unequip items and see overall effect. It is > graphically nicer than having to use the body command to see what stuff > I could equip, but would still seem to be of limited usefulness. You seem to have missed these two parts: >> Clicking a slot (with or without >> an equipped item) would bring up a menu with the items that can be >> equipped there. >> >> Since it's a notebook widget, it would be hard to drag items from the >> inventory to the body diagram; but then again, I have no idea why you'd >> want to do that, since you can double-click it on the inventory :-) Notably, yes, I think it could be possible to enable drag-and-drop; I just don't see that it would be worth it, since really, you can double- click already. > One thing quickly off the top of my head, is if you click on an empty > spot > (say your finger where a ring goes), it could be nice to have an option > for it to make a
[crossfire] Client proposal: redo inventory/look widgets
On the quest to "ungeekify" the client... ;-) Based on recent discussions and a comment from Mwedel, I'd like to propose a revision of the inventory and "look" areas, and the introduction of three new things. (Of course I'm volunteering to write the code for this.) The question being: do people really *USE* all those 10 tabs? Very occasionally I use "unlocked" to sell stuff, but most of the time I use "icons" and the first one. And really, neither is the ideal UI for what I actually want to do. So here's the proposal: Currently we have an inventory notebook and a "look" table. I propose to replace them with two other widgets: what I call the "stuff notebook", and the "shortcut area". The "shortcut area" is really Mwedel's idea. It would be a 10x2 or 10x3 (or even 10x4) table, and you drag either equippable items or spells to that area. Each "slot" essentially manages one keybinding; so if I put my axe on 1,1 and small fireball in 2,1, then pressing "1" does "apply axe" (well not really, but you get the point), and "shift 1" does "cast small fireball". The rows correspond to no mod, shift, ctrl, and alt. Then the "stuff notebook"; I imagine it has a control (checkbox or toggle button) that chooses between "details" and "icons" mode, regardless of tab (I think the choice applies to all tabs). First tab is "look"; the objects on the floor near you. Second is the plain, unfiltered inventory. Yes, the filters are occasionally useful, but IMO, not often enough to justify polluting the UI. Fourth tab is the spell list; this is an awesome addition to the game, IMO it's about time it gets a more permanent space in the UI (and it's somewhat necessary in order for the shortcut area to be useful for mages). The third tab deserves its own paragraph :-) what I'm proposing here is a "body diagram" similar to what many computer adventure games have. Yes, it would require some tinkering, since we have IIRC 3 or 4 different combinations of body parts... but I have an idea how to do it and I'm willing to write the code. Here, you'd have a rough outline of a body, and for each "body slot" your character has, there would be a space where an icon can be drawn; if you equip an item on that slot, the corresponding icon appears there. Clicking a slot (with or without an equipped item) would bring up a menu with the items that can be equipped there. Since it's a notebook widget, it would be hard to drag items from the inventory to the body diagram; but then again, I have no idea why you'd want to do that, since you can double-click it on the inventory :-) I think hovering an icon on any of those widgets, if you are on "icon" view, would display the rest of the information (what you would have on "detail" view) on a tooltip. Thoughts? 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] GTK2-v2 Client new layout defined
Also spracht Mark Wedel (Mon, 30 Jul 2007 22:24:29 -0700): > The real advantage of libglade is that it then makes it very easy for > anyone > to be a tinkerer - anyone with some proficiency in libglade can go about > and try moving things about, and not have to worry about needing to > recompile, etc. There is a non trivial number of people that download > the precompiled packages - OTOH, I have no idea how many of those would > then try to go about playing with glade files. Yeah, that was my thinking exactly. First time I got my hands on the v2 client, years ago, I had a 1024x768 system only for playing. So I fearlessly whipped up glade and made a layout that allowed me to play. No sweat. >>> Of course, my preference would be for using a widget similar to the >>> Gimp's dockable panes, so an user can change the layout at runtime. >>> But I looked around and found no such widget in a library format. > > At one point, that was the reason for the gnome client - the sub > windows were > tearaway, so you could pull one off, put it elsewhere, etc. > > I don't see that functionality in glade - doesn't mean that those > widgets > don't exist, but there is some amount of stuff that requires extra work > to do. I did some research a while ago, there is no such a thing, at least not in library format. It would certainly be a great service to the community in general if someone could abstract the relevant code from the Gimp, either into a new library, or as a contribution to one of libgnome, libsexy, or even gtk+. In fact, for those who haven't used the Gimp in the last few years (or ever), I have to say -- the Gimp dock widgets are simply awesome, they do much more and much better than the Gnome 1 thingies did (or the v1/x11 client's "split windows" mode). Of notably relevance to the CF client: tabbed widgets would become an user decision. Gimp docks create tabs if more than one pane is docked in the same slot. (Did that sentence even make sense? If not, fire up the Gimp and experiment a bit.) > I know it has also been suggested that there be a split window mode - > I think > the only thing to do that would be to remove the root window and make > sub windows for all the other stuff. But I'm sure there is some stuff > that presumes that window_root actually exists, and that the other > windows are children off it. Making window_root exist would be easy - > if some code requires that heirarchy, that is a problem. > > Also, with the gtk2 client (compared to the X11 client), some window > still has > to be nominated as the main/root window - need someplace to put the > menubar. X11 client doesn't have a menubar. But the gtk-v1 client does (did?) have a "split windows" mode, and a menubar. The menubar goes on the window with the stats. On v2 I'd argue it would be on the map. best, Lalo Martins 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] GTK2-v2 Client new layout defined
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 became unable to play on the
laptop, I would be very disappointed.
Generally, your layout reminds me of the v1 client, which makes me ask:
if you're going to have 3 columns, why not put the map in the middle?
Now, on the subject of layouts:
I think it would be a neat idea if the v2 client used libglade, and
allowed the user to choose a layout file in the preferences dialogue.
Yeah, that would probably require a client restart to take effect, and
for best results we should include thumbnail screenshots with the glade
files and find a way to display them in preferences; but overall it
shouldn't be too hard, and if people are serious about writing different
layouts, it might be worth it.
Of course, my preference would be for using a widget similar to the
Gimp's dockable panes, so an user can change the layout at runtime. But
I looked around and found no such widget in a library format.
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.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] classes & guilds
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. It basically keeps the class picking mechanics exactly like they are in CF 1.x: using player changers in-game. Then it would only require writing maps, and I'm much better at that than code. 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] classes & guilds
Also spracht Juergen Kahnert (Thu, 05 Jul 2007 08:18:30 +0200): > I can't see the > special thing why changing the cult needs help from others... In real life, I guess you can just decide you are Budhist or Shamanist, but you can't become Catholic, Muslim, Mormon, traditional Wiccan, or join most of the Christian branches, without special dispensation from a priest. Try "becoming" Jewish :-) >> Only by joining an "advanced" society as I described later, one that >> only admits you if you are a warrior and then teaches you some magic -- >> making you the equivalent of today's "warlock". > > And you end up with characters looking all the same, because they will > make a tour through all the guilds to achieve all the skills... That's a risk, yes. But I hope we can weave things to avoid it. The way I see it a warlock will always be a worse mage than a mage and a worse fighter than a fighter, and it's not hard to enforce that with skill limits. I'd say, for example: The society that teaches magic to fighters only teaches two magic types at amateur level. Even if there are more than one society -- and I envision only one -- it's impossible to join more than once. So if you're serious about it, you can raise one of those to pro by means of a specialized society, like the Tower of Demonology as used in my original post. But I'd put restrictions to keep you from raising both to pro, or raising even one of them to master. (Maybe to be master in a magic skill you need to have all four of them at at least amateur? This would of course be enforced by the maps, not the code.) And of course similar mechanisms to keep mages and priests and thieves from reaching pro in all of one-handed/two-handed/archery. 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] classes & guilds
Also spracht Mark Wedel (Wed, 04 Jul 2007 18:29:55 -0700): > 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. It's good to have different perspectives. I'm clearly going as a pen-and- paper author, shooting for both flavor and game balance. Juergen is coming from some other perspective which I won't try to guess. And since the code needs to get written eventually, of course it's useful to have a code perspective ;-) > Lalo Martins wrote: >> >> In defense of Mark's view of how it works (levels are effective the >> same way, but need more exp), I'd like to say: ... > > Fine by me. It sounds like from that description, amateurs gain exp > more > slowly than professionals, but if both are level 10 in the same skill, > they are effectively equivalent? This sounds like one of the models I > put out - in this case, the skill names just make it easier to know what > skill version you have? In fact it's exactly the model you put out. You'll notice the paragraph starts with "In defense of Mark's view" -- last I checked you're the only Mark here ;-) I'm not really proposing a new idea in this paragraph, rather, I'm exposing my understanding of the *current* meaning of levels in the Crossfire rule system. Which, IMO, supports your model. Sure, it could be changed; but I see no compelling reason to change, since the desired effects can be achieved with your model. >> That said, I'd put a cap on levels... > > Also reasonable. Ideally, the caps could be set by skill, so > for some skills, I think so, yeah. Maybe put the values on the actual archetypes. >> Training to increase proficiency should take time. A way to represent >> that could be: (...) > > This gets a bit messier to code, as now you have multiple versions of > effectively the same skill. If I do the skills command (or just the > output in the client), does it now show two different archery skills? Presumably just the "active" one. Yeah, messy :-( > It'd be a lot easier to just convert (or add/remove) the amateur and > replace it with the professional version. The problem of course is > now you are lower skill level, so may not be able to cast some spells, > weapon to hit could go down, hp go down, etc, which would seem odd. > > I wonder if instead, it could be recorded something like 'player was > level 20 in this skill before it got updated', and things look at > that for min casting level, etc. I'd have to think about if that is > easier to do than multiple skills. Hmm, I like this idea, from what I remember of the code. There is already some similar logic: dragons record the highest level they ever reached, for purposes of atunement "gifts". > > > Interesting ideas, but my quick thoughts/notes: > > - Alex recently started another topic about redoing the intro/low level > area. I thinking having 1 intro area is much better than 5-6 different > intro areas. Er, but I put the intro before the character goes to the "home town" :-) > - While maybe not everyone would use it, I would guess some people would > want an expedited creation method (I just want to player a fighter - I > don't want to wander around a village for for 10 minutes talking to > folks to get the skills I need) Well, this is the kind of thing I'm trying to get rid of :-P Then again, if you're an experienced player and you know exactly what you're doing, getting a "fighter" won't be much slower than it is now, except the distance walked will be a little longer. Ok, I want a human knight. Select Human... select attributes... select Scorn... skip intro... walk South to the Royal Order of Chivalry... ignore the NPC that could give instructions... ignore the magic mouth that says "step here to apply to the Royal Order of Chivalry"... step on the admission mat... there, ready to play. The process was at most twice as long, and it was more fun and enticing, IMHO. > - I might put this as a part of phase 2 - I don't see that this is > actually a requirement related to any of the changes above. It would > seem to be a lot of work, and I'm not sure I'd put it at the same > priority as redoing the skills/classes/races themselves. In fact, for me, this is the *point* of all the changes above :-) >> Learning new skills >> === >> >> New skills, at amateur level, should be IMO taught at a relevant >>
Re: [crossfire] classes & guilds
Also spracht Juergen Kahnert (Wed, 04 Jul 2007 15:16:11 +0200): > On Wed, Jul 04, 2007 at 02:42:05AM +0000, Lalo Martins wrote: >> I could even like it if examining a player reveals her "master" skills >> -- which usually won't be more than a few anyway. > > Do you have an idea how it could looks like? Maybe by clicking on the > character, extending the equipment list. Yes, that's what I thought. >> So pitching a self-taught amateur that took years to get to level 20 >> against a professional who got to this level before "graduating", >> should get an approximately even match. > > I don't think so. Having a master able to teach you the deepest > knowledge (which was gained over generations) is something else than > practicing by your own for years. This is represented by the caps. "The deepest knowledge" is the highest levels. Also, you're missing a point. Read the preceding part again. "Crossfire levels are not a function of experience. They are just that: a measure of how effective a skill is due to experience." Levels are a measure of effectiveness; that's what they mean, at least in this game. So two people of level 20 have the same ability, because that's what level 20 means; if one of them had less, then he wouldn't have level 20. >> The comparison with an untalented black-belt vs. a talented one is IMO >> not fair. A better way to think about it is comparing two fighters who >> were given black belts by the same, rigorous master, in which case they >> should have more or less the same skill. > > I can't confirm that. They won't have the same skill. In fact there > can be huge differences between them, even with the same master teaching > them at (and over) the same time. Then I'm sorry, we seem to have a fundamental difference of philosophy wrt. the real life. I don't believe in that. Bear in mind, I'm not talking about two people training for the same time. I'm talking about two people being awarded the same degree by the same (rigorous) master. The person who's talented will get there faster. The not-very-talented will take a long time. The untalented will never get there. I've seen it happen myself many times on martial arts schools. >> That said, I'd put a cap on levels. If we retain the current level >> system (110/115), I'd cap amateurs at 40 and professionals at 90. >> (Master is of course uncapped, or capped by the system's own limits, >> currently 110). > > I don't think that this will change much. Check out the characters > running around. Do you think they have much skills over 40? Fighters > tend to stop training sorcery after reaching town portal. A level cap > of 40 won't change that... Er, do you really play on the servers? I routinely see people with skills of levels above 100, because that's the only way you can level up at that point. Besides, it still does make a huge difference for things like weapon skills. Finally, there has been talk of redistributing spell levels, and I'm taking for granted that this *will* be done for 2.0. The current spell levels are artifacts from when the highest level was, I don't remember exactly, 40 or 50. >> It would also be interesting to introduce "difficult" items; for >> example, weapons that require pro level in their skills. > > I like that idea. But didn't you said level 20 should be level 20 no > matter of the version of the skill? ;) > > I would simply check the level, not the grade of the skill. You got me there :-) But what I meant to represent here is that someone who had formal training is likely to have more breadth than the self- taught. The examples I use below -- longsword and battle axe -- are really though, and it's unlikely someone will ever bother to spend the time to learn them, if they have to actually live their lives as an active adventurer. Other weapons go beyond that into the barroque: I think someone would have to be really incredibly skilled already before they could self-teach a kusari, for example, without dying in the process. >> Despite appearances, it's just not possible to fight with a longsword >> or a battle axe if you've never been trained on it. > > That would mean you need a lot of skills. For every weapon type a new > skill. And to stay fair, each spell needs to get an own skill level, > too. > > I consider that as an overkill. Oh no, sorry, I'm not proposing different skills. I'm just saying, an untrained person will use the tools (weapons in this case) that are easier to grasp, while someone with formal training will have more breadth. >> Trainin
Re: [crossfire] classes & guilds
er" equivalent in Scorn, you join the Royal Order of Chivalry, where you get professional one-handed and two-handed weapons but no archery; in Navar, you'd instead join the Citizens Guard Corps, getting one-handed and archery. More obviously, each magical academy would only offer two skills, which if I remember my maths correctly, gives us 6 possibilities currently, up to 10 if we implement necromancy as suggested. Joining a society should have a cost, probably in money, although that would be a problem if it's the first thing you do in the game. How hard would it be to implement debt? It should also have some ongoing cost. One idea I like is: to actually enter the premises, you need to pay your fee, which then lets you in and out for some time (a week?) before you have to pay again. This value could be tied to level (overall level? Sum of relevant skills? Highest relevant skill?). I'd also like to make them more or less social, so it would be reasonable to have savebeds in them, and "lounge areas" like the Scorn dragon guild does. It would be interesting to add bulletin boards to them; even better, one inside (for members) and one outside. More importantly, your application to join should be rejected if you have "conflicting" skills. On the starting societies, these would be any skills at pro level at all. Oh, only tangentially related: I'd take that opportunity to "regionalize" the choices of gods. One possibility is that praying at an altar doesn't "convert" you, you need be "converted" on that god's society (although it shouldn't be required to be a member; probably a chapel on a separate entrance). So even though you could still have small "representative" temples of all gods in the major cities, you can't become a follower there. Learning new skills === New skills, at amateur level, should be IMO taught at a relevant society. The Royal Order of Chivalry can teach you amateur archery and smithery, and the Arcane Academy of Scorn has alchemy and one spell type it doesn't teach at pro. For a price, of course; probably very high. Advancing = Then at other places in the world, preferably far from the starting towns, you get other societies that teach you more. I'd even be happy to partially reuse existing maps. To get pro alchemy, you go to the Nurnberg Alchemy Society (existing map, but unfinished); to join, you're required to have amateur level alchemy, which is only learnable in magic academies, so fighters are barred. The Tower of Demonology could reasonably have a new section added, where someone who has amateur summoning can learn it up to pro. These further societies are still societies in all senses, including recurring costs if you want to go back there (and we should think up some perks to encourage that). In terms of RPG, they are similar to "prestige classes". Some current classes could be available only this way. The "warlock" could be replaced by one academy somewhere that teaches fighters to do amateur magic, and another elsewhere (Lake Country comes to mind) that teaches mages to fight. A similar logic goes for the "devotee". Ninjas could be an "improvement" over thieves. Maybe even paladins... Rationales and arguments This gives characters more "involvement" with their, er, "classes". It also, on a crowded server (which we hope to get if we make CF2 cool enough), facilitates characters meeting others of the same society and forming parties. Conversely, if you need one mage for you party of fighters, you know where to go; just stand in front of the Academy for a while. Or if you want to "hire" one, post on the Academy's bulletin board. It also opens the field to even zanier ideas and gaming styles. Merchants Guild anyone? 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] On the software side of "reorganizing the world"
I've been busy, so I have mostly lurked through this discussion, although it's very interesting to me. This week I have some time, so I'm writing a detailed braindump that I should post later. Meanwhile, here's an idea I had when working on Pupland; I didn't pursue it, but it could be very useful if this proposal really goes forward. What I think we need is a "world editor". Editing the world right now is very messy and hard (which is why nobody merged Pupland yet, after what, getting close to 10 years of Bigworld). It's difficult to do, the tools are sub-optimal, and the most obvious ways mess up elevation. (The discussion of whether the current elevation values are even useful belongs elsewhere, in the discussion about weather). 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 map (say, Lone Town) and paste into the world. Also control elevation by hand, using an interface similar to map editors in god games (eg, Sim City). And define things like regions right there, too. If someone wants to pursue that, either as a separate tool or a mode for the new editor, I'd be happy to contribute, although I don't know where to start if I were to write it myself. 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Materials
what about... keep "materialname" and lib/materials, and kill the
"material" field?
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.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Vertical map-tiling
Also spracht Nicolas Weeger (Sun, 03 Jun 2007 23:30:27 +0200): > Hello. > > I remember, quite a long time ago, discussion about "vertical" > map-tiling, that is from eg the top of a tower see the ground below, > belonging to another map. > Anyone remember that, and how it was implemented? > > I think it was like the 4 other map tiles, except used in a different > way. That was the idea. It was never implemented, of course. Points I remember: - Any "nothing" spaces in the upper map, should display the lower map instead. Maybe we'd want some visual clue that the space is at a lower level, though. - And of course walking into one of those sends you down. - There should be an optional "offset", for the case the upper map is smaller? I'm not too keen on this one, better make the maps the same size and use "nothing" spaces as above. Also, this wasn't discussed before, but I'd like the map format to store a height between each vertically-tiled map and the one below it; preferably both. This way if we later come up with an use for that, we don't need to hurry back filling up all maps with values :-P 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Using openal for client audio?
+1. OpenAL is on my list of cool tech I need to set aside some time to investigate. 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] "identification" skills patch
On Mon, 21 May 2007 21:09:31 -0700, Mark Wedel wrote: > Lalo Martins wrote: >> You see 3 beholders. >> They seem healthy and aggressive. >> Beholders usually attack with spells, and often drop beholder eyes. > > That is reasonable, but to really do that, it would seem that the lore > information should be filled in, rather than trying to figure it out > from the monster attributes. My thinking is that we would use the format above when there is no lore field (or, if people really like it, in addition to it). > To figure out what they usually drops > requires parsing the treasure structure - not impossible, but defining > often/rarely/etc for drop frequency gets odd. I'm also not sure I'd > like the output for dragons and other monsters, with a list of 20 things > they frequently drop. My idea is that the code would pick the item(s) most likely to be dropped and print that; the word "often" is static. However, I don't remember how "dropping" works, so I'm not sure there even is a way to determine what's most likely. Equally, the "usually attack" actually displays what attack is stronger; if the monster actually uses that or not, is beyond our scope to know. (How to compare relative "strength" of spells vs. physical attacks is something that still has to be worked out, I'll give this a thought, but only if people generally agree this format is worth the work. I'll obviously also write the code, since I had the idea :-P) 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] "identification" skills patch
Some further suggestions re distance identification :-)
Now there's a much higher chance we'll identify a number of identical
items. So maybe they should "stack"? Say something like:
You see 7 bronze swords. (...)
Second: now that you can identify things that you can't necessarily
carry, maybe there should be some new skills for some of those?
Specially, a skill to id monsters would be sweet.
You see 3 beholders.
They seem healthy and aggressive.
Beholders usually attack with spells, and often drop beholder eyes.
You see 4 wights.
They seem healthy and aggressive.
Wights are usually attack with cold, and often drop wight corpses.
You see 2 monsters you can't identify.
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.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] "identification" skills patch
On Sun, 20 May 2007 21:20:34 -0700, Mark Wedel wrote:
> Alex Schultz wrote:
> Hmm - should you be able to identify stuff you can see, but can't
> reach? An
> example being a treasure room behind a grate, but the grate is closed -
> you can see the treasure room, but are unable to actually get it.
>
> But having ident related skills cover a larger area does make some
> sense.
I'm not so sure. Sometimes you have to touch, smell, or even taste
something to identify it.
Maybe make the range depend on level? Something like lvl/20, so up to
level 20 you only identify what you can touch, smell and taste, and after
that you're experienced enough to be sure from a distance.
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.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Ryo's cleanup
No, you don't get us. The reason we're thanking you is precisely that
nobody wants to do that work :-D we all know it needs doing but... it's
not exciting, it's not shiny, it's not cool... so it gathers dust :-P
Hence the comparison to the Augean Stables. It's quite heroic of you to
be doing it.
In my case, I have things in my queue that I think have a higher
priority, and if I ever get some crossfire time, I spend it on that. I
think it's safe to assume that applies to many other contributors.
Yet... of course, this is not to discourage anyone from helping Nicolas.
If you can, then by all means do it.
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.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Ryo's cleanup
Ryo, I believe I speak for most or all the developers when I express my (our) gratitude, for your tireless efforts cleaning up the Augean Stables... er, I mean, the deprecated stuff in the maps and codebase. Thanks! 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] scripts
On Wed, 09 May 2007 23:34:07 -0700, Mark Wedel wrote: > Lalo Martins wrote: >> One thing that has been bothering me recently, is that increasingly, >> most scripts are tied to arches, yet they reside inside maps, which >> means an admin needs to keep arches and maps strictly in sync. > > Note that this is often the case, and unrelated to scripts. No, but you need to keep them somewhat in sync. With the current state of affairs, you need to keep them *strictly* in sync: update one, update the other. If arch scripts were separate, you could always update arches and not maps, and you could sometimes, not often, update maps and not arches. > Is it possible to run scripts from text that is in memory? If so, > then an > approach similar to the treasures - collect them into a file, read them > into memory, and when needed, run the script from that information in > memory. > > I'd think in that case, the slaying is simpler - just something like > 'slaying > smoking_pipe.py' - since the script is in memory, there is effectively > no need for a pathname. > > One advantage of this collection approach is that the scripts > themselves sit > with the arches (same idea behind the treasurelists) - the script would > be in the same directory as the object itself. I like this idea! It is possible, yes, but not very practical to do. Easier however (and arguably cooler), we can run scripts from a zip file! (Disclaimer: I haven't ever looked at how the plugin loads scripts. I'm making assumptions based on what I know of Python's internals. Ergo, I may be wrong.) 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] scripts
On Thu, 10 May 2007 09:18:09 +0200, Yann Chachkoff wrote: >> > lib/ >> > python/ >> > (arch scripts) >> > maps/ >> > (maps) >> > python/ >> > (map scripts) >> > >> > So we can introduce a notation to mark a script as an arch script, >> > eg: > mmm... I don't understand what the advantage of this would be - I think > it makes things rather complex for map-makers, with no obvious benefit. You missed the point here. It couldn't possibly make things complex for map-makers, since this would never be visible to them :-) map scripts stay exactly as they are. What I'm talking about is introducing a distinction between them and arch scripts. So it would "make things complex" for arch writers... which, IMO, it wouldn't, it would make things a bit simpler for them. 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Patches on tracker
On Mon, 07 May 2007 22:52:51 +0200, Nicolas Weeger wrote: > Le samedi 05 mai 2007 23:10, Mark Wedel a écrit : >> >> The fact that the maps are in the 'share' directory means that write >> access to that area is not a requirement. Lack of write access could >> be for any number of reasons - permissions issues, or for some sites, >> something like that could be put on a read-only filesystem. > > As a side-note, Python can write in the maps's python/ directories, > since Python compiles the scripts to .pyc files. Righto, but if it's unable to due to permissions, then nothing will break. 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] scripts
On Sun, 06 May 2007 18:13:32 +0200, Nicolas Weeger wrote:
> I agree there need to be a way to separate scripts for archetypes,
> instead of having'em in the maps directory.
> I would put them in a subdirectory under where archetypes / treasures /
> formulae are, so we keep some coherence.
Right... that's exactly what I suggested, isn't it? ;-)
> As for having some special syntax, hum. we can always do that first,
> and change later on :)
Which one?
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.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] scripts
One thing that has been bothering me recently, is that increasingly, most
scripts are tied to arches, yet they reside inside maps, which means an
admin needs to keep arches and maps strictly in sync.
I'd like to propose the tiniest addition to the complexity of the python
plugin, so that we'd have a structure like this on a server:
lib/
python/
(arch scripts)
maps/
(maps)
python/
(map scripts)
So we can introduce a notation to mark a script as an arch script, eg:
arch event_apply
title Python
slaying @python/items/smoking_pipe.py
(@ rather than /); or we can just have the plugin look in both places.
Then arch-related scripts could be kept in the arch module where they
belong, or maybe in server, and be installed by server's "make install".
Thoughts?
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.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Blue and green dragon scale / mail
On Tue, 01 May 2007 12:01:47 +0200, Nicolas Weeger wrote:
> Hello.
>
> In response to feature request
> https://sourceforge.net/support/tracker.php?aid=1560406 I added blue and
> green dragon scales (archetype copied from dragon scale), linked them to
> electric and chinese dragons.
> I also added blue and green dragon mail (archetype copied from dragon
> mail), and matching shop converters (again copied from dragon mail
> creator).
>
> Now we can add some converters to shops around the world :)
Awesome, thanks!
I'd say, however... now the "normal" scales need to be made red :-P
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.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Game balance: potion of life, healing, cure disease
On Thu, 12 Apr 2007 20:30:34 +0200, Nicolas Weeger wrote: > Hello. > > Having just started a new character, I think potions of life / healing / cure > disease should be way less expensive than they are now. > > My level 8 character died a lot (ok, Navar is a bad starting place). I have > ~50 plat, potions of life cost ~2500, others are probably the same. > > IMO, those potions should be easily findable (ie monsters drop more, or you > can find them in shops), and cost like 20 or 30 platinum. > > When you're higher level, and start having money, you just don't need > potions - you pray at your god's altar when you die or use your own spells to > protect yourself, you got enough platinum to buy in shops, and so on. maybe the reason they're expensive is the fear that level 10-30 chars will buy all they can find, leaving none for the real beginners to find? One possible solution for this is to have a "restoration service", probably on the house of healing in Scorn 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list [EMAIL PROTECTED] http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] New skill: fishing
On Tue, 03 Apr 2007 23:32:56 +0200, Nicolas Weeger wrote: > I just committed a fishing pole (picture courtesy Maligor), and the > corresponding fishing skill. That's great, some of us wanted that for quite some time :-) thanks > Short summary: to enable a player to fish at a certain spot (sea/river > preferably), just put a fish in the sea's inventory, you're set :) > Of course, ideally, new fish could be created, with their own specifics ^_- I'd like to suggest a small change, if it isn't too pokémon-ish: if the harvested item is a monster, then instead of coming into your inventory, it comes in the space next to you (maybe on the space you're harvesting), and it will attack you. The uses are obvious -- for a hard item, you'd put it in the monster's inventory instead (eg, sea serpent's scale). Or you could charm it. 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ 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. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Pupland branch
I re-created the pupland branch, and started by moving everything to where I think it should be according to the guidelines. As a special open issue, ancient Pupland went to /quests/pupland/ancient, but there are arguments for /ancient_pupland and /quests/ancient_pupland. So if anyone feels strongly about it, now would be the best time to speak up. Also, I'd like people to check out this branch and test if I fixed all the exits. If I have, I'm planning to merge this back into the trunk before starting the actual worldmap work. 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. - personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] desktop file: help request
On Mon, 05 Feb 2007 23:31:26 -0800, Mark Wedel wrote: > Looks good. I wonder if we should include something to differentiate the > gtk1 > & 2 clients. > > On my system, I do have the icon with the gnome menus for the crossfire > client. And all it says is 'Crossfire Client'. If I hover my mouse over it, > it > gives me a description, but still doesn't say anything about what client is. > > Often times on the channel, it is recommended someone use a particular > client. > As the things go now, other than the person running it, there really isn't > much client what client they would get. Even calling it something like > 'Crossfire Client (Gtk2)' would be much more useful. Since (a) this is the client that we recommend primarily and (b) people's desktops will more likely be gtk2 than gtk1, I'd argue to leave it as it is and change the gtk1 entry instead. The guidelines for writing desktop entries out there generally call for more descriptive, less technical details. On that spirit, I used the text from the homepage for the "comment" field, rather than the text in the gtk client's desktop file. Another alternative is to use Name and GenericName keys: Name=Crossfire gtk-v2 Client GenericName=Crossfire Client Although that sounds to me like a stretch of the intended usage. See also below for more on that. >> 2: Hook up the build system to install this file to >> $PREFIX/share/applications or whatever is the appropriate autotools magic. >> I really don't have time to relearn what little autotools I used to know >> to do this, so if someone who knows has a few minutes, please help here. > > This is in the RPM packaging. The normal make install doesn't do anything > with the files. The fact that for it to be of any use, it must be installed > in > the global area, which has a pretty high probability of being outside of > whatever --prefix is set to is one reason. I'm not sure about gnome, but I do have desktop files in /usr/local/share/applications and xfce reads them just fine. Maybe I should check the freedesktop.org spec on that. Can some ubuntu user verify that a file in /usr/local works? And KDE? > One problem is that I believe a uniquely named file is needed for each > program. So as things are now, with both the gtk and gtk2 using the > same name, when installed, one will get overwritten. The one in gtk2 > should be probably be renamed crossfire-client-gtk2.desktop - at least > in this way, the name of the desktop file does match the executable. I thought of that when writing the file, but I feel that if any file is called crossfire-client.desktop, it should be the gtkv2. Or we could rename both to make it explicit. >> 3: The icons should be the ones in pixmaps/*.png, but they are >> corrupted -- probably need the right propset to be recognised as >> binaries. Could someone with the svn fu please do this one? > > This should now be fixed. thanks. >> 5: Again, they need to be hooked up to the build system, so that one of >> them (presumably the higher resolution) gets installed to >> $PREFIX/share/pixmaps/crossfire-client.png > > Is that to make them more easily available for users to find them, or > something else? That's because we're using an "unqualified name" on the icon field: Icon=crossfire-client That makes the menu system look for a file named crossfire-client.png or crossfire-client.svg in the current icon theme, then in the icon path. It's the recommended way of doing it, so that icon theme authors can write an icon for crossfire if they want. The alternative is to write a full pathname in this field, which would require "compiling" the file after you know the installation prefix. 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. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] desktop file: help request
Not for the first time, someone came to #crossfire today, requesting help
to install crossfire, and it turned out he already had it, but couldn't
find it. It turns out we don't ship a .desktop file for the gtk-v2
client, and distros such as ubuntu and fedora won't modify the package to
add one. There is such a file for the gtk client, but it refers to a
non-existent icon file.
So here's a very simple battle plan:
1: Write a proper .desktop file for gtk-v2; possibly use it as a model to
update the one for gtk too. I already committed that file.
2: Hook up the build system to install this file to
$PREFIX/share/applications or whatever is the appropriate autotools magic.
I really don't have time to relearn what little autotools I used to know
to do this, so if someone who knows has a few minutes, please help here.
3: The icons should be the ones in pixmaps/*.png, but they are corrupted
-- probably need the right propset to be recognised as binaries. Could
someone with the svn fu please do this one?
4 (optional): The aforementioned icons are about as pretty as a dog inside
out. Seems they were drawn at 16 and scaled up. So if someone with the
talent wants to draw new ones, be my guest.
5: Again, they need to be hooked up to the build system, so that one of
them (presumably the higher resolution) gets installed to
$PREFIX/share/pixmaps/crossfire-client.png
This is somewhat low priority, or I'd take the time to learn how to do it
myself; but it should be only a few minutes for someone who knows how.
cheers,
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.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CIA - The open source informant
On Fri, 19 Jan 2007 23:28:18 +0100, Christian Hujer wrote:
> Before, only Micah could configure bots. He received so many requests for
> bots
> or new configs that he obviously couldn't reply / support them any longer.
> Now, everybody can register at cia.navi.cx and configure the bots himself via
> a web interface.
aaah, now THAT'S lovely :-) thanks for clearing it up.
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.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CIA - The open source informant
On Thu, 18 Jan 2007 18:29:25 +0100, Christian Hujer wrote:
> Today Micah has added a new service to CIA. It is now possible to have a
> CIA-Bot join an IRC-Channel (e.g. #crossfire at Freenode) and automatically
> post all commits there.
Have I just crossed into an alternate reality? As far as I remember, this
feature was the original purpose of the original CIA, years ago! :-)
(When Micah wrote it to watch PicoGUI's SVN and asked for suggestions to
name it...)
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.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 object-type refactoring
On Mon, 30 Oct 2006 07:16:47 -0700, Alex Schultz wrote: > Well, the way I was thinking of doing it, would be to replace specific > calls to apply, drop, etc as they are sprinkled throughout the code, and > keep common code such as you say, in a "common" subdirectory of the > types directory, and then have the callback called by ob_apply(), call > something like ob_apply_common() at the start of it's code. > IMHO, with this method, the best way to handle legacy non-separated > logic would be to move that legacy logic to the "types/common" > subdirectory, and set it up so ob_apply() and such will call that if it > can't find a callback registered for the type. for that matter... if you're refactoring into a proper object system, why not go all the way and do subclasses? Create a "BASEOBJECT" type, put all the "common" code as methods of this type, and then call that from the top of the specialised methods just like you'd do "super.foo()" in other languages. That keeps the way open for you to decide that, in the future, you need more than one level of inheritance -- eg a "BASEARMOR" type that the armor subtypes inherit from. 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. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Death Penalty, was Re: IRC traffic for Sunday Oct 22
On Wed, 25 Oct 2006 00:42:20 -0700, Mark Wedel wrote: > I'm not sure what the limbo map gets us. I just tossed that around as a possible mechanism to pick your choice of penalty. You could be moved to Limbo, where you can choose between the options you list below by stepping on different exits, or somesuch -- similar to the current Halls of Selection. > A choice between death penalties is interesting. But then you have to > ask what the penalties are. Obvious choices: > - exp loss > - stat loss > - monetary loss > - time loss (character/player has to sit a while?) > - other? I think monetary as in money proper is probably too cheap (and you probably won't be carrying enough to pay it); but sacrificing valuable artifacts adds a cool twist. Also, exp itself can be broken down; "step here to lose X points on your currently active skill" (so you ready_skill then go) in one place, and in another the current "step here to lose Y% exp on all your skills" (where X would have to be larger than Y% of course). I like stat loss, of course; but high-level players have piles of stat potions, so maybe that's only accepted up to a certain level? (Or in practise, it "costs" more and more stat points according to your overall exp, so that it always "hurts" sufficiently) 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. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Pupland Monunent Service
On Fri, 29 Sep 2006 19:58:50 -0600, Alex Schultz wrote:
> Currently, the hall of fame in pupland just sits there static, so I'm
> thinking that perhaps I should make a python script replacement for the
> monument service, to inscribe the names of those who have beat the evil
> masters if they want it inscribed. Anyone have any objections to
> replacing the monument with a 'magical' python based one?
Awesome. As long as some of the names that are there now are kept
statically in the top of the list -- specially those of pupland
contributors if they're there.
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.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
On Mon, 09 Oct 2006 01:10:52 -0700, Mark Wedel wrote: > Make client fullscreen. > > Reasoning here is that most games run in fullscreen mode, so it becomes more > like most games. It can also ensure that other applications are not grabbing > keystrokes/button presses (eg, window manager, etc), so if we tell the player > to > press a key, we can know for sure that if the player presses that key, the > client gets it. For lots of reasons, would still need to support a windowed > mode of operation. > > My thoughts: I personally find fullscreen applications annoying, so would > also > use the window mode (I think most people using unix don't expect full screen > apps). While we can run fullscreen, I don't think we can or should attempt > to > switch resolution. This does then mean that client could be asked to run at > odd > dimensions. I think this issue needs to be investigated further - it may be > possible to make the pointer captive in a non full screen window. I also > think > that if we do full screen window, it needs to be pretty clear how to get out > of > it (nothing more annoying than an app taking over your system) It may have happened while I was in Hong Kong, but from the UI discussions I've seen, I don't remember anyone defending fullscreen clients. Rather, we (myself included) used the term "foolscreen" loosely to describe something else entirely, which is probably more correctly termed "fullwindow". The idea is that the current clients display way too much information; someone has described them as "geeky". Typically, when playing, you're interested: in the map (always), hp/sp/grace/food (almost always), important messages (almost always), chat (often), exp (often), and "look" list (frequently). Everything else only needs to be looked at occasionally. By the basic rules of UI design, it follows that these are the elements that should be always there; if possible, progressively less intrusive in the order above. Other elements should be easy to bring up, but off by default. The solution usually thought of as the best is a design similar to other games, like experimented with in sdlclient and the cfplus client; the map is the main element, taking up almost the whole area, and the other important elements are around the map, possibly in the form of a HUD. Messages and chat could be overlayed on the top left / bottom left of the map, where they're less likely to obscure something important. Pressing ' brings up the "console", where not only you can type, but you can scroll back trough old messages and maybe even see messages that your client was configured not to display in real-time. Other keys (or clicking on "handles" on the edges of the window) would bring up everything else -- basic stats, resists, inventory, spell list, the works. Then of course this raises a separate discussion of widgets. I think "custom" widgets are more appealing, but they have all the disadvantages pointed out by Quinet (specially, clipboard support), and they're obviously extra work. I think such a design is not at all impossible to implement using gtk+ widgets; it may even evolve from the codebase of the current v2 client. 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. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Making maps easier to maintain, by creating custom archetypes for duplicated objects.
on the other hand, there are a few other things that would make something
an archetype. For example, you can't customise an object in a treasure
list, so you have to make an archetype. And the most well-known one, a
custom face.
I'd argue there are things in the game that *shouldn't* be archetypes and
currently are; Lord Eureca is supposed to be unique, but instead he can
come out of your cauldron (wtf?)
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.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS -> SVN conversion
On Mon, 11 Sep 2006 22:37:04 -0700, Mark Wedel wrote:
> What I think I'll probably do is only import the main trunk from CVS.
> There
> really isn't any reason to import any of the branches - those will still
> exist
> in CVS, and I don't think any of them are active.
That's what I figured.
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.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS -> SVN conversion
I don't know if you were even planning to, but for the record, don't
bother converting my pupland branch. It's easier for me to do it manually
(or rather, from the existing bzr branch), since the conversion will be
lossless -- Subversion and bzr understand file and directory moves, while
CVS doesn't, and lots of the work I've done is directory moves.
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.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] cosmologic theory of the evolution of a crossfire hero
Heroes are measured in levels, which are a measure of his experience and
skill. Levels started out in the Old Empire as a system to determine what
spells a magic-user was able to use, but were later formalised trough
tests and theories to all other skills, from jumping to literacy. There
is also an "overall level", known by some as "heroic level"; heroes of
higher level seem to be able to withstand more damage, and control more
powerful artifacts.
According to the priest-scholars of the Occidental Schools, each hero goes
potentially trough five stages:
Chaos (up to level 23) is when the hero becomes a hero; there will be only
a few developed skills, and they deal mostly with weak monsters. This
does mean, however, these are the heroes we see the most, as they're
constantly saving our homes for goblins or undead.
Discord (up to level 46) is typically when heroes die the most, while
trying to figure what kinds of quests and monster they can handle best,
and what are the techniques best suited to them.
Confusion (up to level 69) is a stage where the heroes start developing so
quick, they often don't see the levels going by, and sometimes don't even
know very clearly what they're doing.
Bureaucracy (up to level 92) is an extreme reaction to Confusion; the
heroes decide to put some method to their evolution, up to the point that
it gets almost boring.
Aftermath is when they overgrow Bureaucracy and start on the path to
demigodhood. It is believed that demigods have level 115.
And blessed be the Many-Named in Her perfect work.
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.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Proposal: Alchemy spell changes
On Sun, 10 Sep 2006 15:45:25 -0700, Mark Wedel wrote:
> One of the current issues with alchemy may be at moderate to high levels,
> the
> weight of the nuggets created is also too much to reasonably carry. I wonder
> if
> it may be worthwhile to make different nugget types (platinum nuggets?)
...
> OTOH, perhaps the weight of the nuggets should be seen as a way of
> limiting
> amount of wealth removed from dungeons
IMO that's a non-issue, on such a high level you'll probably have town
portal.
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.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] The Kirby project: Valkyrie, goddess of war
On Thu, 07 Sep 2006 21:07:37 -0700, Mark Wedel wrote: > I think for flesh items, the level of the creature is stored away, and that > is > what is used for comparison on getting resistances. Just because I've been reading this code recently, let's explore it a bit. When a flesh item is created, it stores these pieces of info: - name of the owner (as in "orc's head") - weight of item is adjusted according to owner (the value of weight in the flesh archetype is actually the percentage of owner's weight) - value is adjusted a bit (item->value *= isqrt(donor->level*2)) - food value gets some bonus from owner hp and Con - all resistances are set to half that of the owner's - level on the owner (on its own level field) my change adds other_arch and exp as discussed before. Code is at common/treasure.c. So for dragons eating flesh, the chance of gaining a resist point depends on the flesh resists, its level, and dragon's level. At server/living.c. 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. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] The Kirby project: Valkyrie, goddess of war
On Wed, 06 Sep 2006 22:49:54 -0700, Mark Wedel wrote: > Lalo Martins wrote: >> The slaying thing will only affect enchanted weapons, and she gives them >> rather frequently (as weapons are sacred to her). > > Does she give arrows out a lot? That could help give these character some > form of range attack. I could do that. Enchanted arrows? I think "normal" arrows are about easy enough to find already. >> One alternative idea is to change the flesh code to fill the exp field >> of flesh objects with the exp of the originating monster; would that >> have any unexpected side-effects? Then of course the altar wouldn't >> give the whole exp, just a fraction depending on some factors yet to be >> defined. > > I'm not sure if there would be any side effects of filling in the exp > field. > I doubt it, but I'm not 100% sure that exp isn't overloaded with some > extra meaning. I checked the sell code (shop.c) and the eat code (apply_food()), didn't find any. Anyone can think of another possible use? Then I made the change in my server, tried eating flesh with a dragon, selling it, and using it for alchemy, nothing unexpected seems to have happened. So I'll let it rest for a day or two just in case someone speaks up, then commit it. >> (On an unrelated note, if I do change the flesh code, I'd like to add >> the archetype of the original monster in the other_arch field, for the >> purpose of a spell I'm thinking about; any problem with that?) > > probably not. The issue may be that the archetype may not be entirely > useful > - custom monsters on high level maps vary quite a bit from the > archetype, so you'd have to be careful what fields you use and what you > use them for. I don't care so much. The idea is a "raise dead" or somesuch spell, that turns corpses into (pet) zombies, and heads/hearts into wraiths. It would use the arch of the original monster to set attributes and resists, then apply modifications for undead. Yeah, that would leave them weaker than you'd expect for custom monsters, but I find that perfectly acceptable. Anyway, I'm not writing the spell today or tomorrow, so there's time to figure it out :-) I just thought, if I'm changing flesh to have exp, might as well put in the other_arch in the same commit. 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. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] The Kirby project: Valkyrie, goddess of war
I'm working occasionally on porting the "new gods" I wrote years ago to the current crossfire codebase, then fixing them for balance. I call it "the Kirby project" ;-) The easiest one was one of my favourites: Valkyrie, goddess of war and warriors, which I just committed. It's far from perfect balance-wise right now, but it's good enough to get other people test and suggest how to fine-tune it. Valkie calls for a different gameplay style; or alternatively, it legitimates the style of not using magic. She hates all kinds of magic, and "slays" creatures strong in magic. On the other hand, she denies all magic to her followers as well. In exchange, she gives strong protection against magic. Wait a minute; if there's no magic, then what's the point of the slaying thing? And more importantly, how do you level up? The slaying thing will only affect enchanted weapons, and she gives them rather frequently (as weapons are sacred to her). As for levelling up, that's the fun part. The reason I started with Valkie is that I figured this one out, after a recent irc chat about classes. Valkyrie will accept sacrifices on her altar; you should pick up flesh, bring it to the altar, and then pray. You'll gain praying exp depending on the difference between your level and the dead creature's, and on the flesh resistances. Head and heart are worth slightly more. This is not very fine-tuned yet; as the values are more or less fixed, I'm afraid it would take horrendous piles of flesh to climb a really really high level. One alternative idea is to change the flesh code to fill the exp field of flesh objects with the exp of the originating monster; would that have any unexpected side-effects? Then of course the altar wouldn't give the whole exp, just a fraction depending on some factors yet to be defined. (On an unrelated note, if I do change the flesh code, I'd like to add the archetype of the original monster in the other_arch field, for the purpose of a spell I'm thinking about; any problem with that?) For the sake of testing, I put an altar on the last basement of the abandoned church north of Mostrai in Scorn. This is *NOT* where I intend it to be in the long term, I just want people to help me test it, and that seemed like a good temporary place for it. If you want to test it, have fun, and have a nice carnage! ;-) 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. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Rebalancing, difficulty curve -- simple ideas
On Sat, 02 Sep 2006 14:47:34 -0700, Mark Wedel wrote:
> For most of the mental skills, the complication of things gets cut off.
> Readables above level 10 are pretty darn rare. I'm not sure about
> find/detect
> traps, and the item identification skills are another issue all together.
I have found high-level traps in random maps; as a matter of fact, it's my
primary reason for climbing heaven -- after 30 levels or so they start
giving serious contribution to my find/disarm/lockpick skills, and after
50 they actually often kill me on my current level.
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.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
