Josh

Yeah, they asked for source code and I just sent them the RenderTexture class source code. If that is not enough I will need to create a simpler app from scratch to produce the error.

This copy of the script won't perform the zip compression, but will just scan files and print out how long it took: Publisher.lua For a new default project on my machine, it takes 0.3 seconds.

What I meant to say is that saving a game state is not exactly the same thing as saving a scene.

Stable branch is now updated to 0.9.7. The previous version is available as an archived version.

In Ultra, projects are designed to be used with one language, because unlike Leadwerks, the Ultra components system works with each supported language. However, it is still possible to mix C++ and Lua. The scripting API provides functionality for running scripts, setting variables, and calling functions: https://www.ultraengine.com/learn/Scripting?lang=cpp The sol binding library for Lua is also included, for advanced functionality, and for binding your own C++ classes for use in Lua. The Steamworks code shows an example of this.

Please don't feel there is any rush to update it for the engine update. There is plenty of content already to promote for this update, and it is no problem to promote about your addon in the next major announcement.

0.9.7 Editor will now store the engine version in the project file, and if the version stored there doesn't match the current editor version, the project manager will be displayed at startup. This prevents the problem of projects showing bad graphics or even worse, crashing, when major updates with shader changes go out. Unlit shader family now supports material texture scrolling.

0.9.7 Full build is uploaded. This is expected to be the finished version 0.9.7 that goes out on the stable branch.

0.9.7 New decals in editor will now be created with a default material.

0.9.7 Small fix for terrain tool issue.

I have to roll this change back and do it another way, because it is causing other problems in the editor.

We can make the script generate a bat file that calls tar.exe to generate the zip: @echo off setlocal :: Set variables set "input_file=path\to\your\file.txt" set "output_archive=path\to\your\archive.zip" set "encryption_password=YourSecretPassword" :: Call tar to create a zip archive with AES-256 encryption tar -cvf - "%input_file%" | openssl enc -aes-256-cbc -e -pass pass:"%encryption_password%" -out "%output_archive%" echo Compression completed: %output_archive% endlocal

0.9.7 This update only affects the editor. Not-yet implemented object types are now grayed-out in the scene browser popup add menu. Fixed some physics properties not being saved in scenes. Removed buoyancy setting from entity properties dialog, since it is not implemented yet. Fixed pick mode property affecting editor behavior. Updated component template to add entity property and Collide() method to C++ components. Changed order of effects objects.

Are you sure your component is registered? Can you verify the Load method is being called at all? I tested a new component without any problems.

I think this was probably automatically fixed along with this:

Fixed!

In my test, friction does work. I added support for the other missing values. The buoyance setting is being removed since it does not yet have support.

For you? Anything.

I thought about this a bit more, and I think the simplest solution is to add some logic that makes the world update speed take this extra delay into account if it occurs, instead of just using the user-defined update frequency. Under normal circumstances you would not need to multiply movement values by anything, but if you want to account for the possibility of the framerate dropping below the desired one, you would have that ability.

0.9.7 Some fixes to particle settings in the editor. Removed Publisher script extension so we can make it more secure before releasing. Fix to RecordCollisions() that will provide all collisions that occur. Added an Entity::GetMaterial method. This only returns a material for sprites, particle emitters, and decals.

This is what I use for some internal timing stuff: #ifdef _WIN32 double PCFreq = 0.0; __int64 CounterStart = 0; bool counterstarted = false; #endif double fMillisecs() { #ifdef _WIN32 //return GetTickCount64(); // this only updates every 16 milliseconds, don't use it! //return timeGetTime(); if (!counterstarted) { LARGE_INTEGER li; QueryPerformanceFrequency(&li); PCFreq = double(li.QuadPart) / 1000.0; QueryPerformanceCounter(&li); CounterStart = li.QuadPart; counterstarted = true; } LARGE_INTEGER li; QueryPerformanceCounter(&li); //return (((double(li.QuadPart - CounterStart) / PCFreq) * 1000.0)) / 1000.0; return double(li.QuadPart - CounterStart) / PCFreq; #else long t; struct timeval tv; gettimeofday(&tv, 0); long secstomillisecs = 1000; t = tv.tv_sec * secstomillisecs; t += tv.tv_usec / 1000.0; return t; #endif }

I am going to comment out the z-sorting modification in the release of 0.9.7 that goes out on the stable build, and then we can go back to testing it. I am pretty sure I can make it smart enough to detect when there is a solid background, but I would rather have it working correctly in the stable build and then experiment with it some more on the beta branch.