Scripting Suggestions

[dnmr]

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 <.<

[mich1103]

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 !

[DarkCrusade]

What about this:

Code: (pascal) [Select]

GiveBonus(ID,0); // Ends all timed bonuses (berserker,predator,flamegod)
GiveBonus(ID,BonusID,Time); // Time = any integer value (in seconds)


[Swompie]

Yeah, bring enesce to change some hardcoded stuff..

[DarkCrusade]

What about some kind of scriptable GUI?

Code: (pascal) [Select]

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!

[DorkeyDear]

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 pmfunction 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.

[DorkeyDear]

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 ).

[Swompie]

Added

[Gizd]

procedure OnJoinTeam(ID, TeamA, TeamB: byte);
TeamA - team player was in before
TeamB - team player joined

[Hacktank]

^
|
If you do getplayerstat(ID,'team') in OnJoinTeam it will return the previous team.

procedure ForceWeapon(ID, Primary, Secondary, Ammoprimary,AmmoSecondary: Byte); ......

[Gizd]

^
|
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.

[As de Espada]

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

[Swompie]

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.

[Norbo]

I think particles would be too heavy for soldat, and cause alot of lag and other problems.

[Neosano]

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?

[Gizd]

would make scripting much more exciting

[Norbo]

i think he means make the scripts more exciting, not the actual coding part

[Falcon`]

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?

[Swompie]

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 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.

[DorkeyDear]

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:

Code: [Select]

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;