WolfKit
L3: Member
- Jun 26, 2012
- 128
- 83
I think that's pretty much what he meant.
A heads-up about the SDK
- Thread starter Pocket
- Start date
I think that's pretty much what he meant.
There isn't really any reverse engineering work to be done. VMFs are very simple human-readable structured files. The only thing required is a hefty understanding of math and rendering code... problem is nobody that could do it cares about Source enough to find it worth their time to make a new Hammer.
You say that - over the last few weeks I've been toying around with DirectX and Visual Studio with the intent of exploring how an editor like Hammer might be made.
Obviously there's not much to show for it right now, but it's got a very nice config system. (Computer scientist through and through.) I was thinking of putting it up on GIT (I'd have neither the time nor the experience to see it through all by myself) and gauging interest once I'd properly documented everything up to now.
Obviously there's not much to show for it right now, but it's got a very nice config system. (Computer scientist through and through.) I was thinking of putting it up on GIT (I'd have neither the time nor the experience to see it through all by myself) and gauging interest once I'd properly documented everything up to now.
Dark
L4: Comfortable Member
- Nov 27, 2009
- 159
- 137
There already is a fairly good replacement for basic brush editing.
Microbrush2
Microbrush2
Paint selection, easier re-sizing, just to name two.
Precisely my point. It will take a huge amount of effort just to make something that is an equal to Hammer, and only then can one begin to better it with additional features. ...which, to answer fubar, would be stuff like a better 3D renderer that actually supports all (or most) features of Source materials ($color and $bumpmap for example), three-point-clipping, different kinds of displacement editing, a better model browser (one to put my library out of business!), and every other thing that we've all thought of at times over the years thinking "I wish I could do X easier"
I have seen Microbrush, actually, and it was part of my inspiration, but the fact that it has no prop support, no displacement support, no vertex modification support and no proper texture support means it's not that useful for me.
What I'd been thinking of was orienting the construction of levels from the get-go as being able to use more of the functions you'd generally find in modelling software, because they would just make life a whole lot easier. Some specific things I had in mind were allowing rotation around an arbitrary point (such as a 3D cursor, similar to Blender), aligning to an arbitrary point, allowing rotation and translation in both global and local axes, click-and-drag on faces to select or paint textures, clipping along an arbitrary plane (even picking a face of a brush to use as a clipping plane) and being able to translate/rotate this plane accurately before performing the clip, manipulating displacements using brushes similar to those found in terrain editors such as Far Cry, allowing selection and transformation of arbitrary groups of vertices on displacement surfaces, allowing the option to select multiple brushes and tie them either to one whole brush entity or many individual brush entities, and even (though this is likely to be a pipe dream) allowing temporary physics simulation of physics props on a prop-by-prop basis to allow for more accurate placement. All of these things are things that get on my nerves in Hammer and slow down the mapping process, yet wouldn't take the world to implement (providing a versatile editing backend is able to be created in the first place). Having essentially an open-source level editor to which people could add and modify code as and when they needed I feel would be a good way of pooling whatever programming talent we have as a Source content developer microcosm, though provided as you said that there are people willing and able to devote the time to it.
The advent of Source 2 and its editing tools may however render the whole of the above pointless if Valve come out with the versatility I'm hoping they might (finally).
What I'd been thinking of was orienting the construction of levels from the get-go as being able to use more of the functions you'd generally find in modelling software, because they would just make life a whole lot easier. Some specific things I had in mind were allowing rotation around an arbitrary point (such as a 3D cursor, similar to Blender), aligning to an arbitrary point, allowing rotation and translation in both global and local axes, click-and-drag on faces to select or paint textures, clipping along an arbitrary plane (even picking a face of a brush to use as a clipping plane) and being able to translate/rotate this plane accurately before performing the clip, manipulating displacements using brushes similar to those found in terrain editors such as Far Cry, allowing selection and transformation of arbitrary groups of vertices on displacement surfaces, allowing the option to select multiple brushes and tie them either to one whole brush entity or many individual brush entities, and even (though this is likely to be a pipe dream) allowing temporary physics simulation of physics props on a prop-by-prop basis to allow for more accurate placement. All of these things are things that get on my nerves in Hammer and slow down the mapping process, yet wouldn't take the world to implement (providing a versatile editing backend is able to be created in the first place). Having essentially an open-source level editor to which people could add and modify code as and when they needed I feel would be a good way of pooling whatever programming talent we have as a Source content developer microcosm, though provided as you said that there are people willing and able to devote the time to it.
The advent of Source 2 and its editing tools may however render the whole of the above pointless if Valve come out with the versatility I'm hoping they might (finally).
Since it isn't a very well known feature, if it would be useful to you I thought I should point out you can actually do it, albeit using more than Hammer itself. https://developer.valvesoftware.com/wiki/Map_edit
I was aware of that, actually, it's just a massive pain in the arse to do it so I usually don't bother.
You can get it to work, you need to rebuild the gameinfo.txt in the new file, and then dont launch tf2 through source, everything else will still work. Just when you compile the map you need to move it from its original file to the correct one. This worked for me, I dont know if it will work for everyone though
Last edited by a moderator:
En un mot : everything that any other editor (like UDK) does better. I don't say 'I could do better than Hammer', but I think that a open-source Source (I know) editor would end up beating Hammer quite easily, for multiple reasons.
Some features that I would like :
- Scripts to automatize some tasks (like one that would switch Red and Blu colors / names in some parts of the map, instead of renaming individually each thing)
- Better logics for TF2 (something more simple, without 150 different entities to make a single koth map work)
And so on. Actually, every single change the community would ask could be achieved really faster with an open source Hammer, than with waiting for Valve to fix things. The big problem (no, not that one) would be to code it, obviously :sleep:
WolfKit
L3: Member
- Jun 26, 2012
- 128
- 83
...which, to answer fubar, would be stuff like a better 3D renderer that actually supports all (or most) features of Source materials ($color and $bumpmap for example), three-point-clipping, different kinds of displacement editing, a better model browser (one to put my library out of business!), and every other thing that we've all thought of at times over the years thinking "I wish I could do X easier"
A model browser that doesn't freeze every 15 minutes and require me to completely restart Hammer if I want to use use the model browser again without waiting an indefinite amount of time would be nice.
Yanno, I don't really have any problems with the model browser in Hammer. It at least has a search function, and has never crashed on me. Knock on wood.
The HLMV though which I use quite a lot... if only it would remember the last browsed folder, it'd be as good as a huge upgrade imo.
The HLMV though which I use quite a lot... if only it would remember the last browsed folder, it'd be as good as a huge upgrade imo.
I actually don't mind the current entity system, it's very appealing to me. It's a nice method of incorporating some really useful logic into an editor that doesn't require coding knowledge in order to make something unorthodox, which I assume engines like UDK and Unity etc do. That being said, simplifying existing gamemode setups would always be a plus.
This is an interesting reminder to me of the vast differences between mappers. Since TF2's launch, and even with the later game modes, I've always seen the logic as extremely watered down and simplified into "drag-n-drop" logic that requires few entities and does everything engine-side.
Fish 2.0
L6: Sharp Member
- Nov 22, 2012
- 324
- 262
We need best of both worlds - drag'n'drop entities and then ability to further edit the code of them or create new ones.
Some really, really cool stuff could come from that.
I always found the current entity setup perfectly adequate - the whole ethos of Source is that it gives you the basic building block entities that each do a job, and you then hook them up together in a map in any way you wish. It's only due to the fact that TF2 has game modes that there's a need to have a specific entity structure repeated on lots of maps (in which case a prefab would work very well).