(shouting)

LunaLua Offical Thread

The second SMBX collab!

Shall I stream some LunaLua live development?

Yes
23
92%
No
2
8%
 
Total votes: 25

User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: Presenting: Lunadll for Lua!

Post by Rednaxela »

Mabel wrote:trying to work on a basic AI partner and it seems ok so far; throws fireballs when an NPC gets within a certain range(its a wonky setup with generators but it works) but i have one problem

if the Actor needs to teleport to Demo the generators attached to the AI Actor kinda...dissapear upon teleporting. Is there a way to keep the attached generator on the Actor when it teleports? or possibly a way to have the actor throw things without the need of generators?
Attached? As in with attached layers? Attached layers only capture movement created by the NPC being assigned speed, and will not move in response to the NPC teleporting.

Personally, I'd suggest not using generators, and instead using the new "spawnNPC" routine in LunaLua. You can either use the version written in Lua (which has a couple optional extra parameters "respawn" and "centered"), or if you're using a new enough version of LunaLua it has a spawnNPC routine built in. To throw something would be like...

Code: Select all

local newNPC = spawnNPC(npcid, x, y, section)

-- Don't allow the new NPC to respawn (only needed for the built-in version currently)
newNPC:mem(0xDC, FIELD_WORD, 0)

-- Set up initial speed
newNPC.speedX = 5
newNPC.speedY = 0
Where you set npcid to what you want to throw, and x/y/section based on what's throwing it.
User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: Presenting: Lunadll for Lua!

Post by Rednaxela »

In other news, in the version of LunaLua on github, I've now made string and layer object properties of NPCs writeable (thanks to figuring out how to convince the VB6 runtime to allocate new arbitrary strings)! Expect this functionality in the next release Kev makes (or I can give people an early build if they prefer?)

Example uses are:

Code: Select all

npc.attachedLayerName = "TestLayer" -- Attach a layer to a NPC!

npc.attachedLayerName = "" -- Detach a layer from a NPC!

npc.layerName = "TestLayer" -- Move a NPC onto a different layer!

npc.layerObj = block.layerObj  -- Move a NPC onto a different layer by layer object instead!

npc.deathEventName = "TestEvent" -- Assign a death event to a NPC

npc.deathEventName = "" -- Remove death event from a NPC

-- Or even assign arbitrary new talk messages
npc.msg = "This is the song that never ends, it goes on and on my friends. Some people started singing it not knowing what it was."
In addition, the mem calls now support writing FIELD_STRING fields instead of just reading them.

(and so it doesn't get lost, still would like feedback on the audio buffer length thing I mentioned above)
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

Rednaxela wrote:In other news, in the version of LunaLua on github, I've now made string and layer object properties of NPCs writeable (thanks to figuring out how to convince the VB6 runtime to allocate new arbitrary strings)! Expect this functionality in the next release Kev makes (or I can give people an early build if they prefer?)
Neat. That's some interesting functionality! (Though I'm sure we could already write to the message string, since CinematX wipes it).

As for the audio buffer, 4096 seems a bit large, I agree, but it may be worth allowing the user to specify the buffer size, so they can tailor the sound design for their specific level.
Image
Image
Image
Image
Image
User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: Presenting: Lunadll for Lua!

Post by Rednaxela »

Hoeloe wrote:Neat. That's some interesting functionality! (Though I'm sure we could already write to the message string, since CinematX wipes it).
The method cinematX used, was in my opinion a bit of a messy hack with some big limitations that meant it wasn't capable of many of the examples I gave above. By that I mean... it modified VB6 strings that were already allocated (which sort of conflicts with how the VB6 runtime mostly treats them as immutable...). This had the limitation of not being able to set a string to anything longer than it was already set to, nor could it assign a string to a string pointer field that was unset. The new method I've introduced now properly allocated new strings just as normal VB6 code would, allowing you to write strings to fields that were uninitialized (perhaps rather useful in spawnNPC-style applications), or write strings that are longer than what was already set.

Aside from the sort of examples I already mentioned, being able to allocate strings properly also means there's a possibility I may be able to implement something akin to the spawnNPC routine for the purpose of creating new layers or events at runtime, which previously wouldn't have been possible as doing so definitely requires allocating new strings to give them names.
Hoeloe wrote:As for the audio buffer, 4096 seems a bit large, I agree, but it may be worth allowing the user to specify the buffer size, so they can tailor the sound design for their specific level.
Wait, allowing it to be set per-level? I'm not sure there's terribly much reason. If there any case for it to be modified, I think it ought to be per end-user rather than per-level. Regardless of level, I'd think the optimal experience would be having that buffer as small as does not cause crackle on the computer in question. I suppose if we *really* wanted to get fancy we could attempt to automatically tune this at engine startup by seeing if the audio sample rate measured against the system clock rate deviated by more than a certain amount (unless we have a proper API/callback to detect underruns) while introducing a little dummy CPU load... though not sure how reliable that would be.

I know fancier audio-related stuff (i.e. Mumble, or fancy audio editing software) often has this as an adjustable parameter though I don't usually see it as adjustable in most games. My current thinking is that perhaps just making it 2048 instead of 4096 is probably a good enough balance.

EDIT: Re-reading what you said, I'm now unsure whether you mean "their specific level" as in a SMBX level, or "their specific level" as in the level of buffering appropriate to their setup.
User avatar
Wohlstand
Moondust and TheXTech developer
Posts: 186
Joined: 10 years ago
First name: Vitaly
Pronouns: he/him/his
Location: Moscow, Russia

Re: Presenting: Lunadll for Lua!

Post by Wohlstand »

Horikawa Otane, THIS archive was forgotten:
https://docs.google.com/file/d/0B3QNPpA ... 5vT2M/edit (link on main topic "SDL Dlls + A2XT Sounds")
SDL libraries are required!

P.S. don't forget to overwrite A2MBXT sounds and musics with SMBX 1.3's from this archive
User avatar
Wohlstand
Moondust and TheXTech developer
Posts: 186
Joined: 10 years ago
First name: Vitaly
Pronouns: he/him/his
Location: Moscow, Russia

Re: Presenting: Lunadll for Lua!

Post by Wohlstand »

Horikawa Otane wrote:
Wohlstand wrote:Horikawa Otane, THIS archive was forgotten:
https://docs.google.com/file/d/0B3QNPpA ... 5vT2M/edit (link on main topic "SDL Dlls + A2XT Sounds")
SDL libraries are required!

P.S. don't forget to overwrite A2MBXT sounds and musics with SMBX 1.3's from this archive
He did this and got the same error.
Are http://www.microsoft.com/en-us/download ... x?id=40784 was installed?
MSVC 2013 application requires a special libraries :P But by anyway Windows XP supported
User avatar
Willhart
Stalker, Doxxer, and Sexual Harasser
Banned
Posts: 2434
Joined: 13 years ago
Location: Finland

Re: Presenting: Lunadll for Lua!

Post by Willhart »

Horikawa Otane wrote:Quill is having a problem with LunaDLL.
Quick googling suggests reinstalling Microsoft Visual C++ 2005 SP1 Redistributable Package for XP computer. I do suggest waiting for a second opinion before trying this though, since there are a lot of different versions of it, and I have no idea if it is the correct one.

Edit: Try downloading the one linked on the previous post.
User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: Presenting: Lunadll for Lua!

Post by Rednaxela »

Horikawa Otane wrote:
Willhart wrote:Quick googling suggests reinstalling Microsoft Visual C++ 2005 SP1 Redistributable Package for XP computer. I do suggest waiting for a second opinion before trying this though, since there are a lot of different versions of it, and I have no idea if it is the correct one.

Edit: Try downloading the one linked on the previous post.
This worked! =D
I wonder if it might not be a bad idea to include the required MSVC redistributable DLLs directly in the SMBX folder alongside LunaDLL instead relying on the user installing a system-wide copy. It would make running things simpler.
User avatar
Wohlstand
Moondust and TheXTech developer
Posts: 186
Joined: 10 years ago
First name: Vitaly
Pronouns: he/him/his
Location: Moscow, Russia

Re: Presenting: Lunadll for Lua!

Post by Wohlstand »

Rednaxela wrote:
Horikawa Otane wrote:
Willhart wrote:Quick googling suggests reinstalling Microsoft Visual C++ 2005 SP1 Redistributable Package for XP computer. I do suggest waiting for a second opinion before trying this though, since there are a lot of different versions of it, and I have no idea if it is the correct one.

Edit: Try downloading the one linked on the previous post.
This worked! =D
I wonder if it might not be a bad idea to include the required MSVC redistributable DLLs directly in the SMBX folder alongside LunaDLL instead relying on the user installing a system-wide copy. It would make running things simpler.
I includes than in my part - SDL dependencies package, but now they aren't works :P I need to add more DLL's into than package. I has alone copy of SDL dependencies while Kevin uploads only frequency updating LunaLua library and also keep old builts [he saves his DropBox space]. Now I'm working under Linux because has some important works on them. Later I will look at lost DLL's and will add into than archive
TiKi
Posts: 709
Joined: 11 years ago

Re: Presenting: Lunadll for Lua!

Post by TiKi »

1. Is there a way to make a boss like Bowser or Wart hurt by stomping?

2. Okay so imagine this. I could make hammers replace purple bombs to make Link throw hammers as his special projectile. But is there a way to increment the "bomb" counter by stabbing something then? If I just have to increase the counter manually by some other action, what would you guys have ideas?
User avatar
Kevsoft
LunaLua Master Developer
Posts: 83
Joined: 9 years ago

Re: Presenting: Lunadll for Lua!

Post by Kevsoft »

TiKi wrote:1. Is there a way to make a boss like Bowser or Wart hurt by stomping?

2. Okay so imagine this. I could make hammers replace purple bombs to make Link throw hammers as his special projectile. But is there a way to increment the "bomb" counter by stabbing something then? If I just have to increase the counter manually by some other action, what would you guys have ideas?
1. That is something with the NPC-Config related. Maybe try some NPC-Codes.

2. Currently there is no onKill or onDeath event. You might need to find something else.
User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: Presenting: Lunadll for Lua!

Post by Rednaxela »

Kevsoft wrote:
TiKi wrote:2. Okay so imagine this. I could make hammers replace purple bombs to make Link throw hammers as his special projectile. But is there a way to increment the "bomb" counter by stabbing something then? If I just have to increase the counter manually by some other action, what would you guys have ideas?
2. Currently there is no onKill or onDeath event. You might need to find something else.
Well, there is an Death SMBX event trigger, which one could create an event for and listen for, as long as no more than one die per tick. Alternatively, for the case of sword specifically, you could make your target NPC invincible with offset 0x156 invincibility frames, and then detect when it gets stabbed by detecting when the sword causes offset 0x26 "sword-invincibility-frames" to get set to the value it counts down from, and run npc:kill to make it die in spite of having the invincibility frames. As a third possible way, pNPC library persistent NPC references could also be used to detect when a NPC ceases to exist pretty easily. Lots of ways to do it.
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

So, in helping people with some Lua for MAGLX2, I've realised that there's no reliable way to deal with boss hitboxes. At the moment, we're using a hack with SMB3 bobombs, but they have a tendency to break everything if they're not set up right. To counter this, I'm implementing some new things in the colliders.lua library. So far, I've created two new functions:

Code: Select all

bounce
bounceResponse
The first function, bounce, will detect if you're bouncing on an enemy (it also returns a second value, which you can use to detect a spinjump!). The second will cause the player to "bounce", with exactly the same behaviour as jumping on a regular NPC. You do not have to be immune to damage from the NPC for this to work.

They can be used like this:

Code: Select all

for _,v in pairs(findnpcs(210,player.section)) do
      local b, s = colliders.bounce(player,v);
      if(b and s) then
		 colliders.bounceResponse(player);
      end
   end
This would allow you to spinjump on rinkas! (It won't kill them, though. You can do that by calling the NPC:kill() function.)

The bounce function can take 2 arguments. A player or NPC and a hitbox (or player or NPC).
The bounceResponce function also takes 2: A player or NPC (which will "bounce"), and an optional "height" value, which lets you control the bounce height. By default, this will be the same as for any other NPC, and will be affected by setting jumpheightBounce.

I'm going to look into seeing if I can detect other forms of player collision (Link's sword, primarily).
Image
Image
Image
Image
Image
User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: Presenting: Lunadll for Lua!

Post by Rednaxela »

Hoeloe wrote:I'm going to look into seeing if I can detect other forms of player collision (Link's sword, primarily).
If the NPC is one that doesn't die instantly from the sword (either has multiple hits, it's been granted invincibility via offset 0x156, or it was already immune to the sword specifically in some way), you can detect that it got hit by the sword specifically (or maybe tail too? Need to verify) with the countdown at offset 0x26.
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

Rednaxela wrote:
Hoeloe wrote:I'm going to look into seeing if I can detect other forms of player collision (Link's sword, primarily).
If the NPC is one that doesn't die instantly from the sword (either has multiple hits, it's been granted invincibility via offset 0x156, or it was already immune to the sword specifically in some way), you can detect that it got hit by the sword specifically (or maybe tail too? Need to verify) with the countdown at offset 0x26.
Oh, sure, but that's not what I'm trying to do. I'm trying to create a solution to completely replace default SMBX collision detection, allowing you to create your own collision bounds, or to generate them from the existing player or NPC objects. I need a way of detecting whether a specific point is touching Link's sword, not whether an NPC was hit by it.

I hope, when this library is done, that boss collision volumes can be defined as boxes or circles in Lua, and not rely on existing NPC definitions.
Image
Image
Image
Image
Image
User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: Presenting: Lunadll for Lua!

Post by Rednaxela »

Hoeloe wrote:Oh, sure, but that's not what I'm trying to do. I'm trying to create a solution to completely replace default SMBX collision detection, allowing you to create your own collision bounds, or to generate them from the existing player or NPC objects. I need a way of detecting whether a specific point is touching Link's sword, not whether an NPC was hit by it.
Ahhh, I see. Unless one wants to go with a trial-and-error estimate of sword hitbox.... some time I might be able to do research into where the sword attack hitbox size/offset is stored assuming I'm correct in my understanding that's not currently known. I know other player hitbox information is already known but don't think the sword attacks are? I have some ideas of starting points to search for that.
Last edited by Rednaxela 9 years ago, edited 1 time in total.
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

Rednaxela wrote:
Hoeloe wrote:Oh, sure, but that's not what I'm trying to do. I'm trying to create a solution to completely replace default SMBX collision detection, allowing you to create your own collision bounds, or to generate them from the existing player or NPC objects. I need a way of detecting whether a specific point is touching Link's sword, not whether an NPC was hit by it.
Ahhh, I see. Some time I might be able to do research into if the sword attack hitbox size/offset is stored anywhere assuming I'm correct in my understanding that's not currently known. I have some ideas of starting points to search for that.
That would be a huge help! I believe the only remaining things are Link's sword and the Tanooki tail, as thrown objects and projectiles are already covered by NPC-NPC collision.

Oh, and also, a suggestion for future versions of LunaLua. A useful expansion to "findnpcs" and similar functions would be the option pass tables as arguments. For example, if I called:

Code: Select all

findnpcs({1,2,3},{3,4}) 
Then it would give me a list of all npcs with ID 1,2 or 3, in sections 2 or 3.

This would make some code a lot neater, and presumably could be made more efficient than calling "npcs" and filtering through Lua (certainly more efficient than creating multiple loops using findnpcs).
Image
Image
Image
Image
Image
TiKi
Posts: 709
Joined: 11 years ago

Re: Presenting: Lunadll for Lua!

Post by TiKi »

Don't forget explosion collision.

Thanks for the help, but I think you guys have my bomb question wrong. So Link needs to stab bombs in order to get bombs to throw, but if I replace bombs with something else to get a new projectile, there wouldn't be any bombs to stab. What could I do about that?
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

TiKi wrote:Don't forget explosion collision.
Ah yes. I can easily add in collision with animations though.
Image
Image
Image
Image
Image
TiKi
Posts: 709
Joined: 11 years ago

Re: Presenting: Lunadll for Lua!

Post by TiKi »

I have NO use for this but keyholes interact with the key and SMB2 tree stems and SMW fences interact with the ladybug enemies. Even though they're BGOs. Oh! Some BGOs make the watery splash if there's water over them and you jump in the water at that point.
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

TiKi wrote:I have NO use for this but keyholes interact with the key and SMB2 tree stems and SMW fences interact with the ladybug enemies. Even though they're BGOs. Oh! Some BGOs make the watery splash if there's water over them and you jump in the water at that point.
Not actually sure what you're saying here. You want a way for the player to interact with BGOs through Lua? I mean, at the moment it's possible to fake it just by creating collision volumes using the colliders.Box command (you can do this in a for loop just after the level loads if you need to), but we'd need a way to collect data from BGOs if I were to implement this properly. I hope to augment this library with just about everything you can think of, but interaction with blocks and BGOs is currently not supported because the data structures aren't as well documented as NPCs and players (and we don't even have a way of accessing BGOs from Lua yet). At the moment, though, custom boss/enemy hitboxes are higher priority, so I'm working on those in the first instance.
Image
Image
Image
Image
Image
User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: Presenting: Lunadll for Lua!

Post by Rednaxela »

I think TiKi is simply stating some things that are already relatively common knowledge (except the ladybug fence thing maybe?) rather than asking anything.
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

Here's a thought. Would it be possible to get a variation on placeSprite that allows us to set the dimensions of the drawn sprite? Either by cropping the existing sprite down to the given size, or by scaling it accordingly. I want to add a debug option for colliders.lua that draws all the colliders on the screen, but since they're arbitrary sizes, this isn't currently possible without using an NPC for the purpose.

EDIT: On another note, I think I've got collision with Link's sword working! It may not perfectly match the existing setup, though, so if we can find out how to access Link's sword hitbox, that would be preferable.

Essentially, I'm using Link's sword countdown timer (which is helpfully positive when slashes can make contact, and negative on the cooldown) and creating a custom hitbox based on Link's own hitbox (repositioning and resizing it). I can, using that, approximate Link's sword attack. I'll do the same for the Tanooki tail, and see if I can't work out Yoshi's tongue, too...

EDIT EDIT:
Using the same trick and some new offsets I found, I've managed to get this working with both the tanooki tail and Yoshi tongue! All of Link's slash, the tail and the tongue will hit multiple times on objects, though, unless you counter it, because there's nothing to determine whether something was just hit by said thing, so that needs manually implementing.

Now there are 3 new functions:

Code: Select all

colliders.slash
colliders.tail
colliders.tongue
Each of these takes a player and another hitbox type (Player/NPC/Box/Circle), and will return true if hit by Link's sword, the tanooki or racoon tail, or Yoshi's tongue respectively.

Now onto the last bit: animation collision!

EDIT EDIT EDIT: And, done! Just needed a minor tweak! I'm going to upload this new version now!
Image
Image
Image
Image
Image
User avatar
Kevsoft
LunaLua Master Developer
Posts: 83
Joined: 9 years ago

Re: Presenting: Lunadll for Lua!

Post by Kevsoft »

LunaLua v0.6.1 is out with following changes:
* Resturctured Audio Module [Tutorial]
* New Defines Module
* Added function spawnEffect (runAnimation is now deprecated)
* Added new fields towards the Animation Class
* Added some new function signature overloads for spawnNPC
* Optimzed the VBStr fields, they can now be assigned directly to a string.
Last edited by Kevsoft 9 years ago, edited 1 time in total.
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

Kevsoft wrote: * Added function spawnEffect (replaces runAnimation)
Does this mean "runAnimation" no longer works? Because if that's the case it's horrific for backwards compatibility.
Image
Image
Image
Image
Image
Post Reply