shoot function revisited

[jake13jake]

I would really just like the ability to modify dynamically what projectiles detect as walls.

[Tyhm]

Or which direction was "Down". But we get into putnpc when we do that, don't we?

[excaliber7388]

It would be nice if it was like:
shoot projectile type,fromx,fromy,range(tiles),npcblock 0/1,wallblock0/1;
ex:
shoot(fireball,playerx+.5,player+1.5,10,0,1);
which would make a fireball that can't be blocked by NPCs, but will stop at 10 tiles or a wall.

[jake13jake]

[edit]
MORE TO ADD:
It would be cool if the projectile still existed during the onActionProjectile, and if you could modify it onActionProjectile (as though it were passed as a param), and perhaps the ability to modify a projectile on the event, and keep using it (ex. lvl2 shield would make the direction of the projectile flip).

I also would like to be able to destroy the projectile when I want to, and that it would destroy both serverside AND clientside. (ex, hide an NPC clientside, the projectile will hit at the NPC, but the projectile will continue moving clientside until it hits a clientside wall)

I haven't really had a lot of experience with projectiles, but this is functionality that I thought I could implement some way, but have found otherwise.
[/edit]

Originally Posted by excaliber7388

It would be nice if it was like:
shoot projectile type,fromx,fromy,range(tiles),npcblock 0/1,wallblock0/1;
ex:
shoot(fireball,playerx+.5,player+1.5,10,0,1);
which would make a fireball that can't be blocked by NPCs, but will stop at 10 tiles or a wall.

pfft, just make a gani of a fireball. I just want to be able to have more dynamic wall detection. I mean, I went for that with my movement system and that went very well.

What would also be nice is if you could modify tiletype(x,y) return values, much like enablefeatures and showstats.

ex. I have a timeout loop for enablefeatures

PHP Code:

if (clientr.pausedisabled)
  gui_features |= 2;
else
  gui_features &= ~2;
enablefeatures(gui_features); 


I mean, I'd like to be able to be able to shift one tile to another tiletype. Biggest example being the backside bottom of a cliff that connects to sand tiles.

[Tyhm]

Shmaybe what we really need is the Shoot script opened. "Here's how Shoot works behind the scenes, if it was written as a GScript function:
onShoot(x,y,pow,xdir,etc...){
//create the item in question
//probably use Move to move it
//probably something clever with the Move to trigger on a hit
}

So we could copy, edit, and paste our own custom "Fireball ganis" scripted exactly how we like it. The important detail would be that the script's exactly the way it works - if it's a less efficient approximation there's no sense in bothering, we can write our own less efficient approximations, the whole point of drooling over projectiles is they're hardwired to be faster and smarter than our own NPCs.

[jake13jake]

Originally Posted by Tyhm

Shmaybe what we really need is the Shoot script opened. "Here's how Shoot works behind the scenes, if it was written as a GScript function:
onShoot(x,y,pow,xdir,etc...){
//create the item in question
//probably use Move to move it
//probably something clever with the Move to trigger on a hit
}

So we could copy, edit, and paste our own custom "Fireball ganis" scripted exactly how we like it. The important detail would be that the script's exactly the way it works - if it's a less efficient approximation there's no sense in bothering, we can write our own less efficient approximations, the whole point of drooling over projectiles is they're hardwired to be faster and smarter than our own NPCs.

My only requests here: dynamic wall detection, optional clientside/serverside synch.

Then, if possible, an option (maybe a serverop) not to immediately destroy the projectile when it hits, but to reference it as the 3rd or last parameter onaction(s)projectile that can have it's values modified only in the event.

Classic's system (for traditional projectiles) would only need arrow type, origx, origy, and dir(or)target, and, with enough control of implementation, it would be very easy to abstract that into a class (like how Tyhm was saying here). However, shoot doesn't offer that control of implementation.

What Classic would need to be able to do is reverse an arrow when it hits a player (having a >1 shield power) that is facing the arrow. I only suggest this because I think it would be more convenient, and possibly more efficient than calling the shoot function again from the action(s)projectile event. We would also need to be able to turn off all wall detection except for on most NPCs and players. Now, on the other hand, the clientside/serverside mis-synch is just annoying.

npc.isblockingprojectiles was a good start (considering liftable tiles have been switched to NPCs on classic... wouldn't want them or anything mimicking tiles blocking), though I'm not entirely sure how to implement that. I don't know how.

Also Tyhm, never say to copy and paste scripts, that's what we use classes and weapons for now when we have something we want reusable .

[Tyhm]

Well, I fail to see how you're likely to get it from a website to the server without good old copy and paste. If he were to post a GScript version of the Shoot command, I mean.

[jake13jake]

Originally Posted by Tyhm

Well, I fail to see how you're likely to get it from a website to the server without good old copy and paste. If he were to post a GScript version of the Shoot command, I mean.

It's really impossible to make a gscript version of the shoot or move commands since their intent is to do things that serverside gscript is incapable of.

[Tyhm]

And yet the shoot command does it, so SOME command - probably going all the way into the core programming - IS capable of it. It's like the Move command: There's a way to emulate it with timeouts, just not as efficiently. But maybe there is. I mean, Stefan coded it in C (and a couple languages before); with the proper commands, couldn't he program it in GraalScript? Would Move be a complex brainhurting series of clientside animations, serverside instant move and delayed Sendings, then a calculated interpolation? By that same stretch could Shoot be scripted as just Create This And Move It? In which case it could be rescripted as And When It Hits Billy,
if (BillyShieldPower>1&&BillyDir=(dir+2)%4) dir=(dir+2)%4;//or Billydir, depending on your views of robust vs efficient...

[jake13jake]

Originally Posted by Tyhm

And yet the shoot command does it, so SOME command - probably going all the way into the core programming - IS capable of it. It's like the Move command: There's a way to emulate it with timeouts, just not as efficiently. But maybe there is. I mean, Stefan coded it in C (and a couple languages before); with the proper commands, couldn't he program it in GraalScript? Would Move be a complex brainhurting series of clientside animations, serverside instant move and delayed Sendings, then a calculated interpolation? By that same stretch could Shoot be scripted as just Create This And Move It? In which case it could be rescripted as And When It Hits Billy,
if (BillyShieldPower>1&&BillyDir=(dir+2)%4) dir=(dir+2)%4;//or Billydir, depending on your views of robust vs efficient...

I would think that the server directly interprets the move command, and the client is sent dx, dy, time, and options. There's a forgivable problem in that the time in the parameters isn't always the same time to execute the movement. Although, I see that as better than a projectile's flaw of not being able to match serverside/clientside self-destruction.

[Admins]

The good thing with projectiles is that they are starting immediately on clientside, without worrying about lag. We could expand that so that projectile movement would be controlled via (gani-)script. That could cause some slowdown though when there are many projectiles at the same time, although syncing all those projectiles from serverside to clientside would cause lag/speed problems too.
The perfect solution would probably be:
- creation on clientside
- make it possible to delete the projectile on serverside, e.g. when the serverside detects that the player is cheating and is shooting without having bullets (in onPlayerShoots)
- make it optional to let the projectile be moved automatically, via gani script or controlled by serverside script only
- eventually synchronize those objects quicker, via UDP between server and client like in Graal3D, so that other people see the bullets earlier and there is less difference/lag between the serverside view and the clientside view

[jake13jake]

A cool way to make walls more dynamic would be to reference a wall detection function, but that might be laggy as hell.

I'd probably just go with a list of tiletypes and players/npcs be checked by default.

Well, actually, that makes me think of throwing bushes now, where I wouldn't want it to check for NPCs or players, just to keep going until it hits it's final location.

Also, why isn't there a clientside version of onActionProjectile? j/w because it would help a lot with the smoothness of leap placement when throwing a pot or a bush. Actually, you can't really deal with smoothness this way.

Would be nice if you could have npc visibility excluded from the client that triggered an action. (that way you could place a leaptype clientside for that particular client, and then serverside for every other player but the client)

maybe like a serverside npc.setclientexclusions(list of player objects); (since I think I'd most be using this with putnpc2).

[Moondeath_2]

Psh. Shoot is teh Evil!

[jake13jake]

Originally Posted by Moondeath_2

Psh. Shoot is teh Evil!

Shoot is a good function in an abstract perspective. It just isn't dynamic enough imo.