DerRidda

Right here. http://store.steampowered.com/news/15512/ You can check your steam.sh file to see if you have it already. The naughty line now checks if $STEAMROOT is empty. # Check before removing if [ "$STEAMROOT" != "" ]; then rm -rf "$STEAMROOT/"* fi

This has apparently been fixed already.

What are you even talking about? What you are saying makes no sense at all given the context.

You can team up independently from any engine, we have a forum here, collaboration should be easy to start.

I think the answer to this almost 50/50 split is:

I'm not (yet) using FlowGUI myself, just some of the recently published Winter Game Jam games use it and all have this behavior when I try to play them, as well as your own games in the workshop. Like this one http://www.leadwerks.com/werkspace/topic/11662-space-runner/ and this one http://www.leadwerks.com/werkspace/topic/11665-crazy-auto-present-dash/

I have been thinking about that myself and while I haven't tried anything yet I had the following idea. Every time you are ready to play a walk sound, you make a pick from the player controller to the ground, set for scene collision and use GetMaterial to get its material. http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/entity/entitygetmaterial-r127 Each material will need to be associated with the according walk sound in a table or something though and a default for stuff that isn't associated. It should be fast enough, as you only play walk sounds every couple of seconds anyway. The one problem I could imagine is that getting the material of collapsed scenery won't work but I'm not sure about that.

Have you tested FlowGUI on Linux? Because the Winter Game Jam games using it all share the same issues for me: Invisible mouse cursor and barely responsive menu buttons. In general most things seem to work but with some polish that could be elevated to everything.

Well, before going overkill, some duckduckgo-ing has revealed that turning off PhysX (setting it to CPU) in the Nvidia driver settings has solved a similar issue for other games.

That's a toughy. Nobody else is reporting Nvidia specific issues so far, I myself did use a GTX 650 Ti until recently and just upgraded to a GTX 970 without any critical issues but that's on Linux. The last difference between that benchmark and Leadwerks is that Leadwerks uses OpenGL 4 while the benchmark is on 3.2 so if your problem happens in one extension that only exists in 4.0 or newer you wouldn't see that. Could you upload your test map, preferably with the project you are using for it as well? My suggestion would be to completely remove the Nvidia driver in Windows' safe mode with the best driver removable tool you can find and then cleanly reinstall it.

What driver version are you running? Could be that the one you are using has some OpenGL issues. All the games you are comparing it with use Direct3D, so it's apples to oranges here. If you have Wolfenstein: The New Order or Rage try those, they use OpenGL as well. If you have neither of those try downloading any version of the free Unigine benchmark and let it run with the renderer set to OpenGL. This one for example: https://unigine.com/products/valley/download/

I'm entirely happy with this solution. A sane, simple and safe automated system for the more basic projects out there and the old "include everything" system that allows for total control but also requires it. Let's not bend over backwards for this non-issue.

Nope, that password field is always there you don't need to enter anything there. The drop down menu above the password field has the beta branch which you simply need to select.

I personally found that the Leadwerks editor greatly diminishes my performance when running the games from there but that's on Linux. What performance do you see when you run it straight from the executable while the editor isn't running?

How would it handle the example I posted here? http://www.leadwerks.com/werkspace/topic/11392-published-game-wont-run/page__st__20#entry83033 It sounds like it would fail that scenario. Is there a flag to turn selective file inclusion off/turn on the old behavior?

Some detailed system information would be nice and also check if there is something in ~/.leadwerks/leadwerks.log

Well, then this probably is an implementation issue.

Have you tried playing with SetPhysicsDetail()? http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/world/worldsetphysicsdetail-r785

Could anyone test this on Windows and tell me what they are seeing?

You are officially excused.

Don't forget to pull it from the Ubuntu Software Center as well.

I think this is harder to cleanly do than it might seem at first glance. It's probably easy enough to figure out which assets are currently used in a map and on entities but that doesn't give you the whole picture. At any given time you could be loading a new asset through code and it might not always be evident which assets those are before runtime. For example: You make an RPG with player-selectable avatars but you have a lot of them pre-made and maybe you want to allow the player to use their own images as well so hard coding each and every single one would be silly. Instead you iterate through each file in your player_avatars directory, check to see if it is valid and then use those. Now, how would an export option ever know that you are actually using these files in your project?

Out of curiosity: What happens if you jump into App.lua of the MyGame demo project and change the start.map to any of the non-working example maps and simply run the MyGame executable?

Windows and Linux.

The old "CSG geometry without either a script or mass attached gets 'collapsed' into nothingness" behavior has bit you in the arse, welcome to the club, I can still feel where it bit me. Either add a mass or a script (a blank one is fine) to the CSG in question and you will be fine.