• Slammin' Source map tools
    187 replies, posted
Private experimental version? How old's that? I've got ideas for a new file format similar to VMF, but DMX based and stores vertex / plane data in a larger, but more precise format. No ETA on that, might not happen at all. As for this surf map, it might be best to turn the surf planes into models, perhaps subdivide their surfaces for higher quality vertex lighting for now. ALSO seems like the vrad bug I mentioned in my last post surfaced again, wasn't fixed in the first place, will aim to do that for a hotfix release "soon".
Is it possible that we'll see full lightmaps on props? Like in TF2 now.
That's already supported, and has been since 2014 when TF2 was last merged back to the 2013 MP SDK. They're pretty poorly implemented though and I wouldn't recommend using them.
If you guys need to go off grid, just use func_instance. Saves a lot of effort
THAT will come in handy!
I don't know about the experimental build, ask ficool cause he was talking about it. I am not making a surf map and I don't use momentum mod hammer, besides model collisions aren't good so you still need brushes for em. What I am doing is editing various decompiled maps for various important purposes. I have the permission to do this. I have this collab deathrun map I'm working on and one of the participants was unable to finish, so we worked out a compromise to adapt an old unfinished map of theirs to be in the map, the participant in question does not have the vmf anymore which has tons upon tons of off-grid brushes. This is why you need to bring whatever changes you made in that version over! I need as little invalid solids as possible because a single one can essentially prevent me from working on any decompiled map due to my own standards. And this includes proper vertex saving, to prevent even more invalids which can occur after saving a decompiled map, which is less on the experimental build. Those pictures show that this hammer still isn't good enough and that a properly implemented working hammer patch is way better. Please come up with something soon for I want to be able to properly work on these projects!
Sorry for the extra post, instances can't save me as these are for decompiled maps. Even if it wasn't you'll still be saving multiple times deteriorating brushes, less than usual.
Oh. Ouch.
I don't and can't support / fix decompiled maps. When bspsrc decompiles a BSP, it outputs a standard Hammer VMF, if I were to update Slamma Hammer with the same vertex saving system seen in the Momentum mod Hammer, it wouldn't make any difference because the original decompiled VMF would still be broken to hell and back. Basically, when bspsrc decompiles a BSP, it does a really poor job of replicating the brushes, I don't know how or why, but it causes lots of brushes to be rounded off or have vertices in the completely wrong place. This can also cause some brushes to be made non-convex (invalid), since I increased the rounding radius in my Hammer very slightly (to fix some visual errors and have more accuracy to vbsp's output) there is a higher chance a decompiled brush with some crazy coordinates will be rounded to a point on the grid that makes it invalid. Besides, if I were to implement the alternate vertex data system for surf maps and the few people on this planet that use very complicated arches, it wouldn't make an ounce of difference. vbsp has a very large rounding radius when it loads vertex / plane data from VMFs and any errors you see in the 2D view would likely be rounded off to the nearest integer point, or welded to an adjacent vertex. Not only that, but if your brush appears "broken" after saving the VMF then it'll probably be just fine when you compile your map, not only because the 2D views seem to straight up lie about the true position of a vertex sometimes, but again because vbsp'll just fix it for you. There are rare times where a brush that looks off-grid in Hammer will actually be broken in game. If you really want to torture yourself with a cursed, crusty, decompiled map, then something that may help you is selecting every brush in the map (except ones that should have points off the grid, like rotated things), lowering to the smallest grid size (1), going into vertex-manipulation mode, selecting every single vertex, and pressing CTRL+B. This will round every selected vertex to the nearest integer point on the grid, which can help out. Sorry to hear that this Hammer just isn't good enough for you.
If you're misusing development tools to acheive something the engine isn't really meant to deal with (like working off-grid) and you can't accept that some else isn't going to support your jank workflow, you are not bright.
I understand that decompiled maps will always be fucked, I am not denying that and I do not expect full fixes. I just need things to be the least fucked they can be using this hammer. I need the decompiled brushes to stay as they are so no brushes delete themsleves after saving. Please look into whatever version ficool has does, for it deletes way less brushes when loading certian decompiled maps.
Just for the record, brushes should not degrade the more you load and save a map, no matter what Hammer version you're using, it's just a weird myth. What is the grid size in those images? If that's showing a grid size of 1 unit, then it shouldn't matter to the end result at all, as vbsp will just weld all the vertices together. Anyway, the way Momentum Mod's Hammer saves vertices doesn't change anything at all when you compile your map, as vbsp still only loads the old plane data, since support was never added for the new format, you're basically still compiling the map as it appears in the top image you posted. Literally making no difference from regular Hammer.
Ah, all these small improvements help so much, thank you for the hard work! -translucentshadows works great for translucent textures on brushwork, is there an equivalent feature for props? https://files.facepunch.com/forum/upload/267000/eaeee004-5062-4a75-8489-0d2cbbd9381d/pvkii_2019-05-06_15-51-41.jpg
-TextureShadows might do it. Interlopers.net Forgive me if I'm wrong.
Completely forgot about translucent surfaces on models, oops, there's no way to do that yet. I recommend you keep all but one side of that window brush textured, otherwise the shadows produced will be twice as dark, since the light rays pass through the texture twice (vrad has no way of determining if a face is pointing away from a light ray).
will $nocull affect that? Also, does it just cast shadows, or will it tint the shadow according to the diffuse of the texutre (stained glass window)
Any chance at getting texture shadows to work on displacements?
Displacements have specific code that makes them totally ignore all surface / content attributes iirc, I wouldn't count on that happening. Also, turns out I forgot to include the map launcher program in the latest version of the 2013 MP tools, released a hotfix for that. As for Stiffy's question, nocull won't affect it, and it only casts shadows, no fancy tinting, vrad only reads the alpha channel, which is B&W unfortunately.
@111112oo here's some background info and an external tool to manipulate vertex data - maybe that could help you? But in this case, this is really just another attempt at beating the data into shape with brute force. Decompiled map data is just dirty. Loss of numeric precision in VMF data
But they do degrade when you save a map, no idea what you are on about there. The map ficool and I were testing gave 26 lost brushes on load normal hammer and bad hammerpatch, 6 for the experimental build ficool was using and 16 on the normal build. That is a big difference! On reload, normal hammer/hammerpatch loses 11 brushes and the normal build of this hammer loses 12 brushes, so no protection on that front. This is why the changes from the experimental build need to be brought over + proper vertex saving, to stop more brushes deleting themselves! Hoping for the new filetype project to deliver! Yes, proper vertex saving would probably just result in those brushes failing to compile, but that's a very good thing! For then they can be crosschecked and fixed easily within hammer and it's tools. Yes, I've already stated I know that the Momentum Mod hammerpatch still has that issue, I used it to show what is currently wrong with this build and what could be. Thank you for this! Ficool sent me a tool for identifying brushes that will get deleted so I could combine that with this for some results, better than without.
func_monitor crash on your hammer.
Any news on the sprinkle tool? Been a few months
I wouldn't count on it, I don't have much time to work on these tools anymore, so I'm only really focusing on bugs right now.
Hi, I'm encountering an issue while loading a certain model with this version of Hammer. https://xavie.ru/i/2HfnP8M Here is the model in question: https://cdn.discordapp.com/attachments/111956579447799808/578409167619096616/city.zip
Didn't fix it for me but then again i couldn't launch them in the previous versions either
I would like to request small additions to hammer that could be useful. In Hammer, outputs are either 'Only Once' or 'Infinite', which is representated in the .vmf by a '1' or a '-1'. But it's possible to have outputs fire-able a specific amount of time. https://files.facepunch.com/forum/upload/385257/ea8cfa95-5a34-4e05-9edf-b16d5dacfbd9/image.png If you ever did AddOutput, you can specify the outputs to add to an entity, and you are free to put any number instead of just '1' and '-1'. For example: OnStartTouch > Door > AddOutput > OnUser1 !self:Open::0:5 > Delay Here, the AddOutput will make an output that is fire-able 5 times. After that's, it's removed. Doing that for normal outputs is also possible, but you gotta use a txt editor, to open the vmf and change that value. An output with such 'non-usual' value appear as Only once in hammer, but it is more than once. So, I think it would be great to have an actual 'textbox' to change how many times it's fireable, directly in the output window. ---- There are also 2 shortcuts, not many people are aware off. Ctrl Shift F, to search for an entity by name Ctrl Shift R, to be able to replace 'Text' in the map with something else. It can also be used to search for entities that have a matching parameter, for example, finding every trigger_teleport that use 'Destination' as their Remote Destination. So just like you Added a new menu bar, for Ctrl M (tools > Transform), you could maybe add small buttons for these. ---- Also, I'm wondering if it's possible to replicate how CSGO Hammer act with Map > Entity Report. In that version, you can directly see the Targetname of entities from the menu, without needing to click on each. Thanks for your work.
Hi there. So pretty much, I got a map with sci-fi theme, and as you can imagine it has a lot of func doors + func_buttons to open them (func_buttons are two brushes of the same button on both sides of the door). So the problem is, thouse func_doors and brushes, are going towards "model" limit, after last compile I had models to 1000\4096 but for some reason I hit somesort of limit, because last placed door wont work after compiling. After deleating one pair of door+button, this new door started working. Any suggestions?
Hello, I like the tools, but I have ran into a issue. I am using it for garry's mod and I have textures from hl2 that should emit light and for some reason they do not, here are some examples, all of them are compiled on fast. It seems like light doesn't go through transparent textures overall, help would be appriciated. here are pictures https://files.facepunch.com/forum/upload/477720/c4075104-0468-4914-bcb5-9f73c9343b66/e2d20950ef21d58c2ecec1100d299ef5.jpg https://files.facepunch.com/forum/upload/477720/8c4e4748-463c-4b00-b2fe-f908d6367a7e/cd0799a1534c6195df6eca10fa939c53.jpg https://files.facepunch.com/forum/upload/477720/3395eee0-8a03-4787-96ca-7f803b6d9d5e/028003d499582962dbdba49d49cabb68.jpg https://files.facepunch.com/forum/upload/477720/3722c4d7-2151-46b6-bc0e-09659dd901ef/e92fc8f5d7c44469de9a21af600a915a.jpg
This is a really weird bug and I have absolutely no idea what causes it, I've encountered it a lot myself and I haven't been able to find any pattern for it, it just happens when it wants to. I might get around to finally debugging and testing what causes it, eventually.
It looks like very similar, if not the same bug that I came across: It worked for me by not compiling on -final with the AO and the transparency/cast shadow commands ( the newer ones ). If you compile without them the lighting will work. Is like new lighting features collides with textured lights.
Sorry, you need to Log In to post a reply to this thread.