Mikal's Forum Posts

  • reimuxx Please try it out and let me know if it works for you and if there are C3 ACEs required for 4.2 feature support.

    Also if you are using C3 Spine in a paid/commercial project, please consider supporting the C3 Spine dev effort by donating on the git page.

    github.com/gritsenko/c3_spine_plugin

    I wonder if you've discussed this with Chadori, Mikal and other big addon makers? Will you provide them with support, ensure that their addons get converted before the deadline?

    In my case the answer is no, the only response so far has been to deny a suggestion request for SDK V2 to support the ProUI addon and then no further response after I tried to compromise and be more specific in regard to the response and look for help for another solution. I just got a good helpful response and I appreciate it!

    I hope this changes collaboration continues in the near future. I feel like it has been more collaborative in the past w.r.t. SDK support requests and hope that returns.

    I mentioned this before, but another proposal, is to continue with SDK V2, etc. for the mainline C3. Add a license for full C3 source availability / no encapsulation / obfuscation in runtime or editor as is the general practice with game engines. The typical user which is the one that will complain about broken addons will not pay for the extra license. The extra license can outline the risk and requirements for the user. This license will allow users to work with C3 in advanced way directly or with advanced addons. The advanced addons will only be able to be installed in the advanced version of C3.

    Other engines also have a much more extensive feature set and API (Unreal, Unity, Godot) for both general scripting and plugins, if C3 was at a similar level for SDK V2, it would be more acceptable, since it doesn't I would suggest that C3 takes a different approach for more advanced users.

    This is how it works in every other engine, because you generally can't access the internal engine in any other software.

    In general, for game engine software, Unity, Unreal, Godot all have plans that allow for their internal engine source to be accessed, changed and rebuilt as needed for addons or different functionality by more experienced game developers.

    Looking at some of the sample v2 addons, I notice that this is removed: 

    GetScriptInterfaceClass()
	{
		return self.IMyDrawingPluginInstance;
	}

    My hope is that is because the scripting interfaces for addons will be 'automatically' generated somehow. Is that correct, or is there something else happening?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    Will Scirra provide assistance to help with porting from V1 to V2, besides the very simple SDK examples?

    Is there a possibility to make a 'wrapper' around V2 SDK to support previous V1 SDK addons or at least for the vast majority of the V1 SDK?

    Can Scirra create a script or tool to translate the majority of an addon (and add comments or highlights where the translation is not possible via automatic translation).

    Ashley - please take a collaborative look at the SDK V2 requests - realize that they are not trying to prescribe your SDK V2 design, they are requests for functionality - which could be implemented in different ways. If the request does not map directly to you design, can you please consider other methods or alternative approaches to the functionality that can be used. We want to work together with you as you promised and make SDK V2 powerful and useful for the new addons which use V2.

  • See the latest release for initial 4.2 runtime and physics support. If you see an issue, please share your 4.2 physics project with information about expected behavior. You can post link to project or send me a DM at Discord (I an in Construct community server.)

  • How would you process the data? Use events or JS?

  • Which version of C3 were you using?

    The update was a change specific for r389, if you were using an earlier version, it would not work.

    Today, I just added a new release 1.819 which is backwards compatible.

    If you see an error, report:

    - C3 version used

    - Platform (mac/win/mobile)

    - Errors seen on devtools console:

    developer.chrome.com/docs/devtools/open

  • Released fix for r389+:

    github.com/ConstructFund/proui

  • Hi Mikal, can you help me?

    my character wears Spine physics in her hair, but doesn't construct the physics doesn't work.

    What can it be?

    Physics are not implemented yet in the addon, I'll need to add 4.2 support, but busy at the moment.

  • Added optional functionality to codesign the fat app (tested with adhoc signature).

    We found that on ARM MacOS codesigning is needed to correctly handle permissions.

  • The retro style is so well done. The grainy noise really hits. How do you create your nice detailed level, do you do in C3 editor or external tool and import?

  • I didn't see the MacOS nwjs universal app binary available yet, so I created a tool that can combine two c3 MacOS arm and intel exports into one fat binary. Don't package the C3 nwjs exports.

    FOSS tool - so C3 could integrate if needed/wanted.

    github.com/MikalDev/fattennwjs

    Tagged:

  • Nice work!

  • So, as I said before, we are not actually going to remove all undocumented features in the next release. However we will move forwards with a plan for a v2 SDK over the next year or two, which should give enough time to design a suitable SDK and deal with the inevitable difficult backwards compatibility issues that come up. Let me be clear: we did not have to do this, as we reserved the right to say "tough luck". However as it is clear this is untenable and obviously unpopular, we are promising to do the necessary work to make sure this transition goes smoothly. This does mean designing a new API in co-operation with the addon developer community, and I would hope this ultimately ends up a comprehensive, capable API that does pretty much everything addon developers could reasonably want to do, short of unfettered access to the internal engine. I would ask for co-operation during that process so we can end up with a reliable, robust, maintainable SDK in the long run, and not the risk of disaster that we are constantly running at the moment.

    Thank you Ashley, I appreciate this response and I look forward to co-operating with this effort and helping out with the process as it moves along, whether that is adapting addons to a new C3 SDK, offering suggestions, explaining what features would help port addons or sunsetting addons which can no longer be supported with the new SDK.