PC Gaming

Absolutely!

yeah except libertarians love kings and masters, they just want it to be private and not collective. because they think they're going to be kings and masters in such a society. and it's always the most miserable looking dweeb because that's usually the motivation behind the fantasy.

"order of magnitude" typically means 10x.

Correct!

A reasonable Lua implementation of rigidbody physics isn't going to be 10+ times slower than an equivalent C++ version...

So, here's where you make me go find some actual benchmarks, because you obviously have no clue what you are talking about, and have likely never written any serious code in your life.

https://programming-language-benchmarks.vercel.app/lua-vs-cpp

Take a look at the nbody benchmark scores. nbody is a simulation of Newtonian physics for a 3d point cloud of n number of objects.

When n is 500,000, standard Lua takes about 1145 ms, LuaJIT takes about 75ms, C++ takes about 20ms. to 35ms.

So thats in your two orders of magnitude ballpark range.

When n is 5,000,000, standard Lua just crashes, C++ evaluates it in about 160ms to about 315ms, LuaJIT takes about 715 ms.

So thats uh... infinitely worse? Standard Lua can't even do it.

...

Or take a look at the spectral-norm benchmarks, which show how performant a language is at manipulating matrices and vectors... the kind of calculation core to a 3d physics simulation.

Base Lua can't even complete any of the inidcated benchmarks at all. Times out, crashes, for each given n benchmark.

LuaJIT ends up being about one order of magnitude slower than various C++ compilers.

So these show you Lua doesn't scale well and crashes, because Lua is far less efficient with memory usage than C++ (or C, through LuaJIT)... when it comes to trying to perform the kind of calculations that would need to be performed in a 3d physics engine.

...

To be clear, I'm not saying Lua is faster or as fast as C++, just that you're making it sound as if Lua is too slow for something like this.

I am saying that standard, non LuaJIT Lua is indeed too slow for this, because that is true.

meaning you cannot handle lots of objects, you can only handle a few, and only with a few players if this is all networked… otherwise you get massive physics calculation innacuracy, terrible performance spikes, crashes, and if networked, server hangs/stalls, huge desync, etc.

None of this is true.

All of that is infact true.

I know this, because I have tried it, I've done it.

Lua is too slow, and all of those things I mentioned are indeed what happen if you try to implement 3d physics entirely within it, instead of using a game's actual, native, almost always C++ physics engine.

...

... than just actually having direct access to them… but that would be the case with any language ...

It is specifically a problem with embeddable languages like Lua because they're limited by what is exposed to its VM and how. In the context of modding physics into Morrowind, it's possible that not everything you'd need is cleanly exposed through Lua (which afaik is implemented with a third party plugin and not natively supported).

You don't seem to get what I am saying.

If it is the case that your scripting language, whatever scripting language there exists a plugin for, for whatever game... if that scripting language doesn't have an API method of referencing or manipulating an actual collision mesh or hull... then that doesn't have anything to do with that particular language itself, it means the API is insufficient, the method of communicating between the game's core library and the added in language is insufficient.

What I am saying is, is that this isn't specifically a problem with whatever language you are writing your modifications in.

It is a problem with the API, the injection and interaction system/method/layer.

Thus, the problem you are pointing out as specific to Lua in this instance... isn't even a problem with Lua per se. It would be a problem with any language that is using that particular interaction method.

...

You could compile a .dll that overrides or injects into or otherwise manipulates or interacts with the core game code itself, and then also possibly provide a custom .exe that uses the custom .dlls and the base game .dlls and other files.

This is what many ENB Shader mods do (complex lighting is a different kind of physics calculation), its what Skyrim Script Extender, New Vegas Script Extender do.

Those kinds of mods represent basically a better, more thorough or more powerful API, roughly, as compared to your theoretical example... because they directly manipulate the core game code, have access to more of the core game's function libraries.

NVSE can do things like manipulate the world's gravity, manipulate friction values between different classes of physics objects, manipulate how ragdoll tensor and flexor limits operate, etc.

It can and does directly manipulate the core game physics code.

...

Also I am.... fairly confident that embeddeding a scripting language into a game that doesn't normally support said scripting language... I don't see how or why a VM would be involved in that at any point... unless you're talking about the entire modded game being run in a VM?

I don't know why you would need an entire virtual machine, a virtualized entire operating system... to add Lua into a game. That makes no sense.

...

At the risk of sounding like a dick, I think you're bullshitting. I doubt you've ever seen any physics engine implemented in Lua before...

Nope, I am not bullshitting.

I have never seen or even heard or a 3d, rigid body physics system that is performant enough to run in a 3d game, that just runs in standard Lua, that doesn't pass it to C as LuaJIT does.

There are many games that have their physics engine done in another language... usually C++... which expose an API that parses Lua, such that custom scripts or mods can be written for that game... but that doesn't mean the physics engine of the game itself is somehow now written in Lua, it just means you are using Lua to instantiate and perhaps provide basic initial position, rotation and velocity vectors to an ingame object... and then the physics calculations are handled by C++.

I asked you to provide an example of an actual 3d physics engine running in Lua, because I am calling bullshit on you.

I have never heard of one, I don't know of one that exists, yet you just confidently claim 'oh actually this is totally possible and would be comparably performant!'

You... seem to admit you are bullshitting with these statements:

Lua physics engines certainly exist, but they're mostly gimmicks interesting to developers to study/learn as there aren't many real world use cases for something like that.

Yes, 3d Lua physics examples do exist, but as you say, they are mostly gimmick, proof of concept things, where someone mocks up a 3d physics engine in Lua, and would then presumably later learn how to port that code over into a more performant language like C or C++ or Rust... so that they could actually be used in a releasable game... because Lua is too slow to be useful as a core language for a physics engine, unless its translated into a faster language and then compiled, as is done with LuaJIT.

There are few reasons to choose that over a C++ physics library, not because Lua is slow, but simply because C++ is faster, and the libraries are typically much more mature and feature-rich.

You do not seem to realize that that literally is the more technically worded version of the exact point I am making: Lua is slow, no one has figured out how to code a 'more mature and feature-rich' 3d physics implementation that is comparable to C++ physics implementations, which actually runs in Lua, and doesn't pass it over to C and run the actual code in C, as LuaJIT does.

...

In summation, you yourself claim that a performant and fast Lua physics engine could exist, and when I ask you to provide an example, you stammer and waffle about with claims about theoretical ones that could exist, and then in the end of your post you admit that the only Lua physics engines/simulations you know of are basically little toy ones that are not efficient or fast enough to be used in a game.

... But thats after you say that I am bullshitting by saying the thing you just said at the end there.

Do you even realize you are contradicting yourself and being a hypocrite?

You remind me of the edgelord script kiddies I used to run into on Facepunch all the time.

All talk, no walk, and the talk is all nonsense.

Please either actually learn how to code, or go back to reddit with your baseless bullshitting.

Yeah, was gonna say this.

If you actually do use Lua to significantly alter the actual physics, shit gets fuckywucky really, really fast... its quite inefficient and laggy.

I know, because I've tried to implement custom physics manipulations in Gmod via Lua... the netgraph, and server side lag, becomes absolutely absymal, really fast, if you're trying to use it for more than just a few objects/interactions at a time.

Like the uh... Armored Combat Framework?

That uses Lua to allow you to construct your own custom tanks and what not?

That tries to do things like penetration/ricochet calls on physics and collision hulls... through Lua?

Astoundingly inefficient and laggy in pretty much any situation with more than 3 or 4 vehicles operating and engaging each other at the same time... especially so if they are using high rate of fire autocannons or machine guns.

You have to have an unusually powerful server to be able to handle more than that, and its still gonna chug as you scale up conflict sizes.

As I remember, most ACF servers had/have a bunch of rules about giving warnings before you dupe spawn or dupe save a vehicle design, have maximum part complexity limits, have designated build and designated battle times, or just seperate servers for each... because using Lua to handle so much physics stuff is so often likely to cause server stalls and crashes.