I am new to Cocos2d-x and hoping to port over some Corona SDK apps written in Lua to Cocos2d-x. I downloaded the latest stable build, 2.0.4, and when I run TestLua in the iOS simulator, I am frequently getting casting errors like:
Cocos2d: [LUA ERROR] …TestLua.app//luaScript/ParticleTest/ParticleTest.lua:148: error in function ‘create’.
argument #2 is ‘CCFiniteTimeAction’; ‘CCActionInterval’ expected.
This specific one is also mentioned in another post ( http://www.cocos2d-x.org/boards/11/topics/16280 ), but there are many others.
I do not have the knowledge to fix this as I was going to use TestLua to help me learn. Is there a plan to fix this?
I found that ActionsEaseTest had problems which other modules give you errors and where?
Note the following cast should work to fix CCRepeatForever:create there is about 30 of the
following all in ActionsEaseTest
tamara:runAction(CCRepeatForever:create(tolua.cast(seq1, ‘CCActionInterval’ )))
Andre
Yes, that casting code helps, thank you.
EffectsTest to MotionStreakTest throw the casting error. Specifically in ParticleTest (after fixing the initial error), after the third test (the second Particle Batch) this casting error is thrown by most other tests.
Looks like nothing after NodeTest is built yet.
I think there’s a bug in CCAction.pkg: it claims that CCSequence:createWithTwoActions returns a CCFiniteTimeAction, when the actual C++ code returns a CCSequence. That is, the Lua wrappers are needlessly downcasting the result of CCSequence:createWithTwoActions to the point where it’s actually a superclass of CCActionInterval (which is what CCRepeatForever:create needs) instead of a subclass. Fixing the wrapper is probably a better idea than adding casts all over everybody’s Lua code.
There’s another bug in the Lua wrapping system that causes all the particle systems examples to fail: all the example particle system classes like CCParticleGalaxy are processed by the wrapper initialization system before CCParticleSystemQuad. This doesn’t work: base classes need to be declared before subclasses. I suspect the source of the problem is that in Cocos2d.pkg, ‘$pfile “CCParticleExamples.pkg”’ comes before ‘$pfile “CCParticleSystem.pkg”’, while it really needs to come after.
Try this version and tell me if it works.
I have done some extensive changes to the code but this does not seem to use any of it.
Andre
PS: Please tell me if it works.
Andre, as far as I can tell your version works much better…I only see one error remaining on the Snow test:
ParticleTest.lua:571: error in function 'setStartColor'. argument #2 is 'const ccColor4F'; 'ccColor4F' expected.
But I’m not actually sure that changing this file (other than the ‘.’ => string.byte(‘.’) change on line 136) is a good idea. Most of the real problems lie with the Lua wrapping code, not the test code…changing the test code to work around bugs in the wrapping code sort of defeats the purpose of the testing code. Making the two fixes I suggested in the previous posts to this thread (namely, to CCAction.pkg and Cocos2d.pkg) gets all the same tests running without actually having to change the test code…I’ve tried those fixes and they work. (After those fixes, I still have to make the ‘.’=>string.byte(‘.’) change on line 136 of the test code, and the Snow test is still broken, but everything else seems to work OK.)
You can cast that one out.
I do not have to because I fix the code to ignore const.
Thank you for answering.
Andre
Fixing setStartColor and setStartColorVar in CCParticleSystem.pkg so they accept a const ccColor4F& instead of ccColor4F also fixes the problem. (That’s what the underlying C*+ functions expect now, if I’m reading the CC_PROPERTY_PASS_BY_REF macro stuff correctly.)
I think it’s clear that the .pkg files for tolua*+ are out-of-date in a lot of places, and that this is causing lots of Lua scripts to break. I really, really think it’d be better to just update the .pkg files than start adding workarounds everywhere else.
Are there plans to make sure the.pkg files are updated by the time 2.1 gets out of beta, or has Lua support been given a rather low priority in cocos2d-x?
There is some logic in the code to allow both const an none const to work but it is wrong, I think.
I also added the some logic to support multiple inheritance to tolua++ I posted this code but I do not think it is going any farther.
I am just using the stuff it works pretty well. I have translated a number of the other examples, and had to create new pkg files.
I can now code and debug LUA code on the Android which make it a bit faster to test but not a lot.
To tell you the true I am a bit bewilder by the whole thing and not to sure where this is all going.
Being retired and doing this just for fun I do not mind.
I am not sure I would put all my eggs in this basket.
Andre
Heh…I’m also theoretically retired and just doing this for fun. I’m having major second thoughts about using cocos2d-x for my project if the Lua support is going to be dodgy, though.
Who’s currently ultimately responsible for Lua support in cocos2d-x? How committed are they?
Who’s currently ultimately responsible for Lua support in cocos2d-x? How committed are they?
I have no idea. The code is very good. Lots of work being done.
I ported a released app Premix Puzzle Free to Lua and managed to get it working without too much problem. Not exactly the same but good enough.
I am trying to decide if I want to go further or look around for an alternative. Just using it on Android I guess the IOS Lua is not working.
Scott Davies seems to have HelloLua working on IOS so probably could be done.
They seem to have first started on IOS so I am surprised that the implementation only works on Android.
Andre
