CJO Games

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...

Obviously, this is caveat-ed by the fact that I am running the engine on Linux, however this was an issue too on Windows hence the topic... When the terrain is selected - for instance for painting textures; sculpting etc. The editor is extremely slow making the painting process for detail layers (paths for instance) hard to complete.

I thought I'd post this here for anybody else too impatient to wait for the official Linux release. This is my Wine based setup for a 'working with visual bugs' Ultra game engine running on Linux. The OS I use is Zorin-OS (Ubuntu) on Gnome Desktop. The most important part is to ensure that the launcher of choice (in my case it is Heroic but its also working under Lutris) is pointing to the downloaded Client and not the installed one - it needs to install the client each time but this doesn't have any effect on the saved game files its just the launcher being replaced I'm not sure why this is. It also seems to work best if you force the engine to save or import project files not from the 'C:/' drive that wine creates and instead one of your Linux folders home/desktop, home/documents or one of you other disks from /mnt I've altered some of the .bat files for creating shaders etc to run from Linux so that they are compiled within Linux but the .bat files are runnable from wine if its preferred. You can also point wine to download the Vulkan runtime from wine as well as the SDK on the Linux side - this seems to work well. TXT.txt

Ok, thanks, I'll get back to you..

Any suggestions on how to get them across to you? Its quite a large set...

I found this recently and thought it was a useful resource so posting a link here for others: GitHub - stevinz/awesome-game-engine-dev: Awesome list of resources for Game Engine Development.

Admittedly, I was trying to push the boundaries of the engine with this one. The attached map contains a number of complex KitBash3D models - each with 2k texture files. The files have been exported from blender into the engine and have been placed in the editor (although it was rather slow). I then save the map and exited - this morning I'm unable to open the map as it crashes the engine to desktop. I've attached the map file - if you need more please let me know. Another World.zip

I noticed that I had multiple instances of editor.exe; preview.exe and that they had pushed my cpu useage up to 100% - I think these were from previous running of the game engine and had been left over when I'd experienced crashes. I was able to close all of these through the task manager.

That's great - thanks. The vertical scaling was mostly borne out of mu own laziness rather than it needing to happen that way :-)

Hi Josh I'll let you know if I find any more issues with it - thanks!

Run Game is failing with index out of range. Thea.zip

Generating materials within the editor from Leadwerks .tex causes a crash to desktop with a loss of all previous work...

Ok I think this is working (I think). The original looked as though it was doing something because the built in one was still in the scripts/start folder. To get this to work the original script should be removed from that folder put it in a backup folder outside of scripts/start and it'll then not interfere; you should then be able to see if this is doing what it is intended to or not. This one has been renamed to remove the 'CJO' bit at the end as the engine is looking for FBX2glTF. I've kept the original option within the script so you can switch back to the original by changing the comments in the script. Let me know if its working or not if you use it and suggestions/improvements etc... FBX2glTF.lua

Ah! That post might have been a bit previous... ignore the above it doesn't work I'll post again when it does...