Let's see if I can get this right this time(if you don't know what I mean, don't ask... )
Here's "Reality Factory Script eXtensions" version 0.1.1
Features:
File library:
Saving and loading script files at runtime(Can we say "live debugging"?)
Note: The function for saving scripts has some simkin related errors/glitches(it's a simkin function).
One in particular seems to be related to the comments in arrays bug, and I'm going to look into fixing that.
Math library:
Standard math functions... Why, you ask? Well, because this library can be accessed by any type of script.
Vector type:
Implements a vector in simkin scripts, and provides access to the comon vector math ops.
Integration into any build should be a cinch, since it only takes two simple lines of code.
My intention for RFSX is to provide generalized interfaces for advanced scripting tasks, to help alleviate the stress of figuring out jimmy-rig and work-around ways to do things. RFSX-based scripts will require a greater knowledge of simkin scripting, and in some ways more effort(in others less), but will be much more flexible and capable.
For v 0.2.0, basic gui interface and some more object types are on the agenda.
Feedback, suggestions, and bug reports will be much appreciated. Enjoy.
Edit:
Bloody hell... Forgot to export the makefile from msvc, again(I don't use visual studio for editing, so I do a command line compilation with an exported makefile...) So, when I test-compiled after breaking it down into multiple file, no errors, because it was compiling the old single file!
Well, if this package doesn't work, I'll jump of a cliff.
RFSX Library
RFSX Library
- Attachments
-
- RFSX_v0.1.3.zip
- RFSX scripting extension library, version 0.1.3
- (15.22 KiB) Downloaded 179 times
- fps
- Posts: 504
- Joined: Mon Sep 26, 2005 9:54 pm
- Location: in a magical land devoid of hope, happiness, and sanity.
Re: RFSX Library
do you work with the other programming developers here?
I would hate to see you putting hard work into something that wasn't being used.
There is a fairly large compile in the works right now, you should get in on it. If you aren't already.
I would hate to see you putting hard work into something that wasn't being used.
There is a fairly large compile in the works right now, you should get in on it. If you aren't already.
1 wrote:
for the internet is a cruel and dark place at times, and there's sex and blood everywhere.
2 wrote:
You say that like it's a bad thing.
1 wrote:
You are a bad thing.
for the internet is a cruel and dark place at times, and there's sex and blood everywhere.
2 wrote:
You say that like it's a bad thing.
1 wrote:
You are a bad thing.
Re: RFSX Library
Well, this package is kind of external from RF... It can pretty much just drop into any build, with very little effort.
But, I'm not sure I'll be continuing this... I've been contacted about working on a particular project, so I might be too busy.
But, I'm not sure I'll be continuing this... I've been contacted about working on a particular project, so I might be too busy.
"So, what's the life of a programmer like?" "...Huh? What life?!"
RF System X:
http://www.realityfactory.info/forum/vi ... f=9&t=3599
RF System X:
http://www.realityfactory.info/forum/vi ... f=9&t=3599
Re: RFSX Library
As a final note, in case I don't get back to this...
This package implements methods on Simkin scripted objects using a hashtable to method pointers. So the code can be used as a baseline for optimizing RF's scripting commands.
This package implements methods on Simkin scripted objects using a hashtable to method pointers. So the code can be used as a baseline for optimizing RF's scripting commands.
"So, what's the life of a programmer like?" "...Huh? What life?!"
RF System X:
http://www.realityfactory.info/forum/vi ... f=9&t=3599
RF System X:
http://www.realityfactory.info/forum/vi ... f=9&t=3599
Re: RFSX Library
I recently became fixated on the concept of adding function and variables to Simkin at global scope. To help in understanding the what and why of this, I'll give an example.
If a user writes a pawn script like this(pseudo-code, of course):
The Show() command will fail, because it can't find DrawHudImage(). This is because DrawHudImage() is a method of the pawn, so it can only be accessed by methods owned by the pawn(like Spawn()), and Show() is owned by inventory. This is a nasty limitation to writing complex, advanced scripts. We could edit the above example to work around this, like so:
But that is god awful ugly. And I couldn't bear the thought of doing that just to use a trig function, or check a keypress. But, I wasn't really liking how the RFSX lib was shaping up... Having to call Math.cos(number), and such(I think that's kinda ugly also...) So, I figured out a way to fix it.
For the programmers out there, in Simkin, the skExecutable is the root of, well, everything. In the method function of the ScriptedObject class, when it falls through to skScriptedExecutable, the chain will continue down through to skExecutable. Even the skInterpreter itself does this. And that's where I fixed it. I did a relatively quick little hack, that makes skExecutable fall through to the interpreter. This means we can now derive from the skInterpreter class to add built-in commands and fields, at a global scope.
There's a few things I plan to relocate, and a feature for two I want to work in, but I should have an RFSX-enhanced community release uploaded in the next 12-24 hours.
EDIT: Delayed, but it's a GOOD delay. 2-3 days.
RE-EDIT: Still delayed... I keep finding new tweaks to apply to Simkin. The latest one is storing objects back into the TreeNode structure.
If a user writes a pawn script like this(pseudo-code, of course):
Code: Select all
{
Inventory
{
Show[()
{
DrawHudImage(etc...);
}]
}
Spawn[()
{
Inventory.Show();
}]
}
Code: Select all
Show[(pawn)
{
pawn.DrawHudImage(etc...);
}]
Code: Select all
Spawn[()
{
Inventory.Show(self);
}]
For the programmers out there, in Simkin, the skExecutable is the root of, well, everything. In the method function of the ScriptedObject class, when it falls through to skScriptedExecutable, the chain will continue down through to skExecutable. Even the skInterpreter itself does this. And that's where I fixed it. I did a relatively quick little hack, that makes skExecutable fall through to the interpreter. This means we can now derive from the skInterpreter class to add built-in commands and fields, at a global scope.
There's a few things I plan to relocate, and a feature for two I want to work in, but I should have an RFSX-enhanced community release uploaded in the next 12-24 hours.
EDIT: Delayed, but it's a GOOD delay. 2-3 days.
RE-EDIT: Still delayed... I keep finding new tweaks to apply to Simkin. The latest one is storing objects back into the TreeNode structure.
"So, what's the life of a programmer like?" "...Huh? What life?!"
RF System X:
http://www.realityfactory.info/forum/vi ... f=9&t=3599
RF System X:
http://www.realityfactory.info/forum/vi ... f=9&t=3599