reist

Wonderful to have you back Well, if you mean that it no longer compiles on non-windows systems, the "changes" were that they didn't update the build files. I've got a new CEGUIPython compiled against CEGUI, and don't see any problems with it. And I don't think Xenocide crashing now somewhere inside Ogre has any relation to it.

Congrats, dteviot.

Looks pretty good. If implementing it in C++/python, can the data be stored on the C++ side and AI on the python side? I don't see much data, except for AI-related in the class model.

Well, at this point in time doubtful. However, as it will probably take a couple of years (even with XNA) to get to v1.0, I'm hopeful that by that time Mono, Tao and/or Cegeda will have cought up. Failing that, the C#/XNA code makes a good prototype for backporting to the mainline. Mono is already .Net 2.0 ready, or extremely close to being there. I understand that on some of Microsoft's own tests Mono does better Tao, Mono.XNA and cegui# are another issue. I guess it'll take months before they work really well on Linux. Also, don't forget that .Net on Linux (and other OS's) is a really controversial issue for a lot of people, and the Novell/Microsoft deal didn't exactly make people want to touch it.

Looks like a solid, thought through design. I vote for the genius notes

I'm not seeing this at all. The scroll bar always reaches the bottom for me.

I really like the idea about making the rotating image not directly connected to XNet Now, about CEGUI - for CEGUI 0.6, anything using ListboxItem (ComboBox, MultiLineBox) will be rewritten to use Window-based items instead (probably ItemEntry) So if we want Spinners there, it won't be a problem...later. The devs are taking some time off after releasing 0.5 I guess for now we can just use the way you did it.

Well, I fixed the issues SWIG had with CEGUI::ItemListbox (planned to do it for CEGUI's 0.5.0 release ) Also, I don't think the changes to Pi-Masta's (or the current) code would be that big.

Both issues gone

I don't think we're interested in PyOgre. That's too much low-level for our idea of what to do in Python. The way the code is now there's a separation between graphics module - Ogre3D wrappers in C++ and UI module - UI creation using CEGUI and already prepared parts from graphics module. The separation between Ogre3D and python will probably become way more noticeable with the direction the code is moving in now.

The memory problem is happening when we need to create CEGUI objects ourselves. That'll happen every time we have a table to build, like the one for a save/load game dialog. The problem is that the object is created and managed by python, so when you pass it into the C++ managed table you have to keep the object somewhere. Otherwise it'll be immediately destroyed by python and will cause a segfault...

Thanks Aphexx, but release 728 is ancient. It really has nothing to do with what we have now, especially since we started a full rewrite some months ago. Can someone with administrative rights lock this thread?

lvalue_from_pytype: http://boost.org/libs/python/doc/v2/lvalue_from_pytype.html Everyone is invited to figure this one out

Wow, thinking that I am changing the first layout made I guess I'll remove the other events too, then. If we'll ever need them, we could add them at the time.

Looks good and I agree, but some clarification The design looks not finished. We need to finish it to make it work correctly (not a big problem I think) As I understand the current workings: Tickers come from the outside. If you have more than one ticker, each one will increment game time (!!!) GameTime passes itself to objects (not sure how logical is that) There is no way for python objects to ask for time notifications Currently UFO & craft movements are influenced by the main loop cycles. Nothing else. That's why they move on each PC in totally different speeds. Sunlight is the only one that is game-time influenced.