This member has provided no bio about themself...
If you edit textures you can just reload all materials (Materials -> Reload All... or use the button in the materials inspector, at the top right).
Small typo: the old behaviour is actually with "Centered transforms" unchecked.
1) I don't think that map is available anymore, it was made for testing some texturing stuff. But yeah, that tutorial should be good enough, you can get working terrain in OverDose using that method. Currently, we are using a huge terrain model (func_terrain entity) with vertex blending for the texturing (as in that tutorial), but I'll be looking into a better texturing method in the future, something more flexible and easier to work with.
2) 1 game unit equals 1 inch (or 0.0254 meters). As a reference, the player's bounding box height is 74 units (about 1.88 meters) and size is 32 units on each side (about 0.80 meters).
Remember to export models in ASE, OBJ, or LWO formats, and use the ODModel tool to convert them to the format used by OverDose.
You mean a brush "face" or the whole brush? Because faces yeah, they are limited to polygons with just a few sides by design. Try doing what you need with more adjacent brushes or some other trick.
If it's the whole brush, while in theory it should be entirely possible to do, in practice you're not really supposed to make very complex shapes with brushes, you're better off using models. Anyway, if you're having this problem with a 14 sides brush (not a 14 sides face), please send me a sample .map file so I can reproduce the problem here and find a fix.
As for the sky, no idea as I'm not a designer, I'll point Gavin to your question. In the meantime there are quite a few sample maps in the "maps/sdk" directory, you may find some example there.
Yeah, you can, but beware the game code is work in progress and while the engine itself is 100% functional as it is, it is missing quite a few planned features and some bug fixes / optimizations. That is, use it at your own risk...
Type "sv_pure 0" at the console before trying to load any map. It's a development thing... the final game will not require this from normal users.
Sorry, guest above is me...
Look in renderer/r_postProcess.cpp and sound/s_reverb.cpp files.
Shouldn't. Sounds like OpenGL is crashing when loading shaders or setting up framebuffers or something like that.
Add "+set com_developer 1 +set com_logFile 2 +set r_logFile 1" to the command line and after running the game look for a file called "renderer_DATE_TIME.log".
Post the last few lines here or, better yet, email the file to email@example.com (attach the console.log file too).
The command in OverDose is "+set com_logFile 1", but I'd suggest "+set com_logFile 2" instead which doesn't buffer writes to disk, meaning messages can be lost in the event of a crash.
Yeah, you must download the DirectX SDK from June 2010.
You don't need to go through all the hassle if you don't want to do anything with the code BTW. I always upload the latest binaries whenever I update the code.
Hopefully soon, keep in mind we do this in our spare time. Everyone is welcome to help with maps, models, art, etc... that would allow a faster progress too :)
Yeah, thing is Gavin moved recently and he's still working on his new house. I could post some screenshots, but programmer screenshots suck, so... forget it, lol.
I use VS 2010, but newer versions should work if you convert the project files I suppose.
You need the Windows SDK and DirectX SDK (June 2010). The rest should be included already.
There is no weapon code in the public build yet.
You need to set "sv_pure 0" at the console every time. Then load a map with the "devMap" command.
You can add this to an autoexec.cfg file in the "base" folder so that you don't need to type it every time you run the game:
set sv_pure "0"
If you download all our files from the SVN repository, there are binaries included (tho they are debug builds, ie: a lot slower on the CPU). If you have Visual Studio you can try compiling a release build yourself with full code optimizations.
Well, both DarkRadiant and GtkRadiant should work, as well as the integrated level editor from DooM 3 (or Quake 4 for that matter). We use the same map format, however a few things are different when it comes to materials/textures. It may be a bit annoying at first, but it's not that big a deal really, and it works while we develop our own level editor. Unfortunately I'm not a mapper myself, so I don't know the exact details. I'll ask Gavin about it, maybe he can write a small doc explaining how to set things up.
1) If you use a SVN client (such as TortoiseSVN) you can use the "SVN Update" option and it will just download the new/modified files to keep your copy in sync with ours. The final game WILL have an updater that'll automatically download patches once available.
2) No bots are planned at the moment. Good AI takes a lot of time and we rather concentrate our efforts in a well balanced "humans vs humans" gameplay. It's not a feature we will never consider though, just not a priority.
Yeah, ODRadiant is being developed from scratch by Buzzard. It doesn't do anything useful ATM.
The main menu doesn't do anything ATM.
You need to set sv_pure 0 in the console before loading maps (otherwise the code only tries to load files from pk3 packs).
Thanks for the compliments. And yes, we're always looking for help.
No, you still need a modern computer, even to get a stable 30 FPS.
If it's really (and properly) supported on other GPUs, and it's not too much time and effort to port the current OpenGL code, I might consider it.
Nah, never was. It's just at times we keep quiet for a while.
I don't know. I'll probably wait til the animation system is finished, not sure.
NVIDIA has its share of bugs too, but yeah, based on my own experience ATI/AMD OpenGL drivers are buggier, but not as bad as they used to be years ago.
That card is not yet widely available over here and I couldn't find any decent brand either. The price difference is insignificant between a first-class-brand 680 and a second-class-brand 770, so I went for the 680.
It also requires a bit more juice and I didn't want a new PSU.
ATM I'm working on the FX system and other misc stuff. But yeah, the FX system would be the most important feature in the upcoming internal build.