That would be easy, supposing you can read coordinates. All you'd have to do is modify the dropflag bind.

bind R [dropflag; say (getcampos)]

Doesn't look as elegant as you think it would.

I just noticed that yes, but the trick would be to script that back to normal human language (which is more useful for such thing as just showing up coordinates of that position).

By the way, is there also some command (or variable) which retrieves the camerayaw?

There are, but only in the svn, after the introduction of the sunlight feature. They're getcamyaw and getcampitch.

Yes I agree with you Jorge in that the practicality of this particular function may be limited (or maybe not, who knows). But I think what is more valuable is the concept behind it, namely that it is indeed feasible and definitely practical to create similar functions that "listen" for particular events, an example of which RaZgRiZ has provided.

You can't listen for getting or dropping the flag.

It's a handle, so whatever you decide to have it do in the event of a teamkill, is up to you really. You can have it be an autosay, or execute a script, or make you suicide as punishment.

And those flag handles aren't possible. For the same reason srbs described.

That's a shame that flag handles are not feasible. In that case, the only real world application I can see is auto-sorry, which I would not advise anyone to use, for obvious reasons, and which could have been achieved more easily (e.g. by your now deleted auto-sorry script).

If a comment is irrelevant and causes debates which are also irrelevant, i remove them
If a user steps out of line, i may ban him
If i made a script, regardless of size, it's not your place to decide what i do with it. I asked for constructive criticism, and i got replies such as yours.
If i don't like someone's rating, i ask them what could be improved, but instead i get replies such as yours.

So unless you have something useful to say or do, get the fuck out. I've had enough with Zama going as far as to creating multiple accounts to spam the place and downrate my nodes AGAIN, and i will not tolerate you as well, so i suggest you watch it from here on.

And consider this a promise. All i did was share scripts. All you did was bitch. So suck it up and choke it down. Enjoy a week of silence.

...and,
if you would tell him the points above, he would show you how right you are, and ban your account for at least 1 week, to demonstrate his impressive admin-power one more time :D

I thought i was pretty clear when i said that i do not wish to continue debating the morals of such a script, and that if you really want to, you should do it elsewhere. Apparently though, ignoring that and my request for a specific kind of feedback is really what you people like to do.

I don't have anything against you Fatum, not yet at least. But zama tipped the iceberg and i've been in a very bad mood since then to put up with this. So yea, this is a modification of the autosorry, or rather a generalization of what it once was. And like i said, how you use it is up to YOU and not ME.

And for your information, your account is not banned. Just suspended. But keep making accounts, it's amusing.

You both should stop right here right now.

Fatum, as Razgriz is an admin, you can consider him as a "god", since he has similar powers on this website. I agree he should take the responsibilities for his actions (like anyone else does), but you could have said that on a very different way (as it looks like your just "bitching" around again).

Razgriz, I know people like Zamwa and Fatum can be annoying/irritating, but stay cool. You know what I mean...

I'm no god, and neither i try to be one. However there are a few simple things i requested and instead i'm greeted with complaints about something i cannot care for. Despite how hard i try to keep my cool though, i too have my limits, and it's best not to push the situation beyond that.

As a sign of goodwill, i have unblocked fatum's account in hope he sees i'm not trying to be evil and understand that the script is not meant as a tool for other players to annoy people who find it wrong to use autosorry scripts, rather than expand the game's scriptable frontier.

--------------------

I have gone to lengths to get people to tell me what they would like improved/changed in a script to get a better user base, so you can see that when people come over and tell me that a script is useless because they find its use rude and rate it down, i too find it rude that you think you can decide what the people who browse here must use and what not.

Despite all this, i'm willing to let it go. I have some plans underway, and soon i'll fix an existing node into a master page for everything i have made, one you cannot annoy me with ratings, one that i will keep a close eye on the comments.

--------------------

Oh and suicizer, i know you're online, come on irc damnit :|

at razgriz: alright, but that not means i changed my mind, but i will stop here....so peace and out!

at suicizer:i am atheist...no gods for me!!! :D

A privately owned and operated website can neither be considered a democracy or a place where your "freedom of speech" matters. I would really like you to research the two ideas and you will find that you are very limited by the very core ideals of democracy and freedom of speech. What is offered here actually allows you more room to express your opinion and/or get something accomplished by the will of the people.

Last I heard, it was Nieb.

interesting idea about the other events, however i do not like the idea of an eventbind. to me, a bind in sauer, is something that happens when the user does something. i think of a handle as a piece of code waiting for the game to do something.

What he suggests as an event bind is basically what this whole thing already done, but it goes by a name which contains "bind" in it. I don't know what got both of you so confused. :P

I do have those event handles he mentioned ready though. But i won't commit on this node. I've gotta compile and finalize some structures and get the scripting alley set up.

"to me, a bind in sauer, is something that happens when the user does something. i think of a handle as a piece of code waiting for the game to do something." -skiingpenguins

Keyboard handles must really blow your mind then, eh?

I just thought that making their useage equivalent to that of key binds would better fit the existing structure of Sauerbraten/Cubescript, and make it far more approachable to the average player.

Well not really, such an approach only makes my life harder because it is far more difficult to maintain a "bind handle" once it has been made. And you also can't tab through them. So no.

That's why I suggested making this into an "eventbind".
I wasn't originally planning to, but perhaps I should post my version after all...

While i appreciate your feedback and suggestion into making the handles into executable functions of their own, i simply cannot do that without overcomplicating the way they work.

Currently, in the way they're made, you're required to keep a handle's command set in one place, and add to it along the way. For example:

onteamswitch [
    say "changing team"
    sayteam "hello mates"
]

For a different approach such as the one you described, i would have to drastically redesign the way the command operates, having it create functions of its own that would run individually with their own set of commands and variables, under a single prefix. Kinda like:

addhandle teamswitch TEMP1 [
    say LOL
]
addhandle teamkill TEMP2 [
    say NOOB
]

This would require some heavy thinking, incorporating use of the command flags tutorial script i've made. That won't be the hard part, no. Compressing the code will be..

-----

That being said, i should note that i don't really have a way for these handles to terminate once they run, except for /clearsleep. So keep that in mind each time you reboot your autoexec.cfg.

-----

A second note, a big library update that i should have uploaded a long time ago. Includes many new handles.

Don't get me wrong. I wasn't trying to choose your battles or suggest you take on those modifications.

I certainly wouldn't be interested in trying to do what I described... in cubescript anyway.

I understood the advantages of what you did both from a design and usability perspective. Frankly it may not be possible to do what I described elegantly in cubescript. (Particularily since as far as I can tell functions are only kind of first class in cubescript.)

That said, goodluck and I look forward to seeing what you come up with next.

1) ondamagetotal/dealt are executed every time you shoot (damagetotal increases), and every time you hit something (damagedealt).

2) onskullscore is an svn handle for the Skull Collect mode. If you've played Unreal Tournament, you'll see it's a bit similar to Greed but not all that.

3) yes. sleep delays the execution of its body for given msecs. So that's about 1000 loops a second. It can be raised, but checks slower than 100ms won't be quite as accurate in reading the changes. You can change it if you want though.

Collect looks also very similar to Quake Live's mode; Harvester.

Here's what i think: NOT doable.

I have no way to read what kind of ammo a client has, nor when he takes pickups.

That can actually be considered as cheating, as you receive more information than other players while they aren't able to get such information during the match.

Are you sure? I hope you have time to explain this because I cannot understand how. The idea in mind that I had was that it was to be used as team-play binds (If you're familiar with QuakeWorld's 4on4, you'll be familiar with this concept), however I do not understand that theres an aspect to this that could branch off into cheating.

What does it matter? It's NOT doable without a client mod.

Yeah, I understand that - I just want to know how its able to be used for cheating purposes.

If they are just binds to keys for your own personal use, then you don't need any script at all.

There is a line which people make consider if something is cheating or not. Some people think even something like wall-hacking isn't cheating, while others think there shouldn't be modified anything at all.
As Sauerbraten isn't QuakeWorld (neither any other game), there is a very different policy about cheating.

My personal opinion about it is; if you modify your Sauerbraten version with the means of getting a potential advantage over other players (by modifying the source-code and files like textures, skins, meshes, skyboxes, maps, configuration-files (except config.cfg), etc), then your cheating.

You could actually conclude the line between fair play and cheating as following:

Use your common sense and ask yourself questions like this:
If I would modify this...
- Would my opponent(s) still enjoy the matches also?
- Would my score be unharmed because of it?

P.S.
Sorry for being off-topic right now.

don't know about you, but for me there is an "input format" thing above the post comment button. select plain text and it should work.

<><><><>
<>Ah, ty!<>
<><><><>