How do I add player commands?
Printable View
How do I add player commands?
Quote:
Originally Posted by derpderp
seems to fix it, at least for an extended period of timeCode:event_alive 's $n +0.00333'
Suggestion: Allow SAPP to set spawn times of weapons and individual players.
Examples:
- Lets say I want the sniper in Bloodgulch to spawn every 30s instead of every ~126s. I could just use the event system to change the sniper spawn time. Would be very nice.
- Or the red team leads 2-0 on a 3 cap map. Would be cool if you could use the event system to adjust the spawn time of just the red team from e.g. 5s to 10s until they cap at least once.
Just things to make public games more fun/balanced/enjoyable/noobfriendly
I think custom variables could accomplish a lot of things.
With the addition of other things like $v and vehicle teleporting, you could effectively solve both the spawned vehicle respawn and weapons respawn issue. Whether fixing up a custom respawner or doing that is more work is debatable.
I came up with a couple other useful things you could do with just custom variables, however. This is assuming a lot of things, particularly the order of parsing the variables: $ -> # -> commands (as opposed to $ -> commands as is normal), and # being the prefix to custom commands
Psuedo code for keeping track of an alternative scoring method:
I used $hash so that they could persist for each player the rest of the game session (storing variables to a file would be a huge plus, otherwise using the event commands, the could be written to set, but there's no good way to remove the old ones so it'll accumulate in the events file.)Code:event_start 'addvar gamenum 1;setvar endgame 0'
event_join #$hash_gamenum!=#gamenum 'varset $hash_gamenum #gamenum;varset $hash_score 0'
event_kill 'addvar $hash_score 100'
event_score 'addvar $hash_score 4000'
event_assist 'addvar $hash_score 40'
event_join #$hash_score>0 'w8 3;say $n "Welcome back! Your current score is #$hash_score"'
event_end 'w8 4;setvar endgame 1;w8 6;say * "#redmvp was the Red Team's MVP for this round;say * "#bluemvp was the Blue Team's MVP for this round"'
event_alive #endgame=1 #$hash_endgame!=1 'ctf_score $n #$hash_score;varset $hash_endgame 1;varset testmvpscore #$hash_score;varset testmvpteam $team; varset testmvpplayer $n; cevent test_mvp'
event_custom cname:test_mvp #testmvpteam:red #testmvpscore>#redmvpscore 'varset redmvp #testmvpplayer;varset redmvpscore #testmvpscore'
event_custom cname:test_mvp #testmvpteam:blue #testmvpscore>#bluemvpscore 'varset bluemvp #testmvpplayer;varset bluemvpscore #testmvpscore'
event_alive #endgame=0 #$hash_endgame=1 'varset $hash_endgame 0'
Some other examples of things that would be possible with custom variables:
So it's pretty significant for custom "gametypes"
- Keeping track of kills while using a vehicle
- Multi-team games
- Tracking death streaks
- Any kind of timer
- Player/Team currency (buying vehicles etc)
Overall, I'd like quite a few things:
I understand you're often busy, but custom events sort of inspired new hope that one day we can have these nice things.
- Custom variables (varset, varadd, uses #)
- $v variable for vehicle events (and player events for if the player is in a vehicle?)
- Tp commands for any objects
- Having some kind of return value from functions like spawn
- As an interim for custom variables, being able to pass values through cevent (like cevent fishes Apple 3 Fish) would sort of work, then you could have event variables like $1 $2 and $3 ($1:Apple, $2=3, $3:Fish)
I also think being able to set spawn times for players would be really awesome, that was a feature from the old days that I really missed.
I like the idea of an argument to check what vehicle they are in, as well as if they even are in a vehicle. Would be VERY useful for certain antiglitch area events.
Also... had some more ideas as well...
Quote:
event_collision: Runs if a player hits another player or a vehicle that a player is in, or if the vehicle the player is in hits a player or another vehicle. Again, this could be useful for some antiglitch things, for example... Danger Canyon... have the server kill the person that got pushed, but kick or ban the person that did the pushing. It could also maybe make for some cool things such as trading weapons to individual players (would probably need some variables for this one, or at least new commands), add an interesting twist to Zombies games, run some special events for those vehicle killing noobs (Noob? Who said that?)... interesting things like that.
Quote:
A command to delete admins by player number. This could have a few uses as well... in events, if a logged in admin is glitching, teamkilling, or things like that, and is below a certain level (checked using the $lvl argument), you could automatically have their admin status revoked. Also, if a V2 Admin logs in, leaves, and then comes in with a different name and starts abusing their powers, you can delete the admin powers assigned to them by using the player number, as opposed to checking logs, cross checking IPs, and then looking through the admin index. Obviously, both ways of deleting admins should be kept... but this would be very beneficial in certain cases.
Quote:
A new part to the "d" command... if a V2 Admin logs in, leaves, and then changes their profile... they stay logged in, even with a different name. Having something in the player information to display who that player is logged in as could be useful... as well as a variable/argument for events and commands (so, for example... I could have something like:
Code:event_join $lvl>0 $name!:$loggedinas 'sv_log_note "$name has joined the server, logged in as $loggedinas with level $lvl."'
Quote:
A new event that runs every time an admin runs a command... including RCON if sapp_rcon is enabled. Multiple purposes, including displaying to the other admins if an admin ran a command on somebody, or is running a command on somebody, as well as writing sv_log_notes as per my last suggestion. Maybe include a $command variable or something to check the command.
Quote:
For commands... it'd be nice to implement a way to also say something to admins of a certain level... maybe things like 'lvl0' 'lvl1' 'lvl2' 'lvl3' 'lvl4'... so like for example...
<br>And again, this could incorporate the previous suggestion of using the $loggedinas variable and argument... write a sv_log_note about it, and display it to logged in admins... so something like this:<br>Code:event_snap $botscore>8000 $lvl=0 'say lvl1 "$name (Level $lvl) has a botscore of $botscore. Sightjacking is advised.";say lvl2 "$name (Level $lvl) has a botscore of $botscore. Sightjacking is advised.";say lvl3 "$name (Level $lvl) has a botscore of $botscore. Sightjacking is advised.";say lvl4 "$name (Level $lvl) has a botscore of $botscore. Sightjacking is advised."'
Maybe in a case like that, you could also have variables like lvl1up lvl2up lvl3up lvl4up (lvl0up would just be the equivallent of admin) to say to admins that are, obviously, that level and higher. But having something to say something to specific admin levels at the least would be very useful.Code:event_snap $botscore>8000 $lvl=0 'say lvl1 "$name (Level $lvl) has a botscore of $botscore. Sightjacking is advised.";say lvl2 "$name (Level $lvl) has a botscore of $botscore. Sightjacking is advised.";say lvl3 "$name (Level $lvl - Logged in as $loggedinas) has a botscore of $botscore. Sightjacking is advised.";say lvl4 "$name (Level $lvl - Logged in as $loggedinas) has a botscore of $botscore. Sightjacking is advised."'
Quote:
Another command target for players except the one executing the command or triggering the event. Kind of like the @me in SourceMod commands.
Quote:
A way to remove and respawn vehicles that were already spawned... either by the id of the player using them, or by doing it to all vehicles. The use I was thinking of for this was for situations like attempted base cramming on Death Island, where when the player enters an area in a tank (see earlier suggestions for checking this), not only would it kill/kick/ipban the player, but it would also delete the vehicle that they were in just in case it got far enough to be crammed. It could also help to remove other glitched vehicles on other maps... the admin gets into them and runs the delete vehicle command. Yes, there's vdel, but that only works on vehicles that were spawned/created by the administrator. I'm thinking this would be for the vehicles that were already spawned on the map. It would work the exact same way... just with different vehicles.
And actually, that example gave me another idea, too... what about a file that lists tagsets and who's allowed to be using them? Like, an entire Tagset system?Quote:
Wildcards in event arguments. So, for example... $name:WTF* would be triggered if the players name has WTF in it. Maybe allow the ? to be used as well when triggering it. There could be multiple uses for this... but the one that I'm thinking of is to prevent fake administrators/admins/things like that. So, for example... say there's a tagset «AB». I would be able to write an event like this...
and it would automatically kick any players coming in with the tagset «AB» that didn't have a name matching one of the listed ones.Code:event_join $name:«AB»* $name!:«AB»Test $name!:«AB»Admin $name!:«AB»Awesome 'k $n "FAKE_ADMIN"'
The way it could work could be like this:
Quote:
In the init file:
In the events file:Code:tags_protection 1/0
A new txt file would be created called members.txt or tags.txt. It could be formatted like this:Code:event_badtags $tagset:[whatever_tagset] 'say $n "$nontagname - Please remove $tagset from your Profile Name."'
event_join $badtags=1 'say admin "$name is a fake member. $nontagname is not listed under $tagset in members.txt or tags.txt."'
where any name underneath that one, up until the next tagset line, would be authorized to use that tagset. So, as a working example...Code:Tagset:[Tagset]
Name
Name
Name
Name
tags.txt or members.txt:
In console:Code:Tagset:-AB-
PlayerName
Noob
Vehicle
Epic
Tagset:=AB=
Warthog
Banshee
Tagset:AB*
IAmBoss
Tagset:«AB»
Test
Admin
Awesome
Code:refresh_tags or refresh_members
Code:tagset add [tags] [name]
Code:tagset del [index]
Code:tagset list [tags]
Code:tagset listall
The search would output something like this:Code:tagset search [name]
And then every time a player joined using a tagset without a matching player name, event_badtags would be ran on the user, and the argument $badtags would be set to 1 (if the admin writing the events didn't make use of the kick or ipban, they could use this to limit their experience on the server, or do other things).Code:tagset search mywarthog
ID Tagset Name
# -AB- mywarthog
# =AB= mywarthog
# AB* mywarthog
# «AB» mywarthog
Obviously, this won't help to prevent imposters (unless an optional option (just like minplayers:maxplayers in the mapcycle file) for adding IP Address or CD Hashes is added? In which case, more severe punishments through a seperate event like event_imposter, along with a seperate argument like $imposter=1/0), but it will at least help to limit fake members)
Quote:
A minplayers:maxplayers option for map voting too... allows you to set how many players there needs to be in the server at the time for the voting option to even show up. Also... in the event that no one votes, would it be possible to have SAPP follow the mapcycle for the next round through a new setting like novote_followmapcycle 1/0? Maybe like the first failed voting attempt goes to Map ID 1, the next one goes to Map ID 2, and so on.
Hopefully you'll consider these ideas. I used the quote tags to try and better organize the ideas. If I can think of anything else, I'll let you know.
EDIT:
Had another idea, and also a bug report. Both relating to the admins.
Idea:
And the Bug Report...Quote:
Some advanced possibillities for handling admins, especially v2 Admins. Some things I had thought of:
- Revoking accounts, rather than deleting them altogether. Some clans use a suspension thing for moderators that violated policies... revoking their accounts and reinstating them could save a lot of the hassle involved with deleting and readding them. A command would have to be added such as admin_revoke for v1 and admin revoke for v2... as well as admin_reinstate and admin reinstate. A custom message could also be shown to them stating that their account has been revoked should they try logging in.
- Events for failed logins and failed RCON attempts. Have a variable increasing with each failed attempt within a certain grace period (much like the way tk counts work I guess), and allow servers to have more flexibillity over rules for failed RCON attempts and failed SAPP Login events, such as revoking the account (above suggestion) after x tries, IP Banning the user, or kicking the user. Maybe something like event_badlogin and event_badrcon as well as $failedrcons and $failedlogins.
- This is probably a stupid idea, but it never hurts to ask/mention it. More control over passwords would be a nice thing to have... such as length (I know that stock SAPP is 4-15, but it'd be nice to have the flexibillity to change this), characters allowed/not allowed, making admins reset their passwords every so often, and rules such as "Must not have been a previously used password" "Can not be the last used password" "Can not contain username" and "Must be mixed case." Most forum softwares and other modern things have these features for security, so why not SAPP?
- A command to flag a user to force them to change their password at the next successful login. Something like admin force_pwchange that would display a prompt to the user to use the change_password command to set a new password before using any of their commands. A couple of reasons that this could be used are if an admin expects someone is tampering with their account, or for the failed logins event (see above suggestion).
- A command to view a list of who is logged in. Something like admins_online that could output something like this:
Code:Name: Logged In As: Lvl: Type:
Admin1 Admin1 4 v2
APlayer Admin2 1 v1
You can't kick a V1 Admin at Level 4 or ipban a V1 Admin at Level 4 from the console. It returns an error about kicking admins that are a higher or equal level to you... but the console should be above all of the admin levels, right? Also, if you delete the admin, you still can not kick or ipban them until they leave the server on their own terms. Same goes for V2 Admins.
Hopefully I'm making some sense with these ideas I'm posting here.
Eh... so english speaking ppl still playing this game. :O
Well, I should release 7.2 first that I don't remember half the changes I made. I already tried custom variables 2-3 times but it has some problems, it's not that easy as it seems for the first, but I'll try.
...and meh, I'd rather add lua as Btcc22 suggested, these funcs are too specific etc...
So I guess I'll release 7.2 then annoy me on Xfire about the new bugs or changes/commands I forgot to note.
Didn't code anything in the last month or so, and kinda lost interest in Halo, would like to work on some other project, just have no idea what. :D
Before you give up on halo, i had an idea for someone to integrate a dogecoin payout system to the winner/winning team.
Ask Btcc22, he will do it for sure, he's the fan of dogecoin. :)
So... I guess I'll be the guy to ask the question in everyone's head now... what does that mean for SAPP? Are you going to make it Open Source, give it to somebody else, or still keep working on it?Quote:
Originally Posted by sehe
Also, I'd like to share my thoughts about adding Lua. I don't think that that would be a good idea... you'd just be turning it into Phasor, essentially. Anyone that has an idea for something will be forced to learn Lua, pay someone to write it, or hope that there's a script out there already for what they want at the price of it becoming outdated/conflicting/unsupported/malicious/poorly written/whatever. And not everyone has the time and/or resources to do that. Plus, there'd be so many problems that came up from people that didn't know what they were doing, and it'd create a mess. We already have Phasor for Lua... people like SAPP because it's not Phasor, and people like Phasor because it's not SAPP. What's the need in having two Phasors?
lol, silly.
I don't abandom it yet, but if I ever will, I'll prolly make it open source.
And I won't turn it into Phasor, nothing will change, I'll just might add lua as an extra feature.