reepblue

Doing so will prevent additional code in scripts such as a check for preventing the mouse locking to the center when minimized Also, I'd make sure it flushes any keys and mouse clicks before the world gets unpaused.

When the Linux build of the Game Launcher is available, I recommend only having your game on there. This way, it will easier to manage updates. I'm gonna be honest and say I'm not your target audience so I feel like I can't really give you valid input. But I still wish you the best of luck!

You can also just prevent the world from updating when the window is not active or minimized to fix the mouse bug, but I'm glad to see that this sort of thing is getting built in.

The way it works now is great, but I'm thinking having it disable creating bak files on first time generation would be the biggest improvement, This way, the project always starts out clean. It would also be neat to having the power to exclude certain files from the common folder, and the option to inherit other templates.

I'm happy to hear that you like it Josh. Just a reminder that anyone can edit the ClientScheme.xml script to customize colors and fonts to make the UI fit their game. For instance, "A Demon's Game" might want to have black panels, a spooky font, and a red highlight color while Vectronic would be totally different. If workshop support for templates comes, I'll be more than happy to put it up there for more exposure, while keeping the git for active builds. I hope the behavior of the Project Manager improves with it so it can handle various conditions and options for template authors. Right now, it seems to copy the common folder, then the selected template. (Which you can see here what happens when the template and common folder have a file with the same directory and name.)

It's not because I could not get it to include the .cpp/h files although I added them in text. I'm using VS2015 because of SQL server issues with 2013, so I did not want to replace the solution. I'll look more into this. For now, just add everything under Source/. The stock .sln files should be generated upon creating a project with the template.

Hmm, You should be able just to open the copied Code::Blocks and add all the files in. the solution should automatically be set up to work with the LE libraries. From what I can recall, getting all the dev packages for OpenAL and such was a pain, and it took a bit of Googling. Keep me posted on how you make out.

In the default script, you can use -fullscreen launch option to enable fullscreen. But yeah, I feel that the issue is when the window is minimized as alt-tabbing in windowed mode does not crash, but alt-tabbing from fullscreen does, which Windows auto minimize the window.

You use import if you have collision defines or functions you wish to use throughout your code.

Windows 10 right? Because with Win8.1, I did not have this issue. It also happens when you call window->minimize in C++, but it's more noticeable when you alt-tab from fullscreen mode even if you pause the world like this: // Check to see if the window is active. // Pause the game if it's not. if (window->Active()) { // Update the world. world->Update(); }

I have a trade certificate in graphic design, so I just make my logos.

I'm not sure if I fully understand your question, but I'll do the best I can to answer it. Basically, since there is no Linux build, the Linux Executable that gets copied to your project is the stock one and not LEX. You should not really worry about your Linux version until near release. I just released this, so things might change over time. If you're a Linux developer, I understand your frustration of Windows getting served first, but I currently don't have anyway of compiling the application for Linux at the moment. If you're a Linux user with the Standard Edition, and you wish to compile this, I'd be more than happy to see a pull request of the Linux executable and any code adjustments if needed.

about: The Leadwerks Extended Executable Template (LEX for short) is a third party, and unofficial template for the Leadwerks Game Engine. The template is aimed at developers who are most interested in creating stand-alone games. The template is centered around the executable which contains a functioning options panel, a menu that can be customized, and various useful scripts. Although it's more aimed at stand-alone releases, the template is set up so you can still publish demos to the Game Launcher. Although the executable will not upload to the workshop, you can still stay connected to your fan base without destroying your stable stand-alone project. After an entire summer of development, You can now clone/fork the project on GitHub! Read the Readme for information on setting it up. Documentation Setting Up Customizing the LEX UI Answers for Expected Questions: Q: Why is the appreciations LEX, and not LEE? A: Don't ask why, I just like LEX better. Q: I'm new to Leadwerks, should I use this? A: I'm going to say no, not now. Get to know the engine with the official templates more before looking at this. Q: Will this work if I don't own the Standard Edition? A: Yes! With the executables pre-built, you're off to start your game using Lua! With the default main script, your game will still work with the game launcher. Q: Is this free to use; even for my commercial game? A: Yes! This is why I created this; To get people a jump start on their commercial projects. Q: How often will this be updated? A: The master branch will be updated with every new release of Leadwerks. A beta branch is available and will be actively updated during the engine betas. If you are using a beta branch of the engine, it's recommended you use the beta branch of LEX also. Once a new version of the engine is released, it will be merged with the master branch. Q: Why no Linux build? A: Because my Linux machine took a dirt nap and I can no longer build code for Linux anymore. I recall coding most of the UI code in Code::blocks, so it should build ok if you are on Linux with the Standard Edition. Q: Why a Template? Why not just release the executable, source, and needed files? A: Templates are a one time install, and you can use the template for multiple projects. I also wanted some scripts to show off how to communication to the application, as well as common scripts I actively use. Q: I don't want/like this template, but I want the Executable. What would I need for it to work? A: The application still crashes if there is missing files, which I plan to fix eventually. You'll need the application (Duh), ClientScheme.xml, and the UI folder under materials. In main.lua, you need to call the App class. title="MyGame" local startmap = "" local backgroundmap = "" app = App:Create(title, backgroundmap) app:SetStartMap(startmap) --[[ We loop the app here like this, and not in the app class in code so we can still communicate with the App class in other scripts. --]] while app:Loop() do end If you are still having trouble getting this to work, take a look at the main.h file of source code as all the files needed are listed there. Q: When I make my project, there is already bak* files! Why? A: This is because the Project Manager first copies the Common folder, then the selected template resulting in creating bak files for the common files. There is a batch under tools that deletes all bak files. Be careful though! It's a simple batch file with no checks at the moment. If a batch file that deletes files sounds scary to you, then don't use it, delete it! Q: Do you plan on making tutorials/documentation on how to use this? This looks all confusing! A: Yes. I'll write blog posts and link to them in the this opening post. Q: How do I customize the menu and panels? A: Edit ClientScheme.xml. Special Thanks And Conclusion First off, I'd like to thank the entire community as a whole. Although you did not help directly, searching through the forums of how to do various things really helped. I personally like to thank tjheldna for his work of tjui which it's source helped me a lot. I'd also like to thank Joshua's Leadwerks Template for showing me how to be a better programmer overall. Finally, I'd like to give credit to nick.ace and shadmar for the cubemap shader which is included with fixes for it to work in 3.6. I hope you find this useful for current/useful projects. Please provide feedback and feel free to ask any questions at anytime. If you find any bugs or issues, feel free to post an issue report in the GitHub, or report it here and I'll post it there for you. GitHub: https://github.com/reepblue/LEX-Template

Huh, this maybe why I had trouble when I tried to run Linux on my main machine. I think the best way I've found to cross-develop is to have 2 machines with the project on a git. Of-course, not everyone has 2 PCs, and the only need to cross-develop is if you're building applications for each OS.

Leaks of games happen, and they still happen. You can spend months and months working on your game, only for a server attack or the wrong person to share it with their buddies; which then goes public accidentally, (or intentional). Having an unintended work in progress build out there can give people the wrong idea about your game because there are people out there who think the development process is pretty straight forward. Let's take a look at the Half-Life 2 leak. The game, and the entire engine code was leaked and the entire thing was very unstable, It was also found out that all those were scripted, and broke when you actually play them. A lot of doubts and concerns about the game were made as they felt like they were lied to after seeing videos and screenshots not representing the leak at all. Of course, this later on generated a community of it's own, but that's a rare scenario. Since Leadwerks is far more stable than a Source Engine build from 2003, you can have months of playable work leaked. If you indeed plan to sell your game on Steam or Desura, you most likely don't want you're game freely available. So how can we prevent this? If you already got a SteamAppID from Valve after a successful Greenlight campaign, there is nothing to worry as users need a key to access your game. But what about if all to your game is dev textures, rough code, and programmer art? If you only have the indie edition, or only use Lua scripts for your game, you can use the Game Launcher, and set your game to "Friends-Only". For games written in C++, or have a modified application, we can't do that as our program does not get uploaded to the workshop. With the Standard Edition of Leadwerks however, we can use more of the Steamworks API. A friend of mine was talking to me about how an old Source mod use to detect if an invalid Steam user tried to boot the mod, it would not boot. Once I heard this, I was eager to see if I could get a similar system to work. Every Steam user has a public unique ID that comes in many different forms. Steam and games use this to gather information about the user, among other things. In this case, we are going going to focus on the 64bit FriendID number. Thanks to the Leadwerks API, we can access Steamworks features without our game being on Steam! Let's us first start with creating a bool function under the main.cpp. bool CheckSteamID() { if (Steamworks::Initialize()) { } System::Print("Error: Failed to initialize Steam."); return false; } So far so good! We make it a bool function so if we are not a fail to load Steamworks, or have the wrong ID, it will return false and close the program. Now let's get the users ID number with: uint64_t user = Steamworks::GetUserID(); As I said before, SteamID's come in various forms. The easiest to get is the 64 bit FriendID which appears in profile urls such as http://steamcommunity.com/profiles/76561197996502882/ As you can see, my SteamID is 76561197996502882. For the rest of this article, I'm gonna use mine in place of where you should put yours. A way to get yours is to go on a site such as http://ihavenfi.net/steamid. Popping in the STEAM_0:0:******** format after putting your ID-less profile URL will give you your FriendID. Remember, these numbers are public, they aren't like credit card numbers, or anything. So let's continue! For this example, I'm going to use My SteamID. So let's make a simple if statement comparing the account trying to play this game with a hard coded value. bool CheckSteamID() { if (Steamworks::Initialize()) { uint64_t user = Steamworks::GetUserID(); if (user == 76561197996502882) // Me! { return true; } else { System::Print("Error: Invaild SteamID!"); return false; } System::Print("Error: Failed to initialize Steam."); return false; } With this code, (and I hope you replaced the SteamID), your game will only work for you if you're logged into your account. But you need beta testers, and what about the other developers? Let's Continue by adding more IDs! As another example, let's grab Josh's SteamID. After all, he's the CEO and should be able to play any LE game he wants. Although his profile is private, we can still grab the ID-less URL which is: http://steamcommunity.com/id/Josh Pop it in the converter and we get: STEAM 0:0:6085996. Let's pop that value in again and we finally have his FriendID which is: 76561197972437720 Now let's edit that if statement. if (user == 76561197996502882 // Me! || user == 76561197972437720) // Josh { return true; } Now, Josh can play our game if he's logged into his Steam account. The best way to get ID's is to make a Steam Group for your testers this way you have all the profiles listed that you need to code in. We're not done yet, we still need to call this function near the start of the main function. if (!CheckSteamID()) return 0; Just make sure you comment that out when your game does get to be on steam, or when it releases elsewhere with a different DRM measure if you desire. With this somewhat messy way, you can restrict your games to certain steam accounts without having your games on steam during development. As a bonus, let's welcome the user in the console to make the tester feel they're special. Put this before the function returns true. std::string username = Steamworks::GetUserName(user); System::Print("Hello there, " + username + "!"); And that's it! There is most likely other ways of doing this, but this way is the simplest and easiest. If you hard code FriendIDs, and use the stand-alone publishing for beta builds, your game is just a bunch of unplayable bites and bits if it falls into the wrong hands!

Not saying they should be prefabs, but mainly a working functional way with-in the editor. Maybe you can have a similar format as pfb, but they auto break their instance on creation. Store these in the steamapp folder and have the editor read the files from that directory instead of the users game.

I've been experimenting with dragging and dropping pivots with scripts already attached to them. It worked out really well minus the dialog box showing up when you edit the object. I then just created all the Leadwerks objects one by one and saved them to prefabs, and seems to be faster and easier than the traditional way. Decals and Point lights benefit the most from this method. I've attached my prefabs to give you an idea what I mean. Again, only downside to this is that dialog box. Maybe in the future have all the objects on the left sidebar and if the user holds down on the button/icon, then drags from the button to the scene, the object will be dropped in. If it's just clicked, then it would act like it does now. ObjectPrefabs.zip

I used to play with LEGO all the time! I loved making cities and skyscrapers. I still to this day wish to make a minifigure scale metropolis.

Thanks for fixing the screen position bug and adding apply rules to the decal entity. It really prevents this kind of stuff now with movable objects. https://dl.dropboxusercontent.com/u/16218991/screenshots/Leadwerks/Bugs/decalbug2.png The decal tool feels really solid now!

With mp3 support comes royalties. Leadwerks is advertised to be a royalty free engine, meaning that no additional costs have to be made when you're game ships. If Leadwerks had mp3 support, people would not be able to freely publish their games as they can now. .ogg support is something that has been requested numerous times so join the club. I've read on older posts that people got it implemented with their projects, but I never could myself.

I'm sure. I copied and pasted the decal shader folder of the Common folder even after today's beta update. Here are the shaders along with the older diffuse shader from July 28th. decalshaders.zip

Using the latest shaders, if place a decal on the floor at the map origin, the decal will appear fine. If you move it around, you'll see it move with the decal placement plus a little bit of distance from the map origin. If you place it too far from the map origin, the decal will not appear. The old shader does not do this.

Was this not suppose to be in there yet? It would explain the spam of warnings. I'm really glad to see that such thing is coming soon, but I'm a little bit sad because I've just finished my stuff, and this sounds like it will be a better option. I was able to fix the conflict by putting my classes under a namespace, so my stuff still works for the time being.

Very nice. Will it work with textures that are drawn on the context? I can't wait to play with it! Also, I've noticed some GUI stuff in the library. Is it a WIP, or is it actually functional? Only noticed it because my code broke because of these new conflicts. Gonna look for more surprises!

Thanks to macklebee, the correct answer is to use the count/getnodes function like: unsigned int xo = System::GetGraphicsMode(System::CountGraphicsModes() - 1).x; unsigned int yo = System::GetGraphicsMode(System::CountGraphicsModes() - 1).y; Then, use those int values for x and y. In this case, I need it to be a char to save to an XML file. namespace patch { template < typename T > std::string to_string(const T& n) { std::ostringstream stm; stm << n; return stm.str(); } } std::string sx = patch::to_string(xo); char const *pchar_resX = sx.c_str(); std::string sy = patch::to_string(yo); char const *pchar_resY = sy.c_str();