• Content count

  • Joined

  • Last visited

  1. Enhanced Armor Mod

    Wouldn't you not be able to use the weapon swing event since a bunch of injury types don't come from weapon swings? IE fractures (from falling), climbing through broken windows (glass & scratches), burns, etc?
  2. Enhanced Armor Mod

    Are there better Java doc for these methods that I am not seeing?
  3. Enhanced Armor Mod

    I've been trudging through the previously existing armor code and it's revealed some interesting stuff. The armor mod is completely reactive. I.E. it does not block injury effects (bite, glass, bullet, etc.) before it happens to a player, but after. The mod is constantly monitoring a players body part status, and when it notices a change to a body part (like a new bite injury) it will attempt to block the already occurred effect. If the effect is successfully "blocked", the mod fully restores the health to the body part and removes the effect. It happens so fast that it looks like you never took an injury in the first place. There is no effect on any normal non-injury related damage. The mod also has some strange hangups: Body parts with blocked effects always restore the full health of the body part regardless of what it was previously. If you take an injury to a body part (bite, scratch, etc.), the armor mod will no longer attempt to block additional injuries to that part. So once a body part is injured once, its unprotected until it no longer has any injury. If the player is attacked and blocks it, the armor mod will fully heal the body part, but does nothing to heal or revert the players overall health. So the damage from a "blocked" injury can still kill you from the player damage. I'll see if I can fix any of these things.
  4. Enhanced Armor Mod

    Grouping them might be a bit tough with how they are stored, the shield is pretty much a worse case for amount shown. Most items only effect a few body parts.
  5. Enhanced Armor Mod

    Hello all, I've been working on a Enhanced Armor Mod (EAM) for Hydrocraft and am looking for a bit of feedback. New: Armor is now inspected using a new "Armor" tab. No more individual "Examine" events. Armor stats can be viewed by hovering over an armor piece. Item slots change color depending on the durability of the item in the slot. Green > 75%, Yellow > 50, ... etc. Items in the inventory are marked with a shield icon to show they are equipped as armor. Shields are auto-equipped as armor when equipped in the secondary slot. New sounds for when equipping armor, blocking an attack, and when your armor breaks. "Transfer All" will ignore equipped armor items. See screenshot: Thanks!
  6. ORGM Rechambered

    Will do, thanks for the heads up.
  7. Hydrocraft Mod

    I believe it just means that if you equip the drainable physically in your hand it will drain until it is gone. AKA charges of the item are constantly used while equipped in primary/secondary slots. This does not seem to have any effect on whether it drains/depletes or is equipped in hand when used in recipes. In fact most of your drainables already set it to false (see Solder Gun Powered), with only a few missing it. This all stems from people on my server accidentally equipping the items with the missing parameter in their primary slot and noticing that it very quickly depletes all charges for the item. Notice the base Soap2 drainable recipe. useWhileEquipped is set to false. http://undeniable.info/pz/wiki/item.php?Name=Soap2 On the other hand, the flashlight does not have this parameter (which looks like it defaults to true). And it makes sense that it would drain while equipped. http://undeniable.info/pz/wiki/item.php?Name=Torch
  8. Hydrocraft Mod

    Sure, this should do it. Let me know if I missed anything. Changes.7z
  9. Hydrocraft Mod

    We decided to make a few changes to Apiculture on our server that I thought were interesting. There were several things about the current system we didn't like. Once you got one stage 1 beehive you could pretty much get infinite Honey with the 1 flower (pretty much any type)=1 honeycomb recipe. This recipe increased to a whopping 1 flower = 4 honeycombs with Stage 3. The recipe was also instant and required no wait time (other than the crafting time). Since the recipe was repeatable with a single hive, there was really no incentive to build more than one. To solve this we added another layer between the hive and hive with honey. See below. With this way there was no more instant honeycomb and it also encouraged having multiple hives. It also allowed us to disable collecting honey in the winter because the "Feed Pollen" recipe would fail to activate the hive between November and February. Pollen is created via herbalism table, tweezers and one of flowers used in the previous harvest honeycomb recipe.
  10. ORGM Rechambered

    Haha, thanks. I haven't had to much trouble poking around the code. Although it helps that I am a software developer by trade.
  11. ORGM Rechambered

    Yeah a completely separate system would be great. Our server has been experimenting with using the current one to break weapon parts and it is a pain to say the least. We have ours in a place where we can define the following for components: register('HomeMadeSilencer', { soundReduction=0.1, breakable=true, conditionDamageChance = .9, }) and they will break after some use. We only use it for silencers at the moment but it works on any component. -- based off your compatibility code ORGM.Client.silencerCheck = function(player, item) if item == nil then return end local itemType = item:getType() if ORGM.FirearmTable[itemType] == nil then return end -- get the scriptItem local scriptItem = item:getScriptItem() local soundVolume = scriptItem:getSoundVolume() local soundRadius = scriptItem:getSoundRadius() local swingSound = scriptItem:getSwingSound() local canon = item:getCanon() if canon and not canon:isBroken() then local name = canon:getType() local definition = ORGM.ComponentTable[name]; if definition and definition.soundReduction then local soundReduction = definition.soundReduction soundVolume = soundVolume * soundReduction soundRadius = soundRadius * soundReduction swingSound = 'ORGMSilencedShot' end end item:setSoundVolume(soundVolume) item:setSoundRadius(soundRadius) item:setSwingSound(swingSound) end -- tied too weapon swing ORGM.Client.degradeWeaponParts = function(owner, weapon) local weaponParts = { canon = weapon:getCanon(), recoilPad = weapon:getRecoilpad(), scope = weapon:getScope(), sling = weapon:getSling(), stock = weapon:getStock(), } for key, part in pairs(weaponParts) do -- Make sure part is attached if part then local name = part:getType() local definition = ORGM.ComponentTable[name]; -- Make sure the part is not already broken if not part:isBroken() then -- Make sure part is registered and breakable if definition and definition.breakable then local conditionDamageChance = definition.conditionDamageChance or 1 -- See if we need to reduce the condition if ZombRandFloat(0,100) <= (conditionDamageChance*100) then part:setCondition(part:getCondition()-1); end if part:isBroken() then owner:Say("Damn, my " .. part:getDisplayName() .. " broke!"); end end -- Weapon fired with a broken mod, drop it to the ground else weapon:detachWeaponPart(part); owner:getCurrentSquare():AddWorldInventoryItem(part, 0, 0, 0) -- If the the part type is canon, perform the silencer check if(part:getPartType() == "Canon") then ORGM.Client.silencerCheck(owner, weapon) end end end end end
  12. ORGM Rechambered

    @Fenris_Wolf Have you ever considered making weapon mods break? I have been messing around with this concept using your mod and the silencer one. It has always felt a bit overpowered to me to have a silencer or scope that never breaks while the guns they are on fall to pieces.
  13. Profession Framework Mod

    Thanks for all the updates to this and ORGM! We appreciate your hard work.
  14. Profession Framework Mod

    Very cool! I think you might be missing the trait herbalist2 though. addTrait("Herbalist2", { name = "UI_trait_Herbalist", description = "UI_trait_HerbalistDesc", profession = true, exclude = {"Herbalist"}, swap = "Herbalist", })
  15. ORGM Rechambered

    I don't know if anyone else would be interested, but on my server we didn't like how often weapons/gun items were spawning on corpses (Our zombie count is set to high so we go through a bunch). We didn't want to affect the spawn rate for other containers, so we decided to add a corpse rate modifier that affects the addToCorpse function. This will apply a factor to corpses before any other normal factors are applied. Server.addToCorpse = function(container) local choice = Server.selectFirearm(80, 14, 6) Server.spawnFirearm(container, choice.gun, choice.ammo, (3 * ORGM.Settings.CorpseSpawnModifier), 1, true) -- has gun Server.spawnMagazine(container, choice.gun, choice.ammo, (1 * ORGM.Settings.CorpseSpawnModifier), 3, true) -- has mags Server.spawnAmmo(container, choice.ammo, (3 * ORGM.Settings.CorpseSpawnModifier), 15) -- loose shells Server.spawnAmmoBox(container, choice.ammo, (1 * ORGM.Settings.CorpseSpawnModifier), 1) -- has box end After a bunch of experimentation we realized the spawn rate only goes so low. This is due to how the spawn chance check works. if Rnd(100) > math.ceil(spawnChance) then return false end So the spawn chance only goes down to 1/100 for anything that isn't brought to 0 by a modifier set to 0%. Since anything between 0 and 1 is set to 1 by the ciel() call. So if I set my CorpseSpawnModifier to 30%, all 4 of the items would have a 1/100 chance to spawn (since ciel(3*.3)=1 and ciel(1*.3) =1). In order to rectify this we changed our formula to: if Rnd(1000) > math.ceil(spawnChance*10) then return false end This allowed us to specify spawn rates down to 1/1000. We ended up using 20%, so our firearms & ammo were 6/1000 and mags & boxes were 2/1000.