LunaLua Offical Thread

[Kevsoft]

1. If, for example, I typed "abcd", would "getInput" return the values "a", "ab", "abc" and "abcd", or "a","b","c","d"? The latter may be more useful.

It would return a string "abcd".

2. If "getInput" does return the complete string, what is the cooldown time? That is, if I typed "hello world", how long would I have to wait before pressing the "a" key such that it returns "a" instead of "hello worlda"? (Ignore this is the answer to question 1 returns individual characters)

When I tested it it was never reset until a cheat code was detected in that string.

3. Does the .length field return the length in characters or the length in bytes? It's arguably more convenient to return the length in characters, rather than raw bytes, as it doesn't require the user to know about the internal representation of strings and characters unless they need to do something involving raw data manipulation, in which case they can calculate the byte length from the character count.

Returns the the byte length. 2 bytes per character.

4. What does the "asm" library actually DO? You've given an example of its use, but not actually said what it does.

Actually it is only data manipulation but it is done in the assembly code. Currently you can manipulate the effect, sound and the coins you get per removed npc from the npcToCoins smbx function. (It is called when you hit the ending).
In this example I given does change the animation effect to a explosion and you get 13 coins per removed npc. So when you hit a exit you get a explosion effect instead of the normal coin effect

[Hoeloe]

I suggest changing how .length works so that it returns the character length, before anyone uses it. Changing it after it's been used will cause code incompatibilities.

Also, if it's not reset until a "cheat code" is detected, how do you register a cheat code? Could we see an example of this being used correctly?

[Kevsoft]

LunaLua v0.3.4.2 is out!
Changes:

*Changed that VBStr.length represent character length.
*Added VBStr.clear() to clear out a string.

Also, if it's not reset until a "cheat code" is detected, how do you register a cheat code? Could we see an example of this being used correctly?

Sure:

Code: Select all

function onLoop()
	if(getInput().str:find("sometext"))then
		printText("Here some text for you :D", 30, 300)
	end
end

function onJump() --If player jumps the reset the cheat string buffer.
	getInput():clear()
end

[Hoeloe]

Ah, okay, so you have to manually clear it, or it won't change. Alternatively, it will clear itself if you register a cheat in Autocode? Is that right?

If that's the case, has anyone worked out how to freeze the player in place during cutscenes yet? Because I just might be able to do it using this. Maybe.

[Darkchaox100]

cant you force the player to have no input by simpy setting a SMBX Event?

[Kevsoft]

Ah, okay, so you have to manually clear it, or it won't change. Alternatively, it will clear itself if you register a cheat in Autocode? Is that right?

Yes, it will clear if autocode finds a registered cheat.

[Darkchaox100]

btw kev,could you add a wait function?
lets say:
function onLoop()
if(blablabla==false)then
wait(blablabla==true)
...
So the code only continues if blablabla is True or something like that.

[Kevsoft]

This is not possible what you're trying. Simply because you would hold up the whole game loop. You might wanna try it with a counter variable.

[Hoeloe]

btw kev,could you add a wait function?
lets say:
function onLoop()
if(blablabla==false)then
wait(blablabla==true)
...
So the code only continues if blablabla is True or something like that.

Umm... that can't work. At all. It makes absolutely no sense.

The code in onLoop runs from the start every frame. The if conditional already does what you're asking, but what you've written doesn't make any sense.

I guess what you're wanting to do in that example is, once blablabla is false, wait until blablabla is true and then do something. That's very easy to do, but a "wait" function doesn't actually make sense in the context of this kind of language structure.

What you need is a boolean value. Try this:

Code: Select all

local blatest = false;

function onLoop()
if(not blatest and blablabla == false) then
   blatest = true
 elseif(blatest and blablabla == true) then
  --do a thing
  end
end

[Darkchaox100]

alright.
Anyways about disabling the player input,cant you just force the game to keep pressing the up key,so it works? I didnt tried it yet but thats something i need for my episode.

[Hoeloe]

alright.
Anyways about disabling the player input,cant you just force the game to keep pressing the up key,so it works? I didnt tried it yet but thats something i need for my episode.

You can, but that disables input for progressing text boxes as well, which makes it not very useful for cutscenes. However, it MIGHT be possible to use custom cheats to progress the text box, which would allow this to work.

[Darkchaox100]

alright.
Anyways about disabling the player input,cant you just force the game to keep pressing the up key,so it works? I didnt tried it yet but thats something i need for my episode.

You can, but that disables input for progressing text boxes as well, which makes it not very useful for cutscenes. However, it MIGHT be possible to use custom cheats to progress the text box, which would allow this to work.

Would that not work?

Code: Select all

function onKeyDown(KEY_X, 1)
 if(KEY_UP == true)then
 KEY_UP = false
 end
end

[Hoeloe]

Would that not work?

Code: Select all

function onKeyDown(KEY_X, 1)
 if(KEY_UP == true)then
 KEY_UP = false
 end
end

Nope. Player input is handled by SMBX before the Luna hook, so it's all already done by the time onKeyDown gets called.

Oh, also, you're misunderstanding how function arguments work. They are variables, you can't set them in the function definition.

[Darkchaox100]

Well the only way you can disable it yet is to use this:

Code: Select all

function onLoop()
 player:mem(KEY_JUMP, FIELD_WORD, 0xFFFF)
 player:mem(0x11E, FIELD_WORD, 1)
 player:mem(0x120, FIELD_WORD, 1)
end

(you can still change the direction the player is facing though...Dunno how to disable it)
Or you make a SMBX event and set the Player Controls to Up and with a other event you disable the Up Control again.

[Hoeloe]

Well the only way you can disable it yet is to use this:

Code: Select all

function onLoop()
 player:mem(KEY_JUMP, FIELD_WORD, 0xFFFF)
 player:mem(0x11E, FIELD_WORD, 1)
 player:mem(0x120, FIELD_WORD, 1)
end

(you can still change the direction the player is facing though...Dunno how to disable it)
Or you make a SMBX event and set the Player Controls to Up and with a other event you disable the Up Control again.

My way of doing it was going to be to set the "forced controls" on the player, which prevents inputs from working. Then, I'd use the custom cheats input to search for the string "x" (i.e. a specific button press) to progress the cutscene. I don't know if it would work, but it might be worth a shot.

[Kevsoft]

btw, KEY_JUMP doesn't represent a memory address, it is just a constant value for the onKey events.

[Darkchaox100]

My Previous code (the code i made before i deleted the post) didnt worked because the players state didnt changed...
This seems to work though now:

Code: Select all

--Variables:
stop_input=true
fix=false

--Do the Stopping!
function onLoop()
 if(stop_input==true and fix==false)then -- If the input should be disabled,
  player:mem( 0x122, FIELD_WORD, 0xFFFF) -- force the Players state to be -1/0xFFFF.Keep in mind that the Player should be on the ground.
elseif (stop_input==false and fix==false)then -- If the Input should be enabled again,
 fix=true player:mem( 0x122, FIELD_WORD, 0) -- force the Players state to be normal.
end end

--Enable the Input:
function onKeyDown(keycode, playernum)
 if(playernum == 1 and keycode == KEY_X and fix==false)then -- Use this to enable the Input again.
   stop_input=false
end end

--To Disable the input again,set stop_input to true and fix to false.

EDIT:
Removed some if... in the KeyDown function and made the code less ugly.

[Hoeloe]

Can't you just write "-1" instead of 0xFFFF? It would be easier to read.

Also, do these memory offsets have to be set explicitly during the Lua loop, or can they be done at any time? They're a little unwieldy as it is. Either way, it would probably be best to include them in a library such as cinematX. If they can just be set at any point, then some basic functions that set and reset the memory locations will work. Otherwise, the implementation of these functions can be expanded to set a boolean local to the library, which then sets the memory location during the update loop of the API. Either way, this simplifies the usage of such functions to just a single function call, which is much neater.

EDIT: Okay, so I just tried this code, and it does need to be in the onLoop function, otherwise it won't work.

OKAY! Here's a version that should be included in cinematX (perhaps with some further testing, to cover all cases):

Code: Select all

local freezePlayer = false;

function cinematX.update ()
	if(freezePlayer) then
		player:mem(0x122, FIELD_WORD, -1)
	elseif player:mem(0x122, FIELD_WORD) == -1 then
		player:mem(0x122, FIELD_WORD, 0)
	end
--And the rest of the update function of course.
end


function cinematX.freezePlayerInput()
	freezePlayer = true;
end

function cinematX.unfreezePlayerInput()
	freezePlayer = false;
end

This seems to work fine, and hides the implementation from the user, such that all they have access to is two simple functions: "freezePlayerInput" and "unfreezePlayerInput". They can call these at any time, even in coroutines, and the library will handle it such that it all works. This is much easier on the user.

EDIT: Okay, so I have noted one way this is less than perfect, in that it halts all animation and gravity. This is irritating, since it makes mid-level cutscenes less doable. If possible, we should find a way to keep gravity enabled but stop the player from moving.

[Darkchaox100]

Yeah thats something i found out too.Gravity or animations on the player doesnt seem to work anymore if you Set the state to -1.You might can change the code so it only wors if you stand on collision.

[Hoeloe]

Okay, so I have an alternative solution that supports gravity and things.

It's a little bit of a hack, but it works.

This method requires two SMBX events, one called "DisablePlayerMovement" and one called "EnablePlayerMovement".

DisablePlayerMovement should consist solely of the forced button press "Drop". EnablePlayerMovement should be a blank event.

Now, we can use exactly the same code as before in the functions to enable and disable player movement:

Code: Select all

local freezePlayer=false;

function cinematX.freezePlayerInput()
	freezePlayer = true;
end

function cinematX.unfreezePlayerInput()
	freezePlayer = false;
end

And now, we need to handle actually freezing the player in the update loop. Unfortunately, using these events will freeze the player, but also disable progressing the text in cinematX cutscenes, so there's some extra code to handle that (note: This "progress text" code should probably be put into a function that both handles call. Duplicated code is very rarely a good idea). Some of this code is identical to the input code in cinematX already:

Code: Select all

	if(freezePlayer) then
	triggerEvent("DisablePlayerMovement");
	
		-- Skip dialog if allowed
		if (getInput().str:find("x")	and		cinematX.dialogOn == true) then
			
			if (cinematX.dialogNumCharsCurrent < string.len (cinematX.dialogTextFull)
					and  cinematX.dialogSkippable == true)  then
				
				cinematX.dialogNumCharsCurrent = string.len (cinematX.dialogTextFull)
				cinematX.dialogTextTime = 0
				cinematX.dialogSpeakerTime = 0
			
			elseif  cinematX.dialogEndWithInput == true   then
				playSFX(23) -- 10 = skid, 14 = coin, 23 = shckwup
				cinematX.endDialogLine ()
			end
			getInput():clear();
		end
		
	else
	triggerEvent("EnablePlayerMovement");
	end

This causes an additional piece of text progression code to run when the player is frozen, which uses the custom cheats system, rather than the player's button presses, to handle input. The character can no longer move when frozen, but is still affected by gravity, and if key presses are done via SMBX events, can also be animated.

EDIT: If it were possible to set forced inputs directly from LunaLua, then this setup could be a lot neater, I think.

EDIT EDIT: Okay, so there is one drawback to this system - holding X will skip through the cutscene. This could be made to look like intended behaviour, but the reason it occurs is that the getInput system doesn't make a distinction between holding a button down (causing it to be typed repeatedly) and pressing it a number of times. I believe it should be possible to determine, from C++, whether or not a key is released or not, which, coupled with the current system, could allow for an entire input system to be built, separately from the SMBX one. Of course, if you're going to do that, you might as well bypass custom cheats entirely for this and just create raw event hooks in Lua which look at C++ key presses, outside the SMBX engine.

EDIT AGAIN: Okay, so a quick look at the source and some C++ event handling suggests that this might only be strictly possible with an extended library. It may be worth the effort, at some point, to attach something like SDL as a separate library, to allow for proper input event handling. I think it's far from #1 priority at the moment, but it's something to think about, at least.

[Rixithechao]

Arright, I added a library list to the wiki. Folks should go ahead and make pages for their respective libraries.

As far as progress on cinematX goes, the custom context-sensitive NPC icons are done, with different icons for different types of NPCs. NPCs you've already spoken to (since starting the level) have their icons grayed out.



Other additions:

• A crude parsing system is set up so various NPC properties (icon type, key string to reference that particular NPC, etc.) can be defined in the editor message and coroutines can be called.
• Finished implementing YES/NO dialog prompts.
• Added the beginnings of a basic sidequest framework: initQuest(string name), beginQuest(name), finishQuest(name), isQuestStarted(name), isQuestFinished(name)

I'll probably make a new video showcasing all of these things relatively soon-ish, gonna worry about disabling the player's input after I'm done with that. Then it's back to restoring the NPC movement and animation functionality.

[Hoeloe]

Arright, I added a library list to the wiki. Folks should go ahead and make pages for their respective libraries

Okay, I've done mine. I think I've got a reasonable structure for documentation on there, but if someone has a better one, feel free to use that.

Although, I am somewhat concerned about the forum login system. It gives a maximum limit on the number of characters in the password. Are they not being hashed before being stored on the server? Hashed password don't take up more space if they're longer, so a maximum character limit shouldn't be necessary. It just concerns me because non-hashed passwords are extremely insecure.

[Kevsoft]

Although, I am somewhat concerned about the forum login system. It gives a maximum limit on the number of characters in the password. Are they not being hashed before being stored on the server? Hashed password don't take up more space if they're longer, so a maximum character limit shouldn't be necessary. It just concerns me because non-hashed passwords are extremely insecure.

I just asked Wohlstand. The password in the database are hashed.

[Hoeloe]

Although, I am somewhat concerned about the forum login system. It gives a maximum limit on the number of characters in the password. Are they not being hashed before being stored on the server? Hashed password don't take up more space if they're longer, so a maximum character limit shouldn't be necessary. It just concerns me because non-hashed passwords are extremely insecure.

I just asked Wohlstand. The password in the database are hashed.

That's good to know. Not sure why there's a maximum character limit on passwords then, since it makes no difference to the size of the data on the database.

Also, I want to add that the new NPC talking system looks awesome. Might be better to make the icons only appear when you're near the NPC though, like the standard SMBX ones do, to avoid cluttering the screen. Just a thought.

[Hoeloe]

I have a new, very small, library I made!

Musix

This is an extremely simple Lua library for making music codes! It simplifies the creation of music codes so all you have to do it write down the string you want (it does have some other customisation available, too).

I've also added the documentation to the wiki.