stateful.lua

[SiENcE]

Ok sure, this is my bad design. Anyway thanks very much for explanation! stateful is very usefull, but i should have taken it from the very beginning.

[Puzzlem00n]

Coincidentally, I've been messing with stateful today too. Can I just ask, is there an easy way to access a function from below the current state in the stack?

For example, I have a pause state that is intended to overlay the state below it with a dark rectangle. How can I call the state below's draw function from Pause:draw()? Isn't this sort of the point of having state stacks?

(I'm löving this library, by the way. I've been meaning to start using middleclass for gamestates, and then I found out you had this. )

[kikito]

Coincidentally, I've been messing with stateful today too. Can I just ask, is there an easy way to access a function from below the current state in the stack?

First of all, don't go overblow with stacked states: most of the time one state is enough.

The states are supposed to override the methods "below" them. If you need to "still use the method below" then you should not be overriding the method on the top state.

The solution to your issue is splitting the method in question into two smaller ones - you override one, and leave the other untouched - Is the same discussion I had with Science regarding Game:draw vs Game:baseDraw.

[Puzzlem00n]

Hm. Okay. I may have slightly misunderstood the point of stacking. =)

Sorry if you literally just answered my question when talking to Science- I did skim through it, but evidently I couldn't see how it applied.

Thank you!

[enygmata]

1. Could you make the library compatible with lurker?
2. Could you please add optional state change "restrictions"?
Sometimes it is good to make sure the flow goes in a certain way, e.g. going from MainMenu to GameOver state should throw an error or warning. I think it may be possible to implement this by adding a "to" or "from" field and querying these before starting/finishing the state change.

[Puzzlem00n]

Yeah, I ran into the "compatibility with lurker" problem too. I don't think it's something that'd be easy to do, or fair to ask of Kikito. Commenting out line 85 in stateful makes it sorta work, with some bugs on state stacks. In the end, lurker is only meant for the development of the game, not the end product, so the bugs are excusable.

[kikito]

1. Could you make the library compatible with lurker?

Can you give me more information? What did you try, what did you expected to happen, and what did happen instead?

1. Could you please add optional state change "restrictions"?

No, sorry, I don't think that's frequent enough to be on the library.

[Puzzlem00n]

I can give you what I've found. Apparently, when lurker reloads values defined in states, stateful wants to put the reloaded state as a new state on top of the old one. This gives the error you assert in line 85, about putting an already existing state in the stack. Commenting out the line makes it work, obviously, but the two states still exist, which causes problems when you want to pop a state and it still exists underneath.

[kikito]

I can give you what I've found. Apparently, when lurker reloads values defined in states, stateful wants to put the reloaded state as a new state on top of the old one.

Sorry, but I don't understand what "values defined in states" means, and I have never used lurker before. Does any of you guys have a sample *.love file showing the issue?

[enygmata]

Does any of you guys have a sample *.love file showing the issue?

I attached one simple love file for testing purposes. To make the problem happen, open the menu.lua file and save it again. Lurker will reload the file and an assertion error will be thrown:

State Menu already exists on class Game