DerRidda

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.

Yes, the issue exists with Blender and every other program that calls for any external program when run through Steam. You can test it by clicking the links on the splash image that comes up when Blender starts.

I actually had that on 14.04 as well, have you reported it too Steam/ Valve yet? It's almost guaranteed to be their fault in some way.

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.

This is actually an issue on Unity as well. Look closely, he selected inches, if you do that the string doesn't fit the box under Unity as well.

There's no how-to necessary for that, really. You just use 'chmod +x executable_name' or use the graphical interface via right click and properties. Usually these permissions don't survive a .zip file though (though there is a feature fo zip that can do that). That's why shipping Linux builds as tar.something (tar.bz2 or tar.xz would be the best choices) is usually a good idea as it keeps those permissions intact, especially the executable bit.

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.

Well known issue that's been around since day 1 on Linux that hasn't received the attention it deserves. Makes me grumpy thinking how long this has been around.

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.

And another KDE user is seeing the same issue. Yeah, Josh; Would be great if you reported this to Valve through your arcane Steamworks dev means. Their public Steam for Linux github issue tracker sadly has become a place where reports go to die.

Checking the logs, these are the errors a single instance of gvfs-open (what xdg-open hands off to in Gnome/Unity environments) spits out reliably: (gvfs-open:29475): GLib-GObject-CRITICAL **: /usr/src/packages/BUILD/glib2.0-2.32.3/./gobject/gtype.c:2722: You forgot to call g_type_init() (gvfs-open:29475): GLib-GObject-CRITICAL **: g_type_interface_add_prerequisite: assertion `G_TYPE_IS_INTERFACE (interface_type)' failed (gvfs-open:29475): GLib-CRITICAL **: g_once_init_leave: assertion `result != 0' failed (gvfs-open:29475): GLib-GObject-CRITICAL **: /usr/src/packages/BUILD/glib2.0-2.32.3/./gobject/gtype.c:2722: You forgot to call g_type_init() (gvfs-open:29475): GLib-CRITICAL **: g_once_init_leave: assertion `result != 0' failed (gvfs-open:29475): GLib-GObject-CRITICAL **: /usr/src/packages/BUILD/glib2.0-2.32.3/./gobject/gtype.c:2722: You forgot to call g_type_init() (gvfs-open:29475): GLib-CRITICAL **: g_once_init_leave: assertion `result != 0' failed Might be an issue with gvfs-open after all, I had a KDE user before who had no issues opening external links through Steam. Probably.

Absolutely, yes!

It seems as if xdg-open events or any other event calling for a binary directly, like when Firefox was called directly for web links do not really pass through. It used to work when there was still a stand-alone version of Leadwerks. I investigated the situation with pstree and here is what it looks like: bash-+-bash---steam-+-SteamChildMonit---3*[xdg-open---gvfs-open] | | | | | |-SteamChildMonit-+-sh---Leadwerks-+-{Leadwerks} | | | | | | | `-{threaded-ml} | | | | | | `-3*[xdg-open---gvfs-open] The upper row of 3 xdg-open processes was when I started Leadwerks, clicked 3 objects that would cause an external program to open and, after nothing happened, closed the editor. As you can see those processes went up to SteamChildMonit and never made it passed that. The second row of 3 xdg-open processes was the same thing just that I didn't close the editor this time. Same deal here. |-lightdm-+-upstart-+-2*[steamChildMonit---3*[xdg-open---gvfs-open]] This is after quitting the editor and Steam, see how both SteamChildMonit processes still exist. Intentionally or not, I think Steam is somehow stopping these from getting executed. EDIT1: And here is the same thing for Blender (Steam): steam-+-SteamChildMonit---sh---blender-+-5*[xdg-open---gvfs-open] My locally installed Blender version opens the links in the splash screen just fine and so does the Steam version if it is launched directly instead of through Steam. EDIT2: NEOScavenger SteamChildMonit---sh---NEOScavenger-+-6*[firefox]

I think this used to crash the editor on Linux so it was disabled on purpose as a workaround which has sadly become the permanent "solution" it seems.

Not a bug: start.map is just a generally useless default that is supposed to be changed by you to whatever map your project is supposed to start with or you can chose to create a map called start.map. You usually run tutorial maps through the editor directly anyway.

Sadly, this is not implemented under Linux because of poor toolkit implementation.

I have been running Ubuntu with Unity on a 64 bit system since 11.04, never had a problem that was related to the arch. Care to elaborate what issues you are seeing?

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