DerRidda

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.

I think that was pointed out somewhere else before. Or it was another function where X used to do things solo and is now asking the WM for "permission".

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.

That's a damn good question.

You are right, setting the collision type of the actual pick to Collision.Scene (which equals 2) did the trick as scene does not collide with scene but still collides with prop. Though I'm surprised that SetPickMode(0) didn't work in a way that basically means "No matter my collision type or how you pick, I will be ignored." I probably misunderstand what this actually does. Thanks for the help.

Well, that would make the whole barrier useless but yes, I tried and it is independent from the pickmode, as I fall through it but it still manages to block the pick. Here's the project: https://drive.google.com/file/d/0B3jPhxJap2Y3V05iMlRjYmVSWTQ/view?usp=sharing It's as close to desired behavior as I could get it by changing the "closest" parameter in the picks inside FPSPlayer.lua to false. The left and right columns can be used (good) while the center one still can't (bad). I hope this clearly shows what I'm trying to accomplish.

Huh? Was I that unclear? I need the hand to show up and use the items behind the barrier but apparently my barrier is still being picked even though I set self.entity:SetPickMode(0) which should mean that this entity is ignored in pick tests according to this: http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/entity/entitysetpickmode-r135

Big, player sized sliding puzzle. I basically have a portion of the floor carved out for this and if the player stands in the empty slot in which the blocks should go they either just block the movement, get squished or telefragged depending on how I set up the movement of the blocks. So I just don't want the player in the gap but that gap could be anywhere depending on the state of the puzzle.

I have a bit of a problem here. I need to have a physical barrier behind which entities can be used by the default FPSController. I created a thin barrier with scene collision, applied the invisible.mat and attached a script that basically only does self.entity:SetPickMode(0), in the hopes that that would be enough to accomplish my goals. Well, if it did I wouldn't have to write this... The hand doesn't show up and I can't use the objects behind it. The distance is well within the limits and I have tried changing the "closest" flag in the picks itself to false, which worked but only on some of the objects behind the barrier, others still wouldn't show up/be usable. Any help would be appreciated.

Really well done, makes the editor a whole lot more use- and powerful. Though for usability's sake I would love to see Carve and Hollow added to the right click menu as well, even though there are shortcuts, it feels like it belongs there.

Ah, I just saw you wrote that reply on the OP's Steam thread as well where there is proper context. Reading it here it sounded like you were asking to for the OP's login credentials for no good reason.

What?

That's the one that released as Catalyst 14.12 Omega and it's an absolute bag of manure with OpenGL 4.x. For Windows users it crashes the editor. If you can, roll back to 14.9 or see if the early version of Catalyst 15.3 I mentioned here is available on Manjaro/in an AUR. That might fix it, though early reports suggest it's garbage as well.

What hardware and Catalyst version are you running this on?

I haven't specifically tried that yet but it was already clear that basically none of the windowing features work under Linux. Just take a look at the full screen situation that still doesn't fully work let alone all the other window flags.

Another GDC video:

True but 14.12 is still total toss with OpenGL 4.x on Linux as well. Let's hope that driver hits all platforms sooner rather than later... and actually works.

There is a preview version for Catalyst 15.3 up in the repos for Ubuntu 15.04. You can download the debs here: https://launchpad.net/ubuntu/+source/fglrx-installer/2:15.200-0ubuntu1/+build/7051725 Use at your own risk! If in doubt, wait for the official version to come out. There's also an archive for non-Ubuntu users to take a look at: https://archive.ubuntu.com/ubuntu/pool/restricted/f/fglrx-installer/fglrx-installer_15.200.orig.tar.gz

It sounds like basically all OpenGL 4.2/.3 hardware should be able to handle Vulkan, could be quite worthwhile to pursue it as you might not even be excluding a single customer that can already run LW today but rather add a few new ones as it seems that the Intel Linux drivers could support Vulkan before they are even close to OpenGL 4. This might also be the stepping stone back into sustainable mobile support because it should work on all GLES 3.1 (or higher) hardware, if the drivers happen. I hope you are staying on top of this.

Here is Khronos Group's panel from GDC:

I just installed 15.05 from a daily iso yesterday. I didn't test Leadwerks much yet but so far the editor launches just fine and seems to work as usual.

Leadwerks has moved entirely to Steam. If the only version you have is the USC or stand-alone one, ask Josh for a Steam key.