Jump to content

DerRidda

Members
  • Posts

    406
  • Joined

  • Last visited

Posts posted by DerRidda

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. It still isn't set in stone though this could be beneficial to the consumer as well if it were to happen.

     

    Also I didn't want to be quite so on the nose with my previous post but the forums software bugged out on me and now I have three posts in one.

  6. 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.

  7. 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

  8. 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.

  9. 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.

  10. So, playing the demo of A Demon's Game I noticed that I can barely hit 30 fps on my GTX 970. That's because it is pegging a single CPU core to its maximum which means my GPU is only being <15% utilized.

     

    That's on an AMD FX-6300 @ 3.5 GHz per core not the fastest but it should be enough.

     

    That's probably related to Lua being single threaded but that's crazy low, Natural Selection 2 (on Linux) is pretty much the same, Lua + OpenGL (a crappy implementation at that), but that manages 50-60+ (can't tell exactly because of forced VSync) for me completely maxed out and is a visually very demanding.

     

    So I would like to see what performance other people are seeing on what hardware and what OS and let's use A Demon's Game as a "benchmark", just the first large open room will do.

×
×
  • Create New...