Is this intented to be this way. If I place respawning megahealth somewhere, it doesn't start counting to becomes pickable again, until player's hp is 100? In my scenario I wanted to keep player's health higher than 200 and also if it start counting these numbers just after HP is back to 100, it might change the way I designed one fight to be, player eventually takes some damage, and I wanted to balance that situation by giving megahealth just enough to keep HIM alive and not to die on couple mistakes right away. 

Can you give more details?

When you pick up a megahealth, you receive an inventory item that will gradually "rot" you health back to 100. Then it is removed.

When you pick up a second megahealth while the first one is still active (health > 100), you receive a second inventory item that will also "rot" you health back to 100. The result it that your health will degrade twice as fast. The more megahealth packs you collect, the faster your health will degrade, all the way back to 100.

The fix is somewhat complicated by the behavior Newhouse mentioned - megahealth is supposed to respawn when its "last user" drops to 100, so all the inventory items need to be in check. 

Thank you for implementing the melee only Golem.

I almost have the "storyboard" level(area) finished that will use this for the start of the episode.

Also I highly recommend you move away from AD directory

Will do.

Again thanks... for everything. 

mh respawn times is considered a feature in quakeworld - every now and then he pops up and gives d3d advice.. err.. wait... *cough*.
but yeah, players having control over when the mh respawns so they can try and time it to respawn at the same time as other items on areowalk is a thing.

but yeah, vanilla mh logic:
ongrab = {
other.health += 100;
while (other.health > 100) {
other.health -= 1;
sleep(1);
}
sleep(20);
regeneratenow();
};
so the respawn time depends upon how long the player can keep their health above 100. and if you get 3 or 4 megahealths then it starts to rot away really really quickly.

on the other hand, if you're designing a fight where the player is sure to be taking sustained damage then its imho more interesting if the player has to wait for his health to drop below a certain threshold before he/she grabs the next mh in order to avoid dying due to having no health while there's no mh powerups thanks to them all being on cooldown ater rotting away really fast.
but yes, the (vanilla) mechanics do seem a little buggy. 

And also a great idea to split the devkit assets into different tiers.

I was dreading having to stomach a bunch of "unofficial community patches" of the main AD mod, but this will neatly avoid that. 

More details:

Player is on top of mountain, wizards shoots fire balls at him, and player needs to dodge a lot while trying to kill them all. But since I know not every player is as skilled, some people take more damage than the others. That is why I thought it would be a great idea to place there respawning mh, but wasn't sure how it actually works.

Now thinking about it, this is actually a lot more interesting that you have to wait so your hp goes back to 100, after that mh (starts counting) respawns after some time. So those seconds will be extra intense. 

To be honest I'm not sure I understand the purpose of "everyone [moving] away from AD" to the devkit. For a level that just uses AD entities without adding anything new, working from the AD directory seems ideal for both player and mapper because, like Quoth, you're just dealing with one mod directory. If I'm understanding this right, it seems like you're saying it's better for mappers who want to use AD content to pick what they want, and repackage it in their own mod directory for their map? Honestly this seems like an unnecessary hassle and a bit of a waste, if we're going to end up with the same assets spread over many different folders.

As for "community patches," you say yourself you plan to keep the devkit updated, so I'm pretty confused there. Couldn't the same stuff be included in official patches for AD itself?

Maybe I'm dense so help me out here! 

If I'm understanding this right, it seems like you're saying it's better for mappers who want to use AD content to pick what they want, and repackage it in their own mod directory for their map?
It's not how I read it. I think it was more addressed to people like OTP who released an unofficial patch for AD. That said, I understand Sock's motivation (not allowing a mess of forks) but AD still needs a few things patched. 

don't we need the AD WADs? There are no WADs included in the kit

The WAD files are textures only, these are something you have to sort out yourself because it depends on what texture theme you want.

I recommend you download the wads from Quaddicted. There is even a preview images for most of the texture sets. If you want textures from the AD maps, then you will need to use TexMex to extract them yourself and save them as new wad files.

And maybe I'm just spoiled by Source engine FGD's, but when I use the AD patch 2 FGD in JACK, most of the entities are represented by colored bounding boxes instead of a model or icon. Is this just how it is for Quake mapping?

You need to setup JACK to point to your mod directory where you are developing your stuff. All the paths in the FGD point to the progs directory which must exist under your mod directory. 

If I place respawning megahealth somewhere, it doesn't start counting to becomes pickable again, until player's hp is 100? In my scenario I wanted to keep player's health higher than 200 and also if it start counting these numbers just after HP is back to 100

That is how the MH works, the MH entity is the thing that counts down, it cannot respawn because its busy counting down the player health. If you have multiple MH then you have multiple entities taking the player HP down! If you want to give the player health use the trigger_heal entity. You can reset if you want more health. 

When you pick up a second megahealth while the first one is still active (health > 100), you receive a second inventory item that will also "rot" you health back to 100. The result it that your health will degrade twice as fast. The more megahealth packs you collect, the faster your health will degrade, all the way back to 100.

It sounds like you want the megasphere from Doom and that is fine, but then you should design a new item, not change the existing one.

I know some mappers do the multiple MH thing in a row, but not many. I don't want to make the MH overly complex, I like the id design, is fine for 99% of mappers. There is also the trigger_heal if mappers want to keep players topped up during combats and there is also re-spawn on all standard health packs. 

Thank you for implementing the melee only Golem. I almost have the "storyboard" level(area) finished that will use this for the start of the episode.
Email me if you have other requests, it will be quicker than waiting for replies on forums. 

To be honest I'm not sure I understand the purpose of "everyone [moving] away from AD" to the devkit. For a level that just uses AD entities without adding anything new, working from the AD directory seems ideal for both player and mapper because, like Quoth, you're just dealing with one mod directory

If you are just creating a map and not wanting to change anything about AD then indeed it is fine, just release your map as a dependent of AD. The devkit is aimed at people who want to change the mod for their projects and feel the need to patch AD for the community!

I am trying to avoid community patches, lack of testing and broken setups because everyone is going in opposite directions. The AD team did a crazy amount of testing of all maps and I don't want to see their hard work broken by unofficial patches.

As for "community patches," you say yourself you plan to keep the devkit updated, so I'm pretty confused there. Couldn't the same stuff be included in official patches for AD itself?

Unless there is a critical bug then AD should be left alone. I am patching the devkit for people who want extra features or minor fixes. Ultimately mappers should be taking this opportunity to get into modding themselves. Just like Rubicon2 and RRP, make your own vision! 

Megasphere doesn't rot, among other differences. So I'm not sure why this particular comparison.

Regardless - this is your creation, all I can do is suggest. 

I understand Sock's motivation (not allowing a mess of forks)
People can fork or create their own mods using AD as a base as much as they like. I have no issues with that, as I said I just want the original AD mod to be left alone. Either make maps for it or create your own mod, its all setup ready to go with the devkit.

AD still needs a few things patched
like what critical stuff are you talking about? 

Thanks for the clarification, sock! I am indeed dense hehe. 

Nothing critical, just stuff like the statue gibs being bloody, for example. It would have also been nice to make some parameters user-controlled. I'm notably thinking about some particle effects like the grenade explosions that prevent the player from seeing the action or the footstep volume that you reduced slightly too much IMHO. 

The statues are squishy on the inside deliberately. 

Think of them like Pyura Chilensis (google it, but trigger warning: gross), which is a million times Quakier than some Harry Potter-esque magical rock monster 

Would it be cool for longer maps to have a trigger_sky entity, similar to trigger_fog, that could dynamically change the skybox during the level?

Kind of give a sense of day and night time passing. Could be neat if implemented correctly? 

Maybe?

I think it could be done but not sure if different engines use different commands to change skies 

I think it could be done but not sure if different engines use different commands to change skies

quakespasm uses 'sky foo' as a console command that persists only for that map, fte+ezquake+fuhquake+etc uses r_skybox as a cvar, dp has a loadsky command, markv has a cl_sky cvar (which only works on level changes), while the fitzquake protocol has a svc_skybox thing that will crash any clients that don't support it.

so yeah, good luck with that. :P 

lmao 

I suppose you could stuffcmd all of those commands to cover all engines and then follow with the "clear" command so the player doesn't see all the "unknown command" messages. Ugly as all hell, but we ain't going to get a standard on this across engines. 

And then the engine takes a shit on player immersion by hanging for several seconds when loading the heavy TGA files.