Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Justin

Pages: 1 2 3 4 ... 201
16
That's odd. I looked through the log you sent with the previous build, and it has AndroidManifest.xml files being copied from the following locations.

Code: [Select]
- Copying template file: <lime haxelib>/dependencies/extension-api/src/main/AndroidManifest.xml -> Export/android/bin/deps/extension-api/src/main/AndroidManifest.xml
- Copying template file: <google-play-games extension>/dependencies/google/AndroidManifest.xml -> Export/android/bin/deps/google/AndroidManifest.xml
- Copying template file: <stencyl install>/plaf/lime-templates/android/template/app/src/main/AndroidManifest.xml -> Export/android/bin/app/src/main/AndroidManifest.xml

This is all standard stuff, not the result of any custom engine extension. Perhaps you could try doing a clean compile again now that you have the latest build?

17
It's hard to tell what this does without seeing what the custom blocks do, so I'm not sure meaningful advice can be given.

It sounds like the problem might be that you're only running this code once (in a "do after" event) when you might have intended to keep running this code (with a "do every" or "updating" event).

18
The things you posted about the deleted actor in the scene is unrelated to your Android issues.

It looks like you later opened that scene and then saved the game. That would have caused the deleted actors to be permanently removed from the scene. So if you opened the xml file afterward, that would explain their absence. You shouldn't see those errors in your logs anymore.

19
Last time you posted about android problems on Discord, you were using b11028, and I recommended that you update to the latest private build.

At he top of your logs, I see this:
Code: [Select]
Stencyl Version: 4.1.0-beta [ci/410-beta3] (b11028)
So it looks like you're still using the same Stencyl build you were using back then.

Near the end of your logs, I see this:

Code: [Select]
Manifest merger failed : android:exported needs to be explicitly specified for <activity>. Apps targeting Android 12 and higher are required to specify an explicit value for `android:exported` when the corresponding component has an intent filter defined. See https://developer.android.com/guide/topics/manifest/activity-element#exported for details.

This is precisely the problem that was fixed in 4.1.0-beta3/b11106.  See this Stencyl issue for more details: Android target API 32 (12L) : Failed merge Manifest

If you update to the latest private build, and you still see the same exact error, my advice in the linked issue stands:
Quote
It's possible for the same problem to be present in engine extensions you're using, which will also need to be updated for Android 12+ support. Running without any custom engine extensions should allow the game to compile.

If you post links to the engine extensions you're using, I can try to make any necessary updates.


The latest private build should allow you to export both apk and aab, and it should work with Android 12+. If that's not the case, let me know and I'll fix it.

20
Ask a Question / Re: HTML5 Compiling Failure
« on: September 26, 2022, 08:43:00 pm »
I investigated this a couple weeks ago. Here are the notes I took at the time.

When publishing to HTML5 on Windows, during the closure compiler step, the build may error with a message like this:
Code: [Select]
[haxelib.exe] java.nio.file.InvalidPathException: Illegal char <:> at index 4: file:///C:/Users/Username/AppData/Local/Stencyl/libs/haxelib/shohei909/tweenxcore/1.0.4/tweenxcore/Tools.hx
[haxelib.exe]  at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
[haxelib.exe]  at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
[haxelib.exe]  at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
[haxelib.exe]  at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
[haxelib.exe]  at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
[haxelib.exe]  at sun.nio.fs.AbstractPath.resolveSibling(AbstractPath.java:66)
[haxelib.exe]  at com.google.javascript.jscomp.SourceMapResolver.getRelativePath(SourceMapResolver.java:102)
[haxelib.exe]  at com.google.javascript.jscomp.Compiler.getSourceMapping(Compiler.java:2883)
[haxelib.exe]  at com.google.javascript.jscomp.SourceMap.addMapping(SourceMap.java:175)
[haxelib.exe]  at com.google.javascript.jscomp.CodePrinter$MappedCodePrinter.generateSourceMap(CodePrinter.java:153)
[haxelib.exe]  at com.google.javascript.jscomp.CodePrinter.toSource(CodePrinter.java:849)
[haxelib.exe]  at com.google.javascript.jscomp.CodePrinter.access$300(CodePrinter.java:40)
[haxelib.exe]  at com.google.javascript.jscomp.CodePrinter$Builder.build(CodePrinter.java:778)
[haxelib.exe]  at com.google.javascript.jscomp.Compiler.toSource(Compiler.java:2278)
[haxelib.exe]  at com.google.javascript.jscomp.Compiler.lambda$toSource$11(Compiler.java:2239)
[haxelib.exe]  at com.google.javascript.jscomp.CompilerExecutor.runInCompilerThread(CompilerExecutor.java:129)
[haxelib.exe]  at com.google.javascript.jscomp.Compiler.runInCompilerThread(Compiler.java:826)
[haxelib.exe]  at com.google.javascript.jscomp.Compiler.toSource(Compiler.java:2201)
[haxelib.exe]  at com.google.javascript.jscomp.Compiler.lambda$toSource$9(Compiler.java:2158)
[haxelib.exe]  at com.google.javascript.jscomp.CompilerExecutor$2.call(CompilerExecutor.java:102)
[haxelib.exe]  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[haxelib.exe]  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[haxelib.exe]  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[haxelib.exe]  at java.lang.Thread.run(Thread.java:748)

It would appear that there are various issues with source map support with Haxe-generated JS and the closure compiler.

First, Haxe uses url-encoding for the source map path in the generated javascript file. This is correct. Closure, on the other hand, thinks that it's a file path, and uses java.nio.file.Path to look it up relative to the js file. This causes, for example, paths with spaces in them not to work at all, since the space will be represented as %20. This can be resolved by the following patch to closure:

Code: [Select]
--- a/src/com/google/javascript/jscomp/Compiler.java
+++ b/src/com/google/javascript/jscomp/Compiler.java
@@ -3030,6 +3030,11 @@ public class Compiler extends AbstractCompiler implements ErrorHandler, SourceFi
     String resultOriginalPath = result.getOriginalFile();
     final String relativePath;

+    if(resultOriginalPath.startsWith("file:///"))
+    {
+      resultOriginalPath = resultOriginalPath.substring("file:///".length());
+    }
+
     // Resolving the paths to a source file is expensive, so check the cache first.
     if (sourceMapOriginalPath.equals(resolvedSourceMap.originalPath)
         && resultOriginalPath.equals(resolvedSourceMap.sourceMapPath)) {
@@ -3040,7 +3045,7 @@ public class Compiler extends AbstractCompiler implements ErrorHandler, SourceFi
       if (source == null && !isNullOrEmpty(resultOriginalPath)) {
         source =
             SourceMapResolver.getRelativePath(
-                sourceMap.getOriginalPath(), result.getOriginalFile());
+                sourceMap.getOriginalPath(), resultOriginalPath);
         if (source != null) {
           sourceMapOriginalSources.putIfAbsent(relativePath, source);
         }

Second, absolute paths using the file:// protocol in sourcemap sources aren't handled correctly. Closure thinks that everything either starts with a / and is an absolute path, or it's a relative file path. Again, java.nio.file.Path is used, leading to possible errors like that reported by Krimm. This can be worked around with the following patch, but it's not particularly robust.

Code: [Select]
--- a/src/com/google/javascript/jscomp/Compiler.java
+++ b/src/com/google/javascript/jscomp/Compiler.java
@@ -3030,6 +3030,11 @@ public class Compiler extends AbstractCompiler implements ErrorHandler, SourceFi
     String resultOriginalPath = result.getOriginalFile();
     final String relativePath;

+    if(resultOriginalPath.startsWith("file:///"))
+    {
+      resultOriginalPath = resultOriginalPath.substring("file:///".length());
+    }
+
     // Resolving the paths to a source file is expensive, so check the cache first.
     if (sourceMapOriginalPath.equals(resolvedSourceMap.originalPath)
         && resultOriginalPath.equals(resolvedSourceMap.sourceMapPath)) {
@@ -3040,7 +3045,7 @@ public class Compiler extends AbstractCompiler implements ErrorHandler, SourceFi
       if (source == null && !isNullOrEmpty(resultOriginalPath)) {
         source =
             SourceMapResolver.getRelativePath(
-                sourceMap.getOriginalPath(), result.getOriginalFile());
+                sourceMap.getOriginalPath(), resultOriginalPath);
         if (source != null) {
           sourceMapOriginalSources.putIfAbsent(relativePath, source);
         }

The reason I never ran into this with my test game is that my typical test game has a space in the name, so I was running into issue #1, and closure never event attempted to resolve file paths in the first place.

However, if everything was working as intended (apart from this bug), I would expect that publishing an HTML5 game would always fail, but Krimm's later reports seem to indicate that the bugs occurrence is a bit hard to predict. I feel like there must be more bugs with closure's sourcemap processing feature, and I don't think I can afford the time to look into them.

In the end, I think I'll just remove sourcemap processing from the build in order to avoid this bug in the future.

21
Ask a Question / Re: iOS in app purchases issues
« on: September 06, 2022, 08:52:01 pm »
Is that the only place in the game where you set Bought to true or false? Are you using save/load game blocks (which could load the old value of Bought)? Alternatively, are you even sure that Bought is being set to true in the first place? You don't have any other code in your game that could be switching you back to the main screen? You may want to insert print blocks into your game and watch the logs to make sure that what you think is happening is actually happening. You can also print the value of the Bought attribute at key points.

It may be simpler to use the purchased product with id block for this.

22
Ask a Question / Re: Compile issue
« on: September 04, 2022, 10:24:37 pm »
I don't think this should affect it, but I can't think of anything else: disable the hxcpp compile cache and try again. You can find it at Tools > HXCPP Compile Cache Settings in the menu.

23
Ask a Question / Re: Exlosion via image api dosn't work in one scene
« on: September 02, 2022, 06:22:59 am »
The problem is that the exploded parts of the actor are being attached to the screen, which uses on-screen coordinates. Using on-screen coordinates for this, though, will make it so the images don't move on the screen even if the camera moves. What you probably want to do instead, is attach the images to a layer.

In the collision event, just make the following change:

"attach image to screen" -> "attach image to to layer"

If you want to continue with on-screen coordinates instead, you would make these changes in the "attach image to screen" and "slide image by" blocks:
"x of 1st actor" -> "x (on screen) of 1st actor"
"y of 1st actor" -> "y (on screen) of 1st actor"
"x-center of 1st actor" -> "x (on screen) of 1st actor + half-width of 1st actor"
"y-center of 1st actor" -> "y (on screen) of 1st actor + half-height of 1st actor"

24
Ask a Question / Re: Exlosion via image api dosn't work in one scene
« on: September 01, 2022, 09:15:15 pm »
The test game works fine for me. Does it not work for you?

I'm not sure why it works in one scene but not the other. Perhaps collisions are causing the actors to die in a different behavior in your main play scene?

One thing I noticed is that it seems you're not using the explosion behavior as intended. It shouldn't be attached to the actor that explodes. It should probably only be attached to a single (not exploding) actor in the scene, or it should be a scene behavior. I say this for a couple of reasons.

1. It has cleanup code for deleting images after they've grown small enough. To ensure that this code is run, this behavior shouldn't be attached to an actor that's going to die.

2. It has an event for [ENEMIES] and [BLOCKS] colliding, rather than [self] and [BLOCKS] colliding. Since each copy of this behavior that's currently running has the same event, you only really need one of them.

25
Ask a Question / Re: Lyren's Utility Pack
« on: August 23, 2022, 05:12:32 am »
Commenting on the side note here.

Yes, in Stencyl's marketing materials, Design Mode is considered as "not code," and so that's mirrored on other sites that talk about Stencyl. My personal opinion is closer to yours, though. I think that calling Stencyl a no-code engine when the blocks are in fact an almost 1:1 representation of a programming language is a bit of a stretch. If you really want to call it "no code", you'd have to constrain yourself to pre-made behaviors, which would be rather limiting.

On the other hand, that's the perspective of somebody who knows what's going on. To a beginner, the idea of "coding" a game may seem impenetrable, and the idea of "no code" can be a welcome sign. And what Stencyl offers in that regard is, as you mentioned, a higher-level language, a little bit closer to natural language, that allows the designer to think about the game logic rather than the syntax of the code.

For some subset of Stencyl's users, this faux "no code" programming language may serve as a gentle introduction to programming, even if they're not aware that that's what it is. Plenty of people have taken what they learned from Stencyl's Design Mode behaviors, and used that as a stepping stone on their way to text-based programming languages.

So while I agree that calling it "no code" is inaccurate, if it's looked at from the perspective of a potential Stencyl user, especially somebody with no prior experience programming, I think it can be a helpful label.

26
Haxe doesn't know anything about Rune since you haven't created any Haxe externs for it. Perhaps try wrapping "Rune" inside "js.Syntax.code" to directly access it in the generated Javascript code instead.

js.Syntax API docs

Code: [Select]
js.Syntax.code("Rune").init({
  resumeGame: myResumeGameFunction,
  pauseGame: myPauseGameFunction,
  restartGame: myRestartGameFunction,
  getScore: myGetScoreFunction
});

I'm not positive that that will work, just the first thing I might try.

I took a quick look at the Rune SDK (linked for myself and others), and it says you need to load some javascript before anything else:
Code: [Select]
<script src="https://cdn.jsdelivr.net/npm/rune-games-sdk@2.5.0/dist/browser.min.js"></script>

You may be able to get away with adding that as a dependency in Settings > Advanced > OpenFL Settings.
Code: [Select]
<section if="html5">
    <dependency name="https://cdn.jsdelivr.net/npm/rune-games-sdk@2.5.0/dist/browser.min.js" />
</section>

Otherwise, you may need to create an engine extension with a modified index.html template. Here's an example of an almost blank HTML5 engine extension with an index.html template set up.


You may find it helpful to browse other HTML5 engine extensions that handle integration with different javascript SDKs, so here are a couple that I wrote:
- GameDistribution
- CrazyGames

27
Ask a Question / Re: Extension Not Updating
« on: August 09, 2022, 12:40:57 am »
What you're doing is correct, but you've actually stumbled on a particularly tricky engine extension to modify. That engine extension is a little bit odd. The extension's blocks.xml file does not actually match the extension's Console.hx class.

First, at the top of the Console.hx file, you have the package of the class. This should match the folder structure.

Code: [Select]
package com.fermmmtools.debug;

With that package, you would expect the file to be found here:

Code: [Select]
hud-console/
    com/
        fermmmtools/
            debug/
                Console.hx

However, the class is instead found in the root folder of the engine extension.

Code: [Select]
hud-console/
    Console.hx

Ok, so that's odd.. but what's stranger is this: the blocks in blocks.xml use a Console class in a completely different package.

Code: [Select]
<block
tag="create-console"
spec="create console"
code="com.nmefermmmtools.debug.Console.create();"
type="action"
returns="void"
color="gray"/>

Note that the package here is not "com.fermmmtools.debug", but instead "com.nmefermmmtools.debug".


com.nmefermmmtools.debug actually matches a haxelib that's built-in to Stencyl, and has been included since the earliest Stencyl 3.0 previews. Before Stencyl 4.1, You can find it at Stencyl/plaf/haxe/lib/debug-console/1,00. captaincomic's hud-console extension is actually using this class that's included in Stencyl by default, and not the class included in the engine extension's own sources.

I can only guess about what happened, but I think that captaincomic wanted to expose a number of extra blocks using functionality from that class that Stencyl didn't use. So he copied a slightly different version of the class into his extension, created the blocks he wanted to be available (using the built-in class by mistake), and then tested it, and everything worked fine. There are some slight differences between the two classes, but nothing particularly noticeable, so the fact that the class contained in the engine extension's sources wasn't being used was easy to miss.



Ok, so you want to make changes to the Console.hx class on your side? Here's what you need to do:

1. Fix the blocks.xml files to point to com.fermmmtools.debug.Console, and move the Console.hx file to hud-console/com/fermmmtools/debug/Console.hx.
2. The Console file actually doesn't compile as-is, so you can just replace it with the file found at Stencyl/plaf/haxe/lib/debug-console/1,00/com/nmefermmmtools/debug/Console.hx. Or you can fix the compilation errors. If you replace the whole class, remember to change the package name to com.fermmmtools.debug, and reapply any changes you might have made to the class.

28
Ask a Question / Re: Plane goes crazy when firing
« on: August 07, 2022, 08:23:09 am »
Maybe you need to make sure that the plane can't collide with the bullet.

29
Ask a Question / Re: Does Ad Mob works how to test
« on: August 01, 2022, 06:59:59 pm »
Looks like the images on the article are probably broken by the https update. Until that's fixed, you can view the article on the internet archive.

https://web.archive.org/web/20190213023856/https://www.stencyl.com/help/view/android-ads/

edit: removed some irrelevant information about iap.

30
Something like this shouldn't have to do with your workspace. If the "new" version is what you're editing in Stencyl, and you press the "test game" button, then that's the version Stencyl will try to install to your Android device.

Your logs may have more valuable information. Stencyl may be having trouble installing the game. For a quick solution, you could delete the game from your Android device before testing.

Pages: 1 2 3 4 ... 201