reepblue

It's a start, might need adjusting later but this is great for VR push buttons. function Script:Start() self.entity:SetMass(1) self.entity:SetGravityMode(false) local position=self.entity:GetPosition(true) self.joint=Joint:Slider(position.x,position.y,position.z,0,-20,0,self.entity,nil) self.joint:EnableLimits() self.joint:SetLimits(0,1) -- The lower the number, the shorter distance. self.joint:SetSpring(1000,1000,self.entity:GetMass()) end function Script:UpdateWorld() if self.joint:GetAngle() >= 0.1 then System:Print(self.joint:GetAngle()) end end

Haven't tried since the 17th, but I'll look at it again with the latest RC. I can't test executing without a launch script as that's needed to function.

Really great, I'm going to need this when it comes time to convert my code for the new engine. I already have some macros in place for this. Hopefully we can see a new beta of Turbo out so I can experiment with my actors.

4.6 came a long way, you did good work. With this update, I can't wait to move forward with my VR project.

This works with 4.5 and I think it's part of a bigger issue...

Seems the crash fix in the beta broke the controller model entity. As stated here, I can no longer interact with the controller's as model entities.You can see for yourself if you launch the VR Game Template in 4.6 The Teleporter will be broken as the values from the VR controller aren't being applied to the model.

There are a lot of issues with the script editor, but I don't think it's a priority to fix them.

This was a brute Force test I did before I called it a night. You can move the hide commands with the condition scopes. Regardless, still unable to access the VR stuff like traditional models.

I believe I should be able to access the models like any other models according to the API reference., but it doesn't seem to be the case. I've ran into issues previously (A while ago) with setting a different material to the controllers. I was getting a hard crash. https://www.leadwerks.com/learn?page=API-Reference_Object_VR_GetControllerModel This function was being called with my UpdateWorld function. Also if you removethe p.second != nil condition, the app will crash also. //----------------------------------------------------------------------------- // Purpose: //----------------------------------------------------------------------------- void AVRPlayer::UpdateControllers() { if (VR::GetControllerModel(VR::Left) != nil) { if (m_bControllerLeft == false) { DMsg("VR: Registered left controller.."); VR::TriggerHapticPulse(VR::Left); m_bControllerLeft = true; } UpdateLeftController(); } if (VR::GetControllerModel(VR::Right) != nil) { if (m_bControllerRight == false) { DMsg("VR: Registered right controller.."); VR::TriggerHapticPulse(VR::Right); m_bControllerRight = true; } VR::GetControllerModel(VR::Left)->Hide(); VR::GetControllerModel(VR::Right)->Hide(); UpdateRightController(); } for (auto& p : VR::devicemodel) { if (p.second != nil) { p.second->Hide(); } } }

Sounds like a plan. Are you still interested in replacing the Code::Blocks file or is Leadwerks for Linux on legacy support going forward?

I'll give this a go tonight and let you know how I make out.

I'm looking into ways to re-create my floor buttons I've used in the Vectronic Demo. I don't want to rely on triggers this time around but instead have it be reactive to live physics. Here is a rad picture of how I intend to do this, The idea was to have a slider with a spring attached to prevent the slider joint from collapsing on itself. To test if the button was pressed, I would test the distance from the top model to the base entity. I've tried this with 4.5 and the top kept bouncing. The only thing that worked was using a Kinematic joint, but I couldn't lock it to an axis. I haven't tried this in months, but what would be the best way to go about this and is this do-able in the engine. I hate to ask for help without providing code, but I don't have my attempts anymore.

I request a argument/parameter/options list to use with the command line for each tool. You're kind of limited without knowing some options.

As I mentioned here, I prefer using Windows to actually develop. I only really want to compile and run my apps on Linux.

I've given this a lot of thought, and although I love Linux, it's not my platform of choice for game development. I use it for personal stuff and play with SDL2 but that's it. I've compiled a suggested roadmap which you may consider. 1) Roll back to Ubuntu 16.04 for the complete user experience. Leadwerks (Standard Edition) works as intended out of the box with Ubuntu 16.04. This is most likely your main user base so it would be kind of a shot in the foot to disrupt them. All you really need to do is to make sure games compile with no issue and replace Code::Blocks projects with ether my CodeLite template or CMake. Speaking for someone that really just wants a Linux executable, I don't use the Linux editor as it's inferior to the editor found on Windows. If my game compiles on 16.04, but runs on 18.04, I'm set. I have a VM set up to do this. 2) Keep Linux support until the next paid update I recall on our chat two weeks ago that you plan on a Leadwerks 5 (Not Turbo) and how you may consider that a paid upgrade. I suggest keeping the 4.x supporting Ubuntu 16.04 and skipping (OR having a "build only" support for people like me.) with Leadwerks 5. This way a free update doesn't disrupt the sadly few Linux users, they would have to opt-in for a Linux-less engine. If you include only the build libraries, we can still do Linux ports without you loosing your mind about the editor/GTK! 3) Bring it back Turbo. Cut as much middle ware out as possible and all dependencies are under the app's root folder. This not only makes it easier on you, but for game developers as they don't want to update their 4 year old game because a new version of a distro made it not work. I also suggest going all the way down and build on core Debian instead of Ubuntu. There are lot of concerns in where Ubuntu is going so you might just want to fall back to the root and work your way up. As much as I love Linux, It would make more sense to support only Windows and MacOS on Turbo's launch. I only suggest MacOS as it would be cutting in on Unity's terf, and my 2017 iMac needs something better to do than manage music collect dust. Linux is still a viable platform and I consider it a bomb shelter in-case anything else happens with the other operating systems and/or their companies that own them. The more applications that run on it, the more I consider using it as a daily driver.

Really confused, I used to get the same errors as aiaf, but now I can simply just compile.

Yep, that code loads fine. (Linux too!) I think it's something with the TextArea script exclusively. Noticed that I'm just calling Widget::TextArea without a script. Does the engine call the TextArea.lua script automatically?

I've done player crouching before. You just need to do a pick test when the crouch button is released to check if any brushes or solid models are in the way.

Used the code above: With the dummy flag steven@blackbox:~/Documents/Leadwerks/Projects/ActorTest$ ./ActorTest.sh -devmode -l Reep Softworks - (ActorTest) Initializing Lua... Warning: Lua sandboxing disabled. Executing file "/home/steven/Documents/Leadwerks/Projects/ActorTest/Scripts/Error.lua" ./ActorTest -devmode -l Installing Game: SDK Initializing OpenGL graphics driver... Without: steven@blackbox:~/Documents/Leadwerks/Projects/ActorTest$ ./ActorTest.sh -devmode Reep Softworks - (ActorTest) Initializing Lua... Warning: Lua sandboxing disabled. Executing file "/home/steven/Documents/Leadwerks/Projects/ActorTest/Scripts/Error.lua" Installing Game: SDK Initializing OpenGL graphics driver...

Vertical works, but not horizontal. USed your new script attached above.

I used my CodeLite project with Ubuntu 18.04 and besides the debugger not working anymore, (Might be a permissions thing) I was successfully able to compile and run my game application. Editor Launches as expected.

I'll definitely give this a go tomorrow, thanks!

It looks like this now with 4.6. The dots are the arrows. All I did was create a TextArea Widget and added text to it. ConsoleWindow(const std::string& pWinTitle) { m_pWindow = ENGINE_NAMESPACE::Window::Create(pWinTitle, 0, 0, 600, 600, ENGINE_NAMESPACE::Window::Titlebar + ENGINE_NAMESPACE::Window::Center, GetWindow()); m_pGUI = GUI::Create(m_pWindow); m_pGUI->GetBase()->SetScript("Scripts/GUI/Panel.lua"); m_pLogBox = Widget::TextArea(4, 4, m_pGUI->GetBase()->GetClientSize().x - 8, m_pGUI->GetBase()->GetClientSize().y - 30 - 8, m_pGUI->GetBase()); #ifdef USE_CMD m_pTextBox = Widget::TextField("", 4, m_pGUI->GetBase()->GetClientSize().y - 30, m_pGUI->GetBase()->GetClientSize().x - 8 - 72 - 4, 26, m_pGUI->GetBase()); m_pSendBtn = Widget::Button("Send", m_pGUI->GetBase()->GetClientSize().x - 4 - 72, m_pGUI->GetBase()->GetClientSize().y - 30, 72, 26, m_pGUI->GetBase()); #endif #ifdef WIN32 std::string header = "Reep Softworks - Leadwerks Console App (" + std::string(__DATE__) + ")"; #else std::string header = "Reep Softworks - Leadwerks Console App"; #endif m_pLogBox->AddText(header); size = 0; UpdateTextBox(); }

I'm open for a VSCode setup. How would you go about doing this? Keep in mind that it's common for Linux users to be im anti-Microsoft; they have a sour taste for Microsoft products.

I'm unable to as the application refuses to launch without that Library path bit. Tried hard setting flags within the script. export LD_LIBRARY_PATH=".:${LD_LIBRARY_PATH}" ./CodeLiteTest -devmode -flag -flag2 Same results: steven@blackbox:~/Documents/Leadwerks/Projects/CodeLiteTest$ ./CodeLiteTest.sh Key: devmode = 1 Key: flag = 1 = 1 flag2