Crowbar - an open-source editor

[Kiddnils]

Just saying how much I like the idea of an open-source level editor. Good luck guys!

 

[NoodleCollie]

Good news: after my attempt at a recursive splitter failed miserably (infinite recursion stack overflow failure at that), I've found that it is possible to dock a QDockWidget in the centre of a control as opposed to just around the edges of a window. Needs a bit of coding to get the position of the dock widget when it's being moved and check whether there's a control underneath it to dock to, but with any luck it should then be possible to implement something similar to the tab docking system in SFM/Visual Studio.

 

[Lampenpam]

When I edit the geometry of displacments in hammer is miss two things:

1: changing the axis by a button on the keyboard.
since I hate to always klick on the list and select the axis, especially when I often switch between X and Y.

2: Sometimes it would be neat if you could lock vertisies on a displacments.
So if you are editing the geometry with a greater range, this vertisies wouldn't be affected.

 

[WhyNott]

Hay, you actually called it "Crowbar" after all!


So one day, when i will be an old man, i would sit with my grandchildren near the chimney, and say to them:

"Ya know, once upon a time, i named myself an editor that revolutionised Team Fortess 2 mapping!"


And they would say: "Grandpa, wtf is team fortess 2?"

 

[Fish 2.0]

Something to add to your feature list;

Model importer/compiler

Open up model import
-select .smd model
-select textures
-set skins for model/texture
-UI for qc file creation
compiles it and them boom, it's in game.


Also built in compiler like pakrat would save people an extra step too, so maybe an option for that at later development stages?

 

[Toxindude]

Would it be possible to have a tool that punches holes in brushes. That way we don't have to go in and clip the crap out of it. Or draw arch's to fit around a curve.

 

[Ælement]

I would love a way to move a group of brushes with respect to a single chosen vertice. That way, it would be easier to move things like buildings and make them snap perfectly to the grid again.

 

[Pocket]

Ooh! Tools like arch and cylinder should be set up to orient themselves to whichever 2D view you draw them in. So if you're in the top-down view, for example, it'll be upright.

 

[fubarFX]

oh, and it would probably be handy to make the editor keep track of custom content so we can make paking part of the compile process (with bspzip.exe). that would really arouse me

 

[Terwonick]

I suggest you worry about only the basics right now and get a working editor with the ability for plugins, release that and then produce plugins for arches, custom content, etc...

 

[NoodleCollie]

Yep, that's what I'm thinking of. I've been looking through the Hammer sources and looking at the way they set up objects - everything seems to be subclassed from a base CMapAtom class and rendering looks like it happens in an octree (I looked them up and they're damn interesting). I'll look into architecturing something conceptually similar.

 

[Seba]

When I edit the geometry of displacments in hammer is miss two things:

1: changing the axis by a button on the keyboard.
since I hate to always klick on the list and select the axis, especially when I often switch between X and Y.

2: Sometimes it would be neat if you could lock vertisies on a displacments.
So if you are editing the geometry with a greater range, this vertisies wouldn't be affected.

The first one is usually solved by using the "perpendicular to face" setting and having a displacement cube nearby; that way you can just shift-rightclick (I think that's what it is) any face of the cube and instantly be working in any of the axes. You can also rotate the cube quickly to set custom angles easily.

The second one may sometimes be accomplished by doing whatever adjustment you want, then using the "raise to" option set to 0 to reset the vertex position.

Something to add to your feature list;

Model importer/compiler

Open up model import
-select .smd model
-select textures
-set skins for model/texture
-UI for qc file creation
compiles it and them boom, it's in game.

Wall Worm's model tools kinda do this, except you create the entire model in 3dsmax instead of exporting into the Source editor.

Would it be possible to have a tool that punches holes in brushes. That way we don't have to go in and clip the crap out of it.

Carve already does that (albeit poorly).

Ooh! Tools like arch and cylinder should be set up to orient themselves to whichever 2D view you draw them in. So if you're in the top-down view, for example, it'll be upright.

Doesn't the block tool already do that? I know it does for me.

 

[Mick-a-nator]

I haven't been on these forums in a long time (almost a year? Wow... Hi there strangers) but I'm so glad I did today and chanced upon this thread. This is just the sort of project I'd like to get my teeth into. Of course, this is your baby and I don't want to feel like I'm taking that away from you, but I've downloaded your GitHub code and Qt5 so I can look at them and understand what you've done. I'll say though that I'm mostly excited by the tool/plug-in possibilities since I'm a mathematician.

A few notes on things I though of while reading this thread so far:

UI
Personally, I think the main goal should be getting the most workspace efficiency, i.e. maximising the viewport/toolbar ratio. Basically, Hammer's UI is fine, just a bit old really. I'd say no to floating, GIMP-like toolbars and yes to something tab-based that can be hidden at will. Having plans for plug-in tools means their interface needs to be considered too. Since there could be quite a few available at once, something like Blender's spacebar search would be sensible in my opinion.

Tools and Plug-ins
Clearly a great idea and a much needed feature. I have no idea how one goes about implementing a plug-in system so I don't know whether you'd have to at least keep it in mind now or if you could just add it later. As for the language, I personally like python, but Blender python sucks and lua seems more suitable. Not my field, just my thoughts on that, for what they're worth.

My last note would be that everyone seems to be discussing the design, mainly the UI, as though it needs to be done right first time or else it will fail, but I'm sure you know that's not true. I don't think anyone actually believes things need to be done right straight away, but it seems everyone is being stuck up on getting the idea right before any code is written.

 

[TehStoneMan]

My last note would be that everyone seems to be discussing the design, mainly the UI, as though it needs to be done right first time or else it will fail, but I'm sure you know that's not true. I don't think anyone actually believes things need to be done right straight away, but it seems everyone is being stuck up on getting the idea right before any code is written.

I would agree with this. Get the base code working first, then make it easy to use. Even the best UI would be useless if the software it's attached to doesn't work. On the other hand, quite a few users will put up with a WIP UI if it's a superior tool, especially if they know it's being actively worked on and improved.

 

[NoodleCollie]

I'm more than happy for other people to get involved - the more the better, since we'd be able to get more done in a shorter timespan. I'm not able to do very much as of right now because I'm home and on a secondary computer so don't have access to all my documents, but what I had looked at before my exams was how plugins would interface with the core program. In the plugin manager definition right now (make sure you've got the workbench branch, the master is very out of date and I was planning to use it only to hold stable versions) I've noted down types for document, render protocol, tool and serialisation protocol plugins but I'm thinking of reducing this down to just the tool and serialisation types, at least until I know more accurately what will be required and/or available for plugins. Tools will obviously be things like the picker, clipping, vertex editing and whatever else your imagination can come up with, and serialisations will refer to what file extensions maps can be imported from/exported to and how the map objects are encoded into these files.

As far as I know currently, Qt plugins are essentially DLLs that the application can load and which implement at least a basic plugin interface through which the application communicates with them. Qt also has its own scripting language but I haven't poked around at that yet. There is event support, so I was thinking of utilising that for plugins to use in a similar way to SourceMod.

 

[Layl]

I've been skimming a bit over the thread and what seems to be missing in the discussion so far is actual talk about the architecture of the source code. Did I just miss a page or is that something that's going to be discussed later?

 

[NoodleCollie]

I think it needs to be discussed (sooner rather than later) but it's not very interesting to anyone but coders, hence discussion has been lacking. I've done bits and pieces on paper but I'm thinking it might be a good idea to have a separate folder in the code where documentation of such ideas could be kept as well as on this thread.

 

[Layl]

For the map creators with no programming experience here, just to explain my previous post:

When working on a software project, it's always best to start designing the overall architecture of the project, together with things like gathering requirements. Discussing how a UI should look while the architecture isn't designed yet is like choosing in detail how your spawn room is going to look before having and idea what the rest of the map's layout will be like.

Often you will hear beginner programmers say stuff like "We don't need this useless stuff we'll just get it done", which results in the software project failing spectacularly and ending up on the DailyWTF.

 

[Layl]

Oh, one suggestion I would like to add: XML based file save format
Would make it a lot easier to use things like Git, SVN or Hg with this.

 

[YM]

I have never heard of anyone having 2 vmf's open side by side before. I don't think anyone works like that (not many at least). I use ctrl+tab to jump between files.

I do for instances:

Work in the instance with a smaller view for the main map and then just mouse over it to update. Reeeaaaalllly nice for instances that don't contain everything you'd see in the compiled map.