Josh

It wasn't my preference but it was absolutely necessary for the type of "method collection" the current system does. The Actor has methods defined by the components that are attached to it. Calling the Actor method calls the same method on each component that has it. Since these methods don't get defined until your game is compiled, it's not possible to attach them directly to the entity class in the engine. I don't really like component systems anyways, so I'm fine just doing it the way people expect it to work coming from unity. I'm happy with a single object attached to each entity with an OOP hierarchy, which is also doable with this.

For entity properties, I plan to use JSON files that define the properties that appear in the editor, rather than parsing the script or code files. This will provide more control and less confusing about how properties can be described, and it can be standard for Lua / C++ / C# and even no-code (third-party games). Something like this: { "componentTemplate": { "name": "player", "label": "Player", "language": "c++", "properties": [ { "name": "health", "label": "Health", "type": "INTEGER", "minimum": 1, "maximum": 100, "default": 75 }, { "name": "target", "label": "Target", "type": "ENTITY", "default": null } ] } } These configuration files can either be stored in the game folder, or in a folder of config settings that get loaded based on a command line switch. For example, a configuration for the game Quake can be stored and loaded with a lunch parameter: Editor.exe +game Quake We will have a standard way of defining available properties and getting data into Ultra Engine, for use with any supported language. We also now have a way of exposing C++ classes to Lua with official documentation, and I have worked out all the gotchas of the binding code and documented the information. It's not super easy to set up, but it's also not super hard, and the results it provides are very very good. This has led me to think about the current design of C++ components. Here are the things I like: Standardizing load, save, copy, and updating is very good. The syntax shared_ptr<T> AddComponent<T>() is very good. Making C++ components header-only, while not required, provides a very convenient way to include bits of functionality. Here are the things I don't like: C++ components work slightly differently from Lua scripts attached to entities, and it will also be different from the C# implementation. The Actor / Entity dichotomy is strange but necessary for the design to work. Parsing header files is never going to be perfect. The behavior of C++ components is interesting but extremely nonstandard. The preprocessor works reliably, but it is a piece of technical debt that will undoubtedly require additional work in the future. I'm thinking it may be best to dial things back a bit, keep the good aspects of this, but try to make something that syncs up better with how people will expect their games to work. The way both Lua and C++ in Ultra call a function on each component when you make a single function call is very clever and innovative, but I am not sure the benefit is great enough to justify breaking peoples' expectations and introducing ambiguity. Here is what I am picturing: C++ components are attached directly to an entity with an Entity::AddComponent<T>() method. No "Actor" class. Methods can only be explicitly called on the component you want to call it on. Load and save methods are manually filled in for each component. The engine will call the methods, but the end user needs to fill in the values. Start(), Update(), Collision(), Load(), and Save() still get called by the engine at the appropriate times, for each component. C++, C#, and Lua components all work the same way. C++ example: #include "Components/HealthManager.hpp" auto component = entity->AddComponent<HealthManager>(); component->health = 75; Lua example: local component = entity:AddComponent("Scripts/Components/HealthManager.lua") component.health = 75 C# example (???): #include "Components/HealthManager.cs" var component = entity.AddComponent<HealthManager>(); component.health = 75; What do you think?

Fixed, see release notes.

1.0.2 Updated C++ library with all recent changes. Documentation for exposing C++ classes to Lua is complete. It's a lot to take in, but it covers all the nuances and is very powerful. Use Core::LuaState() instead of the GetLuaState() function in the docs, for now.

1.0.2 Editor now using Lua with UTF-8 strings File thumbnails are disabled until I rework these No environment maps will be set temporarily and PBR materials will appear darker than normal (file opening bug, there is an error in the DDS loader and I don't know why, probably some low-level file read change...) It looks like the DDS load error is happening with every single DDS file...stay tuned... Fixed! (An integer overload of Max() was returning a double causing the calculated mipmap size to be wrong.) You can see the unicode working if you copy and paste this text into the console and press return to run it: Notify("Message: Unicode❤♻Test", "Title: Unicode❤♻Test")

Wide strings in Lua!

1.0.2 Baseline Lua example now works ZenMode module now using light user data for HWND pointer

I think the only way to get that done is to go through all the documentation and write examples for every command. All the information about how Lua works is very explicit in Ultra: https://www.ultraengine.com/learn/Scripting

This Lua code will work right now in the current build of 1.0.2: --Get the displays local displays = GetDisplays() --Create a window local window = CreateWindow("Ultra Engine", 0, 0, 1280, 720, displays[1], WINDOW_CENTER | WINDOW_TITLEBAR) --Create a framebuffer local framebuffer = CreateFramebuffer(window) --Create a world local world = CreateWorld() --Create a camera local camera = CreateCamera(world, 2) camera:SetClearColor(0,0,1,1) camera:SetPosition(0,0,-2) --Create a model local box = CreateBox(world) --Create a light --local light = CreateBoxLight(world) --light:SetRotation(45,35,0) while window:KeyDown(KEY_ESCAPE) == false and window:Closed() == false do --Rotate the model box:Turn(0,0.1,0) --Update the world world:Update() --Render the world to the framebuffer world:Render(framebuffer) end And this shows how the C++ side is set up: https://github.com/UltraEngine/Documentation/blob/master/CPP/PollDebugger.md

1.0.2 All recent changes are now available in the C++ library Updated C++ library to Lua 5.4.4 Added some system Lua files in the game template Added PollDebugger() function Added .vscode folder in game template for development with VSCode @CanardiaPrint() now takes an optional bool for the line return. This function does not attempt to be thread-safe in any way!

This shows how Lua scripting in the editor works:

1.0.2 Updated editor to Lua 5.4.4 and everything seems to work fine. This adds a utf8 library, bitwise operations, constants, integers, to-be-closed variables, and goto. See here for details, previous version was Lua 5.1: https://www.lua.org/versions.html#5.4 A copy of Lua is available here for building modules.

1.0.2 Did a lot of work on editor Lua debugging and it works really well now. I recommend doing an uninstall / reinstall of version 1.0.2 to clear out the scripts.

This was a bug in the way the window position was saved. I fixed this in the latest build.

Update 1.0.2 In-editor Lua debugging now works with Visual Studio Code: Run VSCode Select the File > Open Folder menu item Open your Ultra Engine install directory (C:/Program Files/Ultra Engine) When prompted, install the Lua debugger extension. (Devcat Lua Debugger) Select the Debug option in the left-side panel and press the run button. Or just select the "Scripting > Open Editor Folder in Visual Studio Code" menu item. You can set breakpoints and examine variables when they are hit and step through the code. Set a breakpoint in one of the Lua files in "Scripts/Start/Extensions".

Updated 1.0.2 Editor Added EVENT_ERROR which gets triggered in a RuntimeEvent. EmitEvent now returns a boolean. See docs for explanation. Fixed bug in WAV loader Modules (Lua DLLs) now stored in Scripts/Modules Added some critical system scripts in Scripts/Start/System Editor will now remember window position I recommend uninstalling and reinstalling version 1.0.2. Not the whole client, just the install process in the client. It only takes a minute and it will get rid of some scripts that I moved. This prepares for Lua debugging of the editor from VSCode. I haven't run the Lua debugger in a long time but I think it will all work to allow debugging of editor extensions.

This will give you a better idea of how editor scripting works: https://www.ultraengine.com/learn/EditorEvents?lang=lua The editor emits a lot of extra events to trigger actions. You can intercept these events and override them or add your own functionality. For example, you could intercept the EVENT_OPENASSET event and make a script file open in a new script editor interface.

Did you try deleting Documents / Ultra Engine / Settings.json?

Is this win 10 or 11?

Updated 1.0.2 Lua listeners will now be executed in such a way that errors will be shown Added PreviewSound.lua extension, which plays a WAV file when the popup preview window is displayed

Example: https://www.ultraengine.com/learn/LoadMaterial?lang=lua

This works: RewriteCond %{QUERY_STRING} ^lang=lua$ RewriteRule "^learn/(.+)$" "learn.php?page=$1&lang=lua" RewriteCond %{QUERY_STRING} ^lang=cs RewriteRule "^learn/(.+)$" "learn.php?page=$1&lang=cs" RewriteCond %{QUERY_STRING} ^lang=cpp RewriteRule "^learn/(.+)$" "learn.php?page=$1&lang=cpp" RewriteRule "^learn/(.+)$" "learn.php?page=$1"

I am using this .ntaccess rewrite rule to prettify the documentation URLs: RewriteRule "^learn/(.+)$" "learn.php?page=$1" This makes it so the URL "https://www.ultraengine.com/learn/Entity" gets treated as "https://www.ultraengine.com/learn?page=Entity". However, if I have trailing arguments like "?lang=lua" they get omitted from the redirected URL. How can I add those into the rewrite rule? I want to use a URL like this: https://www.ultraengine.com/learn/Entity?lang=lua

The client app has been updated: https://github.com/UltraEngine/ultraengine.github.io/raw/main/files/UltraClient.exe When you click on a project it will now be opened in the editor If the editor is already open, the client will send a message to the already opened instance, and it will switch to the new folder You can open the project folder by clicking on the new folder icon Shortcuts for the editor will be created on the desktop and in the start menu The gear icon has a little bit of shading on the gear now, which I think looks better Fixes file copy bug in project sync system Also note the name of the client app is now "Client.exe" and the editor is "Editor.exe".

This is the best way to do this: struct EnumWindowInfo { int messageid; WString procname, title; shared_ptr<Buffer> data; shared_ptr<Window> source; bool result; }; BOOL CALLBACK EnumWindowsProc(_In_ HWND hwnd, _In_ LPARAM lParam) { const int MAX_NAME = 2048; auto info = (EnumWindowInfo*)lParam; WString path; path.resize(MAX_NAME); std::fill(path.begin(), path.end(), 0); int sz = GetWindowTextW(hwnd, (LPWSTR)path.c_str(), path.size()); if (0 == sz) { auto err = GetLastError(); return true; } path.resize(sz); //Print(path); if (path != info->title) return true; DWORD lpdwProcessId = 0; auto threadID = GetWindowThreadProcessId(hwnd, &lpdwProcessId); HANDLE proc = OpenProcess(PROCESS_ALL_ACCESS, TRUE, lpdwProcessId); path.resize(MAX_NAME); auto len = GetModuleFileNameExW(proc, NULL, (LPWSTR)path.c_str(), path.size()); CloseHandle(proc); path.resize(len); if (StripDir(path) == info->procname) { COPYDATASTRUCT copydata; copydata.dwData = info->messageid; copydata.cbData = info->data->GetSize(); copydata.lpData = info->data->Data(); HWND srchwnd = 0L; if (info->source) srchwnd = info->source->GetHandle(); ShowWindow(hwnd, SW_RESTORE); SendMessageW(hwnd, WM_COPYDATA, (LPARAM)srchwnd, (LPARAM)&copydata); SetForegroundWindow(hwnd); SetActiveWindow(hwnd); SetFocus(hwnd); info->result = true; return false; } return true; } bool SendWindowData(shared_ptr<Window> source, const WString& title, const WString& processname, const int messageid, shared_ptr<Buffer> data) { EnumWindowInfo info; info.title = title; info.result = false; info.procname = processname; info.data = data; info.messageid = messageid; EnumWindows(EnumWindowsProc, (LPARAM)&info); return info.result; }