SpiderPig

If you publish through the editor the zip file is allready encrypted with a non disclosed password. Only your game can access those files diring the load process.

How are you making the collision hull? Exporting as FBX then converting that model to a collision hull?

No problem. Just the fbx should be fine. ?

Can you upload a model? I can test it on my end and see what might be happening.

The Seventh World is a Medieval Fantasy Survival game, inspired by the likes of Skyrim and ARK Survival Evolved. It's been under development for the last two years but only in the last eight months has a real commitment been made to it. Spending every night after work and every other day working on it I've achieved a base from which to build on. The cuboid landmasses are called fragments. They are arranged as a sphere to make up a planet. Game-play will eventually include moving from one fragment to another. Each fragment face has a gravity direction toward the center of the land mass. Each face is known as a World. The top most face is the First World. The left, The Second World. The right, The Fourth World. The North face is The Fifth World and the South face is The Sixth. The last face, opposite to the top is The Third World. Each World is separated by an area of weak gravity known as the gravity void, making it difficult to travel between them without the right equipment. Each world will also have unique features and biome characteristics. In total, there will be approximately 12.5 million square kilometers of explorable terrain. There is minimal game-play at the moment. You spawn in one of the procedurally generated towns and the most you can do is; Harvest trees. Drink from the well. Sell/buy items from the shop. Eat equitable editable items. Run around. What I'll be working on next is fixing the obvious graphics issues. This will include; Terrain patch seams. Billboard trees and their many issues. Bugs when nearing the gravity void. Distant fragment seams. The Plan My overall plan is to get this to an alpha stage so it can be released on Steam. For this stage I want to have the following implemented; VR Multiplayer Building mechanics. Basic Missions. Improved Graphics. Bug Warning Physics shapes are not releasing and are causing memory usage to increase. Various other small memory leaks. Crashes in the gravity void sometimes. Feedback and suggestions are welcome. I hope to have a progress update every one to weeks. Download Here

What Josh says here is that the deferred renderer can't do transparency like that. We can only discard one pixel at a time to get 100% transparency.

I'm creating a password protected zip in C#. What type of encryption does the engine use when loading a package? I have a flag for AES I can set to 128 or 256 or off. The zip file did load but no files could be read from it, and the passwordVerified flag was still false.

I'm looking at the Actor class, when does ReceiveSignal() execute?

Hi @Josh, a topic of mine for a while has been making my own character controller but with no success. Using the default controller would be fine, except changing the worlds gravity dons't change the up vector for the controller. It just falls to the side. I'd like to have the ability for each controller (and even each physics object) to have it's own gravity direction, or at the very least for the controller to work with world gravity. Options like this allow for much more diverse range of games that Leadwerks (and Turbo) can make. Test program below; #include "App.h" using namespace Leadwerks; App::App() : window(NULL), context(NULL), world(NULL), camera(NULL) {} App::~App() { delete world; delete window; } float lookspeed = 0.1, looksmoothing = 0.5; Vec3 mousepos; float jointpos = 1; bool wireframe = false; Entity* child; Vec3 p = Vec3(0.0f); bool App::Start() { window = Leadwerks::Window::Create(); context = Context::Create(window); world = World::Create(); world->SetGravity(9.8f, 0, 0); camera = Camera::Create(); camera->Move(0, 0, -4); camera->SetDebugPhysicsMode(true); Light* light = DirectionalLight::Create(); light->SetRotation(35, 35, 0); child = Model::Box(); child->SetColor(1.0, 0.0, 0.0); child->SetPhysicsMode(Entity::CharacterPhysics); child->SetMass(1); Model* floor = Model::Box(); floor->SetShape(Shape::Box()); floor->SetPosition(5, 0, 0); floor->SetScale(30, 0.1, 30); floor->SetRotation(0,0,45); mousepos = window->GetMousePosition(); window->SetMousePosition(context->GetWidth() / 2, context->GetHeight() / 2); return true; } bool App::Loop() { if (window->Closed() || window->KeyDown(Key::Escape)) return false; if (window->KeyHit(Key::F3) == true) { camera->GetDebugPhysicsMode() == true ? camera->SetDebugPhysicsMode(false) : camera->SetDebugPhysicsMode(true); } if (window->KeyHit(Key::F4) == true) { camera->GetDebugEntityBoxesMode() == true ? camera->SetDebugEntityBoxesMode(false) : camera->SetDebugEntityBoxesMode(true); } if (window->KeyHit(Key::F2) == true) { if (wireframe == true) { camera->SetDrawMode(0); wireframe = false; } else { camera->SetDrawMode(2); wireframe = true; } } float cx = Math::Round(context->GetWidth() / 2); float cy = Math::Round(context->GetHeight() / 2); Vec3 mpos = window->GetMousePosition(); window->SetMousePosition(cx, cy); mpos = mpos * looksmoothing + mousepos * (1 - looksmoothing); float dx = (mpos.x - cx) * lookspeed; float dy = (mpos.y - cy) * lookspeed; Vec3 camrot = camera->GetRotation(); camrot.x += dy; camrot.y += dx; camera->SetRotation(camrot); mousepos = mpos; float _time = Time::GetSpeed(); float camspeed = 0.2f * _time; if (window->KeyDown(Key::Shift) == true) { camspeed = camspeed * 5.0f; } if (window->KeyDown(Key::W) == true) { camera->Move(0, 0, camspeed); } else if (window->KeyDown(Key::S) == true) { camera->Move(0, 0, -camspeed); } if (window->KeyDown(Key::A) == true) { camera->Move(-camspeed, 0, 0); } else if (window->KeyDown(Key::D) == true) { camera->Move(camspeed, 0, 0); } if (window->KeyDown(Key::T) == true) { camera->Move(0, camspeed, 0); } else if (window->KeyDown(Key::G) == true) { camera->Move(0, -camspeed, 0); } Leadwerks::Time::Update(); world->Update(); world->Render(); context->Sync(); return true; } TestingGrounds.zip

Are you wondering why sand boxing is disabled? I think someone said this was from the Leadwerks 2.x days and not applicable now...

Look forward to seeing these implemented.

Brilliant

Ah okay. 32 it is

Yeah I guess people can do that to the 2D textures themselves if they want too, depending on their GLSL skills. So the 18 256x256x256 RGBA textures for GI can't be packed? We won't need to access those will we?

Side question; would GI only be useful for indoor scenes?

That's a lot of textures... but for great graphics at fast speeds it'll probably be worth it. I'm not familiar with 3D textures but can you store 4 of them in one slot like what can be done with a 2D texture, and then access the appropriate one with UV coords.. or however you access 3D textures?

If you were to make a rule that GI requires 32 textures, does it drastically change what cards the engine will work on? I'm not sure how 16 can be guaranteed and not any more. Is it a memory issue? Are there other ways to store and manipulate data on the GPU that doesn't use texture slots? Like Buffer Objects or something...? Maybe you could bring it down to four to keep it within limits but have the option to use more if the end user wants too use up to 32? Maybe..

Very nice ?

Ah you mean so users can create MODS for your game. In that instance you could probably write your own publishing software, using the package system in C++. Or just upload the game in it's raw project format. Keeping in mind that all assets must be of your own making.

Yeah the numpad tied to this would be great.

The high resolution scene look awesome. Is that all from a single point light?

Encrypting assets is a good idea. If you have a purchased asset in your game, you can't just upload it unencrypted. Even if you don't mind it being used by someone else, the person who made it probably will It's more for convenience than anything else. Not having to copy over extra files and folders after clicking publish would be nice

Looking good

I was using it to load binary files that had precompiled information for various parts of my game. After adding those files into the package for publishing they couldn't load because I was using fopen_s() to load them. (Plus the filepath was now different, being in data.zip) So a published game is loading its package with register set to false..? Meaning I can't load my own extra files from data.zip using ReadFile() so I'll have to add those files after the publishing process as an extra folder or zip. Could a feature be added where we could use our own password? And if our own isn't specified then the default secret one is used. This would only be useful if it were possible then to load our own files from the package using ReadFile().

So our own zips can't be read from, but the default data.zip can with our own files?