Version 0.322 - selection highlighting, grid, ship movement

[Bigjoe5]

- ships accelerate /deacclerate in One Round if you assign it( this means they Must turn in the approitate direction, also enough turning thrust Left in Case of deaccleration)
- ships have à Turning rate/ max Speed

For these two points, the turning rate and acceleration should not be distinct from the ship's speed. In other words, since all ships can get to max speed in the same amount of time, acceleration is directly proportional to max speed. Ships can apply this acceleration in any direction, provided it doesn't make them exceed their max speed, thus enabling the ship to turn. Acceleration direction is irrelevant to ship facing. Instead, the facing of the ship model should change to conform as closely as possible with the direction of the ship's velocity, without doing dumb-looking things like changing directions instantaneously when a ship turns around.

This also means that when the ship is accelerating, the acceleration value should be constant, rather than having an "acceleration curve".

- ships cannot Crash in each other( until you assign à Kamikaze)

Getting close to a ship and self-destructing should be adequate for kamikaze - there's no need to ever make the ships actually crash.

Anyhow, I think all of us are really glad to finally see some more work being done on the combat engine, particularly since tzlaine has been mostly unavailable (though quite understandably so) recently. Just make sure that what you program conforms to the established design of the game.

[strooka]

nice to hear
i'm on it, i'm on it...
i've just put in 2 point lightning yes, pd you've heared right 2 point lightning
i'll give you the pics tomorrow, if it works.
a heavy duty fps test is also in work - the whole program becomes very slow if every player starts with about 400 shpis.
tomorrow i'll give you the test results, pd.

the next thing in shedule is set up opensteer with an animation ship move. actually it displaces.

lets discuss the movement details:
-the player selects a ship - done.
-the player points to a direction.
how should i implement the movement details?
the easiest way would be:
(- when the grid is active, there could be a direct line painted to the destination point that is updated when the ship changes its position.)
- the evaluating round leasts, say, 10 seconds, or until the player stops the evaluating round to input new orders.

- and the ship would fly with the ship's speed and turn with the ship's speed towards the destination.

- it don't need to reach the destination within the evaluating round - the line would point every time where it flys to.

this is for the programmer (me ) the easiest way to implement the movement and for the player a very attractive way to play.

ok?

[strooka]

For these two points, the turning rate and acceleration should not be distinct from the ship's speed. In other words, since all ships can get to max speed in the same amount of time, acceleration is directly proportional to max speed.

lets discuss an exaple:
ship 1 flys 5 meters/sec ->accleration 1/2 meter
ship 2 flys 10 meters/sec -> accleration 1 meter

theese are examples

do you mean that?

Ships can apply this acceleration in any direction, provided it doesn't make them exceed their max speed,

ship 2 flys with 5 meters/sec in direction (100,0,0)

player points to direction (0,100,0)

= ship 2 flys with 5 meters /sec in direction (100,0,0)
and with 5 meters/sec in direction (0,100,0)
(since it can fly 10 meters/sec)
orientation (100,100,0) ? or (0,100,0) ?

what if ship 2 wlys already with 10 meters/sec ?

it cant change direction.

result: the ship won't fly to the coordinates the player points to.

thus enabling the ship to turn. Acceleration direction is irrelevant to ship facing. Instead, the facing of the ship model should change to conform as closely as possible with the direction of the ship's velocity, without doing dumb-looking things like changing directions instantaneously when a ship turns around.

sorry, ic can't figure out what you want to say.

This also means that when the ship is accelerating, the acceleration value should be constant, rather than having an "acceleration curve".

ok

or do you mean that:
enabling manevour engines:
-the player has pointed the ship to a destination.

-it flys to that destination accourding to its turn speed and
movement speed and acceleration speed.

-then the player wants to evacuate of a, say, non guided missile.

-he clicks another time on the ship enabling the manevour engines and tells the ship to move to the side while flying to its destination- the course will be modified, it becomes a thrust to the side.

this would be cool stuff

[Bigjoe5]

lets discuss an exaple:
ship 1 flys 5 meters/sec ->accleration 1/2 meter
ship 2 flys 10 meters/sec -> accleration 1 meter

A better set of figures would be:

Ship 1 - Maximum Speed: 5 units/round (u/r) - Maximum Acceleration: 5 units/round^2 (u/r^2)
Ship 2 - Maximum Speed: 10 units/round (u/r) - Maximum Acceleration: 10 units/round^2 (u/r^2)

since this means that the ship can reach maximum velocity in a single turn, starting from 0.

"Round" refers to one turn of combat, and is used to avoid confusion with the other sense of the word "turn", which is changing the direction of the ship's velocity.

ship 2 flys with 5 meters/sec in direction (100,0,0)

player points to direction (0,100,0)

= ship 2 flys with 5 meters /sec in direction (100,0,0)
and with 5 meters/sec in direction (0,100,0)
(since it can fly 10 meters/sec)
orientation (100,100,0) ? or (0,100,0) ?

what if ship 2 wlys already with 10 meters/sec ?

it cant change direction.

result: the ship won't fly to the coordinates the player points to.

The player doesn't have direct control over the details of the ship's movement. The player will define a point that he wants the ship to go to, and the ship will go there as efficiently as possible. The player cannot directly control the ship's speed. If a ship is ordered to escort a slower ship, it will automatically slow down to match the speed of the slower ship when it reaches it.

It's probably a lot easier to talk about this in degrees or radians... What you're saying is that the ship is flying straight forward (90 degrees) and is then given a new movement order. To carry out this order, it needs to make a 90 degree turn to the right.

This means it needs to stop moving forward and start moving to the right, which means that it needs to accelerate backwards and to the right (315 degrees). It can only exert an acceleration of 10 u/t^2. Since this acceleration is directed at 315 degrees, both the x and the z components of the acceleration will be less than 10 u/t^2. As such, it will take the ship about 1.4 rounds to complete the turn, at which point it will be moving at full speed to the right: 10 u/t, 0 degrees.

Basically, the ship will always go where it's ordered to go, and it will change the direction of its velocity in the most efficient way possible. There is no difference between turning, and accelerating from 0 to max speed - they are both just a change in velocity accomplished by the ship's acceleration in exactly the same way, and I don't see any good reason to have two separate values/types of acceleration for each ship, one for altering the vector component of velocity, and the other for just altering speed. A single value for acceleration which is used for all changes in a ship's velocity should be adequate, unless it's shown to be otherwise.

Any acceleration that would increase the ship's speed above its maximum is forbidden.

thus enabling the ship to turn. Acceleration direction is irrelevant to ship facing. Instead, the facing of the ship model should change to conform as closely as possible with the direction of the ship's velocity, without doing dumb-looking things like changing directions instantaneously when a ship turns around.

sorry, ic can't figure out what you want to say.

What I'm saying is: don't think of the ship as having an "orientation". It isn't pointing in any particular direction. It has a velocity, and it can change that velocity with acceleration, and the direction of that acceleration is not related in any way to where the ship's engines are. The "orientation" of the ship model itself can be manipulated afterwards to give the impression that the ship's movements aren't arbitrary.

or do you mean that:
enabling manevour engines:
-the player has pointed the ship to a destination.

-it flys to that destination accourding to its turn speed and
movement speed and acceleration speed.

-then the player wants to evacuate of a, say, non guided missile.

-he clicks another time on the ship enabling the manevour engines and tells the ship to move to the side while flying to its destination- the course will be modified, it becomes a thrust to the side.

this would be cool stuff

Since the player can conceivably be controlling thousands of ships in a single battle, detailed control over the ship's movement like that would be bad. The player tells the ship what to do and where, and the ship figures out how to use its acceleration optimally to get there.

lets discuss the movement details:
-the player selects a ship - done.
-the player points to a direction.
how should i implement the movement details?
the easiest way would be:
(- when the grid is active, there could be a direct line painted to the destination point that is updated when the ship changes its position.)
- the evaluating round leasts, say, 10 seconds, or until the player stops the evaluating round to input new orders.

The turn, or "evaluating round", lasts 3-5 seconds (I'd say 3 for now), assuming optimal fps. There doesn't need to be a line between the ship and its destination. Whatever the selected ship's immediate target is can be highlighted, whether it's a ship that it has been ordered to attack, or a point in space that it has been ordered to move to.

- and the ship would fly with the ship's speed and turn with the ship's speed towards the destination.

If by this you mean that "the ship moves to its destination as efficiently as possible", then yes, that's fine. If the ship has been ordered to attack another ship, it should try to stay within weapons range of that ship (different attack orders for ships can be added later, and will have to integrate some sort of individual-ship AI).

- it don't need to reach the destination within the evaluating round

That's right.

edit: If you would really rather simulate some kind of "traction" in space for turning, that's OK, but all ships should still be able to make a particular turn in the same amount of time, regardless of max speed.

[strooka]

I've Found out how to Move ships. it took me à while to figure out that of the buggy Code and the ogre implementation. Also i've Found out how to Import all the mc2 meshes.
There seems to Be à function to implement à Grid in ogre.
The Space Combat is already alike Ground Combat (2D) i could simply define a Ground and we have à Ground Combat with mechs.
This would Be much more than yet is implemented, the Code modifications are so Large that i cant Sent it all in One file. Also my hotkey implementation wasnt added to the project, too, so Why post it?
I Need Save Access to the svn Database, then ill send a Major update.

[Geoff the Medio]

I...the Code modifications are so Large that i cant Sent it all in One file.

Do an svn diff to make a patch, and if necessary zip the patch. If you're really adding so much code that you can't post a patch that contains it all, then you're trying to add too much at once and need to post more frequent smaller updates that do less.

Your code contributions still need to be reviewed before they'll be committed to SVN, so you don't need SVN write access.

[strooka]

I think before i commit the Patch i should figure out à correct Client - Server Communication to commit à Fight, or you cant Play the Game anymore.

[Geoff the Medio]

I think before i commit the Patch i should figure out à correct Client - Server Communication to commit à Fight, or you cant Play the Game anymore.

Could you post a patch now that has just the graphical additions and changes?

[strooka]

well - here it is.
i just copied all files to the zip file which are modified or touched.
some files could have no change.
note that i disabled the auto combat by mistake - i did a class of it and that didn't function anymore - if any combat starts it wouldn't end.
if you call

Code: Select all

m_fsm.post_event(CombatComplete());

in

Code: Select all

void ServerApp::ProcessCombats()

at the end of the function, the 3d combat will start for a second and end.

i added a class where one can change some ship parameters by config file - CombatShipTypes.cpp.

there need still some hands laid on the movement.
but a basic movement is given.

[strooka]

Code: Select all

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

    Ogre::Vector3 DIRECTION = destination - ship_data.m_node->getPosition();
    Ogre::Vector3 start_pos = ship_data.m_node->getPosition();

    m_ship_animation_state->setTimePosition(0.0);
    Ogre::NodeAnimationTrack* track =
        m_ship_animation->createNodeTrack(0, ship_data.m_node);

    const int STEPS = 14;

    Ogre::TransformKeyFrame* key = track->createNodeKeyFrame(0);
    key->setTranslate(start_pos);
    key = track->createNodeKeyFrame(0.25 * ship.MaxCombatSpeed());
    key->setTranslate(destination);
    key->setRotation(Ogre::Quaternion(&Ogre::Vector3(destination.x, destination.y, 0)));
     // m_ship_animation_state->setEnabled(true);
    OpenSteer::Vec3 orientation(ship_data.m_node->getOrientation().x, ship_data.m_node->getOrientation().y, ship_data.m_node->getOrientation().z);
    combat_ship.Init(ToOpenSteer(destination), orientation);

    ship_data.m_bt_object->getWorldTransform().setOrigin(ToCollision(ship_data.m_node->getPosition()));
}

This is the funtionizing move ship function.

as ship speed you should set a variable near or equal 1, it reaches its destination after clicking on it.

i haven't found out , though why i shall click only on the first position where the ship started when doing further moves.

[pd]

Didn't you change the ship shader files as well?

[strooka]

all ive foud out is that the whole ship can be hilighted.
there are two sides asembled, but in the fragment processor it's is only the whole ship processed i suppose.
i think the non hilighted side could be accesssed though gl_BackColor.

[Geoff the Medio]

Didn't you change the ship shader files as well?

There are some additions to ship.frag in the diff file, but they're commented out.

There are uncommented-out additions to ship.material for shields, which is also referenced in the c++ code additions.

There are also some uncommented-out additions to ship.material for selected objects. I'm not sure if something related is already used in the existing code, but I didn't see it being added, though might have missed it.

There's also a bunch of additions about moving ships, which seems to be done with some animations along a spline after client-side pathfinding from the current to desried location. All this is probably not useful as it's currently written, because combat system will operate via communication with the server, which will determine the locations of ships and other objects in combat each round, with the client just displaying the results and letting the player give combat orders. Client-side pathfinding will still be necessary though, as the player needs to be shown what path ships will take if ordered to move. Some client-side animation along server-determine pathes will also be necessary, as I think the server is only going to be sending state updates to clients once per round, so the clients will do interpolation / animation of movement between round updates.

There's also some skybox stuff added. I'm not sure what the point of that is...? Is there something wrong with the existing skybox implementation? Or did it add a new feature to the skybox?

There's some ship placement stuff that's probably redundant with tzlaine's recent additions, and lacked necessary server-interaction.

If some of the graphical stuff can be cleaned up / uncommented and explained, it might be useful.

[strooka]

here is a nearly complete pathfinding implementation of the move ship function:

Code: Select all

void CombatWnd::MoveShip(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::Quaternion dest_quat_direction(Ogre::Vector3(0,0,0), dest_vec_direction, Ogre::Vector3(0,0,0));
    dest_quat_direction.normalise();

    ///the turn rate may not be greater than 1 - 1 means the ship can fly any curve in one round
    dest_quat_direction = dest_quat_direction * ship.TurnRate();


    Ogre::Vector3 vec_start_pos = ship_data.m_node->getPosition();

    //TODO:add opensteer code here to find a path
    combat_ship->Init(ToOpenSteer(destination), ToOpenSteer(dest_vec_direction));

    m_ship_animation_state->setTimePosition(0.0);
    Ogre::NodeAnimationTrack* track =
        m_ship_animation->createNodeTrack(0, ship_data.m_node);

    Ogre::TransformKeyFrame* key = track->createNodeKeyFrame(0);
    key->setTranslate(vec_start_pos);
    key->setRotation(start_quat_direction);

    key = track->createNodeKeyFrame(0.25 * ship.MaxCombatSpeed());
    key->setTranslate(destination);
    key->setRotation(dest_quat_direction);

    m_collision_world->getCollisionObjectArray().remove(ship_data.m_bt_object);
    ship_data.m_bt_object->getWorldTransform().setOrigin(ToCollision(destination));
    m_collision_world->addCollisionObject(ship_data.m_bt_object);
}

i'm arware that there shall be a client - server communication with ship movement. this function takes a combat ship pointer, wich is being added to every SceneNode in the scene.
this would be the next step after implementing the grid.

ships shields are functioning, skybox stuff was just a try to that there were a starfield background wanted.

note that the client has to display ship moving and that is implemented here . the server just defines the destination where the ship moves - as long i have comprehended it - and there is an implementation of opensteer, which seems to set server side the paths of the ships - but the animation has to be made by the client and that's what it's done here.

what is rdundant that is an implementation of the class CombatShipTypes.cpp, which defines just the ships behaviour for testing issues - it will be deleted in future implementations.
in opensteer there is also an implementation of the ships speed etc, but it is set to default values.
there should be an implementation of the shipdesign class in the future.

this version of the code works nearly to 100% - the only bugs are double selecting of ships which let the program crash - there is already an implementation of selecting, but one clicking and dragging doesn't work.
and there is a bug - ships sometimes flip to the back if you move them into some directions.
hilighting is also already implemented by tzlane, i reused it like at the planets.

this paths which are defined by the ship move function let the ship directly move to the destination - if there shall be a more complicated path defined - i agree you - then this should be made server side.

my next steps will be displaying a grid and display of an laser shot and explosion.

then i think we can fix it all together by implementing a correct client - server communication and run some tests.

what i can't really do is to reactivate the single left click and drag, because the program is ok, and i don't know why the approitate functions aren't called.

[pd]

what i can't really do is to reactivate the single left click and drag

As mentioned, check out tzlaine's latest commits - especially this one.