search

ValveSoftware / source-sdk-2013

The 2013 edition of the Source SDK
https://developer.valvesoftware.com/wiki/SDK2013_GettingStarted
Other
3.76k stars 2k forks source link

Positions of entities aren't updated in func_instance #117

Open alanedwardes opened 11 years ago

alanedwardes commented 11 years ago

When creating a func_instance containing entities, the composite map doesn't update their positions properly.

instance vmf The VMF being instanced.

composite vmf The composite VMF (note that our instance is positioned away from the centre).

result ingame The result in the engine.

The geometry was moved correctly, however the static prop wasn't, leading to leaks, and the prop being removed from the map.

tealsuki commented 11 years ago

I'm not sure 2013 supports func_instances. There was a big discussion about it a few weeks back. https://github.com/ValveSoftware/source-sdk-2013/issues/70

alanedwardes commented 11 years ago

Damn, that's rather annoying. If you look at the vbsp code however, there is support for it (see MergeInstances in map.cpp inside src/util/vbsp), and hammer does attempt to collapse instances. This is a bug in the sense that this is a feature that's not completely working.

Joe, before you mercilessly kill off this issue, instance support would make it so much easier to design levels! Please could you consider merging the instance changes up to L4D to vbsp down? :)

reepblue commented 11 years ago

Source 2009 supported instances. It was a bit of a pain to get it to work, but it did indeed work.I expect it to be the same here. It's kind of hard to explain, so let me try.

You need to make sure that your fgd is in the relative bin folder as Hammer (You can use the default HL2 one if you wish). Next add a Gamedata entry to your gameinfo.txt. For a reference, look at Team Fortress 2's gameinfo.txt.

When loading the vmf instance make sure you load an instance relative to the map's location. For example, map is in c:/mymaps but the instances are in c:/mymaps/instances. So when locating an instance, you would need to type "instances/myinstance.vmf manually. Why manually? Well I recall the loading does not work unless the InstancePath entry matches, but this causes an issue with vbsp. So, if the InstancePath is correct the browse button will work. BUT if InstancePath is correct vbsp will report errors. So make sure InstancePath is incorrect and just make sure you can get the instances from the map directory.

Sounds confusing? Sorry! But I've made a Portal 1 map using these instances. Personally I would stick to prefabs for anything that's not just a few brushes and models. Remember, is is the L4D2's instancing system, not the system found in Portal 2 or CSGO. that would require a new vmf and bsp version which this branch does not support.

JoeLudwig commented 11 years ago

@alanedwardes : does what @reepblue suggests here work for you?

The changes between the version of the engine used in L4D2 and what is in TF/HL2/CS are substantial and integrating that support over is beyond the scope of what we are doing in the SDK.

alanedwardes commented 11 years ago

I don't have access to my development machine until the end of this week. Is anyone else able to test this?

alanedwardes commented 11 years ago

I figured this out with the help of @reepblue - the problem was that VBSP wasn't using the FGD we had created in the mod directory - instead it was looking for it in the executable directory.

Line 2004 in utils\vsbp\map.cpp:

g_pFullFileSystem->RelativePathToFullPath( GameDataFile, "EXECUTABLE_PATH", FDGPath, sizeof( FDGPath ) )

Looks in steamapps\common\Source SDK Base 2013 Singleplayer\bin for the FGD - when you have your FGD in the mod directory, the code needs to look like this:

g_pFullFileSystem->RelativePathToFullPath( GameDataFile, "MOD", FDGPath, sizeof( FDGPath ) )

So it looks in your game directory for it. Without right FGD code was breaking at line 2403, where it was trying to get the entity out of the FGD file.

I don't know what you can do about this Joe - I guess it's not a problem unless you are shipping your own FGD with your mod.

So this issue can be closed, however I'm not sure the best place to put this information to help people in the future. Maybe here will be enough.

saul commented 11 years ago

Great find Alan. Have you considered the fact that Valve games have their FGDs in the same directory as the engine binaries? Therefore this fix can't be sync'd to the official repo because it'll break their tools. Maybe test for existence in EXECUTABLE_PATH, then fallback to MOD.

alanedwardes commented 11 years ago

@saul yeah, so I don't think they can do much about this - though doing a check sounds like a good idea. Is it worth creating a pull request with that fix?

saul commented 11 years ago

I can't see why it wouldn't be merged if it doesn't affect any current functionality (other than fixing bugs). I'll merge it into my repo, too.

reepblue commented 11 years ago

@ alanedwardes Nice find. I recall having this issue with Valve's fgds that were in "source2009/bin" at the time.

I've noticed that first it tests for the "EXECUTABLE_PATH", then it tests for " ". maybe slapping in "MOD" at line 2006 instead of line 2004 will also fix it? I'll try it.

alanedwardes commented 11 years ago

@reepblue I think "" may be there intentionally - I'd rather not remove it, it's not doing any harm. See my pull request - I settled with nesting another if statement. Thanks for the help all!

saul commented 11 years ago

I think this may have be an error from Valve merging code between branches behind the scenes.

Replacing "" with NULL searches all search paths, which is what I imagine the original code was meant to do.