Missile implementation on the client

[Florian]

Just a thought: it's already quite hard to attack remote targets with magic, please keep that in mind for the steps necessary to prepare shooting an arrow.

[Roja]

Or should he leave the range mode, turn then enter range mode again...?

 

That's what I would think would happen.

[Entropy]

Just a thought: it's already quite hard to attack remote targets with magic, please keep that in mind for the steps necessary to prepare shooting an arrow.

 

The arrows will be quite powerful, but the dificulty of aiming and firing will make them not be too lethal.

[Schmurk]

Animations:

1. Into bow stance-draw & nock arrow

 

2. Bow stance Idle. From here you either go into animation #3 or #4.

 

3. Out of Bow Stance- arrow is put back and quiver and you go back to player idle.

 

4. Fire & reload-arrow is shot, then immediatey the character takes another arrow from the quiver and puts it on the string. From here you go back into #2.

It's exactly how I see things too but in this case, you need a fifth animation to leave the bow stance after a fire if the player has no more arrows.

 

Do you think this solution is ok for you Ent? With also taking into consideration that the player will certainly have to leave the range mode if he wants to rotate for more than 22.5 degrees...

[Entropy]

If we want to rotate for more than 22.5 degrees, we can just 'cheat' and just rotate the character into that position. I don't think it will look that bad.

[Roja]

The "walk in place" animation should be played if needed to rotate more. I can make one specifically being in the bow stance if needed.

[Roja]

but in this case, you need a fifth animation to leave the bow stance after a fire if the player has no more arrows.

 

 

 

Ok so what I'll do is make a Fire into Player Idle. This isn't bow idle, just normal default player_idle1.

[Schmurk]

Great

 

On my side, I've finished to calibrate the rotations in all directions (in horizontal and vertical) and I've seen in the code how to handle actor commands and how to launch the good animations according to the right command.

 

So now, I just have to add the code to store the new animations and to launch them. Then, we'll need the communication with the server and it should be ok. In any case, if you want to change things later (add or remove animations) I think it should be done quite easily on client side so we can first test a method and if it doesn't work well, we can try another...

 

@Kibora: I'll just add some command numbers on my side (like enter_range_mode, idle_range_mode...) in order to treat them in the next_command() function. I hope it'll not be in conflict with your code. If so, tell me!

[Roja]

The "walk in place" animation should be played if needed to rotate more. I can make one specifically being in the bow stance if needed.

 

 

Is this needed?

[Entropy]

Not sure yet, need to see how it will look without this animation first.

[Florian]

I just updated CVS and this is sooooo cool

 

It's only a matter of time until we finally can throw dung around. (-10 charm)

[BrokenAero]

We will also need the following commands:

1. Go to ranged attack mode (needs a new idle frame for that).

2. Reload bow.

3. Go out of ranged idle mode (into the normal idle).

4. Go from ready to fire mode (aim) into the ranged attack mode (idle)

 

I was thinking about the way you click. More than one click, does seem a little unordained.

 

Just a suggestion on how the clicking may work. (as i have seen it in other games of this type_

 

How about using the "hold /release" button option ?

 

ie:

hold button (initiate load bow)

when target is available for attack (possible succeed on target hit (no obstacles)) server sends ok

<indent>target aquirable then cursor changes to "flash mode" or some icon to signify ready for release

button realease (if aquirable and arrow loaded, initiate attack sequence)

 

I liked the way that Entropy laid out the possible sequences. (1,2,3,4)

 

Being that you may beed the server to "OK" the possibilty of launch. the hold button may give some time to

return an "OK" to the client, so when ready (flash icon/ready icon), the player can release the button.

 

If there was the fact that the target was not able to be fired on (obstacles and such), then, the icon

may be a red X (or some icon signifying not possible). That way, when they release the button,

they are notified that the shot cant be made, or the character returns to a "normal" state.

 

As far as implimenting this into code, seems to be more the if/then/goto scenario.

 

The idea that not everyone is 100ms away, I know all too well.

Including the idea that there may be lossy networks, may be a thought, but, I woudlnt take

away the speed/response of the game for a few players.

 

I hope this may help some. Its my 2 cents worth.

 

P.S. the sound packs send the game into a whole new level of playing experience.(thanks)

[Entropy]

You will only have to click twice on the target the first time you fire, to go into the archery mode (bow loaded and aiming). Subsequent firings will require just one click.

[kibora]

Finally have more time. It seems Schmurk did almost everything already

 

Anyway here's a patch:

https://developer.berlios.de/patch/index.ph...p;group_id=1256

 

Here are the commands we need on the server side so far:

1. ADD_ACTOR_COMMAND enter_range_mode (52)

2. ADD_ACTOR_COMMAND leave_range_mode (53)

3. ADD_ACTOR_COMMAND range_mode_idle (54)

4. MISSILE_AIM_A_AT_B (84) [iD1:2][iD2:2]

5. MISSILE_AIM_A_AT_XYZ (85) [iD:2][X:2][Y:2][Z:2]

6. MISSILE_FIRE_A_TO_B (86) [iD1:2][iD2:2][RELOAD:1]

7. MISSILE_FIRE_A_TO_XYZ (87) [iD:2][X:2][Y:2][Z:2][RELOAD:1]

8. MISSILE_FIRE_XYZ_TO_B (88) [X:2][Y:2][Z:2][iD:2]

 

Did i miss anything?

 

@Schmurk: float target[3] means [X:2][Y:2][Z:2] am i right?

 

edit: fixed a mistake

Edited December 15, 2007 by kibora

[Schmurk]

Finally have more time. It seems Schmurk did almost everything already

 

Anyway here's a patch:

https://developer.berlios.de/patch/index.ph...p;group_id=1256

 

Here are the commands we need on the server side so far:

1. ADD_ACTOR_COMMAND enter_range_mode (52)

2. ADD_ACTOR_COMMAND leave_range_mode (53)

3. ADD_ACTOR_COMMAND range_mode_idle (54)

4. MISSILE_AIM_A_AT_B (84) [iD1:2][iD2:2]

5. MISSILE_AIM_A_AT_XYZ (85) [iD:2][X:2][Y:2][Z:2]

6. MISSILE_FIRE_A_TO_B (86) [iD1:2][iD2:2][RELOAD:1]

7. MISSILE_FIRE_A_TO_XYZ (87) [iD:2][X:2][Y:2][Z:2][RELOAD:1]

8. MISSILE_FIRE_XYZ_TO_B (88) [X:2][Y:2][Z:2][iD:2]

 

Did i miss anything?

 

@Schmurk: float target[3] means [X:2][Y:2][Z:2] am i right?

Ok for me

And AFAIK, a float is 4 bytes, not 2. But before we have to see what kind of coordinates Ent will send us. Will it be world coordinates? Or coordinates expressed in tiles...?

[kibora]

Hmmm yes it's 4. Then why the hell do we use float anyway

[Florian]

The shooting animation has a flicker or twitch at the end. Reproducablility: almost always.

[Entropy]

We need to send floats for world coordinates, that's especially important for when the player misses.

As for the reload thing, it should be sent as a separate command just before the fire.

[Schmurk]

The shooting animation has a flicker or twitch at the end. Reproducablility: almost always.

Does it happen only when the char bones are rotated?

And if yes, does it looks like the char come at the original position for a frame or 2?

 

If yes, I've noticed that too and I have to find why it happens. It's like the rotation I'm applying to bones are not taken in account for every frames...

[Florian]

Does it happen only when the char bones are rotated?

And if yes, does it looks like the char come at the original position for a frame or 2?

Yes!

[Schmurk]

Bug found and corrected

I'll submit the changes later as I've got also a few other things to do on it...

[kibora]

We need to send floats for world coordinates, that's especially important for when the player misses.

As for the reload thing, it should be sent as a separate command just before the fire.

 

So you mean the X,Y,Z coords should be 4 bytes each?

[Entropy]

Yes, floats.

[kibora]

Patch updated

 

New commands are:

1. ADD_ACTOR_COMMAND enter_range_mode (52)

2. ADD_ACTOR_COMMAND leave_range_mode (53)

3. ADD_ACTOR_COMMAND range_mode_idle (54)

4. ADD_ACTOR_COMMAND range_mode_reload (56)

5. MISSILE_AIM_A_AT_B (84) [iD1:2][iD2:2]

6. MISSILE_AIM_A_AT_XYZ (85) [iD:2][X:4][Y:4][Z:4]

7. MISSILE_FIRE_A_TO_B (86) [iD1:2][iD2:2]

8. MISSILE_FIRE_A_TO_XYZ (87) [iD:2][X:4][Y:4][Z:4]

9. MISSILE_FIRE_XYZ_TO_B (88) [X:4][Y:4][Z:4][iD:2]

 

@Schmurk: I made some modifications to your code, related to the range_mode_reload command. Please take a look

Edited December 17, 2007 by kibora

[Schmurk]

We've spoke with Radu yesterday about the actor commands and we've finally came to this:

 

#ifdef MISSILES
 , enter_aim_mode = 52
 , leave_aim_mode = 53
 , range_mode_reload = 54
 , range_mode_fire = 55
#endif // MISSILES

 

It will work as follows:

• * enter_aim_mode: it will be used to enter in range mode and to aim at a player so I'll have to check in the client if the current player is already in range mode in order to do the proper action.
  * leave_aim_mode: will be used to leave the range mode before a fire
  * range_mode_reload: will be send just before a fire to specify if the player will have to reload or not (but I think it is what you've already done in the code)
  * range_mode_fire: will fire an arrow and will reload or leave the mode depending on the previous command.
  

And I did a lot of changes in my code since the last commit and I need to do more to take in account the new commands. So I've seen what you did and it seems ok to me but I'll have to change quite a few things anyway so I'll try to merge our codes

 

BTW, why don't you commit the changes on the CVS? All is #ifdefed so it'll not enter in conflict with current code and it'll be easier to work together than with patches... no?

 

Anyway, I'll be a bit busy this week so I don't know when I'll have time to work on it. I hope to have time to submit my changes before saturday because then I'll be off for several days...