SamsaraHold Resurrection + Enhancer

[Untitled]

Just FYI STR21 is Overmind; your edits appear to be for STR20 (Snake Corridors).

[bruiserdaemon]

Ah yeah, obviously Overmind missions i left them like that, no need to improve.

Just a question, why duke's rpg rockets are so weak against certain monsters? It takes forever to kill an archon of hell or a cyberdemon. Seems like they are immune to that attack...?

[Untitled]

It's not difficulty that generally gets me the most complaints unless I've thrown something blatantly unfair (such as terminators, ever), but it's more things like "argh how the hell do you avoid getting hit by the hitscanners" or "wtf why did you send no powerups in a wave with things that do 100+ damage in a single shot".

Anyways, nice work - from your earlier behavior I thought you'd be a bit overzealous but actually you've been pretty good with the map-balance; though again this all has to be online tested before I make any real claims.

[bruiserdaemon]

Where is the monster count based on difficulty? Where do i edit it? ( i want for example more monsters on UV ).

[Untitled]

Ah yeah, obviously Overmind missions i left them like that, no need to improve.

Just a question, why duke's rpg rockets are so weak against certain monsters? It takes forever to kill an archon of hell or a cyberdemon. Seems like they are immune to that attack...?

That's odd - they should be stronger (20ish rockets should down a cyberdemon, 10ish should down an archon). I'll look into this, on my current build.

EDIT: Figured it out. In Single Player, due to a bug (and me never looking at single player samsarahold, because lazy), the rockets don't actually have +FORCERADIUSDMG, which is where Duke's rockets get their strength. This has been fixed - 11 rockets for an Archon of Hell, as it should be.

Where is the monster count based on difficulty? Where do i edit it? ( i want for example more monsters on UV ).

It's located in the strnghld.acs (in the samsarahold code file, in acs_src).

Yes, you WILL need to compile it. The compiling should give you "strnghld.o", after compiling, throw this into the "acs" folder (NOT acs_src OR acs_inc).

Array is SkillScaler; currently the skillScaler is this:
int SkillScaler[5] = { 0.75, 0.75, 1.0, 1.5, 2.0 };

UV is 1.5.

Increasing these isn't recommended; if only because increasing the monster count in multiplayer won't increase the difficulty so much as increase the length; and as I said, single waves shouldn't last over 5 minutes, and single missions shouldn't last over 30 minutes, until you get 6-8 players or you get to Tier 6.

Also given you just increased the monster count on the majority of the missions you've edited :V

EDIT: This is the full scalar:

Code: Select all

// This function applies the multiplier for the given type to amount, and returns the result.
// It handles fixed point conversion and making sure the result is rounded nicely.
// Also, if given a negative amount, it will return it positive and unmultiplied
function int Multiplier (int type, int amount)
{
	if(amount < 0)
	{	return 0 - amount;	}

	int result = amount * RawMultiplier(type);

	if( (result>0.0) && (result<1.0) )	// Make sure our answer is at least one
	{	result = 1;	}
	else
	{	result = result / 1.0;	}	// Make result an integer

	return result;
}

int SkillScaler[5] =	{ 0.75, 0.75, 1.0, 1.5, 2.0 };

// This function returns the multiplier as a fixed point value.
// If the multiplier needs to be tweaked, this is the function to do it in.
function int RawMultiplier (int type)
{
	int result = 1.0;
	switch(type)
	{
	case M_POWERUP:
		If(TimeAttackMode)
		result = 1.5*PlayerCount();
		else
		result = 1.0*PlayerCount();
		break;
	case M_MEDIC:
	case M_AMMO:
		If(TimeAttackMode)
		result = 1.46*PlayerCount() + 0.05  ;	// Slightly above 1.5 for one player to account for rounding errors
		else
		result = 1.05*PlayerCount() - 0.04  ;	// Slightly above 1.0 for one player to account for rounding errors
		break;
	case M_ENEMIES:
		If(TimeAttackMode)
		result = FixedMul(1.55*PlayerCount(), SkillScaler[GameSkill()] - 0.04);
		else
		result = FixedMul(0.05 + 0.96*PlayerCount(), SkillScaler[GameSkill()]);
		break;
	case M_BOSSHEALTH: //Not being used anymore, because THANKS ZANDRONUM
		// 1 player	= 1x
		// 8 players	= 3x
		// result = 2/7 * playercount + 5/7
		// result = (2*playercount + 5) / 7
		result = ( 2.0*PlayerCount() + 5.0 ) / 7; // Dividing fixed by int yields a fixed
		break;
	default:
		PrintBold(s:"Error: Function Multiplier() called without a valid type argument");
	}
	return result;
}

TimeAttackMode is just my way of saying "Hard Mode", I was too lazy to change the variable name.

If you're wondering about the M_BOSSHEALTH scale, well that's because using it with any player count than 2 or more would crash the overmind script for no reason whatsoever.

Overmind's current mechanics exist for a reason, and that reason isn't pretty - I literally can't scale it's health anymore, because apparently it takes offense and would rather die than have it's health scaled.

[bruiserdaemon]

It doesn't give me strnghld.o after compiling, how can i do?

[Untitled]

It doesn't give me strnghld.o after compiling, how can i do?

Hmm.

http://zdoom.org/wiki/ACC try this.

As I said, I'm not touching the SkillScaler because it could potentially make 6 player UV unplayable which I'd like to avoid (though looking at the numbers stepping down to HMP might now be a conceivable option).

Also, new thing for release candidate coming up - UV is a bit harder than it used to be.

[bruiserdaemon]

There is a fastidious bug in this mods, and that is when some monsters fail to spawn. I noted this particularly on STR07: the cybruisers added on hard mode fail to spawn, or spawn only sometimes ( and fewer in number than expected ). I noted that this has something to do with the congestion happening when a lot of monsters have to spawn in small spawn zones, or do not have enough space to move quickly from the spawn zones. Is there a way to counter this?

[Untitled]

There is a fastidious bug in this mods, and that is when some monsters fail to spawn. I noted this particularly on STR07: the cybruisers added on hard mode fail to spawn, or spawn only sometimes ( and fewer in number than expected ). I noted that this has something to do with the congestion happening when a lot of monsters have to spawn in small spawn zones, or do not have enough space to move quickly from the spawn zones. Is there a way to counter this?

Yeah; that's a side effect of the way I coded it; basically the zandronum engine is really bad at telling whether or not space exists for the monster, and activates the spawning, which is done through A_SpawnItemEx.

The way I coded it, if it doesn't have enough space, it simply fails to spawn - I'm trying to figure out a way to counter this, but I don't have much of a lead, aside from forcing a spawn, which would make it get stuck inside another monster - which would be all sorts of bad.

It was to counteract the old method, where due to a flaw in the coding of stronghold, it would spawn the entire hard wave at once rather than distributed as part of the wave - meaning you'd get this ONE section which was impossibly difficult followed by an easy wave in comparison.

That was proving to not be fun for anyone; so I got desperate and switched to the current method, which introduces an alternative bug - but only people who literally have the maps open (i.e. me) will know that the bug exists, so people don't usually complain.

[bruiserdaemon]

Just noted that from time to time a wave brakes. Instead of spawning the usual amount of monsters, only a small number of them spawn, and after killing them, there's no wave complete message. Seems like it happens only on the later waves, never in the early ones. What happens?

[Untitled]

Just noted that from time to time a wave brakes. Instead of spawning the usual amount of monsters, only a small number of them spawn, and after killing them, there's no wave complete message. Seems like it happens only on the later waves, never in the early ones. What happens?

If it's always breaking at very very specific waves, always at a certain time, that means that essentially I goofed and tried to spawn something that doesn't exist; the script breaks, the wave is stopped from spawning any further.

Otherwise, weird. I'll look into this.

---

Alright, got an announcement to make.

As much as I hate to admit, real life is happening this week and I won't be able to release until Friday.

I will release 0.12 Friday, and that will hopefully be the final release - see you next summer, when I start on 0.15, which will probably be a crazy one - 0.12, as much as I hate to admit it, is less about features and more about just polishing this codebase so it doesn't seem like I'm running in circles trying to make it not annihilate poor unsuspecting Zandronum clients.

Hopefully I have a successful release on Friday, so have fun when it happens.

And then see you next summer - 0.15 is gonna get all sorts of crazy.

[HexaDoken]

basically the zandronum engine is really bad at telling whether or not space exists for the monster

No, it's not. You fail at modding.

What I'd do(do note that I have no idea how exactly things work as of now - i'm just suggesting what have worked for me in the past) is to spawn a projectile. An invisible, immobile, damage 0 projectile, that has the same dismensions as the monsters it's attempting to spawn. It wouldn't spawn it immediately - instead, it'd wait for a tic or two. If the projectile is still alive after that tic or two, there is definitely enough room for a monster. Projectiles are pretty damn good at collision detection, ya see. So, if there's room, spawn a monster and substract the wave count. If not, well, damn.

There are only two notable issues here. First, this needs quite a chunk of code(you need a separate projectile for every single damn monster out there - ahahahahahahaha)

Second is to make it work with the whole Stronghold wave system. If I recall how things work in there, Stronghold uses a massive array that stores every single monster in it for the current wave. It shouldn't be too impossible to write a function that finds the monster needed in that array and substracts 1 from it's count.

...

Or you could just use Spawn ACS function and alleviate most of that. It does your collision detection for you and returns true/false depending on if the monster actually succeeded to spawn. If I recall correctly though, this is how Stronghold used to do things to begin with, and you say you have problems with that. Personally, I've got no idea how it could be the culprit of those, but if you give me more details I might be able to suggest a solution or two.

[bruiserdaemon]

Nope, looks like broken waves are just broken, no matter if i change the wave composition and recompile it. This time i think it's the modder's fault, there's some missing script somewhere which brakes the same wave everytime.

Broken waves are:

-STR18 wave 7
-STR17 wave 6
-STR19 wave 7

Also, STR16 wave 6 crashes the game for no reason ( not everytime though, i was able to win it without crashing once ).

[Untitled]

basically the zandronum engine is really bad at telling whether or not space exists for the monster

No, it's not. You fail at modding.

Yep, I do fail at modding - consider that beta 1 released with not one but 2 broken maps. Honestly, being bad is the only reason samsarahold exists; if I was better, I would know how over-my-head I was and probably would've given up - my naviete is why samsarahold got as far as it did, hilariously enough.

Though, I have to admit I don't know what I was saying there - Zandronum is actually acting exactly as I tell it to - The issue isn't figuring out whether or not I have room (I don't) but figuring out how to make room. Hmm.

What I'd do(do note that I have no idea how exactly things work as of now - i'm just suggesting what have worked for me in the past) is to spawn a projectile. An invisible, immobile, damage 0 projectile, that has the same dismensions as the monsters it's attempting to spawn. It wouldn't spawn it immediately - instead, it'd wait for a tic or two. If the projectile is still alive after that tic or two, there is definitely enough room for a monster. Projectiles are pretty damn good at collision detection, ya see. So, if there's room, spawn a monster and substract the wave count. If not, well, damn.

There are only two notable issues here. First, this needs quite a chunk of code(you need a separate projectile for every single damn monster out there - ahahahahahahaha)

That's sort of how it works, actually - basically there's a version for most monsters called "HardMode[Insert Name Here]", which is simply a dummy actor that performs a check for playercount, if it returns positive, it spawns the respective monster.

The problem is spawn point congestion is pretty common - about 50% of the time this thing will spawn, the check returns positive, but has no room of which to do the spawning - of which case, A_SpawnItemEx spawns nothing.

Again, the plus side is that it's not a noticeable problem unless you're developing the maps, so people have been quiet with it.

Second is to make it work with the whole Stronghold wave system. If I recall how things work in there, Stronghold uses a massive array that stores every single monster in it for the current wave. It shouldn't be too impossible to write a function that finds the monster needed in that array and substracts 1 from it's count.

...

Don't need to do that at all - just spawn the HardMode checker thingamajig through the map spawners directly - as long as it dies, it won't freeze waves.

Or you could just use Spawn ACS function and alleviate most of that. It does your collision detection for you and returns true/false depending on if the monster actually succeeded to spawn. If I recall correctly though, this is how Stronghold used to do things to begin with, and you say you have problems with that. Personally, I've got no idea how it could be the culprit of those, but if you give me more details I might be able to suggest a solution or two.

Yeah, the biggest issue isn't that I can't tell (so more like I fail at describing), it's figuring out how to get behaviors out of the way when things *don't* have the room to physically get stuffed in there.

Tricky problem, because if I force a spawn, it might get stuck on top of another monster, and if I make it wait until there's room, it might get a build-up of hard-mode monsters at the end of the wave, resulting in like lol all of the archons of hell at once.

Hmm.

Nope, looks like broken waves are just broken, no matter if i change the wave composition and recompile it. This time i think it's the modder's fault, there's some missing script somewhere which brakes the same wave everytime.

Broken waves are:

-STR18 wave 7
-STR17 wave 6
-STR19 wave 7

Also, STR16 wave 6 crashes the game for no reason ( not everytime though, i was able to win it without crashing once ).

Figured it out, if you're using your modified maps.
"HardModeGuardian", "HardModePhaseImp", and "HardModeHS" do not actually exist - there's no Hard Mode spawner - basically what happens is it tries to spawn the checker that doesn't exist. Because the thing doesn't exist, the script locks up and freezes.

Remove the lines with the offending monsters, then recompile the map scripts, and it should work.

Enter "Puke 930 1" into your console to go to the next wave.

And if that's not enough, well it works on my end so at least that's working - I have something that works.

HardMode Spawners are available for:
-Pinky demons and variants
-Not-small Flyers (Cacos, Elementals)
-Revenants, Wickeds and Zombie Tanks
-All of the Hell Nobles (including satyrs and azazels)
-Fatsos, Hectebi, Arachnotrons, Fusion Spiders
-Cybers, Spidermasterminds, Spider Demolishers, Terminators
-As of the final release but not in your version, Archviles and Diabloists

[HexaDoken]

The problem is spawn point congestion is pretty common - about 50% of the time this thing will spawn, the check returns positive, but has no room of which to do the spawning - of which case, A_SpawnItemEx spawns nothing.

Either you haven't read what I said carefully or I can't really understand you.

Make the spawner a projectile with exact same dimensions as the monster it's attempting to spawn. Make it so that it exists invisibly for a tic or maybe two before actually attempting to spawn anything. Make it so that it signals that "monster has been spawned successfully" after that wait is over. Make it have a blank Death state. In this case, if the spawner gets to the point where it executes the A_SpawnItemEx at all, you know there is definitely room for the monster - otherwise, the projectile would have already detected collision with something, and jumped to Death state, in which it would have dispersed into the wind.

The only trick here is to make it able to actually do that "monster spawn success" signal AFTER it has been spawned - depending on how exactly stronghold works, this might require a bit of coding.

Tricky problem, because if I force a spawn, it might get stuck on top of another monster, and if I make it wait until there's room, it might get a build-up of hard-mode monsters at the end of the wave, resulting in like lol all of the archons of hell at once.

Let the Random Number God sort em all out?

Randomly iterate through available monsters and try to spawn them, removing them from the list on success, and keeping trying until there is nothing left? This way, per statistical probability, you SHOULD get a more or less even spread of difficult and easy monsters throughout the wave.

Of course, RNG will tell your statistical probability to sod off and just spawn all them archons at the least inopportune moment no matter how you build it, but at this point you just chalk it up to bad luck and walk away.

[Untitled]

The problem is spawn point congestion is pretty common - about 50% of the time this thing will spawn, the check returns positive, but has no room of which to do the spawning - of which case, A_SpawnItemEx spawns nothing.

Either you haven't read what I said carefully or I can't really understand you.

Make the spawner a projectile with exact same dimensions as the monster it's attempting to spawn. Make it so that it exists invisibly for a tic or maybe two before actually attempting to spawn anything. Make it so that it signals that "monster has been spawned successfully" after that wait is over. Make it have a blank Death state. In this case, if the spawner gets to the point where it executes the A_SpawnItemEx at all, you know there is definitely room for the monster - otherwise, the projectile would have already detected collision with something, and jumped to Death state, in which it would have dispersed into the wind.

The only trick here is to make it able to actually do that "monster spawn success" signal AFTER it has been spawned - depending on how exactly stronghold works, this might require a bit of coding.

Tricky problem, because if I force a spawn, it might get stuck on top of another monster, and if I make it wait until there's room, it might get a build-up of hard-mode monsters at the end of the wave, resulting in like lol all of the archons of hell at once.

Let the Random Number God sort em all out?

Randomly iterate through available monsters and try to spawn them, removing them from the list on success, and keeping trying until there is nothing left? This way, per statistical probability, you SHOULD get a more or less even spread of difficult and easy monsters throughout the wave.

Of course, RNG will tell your statistical probability to sod off and just spawn all them archons at the least inopportune moment no matter how you build it, but at this point you just chalk it up to bad luck and walk away.

Ok, then the projectile dies and disperses into the wind - and herein lies the problem.

Basically, The map loads the checkers in, spawns them, and then removes them from the cache.

The issue is, as soon as it's been spawned, it's removed from the cache.

So if the spawner dies and disperses into the wind, that's it - the checker has removed itself; nothing is spawned. But because the checker that's doing the spawning itself has been spawned already, it's too late - the ACS removes it from the monster cache, and there can be no second attempt for it - again, the entry is removed the very tic it spawns something, regardless of whether the thing it's spawning is a monster or a checker thingamajig that only has a chance of doing so.

EDIT: Yeah, RNG can be a pain (nothing like dying to 2 revenant missles at essentially 150 HP).

[HexaDoken]

Well uh. Make it so that a checker is not removed immediately from the list after it has been spawned, or make it able to re-add itself back in?

That's mostly what I meant by "might require a bit of coding".

[Untitled]

Well uh. Make it so that a checker is not removed immediately from the list after it has been spawned, or make it able to re-add itself back in?

That's mostly what I meant by "might require a bit of coding".

Ugh. This is somewhat what I feared; I've never messed with any of the actual monster cache stuff, and with real life being a thing now I actually don't have the time to deal with this stuff.

As much as I hate to admit it, this isn't going to be fixed for probably a couple months, where I have the time to go "Ok, time to fix this" and try to fix it and then try to debug it.

I want to lay SamsaraHold to rest for some amount of time - I don't like sporadically updating things here and there, slowly progressing towards some goal at various times here and there - I want to have a length of time to put this into focus, before trying to fix everything.

That's why I'm planning to release 0.12 this Friday; regardless of whether or not I've fixed everything (of which I won't; I don't think I can); I don't want to keep working on this thing when I'm occupied with other life-related things - so I want to put this to the back-burner after the release, and worry about 0.15 next summer, when I have the time to worry about it.

As I said, expect 0.15 next summer - lots of things will be going down that version.

Still, thanks for the comments - they're helpful in figuring out the nature of this problem.

[bruiserdaemon]

I managed to somewhat regolate congestion by using a smart trick: demons and spectres tend to occupy a large space ( about 30 radius, a hell noble being 24 ) and so they are just too large in comparison to their weak power. I just made them smaller, now 20 radius and scale to 0.85. Not mentioning the spiderminds getingt regularly stuck because of their own great size, so by scaling them by a 15% now they move much better through the map ( and are more dangerous ). It is strange that the modder after so many releases didn't figure out that spiderminds get stuck, now they move well thanks to a little trick.

[Untitled]

I managed to somewhat regolate congestion by using a smart trick: demons and spectres tend to occupy a large space ( about 30 radius, a hell noble being 24 ) and so they are just too large in comparison to their weak power. I just made them smaller, now 20 radius and scale to 0.85. Not mentioning the spiderminds getingt regularly stuck because of their own great size, so by scaling them by a 15% now they move much better through the map ( and are more dangerous ). It is strange that the modder after so many releases didn't figure out that spiderminds get stuck, now they move well thanks to a little trick.

Masterminds were reduced from Radius 128 to Radius 96 because of that very reason - and actually, they didn't usually get stuck due to never appearing in maps where that was a possibility.

Masterminds don't usually get stuck on map geometry; usually they get stuck on other demons, I've found.