Small to go into Eternity tonight, no later

I was able to easily code a test program that includes the 3 (yes only 3, not 8) modules that comprise the interpreter and some basic native functions that are needed to program anything substantive. As an exercise, I proceeded to code first a Hello World program in Small, and then I ported fraggle's "Ali-G" simulator (passé but still amusing nonetheless) from FraggleScript to Small.

Issues that were formerly outstanding that have now been addressed follow:

* Waiting scripts and saving state of execution in save games -- I have decided to replace the ability to make scripts wait with the ability to register callback scripts with the engine. For instance, if you want to do something when a particular tagged sector has stopped moving, then you would ask the game (by calling a function) to call a particular script at that time. I've thought it through and anything that's possible via waiting is possible through callbacks, and not only that, they ultimately lead to better, more structured scripts. This also removes the need for me to save the state of the Small virtual machine's registers, IP, etc. All that will need to be saved is the heap, and that's just a linear block of data, and of course the list of scheduled callbacks.

Well, that's it actually. This is gonna be fun!

Actually, I thought of something else I solved. Since line script triggers of types 273-280 can only hold a script number without the use of some kind of ExtraData, but Small functions are named rather than numbered, I will allow a numeric translation table to be put in MapInfo. So basically, if you had these functions in your script:

LineZeroEvent()
LineTwoStuff()
DoSomething()

then you could give them numeric aliases in MapInfo like this:

[scripts]
bin = LUMPNAME
LineZeroEvent = 0
LineTwoStuff = 44
DoSomething = 999

So then in the map you'd use 0, 44, or 999 respectively in the tag fields. Line-triggered script functions would be required to either have a certain number/type of parameters, or to retrieve that info through functions -- that's one outstanding issue I still have to make a decision on. Any input?

tonight½!"½! w00t!!!! /me faints

...rather than cluttering up the mapinfo, why not just have those linetypes call a specific function, which then calls the desired function based on the tag?

(So it's more programmer time wasted, pfah. It makes the results more flexible, since you're not stuck with the same parameter list for all those functions.)

And as far as what should be passed to that function... just the activating object.

Sounds needlessly complex.

Well, I never! :P

You're right actually. I don't like the lookup table idea any more. But requiring a standard public script to be available doesn't strike me very well either, its just more code the user will have to write.

There IS one solution I'm looking at. Small already numbers its public functions with an index number. What I'm trying to find out now is if there's a way for the end-user to see the function indices without having to run the script and explicitly ask for them. If so, I could just have the user use Small's index number for the function, and call directly by index without having to lookup the identifier via the virtual machine. Small range-checks the function index at run-time, so invalid indices would be caught and are a non-issue.

One possible problem is that the index number could change arbitrarily when the script is recompiled :/

I have one question.


will Small be able to play abientsounds globally?

like void ambientsound() in fragglescript?

or better yet, will it support mp3 playback in maps? (call me stupid but I am just curious)

I will provide a similar function for global sounds. It'll probably be called GlobalSound rather than ambientsound, as the name is kind of misleading, and I also have some other plans for ambience as well.

MP3 support cannot be enabled through a scripting language. That requires sound library support. Also, with the problems surfacing about patents with respect to MP3, I would not be in a hurry to use it in a program. Some free format like OGG would be better, if I was intending to support such a thing. Right now I'm not, but I do plan on adding audio cd support eventually.