gmane.games.crossfire.general

SVN:externals update for Gridarta

Rick Tanner — 2013-05-29T23:06:29

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hello,

I updated the external link for Gridarta (gridarta-editor) directory
found in the Crossfire SVN code base. That project was moved to
SourceForge's new platform recently.

However, a changed pdf (server/doc/Developers/smooth.pdf) was
accidentally included in the checkin.

The email alert for the checkin has not arrived in my inbox yet so I'm
not sure what all it's going to show as changed. And what I need to
correct.

The next time you run a SVN update, it will appear that you are
downloading the entire codebase for Gridarta again.

So... Consider this a "heads up" for a long list of file changes at
your next update.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iD8DBQFRpon1hHyvgBp+vH4RAh0FAJ9UubyO9GAjw8jrKdhdUe3PHciZZgCg5xJd
09FHoiyvmWNQJUZt+s/PHeU=
=7d8x
-----END PGP SIGNATURE-----

Re: Race inconsistency for "gnome"

Mark Wedel — 2013-05-12T06:08:51

  Further digging may be necessary - if the gnome race is not used in any spells 
(or is not the enemy of any god), making the player race gnome may be more of an 
advantage, unless there is some backstory for why gnomes never offended anyone. 
  But having it be dwarf would just seem odd.

  The races file is actually a bit of a hack - IIRC, it was originally done way 
back when as an easy way to tweak races (single file to modify, instead of 
needing to go into all the different arch files and do a collect).  Perhaps more 
an issue back in the old days when a collect may thrash the disk for several 
minutes, but all it does now is create confusion, as it redefines something in 
the archetypes.

  Of course, now it is used for other things, like summoning lists, so is not 
really easy to remove.


  The more interesting and harder fix would be to be able to do racial 
heirarchies.  EG, you could have 'good humanoids' or the like which include 
gnome, dwarf, elf, etc, so it is easy to just include that in a

Race inconsistency for "gnome"

Nicolas Weeger — 2013-05-11T19:02:04

Hello.

The "gnome" archetype is defined as having a race of "gnome", but in the 
lib/races file it is defined (and reset by server) as "dwarf".


So I guess one should be fixed, which one?


I admit to not knowing, maybe the easiest fix is to let the race as "gnome", 
there are other monsters with it anyway.



Regards

Nicolas

Re: Gem "upgrade" formulae?

Nicolas Weeger — 2013-05-11T17:12:17

Hello.



I've gone ahead and added the various "raw" gems as well as the upgrade 
recipes.

Right now I use the standard great value / exceptional beauty / flawless beauty 
faces, this can be fixed later :)

Regards


Nicolas

Re: Drop confusion with spooky action at a distance

Karla Stenger — 2013-05-09T18:14:42

Hi,
I think you may refer to the bug fixed with this patch
http://sourceforge.net/p/crossfire/patches/318/
I haven't seen it happening lately :-)


cheers,
k.


2013/3/19 Otto J. Makela <om-X3B1VOXEql0< at >public.gmane.org>

Re: Ice melting spell

Mark Wedel — 2013-05-02T03:57:22

  One can already sort of do this with things like burning hands or other fire 
spells - just be sure to put the ice cubes at the edge so they get a minimal 
amount of fire, which the reduces chance of burning up.

  Of course, there is still a fairly high chance of them burning up even in that 
case (just like with flint & steel).

  Ice cubes could in theory melt on their own - give each a speed, and some 
amount of hit points or the like (perhaps based on how much damage resulted in 
them being put in ice in the first place, eg, a dragon breath is going to be 
pretty big block of ice), and when it runs out of hit points, it is melted.  So 
if players want to wait, they could do so.

  One problem there is that some items should basically get ruined even in that 
case - while the scroll may not burn up and turn to ashes, it getting soaked 
with water would likely ruin any writing on it.

Re: Ice melting spell

Nicolas Weeger — 2013-05-01T07:27:39

Hello.



Maybe a "warm" spell? Which wouldn't give any experience, probably, to avoid 
abusing it :)

And with a probability of warming too much and destroying items in the ice.



Ok for a quest, what kind of quest would you see?


Regards


Nicolas


PS: if possible, avoid replying to all and changing the subject, that appears 
in a single thread for some people, making harder to find that melting topic 
later :)

Re: Gem "upgrade" formulae?

Nicolas Weeger — 2013-05-01T07:24:37

Which is why it's nice to add more formulae, imo, makes non combat stuff more 
interesting :)



Would be an interesting mix, indeed:

20 diamonds with thaumaturgy => unrefined diamond of great value
unrefined  with jewelery => diamond of great value

same for next "levels".



Thanks for the offer :)

Then we'd need, for each gem, 3 new faces: unrefined gem of great value, 
unrefined gem of exceptional value, unrefined gem of flawless value :)



For experience and level, I would say, randomly:

- for gem to gem of great value: level 2, exp 1000

- gem of great value to gem of exceptional value: level 6, exp 6000

- gem of exceptional value to gem of flawless value: level 12, exp 12000


Regards


Nicolas

Re: Gem "upgrade" formulae?

Rick Tanner — 2013-04-29T22:35:03

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I like the idea of being able to assemble or craft items in the game.

Here's my thought on this specific idea..

Thaumaturgy to assemble lesser gems in to a flawed gem.

Jeweler skill to cut/polish the flawed gem in to the gem "of
great value", et al.

If graphics are needed, I volunteer to work on that.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iD8DBQFRfvWWhHyvgBp+vH4RAtEFAKCAN0ecqav220NTE+dffNQ4UEJNAgCfVWco
uSAcvWzaDEx/rR3MK3ahE68=
=ImTW
-----END PGP SIGNATURE-----

Re: Gem "upgrade" formulae?

Kevin Zheng — 2013-04-29T22:14:37

I like this idea; I think having the high chance of failure and huge
number of starting materials offsets the cost and random chance of
finding these in the wild.

Perhaps even a skill like jewelery? Then again, I don't know many
jewelers who can put together a bunch of gems to make a better gem.

Good luck,
Kevin Zheng

Ice melting spell

Otto J. Makela — 2013-04-28T19:36:58

One thing I've been thinking would be nice is a pyro spell for melting ice,
a bit like there is a "earth to dust" spell. Messing around with flints
(specially the humorous bit about mistakenly lighting the flint with itself,
and burning it completely up) seems somewhat, er, medieval.

Any takers, it would seem like this could be a reward item from some quest?

Gem "upgrade" formulae?

Nicolas Weeger — 2013-04-28T19:00:32

Hello.


I was wondering of adding gem "upgrades" alchemy recipes, something like:

- 20 diamonds => 1 diamond of great value
- 20 diamonds of great value => 1 diamond of exceptional beauty
- 20 diamonds of exceptional beauty => 1 diamond of flawless value

(with the number high enough to ensure the diamonds in the recipe cost more 
than the resulting diamond)

And equivalent recipes for other emeralds, rubies and such.


Maybe with a high failure rate, and rather in thaumaturgy maybe, which doesn't 
have many recipes.



Opinions?



Regards


Nicolas

Re: Reorganizing dist files on SourceForge download page

Mark Wedel — 2013-04-26T02:47:14

  So when 1.70.0 was released, you can see that all the files (server, client, 
maps, etc) were placed under the crossfire-1.70.0 - it was a while since I did 
that, but I think some of the reason is as you describe - it makes sense for all 
the files for a release to be under one directory.  I also think it might of had 
something to do with how sourceforge presented the information, and it was 
simply more work to put each one in its own directory.

  However, I didn't have the motivation to go back and fix all the other entries 
- if a CLI to the directory structure is available, probably not that hard (a 
few mkdirs here, a few mvs there), but if it all has to be done by the web 
interface, sort of an annoying process.

  Removing the crossfire- prefix on the directory name could be done - I don't 
feel strongly one way or the other on that.  I would say that the names of the 
actual tar archives may make more sense to rename, eg, arch-1.70.0.tar.gz, 
maps-1.70.0.tar.gz, etc.  The only issue with that i

Re: Reorganizing dist files on SourceForge download page

Kevin Zheng — 2013-04-26T02:58:40

In fact, you can't move or rename stuff from the web GUI. Instead,
SourceForge provides shell or SFTP access to the distfiles. More details
are here:

http://sourceforge.net/apps/trac/sourceforge/wiki/SFTP


Agreed with the latter part; let's keep the 'crossfire-' prefix on the
tarballs themselves. I like dropping it from the folders, though.


We can do that for future releases; no point in churning up old stuff.


Didn't realize that; sorry! :p


I think that's a good idea.

Also, not a bad idea to warn the masses before moving stuff.

Thanks,
Kevin Zheng

Re: Reorganizing dist files on SourceForge download page

Kevin Zheng — 2013-04-26T02:00:36

Yes! Sorry for not making that clear...

Thanks,
Kevin Zheng

Re: Reorganizing dist files on SourceForge download page

Rick Tanner — 2013-04-25T20:28:14

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/24/13 11:16 PM, Kevin Zheng wrote:

Just to make sure, do you mean this page?

https://sourceforge.net/projects/crossfire/files/



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iD8DBQFReZHehHyvgBp+vH4RAqPYAJ0XRlwt5bXN/8fSa60ycn3QRSanLwCgrLFQ
JfLE7Zkx6Q/VyOhKI919czI=
=avtw
-----END PGP SIGNATURE-----

Reorganizing dist files on SourceForge download page

Kevin Zheng — 2013-04-25T04:16:56

Hi everyone,

I've noticed that the files available from the project's SourceForge
download page have become very haphazardly organized. I think that it's
time for someone to consider tidying things up a bit. Here are a few
ideas that I've considered:

* Drop the 'crossfire-' prefix from folder names
We know this is Crossfire, even the URL reveals this.

* Organize the root directory by release version number
Good: Makes stuff from a single release easy to find.
Bad: Some stuff doesn't come out every release, so it's harder to find.

* Delete (or mark obsolete) the 'crossfire-editor' folder.
From what I understand, it's somewhat obsolete now. Perhaps put a copy
of a recent Gridarta editor there instead?

* Don't segregate Windows client/server stuff
I don't see why they can't be put together; saves some clutter.

At the same time, I realize that indiscriminately moving around
distfiles breaks stuff for users and distribution packagers (e.g.
FreeBSD port, which I maintain). Still, I feel that we should make a

Re: Just announced! Crossfire:TCG

Astral Blaze — 2013-04-04T17:44:56

Had I seen this on the day, I would've been fooled

On 2 April 2013 19:33, Rick Tanner <leaf-nLfnTIhOdZRl57MIdRCFDg< at >public.gmane.org> wrote:

_______________________________________________
crossfire mailing list
crossfire-BaP4hoWsOe6VyaH7bEyXVA< at >public.gmane.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

GTK client build configuration stuff

Kurt Fitzner — 2013-04-04T00:57:57

Hi all,

First of all a better re-introduction.  For those that don't remember, I
joined the project long ago to work on the gtk client in Windows.  I got
it working, sort of, with OpenGL on Windows and then joined the navy and
got busy.  I've subsequently become re-interested, and still having SVN
access through SourceForge, I intend to work on getting the gtk client
working better in Windows.

I've been looking at the client's configure.ac and
gtk-v2/src/Makefile.am in trunk and there are a couple changes there
that are breaking MinGW's builds.  The problems are A) X11_LIBS are
being set even if no X is detected and B) OpenGL support is only enabled
if X is present.  On Linux these assumptions work, but not in Windows. 

I don't think killing the requirement for X to be present before OpenGL
is detected will break anything in Linux.  If a person is trying to
build/run the client without X, then there are bigger problems with that
scenario than whether or not OpenGL is detected.

I've attached a patch I int

Setting up MinGW to compile the client in Windows

Kurt Fitzner — 2013-04-02T21:28:31

Compiling the GTK2 Crossfire client under Windows (MINGW)
v1.0

These instructions will take you from a base MinGW installation.

1) Install MinGW.  The easiest way (as of 2 Apr 2013) is by downloading
mingw-get-inst from http://www.mingw.org/wiki/Getting_Started

Follow the instructions for installing MinGW.  Specifically, it is suggested
that MinGW not be installed into a directory with a space in the name.

2) Use mingw-get to install libxml2:
   $ mingw-get install msys-libxml2
  
This version of libxml2 is really an internal library for mingw/msys.  It
is used so that pkg-config reports libxml2 is present.  The actual library
used is in the packages we install in step 3.

3) The easy stuff is done.  The rest needs to be downloaded.  We can get
about halfway there right from gtk.org.  Navigate a browser to:
http://www.gtk.org/download/win32.php and download the run-time and dev
packages for the following:
  GLib, ATK, Pango, gdk-pixbuf, GTK+, zlib, cairo, libpng, Freetype,
  Fontconfig, gettext-runtime,

Win32 client compilation

Kurt Fitzner — 2013-04-02T20:06:01

Hello,

It looks like, since the last time I was involved with CF, a lot of work
was done getting the gtk2 client to compile more nicely in Windows under
mingw.  There are a few issues that remain, however.  I've listed them
below.

- MINGW macro is deprecated.  It is now __MINGW32__.  Patch follows.
- The configure script uses pkg-config to check for gtk+, but then the
gtk-v2/src/Makefile.in doesn't use the resultant GTK2_CFLAGS variable. 
This breaks builds on mingw because include files aren't in the standard
unixy places.  I think just adding < at >GTK_CFLAGS< at > to AM_CFLAGS in
Makefile.am should fix it, but I don't have the right version of
autoconf to find out for sure. Changing this should have no effect on
Unix other than making the build system work in more circumstances.
- The configure script checks for libglade don't check to make sure
pkg-config reports that it works.  This means where libglade is
installed, but a dependency for it (like libxml) isn't installed, the
configure script works as normal but