Jump to content
Eternal Lands Official Forums
Entropy

Missile implementation on the client

Recommended Posts

Have you ever played, say... Tie Fighter, or X-Wing?

darn i miss those games!

 

i agree something would be needed to tone down archery, and being abled to evade the 'lock on' would defenitly help. archery is WAY overpowered in alot of MMORPGs, and some other games imo. everything needs to have some neg, otherwise you can just sit in the KF fort with an automatic bow, shooting out 6 shots a second mowing down everyone from safe behind a wall ;)

and even toned down it will still be a sweet skill :lurker:

 

~1st

Share this post


Link to post
Share on other sites

The thing with having to click twice compared to as say a cooldown fire rate is the fact that on first hand experience I've had to spend 10 seconds chasing down a target to initiate combat. Sometimes those damned things just don't sit still.

 

To balance it a little bit more you could have:

Click once - check if in range (If not, display a Get closer message or whatever)

Animation of drawing and nocking the area

Recheck the distance (say the animation takes 1 second). That gives a second for the intended target to move off screen, or out of range. Then let a 7 second cooldown initiate.

 

To determine whether they initiate or flee could be whether they ignore you or not. Non-aggressive creatures would just kind of walk around as usual. (Maybe have bears and stronger initiate?). And if it's for PK, the player themselves have to go for whatever they're going for. An arrow is just added damage (though maybe display a "Your getting attacked by ****" message?)

 

Though what if an object like a hedge maze is in your way? It's not logical for you not to be able to shoot the arrow because it's a hedge maze, but I would think that would present some problems to the server, no?

Edited by Aerowind

Share this post


Link to post
Share on other sites
(though maybe display a "Your getting attacked by ****" message?)
nonono. then you spoil the fun of a sniper with a really high perception and a good distance :)

if they're close enough to see easily, then who's attacking you would work. otherwise a direction (in both cases, a perception (and maybe direction facing) check could be done to see if you'd be able to tell where it came from)

Share this post


Link to post
Share on other sites
(though maybe display a "Your getting attacked by ****" message?)
nonono. then you spoil the fun of a sniper with a really high perception and a good distance :P

if they're close enough to see easily, then who's attacking you would work. otherwise a direction (in both cases, a perception (and maybe direction facing) check could be done to see if you'd be able to tell where it came from)

 

Heh, that's why I phrased it as a question. Though it would be cool if perhaps your out of range of their site and all it says is "Your being attacked from the North-west" or something. Makes better use of the compass :)

Share this post


Link to post
Share on other sites

Such a message would be totally stupid and pointless.

Anyway, this is in the programming forum, so please no more non programming talk about it.

Share this post


Link to post
Share on other sites

Yes, aiming is neccesary for technical reasons and also for game ballance. If you could shoot a bow at a [semi]automatic rate, then the bows would be too powerful (and look stupid).

 

Oh, and one more thing: When you aim, you will automatically turn to face the target. You will have to fire while you are still facing the target, or else you will need to aim again (makes sense, no?).

How do you determine what is shooting, and what is reaiming? I see 2 options.

 

The first would be to aim with one style of click (eg. second button) and fire with another (eg. first button). This would be practical from a speed point of view (firing before the target is lost), but currently the second mouse button is used to change the cursor so an alternative would need to be developed. This would allow you to easily reaim several times (several targets) before firing, or alternatively fire without reaiming, and miss, which would be more accurate.

 

The second is the option described at the top of this thread. You would aim with the first button and fire with the same button (clicking twice). The first click would cause the client to aim (4) then the second would fire (5).

What if you are no longer aimed correctly, would the second click reaim? If it did, then I think it would be far too easy as it would just be a matter of keeping on clicking until you fire.

 

Personally I prefer the idea of the first option as it requires a bit more skill than just continually clicking and effectivly automatically aiming, however the client implementation of 2 types of click is a problem.

 

 

/edit:

Made things a little more clear (I hope).

Edited by Torg

Share this post


Link to post
Share on other sites

You aim the same way as you attack someone (the server will be context sensitive, depending on what you have in your hand). You fire by repeating the same process.

Share this post


Link to post
Share on other sites

instead of showing an arrow 'object' hurling through the air, maybe it would be more practical (due to the insignificantly short time the arrow would be in the air, plus problems with matching arrow height [on actor and 'airbourne' arrows]) to have some kind of 'Matrix' esque effect..showing some kind of air disturbance where the arrow has flown...just an idea. perhaps the vapour trails could linger and dissipate...not what happens in RL...but hell there aint no dragons or leprechauns neither.

 

I think this is an excellent idea, some form of disturbance rather than an arrow, this means you won't need to alter it if you introduce other missile weapons...

 

Crossbows, the different type of arrows - I imagine Steel, Bronze, Titanium, Iron and maybe plain wood and possibly other missle types (slings + stones perhaps :P bolt guns, throwable javelins, the ability to throw a single stone...) exciting times ahead!!

 

:P

 

I think only the lighter metals should be used to make the arrows and the bow, or maybe heavier arrows would be more likely to fail target but more damage?

Edited by Bahamut_Zero

Share this post


Link to post
Share on other sites

Bump.

 

The point of this thread was looking for somebody to add missile support to client, it seems you have overlooked it if there isn't anybody to work at the client side part of it.

 

It would be nice to get this to next/next of next client update.

Share this post


Link to post
Share on other sites

The point of this thread was looking for somebody to add missile support to client, it seems you have overlooked it if there isn't anybody to work at the client side part of it.

 

It certainly never was overlooked. You have to understand that in development of a project that there are many things to do for it. Everyone has sides to it that they are well versed in working on and some not. Also don't forget about the fact that there are actually very few people working on this project, and many come and go.

Share this post


Link to post
Share on other sites
The point of this thread was looking for somebody to add missile support to client, it seems you have overlooked it if there isn't anybody to work at the client side part of it.

 

It would be nice to get this to next/next of next client update.

I certainly haven't forgotten this, but simply put I'm scared of it. There is a bunch of work invovled that I've never done before so it has a steep learning curve for me.

 

If you've read the "Roadmap to 1.5" thread you would know that I'm also responsible for NEW_SOUND and MINES. I simply don't have the base understanding, or the time to learn.

 

I was however discussing with Xaphier yesterday some of the code he has that will help to implement this. He suggested he could implement that code when he finishes what he's working on, so it is still in the back of our minds.

 

The idea behind this thread was to catch the attention of someone who might be interested but doesn't know about the need for help in this area. This generally implies someone that isn't currently working on the client. As it turns out there isn't anyone willing to try and as Roja said there are very few people working on the client at the moment and we are all busy/don't have time.

Share this post


Link to post
Share on other sites

I thought a bit about this and here's a possible implementation. Any suggestions?

 

List of new "server to client" messages. ":2" means 2 bytes.

 

Protocol number: Params

1. MISSILE_AIM (84): [iD:2][X:2][Y:2][Z:2]

2. MISSILE_A_TO_B (85): [iD1:2][iD2:2]

3. MISSILE_A_TO_XYZ (86): [iD:2][X:2][Y:2][Z:2]

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

5. MISSILE_XYZ_TO_XYZ (88): [X1:2][Y1:2][Z1:2][X2:2][Y2:2][Z2:2]

 

Another possiblity is to merge messages 2-5 in a single one.

 

I don't really see a reason to have the following messages. Do we really need them?

3. The server will send one of the two messages: 1. OK, 2. Not OK

5. You click again on that entity, and the server again sends OK or not OK.

Share this post


Link to post
Share on other sites
Protocol number: Params

1. MISSILE_AIM (84): [iD:2][X:2][Y:2][Z:2]

2. MISSILE_A_TO_B (85): [iD1:2][iD2:2]

3. MISSILE_A_TO_XYZ (86): [iD:2][X:2][Y:2][Z:2]

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

5. MISSILE_XYZ_TO_XYZ (88): [X1:2][Y1:2][Z1:2][X2:2][Y2:2][Z2:2]

Hum, not sure but maybe something like "MISSILE_AIM: [iD:2][iD:2]" will be needed.

BTW, before aiming, the char will have to turn in the good direction in order I can then apply the exact rotation. I think this action must be done by a call of the actual char rotation command and not be part of the aim command...

 

BTW again, how far in the code have you planned to go Kibora? Launch a new actor command after reception of a server message? Or do you also plan to code the new commands in order to execute the good animations and such things...?

It's just to know in order we don't do the same thing :D

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

Hum, so how many animations are required in total?

And how many of them have to be modified?

Depending on the type of the animations, they'll not be stored at the same place. If the animation have to be modified, it will be stored directly in the actor structure. In the other case, it will be stored in the actor_type structure.

 

So according to what you're saying, there'll be the following animations:

- go to ranged attack mode

- idle in ranged attack mode

- go out of ranged attack mode

- aim (turn the char in the good direction => need to modify the keyframe)

- fire (need to modify the keyframe as well)

- reload the bow (when?)

 

Is that right?

 

If yes, maybe that the reload action should be done directly inside the firing animation, at the end of it. In this case, the end of the animation will match the idle animation...?

The only problem is that if the char is out of arrows, he can't reload so there must be one more animation to exit ranged mode just after fire... So it's starting to be a bit complex.

 

But, IIRC, haven't you said some time ago that the player will not be able to fire arrows like a "machine gun"? And that he will have to first aim then shoot?

 

In this case, I thought it would be more like this:

- go to ranged attack mode, load an arrow and aim (modified animation)

- idle during aim (modified animation)

- exit ranged attack mode without firing (modified animation because of aim position)

- fire an arrow and leave ranged attack mode (modified animation because of aim position)

 

Can you explain more precisely how do you see things because I thought it was second solution so I'm a bit confused after your post or maybe I misunderstood what you said... :D

Share this post


Link to post
Share on other sites

Ok, well, I am not sure yet what is the best way to do it, so I am still open to feedback.

 

But here is how I think it will be best, in pseudocode:

Server sends "go into range mode"
Client then goes into the ranged idle frame
Server sends "load bow" (when the player equips an arrow as a weapon)
Client puts the arrow into the bow and goes to "bow loaded" idle.
If server sends "unequip arrow" (to change the arrow type, for example)
Client executes "unload bow" and goes to "range mode" idle
If server sends: "aim"
The client will execute the aim animation (which will be moving bones and stuff)
If server sends "fire"
The client executes the fire animation (but does not reload the bow unless if the server tells it to do so)
If the server sends "abort fire"
The client returns to the idle ranged animation, with the bow loaded.
If the server sends "return to normal combat mode" the client will have to return to the normal idle mode (client might also have to unload the bow if loaded, and unaim if aimed). However, this needs to be further discussed, for example if we allow the client to go directly from "ready to fire" mode to "put the bow down" mode.

Again, this is just a suggestion, if you think there is a better way, please let me know.

Share this post


Link to post
Share on other sites

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)

Hmmm having all these commands (ADD_ACTOR_COMMAND?) is a prerequisite for the animations to get out of sync. Perhaps only 2 would be enough:

 

1. Equip ranged weapon

2. Unequip ranged weapon

 

The other animations could be just part of the other commands as Schmurk suggested. For example the load arrow could be part of the "fire" command, if the animation is fast enough. In such case there's no need for "reaload" command, since the load is part of the fire command

 

As for "MISSILE_AIM (84): [iD:2][X:2][Y:2][Z:2]" perhaps there should be 4 commands for this, just like the MISSILE_X_TO_Y commands, to cover both player IDs and [X][Y][Z] coords.

Share this post


Link to post
Share on other sites
Ok, well, I am not sure yet what is the best way to do it, so I am still open to feedback.

 

But here is how I think it will be best, in pseudocode:

Server sends "go into range mode"
Client then goes into the ranged idle frame
Server sends "load bow" (when the player equips an arrow as a weapon)
Client puts the arrow into the bow and goes to "bow loaded" idle.
If server sends "unequip arrow" (to change the arrow type, for example)
Client executes "unload bow" and goes to "range mode" idle
If server sends: "aim"
The client will execute the aim animation (which will be moving bones and stuff)
If server sends "fire"
The client executes the fire animation (but does not reload the bow unless if the server tells it to do so)
If the server sends "abort fire"
The client returns to the idle ranged animation, with the bow loaded.
If the server sends "return to normal combat mode" the client will have to return to the normal idle mode (client might also have to unload the bow if loaded, and unaim if aimed). However, this needs to be further discussed, for example if we allow the client to go directly from "ready to fire" mode to "put the bow down" mode.

Again, this is just a suggestion, if you think there is a better way, please let me know.

I think that all of this depends on the possibility for the player to fire several arrows while he is in range mode or if he can fire only one arrow and then leaves the mode.

BTW, what kind of posture the char will have when he is in idle mode with no arrow loaded? Will he have a hand on an arrow ready to be loaded or something like that? And how the player will enter this mode?

And a last question, what will be the equipped items? Only a bow and a quiver or also arrows...?

Sorry for all these questions but I think that there are many things that will have to be taken in consideration in order to find a good solution and I think we should discuss about them before...

 

For my part, I don't really see the use of an idle mode with no arrow loaded because it's quite the same than the normal idle mode outside of combat. So I think that if the player goes in range mode, he should load an arrow automatically and if he has no more arrow, he leaves the mode. When he fires an arrow, he loads a new one just after.

And finally, in the case he wants to change the arrows, he leaves the mode, equips the good arrows and enters the mode again.

Out of that, the aiming command can tell the client to rotate the bones in order to be in the good direction even if the previous position was aiming something else.

 

So if I update what I said some posts before and if I add the possibility to fire several arrows while staying in range mode, I see the following possible actions:

- enter in range mode, load an arrow and aim

- leave range mode before fire

- idle with an arrow loaded

- aim again: rotate the char from a position to another

- fire and load a new arrow

- fire and leave mode if no more arrow

 

Note that all the corresponding animations will be specific to each char due to the aiming position and note that aiming while doing an action cost nothing at all because the rotation is done during the animation itself.

 

Now, I'm not totally aware of all out of syncs problems and such things so if doing several actions during the same animation (like "entering in range mode + loading" or "firing + loading") can cause such problems, maybe your solution is better.

Share this post


Link to post
Share on other sites

Hmm, ok, I guess you do have a point that we don't need two ranged idles (one with the arrow loaded, and one without the arrow loaded).

But I don't really want the client to auto reload, because the client can't reliably know if it is out of arrows or not.

Share this post


Link to post
Share on other sites
But I don't really want the client to auto reload, because the client can't reliably know if it is out of arrows or not.
Good point! :lipssealed:

I didn't think to that...

 

Maybe the fire command can give this information?

Share this post


Link to post
Share on other sites
Or just send it RIGHT after the fire command.

Not if the fire and reload actions are in the same animation. In this case, the information should be given by the fire command because it will say the client which animation it should play, the reload one or the leave range mode one...

 

BTW, there's maybe another problem that I just thought about. What do we do when the player want to change his target and he has to turn in a completely different direction? Do we rotate him directly or do we use an animation for that? Or should he leave the range mode, turn then enter range mode again...?

Share this post


Link to post
Share on other sites

I didn't read through all your posts because it's getting a bit confusing. But I need to know for sure what animations I need to make.

So here is how I see things:

 

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.

 

+ another set of 4 for the crossbow(as it'll need different animations)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×