From alriddoch at googlemail.com  Tue Jul  1 07:00:33 2008
From: alriddoch at googlemail.com (Alistair Riddoch)
Date: Tue, 1 Jul 2008 15:00:33 +0100
Subject: [WF-General] Undocumented commits
Message-ID: <4b05edd10807010700s2def39b3gff1e0bfd4bbb7a5a@mail.gmail.com>

In the last 24 hours a number of commits were made to libraries I
maintain in the WorldForge CVS repository.

These commits contained minimal or no messages explaining what they
did, and had no accompanying ChangeLog entry. A brief review of the
ChangeLog files for these libraries should show that an entry exists
for each commit made, and it lists each file affected explicitly,
along with a description of the change.

The commits were made from a cvs account I am not familiar with, so I
am not able to contact the commiter directly. Please can whoever made
these commits add the required ChangeLog entries as soon as possible.
If nothing has been done after a reasonable period of time I will
revert the changes.

Al
-- 
Alistair Riddoch
alriddoch at googlemail.com
http://alistairriddoch.org/

From atorkhov at gmail.com  Tue Jul  1 08:20:27 2008
From: atorkhov at gmail.com (Alexey Torkhov)
Date: Tue, 01 Jul 2008 19:20:27 +0400
Subject: [WF-General] Undocumented commits
In-Reply-To: <4b05edd10807010700s2def39b3gff1e0bfd4bbb7a5a@mail.gmail.com>
References: <4b05edd10807010700s2def39b3gff1e0bfd4bbb7a5a@mail.gmail.com>
Message-ID: <486A4B3B.2010703@gmail.com>

Alistair Riddoch wrote:
> In the last 24 hours a number of commits were made to libraries I
> maintain in the WorldForge CVS repository.
> 
> These commits contained minimal or no messages explaining what they
> did, and had no accompanying ChangeLog entry. A brief review of the
> ChangeLog files for these libraries should show that an entry exists
> for each commit made, and it lists each file affected explicitly,
> along with a description of the change.
> 
> The commits were made from a cvs account I am not familiar with, so I
> am not able to contact the commiter directly. Please can whoever made
> these commits add the required ChangeLog entries as soon as possible.
> If nothing has been done after a reasonable period of time I will
> revert the changes.

Sorry. I was going to add ChangeLog entiries and write you but something 
distracted me.

I see you also going to make new cyphesis release. Please remove 
server/protocol_instructions.h header if it is not needed anymore - it 
is GPLv2-only and could conflict with GPLv3 code.

Alex.

From alriddoch at googlemail.com  Tue Jul  1 09:11:36 2008
From: alriddoch at googlemail.com (Alistair Riddoch)
Date: Tue, 1 Jul 2008 17:11:36 +0100
Subject: [WF-General] Undocumented commits
In-Reply-To: <486A4B3B.2010703@gmail.com>
References: <4b05edd10807010700s2def39b3gff1e0bfd4bbb7a5a@mail.gmail.com>
	<486A4B3B.2010703@gmail.com>
Message-ID: <4b05edd10807010911v2302b6f3ob3ff0bdec461d1e7@mail.gmail.com>

2008/7/1 Alexey Torkhov <atorkhov at gmail.com>:
>
> Sorry. I was going to add ChangeLog entiries and write you but something
> distracted me.

Thanks, I'll check them over.

>
> I see you also going to make new cyphesis release. Please remove
> server/protocol_instructions.h header if it is not needed anymore - it
> is GPLv2-only and could conflict with GPLv3 code.
>

The protocol_instructions.h header was removed from the build on 20th
August last year for exactly this reason, as the ChangeLog shows. I
prefer to keep old removed files around for reference, but add the
line:

#error This file has been removed from the build

to make sure they never get accidentally used. I can see there are
downsides to this, but I still intend to keep them around for now.

Al
-- 
Alistair Riddoch
alriddoch at googlemail.com
http://alistairriddoch.org/

From alriddoch at googlemail.com  Thu Jul  3 05:12:44 2008
From: alriddoch at googlemail.com (Alistair Riddoch)
Date: Thu, 3 Jul 2008 13:12:44 +0100
Subject: [WF-General] Cyphesis 0.5.16 Release
Message-ID: <4b05edd10807030512r72c9a22if360b1f3f0c5f50f@mail.gmail.com>

Cyphesis <http://worldforge.org/dev/eng/servers/cyphesis> version 0.5.16 has
been released and is now available from the WorldForge download
site<http://sourceforge.net/project/showfiles.php?group_id=11799>
.

Cyphesis is a small to medium scale server for WorldForge games, with
builtin AI. This version includes the demo game
Mason<http://worldforge.org/games/mason>which is currently in
development. This release is intended for server
administrators wishing to run a Mason server and World developers developing
new worlds or game systems.[image: More...]

Major changes in this version:

A protocol for activating mechanisms has been implemented.

The memory footprint of a server has been significantly reduced.

The obsolete dysfunctional persistence layer has been removed.

The code has been refactored to have much more sensible class names.

A number of bugs have been fixed.

Source code and Linux binary packages can be downloaded from here:

Source Code tar.bz2<http://downloads.sourceforge.net/worldforge/cyphesis-0.5.16.tar.bz2>

Source Code tar.gz<http://downloads.sourceforge.net/worldforge/cyphesis-0.5.16.tar.gz>

Linux source code
rpm<http://downloads.sourceforge.net/worldforge/cyphesis-0.5.16-1.src.rpm>

Fedora Core 9 rpm<http://downloads.sourceforge.net/worldforge/cyphesis-0.5.16-1.fc9.wf.i386.rpm>


Al
-- 
Alistair Riddoch
alriddoch at googlemail.com
http://alistairriddoch.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.worldforge.org/pipermail/general/attachments/20080703/2cc45f34/attachment.html 

From alriddoch at googlemail.com  Thu Jul 10 17:01:28 2008
From: alriddoch at googlemail.com (Alistair Riddoch)
Date: Fri, 11 Jul 2008 01:01:28 +0100
Subject: [WF-General] quick terrain mod update
In-Reply-To: <53da8f280807091943s657f7158hbfa214c3cf04f42b@mail.gmail.com>
References: <53da8f280807091943s657f7158hbfa214c3cf04f42b@mail.gmail.com>
Message-ID: <4b05edd10807101701x76139469wca99e85fc9976d18@mail.gmail.com>

2008/7/10 Tamas Bates <rhymer at gmail.com>:
> The attached patch updates cyphesis so that it can provide terrain mods to
> ember as an attribute of the terrain entity. It also allows you to change a
> mod's attributes in the entity editor, though this isn't handled correctly,
> yet. Any changes are interpreted as a new modifier that needs to be created.
> Also, this method of handling modifiers probably shouldn't be used at all,
> but it works for now.

Thanks for the patch. I'll look over it for reference, but don't think
it's a good idea to commit this approach to the codebase, as I think
you already understand from our other conversations.

>
> It sounds like they should be handled more like the areas used for trees, so
> my next update will probably be in that direction.
>

Yes, you have the concept exactly. Just as areas of the terrain with a
difference surface are always associated with a concrete physical
entity, so should modifiers that change it's shape.

Good to see working code coming along here. The approach you've taken
here fits really well with the "fast and loose" development philosophy
I wrote about a while back. Rather than waiting until we've designed
the perfect mechanism which involves long delays, you've gone ahead
and implemented something in a nice simple way, and now we have a
better handle on it and understand the problem better, the existing
code can be refactored to use a more refined and flexible mechanism. I
like it.

Keep up the good work.

Al
-- 
Alistair Riddoch
alriddoch at googlemail.com
http://alistairriddoch.org/

From alriddoch at googlemail.com  Thu Jul 10 17:05:40 2008
From: alriddoch at googlemail.com (Alistair Riddoch)
Date: Fri, 11 Jul 2008 01:05:40 +0100
Subject: [WF-General] Updating Cyphesis
In-Reply-To: <53da8f280807101517q1947a18dhac9d1fe69efca079@mail.gmail.com>
References: <53da8f280807031738l4f8e1875y20d7a5a49403a760@mail.gmail.com>
	<4b05edd10807090709u120e8417w54184e97e0210df5@mail.gmail.com>
	<53da8f280807090923y3ece5f61u85d5172e74646ae2@mail.gmail.com>
	<53da8f280807101517q1947a18dhac9d1fe69efca079@mail.gmail.com>
Message-ID: <4b05edd10807101705l3d4e9bfem760368665255737d@mail.gmail.com>

2008/7/10 Tamas Bates <rhymer at gmail.com>:
> I've been looking through the way other properties are applied to entities
> (like the area property) in Cyphesis, It looks like Entity::setAttr already
> takes care of adding properties to an entity. So it looks like the bulk of
> the work to be done is to create a class to handle terrain modifiers
> (TerrainModProperty, perhaps?), and then to ensure that the modifier is
> applied to the terrain when the entity holding it is created (or updated to
> include the modifier).

Yes, TerrainModProperty would be a fine name for the class. The more
tricky problem will be making sure the modifier is updated when the
entity holding the property is moved. It can be done using the
existing code, but probably not well. It may be necessary to make the
code that deals with what I call active properties more flexible and
robust.

I am glad to see the way I have designed the property mechanism in
cyphesis makes sense to someone else.

>
> Are there any classes that check for specific entity attributes that would
> need to be updated to support modifiers?
>

Not that i can think of off the top of my head, but it may be
desirable to add python wrapper code for the class to expose terrain
mod specific functionality to scripts.

Al
-- 
Alistair Riddoch
alriddoch at googlemail.com
http://alistairriddoch.org/

From rhymer at gmail.com  Sat Jul 12 23:03:15 2008
From: rhymer at gmail.com (Tamas Bates)
Date: Sat, 12 Jul 2008 23:03:15 -0700
Subject: [WF-General] SoC: TerrainMod Progress
Message-ID: <53da8f280807122303t4dbab819p2f349ceadcf11249@mail.gmail.com>

I've been working on implementing Mercator Terrain Modifiers for both Ember
and Cyphesis as my Summer of Code project. The reason for this is that
without modifiers customization of the world's terrain is limited to the
height of the basepoints, which makes adding small details (a flat area for
a farm plot or a narrow canyon, for instance) impossible.

I am about half-done with the project. So far I have added support for the
modifiers to Ember along with a small class to keep track of which modifiers
are applied to a given TerrainPage. This class is currently used to display
a cube wherever a modifier is applied when you're in the terrain editor's
overlay mode (similar to the spheres used to mark basepoints), and to
simplify any code needed to manipulate modifiers in Ember. At the moment
there are some limitations on the modifiers that overlap multiple terrain
segments due to an issue in Mercator. Rather than simply overlapping the
segment boundary, the modifier will be clipped to fit in the original
segment it was applied to (usually where the center of the modifier is), and
then applied separately to each, which looks a little odd.

Support for the modifiers in Cyphesis is coming along. I have gotten them to
work, but the solution doesn't fit in with the way similar attributes are
handled. In the near future it will be possible to add terrain mods to any
entity in the game, just like the terrain areas are used for shadows beneath
some trees.

I've also put together a format for transmitting modifiers over Atlas and
written a parser used by both Ember and Cyphesis to handle the data, so
modifiers can be created inside of Cyphesis' define_world.py script.
Behavior when modifying a terrainMod's attributes in the Ember entity editor
is a little erratic, but that should get straightened out over the next
couple of weeks as well.

-Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.worldforge.org/pipermail/general/attachments/20080712/96f2f0f3/attachment-0001.html 

From atorkhov at gmail.com  Mon Jul 14 07:59:30 2008
From: atorkhov at gmail.com (Alexey Torkhov)
Date: Mon, 14 Jul 2008 18:59:30 +0400
Subject: [WF-General] Entity creator weekly GSoC report
Message-ID: <487B69D2.7090005@gmail.com>

Hi.

As per Erik?s request I?m sending GSoC report to this list.

At the moment program that can do following basic things:
     * parse entity recipes,
     * show widget,
     * show GUI adapters from entity recipe on its widget,
     * pass adapters values to Lua function that is specified in entity 
recipe,
     * compose entity replacing placeholders in entity specification 
with values received from Lua function or from adapter directly,
     * send entity to server.

Last week I spend looking and learning on what should be done during the 
second part of program.

The main feature that should be implemented is easy entity positioning. 
This means that while moving mouse over terrain it should show preview 
of entity that will be created. Positioning of entity with mouse was 
recently implemented by Sean and Erik. So I need to implement showing 
imaginary preview or bounding box in the world. This carried me in 
deeply in Ember internals. I?m guessing that this task could simply be 
solved with some OGRE bits and intercepting some controls but I didn?t 
find my way to it yet.

Alex.

From abra185 at gmail.com  Mon Jul 14 08:03:22 2008
From: abra185 at gmail.com (nightz)
Date: Mon, 14 Jul 2008 12:03:22 -0300
Subject: [WF-General] Romulo Introduction - Weekly Report
Message-ID: <1216047803.15356.10.camel@omega>

	Hi there, my name is Romulo, 22, im Brazilian and im currently working
on the Google Summer of Code for Ember. My project is basically
implementing a Sound Manager, responsible to handle
Effects/Music/Streams. It may sound easy but it is a very big project.
 
	On the start we planned a sound handler wich could read the sounddefs
(something like modeldefs) and just play it acordly to server data. We
changed this pretty much to handle the sounds itself according to data
descriptions on the sounddefs and actions received from the server. At
the moment it doesnt play anything. Not anything the server sends at
least. It supports already ogg vorbis playback as well as WAV/PCM
formats, tested in separated executables. I am currently finishing the
sound entity manager wich will connect the Ember::Entity/Eris::Entity to
the Ember::SoundEntity. The Sound entity itself will be responsible in
knowing how to handle the actions server outputs. This week i remade the
SoundObject class to become SoundEntity. Also made a SoundAction class
to answer for server actions. Each SoundAction will be a member of
SoundEntity and depending on the server output it will play its child's
SoundSamples. So, the final status of the project at the moment are:

- Multiplatform.
- Multi thread safe.
- Supports OGG/Vorbis playback.
- Supports WAV/PCM.
- Heavily object oriented driven.
- Abstracted from other Ember modules (graphics, input)
- Client Data Drive (sounddefs - xml)

	I really wish the whole Worldforge community appreciate my work and im
open to critics and comments =]

Sincerely,
Romulo Fernandes.


From rhymer at gmail.com  Mon Jul 14 09:20:28 2008
From: rhymer at gmail.com (Tamas Bates)
Date: Mon, 14 Jul 2008 09:20:28 -0700
Subject: [WF-General] TerrainMods Weekly Update 8
Message-ID: <53da8f280807140920q6635fb11ja61c5559599a0958@mail.gmail.com>

Last week I updated Cyphesis to support terrain mods. I did this mainly by
modifying the TerrainProperty class to check for and apply them. Now that
Cyphesis is able to parse terrain mods, they are no longer stored in the
surfaces attribute of the terrain, but are now contained in their own
attribute. This required a small update to Ember as well, which simplified
the parsing function used for terrain mods.

This leads me to next week's goals. The current implementation works, but
does not use the modifiers as intended, plus it's difficult to alter the
modifiers once they've been created. Next week I intend to first make the
modifiers more general. This means that any entity in the game world can
have a terrain mod as an attribute (Alistair gave a good example of a
building whose foundation needs to be flat). This will require changes in
both Cyphesis and Ember, and I believe much of the work is already done (it
just needs to be moved). Once this is completed, I'll work on making the
modifiers behave better when using the Entity Editor. Currently if you edit
a modifier's parameters in the Entity Editor, a new modifier is created with
the new settings, rather than altering the parameters of the existing
modifier. This is going to be a little tricky because Mercator does not
allow us to change a modifier once it has been applied to the terrain.
Another limitation is that there is no way to remove a specific modifier
from a terrain segment (though there is a function to remove all of them).
One solution may be to hold a list of applied modifiers' attributes, and
when one of them changes clear all mods from the segment(s) it affects, then
apply it and any others affecting the same segment(s) again. Another
solution would be to use another modifier (say a level or slopemod) to
restore the affected terrain before reapplying the new modifier. One issue
with both of these solutions (which we may not be able to get away from) is
that the most recently applied modifier tends to take precedence, which is a
good way to handle things but could cause some confusion for users if they
create the modifiers in one order, then alter them in another.

-Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.worldforge.org/pipermail/general/attachments/20080714/88458825/attachment.html 

From erik.hjortsberg at iteam.se  Tue Jul 15 11:31:48 2008
From: erik.hjortsberg at iteam.se (Erik Hjortsberg)
Date: Tue, 15 Jul 2008 20:31:48 +0200
Subject: [WF-General] Creating imaginary entity
In-Reply-To: <487B6BB8.7070006@gmail.com>
References: <487B6BB8.7070006@gmail.com>
Message-ID: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84A8B@brun.iteam.local>

Hi, sorry I haven't answered before; I've been visiting relatives and haven't had access to Internet nor time off.

I saw your commit where you added your own IInputAdapter; that's exactly the way to do it.

However, we probably want to attach a preview mesh to the mesh as you say. The way Ember decides on what mesh to use is through the ModelMapping framework. The framework basically accepts an instance of Eris::Entity and then applies the rules to it, looking at its attributes, and from that determines what Model to show and which parts to show or hide.

So if we want to show a preview of the model to be created we should basically just create a temporary Eris::Entity from our atlas data and feed that to the ModelMapping framework, get a Model in return and then delete our Eris::Entity.
Then we'll attach our Model to an Ogre::SceneNode which we position in the world. We'll use an Ogre::FrameListener to update the position of our SceneNode to fit with the mouse position each frame. The best example of the latter is the EntityMoveAdapterWorkerTerrainCursor as found here: http://git.worldforge.org/?p=alex/ember.git;a=commitdiff;h=76ede1c4f959b1386d15e67b0fcfcedbe930efeb;hp=ca5ae26910b58c1e85e021102a829cd743fdb55d

And an example of how to use a temporary Eris::Entity to get a Model from the ModelMapping framework can be found in IconManager::getIcon(int pixelWidth, Eris::TypeInfo* erisType), here: http://git.worldforge.org/?p=alex/ember.git;a=blob;f=src/components/ogre/widgets/icons/IconManager.cpp;h=7e6c1ca1ab6114a2686b212b8df407bd8498ceae;hb=76ede1c4f959b1386d15e67b0fcfcedbe930efeb
IconActionCreator is a very simplified implementation of IActionCreator which only records the first model that the mapping framework happens upon. EmberPhysicalEntity uses the more complex and complete EmberEntityActionCreator which also creates and sets up correct actions etc..

However, the code in IconManager::getIcon does not currently work, at least not in debug mode. The reason for this is that when an Eris::Entity is deleted, in the shutdown() method, it will call Eris::View::entityDeleted(Entity* ent). This method will then assert that the Entity in question really was in the global map of entities (i.e. those received from the server). Since we created our entity ourselves it has never been added to the global list in Eris::View and the assert will fail.

This is a really unfortunate assert which effectively prevents us to create any instance of Eris::Entity which aren't part of the world (i.e. created through Eris::View::createEntity(...)). We should see if we can alter Eris so that the assert is removed, allowing us to more easily created temporary entities.
However, when I look through the code now I see that Eris::Entity::shutdown() is virtual. One solution to this problem would be to create a subclass of Eris::Entity, say DetachedEntity, in which you override the shutdown method, providing the same functionality as in the original method, but without the call to Eris::View::entityDeleted.

sincerely Erik

________________________________________
Fr?n: Alexey Torkhov [atorkhov at gmail.com]
Skickat: den 14 juli 2008 17:07
Till: Erik Hjortsberg
Kopia: Kai Blin
?mne: Creating imaginary entity

Hi.

Erik, when you?ll settle down and have time, please answer on question
how to put some imaginary (that is not on server) entity in the world.
Do I have to create instance of EmberPhysicalEntity and register it?

Also, how to put it into moving mode since creating.

I'm now for 4 weeks is not available on IRC - GPRS latency is too bad.

Alex.

From erik.hjortsberg at iteam.se  Wed Jul 16 03:06:43 2008
From: erik.hjortsberg at iteam.se (Erik Hjortsberg)
Date: Wed, 16 Jul 2008 12:06:43 +0200
Subject: [WF-General] TerrainMods Weekly Update 8
In-Reply-To: <53da8f280807140920q6635fb11ja61c5559599a0958@mail.gmail.com>
References: <53da8f280807140920q6635fb11ja61c5559599a0958@mail.gmail.com>
Message-ID: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84A8C@brun.iteam.local>

Hi, I saw your commits to the WorldEmberEntity which handles terrain mods.
However, you would probably want to move that code to EmberEntity instead, since then it will affect all entities instead of just the WorldEmberEntity.
I.e. _all_ entities in the world will always be EmberEntities, since it's the base class for both EmberPhysicalEntity (most entities are physical (have a graphical representation)) and WorldEmberEntity (there will only ever be one instance of WorldEmberEntity: the world entity).

To see how Ember decides what entity class to use look in EmberEntityFactory::instantiate (http://git.worldforge.org/?p=tamas/ember.git;a=blob;f=src/components/ogre/EmberEntityFactory.cpp;h=ebc81fc2efc7ea9902447f59d676d97d40af35db;hb=refs/heads/tamas )
Basically it first checks whether the new entity is the avatar entity, and if so creates an instance of AvatarEmberEntity (which is a subclass of EmberPhysicalEntity). If it's not, it checks whether the entity type is a terrain type, and if so creates an instance of WorldEmberEntity (which is a subclass of EmberEntity). Normally there can only be one instance of the terrain type, so it's practically a singleton. In addition to that, the terrain entity is always the root entity in the entity hierarchy.
If none of the above applies, Ember then checks the ModelMapping framework and looks for a model for the entity type. If any such can be found (which is true in almost all instances) it creates an instance of EmberPhysicalEntity (which is a subclass of EmberEntity); if not it just creates an instance of EmberEntity (which is   subclass of Eris::Entity).

Regarding how to update modifiers, I think the best course right now is to remove and readd all modifiers whenever a single one changes, or is added or deleted. Further on we can look at how to more efficiently apply updates, but I don't think we need to worry about the performance of reapplying all of them currently.

/erik
________________________________________
Fr?n: Tamas Bates [rhymer at gmail.com]
Skickat: den 14 juli 2008 18:20
Till: Erik Hjortsberg; Kai Blin
Kopia: general at worldforge.org
?mne: TerrainMods Weekly Update 8

Last week I updated Cyphesis to support terrain mods. I did this mainly by modifying the TerrainProperty class to check for and apply them. Now that Cyphesis is able to parse terrain mods, they are no longer stored in the surfaces attribute of the terrain, but are now contained in their own attribute. This required a small update to Ember as well, which simplified the parsing function used for terrain mods.

This leads me to next week's goals. The current implementation works, but does not use the modifiers as intended, plus it's difficult to alter the modifiers once they've been created. Next week I intend to first make the modifiers more general. This means that any entity in the game world can have a terrain mod as an attribute (Alistair gave a good example of a building whose foundation needs to be flat). This will require changes in both Cyphesis and Ember, and I believe much of the work is already done (it just needs to be moved). Once this is completed, I'll work on making the modifiers behave better when using the Entity Editor. Currently if you edit a modifier's parameters in the Entity Editor, a new modifier is created with the new settings, rather than altering the parameters of the existing modifier. This is going to be a little tricky because Mercator does not allow us to change a modifier once it has been applied to the terrain. Another limitation is that there is no way to remove a specific modifier from a terrain segment (though there is a function to remove all of them). One solution may be to hold a list of applied modifiers' attributes, and when one of them changes clear all mods from the segment(s) it affects, then apply it and any others affecting the same segment(s) again. Another solution would be to use another modifier (say a level or slopemod) to restore the affected terrain before reapplying the new modifier. One issue with both of these solutions (which we may not be able to get away from) is that the most recently applied modifier tends to take precedence, which is a good way to handle things but could cause some confusion for users if they create the modifiers in one order, then alter them in another.

-Tamas

From atorkhov at gmail.com  Thu Jul 17 10:11:20 2008
From: atorkhov at gmail.com (Alexey Torkhov)
Date: Thu, 17 Jul 2008 21:11:20 +0400
Subject: [WF-General] Creating imaginary entity
In-Reply-To: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84A8B@brun.iteam.local>
References: <487B6BB8.7070006@gmail.com>
	<93BE8A5F0814E64D8CEDC34CA57B764A014EC84A8B@brun.iteam.local>
Message-ID: <487F7D38.5010509@gmail.com>

Hi, good to hear you.

I've made some steps: attached Model to SceneNode and updating SceneNode 
position each frame. Code is reused from IconManager - it works for me 
as my Eris in compiled in non-debug mode.

But I didn't find how to create Eris::Entity from Atlas data and how to 
feed it to ModelMapping framework to get Model. Any clues?

Alex.

Erik Hjortsberg wrote:
> Hi, sorry I haven't answered before; I've been visiting relatives and
> haven't had access to Internet nor time off.
> 
> I saw your commit where you added your own IInputAdapter; that's
> exactly the way to do it.
> 
> However, we probably want to attach a preview mesh to the mesh as you
> say. The way Ember decides on what mesh to use is through the
> ModelMapping framework. The framework basically accepts an instance
> of Eris::Entity and then applies the rules to it, looking at its
> attributes, and from that determines what Model to show and which
> parts to show or hide.
> 
> So if we want to show a preview of the model to be created we should
> basically just create a temporary Eris::Entity from our atlas data
> and feed that to the ModelMapping framework, get a Model in return
> and then delete our Eris::Entity. Then we'll attach our Model to an
> Ogre::SceneNode which we position in the world. We'll use an
> Ogre::FrameListener to update the position of our SceneNode to fit
> with the mouse position each frame. The best example of the latter is
> the EntityMoveAdapterWorkerTerrainCursor as found here:
> http://git.worldforge.org/?p=alex/ember.git;a=commitdiff;h=76ede1c4f959b1386d15e67b0fcfcedbe930efeb;hp=ca5ae26910b58c1e85e021102a829cd743fdb55d
> 
> 
> And an example of how to use a temporary Eris::Entity to get a Model
> from the ModelMapping framework can be found in
> IconManager::getIcon(int pixelWidth, Eris::TypeInfo* erisType), here:
> http://git.worldforge.org/?p=alex/ember.git;a=blob;f=src/components/ogre/widgets/icons/IconManager.cpp;h=7e6c1ca1ab6114a2686b212b8df407bd8498ceae;hb=76ede1c4f959b1386d15e67b0fcfcedbe930efeb
>  IconActionCreator is a very simplified implementation of
> IActionCreator which only records the first model that the mapping
> framework happens upon. EmberPhysicalEntity uses the more complex and
> complete EmberEntityActionCreator which also creates and sets up
> correct actions etc..
> 
> However, the code in IconManager::getIcon does not currently work, at
> least not in debug mode. The reason for this is that when an
> Eris::Entity is deleted, in the shutdown() method, it will call
> Eris::View::entityDeleted(Entity* ent). This method will then assert
> that the Entity in question really was in the global map of entities
> (i.e. those received from the server). Since we created our entity
> ourselves it has never been added to the global list in Eris::View
> and the assert will fail.
> 
> This is a really unfortunate assert which effectively prevents us to
> create any instance of Eris::Entity which aren't part of the world
> (i.e. created through Eris::View::createEntity(...)). We should see
> if we can alter Eris so that the assert is removed, allowing us to
> more easily created temporary entities. However, when I look through
> the code now I see that Eris::Entity::shutdown() is virtual. One
> solution to this problem would be to create a subclass of
> Eris::Entity, say DetachedEntity, in which you override the shutdown
> method, providing the same functionality as in the original method,
> but without the call to Eris::View::entityDeleted.
> 
> sincerely Erik
> 
> ________________________________________
> Fr?n: Alexey Torkhov [atorkhov at gmail.com]
> Skickat: den 14 juli 2008 17:07
> Till: Erik Hjortsberg
> Kopia: Kai Blin
> ?mne: Creating imaginary entity
> 
> Hi.
> 
> Erik, when you?ll settle down and have time, please answer on
> question how to put some imaginary (that is not on server) entity in
> the world. Do I have to create instance of EmberPhysicalEntity and
> register it?
> 
> Also, how to put it into moving mode since creating.
> 
> I'm now for 4 weeks is not available on IRC - GPRS latency is too
> bad.
> 
> Alex.
> 



From erik.hjortsberg at iteam.se  Thu Jul 17 13:05:17 2008
From: erik.hjortsberg at iteam.se (Erik Hjortsberg)
Date: Thu, 17 Jul 2008 22:05:17 +0200
Subject: [WF-General] Creating imaginary entity
In-Reply-To: <487F7D38.5010509@gmail.com>
References: <487B6BB8.7070006@gmail.com>
	<93BE8A5F0814E64D8CEDC34CA57B764A014EC84A8B@brun.iteam.local>,
	<487F7D38.5010509@gmail.com>
Message-ID: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84A8E@brun.iteam.local>

Hi,

normally after the Entity instance has been created it is populated by a call to Eris::Entity::init(...). This is a protected method, called by the Eris::View (since it's a friend class). The init method in turn calls the sight(...) method which then calls the setContentsFromAtlas(...) method, which handles the child entities of the Entity, and then setFromRoot(...) which sets the attributes of the entity from the atlas data. It does this by iteration over the data in the supplied Atlas::Objects::RootData instance and then calling setAttr(...) for each attribute.
I think the best way to proceed here is to use a subclass of Eris::Entity, say DetachedEntity, which exposes a public method which in turn calls setFromRoot. I think we can skip calling setContentsFromAtlas for now. If we don't want to fiddle with wrapping our MapType within a Atlas::Objects::RootData class we can instead just remiplement the functionality in Entity::Sight (i.e. calling setAttr(...) for each attribute).

If all of this however proves to be too clunky (if perhaps there's functionality within Eris::Entity which too heavily relies on the entity being instantiated from real atlas data and correctly added to the View) we could look at providing abstractions within the ModelMapping framework, to make it not so tightly bound to the Eris::Entity class, but I think that should be the last resort.

Once you have the Entity you then need to interface with the ModelMapping framework to get useful data about the models to use etc..
The process works like this:
You first create a ModelMapping instance like this:
modelMapping = ::EmberOgre::Model::Mapping::EmberModelMappingManager::getSingleton().getManager().createMapping(entityPtr, creator);
where "creator" is a pointer to an instance of a class which implements Model::Mapping::IActionCreator. The creator object won't be held by the mapping, so it should really be a reference instead.
The model mapping framework will take care of creating the "matches" and "cases" which make up the mapping for the entity type of the supplied entity, but will delegate the creation of the "actions" to the supplied creator. The most common actions are "display-model" (which will show a Model) and "display-part" (which will show a specified part within a Model). See http://git.worldforge.org/?p=alex/ember.git;a=blob;f=src/components/ogre/EmberEntityActionCreator.cpp;h=83c75a55e81c71f955d4470b045631960fe89b6b;hb=4b4d3c6d1137b87c2678c261880d94699040ce54 for how it's done for the EmberPhysicalEntity. Note that at this stage the actions are only created, they aren't activated yet.

Once the model mapping has been created it's activated by calling ModelMapping::initialize(). This will make the model mapping framework evaluate the data in the entity; mainly its type and it's attributes, and then activating the correct "actions". In the case of the EmberPhysiclaEntity it might mean that an instance of EmberEntityModelAction is activated, which in turn will call EmberPhysicalEntity::setModel(...) (see http://git.worldforge.org/?p=alex/ember.git;a=blob;f=src/components/ogre/EmberEntityModelAction.cpp;h=478dba96015df59e5d9f44e948d7ac0e7a8249eb;hb=4b4d3c6d1137b87c2678c261880d94699040ce54) . Once the model mapping has been initialized it will listen to any changes to the entity's data and activate and deactivate the corresponding actions automatically as the data is changed.
In the case of the icon rendering I've simplified everything so I only perform the first step of creating the model mapping, and then never initializing it. It's then assumed that the first display-model action that is created is the Model that we want to show in the icon.
In this case I think it's however best to implement a full creation and initalization so that changes to the data reflects in changes to the appearance of the entity preview. That means that you will need to create your own instances of Model::Mapping::Actions::Action, pretty much exactly as the current EmberEntityPartAction and EmberEntityModelAction, but instead of calling EmberPhysicalEntity they should call methods on the object you use to handle the preview.

sincerely Erik


________________________________________
Fr?n: Alexey Torkhov [atorkhov at gmail.com]
Skickat: den 17 juli 2008 19:11
Till: Erik Hjortsberg
Kopia: Kai Blin; general at worldforge.org
?mne: Re: Creating imaginary entity

Hi, good to hear you.

I've made some steps: attached Model to SceneNode and updating SceneNode
position each frame. Code is reused from IconManager - it works for me
as my Eris in compiled in non-debug mode.

But I didn't find how to create Eris::Entity from Atlas data and how to
feed it to ModelMapping framework to get Model. Any clues?

Alex.

Erik Hjortsberg wrote:
> Hi, sorry I haven't answered before; I've been visiting relatives and
> haven't had access to Internet nor time off.
>
> I saw your commit where you added your own IInputAdapter; that's
> exactly the way to do it.
>
> However, we probably want to attach a preview mesh to the mesh as you
> say. The way Ember decides on what mesh to use is through the
> ModelMapping framework. The framework basically accepts an instance
> of Eris::Entity and then applies the rules to it, looking at its
> attributes, and from that determines what Model to show and which
> parts to show or hide.
>
> So if we want to show a preview of the model to be created we should
> basically just create a temporary Eris::Entity from our atlas data
> and feed that to the ModelMapping framework, get a Model in return
> and then delete our Eris::Entity. Then we'll attach our Model to an
> Ogre::SceneNode which we position in the world. We'll use an
> Ogre::FrameListener to update the position of our SceneNode to fit
> with the mouse position each frame. The best example of the latter is
> the EntityMoveAdapterWorkerTerrainCursor as found here:
> http://git.worldforge.org/?p=alex/ember.git;a=commitdiff;h=76ede1c4f959b1386d15e67b0fcfcedbe930efeb;hp=ca5ae26910b58c1e85e021102a829cd743fdb55d
>
>
> And an example of how to use a temporary Eris::Entity to get a Model
> from the ModelMapping framework can be found in
> IconManager::getIcon(int pixelWidth, Eris::TypeInfo* erisType), here:
> http://git.worldforge.org/?p=alex/ember.git;a=blob;f=src/components/ogre/widgets/icons/IconManager.cpp;h=7e6c1ca1ab6114a2686b212b8df407bd8498ceae;hb=76ede1c4f959b1386d15e67b0fcfcedbe930efeb
>  IconActionCreator is a very simplified implementation of
> IActionCreator which only records the first model that the mapping
> framework happens upon. EmberPhysicalEntity uses the more complex and
> complete EmberEntityActionCreator which also creates and sets up
> correct actions etc..
>
> However, the code in IconManager::getIcon does not currently work, at
> least not in debug mode. The reason for this is that when an
> Eris::Entity is deleted, in the shutdown() method, it will call
> Eris::View::entityDeleted(Entity* ent). This method will then assert
> that the Entity in question really was in the global map of entities
> (i.e. those received from the server). Since we created our entity
> ourselves it has never been added to the global list in Eris::View
> and the assert will fail.
>
> This is a really unfortunate assert which effectively prevents us to
> create any instance of Eris::Entity which aren't part of the world
> (i.e. created through Eris::View::createEntity(...)). We should see
> if we can alter Eris so that the assert is removed, allowing us to
> more easily created temporary entities. However, when I look through
> the code now I see that Eris::Entity::shutdown() is virtual. One
> solution to this problem would be to create a subclass of
> Eris::Entity, say DetachedEntity, in which you override the shutdown
> method, providing the same functionality as in the original method,
> but without the call to Eris::View::entityDeleted.
>
> sincerely Erik
>
> ________________________________________
> Fr?n: Alexey Torkhov [atorkhov at gmail.com]
> Skickat: den 14 juli 2008 17:07
> Till: Erik Hjortsberg
> Kopia: Kai Blin
> ?mne: Creating imaginary entity
>
> Hi.
>
> Erik, when you?ll settle down and have time, please answer on
> question how to put some imaginary (that is not on server) entity in
> the world. Do I have to create instance of EmberPhysicalEntity and
> register it?
>
> Also, how to put it into moving mode since creating.
>
> I'm now for 4 weeks is not available on IRC - GPRS latency is too
> bad.
>
> Alex.
>



From alriddoch at googlemail.com  Thu Jul 17 22:55:01 2008
From: alriddoch at googlemail.com (Alistair Riddoch)
Date: Fri, 18 Jul 2008 06:55:01 +0100
Subject: [WF-General] Property classes
In-Reply-To: <53da8f280807172157j33076080p2b2652f59c14270a@mail.gmail.com>
References: <53da8f280807171919m6c0fbe0btc2ecd39aa10624ca@mail.gmail.com>
	<4b05edd10807172044k72dc47d5x9a87196ca3a71621@mail.gmail.com>
	<53da8f280807172157j33076080p2b2652f59c14270a@mail.gmail.com>
Message-ID: <4b05edd10807172255t2cb51d45y838318136fe271a9@mail.gmail.com>

The patch isn't viewable on my blackberry for some reason, so I'll
have to review it next week when I get back in front of a computer.
Your approach sounds sane though, so I am confident you are heading in
the right direction.

Al

On 7/18/08, Tamas Bates <rhymer at gmail.com> wrote:
> I found it in CorePropertyManager, but wouldn't have known where to look
> without your advice. I've attached a patch for Cyphesis which has pretty
> much identical functionality to the last one, but fits in with the other
> properties a lot better.
>
> Hopefully I'll have another update before next week with an improved parsing
> function to handle changes to terrain mods better.
>
> -Tamas
>
> On Thu, Jul 17, 2008 at 8:44 PM, Alistair Riddoch <alriddoch at googlemail.com>
> wrote:
>
>> In order to make sure your property class gets used you will need to
>> register it and associate it with a name in the class which I think is
>> called the PropertyManager.
>>
>> If you need to expose some property specific functionality to scripts
>> you will need to create a new wrapper for it, and add support for it
>> to Py_Property.
>>
>> Property and Attribute are different names for the same thing. There
>> is no difference.
>>
>> Sorry if this email is terse or innacurate. I typed it on my phone
>> without access to the source.
>>
>> Best of luck, and ask if you need more.
>>
>> Al
>>
>> On 7/18/08, Tamas Bates <rhymer at gmail.com> wrote:
>> > I think I've figured out how to search for an entity holding a specific
>> > property, but I've run into another problem. It doesn't look like
>> Cyphesis
>> > is using the TerrainModProperty class I created. Do I need to create a
>> > python wrapper for the class, then modify Py_Property.cpp to check for
>> > terrain mods, as is done for the terrain property? Also, how does
>> Cyphesis
>> > know whether something is a property or an attribute of an element? It
>> looks
>> > like they're both set in the same way in define_world.py.
>> >
>> > Thanks for your help, and I hope you got to bed sooner, tonight.
>> >
>> > -Tamas
>> >
>>
>> --
>> Sent from my mobile device
>>
>> Alistair Riddoch
>> alriddoch at googlemail.com
>> http://alistairriddoch.org/
>>
>

-- 
Sent from my mobile device

Alistair Riddoch
alriddoch at googlemail.com
http://alistairriddoch.org/

From zakalawe at mac.com  Fri Jul 18 03:10:41 2008
From: zakalawe at mac.com (James Turner)
Date: Fri, 18 Jul 2008 11:10:41 +0100
Subject: [WF-General] Creating imaginary entity
In-Reply-To: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84A8E@brun.iteam.local>
References: <487B6BB8.7070006@gmail.com>
	<93BE8A5F0814E64D8CEDC34CA57B764A014EC84A8B@brun.iteam.local>
	<487F7D38.5010509@gmail.com>
	<93BE8A5F0814E64D8CEDC34CA57B764A014EC84A8E@brun.iteam.local>
Message-ID: <28258B7A-32D5-4829-A406-D479D6871717@mac.com>


On 17 Jul 2008, at 21:05, Erik Hjortsberg wrote:

> normally after the Entity instance has been created it is populated  
> by a call to Eris::Entity::init(...). This is a protected method,  
> called by the Eris::View (since it's a friend class). The init  
> method in turn calls the sight(...) method which then calls the  
> setContentsFromAtlas(...) method, which handles the child entities  
> of the Entity, and then setFromRoot(...) which sets the attributes  
> of the entity from the atlas data. It does this by iteration over  
> the data in the supplied Atlas::Objects::RootData instance and then  
> calling setAttr(...) for each attribute.
> I think the best way to proceed here is to use a subclass of  
> Eris::Entity, say DetachedEntity, which exposes a public method  
> which in turn calls setFromRoot. I think we can skip calling  
> setContentsFromAtlas for now. If we don't want to fiddle with  
> wrapping our MapType within a Atlas::Objects::RootData class we can  
> instead just remiplement the functionality in Entity::Sight (i.e.  
> calling setAttr(...) for each attribute).

</lurk>

Should work - it's not an intended use case in the current code, but  
equally it's something that was discussed. Updating Eris to support  
either local entities outside the view map, or something along those  
lines, should be pretty trivial. I'd be happy with someone creating an  
Eris::LocalEntity or Eris::ClientSideEntity. Main thing would be to  
ensure the entity is always visible by disabling most (all?)  
interaction with the view - you'd still like to be able to parent such  
entities to normal entities though, as well as having the option for  
them to be parentless.

James

<lurk>

From erik.hjortsberg at iteam.se  Sat Jul 19 02:04:28 2008
From: erik.hjortsberg at iteam.se (Erik Hjortsberg)
Date: Sat, 19 Jul 2008 11:04:28 +0200
Subject: [WF-General] Finding an entity's position in Ember
In-Reply-To: <53da8f280807181107g2c9fea6bx53bbd045bcb1d7d5@mail.gmail.com>
References: <53da8f280807181107g2c9fea6bx53bbd045bcb1d7d5@mail.gmail.com>
Message-ID: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84A8F@brun.iteam.local>

Hi, you should use the Eris::Entity::getPosition method instead (since EmberEntity is a subclass of Eris::Entity).

The scene node is positioned later on in the entity creation process.

/erik
________________________________________
Fr?n: Tamas Bates [rhymer at gmail.com]
Skickat: den 18 juli 2008 20:07
Till: Erik Hjortsberg; Kai Blin
?mne: Finding an entity's position in Ember

I'm working on improving the parsing script so that terrain mods can be changed after they've been applied to the terrain. The first change I made was to make their position match the position of the entity they're applied to. I'm using getSceneNode()->getPosition() to find the entity's position, but the first time this gets called (which is when the entity is created) getPosition() returns (0,0,0). If I make the call later I get the correct position.

Is there a better way to retrieve an entity's position?

-Tamas

From kai.blin at gmail.com  Sat Jul 19 06:54:56 2008
From: kai.blin at gmail.com (Kai Blin)
Date: Sat, 19 Jul 2008 15:54:56 +0200
Subject: [WF-General] Sear changes for GuiChan 0.8,1
Message-ID: <200807191555.06114.kai.blin@gmail.com>

Hi Simon,

Bj?rn Lindeijer from the "The Mana World" project provided some patches to 
allow Sear to use GuiChan 0.8.1 instead of the older version Sear currently 
uses, so distros like Debian/Ubuntu can update their GuiChan packages.

See https://bugs.launchpad.net/sear/+bug/250063

I can push those patches to cvs once I tried them, but probably getting 
distros to pick up the changes will be easier if we get a new release of Sear 
out. This means some additional changes as well, I take.

I'd be happy to offer a hand with those, but I don't know my way around Sear, 
so I'll need some guidance.

Cheers,
Kai
-- 
Kai Blin
WorldForge developer  http://www.worldforge.org/
Wine developer        http://wiki.winehq.org/KaiBlin
Samba team member     http://www.samba.org/samba/team/
--
Will code for cotton.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.worldforge.org/pipermail/general/attachments/20080719/0443e89f/attachment.bin 

From alriddoch at googlemail.com  Sat Jul 19 08:08:12 2008
From: alriddoch at googlemail.com (Alistair Riddoch)
Date: Sat, 19 Jul 2008 17:08:12 +0200
Subject: [WF-General] Sear changes for GuiChan 0.8,1
In-Reply-To: <200807191555.06114.kai.blin@gmail.com>
References: <200807191555.06114.kai.blin@gmail.com>
Message-ID: <4b05edd10807190808l7065a670j7f8c71ebfe1c77f4@mail.gmail.com>

I did much of the original guichan work in sear, so if Simon approves
I would be the best person to apply and test the patch. I'll take a
look once I am back in Ireland Tuesday.

Al

On 7/19/08, Kai Blin <kai.blin at gmail.com> wrote:
> Hi Simon,
>
> Bj?rn Lindeijer from the "The Mana World" project provided some patches to
> allow Sear to use GuiChan 0.8.1 instead of the older version Sear currently
> uses, so distros like Debian/Ubuntu can update their GuiChan packages.
>
> See https://bugs.launchpad.net/sear/+bug/250063
>
> I can push those patches to cvs once I tried them, but probably getting
> distros to pick up the changes will be easier if we get a new release of
> Sear
> out. This means some additional changes as well, I take.
>
> I'd be happy to offer a hand with those, but I don't know my way around
> Sear,
> so I'll need some guidance.
>
> Cheers,
> Kai
> --
> Kai Blin
> WorldForge developer  http://www.worldforge.org/
> Wine developer        http://wiki.winehq.org/KaiBlin
> Samba team member     http://www.samba.org/samba/team/
> --
> Will code for cotton.
>

-- 
Sent from my mobile device

Alistair Riddoch
alriddoch at googlemail.com
http://alistairriddoch.org/

From kai.blin at gmail.com  Sat Jul 19 08:22:29 2008
From: kai.blin at gmail.com (Kai Blin)
Date: Sat, 19 Jul 2008 17:22:29 +0200
Subject: [WF-General] Sear changes for GuiChan 0.8,1
In-Reply-To: <4b05edd10807190808l7065a670j7f8c71ebfe1c77f4@mail.gmail.com>
References: <200807191555.06114.kai.blin@gmail.com>
	<4b05edd10807190808l7065a670j7f8c71ebfe1c77f4@mail.gmail.com>
Message-ID: <200807191722.32609.kai.blin@gmail.com>

On Saturday 19 July 2008 17:08:12 Alistair Riddoch wrote:
> I did much of the original guichan work in sear, so if Simon approves
> I would be the best person to apply and test the patch. I'll take a
> look once I am back in Ireland Tuesday.

Sure. I forgot about you being the person driving the guichan work on Sear. 
The patches are attached to the bug report.

I don't even have a dev environment for Sear set up currently, so I don't mind 
you doing all the work at all ;)

Cheers,
Kai

-- 
Kai Blin
WorldForge developer  http://www.worldforge.org/
Wine developer        http://wiki.winehq.org/KaiBlin
Samba team member     http://www.samba.org/samba/team/
--
Will code for cotton.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.worldforge.org/pipermail/general/attachments/20080719/3dd791c0/attachment-0001.bin 

From kai.blin at gmail.com  Sat Jul 19 08:22:29 2008
From: kai.blin at gmail.com (Kai Blin)
Date: Sat, 19 Jul 2008 17:22:29 +0200
Subject: [WF-General] Sear changes for GuiChan 0.8,1
In-Reply-To: <4b05edd10807190808l7065a670j7f8c71ebfe1c77f4@mail.gmail.com>
References: <200807191555.06114.kai.blin@gmail.com>
	<4b05edd10807190808l7065a670j7f8c71ebfe1c77f4@mail.gmail.com>
Message-ID: <200807191722.32609.kai.blin@gmail.com>

On Saturday 19 July 2008 17:08:12 Alistair Riddoch wrote:
> I did much of the original guichan work in sear, so if Simon approves
> I would be the best person to apply and test the patch. I'll take a
> look once I am back in Ireland Tuesday.

Sure. I forgot about you being the person driving the guichan work on Sear. 
The patches are attached to the bug report.

I don't even have a dev environment for Sear set up currently, so I don't mind 
you doing all the work at all ;)

Cheers,
Kai

-- 
Kai Blin
WorldForge developer  http://www.worldforge.org/
Wine developer        http://wiki.winehq.org/KaiBlin
Samba team member     http://www.samba.org/samba/team/
--
Will code for cotton.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.worldforge.org/pipermail/general/attachments/20080719/3dd791c0/attachment-0002.bin 

From rhymer at gmail.com  Sun Jul 20 22:26:50 2008
From: rhymer at gmail.com (Tamas Bates)
Date: Sun, 20 Jul 2008 22:26:50 -0700
Subject: [WF-General] TerrainMods Weekly Update 9
Message-ID: <53da8f280807202226h502d27eaw50154418f9b114be@mail.gmail.com>

Last week I worked to allow terrain modifiers to be applied to any entity in
the game, and to improve the parsing of modifiers so that they can be
altered after being applied.

 The first goal is now solved, and terrain modifiers now use their parent
entity's position for the location they are applied to. In Ember this
required moving the parsing code from WorldEmberEntity to EmberEntity, and a
couple of changes to the calls made to apply the mods to the terrain. In
Cyphesis I created a new property class, TerrainModProperty, to hold and
process the Atlas data for a modifier, instead of doing so in
TerrainProperty.

 The second goal isn't entirely done, yet. Currently all attributes of a
modifier (including position, now!) are updated correctly on both the client
and the server when you change them in the entity editor, however there are
two things missing. First, when a modifier is changed, all of the
modifications to the segment it is applied to are removed so that multiple
changes don't stack up. Unfortunately, the function that handles this
doesn't currently check for other modifiers applied to the same segment, so
we're currently limited to one modifier per segment. The second issue is
modifiers that overlap multiple segments. The function handling the updates
also doesn't check the size of a modifier, so if it overlaps multiple
segments only the one it was originally applied to is refreshed correctly.
Another, smaller issue that remains is that the first time Cyphesis tries to
get a modifier's position (when the entity holding it is created) it finds
uninitialized values and applies the modifier to the origin, instead of the
correct location. Any other time it checks the position works fine, though.
I'm sure this'll get straightened out next week.

 Next week I'd like to focus on resolving the issues above. I think the
solution for Cyphesis will be a bit different that the one for Ember. In
Cyphesis we can probably search the entity tree for terrain modifiers
applied to the affected segment(s) in order to ensure that all the modifiers
that need to be reapplied are. Ember already tracks which modifiers are
applied to each TerrainPage, and I imagine we can search that list for
modifiers that need to be reapplied. It looks like WFMath already includes
most of the functions that will be needed to handle modifiers that affect
multiple segments, so hopefully it won't be too much trouble to implement
that as well. I'll also make sure that deleting modifiers gets handled
properly.

I've attached a patch containing my changes to Cyphesis so far, and will
send another once these features are more complete.

Also, I'll be out of town on Tuesday, but will return Wednesday morning and
should be able to make up the lost time next weekend.

-Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.worldforge.org/pipermail/general/attachments/20080720/c07f8967/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cyph_terrainmods.patch
Type: text/x-patch
Size: 7792 bytes
Desc: not available
Url : http://mail.worldforge.org/pipermail/general/attachments/20080720/c07f8967/attachment.bin 

From atorkhov at gmail.com  Mon Jul 21 05:53:59 2008
From: atorkhov at gmail.com (Alexey Torkhov)
Date: Mon, 21 Jul 2008 16:53:59 +0400
Subject: [WF-General] Entity creator weekly GSoC report
Message-ID: <488486E7.6090104@gmail.com>

Hi.

On last week I?ve made terrain positioning of new entities. It allows to 
see position where entity will be created. But the preview mesh isn?t 
the same as entity that will be created.

This is the goal for next week?make preview fully represent new entity. 
To achieve this, I need to implement Erik?s plan on DetachedEntity class 
and feeding it to model mapping framework. This is partially done but 
not commited yet.

Also, user interface should be improved?it should stay in ?create? mode 
after creating first entity and allow create fast as many more entities 
as user wants. Also minor things like changing orientation on mouse 
scroll should be made.

Alex.

From atorkhov at gmail.com  Tue Jul 22 09:55:08 2008
From: atorkhov at gmail.com (Alexey Torkhov)
Date: Tue, 22 Jul 2008 20:55:08 +0400
Subject: [WF-General] Creating imaginary entity
In-Reply-To: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84A8E@brun.iteam.local>
References: <487B6BB8.7070006@gmail.com>
	<93BE8A5F0814E64D8CEDC34CA57B764A014EC84A8B@brun.iteam.local>,
	<487F7D38.5010509@gmail.com>
	<93BE8A5F0814E64D8CEDC34CA57B764A014EC84A8E@brun.iteam.local>
Message-ID: <488610EC.7070905@gmail.com>

Hi Erik.

I've done many things from this plan. However, I've find that all code
that works with model mapping (like own instances of
Model::Mapping::Actions::Action) are too much repeat EmberEntity and
EmberPhysiclaEntity.

So, I'm thinking, could we reuse EmberPhysicalEntity instead of working
myself with models, mappings, etc. One problem that I see here is that
we need to have functionality of DetachedEntity there - public method
that sets attributes from atlas. But we can make DetachedEntity subclass
of EmberPhysicalEntity and have that method. What do you think.

Alex.

Erik Hjortsberg wrote:
> Hi,
> 
> normally after the Entity instance has been created it is populated
> by a call to Eris::Entity::init(...). This is a protected method,
> called by the Eris::View (since it's a friend class). The init method
> in turn calls the sight(...) method which then calls the
> setContentsFromAtlas(...) method, which handles the child entities of
> the Entity, and then setFromRoot(...) which sets the attributes of
> the entity from the atlas data. It does this by iteration over the
> data in the supplied Atlas::Objects::RootData instance and then
> calling setAttr(...) for each attribute.
> I think the best way to proceed here is to use a subclass of
> Eris::Entity, say DetachedEntity, which exposes a public method which
> in turn calls setFromRoot. I think we can skip calling
> setContentsFromAtlas for now. If we don't want to fiddle with
> wrapping our MapType within a Atlas::Objects::RootData class we can
> instead just remiplement the functionality in Entity::Sight (i.e.
> calling setAttr(...) for each attribute).
> 
> If all of this however proves to be too clunky (if perhaps there's
> functionality within Eris::Entity which too heavily relies on the
> entity being instantiated from real atlas data and correctly added to
> the View) we could look at providing abstractions within the
> ModelMapping framework, to make it not so tightly bound to the
> Eris::Entity class, but I think that should be the last resort.
> 
> Once you have the Entity you then need to interface with the
> ModelMapping framework to get useful data about the models to use
> etc..
> The process works like this:
> You first create a ModelMapping instance like this:
> modelMapping =
> ::EmberOgre::Model::Mapping::EmberModelMappingManager::getSingleton().getManager().createMapping(entityPtr,
> creator);
> where "creator" is a pointer to an instance of a class which
> implements Model::Mapping::IActionCreator. The creator object won't
> be held by the mapping, so it should really be a reference instead.
> The model mapping framework will take care of creating the "matches"
> and "cases" which make up the mapping for the entity type of the
> supplied entity, but will delegate the creation of the "actions" to
> the supplied creator. The most common actions are "display-model"
> (which will show a Model) and "display-part" (which will show a
> specified part within a Model). See
> http://git.worldforge.org/?p=alex/ember.git;a=blob;f=src/components/ogre/EmberEntityActionCreator.cpp;h=83c75a55e81c71f955d4470b045631960fe89b6b;hb=4b4d3c6d1137b87c2678c261880d94699040ce54
> for how it's done for the EmberPhysicalEntity. Note that at this
> stage the actions are only created, they aren't activated yet.
> 
> Once the model mapping has been created it's activated by calling
> ModelMapping::initialize(). This will make the model mapping
> framework evaluate the data in the entity; mainly its type and it's
> attributes, and then activating the correct "actions". In the case of
> the EmberPhysiclaEntity it might mean that an instance of
> EmberEntityModelAction is activated, which in turn will call
> EmberPhysicalEntity::setModel(...) (see
> http://git.worldforge.org/?p=alex/ember.git;a=blob;f=src/components/ogre/EmberEntityModelAction.cpp;h=478dba96015df59e5d9f44e948d7ac0e7a8249eb;hb=4b4d3c6d1137b87c2678c261880d94699040ce54)
> . Once the model mapping has been initialized it will listen to any
> changes to the entity's data and activate and deactivate the
> corresponding actions automatically as the data is changed.
> In the case of the icon rendering I've simplified everything so I
> only perform the first step of creating the model mapping, and then
> never initializing it. It's then assumed that the first display-model
> action that is created is the Model that we want to show in the icon.
>  In this case I think it's however best to implement a full creation
> and initalization so that changes to the data reflects in changes to
> the appearance of the entity preview. That means that you will need
> to create your own instances of Model::Mapping::Actions::Action,
> pretty much exactly as the current EmberEntityPartAction and
> EmberEntityModelAction, but instead of calling EmberPhysicalEntity
> they should call methods on the object you use to handle the preview. >
> sincerely Erik
> 
> 
> ________________________________________
> Fr?n: Alexey Torkhov [atorkhov at gmail.com]
> Skickat: den 17 juli 2008 19:11
> Till: Erik Hjortsberg
> Kopia: Kai Blin; general at worldforge.org
> ?mne: Re: Creating imaginary entity
> 
> Hi, good to hear you.
> 
> I've made some steps: attached Model to SceneNode and updating SceneNode
> position each frame. Code is reused from IconManager - it works for me
> as my Eris in compiled in non-debug mode.
> 
> But I didn't find how to create Eris::Entity from Atlas data and how to
> feed it to ModelMapping framework to get Model. Any clues?
> 
> Alex.



From atorkhov at gmail.com  Tue Jul 22 10:03:59 2008
From: atorkhov at gmail.com (Alexey Torkhov)
Date: Tue, 22 Jul 2008 21:03:59 +0400
Subject: [WF-General] Stale Ember CVS tree
Message-ID: <488612FF.8040403@gmail.com>

Hi Kai.

Current Ember CVS tree is not updated for long time.

As I remember, you wanted to export Ember Git tree back to CVS. I find
'git-cvsexportcommit' command that is part of git-cvs package. Could you
look into using it for this task? It could be some commit hook to may be
cron task that gets list of latest commits with 'git-rev-list' and
exported each of them.

Alex.




From erik.hjortsberg at iteam.se  Tue Jul 22 13:31:40 2008
From: erik.hjortsberg at iteam.se (Erik Hjortsberg)
Date: Tue, 22 Jul 2008 22:31:40 +0200
Subject: [WF-General] Creating imaginary entity
In-Reply-To: <488610EC.7070905@gmail.com>
References: <487B6BB8.7070006@gmail.com>
	<93BE8A5F0814E64D8CEDC34CA57B764A014EC84A8B@brun.iteam.local>,
	<487F7D38.5010509@gmail.com>
	<93BE8A5F0814E64D8CEDC34CA57B764A014EC84A8E@brun.iteam.local>,
	<488610EC.7070905@gmail.com>
Message-ID: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84A9C@brun.iteam.local>

Hi,

yeah, there's some duplication, but I don't really want to see us extending EmberPhysicalEntity. It's quite a fat class, and the plan in the long run is to instead remove it, using only EmberEntity and a more component based approach. With a more component based approach the handling of the graphical representation should be offloaded to a class responsible for that only. Such a class should then be reusable by other classes also, such as the DetachedEntity in this case.
You're right that it means some extra classes which seem a little redundant. I was thinking of using interfaces that the EmberEntityPartAction and EmberEntityModelAction understand (with just show* and hide* methods). These interfaces should then be implemented by both EmberPhysicalEntity as well as DetachedEntity.
However, I see that some of the stuff in EmberPhysicalEntity, such as the logic for how to scale the model, should be useful here too. In the component based approach that kind of functionality should be easily accessable, but for now perhaps you could give it a try using the EmberPhysicalEntity as base class for DetachedEntity. Try it out and see how it works. If there's no problem we can go with that for now (EmberEntity also has onBboxChanged() which is called whenever the bounding box is updated; that's useful here too).

I've looked at the code you've committed and it looks good.

/erik

________________________________________
Fr?n: Alexey Torkhov [atorkhov at gmail.com]
Skickat: den 22 juli 2008 18:55
Till: Erik Hjortsberg
Kopia: Kai Blin; general at worldforge.org
?mne: Re: SV: Creating imaginary entity

Hi Erik.

I've done many things from this plan. However, I've find that all code
that works with model mapping (like own instances of
Model::Mapping::Actions::Action) are too much repeat EmberEntity and
EmberPhysiclaEntity.

So, I'm thinking, could we reuse EmberPhysicalEntity instead of working
myself with models, mappings, etc. One problem that I see here is that
we need to have functionality of DetachedEntity there - public method
that sets attributes from atlas. But we can make DetachedEntity subclass
of EmberPhysicalEntity and have that method. What do you think.

Alex.

Erik Hjortsberg wrote:
> Hi,
>
> normally after the Entity instance has been created it is populated
> by a call to Eris::Entity::init(...). This is a protected method,
> called by the Eris::View (since it's a friend class). The init method
> in turn calls the sight(...) method which then calls the
> setContentsFromAtlas(...) method, which handles the child entities of
> the Entity, and then setFromRoot(...) which sets the attributes of
> the entity from the atlas data. It does this by iteration over the
> data in the supplied Atlas::Objects::RootData instance and then
> calling setAttr(...) for each attribute.
> I think the best way to proceed here is to use a subclass of
> Eris::Entity, say DetachedEntity, which exposes a public method which
> in turn calls setFromRoot. I think we can skip calling
> setContentsFromAtlas for now. If we don't want to fiddle with
> wrapping our MapType within a Atlas::Objects::RootData class we can
> instead just remiplement the functionality in Entity::Sight (i.e.
> calling setAttr(...) for each attribute).
>
> If all of this however proves to be too clunky (if perhaps there's
> functionality within Eris::Entity which too heavily relies on the
> entity being instantiated from real atlas data and correctly added to
> the View) we could look at providing abstractions within the
> ModelMapping framework, to make it not so tightly bound to the
> Eris::Entity class, but I think that should be the last resort.
>
> Once you have the Entity you then need to interface with the
> ModelMapping framework to get useful data about the models to use
> etc..
> The process works like this:
> You first create a ModelMapping instance like this:
> modelMapping =
> ::EmberOgre::Model::Mapping::EmberModelMappingManager::getSingleton().getManager().createMapping(entityPtr,
> creator);
> where "creator" is a pointer to an instance of a class which
> implements Model::Mapping::IActionCreator. The creator object won't
> be held by the mapping, so it should really be a reference instead.
> The model mapping framework will take care of creating the "matches"
> and "cases" which make up the mapping for the entity type of the
> supplied entity, but will delegate the creation of the "actions" to
> the supplied creator. The most common actions are "display-model"
> (which will show a Model) and "display-part" (which will show a
> specified part within a Model). See
> http://git.worldforge.org/?p=alex/ember.git;a=blob;f=src/components/ogre/EmberEntityActionCreator.cpp;h=83c75a55e81c71f955d4470b045631960fe89b6b;hb=4b4d3c6d1137b87c2678c261880d94699040ce54
> for how it's done for the EmberPhysicalEntity. Note that at this
> stage the actions are only created, they aren't activated yet.
>
> Once the model mapping has been created it's activated by calling
> ModelMapping::initialize(). This will make the model mapping
> framework evaluate the data in the entity; mainly its type and it's
> attributes, and then activating the correct "actions". In the case of
> the EmberPhysiclaEntity it might mean that an instance of
> EmberEntityModelAction is activated, which in turn will call
> EmberPhysicalEntity::setModel(...) (see
> http://git.worldforge.org/?p=alex/ember.git;a=blob;f=src/components/ogre/EmberEntityModelAction.cpp;h=478dba96015df59e5d9f44e948d7ac0e7a8249eb;hb=4b4d3c6d1137b87c2678c261880d94699040ce54)
> . Once the model mapping has been initialized it will listen to any
> changes to the entity's data and activate and deactivate the
> corresponding actions automatically as the data is changed.
> In the case of the icon rendering I've simplified everything so I
> only perform the first step of creating the model mapping, and then
> never initializing it. It's then assumed that the first display-model
> action that is created is the Model that we want to show in the icon.
>  In this case I think it's however best to implement a full creation
> and initalization so that changes to the data reflects in changes to
> the appearance of the entity preview. That means that you will need
> to create your own instances of Model::Mapping::Actions::Action,
> pretty much exactly as the current EmberEntityPartAction and
> EmberEntityModelAction, but instead of calling EmberPhysicalEntity
> they should call methods on the object you use to handle the preview. >
> sincerely Erik
>
>
> ________________________________________
> Fr?n: Alexey Torkhov [atorkhov at gmail.com]
> Skickat: den 17 juli 2008 19:11
> Till: Erik Hjortsberg
> Kopia: Kai Blin; general at worldforge.org
> ?mne: Re: Creating imaginary entity
>
> Hi, good to hear you.
>
> I've made some steps: attached Model to SceneNode and updating SceneNode
> position each frame. Code is reused from IconManager - it works for me
> as my Eris in compiled in non-debug mode.
>
> But I didn't find how to create Eris::Entity from Atlas data and how to
> feed it to ModelMapping framework to get Model. Any clues?
>
> Alex.



From abra185 at gmail.com  Tue Jul 22 19:52:56 2008
From: abra185 at gmail.com (nightz)
Date: Tue, 22 Jul 2008 23:52:56 -0300
Subject: [WF-General] Weekly Reports
Message-ID: <1216781576.9459.2.camel@omega>

Hi all ember's and members ;) A bit late but its here....Last week i had
a major issue with std::map and i still havent discovered what the bug
is, problem was when i called std::map<std::string,
SoundAction*>::iterator it(mEntities.find(name)); it crashed (segfault)
on mEntities.find() method and i couldnt discover why, so i lost alot of
time getting around that, as Erik told me, i should have mailed him, my
bad =/ I also implemented the SoundEntityManager, the SoundActions and
SoundEntity fully but Erik told me today to drop the SoundActions and
handle stuff on the Modelmap part. I agree with him and started doing
this today. Hopefully that will be pretty fast and i will finally get
sounds ingame.

Sincerely,
R?mulo Fernandes.


From rhymer at gmail.com  Sun Jul 27 22:13:20 2008
From: rhymer at gmail.com (Tamas Bates)
Date: Sun, 27 Jul 2008 22:13:20 -0700
Subject: [WF-General] TerrainMods Weekly Update 10
Message-ID: <53da8f280807272213y31d68532v5f047684e96d7b5@mail.gmail.com>

Last week I worked to improve the behavior of terrain modifiers after
they've been applied to the terrain. My little trip out of town on Tuesday
set me back farther than I thought it would, partly because some of the
features I was working on took longer than I thought they would (mostly due
to some assumptions I made in the TerrainPage code a few weeks ago). In any
case, making changes to an applied modifier in the Entity Editor now works
correctly. When a change is made to an entity holding a modifier, it clears
all of the mods from the segment the entity is located in then applies the
new settings and then reapplies any other modifiers that were applied to the
same segment. If you move the entity holding a modifier, however, a new one
is created, rather than moving the old one (which should be fixed). I had
some trouble handling multiple segments, but I believe that this can be
handled by using the altered modifier's bounding box, and checking to see
which segments it overlaps. Any segments overlapped by the mod's bounding
box will have their mods cleared and reapplied before the altered mod is
reapplied, which should ensure that its affect on adjacent segments isn't
accidentally cleared.

Despite last week's delays, I believe I'm still on schedule (whew!). Next
week I'll finish up the work required to update multiple segments when a
modifier is changed. I'll also work on getting the modifiers to update
correctly when the entity holding them moves (again it looks like the way
TerrainAreas are handled will serve as a good model to follow).

I will NOT be going out of town this week ;)

-Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.worldforge.org/pipermail/general/attachments/20080727/55d436f6/attachment.html 

From atorkhov at gmail.com  Mon Jul 28 05:07:46 2008
From: atorkhov at gmail.com (Alexey Torkhov)
Date: Mon, 28 Jul 2008 16:07:46 +0400
Subject: [WF-General] Entity creator weekly GSoC report
Message-ID: <488DB692.1090008@gmail.com>

Hi.

I?ve started to work with model mapping framework on last week. It 
required to reimplement or copy a bunch of methods from 
EmberPhysicalEntity and satellite classes. It didn?t satify me well and 
I made an attempt to reuse EmberPhysicalEntity directly but it wasn?t 
very successful. I?m thinking that it in some places assumes entity 
properly belong to entity hierarchy. Making it to support detached 
entity seems to require some changes there. So I decided to drop this 
attempt and continue to work with model mapping directly to render 
preview mesh correctly. And that?s what I?m going to do for next week.

Alex.


From erik.hjortsberg at iteam.se  Mon Jul 28 10:29:46 2008
From: erik.hjortsberg at iteam.se (Erik Hjortsberg)
Date: Mon, 28 Jul 2008 19:29:46 +0200
Subject: [WF-General] Entity creator weekly GSoC report
In-Reply-To: <488DB692.1090008@gmail.com>
References: <488DB692.1090008@gmail.com>
Message-ID: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84AA5@brun.iteam.local>

What happened when you tried to subclass EmberPhysicalEntity?

/erik
________________________________________
Fr?n: Alexey Torkhov [atorkhov at gmail.com]
Skickat: den 28 juli 2008 14:07
Till: Erik Hjortsberg
Kopia: Kai Blin; general at worldforge.org
?mne: Entity creator weekly GSoC report

Hi.

I?ve started to work with model mapping framework on last week. It
required to reimplement or copy a bunch of methods from
EmberPhysicalEntity and satellite classes. It didn?t satify me well and
I made an attempt to reuse EmberPhysicalEntity directly but it wasn?t
very successful. I?m thinking that it in some places assumes entity
properly belong to entity hierarchy. Making it to support detached
entity seems to require some changes there. So I decided to drop this
attempt and continue to work with model mapping directly to render
preview mesh correctly. And that?s what I?m going to do for next week.

Alex.


From atorkhov at gmail.com  Mon Jul 28 11:16:27 2008
From: atorkhov at gmail.com (Alexey Torkhov)
Date: Mon, 28 Jul 2008 22:16:27 +0400
Subject: [WF-General] Orientation of entities in Ember
Message-ID: <488E0CFB.4090901@gmail.com>

Hi.

I've just committed a code that makes orientation of preview the same as 
entity that is created:

mEntityNode->setOrientation(Atlas2Ogre(mOrientation));
mEntityNode->rotate(Ogre::Vector3::UNIT_Y,(Ogre::Degree)90);

As you see, in addition to converting orientation from Atlas to Ogre I 
had to rotate an entity 90? around Y (up) axis as 
EmberPhysicalEntity::initFromModel() does.
It is written that it is "rotate node to fit with WF space" but this 
rotation is not conversion from Ogre to Atlas, nor vice versa.

Is this a bug? And all entities rotated in Ember? Or this is compensated 
somehow else?

Alex.


From atorkhov at gmail.com  Mon Jul 28 11:25:03 2008
From: atorkhov at gmail.com (Alexey Torkhov)
Date: Mon, 28 Jul 2008 22:25:03 +0400
Subject: [WF-General] Entity creator weekly GSoC report
In-Reply-To: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84AA5@brun.iteam.local>
References: <488DB692.1090008@gmail.com>
	<93BE8A5F0814E64D8CEDC34CA57B764A014EC84AA5@brun.iteam.local>
Message-ID: <488E0EFF.5060003@gmail.com>

Erik Hjortsberg ?????:
> What happened when you tried to subclass EmberPhysicalEntity?
I was unable to show up a node in scene. May be I didn't dig deep enough.

Anyway, I've just made preview work without subclassing it. But, if you 
want, I can make another try with EmberPhysicalEntity.


Also, I didn't write in report what I'm planning to do after preview 
done. So, I have work on improving user interface - it should stay in 
"create" mode after creating first entity. Also, I need to make correct 
deinitialization of various things.

Erik, would be good to hear your thoughts on what should be done - may 
be improvement of current features or code or something else.

Alex.

From erik.hjortsberg at iteam.se  Mon Jul 28 14:33:54 2008
From: erik.hjortsberg at iteam.se (Erik Hjortsberg)
Date: Mon, 28 Jul 2008 23:33:54 +0200
Subject: [WF-General] Orientation of entities in Ember
In-Reply-To: <488E0CFB.4090901@gmail.com>
References: <488E0CFB.4090901@gmail.com>
Message-ID: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84AA6@brun.iteam.local>

Yeah, that's needed because of the conversion between coord systems.
I'm not sure of how to avoid it; perhaps it should be embedded in the Atlas2Ogre(Quaternion) method directly (and subsequently in Ogre2Atlas(Quaternion)) but that might break other functionality which is working now. I honestly avoided touching that code once I got it working; it's too easy to get lost in the conversions between the different coord systems.

Note that every graphical entity (i.e. EmberPhysicalEntity) are composed of two Ogre::SceneNode: one "base" node (which actually belongs to EmberEntity) and then the child "scale" node which belongs to EmberPhysicalEntity. It's only the scale node that's rotated 90 degrees.

/erik
________________________________________
Fr?n: Alexey Torkhov [atorkhov at gmail.com]
Skickat: den 28 juli 2008 20:16
Till: Erik Hjortsberg
Kopia: general at worldforge.org
?mne: Orientation of entities in Ember

Hi.

I've just committed a code that makes orientation of preview the same as
entity that is created:

mEntityNode->setOrientation(Atlas2Ogre(mOrientation));
mEntityNode->rotate(Ogre::Vector3::UNIT_Y,(Ogre::Degree)90);

As you see, in addition to converting orientation from Atlas to Ogre I
had to rotate an entity 90? around Y (up) axis as
EmberPhysicalEntity::initFromModel() does.
It is written that it is "rotate node to fit with WF space" but this
rotation is not conversion from Ogre to Atlas, nor vice versa.

Is this a bug? And all entities rotated in Ember? Or this is compensated
somehow else?

Alex.


From erik.hjortsberg at iteam.se  Mon Jul 28 14:49:01 2008
From: erik.hjortsberg at iteam.se (Erik Hjortsberg)
Date: Mon, 28 Jul 2008 23:49:01 +0200
Subject: [WF-General] Entity creator weekly GSoC report
In-Reply-To: <488E0EFF.5060003@gmail.com>
References: <488DB692.1090008@gmail.com>
	<93BE8A5F0814E64D8CEDC34CA57B764A014EC84AA5@brun.iteam.local>,
	<488E0EFF.5060003@gmail.com>
Message-ID: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84AA7@brun.iteam.local>

I think the current code works ok. There's a bit of duplicate code, but as I said earlier the plan is to redesign the way the classes are composed, so we'll have to live with an interim solution until that.

I would like to see some examples of how to easily implement drop down lists of different attributes. I'm thinking something along

<entityrecipes>
  <entityrecipe name="boulder">
    <entity type="boulder">
      <atlas>
        <map>
          <list name="bbox">$bbox</list>
          <float name="mass">$mass</float>
          <string name="style">$style</string>
        </map>
      </atlas>
    </entity>
    <adapters>
      <adapter name="mass" type="number" title="Mass"/>
      <adapter name="style" type="list" title="Style">
        <item>a</item>
        <item>b</item>
        <item>c</item>
        <item>d</item>
        <item>e</item>
      </adapter>
    </adapters>
    <bindings>
      <bind name="bbox" func="calcSize">
        <adapter name="mass" />
      </bind>
      <bind name="mass">
        <adapter name="mass" />
      </bind>
      <bind name="style">
         <adapter name="style" />
      </bind>
   </bindings>


Now, I'm not sure how much work this would be to add: we're nearing the end of the program so you shouldn't take on something too large. How much work do you think it would take?
The functionality for easily creating many entities through letting the user click away while in "create" mode is also very useful, and could perhaps be lumped with other general UI refinements. Basically just make sure that everything is smooth and intuitive (putting tooltips on all ui elements etc.).

/erik

________________________________________
Fr?n: Alexey Torkhov [atorkhov at gmail.com]
Skickat: den 28 juli 2008 20:25
Till: Erik Hjortsberg
Kopia: Kai Blin; general at worldforge.org
?mne: Re: SV: Entity creator weekly GSoC report

Erik Hjortsberg ?????:
> What happened when you tried to subclass EmberPhysicalEntity?
I was unable to show up a node in scene. May be I didn't dig deep enough.

Anyway, I've just made preview work without subclassing it. But, if you
want, I can make another try with EmberPhysicalEntity.


Also, I didn't write in report what I'm planning to do after preview
done. So, I have work on improving user interface - it should stay in
"create" mode after creating first entity. Also, I need to make correct
deinitialization of various things.

Erik, would be good to hear your thoughts on what should be done - may
be improvement of current features or code or something else.

Alex.

From abra185 at gmail.com  Mon Jul 28 20:43:26 2008
From: abra185 at gmail.com (nightz)
Date: Tue, 29 Jul 2008 00:43:26 -0300
Subject: [WF-General] Weekly Reports
Message-ID: <1217303006.23668.2.camel@omega>

Hi all Worldforgers, how are you? This week i took care to follow Erik
comments about the system and got it a bit more close to where we want
it. I got the ModelMapping knowning about the Sounddefs and
reimplemented SoundActions and SoundGroups. Basically i want to tie an
EmberEntity to a model and a sound entity, the sound entity will be
responsible to handle the entity position and update the sound buffers
within it (for better 3d audio) and the sound groups will just play the
sounds! I am missing now just a way to communicate EmberPhysicalEntity
and the actions parsed from the modeldef, can anyone help me out? Since
Erik is travelling things get a bit harder to go since i have to digg
out alot more on the code but things are still going. On the next week i
plan to finish this integration and have it playing sounds, i cant stand
anymore without them! Thats it.

Sincerely,
Romulo Fernandes.


From atorkhov at gmail.com  Tue Jul 29 07:38:46 2008
From: atorkhov at gmail.com (Alexey Torkhov)
Date: Tue, 29 Jul 2008 18:38:46 +0400
Subject: [WF-General] Entity creator weekly GSoC report
In-Reply-To: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84AA7@brun.iteam.local>
References: <488DB692.1090008@gmail.com>
	<93BE8A5F0814E64D8CEDC34CA57B764A014EC84AA5@brun.iteam.local>
	,<488E0EFF.5060003@gmail.com>
	<93BE8A5F0814E64D8CEDC34CA57B764A014EC84AA7@brun.iteam.local>
Message-ID: <1217342326.4097.21.camel@nat.tortilla.ru>

? ???, 28/07/2008 ? 23:49 +0200, Erik Hjortsberg ?????:
> Now, I'm not sure how much work this would be to add: we're nearing
> the end of the program so you shouldn't take on something too large.
> How much work do you think it would take?
Yes, having drop down lists would be good, I planned to do it in
proposal. It probably would not take long time, as we already have
StringAdapter with suggestions. If it works, then the only thing to do
is add custom adapter parameters to recipe parser. I'll take a look into
it.

> The functionality for easily creating many entities through letting
> the user click away while in "create" mode is also very useful, and
> could perhaps be lumped with other general UI refinements. Basically
> just make sure that everything is smooth and intuitive (putting
> tooltips on all ui elements etc.).
Is there a way in CEGUI to forward click only to my widget? I'm
thinking, is it possible make changes to adapters without getting out of
"create" mode.


From erik.hjortsberg at iteam.se  Tue Jul 29 07:48:39 2008
From: erik.hjortsberg at iteam.se (Erik Hjortsberg)
Date: Tue, 29 Jul 2008 16:48:39 +0200
Subject: [WF-General] Weekly Reports
In-Reply-To: <1217303006.23668.2.camel@omega>
References: <1217303006.23668.2.camel@omega>
Message-ID: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84AA9@brun.iteam.local>

Hi, I think that the best way would be to in your SoundEntity listen to the Eris::Entity::Acted and Eris::Entity::Noise signals. I'm not sure if and how often the Noise signal are emitted (it's up to the server really) so we could focus on the Acted signals.

If you listen to the Acted signal, you should look at the code in EmberPhysicalEntity which extracts the Model::Action for that action, and then adapt it to extract a ActionDefinition from the ModelDefinition instead.
It should perhaps look something like this (where "act" is a "const Atlas::Objects::Operation::RootOperation&") and we assume that there's a member variable mEntity which points to an instance of EmberPhysicalEntity:

        const std::list<std::string> &p = act->getParents();
        std::list<std::string>::const_iterator I = p.begin();

        if (I != p.end()) {
                const std::string& actionName(*I);

                ...check if a sound should be played for that action...
        }


However, you initially need to go through all actions to see if there's any sounds defined, to know whether you should create the SoundEntity. And in the constructor for the SoundEntity you also probably want to set up a local map of the actions and their sounds, since the ModelDefinition stores the ActionDefinitions in a vector only, so lookup isn't fast (and you don't want to do a lookup through the whole vector every time an action is played).

The code you've committed in EmberPhysicalEntity::setSounds() is on the right track, though you should first check whether there's actually any actions defined that have any sounds before deciding to create the SoundEntity instance. A lot of Models won't have any sounds.
As you can see in ActionDefinition I've already since before added a SoundDefinition. That's from old, and you can alter that to better behave with your changed (which I guess you've already done). In the code you've committed you're using a pointer for the ActionDefinitionStore when you should use a const reference instead.
Then you just need to iterate through the actions and see if any of them have any sounds defined for them, and if so you should create the SoundEntity and set it up.

I'm a bit curious through from where you've picked up the pattern of using #defines in the way that you do.
I'm sorry to say that's it's not something that we can have in Ember, for a number of different reasons. The usage of #defines where not absolutely needed is strongly discouraged. It makes the code harder to read and maintain. One of the reasons is that one must remember to alway #undefine the #define when it runs out of "scope", else you risk getting strange collisions later on. Macros in general should be avoided as much as possible when not necessary; see http://www.research.att.com/~bs/bs_faq2.html#macro .

/erik




________________________________________
Fr?n: general-bounces at mail.worldforge.org [general-bounces at mail.worldforge.org] f&#246;r nightz [abra185 at gmail.com]
Skickat: den 29 juli 2008 05:43
Till: general at mail.worldforge.org
?mne: [WF-General] Weekly Reports

Hi all Worldforgers, how are you? This week i took care to follow Erik
comments about the system and got it a bit more close to where we want
it. I got the ModelMapping knowning about the Sounddefs and
reimplemented SoundActions and SoundGroups. Basically i want to tie an
EmberEntity to a model and a sound entity, the sound entity will be
responsible to handle the entity position and update the sound buffers
within it (for better 3d audio) and the sound groups will just play the
sounds! I am missing now just a way to communicate EmberPhysicalEntity
and the actions parsed from the modeldef, can anyone help me out? Since
Erik is travelling things get a bit harder to go since i have to digg
out alot more on the code but things are still going. On the next week i
plan to finish this integration and have it playing sounds, i cant stand
anymore without them! Thats it.

Sincerely,
Romulo Fernandes.

_______________________________________________
General mailing list
General at mail.worldforge.org
http://mail.worldforge.org/lists/listinfo/general

From erik.hjortsberg at iteam.se  Tue Jul 29 07:48:39 2008
From: erik.hjortsberg at iteam.se (Erik Hjortsberg)
Date: Tue, 29 Jul 2008 16:48:39 +0200
Subject: [WF-General] Weekly Reports
In-Reply-To: <1217303006.23668.2.camel@omega>
References: <1217303006.23668.2.camel@omega>
Message-ID: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84AA9@brun.iteam.local>

Hi, I think that the best way would be to in your SoundEntity listen to the Eris::Entity::Acted and Eris::Entity::Noise signals. I'm not sure if and how often the Noise signal are emitted (it's up to the server really) so we could focus on the Acted signals.

If you listen to the Acted signal, you should look at the code in EmberPhysicalEntity which extracts the Model::Action for that action, and then adapt it to extract a ActionDefinition from the ModelDefinition instead.
It should perhaps look something like this (where "act" is a "const Atlas::Objects::Operation::RootOperation&") and we assume that there's a member variable mEntity which points to an instance of EmberPhysicalEntity:

        const std::list<std::string> &p = act->getParents();
        std::list<std::string>::const_iterator I = p.begin();

        if (I != p.end()) {
                const std::string& actionName(*I);

                ...check if a sound should be played for that action...
        }


However, you initially need to go through all actions to see if there's any sounds defined, to know whether you should create the SoundEntity. And in the constructor for the SoundEntity you also probably want to set up a local map of the actions and their sounds, since the ModelDefinition stores the ActionDefinitions in a vector only, so lookup isn't fast (and you don't want to do a lookup through the whole vector every time an action is played).

The code you've committed in EmberPhysicalEntity::setSounds() is on the right track, though you should first check whether there's actually any actions defined that have any sounds before deciding to create the SoundEntity instance. A lot of Models won't have any sounds.
As you can see in ActionDefinition I've already since before added a SoundDefinition. That's from old, and you can alter that to better behave with your changed (which I guess you've already done). In the code you've committed you're using a pointer for the ActionDefinitionStore when you should use a const reference instead.
Then you just need to iterate through the actions and see if any of them have any sounds defined for them, and if so you should create the SoundEntity and set it up.

I'm a bit curious through from where you've picked up the pattern of using #defines in the way that you do.
I'm sorry to say that's it's not something that we can have in Ember, for a number of different reasons. The usage of #defines where not absolutely needed is strongly discouraged. It makes the code harder to read and maintain. One of the reasons is that one must remember to alway #undefine the #define when it runs out of "scope", else you risk getting strange collisions later on. Macros in general should be avoided as much as possible when not necessary; see http://www.research.att.com/~bs/bs_faq2.html#macro .

/erik




________________________________________
Fr?n: general-bounces at mail.worldforge.org [general-bounces at mail.worldforge.org] f&#246;r nightz [abra185 at gmail.com]
Skickat: den 29 juli 2008 05:43
Till: general at mail.worldforge.org
?mne: [WF-General] Weekly Reports

Hi all Worldforgers, how are you? This week i took care to follow Erik
comments about the system and got it a bit more close to where we want
it. I got the ModelMapping knowning about the Sounddefs and
reimplemented SoundActions and SoundGroups. Basically i want to tie an
EmberEntity to a model and a sound entity, the sound entity will be
responsible to handle the entity position and update the sound buffers
within it (for better 3d audio) and the sound groups will just play the
sounds! I am missing now just a way to communicate EmberPhysicalEntity
and the actions parsed from the modeldef, can anyone help me out? Since
Erik is travelling things get a bit harder to go since i have to digg
out alot more on the code but things are still going. On the next week i
plan to finish this integration and have it playing sounds, i cant stand
anymore without them! Thats it.

Sincerely,
Romulo Fernandes.

_______________________________________________
General mailing list
General at mail.worldforge.org
http://mail.worldforge.org/lists/listinfo/general

From erik.hjortsberg at iteam.se  Tue Jul 29 08:03:16 2008
From: erik.hjortsberg at iteam.se (Erik Hjortsberg)
Date: Tue, 29 Jul 2008 17:03:16 +0200
Subject: [WF-General] Entity creator weekly GSoC report
In-Reply-To: <1217342326.4097.21.camel@nat.tortilla.ru>
References: <488DB692.1090008@gmail.com>
	<93BE8A5F0814E64D8CEDC34CA57B764A014EC84AA5@brun.iteam.local>
	,<488E0EFF.5060003@gmail.com>
	<93BE8A5F0814E64D8CEDC34CA57B764A014EC84AA7@brun.iteam.local>,
	<1217342326.4097.21.camel@nat.tortilla.ru>
Message-ID: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84AAA@brun.iteam.local>

An idea I have is to let the user select "random" for every dropdown box. I.e. telling Ember to randomly choose any of the items in the dropdown whenever a new entity is placed (that could also apply to sliders). Though we should perhaps start with the basic dropdown first.

The issue with allowing you to click on the gui while in "create" mode is that you then need some method to check whether there's an active, clickable widget under it. Though as you say the easier way would be to perhaps just check if the Entity creator widget is under the mouse.
The best way to do that would probably be to first get the CEGUI::Window that is under the mouse, through http://www.cegui.org.uk/api_reference/classCEGUI_1_1System.html#4fb0b16eee0392aa3691a3931c044dd8 and then checking if that window either is the entity creator window, or is an "ancestor" of it (i.e. a nested child), through this method: http://www.cegui.org.uk/api_reference/classCEGUI_1_1Window.html#4d7bc3476cfceb97d5956659ff937129

/erik
________________________________________
Fr?n: Alexey Torkhov [atorkhov at gmail.com]
Skickat: den 29 juli 2008 16:38
Till: Erik Hjortsberg
Kopia: Kai Blin; general at worldforge.org
?mne: Re: SV: SV: Entity creator weekly GSoC report

? ???, 28/07/2008 ? 23:49 +0200, Erik Hjortsberg ?????:
> Now, I'm not sure how much work this would be to add: we're nearing
> the end of the program so you shouldn't take on something too large.
> How much work do you think it would take?
Yes, having drop down lists would be good, I planned to do it in
proposal. It probably would not take long time, as we already have
StringAdapter with suggestions. If it works, then the only thing to do
is add custom adapter parameters to recipe parser. I'll take a look into
it.

> The functionality for easily creating many entities through letting
> the user click away while in "create" mode is also very useful, and
> could perhaps be lumped with other general UI refinements. Basically
> just make sure that everything is smooth and intuitive (putting
> tooltips on all ui elements etc.).
Is there a way in CEGUI to forward click only to my widget? I'm
thinking, is it possible make changes to adapters without getting out of
"create" mode.


From erik.hjortsberg at iteam.se  Wed Jul 30 02:18:46 2008
From: erik.hjortsberg at iteam.se (Erik Hjortsberg)
Date: Wed, 30 Jul 2008 11:18:46 +0200
Subject: [WF-General] Weekly Reports
In-Reply-To: <1217303006.23668.2.camel@omega>
References: <1217303006.23668.2.camel@omega>
Message-ID: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84AAC@brun.iteam.local>

Hi, I saw the commits you made, looks better. Now you're correctly parsing the actions looking for sounds. Two things however:

* You must be careful not to cause any unnecessary copying when using instances that are returned by ref. This code in particular:
ActionDefinitionsStore store = master->getActionDefinitions();
the getActionDefionitions() method returns a reference to the vector containing the definitions, but as the "store" variable isn't a reference a full copy of the vector will happen. In this case it only contains pointers to ActionDefinitions, so it will only copy the pointers, but if it had contained real instances instead those would have been copied as well. All in all it's an unnecessary copy operation. The preferred way is instead to do
const ActionDefinitionsStore& store = master->getActionDefinitions();

* You absolutely must stop using defines the way you use them. In the aforementioned example you've used a #define for ActionDefinitionsStore, which makes it hard to use it because every time someone revisits the code they will get confused, since there's already a typedef named EmberOgre::Model::ActionDefinitionsStore, but that's not what's used here. Furthermore, one has to then look up the #define to see what's really defined. Is it
 #define ActionDefinitionsStore std::vector<Model::ActionDefinition*>
or
 #define ActionDefinitionsStore const std::vector<Model::ActionDefinition*>
or
 #define ActionDefinitionsStore std::vector<Model::ActionDefinition*>&
or
 #define ActionDefinitionsStore const std::vector<Model::ActionDefinition*>&

Those can behave very differently, and it's absolutely crucial that anyone revisiting the code later on knows exactly what any given definition is. Having to look up the definitions all the time makes the code much harder to maintain.
In addition to that, one of the advantages of using typedefs is that it's easy to later on change it to another container class, implementing the same interface. One only needs to do that in one single place (i.e. ModelDefinition.h) and all other parts of the code that's referencing it will be updated.
However, with the way you've used #define here this will break, because suddenly the #define won't match the "real" ActionDefinitionsStore typedef.

sincerely Erik
________________________________________
Fr?n: general-bounces at mail.worldforge.org [general-bounces at mail.worldforge.org] f&#246;r nightz [abra185 at gmail.com]
Skickat: den 29 juli 2008 05:43
Till: general at mail.worldforge.org
?mne: [WF-General] Weekly Reports

Hi all Worldforgers, how are you? This week i took care to follow Erik
comments about the system and got it a bit more close to where we want
it. I got the ModelMapping knowning about the Sounddefs and
reimplemented SoundActions and SoundGroups. Basically i want to tie an
EmberEntity to a model and a sound entity, the sound entity will be
responsible to handle the entity position and update the sound buffers
within it (for better 3d audio) and the sound groups will just play the
sounds! I am missing now just a way to communicate EmberPhysicalEntity
and the actions parsed from the modeldef, can anyone help me out? Since
Erik is travelling things get a bit harder to go since i have to digg
out alot more on the code but things are still going. On the next week i
plan to finish this integration and have it playing sounds, i cant stand
anymore without them! Thats it.

Sincerely,
Romulo Fernandes.

_______________________________________________
General mailing list
General at mail.worldforge.org
http://mail.worldforge.org/lists/listinfo/general

From erik.hjortsberg at iteam.se  Wed Jul 30 02:18:46 2008
From: erik.hjortsberg at iteam.se (Erik Hjortsberg)
Date: Wed, 30 Jul 2008 11:18:46 +0200
Subject: [WF-General] Weekly Reports
In-Reply-To: <1217303006.23668.2.camel@omega>
References: <1217303006.23668.2.camel@omega>
Message-ID: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84AAC@brun.iteam.local>

Hi, I saw the commits you made, looks better. Now you're correctly parsing the actions looking for sounds. Two things however:

* You must be careful not to cause any unnecessary copying when using instances that are returned by ref. This code in particular:
ActionDefinitionsStore store = master->getActionDefinitions();
the getActionDefionitions() method returns a reference to the vector containing the definitions, but as the "store" variable isn't a reference a full copy of the vector will happen. In this case it only contains pointers to ActionDefinitions, so it will only copy the pointers, but if it had contained real instances instead those would have been copied as well. All in all it's an unnecessary copy operation. The preferred way is instead to do
const ActionDefinitionsStore& store = master->getActionDefinitions();

* You absolutely must stop using defines the way you use them. In the aforementioned example you've used a #define for ActionDefinitionsStore, which makes it hard to use it because every time someone revisits the code they will get confused, since there's already a typedef named EmberOgre::Model::ActionDefinitionsStore, but that's not what's used here. Furthermore, one has to then look up the #define to see what's really defined. Is it
 #define ActionDefinitionsStore std::vector<Model::ActionDefinition*>
or
 #define ActionDefinitionsStore const std::vector<Model::ActionDefinition*>
or
 #define ActionDefinitionsStore std::vector<Model::ActionDefinition*>&
or
 #define ActionDefinitionsStore const std::vector<Model::ActionDefinition*>&

Those can behave very differently, and it's absolutely crucial that anyone revisiting the code later on knows exactly what any given definition is. Having to look up the definitions all the time makes the code much harder to maintain.
In addition to that, one of the advantages of using typedefs is that it's easy to later on change it to another container class, implementing the same interface. One only needs to do that in one single place (i.e. ModelDefinition.h) and all other parts of the code that's referencing it will be updated.
However, with the way you've used #define here this will break, because suddenly the #define won't match the "real" ActionDefinitionsStore typedef.

sincerely Erik
________________________________________
Fr?n: general-bounces at mail.worldforge.org [general-bounces at mail.worldforge.org] f&#246;r nightz [abra185 at gmail.com]
Skickat: den 29 juli 2008 05:43
Till: general at mail.worldforge.org
?mne: [WF-General] Weekly Reports

Hi all Worldforgers, how are you? This week i took care to follow Erik
comments about the system and got it a bit more close to where we want
it. I got the ModelMapping knowning about the Sounddefs and
reimplemented SoundActions and SoundGroups. Basically i want to tie an
EmberEntity to a model and a sound entity, the sound entity will be
responsible to handle the entity position and update the sound buffers
within it (for better 3d audio) and the sound groups will just play the
sounds! I am missing now just a way to communicate EmberPhysicalEntity
and the actions parsed from the modeldef, can anyone help me out? Since
Erik is travelling things get a bit harder to go since i have to digg
out alot more on the code but things are still going. On the next week i
plan to finish this integration and have it playing sounds, i cant stand
anymore without them! Thats it.

Sincerely,
Romulo Fernandes.

_______________________________________________
General mailing list
General at mail.worldforge.org
http://mail.worldforge.org/lists/listinfo/general

From erik.hjortsberg at iteam.se  Thu Jul 31 09:59:50 2008
From: erik.hjortsberg at iteam.se (Erik Hjortsberg)
Date: Thu, 31 Jul 2008 18:59:50 +0200
Subject: [WF-General] Entity creator weekly GSoC report
In-Reply-To: <1217342326.4097.21.camel@nat.tortilla.ru>
References: <488DB692.1090008@gmail.com>
	<93BE8A5F0814E64D8CEDC34CA57B764A014EC84AA5@brun.iteam.local>
	,<488E0EFF.5060003@gmail.com>
	<93BE8A5F0814E64D8CEDC34CA57B764A014EC84AA7@brun.iteam.local>,
	<1217342326.4097.21.camel@nat.tortilla.ru>
Message-ID: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84AAD@brun.iteam.local>

Hi, I saw the commits you did with changes to EntityCreatorInputAdapter::injectMouseButton*
However, you don't need to call the CEGUI methods there yourself if the cursor is over the entity creator window; you just need to return "true".

See, when input is recieved (say a mouse click) the Input class will iterate over the instances of IInputAdapter that are registered with it, starting with the one that was most recently added first, and then call the injectMouseButtonDown for each entity, _unless_ the current adapter instance returns "false". This allows adapters to "consume" events, preventing them from reaching other adapters.
In this case, there will be two adapters registered: the cegui input adapter which routes events to CEGUI, and the EntityCreatorInputAdapter. (The CEGUI adapter is pretty much always registered as the bottom most adapter.)
So the Input class will first call EntityCreatorInputAdapter::injectMouseButtonDown(...) and then, if that call returns true, it will call the CEGUI adapter.
Thus, the only thing you need to do if you want CEGUI to also recieve the input events is to return "true".

The semantics are perhaps a bit muddled, I think it would probably be better to refactor the interface into
void IInputAdapter::injectMouseButtonDown(const Input::MouseButton& button, bool& allowFurtherProcessing)
As it is now it's not obvious what the return value accomplishes unless one looks at the source for IInputAdapter.


/erik

________________________________________
Fr?n: Alexey Torkhov [atorkhov at gmail.com]
Skickat: den 29 juli 2008 16:38
Till: Erik Hjortsberg
Kopia: Kai Blin; general at worldforge.org
?mne: Re: SV: SV: Entity creator weekly GSoC report

? ???, 28/07/2008 ? 23:49 +0200, Erik Hjortsberg ?????:
> Now, I'm not sure how much work this would be to add: we're nearing
> the end of the program so you shouldn't take on something too large.
> How much work do you think it would take?
Yes, having drop down lists would be good, I planned to do it in
proposal. It probably would not take long time, as we already have
StringAdapter with suggestions. If it works, then the only thing to do
is add custom adapter parameters to recipe parser. I'll take a look into
it.

> The functionality for easily creating many entities through letting
> the user click away while in "create" mode is also very useful, and
> could perhaps be lumped with other general UI refinements. Basically
> just make sure that everything is smooth and intuitive (putting
> tooltips on all ui elements etc.).
Is there a way in CEGUI to forward click only to my widget? I'm
thinking, is it possible make changes to adapters without getting out of
"create" mode.


From erik.hjortsberg at iteam.se  Thu Jul 31 10:09:00 2008
From: erik.hjortsberg at iteam.se (Erik Hjortsberg)
Date: Thu, 31 Jul 2008 19:09:00 +0200
Subject: [WF-General] Weekly Reports
In-Reply-To: <1217303006.23668.2.camel@omega>
References: <1217303006.23668.2.camel@omega>
Message-ID: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84AAE@brun.iteam.local>

Hi, I saw your latest commit. There's no need at all to say you're sorry, or that the defines were "stupid". One of the goals of the SoC is to increase your coding skills through real world coding, and the absolute best way to learn is to learn from experimenting. It's only good that you try out different things, since it allows us to reflect on why they are good or bad.

/erik
________________________________________
Fr?n: general-bounces at mail.worldforge.org [general-bounces at mail.worldforge.org] f&#246;r nightz [abra185 at gmail.com]
Skickat: den 29 juli 2008 05:43
Till: general at mail.worldforge.org
?mne: [WF-General] Weekly Reports

Hi all Worldforgers, how are you? This week i took care to follow Erik
comments about the system and got it a bit more close to where we want
it. I got the ModelMapping knowning about the Sounddefs and
reimplemented SoundActions and SoundGroups. Basically i want to tie an
EmberEntity to a model and a sound entity, the sound entity will be
responsible to handle the entity position and update the sound buffers
within it (for better 3d audio) and the sound groups will just play the
sounds! I am missing now just a way to communicate EmberPhysicalEntity
and the actions parsed from the modeldef, can anyone help me out? Since
Erik is travelling things get a bit harder to go since i have to digg
out alot more on the code but things are still going. On the next week i
plan to finish this integration and have it playing sounds, i cant stand
anymore without them! Thats it.

Sincerely,
Romulo Fernandes.

_______________________________________________
General mailing list
General at mail.worldforge.org
http://mail.worldforge.org/lists/listinfo/general

From erik.hjortsberg at iteam.se  Thu Jul 31 10:09:00 2008
From: erik.hjortsberg at iteam.se (Erik Hjortsberg)
Date: Thu, 31 Jul 2008 19:09:00 +0200
Subject: [WF-General] Weekly Reports
In-Reply-To: <1217303006.23668.2.camel@omega>
References: <1217303006.23668.2.camel@omega>
Message-ID: <93BE8A5F0814E64D8CEDC34CA57B764A014EC84AAE@brun.iteam.local>

Hi, I saw your latest commit. There's no need at all to say you're sorry, or that the defines were "stupid". One of the goals of the SoC is to increase your coding skills through real world coding, and the absolute best way to learn is to learn from experimenting. It's only good that you try out different things, since it allows us to reflect on why they are good or bad.

/erik
________________________________________
Fr?n: general-bounces at mail.worldforge.org [general-bounces at mail.worldforge.org] f&#246;r nightz [abra185 at gmail.com]
Skickat: den 29 juli 2008 05:43
Till: general at mail.worldforge.org
?mne: [WF-General] Weekly Reports

Hi all Worldforgers, how are you? This week i took care to follow Erik
comments about the system and got it a bit more close to where we want
it. I got the ModelMapping knowning about the Sounddefs and
reimplemented SoundActions and SoundGroups. Basically i want to tie an
EmberEntity to a model and a sound entity, the sound entity will be
responsible to handle the entity position and update the sound buffers
within it (for better 3d audio) and the sound groups will just play the
sounds! I am missing now just a way to communicate EmberPhysicalEntity
and the actions parsed from the modeldef, can anyone help me out? Since
Erik is travelling things get a bit harder to go since i have to digg
out alot more on the code but things are still going. On the next week i
plan to finish this integration and have it playing sounds, i cant stand
anymore without them! Thats it.

Sincerely,
Romulo Fernandes.

_______________________________________________
General mailing list
General at mail.worldforge.org
http://mail.worldforge.org/lists/listinfo/general