reepblue

Oh yeah, found that out myself. Not only the game crashes, but if it's hooked to the debugger, the editor will also crash, lol. Fixed my fullscreen issue, I really need to figure out how fonts work with the GUI as they still look broken, but everything else is pretty functional.

Interesting, might make a 'call' command for that. Thanks!

Win10 Pro. Einlander's sample code works, but strangely, my code doesn't work anymore. I might need to do some rewriting.

Find it odd that the default template works, but when using Window.Fullscreen in my code, I'm getting similar issues.

I think it's a dual monitor issue, everything is good here. (Single Monitor)

Luawerks will be updated for 4.4. I used Joshes recent menu to integrate it with the rest of the framework. Done: Options will be saved to the cfg file upon hitting the apply button. Don't worry, it still changes the world settings too! The new console interface is working. Backwards compatible with 4.3. To Do: Figure out why the font looks garbled. Find out how to change Fonts and colors for certain text. (The old console highlighted warnings in yellow and errors in red.) Console user history, In the previous console, if you hit the up arrow you can cycle through previous entries. Find the backup of LEX and see where I put the buttons and game logo. Going to recreate that. I still need to support basic backgrounds when a map isn't loaded. If I have time, I'll add support for background maps.

This current beta pretty much just broke Luawerks' console although I reinstalled the item. It's Ok since I was gonna make a new console box with the new GUI anyway. Just odd that broke. Also, Joint issue still exists with my script, but not in the stock fps game. I'll investigate that. Might open another post with a video. Luckily the double jumping fix works! Overall, really cool, thanks for keeping me busy!

I've been revisiting my FPS script by implement the newer way of handling carried objects. I'm happy with the results so far, however, I've noticed that after I've picked the box up and held it in the air still; and then tried to move while still holding the object, the box will just be stuck there, and it's still awake. Then I tried the stock FPS template to see if it was my code, and it happens there too, also got a hang second time I tried it. Pretty much: Open Pickup Objects Map of the FPS Template Pick up a box. Bring it to the air and then hold it in the air for a moment. Try to move.

With the default FPS script, you can now double jump by pressing the space bar again when in mid-air. Ether something happened behind the scenes or the script needs to be changed. I mean the effect is cool if you want a double jump, but not everyone would want it.

With the Standard Clone of the FPS Template, and in the AI and Events map. Sometimes upon picking up the object will cause the app to freeze. Try picking up the crate out of the pickup truck! If you comment out the update the code with this, the game doesn't lockup anymore. --self.effector:SetTargetPosition(pos,0.25) --self.effector:SetTargetRotation(rot,0.25) self.carryingEntity:PhysicsSetPosition(pos.x,pos.y,pos.z,0.25) self.carryingEntity:PhysicsSetRotation(rot,0.5)

I think I just used the standard transparent shader. All I really made was the material and the script. Like Tumiar said, if mine is acting up, so would any transparent material.

Pretty neat!. Also acts like a nice GUI demo too.

Recently updated to the 4.4 beta, and saw the massive amounts of additional dlls needed to run the executable. Perhaps move the dlls. so, and executable to a Bin folder and set the working directory to "../". Anyone can do this now with the professional edition by adding this to the main function: FileSystem::SetDir("../"); The issue comes when launching from the editor. Not a major issue, but the file directory would look nicer. Maybe something to consider in LE5.

It's ready to rock! http://steamcommunity.com/sharedfiles/filedetails/?id=933409657

Again, Luawerks was written in C++. There are many problems distributing it like that. Leadwerks updates every few months. So it's a cat and mouse game keeping it updated and making sure projects work out of the box. Pre-compiled apps are a no go also. We'd have to test on all platforms that Leadwerks supports. While this was OK with Windows and Linux, but soon the engine will support macOS and I don't have a Mac! Most people use Lua with Leadwerks. The developer for "A Demon's Game" didn't know C++ and if a bug happened or something wasn't quite right, they would have to wait on me to get back to them. I felt like I was taking control away from people. With the full API, you have access to all public functions and members; fully supported or not. You can wake up one morning to an engine update and your code is broke because Josh did something to make the engine better. (Short or long term) C++ programmers can be picky about how things are done. Even I'm like that! It's easier to debug and fix lua errors than application crashes. Also I had a case in which the app ran fine for everyone but one person. Speed isn't an issue as no to very little mathematics/weird calls are preformed in the script. I'm currently converting Luawerks for a paid release on the Workshop. Pretty much I'm just adding polish to the code, and documenting everything I feel the user should know about. I'm not sure about being ok with what you want to do unless it's for personal use. I'll keep you informed tho.

< Linked Removed > This was the replacement of LEX I was working on a while back. When you install this in your project, your app will have support for console commands, a working dev console, and a separation of main menu, in-game and paused states. As long as your map doesn't have spaces, you can load any map by entering map mymap in the console box. To open the console box, press tilde or slash. I was writing documentation, but then I got busy, and sorta forgot about it. < Linked Removed > Decided to share this more publicly. Haven't worked on it in a while, so if you have any questions, please gimme a few moments to go over it to answer your question(s). Thanks! Edit: Gonna clean it up and fully document it. It'll also be on the workshop.

As long as you keep the full price option, I'm all for the addition of a subscription option.

Alright, sounds good! I was getting a feeling that the current version was gonna "rot" until you said that! Also nice to hear that 4 and 5+ are gonna co-exist in a way. Again, interested to see what will come, but take your time. We want the best.

Really cool news! I've been dropping by for the past few months as the site has been slow. I like what I've read, happy that a "pay up front" option is still available, as it's one of the pluses of Leadwerks for me. Not a big fan of subscription-ware, but I understand why it's there. A question though: Since Leadwerks 5 is gonna be different when it comes to API, and it being a separate product than what we have now, what's gonna happen to 4.3/4.4 support? Because I suspect that the current Steam app is gonna be Leadwerks 4, and unless you request to take down the app, people might still buy and use the current version while 5 is well out. I know for 2.x, you moved all documentation to a legacy page, do you plan to do that? It's something that's not worth getting worried about; I know, just was curious on your thoughts. Also, is 4.4 still gonna be a thing? I wish you the best and looking forward to the future, looking forward to your future development blogs too. I'll be happy to early-adopt when available!

Really hope the UI update will make Leadwerks work on most flavors. Having it operate on Ubuntu Studio with the xfce desktop would be a win!

I'll be sure to check this out when it's out of beta. The physics always threw me off in the past and I'm glad it's finally being addressed.

Oh, I thought you wanted to phrase arguments as concommands. I don't know what I was thinking, I'm sorry. Yeah, I also had times where a param box would be useful. I got around this by using batches, and checking if debughostname was not nil to check if the app was running from the editor. function LSystem:LaunchedFromEditor() if System:GetProperty("debuggerhostname") ~= "" then return true end return false end TBH, running fullscreen in debug is like asking your game to run as slow as possible unless you're testing shaders. I had the game always ran in a case where I could close it in case something bad happened. To make sure that my "full experience" settings didn't load when I was just testing/developing, I'd use that function up above. Again, thought this was in the Programming section about turning properties into concommands. >>

Lua: https://github.com/reepblue/Luawerks CPP: https://bitbucket.org/reepblue/lex2-dev I didn't really mix this with the engine's Arguments vector, but that's easy to do in C++.

I was just making a new projects with the project manager. *shrugs*

Usually out and about on Saturdays, but I'll try to be there!