flixel
flixel copied to clipboard
FlxTypedSignal is not found when it exists
- Haxe version: 4.3.3
- Flixel version: 5.6.2
- OpenFL version: 9.2.2
- Lime version: 8.1.2
- Affected targets: Windows Linux
To start, I have been having this issue with the game compiling with Haxe 4.3.3, and only 4.3.3 since it doesn't seem to occur in 4.2.5, see below.
Observed behavior:
/home/moxie/haxe/lib/flixel/5,6,2/flixel/input/actions/FlxActionManager.hx:54: characters 47-96 : Type not found : FlxTypedSignal
/home/moxie/haxe/lib/flixel/5,6,2/flixel/input/gamepad/FlxGamepadManager.hx:46: characters 44-76 : Type not found : FlxTypedSignal
Was tested in Linux, but it seems to occur for Windows too, I have tried -clean or -final but both end with the same results.
Expected behavior: The game to compile.
are these the only 2 errors you're getting?
are these the only 2 errors you're getting?
yeah
wait nevermind, you can add this too
/home/moxie/haxe/lib/flixel/5,6,2/flixel/FlxCamera.hx:30: characters 31-68 : Module flixel.graphics.tile.FlxDrawQuadsItem does not define type FlxDrawQuadsItem
does it happen when you create a new template project? Does it happen on a flixel demo?
doesn't happen for a blank project, and I'll try the demo when I can get enough space
okay so uhm, I'm supposed to lime build with the demos right? because they are either taking a god awful long time to compile or nothing is actually happening
cpp builds take a while, try html5?
cpp builds take a while, try html5?
okay sure
This same thing is happening to me, minus another weird error that may be my fault:
C:/HaxeToolkit/haxe/lib/flixel/5,6,2/flixel/group/FlxGroup.hx:68: characters 37-60 : Type not found : FlxTypedSignal C:\HaxeToolkit\haxe\std/haxe/MainLoop.hx:33: characters 50-72 : Void should be Float C:/HaxeToolkit/haxe/lib/flixel/5,6,2/flixel/system/frontEnds/SignalFrontEnd.hx:14: characters 43-52 : Type not found : FlxSignal
I tried replacing it with an older version of FlxSignal.hx, which I know worked, but now I'm getting these errors:
C:/HaxeToolkit/haxe/lib/flixel/5,6,2/flixel/group/FlxGroup.hx:68: characters 37-60 : Type not found : FlxTypedSignal export/windows/haxe/ApplicationMain.hx:153: characters 5-36 : ... Called from macro here C:/HaxeToolkit/haxe/lib/flixel/5,6,2/flixel/system/frontEnds/SignalFrontEnd.hx:14: characters 43-52 : Type not found : FlxSignal export/windows/haxe/ApplicationMain.hx:153: characters 5-36 : ... Called from macro here C:/HaxeToolkit/haxe/lib/flixel/5,6,2/flixel/system/frontEnds/DebuggerFrontEnd.hx:42: characters 45-54 : Type not found : FlxSignal export/windows/haxe/ApplicationMain.hx:153: characters 5-36 : ... Called from macro here C:/HaxeToolkit/haxe/lib/flixel/5,6,2/flixel/system/debug/FlxDebugger.hx:58: character 16 : You cannot use @:build inside a macro : make sure that your type is not used in macro export/windows/haxe/ApplicationMain.hx:153: characters 5-36 : ... Called from macro here C:/HaxeToolkit/haxe/lib/flixel/5,6,2/flixel/system/debug/FlxDebugger.hx:55: character 16 : You cannot use @:build inside a macro : make sure that your type is not used in macro export/windows/haxe/ApplicationMain.hx:153: characters 5-36 : ... Called from macro here C:/HaxeToolkit/haxe/lib/flixel/5,6,2/flixel/system/debug/FlxDebugger.hx:52: character 16 : You cannot use @:build inside a macro : make sure that your type is not used in macro
I fixed it but honestly i can't even tell how.
This same thing is happening to me, minus another weird error that may be my fault
the way haxe compilers work, if you have errors in your code, it may cause other files to falsely report errors, so always start with fixing any errors in your code before worrying about errors in depended libs
@moxie-coder Do you happen to have an import.hx file in the source code you're testing? I was working with somebody else's project and encountered the same error. I managed to fix it by wrapping the entirety of its import file in a if !macro conditional compilation block.
apparently people shadowing flixel files fixed this by removing the shadowing files
@moxie-coder Do you happen to have an
import.hxfile in the source code you're testing? I was working with somebody else's project and encountered the same error. I managed to fix it by wrapping the entirety of its import file in aif !macroconditional compilation block.
I already did that, and it still happens
cpp builds take a while, try html5?
okay sure
did you ever try this?
apparently people shadowing flixel files fixed this by removing the shadowing files
or this?
Been having the same issue recently, even with only a (mostly empty) flixel tpl Haxe: 4.3.4 Flixel: 5.7.2 OpenFL: 9.3.3 Lime: 8.1.2 I've tested on HashLink and C++, and I'm not using any extra defines
update: this was likely due to me shadowing 29 classes in my FNF mod so I'm just gonna go ahead and close this
update: this was likely due to me shadowing 29 classes in my FNF mod so I'm just gonna go ahead and close this
@moxie-coder when you feel you need to shadow a class, it would be helpful if you made a discussion about it. we may offer alternatives, or make a change that accommodates your need. if you don't tell me what problems flixel is causing you I can't do anything to help
update: this was likely due to me shadowing 29 classes in my FNF mod so I'm just gonna go ahead and close this
@moxie-coder when you feel you need to shadow a class, it would be helpful if you made a discussion about it. we may offer alternatives, or make a change that accommodates your need. if you don't tell me what problems flixel is causing you I can't do anything to help
yeah good to know, I did all of that before this issue happened though so I kinda did not do that
seems people are still having this issue. does anyone have a public project that recreates this issue?
I remembered something, you can do
<haxedef name="message.reporting" value="pretty" /> which makes the errors not only look better, but also shows where the problem is, instead of just telling you what line and such
flixel/git/flixel/group/FlxGroup.hx:83: characters 37-60
83 | public var memberAdded(get, never):FlxTypedSignal<T->Void>;
| ^^^^^^^^^^^^^^^^^^^^^^^
| Type not found : FlxTypedSignal
flixel/git/flixel/system/frontEnds/SignalFrontEnd.hx:14: characters 43-52
14 | public var preStateSwitch(default, null):FlxSignal = new FlxSignal();
| ^^^^^^^^^
| Type not found : FlxSignal
here's the output for it
@Geokureli good news, I fixed the problem by removing a shadowed OpenFL class Assets (openfl.utils.Assets)
Shadowing this class seems to cause the error for some reason
@Geokureli good news, I fixed the problem by removing a shadowed OpenFL class
Assets (openfl.utils.Assets)Shadowing this class seems to cause the error for some reason
That's... weiiird. Does openfl.utils.assets import or mess with it in any way?
Looking in the code, it does appear to make use of macros in some way, but importing it globally (with #if !macro so it doesn’t get imported when we’re in a macro) or normally, but only when I shadowed it, removing it seemed to fix it, but I can try to make a sample project if needed
On Sun, Sep 8, 2024 at 10:25 PM Cynda @.***> wrote:
@Geokureli https://github.com/Geokureli good news, I fixed the problem by removing a shadowed OpenFL class Assets (openfl.utils.Assets)
Shadowing this class seems to cause the error for some reason
That's... weiiird. Does openfl.utils.assets import or mess with it in any way?
— Reply to this email directly, view it on GitHub https://github.com/HaxeFlixel/flixel/issues/3092#issuecomment-2336987299, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5VHQKVUYCMGXJR4PIGC2SDZVUBKHAVCNFSM6AAAAABFCVBVUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZWHE4DOMRZHE . You are receiving this because you were mentioned.Message ID: @.***>
Quick reminder that unless you can recreate this issue in a small shareable test project, there's really nothing anyone can do to help.
9 times out of 10 these weird issues involve shadowed classes, which is why we recommend creating a new project, and moving things over from the failing project, until the new one fails, then simplifying that project down to only relevant parts. It's tough work, but it's really the only way anyone can help.
Quick reminder that unless you can recreate this issue in a small shareable test project, there's really nothing anyone can do to help.
9 times out of 10 these weird issues involve shadowed classes, which is why we recommend creating a new project, and moving things over from the failing project, until the new one fails, then simplifying that project down to only relevant parts. It's tough work, but it's really the only way anyone can help.
good point I'll go make a sample project & see if I can reproduce it there