Forum posts
- Forums
- Posts
- Posted by
Penguinboy
I think the idea is that it could be useful to snap to other increments like 5 or 10 degrees.
OBJ is an incredibly simple format, especially since so much of it cannot be applied to Sledge since it involves free-form geometry and curved surfaces. Sledge ignores surfaces, curves, materials, and material coordinates.
To answer your questions...
To answer your questions...
- I downloaded test objects from the internet
- N/A, see above
- I used a 20-sided regular polyhedron (an icosahedron) to test importing of a single convex solid (this is the only time Sledge will create a complex solid from an import), and the other test I used was a large array of quads (~110k faces) exported from a minecraft map. I tested a few others for once-off tests but those were the main two I tested on.
- N/A
- The OBJ standard doesn't have any information about compression, I don't know what this means. If it's just simple sharing of vertices or polygon decimation, this is just additional complexity on the exporting program and doesn't impact the object consumer.
- The OBJ doesn't support specifying a scale. I multiply all values by 100 because the samples i tried exported on a much smaller scale than a standard map.
- From what I can see, the OBJ doesn't allow a transformation to be applied to a group of objects. Goldsource/Source uses a Z-up coordinate system, so if you're working in a Y-up environment you will need to rotate the object before you export, or after you import.
- Yes, no errors occurred for my test cases
- N/A, see above
- Yes, one of my test cases was very small (1 unit) and one was quite large
- Texture coordinates in the OBJ format are stored as U/V coordinates which are incompatible with the axis system in GS/Source. Textures are aligned to face instead.
- The result will be unavoidably different due to faces being turned into solids when the file is imported into Sledge.
Well, it is not a feature intended to be used by beginners. OBJ uses the order of vertices to specify face directions, so setting the normals to point outwards needs to be done (it's not possible to magically predict which direction you intended them to face).
Quads and other face types are supposed to work, but I'll need to investigate why they're not working using your examples.
Quads and other face types are supposed to work, but I'll need to investigate why they're not working using your examples.
Can you upload a sample .obj file that generates the invalid solids so I can debug it myself? The couple of samples I used to test the import when I was coding worked without errors.
@Cooborky: Maybe I could figure out what the problem is if I tried using the same files that you are. Can you upload your FGD file and sprites folder, plus the settings file from the "%appdata%/Sledge" folder? Hopefully we can work out what the problem is...
When you edit a sprite entity, there's the option to "browse" for a sprite. Do your editor sprites (light.spr, speaker.spr, etc) appear in that browser? (they are supposed to)
I have fixed the slowness when selecting textures, so that should be fixed in the next version. Also, your favourites didn't get deleted, but I accidentally made a change that means that existing favourites didn't appear in the browser. I'll fix that in the next version too, so your old favourites will return again.
When you edit a sprite entity, there's the option to "browse" for a sprite. Do your editor sprites (light.spr, speaker.spr, etc) appear in that browser? (they are supposed to)
I have fixed the slowness when selecting textures, so that should be fixed in the next version. Also, your favourites didn't get deleted, but I accidentally made a change that means that existing favourites didn't appear in the browser. I'll fix that in the next version too, so your old favourites will return again.
I must admit that I only tested it with one WAD file >_<
I won't do an "emergency" patch for this one, but I will make sure it's fixed for the next version. Sorry for the hassle
@Archie: Could it use whatever texture is selected (i.e. appearing in the right bar)), or should it always use null/nodraw?
I won't do an "emergency" patch for this one, but I will make sure it's fixed for the next version. Sorry for the hassle
@Archie: Could it use whatever texture is selected (i.e. appearing in the right bar)), or should it always use null/nodraw?
I've just released an update, can you guys please try it out and let me know if it's working for you? Thanks for being patient!
I also added a fix for DiscoStu's dilemma of wanting to exclude certain WAD files, by adding both a blacklist and a whitelist. Here's how they work:
Blacklist:
Add texture packages you want to exclude from being loaded, one per line. For example, it might look like this:
Whitelist:
If you want to use Sledge the "old way" - that is, you only want to load a certain list of WAD files, you can use the whitelist. Using the example above as the whitelist, this time ONLY halflife.wad and cstrike.wad will be loaded, and no others. Leave the list blank if you don't want to use the whitelist.
Changes:
I also added a fix for DiscoStu's dilemma of wanting to exclude certain WAD files, by adding both a blacklist and a whitelist. Here's how they work:
Blacklist:
Add texture packages you want to exclude from being loaded, one per line. For example, it might look like this:
halflifeWhich means halflife.wad and cstrike.wad will NOT be loaded. "cached" and "gfx" are always excluded automatically, as these are never useful.
cstrike
Whitelist:
If you want to use Sledge the "old way" - that is, you only want to load a certain list of WAD files, you can use the whitelist. Using the example above as the whitelist, this time ONLY halflife.wad and cstrike.wad will be loaded, and no others. Leave the list blank if you don't want to use the whitelist.
Changes:
- Added error handling when trying to load invalid WAD files
- Added support for a texture blacklist (exclude/ignore certain texture packages)
- Added support for a texture whitelist (only load specified texture packages, ignore all others)
@Dim: Hmm, looks like that's caused by a WAD file that has two items with the same name. I don't know how someone managed to do that! I'll have to make a fix for that as well, I'll see what I can do when I get home from work. For now, you can try to find the WAD that has two textures with the same name - removing that should stop the bug.
@COOBORKY: 311? Damn, that's a lot If you don't want to go through them all, I'll try to get a fix out later tonight (~12 hours from now).
@COOBORKY: 311? Damn, that's a lot
If you don't want to go through them all, I'll try to get a fix out later tonight (~12 hours from now).Can you look in your game and mod directories, and open each WAD file in Wally or GCFScape until you find the one that doesn't open? If you remove that, it should stop the error. I'll add error handling for invalid WAD files in the next version 
Yeah, the next thing I have to add is the ability to exclude textures/wads from the list, like Hammer 4 does.
New release! It's almost been a full month since the last one. In terms of new features, this release doesn't have a whole lot, but there are plenty of bug fixes!
There are also some reasonably major changes to how textures are loaded (in preparation for Source support) - WAD files are loaded from the game directories now (i.e. your game folder, and your mod folder). Any WAD files you have set up now will be removed, and your game WADs will be used instead! If you want extra WADs to load, go into the "Textures" tab of your game configuration settings, and add the files in there. You can add a folder to load all the WADs inside that folder.
The setting to load WAD files from your compile tools folder has been implemented, so you can turn that on and use zlht.wad without needing to add it manually.
Additionally, sprites and models from your FGD folders can be loaded as well, so you don't have to copy them into the Sledge directory, or into your game directories. Toggle the setting on in the "Entities" tab for your game, and then put the "models" and "sprites" folders in the same folder as your FGD file(s).
Full list:
Major features
There are also some reasonably major changes to how textures are loaded (in preparation for Source support) - WAD files are loaded from the game directories now (i.e. your game folder, and your mod folder). Any WAD files you have set up now will be removed, and your game WADs will be used instead! If you want extra WADs to load, go into the "Textures" tab of your game configuration settings, and add the files in there. You can add a folder to load all the WADs inside that folder.
The setting to load WAD files from your compile tools folder has been implemented, so you can turn that on and use zlht.wad without needing to add it manually.
Additionally, sprites and models from your FGD folders can be loaded as well, so you don't have to copy them into the Sledge directory, or into your game directories. Toggle the setting on in the "Entities" tab for your game, and then put the "models" and "sprites" folders in the same folder as your FGD file(s).
Full list:
Major features
- Added support for VPK packages
- Added support for VMT/VTF textures
- Textures are now loaded from the game files (they don't need to be added one-by-one)
- Additional WADs can be added from the "Additional Texture Packages" section in the settings
- Sprites, models and textures can now be automatically loaded from FGD and compile tool folders
- Added a file browser in the object properties dialog for "sound" keyvalues
- Added a texture browser for sprite and decal types in the object properties dialog
- Added support for dragging-and-dropping files from Windows
- Added support for rendering sprite scale in the 3D view
- Added right-click class selector menu to the entity tool
- Add shift+arrow keys to move around the 3D view
- Added skip selection/visibility and stack size undo stack settings
- Added setting to change the size of the undo stack
- Added setting to fast-forward selection-related actions when performing undo/redo
- Add more detailed error reporting (line/char numbers) to the FGD provider
- Actions that don't modify state don't mark the map as changed
- Added an option to the Tetrahedron brush to place the top vertex at the centroid of the base
- Put up/downs next to all the 3D setting sliders for more precise input
- Implemented mouse invert settings in the 3D view
- Replaced HLLib file loaders (PAK, WAD, VPK) with native .NET implementations (for greater portability)
- Added some additional compile options (individual tools can be turned off)
- Allow support for multiple keys with the same name in the object properties dialog
- Added support for Quake-style MAP format (as generated by WinBSPc)
- Update bounding boxes, decals, sprites, and models correctly for entities when changing class
- Various fixes related to parenting and modifying objects
- Various fixes related to undo/redo not working as expected
- Zero value keys in transform dialog reset values to 1 if in scale mode
- Fix silly file associations to use the normal method
- Make the filter on the texture browser save the typed text properly
- Make "apply with values" right-click texture application work correctly when no faces are selected
- Various optimisations and bug fixes when loading MAP and VMF files
I tried this during the beta, it's really cool, but unfortunately the input lag was noticeable even on medium-paced games. I was running it on 1080p through my gigabit ethernet. They added new options since I tried it, so I'll test it again and report back.
Edit: Input lag is better, but video lag is worse. Even with 720p downscaling on "fast" quality (i.e huge artifacts), streaming a relatively modern UE3 game was too laggy, but indie games worked pretty well. My PC is running a GTX570 and an i7-3770. I'll try again some other time, just in case something else was hogging my CPU/network.
Edit: Input lag is better, but video lag is worse. Even with 720p downscaling on "fast" quality (i.e huge artifacts), streaming a relatively modern UE3 game was too laggy, but indie games worked pretty well. My PC is running a GTX570 and an i7-3770. I'll try again some other time, just in case something else was hogging my CPU/network.
There's nothing stopping me from making improvements to the system
@Stu: That's definitely not a crazy idea, instancing will be added for Source support, and it will work with GS as well. Same goes for displacements, which will replace the need for the trimesh hack that Rim mentioned.
I just did some experimenting with Hammer and multi_managers, Hammer saves multiple keys like this:
test
test#1
test#2
test#3
And GS supports triggering in this manner. With the above example, the "test" entity will indeed be triggered 4 times. I'll add support for this format in the next version (Sledge will simply put "#1" on the end of duplicated keys). For now, you can add two triggers to the same entity by manually adding the "#1" on the end of the second key.
@Stu: thanks for the bugs. The "Apply" button will apply the selected texture to the selected faces. It will change the texture on the faces, rather than changing the scaling. (you can also double click a texture from one of the two texture panels to apply it)
test
test#1
test#2
test#3
And GS supports triggering in this manner. With the above example, the "test" entity will indeed be triggered 4 times. I'll add support for this format in the next version (Sledge will simply put "#1" on the end of duplicated keys). For now, you can add two triggers to the same entity by manually adding the "#1" on the end of the second key.
@Stu: thanks for the bugs. The "Apply" button will apply the selected texture to the selected faces. It will change the texture on the faces, rather than changing the scaling. (you can also double click a texture from one of the two texture panels to apply it)
I didn't know that Hammer allowed duplicate keys, I'll be sure to fix that.
@Striker: this is probably because I did the integration in a dumb way - I know what I did wrong and there's absolutely no reason why I should have done it that way. I'll make a change and hopefully that should fix the problem. It's not related to any incompatibilities in Windows.
@Rim: I'd love it if you actually gave Sledge a try
The VM tool window has a very clearly labelled VM scaling feature. I really hate how Hammer has so many interesting features hidden in shortcuts and other obscure locations, so I make an effort to try and expose those features in a more user-friendly way.
@Stu: that was annoying me, too! In the next version, selection doesn't mark the map as "unsaved".
@Instant: From what I have heard, as ridiculous as the thought experiment is, it could never be dismissed as the nonsense it was initially intended to be. The fact that it still cannot be disproved is a sign of how far we still have to go in research of the field. Of course, I get all my information from entertainment media, so take all that with a grain of salt (Japanese sci-fi absolutely loves Schrodinger's cat and I have heard it explained in great detail far too many times...)
Personally I like the many-worlds theory. I don't have any logical reason, I just think that it's awesome.
@Striker: this is probably because I did the integration in a dumb way - I know what I did wrong and there's absolutely no reason why I should have done it that way. I'll make a change and hopefully that should fix the problem. It's not related to any incompatibilities in Windows.
@Rim: I'd love it if you actually gave Sledge a try
The VM tool window has a very clearly labelled VM scaling feature. I really hate how Hammer has so many interesting features hidden in shortcuts and other obscure locations, so I make an effort to try and expose those features in a more user-friendly way.
@Stu: that was annoying me, too! In the next version, selection doesn't mark the map as "unsaved".
@Instant: From what I have heard, as ridiculous as the thought experiment is, it could never be dismissed as the nonsense it was initially intended to be. The fact that it still cannot be disproved is a sign of how far we still have to go in research of the field. Of course, I get all my information from entertainment media, so take all that with a grain of salt
(Japanese sci-fi absolutely loves Schrodinger's cat and I have heard it explained in great detail far too many times...)Personally I like the many-worlds theory. I don't have any logical reason, I just think that it's awesome.
It is, I just renamed it to "select" because "mark" doesn't make much sense in my opinion
I'm fairly certain I recently added that functionality - when you have the texture tool opened, open the browse window, find the texture, and press the "select" button.
I think it's because at the moment, Sledge reads line-by-line from the compile tools output, and the percentages are all written out on one line. It probably shows the percentages, but only after the task is 100% complete and it has moved onto the next one, which makes it somewhat useless.
I'll see if I can change it to show the percentages in a better way.
Edit: unfortunately it's not possible. The compile tools overwrite the progress with a carriage return to show the progress in place, like this:
10% complete\r
20% complete\r
30% complete\r
...etc...
This updates the percentage on one line and looks nice in the console, but that output is never actually "written" anywhere. If you look at a compile log with -estimate turned on, the percentage is not actually shown. Unfortunately the compile log output is the same output that any Windows program will get, so it's not possible to grab the percentage values from the console.
I can add a setting to show the console window instead of showing the log from inside Sledge, that would allow you to see the progress, at the expense of being more annoying.
I'll see if I can change it to show the percentages in a better way.
Edit: unfortunately it's not possible. The compile tools overwrite the progress with a carriage return to show the progress in place, like this:
10% complete\r
20% complete\r
30% complete\r
...etc...
This updates the percentage on one line and looks nice in the console, but that output is never actually "written" anywhere. If you look at a compile log with -estimate turned on, the percentage is not actually shown. Unfortunately the compile log output is the same output that any Windows program will get, so it's not possible to grab the percentage values from the console.
I can add a setting to show the console window instead of showing the log from inside Sledge, that would allow you to see the progress, at the expense of being more annoying.
@Striker: Sledge's current interface wouldn't work on a touch screen device - it would have to be a custom-made interface, which means that a lot of the code that does the important stuff cannot be reused. I don't think you can be productive enough on a tablet to make porting it to Android worth my time. The code is all in C# though, and Xamarin makes C# and Mono available on Android and iOS, so it is theoretically possible that someone could use some existing code to make an Android editor. I don't think that person will be me, though
Tablets are for consuming media, not creating it.
Tablets are for consuming media, not creating it.
@petedoble: Thanks for the feedback. Can you wait until the next release, and then let me know if this problem is fixed? I made some fixes related to sprite bounding boxes and I think they might have covered your bug as well.
@Urby: Does it happen all the time on certain brushes? Can you give me a brush that loses its texture values when it is cloned? You can paste the brush from Sledge directly into pastebin, the clipboard is plain text.
Sprite scaling is in the next version! But what is this "model scaling" witchcraft you speak of? Is that a SOHL thing?
@Scotch: It supports whatever size grid you want. Just go into setttings > game configurations > entities > and change the grid size to whatever. It also supports specifying the map size in the FGD like Source does (put "mapsize(-4096, 4096)" at the top of the file), but be aware that an FGD with that syntax will probably not work in Hammer 3.
@Urby: Does it happen all the time on certain brushes? Can you give me a brush that loses its texture values when it is cloned? You can paste the brush from Sledge directly into pastebin, the clipboard is plain text.
Sprite scaling is in the next version! But what is this "model scaling" witchcraft you speak of? Is that a SOHL thing?
@Scotch: It supports whatever size grid you want. Just go into setttings > game configurations > entities > and change the grid size to whatever. It also supports specifying the map size in the FGD like Source does (put "mapsize(-4096, 4096)" at the top of the file), but be aware that an FGD with that syntax will probably not work in Hammer 3.
Yeah, at the moment it ignores the scale of the sprite, I will add support for that later. You're talking about game sprites (env_sprite) right? As far as I know, the editor sprites (light, env_speaker, etc) don't have a scale...
VMF is better in every possible way, because it can have extra data without breaking compatibility with other programs that use it. It's sort of like XML in that you can add extra stuff to it, and programs that don't know about your extra stuff can simply ignore it.
When Sledge starts supporting newer features (e.g. displacements, instances), the only way to keep them in their proper editable format will be to use VMF. Sledge will warn users when they use a format that doesn't support features they are using, to make sure that they know data will be lost.
For example, say you create a displacement and save it as RMF. Sledge will first warn the user that RMF doesn't support displacements, but if they ignore the warning and save anyway, the displacements will be converted into a bunch of tetrahedrons. You can still open the RMF, but the displacement no longer exists, which means you cannot edit it using the displacement tool anymore. (Note: Displacements aren't supported in Sledge yet, but eventually they will be!)
Already Sledge uses VMF's additional features to save data that RMF doesn't allow: multiple visgroups, grid size, ignore groups on/off, and other minor things. In the future, there will be MAJOR features that depend on VMF to work, so I recommend using it for everything. You can always export RMF/MAP if you need that format for whatever reason.
Edit: VMFs saved by Sledge DO NOT have rounding errors! Hammer 4 does, Sledge does not!
When Sledge starts supporting newer features (e.g. displacements, instances), the only way to keep them in their proper editable format will be to use VMF. Sledge will warn users when they use a format that doesn't support features they are using, to make sure that they know data will be lost.
For example, say you create a displacement and save it as RMF. Sledge will first warn the user that RMF doesn't support displacements, but if they ignore the warning and save anyway, the displacements will be converted into a bunch of tetrahedrons. You can still open the RMF, but the displacement no longer exists, which means you cannot edit it using the displacement tool anymore. (Note: Displacements aren't supported in Sledge yet, but eventually they will be!)
Already Sledge uses VMF's additional features to save data that RMF doesn't allow: multiple visgroups, grid size, ignore groups on/off, and other minor things. In the future, there will be MAJOR features that depend on VMF to work, so I recommend using it for everything. You can always export RMF/MAP if you need that format for whatever reason.
Edit: VMFs saved by Sledge DO NOT have rounding errors! Hammer 4 does, Sledge does not!
I've been going on something of a bug fixing frenzy in the last few days, mostly related to undo and redo not doing what it's supposed to. I think I might have fixed up Striker's issue with clipping and VM stuff too, but if anyone is experiencing that I would love to get more info to double-check.
@Stu: Settings slider values: shouldn't be too hard to add in, I'll check it out.
Middle clicking to free-look: again, should be possible to do this.
@TJB and others: As Tetsu0 explained, rotation around any point can be done by moving the origin point when the select tool is in rotate mode. I have noticed some cases where the rotation point can be difficult to "grab" (not recognising clicks sometimes), but I haven't had time to investigate. Hover the mouse around there, the cursor should change when you are over the origin point.
@Unq: Thanks for the feedback! Inverting the mouse should be an easy fix, I'll put it in the next release. Light (and other entities) helpers might take a bit longer to add, but they're definitely planned. I want to support whatever Hammer 4 uses to add the helpers (FGD stuff, probably), and then maybe add a few extra helpers that Hammer doesn't have, too.
@Stu: Settings slider values: shouldn't be too hard to add in, I'll check it out.
Middle clicking to free-look: again, should be possible to do this.
@TJB and others: As Tetsu0 explained, rotation around any point can be done by moving the origin point when the select tool is in rotate mode. I have noticed some cases where the rotation point can be difficult to "grab" (not recognising clicks sometimes), but I haven't had time to investigate. Hover the mouse around there, the cursor should change when you are over the origin point.
@Unq: Thanks for the feedback! Inverting the mouse should be an easy fix, I'll put it in the next release. Light (and other entities) helpers might take a bit longer to add, but they're definitely planned. I want to support whatever Hammer 4 uses to add the helpers (FGD stuff, probably), and then maybe add a few extra helpers that Hammer doesn't have, too.
Sledge doesn't have any problem with off-grid vertices if it is loading a VMF that is saved by Sledge. It will be accurate to 8 decimal places with no loss of precision.
You will get minor rounding issues when interacting with Hammer:
@rufee: .NET's Decimal isn't native to the CPU, unlike floating point. This means it is slower, but allows for much more precision. It's a 128-bit storage format, which is entirely unrelated to how many bits the CPU uses. It's not any different to creating a 128-bit struct in C/C++/whatever.
@COOBORKY: Yes, putting a background image on the 2D grid has been a suggestion for a while. It will be added at some point.
@Striker: Have you updated to 0.1.0.24? Is there any other information you can provide on how I can replicate this bug? What is the error message you get when it crashes? Did you click submit on the bug report?
You will get minor rounding issues when interacting with Hammer:
- Loading an RMF file (saved by Sledge or Hammer): RMF saves FP values, which are approximately accurate to only 6 or so decimal places. That should be plenty, though.
- Loading a VMF file (that wasn't created by Sledge): By default, VMF only stores the planes of a solid, rather than the vertices. Sledge needs to perform the plane intersection algorithm to get the actual vertices back again, which may cause slight imprecision and off-grid vertices due to Hammer saving the value as a FP number. After fixing any errors and re-saving, the errors will not return (unless you open and re-save the VMF in Hammer again).
@rufee: .NET's Decimal isn't native to the CPU, unlike floating point. This means it is slower, but allows for much more precision. It's a 128-bit storage format, which is entirely unrelated to how many bits the CPU uses. It's not any different to creating a 128-bit struct in C/C++/whatever.
@COOBORKY: Yes, putting a background image on the 2D grid has been a suggestion for a while. It will be added at some point.
@Striker: Have you updated to 0.1.0.24? Is there any other information you can provide on how I can replicate this bug? What is the error message you get when it crashes? Did you click submit on the bug report?
No, but I am now....
I am intrigued by this idea.
I am intrigued by this idea.
I'm not entirely sure what you mean, are you talking about if/when there's a plugin system? I'd make some sort of API available to .NET and/or a scripting language such as Python or something, but C++ wouldn't be an option. If you're used to C++, C# is pretty easy to learn.
It sends a HTTP request to a website, nothing special.
I look at the list every now and then and try to figure out how and why the bug happened, and see if I can fix it.
You can see the bug reports here: http://bugs.sledge-editor.com/
I look at the list every now and then and try to figure out how and why the bug happened, and see if I can fix it.
You can see the bug reports here: http://bugs.sledge-editor.com/
I just fixed the problem with changing between entity types, it will be in the next version.
It's a shame you weren't able to submit the window-spamming bug, I'll take a look at it but without more info it makes it difficult.
It's a shame you weren't able to submit the window-spamming bug, I'll take a look at it but without more info it makes it difficult.
Reverse-engineering software is not illegal. The only way something like this could be illegal is if it uses code that has been stolen from Valve - as far as I know, this engine is written from scratch to replicate GS, but doesn't use any of the original GS code.
Besides, why should anybody be telling someone how to spend their time? If someone wants to put effort into recreating Goldsource-related software from the ground up, why shouldn't they not be allowed to?
EDIT: Of course, the HL EULA does forbid reverse-engineering, but let's just ignore that...
Besides, why should anybody be telling someone how to spend their time? If someone wants to put effort into recreating Goldsource-related software from the ground up, why shouldn't they not be allowed to?
EDIT: Of course, the HL EULA does forbid reverse-engineering, but let's just ignore that...
Many projects exist simply because the creator enjoys working on them. Is that not enough of a reason for this to exist?
Yeah, I'll add some more detailed information (line number, character index, etc) to the error message so people can find where the error is in the FGD file.
Edit: How's this:
Edit: How's this:
The COF FGD seems to have a syntax error. Open it in notepad, and on line 944, change this:
button ((choices) : "Ratio to get (Scale)" : 0 =button (choices) : "Ratio to get (Scale)" : 0 =I kinda broke some important things in the last release, so now it's time for a bugfix that should fix it up! I also implemented Archie's suggestion of not showing an infinite clipping plane in 3D, because that looks stupid.
Release notes:
@Archie: I'll add multi-tile fit at some point...but I will need to re-arrange the texture tool window to fit it in somewhere, which is annoying >_>
Shift+Arrow Keys in 3D can be done. Are there any other missing obscure keyboard shortcuts that you know of?
@Rim: It's certainly a long way away from doing something like that, I don't know how possible it is to import an arbitrary .obj file into a displacement. It's really hard to try and import a model format like .obj (and others) into a solid/bsp format.
Release notes:
- Don't display an infinite clipping plane in the clip tool
- Made sprite files open without permission errors
- Fix multiple issues related to undoing, clipping, moving, and various other important things
- Fixed transparency on the display list renderer
- Removed immediate mode renderer (use display list instead)
- Connect the close button on the entity report dialog
@Archie: I'll add multi-tile fit at some point...but I will need to re-arrange the texture tool window to fit it in somewhere, which is annoying >_>
Shift+Arrow Keys in 3D can be done. Are there any other missing obscure keyboard shortcuts that you know of?
@Rim: It's certainly a long way away from doing something like that, I don't know how possible it is to import an arbitrary .obj file into a displacement. It's really hard to try and import a model format like .obj (and others) into a solid/bsp format.
Yes, you can open models from Blender or some other 3D tool using the .obj format, but if the model isn't a valid solid (and most of the time it won't be), it will create tetrahedrons for each face in the model. It's not very efficient!
I haven't really used any of the render modes before, how do they work?
I haven't really used any of the render modes before, how do they work?
Thanks, I'll be sure to fix it in the next version
Time for a new release! This version fixes the long-standing texture corruption bug that some people were noticing. Also, sprites rendering in the 3D view. Changes below:
Major features
@Mozartkugeln: No, you rock!
Thanks again for your contribution!
Major features
- Render sprites in the 3D view. Fixes #106.
- Basic .obj format support
- Render vertices in the 2D views. Fixes #169.
- Implemented the "select" button in the texture browser. Fixes #115.
- Option to use Sledge as a single instance application (on by default)
- Windows file associations and jump list support
- Sprite browser for the object properties dialog
- Added support for the new SteamPipe downloads and addon folders. Fixes #171.
- Add support for HD models (can be toggled in the game settings)
- Change the default format of screenshots depending on what viewport type is active. Fixes #165.
- Fix texture axes becoming corrupt when copying brushes. Fixes #93, fixes #133.
- Change bevel to behave like null instead of like aaatrigger
- Closing the VM tool window switches back to the selection tool
- Remove duplicate Ctrl+H hotkey binding
- Add grid colour preset buttons. Fixes #167.
- Make the entity bounding box align properly with the model. Fixes #168.
- Only select vertices for a single solid when clicking in the 2D view with the select tool. Fixes #145.
- Disabling the nudge setting now actually disables nudging
- Minor teak to get invalid solid checking more reliable
- Optimisations for selection and manipulation operations for large maps
- Made box size font a bit smaller
@Mozartkugeln: No, you rock!
Thanks again for your contribution!
You know that the VDC is just a wiki that anybody can edit, right?
I doubt anyone from Valve actually uses it.
I doubt anyone from Valve actually uses it.
That reminds me, I should update the website, some of the info is out of date now
Good news for those experiencing the texture stretching issues: I've finally found the bug and have fixed it, so the next release will resolve the issue
Big thanks to Alberto and his friend Wheatley (as well as everyone who reported the bug) for helping me diagnose the problem.
Big thanks to Alberto and his friend Wheatley (as well as everyone who reported the bug) for helping me diagnose the problem.
Success! We finally got it working for you 
OK: New release to fix the bugs:
Fixed infinite loop when deleting groups/entities
Added detection and forced override for resizing of non power of two textures
Change the WAD cache separator char and add error handling when parsing the texture cache
Optimised icon file sizes
Fixed infinite loop when deleting groups/entities
Added detection and forced override for resizing of non power of two textures
Change the WAD cache separator char and add error handling when parsing the texture cache
Optimised icon file sizes
The delete thing is happening for me as well. I have fixed it, I'll do a patch release soon because that's a pretty bad bug
Yeah, I'll see what improvements I can make to the texture favourites stuff later on
Do you mean when there's nothing selected and it moves the camera? I was just making it the same as Hammer, but I could make it a setting if you want. If you have something selected and the arrow keys still move the camera then that's a bug, unless you have "arrow keys nudge" disabled in the 2D view settings.
Thanks for uploading the files, I found the problem, it's in your "hq_textures.wad" file. The texture "hq_weird_brick" actually has an invisible "ASCII Unit Separator" character between the "hq" and the "_" in the name. I was using that character as a delimiter in my texture cache so that's what caused the bug. I changed my delimiter and also added some error handling in case it happens again, so it will be fixed in the next version. If you don't need it, removing that WAD should fix the problem in the mean time
I love that you use so many WAD files, you find all the WAD-related bugs that I can't find
Thanks for uploading the files, I found the problem, it's in your "hq_textures.wad" file. The texture "hq_weird_brick" actually has an invisible "ASCII Unit Separator" character between the "hq" and the "_" in the name. I was using that character as a delimiter in my texture cache so that's what caused the bug. I changed my delimiter and also added some error handling in case it happens again, so it will be fixed in the next version. If you don't need it, removing that WAD should fix the problem in the mean time
I love that you use so many WAD files, you find all the WAD-related bugs that I can't find
Ok, unfortunately it looks like one specific wad file is causing the error -_-
Can you zip the whole TextureCache folder and upload it somewhere please?
Can you zip the whole TextureCache folder and upload it somewhere please?
Yep that's the one. Looks like the problem is with the texture cache, if you look in the same folder (%appdata%/Sledge), there'll be a subfolder called "TextureCache" - can you upload one of the files from that to pastebin?
After you upload it you can delete the folder and that will stop Sledge from crashing (unfortunately the error will occur next time you start Sledge after that, so you need to keep deleting it).
After you upload it you can delete the folder and that will stop Sledge from crashing (unfortunately the error will occur next time you start Sledge after that, so you need to keep deleting it).
Can you submit the error so I can see the full detail, and also put your Sledge.vdf file (located in "%AppData%/Sledge") onto Pastebin so I can investigate?
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
Example screenshot:
Minor features
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.
- Added favourite textures in the texture browser. Fixes #14.
- 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
- 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
That looks really cool, but I'm going to work on other more important features first