Crossfire Gtk Client compiled against Gtk 2.0

The patch included adds a --enable-cfgtk2 option to configure, that's
disabled by default. It's based on the Windows gtk 2.0 client changes
made to the gcfclient and is quite simple. Since it changes some of
the #ifdef WIN32 to CFGTK2 the windows project files will also need
to be changed accordingly, also the patch doesn't include a
'configure' since it makes patches look friggen ugly so automake is
needed to recreate it.
The configure.in changes also have some smmall issues:
- It reruns PKG_CHECK_MODULES macro that's already been run for
gtkv2 (I didn't want to restructure that part)
- defining --enable-cfgtk2 will cause a configure failure if
GTK 2.0 is not found, it doesn't fall back (a non-issue really)
- it defines -DGTK_WINDOW_DIALOG=GTK_WINDOW_TOPLEVEL as a
compiler flag, instead of using CFGTK2 in the source files (Actually
I've never tried redefining macroes as compiler flags before but
apparently it works)
- the use of GTK_ENABLE_BROKEN isn't all that beautiful but
would require some major work on the multiline text widgets, this is
also used on the windows client
The patch has only been tested on Debian sid amd64 setup and SDL
didn't seem to work, rather strangely you need to disable it in the
game configuration files of the game or it'll result in a crash even
if SDL isn't compiled against it.

Re: Wiki organization.

On Wed, 26 Oct 2005, Andrew Fuchs wrote:
> Should in-game (map guide, etc) be seperated from out of game stuff
> (client help)?
I'd say overall the two should be logically seperated yes. Ie, a single
article should not contain in-game and out-of-game info. Of course
wikilinks may go between them.
> Should there be a section describing each server?
For sure. Being a Wiki these can be maintained by the server admins.
> Should there be a section describing each server's guilds?
If appropriate, sure.
> What to do about spoilers? (rot-13?)
I'd rather not rot-13 the data without an easy way to make it legible
(unless the s/w in use does include this). The Wikipedia approach works
well - a big spoiler warning :)
Cheers,
Rob
--
--
Robert Brockway B.Sc. Phone: +1-416-669-3073
Senior Technical Consultant Email: support@...

Changing Python scripts for global events

Hello.
I was wondering if it wouldn't be interesting to make the
/python/event/python_xxx scripts simply run all scripts in a subdir eg
/python/event/born/, or have the plugin do that itself.
(yes, it feels like runlevels in linux)
The idea is to "modularize" the scripts, to be able to simply distribute
extensions. So we could for instance pack the whole "postoffice"
scripts, and make that an install option. Then make a "guild" package,
and thus (a "gps" one, ...).
Ryo

Re: Changing Python scripts for global events

Le Mardi 1 Novembre 2005 17:42, Nicolas Weeger a écrit :
> Hello.
>
> I was wondering if it wouldn't be interesting to make the
> /python/event/python_xxx scripts simply run all scripts in a subdir eg
> /python/event/born/, or have the plugin do that itself.
>
Sounds indeed like a good idea.
I'd prefer to see the plugin do the job itself - it looks somewhat more
logical to me.
> (yes, it feels like runlevels in linux)
>
> The idea is to "modularize" the scripts, to be able to simply distribute
> extensions. So we could for instance pack the whole "postoffice"
> scripts, and make that an install option. Then make a "guild" package,
> and thus (a "gps" one, ...).
>
... And the next logical step could be the packaging of new maps in the same
way - so if I don't install the Post Office Script package, I cannot install
the Post Office maps (and the buildings are simply unlinked).
Admittedly, this is a rather long-term idea, and maybe unnecessary - but well,
maybe there is something good to gather from that silly idea ?
> Ryo
>
> _______________________________________________
> crossfire mailing list
> crossfire@...
> http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: Changing Python scripts for global events

On 11/1/05, Yann Chachkoff <yann.chachkoff@...> wrote:
> Le Mardi 1 Novembre 2005 17:42, Nicolas Weeger a écrit :
...
> > I was wondering if it wouldn't be interesting to make the
> > /python/event/python_xxx scripts simply run all scripts in a subdir eg
> > /python/event/born/, or have the plugin do that itself.
Sounds good.
> Sounds indeed like a good idea.
> I'd prefer to see the plugin do the job itself - it looks somewhat more
> logical to me.
Agreed.
...
--
Andrew Fuchs

Re: Changing Python scripts for global events

I don't like this idea at all.
"Let's add layers of complexity for no reason!!1111"
Time would better be spent creating usefull things
like new maps and scripts rather then pissing off
people trying to install things IMHO.
--- Yann Chachkoff <yann.chachkoff@...>
wrote:
> ... And the next logical step could be the packaging
> of new maps in the same
> way - so if I don't install the Post Office Script
> package, I cannot install
> the Post Office maps (and the buildings are simply
> unlinked).
> Admittedly, this is a rather long-term idea, and
> maybe unnecessary - but well,
> maybe there is something good to gather from that
> silly idea ?
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

Re: Crossfire Gtk Client compiled against Gtk 2.0

Very nifty. Couple of comments:
- I had to use --disable-gtktest for it to compile. This is probably
related to the configure logic you reused, as mentioned in your post.
- SDL works for me, although lighting leaves some odd effects. As I
haven't been using SDL recently (by mistake), I don't know if these
effects are a problem of the gtk2 build, or "normal".
- If "popup windows" is disabled, I can't log in (can't type the username).
I suppose, until the gtk-v2 client matures, this is the best bet for a
"default" 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.
--
http://www.laranja.org/ mailto:lalo.martins@...
GNU: never give up freedom http://www.gnu.org/

Re: Changing Python scripts for global events

Mitch Obrian a écrit :
> I don't like this idea at all.
> "Let's add layers of complexity for no reason!!1111"
>
> Time would better be spent creating usefull things
> like new maps and scripts rather then pissing off
> people trying to install things IMHO.
Hum actually I see my proposal as a way to simplify distribution &
maintenance of map & Python stuff.
Right now, to add a script for a new player event, you have to modify
the python_born.py script, and insert correct lines. Thus if a server
maintainer wants to disable a function, need to comment out lines,
figure out which and such. Also, if someone makes some scripts, to add
them, need again to patch the script.
If & when we have many scripts, in a modular way, it'll be a real pain
to manage the global event files.
But well, YMMV, of course :)
Ryo

Pickup issues

Hello.
The query_cost function was changed part of selling / buying
improvement. But now the pickup ratio, which uses this function to
estimate the item's price, grabs much more items than before.
Should we try to fix to keep previous behaviour? Or just ignore & leave
like that?
(with ratio 75 [max], i picked all items in dragonmountain except 2
really heavy armors lol)
Ryo

Weather bug, continued

Hello.
I think I figured out why some tiles disappear under weather.
weather.c:change_the_world handles removal of grown items, including
(for instance) grass. It handles ground by simply checking from the
get_ob_map()->above object.
When the overlay for a map is loaded, by map.c:load_overlay_map, items
are inserted, but for some *under* the grass. The revelant code in
object.c:insert_ob_in_map is:
originator->below = op;
} else {
/* If there are other objects, then */
if((! (flag & INS_MAP_LOAD)) &&
((top=GET_MAP_OB(op->map,op->x,op->y))!=NULL)) {
object *last=NULL;
/*
* If there are multiple objects on this space, we do some trickier
handling.
what happens is that a tmap overloading, INS_MAP_LOAD is set, so items
are inserted *below* other items.
So next run the change_the_world will simply check from eg the grass,
and remove it if weather conditions prevent it.
My proposed check is to change insert_ob_in_map for: