Client-side Scripting

[daenyth]

With all the recent talks of a client-side scripting system, (just simple conditionals and variables, $currentstage$, $tonextstage$, $currentweapon$, etc.) I was wondering if anyone wanted to take up this project? I'd love to, but I just don't have the knowledge needed to do it. I'll be happy to beta-test though.

[Odin]

Shouldn't it rather be a server-side scripting system? Client-side would only make things bad.

[techhead]

Why not have client-side?
A "Ovemind/Reactor down, Defend!!" bind would be better if it knew which team you were on, without having to go through scripting with separate bind lists.

[daenyth]

Shouldn't it rather be a server-side scripting system? Client-side would only make things bad.

I really don't see how this could be abused. Just things to allow stuff like "say_team $tonextstage$ kills to next stage!" or "if ($team$ == human) { class ckit } elseif ($team$ == alien) { class builder } else { echo "Join a team first!" }

[daenyth]

Rather than arguing that it can be abused, why don't we agree upon what is needed by a simple script system?
IMO, these first two are most important; the variables would only be information to which the player already has access (mostly through the scoreboard splash, or the HUD). The conditionals are probably slightly less important.

Conditionals
if
elseif
else

Dynamic variables
$team$ (Which race am i?)
$stage$ (What stage is my team?)
$weapon$ ($class$?) (What weapon do I have?)
$tonextstage$ (How many kills to next stage?)
$location$ (Where in the map am I?)
$hp$ (My current hp)
$ammo$ (includes goon barbs)

Ability to create named functions
func &foo& { say_team "bar"; }


What NOT to implement?
for (spam concerns)
while (spam)
goto (spam)
What else?

[David]

Functions = Spam too.

But I can do that already, with a cfg that exec's its self, or a vstr that calls its self.

all we need is the variable's (both in human readable and number form*) and a simple if system.
Everything else is already there,

*eg:
$team = Alien or Human or Spectator
#team = 0 or 1 or 2

[Stof]

What NOT to implement?
for (spam concerns)
while (spam)
goto (spam)
What else?

Some corrections in what NOT to implement;
goto (goto)
; (spam)
functions (spam)

Code: [Select]

Examples:
func spam()
{
   say "SPAM";
   say "SPAM";
   say "SPAM";
   say "SPAM";
   say "SPAM";
   say "SPAM";
   say "SPAM";
   say "SPAM";
   say "SPAM";
   say "SPAM";
}

Example 2:
fun super_spam()
{
    spam();
    spam();
    spam();
    spam();
    spam();
    spam();
    spam();
    spam();
    spam();
    spam();
    spam();
}

Examples 3:
func monster_spam()
{
    super_spam();
    super_spam();
    super_spam();
    super_spam();
    super_spam();
    super_spam();
    super_spam();
    super_spam();
    super_spam();
}

Example 4:
func infinite_spam()
{
    monster_spam();
    infinite_spam();
}


Morailty, if spam is your concern, you might as well forget the whole scripting language thing or instead code spam limiters in the server.

[whitebear]

I think these bind helpers are useless. Team say binds are useless too. I've started automaticly ignore all chat messages with anoying color coding. Ents in LoD movies are exactly correct that you should think if it's worth of teling before you say anything.

Every message that is binded start to look dull in it's repeativeness while people change what they say if it's done manualy every time.

[David]

All you need is:

Code: [Select]

set spam="say SPAM!;vstr spam"
vstr spam

[Coca-Cola]

Code: [Select]


for(int i=1; i>0; i++){

say("My code>Yours");
}


pwnt ;p

[Undeference]

Surprise us. Write an interpreter (or better yet, a compiler, and use the existing vm to run the code) that supports what is currently available (server.cfg and maprotation.cfg should be directly supported) and submit your patch to Bugzilla. It should be usable enough to use custom g_admin commands. In fact, most of the hard coded g_admin commands could be reimplemented as custom commands if there were good enough scripting.
Of course, why it most likely won't make it for the client has already been discussed.

[Risujin]

Code: [Select]

(loop for i across #(1 2 3) do (ap ("print \"omg its 1958 all over again\n\"")))


[DASPRiD]

Why not have client-side?
A "Ovemind/Reactor down, Defend!!" bind would be better if it knew which team you were on, without having to go through scripting with separate bind lists.

Things Like Overmind down / Reactor down will be implemented with the radio commands in the next version. No need for senseless scripting. But we need scripting on the mapping-side.

[techhead]

I was using it as an easy to cite example, scripting would also allow for some more complicated pre-programmed stuff.

[Paradox]

One thing that is being mentioned is conditionals, if, else, etc. Loops would be great, for example:

Code: [Select]

//Script for building 5 acid tubes
var acidtube == 0
if acidtube > 5, then
for acictube 1
build acidtube
else
stop
As you can tell, i like RPN (dont ask what it is, you should know this).

[daenyth]

Surprise us. Write an interpreter (or better yet, a compiler, and use the existing vm to run the code) that supports what is currently available (server.cfg and maprotation.cfg should be directly supported) and submit your patch to Bugzilla. It should be usable enough to use custom g_admin commands. In fact, most of the hard coded g_admin commands could be reimplemented as custom commands if there were good enough scripting.
Of course, why it most likely won't make it for the client has already been discussed.

As I said, I simply don't have the required skill to do it myself... I thought I'd throw the idea out there and see what the community liked, but it seems that most people feel it's not needed.


And as for the spam concerns, I was a little short-sighted in saying which things may be bad to implement. After thinking about it some more if anyone did implement this, it would be better to include those functions (except goto ), and just have server-side flood control, as some qvm's already do.

[David]

if you want it, compile this (and finish it) into trem.
http://icculus.org/~phaethon/q3a/q3sh/q3sh.html

[FisherP]

I wouldn't mind of if..then..else statements within the client side console, makes for a more flexible bind system.

As for spam the only way to really prevent it is on the server side in a qvm. I don't care much atm for a goto, and don't see the need for functions or subroutines. Just a better way of doing what we do now, if I'm a granger then I want to build stuff, if I am a human with a ckit, I want to build other stuff. It would be nice to not have to concern myself with what my keys are bound to, it could/should be automatic.

[kevlarman]

I wouldn't mind of if..then..else statements within the client side console, makes for a more flexible bind system.

As for spam the only way to really prevent it is on the server side in a qvm. I don't care much atm for a goto, and don't see the need for functions or subroutines. Just a better way of doing what we do now, if I'm a granger then I want to build stuff, if I am a human with a ckit, I want to build other stuff. It would be nice to not have to concern myself with what my keys are bound to, it could/should be automatic.

this is already possible by separating binds into humans.cfg and aliens.cfg and binding 2 keys to "team humans;exec humans" and "team aliens;exec aliens".

[Rawr]

I would like client side scripting in the tjw command blocks. So you can do intergers and usernames/slot numbers and such.

[Undeference]

I would like client side scripting in the tjw command blocks. So you can do intergers and usernames/slot numbers and such.

Do I even need to point out where that went wrong?

[daenyth]

I wouldn't mind of if..then..else statements within the client side console, makes for a more flexible bind system.

As for spam the only way to really prevent it is on the server side in a qvm. I don't care much atm for a goto, and don't see the need for functions or subroutines. Just a better way of doing what we do now, if I'm a granger then I want to build stuff, if I am a human with a ckit, I want to build other stuff. It would be nice to not have to concern myself with what my keys are bound to, it could/should be automatic.

this is already possible by separating binds into humans.cfg and aliens.cfg and binding 2 keys to "team humans;exec humans" and "team aliens;exec aliens".

But more along the lines of

Code: [Select]


/bind key rebind()
sub rebind {
  if ("$team" eq "aliens") {
    exec alienbinds.cfg
    if ("$class" eq "builder") {
      exec alienbuilder.cfg
    }
  } elsif ("$team" eq "humans") {
    exec humanbinds.cfg
  }
}


etc, etc

[Smokey]

Every one of these examples has been in a different format. If this is done, I think it should follow the mIRC scripting system (Due to its ease)

Code: [Select]


if ($stage == 1) {
 say_team We need stage 2!
}
elseif ($stage == 2) {
 say_team We need stage 3!
}
else {
 say_team WTF WE NEED A STAGE OMGBBQHAX
}


[David]

mIRC lacks quotes around strings.
IMO that sort of stupidity makes it good for nothing.
If you want a full scripting language, embed perl.
Or better still bash,

[Paradox]

or better yet, C

[Smokey]

mIRC lacks quotes around strings.
IMO that sort of stupidity makes it good for nothing.
If you want a full scripting language, embed perl.
Or better still bash,

simplicity.

[Matt2k10]

Make it like python!

[FisherP]

I wouldn't mind of if..then..else statements within the client side console, makes for a more flexible bind system.

As for spam the only way to really prevent it is on the server side in a qvm. I don't care much atm for a goto, and don't see the need for functions or subroutines. Just a better way of doing what we do now, if I'm a granger then I want to build stuff, if I am a human with a ckit, I want to build other stuff. It would be nice to not have to concern myself with what my keys are bound to, it could/should be automatic.

this is already possible by separating binds into humans.cfg and aliens.cfg and binding 2 keys to "team humans;exec humans" and "team aliens;exec aliens".

I already work my binds this way ref: http://tremulous.net/phpBB2/viewtopic.php?t=1240, but it would be easier if the system just knew, in order for me to set my binds up for a builder at the start of a game I need to hit two keys, I'm not complaining, it's a good system, but I think it can be improved.

But more along the lines of

Code: [Select]


/bind key rebind()
sub rebind {
  if ("$team" eq "aliens") {
    exec alienbinds.cfg
    if ("$class" eq "builder") {
      exec alienbuilder.cfg
    }
  } elsif ("$team" eq "humans") {
    exec humanbinds.cfg
  }
}



etc, etc

No, not like that because you can do this in separate cfg files, more like (i don't know the syntax so this is more at concept level)

Code: [Select]


/bind key buildsomething()
sub buildsomething {
  if ("$item" eq "ckit") {
      bind key (build something human)}
  elsif ("$class" eq "builder") {
      bind key (build something alien) }
}