I was randomly browsing the vdc and found this https://developer.valvesoftware.com/wiki/Hammer_Feature_Requests
Crowbar - an open-source editor
- Thread starter NoodleCollie
- Start date
My Qt seems to have fucked itself lately - the compiler just crashes when I try and build anything. No idea what's happened, reinstalling doesn't seem to fix it.
Mick-a-nator
aa
- Feb 18, 2009
- 640
- 630
I get some message about the debugger not being set up or something, but no indication of how to do that. Same prob? I'm getting errors on quite a few lines of code to do with the plugin manager. I'm gonna do a pull request soon with some basic file IO which also fixes some of them, but I have no idea what's causing some of them.
A good read for anyone programming/designing apps, not just people looking to code for this project, is Getting Real, which is free at that link (you have to sign up for a mailing list, but you can unsub once you have the pdf). Considering how everyone here keeps going on about features, I think it's relevant, to get you all focused on what matters.
That's a HUGE list that needs to be ignored for as long as possible. Skimming over it, most items are easy with plugins or are easily solved with careful design of a UI that doesn't suck.
A good read for anyone programming/designing apps, not just people looking to code for this project, is Getting Real, which is free at that link (you have to sign up for a mailing list, but you can unsub once you have the pdf). Considering how everyone here keeps going on about features, I think it's relevant, to get you all focused on what matters.
My errors are looking like this:
If I disable jom through the options then nmake crashes. Everything was working fine when I was up at uni.
EDIT: Reinstalling QT and Visual Studio Express 2012 seemed to fix it.
If I disable jom through the options then nmake crashes. Everything was working fine when I was up at uni.
EDIT: Reinstalling QT and Visual Studio Express 2012 seemed to fix it.
Last edited:
Just done a commit for today's messings - I've created a logging window which holds a text editor that prints read-only text. The application and any of its plugins will be able to print log messages to this window (which is enabled using -debug on the command line) and messages will get logged to files. Eventually I'm planning to implement some kind of console functionality into this window - I thought it would be a good idea to have a good system in place for debugging and probing early on.
EDIT: Been probing into OpenGL now and it appears Qt ships with a very outdated/incomplete OpenGL library, so a lot of identifiers are missing. I'm trying out libQGLViewer to see if I can get OpenGL working with that.
EDIT: Been probing into OpenGL now and it appears Qt ships with a very outdated/incomplete OpenGL library, so a lot of identifiers are missing. I'm trying out libQGLViewer to see if I can get OpenGL working with that.
Last edited:
Update: Just done an arseload of work on re-implementing the properties system I had in C#. C++ macros have been extremely helpful in cutting down on the square miles of boilerplate code that entails.
(For people interested in the technicals: the majority of the work was understanding how to get around the limitation of avoiding multiple inheritance from QObject. Slots (which connect programmatically to signals similarly to Source's I/O system) require the Q_OBJECT macro in the class, and if you implement slots in an interface class and then inherit from that in another class which already inherits from QObject the compile will fail. I managed to find http://doc.qt.digia.com/qq/qq15-academic.html#multipleinheritance online which explains the workaround: a wrapper class which uses the Q_OBJECT macro binds the slot functions (and any other functions you specify) to the functions of your interface, thereby linking slot wrapper::f() to non-slot interface::f(). Since only the most external function needs to be defined as a slot, it simply means interface::f() will be called when a signal is sent to slot wrapper::f(). If you want to hook up a signal to a slot on the derived object that inherits from the interface, instead of inheriting the derived object from the slot implementer (and so causing a multiple inheritance error for QObject) you give the derived object the wrapper to instantiate in its constructor and you hook your signal to the slot on the wrapper object instead - the wrapper essentially becomes the informal "interface" that you now communicate with. Therefore, if you want to bind a signal to a slot from the IBaseProperty interface (basic string handling etc.) then you call object.slotsBase()->slotname(), and object.slotsFor()->slotname() to access a more specific slot from the type-specific properties.)
(For people interested in the technicals: the majority of the work was understanding how to get around the limitation of avoiding multiple inheritance from QObject. Slots (which connect programmatically to signals similarly to Source's I/O system) require the Q_OBJECT macro in the class, and if you implement slots in an interface class and then inherit from that in another class which already inherits from QObject the compile will fail. I managed to find http://doc.qt.digia.com/qq/qq15-academic.html#multipleinheritance online which explains the workaround: a wrapper class which uses the Q_OBJECT macro binds the slot functions (and any other functions you specify) to the functions of your interface, thereby linking slot wrapper::f() to non-slot interface::f(). Since only the most external function needs to be defined as a slot, it simply means interface::f() will be called when a signal is sent to slot wrapper::f(). If you want to hook up a signal to a slot on the derived object that inherits from the interface, instead of inheriting the derived object from the slot implementer (and so causing a multiple inheritance error for QObject) you give the derived object the wrapper to instantiate in its constructor and you hook your signal to the slot on the wrapper object instead - the wrapper essentially becomes the informal "interface" that you now communicate with. Therefore, if you want to bind a signal to a slot from the IBaseProperty interface (basic string handling etc.) then you call object.slotsBase()->slotname(), and object.slotsFor()->slotname() to access a more specific slot from the type-specific properties.)
Last edited:
I'm a C programmer, and I use OpenGL to make contributions to Blender 3D, and I am working on my own 3D app geared less towards organic/complex models like people and more towards modeling architecture. It is almost like Hammer, but it operates based off of procedural generation. I don't want to talk about it like I finished it, though. As far as yours goes, it probably will go farther than mine, but a word of suggestion: use OpenGL for the GUI, don't use Qt.
You mean rendering the controls in the OpenGL window as opposed to Qt controls? Is there a specific advantage to that?
I'd be willing to do icons or graphics, if you need. This is a project I'd love to see happen - Hammer is a tad poop.
(You can see some of my work on this site, though its mostly level design or textures http://elitetreacle.info/)
(You can see some of my work on this site, though its mostly level design or textures http://elitetreacle.info/)
I'm sure we'll need some graphics done at some point - toolbar buttons and the like.
Lates commit - I learned Doxygen! It's awesome and now the code documentation is up-to-date.
Lates commit - I learned Doxygen! It's awesome and now the code documentation is up-to-date.
What sort of style are you going with for the UI? Modernised versions of the Hammer icons, or something different? I'll start on designing things this week.
To be honest I haven't really considered it yet because I'm still pretty early on in the process. The only thing that comes to mind instantly is that since we've gone for a Half Life-themed title in Crowbar, it might be worth continuing that theme in the buttons (eg. entity logo is a headcrab NPC, stuff like that). I think it might be possible to change the whole style scheme of a Qt project too, so we're not just limited to button icons.
EDIT: It is - see http://qt-project.org/doc/qt-4.8/stylesheet.html
EDIT: It is - see http://qt-project.org/doc/qt-4.8/stylesheet.html
JUST HAD A GREAT IDEA that I need to write down so I don't forget it: Have a section under "Help" that brings up content from TF2Maps forums and tutorials in an integrated window? Would obviously be best if there were game-specific menu entries to bring up content for different games (maybe provide this functionality via plugins), but I was thinking it would be good to make it easy to look up topics on how to accomplish a certain aspect of map-making and follow things along with as little disruption as possible.
So you're thinking of having multiple themes? That's cool. Would you mind sending a list of features that aren't in Hammer that you'd want icons for (I'll take it as read that everything that has an icon in Hammer will have an icon in Crowbar)
Hammer already links to the Valve Developer Wiki from its help menu, and I'd like to think that offers more comprehensive guides than we do. In particular, it covers more than just TF2. And in either case, all of the instructions are written with Hammer in mind, not this new tool you're making. Let's wait until it actually exists before we worry about writing tutorials for it, let alone whether to link to them from the program itself.
As far as visual style, I was kind of implying when I suggested Qt that it ought to visually complement Source Filmmaker. But that still leaves a lot of leeway for getting creative with the theme.
Oh, I see! Yeah, that'd look pretty good! (though the idea of being able to change theme is one I'm sure some would appreciate).
That reminds me of another thing - it might be nice at a later stage to have new polished tool models like the camera, player spawn, etc.
Deodorant
L6: Sharp Member
- Oct 31, 2011
- 263
- 214
I don't know if this has been mentioned before by me or by anyone else, but I think a measure tool would be really neat; Like, you click on one of the 2D views to place a start point, and when you move the mouse there's a straight line going from the point to the cursor and a little number that shows the current length of the line in HUs. It would be nice for measuring distances at different angles than those of the grid.
Yes. It cuts down on executable size VERY drastically, and ENSURES complete compatibility, consistency, and functionality with many systems (not to mention performance, although Qt is very well optimized). Yes, Qt is cross platform, but every major desktop OS out there has at least some type of OpenGL implementation on it. Yes, it requires more effort, but is it worth it? It all depends. Qt is available on Linux, but it is yet another hassle to handle. Since Valve is porting their collection to Linux, it would only make sense to make a Linux version of Crowbar. Also, you will be using OpenGL and/or DirectX, anyway for the viewports, among other things. There is no use in making another dependency and increasing your exec size.
As far as specifics go, it really comes down to buffer operations and projecting textured quads orthogonally to get a UI running in OpenGL (easier said than done, especially when trying to play along with pixel shaders, but just take a look at Blender 3D, there is no GTK+/Qt code in the software, so it can be compiled more or less from the same source files for Windows, OS X, ALL Linux distros, all 3 BSD's, even Sun's Solaris, and all within 50mb, that being a full 3D movie studio WITH a Python interpreter).
IMHO, it doesn't matter which you choose. Qt is more convenient, while OpenGL is cooler and more efficient. It's all up to you.
^My point is proven.^