reepblue

Nice, I'm taking that the libraries don't support 2013 anymore, right? Also great to see how fast you've managed to get it working. (Like the RC was released yesterday. lol)

Good idea! Will there still 2013 backwards compatibility atleast for the first few months? I don't want to get the new VS until it's fully released. Not a huge deal for me, but still very cool.

Cool, so any assets that aren't in the new map will be released when GCResume() is called??

Really cool man. You should think about adding in controller support. If anything, pick up a Steam Controller and bind said keys to it before you go. I haven't played with the controller in Leadwerks, so it's something you gotta look into. I wouldn't bother with native XInput as I believe that Steamworks is eventually gonna take care of that. You might feel frustrated watching others play, but watch them play until they totally give up. You might have a person or two that might not notice something, and you might consider reworking a part to make it more clear. At Dev Days, some people just wanted to watch a Dev play and talk about it, which is fine too. That reminds me of a few stories. One, before we went to Dev Days in October, The PUNT team was almost panicking to finish the demo level. It was like 10 at night and something was like really broke and the main mapper wasn't on to fix it. It was pretty funny, I was on the Discord laughing I on the other hand finished the Blue Portals Demo a week in advance. Also, while we were showing Jeep Alive and Kicking, Chamber 07 didn't work. A real disappointment, but it was just one chamber which I'm sure he played 100 times before.

That seems to work. I put it on the top. Thanks. While It'll work for 16.04, I can say I had issues with 16.10. But that isn't an LTS release so it is what it is I suppose.

Make sure app is defined in Main.lua. app:Disconnect() All honesty, I really should set you up with the newer system as the git has been deleted cause I broke it, and the entire design was bad.

This is a well known problem. It existed since the release of Leadwerks on Linux.

It's actually very cumbersome to find VS2013. You have to go through some hoops to get the web installer from Microsoft.

No, I made the icons before the 4,1 release. And my design would have been flat to match the others. I got an idea for a design that'll fit. It'll pretty much be the same thing, just match the rest of the icons.

If the workshop button is actually gonna stay this time, I'll be happy to make an icon for that before 4.2 ships. Also, great to hear. I hope this will later mean more things can be on the workshop in the future.

Technically, people do with the branch system already in play. Issue is that in-order to switch branches, you'd need to redownload the differences. What I did was every time a build gets officially released, I backup all the contents of the Steam depot and place it under Leadwerks/Archive, then go to the beta branch to play with new features. (I'm not working on an actual game at the moment, or else I'd stick with the most stable.) When I notice that something is broken and it's a real bother like the libs not working anymore or something; depending on the update, I can ether redirect the LeadwerksLib path and keep the beta tools to wait for an official fix or backup the contents of the beta and restore the dlls and exe. Not really concern about scripts/shaders, but that depends on the update. Yeah, what I do is prob not ideal, and something a typical user would not need or do. However the idea of having the stable and beta branches locally would be nice, especially with the ones with slow or limited Internet.

Wait for the new GUI.

You could also make it a "Tool App" in Steamworks and it'll get treated as a separate app. Only thing is that it'll be under "Tools." Just a thought when I left as going back and forth between builds is a bit of a hassle. Not everyone is going to have an archive of previous builds like I do.

I'm also making something that others can use, so It should not conflict too much with the standard API and how Leadwerks is setup out of the box!

After I've returned from Steam Dev Days, I caught a terrible cold, so my first week home was unproductive when it came to LEX or Blue Portals. But besides that, I had a great time! I mentioned briefly in my last blog post before I went that I was giving LEX some reorganizing and defragmenting. This blog post, I'm going to go more into detail. LEX2 has a lot of things going for it. The developer console is really handy, the AssetManager prevents crashes and has the ability to pre-loads things for you and the PostStart() command for entities allows you to make entities do things RIGHT AFTER the map loads instead of during the loading process. All very helpful! Crawler's Den taught me a lot about what I was doing with LEX2, and where I should go. I designed it to be more Lua friendly than the initial release. but also allowed easy C++ classes to be made. Crawler's Den had the challenge of "Make a whole game in Leadwerks using nothing but C++". I know it was do-able, but how hard could it be? Leadwerks today isn't really as optimized to be developed using C++ as it is to Lua. I had to do go through a lot of hoops with somethings that could have been done easily if I just wrote the game in Lua. For instance, making C++ classes required more thought, and to attach my C++ puppeteers (actors) to entities in the editor, I had to make a Lua script that acted like a Hammer fgd file to sync it's keyvalues, inputs and outputs. Oh and on top of that, I had to make sure that each puppeteer got deleted properly. All and all, it was do-able, just not ideal at all! I'm switching back to be more focused to making games with Lua for now. I started by making a new project and re-writing the console system to be more flexible. Instead of defining all ConCommands in one cpp file, ConCommands can be defined anywhere now like: static void ConCommand_SayHi(vector parameters) { System::Print("Hi") } static ConCommand sayhi("sayhi", ConCommand_SayHi); With this system, it may be possible to make your own console commands via lua, but I'd have to look into it. My ExSystem Class is derived from Leadwerks System Class, and it's how to talk to the application directly. It handles the dev console, pausing, resuming, and other states that the application might be in. 90% of ExSystem can be called from Lua. The Developer console is much more powerful than it ever was. You can now make entities fire script functions or outputs by the entity name, or using !picker when looking at it. fire <entityname> <functionname> There are also a lot of Utility functions from the previous codebase. One of my favorites is this function. inline Leadwerks::Entity* UTIL_PickFromCamera(int pDistance, int pCollisionType=0, float pRadius=0) { Leadwerks::PickInfo pickinfo = Leadwerks::PickInfo(); Leadwerks::Vec3 p0 = UTIL_GetActiveCamera()->GetPosition(true); Leadwerks::Vec3 p1 = Leadwerks::Transform::Point(0, 0, pDistance, UTIL_GetActiveCamera(), NULL); if (UTIL_GetActiveCamera()->world->Pick(p0, p1, pickinfo, pRadius, false, pCollisionType)) { return pickinfo.entity; } return nullptr; } I also made the settings.config file store in the AppData folder instead of the game's root. While I never had any permission issues with the old way, still best to have the user's settings there. I merged both the WindowManager and ContextManager to be one class; There is just a WindowManager now. There was no point to have the context be managed in it's own class; definitely now since I took out my UI code I had in there for the console drawing. I also fixed Screenshots being properly placed in it's own Directory in the game's folder! The World Manager is what got the most fat reduced. Before I had a great chunk of code that was ether commented or ifdef'd out. For example, I had old code for my cubemap factory before the Probes where a thing, and other checks that in the long run might cause more problems later. The World Manager is responsible that when a user want's to load a map, a world get's created or cleared, and PostStart is fired on all entities if they have a script. If the user want's to go back to the menu, the world manager clears, and then releases the world. Something that was 913 lines got reduced to 260, and it does pretty much the exact same thing. I removed the InputManager as at Dev Days I learned that that Steam will later be able to handle that for you, not exclusive to the Steam Controller. Also, the implementation was really confusing and tricky. Finally, I removed a bunch of classes that are no longer needed including the Puppeteer class as the focus is now Lua. I want to keep the scope of things small right now. All you need to convert a game using the standard executables to the LEX is to replace the 2 executables and add this self explanatory Lua script that'll override main.lua. --This function will be called once when the program starts function App:Start() return true end --This function will be called right after when the program starts. function App:PostStart() end --This is our main program loop and will be called continuously until the program ends function App:Loop() return true end --This function is called once when the program pauses time. function App:onpause() end --This function is called once when the program resumes time. function App:onresume() end --This function is called while the program is loading a map. (This is where you draw your loading screen!) function App:OnMapLoad() end --This function is called when the program finished loading a map. function App:OnPostMapLoad() end --This function is called when the program disconnected from a map. function App:OnDisconnect() end --This function is called when the program closes. function App:OnShutdown() end Since it's really those three files that need to be shipped for the product to work, I can use the the standard Leadwerks Project Manager again. I don't plan on releasing the source code at this time. Maybe when making C++ games becomes more streamlined I'll re-integrate my C++ systems. There are still somethings to do though: Integrate the dev console to the Leadwerks GUI when that's fully done. The CMD using Cin approach that I'm using now is kind of bad. Play with the app a few hours a day, fix bugs, build on it a little each week. Find a good method in distribution, and keeping people up to date. In the future, I also hope to add more classes you can use while making gameplay objects. Somethings like a Beam class, and such to make things much more simpler. I also hacked together this shader that takes in roughness and ao sheets along with the diffuse, normal and spec. My artist gave me some textures right from Mamoset and my goal was to import them to Leadwerks as close as I could. I think they came out really well.

Can be a script property like. Script.line=Vec2(0) --line

During one of the talks (I believe Games As A Service or Early Access) one of the speakers mentioned that they put their beta branch as free DLC so users can go back and forth from the stable release to the latest beta. I think this would be really great if Leadwerks did the same thing. This way users can continue develop their game on a stable release but also check in to see what's new. Sometimes there might be a feature that people would want to check out and test but it might screw up what they're currently working on (i.e new map,model version or something else wacky.)

It was really great hooking up! Hope you liked our demos and our plans for the future,

Very happy on how everything is coming along. Blue Portals: Anniversary Edition development is going a tad slower than I wanted it too, but it's coming along nicely. We've finally shipped that in late August, and the mod made even more progress since. We just got some unknowns to work out like voice acting and music. I got some puzzles in the pipeline, and the mod right now has 11 playable maps. LEX2 is getting re-organized. I went back to the CMD window based dev console as I plan on adding in the final console with the new GUI once that's done and well documented. I also implemented a Convar system along with a new conommand system. Pretty much, a new foundation is in place, and I shifted my focus to be easier lua development for now. I'll write about it more when I know more on how I wish to accomplish this. Steam Dev Days is next week! I've spent the last month going through my archive of experiments and prototypes, along with making demo maps for Blue Portals: Anniversary Edition. Chris (my texture artist) is bringing his Surface to showcase our stuff. If you're gonna be attending the event, come find us! We've got a lot to show off and talk about. I'll most likely be posting on my twitter through out the event. Unfortunately, the surface ran any Leadwerks project terribly, so we are only limited to our Source projects. That's really it. I know I usually write an essay for blog posts, but I've been busy lately in preparation for Steam Dev Days. I'm really excited, as I never been on that side of the country before!

In the current version of Leadwerks, you can disable the console window by putting this in main.cpp: // This will remove the cmd window from showing up with our window. #pragma comment(linker, "/SUBSYSTEM:windows /ENTRY:mainCRTStartup")

Script::Delete() is from the LE3.0 days and has been 'replaced' with Script::Release(). Everything in LE should be released and the engine will take care of the rest. I never used Detach personally so I can't tell you what it'd be good for.

UpdatePhysics is when the Physics calculation is being ticked while Updateworld is once per frame. If you want something consistent regardless of framerate (such as fading out and such) use UpdatePhysics,

Really nice, Last push, the GUI didn't work, but now it does. There seems to be an issue with the top image on my 2560 x 1080 screen. The app takes a bit of time to load, but once it's fully loaded, it runs really smooth here.

Oh nice, your now recording these.

Crawler's Den is a demo I made for the Summer Games Tournament this year. You can grab it here. This blog I'd like to share my reflections on developing the project on LEX2 and Leadwerks in general. When I started the project, my template had no animation manger, and the puppeteer system was just coming online. The goal was to recreate the AI and Events map and write the entire thing in C++. Not only to test the puppeteer system and my ideas on how to link said puppeteers to the flowgraph, but I would have classes to derive from when I start working on Vectronic again. Right now, LEX2 is a template that gets installed in the Templates folder of the Leadwerks App Directory. However, upon creating a template, I noticed that the project and sources didn't seem to copy over as they did in testing. I think it has to do with the project manager's date based system as I was on the beta branch when I started. So fixing my project was no biggie, but not something I'd like to ship out. The player was the first thing to get coded as I wrote about here. I based my player code of the Source engine's player because I really like how that feels. It wasn't long until I had a player that can walk, jump, crouch, and use/pickup objects. Neat! I'm really happy how it turned out. There are some improvements I thought I can make, but it was drawing close to the deadline so it has to wait. The animation system was next. Without it, no gun and no crawlers. I started transferring code line by line but I didn't understand how to convert for inpairs loops to C++. This is when CrazyCarpet got involved as he was very willing to help as he needed an animation system for his stuff too. It took a few days to iron out, and minus slight problems I'm having, it works pretty much the same as it's lua variant. You can read the topic here about it which includes a link to the final code on Aggror's Wiki. Now having the animation system in place, the weapon was next. I first translated the FPSGun script from 3.2 as it was a lot simpler and it was something to get started. I later added bullets, and allowance of different weapon types although the project would just need a pistol. The crawler was something I put on the backburner as I never did AI in Leadwerks before. I was aware of the functions, but never needed to use them. This was my first project where I needed to use the navmesh system too. I did level design next because I really wanted to start mapping. I needed to start from scratch with the map. The AI and Events map used meters instead of centimeters so nothing lined up with the grid anymore. there was once an option to switch between the two measurements, but I guess Josh took it out, or it's under legacy features. Ether way, I wanted to use centimeters. I shelled the map out by eye and feel, I hardly went back to the source material as that would require switching the project and such. I had the map mostly shelled out before I started to work on textures. I usually use Paint.Net for raster artwork, but I decided for this project to use an older version of Photoshop. Not only because it's "what the pros use" but I want to use a file format that could be readable in other software. PSDs can be read by gimp so if there comes a day in which I'm making games on a non-windows machine, I can still open psds. I should learn how to use gimp and ditch Paint.net as PDN is Windows only. But I wanted to make a game, not learn new software. Now that I know how to properly port in models from blender, I had a lot of fun modeling for my scene. Making support beams, trims vents, and such was really fun, and everything got imported correctly. I had the best luck using FBX ASCII 6.2 versus the Binary 7.4 option, and Applying scale made sure that everything was sized correctly with a default scale setting as 1,1,1 like it should be. I couldn't remodel everything, I just remodeled things that wouldn't connect together right due to the measurement change. There was some old models I just used the model editors scale tool. While building my level was really fun, optimizing was the exact opposite. I limited my shadows, optimized my prop settings, made lights smaller, and collapsed a lot of modular pieces together and with my 750Ti, I get 90fps in the first room and 70ish in the showdown room. One thing I always thought was a good idea was to develop on medium range hardware. If you were to develop on lets say a 980Ti, you could get away with a few more expenses, but throw it on an older card, and it might chug, Develop on a mid-range card, and it'll play fine on that, better on newer and powerful hardware. I was cutting batches and polys like crazy but I couldn't get to a point where the entire scene was 100fps. I've added a wireframe view mode to my console options to see what was being drawn that shouldn't in which made me develop a portal volume that could hide, or show all the objects in it's volume while ignoring collapsed brushes. I eventually ditched the portal volumes because of a bug that I didn't feel like fixing, and I only saw 5 more frames in the end which wasn't worth the flowgraph mess I had to do. If I could get it to be automatic and fix that bug, I might re-add it. There was a time when I sent the project to CrazyCarpet to debug something and this is when I learned that my theory about developing on mid-range hardware was correct. He reported 100-120+ frames on his 980, and for some reason was getting better results on his 750. My PC is no spring chicken, but he was getting 100 frames all round on a 750, meanwhile I drop to 70 on my 750Ti? While I'm really happy that my pain and suffering resulted in better performance on newer hardware, it'd be great if I could have those results on my end. The deadline was drawing near, and it was time to do the crawler, and a few other classes. By this time, I've developed and successfully created a way for my puppeteer class to communicate with the flowgraph. In short, each puppeteer has it's own lua script in which you can set the values and write the inputs and outputs to the class. Inputs are handled through a message system while outputs are fired by the entitles component class. I'd have to write another blog on how it works but I'm sure weeks after I do, there might be an official way to link C++ classes to your game and the flowgraph. So I played with that converting more scripts to C++. Then it came time for the crawler. The crawler was a bit more difficult, and this is when I noticed an issue with the animation manager. It wasn't playing looping animations correctly. A quick line comment of --n fixed this, but to this day there is a problem in which it has a hard time going from attacking to running. It defaults back to it's idle animation and then glides around. Might be my monster code, but I was going on the last few days and the map wasn't done yet. I was using the beta branch for a while, then Josh pushed a broken build which put me back on 4.1. I noticed the editor runs more smoothly on the default branch than the beta branch. I would think that this has to do with a debug settings or garbage collection that's enabled when Josh does development and only turns it off during prime time. But then, the beta branch was "fixed" so I jumped to that while keeping my game on 4.1 (I archive releases). I noticed a bug with the probes, and my map got corrupted on it. Thankfully I made a backup, so I didn't lose everything. I went back to the speedy stable release, finished my map and went to upload it. Uploading is always a chore on my connection. I really hate when I spend hours uploading something and then after all that it fails to upload due to some error. This is why the Vectronic Demo is out of date on the game launcher, and why Crawler's Den is only on my dropbox right now. I should have used my mobile data, but I didn't for some reason. Ether way, besides a few small bugs, the project is out and playable using LEX2. Here is a summary of working with it. Good: No worry about back end stuff, besides somethings I needed to improve thanks to this project, I didn't have to spend a week writing window, context or world code. Console was a god send allowing me to easily debug my map in-game. Loading whatever map I want without the editor or hard coding was pretty dope. Once they were done, the puppeteers are really neat to work with. They are set up like lua scripts, and all the hooking is done in the base class. The precaching and Asset Manager worked amazingly well. No more slowdowns on loading models in real time, and no crashes because you mistyped the path. Really handy! I made a volume class for triggers and such. Works way better than collision based ones. Bad: Project's don't copy right with the project manager. Again, might be the date based system. The input system isn't done. It uses SDL for it's input handling and there is a bug in which all inputs must be done in UpdateWorld. CrazyCarpet said he'll look at this so we can correctly place movement inputs in UpdatePhysics. I feel as though Puppeteers should be called actors. They are called puppeteers because there was a class called Actor which was the actual entity doing the actions instead of a separate class controlling the entity. A lot of commented out code. I need to delete some things I've commented out months ago. It was kind of a pain to make sure the core code was synced up with the base project, the game project and the git repo. I want it so that all games off of LEX2 use the same Core files. Some reason I couldn't derive from my volume triggers.... I have an idea for this going forward but I don't want to express it just yet. No matter how I go forward, the foundation is here to stay. It might get cleaned up, maybe edited a lot, but I don't see a need for a rewrite, it's all solid. Thank you for reading this, I hope you have fun with Crawler's Den!