Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

4 Neutral

About CyrusBlaze

  • Rank
  1. As gamestage is currently based on " gameStage = ( playerLevel + daysSurvived ) * difficultyBonus " this likely only updates on a new day, when the player level ups or when the player dies. It is highly unlikely this calculation is running all the time. Once the gamestage does trigger an update, this would update the 3 new variables adding in 3 calculations per gamestage update. These would then stored in their respective variables and referenced when needed by the respective systems. All the rest of the calculations (such as loot rolls, zombie spawns, horde stuff) are already being done, this would not change them in any way apart from what they use as a starting value (***stage vs gamestage) this would not add any additional complexity or calculations in those systems. So it would all boil down to how often the gamestage is being calculated / updated as yes, it would add some calculations to it. But as its very unlikely they have the gamestage update running constantly the over all impact / added complexity would be quite minimal.
  2. The impact would likely be quite minimal (if any at all) as all the 'hard' calculation are already currently being done (gamestage itself is actually a pretty simple calculation as is). All this does is add a couple very basic X * y = Z calculation (3 of them with my suggestions). So while yes it will need to calculate those three new variables when the gamestage changes, considering the sheer number of other calculations being done at any given point adding in 3 new (very basic arithmetic) ones would likely equate to a drop in the ocean. (I also imagine the game stage calculation is only updated after a certain amount of time and not constantly recalculating which would further reduce the impact this could possibly have) As for how involved the coding would be, I feel this would be fairly easy to pull off as many of the potentially impacted systems are referenced in their own ways/sections so it would be a relativity simply matter of renaming the variable they use (currently gamestage) and have the gamestage to 'other stage' calculation called prior to them being processed. Once the key variables are created and passed onto their corresponding sections, the XMLs themselves could very easily be mass modified. While I haven't seen the core code for this game, and solely based off my experience as a programmer (for what its worth, programming is a large part of my job) splitting one variable into 3 and passing them into the correct procedure/classes/libraries and updating each to the new variable is a pretty simple/straight forward task. Its all just a matter if enough people and the Pimps think its a good idea or not (*fingers crossed they see it an love it*) lol
  3. At some point it might be statistically unlikely, but that's only after hundreds if not thousands of rolls for the exact loot group. With your sample size it absolutely can be chalked up to 'luck lol' That being said here are the groups that control the gun part loot tables: (you can view the entire loot table via the loot file in the data/config folder if you want to see what is where and report an item actually missing) <lootgroup name="modGunT1"> <item name="modGunBipod"/> <item name="modGunChoke"/> <item name="modGunDuckbill"/> <item name="modGunFlashlight"/> <item name="modGunForegrip"/> <item name="modGunMagazineExtender"/> <item name="modGunMeleeTheHunter"/> <item name="modGunMuzzleBrake"/> <item name="modGunScopeSmall"/> <item name="modGunTriggerGroupSemi"/> <item name="modShotgunSawedOffBarrel"/> </lootgroup> <lootgroup name="modGunT2"> <item name="modGunBarrelExtender"/> <item name="modGunCrippleEm"/> <item name="modGunBowArrowRest"/> <item name="modGunLaserSight"/> <item name="modGunReflexSight"/> <item name="modGunRetractingStock"/> <item name="modGunScopeMedium"/> <item name="modGunSoundSuppressorSilencer"/> <item name="modGunTriggerGroupBurst3"/> <item name="modGunShotgunTubeExtenderMagazine"/> </lootgroup> <lootgroup name="modGunT3"> <item name="modGunBowPolymerString"/> <item name="modGunScopeLarge"/> <item name="modGunTriggerGroupAutomatic"/> <item name="modGunDrumMagazineExtender" prob=".3"/> </lootgroup> The Semi mod is actually a T1 mod, so with a higher gamestage the other tiers are also being rolled on reducing the chances of seeing them the further into progression you get (not impossible, but you have a higher chance at the lower tiers) The Silencer is a T2 and in the same group as the burst mod you have gotten several of, so just a matter of the RNG gods not giving you what you want.
  4. Will try and get straight to the point as I feel this should be fairly easy to understand, and something i think would be fairly 'easy' to implement. Gamestage currently dictates quite a bit on how the games progression plays out, what zeds you see in POIs, how hard hordes are, and now (for better or worse) what loot you find. I think that while the Gamestage is a good starting point for how 'progressed' a player is, I think there is room for improvement and customization that can be done with it to allow for a wider group of people to benefit and choose how to play. So I present the following additions! Gamestage - Stays essentially the same as it is now, but rather than being then end all be all 'progression' the following will use this core number as their base, allowing for them to be customized by the player Lootstage Zombiestage Hordestage The above would then used by their perspective systems, this could give players (either via game options or even mods) the option to adjust how these would progress. Want 'better' loot sooner? Set your Lootstage to 150% Want easier non-horde Zombies? Drop your Zombiestage to 75% Want stronger hordes? Bump that Hordestage to 175% Everything else with these would be the same as they are now (assuming each were set to 100%) but rather than use purely the gamestage value, it takes the gamestage and modifies it based off the selected percentage. Hope that all makes sense, let me know your thoughts or ways this could be adjusted / improved upon.
  5. Love this! Will come in handy once i get my server up and running. Any chance you can do the same with the other vehicles? (motorcycles especially)
  6. don't know how I missed this mod back when I last played A16, but saw you UI stuff and just had to give this a shot. SO reloaded my A16 copy and so far I am loving it! Can't wait to see what you do with this for A17!
  7. I modified it slightly, but am at work so cant test to make sure it functions right <set xpath="/buffs/buff[@name='buffReloadMovementPenalty']/effect_group/requirement[@name='ProgressionLevel' and @value='0']/passive_effect[@value='.5']/@value">0.005</set> <set xpath="/buffs/buff[@name='buffReloadMovementPenalty']/effect_group/requirement[@name='ProgressionLevel' and @value='1']/passive_effect[@value='.4']/@value">0.004</set> <set xpath="/buffs/buff[@name='buffReloadMovementPenalty']/effect_group/requirement[@name='ProgressionLevel' and @value='2']/passive_effect[@value='.3']/@value">0.003</set> <set xpath="/buffs/buff[@name='buffReloadMovementPenalty']/effect_group/requirement[@name='ProgressionLevel' and @value='3']/passive_effect[@value='.2']/@value">0.002</set> <set xpath="/buffs/buff[@name='buffReloadMovementPenalty']/effect_group/requirement[@name='ProgressionLevel' and @value='4']/passive_effect[@value='.1']/@value">0.001</set>
  8. Here is a snippet that I used to add it to various food types. I originally did it for each recipe individually, but you can chain some 'or' commands in the name section to add them all at once. <append xpath="/items/item[@name=foodBoiledMeat] /property[@class=Action0]"> <property name="Create_item" value="drinkJarEmpty"/> </append>
  9. While you may not be able to modify the locilization file. I have had decent success in modifying a description directly and bypassing the localization file (if it cant fidn it in the locilization fiel it prints it as is ingame) It may not be perfect for all cases, but my limited use of it works well enough until propr localization modding is implemented.
  10. CyrusBlaze

    TSBX Collection

    I went about this a slightly different way with my tweaks. (Have not heavily tested it but should work... maybe) Instead of adjusting the weapons, I added a Level 0 skill to the various headshot skills to give a baseline headshot amount that increases based on skill level.
  11. First A17e patch and I can already say I LOVE this new method. Yes, it does take a bit more work upfront.. but man is it worth it!!
  12. (Have not tested this yet - will attempt to do so when I get home tonight) How about adding/changing things within the text files such as the locilization.txt?
  13. Do you know in what order the mods are applied? I'm assuming that it is most likely going to be trying to parse them alphabetically. May do some testing later today to see if that seems to be the case
  14. CyrusBlaze

    A16 Valmod Pack

    This is due to the amount of recipes. basically every time the inventory is updated (items added/removed) the game rechecks EVERY recipe in the game causing this lag. This is especially worse in the forge when you are melting items down or making items that get crafted quickly (such as bullets) as the quantities are changing constantly thus call for a recipe refresh constantly. You can reduce this effect to an extent by switching to your "favorites" menu as that will usually have no, or very few recipes in it and will reduce the number of 'refreshes' that are done at each inventory update. Personally I would like too see TFP address this directly by having a simple 'refresh' button that will update the recipe list rather than it doing it at every inventory update.
  • Create New...