I believe we can disregard any differences between win7 and win10 until Chrome stops being updated for win7 or win7 can't benefit from specific functions.

Especially since in C3 it's all browser based and even works fine on a ChromeBook

The only major changes between win10 and win7 that are coming is new CPU support for AMD Ryzen, which I doubt will affect browsers. Someone will probably at the very least make an open source driver for ReactOS that may work with Win7 just fine for that.

https://www.reactos.org/

Windows 7 will be going strong for quite some time even if unsupported by MS

With Construct 3 being browser based it could provide an environment where Scirra could easily make an sound panel or at the very least have an SDK that allows you to use existing javascript audio tools in a custom panel.

Hopefully we'll have some news on how they're handling things but from their existing screenshots things look promising.

Check the value of "self". It's saying that it can't get "trigger" from undefined.

So my guess is "self" isn't the right value.

self.runtime is probably undefined so you can't get further values.

You can even use the browser debugger to stop at that line so you can inspect the values.

I think I figured out how to deal with it.

Since the function I'm calling in the API has it's own THIS and SELF tags I had to specify the it outside the trigger call

Acts.prototype.listenTo = function (topic_)
{
	var c2self = this;
	APIThing.Messages.listenTo({topic: topic_}).then(function(message,msgInfo) {
		c2self.msgContent = JSON.stringify(msgInfo);
		c2self.runtime.trigger(cr.plugins_.PluginName.prototype.cnds.OnProvMessage, c2self);
	});
};[/code:1a86eokk]

With this code it's returning the JSON info I need .

I ran into a slight issue trying to use an API that works fine on a normal page but is giving me some issues through C2.

[quote:3vw215xn]c2runtime.js:16296 Uncaught (in promise) TypeError: Cannot read property 'trigger' of undefined

• at messageEvents.cb (C2runtime)
• at self.provider.getPost.then (API)

The line in question on the C2runtime was:

self.runtime.trigger(cr.plugins_.PluginName.prototype.cnds.OnProvMessage, self);[/code:3vw215xn]

Looks like the self modifier there might be applying to the API's listen promise/function, so there might be a better way for this to be executed. An earlier version of the API worked no problem with just BrowserExecJS but due to updates to it using promises, I'm having to delve into the SDK a little to try to make things work. I'm not used to working with Promises so there might be a simple solution I need.

Here's the runtime code for the plugin I'm trying to setup. Currently the only actions are Connect, Listen, Send, with an expression for the message and condition to trigger when a message is received.
[code:3vw215xn]
	// called whenever an instance is created
	instanceProto.onCreate = function()
	{
		
		this.msgContent = "";
		
		APIThing.Messages.setProvider('providername', {server: 'localhost', port: 5001});
		
		var self = this;
	};

...
	//////////////////////////////////////
	// Conditions
	function Cnds() {};
	
	Cnds.prototype.OnProvMessage = function ()
	{
		return true;
	};
	
	pluginProto.cnds = new Cnds();
	
	//////////////////////////////////////
	// Actions
	function Acts() {};
	
	Acts.prototype.listenTo = function (topic_)
	{
		APIThing.Messages.listenTo({topic: topic_}).then(function(message,msgInfo) {
			self.msgContent = JSON.stringify(msgInfo);
			self.runtime.trigger(cr.plugins_.PluginName.prototype.cnds.OnProvMessage, self);
		});
	};
	
	Acts.prototype.sendMsg = function (topic_, msg_)
	{
		APIThing.Messages.sendMessage({
			topic: topic_, data: {stuff: ((msg_).toString() + '').toString()}
		});
	};
	
	pluginProto.acts = new Acts();
	
	//////////////////////////////////////
	// Expressions
	function Exps() {};
	
	Exps.prototype.message = function (ret)
	{
		 ret.set_string(this.msgContent);
	};
	
	// ... other expressions here ...
	
	pluginProto.exps = new Exps();
[/code:3vw215xn]

2D flowchart systems like that are pretty much completely different to events.

They're pretty similar in my opinion after working with both smart contracts and node-red. (only a minor amount at the moment.)

I'd love to see flow support in C3, although it's not a priority.

With a proper flow translation you can easily convert flows into the tree structure events and normal coding uses.

Would it be possible to have it as a DLC/add-on option for Steam so I can stay up to date through Steam?

I keep track on the website anyway but it would be a nice convenience since I already have C2 through Steam.

Workshop Support for GDT - Greenworks updated as well

Seems like they updated their plugin to have workshop integration. High hopes for C2 potential for native steam games once 0.11 is stable.

With save/load, you don't have to save your entire project's state.

Mostly to reduce the clutter of it's savefile, make a couple families called "No Save OBJECTTYPE" and apply the behavior that prevents saving of that object's data. This way you don't have to record the exact location of all the sprites and static elements, saving the global variables and whatever objects you did not blacklist.

With webstorage, you just save a key to a value, sort of like a perma-dictionary key. You have to design your own events on what to load into where with this, but it's more of a whitelist option, where you choose what to save. The save/load basically uses this, but it's saving/loading code is already programmed into the C2 engine.

In the end they both function the same, data is saved and is kept until webstorage/localstorage is cleared.

So in summary, for saving games:

Save/Load = Blacklist

Webstorage = Whitelist

Are you previewing in chrome or exporting?

Are you resizing your playable area in non-integers? (Windowsize for node)

Are you using pixel rounding?

Usually upon export since it's a cut image from the spritesheet/tile it has the common issue of grabbing a few subpixels of the transparency around the sprite/tile. Professional games experience this too in their engines and bleed the texture a few pixels outside of the area they're cutting.

With C2 the best way to avoid that without editing the output compiled image file is to resize based on integer, use pixel rounding, or LQ Render

But then it would be a different sprite or different animation frame, in which then you're going to have a default imagepoint on that version to shoot with anyway.