Reply to Thread

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

Logging in with you Steam ID has now been restored ♥

The last reply was more than 60 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.

Information
Message
The maximum number of attachments: 10
Maximum file size: 10 MB
Allowed extensions: bmp, gif, jpeg, jpg, mp3, mp4, pdf, png, txt, zip
Automatically detects web page links.
Displays smilies as smiley-images.
Allows BBCodes to be used.

Previous Posts 18

  • .RK wrote:

    I know that vent. I also converted that to a model when I did stuff during development. What the hell?

    If you did removed that track, I would suppose that change will get reflected in the switchboard (if it's even still there in your version; it looks like it is but it's a bit hard to see from that angle).
    I mean, It's possible I may be mis-remembering. I'll double check when I get to my home computer in a bit, but I'm fairly certain I checked in the vmf you'd given me to see if I could just use the pre-existing model, only to find there was none.

    And yeah, I'm waiting to update the switchboard until I get everything finalized. Whatever layout I settle on is what it will show.
  • I know that vent. I also converted that to a model when I did stuff during development. What the hell?

    If you did removed that track, I would suppose that change will get reflected in the switchboard (if it's even still there in your version; it looks like it is but it's a bit hard to see from that angle).
  • .RK wrote:

    Huh. Interesting that you decided to detach that downed pipe near the bridge (I think). I can remember my reason for reattaching it was because there were a ton of brushes there in the case of the downed pipe. I still cite it as the only significant change that I made to dev areas (actually, I figure this might be why you did it as a reversion to how it is originally downed).

    I'll be interested to see what this ends up looking like in the end~
    Any changes you made to the dev maps that I undid were almost certainly not done so intentionally. The only exception I can think of is cutting that fork in the track you added near where the wire is now. I really didn't want to get rid of that one, but the brush limit gave me no choice.

    Any other changes only happened because when I started working on porting the map, I took the existing loop version of c2a2a and deleted all of the areas from the decompiled mod version c2a2a, and then took what was left and stuck it to the source vmf of the retail version of the level. Any changes you made to the dev level that I didn't specifically try and preserve were lost during this process. The reason I did that in the first place was because I theorized you were running up against the brush limits because the decompiler had inefficiently recreated the level, and that using the official source vmf might fix that. Unfortunately, I was wrong, and it didn't help with that, but it does mean that I don't have to worry about differences between the mod and retail version of the map anymore.

    As for the pipe, I believe I know what brushwork you're speaking of. I actually did take care of that, though I'm not really happy with how it's turned out. If you look closely in the picture I uploaded, you'll notice there's a weird texture where the pipe would meet the wall. That's because I converted all of that detail brushwork to a single model, which has caused some... issues with textures. When I get around to fixing that, I'm going to convert the detailing into as many models as needed; not one. I also went ahead and replaced the drawbridge and electrical equipment with the model substitutes you'd created to further reduce the brushside count. In this process, I found something I think you may have overlooked: the giant vent near the top of the drawbridge room is made of quite a few complex detail brushes. Converting that to a model didn't result in any significant or noticeable decrease in lighting quality, and gave me around a hundred more brushsides to use.

    Right now, I believe I've carved out a budget of about... 200 brushsides, give or take. I think that might allow me to add a single, non-complex room to the map further down the line. If a technique with displacements I'm experimenting with works out, I might be able to bump that up even further (and maybe even restore a few cut areas). For now though, my primary focus is getting the look and feel of the elevator hall and track control room to a place I'm happy with, along with playtesting and making gameplay tweaks where I think they're necessary.
  • jadebenn wrote:

    .RK wrote:

    Ah, yes, this problem. This was definitely something I struggled with when I tried porting c2a2a into 2013. I mentioned in the loop mod development thread that I had this issue but I forget if I've brought it up in other places because I come here so rarely nowadays.

    But now I'm curious: Did you manage to get c2a2a to compile in 2013? I ask because I didn't the last time I tried and what's on the workshop now is compiled under 2007 (I'd be over the moon if it worked in 2013).
    -snip-
    Huh. Interesting that you decided to detach that downed pipe near the bridge (I think). I can remember my reason for reattaching it was because there were a ton of brushes there in the case of the downed pipe. I still cite it as the only significant change that I made to dev areas (actually, I figure this might be why you did it as a reversion to how it is originally downed).


    I'll be interested to see what this ends up looking like in the end~
  • .RK wrote:

    Ah, yes, this problem. This was definitely something I struggled with when I tried porting c2a2a into 2013. I mentioned in the loop mod development thread that I had this issue but I forget if I've brought it up in other places because I come here so rarely nowadays.

    But now I'm curious: Did you manage to get c2a2a to compile in 2013? I ask because I didn't the last time I tried and what's on the workshop now is compiled under 2007 (I'd be over the moon if it worked in 2013).

    I have a version that compiles in 2013, but that came at the cost of cutting quite a lot of detailing. I started to see where I could optimize the map, and I converted quite a few brush-hogs to models, but that wasn't enough to restore the detailing I cut. So, I decided to try and re-detail what I could.

    Then things... got a little out of hand. I started making more substantial changes. I aligned the loop to the 16 scale hammer grid, re-added the electrical wire from Half-Life's c2a2a, blocked off the shortcut hatch to the bridge, and then I began to re-detail the security room and elevator hall.

    I actually have some WIP screenshots from a lighting test earlier today.

    Huge Images

    The elevator hall:


    The initial loop junction:


    The slightly reworked (and incomplete) track control:


    The wire strikes back:


    The removal of the shortcut hatch:



    So yeah, it runs in the Black Mesa Source engine, but not without modifications to bring it below the limits.
  • Ah, yes, this problem. This was definitely something I struggled with when I tried porting c2a2a into 2013. I mentioned in the loop mod development thread that I had this issue but I forget if I've brought it up in other places because I come here so rarely nowadays.

    But now I'm curious: Did you manage to get c2a2a to compile in 2013? I ask because I didn't the last time I tried and what's on the workshop now is compiled under 2007 (I'd be over the moon if it worked in 2013).
  • ESToomere wrote:

    jadebenn wrote:

    Tried compiling a different map (bm_c2a1a). Found something interesting.

    See, bm_c2a1a has 4,286 phantom brushsides. My version of bm_c2a2a has 5,532. That's a difference of 1,246 brush sides. So the number isn't constant per map. It varies, for seemingly no reason.
    From what I've read, the .vmf's that come with the game aren't actually up to date. Also, if you used a decompiler then it can't automagically recreate toolbrushes that are removed at compile.
    Right, but I wasn't comparing the bsp I compiled to the bsp that comes with the retail version (although that IS a good idea), I was comparing it to a bsp of the same map compiled with the other vbsp tool. Therefore, since both maps came from the same vmf, the only way the brushsides could be changing is because the two versions of vbsp are doing something differently, and I intend to find out what that is.

    I am beginning to think it's likely something to do with brush entities.
  • jadebenn wrote:

    Tried compiling a different map (bm_c2a1a). Found something interesting.

    See, bm_c2a1a has 4,286 phantom brushsides. My version of bm_c2a2a has 5,532. That's a difference of 1,246 brush sides. So the number isn't constant per map. It varies, for seemingly no reason.
    From what I've read, the .vmf's that come with the game aren't actually up to date. Also, if you used a decompiler then it can't automagically recreate toolbrushes that are removed at compile.
  • Tried compiling a different map (bm_c2a1a). Found something interesting.

    See, bm_c2a1a has 4,286 phantom brushsides. My version of bm_c2a2a has 5,532. That's a difference of 1,246 brush sides. So the number isn't constant per map. It varies, for seemingly no reason.
  • So, an update for you all. I still haven't figured out the exact cause of the issue, but I've made some progress in narrowing it down. Whatever's happening, it's definitely happening in VBSP. The phantom brushsides appear immediately after compiling the vmf with the Black Mesa retail VBSP, and immediately disappear when compiling with the SDK 2007 VBSP (for the mod version).

    The good news is that I have eliminated several theories as to why this might be happening:
    • Both compilers count skip brushes towards the limit, despite the fact that VBSP ignores them during compilation (I actually have to hide skips to be able to compile on the Black Mesa Source branch, that's how close I am to the brushside limit).
    • Both compilers count player clips, brush entities, and trigger brushes towards the limit (annoying, since trigger brushes aren't really brush entities as I know them).
    • Both compilers chop the level the same amount of times (still not exactly sure what a 'chop' is in the context of VBSP, but I know they both arrive at the same number thanks to -verbose).
    • Both hammer editors show the vmf as having the same amount of objects (so I know it's not on hammer's end).
    I'll continue to keep you guys updated as I work on this. The next thing I'm going to try is compiling a different vmf in both engines, to see if the phantom brushsides appear there as well. That way I can figure out if this issue is something unique to this level, or if it's a widespread problem.