Ember ToDo List
From WorldForgeWiki
This is the todo list for Ember. As of 2007-08-03 we now use the Launchpad for all feature request and planning. This page is locked and the items in it will be moved over to the Launchpad.
Contents
Current ToDo list
General
- Implement a rule based model mapping system, which allows us to use arbitrary rules for mapping between entities, attributes and models and parts. [partially done]
- Implement entity type matching [done]
- Implement attribute value matching [done]
- Text value matching [done]
- Numerical value matching [done]
- Complex value matching (such as Maps and Lists) [not done]
- Composite values (such as "Height" for getting the z-size of the bbox) [done]
- Implement outfit reference mapping [done]
- Clean up the Sound Service to actually function [done]
- Handle sound resources. Perhaps use an abstract resouce interface which can be implemented by the Ogre resource manager? (We could of course write a resource manager ourselves, but Ogre already has one, so that can be reused (through an interface of course)). [done]
- Connect entities to the sound service, allowing 3d sounds to be played. [done]
- Add sound information to the modeldef format. [done]
- Add information to the modeldef format for autorotation of objects attached to attach points (so that settlers holding tools will look alright) [partially done]
- Update the human and item modeldefinitions with valid values for this. [partially done]
- Refactor the terrain code into a more suitable architecture (ask Erik for details). [done]
- Activate GPU shader terrain. [done]
- Refactor the TerrainPage into these classes: "TerrainPageGeometry" being responsible for the geometry of the page, "TerrainPageSurface" being responsible for the texture of the page, "TerrainPageSurfaceLayer" being responsible for one mercator shader, "TerrainPageSurfaceCompiler" being responsible for creating an Ogre material from the aforementioned classes. [done]
- Use hardware skeleton animation with GPU shaders that can handle the number of bones in the skeletons used. [not done]
- When movement changes during an action animation, the action animation should be aborted and the movement animation should play. [not done]
- Allow editing of entities while in admin mode, through a simple entity editing widget which would allow adding, removing and changing of atlas attributes. [done]
- Allow editing of terrain areas through a widget. This would be combined with the current terrain editing functionality. [not done]
- When in admin mode, it shall be possible to "teleport" the avatar by just clicking on the terrain. [done]
- Use libwfut instead of the java WFUT. [done]
- Add a wfut service. [done]
- Add a wfut section to the config file [done]
- Adapt the loading bar to show download progress [done]
- Use the wfut service on startup [done]
- Upgrade to Ogre 1.4 [done]
- Upgrade to CEGUI 0.5.0 [done]
- When in admin mode, it should be possible to "possess" another character, in effect acting as that character. [not done]
- Mark entities that are controlled by a player (which have the "external" attribute set to "1"), perhaps by always displaying their name on top of them (like WoW). [done]
- Add commands for rotating the character, "+character_rotate_left" and "+character_rotate_right". [not done]
Refactoring
- Don't use the Ogre automatic rendering loop, instead use our own timer loop. [partially done]
- Cap the framerate at 60 fps, letting Eris (or the OS) have the surplus cycles. [not done]
- Stop rendering when the window is hidden. This must allow the engine to be correctly updated without having to rely on Ogre frame events. [done]
- Render the GUI in a fixed step, say 30 or 60 fps, skipping scene renders of the gui dips. This will make sure that the gui always is responsive, even if the scene isn't. [not done]
- Refactor the camera system [not done]
- Separate the CameraMount from the Camera. A CameraMount would be something like third-person, first-person or free flying [not done]
- Separate out application functionality into the Application.h class, letting only Ogre stuff still be in EmberOgre. [partially done]
- Split EmberOgre into smaller classes. [partially done]
- Make input fully independent of Ogre. Move the input handling to the Input service. [partially done]
- Move modelmapping stuff into a temporary libAres library, so that it can be reused by other clients [not done]
- Write example Actions for Sear. [not done]
GUI
- Expand the model editor [not done]
- Add ability to set the group of parts [not done]
- Allow editing of actions [not done]
- Create a model mapping editor with CEGUI and Lua [not done]
- Revamp the inventory [partially done]
- Allow for stacking [not done]
- Show inventory items as graphics, using the CEGUIImage class, perhaps adding a IconManager for caching and handling of icons [done]
- Allow for using items directly in the inventory, like eating a loaf of bread [done]
Introductory tasks
These are tasks that are better suited for developers getting into the Ember framework. For more information, contact User:Erik.
- Allow the Terrain Editor to change multiple height points at once. The idea is that when editing the terrain you sometimes want to edit more than a single height point at once, instead you also would want to affect the surrounding height points within a certain radius. For example when creating a large mountain. Currently the TerrainEditAction class has support for multiple movements per action, but only the base point clicked will be moved. [not done]
- Add radius and falloff options. The radius (in meters) determines how many base points to affect. The falloff determines how much surrounding base points will be affected. [not done]
- Edit the gui to allow for changing of these options. [not done]
- Split up the files src/components/ogre/terrain/TerrainEditor.h|cpp into separate files for the different classes, to be places in the subdirectory src/components/ogre/terrain/editing. [not done]
- Activate multiple select on the Give dialog. [done]
- Make the Task dialog slightly longer. [not done]
- Gallow model should be adjusted higher, jetty lower. [partially done]
- Save all world messages (such as chat, events ingame etc.) to a log, such as ~/.ember/logs/20070303190012.log. It should be fully configurable from the configuration file. [partially done]
- Add option to set the run and walking speed in ember.conf. This is in the end however dictated by the server, so a change needs to be done there too. An even better scenario would be if the client would get this information from the server. [done]
- The entity type "pile" has a "material" attribute which can be either "sand", "earth" or "sílt". Make the pile model reflect this by editing the modelmapping. [done]
- When the pickaxe is used on the world it sends a delve operation which can result in a "boulder" or an "ice" entity. We need meshes, models and modelmappings for this. [done]
Wanted features
These are features wanted by non-developers of Ember. If you add something here, the Ember devs will comment on it.
AniCator
- OpenGL and Direct3D Shader Library support.
There's already support for Cg, HLSL and GLSL shaders.--Erik
- More graphical features
Please be more specific.--Erik
- Better physics. (Blender 3D uses Bullet, it's a nice sweet physics engine)
Currently there's no physics engine at all. This is because there's no physics on the server (cyphesis). Physics would need to be added to the servers first. We do however use OpCode for collision detection, mainly for doing mouse picking. Bullet has been suggested as a replacement to the stagnant OpCode.--Erik
- Improve the rasterizer to allow high poly-counts for maybe facial animation combined with VoIP/Voice Chat
You will need to elaborate. Ogre, which is the 3d engine component, provides vertex animation which can be used for facial animation. I don't understand what you mean by "rasterizer" however. VOIP isn't something that's interesting for us currently.--Erik
Winter Knight
- Mouse movement is very slow and awkward. Rather than moving the mouse cursor manually, ember should let the OS handle the mouse cursor.
- This would indeed improve the response from the gui, especially when running with low fps. The issue is however that we're using CEGUI for the cursor handling. I'm not sure how easy it would be to make it use the hardware cursor, since we also want to be able to change the cursor image. We'll have to look further into this. One option would be to completely disable the CEGUI cursor and use SDL for cross platform cursor handling.--Erik 20:17, 17 June 2007 (CEST)
- I don't think changing the hardware cursor image would be much of an issue. Lots of programs do that.--Winter Knight
- This would indeed improve the response from the gui, especially when running with low fps. The issue is however that we're using CEGUI for the cursor handling. I'm not sure how easy it would be to make it use the hardware cursor, since we also want to be able to change the cursor image. We'll have to look further into this. One option would be to completely disable the CEGUI cursor and use SDL for cross platform cursor handling.--Erik 20:17, 17 June 2007 (CEST)
- More keyboard control at startup, such as being able to press Enter to login. Logging in is a pain when you have to use both the keyboard and mouse.[done]
- CEGUI doesn't have any built in support for things such as default forms submittal or tab order, so these are things that we need to do manually (I've already added utility methods to the Widget class for tabbing, but they need to be activated on each windows that will have tab support). Being able to press "enter" on the server log in window would indeed be nice to have.--Erik 20:17, 17 June 2007 (CEST)
- This has now been fixed.--Erik 12:11, 21 December 2007 (CET)
- CEGUI doesn't have any built in support for things such as default forms submittal or tab order, so these are things that we need to do manually (I've already added utility methods to the Widget class for tabbing, but they need to be activated on each windows that will have tab support). Being able to press "enter" on the server log in window would indeed be nice to have.--Erik 20:17, 17 June 2007 (CEST)
- Remember my username and password. I am the only one using this computer, and I log in and out a lot.
- I don't know if cyphesis supports logging in with a hashed password. We don't want to store the password in cleartext so that's required. If so, this would be an excellent introductory task.--Erik 20:17, 17 June 2007 (CEST)
- "Logging in with a hashed password" is never an option. The idea of password hashes is that you can store encrypted passwords on the server, and if they are ever compromised, the attacker still doesn't actually have the passwords. You can't obtain the password from the hash; you can only verify that a given password is correct, or incorrect. There is no equivalent for clients. Somebody has to know the actual password. It's either going to be in the user's head, or on his disk. I'm suggesting an "option" that it be on disk (in clear text.) Every program that stores passwords for you, such as firefox, stores them in clear text, unless these passwords themselves are password protected. Firefox offers a "master password" option, but that wouldn't make any sense for ember, since there is only one password. Also, keep in mind that if a user can store a password on disk, they are more likely to use a strong password that is unlikely to be compromised in a brute-force attack. Storing clear text passwords on disk is a decision, and it is up to the end user to balance security and convenience, and to come up with their own security procedures. --Winter Knight
- Note that since we're in control of the whole system, we could provide the same hashing function in the client as on the servers, and thus allow the password to be stored hashed on the client also. However, it could easily be argued that the default OS security should be sufficient. As long as we don't store any passwords unless the user explicitly has told the client to do so. We'll however have to add some functionality in Ember that checks that the user config files always have the correct permissions and aren't world readable.
- No. Allowing hashes to be used in place of passwords would defeat the whole purpose of using hashes in the first place. Let's assume that cyphesis allows us to use either passwords, or hashes (hashes only has a similar security problem.) You have the hash stored in ~/.ember. I compromise your computer, and obtain the hash. I can use that hash to log in from my computer, even though I don't know what your "password" is. In essence, your hash has become the password, and is still stored in an easily readable format.
- The security method you suggest adds no security, and in fact removes everything good about hashes. If I were to compromise the server in such a way that I can read the files, and I obtained the complete list of hashes, I could use those hashes to log in as if I knew the passwords. The whole point of using hashes instead of passwords are that hashes can only be used to verify passwords, and cannot be used to actually log in. The server only needs to verify passwords. The client needs to log in.
- Making sure that the permissions for the user's ~/.ember directory is secure is a good idea. --Winter Knight
- The main reason for storing a password as a hash is that users usually reuse their passwords on many different sites. People usually only have 3-7 passwords that are constantly reused. However, by storing the hash instead of the original password we can prevent an attacker from obtaining the clear text password, which probably is reused on many other sites/systems that the user frequents. I.e. if an attacker would be able to read the ember.conf file, that would of course mean that this attacker would be able to log in to cyphesis as the user, no matter whether we store the password as a hash or in clear text. But if we store it as a hash, we can at least prevent the attacker from trying to reuse the password on other sites/systems.--Erik 10:50, 18 June 2007 (CEST)
- Yeah. I suppose that is another use for a hash. I've never seen anything like it done before. I like it. When the user enters their password, hash it, then send that hash as the password. The server can store/verify the hash just like it has been verifying passwords. There would be no need to change cyphesis. There would be a problem with interoperability. Sear, Ember, and any future clients would need to have the hashing algorithm incorporated. Current users would need to be able to change their passwords to the hashes.
- I thought of an addition, but it has its own problems. Add a salt in a config file. The hash would come from both the password and the salt. This would make brute forces much harder. If the salt was two bytes, an attacker would have to force every word 65536 times. 4 bytes? 4.3 B times. The problem is that the user would need this salt in order to log in. They probably won't have it if they log in from a friend's house, or the library, or even their own second computer.
- In the end, these are really 3 separate ideas, though: salt, hash, and storing passwords for the user. --Winter Knight
- The main reason for storing a password as a hash is that users usually reuse their passwords on many different sites. People usually only have 3-7 passwords that are constantly reused. However, by storing the hash instead of the original password we can prevent an attacker from obtaining the clear text password, which probably is reused on many other sites/systems that the user frequents. I.e. if an attacker would be able to read the ember.conf file, that would of course mean that this attacker would be able to log in to cyphesis as the user, no matter whether we store the password as a hash or in clear text. But if we store it as a hash, we can at least prevent the attacker from trying to reuse the password on other sites/systems.--Erik 10:50, 18 June 2007 (CEST)
- Note that since we're in control of the whole system, we could provide the same hashing function in the client as on the servers, and thus allow the password to be stored hashed on the client also. However, it could easily be argued that the default OS security should be sufficient. As long as we don't store any passwords unless the user explicitly has told the client to do so. We'll however have to add some functionality in Ember that checks that the user config files always have the correct permissions and aren't world readable.
- "Logging in with a hashed password" is never an option. The idea of password hashes is that you can store encrypted passwords on the server, and if they are ever compromised, the attacker still doesn't actually have the passwords. You can't obtain the password from the hash; you can only verify that a given password is correct, or incorrect. There is no equivalent for clients. Somebody has to know the actual password. It's either going to be in the user's head, or on his disk. I'm suggesting an "option" that it be on disk (in clear text.) Every program that stores passwords for you, such as firefox, stores them in clear text, unless these passwords themselves are password protected. Firefox offers a "master password" option, but that wouldn't make any sense for ember, since there is only one password. Also, keep in mind that if a user can store a password on disk, they are more likely to use a strong password that is unlikely to be compromised in a brute-force attack. Storing clear text passwords on disk is a decision, and it is up to the end user to balance security and convenience, and to come up with their own security procedures. --Winter Knight
- I don't know if cyphesis supports logging in with a hashed password. We don't want to store the password in cleartext so that's required. If so, this would be an excellent introductory task.--Erik 20:17, 17 June 2007 (CEST)
- An option, perhaps in a config file in ~/.ember, to not contact the amber server at every single load. It makes debugging slightly slower, and if I was not connected to the internet, it would stall.
- This already exists. Add the following to ~/.ember/ember.conf to disable the WFUT updating:
[wfut] enabled=false
- I'll have to look into the issue with it stalling when there's no connection though. Also, I'll have to add support for disabling the metaserver. Currently there's no way to do that.--Erik 20:17, 17 June 2007 (CEST)
- The ability to use a resolution other than 1024x768. The setting in ~/.ember/ogre.cfg doesn't work. Debugging would be easier if the window didn't take an entire workspace.
- It's currently hard coded to 1024x768 in the code. Presumably there would be no problem with using a different resolution, but I'll have to investigate. If you find the workspace cramped you could try running a duplicate X-server ("startx -- :1") and then running Ember on that screen ("DISPLAY=:1 ./ember.bin"). --Erik 20:17, 17 June 2007 (CEST)
- I just disable fullscreen instead. It's more flexible than what you suggested. But it is still a workaround for a lacking feature. --Winter Knight
- This has now been fixed.--Erik 12:11, 21 December 2007 (CET)
- I just disable fullscreen instead. It's more flexible than what you suggested. But it is still a workaround for a lacking feature. --Winter Knight
- It's currently hard coded to 1024x768 in the code. Presumably there would be no problem with using a different resolution, but I'll have to investigate. If you find the workspace cramped you could try running a duplicate X-server ("startx -- :1") and then running Ember on that screen ("DISPLAY=:1 ./ember.bin"). --Erik 20:17, 17 June 2007 (CEST)
- Make the help screen readable. Keyword: line breaks.[done]
- This is fixed in cvs. --Erik 20:17, 17 June 2007 (CEST)
- No it isn't. The offending file is src/components/ogre/widgets/HelpWidget.xml. It hasn't been updated since March. The file itself has line breaks, but it is an xml file, and in xml, all white space is a "space." Using CDATA might work, or you might have to put something like "\n". It depends on how CEGUI uses the file. I'd be happy to look into this one and give you a patch. I don't think it will be too hard. --Winter Knight
- This one is strange, and I would appreciate it if you helped me out. On my local machine the line breaks are recognized. It might be that they are stripped/converted in the cvs process. Another option is that the different xml loading backends of CEGUI behave differently. What backend are you using (should be in ~/.ember/CEGUI.log)?
- I made some adjustments to HelpWidget.xml, and the lines break properly on my system. I'm about to email them to you, assuming I find your email address. I'm using CEGUI-0.5.0b. I downloaded it last week. I think CEGUI has a few kinks in regards to line breaks. I also think that you are right that the version matters. All I did to "fix" the problem was make the Property tag have a beginning tag and an end tag, rather than have the text all in one tag. Considering the length of the text, it looks better that way anyway. I should also point out that I was wrong about CDATA. It looks like it depends on the implementation, and CEGUI does indeed honor white space, but not in attributes (not in my version), only in the text between tags. --Winter Knight
- This one is strange, and I would appreciate it if you helped me out. On my local machine the line breaks are recognized. It might be that they are stripped/converted in the cvs process. Another option is that the different xml loading backends of CEGUI behave differently. What backend are you using (should be in ~/.ember/CEGUI.log)?
- No it isn't. The offending file is src/components/ogre/widgets/HelpWidget.xml. It hasn't been updated since March. The file itself has line breaks, but it is an xml file, and in xml, all white space is a "space." Using CDATA might work, or you might have to put something like "\n". It depends on how CEGUI uses the file. I'd be happy to look into this one and give you a patch. I don't think it will be too hard. --Winter Knight
- This is fixed in cvs. --Erik 20:17, 17 June 2007 (CEST)
- Add ability to eat. Perhaps make it similar to cutting? Wield the food, then click on your own character and select "Eat <fruit>". Perhaps this could be fixed on the server too. If Cyphesis made eating more like cutting, then Ember wouldn't need to be changed, since Ember can cut.
- I've deliberately not done anything about this because this is something that should fit under the reworking of the inventory widget. The current one is a placeholder. See the todo item further up on this page.--Erik 20:17, 17 June 2007 (CEST)
Bugs
Random bugs that needs fixing.
This list is deprecated, new bugs should instead be reported through the [Launchpad].
- Fix entering and exiting of buildings. Currently the avatar is rotated in a strange way, probably to counter previous behaviour in Eris or Cyphesis. [done]
- Using the scythe or shovel on the ground doesn't seem to work. It's probably returning an incorrect position. [done]
- Entity selection is sometimes off, returning "moraf" when it shouldn't. (This is a little bit problematic since the collision detection lib doesn't handle back face selection, so with some meshes where there's faces with backface culling disabled, such as the canvas of the stable, it's not possible to select the canvas from some angles. The version of OgreOpcode used is however very old, and could be updated. Also, OpCode is very much an inactive project. It might be prudent to keep a watch on the Bullet project. Update: updated to latest ogreopcode which allows for turning of backface culling [done]
- Disallow movement of the world. [done]
- Changes to the terrain does not cause updates on the client (i.e. only the client that does the editing sees the changes, other client won't get updated terrain). [done]
- Right clicking when not logged in still makes it enter the movement mode. [done]
- Clicking on window backgrounds propagates to the "world canvas" and brings up the menu. [done]
- Double clicking on the world moves the avatar there. This is confusing, especially since there's now a "move to" menu item (as seen here). [done]
- Lightning on the path near the sty changes as the camera moves. Normal problem perhaps? [done]
- Context menu is available in movement mode. [done]
- Horizontal sliders misses the thumb element. (this is a bug with CEGUI) [not done]
- Scaling slider in the entity edit starts in the wrong place. [not done]
