reepblue

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!

Really cool, Really useful for projects that might contain additional libraries.

You can open a prefab file like if it were a map.

Crawler's Den is a short experimental demo that was made just in the nick of time for the Summer Games Tournament 2016! This demo is a recreation of the AI and Events map of the SDK, however, the entire project was written in C++, and had it's connections made via Lua scripting thanks to LEX2's puppeteer class. This demo showcases: 4.1's visual enhancements. (Probe reflections, volumentric lighting) A map in which all game classes are written in C++. The LEX2 Template which allowed for in-game debugging, and smoother development. Known Bugs (Things I couldn't fix before the deadline: The animation manager has a hiccup switching from a non-looping animation to a looping animation. You might see crawler's glide after they attack. It's sometimes hard to press buttons using E. Not sure what's causing this, Sometimes it works fine, other times you have to press E all around the button. If you notice anything else weird, let me know, I can't say I'd patch it, but it's good to know of problems going forward. Although it's not perfect, this demo had a goal of stress testing LEX2 seeing what in the template needed improvement or not needed at all. This project made me think about what I want to do with this going forward, but I'll write a blog post about that. I'd like to thank CrazyCarpet and Mattline1 for their help. Crazy helped me with vectrors and math, while Matt made the input system which will allow plug and play XInput support in the future. Thanks guys! Download (Note, it's on my dropbox because I got a permission error when I went to upload it to the database. I hope this can still qualify.. :/ ) Enjoy.

I was working on this map and then all of a sudden, I got an error: String Index Out Of Range I restarted the editor, and got the infamous error message and now the map is just an unreadable pile of bits. Luckly, I backed up the map before today's edits. The only thing I did that I think I shouldn't be doing was using the beta branch to work on a map for a game using 4.1. Josh, if you need the full project, I can send you it. Unfortunately, I might postpone the project to next tournament anyway due to design reasons. Thanks! brokenmap.zip

Seems to be an issue of the Probes not displaying correctly. The editor is running the latest beta, Game running on 4.1 And this screen is right after I've created a brand new project using the beta. Funny enough, the map I'm working on for my summer game doesn't seem to have this issue. Maybe might have to do something with the directional light? Then again, AI-Events SDK map doesn't have one.

This might be why my project crashes. I thought it was a linker problem since I saw the project file changed.

Open map with no navmesh. Go to Tools->Build Navmesh Create one at default settings. See nothing was created after the wait. OR Open map with a navmesh. Go to Tools->Build Navmesh Create one at default settings. See that the existing one was deleted. I ended up going back to the default branch because of this. I needed to build the navmesh for my game. Might I add, the default branch of the editor runs a lot smoother.

LEX2 uses the user's native res for the default fullscreen. If you look back a few topics, Mac posted code containing how to get all supported resolutions for the machine. Use System::CountGraphicNodes()-1.x and System::CountGraphicNodes()-1.y.

Yeah, the prefab system was really meant for models, and acted like a workaround adding shapes to models. The system should be updated to allow you to make rooms and put them together in one map. Technically, you should make your door stuff models.

Yeah, I was missing ReadLine, I got involved looking into raw C++ stuff meanwhile that function is what I needed. >< All working now, thanks. Does not support everything, but it will support most things. std::string GetKeyValue(std::string pPath, std::string pKey) { Stream* stream = FileSystem::ReadFile(pPath); string command(pKey + "="); std::size_t found = stream->ReadString().rfind(command); if (found != std::string::npos) { std::cout << pKey << " found at: " << found << '\n'; } stream->Seek(found + command.size()); // Read only the line we're on! string finals = stream->ReadLine(); // Delete the quotes if any. finals.erase( remove(finals.begin(), finals.end(), '\"'), finals.end() ); // Return our value! return finals; } // This function will be called once when the program starts. bool Start() { std::string path = "materials/developer/bluegrid.mat"; cout << GetKeyValue(path, "shader") << endl; }

I did it like this, I'll look into compare right now, thanks. std::string GetKeyValue(std::string pPath, std::string pKeyVal) { std::string path = pPath; Stream* stream = FileSystem::ReadFile(path); string command(pKeyVal + "="); std::size_t found = stream->ReadString().find(command); if (found != std::string::npos) std::cout << pKeyVal << " found at: " << found << '\n'; stream->Seek(found + command.size()); string finals = stream->ReadString(); finals.erase( remove(finals.begin(), finals.end(), '\"'), finals.end() ); return finals; EDIT: still has a problem if the value isn't the last.

My main problem would be the Seek command. How would it know where to find it? The keyvalue can be at the top or at the bottom of the file.

FileSystem.h of the engine's API.

I've noticed that by default the engine creates a settings file and saves it to the AppPath. The issue is that there is really no clear documentation about how to read or write keyvalues in a stream. So I just used PugiXML for settings instead. Now I'm faced with this issue again. I want to get a custom value in a material file, but I want to check if it's there. and read the value after the equal symbol. I've spent the last few hours looking at the FileSystem/Stream classes. I'd hope there was a ReadKey() function. The only thing I saw that looked like what I was looking for is: Stream* ReadFile(const std::string& path, uint64_t fileid, const std::string key); But I have no idea how I'd set up the fileid. Any tips would be appreciated. Thanks.

This will be perfect for my dev console! I really like how it's coming along. I'm hoping the dark theme stays!