Scriptcore suggestions.

[tk]

Well here are some most important things that should be done in the future version of crapcore (besides adding new stuff ofc), whenever it arrives.

1. GetSpawn/PlayerStat and so on...
They should be removed, or if not removed (to keep compatibility with older scripts), there should be added some decent substitute for them.
I don't have to explain to anyone who coded sth more than a hello world application in his life, how lame solution the current functions are. Just look at their implementation:

Code: [Select]

function GetPlayerStat(ID: byte; Stat: string): Variant;
begin
  if (ID > 32) or (ID < 1) then exit;

  Stat := uppercase(Stat);
  if Stat = 'KILLS' then result := Sprite[ID].Player.Kills; //Integer
  if Stat = 'DEATHS' then result := Sprite[ID].Player.Deaths; //Integer
  if Stat = 'PING' then result := Sprite[ID].Player.PingTime; //Integer
  if Stat = 'TEAM' then result := Sprite[ID].Player.Team; //Byte
  if Stat = 'ACTIVE' then result := Sprite[ID].Active; //Boolean
  if Stat = 'IP' then result := Sprite[ID].Player.IP; //String

  if Stat = 'NAME' then result := Sprite[ID].Player.Name; //String
  if Stat = 'ALIVE' then result := iif(Sprite[ID].DeadMeat = true, false, true); //Boolean
  if Stat = 'HEALTH' then result := Sprite[ID].Health; //Integer
  if Stat = 'PRIMARY' then result := Sprite[ID].Weapon.Num; //Byte
  if Stat = 'SECONDARY' then result := Sprite[ID].SecondaryWeapon.Num; //Byte
  if Stat = 'AMMO' then result := Sprite[ID].Weapon.AmmoCount; //Byte
  if Stat = 'JETS' then result := Sprite[ID].JetsCount; //Integer
  if Stat = 'GRENADES' then result := Sprite[ID].GrenadeCount; //Byte
  if Stat = 'X' then result := Sprite[ID].Skeleton.Pos[1].x; //Single
  if Stat = 'Y' then result := Sprite[ID].Skeleton.Pos[1].y; //Single
  if Stat = 'FLAGGER' then result := iif((Sprite[ID].HoldedThing > 0) and (Thing[Sprite[ID].HoldedThing].Style < 4), true, false); //Boolean
  if Stat = 'TIME' then result := Sprite[ID].Player.PlayTime; //Integer
  if Stat = 'GROUND' then result := Sprite[ID].OnGround; //Boolean
  if Stat = 'HUMAN' then result := iif(Sprite[ID].Player.ControlMethod = HUMAN, true, false); //Boolean
  if Stat = 'VELX' then result := SpriteParts.Velocity[ID].x; //Single
  if Stat = 'VELY' then result := SpriteParts.Velocity[ID].y; //Single
  if Stat = 'VEST' then result := Sprite[ID].Vest; //Integer
  if Stat = 'TIME' then result := Sprite[ID].Player.PlayTime; //Integer
  if Stat = 'DIRECTION' then result := iif(Sprite[ID].Direction = -1, '<', '>'); //Char
end;
I guess it was already mentioned many times, but come on, this must be changed. I haven't seen more inefficient piece of code than this before.
How else the problem could be solved
-giving us access to some arrays of players vars - the best way i guess
-separate functions for each player vars, separate for active, alive, etc check - if accessible vars are impossible
-at least some numeric value as set/get...stat functions argument. There are things like enum. But not f**king string, checked against 30 matches on each call!

2. Faster Apponidle
Possibility to adjust frequency of apponidle event would be great. Currently scripters have to do many complicated, inefficient and lame workarounds for this problem, like some dummy bots hurt by falling bullets etc, just to get some better frequency than 1 call per second. The argument stated by EnEsCe why there would be no fast apponidle is "efficiency" Too fast apponidle would cause too high cpu usage. But come on, efficiency problems are located somewhere else (just see point 1). And if someone codes his script in wrong way, it's his fault, not a problem of too fast apponidle. Write your scripts in efficient way.

3. Stable threads
If not fast apponidle then give us 100% stable threads. Even though we have functions to create threads they are just useless. It's impossible to create a thread lasting for more than 30 seconds without single error or crash.

Other less important things
- Unlock some bullet types in CreateBullet - I just don't understand why they are disabled. If they "cause weaponmod problems" then FIX the problem, not just cure the situation by disabling some features.
- Fix ReadFile (or add another function) - the current version is not able to read binary files, it just cuts the string on some chars considered illegal.

[CurryWurst]

I fully support these suggestions and hope they will be implemented as soon as possible. Especially threading would offer cool new features, but please make them stable. The current Scriptcore threading implementation is ridiculous. I'm not sure if EnEsCe has ever heard of locking shared variables, but tons of access violations errors do not militate in favor of his programming abilities.

It is desired not to break compatibility to old scripts unless you consider changes like that to be of very significance.

[DorkeyDear]

@2:
Any higher CPU usage due to the script would be the scripters fault, and the server owner should not be penalized for it. It is up to the scripter to make the script in a manner that is usable by as many server owners as possible (that want it). If every call of AppOnIdle (if it were going at a faster frequency) when it was unnecessary, and a higher CPU usage is used, then the scripter may have lost a customer and it is his fault. For server hosters (e.g. EnEsCe's hosting service), I'm sure some CPU manager/regulator can be found for applications. Limit the CPU or warn the user that their Soldat server will be temporarily suspended until the problem is fixed or something along those lines. Again, lost of a customer in the eyes of the scripter, since the script would need to be removed to 'fix' the issue.

@Other (Reading binary files)
Wanted to add a reference to a bug report.

[dnmr]

Fully supporting everything said above. This should be done before any new shiny neat stuff is added |:

[Falcon`]

I'll throw in some more suggestions ("lower priority" tho)

• Pointers and Objects
  Current cr..scriptcore base on this, at least afaik. This software fully supports pointers and objects, i have no idea why this features are unavailable in soldat's scriptcore
  
• Force Weapon bow lock
  On human player, bow/flame bow can be forced only in RamboMatch. Please unlock it to all modes, and also,if possible, make (in other modes) bots NOT chase "forced rambo" as they're ready to even teamkill in this case (just give bows to two bots in ctf/inf/tm, you'll see)
  
• Extended RayCast function
  Please add some options to tell RayCast what polygons it should take into account. So some booleans playercolide and bulletcolide or just in chmod style,
  
  • 1 - scan only all+bullet colide
  • 2 - scan all+human collide
  • 3 - 1+2

[deguix]

I know I know... im sugesting to add a couple of things :/:
- OnWeaponReload event: so that I may be able to control weapon bullets spent, without resorting to the horrible AppOnIdle.
- Add an option for showing or not the weapon list in the client. My mod has all weapons, but the weapons are always determined beforehand, so the weapon list for my mod is useless.
- OnLeaveGame should have an extra parameter stating what kind of kick the player received if the 2nd param "Kicked" is true (I think it should be string). (actually, for me, it would be best to remove all kicks/bans from soldat.ini and put them in scripting, but I guess there are some non-scripted -.-)

[Hacktank]

#1 priority: , after that:

Fix dynamic array instability

Remove hard-coding of:
 - Fall damage: proc onplayerdamage
 - M79/Law: simply pass normal damage calculation to onplayerdamage, based off the weapons.ini like all the other weapons
 - berserker powerup damage: simply PRE-multiply the damage parameter of onplayerdamage by 4

Allow all guns to properly fire any bullet style. Failure will currently ensue if you try to do try to shoot stat bullets out of a normal gun. Or if you try to shoot grenades from a gun it will actually take a grenade from your normal grenade pool and shoot it, doing normal damage, if you dont have any grenades the fired nade does no damage ect.

Fix bullet styles so that any can be spawned. Currently the ONLY bullet styles that will work properly are statgun and m79. All the others have some kind of weirdness, especially flames.

setplayerstat:
health
vest
xvel
yvel
ammo
secammo
grenades
jets
x
y
kills
deaths
flags

Currently it is infeasible to have your source in multiple files because the line numbers given in errors are cumulative over all files rather than per-file, making it very cumbersome to debug.

MySQL

[DorkeyDear]

Fix dynamic array instability

Do you have a specific example? I've heard dynamic arrays can be unstable but I never really witnessed it myself and don't want to have issues with it The most i've seen was an uninitialized dynamic array (easy fix though: my_ary := []; ).

Currently it is infeasible to have your source in multiple files because the line numbers given in errors are cumulative over all files rather than per-file, making it very cumbersome to debug.

this may help. its what i use for my large scripts (helps a ton)