Josh

I have not sent out an email or posted anything anywhere else about the release yet, I think I want to demonstrate more component functionality first, with an emphasis on player movement. Using this for the player model, I want to demonstrate four movement components: https://sketchfab.com/3d-models/biped-robot-801d2a245e4a4405a0c2152b35b5e486 First-person player (no visible model) Free-flight camera with collision (no visible model) Basic third-person player Random navmesh movement, just picks a random point and walks to it, just to show basic navmesh functionality. I'd rather not add weapons yet because I am not sure how the components should be broken up, and I want a lot of user feedback on how it should be designed. The existing components are designed to be simple and understandable. With Leadwerks, I was sort of showing off and making a game, but it made the player and AI scripts excessively complex and hard to modify. Once everyone understands how those components work, we can discuss how the weapons system should be set up. We want weapons that work with first-person, third-person, and enemy/NPC components. I don't know yet how that should work and I want your input.

I look forward to it...

The sprite handle/offset issue can be demonstrated in the editor just by loading a map that has a sprite in it. I have uploaded a fix for the editor on the .dev channel. A build of the static libs and Lua binaries will be available later today.

Fixed bug where a viewport mouse event would get triggered by double clicking on a file in the file requester dialog, and the underlying object would get selected.

There's probably a good reason not to do this. Editor scripts are like application code. A script can do bad things. If the editor just runs whatever scripts appear in somewhere in a non-admin folder, the editor could do bad things. Making the user copy a file into the "Program Files\Ultra Engine" directory ensures that they have to have admin priveleges to complete that step. I suppose you could put a script in their that load a folder somewhere else and executes all those scripts, but there's still that critical step where the user has to confirm they know what they are doing and are allowed to.

Also, if you can build the preprocessor with Ultra App Kit you will get a much smaller executable.

Something important to understand with sprites is they don't have any rotation on the CPU side...the sprite facing code only executes in the vertex shader. The reason for this is that their rotation is always relative to a camera, and there may be multiple cameras rendering the same sprite, and rotating it differently for each camera isn't possible. So the concept of a world Pick operation intersecting the rotated mesh doesn't make sense, because that rotation has to be defined relative to something. This is why sprites use a sphere collider for picking. I could adjust the radius of the sphere collider, but it is still a round shape around the center of the sprite that can be picked.

There is no support for saving BC7 without this plugin. The reason for this is that BC7 saving is normally incredibly slow. You can try this yourself in Visual Studio. Converting a 1024x1024 image into BC7 will take a full minute! The ISPCTexComp plugin uses special magic so that BC7 only takes a few seconds.

Apparently Avast does this to Autodesk too: https://forums.autodesk.com/t5/fusion-360-support/avast-antivirus-going-nuts-about-quot-evo-gen-quot/td-p/8286866 I did a scan of the EXE (it's the 2023 build) with Microsoft Defender and it did not detect anything.

It says the preprocessor exited with an error code? error MSB3073: :VCEnd" exited with code 9009

Added a simple third-person player controller component, for both C++ and Lua.

Lua binaries are updated with support for flowgraph connections in maps. The starting map will work in Lua just like it does in C++. ChatGPT did a nice job of converting my C++ components into Lua code. This is very interesting because map files themselves are language-agnostic. The same map can run in a Lua or C++ game, with all the same behavior. You don't ever have to call FireOutputs() in Lua, as this will be handled automatically for you.

Starting map is updated to demonstrate a collision trigger and two sliding doors (C++ only). Now going to make it work with Lua...

The header externs the global variables so you can probably create your own time update function. Timing.h

Working flowgraph is available on /dev channel now.

Added first pass at the sliding door component. It works nicely. Editor now supports file path component properties. Create a string value and add settings for "filecategory" or "filepattern". category can be SOUND, MODEL, TEXTURE, or MATERIAL, and will get the file pattern for that asset type, including the types any import plugins include. { "name": "myfile", "label": "My file", "filecategory": "SOUND" }, { "name": "myfile2", "label": "My file 2", "filepattern": "Text Files (*.txt):txt" }

First implementation of the flowgraph in Ultra is up on the /dev channel. Only the C++ static library is updated, Lua is not built or tested yet. (When it is, some of the things you have to do manually in C++ will be automated in Lua.) Zooming is not supported yet, but it will not be too hard to add with the DPI scaling feature we have. Method arguments are not yet supported. CollisionTrigger component has been added to the C++ template, seems to work well. To expose methods as either inputs or outputs, add them to the JSON file: "inputs": [ { "name": "Test1" }, { "name": "Test2" } ], "outputs": [ { "name": "Test1" }, { "name": "Test2" } ] In C++ you must manually call FireOutputs() in any methods that act as outputs: virtual void Test1() { Print("Test1"); FireOutputs("Test1"); } To receive flowgraph connections, you must add CallMethod() to your component: virtual std::any CallMethod(shared_ptr<Component> caller, const WString& name, const std::vector<std::any>& args) { if (name == "Test1") { Test1(); } else if (name == "Test2") { Test2(); } return false; } I will try to get some usable components that use this up soon.

I'm very sorry to hear that. Your father was a well-liked regular here since 2009. You might find some of his posts and stuff interesting to read: https://www.ultraengine.com/community/profile/53-cassius/content/?type=forums_topic&change_section=1

Your little command language looks cool. This is probably more useful than exposing full Lua programming. What are the extents/limitations of the syntax? Is it just "command arg1, arg2, arg3?"

I have attached the timing code for you. Hopefully this will help. Timing.cpp

1. No. Steam Direct allows anyone to publish on Steam, and this is a better path for developers. 2. Yes! 3. I don't plan on integrating Steam Workshop for a few reasons. Ultra is offered both on Steam and as a standalone, whereas Leadwerks was Steam exclusive. Steam Workshop has never worked very well for me, and has always been slow-loading. I'm trying to focus on making the import pipeline the best it can be. Instead of trying to build up a repository of 3D models, I would rather just make it easy to import models from an existing site like Sketchfab. Maybe a Sketchfab browser will be integrated in the future. 4. Plugins and editor extensions are supported now.

When the people tell me its ready.

Starting on the flowgraph implementation. I'm going to try to have this done by Monday. This is rendered in GDI+. Zoom also works, without much effort: I'm designing it as a custom widget I will post the source to, so it can be reused for other purposes if desired. I didn't mention it but segmented line widget blocks exist in Ultra now.

In Leadwerks, the physics are updated one step in the World::Update method if 16 milliseconds have passed since the last physics step. This works independently from the framerate. Physics objects are smoothly interpolated between the previous two steps in order to provide smooth motion, even if the framerate varies from 60 hz. There is no easy way to modify the physics step time.

for n = 1, #scene.entities do entity = scene.entities[n] end