 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
- When you delete a brush or group of brushes that is part or all of a visgroup and get it back with Ctrl+Z, the brush or group of brushes is no longer part of the visgroup.
- ] works fine to rise the size of the grid, but [ isn't working to make it smaller. Yeah, i know the issues with Half-life's map format, but ''parsing error in line 8'' happened when using JackHammer's provided compilers Couldn't get to make this show again. Found another error where it insisted on using the textures from quake/id1/quake.wad which is non-existent, but comes as an entry by default. Deleted the entry on the textures window and worked fine, so it isn't important. * On the suggestions side, i have three. - Please add an option to block the up-down-left-right keys from moving the selected brushes. It is an useful feature indeed being able to move them that way, but half of the time you are moving them without noticing, when using those keys to move the camera around or when doing other things. I never had to check so many brushes that where causing leaks or other compiling problems in a map since WC 1.1.2, and those aren't exactly good old memories. - Isn't there a way to make it so the compiling window doesn't freeze while compiling when you go to another window? I know that the compiling is still going on and that it is an issue that has been happening since WC1.0, but it would be useful to check other things that don't ask much for the processor (looking at tutorials for example) while it is compiling and still being able to check how it is going or if an error that doesn't stop the compiling happens, when doing long (many hours long) visings. The other option would be using Necro's compiling GUI which hasn't this problem, but it is an external program. - Also related to compiling, and an old WC issue too: clicking on the extra option for compiling and adding -extra in the expert mode doesn't do exactly the same. I don't know what happens, but some features of some compilers don't work (colored lighting for example). I know that this should be directed to the person who made the compilers i use, but it is a strange thing that there is a difference in something like that, and think it could be easy to fix. I hope one day developers of all compilers will add map220 support for JH needs At least all Quake compilers that have been around for 10-15 years or less do that already. Quake 2 ones don't as far as i know. Don't know about Quake 3 ones. * WizardExt: - Add shortcut Alt+a/s to decrease/increase grid size. (my biggest annoyance at the moment, because there is no quick way to change grid size) There is one already. ] and [, but [ doesn't seem to work at the moment. - Moving an object that is off-grid, should snap it on to the grid once you start moving it. Better not, there is some times when you want the brushes to stay off grid, for example after rotating a group of brushes (the box where the group is can be off grid, but the points of the brushes themselves are are still on grid. Better give the mapper the freedom to choose, as there is already a ''snap on grid'' option with its hotkey that works fine for that. Good luck with the contest. In three days we will get to see the maps and how they went. @Cocerello
Thank you, I had lots of fun! about grid-size shortcuts.. [ works, aswell as -/+. But I really appreciate recent additional shortcuts for decrease/increase grid that exist in recent Hammer versions. Something that speeds up workflow, very accessible. about moving objects that are off-grid: Rotating something won't snap it to the grid. The only snapping then would be the angle snap. I am not following you fully, how can you have the group being off grid and the brushes making up the group being on grid? Groups don't function that way? Anyway, the way I suggest is how it works in recent Hammer version. And there is freedom to choose; if you want to move something off-grid, you can toggle off "snap to grid" or move objects using Alt pressed. A more advanced suggestion:
A lot of the more advanced rotation operations require making a large brush that can be used to fake a pivot point for the rotation of a group of objects. It would be awesome if, say, you could middle click in the viewport and define a temporary pivot location. Then all scaling/rotation operations happen around that point rather than the center of the selected group of brushes/entities. Allow for a quick way to clear that temporary pivot and it will revert to the current way of doing things. Please? :) About [, i'll check it more in other computers. Maybe it is an issue of incompatibilities between the languages in keyboards or OS incompatibilities, who knows!
WizardExt I haven't explained myself well: it is more like sometimes is better to have them off-grid for some calculations when vertex manipulation is used a lot on a rotated brush in a non 45 or 90 angle, even more with some more complex brushes. Check the brushes around four of the spawn points in my first map submitted for the contest when we had them published to see an example of where i needed that. It has to do with using irregular prisms with quadrangular base for some complex structures. And there is freedom to choose; if you want to move something off-grid, you can toggle off "snap to grid" or move objects using Alt pressed. Where can you toggle off it? Haven't seen that, and want to use it. I haven't explained myself well again: Yeah, right now there is freedom, but if you make it so they snap automatically when moving like i think you were asking for, the mapper loses the freedom to choose. But my words are invalidated if you say there is an option to revert it back aside from Ctrl+Z. TB2 uses a handle that you can freely place by dragging its center point around. It works quite well, people have done some cool (and to me, unexpected) stuff with it:
http://t.co/xVHumtHPyN http://t.co/Mwd5t26ILQ Never saw TB in action. I'm scared of it because it doesn't have 2d viewports, for me it's the same as a car without a steering wheel. Althouth I believe such car can be very handy. :)
Btw, JH has an ability to rotate a brush around a vertex pivot. Just enter Vertex Manipulation mode, select all the vertices, press RMB on some vertex and drag it. I got convinced by people that 2D views are better for some things, so TB2 will have them, too.
The vertex pivot thing is interesting. Which axis does it rotate about? Maybe this would also be useful for brush edges so that you can easily rotate a brush about one of its edges. I think someone requested that feature for TB a while back. The choice of axis is straightforward.
After some tests in JH I've remembered that rotation pivot is arbitrary. ^^ Just click any point in 2D with RMB and rotate the whole thing aroung it. Scaling relative to an arbitrary pivot is also possible. Hit Alt+E in vertex manipulation mode and drag the blue circle (this is a pivot). Well, yes, I often forget the things I've coded some time ago.. :( Are you sure? If I select some brushes and try to right click in the viewport, I get the context menu
https://dl.dropboxusercontent.com/u/161473/Misc/2015-03-31%2009_39_27-Jackhammer%20-%20%5BQMapJam.jmf%5D.png Please make selections part of the undo buffer. It's maddening when you deselect something, hit undo by reflex to get it back, and it undoes something you did earlier instead.
Selections and object properties (which are currently also non-undoable) will blow the undo buffer up.
Have a limit. Most apps will give you an option where you can set the number of undos you want. So if someone has a monster machine, they can jack the number up higher.
Also, something I've seen done is clearing the undo buffer whenever the map is saved. ToeTag does that... Also, there really is no need to limit the undo buffer. You can collate subsequent actions into one (for example, you can collate 5 subsequent transforms if they happen within a certain amount of time) and the actual information you have to store is quite small for most operations in a level editor.
>>clearing the undo buffer whenever the map is saved
This is the most evil feature I've ever encounetered. Once I've lost my work in Excel after occasional Del followed by Ctrl+S instead of Ctrl+Z! Whether it's more or less evil than only including certain actions in the undo/redo buffer is a debate for another time then. ;)
Well, excluding selections from undo buffer can't be fatal as compared to deleting or modifying objects, you can always select again and you can't break the work with unwanted selection.
As for entity properties, well yes, this is evil. But afaik VHE doesn't undo them too, and I was too lazy to implement it since it doesn't fit well to my undo system. :( I have always been able to undo everything I've done with Jackhammer after saving a map with no problem.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |