Script Core Suggestions

[miketh2005]

I have a script where I want to align (Draw)text to the weapons in the weapon selection menu but for that to work on custom resolution I would have to know the resolution so I can scale the text down.

I see... well you can always make it so the person can customize his screen res.

We need to know your screen resolution for this script to work!
1. *RES TYPES HERE*
2. *RES TYPES HERE*
3. *RES TYPES HERE*
etc.
Type /res *number* to set your resolution!

Good idea, eh? I'm a genius

[Serial K!ller]

I already made a /scale command that loops trough all text scale to match the possible custom resolutions :p
But if it worked automaticly it would be much easier.

[miketh2005]

Aw! Your a better genius than me How the hell did you do that? I the code public?

[Snowy]

I'm in the middle of writing a new zombie script and I've came across a few things that are missing that would make the job a lot easier (and make the result ultimately better). Some may already exist, but I havn't seen them where I've been looking (http://enesce.com/help/)

function WriteINI(FileName,Section,Key,Value: string) - inis are just better

function OnPlayerShoot(Shooter: Byte;Bullettype: Integer) : integer - called a lot so unless you want the server to lag itself to death you would have to script it sparingly.

function OnBulletKill(Shooter: Byte;Victim: Byte;Bullettype: Integer) : integer - called a lot like the one above so same deal. The Victim would store who the bullet hit, 0 if it hit the ground and perhaps -1 if it expired by time. Would be useful to make exploding rounds and flash grenades, etc.

procedure OnTick(Ticksfromsecond: byte) - call this procedure every tick storing the difference (in ticks) between it and when apponidle is called ie if you wanted to do something three times a second, you would check if ticksfromsecond = 20, 40 or 60.

procedure MovePlayer(ID: Byte; X, Y: Single, MoveBots: Boolean); - moving bots can be useful, and I figure if they are gonna get scared and not know where they're going, so be it. And if its that concerning, make them take instructions from the closest waypoint to where they are moved to, or make it the one they are trying to get to, whatever's easiest.

procedure SetSpeed(ID: Byte; Xspeed, Yspeed: double); - probs needs a bit of a recode to Soldat itself to get this to work, but it definately has its uses (I've encountered two places in the script I'm working on that would definately benefit from this)

GetPlayerStat(ID; 'MouseX') / GetPlayerStat(ID; 'MouseY') - get the position of the players mouse  (or the angle that the player is aiming, whichever the server already knows)

procedure OnObjectGrab(ID, ObjectID: byte;GrabbedInBase: boolean) - same as flag grab but for any object

procedure OnObjectShoot(Shooter, ObjectID: byte;) - would need to make shooting object possible in online play first I guess, but it would be useful for making explosive barrels and the like

function SpawnCustomObject(X,Y:Single; Imagedir: String; ObjType: Byte; Grabable: Boolean): integer; - spawn an object with a custom image on it and give it its own object type, would need the onobjectgrab procedure to have any real use. would also need an update to soldat itself for both the creating of the object and the downloading of the images used. On that note I figure you should be able to set a custom image for the grenades being used both as they appear in the gui and as they are thrown so you can make boxes of molotovs and flash bangs, etc...the ability the make custom bullettypes for any weapon and even custom weapons would be a great addition imo...just replace the files that contain the default ones when entering a server and replace then with the originals when leaving.

Thats all the ones I can remember this second. And when can we expect the playsound function to be implemented?

[SpiltCoffee]

OnPlayerShoot, OnBulletKill and OnTick will be called too often, Snowy, so it's highly, highly unlikely EnEsCe will consider those three suggestions.

[Snowy]

Yeah but its not just about how often its called...whats you do with it also counts. If scripters only use it in ways like I suggested they won't impact on performance too much. You could lag up your server if you put enough stuff happening in the apponidle procedure...the more often something is called the more careful you have to be to not overdo it.

Edit: another thing...imo m79/law/flame arrow bullets shouldn't add an extra 4000 or whatever damage onto a direct hit...when it comes to scripting, you don't always want to get an instant kill no matter what. you can sort of script around it, but that just makes it unnecessarily difficult.

[SpiltCoffee]

EnEsCe is trying to prevent people from overdoing it in the first place. He doesn't want people writing scripts that call a lot of events really often, because the ScriptCore isn't designed for that heavy kind of use.

[Snowy]

imo he should worry less about stopping poorly scripted scripts from blowing up people's computers and more about increasing the potential of scripts in general...but that's just imo

[croat1gamer]

He explained it really nice:

croat1gamer says:
Why dont you want to add such an option to the scriptcore, but simply make it “USE AT OWN RISK”
Its not like that scripters dont know what to do with it, what can it cause, and what to do to prevent server slowing down.

EnEsCe says:
Because you know everybody will use it, and it will become an extreme nuisance to hosts that run many servers such as myself. And then there is the slew of access violations it causes.

You see, if everyone starts using it, they will use it on paid servers, and it will be obviously a nuisance as it will slow down the whole computer, including the other servers.

I still didnt got an answer to this:

What about making 2 versions of soldatserver?
One which will be the “safe mode”, which will internally have the faster appondile disabled, which will be given to the server hosters, but if they want, they can use the not “safe mode” one, which will be the real soldatserver, with everything enabled.

It sounds perfectly fine to me, as its like the ReadLnSocket, it needs Safe Mode turned off to work. And to do it the players just need to do -safe 0 to disable Safe Mode, but in my suggestion, there wont be the option of disabling it, but they need to use the server version which is having it disabled already.

[Snowy]

That second quote was exactly what I was going to say before I got to the part where you said it already There needn't necessarily be two completely different versions of the server, just a command line argument or whatchacallit when starting it that determines whether the procedure is used or not (not by default I suppose), so that way if its used by hosters there isn't any way for someone to enable it and there isn't any need for a second server version.

random question: is it possible to have a 'dummy' bot in a dedicated server? I've tried removing every stat and I can get the bot to be invisible of all things but I can't get it to stay still.

[iDante]

Just name it Dummy.

Wasn't this thread supposed to be about ideas and not discussions?
Anyway possibly in the main post add a DO NOT SUGGEST: faster apponidle, onweaponfire. Might make things nicer as there've been plenty of those suggestions throughout this thread.

[EnEsCe]

Sorry guys but I have stopped monitoring this thread as of two months ago. Due to you all constantly disregarding the bold text in my first post, and since I can't manually keep it clean anymore. If you have a suggestion, you'll have to present it to me in another form.

[KEEN]

hi! I was reading some posts related with scripts... I've a proposition for include if it looks good...

I was thinking OnDataArrival enable an event with StopHere and Resume functions to take better control of what arrives at the server from the client, something like this:

procedure OnDataArrival(ID: Byte, Type,Data: String)

Parameter Info:
ID (Byte): Player ID.
Type (String): RequestGame, JoinGame, JoinTeam, LeaveGame... etc... (player related functions, for example)
Data (String): Incoming data properly.

Description:
This procedure will intercept data coming from clients

Example:

Code: [Select]

procedure OnDataArrival(ID: Byte, Type,Data: String)
begin
if (Type = 'PlayerSpeak') then // recognize the type of data
begin
if (Data = 'spam') then         // set what we want to intercept
begin
Command('/gmute ' + ID); // action accordingly
StopHere         // important, stops running the following event: OnPlayerSpeak()
else Resume // if it arrives is not what we want to intercept, continues with the next event: OnPlayerSpeak()
end;
end;
end;

surely miss a lot of information, but it's just an idea...
cya!

[mich1103]

make a /unbanlast willunban last banned guys

[Hacktank]

That has nothing to do with scripting and there is an unbanlast command that does just that.

[As de Espada]

Possibility to read binary files correctly. I am currently working with some files that are not a txt and they won't read to the end (probably becaues they have an end string token inside it or anything)

[squiddy]

Well, this topic seems a bit dead..

Anyhow, I'd like to make my suggestion: WorldText again. PLEASE! Being limited to only one text in the screen (hence DrawText) is very frustrating..

[Falcon`]

draw text layers has already been implemented. What comes to world/interface text you should not expect them anytime soon as they both seem to require netcode changes which i'd rather not touch... yet.

[squiddy]

Well, those are good news, though. If we have layers in DrawText, then it is almost the same as WorldText (except from the location of the text, obviously). That is great! =D

[Mercury92]

draw text layers has already been implemented. What comes to world/interface text you should not expect them anytime soon as they both seem to require netcode changes which i'd rather not touch... yet.

Where may I find updated docs/wiki for ScriptCore including Next Soldat update.