To Do List & Bugs

[daniel.santos]

This is a list of outstanding & planned items for the Glest Advanced Engine.  I put the targeted branch or version for each item following the description.

• Lightning still needs a visual effects revamp.  This will probably involve further enhancements to the base particle system (to produce long shafts without having to manage so many individual particles). [0.2]
• Effects do not yet support sounds, particles & changes to lighting. [0.3]
• Lighting & shadows looks a little funny from a distance.  It tends to cast shadows a set, square distance away and looks funny (perhaps because the light intensity doesn't follow the inverse square law?) Can probably be fixed by applying an alpha to the shadow based upon the distance from the light source, but only from local light sources (i.e., not sun or moon). [0.2?]
• MaxRenderDistance setting is not yet doing anything.  GameCamera::computeVisibleQuad() needs to be re-implemented (I never got around to finishing that one before) and use MaxRenderDistance.   (I need to suck in the code from Glest 3.2 beta, I think Martiño has done some work on this)[0.2]
• AI for interacting with & pathing around enemy walls -- they should only attack an enemy wall when they can't find another nearby way around it.  Additionally, AI should always focus their attacks on the same portions of a wall and prefer the most easily destroyed (usually a gate).  Note: A "wall" is defined as any unit with the "wall" property in it's definition. [0.2??]
• Unit skills to alter map landscape (dig gullies, etc. - for FPM Path of Reason ). [>0.2]
• Move skills need to have a max incline/decline and speed modifiers based upon incline and decline (slower up hill, faster down hill) [Update: Glest has always modified unit's speed based upon incline/decline, it's just a very small change in unit speed].  This may possibly involve other realistic travel hazards such as taking damage from "slipping" and going downhill faster than tolerated or even slipping and sliding downhill when attempting to climb a steep incline.  This will allow scouts to go places that a mounted unit cannot, etc. [>=0.3]
• adding "whatsits" (a.k.a., Glesimals [0.2, Status: pain in the arse - have done some work on this in 0.2.8, needs more testing.]
• Pathing code needs revamp due to performance problems. [0.2]
• Need to tweak the way the engine manages alpha layers in textures/models so that the Lich's cape doesn't look funny. [0.2 or 0.3]
• Remove "phantom cancel button" from GUI. http://http://www.glest.org/glest_board/viewtopic.php?t=3441 [0.2]
• Harvesting units are getting stuck courtyard of FPM Abbey[0.2]
• collision detection for left-clicking on non-display element (buttons, minimap, etc.) uses too much processing and can cause a pause in the game on slower machines when the number of total units in game increases. [Status: Partially fixed in 0.2.8: This is a long-standing Glest issue.  Every left click makes a call to Renderer::renderUnitsFast() to collect mesh data and determine if there is a collision or not, which is a fairly expensive operation.  Due to a flaw, this was actually getting called twice per left click.  I have partially resolved this by making sure that it only calls renderUnitsFast() once, but more can be done to make it faster, like changing the "visibleQuad" to 3x3 area around the clicked cell or something like that (instead of looking at the camera's visible area)]
• GAE AI not compatible with Indians mod (AI doesn't build/produce units) [status: Fixed in 0.2.7]

[Duke]

I think there are two things could be included:

- Units housing other units (also graphically)
  This is for transport ships, siege towers and perhaps walkable walls (although that one might need a different mechanism)

- advanced map object interaction. like burning or chopping down forrest without harvesting them first and corresponding: replanting trees.

[hailstone]

Nice.

There is a cancel button bug. http://www.glest.org/glest_board/viewtopic.php?t=3441
I think I found the cause but don't know how to fix because of undocumented complexity.

[daniel.santos]

thanks guys!

[@kukac@]

And what about the release?  

[orion]

Daniel, you also have to make the GAE compatible with the indians. When you play against the indians faction, the computer just harvests more resources without actually producing something.

[daniel.santos]

And what about the release?    But when we get a bugzilla database, it'll be easier to track which bugs gets/got fixed in which release, etc.

orion, added it to the bug list

[daniel.santos]

Daniel, you also have to make the GAE compatible with the indians. When you play against the indians faction, the computer just harvests more resources without actually producing something.

orion, I played a full game (had FOW off) and watched and they build the whole nine yards, made warriors, attacked, etc.  I used the "megapack_v2" from titusgames.de.  I did this on Linux, but I played a game last night on Windows and didn't have any problems

[orion]

I'm sorry for that. When I looked at the version of the GAE that I was playing, it said V0.2.6. Disregard that.

[daniel.santos]

w00t! I fixed it  (maybe?)

[orion]

Yep, I believe you fixed it...whatever you did worked.

Another thing, (and I promise this is a real bug), units stop harvesting resources. Frequently, I will find units just standing and doing nothing when they're supposed to be getting resources (mining, wood, etc.)

[daniel.santos]

I'm sure the issue with the Indians mod was real, I've heard it elsewhere.  As far as harvesting, units have a limit as to how far they will look for a new resource of what they are harvesting (and, I know, they will also switch between gold & stone).  If you have gold on the opposite side of your base building (castle/mage tower) and they run out on one side, they aren't going to be able to find the new source so they will stop.

If you are talking about units standing around at the Abbey, that's a different story and that's a real bug.  In the mean time, I recommend you build a shrine in the middle of the abbey's courtyard, right where the fountain is, this will prevent the problem.  What is actually happening here is that the workers are trying to get to the center of the building and, during that process, once they get to a cell that's adjacent to a cell in the building's cellmap that is marked with a 1, then they drop off the supply.  But with the Abbey, the center is walkable (0 value in the cell map) so they get to the center and never find one.  I've got a plan to fix this problem, but haven't gotten around to it yet.

[orion]

I'm not talking about how the units stop after there are no more resources. I'm saying that several times, units will stop while there are alot of resources left. I don't know what causes it, but when I find out, I'll give you a "TuxGamer Bug Report".

[daniel.santos]

Are you sure this isn't workers harvesting gold and being stuck at the Abbey?  If not, please do let me know how to reproduce it or at least what happens before they get there, etc.  Also, make sure that this isn't because they are stuck and can't move.

[orion]

It's not the Abbey thing. I'll figure out what's going on.

PS: goodluck with the multiplayer thing.

[orion]

Ok, I don't know if this is correct, but it seems that the units stop after an upgrade in any particular building. I still need to test it out some more.

[daniel.santos]

interesting, please do let me know

[Jamesgamer]

Very minor bug (hasn't caused any actual problems for me yet)...

When a unit is blocked by other units from repairing something, they will switch from repair to stop to repair, and sometimes have some sort of order on queue. Doesn't cause any real problem, just aesthetics.

[hailstone]

I think performance issues could be added as another heading in the list.

[orion]

The only performance problems that exist is the unit pathing code, which is already listed.

[hailstone]

I still think it's good to have it as a separate heading, maybe refactoring as a heading.

[daniel.santos]

I think performance issues could be added as another heading in the list.

I'm not sure if it's just my modifications in 0.2.8, but I'm having performance issues when drag-drop selecting.  I've experimented with a few mechanisms and I have one hacky-mechanism that works-around the problem.  I wanted to re-write all of the code for that, for one, so you can drag-drop select units while the game is paused, but I can't figure out the openGL code that does it efficiently - I'm trying to avoid using the renderUnitsFast() function and just calculate which units are selected during the actual rendering (not when the mouseMove event is generated), but I don't think I can set the render mode to both GL_SELECT and GL_RENDER at the same time, so maybe I can figure out something else that's efficient.

[Ayrin Greenflag]

i have a question, in map maker you can chose level of terrain from -5 tp +5 if i remember well..it's possible to check this level inside game? I ask this because some unit could be tied to terrain level...the use of this could be the ships unit...example the unit can travel only if terrain is -2 or more ...i think it's possible coz soldiers already walk only if terrain is till -1, but their vertical position is chained to terrain level instead ships could always have the vertical on 0 level ...is my thinking right?

[daniel.santos]

Close, but ships would simply ignore the changes in terrain level from one cell to the next since they will be floating on the water and the terrain will be below them at that point.  We were discussing the possibilities of this in one of these threads around here -- notably, to accommodate units with a more flexible tolerance for below sea-level travel.  One of my points is that very tall units (behemoth, etc.) should be able to travel in -2 depth or so, since they are much taller.  Additionally, a unit may have a separate travel skill for swimming where they travel slower (in the case of ordinary humanoids) or faster (in the case of a possible fishy humanoid) .  I'm in support of having some type of defensibility changes due to terrain too (similar to wesnoth's mechanism), but I wouldn't care to investigate that until the future and would probably be based upon amount of damage taken with certain damage/terrain types as opposed to a "chance of being hit" which is always 100% in Glest/GAE --  although somebody else proposed changing that as well for a modern warfare type of mod.

[wciow]

as opposed to a "chance of being hit" which is always 100% in Glest/GAE

A hackish way around this in the current GAE code is to set a units damage value to 0 (no damage) and then put all the damage into the units effect with the chance attribute set at less than 100%. This is really a hack since the unit will always hit the target but there is only a percentage chance that its associated effect will cause damage.