Josh

I meant that was something for me to do, but the answer to your question is here: https://github.com/Regalis11/scpcb

Do you mean the text size? The side panel is resizable.

Got my Vive set up again, and everything is currently charging. It always amazes me how reliably this moderatly complicated setup works.

5.0.2 beta Added View > Show Terrain menu item and associated functionality.

I love these types of threads. They make life exciting!

I don't know anything about Adrenaline software. It's easy to select your card in that dialog and download the correct drivers for your card.

Card is a AMD Radeon RX 6700 XT. I have a 6600, not much different. I think your drivers are probably not installed correctly? You can get the correct graphics driver for your card here: https://www.amd.com/en/support/download/drivers.html

That is true, it has been "deprecated" for years...yet it still works.

I will make this "unsolved" since the original issue is not fixed, but I am glad we found something that works for you.

When you run from the editor, it includes the map file in the command line. If no map file is specific, the game starts in the default menu. I would need to see your project in order to tell what is happening.

Does the game work if you just double-click the executable?

Thank you. This sounds like a possible bug I need to investigate in more detail.

I created a new blank project, installed the Lua Debugger by dev-cat, ran the project, and this is the result:

Try adjusting the tile order with this command: https://www.leadwerks.com/learn/Tile_SetOrder

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.