@aprokurov said in Can't run game by 'lime test neko':

Invalid field access : set

"Invalid field access" is usually an indication for a null reference error. Perhaps you're doing something with a sprite that has already been destroyed?

Are other targets working? It seems likely they would have the same issue.

Compiling code from third chapter of tutorial "Groundwork"

It might be a bit early in the tutorial to do this, but whenever you run into trouble, you can compare your code to the finished version of the game here:

https://github.com/HaxeFlixel/flixel-demos/tree/dev/Tutorials/TurnBasedRPG/source

Btw, in your original code snippet, you check puyo for null - couldn't puyoB be null still?

if (puyo.overlaps(puyoB))
{
	return true;
}

Do you have any idea why this could be?

Reflect.fields() returns the fields something has at runtime - if a field is declared as inline, it might not show up for instance. Similarly, if length is a propery with a getter, the accessors might show up instead (get_length), but I believe this depends on the target.

Type.getClass() returns the runtime type of the object.

@grimms767 There's Type.getClass() and Type.getClassName(), which can be used together:

var className = Type.getClassName(Type.getClass(object));

For a list of fields, you could use Reflect.fields().

That said, I would try to avoid using these for the final code (although they may be useful for debugging).

Could you share some of the surrounding code? Where does puyo come from exactly? Is there any point where you cast it or it's Dynamic?

There's a chance you get "invalid field access" because the object does indeed not have a length field, because it doesn't have the type you think it does (if you subverted the type system with cast or similar, that is).

@agustín-pérez-fernández That's odd, works fine here. Same chrome version actually!

Nice game btw! Awesome that you decided to open-source it, I'm sure it can serve as a helpful learning resource.

Using FlxState for that is definitely a very unusual approach... So you're add()ing FlxState instances to the main FlxState / game state?

Usually you'd use a FlxSpriteGroup or a FlxNestedSprite. Neither of them are proper "display object containers" like you might be used to from the Flash API though.

The VSCode instructions and flixel-templates have now been updated to use the Lime extension:

https://haxeflixel.com/documentation/visual-studio-code/

(try Shift+F5 to clear the cache if you're still seeing the old version of the page)

I'm one of the maintainers of the VSCode plugin, so I guess I'm too biased to comment. ;)

Vshaxe has a decent amount of documentation:

https://github.com/vshaxe/vshaxe/wiki

The VSCode template uses hxml files that are generated on compilation for code completion (by default the Flash one for the Flash target). If you're building for another target, the selected hxml file won't have the flixel-addons dependency yet. You can change this in the status bar.

I'd recommend to use the Lime extension instead, which doesn't rely on those HXML files and updates dynamically instead:

https://marketplace.visualstudio.com/items?itemName=openfl.lime-vscode-extension

Since it generates tasks for you, you should delete any tasks from tasks.json that you're not using for debugging.

The VSCode docs will be updated for use with the Lime extension soon.