[Library] LövelyMoon v2

[love2d]

Hey Davidobot, great work!

Is it possible for you to add a LICENSE comment at the top of the file with attribution such as your name, website, and bVictor7364? Something like MIT or Apache 2.0 or zlib depending on your preferences?

Also, is it possible to look into adding a way to do substates. So each file is a state, but maybe easily accessible custom value such as class._id so that within the file, multiple logic blocks can occur depending on what substate we're in. Allows to reduce file bloat if you have say 100 substates, and can fit them into 10 states (files) instead of 100 files.

[Davidobot]

Hey Davidobot, great work!...

Hi! Feel free to give attribution via an MIT license and just refer to me and bVictor7364 by username. You can include my website http://davidobot.net in the credit too.

As for substates - that sounds like a bit of a niche thing. You can add such functionality relatively easily by either keeping track of the variable yourself, or by wrangling something into the lovelymoon base.

[Anase Skyrider]

Hi, I've been looking at libraries to help me with my game's internal architecture. This looks FANTASTIC for my purposes: simple to use, has enough features without being too convoluted to use (Polygamy looks very feature-rich but also too complicated for me).

Reading the code without testing it, it would appear that states' events are called in the order they're created, making addState() equivalent to a push() and destroyState() equivalent to a pop() in the call-order. If states ever need to be reordered, say because of some weird interactions with object draw order while running multiple states, you'd have to use these two functions to do so. To support this, I recommend making these changes in lovelyMoon.lua:

#141: This will return the removed state, as table.remove() returns removed tables, so if you need to store it as a local, you can. Prior to this, you'd first have to call lovelyMoon.getState(id) before calling lovelyMoon.destroyState(id).

Code: Select all

return table.remove(_slotState.states, index)

#76: If you call lovelyMoon.addState(<state_object>), it will push it to the stack *without* reinitializing the state.

Code: Select all

function lovelyMoon.addState(req, id)
	local class
	if type(req) == "table" then
		class = req
		if id then
			class._id = id
		end
	else
		class = require(req)
		class._enabled = false
		class._id = id
		class:load()
	end
	table.insert(_slotState.states, class)
	return class, state
end

Also, where does the variable `state` that is returned come from? It doesn't seem to do anything, and isn't set anywhere in this function.

Regarding lovelyMoon.event.update(dt), it appears that the line

Code: Select all

local newState = state:update(dt)

followed by the checks for newState not being nil and if it has a .close and .load function, implies that writing a state object whose :update() returns *anything* will close and reload the state (if it can). I'm not sure what the purpose of this is, but it's an undocumented usage.

The usage for state:new() is also ambiguous because the code-as-written, with the examples given, appears to function around the idea of creating state classes and then modifying the single class when you require() it. I'm not sure what place that instances of the state classes has since addState() require()s the class's file and adds that to the stack, :new() doesn't do anything to add the instance to anything, states don't have any metatable stuff that calls any extant instances, and you can't add instances to the state stack without the addState() modifications I made.

Documentation in general on what the state functions do would be appreciated since this is the only link to this project that exists. Examples:

Documentation:
State objects:

Code: Select all

state:load()

Called whenever a state is created with lovelyMoon.addState(req, id).

Code: Select all

state:close()

Called whenever a state is removed with lovelyMoon.destroyState(id).

Code: Select all

state:enable()

Called whenever a state is enabled with lovelyMoon.enableState(id).

Code: Select all

state:disable()

Called whenever a state is disabled with lovelyMoon.disableState(id).

[Anase Skyrider]

Following up on my last post, I've modified LovelyMoon for anyone to download. This file includes, in one zip, an updated demo, template, and usage guide (README.txt) for v3, as well as an MIT license (LICENSE.txt). Some minor fixes include the demo calling lovelyMoon.event instead of lovelyMoon.events.

lovelyMoon_v3.zip

(8.78 KiB) Downloaded 452 times

Changelog:
- added MIT license for Davidobot to lovelyMoon.lua, with credits to bVictor7364 and Anase Skyrider below (and separate from) the license.
- replaced lovelyMoon.new with lovelyMoon.cloneState(state). cloneState deepcopies a passed state.
- renamed the following lovelyMoon functions in order to make it more clear which state methods they call:
-- addState() -> loadState()
-- destroyState() -> removeState()
- renamed the following state methods in accordance with the above change:
-- state:destroy() -> state:remove()
- lovelyMoon.removeState() now returns the removed state when called.
- lovelyMoon.loadState() now allows you to pass a state object as the first argument. Will not call state:load() if passing a state. Loading a module will still call state:load(). You can also still pass an optional id for the second argument, this will rename the state.
- removed some code from lovelyMoon.event.update. No longer causes your state to unload and reload if state:update() returns anything.
- updated keypressed, keyreleased, mousepressed, and mousereleased events to pass parameters, up to date with LOVE 11.3.
- added wheelmoved event.
- included (simplistic) directions for adding your own LOVE callback events to lovelyMoon.lua (inside the module file itself).
- slight formatting tweaks and comments generally everywhere.

[bVictor7364]

Hi Anase Skyrider,

Your update is AWESOME! Thanks for keeping this library alive! Unfortunately, I am not using love2d full time for the time being, but I'm planning to get back to it eventually. In the meantime, I tested out your version and it's great!

I decided to adress the issue that you mentioned, that this is the only place the library is available. So, I created a github repo for it with all three versions and thei releases and appropriate credits. If you and Davidobot have github accounts, I would love to add you both as collaborators.

Here's the github repo: https://github.com/yokai-shogun/lovelyMoon

And the library can be downloaded using this link: https://github.com/yokai-shogun/lovelyM ... ses/latest

[Davidobot]

Hi both! That's really cool to see this work live on after so many years I'll update the OP as soon as I can.

My github name is the same as my username here and I starred the repo

[Anase Skyrider]

If you and Davidobot have github accounts, I would love to add you both as collaborators.

I go by https://github.com/anaseskyrider.

Also, I've thought of some use-cases for *keeping* the original state:new() function, creating state subclasses, so if you want to keep that in addition to cloneState(), it would only take a quick copy-paste to keep it in your released version 3. For one thing, it's generally more memory-efficient. Although the behavior itself is relatively simple, using very basic Lua inheritance, so anyone could easily write the three-or-so lines of code needed to create a state subclass within an individual state module's file.