DerRidda

That solves nothing and only introduces problems when people try to apply math concepts that are "handedness" dependent in Leadwerks as right handed systems are the default in all of math and physics unless explicitly stated otherwise.. Is there any good reason why you did it? +Y can be easily achieved in right handed systems as well, as you just rotate the system as a whole. EDIT: Here Unity is left-handed too, I don't get why engine devs do this silly thing on purpose.

Even without the Steam restart I can now see the standard edition showing up as DLC under Linux.

Is the source for the GTK plug-in you are using available?

Mouse scrolling not working in most menus. This gets much more annoying than one might think. I think we talked about just trying to enable it again after some other unrelated gtk fixes. Did you ever do that internally?

Finally, seems to work well.

With decals coming will you finally give us a the ability to extract some extra information from CSG geometry via picking? It would be nice to know what material is on that wall the player shot at to paint the proper bullet hole decal on top of it.

Kill it with fire! http://arstechnica.com/security/2015/07/firefox-blacklists-flash-player-due-to-unpatched-0-day-vulnerabilities/

Could this offset feature be abused to basically dig a cave into the terrain?

Since I've recently completely removed Flash from every browser on my system I have noticed that embedded YT videos in blog posts don't show up anymore. See: There's no reason to embed YT videos as anything but HTML5 these days. Supporting the Flash ecosystem is just dangerous behavior.

So it's billboards for the most distant vegetation, right? Will we see an automated LOD system for the distances closer than billboard distance? That could allow for crazy dense vegetation.

B-b-but how will this fit 4 R9 Fury X cards in crossfire? Though I do hope you got a modular PSU with that to keep your sanity during cable management. I will keep that form factor in my mind the next time I build for somebody else.

Seems to work nicely here so far. What changed that it is now possible to actually use completely dynamic resizing?

I can nail down the exact reason for the crash but just from snippet you have posted I can already see a few 'unclean' things. 1st: Why are you even setting 'self.window=0' at all? There's no need for that and even though Lua isn't strictly typed, this could cause issues more than be helpful. It should actually be hard to even detect window being nil with that in the code. You should be seeing type issues instead. Judging from that I somehow fear that you are setting self.window to nil somewhere in the lines you didn't post. 2nd: Setting 'windowstyle = window.FullScreen' will cause issues while keeping if 'System:GetProperty("fullscreen")=="1" then windowstyle=windowstyle+window.FullScreen end' if somebody actually ever uses command line option for fullscreen, as window.FullScreen .titlebar are actually just constant numbers that, when added, give a sum that can be uniquely traced back to the flags that were set. Adding the same constant twice should never happen here. I would strongly recommend pasting the entire App.lua contents unless you are hiding the secret sauce there.

Something either went wrong during Window creation or it was skipped entirely or maybe a forgotten 'self'. Best to post your App.lua script here.

I wasn't talking about your issue in particular, I'm talking about the issue in general, of course your use case is another valid example: You can't make the game work the way you want it to through no fault of your own because of an arbitrary engine limitation. This, in my opinion, is beyond any other issues (such as bugs) the reason that would drive me away from an engine in no time: A design decision that actively gets in the way of me (and anyone else for that matter) doing what I want to do.

Seeing what Josh wrote in the topic you linked: I don't see how multiple nav meshes would be a problem. It's not like there would be a need for a lot of them, every object that doesn't have a nav mesh specific to its size would just use the next 'larger' one. A traditional FPS would need only two to three at tops, one for crouched and one for standing and maybe one for prone. And that's only if you want to let the AI even use these height levels for navigation as well, which a lot of games don't. (Just think about how many fps you have played where AI can't follow you into air vents. The answer is "almost all of them".) Is it even that expensive to have multiple nav meshes in your game after they have been generated? (Which afaik is the actual expensive part) Josh, just think about this, you have literally made it impossible to properly implement crouching. I don't think you want that. I think the first best step would be to allow for re-sizing of the character control shape between tomorrow and Friday until the nav mesh is figured out everything just uses the default one. Every object that is smaller would already be able to move opening up a ton of use cases already.

I agree, you can't even implement a proper crouch with that even in an FPS. It should really allow more adjustments.

I have a netbook with an AMD E450 APU running Ubuntu 14.04 LTS 64bit. Leadwerks runs, though not great it's better than I expected. That's with proprietary drivers of course. So the considerably stronger A-Series APUs should do ok.

Not really. No chance that 8400 is even running dedicated GDDR VRAM plus no card by any manufacturer where the second digit from the left is below 5 is designed to give anything more than office performance. Your 7600M probably has dedicated GDDR VRAM and actually is designed for some gaming. A difference of one generation doesn't help at all in this case.

You will need to update your driver to this one: http://support.amd.com/en-us/kb-articles/Pages/latest-catalyst-windows-beta.aspx

You will always have to find out detailed system requirements through testing. But there are some pointers that are always the same: While the editor is 32 bit on both platforms the engine is 32 bit only on Windows (which is bound to be limiting to somebody sooner rather than later) and 64 bit only on Linux. OpenGL 4.0 compatible graphics hardware is a given and that should not require any additional info on Windows but on Linux you should mention that the open source drivers are not supported yet as well as Intel HD integrated graphics in general (yet). Most of the rest is to be determined through some testing. Better be too strict with the minimum requirements than too soft.

That is troubling indeed and a big impact on every other party's rights to freely negotiate a contract. It's not just a problem with programs such as Leadwerks but also Blender which is using the GPL and that isn't exactly a license that accepts any kind of external restrictions imposed on what the users can do with the software. Classic Valve derp-out.

At first I was interested but then I was just thinking of why I'd need yet another beefed-up text editor next to all those established and good solutions.

Linux version is available now as well, Mac is supposed to follow.

I disagree. As it stands there is still the need to recognize the platform to workaround some Linux specific issues, like mismatching key constants between operating systems and the simply non-functional window layout behavior.