Sledge (Hammer Alternative) Alpha Build Created 10 years ago2013-07-27 02:24:39 UTC by Penguinboy

That has been reported several times but I've been unable to replicate it. Can you provide more info?

What renderer are you using? Does it happen every time, and on every VMF? Can you send me a VMF file that has the issue?

Changed Opengl 2.1 to opengl 1.0 Display lists and its fine now..
and ye it happened all the time and with every vmf

my gpu is "radeon hd7750 2gb"
it should have opengl 2.1 compability aswell but im actually not that sure..

Your card should definitely support OpenGL 2.1, it's possible there's an issue in AMD's OpenGL code...

Unfortunately the HD7750 is a little too expensive for me to buy for testing purposes (about $115), I will have to see if someone else is having the same issue on a cheaper AMD card.

Let me know if it happens again now that you've switched to the display list renderer, that could mean something else is going wrong.

I don't think that issue is directly related to videocard model. Here's the first test map I've created in Sledge (very fascinating, I know ):Looks like in some cases world/face alignment is not saved. Sadly, I am unable to reproduce this issue. Oh, and my videocard is GeForce 450 GTS

Darn, that's too bad
This is probably the most-reported bug so far, and I've never seen it actually happen! Very annoying

it also happened when i shift dragged object..
copy was fine but texture on original brush messed up

my laptop has a mobility Radeon HD5650, other than the bugs I have noted, it works fine. I haven't experienced the clone bug.

Looks like using "Make Hollow" command with negative wall width leads to this issue. The texture alignment looks fine after performing the command, but is messed up after saving and then reloading the map.

People still use the hollow tool? Euw...

That's almost as bad as the carve tool.

???
Hollow is fine. How could it possibly be almost as bad as carving?

If you use it on something other than a rectangular prism

"Make hollow" actually works by creating a clone of the object, resizing it to be smaller (by the selected wall width, on all sides), and then carving the smaller clone into the larger original.

It's literally equally as bad as carving, aside from the fact that it generates the carved solid for you based on the selection.

Add a warning: "Using Carve and Hollow tools voids your warranty"

Nah. They are just tools to get the job done. If you use them, great. If you dont, great! If I was opinionated on carve I would have just left it out

I'm having trouble starting a new map with a configuration I made today. I have an older one for a different mod (sven-coop) that works perfectly fine, but whenever I try to make a map with the new one, I get an error message.
I'm using the latest build, and the configuration is set up as a goldsource mod in sledge.
This also occurs when opening a .vmf created in the other config in the new one.

Can you remove your WAD files and add them back one-by-one? One of them looks to be causing the error.

Alright, will do and report back.
(Guess nobody else had to file error reports today, that's a good sign. :P)
EDIT: Yup, removing the custom WAD I had made fixed the problem. Guess it's corrupt or something. (Or maybe it's smaller than expected? There's only 1 texture in it.)
Thanks for the speedy reply and psychic ability to diagnose errors!
EDIT2: Oh, I understand completely what I did wrong now - I created it as a Quake 2 WAD instead of a Half-Life WAD. Whoops.

now shift-dragged brush textures will mess up.

Next problem is, if i select alot of brushes and hit and hold space then mouse click to move camera it deselects everything and brush where my mouse was on that time get selected instead.

I haven't managed to get the texture bug when shift-dragging either :/
Does it happen every time? Is there any info you can provide that would help me reproduce the bug?

okei i payed attention to this and if i shift drag a brush i already shift dragged then it happens. original brush is fine i can shift drag it as much i want and its fine.

Made video about that: https://www.youtube.com/watch?v=hAlSZWEu1Fs

In the meantime, here's another version of my patch.
It's for revision 438, it contains changes from the previous one, and it adds the following:

1. Brush vertices are now rendered in 2D views (modern renderer only).
2. Selection box is rendered as a dashed line.
3. [Fixed] Only 3 bottom resize highlights of selection box were rendered.
4. Selection box font size is now the same as entity name font size.
5. Decimal part of selection/selected brush size is now shown only when it's not 0.
6. Entity name text is now horizontally centered on entity's location.

That's how these 6 look like:7. Texture Application Form: you can apply textures to selected faces by double-clicking on a texture in both texture lists.
8. You can now select stuff while moving 3D camera using Space+WASD keys.
9. Settings form -> Game Configurations ->Saving: "Map Save Dir" and "Autosave Dir" Browse buttons were missing Click handlers.
10. Make Hollow: "Select wall width" window setting can now be applied using Enter key.

Also, a couple of questions:
1. Are there any chances to get the changes I made into the trunk? Or a better solution would be to make a separate branch (and, probably, a separate thread for it)?

2. I'd like to add Quake map support. That would require adding Quake model loaders (Quake mdl, MD2 and MD3) and Quake pak support. Can you outline the steps required to implement this? Or is it too early to mess with right now?

2. I'd like to add Quake map support. That would require adding Quake model loaders (Quake mdl, MD2 and MD3) and Quake pak support. Can you outline the steps required to implement this? Or is it too early to mess with right now?

I love you already, can't provide too much info on the steps as far as Q2 goes texture loading will have to be changed since quake uses .wal files instead of packaging textures into .wad's (Even though there is the pointless q2 .wad format for some reason), love to help with quake support. And yes a new thread is in order.

Actually, if you want a modern Hammer clone with Quake map support, you can try Jackhammer

I'm getting different from expected functionality with the clip tool - for some reason clicking on the clip toolbar button will not cycle through clip types for me - I just get the "keep both sides" option.

@MaxED: I know it's a pain, but the best bet is to submit a separate GitHub pull request for each change. It's going to be difficult for me to merge those changes in when all the changes are in a combined patch, since some of them conflict with my own changes or requirements, e.g:
1- This needs to be a toggle-able option, and needs to be implemented in all renderers (I have a requirement that all renderers must look the same).
8- This actually seems to be undoing a fix that I have just made in the unreleased build, since many people reported it as a bug.

Plus issues with testing as well, and many of them change defined behaviour and will need to be made into toggle settings. I can deal with adding toggle settings (if you don't want to) as long as each change is in a separate pull request so I can review the changes on an individual basis.

Since you don't seem to be familiar with Git, here's a quick tutorial (let me know if more info is needed):

1. Create a GitHub account, fork the Sledge repo (this copies it to your account)
2. Download SourceTree and log into your GitHub account in the "view > hosted repositories" window, after that double click the Sledge repo to check it out
3. Click "Branch" and give it an appropriate name
4. Apply your changes, commit, and push your branch (in that order)
5. In GitHub, create a pull request to merge your branch into sledge master
6. Repeat steps 3-5 for each change

GitHub creates a discussion thread for each pull request, so if I find issues with a particular change I can comment on it from there and we can discuss possible solutions. GitHub has primitive support for SVN but I'm not sure how it deals with branches since they have very different branching models. You can try it, but SourceTree makes it pretty easy to deal with Git.

As I said, I know it's annoying, but it really helps me out a lot when reviewing the code changes - especially to have each individual change in a separate pull request so I can see which code changes are relevant to which features.

As for Quake support: yes please! I have absolutely no experience with Quake 1/2 so I cannot add Quake support myself (without significant investment in learning the engines), but if you have the knowledge of how the Quake mapping process differs from Goldsource, we could probably implement it!

The first step would be to create an issue on GitHub that details what all the differences between the engines and mapping process are. Specifically, stuff like:

• Is mapping/supporting Quake 1 different to Quake 2? How different?
• File formats: Models, textures, FGD, packages (WAD, PAK), game folder structures, different install types (is a Steam install different to a disc install), how mods work, and so on
• Compile process: Same as Goldsource? What compile flags are available? Are there updated compile tools, like VHLT? Where do files get copied after compiling finishes? What flags are required to run the game?
• Map format: Does the Quake MAP format have any differences from the GS MAP format?
• Entities: How does Quake specify entities? FGDs? Hard-coded?
• Different map objects: GS has four basic objects: Solid, Group, World, and Entity. Which map objects does Quake use?
• Any other possible differences!

After that we can discuss the challenges with supporting the Quake engine and how to go about implementing them. I don't think it'll be a huge deal to get the app to support a second engine: I'd need to make those changes when I add Source support, anyway. The difficult part would be creating model/texture loaders for the file formats, and there are plenty of open source projects who have already done that for Quake 1/2 formats, so it should be pretty manageable. Unfortunately HLLib does not work with Quake formats (that I know of), so a package loader for Quake formats in .NET will have to be found, or written from scratch.

@Jeff: The reason is that the feature hasn't been implemented yet >_>
It's on the todo list, though!

Well as long as it's something not implemented yet as opposed to something bugged out, it's fine.

Quake1/2 mapping is essentially the same, .map is similar to HL's implementation with a few differences. A quick search yielded some results:
Q1 - http://www.gamers.org/dEngine/quake/QDP/qmapspec.html
Q2 - http://www.gamers.org/dEngine/quake2/Q2DP/Q2DP_Map/Q2DP_Map.shtml

Im going to outline only Q2 now

There are quite a lot of tools for Q2 available though many are scattered around and hard to find http://home.insightbb.com/~gryndehl/q2compile/quake2.html one of them with sources, i remember using tim's tools but not quite sure about the real name.

Entities are defined in .fgd's also hard to come by

Im not a big Q1 guy so i don't know the specifics of it. As far as textures go over the years i've never seen Q2 use .wad anywhere, textures are defined as .wal and dumped into folders (similar to source materials) either in .pak or in the folder named "textures" in the mod's dir.

.pak format is quite simple as outlined here: http://quakewiki.org/wiki/.pak

Folder structure is similar to hl's with baseq2 folder being what the valve folder is to hl. Every mod has its own folder with a gamex86.dll inside which is the mod's code, any .pak files are loaded from the mod's dir and added to the ones loaded already so overlapping can happen, files in folders have precedence i think.

Model's are in .md2 format with separate textures in .pcx ?
There is an outline of the format somewhere so parsers won't be hard to code. No bone structure in the format so everything is pretty simple.

Textures if i recall right have some sort of flags or maybe faces do, for example making a ladder you need to set a face to be "sticky", there is no ladder entity like in hl.

A lot of info about formats can be gathered from other editors such as QuArK, or the "*radiant" variants.

@Penguinboy: thanks for detailed reply! I'll do as you suggest then.
About change ¹8: it's actually not. I suppose demonstration will serve better than explanation. Here's my Sledge build, located at some obscure FTP.
1. Try scrolling 2d views by holding Spacebar and moving the mouse (you don't need to press any mouse buttons to do this).
2. Try moving the camera in the 3D view by holding Space an using WASDQE (no need to press any mouse buttons either)
3. Try selecting stuff while doing ¹2.

IS and input-output system possible in some way for GS?

If you somehow wrangle in/out support into Goldsource Sledge will literally be the only option for mappers. It's so much better.

Its not really made for that, the only entity that would work with that is the multimanager and multisource, it would be awesome but whats the point of having 1 output and 1 input ?

I was wondering if the FGD can be creatively interpreted for an I/O setup. Even if its just one in and out after all options have been explored, would it make enough of a difference? Could a new FGD be made to improve upon this in some way.

Fortune favors the bold...

For some entities it can be, like func_door's delay before close could be set by another entities out option, but that is just hardcoding.

A nice feature would be to check if the entity you are targeting exists, or have a dropdown list of all entities that have their name set. Like in H4.

Or even knowing what entities target it. Maybe not a complete I/O system, but perhaps something that is a bit more ergonomic.

Didn't Hammer have an option somewhere to draw lines between interacting entities that didn't really do anything?

We can't really do an I/O system as goldsrc is literally a "trigger" system rather than source's multiple output system.

@DiscoStu yeah I think there was that "show connections" thing. If it did work I never used it.

I'm not suggesting we reinvent the mousetrap here, but working with GS entities can be disorienting. When working on those Cap-point and KOTH entity setups, I really wished I had a way to see what was triggering an entity, and what it was triggering.

Then again, does anyone know how what kind of power one can have when you turn SmarEdit off and start inserting parameters that weren't there before? Anyone ever experiment with this?

SmartEdit = EasyEdit

Rim's disorientation gave me an idea:
http://i.imgur.com/nAEz2TU.png

Why not generate such a scheme that would make looking for your entities easier, graphically linking them so that you know exactly what you target.
Clicking on one of these could bring up entity properties with the ability to edit them also showing what the entity is targeting and what its being targeted by. In case of a multimanager it would list its outputs in an easy to edit way.
Also a button to show this entity in the map.

Can still photoshop

Looks like the schematic view in 3DS Max. Its like a graphic breakdown of interrelationships.LOTS of 3d packages have such a view because the rigging and animation can get incredibly hard to look at and understand.

Yeah i was basing this on what the 3D editors have, could be a nice addition to complex entity setups imo.

That looks really cool, but I'm going to work on other more important features first

so PB, I've not even touched engines so I can't comment on anything, but how possible would it be to implement an INCREDIBLY basic light raytracer view? Wouldn't obviously mimic rad but it would give a vague idea as to what the final product may look like without having to compile it.

raytracing is very expensive on hardware and not suited for realtime applications. Radiosity lighting like rad does is less hardware intensive however it would still take time to render.

Imagine you have a big level and you add a wall somewhere now everything has to be rerendered and you are stuck waiting until it finishes. There is a reason we compile

rufee's idea would be tits

Anything with tits is good.

Im tempted to get the source code and make it

New release is out! This release has some nice additions made by users Mozartkugeln and MaxED, so a big thanks to both of them for helping make Sledge better!

Got lots of features here:

Major features

• New Arch brush feature: smooth ramps

• Added experimental 3D rotation widget (currently only available during rotation mode)

• Render entity text in the 2D views (when zoom level >= 1)
• Entity angles are now shown in 2D viewports (when zoom level >= 0.5)

• Viewport window grid layout editor

• Support for multiple viewport windows (multi-monitor support)

• Add feature to capture a screenshot of a viewport. Fixes #149, fixes #97.

Example screenshot:

• Added favourite textures in the texture browser. Fixes #14.

Minor features

• Null textures are not tested during selection when they are hidden. Fixes #147.
• Set the bounding box of model entities to the size of their display model. Fixes #148.
• Clip tool now cycles between which side of the clip to keep. Fixes #48.
• VM tool now cycles between which types of points to show. Fixes #128.
• Double-clicking a texture in the texture application form will apply it
• Added a setting for rendering the selection box with dashed lines
• Added a setting for requiring a mouse click to move the camera when space is down
• Allow for decimal precision in numeric brush script controls. Fixes #127.
• Add an option to allow users to toggle rounding of created brush vertices. Fixes #131.
• Add missing hotkeys for carve and hollow. Fixes #132.
• Added axis text to the 2D viewport labels
• New 16px icon set
• Lots of other minor features

Bug fixes

• Fixed a text rendering crash on older graphics cards
• Fix for rendering issues on old ATI cards
• Make "center views on selection" work when nothing is selected. Fixes #134.
• Update the merging and vertex grouping logic in the VM tool. Fixes #139, fixes #140.
• Ignore clicking in the 3D view when space is held down to control the camera. Fixes #135.
• Fix error in the grouping actions. Fixes #130.
• Fix several issues on the texture application form.
• 3D camera can now be moved up/down using Q/E keys.
• Arrow keys can now be used to move the viewport camera in the 2D views
• Lots of small performance optimisations

Feature list not long enough. Add more stuff plz.

Good grief. This is epic. Epic on a startling scale.