Josh

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.

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.

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.

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

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!

Perfect, thank you. I can produce the error on my end with this scene. This will get fixed pretty soon.

Hello, and welcome. I tried to reproduce your error, but my attempt worked correctly: Is this a problem you can easily re-create? Can you upload a map file that will produce the error if I use the carve tool on one object? The forum allows ZIP file attachments.

Okay, I will pick up a comparable GPU and see what the results are. Maybe the drivers for these are doing something a little differently.

Maybe a dumb question, but have you updated your graphics drivers any time recently?

map2.map works fine in-game on my Nvidia card. What GPU do you have?

As the days grow shorter, fireplaces crackle, and winter chill fills the air, the Leadwerks community is heating things up with the return of our annual Winter Games Tournament! It’s your chance to unleash your creativity, bring your wildest ideas to life, and take part in the fun with your fellow developers. 🏆 The Challenge Create a simple, playable game using Leadwerks within the tournament timeframe. When you're done, upload your masterpiece on our website before the deadline hits! 🛠️ How to Play Build your simple playable game with Leadwerks. Submit it before January 19, 2026 (GMT). Make sure your mailing address is up-to-date in your user profile to claim your prize! 🎁 Prizes for Everyone! Rather than a competition; this tournament is a co-opetition; a collaborative challenge where everyone wins! Every participant gets a prize. (See details below.) 🎉 Tier 1 Prize: The Leadwerks Sticker Pack All new participants (up to 100) will receive this awesome swag in the mail! A sleek round Leadwerks gear icon with a blue border, approximately 2.75 inches in diameter. A gear icon sticker about 2 inches in diameter with a vibrant purple border. A rectangular decal featuring the Leadwerks logo on a stunning dark background. 🔥 Special Rewards for Returning Champions Have you participated in our previous tournaments? If yes, you’re in for a treat! Up to 20 returning champions will receive a special prize package, including: The Tier 1 Leadwerks sticker pack (x3 stickers). A luxury high-capacity Leadwerks USB drive with leather siding and a magnetic closing box, perfect for backups or transporting files between machines...with style! One mystery bonus item(!) 🚀 Ready to Join the Fun? Don’t miss out! Submit your game before the January 19, 2026 deadline! Remember, to claim your prize, update your mailing address in your user profile. If you don't have Leadwerks yet, now's a great time to grab it with a discount during the Steam WInter Sale.❄️ Let’s make this winter unforgettable with creativity, collaboration, and a whole lot of fun. We can’t wait to see what you build! The tournament starts Saturday. Good luck, and happy developing!

5.0.1 final is now on default branch, beta branch is in sync.