Late game bug/RNG fixing

[Alhanalem]

I really didn't expect that the things that result in the rollover would be in uScript. If it turns out you can address it without breaking anything (famous last words) that will be impressive to say the least.

(Finding it nigh impossible to do anything without EV/summoner is quite the change from pre-copters).

Nightmare is designed to require the use of the whole range of tools at your disposal. That's why it wasn't considered "done" til the whole shards pack was released. In some ways it is kind of lame that you need those tools in particular (However, Jester can potentially ease that a bit by freeing up DU if you can get the presents to cooperate), at the same time if they didn't feel powerful or bring anything really wanted to the table, very few people would get them, so from that perspective I can see why they were made so valuable.

[CrzyRndm]

I really didn't expect that the things that result in the rollover would be in uScript. If it turns out you can address it without breaking anything (famous last words) that will be impressive to say the least.

Weapon rollovers are completely fixed. Some minor code rearrangement and adding max/min range to the stat generation was all. It's so simple that I almost doubt it can be buggy (almost...). It works as far as I can tell in some short tests.
- I didn't change the storage type if that's what you were thinking. That would have been a little more difficult

Just need to identify the correct variables for upgrades to seperate and i should have that working too (pretty much the same operation, just different names). However, I see no way to reliably test this, b/c:

A) It isn't as blindingly obvious as the weapon specific rolls when it happens as it gets rolled before ever being shown to the player instead of on pickup.
B) None of the maps added after misty are included in TC's at the moment (I'm guessing b/c it's extremely easy to bypass the money requirement). Boss Rush would be kinda useful for testing how effective these changes are...

EDIT

Upgrades should no longer roll (just run up now to check for breakages )
And it's broke...

[Alhanalem]

And it's broke...

I guess I jinxed it

[CrzyRndm]

Found the problem lol. Bad variable call... Guess I have to do it the messy way for now

EDIT

derp, more like bad variable placement... (<insert face-palm smiley>)

- Added overlord zoom increase
- Confirmed stopping upgrade rollover code works (randomiztion is unchanged). Rollovers no longer exist

[grey-1]

CrzyRndm -

DUDE (sorry for the shout...) :-P

I downloaded the DDDK weekend before the last with basically the intent to make a TC called fix_vanilla. Where I would make code fixes but not change anything else like balancing of mobs.

With that I sent an email to Dingle asking his permission to include his code suggestions that he has posted with the proviso that he would be given full credit. He agreed. The first thing I was going to fix was the roll over, because Dingle suggested a fclamp method back in April that also would work. I was next going to incorporate his go negative fix suggestion (though not a bug fix per se). Then tackle the resists bug. And a couple of other bugs that I don't recall offhand. Dingle did suggest making some sort of fun TC addition just to generate interest.

Anyway I was hoping this would make a base TC that others could use as a starting point. But I was also hoping that with enough play time in the TC by other players to make sure the fix_vanilla didn't break something else that it would be something that Trendy could possibly use as a patch for the ranked version. I know wishful thinking, but hey it would be constructive instead of just a rant (though that rant did reveal the code issue).

So while I had some install issues and some problems starting the DDDK, plus now that I'm in it I have a bit of learning to do - it would appear you beat me to the punch. Cool. (oh and I had an aborted Talay run as you are well aware).

In fact last time I coded anything seriously there was really only a text editor needed. That is progress for you.

So I would suggest having 2 TCs. One for fixes and one for balancing/extras.

And I would like to volunteer to be a tester for you since I believe firmly in what you are doing. Or let me know if I can help in any way.

BTW; my fun ideas for a TC were gear crafting and... wait for it... tower setup save/recall for survival.

tl;dr: sweet and can I help?

[CrzyRndm]

CrzyRndm -
DUDE (sorry for the shout...) :-P

I downloaded the DDDK weekend before the last with basically the intent to make a TC called fix_vanilla

I think it was your post that gave me the idea in the first place Plus I really needed the coding practice

sweet and can I help?

No problem. Need more of those bugs/semi-bugs at the moment

EDIT

Added
- Change colour of fire projectiles/animation so it isn't blinding white.
- Remove blindingly white ball from center of auras
- Make MMT projectile more blue than white
>>>Unsure how/if possible, but would make things a little easier on the eyes with less white around

- Chumm's suggestion on spider "no target" pathing AI

[Dingle]

grey-1's in, so I guess we're sort-of merging our projects here. I'll add some pointers for some things you're wanting to do.

Intended Changes

- Removal of low stat (all stats < ~30) items from NM loot generation at some arbitary point in wave/quality/<possibly just NM>.
- Tavern Shop rebuffed. Myth armour should atleast be normal after a NM game. - Shop quality values found. Some experimentation needed

For both of these, you need to look in the DunDefHeroManager.uc class; the function GetCurrentMissionEquipmentRandomizerMultiplier controls the most important value of both.

This section controls the chance of a low multiplier being used for floor loot:

	if(FRand() < DunDefMapInfo(class'WorldInfo'.static.GetWorldInfo().GetMapInfo()).EquipmentRandomizerMultiplierPercentageToUse)
		return ddGRI.DifficultyEquipmentRandomizerAbsoluteMultiplier[ddGRI.CurrentGameDifficulty]*(0.9 + 0.1*Flerp(FMin(waveNumber/scalingWave,1),1,ddGRI.DifficultyEquipmentRandomizerNegativeWaveWeighting[ddGRI.CurrentGameDifficulty]));

This section controls the chance of a low multiplier being used for shop loot (yes, it's repeated twice):

	if(bIsForShop && FRand() < DunDefMapInfo(class'WorldInfo'.static.GetWorldInfo().GetMapInfo()).EquipmentRandomizerMultiplierPercentageToUse)
		val*=0.5;

	if(bIsForShop && FRand() < DunDefMapInfo(class'WorldInfo'.static.GetWorldInfo().GetMapInfo()).EquipmentRandomizerMultiplierPercentageToUse)
		val*=0.5;

Removing those sections entirely would mean the full multiplier is always used in those cases. The other option is rebalancing the formulae or variables used.

Possible Changes

- Reward weapon size biased favourably (squire/monk = larger, hunt/app = smaller). This depends entirely on the effects of the GoNegative function. B/c rewards have a much higher than normal quality it's possible that this will be unnecessary.

Size is generated in the AddRandomizeValues function of HeroEquipment.uc, at the following code:

	curRandomValue = GenerateRandomizerValue(equipmentQuality,WeaponDrawScaleMultiplierRandomizer);
	WeaponDrawScaleMultiplier = FMax((WeaponDrawScaleMultiplier + WeaponDrawScaleMultiplierRandomizer.MaxRandomValue * WeaponDrawScaleRandomizerExtraMultiplier * curRandomValue) * WeaponDrawScaleGlobalMultiplier,MinWeaponScale);

I'd suggest something like this to change it:

	if((EquipmentType == EQT_WEAPON && (WeaponType == EWT_WEAPON_INITIATE || WeaponType == EWT_WEAPON_APPRENTICE)
		equipmentQuality = 2.0 - equipmentQuality;
	curRandomValue = GenerateRandomizerValue(equipmentQuality,WeaponDrawScaleMultiplierRandomizer);
	WeaponDrawScaleMultiplier = FMax((WeaponDrawScaleMultiplier + WeaponDrawScaleMultiplierRandomizer.MaxRandomValue * WeaponDrawScaleRandomizerExtraMultiplier * curRandomValue) * WeaponDrawScaleGlobalMultiplier,MinWeaponScale);
	if((EquipmentType == EQT_WEAPON && (WeaponType == EWT_WEAPON_INITIATE || WeaponType == EWT_WEAPON_APPRENTICE)
		equipmentQuality = 2.0 - equipmentQuality;

What's going on there is this: the weapon size is weighted purely on equipment quality. If the weapon type is EWT_WEAPON_INITIATE (Huntress. Don't ask.) or EWT_WEAPON_APPRENTICE, it flips the quality from one side of 1.0 to the other, so higher qualities get reduced and lower qualities get increased. This means that higher initial qualities create smaller weapons, and lower initial qualities create larger weapons.

The code handling the flip is done twice because the quality is used further down the line, though only in a few rare cases. Better to have the original quality there.

- Doing something about the armour/weapon ratio.

This might be harder; armor already pretty much has the lowest rarity value in the scale, so it's technically the most common loot type. The perceived rarity is more due to 1) weapons have higher qualities on average, pushing armor out; and 2) there are 20 types of armor, and at any time a player is only looking for 4 of them.

Modifying the RNG by reducing the negative chances should improve the average quality of armor a lot more than it does the average quality of weapons, however. Less armor will be considered lower value and deleted, so it somewhat raises the perceived drop rate of armor.


If you can think of anything else you want, I pretty much know what is and isn't possible without a lot of work.

[Demonseye]

The thing is, it DOES make them irrelevant. NM still works just fine. Take down the copters and the ogres become weaker. That's the counter.

Up until copters were introduced, ogres were basically still the only enemy that can really end the game. Copters were designed to be a threat. The only thing I would do to balance them at this point, because they've already had the hell nerfed out of them, is reduce their numbers. This is just my opinion, of course, but the fact is copters have a counter, and their intended purpose was to be a serious threat if not handled properly, just like all the enemies before it.

Problem, is that you think only about people that CAN handle those copters. I, am one of them.

but are you thinking even one second about the lower players trying to get to Nightmare? Poofie, a copter that will pwn your build and take your happiness away...

How can they get some gear to survive Nightmare if you throw ultimate powerfulness on them? (especially when dat RNG is broken)

AND the most important thing : how to survive maps that didn't have a single change on them, same mana, same DU's, but the most deadly enemies were added on top of all of the others?

Strategically speaking, Air-carried enemies should have less defense, way less defense than others as long as they are flying? why do you think that in RTS, the troops carried via a Chinook or some other thing have way less HP than when they are on ground?

Think about the lower players trying to get to Nightmare without any help. Low tower stats, even lower DPS... impossible.

[grey-1]

I actually like the copters and the counter... but I do understand the pain for players breaking into nightmare.

I don't think it would take much to keep them a challenge and yet make them easier to deal with for low to mid stat nm players. First thing is to keep them from flying too high. I know this is supposed to have been fixed... Next thing would be to look at the flare rate of fire. Getting that to scale (or better scale if it already does) with the wave would mean that on the lower waves the defenses would be more effective at shooting down the ogre laden copters and thus copter-ogres would be weaker. Anyway something as small as that change could make a huge difference in the earlier waves where most players with low to mid nm stats would expect to be playing. This scaling would also leave the later wave copters and copter-ogres either untouched (or even slightly buffed if needed). If the flare rate scaling isn't effective as a means, then copter health scaling would be the next thing I'd look at. I wouldn't touch the copter-ogres or the headcounts. IMO balancing at this point is a very delicate thing and requires time in testing so the nerf/buff/nerf cycle does not start.

Also does anyone know if I can just use a text editor to make code changes and then jump to DDDK to cook (compile) instead of hunting around inside the DDDK?

EDITED: Deleted the weapon size comment since Dingle already had it covered with code (which I didn't fully read earlier). Nicely coded.

[Dingle]

Dingle - with regards to the size /quality call; could it be changed so that toon type determined the sizing direction then original quality determined the size adjustment. For example squire/monk weapons get larger the higher the quality and hunt/app weapons get smaller the higher the quality? Something like a do case with an error catch.

Also does anyone know if I can just use a text editor to make code changes and then jump to DDDK to cook (compile) instead of hunting around inside the DDDK?

It's easier to go by weapon types. A given item knows what weapon type it is, and hence which classes can equip it, but the stat randomizer doesn't know what class you're using at the time.

And yes, you can use text editors to make changes. Create a total conversion, find the new folder for it, and edit the scripts directly, and the changes get compiled next time you load the DDDK with that TC. Heck, I don't recall DDDK actually having a code editor built in - you pretty much have to use a text editor. There aren't any I know of which are designed for unreal script, although some text editors have plug-ins available which are capable of minor things like syntax checking for unreal script.