LÖVE

Eumm ... what? ... fixed already? These youngsters are too fast for me. (... Where did I put my teeth?)

Thanks for fixing that for me ...again!

Note taken about testing code before putting it on the wiki. I've learned the lesson and keep it in mind for my next update.

However, I don't agree with you in something - I do think that a non-working example is better than no example at all: at least, the later can be fixed by some gifted individual on the internet . But don't worry, I'm not counting on this to happen in the future.

By the way, Robin, would you be interested in peer-reviewing the next update before I release it to the wild? I promise it can be interesting... and challenging!

agreed; broken example is better than nothing. :] thanks guys. ill post further questions in the general section to keep this place clear

kikito wrote:By the way, Robin, would you be interested in peer-reviewing the next update before I release it to the wild? I promise it can be interesting... and challenging!

Provided I have time, sure, why not?

alright, fiddling with passion avalanche right now; when i put right after line 17 i get an error. i tried setSpin and the same thing happened. then i tried to split setPosition into setX and setY and that worked. so it's working with some functions and not others. don't know the problem. the error is:

passion/hasBody.lua 116 attempt to call field '?' (a nil value).

so am i making an error somewhere or is it broken?

Hi Pliskin,

I'm afraid setVelocity and setSpin where changed to setLinearVelocity and setAngularVelocity on 0.6 ... and the code on the example hasn't taken this name change into account.

If you want to use them, you must update the delegatedMethods on HasBody.lua, to this: And then use self:setLinearVelocity and self:setAngularVelocity.

This works on my current version of PÄSSION. I'll try to set up a google project today so people can keep up with the most up-to-date code more easily.

Done!

The latest sourcecode can be downloaded from the new google code page.

Warning: the current version includes some new stuff (StatefulObject.lua) that still doesn't work - even the file name isn't definitive. If I'm not able to fix it by myself in 3 days, I'll ask for help on another post.

Regards!

oo they look exciting. hopefully development goes smoothly

Ok this is starting to look interesting.

I've got some good news, but I've also hit a problem for which I need help (hopefully from the LÖVE core team)

*** GOOD NEWS ***

Now I've got Stateful classes more or less set up - Actors are Stateful classes.

A stateful class is a class with a currentState property. The current state is a list of functions(1) that "override" the default classes' methods. States work with inheritance and (will/might work now but I haven't tested yet) with interfaces.

On the example I'm attaching, a "Player" actor represented by a rectangle can move left and right with the arrow keys, and jump with the "up arrow". But he can't jump while he's on air. Instead of using a boolean for "playerCanJump", i used "Player" class has two states(2). "Air" and "Ground". While on the ground, the player can "jump" - when not touching ground, the actor is on "Air". The "Air" state redefines a method called "jump" so it does nothing.

Yes I'm aware that the player "sticks to walls" like spiderman. An interesting side effect that might come out handy later.

The attached example also "colors" the scenery in green when the player is touching it, and shows tiny circles on the player's origin of coordinates and cotact points with the scenery.

*** HELP NEEDED *** .love file works, uncompressed folder fails

The title says it all. This sample works ok as long as it is compressed on a .love file.

However, when I try to use the uncompressed folder (drag-n-dropping the folder to the love executable) I got an error message - which basically says that one of my variables is not set. I've tried commenting out the line that throws the error (it is one of my control asserts in PÄSSION). And that's where the weird things start... the assert keeps failing, even if I commented out the assert line.

It looks as if the love executable is storing an "older" copy of my files somewhere on a temp folder - it certainly isn't receiving the right "folder" when I drag-n-drop folders on it any more. For .love files, it runs as it should, though.

This is a big pain for me since now I've got to manually select, compress and rename my folder every time I want to test a change. Not cool.

I'm using the latest version from the builds(20091214 - 301312c82b00) on winXP.

I'd appreciate any feedback from anyone regarding this issue. Are you having similar problems on MacOS or Linux? Does anyone know of any "temporary cache" that I could purge?

Thanks a lot!

(1) -well, really the states are classes; the current state is an instance of a "state class".
(2) The states are actually inside the parent actor class, Pawn. Player inherits from Pawn. I did it this way so in the future I could inherit Enemy from Pawn, and have the enemies use the same rules for movement as the player.

Works fine for me, I'm running on Windows Vista.

kikito wrote:Yes I'm aware that the player "sticks to walls" like spiderman. An interesting side effect that might come out handy later.

Seems familiar. In LovelyBigPlanet, you can hang onto walls and ceilings, and we've found uses for them.

It works for me, even when uncompressed. There should not be any "cache" problems. Are sure you are unzipping it to a new (empty) directory?

Two unrelated things:

One thing in your code: The usual way to do this is: And one thing while playing: if you jump on the box, you can't walk off it. Is this by design? The only way you can get off it is by jumping, which you can't unless you remove in Pawn:touching().