Scripting API

[acme_pjz]

And who knows, maybe the onSave and onLoad events can be used for some interesting puzzles?

Not really At least it won't work when replaying the level record

BTW, is it useful to allow each block has its own local variables, just like C++ classes? And is it hard to implement?

[acme_pjz]

Hi everyone,

Recently I created an icon for block with scripts. It's 16x16 icon, but I think it's dull Are there anyone wants to make a better icon?

[odamite]

Hello acme_pjz,

Here's my take on the icon. I tried to follow the new inky-style. However I think that looks a bit out of place on a block but fine in the popup menu.

scripting.png (675 Bytes) Viewed 23909 times

[acme_pjz]

Hi odamite,

Your icon is better than mine Don't know if it will better if horizontally flipped because it will looks like "S", which is the first letter of "Scripting"

[Edward_Lii]

Hello odamite,

Here's my take on the icon. I tried to follow the new inky-style. However I think that looks a bit out of place on a block but fine in the popup menu.

The icon looks great.
About it looking out of place on the blocks, I agree, but it's very useful to see which blocks have scripts and which don't.
Maybe we could add a key binding that, once pressed, will show the icon for blocks with scripts.

[acme_pjz]

...
I fully agree, I implemented an enable state for blocks to substitute dynamic addition and removal of objects.
This way blocks can be disabled and re-enabled through scripting making them fully disappear, both visually and collision wise.

I found a minor problem, the moving blocks already have a property named "enabled", so if we want to expose it in scripting API we have to rename it maybe "activated"?

[Edward_Lii]

Hello acme_pjz,

I found a minor problem, the moving blocks already have a property named "enabled", so if we want to expose it in scripting API we have to rename it maybe "activated"?

I assume you mean rename the new enabled property to activated?
If so, go ahead and change it, the enabled property probably isn't used in any levels yet.

[acme_pjz]

I assume you mean rename the new enabled property to activated?
If so, go ahead and change it, the enabled property probably isn't used in any levels yet.

No, I mean the old enabled property of moving blocks Change it will only affect UI translation, though. IMHO it's confusing if a block becomes invisible when we "deactivate" it

[Edward_Lii]

Hello acme_pjz,

No, I mean the old enabled property of moving blocks Change it will only affect UI translation, though. IMHO it's confusing if a block becomes invisible when we "deactivate" it

I agree that "enable" is a bit more logical than "activated", but how do you plan on changing it?
Only naming it "(de)activated" and keeping the name in the file "disabled" for backwards compatibility will make the level files look weird:

{l Code}: {l Select All Code}

tile(ConveyorBelt,450,300){
   disabled=0
   enabled=0
   speed=2
}

Maybe we should rename it both in the UI and the levelfile, but remain compatibility with the older name?

[acme_pjz]

Hi,

I agree that "enable" is a bit more logical than "activated", but how do you plan on changing it?
Only naming it "(de)activated" and keeping the name in the file "disabled" for backwards compatibility will make the level files look weird

OK, then change the new "enabled" property to "visible"? And a notice to level designer that an invisible block isn't involved in game logic

BTW, the new "enabled" property doesn't save to the level file, right? It can be accessed with script only

[Edward_Lii]

Hello acme_pjz,

BTW, the new "enabled" property doesn't save to the level file, right? It can be accessed with script only

Not yet, I wasn't sure if this was needed.
It makes sense that if it can change during runtime it can be (pre-)set in the level file, just like the fragile state, etc...

Then again, the enabled state doesn't play nice with the leveleditor, the blocks are invisible while editing.


What if we do as you suggested first, rename the old enabled to activated/deactivated, since it makes sense for moving blocks and conveyor belts to be activated.
We won't read/store the new enabled property in level files, if the levelmaker wants a block to be disable at the start of a level he must script it in an onCreate script.
This solves the problems with editing disabled blocks.

The only thing left is the way it's named in the level file. We should still read the disabled setting for backwards compatibility, but maybe we should also start supporting "activated = 1"?

P.S. Sorry for the inconvenience.

[acme_pjz]

Hi Edward_Lii,

I have some suggestions. Currently the script code is compiled every time when script is executed. I think it will affect game performance I'd like to change the code to compile the script after the level is loaded (in level editor, after test play button clicked). We could also add some get/set function to script APIs to allow script change the event handler at rumtime . Is it a good idea?

[Edward_Lii]

Hello acme_pjz,

Currently the script code is compiled every time when script is executed. I think it will affect game performance I'd like to change the code to compile the script after the level is loaded (in level editor, after test play button clicked).

I think this is a good idea, not sure if the performance gain is noticeable on the desktop, but it is probably on mobile devices.
One thing to keep in mind is that you can't use luaL_loadstring or luaL_dostring since they expect a null terminated string and Lua bytecode can contain null characters.

We could also add some get/set function to script APIs to allow script change the event handler at rumtime . Is it a good idea?

If it isn't too hard to implementing it, sure. Not sure if it's really needed for most levels.

[acme_pjz]

Unfortunately, I can't find a way to reserve a Lua variable for future use , except for some extremely ugly ad-hoc tricks (for example save some temp variables in Lua state)

[EDIT] Ah, I found it, using LUA_REGISTRYINDEX, luaL_ref and luaL_unref

[acme_pjz]

Hi Edward_Lii,

Added a game library to the ScriptAPI, it can be used to retrieve time and number of recordings as well as winning the level through scripting.

There is a "level" library already. I think maybe we should merge them?

[Edward_Lii]

Hello acme_pjz,

There is a "level" library already. I think maybe we should merge them?

Yeah I think that isn't such a bad idea.
For some reason I thought it didn't really fit the level library since the time playing isn't really part of the level, but more the game mechanics.
But then again, it's probably better to keep the library count low and extend existing ones.

I've merged the game and level library in svn rev. 671.