Crazycarpet

https://www.lua.org/pil/24.html See lua_register, but keep in mind you have to wrap the functions you wish to expose in plain C.... ToLua++ is your best bet. https://bitbucket.org/Codeblockz/toluapkggenerator2 If you can figure out how to use my above tool, it will help you a ton! It'll auto-generate your Lua bindings for anything commented with //lua including enumerations, classes, polymorphic classes, namespaces, etc... Keep in mind to expose a class and it's members you have to tag the class declaration too like so: class MyClass //lua { void MyExposedFunc(); //lua int myExposedVar; //lua void MyUnexposedFunc(); } In Lua you would then do: local obj = MyClass() obj:MyExposedFunc() print(obj.myExposedVar) You do not have to tag namespaces with //lua however. I also wrote a C++ version of this I'm not planning on releasing publicly but if you need it I may be able to share it if you don't give it out. Also note that with namespaces the access is different like: namespace MyNamespace { void MyFunc(); //lua } Lua: MyNamespace.MyFunc() Note the '.' instead of ':' as namespaces are simply tables, where as classes are metatables.

Well, I never claimed to be good at addition But I meant 97.81% of ALL users are on 64 bit operating systems.

Yeah I would love to see this even in LE4.... according to the steam survey 97.81% of users are on 64 bit OSes, and likely even more than that have 64 bit supported hardware although steam doesn't give these numbers. http://store.steampowered.com/hwsurvey/ (That being said this thread is beyond dead! and 64 bit was promised for LE 5)

Maybe try re-installing Leadwerks? Or.. first if there is a way to reset all of your settings try that. I don't think there is a setting that would do this but who knows. Have you tried updating your mouse/touchpad drivers?

It might help Josh figure this out (assuming it's an editor issue) if you'd provide him with more details, maybe a video? and at the bare minimum the OS you're running.

Clickbait at its finest.

Gross, please don't go procedural. I would use plain C 100 pct of the time rather than C++ if I didn't want OOP.... If a user has problems grasping the concept of OOP they should spend some time learning the tools that each programming language provides before moving onto game development.... If you can't grasp the concept of OOP, you will never be able to make a game.. Simple as that. The concept of polymorphism is fairly simple, it is taught to first year computing students @ any university in North America and these classes are absolute jokes most students take to avoid having to take calculus. It would be a shame to see LE move away from object oriented programming. Not to mention Blitz isn't a great example to follow, considering it is not a very popular programming language to start with. It certainly isn't known for it's "smart" design choices.

Out of curiosity, wouldn't the door script be quite a bit better performance wise as the engine would be able to re-use the same vertex positions and normals of the mesh every frame where as the animated door needs to have the vertices of the mesh re-computed every frame?

" Leadwerks 5 is designed to be the most advanced game engine in the world " LE4 is a great engine, but I mean come on.

Making an actual hole in the terrain would be getting pretty complicated. (if possible at all in Leadwerks.) However if you simply want to hide the terrain while you're in a "hole" you could simply have another World and use World::SetCurrent to switch to a terrain-less world. There was a thread a while back where people discussed the issues of trying to hide terrain via code, one issue being that if you disable collision on the terrain, all the entities in the world are going to fall! the other being that LE's renderer seems to forcefully draw the terrain regardless of whether or not it's hidden... now there are definitely ways to force it to not be rendered, but the world method is probably your best bet.

That's not quite as simple as it is as this would cause a huge rubber banding effect due to the latency... this is where concepts such as client prediction, and server reconciliation come in. Essentially you make the client simulate his own movement as usual, and while the client receives movement "results" from the server (i.e: the end-position the server got after simulating the movement) you'd interpolate the client towards the servers result. Valve has some awesome write-ups on how they handle reconciliation/prediction and interpolation I suggest giving them a read! Another great article is http://www.gabrielgambetta.com/client-server-game-architecture.html I'm going to have to disagree with you there, I think you'd find you have much more freedom using raw ENet and writing your own high level functions over it as lots of the necessary things you'll need are hidden behind tons of abstractions in the Leadwerks networking library (which is really just ENet hidden behind simple abstractions). ENet is well documented... the Leadwerks abstractions are not, you're going to have a hell of a time figuring things out. IMO, most the features in Leadwerks were made with love & care, and well though-out... Networking in LE seems like it was mashed together over night with minimal thought put into it. Newton Dynamics is a quite physically accurate physics engine (as far as physics engines go) they rarely use made-up numbers, every number in their physics equations are there for a reason and originated from something "real". However, like every other physics engine... Newton is non-deterministic... different FPUs handle the floating point numbers differently and can store them with different internal representations, leading to slightly off results. You can not rely on the fact that the outcome of this "crash" will be identical... however if the parameters that lead to the crash are as identical as they can be you can except a quite similar result which is where client prediction/reconciliation comes in. You know the result the client produces will be both smooth, and close to correct... so the reconciliation won't be very noticeable. Honestly, these topics can range from very simple to extremely advanced depending on if you care about cheaters (if not, just spam unreliable messages updating the clients position w/ the position they say they're at!)... Only advice I can give is start simple and then read articles like the ones from Valve, and the one I linked above and try your best to come up with a nice solution to keep entities in the world in sync without getting visible banding from the latency! I personally haven't been able to get smooth client prediction results with Leadwerks for some reason... most likely because I never understood how SetInputs worked correctly and gave up before learning more about the LE character controller. However I did come close! I think as of right now everyone is just using a unreliable channel to receive the position of players/vehicles from the client... and trusting that result. (This is dangerous however, because a client could make a teleport "hack" by sending a fake position to the server.) The reason people tend not to go in depth about these topics is because there's no "global solution" that'll work nicely for everyone... you have to decide what kind of game you want to make, and come up with a solution that's best for you!

Use SetInput to move because "Move" and "Translate" don't take physics into account. https://www.leadwerks.com/learn?page=API-Reference_Object_Entity_SetInput

It's not really complicated... that's just kind of the point I was making, it's easy if you READ the enet documentation.. it's hard when it's hidden behind Leadwerks abstractions and undocumented... No flags = Unreliable, sequenced. Unsequenced flag = Unreliable, unsequenced. Reliable flag = Reliable, sequenced. The documentation makes it very clear. ENet is EXACTLY what it says it is, a low-level networking API... if you want to build a networking API into the engine it should be a higher-level design.

Message.Ordered/Message.Sequenced is an unreliable channel... by default reliable packets are sequenced in ENet and CANNOT be unsequenced... ENet however provides a flag called ENET_PACKET_FLAG_UNSEQUENCED you can use to make a channel both unreliable AND un-sequenced. Assuming the name doesn't lie, it's safe to assume that under the hood Message.Ordered simply passes no flags to the enet_packet_create function.

ENet certainly does support unreliable channels... they just also happen to be sequenced. Well, the idea of a state-sync style (Discard older packets) channel and reliability at the same time directly conflict conceptually.. you can't say "Hey, I want to guarantee this packet arrives and is handed in-order... oh but I want it discarded if a newer packet comes." reliable means you NEED that packet to arrive, and in order... if you only want to process the latest packet, use unreliable channels, as Ma-Shell pointed out ENet already handles this. Not trying to sound like a hater (okay maybe a little) but I feel like the networking implementation in Leadwerks just forces you to use ENet in a more limited, undocumented way... if you're not going to implement a high-level networking layer over ENet then what's the point? A high level networking layer should handle things like specific-data type writing for the engine instead of having to convert everything to a character array and send it... this should be handled for you so it can also handle endianness in the background (Which can't be handled by Lua.). As is it feels like using ENet is easier, and it definitely gives you more freedom... In an ideal high level networking API you should also be able to create your own MasterServer (This being a separate class from Server) that acts as the median for NAT punchthrough so people can do peer-to-peer and can host their own master server lists! The current setup in LE hides your underlying ENet objects so it makes it hard for users to extend it and add their own high-level features... anyways that's my rant.

Would actually be so handy, Unity calls this their "State Sync' channel and it helps a ton to have. But you still need to send the users inputs reliably to the server...

That's exactly what you should do, have a look at this: http://enet.bespin.org/Tutorial.html

That is very odd, I don't know enough about how Josh implemented this so this is probably a question he'd be able to answer. I'll send you the base and some documentation though, maybe you'll find it easier.

Well, when using ENet by default you'd simply access ENetPeers ENetAddress member and the 'host' value will always be unique as it's ENets internal representation of the clients IP address. I don't know exactly how Joshs version works as he hides the ENet usage behind lots of abstractions so he can simply make "NetworkDrivers" to switch between networking libraries in a clever way. However I'd assume the fact that the addresses are returning 0 would suggest that a successful connection has not been established (as in ENet this would be the case.). Are you POSITIVE you're even establishing a connection? with ENet/LE alike you'd do something like this to connect: Client* client = Client::Create(); Peer* peer = client->Connect("someip", 1234); // Now here we'd poll client->Update() til we receive a succesful connection message! Message* message; do { message = client->Update(); // Could do this better w/ timeout, etc. } while (message->id != Message::Connect); // If we ever make it here a connection has been established since no timeout was specified. If you ask me I think ENet does it better w/ their events xD Like I said if you shoot me a PM I'd be glad to share a networking base I wrote for Leadwerks overtop of ENet that I think you'd find is much easier to use for you.... it allows you to write engine types and bytes directly, while also handling endianness for you and extending the aggregation of packets. It'd save you from all these headaches. (Oh, and it also handles sending/receiving on a thread for you, except for client connection.. this makes the client hang til they connect.)

Under the hood the Leadwerks networking system is ENet, nothing more... ENet provides great flow control as-is and you really shouldn't have a "channel" for each user. You (generally) should have a channel for reliable packets, and a channel for unreliable packets which LE's networking system uses ENet to create for you already. But really the channels you have created and what they're used for will vary hugely game-to-game. Have a look at: http://enet.bespin.org/\ "Features and Architecture" is a good read. You'll see that channels although they do not operate concurrently, will not hold up the sending/receiving of other channels if one channel is waiting or hanging on a reliable packet that hasn't arrived... You'd be best off reading up on ENet and the features it provides and deciding what behavior would be best for your game as depending on the style of game (FPS, RTS, etc) you'll need drastically different networking setups for optimal performance. Leadwerks::Server is as "smart" as an ENet host with a couple of channels (See the LE docs, one is reliable and sequenced, the other is just sequenced). If you're using C++, shoot me a PM and I can help you with Leadwerks networking. I have a basecode that I can share that will help you with dealing with endianness, further aggregation, and a few other gotchas that come with the use of ENet.

I don't think networking is done is it? Last I checked it doesn't deal with endianness so a big/little endian machine can't communicate with eachother.... this can't be done manually through Lua sadly. (Or at least easily) But it'd really help if you could post your code! I was playing with this not long ago and it seems to work fine... Are you sure the message is being both sent and recieved? Server::Update and Client::Update both return NULL when there is no message.

https://bitbucket.org/Codeblockz/toluapkggenerator2 This should compile on Monodevelop 2.2 or greater, although I haven't tested it! it adds more support like enumerations, methods/variables that are just in namespaces and not classes, size_t and other fixed size integer support, nested namespaces and classes (Although the #define you'll see by default makes it generate classes outside of all modules (i.e: hidden behind no Lua table), and methods in namespaces are only in the lowest namespace. (This is only by default. You can make it generate the full hierarchy in Lua by commenting out the define ```MINIMAL_NAMESPACE_NESTING``` at the top of "Program.cs". Also it says "Unions are unsupported", but this is only partially true, look what Josh did in Vec3.h to expose the unions using a comment like: //float x, r, y, g, z, b;//lua The same works here. I strongly recommend you use this along with it: https://bitbucket.org/Codeblockz/fixtoluanamespaces The instructions for the generator explain how. to add it (Simply compile & drop in same directory as ToLuaPkgGenrator2 executable). It's (I think) like Josh's FixGlueCode or whatever script. if I were to tag something like class AClass { //lua MyNamespace::SomeClass member; //lua } This second application will go through the generated ToLua bindings and rename "MyNamespace::SomeClass" to "SomeClass" in strings, not in the code... making sure ToLua++ knows that they represent the same class. Why don't I make the generator simply not write this preceding namespace to the generated pkg files? Well because ToLua++ still needs it to be named this way in code and the generator only adds 'using' statements for namespaces based on hierachy, it currently doesn't support using statements being generated for cases like this as it'd be much more complicated to handle all scenarios. The second application was the simpler solution. You'll have to write your own bash script however that's equivalent to the batch script provided if you want to use this on Linux! Should be easy. If you do end up getting it running on Linux a share of the Bash would be appreciated, but not necessary! (As one of my projects unrelated to LE uses it and will need it to work on Linux as well.)

Bug report.

Great tool! Lots of potential for expansion too, it would be really cool to do some automatic terrain smoothing/leveling/grading in the future so the roads are minimally angled even if they're going up a hill, etc.

He's selling that script.. so if he made a tutorial on it it'd put all his hard-work to waste.