CJO Games

Hi Josh, I can confirm that there have been no further issues with recent builds - thanks as always!

Sorry Josh, this doesn't seem to have solved the issue. Even with an (admittedly very large) empty map it is still very slow... I have removed all textures so this shouldn't be an issue when you test your end but hopefully you will be able to reproduce this at your end - as soon as the terrain is selected for painting it becomes very slow. 1451298458_Mountainsandtarns2048.zip

Will test and confirm...

Try any of the standard model files copied from the Leadwerks editor into Ultra - it appears to happen when scrolling through assets from any source - granted I have a hell of a lot of assets in the editor but I was able to reproduce by copying over some Leadwerks editor models such as 'Modbuilder' from the workshop...

Starting the editor or scrolling through the assets - I think its related to the editor's generation of .png images...

Seek position outside of bounds - this occurs repetitively when starting the editor and whilst using it.

Thanks Josh!

Yeah, I've tried that, unfortunately - plus a fresh install but no luck.

Suddenly today the client app seems to have stopped working. I'm unable to open the editor as I have a authentication error. Reinstalling the client hasn't worked.

I might have raised this before so apologies if it's a duplicate... If the editor crashes to desktop the Preview app will continue to run in the background - if there are multiple crashes (which there are) then the preview app is running multiple times this will run CPU usage up to 100% until the app freezes - force ending the preview app solves the problem and the editor will recover.

Sames as with the other bug report today...

Nvidia GTX1650 DDR6 OC 4gb CPU is Intel i3 10105f RAM is Ddr4 16gb it's been consistent behaviour since launch and appears to get worse the more assets are placed in scene. It's not specific to Linux or Windows happens in both.

The editor is continuously posting the above error (VK_Wait For Fences returned error -4). Its causing a hard crash at each instance to the editor the client and my PC. When the editor is restarted the work done up until that point is lost even when its saved at regular intervals.

I'm not sure if this is an intended function or a bug sop do with it as you will. See the pictures below for a clearer idea. It appears to be the grid lines that are continuously visible in the editor and also when the 'game' is run...

Have a look at the attached fps script - it's a working example of how jump is integrated - it seems counter-intuitive to rewrite what is already available and what is already working...

I think the best way to answer this question is to ask another - what is it you want your created model to do? Assuming you want to create a player character(?) the first thing to do is place it in the editor (graphically) and then attach a player script to it using the script tab in the editor (you can see it in your post above) - I think you are trying to set up a player character programmatically, which is fine but not necessary; indeed, the graphical option (drag and drop) is an easier start and gives you the chance to get a working prototype up and running. I have found that learning my way around code comes easier to me by looking at and adapting ready built scripts - seeing how they work and then understanding that feels like a more natural approach - but of course this all comes don to personal preference. In terms of what I think you are trying to do above you might start with the included FPS script and adapt it for your needs - as an example - here is my own adapted FPS script which includes a number of commented sections where I have tried to understand what each part is doing and also has some other changes that I have found useful/necessary for my own projects. I've also attached a script I'm currently working on which is designed with a space exploration game in mind and which I have adapted from the spectator script included with Leadwerks. Hopefully these will be helpful to you. In terms of LUA in general, Leadwerks is more of an implementation of it than its purest form so although its useful to look up other sources it will have differences too. I have actually found that AppGameKit Studio has been useful because although it is a BASIC language its structure and syntax are similar to the way LUA in Leadwerks works. Also useful are the Skyline Game Engine which also uses LUA but in a different form and Game Guru Max which has its own quirky implementation of LUA. FPSPlayer.lua BridgeCam.lua

One more image in single view-port and with the terrain fully 'painted' in Ultra - it also includes my first iteration of a water texture as a stand in...

Here are a couple more images as a sort of comparison of Leadwerks on Linux and Ultra on Linux. They show the same map loaded in both although admittedly at different stages - the Leadwerks map is fully painted and has a full vegetation layer too - because those tools aren't available yet in Ultra the vegetation layer is, obviously, missing. I do think it serves to demonstrate the strengths and weaknesses of both engines though - for my own part, Leadwerks' biggest strength has always been its lighting - there isn't anything quite like it not even Ultra (this is just my own opinion). Ultra's lighting, although nice is much softer and so the result is, as far as I can tell thus far - that from afar it all looks lovely but close up it loses some of the definition that Leadwerks has. In terms of running on Linux - Leadwerks has the benefit of being a steam app and is running through their compatibility layer with Proton 8.0-4 this presents no issues and the long running LIBCURL error isn't a factor either. As previously stated, the Ultra Engine is running through Lutris and is using the Wine compatibility layer, specifically this one: lutris- GE-Porton8-15-x86_64 - its fast and it runs but there are problems specifically with the editor in multi window mode whereby the back-buffer(?) will go blank this can be seen in the last image. If you click the mouse to regain focus on the window it comes back to life again but it does make interaction a challenge. I suspect this has more to do with the Nvidia driver implementation than it does the engine.

It's a feature available in Leadwerks that I really miss in Ultra...

And one final one with the map I'm currently working on in the editor...

And the app running as of right now...

I have switched OS to POP_OS as I find it more stable than Zorin even though I think Zorin is better looking. One of the things I noticed is that Zorin is heavily reliant on Flatpak and, it would appear that the desktop itself runs within a Flatpak container. Unfortunately, this can cause issues with SDK's and access - this is especially the case when using other disks and them appearing either under /media or under /mnt and the access to those positions through the Wine layer. With POP_OS I've got Ultra running through Lutris and, it would appear, this has been less buggy than Heroic in terms of screen - refresh. When moving objects in the map all four screens were going blank which made interaction interesting to say the least! It's still an issue at the minute but less so. If you install this way be certain to add the cmd app/module through Winetricks otherwise you won't be able to run the .bat files from within the editor. The main benefit with all of this is that I don't need to continually install the client app as was required with Zorin and the Heroic launcher. With Lutris it's possible to permanently point to the installed client app and it will run. The following tools have proven to be useful with all of this: SPIRV-Tools; Vulkan-SDK (Linux); SPIRV-cross-main. Godot Engine FBX2glTF converter; Lutris; Heroic Launcher; Proton-up and Wine/ Winetricks.

How about a terrain edit mode that means the terrain selection is only available at certain points like for instance create terrain with a add/move/edit (size, height, import etc) selection and allow the painting of the terrain (and presumably the vegetation layers) to happen as it does now as part of the general workflow? I get the feeling that the issue is exasperated by the terrain being selected and the mouse tool panning over that so not having the terrain selected unless you need to move it or edit its size or add more terrain might help...