Version 0.322 - selection highlighting, grid, ship movement

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Message
Author
User avatar
strooka
Space Kraken
Posts: 165
Joined: Tue Jun 23, 2009 5:34 pm
Location: Bielefeld, Germany

Re: Version 0.322 - selection highlighting, grid, ship movement

#46 Post by strooka »

here is the right calculation of the direction vector. the ship does no more flip onto the back:

Code: Select all

void CombatWnd::MoveCombatShip(CombatShipPtr &combat_ship, Ogre::Vector3& destination)
{
    const Ship& ship = combat_ship->GetShip();
    ShipData& ship_data = m_ship_assets[combat_ship->GetShip().ID()];

    Ogre::Quaternion start_quat_direction = ship_data.m_node->getOrientation();
    Ogre::Vector3 dest_vec_direction = destination - ship_data.m_node->getPosition();

    //calc the direction
    dest_vec_direction.normalise();
    Ogre::Matrix3 matrix;
    matrix.SetColumn(0,Ogre::Vector3(dest_vec_direction.y, -dest_vec_direction.x, 0));
    matrix.SetColumn(1,Ogre::Vector3(dest_vec_direction.x, dest_vec_direction.y, 0));
    matrix.SetColumn(2,Ogre::Vector3(0, 0, 1));
    Ogre::Quaternion dest_quat_direction(matrix);
    dest_quat_direction.normalise();

...

User avatar
strooka
Space Kraken
Posts: 165
Joined: Tue Jun 23, 2009 5:34 pm
Location: Bielefeld, Germany

Re: Version 0.322 - selection highlighting, grid, ship movement

#47 Post by strooka »

here is a cleaned up patch of the modifications (without CombatShipTypes, HotKeyManager):
Attachments
diff3387ShipMove2.txt
updated ship movement
(25.33 KiB) Downloaded 66 times

User avatar
strooka
Space Kraken
Posts: 165
Joined: Tue Jun 23, 2009 5:34 pm
Location: Bielefeld, Germany

Re: Version 0.322 - selection highlighting, grid, ship movement

#48 Post by strooka »

a grid:
Image

here are the files.

some other files had to modified, too cause of display problems.

here is the code:
it must be placed here:

Code: Select all

CombatWnd::CombatWnd(Ogre::SceneManager* scene_manager,
                     Ogre::Camera* camera,
....
    m_camera_animation->setInterpolationMode(Ogre::Animation::IM_SPLINE);
    m_camera_animation_state->setEnabled(true);
    m_camera_animation_state->setLoop(false);

    m_ship_animation->setInterpolationMode(Ogre::Animation::IM_SPLINE);
    m_ship_animation_state->setEnabled(true);
    m_ship_animation_state->setLoop(false);

    // Define a grid plane mesh
    Ogre::Plane plane;
    plane.normal = Ogre::Vector3::UNIT_Z;
    plane.d = 200;
    Ogre::MeshManager::getSingleton().createPlane( "GridPlane", Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME,
                                                   plane, 2500, 2500, 1, 1, false, 1, 7, 7, Ogre::Vector3::UNIT_X);

    Ogre::Entity* ent_grid = m_scene_manager->createEntity("grid", "GridPlane");
    ent_grid->setMaterialName("backgrounds/grid");
    m_scene_manager->getRootSceneNode()->createChildSceneNode()->attachObject(ent_grid);

    // set up collision detection system
    m_collision_configuration = new btDefaultCollisionConfiguration;
...
Attachments
grid.zip
the material files
(2.19 KiB) Downloaded 80 times

User avatar
Bigjoe5
Designer and Programmer
Posts: 2058
Joined: Tue Aug 14, 2007 6:33 pm
Location: Orion

Re: Version 0.322 - selection highlighting, grid, ship movement

#49 Post by Bigjoe5 »

On a circular tactical map, a "grid" of circles and spokes would probably be more useful than a square grid, though both should probably be available as toggle-able options.
Warning: Antarans in dimensional portal are closer than they appear.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Version 0.322 - selection highlighting, grid, ship movement

#50 Post by Geoff the Medio »

Bigjoe5 wrote:On a circular tactical map, a "grid" of circles and spokes would probably be more useful than a square grid, though both should probably be available as toggle-able options.
More so, it would be useful to have two concentric rings around each planet that demacate the orbital space around the planet. Stars should probably also have a similar area.

The orbital ring of each planet, there should also be a faint circle that runs through the planet mesh at the appropriate radius.

In the regions where neither planet nor star have orbital space, a background grid could be shown.

Could that be set up? Artist input for mockups and textures would be helpful. Ideal would be a texture with uniformly spaced grid (or just a single grid cell) so things tile properly.
strooka wrote:here is a cleaned up patch of the modifications (without CombatShipTypes, HotKeyManager):
You modified a few ShipPlaced functions to take a different set of parameters for unclear reasons... The originally-passed CombatShipPtr contains a pointer to the ship you replaced it with... so why the change?

There is already a mechanism to add ship nodes to the combat wnd set up, but you seem to have ignored it and instead added a new method involving a direct dependency between CombatSetupWnd and CombatWnd, with the former having a member pointer to the latter... Why?

There is some pathing stuff that adds obstacles for pathing around the star, planets and asteroid belts in the CombatWnd setup, but this ignores the wrapping of this sort of code in #ifdef that's used elsewhere.

You moved ray intersection code between files... why?

The ship animation stuff might be useful. It looks like the added MoveCombatShip function sets the ship's animation stuff so that it will move along a path that was determined by the collision system. Does this animated movement happen automatically over the next few seconds of rendering, without the MoveCombatShip being recalled? If ships are themselves collision objects, and are moving around, doesn't the collision detection and pathing need to update for other ships moving, rather than relying on a path determined based on where things were when the move started? Or is is that already handled automatically? Regardless, if my summary was right, then MoveCombatShip should probably be renamed SetShipMovePathAnimation or somesuch, to more clearly indicate what it does.

Could AddShield be modified, or the shield material be set up, so that the geometry of the shield could be calculated from the passed-in ship geometry? (I don't know what's really possible with this system...)

User avatar
strooka
Space Kraken
Posts: 165
Joined: Tue Jun 23, 2009 5:34 pm
Location: Bielefeld, Germany

Re: Version 0.322 - selection highlighting, grid, ship movement

#51 Post by strooka »

You modified a few ShipPlaced functions to take a different set of parameters for unclear reasons... The originally-passed CombatShipPtr contains a pointer to the ship you replaced it with... so why the change?

There is already a mechanism to add ship nodes to the combat wnd set up, but you seem to have ignored it and instead added a new method involving a direct dependency between CombatSetupWnd and CombatWnd, with the former having a member pointer to the latter... Why?
There can Be only One pathingengine Object which is in Combat wnd. I Need that Object to create à combatShip Structure which is Stores in the any stucture of the Node. So ill have to Call à function in combatwnd that created the Structure. For this Structure i Need the Ship and the Node Object which takes the shipplaced func.
The addship func simply isnt called when placing ships.
I suppose cause it Needs à combatship struct which cant created in combatsetupwnd.
There is some pathing stuff that adds obstacles for pathing around the star, planets and asteroid belts in the CombatWnd setup, but this ignores the wrapping of this sort of code in #ifdef that's used elsewhere.
The ifdefs are old. I wanted to make less changes As possible cause other People work on it , too.
I suppose that i enabled the ifdefs... If you mean the static opensteer obstacles Testung stuff.

You moved ray intersection code between files... why?
You mentioned Not looking for strings if determining weter à Ship and getting the any struct.
But it isn't stored in the Object returned by the Ray intersection.
So i had to make à workaround.

The ship animation stuff might be useful. It looks like the added MoveCombatShip function sets the ship's animation stuff so that it will move along a path that was determined by the collision system. Does this animated movement happen automatically over the next few seconds of rendering, without the MoveCombatShip being recalled?
Yes.
If ships are themselves collision objects, and are moving around, doesn't the collision detection and pathing need to update for other ships moving, rather than relying on a path determined based on where things were when the move started? Or is is that already handled automatically?
we should Set up the Animation System to à Dynamic Position update. If you have 500 ships, the Time between collision Updates and steering Updates should Be longer.
Opensteer always returns wether there is steering needed that will Be made by this func.

Regardless, if my summary was right, then MoveCombatShip should probably be renamed SetShipMovePathAnimation or somesuch, to more clearly indicate what it does.
Ok
Could AddShield be modified, or the shield material be set up, so that the geometry of the shield could be calculated from the passed-in ship geometry? (I don't know what's really possible with this system...)
i have à Material half Ready for this, but i had Problems with the transparency.
Actually i discovered that there are powerful material ediord for this already exist.

[/quote]

Post Reply