Fimbul

I like this idea, though I think "Variable Namespaces" would be a more appropriate name.

KFC

That's what I currently do. But there have been occasions where I've needed to change the properties of a layer (or add a new one) to a non-trivial amount of layouts. Most recently, I changed how transitioning to/from solid colors worked so that it didn't require webgl, and I needed to add a layer to about 100 layouts, as well as remove the webgl effect from those layouts. It would have been far simpler to just create the layer from events, so I don't have to do that repetitive work. Why do repetitive work when the computer should be able to do it?

Additionally, if you have a game with a level editor, a user may want to make a level with more parallax backgrounds than you have layers in the layout that loads the levels.

zenox98

DUTOIT

It seems both of you missed the part where I mentioned that I'm already creating the objects via events. I want to create the layers as well as the objects via events.

While working on a project, I find that I create several instance variables whose values get set by events while the game is running, and have no purpose being configured in the layout editor. At the same time, those same objects will have a couple variables that DO need to be configured in the layout editor, and those runtime-only variables clutter up the properties window and get in the way. It would be great if I could hide those runtime-only variables from the layout editor, so as to avoid confusing other people who also work on the project.

This is pretty minor in the grand scheme of things, but would still be nice to have.

I'm working on a project with a lot of layouts, and most of those layouts share certain elements (like the UI). I use events to create all of the objects for those elements (so that changes are reflected everywhere), and I give them their own layer for organization. However, sometimes I need to make a change or add a feature that requires a layer to be added or modified. Currently I have to go through each layout manually, and make the change. This is very tedious and boring. If I could create that layer at runtime (like the objects that populate it), I could avoid such mindless tasks.

It would also be useful for games with level editors, as some levels may need more layers than others.

Do you use default platform behavior? Do you use the real x, y vel?

Yes, that is the built in platform behavior. I just use some events to tweak some numbers (such as max speed, gravity, jump strength, and acceleration) under the right conditions.

- Big Mario should slide off the box, not bounce against it when not breaking it.

This is one of those things where the amount of effort spent trying to fix it would be better spent developing a custom platforming behavior where you can easily tweak the fine collision details, but at that point, I may as well not use Construct.

- The star does not bounce against "brick" boxes. It needs it own family to collide against.

I did kinda rush this one because I wanted to post the game, but getting it exactly right would require a lot more studying it, and I really wanted to get this done within a week.

- Even the flag pole shares the same issues when hit with low x-vel.

I'm not really sure what you are talking about here. I zero the player's X velocity and set their X position when they touch the flagpole anyway, so I'm not sure how a low X velocity could affect it. if you mean it gets activated before you actually touch the pole, that can be fixed with a simple X position compare.

- Just watching the gombas for a while makes them stick together. I fixed this with a separate box for turning.

Fixing this wouldn't be too hard if I could reliably reproduce it.

- Contiguous walking to the left when big Mario on an edge with around 16 pixels of gap will kill Mario. Does Mario die when ofscreen?

???

All I do is adjust the player X position if they are outside the bounds of the screen.

Too bad that playing stuff in the wip "REALLY bothers" you. But maybe you got something out of it. Maybe a better feel for c2. Else you gonna waste a lot of weeks.

Considering the goal here was to clone a Mario game, and the core aspect of Mario games is the platforming, I really think you should have spent more time on it. Getting other minor details wrong doesn't bug me nearly as much as getting the core gameplay wrong. I didn't even bother making anything else work until the platforming was just right, because it's so monumentally important in a Mario game.

If you don't want to spend that much time on the platforming, perhaps you should try cloning a game with easier platform controls? Like Megaman? No X acceleration to worry about, no differing numbers based on how fast you are moving. All you need to work out is jumping higher by holding the jump button, and that's pretty easy once you know the trick (reduce player gravity immediately after jumping and while the jump button is still held). I don't know the exact mechanic Megaman uses to determine when the jump-hold effect should forcefully end, but Mario 1 ends it once you start falling, and Mario 3 ends it once your Y speed is high enough (above -2 pixels per frame, or -120 pixels per second). Figuring out how Megaman does it should be pretty easy with an emulator that lets you view the game RAM in real-time. Also stepping frame by frame. Lots of stepping frame by frame.

There are a lot of things that make this *not* feel like a Mario game, but most importantly are the platforming physics. It's so easy to get wrong and so many fan games do. This bothers me. Call it a pet peeve.

Mario needs to accelerate to his max speed, not just get there instantly. His jump strength (and gravity) need to change depending on how fast he is moving. His jump needs to be higher if you hold down the jump button.

To get a better feel for c2 I decided to remake level 1 from Super Mario Bros. as close to the original as possible.

When I see something like the bolded part above, and the platforming controls aren't right, it REALLY bothers me. In fact, it bothered me so much, I spent the last week making this.

Problem Description

If you try to preload a sound that does not exist, the "All Preloads Complete" condition will never become true

This only happens when the project is exported for Node-Webkit. Previewing with Node-Webkit works fine.

Attach a Capx

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

Description of Capx

On start of layout, it preloads a sound that doesn't exist, and sets the text to "Preloading"

When preloads are complete, it changes the text to "Preloads Complete"

Steps to Reproduce Bug

• Open capx.
• Export for Node-Webkit
• Run exported project.
• Text will say "Preloading" instead of the expected "Preloads Complete"

Observed Result

Text says "Preloading"

Expected Result

Text says "Preloads Complete"

Affected Browsers

• Chrome: (NO)
• FireFox: (NO)
• Node-Webkit: (YES) (when exported)

Operating System and Service Pack

Windows 7 Home SP1

Construct 2 Version ID

Release 177 (64-bit)

The very last event in your project is creating an infinite recursion. Whenever an AlertPointer object is created, you are asking Construct 2 to create another one (which runs the 'On Created' event again immediately, creating another object). This causes an endless series of function calls with no returns, until the call stack overflows.

I'm trying to create a split-screen effect using this plugin, and I've encountered a strange problem where an object refuses to paste correctly after creating more than 2 instances of the plugin.

Here is a test file. With 2 players, everything seems to work fine. If you use the left mouse button to add another player, the status bar disappears. Removing the added player with the right mouse button makes it render again.

On a side note, I would really like to see a "Paste Layer" action (like the one from the canvas plugin). Construct 2 doesn't make it easy to replicate that using only "Paste Object"

FYI I never saw any "Bug Report Template" appear when I clicked "Post a new topic"

I have a Logitech Dual Action controller (It looks like this, can't get more specific with the model number). It's not an XInput compatible controller, but it worked with Node-Webkit regardless. It doesn't work with Internet Explorer, Firefox, or Chrome.

I updated Construct 2 to find that the controller no longer worked with Node-Webkit. I tested to find out exactly which version it stopped working in, and found that it worked just fine in r160, and didn't work in r160.2. I also tested with a wired Xbox360 controller, and that still works. Copying the 'exporters\html5\node-webkit\win32' folder from r160 and placing it into r160.2 makes my Logitech controller work again. Here is a test .capx, though I don't see the point of that for this report.

I realize this technically isn't a Construct 2 issue, but this update does pose a problem for me. Replacing the Node-Webkit exporter every time I update Construct 2 is an annoying workaround, especially since I'm likely to forget about this by the time another stable update rolls around. Additionally, there may eventually be some future update or plugin that requires the newer version of Node-Webkit, which will make this problem much worse.