Massokre's Classic Discussion (split from Warning about graalians.com)

[Lyndzey]

Originally Posted by Tyhm

It's ironic that projectiles were designed to be used with Classic Style Arrows, and that last check they didn't work with Classic's "Firing Through This Wall" genre. IMHO arrows ought to bounce of certain walls and soar over certain obstacles (bushes, pits, fences), but that's a fair degree of coding that ultimately isn't worth it.
Well, maybe not. onwall and in(this set of statically defined "wall" ids) takes about as much effort. Maybe more processor time? Who knows.
An ordered In would take log(n) time to burn through, on the other hand, but then we find ourselves asking for Stefan to create another command just to make Classic's arrows work a skoch better. It's all very silly.

Come back

[Polo]

Originally Posted by Tyhm

It's ironic that projectiles were designed to be used with Classic Style Arrows, and that last check they didn't work with Classic's "Firing Through This Wall" genre. IMHO arrows ought to bounce of certain walls and soar over certain obstacles (bushes, pits, fences), but that's a fair degree of coding that ultimately isn't worth it.
Well, maybe not. onwall and in(this set of statically defined "wall" ids) takes about as much effort. Maybe more processor time? Who knows.
An ordered In would take log(n) time to burn through, on the other hand, but then we find ourselves asking for Stefan to create another command just to make Classic's arrows work a skoch better. It's all very silly.

You also have the major problem that to hit a moving target, you'd need a 0.05 second timeout, which is somthing we should be avoiding on serverside.

[nikomi946]

First rule of marketing, bad publicity is better than no publicity. I'd like to thank you all for steadily increasing playercount from as low as 0 up to 35 to 60 with this thread.

[jake13jake]

Originally Posted by Polo

You also have the major problem that to hit a moving target, you'd need a 0.05 second timeout, which is somthing we should be avoiding on serverside.

According to the newfeatures.txt I read, the shoot function triggers the clients and then the movement on each of the clients is the movement is controlled individually by the clients. In essence, the only difference between I clientside arrow and a serverside arrow is that everyone will see the arrow in the proper starting location. If there is a clientside object in front of the player, the arrow will stop at the object rather than hitting the player. If another player was on the same position as the other without seeing that same clientside object, that player would be hit by the arrow.

So in all senses, it's pointless to say that the only way to shoot arrows securely is to use the shoot command serverside. We could always make a new shoot command that does the same thing, but recognizes only objects instead of walls, like the clientside shoot(@arrowtype) commands do. The only thing we wouldn't be able to. So, when you trigger the client, all you'd need to do is send x,y,dx/.05,dy/.05,owner,image... whatever you'd need it to send.

So Storm, how about redoing the projectile system?

Add: In any sense, for stuff with irregular movement, we could make different movement parameter types that would call a class that defines the path for the type of movement

As for the structures I thought of that would put damage leaps and bounds beyond where it is now, try to remind me the next time you have time.

Euhh.. also remind me to ask you about level links in quests.

[Tyhm]

Originally Posted by Lyndzey

Come back

As much as I'd love to oblige, it's murder on my social life - I so much as log on, find myself inexorably romantically tied to one Graalian of my past or another, fritter away roundabout two years waiting for it to bloom and eventually realize everyone's laughing at me.

Originally Posted by Polo

You also have the major problem that to hit a moving target, you'd need a 0.05 second timeout, which is somthing we should be avoiding on serverside.

I always thought that was humorous. This is a bit tricky to code, but try and keep up on the concept:
Tyhm enters a room.
From 30.5,30, facing 0, he fires an Arrow at server time index 12345600. This checks the next likely wall (let's say at y=10) and sets the server string for it.
Every client then recieves "30.5,30,0,12345600,10" and extrapolates:
30.5,29,123456001;
30.5,28,123456002;
30.5,27,123456003;
30.5,26,123456004;
and so on until it hits the wall. Every client sees the arrow flying and, if they intercept it, they take the damage.
The tricky bit is if a client is hit, that changes when the arrow hit a wall and you have to tell everyone in the room not to worry about that projectile anymore. Further, it makes octoballs a little tricky (but not much: dir*90 gives you the angle clockwise from N, so we could just store it all that way), and rooms that spam Way Too Many Projectiles get complicated...but maybe not too complicated. Major complication - you still have to trust the clients to recieve their damage, much in the same way you have to trust the clients to tell the truth about what walls they've walked through. Possible solution - hit the client occasionally to keep it honest. With blanks, maybe, I dunno, tell the client it's about to be shot and see if it accepts it and reports back with damage, then heal it and let it be. Maybe that'd be a GP tool, the Inescapable Arrow that Definitely Hits Any Player That Isn't Cheating And Jails Any Player That It Somehow Misses. I dunno, it all got too complicated for me a long time ago.

Anyone watching - this is why Classic's taking so long, it's not as easy as "Just upload the old levels, OMG!", everything needs to be coded for serverside compatibility. If you don't like it, Stefan's the man to talk to, he's the one who implemented the security that effectively ended good old simplified (if painfully buggy and easily exploited) clientside scripting.

Still don't see why signs ever became serverside...

[jake13jake]

Originally Posted by Tyhm

Still don't see why signs ever became serverside...

Well, I've been told because they can display variables, but so can <graalmsg>
It would be better if you could just script predefined level objects without using NPCs. Like, some kind of script access per server of how the .nw syntax is read. It's easier to browse through a level in wordpad that way and edit things manually. Tyhm, I don't know why level links aren't controled by the NPC Server.

it would be cool if you could manipulate syntax to accept classes you've made for baddies that pass parameters to the baddy script, or any custom syntax. It would really improve the readability of the level file.

MYBADDY params
line1...
line2...
line3...
MYBADDYEND

KEYDOOR x y ID

ADD: Although Tyhm, writing a script to replace the sign, baddy, and link syntaxes with NPCs would be quite easy. Could do it in Java, don't know enough of the C++ library to be do it in C++ though, which I would prefer.

[Polo]

Originally Posted by Tyhm

...Interpolation Stuff...

I had considered somthing like this before, but when players are laggy, then multiple people would get hit, or people would appear to be cheating. For example, one person gets hit on thier screen, but they are laggy, before they can tell the server to quash the arrow, it hits 3 more people.

[jake13jake]

Originally Posted by Polo

I had considered somthing like this before, but when players are laggy, then multiple people would get hit, or people would appear to be cheating. For example, one person gets hit on thier screen, but they are laggy, before they can tell the server to quash the arrow, it hits 3 more people.

Storm, did you read my post? The clients destroy the arrows -_-.

[Tyhm]

Originally Posted by jake13jake

Storm, did you read my post? The clients destroy the arrows -_-.

I don't see the connection.
And he has a point (I think I touched on this) - it ain't perfect. But that's lag. If an arrow goes through one guy to three others once in a while, euh. I'm more concerned with how we have to trust the player to be honest about getting hit.

[DarkCloud_PK]

Originally Posted by Tyhm

Pish, like I need your permission. I'm an Emeritus, by my own regulations I can return whenever I feel like it. (But I wouldn't do that to you, so don't sweat it)

Excellent, I'm returning to FAQ/Special Ops post haste on this note.

[jake13jake]

Originally Posted by Tyhm

I don't see the connection.
And he has a point (I think I touched on this) - it ain't perfect. But that's lag. If an arrow goes through one guy to three others once in a while, euh. I'm more concerned with how we have to trust the player to be honest about getting hit.

From the 2002 newfeatures.txt file:
"Projectiles are easy to use and don't take a lot of bandwidth because only the shooting of the projectile needs to be sent, the movement is calculated on the different computers."

In all cases, you can't trust movement scripts. You can, however, determine whether the packets being sent back to the server by a player make any sense. Let's say on one client, the projectile hits a fellow player. That client can then tell the server that the player was hit, as well as a bunch of other clients. If the majority clients say the player was hit, but the player never gets hit, you can just echo it to RC, "player not hit by arrow." Then again, there's the possibility that the player had a clientside object blocking the arrow from hitting him/her. In any case, there's no way of making it perfect, but you can perform checks for anything that might be out of place.

Yea, and Tyhm, doing arrows in the way you described would not leave room for a clientside object blocking the player from the arrow.

[Tyhm]

Then clientside objects ought not be allowed to block the player from arrows. Or perhaps more to the point, objects ought not be allowed to block the player from arrows on clientside. If a permanent or immovable barrier is put up, it ought to tell the server about itself; if a player has a shield of some sort, he was still "hit" by the arrow, it just did no damage nor did it hinder him, and such ought be accounted for.

But I digress - the point is, these growing pains are felt on every server as it develops unnecessarily. G2K1 had these problems, and what have we learned from their toil? Zilch. Why?

[jake13jake]

Originally Posted by Tyhm

Then clientside objects ought not be allowed to block the player from arrows. Or perhaps more to the point, objects ought not be allowed to block the player from arrows on clientside. If a permanent or immovable barrier is put up, it ought to tell the server about itself; if a player has a shield of some sort, he was still "hit" by the arrow, it just did no damage nor did it hinder him, and such ought be accounted for.

But I digress - the point is, these growing pains are felt on every server as it develops unnecessarily. G2K1 had these problems, and what have we learned from their toil? Zilch. Why?

Shields are controlled by the player's direction, and the player's direction can be changed directly clientside... thus it's flawed. Permanent/immovable barriers are generally not the case for clientside objects that might block the player from getting hit. I'm just trying to demonstrate how it would always be flawed no matter what way you did it.

[Tyhm]

Sure. It's just a question of finding the least flawed or most acceptable solution. But my point is that other servers have coded systems that work, and the writers (particularly Stefan-like ones) would probably be willing to share their wealth of knowledge if there was a database/distro/library, but there isn't.

[jake13jake]

Originally Posted by Tyhm

Sure. It's just a question of finding the least flawed or most acceptable solution. But my point is that other servers have coded systems that work, and the writers (particularly Stefan-like ones) would probably be willing to share their wealth of knowledge if there was a database/distro/library, but there isn't.

???
My control_movement and a few other scripts of mine are at graal.net...