All Activity

Ok, that makes sense. Thanks by the detailed explanation.

For Lua, this is by design. Since Lua is dynamically typed, it's easiest to attach properties and functions directly to the entity. For parts of the code where two entities interact, this makes things very easy and straightforward: function MyGameObject:EncounterOtherObject(entity) if entity.team ~= self.team then-- other entity is on a different team than me if isnumber(entity.health) and entity.health > 0 then-- other entity is still alive --Attack the enemy! end end end Now with C++ (and potentially other languages in the future), since it is statically typed, all properties have to be declared in a separate class anyways, so there is no downside to using multiple objects to store those. In C++ the same code above would look something like this: void MyGameObject::EncounterOtherObject(shared_ptr<Entity> entity) { for (auto component : entity->components) { auto baseclass = dynamic_pointer_cast<BaseClass>(component); if (not baseclass) continue; if (baseclass->team ~= this->team)// entity is on a different team than me, probably { if (baseclass->health > 0)// entity is still alive, probably { // Attack code! break; } } } } However, if this approach were applied to Lua it would introduce two problems. First, flipping back and forth between a script object and an entity object is tedious, and it introduces a constant burden to everything you do. Due to technical limitations at the time, Leadwerks 4 had a separate script and entity object, and it was a constant burden to try to remember which functions and properties were entity functions in the engine, and which were script functions attached to the entity script table. When you can just type self.health or entity.magic it makes life much easier, and aligns better with the design of the Lua language. The alternative is to force the user to declare a for loop every time they want to access a value on another entity or call a function. It makes the interactions between objects very tedious to code. Second, this introduces ambiguity into the system. What is an entity's health value? You can loop through all the components until you find a class that has that value as part of it, and return the first one you encounter. What if two attached objects have two different values? The entity will be treated in unexpected ways by other entities, and if you debug just that class you won't know why, unless you filter through all the possible other entities. Game debugging is complicated, and I think adding more complication to something that is already complicated should be avoided. We allow multiple attached objects with C++ because the static typing of C++ prevents us from doing things the Lua way anyways, but in my own game I am developing, we have a strict rule of one object per entity, so that we can simplify our code like so: void MyGameObject::EncounterOtherObject(shared_ptr<Entity> entity) { auto baseclass = dynamic_pointer_cast<BaseClass>(entity->actor);// value is equal to component[0] if it exists, or NULL if it does not if (not baseclass) return; if (baseclass->team ~= this->team)// entity is definitely on a different team than me { if (baseclass->health > 0)// entity is definitely still alive { // Attack code! } } } That way I don't have to guess which attached object is triggering some behavior, I just look at the actor, and I know all my properties and functions are stored there. To make everything accessible without casting to different classes, I just declare all members and functions in a single base class that get accessed across different entities in the base class, and all my game classes are derived from that. C++ programmers can still do things the way the second example here shows, but for my own games I prefer the last example.

I'm going to be crazy with the ragdoll What is the correct way to copy the collider rotation and position to a bone? At the moment, I have a functional ragdoll, but only some bones doesn't work as expected and I don't know why Video showing the error: Thi's part of code where I transfer the position and rotation: for _, name in ipairs(updateOrder) do local data = self.rigidBodies[name] local bd = self.bones[name] if data and data.marker and bd and bd.bone then local markerWorldPos = data.marker:GetPosition(true) self.transformHelper:SetPosition(markerWorldPos, true) local skeletonPos = self.transformHelper:GetPosition(false) bd.bone:SetPosition(skeletonPos, true) local worldRot = data.marker: GetQuaternion(true) local localRot = TransformRotation(worldRot, nil, model) bd.bone: SetRotation(localRot:ToEuler(), true) end end

That mean I must do all the code for an entity in the same script?

The shadows when using the directional light in VR is broken. Create a VR project and attach the VRPlayer script to an entity on a simple map and you'll notice it. May have broken when this was fixed.

Line 261 under the Load function, apply this fix. self.camera:SetRotation(0, self.rotation.y, 0)

The First Person Template is what you're looking for.

Hi Luke, The original game has some problems at different resolutions because it was made using DirectX 7. The best solution would be if we are able to totally rewrite the rendering code using OpenGL.

i have a 2560x1440 resolution screen and i tried to click on 2560x1440 but it says "unable to create 3d scene" dont know if this is something with my computer but i dont think it is

Thanks. Talking about demos, is there a simple demo game in c++, to see all in action? I'm reading the documentation and making small programas to understad de engine, but a simple game would be very helpfull.

Hello everyone! I am officially joining the Leadwerks Winter Games 2025 Tournament with my project: Ingenuity Legacy. This game will be a tribute to the historic adventure of the helicopter on Mars. My goal is to capture the feeling of solitude and the technological achievement of Ingenuity on the surface of the Red Planet. Tech Specs & Tools For this tournament, I decided to go with a transparent and classic approach: Engine: Leadwerks 5. Language: Lua Script. Dev Environment: I will use the Leadwerks Map Editor for level design and Visual Studio Code for all scripting. Methodology: The project starts from scratch. I am beginning with a completely blank code file—no pre-made templates—to build the flight mechanics step-by-step. Resources: I will be using assets available from the internet for the art and environment, and I will use AI assistance to support the coding process when necessary to speed things up. Follow the Development Live I want to share the creation process with you all, from the very first line of code to the final build. I will be streaming my development sessions live on Twitch. "Spin up, take off, climb, hover, descent, landing, touchdown and spin down." Ingenuity Legacy | Leadwerks Winter Games 2025 🚁 "Altimeter data confirmed."

Create a tile from an image file: https://www.leadwerks.com/learn/LoadTile?lang=lua Center the handle: https://www.leadwerks.com/learn/Tile_MidHandle?lang=lua Then position it at half the screen resolution: https://www.leadwerks.com/learn/2dgraphics?lang=lua

The way the entity script system works is by adding all the fields and functions the table has onto the entity, when the script is assigned. You can declare a field on the table at the top of the script like this: MyScript = {} MyScript.data = {} MyScript.data will be the same table for every entity that uses the script. You can also add fields in the entity Start function: function MyScript:Start() self.data = {} end In this case, the data field will be a different table for each entity that uses this script, because each entity is calling the Start function and having a different table created and assigned to just that one entity.

There is no required theme for this event. Many people make Christmas or Winter-themed games. Snowmen, present hunts, Christmas trees, that kind of thing. But it's not required.

@Josh, what is the game theme?

I pulled these from our repo for the First-Person Demo project which was a git repo. I recommend you use SVN over git as git-lfs can get messy, but I understand that may not be an option for most people. .gitignore # This .gitignore is optimized for Leadwerks 5 Projects and is intended to be copied and modified to fit the needs of the project of it's apart of. # Visual Studio Intermediate Files .vs/** x64/** *.exp *.pdb *.BuildCppClean.log **.recipe **.FileListAbsolute.txt *.ilk *.log *.tlog *.idb *.vcxproj.user # Backup folder: Backup/** # Compressed backups: *.zip *.pak *.7z *.rar *.tar.gz # Ignore GLTF #*.gltf #*.bin # Ignore Exes *.exe # Ignore meta files **.meta # Useful for preventing test assets being pushed **/NoCommit/** **/nocommit/** .gitattributes *.bat eol=crlf *.sh eol=lf *.sln text eol=crlf *.vcxproj text eol=crlf *.vcxproj.filters text eol=crlf .gitattributes text .gitignore text *.basis binary *.bin binary *.collider binary *.dds binary *.tex binary *.ico binary *.wav binary *.mp3 binary *.ogg binary *.map binary *.mdl binary *.phys binary *.tex binary # git-lfs *.exe binary filter=lfs diff=lfs merge=lfs -text *.lib binary filter=lfs diff=lfs merge=lfs -text

I want that .gitignore file too... And it would be great if it were created with the project.

What's the better (efficient) way to add a crosshair in the middle of the screen?

Forget it, seem I have a mess with the variables scope

Hi, I was create an enemy entity, attached a script (component?), then duplicate that enemy several times. How to access a variable of only one entity from another script? Now, I use a raycast to get the target entity and access the variable like that: myentity.myvariable but that variable changes on another entity, no the one I want to.

I will try to rebuild the level inside Leadwerks, at least walls, floors ceilings and some structures. I wonder how the level will look like when it is build through its internal tools :-D

@reepblue might have something to say about this...

Would anyone be willing to share a generic .gitignore for Leadwerks 5 C++ projects?

Thanks for the info. Please let me know if this comes up again!

I will post another response when it is solved. This is my system for tracking bugs, so it's best to keep it unsolved until I am finished. Thanks for reporting this!