The Crowbar Editor Testing Thread [a0.02]

The Crowbar Editor Testing Thread [a0.03]

The deadline for my final year project report is fast approaching (21st April), so now has come the time to see if I can get some real-life geeks to test out the Crowbar editor so that I can evaluate how successful it's been so far.



What stage are we at?
I took the editor on as an FYP at university basically because I'm terrible with projects and usually burn out before I finish them, so I wanted to have to work to a deadline and be required to have something to show for it at the end.

The current build is very much a prototype: for the past 7 months I've been muddling through and learning things as I go along, so I wouldn't say it represents what the final product should look like, especially since I'm stuck with an outdated 3D framework until the end of this term. It does, however, give an idea of how the core functionality should be expected to work, being based around a hierarchical object structure.

What the hell is a "hierarchical object structure"?
In Hammer, you can only create brushes in "world space": translation, rotation and scaling are all done in world units. In Crowbar, you create brushes in world space by default, but you (will ASAP) also have the option to "parent" them to another object. This is very much like how parenting works in Source itself: when the parent moves, its children move with it; when the parent rotates, its children rotate relative to it. What this means for the editor is that if you parent brush A to brush B and then rotate brush B, you will still be able to translate, rotate or scale brush A in its own local orientation, instead of being restricted to only doing these operations along the world axes. (In Hammer, there's no way to make a brush "longer" on one axis, once it's been rotated to a weird angle, without rotating it back to a convenient orientation first.)

What's in this test release?
As of right now (alpha 0.02), the functionality is pretty basic. If I can implement a few more things over this weekend then I'll update it, but I've been gunning for a bare-bones implementation that demonstrates the basic operations that we're used to in Hammer. The implementation for object hierarchies is there, but you can't manipulate them through the actual UI yet.

The salient points are thus:

• There are only two viewports. This appears to be a limitation of the current 3D framework I'm using - if I tried to add more 2D viewports, all the brushes in the subsequent views would start doing freaky things like rendering as separate copies of the grid and crashing the program if you zoomed in too close. As I mentioned above, the 3D framework I'm stuck with (I started using it on September before the newer version had come out and it's too late to change now) I will be updating once I've finished the project assignment and am back to working on my own schedule, so it's just for this prototype. The 2D view does allow you to change the orientation between side, front and top.
• Select, Create Brush and Face Edit tools are available. Translation and scaling of brushes are available but not rotation yet. No other tools as of right now.
• A sample set of textures is packaged with the editor. It currently reads PNGs from the textures directory where the executable is located. If you want to test out more textures from TF2 or any other game, convert them to PNGs and put them in the correct subfolder. Rendering of transparent/translucent materials may be a bit wacky because I haven't tested it yet, but by all means give it a go.
• Maps can be exported to VMF with "Save As", but not read yet. The exported VMFs should be loadable in Hammer (ie. tell me if they're not).
• There is no undo/redo yet.

Controls are:

• Z toggles mouselook mode in the 3D view.
• W/A/S/D control the 3D camera. Q and E move it up and down.
• Space will allow you to pan the grid in the 2D view.
• Mouse wheel zooms the 2D grid in and out.
  Tab toggles visibility of the 2D view.
  Left click selects, right click applies the current texture when using the face edit tool.
• When translating brushes, Alt disables grid snapping and Ctrl enables half-grid snapping. Snapping is applied to the brush origin (the square in the centre of the brush in the 2D view).

Urgent things I would like to address ASAP:

• Shift-dragging should clone the selected brushes.
• Translating a group of brushes will cause them to "ripple" when snapping is enabled, as each brush snaps individually to the grid. Snapping should happen relative to the entire group, not individually.

Where can I download it?

• Alpha 0.03 (Windows 32-bit)
• Alpha 0.02 (Windows 32-bit)

If people want I can also make an OSX version available but I don't have any experience running those applications outside of the IDE environment yet, so it may require a bit of research and testing for me to get it working.

What sort of feedback would be useful?

Any feedback, positive or negative, is much appreciated. I've been coding this for so long that I've lost any semblance of objectivity, so I really do need opinions of genuine users in order to know what works and what doesn't.

Specifically, the following are helpful:

• Bugs - If you find anything that blatantly doesn't work as it should, let me know what it is along with the circumstances and steps to replicate it.
• Comparisons against Hammer - Are there things you think the editor (even at this very primitive stage) does better than Hammer, or things that Hammer accomplishes more efficiently?
• Functionality/usability - Are the editor functions straightforward to use? Are they frustrating? Even at this early stage where the operations are purely utilitarian, it's useful to know in what direction to proceed with regards to the most efficient way to translate user input into editor operations.

Finally, just throw stuff at the application and see what crashes it. Let's stress-test this.

 

Good start.

Windows 8.1

 

That picture's not showing up for me.

EDIT: Wait, I think I know what's wrong. Zip's been updated.
EDIT2: Having said that, it seems to be crashing on startup on the machine I'm now testing it on. Looking into it.

OK, it's now confirmed working on a PC that's not my own, so we should be good to go.

 

I somehow made an infinitely thin brush and can't resize it.

The application is raping one of my CPU cores, add a frame limiter?

"Subtract" selection does "add".

Toggling the second view while in mouse control causes the mouse control to jump.

I somehow got this brush to render as if it were in the wrong position with the face edit tool: http://i.imgur.com/RSFBro2.png

The brush creation tool seems to "forget" the tentative shape along the axises other than the one being viewed.

---

Zooming is more "vicious" than hammer and becomes nearly useless.

The 3d hotkey being p makes it very difficult to quickly switch back and forth of it.

 

Keep in mind that other keyboards have some letters mixed around. E is a better key for "move down".
Mouselock in 3D is quite fast.
I hope there will be a way to have 3 2D views at a time.

 

We will most definitely be able to have 3 2D views, just not at the moment.

 

Please make the controls more similar like Hammer so changing between the two won't be as strange

 

And fix problems with controls with feedback.

 

Have made controls W/A/S/D/Q/E with Z to toggle and that does seem to work better, so I'll stick to that.

Working through the other bugs - adding resize handles to the brush creation tool has been difficult (I never said the code was pretty) but I'm almost done. The rest should be relatively straightforward.

 

Very nice project.
The name is a bit confusing. There's already the crowbar model thingy around. If you want this to become widespread at some point, think about changing the name, especially now since it's really early in.
I see this not necessarily as an opportunity to have a different editor, but a fixed one. Decimal loss issues and broken dialog windows really piss me off, I'm sure everyone here has his own personal grudge against the hammer editor.

 

Actually this project's been going since May 2013: http://forums.tf2maps.net/showthread.php?t=21178 I was slightly irked when I heard about the other tool with the name Crowbar, but I guess that's my fault for not actually getting out there first. I've had my GitHub repo and all sorts named since 2013, I'll have to see how easy it'd be to change all that.

Good news is that all the bugs I've had so far I've managed to fix. When I get back onto my laptop with Windows on it I'll compile a revision.

 

Updated the first post with alpha 0.03.

 

Grudge puts it very lightly.

 

Hey ! I remember learning about this project back in 2013, was wondering how it was going. On the one hand, it's still in Alpha, and I'm still stuck with Hammer. On the other hand, it's still being developed, which not what you'd expect reading the first few pages of the crowbar thread. So, congratulations for being more awesome a developer than anyone else I know !

Otherwise, I haven't tried your editor yet, but I have two suggestions :
- Add customized inputs. Seriously, you MUST add those. Hammer is kind of a pain for me because its inputs are optimized for a qwerty keyboard and I have an azerty one. I know it's easy to switch, but it still annoys me. I don't know why (almost) nobody would think of making a 3D PC game with fixed inputs, but a 3D editor with fixed inputs is apparently okay.
- If the name thing makes people confuse the Crowbar editor with the Crowbar project (I don't see why, but maybe it could happen), maybe call it the Red Crowbar or something ? It's not as catchy as Crowbar, and there's not the same resemblance Crowbar/Hammer, but it's still better than completely switching names.

 

You should call it something steam related just like valve and steam pipe.

 

There will be customisable inputs, but at this point they're not critical (and would require me re-coding a non-trivial amount of the prototype) so I'm going to leave them for when I get a proper build down.

I'm going to need to do some evaluation soon, so if people could provide me with some feedback on how the prototype compares to Hammer in terms of usability, functionality, etc. then that would be useful. I originally wrote up some 1 to 5-scored questions but they might not be as applicable as I intended since this is only a very basic prototype and doesn't have a lot of the functionality I originally intended.

 

Hammer doesn't have to do with valves or pipes or plumbing, though. A hammer is a tool and so is a crowbar. Albeit a crowbar is usually used for destroying things, rather than assembling...

 

I think "Pliers" will be the appropriate name, since it fixes what hammer does wrong.

But it doesn't sound as catchy as "Crowbar"

 

Right, my project report is in next Monday, so if any of you have comments on how the prototype compared to Hammer in terms of functionality/usability they'd be much appreciated while I still have time to write them into the document. After I've sorted out the rest of the things this term (including this report, a presentation and poster, the rest of my coursework and homework, my exams...) I can finally upgrade to the newer and better 3D framework and look at converting the prototype into a proper application.

 

Call it Sledgehammer and Sickle then?