Forum posts

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.

@Rim: if you could make a mock-up or something of what you mean, I would be happy to add it to the list of enhancements.

@CapT: setting a custom background image is still on the to-do list and will be added eventually

@Instant: thanks, that's awesome. I will keep an eye on the comments in that thread for suggestions and bugs, in case FP users don't want to create an account here.

New version! I finally got around to adding advanced compiling features. You will need to review your game and build settings as they have changed quite a bit, if you don't the compiling won't work correctly.

Full change list:

• Added proper advanced compiling support
• Added click-to-expand buttons to the docked panels
• Fixed a bug where the WAD paths were not saved to a MAP file correctly.
• Fix cursor not being captured correctly by the 3D viewport in free look mode. Fixes #98.
• Check for, and remove, empty groups when deleting objects. Fixes #32.
• Stop groups with no children causing errors during selection. Fixes #52.
• Double-clicking an object should open the object properties window. Fixes #54.
• Don't select parent objects when ignore groups is enabled. Fixes #66.
• Added information message for when no games have been configured
• Render the grid correctly on initial load in the modern renderer
• Add support for the updated Source FGD format (TF2, csgo)

(There was a bit of a hiccup in the update process so if you were unfortunate enough to update in the last hour or so to version 0.1.0.18, you will need to update again to 0.1.0.19. Sorry!)

Yes, someone else posted a different issue but it happened after their laptop went into sleep (or possibly hibernate) mode. I'm not really sure how I will work around something like that, I will investigate.

@Stu: You're probably thinking of Hibernate as an ORM library for Java. It is often used in web code, but that is because Java (that connects to a database) is mostly used for back-end web stuff. It can be used in desktop Java programs too. There's a .NET port called NHibernate that could theoretically be used in a WinForms app

I agree, dependency management is more important than a lot of developers think, and it's annoying to see a very basic program is written in something like Java or .NET when you could write the same thing in C without any more effort. (Or, when you try and load up some open source project and it has to download 100 extra dependencies before it will even compile)

I'd say though, that once you have any sort of UI going on in your application, you don't have much of a choice but to use some sort of heavy framework dependency (Java/Swing, .NET/WinForms, C++/Qt), especially if you want to think about portability. Qt is probably the best choice for portability (because Swing is really terrible), but WinForms is surprisingly portable when you look at the Mono project.

When you consider The Compilator, I would say that it has a complex enough interface to justify introducing a framework dependency. Considering that Nem's Batch Compiler (which is what most people use) is also written in C# (or Delphi), I think that it is a reasonable choice to use .NET for it.

In the end it's all about choosing the right tool for the job, and in many cases there is more than one 'right' tool to choose from.

Sure, that's fairly easy to do. When you create the Process object to run the batch in .NET, set UseShellExecute to false and RedirectStandardOutput to true, add an event handler for OutputDataReceived, and then call BeginOutputReadLine after you start the process. Your event handler will get called when the process has output a line of text for you to append to your textbox.

Then you can subscribe to the Exited event, which gets called when the process finishes. This is the best way to handle it because you don't have to mess with any threads in your application code.

(If you use the WaitForExit function instead of the Exited event, you will need to start the process in a new thread so that you don't block your UI. If you do that, you will need to use the Invoke/BeginInvoke method in WinForms to switch back to the UI thread when appending lines to the text box. This is annoying, so the event is a better option in this case.)

Set CreateNoWindow to true to prevent the command window from opening. You can see how Sledge is starting a process here (wip).

Hey TMA, I'm not sure if you're still working on updates for this, but I have been investigating Source compiling for Sledge and I am not having any trouble using the latest version of vbsp. Perhaps the SteamPipe update has fixed your Source compile troubles? It may be worth trying again with the latest build tools (which is the 2013 version, your screenshot above is showing the 2011 tools and the pre-SteamPipe game paths).

Here's the VBSP parameters I have been testing with (just taken from Hammer's command line):

Hi, Welcome to TWHL!

I'm assuming that you can see other entities, but not the func_ options. If that's not the case let me know.

There are two types of entities: Point entities, and Brush entities. Point entities are the ones you can see in the list on the right when you are using the entity tool. Brush entities cannot be placed, they need to be attached to brushwork in the map.

Create a block using the brush tool, select it, and then click the "Move Selected to Entity" button that's located just above the list of entities on the right side. It will convert the brush into an entity, and then you can select the type of the entity from the properties dialog that will appear (this is where you will see your func_ entities).

I've seen that editor before, it's written in Qt so I doubt that it is built from Hammer source code. Of course, it's not open source so you can't say for sure if it's based on Hammer or not. The source code for it has been leaked a few times, IIRC, so it could be possible.

I've got no issues with competition. There's this one, and the Sven Co-op team has access to the Hammer 3.5 source code and are making enhancements for it as well. But neither of these projects are open source, and they're not interested in Source support at the moment, either. While Sledge is trying to produce an editor to replace Hammer, it's not trying to emulate Hammer exactly (unlike these projects). I'm trying to evolve the editor in a way that makes it easier for experienced users and new users alike by adding new concepts, back-porting Source features to GS, and other cool stuff. If another project does a cool thing, I'll just steal the idea and do it better in Sledge

Thanks Crayz, I will try to get Source supported as soon as I can, but for the moment Source won't work very well yet. You should be able to load up the CS:S FGD from steamapps/common/counter-strike source/bin/cstrike.fgd, and Sledge should show the entity list (I've tested the HL2 FGD and it works). Source textures won't show up at all yet, and displacements won't work either. I still have a lot of work to do on the base application and on Goldsource support so please be patient until I can add Source support

@Jeff: I know precision issues have always been a problem in Hammer and the compile tools, but I haven't done a lot of testing with Sledge in that regard because I don't have much experience or knowledge in those areas. When I start working on Source support, could I ask you to help me out with identifying issues like this and trying to fix them? Of course I would accept help from anybody else who knows about these issues as well!

On your comment about file formats, VMF is actually the best format out of the three by far, because it's extensible. If you open and re-save a H4 VMF in Sledge and take a look at it in notepad, you can notice that Sledge actually saves the vertex values to the file (to speed up loading and to reduce precision issues), even though Hammer doesn't. Even though Sledge saves extra information to the file, Hammer 4 still opens it without errors. This is why VMF is a great format!

Thanks for the bugs/suggestions guys, I will look into them this weekend.

Not sure where you guys are looking, TWHL has always had a favicon...

You might have some luck asking on reddit (r/gamedesign or similar) or on Extra Credits' forum, I'm sure that if either of those communities can't give you what you are looking for, they should be able to point you in the right direction.

@Cooborky: The mouse capture issue is kind of complicated to fix so I ignored it for this release. I will investigate a better fix for the future

Your mind isn't playing tricks on you regarding the missing WAD files in the exported MAP. Compiling does a slightly different save process than exporting (as compiling clips the cordon beforehand) and the export/save function isn't adding the WAD files correctly. I'll fix it in the next version.

@kaffikopp: Clipping tool behaviour and hiding the window are features in the works, but vertex mode in the camera tool might be quite difficult, I'm not sure how I would go about implementing that with the current architecture. I will have a think about it.

@Archie: Screenshots are a neat idea, I will have a think about it.

New version time! This one has a bunch of minor improvements and bug fixes that have been reported recently. The sidebar is slightly improved now (it can be resized!) to make it ready for new features in the future.

Full change list:

Sledge 0.1.0.17

• Right sidebar changed to prepare for future features
• Sidebar and viewport layouts are now saved
• Fixed crash in the model file browser
• Minor fixes related to multiple FGD files
• Fixed issues related to hotkey localisation
• The shift key must now be held to create a new camera in the camera tool
• Added "Reset to defaults" buttons for the hotkey configuration screen
• Added camera tool hotkey (Shift+C)
• Changed the behaviour of "rotation height" in the torus tool since it generated invalid geometry
• Added arch and sphere brush types
• Arrow keys pan and tilt in the 3D view. Resolves #91.
• Improved the game selection form
• Significantly improved rendering on Intel GPUs
• Added hotkeys for flipping objects (Ctrl+L,I,K for X,Y,Z flipping)
• The texture browser now remembers the selected package, texture, filter, view type, and sort options
• Added "Export" function to "Save As" without switching to the new file

Good point, I will add an export function that works the same as "Save As", except that it doesn't switch you to the new file.

#2 is pretty easy to do and #3 isn't too bad, so I will try and get those into the next release. #1 is a bit more complicated and if I did something like that it probably wouldn't work exactly like that, so no guarantees there.

@ninja: do you mean the transform dialog? Look here.

Once Source support is implemented in Sledge it will start warning people who use the RMF format because RMF doesn't support features such as displacements, instances, additional map properties, and so on, which cripples a lot of the power of the editor (Sledge will change these back to plain brushwork - displacements into triangles, instances into brushwork, etc). Instances and displacements in Sledge will work in both Source and Goldsource if you use the VMF format.

It doesn't work like that. Code written for a (serial) CPU would almost always run slower, if at all, on a GPU even if perfect emulation was available (it isn't, afaik). The processing code needs to be written specifically for the purpose of parallel programming. Multicore CPUs are starting to get people thinking in that direction, but you can't just summon "GPU magic" and get everything instantly working.

From a quick look online, experimental libraries like C++ AMP appear to be simplifying things and making GPU compute available from a standard C++ application, but you need to use the data structures and language macros defined by the library, it cannot just be bolted onto code and be expected to work out of the box.

That post is ancient ninja, OpenCL is generally the more common CPU compute language because it is more portable and it can even default back to CPU when a GPU is not available. CUDA still exists but isn't very common because it only works on Nvidia graphics cards.

It will notify you when an update is available. I'm still working on it!

Intel graphics by any chance? Once the next version is released, could you check again and let me know if it's fixed? The next version has a fix that should make the depth testing much better on Intel GPUs and fix that weird triangle effect where brushes meet. If it's not fixed then I might ask you to provide more screenshots or a video if you're able to, but if you have Intel graphics there's a high chance it will be fixed so don't do anything yet

I recommend that you use VMF for all your Sledge editing, regardless of engine, as it is a more extensible format and it will retain more features. Use RMF if you need compatibility with Hammer, otherwise use VMF.

It's not that simple, but there are a number of standard programming languages and APIs that allow relatively easy use of GPU computation. It'd be a huge amount of work though, and you would need to know a shitload about the compilation process to be able to do it. I don't know enough about the compilation process to even know if it can be sped up via GPU programming (probably yes, but I couldn't say for sure).

It checks for updates automatically each time it starts up.

Thanks, I'll test it out when I get home from work

Edit: well there's your problem: a texture called "|gt01". The pipe character '|' is not a valid Windows path character and it was crashing because I was using the default .NET file path handlers to open WAD textures. Replaced it with a custom function and all is well. This WAD crashes GCFScape with the same error message as well.

@x6herbius: The vertex tool is a bit more complex because it has to know about shared vertices, but aside from that it's much easier to keep the vertices separate per-face. When transforming a solid, you can simply perform the same transformation on every vertex - the shared vertices that happen to be in the same place will be transformed in the same way, so you don't have to worry too much about it.

In terms of avoiding nonplanar vertices, Sledge currently does nothing to avoid this - same as Hammer. I have looked into auto-correction during VM like gtkRadiant (or QuArK? I forget) does, and I will probably try to add that as an option in a future version.

Regarding plugins and architecture, I'm structuring Sledge in a way that most things are extensible, but Sledge itself contains all the core functionality. This makes it easy to extend with new features (most common plugin use-case), but more difficult to remove/replace existing functionality (extremely uncommon use case, if a developer wants to do this they should create a fork). Cross-dependencies between plugins sounds like a very painful thing to deal with, so good luck with that!

I'd suggest starting with the big stuff (like the map objects, gamedata, file parsing, rendering, and editing) instead of focusing too much on UI niceties like plugins and consoles, simply because you will come across any shortcomings in your architecture while working on those, rather than when working on chrome components. I've been working on adding extra UI in Sledge at the moment and it is blissfully easy and simple when compared to editing or rendering which are incredibly difficult and require a lot of non-trivial architecture refactoring when trying to add new features.

@COOBORKY: Do you happen to have a download link for the WAD that breaks Sledge? I think I have fixed the problem in the next version, but it would be nice to be able to test it for sure. Thanks for reporting the bugs, I will be sure to take a look at them.

@Striker: I'll take a look at this, invalid solids have been annoying me lately since I have been trying to create a sphere brush tool :/

@Archie: Sledge is a hobby project that costs me nothing to host or maintain. The best donation anybody can give is to use the program, report bugs and missing features, and help spread the word

I'm considering allowing plugins in the form of Python scripts but I'm not sure yet. Most likely the plugins will be in the form of .NET DLL's written in C# or VB.

Sledge stores the faces as a series of sorted vertices on a plane, and only creates triangles when it's time to render. You'll probably need to do the same thing, especially when implementing displacements, where the brush vertices are completely unrelated to the vertices of the displacement that you are actually rendering. You can take a look at the implementation here.

Edit: Good news for Intel graphics users, I was able to resolve the weird artifacts that Striker was experiencing (well, it's fixed on my laptop running an Intel HD 3000 GPU). It'll be fixed in the next version. Turns out that Intel graphics works much better with a 24-bit depth buffer instead of the default value of 16 that I was using. As a bonus side effect, it should slightly improve the rendering accuracy on all other platforms as well

I mean the renderer in the first tab of the settings window, you can switch between OpenGL 2 and OpenGL 1.

Anyway, I've actually noticed that effect before on my laptop that has an Intel graphics card, so it's probably caused by Intel's implementation of OpenGL. Google isn't telling me about any immediate solutions so I will need to look around to see if there is a fix.

Is it like that on every map? Can you try switching the renderer in the first tab of the settings and restarting?

It kinda looks like the z-fighting effect you get when two faces overlap. All those faces wouldn't happen to be overlapping, would they?

Can you post a screenshot?

Sledge has the "texture scaling lock" feature from Hammer 4, it's not 100% accurate but it makes a best guess to retain texture coordinates when scaling solids.

You can still apply the texture using the Shift+T shortcut, it's not really an interactive tool so I didn't want to put it on the main toolbar. I could add it to the top shortcut bar though, or perhaps put the a button next to "Browse" and "Replace" on the texture box on the right side, would either of those be good enough?

Could you go into more detail about the texture trick, I think I sort of know what you mean (manually editing texture axes), but I've never heard of this specific trick. I'm curious to know more!

Even if the time to compile lights was acceptable (it isn't, as rufee pointed out), it wouldn't be all that useful for Sledge because it doesn't have any concept of what to do with a BSP. To get something like that going, you would need to re-implement the entire Goldsource renderer in Sledge to replicate the results, but as you can imagine that's not a very realistic task. That gets even worse when you consider Source compatibility, dynamic and projected lights, and so on.

The alternative is to fake a lighting system to approximate the results - instead of using the RAD process to generate lights, they are rendered in real time using a custom Sledge implementation. It wouldn't look exactly the same as the compiled result, but it should be close enough so it would still help when placing lights to get a general feel of what the lighting looks like. This is similar to how Hammer 4's "raytraced lighting preview" behaves, if I recall.

However, lighting, shadows, and all that kind of stuff is much too complex for me at the moment as I have no experience in those areas, and I know that they are reasonably difficult concepts in 3D rendering. It's possible to add something like that, but I doubt it will be added any time soon simply because I have more important things to work on.

Unreal Engine, Unity, Crytek and other modern editors get proper lighting support out of the box simply because they don't use precompiled lighting anymore, and their editors have the actual engine embedded into the application. Sledge doesn't have that kind of advantage.

Thanks for reporting the issue with the model browser, I will try and replicate it tonight. As for sprite browsing, it hasn't been implemented yet (sprites don't render in the 3D view yet, either).

@GamerX: Unfortunately your graphics card only supports OpenGL 2.0 (not 2.1), but Sledge will still work for you - in Sledge, before you open a map, go to Tools > Settings, and on the first tab you will see a drop down for "Renderer". Select the middle option and save the settings, then try to open a map again.

@kaffikopp: Currently I'm only looking to support Goldsource and Source, but I'm not opposed to supporting additional formats later if there is demand for them.

@ciba43: I was able to downgrade the required OpenGL version to 2.1 (from 3.0), and Wiki seems to indicate that the FX 5200 supports up to OpenGL 2.1, which probably explains why it is now working for you!

@x6herbius: That's really cool, I had a read through your thread and it looks as if you're well on your way with the theory (much ahead of where I was after 7 months working on my editor!), but you haven't done a huge amount of code yet.

You're more than welcome to look at the Sledge code and use that to inspire your implementation, and of course I would love if you were interested in helping out with Sledge itself! No pressure of course (but it sure would be nice to have someone working on Source stuff in Sledge parallel to my efforts in getting Goldsource support complete!)

Your thread has lots of good ideas and I hope you don't mind if I borrow some of them in the future. I saw you were focusing on portability (hence using Qt), Sledge is theoretically portable with Mono but I haven't had the chance to get it working properly on Unix-like systems yet.

Whether you are looking at Sledge code or trying to work out some detail for your own implementation, feel free to drop me a line and I will try to offer some advice. Hopefully I can save you some of the time it took me to work out some of the annoying tricky details of implementing an editor! I was especially interested in your discussion about VBO's and shaders - I've just finished such an implementation myself and would be happy to offer some advice if you are interested

@Striker: It would be possible with WebGL and some server-side preprocessing (I wouldn't want a browser to be parsing 50mb+ BSP files and JavaScript isn't great for reading binaries), but how useful would it really be? It wouldn't be able to show any textures due to copyright, and it would require the BSP to be uploaded to a server for processing. The most you would get is shaded polygons and a freelook camera, which I admit would be pretty neat, but is that really any more useful than uploading screenshots instead? I guess you could do the same thing with RMF/MAP/VMF as well, but still...

What model is your graphics card? If it is an older card, go into the settings and change the renderer option the second choice (OpenGL 1.0 Display Lists), this will use an older version of OpenGL that should work for you. If it's a newer card let me know the brand, model and what version driver you are running and I will take a closer look.

That's in the "future possibilities" section, and definitely not something that will be added any time soon. It would be pretty cool, though!

@Striker: I plan on adding Twister stuff either as a plugin, or as an expanded implementation in the displacement editing tools.

Thanks Alberto for helping to spread the word

Well, it would be possible to use propper the same way as it is used now, and it may be possible to make a plugin that automatically does it (once plugin support has been added, of course).

@kaffikopp: Thanks for testing, could you send me your Settings.vdf file that's located at "%appdata%/Sledge" (pastebin is fine), this will let me see your re-bound hotkeys so I can try and diagnose the issue. I will be sure to fix the missing/duplicate hotkeys in the next version as well

@Instant: thanks for the link, looks quite useful, I will definitely check it out! In case you don't know about it, The Noun Project is another good source for icons: http://thenounproject.com/

Heh, thanks Archie! Though you seem to have selectively forgotten all the times I beat you at Worms...

Showing/combining animated (plus randomly tiling and toggle/button textures?) textures is an interesting idea, but reasonably difficult to implement because I'd want them to render in the 3D view as well (I probably wouldn't render the random tiling ones, though). I'll put it onto the post-alpha feature list.

Time for a new release! This release fixes a number of issues that have been pointed out recently, including:

Viewport labels/render type:Hotkey customisation:Plus an improved camera tool and texture browser. Be sure to test it out

Full list:

• Added viewport labels and type switching (textured, wireframe, etc)
• Added support for customising hotkeys
• Improved camera tool with support for multiple cameras, switching between cameras, and moving the look position
• Added sorting, 1:1 size mode, and proper texture information to the texture browser
• Added new setting for the 3D view background colour
• Fixed a bug with the selection tool not displaying the correct box dimensions
• Fixed a bug with selection not working properly when the FOV is not 60

Yep, it's in there. There's also a "split face" button in the VM tool to make the feature more visible.

Thanks for the tip, I will check it out! I've never actually used it for reference because of how woefully incomplete and out of date it is

Woah, thanks for all your feedback, I'll definitely try to get all your issues fixed!

I tried changing my all region settings to Norway but shortcuts still worked for me. The hotkeys tab in the settings window will eventually let you customise all your hotkeys so I will work on that and see if that helps identify what the problem is for you. I didn't know about Alt+S and Alt+A in Hammer, currently Sledge is hooked up with the [ and ] hotkeys for changing the grid size.

At the moment the 'background colour' applies to both 2D and 3D views, but I can create a separate colour for the 3D background if you think it's needed. For the viewport labels and switching between wireframe and so on, that's a planned feature but it's not available yet. I don't know what the default FOV of Hammer is, it could be figured out by trial-and-error but I don't have the time for that

The missing selection dimensions in the status bar is a bug and I will fix it when I can. Same for the bug related to changing the FOV, I can't believe I made a bug out of something so obvious!

I'll work on adding the missing features in the texture browser.

For the camera tool, thanks for your explanation. I've never actually used it so I wasn't aware that it did all that stuff. Is there a tutorial or something that shows all the features of the camera tool in Hammer? That would be very useful for me. As for not being able to move the "pointer"... I tried doing that but the maths was too hard so I gave up for the time being... I'll try and approach it from a different angle so it works as you expect! I intentionally turned off snap to grid because I didn't think it was useful for cameras, but I will turn it back on if that's the expected behaviour

Again thanks for your feedback and please don't hesitate to continue telling me about bugs and missing features! I will try and get most of your bugs fixed in the next week or so as I am on holiday at the moment