Bloodknight

Just came across this on steam http://store.steampowered.com/app/388820/Raiseland/ it will apparently be discontinued after the 16th of August, so I figured I'd throw a quick post here in case anybody else might think it's worth a gamble at a silly price. I haven't had much of a look yet, but it does export height maps, so if nothing else, that's a thing.

Something is badly wrong with that last line, it looks like a chunk of file has somehow gotten deleted and the filename has been replaced by a header guard.

look for TerrainEditor::autoMaterialLayer in terrainEditor.cpp, this shows how to paint the terrain via code.

A Big Thanks to Az who recognised the errors and had fixed them in his version https://github.com/Azaezel/Torque3D/commit/8ca53c771f8b8e25c5cb37fe74632ffb20fba4dc https://github.com/Azaezel/Torque3D/commit/8501f2e6fc20ea4dac963669f75e184779bfde69 Now I can get on with making the rpg module

Solution to this problem was added to the repository a few weeks back, posting here in case this is the first thread people find looking for solutions http://forums.torque3d.org/viewtopic.php?f=2&t=1046

Current branch can be found here https://github.com/Bloodknight/Torque3D/tree/AFX_DevHead The error list that VS provides is here https://pastebin.com/SV9sKXeR I have reached my limits on the fixes that I understand.

For those who cannot compile the 3.10 master branch, the following fix needs to be applied. https://github.com/GarageGames/Torque3D/commit/ef1edd375116c6ab1dffb9ba30620353439b5afd https://github.com/GarageGames/Torque3D/commit/7cc0373b4829a692339d1ab66c60de045d212abf The question this leads to is should the SC start to consider a git flow type system whereby fixes like this are applied quickly (well I mean when found and fixed) to the master branch and not just rolled into the devhead. Assuming most people use stable versions vs cutting edge changes in devhead, would it not make sense to have bug fixes applied to these versions? while most are probably trivial, this particular problem is a show stopper, and not everyone thinks to look through individual commits of development versions to fix a 'stable' version.

I think the issue is more one of an emergent behaviour based on more than one change in a variety of slightly different systems, rather than a specific decision made on a particular part. Or at least that is my understanding after the past few hours or work and discussion by those smart enough to fix such things :)

Yes, the first one is made by me and the second one is the same, but after you broke it, congratulations, this now proves that you have no idea how it was done before after you broke it. For all others please ignore this as there is no different terrain method used in both slots nor any different blending methods, nor any different terrain materials, the only thing that happened is that Bloodknight ripped the terrain out of my game and broke the scene by importing it in default Torque without keeping the settings or the features added in my engine fork. This proves nothing other than Bloodknight having no idea what he is doing. congratulations on making yourself look completely silly. Both of those screenshots use EXACTLY the same textures with EXACTLY the same settings

[13:26:54] [bloodknight] 3.8 default detail strength 1 http://i.imgur.com/qSyXlRX.jpg [13:27:21] [bloodknight] 3.8 detail strength 2 http://i.imgur.com/hiZhXtL.jpg [13:28:09] [bloodknight] 3.9/3.10 default detail strength 1 http://i.imgur.com/JyjR7GF.jpg [13:28:47] [bloodknight] 3.9/3.10 detail strength 0.5 http://i.imgur.com/CL19wO9.jpg you can increase the intensity of the detail in 3.8 by increasing the strength value, this does so nice and even, in 3.9 and above the only way is to decrease the detail intensity which kills the detail While this is probably getting into the realms of subjectivity with regards to visuals, to me at least the former system allows for much more flexibility, while the current systems forces you to make perfect textures else it will look terrible. It appears to me at least that this change was made without proper testing, I did note that there was a change at one point to lighten the supplied detail textures, this imo does precisely the opposite of whats needed, it reduces the detail levels and at the same time does not fix the ugly intense spots. for me at least i am going to hunt down the change from 3.8 and revert it, hoping to hell that this isnt part of the dx11 changes

if by intensity you mean the strength settings, they are pretty useless now compared to previous versions regardless of the workflow methods. Problems are as such :- If you want to use greyscale detail and macro textures as is the traditional method, you need to make quite a pale greyscale image, then to get the level of detail you require starts to force the whites through and 'wash out' the colour of the main texture, if your greyscale is too dark then it all goes to pot really quickly. Using coloured detail textures, which used to work, no longer works at all, there are no settings I can find anymore that create decent looking terrain painting with this method. Now it may be that this method of working is no longer supported, but it was always a fallback when detail textures were of insufficient quality to make decent looking terrain. http://i.imgur.com/kTBfeSG.jpg http://i.imgur.com/qD0afeX.jpg The second of those two images has the ability to be improved via tweaking imo, the first not so much

Pretty sure that's the first time I have seen anybody argue to keep something more difficult than necessary :p While there are a multitude of nuances that make textures great, removing tessellation artefacts, getting the lighting right etc does not mean that the terrain painting system should be difficult for an average dev to make good terrains for. Despite duions valiant attempts to tell the world that his terrain textures are the best terrain textures in the world, it is obvious that those textures do not actually work with torque. The blending artefacts displayed in jeffs images exist everywhere regardless, to such an extent that even the so called best textures ever look shite, I even downloaded the latest ubergame to see how duion does it to make them look good, I figured there were just some settings I was missing. but they look shite in ubergame too.

yes, but they can break code, depending on what gets changed

@Timmy it was more of a tale of caution regards running a style changer across an entire codebase to get it up to scratch. I do like the idea of a switchable style system that allows you to auto style for whichever project you are working on at the time, seems to be sadly lacking in IDEs

So, every couple years or so this topic pops up. iirc the last one was literally all about the indents (i personally favour 4 over 2), the problem is that many developers have holy views regarding their style, and as such conversations generally end in religious debates on every single point. Personally, i have a few pet hates, the first of which is un bracketed single conditionals, I can't tell you the number of times I've seen a conditional added to and then not work because braces weren't added; rookie mistake maybe, but relatively common none the less. My next pet hate is 2 space indents, I personally find the small indents problematic in that I can lose an indent when quick scanning the code, 4 space indents make it much more difficult to miss an indent. Generally, I can work with whatever styles are being used, and adapt to that style when working on a specific project, lately, I've been tinkering with C# work and I've just left that shit as default because I can't be bothered to tinker with style settings. The general consensus having discussed this with those who do most of the work was:- 1. Fix already not correctly styled code when working on those particular files. 2. A consensus is never likely to be reached within a wider audience. There is another issue that needs to be mentioned, I have seen astyle and other similar systems completely break projects, so this is not as simple as just running a style fixer on a project. I suspect that trying this on torque, given some of the outright shitty and shifty practices that have gone on in the past would result in complete disaster and as such turning this exercise into a much larger task than necessary.

The console.log file is locked open by torque, you need to change the system so that it flushes and closes so that other applications can access the file. I believe this has a performance cost however, options are flushing periodically, one minute, five minutes maybe. There is also the console/CMD/Terminal window option for live viewing of output.

This looks fun, i recall a conversation with Az a week or few ago about how useful this would be, ive been heads down in Assignment handin mode the past 2 weeks, i'll see if i have some time this weekend to test and break this (breaking, its what i'm best at :p )

VS screenies http://i.imgur.com/KnZC20g.png console.log http://pastebin.com/B4Y9CP5s

Oops, win 10 64, probably cheapass home version. Of the few programs that did act up adding them to the nvidia whitelist did the trick, why this isnt the case for my compiled torque project i dont really know, been busy with other stuff so haven't yet had time to investigate and document further

Game keeps ignoring all my GPUs even when i set the nvidia gpu to be the only one switched on (even my battery was begging for mercy after 10 minutes). Cant find the pastebin post since i did on a guest acct on laptop itself, but the upshot is that it was loading the null driver, and then dying, i'll post log later. Ive tried all of the conventional methods, and they don't appear to work, so any suggestions to fix this before i push it to github as a real issue would be nice. edit: i still think an actual issues page on the forum might be useful, since i dont really think operator failures should be posted to github issues

by not intended you mean when you hit the brakes, the headlights come on so you can see the full horror on the face of the victim late at night?

yes its a ridiculous key... but it stops you hopping out by mistake for future reference this long and ugly file contains all the binds and functions https://github.com/GarageGames/Torque3D/blob/c83efa59e0a11fc15c68afaf106807643191ac6f/Templates/Full/game/scripts/client/default.bind.cs#L740

ctrl-f

The two are effectively the same, as far as rumble i dont believe so, but i believe that adding wouldnt be difficult via directx since support is there

https://www.shadertoy.com/results?query=refraction