Recent Posts

Thanks chewie 

As far as the "short time" working with FIFE, well
That says a lot about your engine, its quality and ease (cough) of use 

But seriously, Thanks to all of FIFE and your engine ...

Well, back to more coding and "cracking the whip"

All the best,
Tim 

They did it! 

Welcome to the FIFE community  As the screenshots tell me, the force is with you - looks really impressive, considering the "short" time you are working with FIFE.

Best of luck to your team & cheers,
chewie

Hello, My name is Tim, Otherwise known as TAbracadabra.

We are developing a game utilizing the Awesome FIFE Engine.

Thanks FIFE !  

Currently the game does not have a "real" name that we have agreed on ('Cause building it was more of a fun thing to do 1st) but, we refer to it as ATDAlpha which is a direct relation to the game concept conceived by ATDestroy, one of our project team members.

You can view our first post for the game at our blog sub-domain of our business website: http://blog.aitechsolutions.net/2010/08/22/atdalpha--a-star-wars-themed-rpg-using-the-fife-engine.aspx

It has some screen-shots from our early development version.

We'd welcome any feed back or suggestions. Our ears are open!

Feel free to send us a comment or request via the parent site's contact page:
http://www.aitechsolutions.net/ContactAITechSMain.shtml

Thanks and all the best,

Tim

 

We had a similar report here about 64bit windows -> http://forums.fifengine.net/index.php?topic=359.0

Solution seems to be to use a 32bit version of python.

Hi Everybody,
i'm new in the FIFE community. I would like to try FIFE but i have problem to compile it.
I try compilation on a Linux Ubuntu 10.4 64bit edition.
When I use the scons command, I have the error :

/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libpython2.6.a(abstract.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libpython2.6.a: could not read symbols: Bad value

After search on google, I read that error is perhaps caused by compatibility problem with 64bit version, but i don't understand how get around the problem.

If someone can help me...

Thanks for the investigation Auree

The suspicious revision not only has changes regarding the shooter demo but also modified an important core module: fife_timer

http://fife.trac.cvsdude.com/engine/browser/trunk/engine/python/fife/extensions/fife_timer.py?rev=3310

Pychan uses timers all over the place for the event management (see events.py in extensions/pychan/ ), and my guess was / is that something goes very wrong here.
FIFedit makes heavy use of pychan and especially events. So it is more then likely
to me, that we have to fix the timer module.

I experience the same segfaults you do, sometimes up to 5-6 in a row. If the editor does not crash, I hit the "save map" button ...  nearly every second  :/
(Ubuntu 9.10, 32bit, Python 2.6.4, SWIG Version 1.3.36)

cheers,
chewie

Update:
Auree and I installed a self.thisown = 0 in fife_timers.py/Timer.__init__ which seems to solve our segfault-problem for now.

This is by no means a solution, but looking over FIFE::TimeManager and FIFE:TimeEvent we found that:
* TimeManager doesn't cleanup old timers, just manages his event vector for the TimeManager::update() calls
* Helios don't like the return; in the TimeEvent deconstructor
* Helios monitored the TimeEvent deconstructor - and it is called from somewhere

So as we are talking about segfaults, which part of FIFE is deleting old TimeEvents? Events are registerd by clients all over the place - but can we rely on python's gc to delete them?

Moin

As some of you know I experience some problems with FIFE map editor. It crashes. So I'm creating this topic to provide you with all information about the problem that I have. Because I really want this to be fixed

What exactly happens when I run the editor: it starts successfully. But then even the slightest mouse movement may lead to a crash. Or a mouse click. Sometimes (very rarely) it doesn't crash at once and I can open a map and edit it. But eventually it crashes at a random moment.
I don't have this problem with the demos. None of them crashed so far.

I'm running Ubuntu 10.04, 32bit, with Python 2.6.5.

Here's the gdb output (although I know you don't find it very helpful):

Code:

(gdb) run run.py
Starting program: /usr/bin/python run.py
[Thread debugging using libthread_db enabled]
Using the FIFE python module found here:  ../../engine/python/fife
Controller: log: Engine initialize start
Controller: log: Engine settings validated
[New Thread 0xb6f70b70 (LWP 2490)]
Controller: log: Creating event manager
Controller: log: Creating pools
Controller: log: Creating render backend
Controller: log: OpenGL Render backend created
Controller: log: Initializing render backend
Controller: log: Creating main screen
Controller: log: Main screen created
Controller: log: Constructing GUI manager
Controller: log: Events bind to GUI manager
Controller: log: Creating default font
Controller: log: Initializing GUI manager
Controller: log: GUI manager initialized
Controller: log: Creating sound manager
Controller: log: Creating renderers
Controller: log: Creating model
Controller: log: Adding pathers to model
Controller: log: Adding grid prototypes to model
Controller: log: Engine intialized
Importing plugin: LayerTool
Importing plugin: HistoryManager
Importing plugin: CameraEdit
Importing plugin: ObjectSelector
Importing plugin: ObjectEdit

Program received signal SIGSEGV, Segmentation fault.
0x0038d9f2 in ?? () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0x0038d9f2 in ?? () from /lib/tls/i686/cmov/libc.so.6
#1  0x0038fafd in ?? () from /lib/tls/i686/cmov/libc.so.6
#2  0x00391f9c in malloc () from /lib/tls/i686/cmov/libc.so.6
#3  0x02b39a02 in ?? () from /usr/lib/dri/fglrx_dri.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Yesterday I spent the entire evening trying to find the revision that broke the editor for me. And I found it. It's (drumroll) revision #3310. I'm surprised, 'cause according to the log only the shooter demo was changed in this revision. But facts are facts: if I compile FIFE rev#3309 the editor doesn't crash. If I compile #3310 or a newer revision - it crashes.

Please let me know if there's anything else I can do to help you locate and fix the problem.

Hello, I have come across an error when trying to boot up fife editor or any of its demos, I went there in command prompt and my error is -
          from fife import fife
Importerror: No module named fife

This happens every time I try and boot any of the run.py files, I'm running windows 7 so I'm going to assume its something wrong with that, and I do have python, thanks.

Glad to hear you got the demos going.

Probably a new thread would be best for specific questions about pychan and other parts of FIFE.

You can also come to the IRC channel and ask the questions there for possibly a more real-time response. The demos should be a pretty good resource for learning the API. I would focus on the Shooter demo and RPG demo as those are more up to date and pretty clean. The rio de hola demo is a bit aged but is still useful.

Written documentation is a bit lacking currently as we just don't have sufficient resources to keep those up to date so I would suggest going to the code first or the automated documentation Barra pointed out in an early reply.

API docs can be found here, both for the C++ core API as well as the Python bindings:
http://fifedocs.boxbox.org