Is there a way to ramp up the speed of the projectile shotty pellets? I find them a little slow as they are.

The speed of the projectile shotgun are fast enough. The SSG/TSG are 1500 and the SG is 2000. As a comparison the NG/SNG/RL are all 1000. If you want the shotguns to be any faster, either change the progs to suit your gameplay style or use hitscan.

Same goes for the crossbow knight's bolts, they're too easy to evade
Have you tried the crossbow knights on nightmare skill? Most projectiles get faster based on skill level and the bolts scale as follows:
500=easy, 700=normal, 900=hard, 1100=nm

If you want a good example of crossbow scaling, load up 'ad_test6' go to the crossbow arena and change the skill level via the console. The projectile speed is dynamic based on current skill level settings. 

the AD plasma gun replacement of the lightning gun seemes odd to me, where does the LG go, why would I drop it to pick up the plasma gun. Lame.

I think Quake has too many weapons already and adding more is always going to be tricky because many of the existing weapons are good for certain game play styles.

Rogue expansion pack added extra weapons by allowing the player to cycle between various types and the extra ammo to collect was even more confusing. I wanted the new weapons of AD to be direct replacements with extra benefits and I believe the Shadow Axe, Triple Shotgun and Plasma gun do just that. There is a ton of stats available for each weapon in the readme file if anyone is curious to know how each weapon is better.

I am also in the middle of creating web friendly documentation which has a page for the new weapons with all stats in nice neat tables! 

I'm game. Sounds like fun. Every map I've ever made was intended for coop and I've always striven for that upgraded oldschool flavor that AD so perfectly nails down. Shoot me an email if you want to send me info such as coop only spawnflags to use and any particular requirements you may have.

Cool bbox info, had no clue. Also that makes sense for the weapons. 

So I can use these trigger_fog brushes, and inside of it will be specific fog I set up. If I put next to each other almost the same duplicates of the original, but I only change color a little bit.. or maybe changing it to totally different color like from blue to orange/yellow.

The trigger fog entity in AD works by blending (over time specified) from existing fog settings (should be defined on worldspawn) to what is specified in the fog entity. Plenty of the current AD maps have fog blending examples (especially mfx maps).

The current problem with fog blending is that the QC cannot find out from the client what the current values of the fog being used. This is why the worldspawn should specify fog_density and fog_colour so that the first triggered change has the starting fog values correct.

There is a test mode on the entity (trigger_fog) by setting fog_density to -1 and the QC will pick a random colour so you can see how the system copes with blends from extreme fog values. The system simple does a linear transition from one value (up/down) to the final value. The QC sets up a special entity to control the fog blends so that its independent from anything else running around the map.

You can setup fog triggers back to back, but it would probably produce weird results. The best solution is to allow the fog controller time (4 seconds is a good average) to blend gradually from one colour to the next. The fog changes should be gradual and subtle otherwise it will look and feel jarring to the player. 

Sock, I've been planning to implement this idea of having separate boxes for world and weapon collision. I don't program (yet, working on that) but I assume one could have multiple and varied hitboxes positioned differently around the entity? Nothing fancy, but perhaps one for the head and one for the body?

The other issue with bounding boxes is that they need to be square because they don't rotate (unlike the monsters). This sadly restricts what shape and size monsters can be.

This is really bothersome and has been high on my list of things to tackle. I assume rotating bboxes would best be done engine-side?

My goal: an arrangement of bboxes, no more complex than this, that can rotate in 45 degree increments. I suspect this is outside the realm of reasonable qc/csqc? 

This might be stupid question, since I believe Quake's code architecture hasn't been programmed to work this way but.. I was working in past coding, using C# and making event manager system - which is similar to observer design pattern.

Basically it means that game has events, which are possible to set to handled through specific program components.

My question is.. is it possible to listen for example when player shoots, if player stands inside of some specific trigger and do actions only if player shoots or does something specified? Just wondering, because enemy AI is quite stupid, and sometimes it seems it would be better to place carefully walls behind them so they don't try to walk upstairs, instead downstairs where player is.

I'm working on spiralstaircase and this happens constantly if there is not something to force them to stay at least there were they started. Is it possible to force enemies to make path decisions based on path flags/notes? 

I posted something very useful for you in the coding help thread.

I don't want to distract from your question, but your curiosity won't ever get satisfied enough by a question here and question there, and if you can code ... well --- check the "Coding Help Thread" for useful info I'm posting for you. 

If you can actually code, you are probably mostly better off learning how QuakeC works

HOW TO USE QUAKEC

0. QuakeC tutorials ---- MAJORLY useful
1. QuakeC source code
2. FTEQCC compiler - Compiles the QuakeC source

Extract the fteqcc executable to the folder with the QuakeC source code and double click it and it will compile up a progs.dat. That is what runs and is hiding inside quake/id1/pak0.pak. You need Pakscape to open pak files.

3. Pakscape Pak Editor Open/edit pakfiles.
4. QuakeC help forum (deadish) with useful reference threads
5. QuakeC specs
6. Links and References (very useful)

The QuakeC source code for progs 1.06 is standard Quake, it isn't Arcane Dimensions, but Arcane Dimensions, for example, is open source and if you were interested would be able to compile Arcane Dimensions following similar steps. 

Latest version is actually here:
http://triptohell.info/moodles/fteqcc/ 

Oh, thanks Baker. I just checked Coding Help page, and wondered what I even asked, it seems it was in different thread totally. I will look up those links, post saved* 

assume one could have multiple and varied hitboxes positioned differently around the entity? Nothing fancy, but perhaps one for the head and one for the body?

You could have multiple bounding boxes but sync between entities in quake is awkward at best. You should stick to one collision hull and calculate from the projectile impact location where this is in relation to the model/body. You could easily work out from the monster origin what part or direction the impact happened. I assume you are going to change the animations based on body damage?

I assume rotating bboxes would best be done engine-side?
This is certainly something you have to do engine side and it will make your mod extremely custom because you will rely on this feature. Not sure how difficult this is going to be to code but it will affect gameplay because monsters will have more precise bounding boxes and also be able to move through diagonal spaces easier.

Just wondering, because enemy AI is quite stupid, and sometimes it seems it would be better to place carefully walls behind them so they don't try to walk upstairs, instead downstairs where player is
The Quake AI just runs in straight lines at the player. if you want something more complex you need to create an AI navigation network. Have you checked out the In the Shadows mod yet? All the maps work with vanilla gameplay and the monsters will hunt you down where ever you go in the map. 

Adding holes or gaps in the floor effectively blocks monsters, even if small enough to walk over, because they use hull0 to find the floor. So try adding de orative floor grates or something wherever you need to keep monsters contained. 

Really wish there was enemy and player specific noclip brushes like in quake 2 

Really wish there was enemy and player specific noclip brushes like in quake 2 

Heh. ya. good luck. with that.

You may have wierd issues with the head getting stuck and the body continuing to move. I attempted domething similar once to implement crouch bit there is a wierd bug where the player can randomly get stuck for no reason...it's tantalizing but not reliable. 

I haven't checked lately but can't you fix the issue of monsters not crossing gaps by filling the gap with a clip-textured brush? Or is it only possible with a func_wall and alpha key? In any case, the solution only really works if it's acceptable for the brush to affect player movement as well, i.e having the gap be small enough that their bounding box wouldn't reasonably slip into it. The func_wall also has the negative effect of blocking any shots through it, unfortunately.

It's not perfect, but if you don't want monsters to run in a certain direction, I like to use a trigger_monsterjump with very low values to stop their movement. Of course, this has numerous downsides, but it can help with layouts that seem to make monsters run away from the player due to their design. Just make sure that the player can't get past the jump, or the monsters won't be able to follow! 

I see.

I assume you are going to change the animations based on body damage?

That and for requiring better accuracy on behalf of player and for aesthetics (no impact particles appearing in empty space around the model). Thanks for the insight! 

Might be able to cheat by calculating impact origin distance from the monster's origin and playing a specific pain-animation/damage based on whether the distance is past certain ranges. 

Yeah, sock mentioned this too. I was unaware this was a thing. I intend to go this route before trying to wrangle a bunch of hitboxes. Glad I asked! 

"I have double checked and this is the map name" I know, that's why you should make sure whether he made a typo or a wordplay.

"Most projectiles get faster based on skill level and the bolts scale as follows:
500=easy, 700=normal, 900=hard, 1100=nm" Yeah, I wasn't aware of that until I switched skill settings. I don't usually play nightmare unless a particular map is too easy on skill 2. It's much better on hard if still slightly slow, but it's good to know I can tweak it, though I haven't the slightest clue on how to edit the progs. And reverting to hitscan defeats the benefits of having projectile guns.

"I think Quake has too many weapons already" Uh, seriously? 8 weapons, of which 3 are basically beefed up versions or variations of other ones, effectively rounding that number to only 5 types of weapons, and you find that too much? Huh!...

"I wanted the new weapons of AD to be direct replacements with extra benefits and I believe the Shadow Axe, Triple Shotgun and Plasma gun do just that." That's true for the shadow axe and the widowmaker, but the plasma and lightning guns have radically different behaviors that call for different tactical uses. Sure we can bind that impulse-something (forgot the number) to a toggle key, but that's not nearly as convenient as having the possibility to cycle through them both using the mouse wheel. Please consider adding this as an optional feature - only for the plasma, not for the axe and WM. 

...that permanently replacing the LG with the PG leaves the player with zero hitscan guns.

(there should be an edit button to prevent this kind of double-posts) 

At this point AD is effectively turning into a total conversion (especially if you look at sock's new weapon interface), which I actually don't mind. 

Limiting to 8:
1 Axe-Upgrades to Shadow Axe
2 Shotgun-Upgrades to DBShotgun-then TBWidowmaker (I hear you, then theres no long-range weapon ...see #4. Also this makes the Sharpshooter powerup more desirable/useful)
3 Nailgun-Upgrades to Perforator (really who goes back to the nailgun except by mistake)
4 ITS Crossbow Please! With Nightmare-speed bolts and damage of 130. Crossbow knights could drop a couple bolts, bolt quiver ammo should be somewhat scarce. Poison could be used sparingly too.
5 Grenade Launcher
6 Rocket Launcher
7 Lightning Gun (but can we please increase the range)
8 Plasma Gun

There, no same number swapping like the mission packs had.

There's even room for
9

But 9 would be too much. This isn't half-life right sock?

Hmm, in all seriousness though I don't see why the supernailgun couldn't be an upgrade of the nailgun. 

note, quake only supports 4 ammo types on the HUD. (yeah there are weird hacks for Rogue mission pack but they are weird.) 

8 weapons, of which 3 are basically beefed up versions or variations of other ones, effectively rounding that number to only 5 types of weapons, and you find that too much?

Two nailguns are really the only pair that feels redundant. GL and RL are about as different as you can go with the same kind of impact effect, and even the shotguns have their unique applications.

Also, I'm all for small yet practical arsenals.

...that permanently replacing the LG with the PG leaves the player with zero hitscan guns.
Technically, it's not a hitscan weapon.