Comments - [Berserk]

Thanks mate. Yes, we are, just at a slower than desired pace, but we never abandoned anything.

There will be, but we can't say when. We work on this in our spare time, we can't put more than just a few hours a week into it unfortunately, and, again unfortunately, we're only three guys working on it ATM.

A complete rewrite of the code. And I really mean complete.

Nope, never heard of it myself, tho I'm a programmer, not into map design at all. We have our own version of Radiant anyway, which supports everything we need and everything works exactly as it should... for us, of course.

We have around 15 GB here, but not sure how much is actually downloaded and how much is local backups, etc.

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

Sourceforge.net

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.

edit?

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 nicolasmf@hotmail.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.