I will just leave this recent response from Ashley here:

Changing the icon of a Windows executable is suprisingly hard. It uses the ICO format which is an ancient format dragged kicking and screaming from the 16-bit Windows 3.1 days all the way through to 64-bit Windows 10. It never had any decent support in the Windows APIs to write ICO files as far as I am aware, and the documentation on the subject is pretty poor (and absolutely littered with accumulated backwards-compatibility baggage from over the years). So to support this would basically mean spending several days reverse-engineering an old, obscure and poorly documented format. Alternatively there are existing tools that can do this, and we have a lot of much more pressing things to work on, so...

TheRealDannyyy: Welcome to the bugs forum.

If you have encountered a bug, fill a proper bug report following the bug report guidelines so that Ashley can investigate the issue properly.

Closed bugs are not re-opened.

Especially since the issue is different from the original subject (preview is not export).

Kyatric seriously?

Ok fine then, I'll do it even though it is an engine side issue and therefor I'm not able to provide a proper capx with my report which is against the guidelines...

This issue is not fully fixed! (I'm using the latest version of NW.js installed [v0.14.0])

When closing NW.js using the native Windows "X", it leaves a process behind.

Even if this issue is fixed for export, it should be fixed for the previewmode too.

Kyatric I request to re-open this issue and close it when it is fully fixed, thanks!

EDIT: For some odd reason this doesn't seem happen each time when trying to launch the preview.

> Sorry to say the following but this will also end up dead like the two previous requests for this.

> HERE is my request if you're interested...

>

> I have several friends that know JS quiet well that tried to "break" into the engines code and

> make it possible for us to do this with a plugin or whatever.

> Most of them failed or got weird results, either Ashley doesn't want this feature because it causes issues with

> certain parts of the engine or browsers cause problems so that Ashley is not able to implement that currently.

>

> These are all speculations though because no one seems to care about this feature that much to provide us with more information.

>

I figured it would be something like this. It's really unfortunate because it's somewhat of a standard feature, and can be important for professional developers. How close where your friends able to get? I wish we didn't have to hack a solution but if one is possible I would be willing to pay for it.

...

Armaldio was the only one that found out more details on how the system actually works,

I wanted to get him here to explain further but well he magically appeared by himself.

One side note, neither Armaldio or myself said that we "hacked" Constuct 2.

We tried to achieve something with existing legal resources given by the software itself.

We don't want to get in trouble for things that we didn't do or tried to do.

Amazing work rexrainbow!

I've got a two questions about features that could be added in future if possible of course:

1. Would it be possible to add URL tags to make hyperlinks within the text?

2. Would it be possible to add "sprites" in form of IMG tags within the text (to add smiley's for example)?

Something like this in C2:

This is just some random text including a smiley face [img=#SPRITENAMEHERE#][/img] in the middle of the text![/code:3lsc2shy][u]Result in the game view:[/u]
This is just some random text including a smiley face    in the middle of the text!

Sorry to say the following but this will also end up dead like the two previous requests for this.

HERE is my request if you're interested...

I have several friends that know JS quiet well that tried to "break" into the engines code and

make it possible for us to do this with a plugin or whatever.

Most of them failed or got weird results, either Ashley doesn't want this feature because it causes issues with

certain parts of the engine or browsers cause problems so that Ashley is not able to implement that currently.

These are all speculations though because no one seems to care about this feature that much to provide us with more information.

If it's just one and the same background repeating itself then you could look at Construct 2/Templates folder. There are few templates that uses tiled background to to that.

Wrap behavior is not a good option for a seamless background.

Why not? It is a totally a solution if you use it correctly.

EDIT: It also depends on the type of game of course.

You can easily do that by using the "Wrap" behavior.

In any case I'd be surprised if the performance benefit in this case was anything other than infinitesimal?

Maybe not on desktop or overall devices with a lot of power but imagine that you'd create a mobile game with ~25 sprites using the behavior at the same time.

...could you perhaps disable Anchor behaviour when unneeded?

guess you could, but isn't the plugin made to simplify the whole process? If I have to do workarounds like these all the time with each sprite, I'd not use the plugin in first place and directly go over to methods with Viewport Expressions.

I don't know how the anchor behavior works regarding this matter, but I think it sets the positions only if the game was resized and not every tick.

oesn't this still require a process to check if the viewport had been resized or not? I still see no benefit in using the plugin if that would be the case.

Hi there, I have a question about relative placement of sprites using the anchor behavior.

I think that there are 2 ways to relatively align objects to the viewport of a game:

1. The Anchor Behavior

2. Manually placing the sprites X & Y positions by using the Viewport Expressions. [eg. ViewportLeft("Layer") + ViewportRight("Layer")) / 2 , to center X]

However, if we for example plan to create a simple game menu with a sprite in the center and use the anchor behavior to do that, wouldn't that be inefficient

compared to manually placing the sprites X position with the viewport expressions at the start of a layout?

I mean when using the 2nd method you essentially just trigger it once with only one impact on performance on the start of the layout.

Just to make it clear, I think that the anchor behavior is always setting the position of a sprite.

Meaning after the sprite had been placed in the correct position in the first time, would it still run and try to set the sprites position even if it has the same value as before?

For example if we would try to place the relative X position of a sprite, would the behavior work like the following:

IF: Sprite.X is still at the same place ~> DO: Nothing (No further performance impact.)
ELSE DO: Set the new position and relatively place Sprite.X[/code:8jwxgv2g] OR does the behavior work like this:
[code:8jwxgv2g]ALWAYS [Every Tick]: Determine the new position and relatively place Sprite.X (Constant impact on performance.)[/code:8jwxgv2g]
I know that this might be confusing but it is really difficult for me to explain this process
because I don't know/understand what goes on behind the scenes, in the actual JS code.
([i]I guess this question is for people with experience in coding with JS?[/i])

#2. When you debug the layout, is the game supposed to run slow? I was running the first game in the Level 0 book-Bubble Pop Madness- and when debugging, the game chugged, like 5-9 FPS. (Using Google Chrome, btw.)

Running it normally doesn't cause any issues.

I'm not sure if it is just on my end but I usually separate the debug ribbon from the game canvas while debugging and everything runs fine then.

There is a small button to do that, you should try it out yourself, it might help you out. (Note: you have to manually do that every time when you want to debug.)

Well 7 page of this topic named "Construct 3 any news?", "What we do is discuss and compare engines because that is what this topic is about" is actually off topic.

People asked infos about C3, infos were released.

Why compare with other engines ?...

Yeah it started differently but got twisted around so that is kinda our "current" topic since Ashley said everything about C3 he could say for the moment.

I also never threatened anyone, I just wanted to gather some more information about C3 (maybe not in the most polite way) but in the end you can see the results.

It's not easy to talk about something with so less information about it, that is why we do speculations + comparisons and let the people decide if they would like it or not (sometimes it might be a bit more critical than expected).

I think this can only benefit Scirra because it shows what your audience is all about for future products without them doing a "market research" or something like that.

This is really not a topic about liking or hating C2/C3, just wanted to make that clear for future responses.