reepblue

Isn't MSVCR100 associated with Visual Studio 2010? Do you have a steam copy or the Enterprise version? I have installed Leadwerks on Win10 with Steam without any problems.

Will the new spring parameter be still available though? Seems it can have other uses.

F

Try looking up your model with Linux in the search. Usually there is somebody else trying to do the same thing. To clarify, you got the driver from the repo or a Deb on the internet. The Nvidia package in the repo should have worked. Then again, the computer was designed to run Windows but Nvidia is usually good about drivers.

Tbh we should do this for every dependency possible. Definitely if 4.6 is the final release of the engine unless you wish to maintain it every 2-4 years once a new LTS ships.

What about client object drawing? For example with an fps, I don't want my player model to draw but I want people to see it and I want to see their player model. How would that be achieved?

Really cool. Hopefully a network newbie like me can understand this. Hopefully you can copy and paste this system into the new engine once this update goes live.

I couldn't test it with you being my high latency internet. But I really like how it looks. Gives me a old school Source MP feel and it hits home for me. When the template is done, I'll be sure to play with it. I have a home network I can test on. I can always reinstall LE on my Linux machine if my Win8 laptop can't handle it.

Since the Turbo repo is now distant from the Leadwerks one, will this roll into Turbo or will it be less Steam reliant?

Like Josh said, just use CSG to shell your level and add props later. Just because other technologies push the "model and UV walls and floors into modular pieces" doesn't make it right. The advantage of using CSG is that you can get an idea out fast. You can reshape the layout at any time and once everyone is happy with it, then you detail it.

What was the cause of this issue?

Glad to hear you made it to the States safely. Hopefully this means more stable Turbo builds and more development.

Keep in mind you might run into an issue in which the engine will require libcurl3 but the OS has libcurl4 installed by default (or vise versa.)

I can't wait to write my own scripts. Nice to see physics online. ? On the note of the Destroy function, I think Free() would be a better name. Destroy sounds like kill/delete. Free is what I name functions that clean out pointers and values with my RaspPi project. Who knows, I may just be weird. I'd be interested in others take on it.

Oh yeah no. That will not work in VR. lol. But the old Vectronic Demo can.

Oh the platforms? Yeah it's possible to do but idk most people would be able to stomach it, probably not worth the effort. I would just make the platforms enable a teleport path upward. Since scripting is now in the engine, I might experiment with porting my existing system in. The ball shooting stuff should work well in VR

My plan was to port Vectronic to Turbo. I still have to work on the assets and if you can get physics in, we can work something out.

I'll be sure to give this a try this week.

Making any app 64 bit will not magically make the run better. It's about memory and thread management. Leadwerks at it's core was supposed to run on mobile devices from 2010-2012 at the start. Turbo is Leadwerks but multithreaded and uses a more modern C++ standard. (And other cool stuff..) Turbo is in beta but it's not production ready yet. It's more for tinkerer's and helps financially support development. I'd stay tuned for more information and to see what happens.

Leadwerks is a 32bit library. You'll have to wait for Turbo Game Engine for 64bit support.

Imo, it should be up to the end user to decide how they want to build their systems. The engine should do just this, allow multiple scripts to be attached to the entire and handle duplications if there is any. Would I personally attach multiple scripts with the same function and value names? Most likely not, but that's my choice as a programmer. Multiple scripts will remove needing to rewrite effects per object type and allow things to be more modular. I see this as another tool in the toolbox. As long as it doesn't hinder what a programmer wants to do (Like if Rick wants to use an event system.) Its fine by me.

I'll probably never use the multiple return value feature and mostly stick with mono-scripting mostly However, it's really cool to have multiple script attachments for those cases in which multiple scripts would make sense. I rarely run into it, but it does happen. Overall the Lua implementation looks much better than it is in Leadwerks. Really stoked about using an entity as a table for other scripts to add, remove or manipulate. You made this much better, hopefully you can hit the same bar with the flowgraph/io system. ?

I've uploaded a new release last night correcting the player's pickup to be much more reliable. It should be very rare for a case in which the player is in a object and releases it causing the player to fly backward. I could have kept objects solid but that caused another can of worms. I also posted this on my OneDrive due to issues of people not being able to download it from this site. Yesterday I was working on implementation of the power balls and the launcher. I've written a rough draft of this a few weeks ago and I had it fully working in normal player code. When I started to work on the VR version, that's when I started to run into some problems. First, I didn't like how the code was looking. It involved a lot of referencing of entities and classes. What made it hard is that the VR implementation was different from the normal players. What didn't help was after too many restarts of my application with VR enabled, the entirety of Steam would just crash. So developing for VR was very frustrating. With Turbo coming a long, I wanted my code to work with little modification as possible. I've written a function wrapper that'll only be called if the application is ran under Leadwerks. This both will save time in replacing these functions when the time comes, and get's me used to the new functions. One thing I'd still have to fix is how Lua is implemented in the new engine. Most of the heavy functionalities are in classes which will defiantly keep self.entity for referring to the entity it's being used on. However somethings will still need to be changed and there are a lot of unknowns right now. With that being said, I think it's safe to say it'll be best to focus on the art and assets going forward. With the amount of time I have to make these assets, I'm sure more clarification with Lua scripts with the new engine will surface, maybe even a beta to play with. But with it being Leadwerks or Turbo, they both need assets. VR mode will also be dropped for now. It'll still be there, just not fully supported. You'll need to run the app with -devmode to see the VR tab now. After the project transitions into Turbo, VR development will continue. I shall be going back to my Linux machine with my ultra wide color calibrated monitor to work on these assets. I've created a lot of Vectronic themed stuff in the past and I'm going to go through it and see what I can savage from it. All my models are done in Blender, and I want to create all textures in GIMP this way my files can be used with free and open sourced tools. Also, if there is any Linux developers who wish to use this package, they don't have to be hit in the face with Maya and Photoshop files. Releases will slow down, but I'll be posting screenshots of my work soon.

The following is included in this release: Fixed player's pick up in which the object will not drop when the player is in the object's global aabb space. Replaced the player's model to shrink player's AABB radius. Disabled the VR tab of the launcher in Linux. Due to issues with the last release, I've uploaded it on my OneDrive. https://1drv.ms/u/s!AunSDJ8Se0vXiTXauNe965YH_H5n

Neat, but will the complete functions be exposed as well? I'm hoping to convert LE scripts to Turbo when this ships.