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.

[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 -_-.

[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.

[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...

[Tyhm]

But are the arrow scripts and so forth from G2K1?
One would think that given Classic's lofty position it would have been possible for someone like myself to get a hold of them back when the conversion first started but noo...

[jake13jake]

Classic News: Once v2 is disabled, we'll have beer w/ drunk movement again. It's my personal replication of the old drunk movement, but using my control_movement it doesn't take you through walls.

Master Storm uploaded Jay's House, and I uploaded the Babord Floating House. Both have been moved to Graal City, north of the river take a right after the bridge.

MoD Fort was put up, and more recently the flag was put up (I'll probably script today). I was rather shocked that when I massed for ideas of how I should script it, there was a major disinterest in the idea of guild warring (which shouldn't have surprised me with the way global guilds are). I decided that this is just one way that Graal's social environment has changed, and has led me to propose an eventual move to support only local guilds (haven't talked to Storm about it yet, but it wouldn't be smart to do it immediately anyway). Because of this, I will probably just script it the way it used to be.

The first major quest is nearing completion. The only room that needs to be made is the boss room. Other than that, there's only one non-security related script left to be made within the quest.

Exodus has been working on expanding the overworld into a continent. The biggest problem he's encountered, to my knowledge, is correcting the mountain's proportions.

Seize (who was temporarily assigned Nimda Island), is now the seventh person (EDIT: well, eighth actually) I've assigned to create the Gnome Caves, will hopefully create the Gnome Caves.

The person assigned the Kull's Castle Interior so long ago simply abandoned it with like three rooms. So I'm going to reassign it to Racil (Who was temporarily assigned the desert island) the next time I encounter him online.

To Storm:
I suppose I can contact you this way.
My new movement system is almost done (I figure you will help with this and implement it). It doesn't take too long, like I said, don't know why you've been taking so long.

A few things:
- (nevermind, used player.ani == client.walk_gani) system_gani still needs to turn off system_action in certain cases. Unless you want to send precedence exceptions in parameters, this will probably remove grab/pull while in beds
- (nevermind, done) system_keys still needs to somehow interact with system_action to grab something (could have done it in the action system, but it made more sense to put it in the keys system). It also somehow hates me when using the movement handling vars.
- (nevermind, done) want to eliminate all -1s from the internal movement system handling (for communicating.
- (nevermind, done) side moving/wall sliding whatever you want to call it and you say it's easy to script needs to be done (since you say it's easy I'll leave it to you cuz I just don't get it).
-Some things need to interact with the damage system

*COUGH* I guess it's done; Now I leave you triggeractions and key handling revision. God, I hope you use this integrable, completed movement system. O DARN, wait a minute, I didn't do jumping either.

[Luda]

Will Avalon or Babord be coming back at all?