[WMCoolmon]

"Fileless FS2" support.
FS2 may be run with as little as a scripting.tbl to tell it what to do and still function. Although I recommend you extract data/fonts/font01.vf from sparky_fs2.vp so you can use the text-based drawing function.

CFile system scripting support
Lets you manipulate files, to a certain degree. At this point, the read() and write() functions are modelled after the standard Lua ones, and so are not compatible with binary-based FS2 files. They will work with .tbl files just fine, although you will have to build a parser to do that. Their most valuable use is for advanced campaign- or mod- persistent data; possibly for external config files for scripts. Note that they are limited to standard FS2 directories; this is probably not going to change, although I will consider adding more directories, if there's a pressing reason for it.

SEXP Variables scripting support
Relatively straightforward. To get the name of a variable from a handle, use tostring(variable). You should be able to access all SEXP variables (non-persistent, campaign-persistent, player-persistent), although I've only tested non-persistent variables. To create a new variable, you would use

Code: [Select]

mn.SEXPVariables['newname'] = "newdata"
If the variable 'newname' already existed, that would simply change the value.

Note that there is a vulnerability - I didn't realize that the original variable setting functions did not bother to check if names and variable values were too long. The limit is 31 characters; any more will cause memory leaks.

Fixed setting handle variables
If you noticed that you couldn't set any handle variables in the more recent builds, I've fixed this bug.

Silly SEXP fixes
Ordinarily I wouldn't remember something this trivial, but oh well. A couple of the set-*-ammo functions would pop up a warning in debug builds every time they were used, because Karajorma tried to be lazy.

Conditional Hooks
These've been in for awhile, but I don't think I've given them much publicity.

Code: [Select]

;;After #State Hooks section
#Conditional Hooks
$Condition:
$Condition:
;;...
$Action:
$Action:
;;...

;;For example
$Shipclass: GTF Ulysses
$On Weapon Collision: [
   gr.FlashScreen(255, 0, 0)
]

Conditions - State, Campaign, Mission, Object type, Ship, Ship class, Ship type, Weapon class
Actions - Hook (deprecated), On Ship Collision, On Weapon Collision, On Debris Collision, On Asteroid Collision, On Warpin, On Warpout, On Death

I've spent quite a bit of time on the collision hooks. Each one will set variables in the ScriptingVariables library when the hook is triggered due to a collision, for each object. For example, a ship and an asteroid colliding will set "sv.Ship" and "sv.Asteroid"; debris and a weapon, "sv.Debris" and "sv.Weapon". Two ships, "sv.Ship" and "sv.ShipB", two weapons, "svWeapon" and "sv.WeaponB". As of now, "ship" and "shipB" are set arbitrarily. These hooks should also have working overrides. Ship & weapon collisions have been tested, debris & asteroid collisions have not been.

Scripting.html (76k, 56k beware. )
http://fs2source.warpcore.org/exes/latest/C10302006.zip

[redmenace]

Has this been committed?

[karajorma]

SEXP Variables scripting support
Relatively straightforward. To get the name of a variable from a handle, use tostring(variable). You should be able to access all SEXP variables (non-persistent, campaign-persistent, player-persistent), although I've only tested non-persistent variables. To create a new variable, you would use

Code: [Select]

mn.SEXPVariables['newname'] = "newdata"
If the variable 'newname' already existed, that would simply change the value.

Note that there is a vulnerability - I didn't realize that the original variable setting functions did not bother to check if names and variable values were too long. The limit is 31 characters; any more will cause memory leaks.

The 3.6.9 branch now has support for network-variables. That shouldn't affect your code too much but if your code doesn't go through the sexp_modify_variable() function (I think that's its name but i'm not infront of my main PC at the moment) at some point you'll need to decide whether to send a variable update packet yourself or not. There are pros and cons either way really.

Silly SEXP fixes
Ordinarily I wouldn't remember something this trivial, but oh well. A couple of the set-*-ammo functions would pop up a warning in debug builds every time they were used, because Karajorma tried to be lazy.

Oh? Is that the issue I fixed in 3.6.9? I may not have remembered to pass the change on to CVS but that was actually cause I plan to change the code when I add another network packet to deal with issues using the SEXP in multiplayer (hopefully today. If not, tomorrow).

[Wanderer]

Awesome


Have the problems related to 'plr' and 'slf' been fixed?

[WMCoolmon]

lol.

Both variables have been moved to the "sv" scripting variables library, so you don't have to worry about the engine overriding your globals by accident. They've also been expanded to fit with the typical naming conventions, so they're sv.Self and sv.Player. I haven't changed sv.Player, AFAIK, but I did expand sv.Self to work in more modes than originally.

I don't exactly remember what the problem was with the Player variable, something about fs2_open crashing when it was used...adding the isValid() function to all handles may have helped with that, but if it's an out-of-bounds thing, I may need to expand that function to check for that.

[WMCoolmon]

Oh, and yes, I did try and use the existing SEXP functions as much as possible. I didn't add any kind of networking support, as from what I recall of discussions elsewhere that's still in the works. Probably just a matter of adding another variable to the handle, though.

[Wanderer]

Ok... the problem was that with certain builds (IIRC Redmenace's) the 'plr' worked very nicely but on some other builds only the d build accepted the 'plr' and r build just caused an instant CTD without any errors.

Hmm... I couldn't see those variables - for example sv.Player - in scripting.html that you posted.. Though i suppose it isn't that difficult to iterate through the variables and grab their names from there.

[WMCoolmon]

They aren't listed because they're set by the hooks themselves, so at the time of the scripting file creation they don't exist.

I did start coding on a Globals array inside of "sv" that will appear, but I don't think it will actually do anything right now.

[Nuke]

looks good, but some of its gonna take me forever to figure out

btw whats with all of theese errors, running with retail data only (no scripts)

Code: [Select]

Error: Can't open model file <_Mekhu_HL-7>
File:\Documents and Settings\Administrator\My Documents\My Source Code\fs2_open\code\model\modelread.cpp
Line: 1870
[This filename points to the location of a file on the computer that built this executable]

Call stack:
------------------------------------------------------------------
------------------------------------------------------------------

this doesnt happen with the debug build

[WMCoolmon]

Hrm...

Here's something fun...this lists all the SEXP variables in a mission, as well as value and persistence.

Code: [Select]

#Global Hooks
$HUD: [
y = 10
num_vars = #mn.SEXPVariables
for i=1,num_vars do
--Setup
v = mn.SEXPVariables[i]
x = 10

--Name
gr.setColor(255, 255, 255, 255)
gr.drawString(tostring(v), x, y)
x = x+200

gr.setColor(192, 192, 192, 255)
--Type
gr.drawString(tostring(v.Type), x, y)
x = x+200

--Value
gr.drawString(v.Value, x, y)
x = x+200
--Persistence
gr.drawString(tostring(v.Persistence), x, y)

--Next row
y = y+10
end
]
#End

[karajorma]

Now that could be very useful. Bind it to a key and I can instantly get a list of what all my variables are at any time (Rather than having to output to messages or run via the debugger).

Could be especially useful in multiplayer tests.