Official Soldat Forums
Server Talk => Scripting Discussions and Help => Topic started by: Swompie on April 13, 2010, 01:17:14 pm
-
Ok, I've decided to make this topic since eC doesn't watch the old Scripting Core Suggestions thread anymore...
Things you should check before you post a suggestion:
- Check if it has been suggested already.
- Think about your suggestion twice before you post it.
- If the proc./func. doesn't explain itself add an description of it.
Implemented stuff through this topic
Suggestions
- function WriteINI(FileName, Section, Key: string): boolean;
- function Power(Base, Exponent: double): double;
- function GetBotStat(ID: byte; Stat: string): variant; [Click! (http://forums.soldat.pl/index.php?topic=37957.msg461795#msg461795) for more info]
- function ReadBinaryFile(const Filename: string): string; [Click! (http://forums.soldat.pl/index.php?topic=37957.msg464408#msg464408) for more info]
- Add Jet fuel, grenades, vest values to SetPlayerStat();
- Allow to use all bulletstyles with CreateBullet();
- Make OnPlayerSpeak(); return a boolean [Click! (http://forums.soldat.pl/index.php?topic=37957.msg464408#msg464408) for more info]
- Make plain bullets visible no matter which weapon players hold
- procedure CreateDirectory/CreateFolder(const Path: string);
- procedure CreateFile(const Path: string);
- -> I guess they could be combined. Note that CreateFile is already possible via WriteFileing an empty string.
- function ReadAccess(const Path: string): boolean;
- -> returns whether or not I have read access to the file
- function WriteAccess(const Path: string): boolean;
- -> returns whether or not I have write access to the file
- function ExecuteAccess(const Path: string): boolean;
- ->returns whether or not I have execution access to the file
- ->this probably will rarely if ever be used, but could possibly be used with shellexec.
This stuff will never implemented
- There will be no procedure which triggers whenever a player shoots.
- There will be no event which triggers each tick or millisecond or too often in general.
- There will be no function(s) which allow to get info or modify waypoints.
-
- procedure OnPlayerShoot(Shooter, Bulletstyle: byte);
- procedure OnTick(Ticks: integer);
Those will not be implemented. OnShoot would be called too many times(imagine 32 players shooting minigun, instant crash), OnTick too I think.
-
function GetWaypointStat(ID: byte; Stat: string): Variant;
procedure SetWaypointStat(ID: byte; Stat: string;Value: Variant);
This would add another dimension to customizability (zombie RPG scripts for example :P)
function GetBotStat(ID: byte; Stat: string): Variant;
target: byte // current target id of aggression, 0 for idle
waypoint: byte // current waypoint bot is following
string: friend // the friend name
state: byte // bot state 0 = idle/following waypoints, 1 = attacking, 2 = attacking flagger, 3 = fleeing with flag, ect
procedure SetWaypointStat(ID: byte; Stat: string;Value: Variant);
all of the things above
More to come.
-
OnKnifeThrow
(If you dont want knife throwing in your server you KillObjects (kill the knife in air))
-
OnWeaponChange already does this.
-
pow() or power() function, at the moment you have to do stupid loops.
-
Updated :O
Yeah, I think alot of other math functions should be implemented too.
One question Hacktank, why would you want to modify the waypoints?
GetBotStat is actually something nice & new, I like it!
edit
What you guys think about bows back to all gamemodes?
-
OnKnifeThrow
(If you dont want knife throwing in your server you KillObjects (kill the knife in air))
Flying knife is a bullet not object.
Oh, GetBulletStat(),KillBullet() etc :D
-
Swompie slaps Gizd with a huge Scripting Manual (http://devs.soldat.pl/wiki/index.php?title=GetObjectStat)
Style #25..
-
Swompie slaps Gizd with a huge Scripting Manual (http://devs.soldat.pl/wiki/index.php?title=GetObjectStat)
Style #25..
the knife is a bullet until it collides with something. Then it becomes an object (hence it can't deal damage any more and you can pick it up)
On a side note, this thread is turning into a mess of a discussion already <.< Not good
-
Well, dnmr, what have you expected...
-
The thread might be messy, but Swompie is taking note of all the suggested additions to the ScriptCore, so it's all good.
I reckon, if you're gonna recommend SetPlayerStat have a vest value, also recommend that GetPlayerStat to have a vest value. :D
-
also recommend that GetPlayerStat to have a vest value. :D
It does -.-
-
http://enesce.com/help/html/Functions/GetPlayerStat.html
I don't see it. :/
-
Swompie slaps Gizd with a huge Scripting Manual (http://devs.soldat.pl/wiki/index.php?title=GetObjectStat)
Style #25..
the knife is a bullet until it collides with something. Then it becomes an object (hence it can't deal damage any more and you can pick it up)
On a side note, this thread is turning into a mess of a discussion already <.< Not good
I still can learn things.. :-X
Anyway, less discussing and more suggestions are appreciated.
Edit
This manual ftw. (http://devs.soldat.pl/wiki/index.php?title=GetPlayerStat)
-
function ReadDataFile(Filename: string): string;
Same exact thing as ReadFile, except doesn't "quit" reading after that one character that makes it stop reading :P (I forget what exactly it is right now).
-
pow() or power() function, at the moment you have to do stupid loops.
http://forums.soldat.pl/index.php?topic=33387.0
Both scripted and built in functions have to do stupid loops.
-
But if it was implemented we hadn't to dig through all the scripts and then copy&paste it into our script. :P
-
tk, I love you!
-
Anyone else than me wants plain bullets spawned through CreateBullet() visible to anyone no matter which weapon he carries?
-
Anyone else than me wants plain bullets spawned through CreateBullet() visible to anyone no matter which weapon he carries?
of course
-
DoDamage should return the bulletstyle.
OnPlayerSpeak should return a boolean also to mute players/disable commands.
-
DoDamage should return the bulletstyle.
How would that be any useful?
-
Imagine >.<
For example you wouldn't need to change the weapons.ini to change damage dealt by certain guns.
Or set the damage to 0 for certain conditions like a that makes you invincible to CERTAIN bullets.
So much stuff you could do ...
-
Do you mean OnPlayerDamage? Because DoDamage is a procedure, and even if it was a function, anything it returns (besides maybe how much of the player's health was lost?) would be useless.
-
Edit my ReadDataFile suggestion please:
function ReadBinaryFile(const Filename: string): string;
Identical to ReadFile, except that it ignores the feature where it stops reading once it reaches the character 0x1A (26 dec).
http://forums.soldat.pl/index.php?topic=35628.0
http://forums.soldat.pl/index.php?topic=26661.msg428455#msg428455
I think everybody has been wishing for the OnPlayerSpeak event to no longer being threaded (reason why it cannot return a value), and to allow it to return a boolean, which action is very similar to OnCommand and OnPlayerCommand return values. That is, allowing or disallowing the message to be relayed to all the other clients. (This was in addition to DarkCrusade's comment)
http://forums.soldat.pl/index.php?topic=26661.msg327943#msg327943 - Also includes another idea: having the Text parameter of OnPlayerSpeak be reference variable, so it can be edited. This also requires OnPlayerSpeak to not be threaded.
Some topic on Soldat Forums mentioned:
function GetWaypointStat(const WId: byte; const Stat: string): variant;
procedure SetWaypointStat(const WId: byte; const Stat: string; const Value: variant);
But it can be understandable the reason why these would not be implemented. It would require sending waypoint data after players have already joined. Since you cannot manipulate the server (with scripting) so only certain players only see certain things (like bots following a waypoint), you cannot edit the waypoints; otherwise, there would be complications of what one player sees compared to another player sees a bot doing.
It would probably also take a lot of effort to edit the code such that certain bots can only follow certain waypoints, but that would be an interesting idea to see.
http://forums.soldat.pl/index.php?topic=26661.msg426548#msg426548
http://forums.soldat.pl/index.php?topic=22560.msg262527#msg262527
This (http://forums.soldat.pl/index.php?topic=22560) topic provides many other suggestions which could be added to the list, if you want.
This is more of a bug fix request, but I'll mention it anyways: INCLUDE pre-processor directive would be nice if it were working.
{$INCLUDE ./shared/binary.pas}
-
Do you mean OnPlayerDamage? Because DoDamage is a procedure, and even if it was a function, anything it returns (besides maybe how much of the player's health was lost?) would be useless.
Sorry, yeah I was talking about OnPlayerDamage.
-
Updated & heavily edited my first post, I like it much more now :-*
-
This dies, :(
-
What about this:
Function OnHit(ID,Bullet:Byte):Boolean; // ID: Player being hit, Bullet: ID of the bullet
begin
Result := false; // set to true to cancel hit registration
end;
OnHit triggers whenever a player is hit by a bullet. The only thing it does is manipulating the hit registration. This way you are able to neglect the instant kill effect of M79 and LAW or not getting pushed by shotgun pellets. There would be new possibilities for RPG mods either (like some skill that turns you into dust, you get invisible and bullets just fly through you)
Function OnPolygonTouch(ID,Type:Byte):Boolean; // ID: Player who touches a polygon
begin // Type: Polygon type
Result := false; // set to true if he shall fall through
end;
Allow different players different paths or special places (mainly for new subgame modes / RPGs)
-
@up
- There will be no procedure which triggers whenever a player shoots.
- There will be no event which triggers each tick or millisecond.
Idk how would the OnPolyTouch be implemented but I guess it would trigger really really often.
-
OnHit wouldn't trigger whenever someone shoots. It'll trigger whenever a player is being hit :3
-
OnHit wouldn't trigger whenever someone shoots. It'll trigger whenever a player is being hit :3
That won't change frequency a lot.
-
OnHit wouldn't trigger whenever someone shoots. It'll trigger whenever a player is being hit :3
That won't change frequency a lot.
How 'bout OnPlayerDamage.
And still it wouldn't be possible to negate the insta-kill explosives, because it still had to be removed the hardcoded part..
-
OnHit wouldn't trigger whenever someone shoots. It'll trigger whenever a player is being hit :3
That won't change frequency a lot.
How 'bout OnPlayerDamage.
And still it wouldn't be possible to negate the insta-kill explosives, because it still had to be removed the hardcoded part..
Ohh, but you can now. I figured out how!
When your hit with a law/m79 it automaticly setts your health to somewhere around -300 through -400. But you can completly negate this in onplayerdamage() by using result := -)getplayerstat(victim,'health') - DAMAGEYOUREALLYWANT). It works perfectly.
-
Or you just set a bullets damage to -99999 and set the health back to the original value in OnPlayerDamage
-
That is pretty much exactly what i just said. Also I am talking current release version w/o setplayerstat(). Which will fail unless it has: health, vest, primary/secondary ammo, nades, and jet.
-
More:
GetPlayerStat(ID,'Programmes'); // Returns the amount of programs running behind Soldat
GetPlayerStat(ID,'TimeConnected'); // Returns the time (in seconds) a player is connected
Makes things easier
-
wtf is programmes.. why would you need it?
And you can calculate timeconnected with two lines of code <.<
-
First: Just some random idea that came up to me when I worked on AntiCheat :3
Second: Coders are lazy, man
-
First: Just some random idea that came up to me when I worked on AntiCheat :3
...
Second: Coders are lazy, man
exactly why i think you shouldnt even bother asking for it to be implemented <.<
-
wtf is programmes.. why would you need it?
And you can calculate timeconnected with two lines of code <.<
Maybe to se if there is a hack on or something like that !
-
What about this:
GiveBonus(ID,0); // Ends all timed bonuses (berserker,predator,flamegod)
GiveBonus(ID,BonusID,Time); // Time = any integer value (in seconds)
-
Yeah, bring enesce to change some hardcoded stuff..
-
What about some kind of scriptable GUI?
Function CreateGUI(ID,Transparency:Byte; XPosition,YPosition,ScaleX,ScaleY:Single; Title:String; Colour:LongInt): Byte; // Returns the ID of the GUI, position and scale should be understandable
Function TextField(GUIID:Byte; XPosition,YPosition:Single; Title:String; Colour:LongInt): Byte; // Creates a textfield, the player is able to write something
Function CreateButton(GUIID:Byte; XPosition,YPosition,XScale,YScale:Single; Title:String; Colour:LongInt): Byte; // Creates a button, that players are able to press
Procedure OnPressButton(ID,ButtonID:Byte); // Triggers whenever a player hits a button
Procedure OnTextInput(ID:Byte; Input:String); // Triggers whenever a player uses a text field
Useful for account creation and some kind of ingame dictionary that helps people to get into subgamemodes and stuff. New vote options are available either and it should also be mentioned that this could be used for private chatting!
-
procedure CreateDirectory(const Path: string); or procedure CreateFolder(const Path: string);
procedure CreateFile(const Path: string);
I guess they could be combined. Note that CreateFile is already possible via WriteFileing an empty string.
From: June 17, 2010, 09:10:08 pm
function DirectoryExists(const Path: string): boolean;
similar to FileExists, except this works for directories (a.k.a. folders), and not files.
This can also be a used with one-another as a method to tell if a specific existing path is a directory or file, or does not exist.
-
function ReadAccess(const Path: string): boolean;
returns whether or not I have read access to the file
function WriteAccess(const Path: string): boolean;
returns whether or not I have write access to the file
function ExecuteAccess(const Path: string): boolean;
returns whether or not I have execution access to the file
this probably will rarely if ever be used, but could possibly be used with shellexec.
My main aggravation currently is how I have a directory that does not exist, I cannot even check if it exists or not (or even create it), and when writing in a non-existent directory in ActivateServer, it causes a map loading error (at least when starting the server).
It would probably be more appropriate to have the events OnActivateServer and OnActivateScript, but due to capability reasons, this probably will never happen. OnActivateServer guarantees nobody in the server when called and can be used for initializing databases (and occurring the checks if it already exists less frequently), while OnActivateScript (on compile / recompile) does not guarantee nobody on the sever, and this is equivalent to the currently known ActivateServer. I do not really expect this (and the word "On" is optional :P).
-
Added ;)
-
procedure OnJoinTeam(ID, TeamA, TeamB: byte);
TeamA - team player was in before
TeamB - team player joined
-
^
|
If you do getplayerstat(ID,'team') in OnJoinTeam it will return the previous team.
procedure ForceWeapon(ID, Primary, Secondary, Ammoprimary,AmmoSecondary: Byte); ......
-
^
|
If you do getplayerstat(ID,'team') in OnJoinTeam it will return the previous team.
And if you do GetPlayerStat(ID,'Primary') in OnWeaponChange it will return new weapon.
-
some particle support would be good (like jets and sparks)
procedure createParticles(r;g;b; speed; direction; speedRange=0; directionRange=0, amount=1);
this way we don't need to use explosions to make a sign
-
some particle support would be good (like jets and sparks)
procedure createParticles(r;g;b; speed; direction; speedRange=0; directionRange=0, amount=1);
this way we don't need to use explosions to make a sign
Haha, yeah that would be really funny and cool, may could be done with InterfaceText and InterfaceImage or how they are called, but such a function would make scripting much more exciting and servers cooler.
gonna update first post tommorow.
-
I think particles would be too heavy for soldat, and cause alot of lag and other problems.
-
I think particles would be too heavy for soldat, and cause alot of lag and other problems.
bullshit. Jets don't lag, so why would some particles lag?
-
would make scripting much more exciting
???
-
i think he means make the scripts more exciting, not the actual coding part :D
-
Remove ItemID from Intefrace/WorldText/Image functions and BigText from DrawText, and make them return an ID of Text, what will allow scripter to place as much texts on screen as he needs. You may say "then you can spam/crash some server". Well, true but there's some reason why all scripts in soldatcentral are moderated, isn't there?
-
Tbh, I think we can live with just 3 layers for DrawText, even though a few more would be quite possible.
BUT: Instead of adding new stuff I really liked a more stable server than more features ;) (Yeah, anyone wants that \o/, don't we?)
I'm not sure how helpful the Image function will be in future, but when we will be able to use custom pictures (combined with UsePackage (http://enesce.com/help/html/Functions/UsePackage.html) procedure) it would be even more helpful and nice instead of having a set of images which can't be really used for alot of things.
-
Having CrossFunc (or an equivalent function) throw exceptions not caught in the invoked function.
It is probably already possible via the use of the exception-related function, but it would require some extra code in every function that is expected to be CrossFunced.
function FuncIdtoName(const Id: cardinal): string;
function FuncNametoId(const Name: string): cardinal;
Any equivalent CrossFunc function(s) (including ThreadFunc) would be necessary if you want to CrossFunc using the id.
Although, I haven't actually tested if function identifiers are local to the script or not, but if they are, then the "equivalent CrossFunc" would have to be local to the script.
This may make CrossFuncing more efficient (but I'm not fully aware of the inner-workings of CrossFunc, so I really don't know).
The main reason to this is the ExceptionProc function/variable (haven't tested which it is) that is modified when an exception is thrown. This will make debugging a little easier.
For those who aren't aware, the exception-related functions:
procedure RaiseLastException;
procedure RaiseException(Ex: TIFException; Param: string);
function ExceptionType: TIFException;
function ExceptionParam: string;
function ExceptionProc: Cardinal;
function ExceptionPos: Cardinal;
function ExceptionToString(er: TIFException; Param: string): string;
-
GZip support. I'm not aware of the compressing and decompressing algorithms, but I'm sure they would be much faster if built into the Soldat Server rather than scripted.
-
Fix weapon parameter in OnPlayerDamage (2.7.X)
FFS, i was shooting from statgun and it was set to 4 (steyer)... Yes, i had steyer in hand. Is it linked to GetPlayerStat(Shooter, 'Primary') or what?
-
Statguns don't have their own weapon ID, not yet ;)
-
then.. fix it :P It should have, shouldn't it?
Also some new raycast parameter that tells if it should fail on Player-Collide polygons or not would be nice
-
Having the OnGameEnd (http://enesce.com/help/index.html?Events/OnGameEnd.html) event return a string for the new map. This will allow custom map lists that are dynamic based on whatever the script would like.
function OnGameEnd(): string;
-
Having the OnGameEnd (http://enesce.com/help/index.html?Events/OnGameEnd.html) event return a string for the new map. This will allow custom map lists that are dynamic based on whatever the script would like.
function OnGameEnd(): string;
dont you get enough info using onmapchange?
-
Procedure OnKeyPress(ID:Byte; Key:String);
Cool new options for scripting (admin commands, new player commands..).
-
What would be if i hold a key?
Its same as OnFire and a faster AppOnIdle.
-
This is more accurate than AppOnIdle where the user needs to press the button the moment the procedure gets called. This means that a key press will be recognized once a second.
OnKeyPress will be called everytime a player presses a key. The script will not care about the duration, it'll be called only once. This means that a player can have more taunts than usual for example. The normal taunts for messages and the new ones for commands. Also this is very useful for RPG servers and those who claim to be one.
-
Still being called to often.
-
You could just ignore the buttons that are already used by default.
-
the game would also have to know user's key settings, ignoring default wouldn't be enough
-
Not a big deal..
-
so all key presses should be sent to server? or only certain ones? which ones?
onkeypress would be called wayyy too often and easily spammable. maybe the following would be a better alternative:
My suggestion:
SetTaunt(ID:byte, taunt:string)
example:
procedure OnPlayerSpeak(ID: Byte; Text: string);
var MedTaunt, BomTaunt:string;
begin
MedTaunt := ReadFile('taunts\MedicTaunt.txt');
BomTaunt := ReadFile('taunts\BomberTaunt.txt');
if (Text = '!medic') then
begin
SetTaunt(ID, MedTaunt);
WriteConsole(ID, 'You are now a MEDIC. Press Alt+W to heal teammate.', $A00000);
end
else if (Text = '!bomb') then
begin
SetTaunt(ID, BomTaunt);
WriteConsole(ID, 'You are now a BOMBER. Press Alt+W to place mine.', $A00000);
end;
end;
Allow the server to edit individual players' in-game taunt layout. This way, scripted game modes can simply say "press Alt + W to plant mine."
Of course, the client's taunt file would never be edited, and would be used if a server doesn't use custom taunt settings, so as to not affect regular game play.
Also:
Could you organize the suggestions so far into categories?
One called "filesystem" (for all file/directory-related suggestions), another for Events, one for Functions, and an "other" category. Much appreciated!
-
My suggestions !
ServerModifier('Temperature',Rain);
Example :
procedure AppOnIdle(Ticks: integer);
begin
if timeleft = 180 then begin
ServerModifier('Temperature',SandStorm);
WriteConsole(0,'Incoming sand storm !',$EE81FAA1);
end;
end;
I don't know if that will cause a problem with the map setting ... :-\
-
@zxy: Wouldn't it be acceptable, if the scripter himself decides which keys will call OnKeyPress? Like you had a variable in your const part:
Keys = 'T|Z|U|I|O';
OnKeyPress would only be triggered by T,Z,U,I and O.
@mich: Sounds like something so unnecessary that it wouldn't even be considered to be put on the TODO list. Yet I could need this for one of my projects ...
-
Yeah but it would be nice to have it !
i don't think it will be a problem for EnEsCe (He can make it easily i think :P )
-
@DarkC:
well i feel like what i'm suggesting is more ideal because it really doesn't require so much network code editing i feel. i guess it can be placed in parallel to OnKeyPress - I'm sure E can decide better which would be better to work on.
I am also of the opinion that OnKeyPress should not be called for already-in-use keys (asdw qerfx) - too much event calling there....
@mich:
What do you mean by temperature? do you mean weather?
Your idea would allow for the map-format to remain unchanged, but probably does require a bit too much in-game map-code reworking... plus i turn these features off cuz my comp ain't the sharpest pencil in a geek's bag pack...
-
Still it would be nice to have it, not only because ServerModifier can only modify the gravity yet. I'd totally use this feature, because I am working on a Pokemon script for Soldat [pigtail]
The command would be more like
Procedure ServerModifier('Weather', Value:Byte);
'Weather': Name of the variable being modified.
Value: 0: no weather, 1: rain, 2: sandstorm, 3: snow
-
I am working on a Pokemon script for Soldat
: no weather, 1: rain, 2: sandstorm, 3: snow[/i]
...........oh dear........ let me in on the loop (PM me?). it sounds interesting, mainly cuz i can't imagine how it's going to go down.
-
Fix GetPlayerStat(ID, 'Ammo').
God, it sometimes returns so fucking fake values....
Test it yourself, called somewhere at OnWeaponChage with bunch of ForceWeapons
-
No problem with GetPlayerStat(). It's OnWeaponChange. For example if you access 'Primary' and the ID switched weapons it'll return SecondaryNum ;)
-
I already noticed this. But it sometimes returned max ammo, while i had only half or so.
-
A scripting event (or some other method) to filter what is seen by admins or on the console itself (more specifically of interest to me, admin-port dump).
-
Function OnVoteKick(Voter,Target:Byte):Boolean;
begin
Result := false;
end;
Voter: ID of the player who voted
Target: ID to be kicked
Result: Set to true to disallow the cast of the vote
Function OnVoteMap(ID:Byte; Map:String):Boolean;
begin
Result := false;
end;
Voter: ID of the player who voted
Map: Mapname of the voted map
Result: Set to true to disallow the cast of the vote
Function OnVoteKickEnd(Voter,Target:Byte; Success:Boolean):Boolean;
begin
Result := false;
end;
Voter: ID of the player who voted
Target: ID to be kicked
Success: Kicked=true
Result: Set to true to disallow the vote cast
Function OnVoteMapEnd(Voter:Byte; Map:String; Success:Boolean):Boolean;
begin
Result := false;
end;
Voter: ID of the player who voted
Map: Map to be played
Success: Successful = true
Result: Set to true to disallow the vote cast
Quite obvious suggestion. We have scripted long enough without it..
-
Suggestion for GetPlayerStat:
is Visible? (boolean) (checks to see if the user is in pred mode or not)
just a suggestion, might make it a bit easier for other devs
-
Maybe a bit more advanced:
Function GetPlayerStat(ID,'Mode'):Byte;
Result = 1: Normal
Result = 2: Berserker
Result = 3: Predator
Result = 4: Flamegod
Returns 1 if player is dead.
-
Nice suggestion ! ;D
Aleady suggested but EnEsCe didn't read it ... >:(
Function GetPlayerStat(ID,'Hair'):Byte;
1= Army
2= Punk
3= Mr.T style
4= Dreadlocks
5= Normal
Why should this be added ?
Because in rpg server player will be auto assigned classe if the player have a dreadlock hair :P
We could do the same thing with the hat,helmet or the skin :P
-
Function GetGostekStat(ID,'Stat'):Variant;
Chain: Dogtags: Byte
Hat: Hatstyle: Byte
Hair1: Hairstyle: Byte
Hair2: Colour of the hair: Longint
Face: Colour of the face: Longint
Body: Colour of the body: Longint
Legs: Colour of the legs: Longint
Same added for SetPlayerStat() would be nice ;)
-
Nice suggestion ! ;D
Dark, nice ;D
-
/me revives the dead topic
If soldat will be ever developed, please add something like "Dummy=true/false" to .bot files, so i don't have to name bot "Dummy" to make it not moving/shooting/interacting
-
/me revives the dead topic
If soldat will be ever developed, please add something like "Dummy=true/false" to .bot files, so i don't have to name bot "Dummy" to make it not moving/shooting/interacting
+1000 votes