Forum posts

@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!

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?

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

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

"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.

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

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.

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?

@MaxED: I've actually been doing just that! I'm not using Json.NET since I don't want to add an additional dependency, but I've rigged up a custom serialisation layer to store window coordinates for a custom viewport/window layout thing that I've been working on.

Can you use imgur/pastebin instead of mediafire/dropbox? My work blocks file storage websites

@MaxED: I'll take a look at these when I can, but it seems that some of them are changing expected Hammer behaviour (camera tool) so I'll need to test against VHE 3 and 4 to ensure consistency. If they change the behaviour they will need to be toggled on and off via a setting.

Some of these I have different plans for - for example, storing window positions (I want to get this saving for all windows so it's remembered across multiple sessions).

For number 5, free look mode is enabled by tapping the "Z" key - this is the same behaviour as Hammer 3 and 4.

@Instant: I can't see the picture, but there's already a folder tree there! For GS they're just grouped by WAD file, but for Source it will be a full-on folder tree since that's how Source materials are grouped. There's already a suggestion for "favourite textures", but I wasn't sure where to put it. I really like the idea of creating custom folders and putting them in there, I hadn't thought of that!

Indeed. A couple of people have helped out on various things, but you can't just "add on" people - it's something that someone has to want to do. It's a pretty big commitment and I don't really expect that anyone is willing to help in a large way. GitHub allows more people to make smaller additions, which is pretty cool.

Alpha is just a label, removing that label won't magically make the application any more polished. Use it if you think it is good enough, and if you don't think it's good enough, tell me why it's not and I will fix it

I wait for a significant amount of change before I put out a new release. I'm planning on making a new release in the next few days. I'll announce it here plus Sledge checks for updates when it is launched.

You can hide the right toolbar by clicking the small arrow in the top corner, but the other toolbars can't be hidden at the moment. In the future I have plans for a more advanced layout customisation thing, but that's a while away.

@Instant: I mean when off-grid vertices are unavoidable for brushes that are rotated at odd angles. It also depends on what you mean by "snap to grid" - should it snap to the current grid (e.g. 64x64), or only round to the nearest whole number (i.e. snap to 1x1 grid), or even smaller (round to 2 decimal places)? Either way it will cause issues with small geometry (where brush size is less than the grid size).

I could add something that could try to perform the vertex rounding on the selected objects, but if it creates an invalid brush, it doesn't round anything. I'll look into the options.

@CapT: Can I hold my breath too? Sounds fun. What are we waiting for again?

Sledge is still in Alpha, meaning that I still haven't worked out all the bugs. There's some issues with VM and some architectural problems that I need to fix first, plus some time-consuming stuff like automatic game detection, settings importers, and some other stuff. Once I've gotten those nailed down, then I can start on Source support. It's important to have a solid foundation to work upon. Source support will be added as soon as it can be.

(On a side note- I'm not accepting donations or any sort of payment for Sledge. Donating will not speed up development, unless I get enough money to quit my day job and work on Sledge full-time. Since this is extremely unlikely, I feel that accepting donations is quite unreasonable since I work on Sledge in my free time as a hobby.)

How would something like that work when snapping the vertices to the grid will create non-planar vertices? Sledge shouldn't have the issue with off-grid vertices, unless it's opening a VMF that has been saved by Source Hammer.

If you're wanting to make a mod with custom code, you'll have to wrangle with the Source SDK, but if you just want to make maps for an existing game, run Hammer.bat inside the game's bin folder. This applies to HL2, TF2, CS:S, DOD:S and Portal 1. The other games have their own SDK/authoring tools that you need to install and use. Make sure your games have been converted to SteamPipe (they need to be in the common folder).

e.g:
TF2: Steam/SteamApps/common/Team Fortress 2/bin/Hammer.bat
HL2/EP1/EP2: Steam/SteamApps/common/Half-Life 2/bin/Hammer.bat

@Stu: That all sounds quite reasonable and I hadn't even thought of that method, however, it has a few issues when it comes to implementing that in Sledge:

• When in the void area, the skybox bits will look like a chunk of sky floating in the void, which would look weird
• It won't work in the older renderers, and I want to keep the rendering looking as similar as possible on all GPUs
• Framebuffers weren't introduced until OpenGL 3.0, so I would need to create a new renderer for GL3
• Framebuffers are hard and I suck at graphics programming >_>

@Alberto, detail textures: no, probably not. There aren't any plans to render animated or random tiling textures, either. These things require a lot of effort and the benefit is quite low.

You say that, but really Hammer is just a primitive modelling tool
So the evidence suggests that you CAN model, at least in some form

I see, I somehow missed your first paragraph

Regardless, it's much too difficult to draw a "correct-looking" skybox on the sky brushes, because as CapT says, it involves real-time visibility calculations, which is somewhat out of scope. It seems more sensible to offer the void-replacing method as a toggle (maybe it can hide the sky brush group at the same time?) and let the user turn it on and off whenever they want.

Not going to happen. It's void replacement or nothing. Considering it'd be a toggle option, I don't see how "it's harder to find leaks" is a valid argument, unless you set your void colour to the same as the sky texture, but that's somewhat silly.

I've never done much with skyboxes and I'll have to rig up some code to load the textures in (as they're not WAD textures in GS), but I'll mess around with the skybox stuff and see what I can do. It'll definitely be a toggle, because honestly I think the skybox would get in the way most of the time.

Just to clarify, the skybox will render instead of the void, but sky brushes will still appear like normal? Seems a bit useless, but hey, I'll see if I can do it and you guys can try it and let me know what you think.

I fixed the links in the original post. The palette may need to be completely identical (aside from the last colour), try copying a palette from an existing decal and use that unmodified, that might help you narrow down what the problem is.

It's all about providing different options - you might not use it but other people will. It's like how there are several different ways to move the camera around, everyone uses a method that works for their editing style, so providing more options makes everyone more efficient.

@Tet: what do you mean by "localised translations"?

Arbitrary rotation points are definitely going to be added.

Neat, though that screenshot looks like it's mostly displacements and models, so I don't know how much you would gain from converting it to Goldsource

Here's what I've been playing with recently in Sledge - 3D manipulation tools:

Yeah, I've been taking a bit of a break so I don't burn myself out. I'll make sure the ramp tool improvements make it into the next version, though!

No, in the case of many of those, they are things that are critical from a functional standpoint. For example, large file uploads are a key piece of functionality that I need to have to meet my requirements. Autocomplete dropdowns are necessary because requiring a user to type a user's id to send them a private message is ridiculous, and typing the user name is not compatible anymore because multiple recipients are allowed now. Modals and popups are necessary to notify the user of various things.

I don't design for a lack of JavaScript because I wouldn't be able to implement my functional requirements without it. In the case of TWHL4, without JavaScript, you would not be able to upload maps > 2mb, use the live shoutbox, or send private messages (among other things) without JavaScript enabled.

@Stu: Those days are long gone. JavaScript is universally supported and is a part of the web ecosystem, just like HTML and CSS are. If you disable JS and the website is "broken", that's not the website's fault, it's yours - it's like disabling CSS and expecting a website to still look nice. HTML specifies structure, CSS defines style, and JavaScript controls behaviour.

Back in the days when CSS was first becoming common, many people still used table-based layouts in their websites so that people using browsers that didn't support CSS still had a rough equivalent of the page layout they wanted to achieve. As browsers that supported CSS properly became extremely common, people started ditching the table layouts and used CSS-based ones instead. These days nobody would even consider using table layouts or disabling CSS, because it's fundamental to how the web operates.

More recently this was the case with JavaScript too, but now that pretty much every mobile device and desktop browser has full support for JS, it has also matured to the point that it is a required part of browser infrastructure. Sticking to the idea that "10 years ago it was considered bad practice to rely on JavaScript" is just backwards thinking, in my opinion, and doesn't have a very solid logical foundation. If you don't like how a website uses JavaScript, either block that individual script/domain, or just simply don't visit that website.

NoScript is still useful, but I think it should be used as a blacklisting tool rather than a whitelisting one.

I've been doing a very heavy JavaScript app at work recently and TWHL4 will rely on JS, so I'm a bit opinionated on this matter >_>

Without JavaScript you can't do things like large file uploads, screenshot slideshows, live updating shoutboxes, autocompleting dropdowns, tooltips and popups, and other cool stuff like that.

Thanks, I'll take a look at the grouping stuff (plus the other bugs too!)

Well, ads can do a lot of damage there. Remember those ads for "spyware scanners" or whatever that say "100 bugs found on your computer, click here to scan!" - well, people actually click those and install the software. Usually they're harmless and just nag you to pay for the full version, but that kind of stuff adds up and can contribute to crapware being put onto computers.

It doesn't help that "legitimate" software like Flash and Java include millions of toolbars and other crap, and the regular user will just leave those boxes ticked because they don't understand what they mean. There's a lot of value in educating users to ignore ads and avoid installing extra junk bundled into software.

JavaScript is heavily sandboxed by every browser - you won't get any sort of malicious software on your computer from JavaScript running in an up-to-date browser. NoScript is for paranoid people who don't understand that JavaScript cannot escape the browser. If you really think it's possible to bypass browser security that easily, you should use wget and read the HTML manually.

The worst you'll ever get from JavaScript is ad networks tracking your browsing habits, and AdBlock stops that without any need to disable JavaScript. Your boss is correct to not use NoScript. You're not "protecting" anything, just making your browsing experience worse.

The Australis update is what you're talking about, and it's what I meant when I said that they're trying really hard to make it look like Chrome. Someone's already created an add-on for the beta version that restores the tabs-on-bottom mode that I use, but it's annoying that it's required. If you don't care about tabs-on-bottom mode, the only noticeable change is that the tabs are curvy and the file/edit/view/etc menu bar is replaced by the Chrome-button (but I think the menu bar can be switched back on). At the very least it can be customised, unlike Chrome's stuff.

Hmm, that's weird. What model is your graphics card? Does it happen on every map? If you create a new map and start applying textures, is there any point when it stops showing the textures correctly?

There's no need for sarcasm, I'm trying really hard to get Sledge working even on older graphics cards like yours. Graphics development, especially for GPUs older than 10 years, is pretty difficult, so please be patient when using these alpha builds.

The problem is in the box size printing that was added in the latest release. For now, can you go into the "2D Views" tab in the settings and uncheck "Draw selection box size in the viewport":I think that will fix the errors you are experiencing for now. I will add a fix to the next release so you can re-enable this setting.

As for your textures, make sure you've added your WAD files to the game profile.

The changes they keep making is somewhat annoying, but for me, Firefox is still the best (and only) option, especially when a lot of the alternatives are closed-source. Mozilla actually cares about security and open-source, and they don't have an agenda. Google is as evil as Apple/MS/Oracle/etc these days, so it really is the only option for me.

Even though every browser (including FF) is trying extremely hard to copy Chrome's extremely limited interface in every way, Firefox at the very least allows plugins to restore those removed features again. It's not ideal, but it's better than the alternative of having no control whatsoever (Chrome plugins are quite limited and don't allow UI changes).

Stu: You probably want to look at Seamonkey. Imagine the rendering and security of modern Firefox with the UI of Netscape 6, plus it also has all the superfluous crap that pre-Chrome Opera had built-in.

One map in particular, or any map? Try things like removing WADs and FGDs from the game profile, changing the rendering settings, and other stuff to see if you can nail down what's causing it.

One of my "future ideas" is to allow direct manipulation of the texture axes (the yellow + green lines that show when editing textures) in the 3D view. It would be a pretty advanced feature, but it would probably allow you to do what you need.

In that case you'll be happy with the new release which adds the box dimensions you desire!

Full list:

• Draw selection box size in the 2D viewports. Resolves #120.
• Only open the properties window on double click in the 3D view. Fixes #109.
• Add nice update notification dialog to display release notes
• Add transform as a menu item in the viewport right client menu. Resolves #111.
• Holding down control moves all points of the clip tool. Resolves #107.
• Update the box coordinates in the status bar when transforming. Fixes #119.
• Fix issue where models would not render due to flexible casing and type in the FGD format.
• Make sure the brush controls are displayed in the correct order. Fixes #125.
• Sort the entity flags when reading them to apply, stops the flags from being swapped randomly
• Don't mess with texture settings when rendering the entity tool. Fixes #102.
• Ctrl+click in the 3D view of the VM tool can deselect solids. Fixes #122.
• Don't select extra vertices in the VM tool unless the mouse is clicked. Fixes #108.
• Hold control to scale proportionally in the box tools. Resolves #123.
• Implement 3D movement settings. Fixes #116.
• Keep the recent texture list in sync between the texture tool and the sidebar panel. Fixes #101.
• Tweak the tolerance value for invalid solids to match Hammer's behaviour. Fixes #114, also hopefully fixes #68 as well.
• Add setting to change the mouse wheel move distance in the 3D view

You may be interested in reading the official response to that rumour: http://www.reddit.com/r/gaming/comments/1y70ej/valve_vac_and_trust/

Look in the "External dependencies" folder, that's where it appears for me.

No, because all the file paths are absolute. To be portable, you should be able to put your WADs and FGDs with the app on a USB stick and the game configs need to work correctly regardless of whether it mounts to D:/ or K:/ or whatever else.

But it is essentially how I would imagine an "extrude" for a BSP system would work. You can't physically modify the face like you can in a modelling tool (it would create invalid solids), but you can perform interactions with the face that create new geometry.

@Rim: part of the "future list" is in my head, some of it is in the GitHub issues page. Right now I might be only aiming to replicate Hammer's capabilities (improving them where I can), but once I have that at an acceptable level I can start adding new things. The addition of Source support and displacements/instances for Goldsource users should hopefully make the switch worth it, and that's just the beginning of what I would like to do.

@Disco: If you do that, you can't allow the user to choose the install directory, which I think is worse than using appdata for the settings file... It'd be possible to create a portable version of Sledge with a bit of extra code.

Because the default Windows filesystem permissions do not allow writing to the program install directory.

The settings file is located in "%AppData%/Sledge", you can copy it to the same location and it will work. You will need to re-configure the game & build file paths unless they're exactly the same on both computers.

@Rim: That's cool, but it's a long way down the line simply because of how difficult it would be to implement. I will add it into the list of "future things that would be nice".

Thanks Archie, I'll keep an eye on the thread.

The Sven Co-op team have said that workshop is possible for the new Steam version, but if I recall they are not looking to add it to the first release. But workshop for GS (at least for Sven) is possible and may happen at some point!

It's almost certainly a problem with your configuration, can you send me some more information (pastebin is fine):

• The Settings.vdf file located in "%AppData%/Sledge"
• The FGD you are using
• The absolute path of the player.mdl file you would expect to load from an info_player_start entity (e.g. C:/Half-Life/valve/models/player.mdl)
• The file size of the player.mdl and playert.mdl in bytes

As I have said multiple times, sprites are not implemented yet, but models are.

Again, check that your game paths are set up correctly. Model rendering has been implemented for a while now.Make sure you have either WON HL or an updated Steam HL (post-steampipe). Go into the game settings and set it up, and then close and re-open your map.

There's not a lot I can do about speed, Hammer will always win there because it it written in C++ which is on average about 30% faster for CPU-intensive tasks like loading maps. Also, Hammer loads all WAD files on startup, but Sledge loads them all when you open the map. The slowdown simply happens at a different time (startup vs. map load). Try changing your computer's power settings so that it doesn't power down your spindle drives, that's sometimes a cause of massive slowdowns during loading. That applies to Hammer, too.

I'm not sure what you mean about real-time rendering... sprites are still not there yet, but models have been implemented for quite a while. Make sure you have set up your game paths correctly.