Engine Release: v1.26.0

Engine v1.26.0 has been released. Release notes:

To stay updated on engine development, hit Watch on the repo. Support us by hitting Star too! :smile:

5 Likes

Relly awesome that you’re working on ES6 classes and this is for sure a step in the right direction, but it seems as the implementation is not 100% complete yet?

When forking this project https://playcanvas.com/project/668763/overview/es6-script-tests and trying to attach es6-script to an Entity on the scene it simply not possible.

Also, when selecting the es6-script.js asset and looking in the inspector in the right side of the screen it says “No Script Objects found”.

Maybe it’s pc.registerScript() that isn’t registering the script properly?

EDIT: Created an issue on Github: https://github.com/playcanvas/engine/issues/1934

Love the ES6 support! But presumably using it will kill IE11 support for that game? Would you guys ever consider adding a transpiler such as Babel into the build pipeline?

1 Like

@davidpox
It doesn’t answer your question and it’s not a perfect solution but it might show a way.

I’m currently trying to use the project linked below as it opens up a few possibilities such as using my own IDE (WebStorm) and using TypeScript.

It transpiles your code with webpack and uploads the transpiled code to your project so the door is pretty much open for you to use whatever feature you’d like.

With the newest update this template is now broken, it doesnt work because of the way it attaches attributes to the script type. I wonder if we could get any kind of rollback for this… or at least a way to choose what playcanvas build we can use in editor, this template is my main way of working because of vscode + typescript.

Hi @Alberto_Carbajal. That template has not had a commit in over 2 years so it doesn’t appear to be maintained. It’s written by a third party and is not officially supported by the PlayCanvas team. I’m sure it’s pretty straightforward to update to work against the latest engine though. Note that there are a lot of PlayCanvas developers who do use Typescript locally and they didn’t have too difficult a time moving to 1.26.0.

BTW, it is possible to run your scene from the Editor against an older engine version. Check out this page:

https://developer.playcanvas.com/en/user-manual/scripting/custom_engine/#launch-with-a-previous-stable-engine

Yeah, I know the template is outdated but I found it was pretty easy to modify and use in combination with the PlayCanvas editor so I just thought I wanted to share it as others might find it helpful as well.

I’m pretty curious on how others are integrating with TypeScript so if you know of any examples, @will, I’d be grateful🙏

And just to be clear, the only troubles I had moving to 1.26.0 was actually having the editor recognising scripts using the new (to PlayCanvas) ES6 classes. Besides that 1.26.0 works perfectly well.

EDIT: And thanks for the tip on specifying the engine version, I wasn’t aware of that👍

Yeah, that tip about using earlier versions is actually super-useful. Let’s say, for example, there’s some regression in the engine that affects you. It’s easy to determine when it was introduced and it allows you to carry on unhindered while we deploy a fix.

I think we need one or more typescript examples in the engine codebase. I created this issue just now:

Anybody want to take that? @aiab_animech maybe? :smile:

1 Like

Urm, Will, i think you missed my issue I have with the latest build and now the online editor has the similar problem as well. attributes typehinting is lost on generated class, and for es5 case, this.attributes is erraneously reflected as a typehint, when in reality it should be undefined .This problem wasn’t addressed?

https://github.com/playcanvas/engine/pull/1908#issuecomment-603175894

I have to manually patch the playcanvas.d.ts file to add an actual static behind readonly attributes, so it doesn’t appear as a member instance property but instead reflects the proper typehint for ScriptTypeClass.attributes… Somehow, when using jsdoc to export out the field definition (@static) keyword gets reflected, but it appears to have no effect on the typehints compared to a full static declaration.

Regarding Typescript and “the outdated template”…

Use my updated one that is more fairly recent Introducing updated Playcanvas JS/Typescript Template . I have working recent Typescript template examples for the version of Playcanvas just before this new 1.26.0 update (backward compatible) which should still work despite not using the new 1.26.0 version approach (that now allows extending pc.ScriptType directly), . Looks like on the new roadmap, I’d have to change the approach to extending pc.ScriptType directly and using a a possibly new @registerScript decorator instead (rather than the current @createScript decorator) . However, i think i’d hold this back until the inherant issues with failure to recognise/parse scripts within online editor is dealt with with regards to extending pc.ScriptType directly. (including the typehinting attributes issue i mentioned above).

Honestly though, i felt this update wasn’t really that “perfect” (and i thought you’d would had tested this for longer). There are already some issues assosiated with the use of Es6 classes as mentioned by the others. However, it’s one of those features i won’t use directly anyway since i also want to support mobile browsers as well, which means Babel or some means of transpiling (like Typescript), is still needed just in case (possible to do for online editor compile?).

At least it’s a first step, but ideally, I would have wished for the ability to extend pc.ScriptType directly without having to remember to use “registerScript” at the bottom. (eg. like how in React, you can extend React.Component directly…). Unfortunately, given the way Playcanvas works, this might not be possible without the use of decorators to make the process more obvious( declaring it on top so it stands out more…). But decorators are non-standard browser feature requiring either Babel/Typescript. Also, I would wish to have the ability to locally define typed attributes with full type hinting/type checking support available within Typescript like what i already have in my Babel/Typescript template, (but again, i use decorators for this…).

1 Like

It seems @aiab_animech has fixed the static attributes problem:

I just merged that.