ScriptAPI changes

[Gurt]

The ScriptAPI as of version v.1.3.0 of the game is what we consider completed. There're no more planned features.

[Creeper]

So wait there are going to be more new triggers?

[chelog]

How about an event when object is destroyed? Just like OnPlayerDeathTrigger

[ShutDownMan]

I wanna ask if you will make the Static and Dynamics objects lists enable for read/write on the ScriptAPI.

There's a script I'm making that needs to go through every dynamic object, make a deep copy (or only copy it's name), and remove the object, to spawn it only later, when the player gets near it.

I don't think it's too risky to do that.

[TheOriginalCj]

I keep forgetting to look for this, but is there a library section of reserved function identifiers? I only ask because I'm now just realizing that some function names are reserved.

As for some of the questions here, I believe some of these API features will require the implementation of a few more triggers, so don't fear, they're here to stay.

EDIT: To add on this list, if any of these are not possible, they should be:

The ability for area triggers to be able to sense if there is a spesific type of projectile in the general area. (i.e. Bullet, Flare, Rocket. etc.)

A command that can get/set the current angle of a revolute joint. (This would be helpful in running an oscillation type of joint, or perhaps even a human powered switch.)

[Antonikon]

Be able to store and load data from disk (up to a certain maximum (maybe 1MB)) per map/extensionscript as persistent data.

Some time ago I found a temporary solution. I create a string with my data and add "SOMETEXT" in beginning. Then i find this text by Cheat Engine and copy hex data. Then remove all 00 code. Then use hex to ascii converter and copy data to string constant in script.

P.S
Didn't know where to post this "small hack".

[dudely-kay]

This suggestion might be silly (or in the wrong place) , but can you add methods that allow you to get or edit the characteristics of a player's skin (IProfile) or create a whole new skin ?
something like : (IProfile) skin.GetSkinColour() or (IProfile) skin.SetAccessory()

If you're creative enough, you can find good uses of such methods, for example : in case you're creating a zombie map and you want to make the "zombified" players' skins looks a bit the original skin

[Gurt]

Updated the planned ScriptAPI changes with extensions ScriptAPI only features.

Being able to modify IProfile through the ScriptAPI might be something we'll consider once we start with bots.

[Motto73]

The System.IO is a lovely thing. But that could not be used straight, because that would be quite, well, dangerous. But if you can do it, it would be great if we are allowed to write the data to a file and find it there when needed!

[Gurt]

The System.IO is a lovely thing. But that could not be used straight, because that would be quite, well, dangerous. But if you can do it, it would be great if we are allowed to write the data to a file and find it there when needed!

It will not be allowed to use System.IO in the ScriptAPI. You will have to use functions/classes provided by the ScriptAPI in some way.

[JakSparro98]

I've a question, all the code in the map script is executed as single thread?


I'm creating an AI sketch provided with pathfinding and shooting, the problem is that this heavy code seems the be executed in the game simulation thread (so multiple enemy equals huge lag), if you put while(true) the entire game simulation will freeze and you forced to kill the process.

There will ever be the possibility to run pieces of code in a separate thread? Probably meanwhile there will be already the official artificial intelligence and probably never multithreading will see the light, due for possible security issues.

[Gurt]

I've a question, all the code in the map script is executed as single thread?
...
There will ever be the possibility to run pieces of code in a separate thread?

No. The whole ScriptAPI is an afterthought and was never planned from the start to be a part of SFD. The ScriptAPI will always run in the main thread for SFD's update logic to prevent other issues such as racing conditions, deadlocks, crashes, apphangs and other problems related to "unsafe" threading when manipulating the game world in SFD. The Script also runs in a sandbox environment in another AppDomain to limit the user to prevent harmful code such as System.IO calls - this also makes the code run slower.

I have been thinking about terminating calls to the script that takes too long to run (like a while(true)) to prevent hanging but it's not the focus right now.

In general: Keep any code fast and simple to execute as it must always terminate.

You could redesign your code so it process a few iterations on your pathfinding logic before "pausing" and wait for the next update cycle and process a few more iterations.

[JakSparro98]

The ScriptAPI will always run in the main thread for SFD's update logic to prevent other issues such as racing conditions, deadlocks, crashes, apphangs and other problems related to "unsafe" threading when manipulating the game world in SFD. The Script also runs in a sandbox environment in another AppDomain to limit the user to prevent harmful code such as System.IO calls - this also makes the code run slower.

theoretically racing conditions and deadlocks are problem of who writes the script if something is not in sync or there are multiple variable assignment without an order. There wouldn't be a problem if (like you said for the while cycle) is defined a time slice for possible deadlocks, also the script sandbox would parse the code one time entirely and not when it is executed.

You could redesign your code so it process a few iterations on your pathfinding logic before "pausing" and wait for the next update cycle and process a few more iterations.

so it needs to be completed in a couple of cycles?

Currently the pathfinding build the entire path and terminates, every second since the enemy is spawned the function is invoked but works only if the new goal node is changed, after a bit of enemy istances the pathfinding is always in execution, one time for enemy3 another for the enemy7 and more the path is complex more the while cycle make the thread hangs costantly for a few milliseconds.

The path can be reused but if some enemies are pointing another player there will be different path calculation.

eventually I want to ask if the CPU AI of the classic SuperFighters was divided in threads (probably yes because of lack of third party programmers).

I know this could be off topic, I will open another in case the discussion continues.

[Gurt]

You're bringing up problems that's more or less generic for pathfinding algorithms in general.

In SFD you're limited to what you can do and can't do in the ScriptAPI.
Everything is executed in the update thread for SFD.
You can not create your own threads.

I suggest you apply some sort of round robin over your enemies when you solve the path finding. That's pretty much what we did in SF to avoid it hooging the CPU when there're many CPUs.

[JakSparro98]

A possible addition on the IPlayer class...may be usefull an IsHit boolean when you cannot record a state with Is.Staggering or Is.Falling for a player... today a simple melee/projectile hit on a crate or on a player isn't handled.

[Motto73]

The health can be manipulated via Script_Api, but stamina can't. Please make it avaible, it's a big problem for me in these custom modes, where this needs to be changed.

!	Message from: KliPeH
	Merged a separate bump into this post.

1: OnHitEvent

In the very basics something happens when any object is damaged.

We could two ways to use this:
1. Through script: We could have a listener to listen to certain hits, liek when any object is damaged

OnHitEvent(baseobject TargetObject, DamageType¹ damageType, float damageAmount, baseObject damager, bool Destroyed)

targetObject = the object that is damaged, damageType = Type of damage, damageAmount = how much damage, damager = damaging object(null if projectile), Destroyed = If the object is destroyed.

2. Through a trigger: We could have another trigger, a OnHitTrigger. I could just call for a specified script method when 1.Any object/2. Any targeted object is damaged. It would call with OnHitEvent, not with TriggerArgs.

*¹ We would need another enum for this: DamageType.Projectile, Melee, Fall(or collisions just), fire and explosion.

2. OnDestroyedEvent

Basically the same as above, but only calls if the object is destroyed.

Please comment and answer when you are able!

[JakSparro98]

Could be added an attribute with the name of the player's used language in the game.

This provides an enum type with a language list for choosing a standard language rather than a free name format given by the translation tool (first 100/50 spoken languages to choose).

It can be accessed from the IUser class to specify which player is processed by the API.

Could also be usefull to use with the individual message popup already planned, the script can behave differently depending of what language is used and if there are available messages for that language.

[JakSparro98]

With my last script request I notice that we would need of a command that prevent an object from being destroyed next tick, for instance if I catch with "DestructionInitiated" a true response then I can cancel object destruction with an ipotetic "CancelDestructionInitiated" and reset his health.

[JakSparro98]

I have other three entries for the IPlayer class:

IsBazookaRiding: boolean, true if a player is riding a bazooka rocket, false if not

GetManualAimAngle: float, gets the angle in degreer/radiants of half circle (0 to 180 because with FacingDirection
we can check the side the aiming is)

IsChatTyping: boolean, true if a player have opened the chat, false if not.

[Armadyl5]

I want to suggest adding an "infinite block" as a command