Jump to content

DerRidda

Members
  • Posts

    406
  • Joined

  • Last visited

Posts posted by DerRidda

  1. I think this has to do with XDG calls being ignored. Originally, this was hard-coded to open FF, now it opens the Steam client, except that the calls are ignored in Ubuntu 15.

     

    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.

  2. I'm not making FPS games, i don't need crouch , read again rolleyes.gif

     

    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.

    • Upvote 2
  3. 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.

  4. LE3 would need to get flexibility about Character controller collision, or some option to disable character controller collision to use our own. It is too FPS centric today for characters and not suited for other RPG games when it comes to characters collision.

     

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

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

    • Upvote 3
  6. Hypothetical scenario involves 4 PCs.

     

    Two machines are for modeling, artwork, and audio editing, and the other two are used for coding.

     

    If I really wanted to be a cheapskate I would ask every programmer (including me) to bring their own laptop.

     

    My current calculations place the cost for these four machines at a total cost of around $2500 (not including shipping fees, taxes, and cost of assembly by a third party). If I am being far too miserly, please tell me how much one ought to spend.

     

    For a properly equipped studio 2.5k would be a decent price to pay per machine per person. If you really do not have enough money to spend on PCs, a BYOD (bring your own device) scenario wouldn't even be a bad idea. You can then really go all out on one single computer with those 2.5k and set it up as a server for compilation and rendering, maybe even to provide the whole desktop remotely.

     

    But that machine you linked to? Every coder worth their salt would turn on their heel and leave the moment they saw it.

  7. Does anyone have an AMD APU? I'd prefer to avoid Intel at all cost due to their Linux drivers.

     

    I'd be curious to see how LE would run on an A6, A8, and A10.

     

    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.

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

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

     

    Is this a bug to report to Valve?

     

    Probably.

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

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

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

×
×
  • Create New...