Doh ! 

config file no more + added a proper skybox as well as fixing the odd waterbrushes 

skill 2, 2 secrets

I didn't like sound design that much, but gameplay is quite nice. Map left me wanting more.

Imho rooftops are just asking to have some action there.

Oh and atm it is possible to get stuck in quad exit door. Demo included.
I think you can prevent this by adding clips to the sides of quad shaft.

https://drive.google.com/open?id=0B3li06myS1r1NmJIc3JCVTVhczA 

*Fullbright pixels begone for dmc.wad
*Did clip brushes for windtunnels to better orient the player
*Pushed maximum nail ammo to 250
*Added scrags on the bridge parts, keep the dogs for easy mode
*Getting the BFG while picking up MegaHealth has been fixed

http://www.mediafire.com/download/kxhaw2l9nn9ft6t/schlossherr.zip 

I'm not sure if fullbrights fixed in dmc.wad supposed to mean that there should be none of those anymore or one wad is fixed and few more to go.

I can still get stuck in quad door. Was a bit tricky to find it since my previous method doesn't work in this version.
https://drive.google.com/open?id=0B3li06myS1r1ZFJ2Rko1NC01d0U
Pushing player farther or closing door earlier might solve it I guess.

Found gate#8 this time. 

*This time, no more fullbright pixels (I admit I got lazy here, only got dmc.wad but that's because TexMex's remove fullbright feature is wonky so I had to edit textures myself)
*Didn't notice this, but going to the belltower secret before going through the rotating doors make going back to the lighthouse a chore, so I added a trigger up there to open the gates if they aren't. 

 

Door seems to be dw-proof now.

Found few fullbrights and one z-fight.
https://drive.google.com/open?id=0B3li06myS1r1Y0pxRC1KamZ2bUk 

What you reported + realigned some crates in the Gate#8 deposit 

Sorry, last time I started my search after finishing the map, while all doors were open and missed these

https://drive.google.com/open?id=0B3li06myS1r1ZWU4bzJfME5tWmM

Aside from that I think you are good to go. 

Link for those who don't want to search in the thread
http://www.mediafire.com/download/kxhaw2l9nn9ft6t/schlossherr.zip 

 

Keep it up, also good work on the new guns. Especially the BFG, it's probably the best version of the gun I have seen in Quake. 

But thanks! 

;) 

The BFG's unfinished though. Not only did I not put in ammo consumption (I plan for 30 cells per shot), I need to make the initial impact sprite appear (which doesn't even though I literally took the original explosion code alongside doom's sprites, I can't find a solution to this, same goes to the Rocketman's rocket explosion sprites which doesn't appear even though it's the same explosion code as vanilla) and as for the sphere going through gibbing enemies, I have to find a way to destroy the initial projectile and make a new one while still using the first projectile's speed and angle (I have no idea how to do this).
I plan on adding a weapon similar to Daikatana's Shotcycler (but with more power to it, think actual 6 consecutive SSG shots) as well as adding a Berserk powerup (that will add a lot of IF in the code...)
But since I'm using hipnotic's source code tacked on, nicely placed weapon HUD won't be a thing, since Preach told me I can't add nor change HUD elements, only modify the icons. A shame. I could've at least make an Infantry Gun, Gatling Gun and BFG9500 weapon icons if I used rogue's sourcecode, but I guess that's too late now. 

I didn't know you couldn't change the hud... is it hard-coded? 

"You only have three options as to how the HUD works. You can have the HUD like it is in vanilla, or the HUD from mission pack one, or the HUD from mission pack two. You can customise the icons themselves, but there is no way of rearranging them or adding more than what the mission packs have. The mission packs got special customisations to the engine code before the source was released, it's not something the QC gives you any ability to change. " 

So it would require an engine change? 

Something like Darkplaces would overcome it I think, or hell, a port to a new engine to really break engine limits (which would mean no more bit slots and modifiable HUD).
But I want Schlossherr to be compatible with the most clients possible (yeah there's colored lighting and skyboxes but whatevs), so rendering it DP-only is a no-no to me. 

fourth method:
csqc can change huds however it wants. obviously this requires people to use an engine that isn't basically crippleware.

fifth method:
either svc_showlmp or tei_showlmp extensions. while limited and a real pain to use (on account of not knowing the user's screen size, these can provide simple additions that are usable from ssqc. oh noes! an extension! I shall surely burn in hell for suggesting that!

sixth method:
make a guess at the user's video resolution and spam centerprints at them, with enough new line chars that the visible text appears just above their hud.
this one truely is evil. and hacky on account of not knowing their resolution, and can't do images. But hey, if your user doesn't want to give you any possibilities of using extensions, they'll be the ones to suffer by having to explicitly tell the ssqc what resolution they're using so that the mod can waste enough of their bandwidth with new lines to put the text in the right place.

seventh method:
directly hack an engine so that your mod stops working correctly as soon as the user tries to use an engine version which doesn't crash on the next limit-breaking map or whatever.
yay hacks. 

I could try csqc but that thing's barely documented and is DP exclusive. Where can I get that/those extensions? 

DP exclusive
no offsense, but that's bullshit.
FTE's implementation is much more versatile.
And if you want something more like quakespasm (and by that, I mean crippleware) then RMQe's implementation is sufficient for most huds.

which part of http://triptohell.info/moodles/fteqcc/csqcsysdefs.qc do you believe to be poorly documented? Imho its better documented than vanilla ssqc was (but then I'm biased as I wrote that stuff and thus understand it perfectly). Yes it is also more versatile/complex than vanilla ssqc and thus does kinda need more docs, you can't win them all. That said, if 'use the source' worked for carmack, then I'm going to be lazy too... :P
I'd be nice to add better/more complete descriptions to it, but I'm a) lazy. b) terrible at explaining things without getting annoyed at how verbose you need to be to fully explain things, and how fully explaining things does NOT aid with idiot-proofing at all and it being those people who actually need it to be fully explained. What can I say? Mutual exclusions annoy me.
Anyway, once you know the name of something, you can generally search insideqc.com's forums and get further info that way, and I'd like to think that most of it is fairly self explanitory once you know that the builtin exists. If you still have any problems, post about them (ideally on insideqc) and in that way the available 'documentation' will hopefully improve enough to help someone else, even if you yourself are defeated by it.
here's my old poopy hud code: https://sourceforge.net/p/fteqw/code/HEAD/tree/trunk/quakec/csqctest/src/cs/hud.qc?format=raw
you need some CSQC_RenderView function that called clearscene();setviewprop(VF_ENGINESBAR, FALSE);addentities(3); renderscene();Hud_Draw(...); and you should have something that looks somewhat like vanilla but is fully defined by qc.
I'm sure you can find nicer examples out there if you look.
basically, use getstatf to read the various STAT_* values (clientstat in ssqc to define custom ones starting at 32+), then call drawpic, drawfill, drawstring accordingly to throw it all at the screen.
DP requires some other functions, which you can provide stubs for easily enough. RMQe is a bit more basic in that its qcvm requires a very specific defs layout, and has multiple omissions.
Additionally, here's my attempt to repeatedly insult anyone who complains that csqc is poorly documented: https://sourceforge.net/p/fteqw/code/HEAD/tree/trunk/specs/csqc_for_idiots.txt?format=raw - once you have a basic understanding of the various concepts, the entire thing becomes much more aproachable.

if you want nehahra's svc_showlmp, then:
WriteByte(MSG_ONE, 35);
WriteString(MSG_ONE, "slotidentifier"); //just a name/id, not visible to the user in any way.
WriteString(MSG_ONE, "gfx/foo.lmp"); //the image to display
WriteByte(MSG_ONE, xcoord); //might be a short in one of dp's other protocols, good luck guessing what it'll expect. nehahra used bytes.
WriteByte(MSG_ONE, ycoord); //yes, this means that the image is probably limited to the top left of the screen. you have no idea how big the screen is either, so that's probably for the best.
you can then move/replace it by using the same series of writes.
To remove it completely:
WriteByte(MSG_ONE, 36);
WriteString(MSG_ONE, "slotidentifier");
note that while the extension is called 'showlmp', engines will probably also support tgas too, but they *might* still depend on the lmp to determine the proper image size (hurrah for the lack of width+height args). Or they might just display your high-res image at a really really high resolution... yay engine-specific behaviour.
this particular extension should exist in nehahra (of course), dp, markv, and fte.

you can find documentation for tei_showlmp2 in http://triptohell.info/moodles/fteqcc/fteextensions.qc but there's no real descriptions. this extension came from telejano, hence the prefix.
there's a bit more functionality to it, in that it has a 'zone' argument, so you're no longer limited to only the top left of the screen, and you no longer have to guess the screen size. the coords can be a bit weird though, as tei opted to require 8000 to be added or something like that rather than use signed offsets. its also utilised via builtins rather than having to guess whether the current network protocol is using shorts or bytes. however, it only exists in fte+telejano, and its been years since I heard anyone else even mention telejano. shame really, but oh well. as the original showlmp works in fte anyway, you're probably best focusing on that prior extension and only using this extended extension if there's a compelling need for something that'll only work in only one current engine.

looks like I wrote another essay... meh, screw proof reading. 

My mistake on believing it was DP only.
Though while it looks interesting, I don't really understand how it works, nor its functions. I guess I should've said instead of lacking documentations, more like it lacks tutorials, since I don't see many people use it that much, so I don't really get what does what.
Still, I'd like to know more about CSQC. Maybe after working on that HUD stuff I could see if I can move the weapon viewmodel around the screen, like nQuake did (though purely for cosmetic reasons, sometimes I like me some side weaponmodel, better if I can switch that on while looking at demos). 

when you start using extensions - any extension - you can find yourself tempted to use just one more... CSQC's versatility makes this so very tempting.
There really is no harm with just making a hud and stopping there.

I keep thinking that I ought to write a patch for quakespasm or markv to provide hud-only csqc support, except that I'd probably end up overcomplicating it or something, plus I've got enough other stuff demanding my attention.