reepblue

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!

Assigning an actor to an entity during or after level load causes crashing. CPP: #pragma once #include "ActorFactory.h" /* #include #include #include */ #include "../../Game/SimpleActor.h" namespace Leadwerks { void ActorFactory::AssignEntityToActor(Entity* entity, string actorname) { if (actorname == "actor_test") { SimpleActor* a = new SimpleActor; if (entity != NULL) { entity->SetActor(a); } } } /* Actor* TestCreate(vector parameters) { Actor* b = new Actor; return b; } */ } Header: #pragma once #include "Leadwerks.h" namespace Leadwerks { class Actor; class Entity; class ActorFactory : public Object//lua { public: //static void AssignNameToActor(string pName, Actor* actorclass); static void AssignEntityToActor(Entity* entity, string actorname);//lua private: ActorFactory() {}; ~ActorFactory() {}; }; } What I was trying to do was a system in which I'd register all my actors to a map, but this simple function is causing issues...

Wow, looks really great. It feels very fresh, and makes the engine itself more updated somehow. Probably cause the old site just made a list while this gives you screenshots/pictures of what the engine is capable of!

Splendid. Came back here for my Base Actor Class for a C++ player. I'll let you know how it works out!

Make an invisible ramp over the stairs.

Say hello to new set! Higher poly, and way better UV maps than my old models.

Yeah, I missed that post, Thanks Mac!

I agree, only thing I recommend is a way so new games can easily get discovered.

You make roughs like me!

That was most likely the intended purpose, but I can think of a few cases in which an artist might want to bring a brush (or a set of them) into their model editor. Depends on what you're trying to do really.

Unless they are desperate, nobody is gonna want to do that. I was hoping I could just make a batch that converts the vmf to obj. Really odd that editor's obj export doesn't export the uvs in the first place..