Best posts made by IBwWG

@rknonchalance Just for an example of HTML5 size, for a game I recently did for a jam, the added weight to the output JS was about 3 MB. But that included all my game code too.

I import flash.net.URLLoader; instead of nme.... and it works for me...worth a try? As for Event you probably want to import openfl.events.Event;.

The plot gets weirder. After figuring out the the crashing bug and fixing it, I put the switch statement back.

Again my game doesn't react right, but also doesn't give an error. Now, however, the "done the switch statement" is logged to the console (after starting out and default.)

I'm really curious how switch vs if/else makes such a big difference to the functionality. That "default" should definitely not be the one being hit, if you look at the other traces--it should instead hit the line that traces "we should get here".

@Claudio-Ficara What's my working area? I would think the class, since it's a private class variable, but outside the class such a statement wouldn't even compile. That's why I think it only applies to static variables, or perhaps variables you pass between states (or keep "alive" in some other way.)

As for "better ways of course" I would love to be educated on this point but maybe I should open a new thread for that. :)

Another word of caution, if you're add()ing rather than insert()ing with the thought of putting something at the top of the z-order, the above strategy of putting it in a FlxGroup is insufficient. Check FlxGroup.add()'s doc--it will just put your object back in the same spot--or even lower--because it reuses the first null spot it comes across.

OK, if anyone's interested in this, you'll need these two pieces:

https://github.com/openfl/openfl/pull/1165
https://github.com/HaxeFlixel/flixel-addons/pull/256

And then you'll also need to supply a path, since, as Gama11 said, there's no file picker dialog right now on legacy.

If you're using the excellent crashdumper anyway, you can use my code, which depends on it (Util and a crashdumper instance):

		var path = Main.crashDumper.path + "screenshots/";
		if (!FileSystem.exists(Util.pathFix(path)))
			FileSystem.createDirectory(path);
		FlxScreenGrab.presetPath = path;
		FlxScreenGrab.defineHotKeys(["F12"], true, false);

Then just put this in any state's create() that you want to screenshot from:

add(new FlxScreenGrab());

The other day I encountered of these issues that I think is HaxeFlixel-related, and then I cannot manage to reproduce. (Well, I'm sure I could, given enough time, but I'm trying to push for final.)

But in case the workaround is of use...

I had this line in a function, which, via trace calls, I verified was called only once:

FlxTween.tween(sidePanel, {x: sidePanelLeftStop}, 0.6, { ease: FlxEase.quintIn } ).then(FlxTween.num(0, 1, 0.8, { ease: FlxEase.circOut }, fadeMap));

Yet, fadeMap was getting called at the end of the run twice with the value 1, instead of only once:

MapState.hx:142: fademap,0.661437827766148
MapState.hx:142: fademap,0.74535599249993
MapState.hx:142: fademap,0.812232862067414
MapState.hx:142: fademap,0.866025403784439
MapState.hx:142: fademap,0.90905934288631
MapState.hx:142: fademap,0.942809041582063
MapState.hx:142: fademap,0.968245836551854
MapState.hx:142: fademap,0.986013297183269
MapState.hx:142: fademap,0.996521728591783
MapState.hx:142: fademap,1
MapState.hx:142: fademap,1

(In isolated reproductions, it got called only once, as expected.) Unfortunately, I had some other code I wanted to chain after it, which was not a tween, so I had been banking on the call with 1 being passed; there was some game logic happening in there, which, if executed twice, introduced a pretty nasty bug.

So the quick and dirty workaround was:

	var doubleVOneWorkaround:Bool = false;
	function fadeMap(v:Float){
		trace("fademap", v);
		if (v == 1 && !doubleVOneWorkaround) {
			doubleVOneWorkaround = true;
			// the rest of the stuff I want executed only once, here

No idea what that was about, but this fixed the bug.

@LangLearn-Korean ONESHOT is the default (so you can omit it, and the whole options param). I think they auto-recycle. I've never tried pooling them.

I can confirm that it's definitely not safe to call dumpCache() on cpp, if you intend to use pixel perfect collision checks! It results in your collisions never colliding because they get checked against an auto-generated transparent image.

I can also confirm it is safe to call dumpCache() on flash, even with collision checks, because, IIRC, it doesn't do anything anyway on that platform.