So it looks like Facepunch's next sandbox game (potentially Garrysmod 2) is gonna be in UE4 - Games

Oh boy, time to learn me some C#! [QUOTE=thelurker1234;52650086] Honestly Facepunch has enough resources that they would'nt have to bother with valve assets. They could bring on workers to create texture sets, models, etc. that mappers would then be able to use.[/QUOTE] To be honest, if we just all pitch in, it would be great, but it wouldn't be as uniform-styled as HL2. Sure, the HL2 models are janky and look like they belong to junkyard, but, first, there's certain charm to that, and second, they're pretty uniform in style, amount of detail, grunge, gloss and their color palette. While some novice modeller may have a universally-useful prop, but with low-res textures on it, and some pros are going to go full 4096x4096 on props of silverware. We'd have to have some kind of art direction guideline list or something... I'm not even mentioning how much of a headache would be managing intellectual property rights of all these people, which is a separate can of worms if you're going to bundle this pack with game (technically selling it). Could be easily circumvented by having this community pack freely available, though. In any case, it'd better to consult with lawyer before some stupid crap with some vaguely-formulated cross-country law crops up.

[QUOTE=thelurker1234;52650086]Source has a lot of neat features, and Unreal has some pretty bad problems such as its awful physics engine, performance, etc..[/QUOTE] Awful physics engine? could you elaborate on that? [editline]o[/editline] It uses PhysX, how on earth is that awful :v: [quote=quotebox makes the video smaller][media]https://www.youtube.com/watch?v=B7_rPDwSKe8[/media][/quote]

[QUOTE=Ellistron;52650050]exactly, how many copies of CSS have been sold just because wanted it for gmod? valve makes money even if the assets aren't being used in their own engine, it's a win-win for them[/QUOTE] It was also basically free advertising

I'm am curious to know how they implemented usage of C# in Unreal.

-snip-

[QUOTE=Sam Za Nemesis;52650473]Is Facepunch Studios still hiring? This seems like the perfect project I'd like to contribute on[/QUOTE] [url]https://wwww.facepunch.com/#jobs[/url] Probably can try here

[QUOTE=sarge997;52650453]I'm am curious to know how they implemented usage of C# in Unreal.[/QUOTE] I'd guess they're using their own implementation with the help of mono.

[QUOTE=legendofrobbo;52649876]yeah, they should bring in themed prop packs with junkyard, modern and scifi props available by default that way different gamemodes/maps can use whichever kit fits the best (or just give no shits and use all of them)[/QUOTE] 1. Junkyard (hl2 equal) 2. Modern (CS equal) 3. Medieval 4. Scifi/space (Spacebuild equal) 5. Pheonix props 6. Weapons of all themes

[QUOTE=layla;52648825]We're exposing the asset importing to C# so anyone can write an importer for any asset format. We don't use any UE4 movement code. It's all done in C#. That goes for a lot of things, we use UE4 for rendering, physics, audio etc but use no gameplay specific code. You're not even going to be aware that it's UE4. The cool thing is that you wont have to port anything. I have a fetish for this kinda stuff and will make all asset converting automatic or just write an importer that loads all old source content outright. There's no more model compiling, you throw in your file and it loads.[/QUOTE] I don't think I've been this hyped for a game that may or may not release [editline]a[/editline] If this does end up being "gmod 2", IMO you guys should do some sort of closed beta for the dev forum or something, so that we can make content for the game before it comes out, just to get it started

[QUOTE=meharryp;52651079]I don't think I've been this hyped for a game that may or may not release [editline]a[/editline] If this does end up being "gmod 2", IMO you guys should do some sort of closed beta for the dev forum or something, so that we can make content for the game before it comes out, just to get it started[/QUOTE] Fancy seeing you here. :p I agree though, that's what Project Sansar did (that project from the guys behind Second Life), they had a closed beta for a while and let users populate the store with assets over time. That way the game wasn't completely empty upon release. At the same time though, I don't think they should follow through with this, it'd be interesting seeing the game in it's earliest release. Watching the workshop slowly populate.

Excuse the lack of reading previous pages, but are there any planes to hook Lua into Sandbox (the same way it works in GMod?). Obviously the functionality and hooks would differ but general Lua support would be nice (especially for those who aren't great with C# but have Lua experience). Similar to FiveM where mods can either be created Via C# (Maximum customizability) or Lua (limited, but still large) Does UE4 have a LuaJIT addon?

[QUOTE=joshuadim;52650514][url]https://wwww.facepunch.com/#jobs[/url] Probably can try here[/QUOTE] I was always upset how they never wanted artists.

[QUOTE=ZombieDawgs;52651604]I was always upset how they never wanted artists.[/QUOTE] i'm sure they're looking for anyone, just send a resume with a portfolio i guess

[QUOTE=Sam Za Nemesis;52650473]Is Facepunch Studios still hiring? This seems like the perfect project I'd like to contribute on[/QUOTE] Ah, so you’re seeing your Nokia N9 get ported to UE4 from Source personally? What, then, of C17 Ep1?

[QUOTE=Paul-Simon;52650389]Awful physics engine? could you elaborate on that? [editline]o[/editline] It uses PhysX, how on earth is that awful :v:[/QUOTE] Proprietary trash. PhysX might be OK if implemented correctly, but usually it's just sort of mashed in, and the result is frame rate dependent simulation (the physics break above or below certain frame-rates) and general instability. Plenty of developers I've spoken to would love to have more physics dependent gameplay and features, but can't because PhysX is so unstable and unpredictable compared to a proper solution like Havok or Bullet. If your point is going to be GPU accelerated, then don't look at PhysX, since it's a locked down walled garden for NVIDIA. Look at getting developers to finish the Bullet GPU accelerated pipeline, it's mostly there, and works on all OpenCL capable GPUs. We can post mass-physics videos all day, they don't prove anything. [quote] [media]https://www.youtube.com/watch?v=YG5qDeWHNmk[/media] [media]https://www.youtube.com/watch?v=143k1fqPukk[/media] [media]https://www.youtube.com/watch?v=dJXByKN2Fqw[/media] [media]https://www.youtube.com/watch?v=omHUU4oaWcE[/media][/quote]

PhysX in UE4 isn't really that good compared to the source physics engine, I've played with it extensively and it's a lot less stable no matter how you adjust it, things like making a train which is sort of unreliable in gmod is next to impossible in UE4, for a game the heavily relies on physics this is a very serious problem, in my opinion I would consider UE4 to be unsuitable, unless you want to replace the physics engine but that's a major job that would require a massive overhaul of the engine.

[QUOTE=Chryseus;52652036]PhysX in UE4 isn't really that good compared to the source physics engine, I've played with it extensively and it's a lot less stable no matter how you adjust it, things like making a train which is sort of unreliable in gmod is next to impossible in UE4, for a game the heavily relies on physics this is a very serious problem, in my opinion I would consider UE4 to be unsuitable, unless you want to replace the physics engine but that's a major job that would require a massive overhaul of the engine.[/QUOTE] What sets VPhysics apart from modern physics engines, anyhow? Do more recent versions of Havok maintain this uniqueness? Would a next-gen alternative such as Source 2’s Rubikon be just as bad as PhysX?

[QUOTE=chipsnapper2;52652093]What sets VPhysics apart from modern physics engines, anyhow? Do more recent versions of Havok maintain this uniqueness? Would a next-gen alternative such as Source 2’s Rubikon be just as bad as PhysX?[/QUOTE] Pretty sure it has to do with the core math behind collision detection and intersection. Vphysics is a weird bastard child of Ipion and early Havok. Modern Havok games seem to handle it all fairly well, Halo 2+, Battlefield 3+. If you want the pure mathematical and implementation details for Rubkion, they've been available since 2013 onward: [url]http://box2d.org/downloads/[/url] Look for anything from Dirk or Sergiy.

I'm still mostly curious as to what kind of feature extension we'll be seeing from this project. As I mentioned earlier, and Layla touched on it, UE4 is already extraordinarily powerful even in the hands of beginners and non-coders. It's easy to work in, the FBX pipeline is easy to work with and allows for a ton of flexibility, and packaging and distribution is pretty no-brainer; plus, you can already work in C# in UE4 [URL="https://mono-ue.github.io/"]if you want.[/URL] Combine this with free plugins and the engine being completely open source, and it's hard to imagine a more powerful or easier to use tool built on top of UE4 that accomplishes the same thing that UE4 already does. Additionally, plugins like [URL="https://forums.unrealengine.com/unreal-engine/marketplace/66198-hammuer-a-hammer-worldcraft-map-importer-for-unreal-engine"]HammUEr[/URL] let you import BSP map files and their content relatively quickly and easily as is, and using GCFScape and VTFEdit takes only a few minutes to port over all of Source content to UE4. On-the-fly moddability seems to be the big draw, but games like ARK make modding pretty powerful and just as easy as UE4 is at its core, and although a lot of people scoff at using the launcher, it's still a single program and a far better workflow than Source's. Obviously these things aren't necessarily "on-the-fly" like this project seems to be pushing for, but I guess my question is, why do they need to be on the fly? What are the benefits of writing a gamemode that can run and be distributed within the S&box at runtime, when I can just create the idea as game using freely available templates and bases and then just distribute that? The biggest problem is of course the distribution model, and getting the project into the hands of an audience, which Gmod is a great tool for (in most cases, although the playerbase doesn't really incentivize new creative gamemodes and as such we've seen stagnation) What kind of benefits, barring the benefits already gained from using UE4 and the aforementioned plugins available, and aside from ease-of-use for entry level coders and easier project distribution are we going to see from S&box? This isn't meant to be snide or rude either, I'm legitimately curious as to the benefits of making a gamemode built in S&box over, say, recreating a basic HL2 project in UE4 and building a bunch of standalone UE4 projects based on that for every gamemode I want to make, DarkRP, Sandbox, etc. and then hosting that on a website via HTML5, while using tools like HammUEr and MonoUE (even if it's in an early stage) to work with Source's content and C# respectively?

[QUOTE=Loriborn;52648633][media]https://youtu.be/MvIkoFQlNeg[/media] Just saying, UE4 doesn't have to be this homogeneous description of modern post processing and game design; this is like, 10 minutes of mock up. You can do far more delving into the source code that is freely available, but even without that, a few tweaks and you can bunnyhop and glitch out physics all day.[/QUOTE] I want a tutorial based explicitly on making UE4 look and feel like Source.

[QUOTE=Dr. Evilcop;52652841]I want a tutorial based explicitly on making UE4 look and feel like Source.[/QUOTE] -Pre-render all map lighting -have crappy dynamic shadows on props multiply on each-other -make every part of main map geometry with an eight point cube -ensure no more than seven things in the game use normal maps

[QUOTE=glitchvid;52651987]Proprietary trash. PhysX might be OK if implemented correctly, but usually it's just sort of mashed in, and the result is frame rate dependent simulation (the physics break above or below certain frame-rates) and general instability. Plenty of developers I've spoken to would love to have more physics dependent gameplay and features, but can't because PhysX is so unstable and unpredictable compared to a proper solution like Havok or Bullet. If your point is going to be GPU accelerated, then don't look at PhysX, since it's a locked down walled garden for NVIDIA. Look at getting developers to finish the Bullet GPU accelerated pipeline, it's mostly there, and works on all OpenCL capable GPUs. We can post mass-physics videos all day, they don't prove anything.[/QUOTE] The comparison here is to Source's implementation of Havok, and modern day PhysX is easily more capable than it. I posted that specific mass physics video because it displays a few things that are impossible in ye olde Havok: - Stacking more than a couple of 10's of objects on top of eachother, and having them fall down, would often result in Havok just hanging up entirely (I used to make a bunch of mass physics videos back in the day) - More than 2000 props was just impossible. GPU acceleration is kind of irrelevant. Not sure why you bring that up. PhysX is primarily a CPU-driven engine in games nowadays. Bullet would be nice, but PhysX is also nice - so why bother switching.

[QUOTE=Loriborn;52652413]I'm still mostly curious as to what kind of feature extension we'll be seeing from this project. As I mentioned earlier, and Layla touched on it, UE4 is already extraordinarily powerful even in the hands of beginners and non-coders. It's easy to work in, the FBX pipeline is easy to work with and allows for a ton of flexibility, and packaging and distribution is pretty no-brainer; plus, you can already work in C# in UE4 [URL="https://mono-ue.github.io/"]if you want.[/URL] Combine this with free plugins and the engine being completely open source, and it's hard to imagine a more powerful or easier to use tool built on top of UE4 that accomplishes the same thing that UE4 already does. Additionally, plugins like [URL="https://forums.unrealengine.com/unreal-engine/marketplace/66198-hammuer-a-hammer-worldcraft-map-importer-for-unreal-engine"]HammUEr[/URL] let you import BSP map files and their content relatively quickly and easily as is, and using GCFScape and VTFEdit takes only a few minutes to port over all of Source content to UE4. On-the-fly moddability seems to be the big draw, but games like ARK make modding pretty powerful and just as easy as UE4 is at its core, and although a lot of people scoff at using the launcher, it's still a single program and a far better workflow than Source's. Obviously these things aren't necessarily "on-the-fly" like this project seems to be pushing for, but I guess my question is, why do they need to be on the fly? What are the benefits of writing a gamemode that can run and be distributed within the S&box at runtime, when I can just create the idea as game using freely available templates and bases and then just distribute that? The biggest problem is of course the distribution model, and getting the project into the hands of an audience, which Gmod is a great tool for (in most cases, although the playerbase doesn't really incentivize new creative gamemodes and as such we've seen stagnation) What kind of benefits, barring the benefits already gained from using UE4 and the aforementioned plugins available, and aside from ease-of-use for entry level coders and easier project distribution are we going to see from S&box? This isn't meant to be snide or rude either, I'm legitimately curious as to the benefits of making a gamemode built in S&box over, say, recreating a basic HL2 project in UE4 and building a bunch of standalone UE4 projects based on that for every gamemode I want to make, DarkRP, Sandbox, etc. and then hosting that on a website via HTML5, while using tools like HammUEr and MonoUE (even if it's in an early stage) to work with Source's content and C# respectively?[/QUOTE] All you've suggested is to download some plugins and software to import a few source models. The point of this project goes beyond slapping down the included character actor and spawning a few source models. Even if the point of the project was to import source assets, you're asking what is the advantage of using S&Box? The fact that you don't need to download a huge editor and shitty plugins, which the average person has no interest in doing. You can fuck around with VTFEdit all day if that's what you're into but most people aren't, they just want a sandbox game that you can fuck around with without downloading a massive editor, so that is what we're making. We're taking gmod and doing it better, the fact that it's on UE4 is irrelevant to the end user, only us internally.

[QUOTE=Chryseus;52652036]PhysX in UE4 isn't really that good compared to the source physics engine, I've played with it extensively and it's a lot less stable no matter how you adjust it, things like making a train which is sort of unreliable in gmod is next to impossible in UE4, for a game the heavily relies on physics this is a very serious problem, in my opinion I would consider UE4 to be unsuitable, unless you want to replace the physics engine but that's a major job that would require a massive overhaul of the engine.[/QUOTE] honestly when i played around with it physx was more than adequate for a sandbox game the problem with physx in ue4 is that the default settings for it are the most efficient and CPU saving solution, at the cost of things being a bit jank (objects can phase through walls/each other at very high velocities, angular motion from physics rebounds not working particularly well etc) if you mess around with it you can make it much better than what it is by default

I don't know, I think the studious end user would appreciate the switch. I remember years ago when my friends and I played, we all thought the game would be much better suited to a more capable engine. [editline]6th September 2017[/editline] [QUOTE=legendofrobbo;52653064]honestly when i played around with it physx was more than adequate for a sandbox game the problem with physx in ue4 is that the default settings for it are the most efficient and CPU saving solution, at the cost of things being a bit jank (objects can phase through walls/each other at very high velocities, angular motion from physics rebounds not working particularly well etc) if you mess around with it you can make it much better than what it is by default[/QUOTE] Physics tickrate being one of the first things to go after. In DCR3d, you can play on 2000Hz for older machines, or 4000Hz for higher-end PCs.

[QUOTE=layla;52652960]All you've suggested is to download some plugins and software to import a few source models. The point of this project goes beyond slapping down the included character actor and spawning a few source models. Even if the point of the project was to import source assets, you're asking what is the advantage of using S&Box? The fact that you don't need to download a huge editor and shitty plugins, which the average person has no interest in doing. You can fuck around with VTFEdit all day if that's what you're into but most people aren't, they just want a sandbox game that you can fuck around with without downloading a massive editor, so that is what we're making. We're taking gmod and doing it better, the fact that it's on UE4 is irrelevant to the end user, only us internally.[/QUOTE] Even if S&box wasn't built on UE4, I feel as if in the era of free powerful open source game engines, the comparison is inevitable. My point isn't to attack the project, I'm excited for S&box to succeed, whether a Gmod sequel or not, but fair enough to say, many of those plugins and their developers are highly skilled and put a lot of time and work into their plugins, so I think calling them shitty is a bit excessive. I'm just rhetorically asking what that "beyond" part is, what the main features of S&box will be beyond the built-in content importing at runtime, which I only emphasize because it's one of the biggest features we've seen and the one a lot of people here seem most excited about. C# integration of course being another clamored for Gmod2 feature. I'm not saying that these are not big features either, they're important, but I'm legitimately just curious as to what other features are planned for S&box that will expand the S&box toolkit.

[QUOTE=Paul-Simon;52652884]The comparison here is to Source's implementation of Havok, and modern day PhysX is easily more capable than it. I posted that specific mass physics video because it displays a few things that are impossible in ye olde Havok: - Stacking more than a couple of 10's of objects on top of eachother, and having them fall down, would often result in Havok just hanging up entirely (I used to make a bunch of mass physics videos back in the day) - More than 2000 props was just impossible. GPU acceleration is kind of irrelevant. Not sure why you bring that up. PhysX is primarily a CPU-driven engine in games nowadays. Bullet would be nice, but PhysX is also nice - so why bother switching.[/QUOTE] Source's Vphysics is really more Ipon than Havok TBH. All of those are pretty possible with Vphysics. Orangebox changed some of it, they introduced a max speed and collisions per object per tick, presumably for stability on the console platform. But if you use an older version of the engine, or raise those limits, the physics are comparably smooth with large numbers of objects. As for the limit, that is a Source issue, more to do with free edcits, something raised in Gmod, I haven't tested since that change was made, but I could likely get something similarly large to the video you posted, in Gmod. I really don't see PhysX superior to Havok in any really relevant way, its contact solving is less reliable (and prone to clipping, sticking, sliding, and unbalanced systems) than Havok, unless you really step up the number of sub-tick calculations. Its only saving grace is the GPU accelerated features, but those are limited to NVIDIA. PhysX isn't a 'bad' physics engine per se, but there's a reason we see games using Havok or Bullet (GTA) whenever there's any actual gameplay related to the physics.

I really don't care what engine it's on, I just want a gmod replacement. I have been looking for a building game that can catch that spark that gmod had without the limitations that source has but none come close. I would preorder this shit the instant it hit the store earliest access or not.

S&box will only be truly superior if shitty DarkRP clones are banned.

[QUOTE=glitchvid;52653271]Source's Vphysics is really more Ipon than Havok TBH. All of those are pretty possible with Vphysics. Orangebox changed some of it, they introduced a max speed and collisions per object per tick, presumably for stability on the console platform. But if you use an older version of the engine, or raise those limits, the physics are comparably smooth with large numbers of objects. As for the limit, that is a Source issue, more to do with free edcits, something raised in Gmod, I haven't tested since that change was made, but I could likely get something similarly large to the video you posted, in Gmod. I really don't see PhysX superior to Havok in any really relevant way, its contact solving is less reliable (and prone to clipping, sticking, sliding, and unbalanced systems) than Havok, unless you really step up the number of sub-tick calculations. Its only saving grace is the GPU accelerated features, but those are limited to NVIDIA. PhysX isn't a 'bad' physics engine per se, but there's a reason we see games using Havok or Bullet (GTA) whenever there's any actual gameplay related to the physics.[/QUOTE] Fair enough, you clearly know your shit. Whatever we do end up getting, it is going to be better than the physics engine implementation we were used to though, that's for sure.