Johncw87's Forum Posts

  • I put 3 text boxes into a layout, previewed with NW.js, and saw nothing odd. You should provide a *.capx and some additional information.

    • graphics card model
    • graphics driver version
    • graphics driver release date
    • webgl enabled or disabled

  • When you pick a file, the browser loads it, and assigns a temporary URL to it. When the browser decides that the data isn't needed anymore (or when you close the browser) it unloads it, and the URL becomes invalid. The URL isn't a shortened version of the filepath, nor a shortened version of the image itself. It's a temporary name assigned to a temporary blob of data. There's no Construct 2 bug here.

    What you need to do, is save the actual image, instead of a temporary name for the image.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Collision cells are a performance tool. Used correctly, they can increase performance. Used incorrectly, they can decrease it. IIRC, the size of each 'cell' is determined by the window size defined in the project properties. But, since you made that ridiculously huge, you rendered the collision cells completely ineffective at boosting performance. If you take that exact same project, lower the window size to something sane (like 640x480), and set the layout scale to compensate (like 0.05), you will get a very similar result, and it will be much faster. This is not a problem with the tool, this is a problem with how it's being used.

  • The fact that he doesn't care is enough. They are hiding behind an easy excuse of the drivers being the problem because they can't repro. This bug has been reported since looong and always been denied. It is not my job to look around and bring informations in that sense. I can give infos if I have them and/or I'm being asked, but as you can see, no officials ever asked anything. Bug reporting here is terrificly bad. I can act nice you know, when I'm taken serious. This is by far not the case here as you can see based on the answers you got after all the huge work you made for them trying to rule out cases and demonstrate with A+B that it is not a driver bug.

    Think about it from his perspective. Lets say that you are tasked with fixing this bug, and you can't replicate it. How do you even begin trying to find the cause if the issue never manifests on your machine? How would you know if you have fixed it or not? Instead of complaining about how much he "doesn't care" (which is NOT helpful), try to help Ashley reproduce it. That's how this will get fixed.

    Also, consider the small size of Scirra's dev team, and that Construct 3 is in development. Ashley probably doesn't have a bunch of time to dedicate to hunting down minor bugs like this, especially when you consider how many non-bugs get reported. The more you can do to narrow down the cause, the easier it will be for Ashley to identify the bug and fix it.

  • I was thinking about this bug again today, and decided to try replicating it on a software OpenGL implementation, to rule out driver bugs completely. I downloaded Mesa 3D 12.0.6 for this test, cross-compiled it from Ubuntu for windows 64-bit, and placed the resulting opengl32.dll into my Construct 2 folder. As an added precaution, I removed all 3rd-party plugins that could render something. As I expected, I was still able to reproduce the bug. I know for a fact that Construct 2 was using Mesa 3D, as process explorer showed that opengl32.dll was loaded from the Construct 2 folder, instead of System32 (also the editor ran pretty slowly, which was expected). If anyone else wants to try this without having to compile Mesa 3D, I've put it on google drive.

    Psychokiller1888 I don't think your 'persistence' in this matter is helping. If you have no new information to offer for this bug report, could you maybe chill? I know the bug is annoying, but you have a few usable workarounds. You don't need to hound Ashley about it.

  • *quote snip*

    I 100% agree with you, I also would have liked to have a third tilemap for jump-throughs, which would complicate issues even further, which leads me to suggest that tilemaps need the ability to set behaviors per tile/groups of tiles.

    Well, that wouldn't really work, since adding behaviors to individual tiles would inevitably lead to people trying to add movement behaviors to them, and that wouldn't work for obvious reasons.

    The best workaround I can suggest is to have 3 separate Tilemap objects, instead of 3 instances of the same Tilemap object. That way, you can filter the traces however you want.

  • *quote snip*

    Ahh, so is there a way of sorting it out so I can have a second instance of the tilemap (for backgrounds) with solids disabled and not trigger the trace?

    No. This is also unlikely to change, as having the Solid behavior continue to have an influence after switching it to custom seems arbitrary. Code-wise, I would either have to used an optimized method that might break in future construct versions, or perform a second search through an already filtered list. I'm not really fond of either solution.

    IMO, this problem of yours highlights the Tilemap plugin's inability to mark a tile as having no collision. Though the Tilemap plugin has improved significantly since its initial release, these sorts of shortcomings are why I don't use it in my projects.

  • >

    > >

    > > *quote snip*

    > >

    > > Here's an example, sorry I used 5 traces, it's just for a experiment, but as you can see, the second instance with the solids disabled still affects the trace: https://www.dropbox.com/s/0p6rkii91i8e4 ... .capx?dl=0

    > >

    >

    > Well, I would like to look at your project, but you've got these other plugins in it.

    > [quote:3p7rp5s8]

    > MagiCam

    > Simulate key event

    > Platform Plus

    >

    >

    While I doubt another plugin is causing a problem, it's still a good idea to keep other 3rd party plugins out of a .capx when you are reporting a bug. But most importantly, I'm lazy and don't want to hunt down and install these plugins <img src="{SMILIES_PATH}/icon_lol.gif" alt=":lol:" title="Laughing">

    Sorry, forgot about those! Here's a cleaned version: https://www.dropbox.com/s/62rf3cy1y7ukn ... .capx?dl=0

    As you see with the delayed function, the added instance causes the tracer to find the obstacles.

    Well, the problem is clear as day! Remember what I said before?

    If you are using the plugin in 'Solid' mode, it will ignore any instances where the 'Solid' behavior is disabled.

    That only applies for 'Solid' obstacle mode. It doesn't work in 'Custom' obstacle mode.

  • *quote snip*

    Here's an example, sorry I used 5 traces, it's just for a experiment, but as you can see, the second instance with the solids disabled still affects the trace: https://www.dropbox.com/s/0p6rkii91i8e4 ... .capx?dl=0

    Well, I would like to look at your project, but you've got these other plugins in it.

    [quote:1wm6j8r0]

    MagiCam

    Simulate key event

    Platform Plus

    While I doubt another plugin is causing a problem, it's still a good idea to keep other 3rd party plugins out of a .capx when you are reporting a bug. But most importantly, I'm lazy and don't want to hunt down and install these plugins <img src="{SMILIES_PATH}/icon_lol.gif" alt=":lol:" title="Laughing">

  • *quote snip*

    It's for tiles that are non solid and tiles that are solid, can't have both on he same tilemap so I had to duplicate. Actually, ray cast doesn't ignore a seperate instance of the same object that has different solid settings, I tried for hours over the weekend, picking instances of the tilemap, delaying functions to debug the problem and if I have a second tilemap instance of the same object, this time with the solids disabled, it instantly adds all of the new tiles to the tracer.

    I just tested it, and it works fine.

    https://dl.dropboxusercontent.com/u/207 ... lemap.capx

    This is the same test project shown in the OP, but with a second instance of the tilemap. This second instance has 4 tiles, none of which affect the reflecting laser due to its 'Solid' behavior being disabled.

  • Johncw87 Is it possible to pick a single instance to trace? I have two tilemap duplicates, one created at runtime, for handling solids differently to the background tiles, and the minute that is created, the tracer sees all the tiles as obstacles. Can I just have the tracer use the instance with the solid tiles removed?

    If you are using the plugin in 'Solid' mode, it will ignore any instances where the 'Solid' behavior is disabled. But why are you using the same tiles in the foreground and in the background? Don't you think that would get confusing?

  • >

    > How so? It sounds to me like you just need 1 trace object and a for loop. Or is there a reason you need to keep information about a trace after you apply damage and effects?

    >

    While I could create one weapon with a loop, I plan on having multiple enemy's, all also using hit-scan weapons. I believe this could not be done with a loop.

    I think it could be done easily with a loop. Easily enough that I decided to throw together a little test:

    https://www.dropbox.com/s/st41in3pks8luiy/hitscan_test.capx?dl=0

    Since I used the turret behavior's shoot trigger, I didn't even need the loop! So, just for kicks, I made 4 of the turrets have a 'shotgun' weapon (which required a loop).

  • Will you try to add support for multiple arrays? I know you can do it by create multiple Trace objects. But I am trying to create hit-scan weapons, and with guns like a shotgun, to is very inconvenient to create up to 10 different Trace objects.

    How so? It sounds to me like you just need 1 trace object and a for loop. Or is there a reason you need to keep information about a trace after you apply damage and effects?

  • Sometimes Mario bumps a block, but the block does not work, how can it be fixed?

    In the cases where this happens, what is supposed to happen is Mario continues upwards, passing through the block, while also being pushed to the left (or right) to get him out of the block. Construct 2's built in platform behavior does not allow for such fuzzy collisions (nor do I expect it to). Working around this would defeat the purpose of using Construct 2 to begin with.

  • I can't reproduce any issue on Windows 10 64-bit with an nVidia GTX 1070 - it looks like this, which AFAICT is correct: https://dl.dropboxusercontent.com/u/15217362/9patchrendering.png

    It never changes as I scroll/zoom around.

    A key thing missing from that screenshot is having another, large project loaded into the editor at the same time. I thought I made that pretty clear. Load multiple large projects, just to be sure.

    http://i.imgur.com/AWnaaEL.png

    Even the grid is missing (which is unusual for this bug).

    2) it ought to reproduce in both the 32-bit and 64-bit versions identically if it's a logic problem with C2's code, since we compile the same source code for both builds.

    So this seems like it could be some kind of 64-bit driver issue, but I have to admit, I'm not sure. These kinds of problems are notoriously borderline-impossible to solve. We've had a bunch of them in the past. At least this isn't a serious one - we've had "C2 crashes on startup on all Radeon cards of this model" in the past...

    While I've never seen it myself, there are potential problems that can arise when compiling for 64-bit. The only thing I can think of though, is making an assumption that pointers are 4 bytes long. Perhaps a pointer is being stored in a variable that is only 4 bytes long in the 64-bit build? If I were you, I would take a close look at any pointers that may be stored on the same struct or class that contains any OpenGL transformation matrices.