reepblue

When I started with the Source Engine, the learning curve was pretty easy as all the nasty bits where taken care off. You jumped into hammer, made rooms, learn about entities,how they communicate and made community maps. As the years past, I dug deeper and deeper with creating materials, models, scripts then compiling code. There was a point where I knew how exactly the engine was set up, how it worked, and other things that are now obsolete. When I jumped to Leadwerks, a lot of stuff seemed familiar to me because of the CSG creation tools and the pipeline just made more sense than Unity, Unreal or even Source which I knew about so much. The biggest hump for me was Lua scripting as I was so used to C++, and never did any Lua before. I did struggle with it until I had a light bulb go off. Example scripts, new and old forum posts helped a lot. Even I now prefer Lua for game logic over C++. Compiling the entire solution to test a few lines of code for one entity was kind of dumb. And this was back with 3.2 when they only had a few community tutorials which where outdated and somewhat hard to follow. They recently replaced that with the tutorial section you're following today, and a cleaner API reference. Over all, it will take time, but once you know how Leadwerks works, you'll enjoy it.

Yes, it's functional.

Make sure all outputs are self.component:CallOutputs, not self:CallOutputs. I noticed that some scripts still have that old snippet.

Gamecreator, Most of Vectronic's textures use glow/emission stuff, plus a modified version of it so it can change the glow color. What's the issue? If you need any help with glow/emission stuff, feel free to ask. Meh, I was working on something too, but the project was not to my standards. Besides, what I did/doing instead will help Vectronic and possibly many others when it's done, so it's a better trade off in my opinion. But here's a screenshot. Notice the non-original content.

They should be realizable in the latest beta branch. Source: http://www.leadwerks.com/werkspace/blog/1/entry-1489-resizable-viewports-on-linux/

It's still seems to be vaild as it's in LensFlare.h: virtual void SetRotationSpeed(const float rotationspeed);//lua What it does, I dunno; experiment!

Don't think so as these were not prefabs. They were just brushes that were copied and manipulated. Plus they were fine up until a few days ago.

It's been a while since I looked at the Vectronic demo map, and when I opened it the other day, I noticed that my indicator lights (which was changed to brushes during the "Model Rotation Bug") where ether not facing the correct way, or the offset was off. I can say, these brushes were heavily copied and rotated a lot to make the trail effect. Nothing else seemed out of the normal, however. I was able to quickly fix them however. I'm not sure it's because of a beta update, or just a hiccup, or a similar issue like the models had; but I guess it's something to look at. Sorry for the delay in reporting, it was the 4th after all.

You can use the built in tolua stuff. Here is an example,and a post that helped me. There is not a whole lot of documentation on this, so your best bet is to read headers and search forum posts. On the C++ side of things, I do the basic stuff like how levels are changed, UI, menu, etc while lua is mainly the game logic like the Player, elements, etc. Minus that there are some things you can only do in C++, Leadwerks allows you to develop your game anyway you want. After all, it's just a set of libraries called with a console application.

I've read that any program that is designed to run on Windows 7 or 8/8.1 (Which Leadwerks does.) will run without a problem on 10. And If not, I'm sure Josh will rebuild the solutions/fix the issues when the update comes out later this month. But honestly, I don't see why LE wouldn't work.

I hope the workshop is filled with things that are worth money rather than cheap/broken/stolen content with a high price tag. I guess we have to trust the "good floats, bad sinks" logic here. If I ever post something for sale on the workshop, I'll be sure it's worth the money. Hopefully everyone has the same idea as I do.

I had this issue! It would work fine if the game was windowed, but would flicker on fullscreen. This is why the spotlights in Vectronic use sprites instead of lens flares. Also on a Nvidia card.

I swore that this was addressed myself, but I still divide all my color values by 255 as I'm sure it will always work.

So far, C++ application that has a settings system, and a MenuUI that can easily work on any LE game. Menu, loading screen and other things can be edited outside of Visual Studio. It also has a background map system too.

Make a new collision response rule in Main.lua. -- Props can activate triggers. Collision:SetResponse(Collision.Prop, Collision.Trigger, Collision.Trigger) You might also want a new collision for objects that are picked up. Vectronic is a working example of this. Collision.PickedUpProp = 12 -- Picked up objects can still collide with triggers, but never characters. Collision:SetResponse(Collision.PickedUpProp, Collision.Character, Collision.None) Collision:SetResponse(Collision.PickedUpProp, Collision.Scene, Collision.Collide) Collision:SetResponse(Collision.PickedUpProp, Collision.Prop, Collision.Collide) Collision:SetResponse(Collision.PickedUpProp, Collision.Trigger, Collision.Trigger) Collision:SetResponse(Collision.PickedUpProp, Collision.PickedUpProp, Collision.None)

In a perfect world, everyone could just go with their preferences and enjoy games the same way. My linux machine is an AMD processor, with an AMD GPU running Ubuntu 14.04LTS, and it plays Portal 1 at 30fps. And I know if I were to slap a drive running Windows/DirectX, that game will run with no issues. Maybe the 15 driver will fix everything, who knows. At the end of the day, I don't have control over what players want/have in their PCs.

I'm not really mad, it just makes things harder than they have too...

Over 2 weeks ago, I released a small demo showcasing my project's core gameplay on the Leadwerks Engine. Although I'm happy with the demo; it's a good landmark for the project, but it can be better visually and functionality. I learned a lot of new information about the engine on how to better optimize it, multiplatform diffrences, and I grew a slight hatred to a certain brand of GPUs. But the demo on the Game Launcher to me was a success. The stand-alone version in my opinion was a bit shakey as with stand-alone releases you lose the end user's ease of use when it comes to settings and the requirement of OpenAL. The Vectronic Demo was indeed targeted to work with the Game Launcher from the begining as I wanted to be more focused on the actual game scripting than the dirty stuff such as how settings are loaded, menus, etc. But I also wanted a stand-alone version out due to the launcher being in beta, and I wanted to let people on linux play it. I took Vectronic to the Portal community to see how they liked it. I mostly got back issues in actually launching the application. Besides the lack of OpenAL, most people did not seem to understand how they can run the Portal 2 (Which runs on a branch of the Source Engine that can run on DX9 cards.), and other games but not Leadwerks; especally on a certain brand of a GPU. One person actually got angry at me because he could not run the game. Overall, it was mostly things that Josh nor I can fix. (i.e it was ether outdated hardware or poor drivers.) However, the OpenAL requirement is something I can look into. Right now, I'm stepping away from the demo, and focusing on improving the stand-alone experience now since the soultions for the standard edition has been recently optimized. With the Summer Games Tournament coming up, it's a good deadline to stay focused, and to experment with non-Vectronic stuff. After this project is done, Vectronic will be back on track as I kind of need this done before I continue to work on my main project. I still got Part 2 of My Introduction Entry to write which I share why and how I moved the Project to Leadwerks, but I think I'll write that when I want to look back as right now I want to looking forward. I might also share various techniques I used in the Vectronic Demo as I think it will help with any user of Leadwerks; especially durning the summer tournament. I'll continue to write about whatever I'm working on here.

It happens with any map with Post Effects shaders. I took the start map, added shaders. and re-saved it in Windows. https://dl.dropboxusercontent.com/u/16218991/Requests/transfertest.map I test it myself. The Post Effects list clears when loading it on Linux. However, if you where to add Post Effects in a map on Linux, then open the map in Windows, the list does not clear as expected.

Hmm, I guess I was not paying attention. Yeah everything seems to be the same on both platforms. However, the post processing effects don't transfer over, the "Post Effects" under the map tab becomes blank after they have been set in windows. I did not try the other way yet.

Ahh, ok. I tried the Tutorial project's fan model and it was turned off. I'll "open" this again if I notice anything weird.

This model I noticed it. All my models with bones and animations seem to do it such as most props in Vectronic.

Not sure it's a bug or not, but I noticed that when dropping a model in from the asset browser, Occlusion Culling is enabled by default, when on Window's it's disabled. Opening maps on Linux that were saved on Windows will switch all the models OC setting to enabled, and when read back on Windows, it will remain enabled. CSG on the other hand it's disabled by default. I understand the linux version has a lot of gotcha's, so not sure if this is intended or not.

I really hope I can come up with something small and fun within the time period. I also want to take a break from the first person perspective/genre.

Reporting that performance of newly built executables now has identical performance to the stock build. Thanks, now I can really get back to work.