Reality Factory

Yes, GUI textures can be stretched but you can also create layouts that keep them at their original size.

Sorry about the lack of updates ...
Unfortunately, there has not been much progress during the last month because I started some preliminary work for my diploma thesis 4 weeks ago. I was snowed under with work and spent more than 45 hours a week at university. I'm getting used to it now so I'll be able to continue the work on RF. I'm sorry that I have to repostpone the next release and it may seem to never get finished but I'm really trying my best ...

No worries, thank you for telling.

But any hope about getting it finished before the end of the year?

I definitely want to finish it before the end of the year.

QuestOfDreams wrote:I made a Genesis3D renderer using the geEngine_RenderPoly function. This was a bit tricky because this function requires the textures to be added to a geWorld and we don't have a world loaded when the program starts into the menu. I solved this by adding a dummy 'NULL' world to the engine that just serves as a texture container. Not the most elegant way but it works so far...

Just looked over this... and an idea comes to my mind.

So there is a world object available during the menu. So would it be possible, theorethically, to add a Pawn entity to this world, which then executes a script during the menu? I've not worked with genesis world objects so far, but could it be possible to have a menu-level which is stored as a second world and is used when you are in the menu, and the normal level which is used when outside of the menu?

(Just playing around with this idea... If it is possible to load two worlds in memory, but only execute one at a time, then would it, theorethically, be possible to have an exterior and an interior level for better performance?)

Yes. That is very possible Jay. Genesis was made to do exactly as you are suggesting.

It would far more efficient to add a SceneGraph and Terrain engine to Genesis to allow this to work smoothly. Adjusting Genesis to support both terrain and BSP would allow the engine to be optimized for terrain when using it and BSP when using that. The terrain engine and editor modifications would be a lot of work though. This should wait for DX9 or OpenGL modifications to allow bigger batches for rendering (e.g Vertex Buffers). Getting rid of the BSP in favor of an Octree would help a lot also. These are big changes which would require a lot of engine work.

Just a question about 0.80: Will the conversation tree builder or something similar be available? I guess the existing conversations will no longer work.

There won't be a tool like treebuilder right from the start. Maybe I can put together a tool for subsequent releases...

Progress:
Fixed the comment bug in the Simkin TreeNode lexer (every single world in comments outside of [ ] was stored as an identifier, now comments (// and /* */) will just be dropped)
Added Graywolf's RFSX library
Implemented CEGUI ScriptModule for Simkin, so that Simkin script methods can be used as event handlers for GUI events, still need to expose some CEGUI functions to Simkin though.

Awesome news! Finally the comment bug is fixed.

QuestOfDreams wrote: Implemented CEGUI ScriptModule for Simkin, so that Simkin script methods can be used as event handlers for GUI events

Awesome! Will these event handlers be in regular pawn scripts or will they be stored in an independent script?

Awsome work QOD!!!!

Hey QOD, I wanna ask if there will be pathfinding in the new version of RF. Juutis told me that Jay has developed a pathfinding system, that's using scriptpoints. It would be awesome to have pathfinding in RF!

QoD pm'ed me about that shortly after the last community release. No, there will be no pathfinding. This is because the pathfinding i implemented is made using a self-invented algortihm. There are known algorithms that can be implemented that are already thoroughly tested and always give the best path at a reasonable speed. My algorithm first does not always give you the best path, and secondly may have some memory problems (memory leaks), because i haven't tested it against memory leaks. With an official algorithm we already know that it works, we don't have to debug it, and it will work as we want it right away.

When we implement pathfinding in the official releases, we want a perfect (or next-to-perfect) implementation because there are already enough half-working features in RF.

Hope that clears it up.