ECS vs. Dynamic Typing for Lua

[Pleca]

Please, let’s keep both approaches. For example, in a dungeon filled with many torches, I’d use ECS for efficiency, while for a few unique objects, I’d prefer the OOP approach for simplicity. I’m with reepblue on this one.

[Alienhead]

I'm on a plane currently and won't go into detail, but a one script system totally deprives the ability for add-ons and extensions.  Example, my player control is a solo component,  if I want to add the ability for a shotgun weapon I simply add the shotgun component to the player and he can use that ability.  I can further add more abilities to the player by assigning additional components. 

 

[Alienhead]

How is that well known engines such as Unity and others have worked around the issue you present and still allow multiple components??

[Josh]

13 hours ago, Dreikblack said:

So please do it?

Are you sure this is needed? In the last build I got rid of all virtual inheritance because it does not appear to be needed for anything, and I think you said there was no problem in your previous post.

Regarding components, one possible solution might be for the editor to detect base components and display them as if they were separate components. Here is an example of a base component and another component derived from that:

class MyBaseComponent : public Component
{
    Vec4 lower;//"Min color" COLOR
    Vec4 upper;//"Max color" COLOR
  
    void Update()
    {
      	Vec4 color;
      	color.r = Random(lower.r, upper.r);
      	color.g = Random(lower.g, upper.g);
      	color.b = Random(lower.b, upper.b);
      	color.a = Random(lower.a, upper.a);
      	GetEntity()->SetColor(color);
    }
};

class MyDerivedComponent : public MyBaseComponent
{
    Vec3 speed;//"Speed"
  
    void Update()
    {
      	GetEntity()->Turn(speed);
      	MyBaseComponent::Update();
    }
};

When you add MyDerivedComponent to an entity, tabs for MyDerivedComponent and MyBaseComponent would appear, with properties displayed in each one, as if they were two different components.

The differences would be:

• You would not be mixing and matching different components in the editor. Combination of different components would be achieved by declaring a class that inherits another.
• You can't have two properties or methods with the same name, since they would overwrite each other, since they are on one object.

This might solve several problems:

• This would retain visual separation of properties and flowgraph subobjects in the editor.
• This would retain separation of code in different files.
• Problems involving the order different component methods are executed in would go away.
• The component would just be a single object to access in code.

[Dreikblack]

14 minutes ago, Josh said:

I think you said there was no problem in your previous post.

Because i forgot to make it Object's child. As() and Self() are pretty useful. And then i would able to pass it as Object in LW5 API methods. Also i thought it would needed to GetComponent() but gladly this one works for any class. 

[Josh]

Just now, Dreikblack said:

Because i forgot to make it Object's child. As() and Self() are pretty useful. And then i would able to pass it as Object in LW5 API methods. Also i thought it would needed to GetComponent() but gladly this one works for any class. 

Okay, if you find that useful, I don't have any objection to doing this in the next build.

[Dreikblack]

51 minutes ago, Josh said:

You would not be mixing and matching different components in the editor. Combination of different components would be achieved by declaring a class that inherits another.

It's not an option at all for cases when you need different components for same entity.

53 minutes ago, Josh said:

This would retain separation of code in different files.

And again it will not since you don't do deriving for totally different components and sane persons will not hundreds derive combinations when they can do dozen components for everything already with proper system which you want to destroy without any single good reason to do so.

55 minutes ago, Josh said:

• Problems involving the order different component methods are executed in would go away.
• The component would just be a single object to access in code.

Just use single component per entity without making to so it everyone else, you can do it already. Don't break what already works millions time better than you want to do. Stop ignoring GetComponent() method existence for making excuses.

[Alienhead]

It seems like Josh's mind was made up before starting this thread anyways.  Before I waste anymore time I would like to know if you plan on going through with this new system so that I may start my search for an alternate product.

[beo6]

Why remove the option to create reusable components?
This sounds like you want to get rid of this to force people to always reimplement everything to fit their needs for no reason.

I think it worked perfectly fine for Leadwerks 4.

After some thought through standards where established, many components where made in a way to be compatible. Like the 1st person script.

Quite a few used my "Amnesia" - like notes script (i think). And it allowed some people to quickly put together some games.

 

[Dreikblack]

@Joshyou keep ignoring any criticism on this topic, but i will try again.
Multi-components allow:

• To keep logic components in one place. Even if components without entities will appear (meanwhile you want to do opposite...) there is still a lot of examples like thunder - point light with components that: 1. Make light appear and with-time reduce brightness. 2. Do sound. 3. Trigger 1 and 2 on random time. All 3 components are used in a lot other cases.
• Entity and component being different classes in good thing - no overriding for same names, no extra bull**** when you looking for something with autocomplete. Also component may exist without entity and i use it (by creating with own method).
• Mix behavior and avoid tech debt aka duplicated code in this case. Some of real examples beside above: 

1. Brush entity with: Tile trigger (when unit enters in trigger) which trigger dialog component (to text for player) and also trigger Objective trigger (to make objective about finding this door complete), usable trigger - context button to open door. All of at same entity and would be longer to make with worse result if we had no multi-comp system.
2. Padlock on door  (brush with lock texture): UsableObject component - for highlighting this entity and trigger usable trigger from above by picking. Second component is RemoveObject - for removing this lock when door is open.
3. Animated model: on signal it's start moving with Way Mover component and start animation with another component. And i would also use third component to remove entity from scene in next game, but currently it's in WayMover.
4. Similar combo for weapons on table + they have QuakeModel component for fixing their model.
5. Tile trigger, dilaog + SoundEffect to make sound when unit enters this trigger.
6.  Button entity: Trigger on damage component + WayMover to make move this entity on trigger.
7. Pillar with WayMover and EnvLevel component - to hide entity when it's too close to camera
8. Acid brush - Acid component + WayMover.

In result with enough components you can make a levels without coding just by combing components.

Made up by you cons:

Quote

With mulitple components, you have to know exactly what component you are looking for.

With single one it's exactly same, even if you screw it up by mixing with entity - you NEED to know what component entity have to do anything with that. You can't do entity->health = 0 in both Lua and C++ because Component don't have and you cast it in C++ anyway (and it's easy to do currently - just use GetComponent() and in lua it will be an error if table (component) don't have it.

For C++ you also can cast not to even base Class, but interface class if needed.

By the way in reality you never have cases when entity have few component with same method which you want to call. Like why the hell same entity would have two different health or use()? You just do GetComponent<Interface> or GetComponent<SomeBaseComponent>(), call once whatever you want and thats it.

And in Lua you use single component which have function for sure you just do in Lua without loop and knowing which exactly component is that:

entity.components[1]:Use()

In result nothing will be changed in that matter and problem simply does not exist.

If anything, tag system for components would be helpful for Lua to determinate if abstract component have variable and functions quickly. Something like:
local components = entity:GetComponentsByTag("Health")

Quote

One script, one entity

Why it's would be bad already described in Multi-comps pros. You are too lazy to write GetEntity() it's your personal problem.

Quote

ECS totally throws that away and makes things far less modular and reusable.

Sorry, but it's literally random bull**** of yours and i explained above how it's opposite, meanwhile new approach would break everything and make people do same stuff all over again in same scripts/components without ability to combine functionality. If you can't make combinable components it's only your own skill issue. And most likely reason why FPSPlayer and footstep components are not work together (which could be non true after another your false accusations) is how messy FPSPlayer component is - it's have too much stuff that have to be in different components. And you want all components be that bad...

Quote

downside of multiple components is never knowing what type of object an entity really is supposed to be.

Aaaaaaaaaaand nothing would be changed for single component. In most cases entity type does not matter and when it does you just use specific component for specific entity type. And ofc. it's easy to check entity type via casting if you need.

Again nothing would be changed in that matter and problem simply does not exist.

Quote

Any time you call a method, set a value, or get a value from another entity, a for loop is required. This is tedious and makes me want to avoid entity interactions, unless I absolutely have to do something.

Entity interactions get very complicated and ambiguous

Retrieving a value from another entity involves a lot of code and is ambiguous.

Another example of made up issues because @Joshignores Entity::GetComponent() existence.

 

Short conclusion:

Mono-component gives no benefits at all and hurts everything that multi-components system gives, and would do big damage for both novices and experience engine by removing ability to make and combine simple and clear components, beside confusing people by combing entity and component scopes.

[Alienhead]

I would like to officially withdraw my opinion on this subject,  I do not wish my opinion to have any sway on the outcome due to the fact I have thought long and hard on this matter and decided to move on to a different product.  I bid you all a fond farewell, I've had some fun years here!

[AnthonyPython]

I agree completely with dreik and reep on this matter, seems to be completely a none issue, I prefer making specialized components like a health or armor component etc, so more multi-component less than mono, instead of always doing it as a mono-component. But I do like to do it some times as a mono component from time to time so I do a mix of both.
I think this is more a developers preference of how they want to approach something more than an actual issue.
If ya want to do mono component tutorials that is fine, but do not try to force a very specific methodology with such a late change idea onto current developers.
It would be different if this was the path you wanted to do from the start, and no one would be bothered about it but that isn't the case. Especially when as reep pointed out is too close to 1.0 release.
So yea a complete none-issue.

[Josh]

23 hours ago, AnthonyPython said:

I prefer making specialized components like a health or armor component etc, so more multi-component less than mono

Have you written such a system? I had a lot of trouble when I tried to do this. (The video will start at the right time.) This describes why I made the FPSPlayer a single script. 

The other issue I see is the interaction of objects. Let's say we have a function that lets a turret choose which object it wants to target. I want to find the nearest object that has a team value defined that is different from the turret's team value:

function Turret:ChooseNewTarget()
	self.target = nil
	local mindistance = self.range
	local entities = self.entity.world:GetEntitiesInArea(self.entity.position - self.range, self.entity.position + self.range)
	for n = 1, #entities do
		if entities[n] ~= self.entity then
			local dist = self.entity:GetDistance(entities[n])
			if dist < mindistance then
				for name, component in pairs(entities[n].components) do
					if isnumber(component.team) and component.team ~= self.team then
						self.target = entities[n]
						mindistance = dist
						break
					end
				end
			end
		end
	end
end

I think most people will struggle with the inner loop through the components, Even if they understand it while they are listening to me explain it in a video, and looking at code I already wrote, I don't think they will remember how to make use of it. If they do remember, I think it will slow them down dramatically and make game interactions tedious to write. This is a lot of extra overhead just to access a variable. For many people, I think this will effectively make Leadwerks script code "read-only" since they will be unable to write new code with the system:

for name, component in pairs(entities[n].components) do

end

You also have the problem of "which value is the real value"? What if one of their scripts sets the team property to nil, but they keep getting attacked? That kind of stuff is very difficult to track down.

The alternative I am proposing removes the need for the inner loop, because the properties are just attached directly to the entity object.

function Turret:ChooseNewTarget()
	local mindistance = self.range
	local entities = self.world:GetEntitiesInArea(self.position - self.range, self.position + self.range)
	self.target = nil
	for n = 1, #entities do
		if entities[n] ~= self then
			local dist = self:GetDistance(entities[n])
			if dist < mindistance then
				if isnumber(entities[n].team) and entities[n].team ~= self.team then
					self.target = entities[n]
					mindistance = dist
				end
			end
		end
	end
end

I think the problems of the current design are significant enough to cause perhaps a 70% dropout rate when these tutorials are viewed, whereas the proposed design will have maybe a 20% dropout rate. That's jsut a guess based on my intuition, but I think it is roughly correct.

It seems like a lot of the perceived benefit of multi-components is that if you just had a set of modular gameplay components, you could construct a game just by adding components and setting properties. I have been asking for a year and a half, what are these abstract gameplay components? No one has answered me. I installed unity to find out what they did, but it turns out Leadwerks includes more stock scripts than unity. So who is going to create these modular components that allow every game to be made? I have no idea how to do this. No one can even tell me what they should even be.

Lua is the only language that allows us to just do the thing that is most intuitive to most people. It seems very strange to get rid of this simple design that everyone can understand, in favor of something that seems very complicated and difficult to use.

box = CreateBox(world)
box.health = 100

 

[beo6]

i just watched the video and now i better understand where the idea of josh comes from. But i still think the proposed solution is wrong.

As mentioned, it will remove versatility of components. Now you end up having to write a very specific component for each type.

Take the example from the video and the HealthManager component:

- Since you can't seperate it anymore you would end up with a HealthManagement part in the Monster, Player, Damagable Objects and so on. Its not very reusable. And if you change one thing, you would have to change it in each and any script.

- About the issue with the calling order:
Yes its hard to explain and would probably trick me over (however i was right of the bat able to tell why it happens. No idea why it took a week for josh)

Also another thing in the examples are bad in my opinion is to check for function names. If someone adds a component with a function with the same name, and even worse if that function has a different type or amount of arguments, it will crash.

So my proposal:

Add a way to use dependencies between components. This is pretty default to understand for any programmer and should be easy to explain.
I haven't programmed with LUA for some time so i don't know if its possible, but maybe you can do some kind of inheritence, so you could have your FPS player extend from the HealthManager. Or maybe like interfaces in other languages.

If thats not possible, i guess what could work is defining what component needs another component to be called first. That way you give the responsibility of dependencies to the components and the user who is just consuming components does not have to care about this design detail.

Or if its possible: Have some kind of event system. So the actual calling of component functions really only happens if all components and its functions are there.
Maybe a

entity.components.HealthManager:CallFunction('AddDamage', self.damage)

call could do the actual call once its sure also the FPSPlayer component (and any other component) is there.
Of course if its possible to hide this design detail and still use regular `entity.components.HealthManager:AddDamage(self.damage)` that would be even better.


These are just some really quick ideas around the issue without removing multiple components.

[AnthonyPython]

16 hours ago, beo6 said:

I haven't programmed with LUA for some time so i don't know if its possible, but maybe you can do some kind of inheritence

you can, with the metatable you can do a OOP like thing but it's not like C# or C++ classes but a metatable can be treated similar to of those.

 

17 hours ago, Josh said:

Have you written such a system?

I have before yes, with a global event table to dispatch Function calls and such with out having to do it directly between each other.(such as beo6 is suggesting)

 

17 hours ago, Josh said:

It seems like a lot of the perceived benefit of multi-components is that if you just had a set of modular gameplay components, you could construct a game just by adding components and setting properties. I have been asking for a year and a half, what are these abstract gameplay components? No one has answered me.

which is a misconception I've never seen any one express, the only one's that do this are the plug & play sort of system you are describing, where they already have all the logic set up and created to work in such that way. which is far and few between since it can be very limiting since it just depends how far people are willing to even make them to begin with. 

unity is incredibly bare bones in a default project. In Unity or other C# component systems you can just directly execute a components function with only a couple lines (GetComponent) and easily check to see if a component exist.(you can also require a component and it will automatically be added to said entity with the script default values) I use this a lot in a helicopter game in S&box C# same deal there.
A way to get entities in unity in a scene, this I specifically look for a component in a child but the same can be done in a parent.

Now I didn't do a radius check like you did because that's not built in unity unless you use colliders as far as I know, you have to make a function for that your self.

using System.Collections.Generic;
using UnityEngine;
using UnityEngine.SceneManagement;


List<GameObject> buffer;
var roots = scene.GetRootGameObjects(buffer);
for (int r = 0; r < roots.Length; r++)
{
  var childtransforms = roots[r].GetComponentsInChildren<Transform>(true); // true means include inactive ones as well
  for (int t = 0; t < childtransforms.Length; t++)
    Debug.Log( "childpos : " + transforms[t].localPosition);
}

This a common way to check for entities using a collider of some kind with a simple physics Query for a large amount of unity users and to execute said function.

using UnityEngine;

public class RadiusCheckExample : MonoBehaviour
{
    public float detectionRadius = 10f;
    public Vector3 centerPoint; // Assign in the Inspector or set dynamically

    void Update()
    {
        FindAndExecuteOnScripts();
    }

    void FindAndExecuteOnScripts()
    {
        Collider[] hitColliders = Physics.OverlapSphere(centerPoint, detectionRadius);

        foreach (Collider hitCollider in hitColliders)
        {
            // Try to get the specific script component
            MySpecificScript script = hitCollider.GetComponent<MySpecificScript>();

            // If the script is found, execute its function
            if (script != null)
            {
                script.PerformAction(); // 'PerformAction' is a public function within MySpecificScript
            }
        }
    }

}

This is a new method added into unity to replace the outdated Object.FindObjectsOfType<>() for entities

public class ScriptExample : MonoBehaviour
{
    private const int count = 10;

    void Start()
    {
        var gameObjects = new GameObject[count];
        var expectedTextMeshObjects = new TextMesh[count];
        var expectedCanvasObjects = new CanvasRenderer[count];

        for (var i = 0; i < count; ++i)
        {
            gameObjects[i] = new GameObject();
            expectedTextMeshObjects[i] = gameObjects[i].AddComponent<TextMesh>();
            expectedCanvasObjects[i] = gameObjects[i].AddComponent<CanvasRenderer>();
        }
    }

    void Update()
    {
        if (Input.GetKeyDown(KeyCode.Space))
        {
            var foundCanvasObjects = FindObjectsByType<CanvasRenderer>(FindObjectsSortMode.None);
            var foundTextMeshObjects = FindObjectsByType(typeof(TextMesh), FindObjectsSortMode.None);
            Debug.Log(foundCanvasObjects + " : " + foundCanvasObjects.Length);
            Debug.Log(foundTextMeshObjects + " : " + foundTextMeshObjects.Length);
        }
    }
}

 

17 hours ago, Josh said:

I think most people will struggle with the inner loop through the components, Even if they understand it while they are listening to me explain it in a video, and looking at code I already wrote, I don't think they will remember how to make use of it. If they do remember, I think it will slow them down dramatically and make game interactions tedious to write. This is a lot of extra overhead just to access a variable. For many people, I think this will effectively make Leadwerks script code "read-only" since they will be unable to write new code with the system

you can always add one or more kind of helper function to reduce this instead of moving stuff directly to a entities table, this isn't that bad really, but it could use a helper function or two in order to alleviate this specific scenario.

GetEntitiesInArea followed by a loop of the entities to get only that one specific component from a returned array of a specific type wanted as you can do with unity. I don't think moving them to the entity table would a good idea because then what would the point of it being when each component is suppose to hold themselves each independent of each other so that you don't have to keep writing redundant code that is the point of components it's not meant to be a plug & play system(apparently from the misconception) unless it is designed from the start to be that way. I mean that would defeat the purpose.

17 hours ago, Josh said:

You also have the problem of "which value is the real value"? What if one of their scripts sets the team property to nil, but they keep getting attacked? That kind of stuff is very difficult to track down.

Now that I thought about it seems the problem here is more so of asking who is your market audience?, are you trying to target only no code people?, you can't possibly do everything for people.
I know you want to try to simplify things to make it easier for people to get into it. but the problem is people just need time to learn and you can't force people to do that. programming scares people off already, are you trying to make it more appealing for that group of customers. Making it single component sure would simplify it for people to get into it but then it just be no different than programming in source engine or quake or any other older style engine. I do think you are confusing your target audience some here.

If for some reason we need to compromise with this new direction you are wanting, you might need to pull a unreal here, and just keep the current multi-component usage but add support to allow the older quake Entity style if this is something you rather desire because as it stands no one here wants to prevent multiple component usage. Again this is more of developers preference to how they want to organize and build their game and you shouldn't remove that.

ECS and Entity Methodology both have their own pros and cons, but in my opinion a EC has much more pro's compared to Entity based.

Components: easier to extend and change, easier to reduce and reuse, very easy deploying the DRY method naturally(if you are making small components),you can decide what should be-available on said entity (with out extra fluff). better organization (at least to me anyways), Data-Oriented Con's: steeper learning curve. 

Entity only based  pro's: All in one place, easier to drop n and be done. Con's: Requires blob files/component, super specialized Entities. harder to extend, higher chance of duplicate code, legacy method prone to easily become a mess. Potentially harder to hunt down bugs. a 200 line small component compared to a blob that is like 5k lines, will always be harder to read and debug(no matter the language used).

Both are completely fine and valid ways but it's up to the developer which way they want. if you are old school and like it, do the old school method, if you want Components use them.

 

[Josh]

The Entity / Actor system in Leadwerks 4 was really just a single component. There's probably no harm in just leaving the C++ multiple component system as-is, as long as I modify my example scenes so they just use a single class per entity, in order for the scene to work with all programming languages.

However, the Lua API can be greatly simplified if we store properties in the entity itself, instead of storing them in a series of sub-objects. Getting and setting properties, calling functions, and debugging are much more intuitive this way, especially for new programmers. This is how I wanted Leadwerks 4 to work, but technical limitations at the time prevented this.

[Josh]

On 8/13/2025 at 10:18 PM, Pleca said:

in a dungeon filled with many torches, I’d use ECS for efficiency

How would ECS make torches more efficient?

[Dreikblack]

30 minutes ago, Josh said:

There's probably no harm in just leaving the C++ multiple component system as-is, as long as I modify my example scenes so they just use a single class per entity, in order for the scene to work with all programming languages.

Would the Editor keep working as it is in terms of multi components?

30 minutes ago, Josh said:

Getting and setting properties, calling functions, and debugging are much more intuitive this way, especially for new programmers.

But it's not. It's already annoying to debug lua and having all variables and functions in single table will make so much worse...

I wish Pivot was base class for Entity or something, because it's so much overloaded with stuff that makes me using search function every time when i debug entity in C++, but probably parent system would not allow it to rid of stuff that does not make sense for pivots for example. At least m_vars could be removed, but whatever.

Just found out Unity solved this problem by putting different stuff as Transform and Mesh to different components.

[Josh]

9 minutes ago, Dreikblack said:

But it's not. It's already annoying to debug lua and having all variables and functions in single table will make so much worse...

It may be that you're just not the intended audience for the Lua API. Usually I can come up with solutions that satisfy the power users and the beginners, but it's probably inevitable that eventually there will be some conflict where it is impossible to make everyone happy.

9 minutes ago, Dreikblack said:

I wish Pivot was base class for Entity or something, because it's so much overloaded with stuff that makes me using search function every time when i debug entity in C++, but probably parent system would not allow it to rid of stuff that does not make sense for pivots for example. At least m_vars could be removed, but whatever.

I don't understand this. What effect would this have?

[reepblue]

30 minutes ago, Josh said:

The Entity / Actor system in Leadwerks 4 was really just a single component. There's probably no harm in just leaving the C++ multiple component system as-is, as long as I modify my example scenes so they just use a single class per entity, in order for the scene to work with all programming languages.

However, the Lua API can be greatly simplified if we store properties in the entity itself, instead of storing them in a series of sub-objects. Getting and setting properties, calling functions, and debugging are much more intuitive this way, especially for new programmers. This is how I wanted Leadwerks 4 to work, but technical limitations at the time prevented this.

This might be considered as "fragmentation of the user base" but why don't you keep the component system as a pro-feature? From these conversations and borderline arguments, what I'm seeing is that you want the scripting system to be simple to teach and explain, but most people defending the component system are C++ users who seemed to be doing fine with the examples and documentation (or lack thereof) for the past few years. These customers tend to do things their way anyway and don't like they are being told they are using the engine wrong. You seem to get a lot of push back on this thread due to the fact that the Pro version has been the popular choice over the standard edition. Even though I expect that to even out or change once the full release goes out, the Pro version is something special and the people who use it aren't afraid of burning themselves due to their own bad decisions. 

[Dreikblack]

8 minutes ago, Josh said:

It may be that you're just not the intended audience for the Lua API. Usually I can come up with solutions that satisfy the power users and the beginners, but it's probably inevitable that eventually there will be some conflict where it is impossible to make everyone happy.

Currently this is how debug looks:

At least lua have less vars exposed, but VS Code don't have search var function and putting everything in same table only make it worse to debug for everyone, including beginners.

Tried IDE in the Editor, does not look much better:

[Josh]

3 minutes ago, Dreikblack said:

Currently this is how debug looks:

At least lua have less vars exposed, but VS Code don't have search var function and putting everything in same table only make it worse to debug for everyone, including beginners.

Tried IDE in the Editor, does not look much better:

In Lua, I have the ability to control what values are displayed, and can expose as much or as little as people find useful.

The integrated script editor replaces VSCode and gives me a lot more control over the user experience.

[Dreikblack]

Just now, Josh said:

The debugger is supposed to show you the values an entity has. It is performing its intended function. What else would it be doing here? I have the ability in Lua to show as much or as little detail as people find useful.

If entity and component will be same table it will be too much stuff in same place and extra time every time when you quickly check what values component have.

19 minutes ago, Josh said:

I don't understand this. What effect would this have?

Less stuff in debug and for auto-complete (which is even worse for Widget class). And probably it affects memory usage too. Currently i can't see even half of vars for pivot at 2K screen:

[Dreikblack]

9 minutes ago, reepblue said:

don't like they are being told they are using the engine wrong.

Somehow it was Josh who used components wrong XD

[Josh]

You are mixing VSCode, Visual Studio, and the integrated script editor up in the same discussion.

1. I just said C++ probably wouldn't gain anything by eliminating multiple components, and it's probably fine to leave that system as-is.

2. VSCode has been replaced by the integrated script editor.

3. I have control over what properties are exposed by the Lua debugger.