Zandronum Chat on our Discord Server Get the latest version: 3.2
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000247Zandronum[All Projects] Suggestionpublic2010-12-27 23:002013-12-27 09:42
ReporterIjon Tichy 
Assigned To 
PriorityhighSeverityfeatureReproducibilityN/A
StatusclosedResolutiondenied 
PlatformLinuxOSUbuntuOS Version10.04 x86
Product Version98d 
Target VersionFixed in Version 
Summary0000247: SWIG Interface to Skulltag
DescriptionIn case you don't know, SWIG is a tool that allows otherwise disconnected
processes to talk to each other with complex data types, and allows scripts
(Python much?) to effectively control an aspect of the server program. What I'm
suggesting is that one be added to Skulltag, so things like server bots have more
purpose than 'say a bunch of stuff'. Also, it'd allow a bot to get information
more reliably. It's probably going to be a huge undertaking to implement this
feature, but I can safely say that it will very well be worth it.
Steps To Reproduce*code*
Additional InformationI'm currently coding a server bot (isn't /everyone/ coding a server bot these
days?), and parsing input while being sure that there's no data that's faked is
proving tricky (even with newline disabled: say someone has a name like "CHAT
Ijon Tichy: " - what do you get when that person connects? "CHAT Ijon Tichy: has
connected."!). Yes, there's the suggestion for chat strings to be formatted like
"%[name]%: [message]" or whatnot, which would be helpful, but how about getting
the chat from the program in the format (idx, name, message)? Then you wouldn't
need to worry about just which character is a delimiter, and it makes getting
the chat string less error-prone.

There's also DMFlag parsing, which, while more rigid, has an issue - what if the
DMFlags are set at the beginning of the server? You don't get a handy-dandy
"dmflags changed to: 31337" or whatnot. Then you could retort with "just poll
the server for the dmflags!", which would work, except for the fact that it
would be polling the server at least five times a second. Think about the RCon
users! You could also say "have the bot take the dmflags from the arguments",
but what if the bot's run with no arguments, and the flags default to whatever
they were last time? We have an issue here, don't we?

Aside from those things, being able to interact with the Skulltag server through
SWIG would allow the bot coder to do things like give and take items from
players (!rtd, anyone?), set health, personal gravity, speed, etc (again, !rtd),
allow a server to more readily communicate with the players, and be able to talk
to specific players (kinda like an echo sent to one client), spawn things at
certain coordinates (add a way to get player angle and coordinates, and suddenly
grenades are flying out someone's ears in a vanilla game), change a player's
position (although this would be risky), and maybe even change the map in-place
(although this would be VERY risky).

'Course, you wouldn't be able to implement new client-side commands this way, so
it wouldn't be a complete copy of SourceMod. But then again, we have this little
thing we like to call KEYCONF, so that shouldn't be an issue amirite?

Here's some commands that I think would be nice and helpful:

Note: Return an exception whenever a required argument is missing (if that's
even necessary).

playerInfo(idx=-1): If the idx is -1, return an array in the form of ((idx, ip,
name)...) If a zero or positive idx is passed, then check if a player with that
idx is in-game. If so, return an array in the form of (name, team, autoaimDist,
color, skin, gender, switchOnPickup, moveBob, stillBob, playerClass, unlagged) -
basically all the info you'd get from playerinfo normally. If no player has that
idx, then return false.

getPlayerGameStats(idx=-1): If the idx is -1, return an array in the form of
((idx, kills, deaths, suicides, points)...). Otherwise, if the idx is associated
with a player, return an array in the form of (idx, kills, deaths, suicides,
points). If it isn't, return false.

getPosInfo(idx): Return the coordinates of the player with the idx passed to
the player. If there is no player with the idx, return false. Otherwise, return
an (x, y, z, velx, vely, velz, angle) array.

setPosition(idx, x, y, z, velx, vely, velz, angle): Moves a player with the idx
passed to the coordinates passed, with the velocity passed, facing the angle
passed. If there's no player associated with the idx, then do nothing and return
false. Otherwise, move the player and return true.

getIdxFromName(name): From the name provided, returns the first idx that matches
it, color codes and all, or false if none match it.

getIdxFromIP(ip): From the IP provided, return the first idx that's associated
with it. As for why more than one would be associated, I dunno.

getCVar(name): Return the value associated with the name passed, or an exception
if it doesn't exist.

setCVar(name, value): Set the CVar with the name specified to the value
specified. Remember, this is all server-side.

getFlags(): Return all the flags in a hash {flagName: flagValue... }. As of
right now, this would be {'dmflags': 5345, 'dmflags2': 28644, 'dmflags3': 35652,
'compatflags': 0, 'compatflags2': 0, 'lmsallowedweapons': 1023,
'lmsspectatorsettings': 2} (these values are just examples).

getChatStrings(team=0): Get all chat messages since the last map (not changemap)
change. Obviously, this can get pretty large. The team argument is for whether
to include team messages.

getNewChatStrings(team=0): Get the chat messages that were said since the last
check. The team argument, again, is for whether to include team messages, but
they'll be removed from the waiting list either way. This effectively reads from
a queue of spoken chat messages.

getPlayerStats(idx): If a player isn't associated with the idx passed, return
false. Otherwise, return an array in the form of (health, armor, armorClass,
weapon, ammoTypeOne, ammoCountOne, ammoTypeTwo, ammoCountTwo).

getPlayerInventory(idx): If no player is associated with the idx passed, return
false. Otherwise, return their entire inventory, in the form of ((itemName,
itemCount)...).

givePlayer(idx, item, count=1): Give the player associated with the idx passed
$count amount of $item (bash-isms? in MY suggestion?!). If the idx or the item
doesn't exist, return false, otherwise return true. If count is less than one,
do nothing, but still return true.

takePlayer(idx, item, count=2147483647): Take $count amount of $item from the
player associated with the idx. If the idx or the item doesn't exist, return
false, otherwise return true. If count is less than one, do nothing, but still
return true.

damagePlayer(idx, damage=2147483647, ignoreArmor=0, damageType="Normal"): Damage
the player associated with the idx for $damage HP, with the damage type passed.
If no player is associated with the idx or (s)he's dead, return false, otherwise
return true.

kickPlayer(idx, reason=""): Kicks the player associated with the idx passed, if
there is one, with the reason specified. Returns true if a player was kicked,
false otherwise.

kickPlayerFromGame(idx, reason=""): Kicks the player associated with the idx
passed from the game, if there is one, with the reason specified. Returns true
if a player was kicked, false otherwise.

banPlayer(idx, time, reason=""): Bans the player associated with the idx passed,
if there is one, with the reason specified. time is in seconds, and if it's
negative, then interpret it as a permaban. Return the IP of the banee if the ban
was successful, false otherwise.

unBanIP(ip): Unban the IP specified. If the IP wasn't banned, then return false,
otherwise return true.

spawnActor(actor, x, y, z, velx, vely, velz, angle, force=false): Effectively
A_SpawnItemEx without the flags or chance arguments. Attempt to spawn the actor
(or force the spawn if force is true), and return true if it succeeds, false if
it's outside the map, and an exception if the actor doesn't exist.

That's all I can think of right now.
Attached Files

- Relationships

-  Notes
User avatar (0001812)
Ijon Tichy (reporter)
2011-06-24 19:23

Since Omega8 released a server bot, I figured I might as well bump this. After all, although this will probably be utter hell to put in, it would would also open up a new wave of server sophistication. You want that, don't you? D:

Also, I thought of a few more commands (that I missed, maybe):

- movePlayer(idx, x, y, z):
Adds the specified coordinates to the coordinates of the player with the specified idx. Meant to be a simpler version of setPosition.

- setPlayerVelocity(idx, vx, vy, vz, additive):
Sets the specified player's velocity to the specified velocity (or adds it, if additive is true). Meant to be a simpler version of setPosition.

- setPlayerPosition(idx, x, y, z, velx, vely, velz, angle, pitch):
Exactly the same as the original setPosition, but with pitch.
NOTE: setPosition should be removed.

- setActorPosition(tid, x, y, z, velx, vely, velz, angle, pitch):
Sets the coordinates, velocity, pitch, and angle of all actors with the specified TID.

- moveActor(tid, x, y, z):
Adds the specified coordinates to the coordinates of the actors with the specified tid. Meant to be a simpler version of setActorPosition.

- setActorVelocity(idx, vx, vy, vz, additive):
Sets the specified actors' velocity to the specified velocity (or adds it, if additive is true). Meant to be a simpler version of setActorPosition.

- executeScript(script, always, arg1, arg2, arg3):
Executes the specified script (all the time if always is true) with the specified arguments.

- getMaps():
Return an array populated with elements in the format (mapName, mapNum). The order should be the order in-game.

- changeMap(mapName):
Change the map to the specified map. If set is 1, act like 'map' was run. If set is 2, act like 'changemap', but reset the inventory.

- nextMap(set):
Go to the next map. If set is 1, act like 'map' was run. If set is 2, act like 'changemap', but reset the inventory.

- previousMap(set):
Go to the previous map. If set is 1, act like 'map' was run. If set is 2, act like 'changemap', but reset the inventory.

- restartMap(set):
Restart the map. If set is 1, act like 'map' was run. If set is 2, act like 'changemap', but reset the inventory.

- say(string, team, idx):
Say the specified string. If team is not 0, talk only to the specified team. If idx is not -1, talk only to the person with that idx. idx takes precedence over team.

- log(string, team, idx):
Log the specified string. If team is not 0, talk only to the specified team. If idx is not -1, talk only to the person with that idx. idx takes precedence over team.

- print(string, team, idx):
Print the specified string. If team is not 0, talk only to the specified team. If idx is not -1, talk only to the person with that idx. idx takes precedence over team.
User avatar (0007721)
Ijon Tichy (reporter)
2013-12-23 03:40

Okay, so this almost definitely isn't going to happen, and disabling monitoring on something brings it to the top.

Feel free to close this.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2010-12-27 23:00 Ijon Tichy New Issue
2011-06-24 19:23 Ijon Tichy Note Added: 0001812
2013-12-23 03:40 Ijon Tichy Note Added: 0007721
2013-12-27 09:42 Blzut3 Status new => closed
2013-12-27 09:42 Blzut3 Resolution open => denied






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker