{11} Assigned, Active Tickets by Owner (Full Description) (22 matches)

I have noticed that when two ships are next to each other, the two models will overlap into the same physical space. This issue is particularly pronounced with larger ships. What should happen is that one ship should stop when blocked by another, or the larger ship should push the smaller ship out of the way. While this may not seem significant, it is in fact critical to the matter of naval strategy. At the Battle of Salamis, one of the reasons that the Persians were defeated is that the vastness of their navy made it impossible for their ships to maneuver, making them easy prey for the Athenians. This would not have been a problem if their ships had been able to overlap into the same physical space! Thus in order to ensure realistic naval strategy, we must adhere faithfully to the laws of physics.

This ticket is for modifying sidebar.php (to include all widgets and plugins) and call it it in all pages.

The GUI engine is subject to a number of bugs related to the handling of mouse button releases. Currently mouse events are only sent to the GUI object that has focus, which is adequate for mouse button presses. The problem comes from not handling the subsequent release:

In the minimap if you left-click-drag, the camera moves but if you go outside the minimap area and release the button, the minimap is never notified since it lost focus and will continue to expect mouse movement (in fact you must re-click and release inside the minimap to correct this.) A similar problem occurs for bandboxing selection in windowed mode and in fact anywhere that mouse button release is expected.

At a guess, we may want to send button release events to all GUI objects instead of only the one with focus. Trying to reset the button state locally upon losing focus is a hack that doesn't really work (imagine left-click-dragging in the minimap and then accidentally going 1 pixel outside the minimap area, well you've lost focus and so even though you're still holding down the button, it would lose function).

The database is full of stuff already. Instead of cluttering it with additional DBs, it would be nice if the current WP installation would move into the development database.

• Traders generate resources by moving along trade routes (between player and allied Markets/Docks?)
• XML.Entity.Actions.Trade

This ticket is for modifying page.php and style.css to create a rough version of our theme. Once basic CSS, HTML, and PHP are put into place, artwork needs to be identified and requested.

For skinned models, the  COLLADA 1.4.1 spec allows a special vertex weight index of -1, which indicates the weight applies to the bind-shape matrix* instead of a particular bone, as seen in this example:

<skin>
  <source id="joints"/>
  <source id="weights"/>
  <vertex_weights count="4">
    <input semantic="JOINT" source="#joints"/>
    <input semantic="WEIGHT" source="#weights"/>
    <vcount>3 2 2 3</vcount>
    <v>
      -1 0 0 1 1 2
      -1 3 1 4
      -1 3 2 4
      -1 0 3 1 2 2
    </v>
  </vertex_weights>
</skin>

(*The bind-shape matrix represents the transform of the bind-shape prior to skinning, it transforms the bind-shape from object space to bind-space. It's specified by a <bind_shape_matrix> element in the <skin> or assumed to be an identity transform. See pages 4.6-4.8 of the COLLADA spec for more notes.)

Currently if you try to add such a model to the game, it will fail to import since the PMD converter thinks there are more than 256 bones (the -1 index is typecast to an unsigned int). Apparently Blender 2.60a likes to export such models and seems to have made general improvements to animation exporting, so we should find a way to implement this.

As a workaround, it may be possible to export animations with Blender 2.6 and the corresponding models with an older version.

Many of the models are in the PMD format and are not editable by most 3d editing programs. A converter would be needed to ensure high modability in this game, as well to make edits to models.

An alternate solution is for someone to just convert all PMD to DAE.

OS X CoreAudio has some trouble with our reuse of sources (see http://www.wildfiregames.com/forum/index.php?showtopic=15066). There are various bandaids such as FIFO reuse (thus giving CoreAudio more time to finish what it's doing before we reset the source properties). However, one proper fix might be to just generate/delete sources anew.

This used to be super expensive on hardware implementations, but OpenALsoft should manage much faster. I have implemented this approach (see attached patch) and run a quick test.

With the old suballocator, running -autostart="We Are Legion", sending the front middle guy forwards and waiting for the dust to clear, I see tc_OpenAL_source: 3790.03 kc (5203x) (about 0.2 us per alloc). The new patched version gets tc_OpenAL_source: 239.762 Mc (5411x). Apparently the battle went slightly differently, there were also more casualties, but the per-alloc cost is indeed higher (14 us). Still nothing to worry about; I think this approach is fine on software implementations of OpenAL.

I'd appreciate people testing this on OS X, which requires removing the little kill-switch in hwdetect.js.

Questions:

1) does this fix the issues?

2) is the per-alloc overhead [converting the above number to seconds by dividing by the CPU clock and normalizing according to the number of calls (in parentheses)] similar?

Jan - this didn't work. See my notes below. (kenny)

Consider the elegance of |if (cmpVisual)| instead of |if (!cmpVisual.null())|.

Some actors like  props/flora/water_lillies.xml which are not decals but flat models, can cause selection problems in Atlas. They have a selection box, but the calculation of the box and/or the the algorithm in RayIntersect is failing and causing unpredictable behavior. It's especially noticeable on Belgian Bog, due to the high concentration of such lillies in the center. Clicking in a seemingly open area of the map might select a lilly by mistake. Strangely  props/flora/pond_lillies_large.xml does not have this problem.

It's easy to test on a blank map. I put a breakpoint in the selection code and found the CBoundingBoxOriented data for water_lillies:

m_Center = {X=298.17743 Y=22.402514 Z=378.40604 }
m_HalfSizes = {X=1.8804212 Y=0.00000000 Z=1.8804319 }
m_Basis
   [0] = {X=0.70711076 Y=0.00000000 Z=0.70710266 }
   [1] = {X=-1.#IND000 Y=-1.#IND000 Z=-1.#IND000 }
   [2] = {X=-0.70709860 Y=0.00000000 Z=0.70711488 }

compared with the data for pond_lillies_large:

m_Center = {X=297.05060 Y=22.391361 Z=382.82440 }
m_HalfSizes = {X=10.045100 Y=9.5367432e-007 Z=9.4280548 }
m_Basis
   [0] = {X=0.70711213 Y=0.00000000 Z=0.70710146 }
   [1] = {X=0.00000000 Y=1.0000000 Z=0.00000000 }
   [2] = {X=-0.70710194 Y=0.00000000 Z=0.70711166 }

Notice the first example has -1.#IND000 values in one of its basis vectors, which means "indeterminate" value. The height of the bounding box (m_HalfSizes.Y) is exactly 0. The second example has sane values. Maybe we could detect completely flat models and give them a small selection box height or specially handle 2D intersection in 3D space. I guess a similar problem would occur with a vertically-oriented flat model, so the best solution is probably independent of orientation.