[Modder] Request for Modification

[proud burrow]

Title: Add new vehicle events.

Introduction:
Introduce yourself briefly and state your motivation for sharing your idea or suggestion.
Hello there, I am currently developing a mechanic mod that adds new vehicle parts. While working on the mod I realised that there was no events triggered when a collision happen.

Problem Statement:
Identify the problem and explain why the current system is inadequate.
The new vehicle parts do not seem to receive damage when a vehicle is involved in a collision.

Solution Overview:
Provide an overview of your modification idea and its benefits.
The solution would involve adding events that are triggered when a car collides with a IsoGameCharacter, BaseVehicle and IsoObject, .
By listening to these events, it would be possible to selectively apply damage to specific vehicle parts based on our needs and much more.

Step-by-Step Implementation:
Outline the sequential steps to implement your modification.
Step 1: Add new events to LuaEventManager class

  OnVehicleCollideWithCharacter (vehicle, character, speed)
  OnVehicleCollideWithVehicle (vehicle, otherVehicle, speed)
  OnVehicleCollideWithObject (vehicle, isoObject, speed)
  OnVehicleCrash (vehicle, direction, speed)
  OnVehiclePartDamaged (vehiclePart, damage)

Step 2: Trigger the events where it should in BaseVehicle, VehiclePart, IsoObject and IsoGameCharacter.

Supporting Evidence:
Present relevant evidence or data supporting the feasibility and effectiveness of your modification.
While I do not have direct evidences, there is a general consensus within the modding community regarding the significance of events and their positive impact. By incorporating more events, a wide range of creative possibilities can be unlocked, leading to an enhanced quality of modded content.

Conclusion:
Summarize your idea, emphasize its potential benefits, and encourage feedback.
This modification would open up new possibilities for modders to create diverse and dynamic vehicle-based mods, fostering innovation within the modding community.

[novel rampart]

Title: Add into AddXP event argument/arguments if it was called by TV or VHS

Introduction:
I have my own mod Exp Recovery and currently have option to disable exp saving while reading book due to some mods gives exp literally for reading book

Problem Statement:
Problem is with this option you actually can't save absolutely any exp even from common ways like TV/VHS

Solution Overview:
Will be awesome to have argument/arguments to get for which thing players got exp
Exactly for my problem argument isTVorVHS is fine cos while u reading book u can't get any exp from any other source
Even better will be some thing to get "source name" from where exp was added (TV/VHS + as I remember adding exp for Sprinting also handles on java side, mb there's more same things, I didn't check them fully). And I think it's will be important only for java side cos lua source can be obtained by debug traces.

Step-by-Step Implementation:
.AddXP(character, perk, level, "TV")
.AddXP(character, perk, level, "VHS")
.AddXP(character, perk, level, "Sprinting")

Supporting Evidence:
With xp source name will be easier to handle getting of exp

Conclusion:
print(summarize(my_idea))

[proud burrow]

I suggest, you look into the source code and add the steps to implement your changes. Basically as if you were creating the modification yourself. This way other modders and TIS can review it and discuss better ways of implementing it, if any.

[warm gull]

Absolutely back this up! I constantly hit similar problems with vehicle related mods. Specially the bicycles. It's annoying, wasteful of performance and time consuming to make an alternate system and even then it's not remotely close to a proper, Vanilla way.

[warm gull]

Title: Trigger a proper event when a Player creates a new character. Pretty sure this one doesn't exist.

Introduction:
Hey hey! My Deathboard mod, and I am sure many others, partly rely on knowing when a Player makes a new character.

Problem Statement:
There is no proper way to know if a Player made a new character, and any methods we currently have are very messy.
OnCreatePlayer triggers anytime the game loads a character, rather than a new one. Somewhat confusing name.

OnNewGame For some reason triggers when a Player creates a new character. What? Not that it matters anyways. It only triggers if you press to make a new character immediately upon dying. If you leave and load the game again and make a new character, it doesn't trigger!

Solution Overview:
Add a proper OnNewCharacter event or something like this that only triggers when a new character is made. Not only in the same session, not every time a Player gets in. To get around this I had to hook in OnCreatePlayer and just make a guess based on if the Player character is new or not, which isn't exactly great.

Step-by-Step Implementation:
No idea how the game handles this internally, but we can see it absolutely knows when the Player is making a new character.

Conclusion:
As I've stated before, I believe this would help in many cases. I've only had this experience for my Deathboard mod, but someone suggested a mod for clearing the map on character creation that also would rely on this, and anything that wants to change anything about a Player on client side after they create a new character would also benefit.

[novel rampart]

oki, will change it asap

[proud burrow]

@warm gull @novel rampart do check my first suggestion up there as an example. Also let me know if you have ideas how to present our suggestion better.
#1118138532314218557 message

[warm gull]

I read it before

I think mine is obvious enough I don't need to add step-by-step implementation, we just need a method.

Can even be just a void, so long as it triggers properly

[novel rampart]

@proud burrow btw can I send here a simple suggestion? it's about OnWeaponHitTree to add tree obj there but I have no idea what's to write in all request sections

[proud burrow]

Something like LuaEventManager.triggerEvent("OnWeaponHitTree", character, weapon, (IsoTree)this);

[novel rampart]

yea yea

[proud burrow]

Title: Add tree parameter to OnWeaponHitTree event

Problem Statement:
Identify the problem and explain why the current system is inadequate.
The event OnWeaponHitTree doesn't tell us which tree was hit.

Solution Overview:
Provide an overview of your modification idea and its benefits.
Simply by adding the tree as a parameter to the code that triggers it.

Step-by-Step Implementation:
Outline the sequential steps to implement your modification.

Step 1: Add the parameter in IsoTree class

// this = IsoTree
LuaEventManager.triggerEvent("OnWeaponHitTree", character, weapon, this);

Supporting Evidence:
Present relevant evidence or data supporting the feasibility and effectiveness of your modification.
We add the parameter last to keep compatibility with any existing code.
The parameter could be null if the tree was destroyed by that hit.

Conclusion:
Summarize your idea, emphasize its potential benefits, and encourage feedback.
By adding this parameter it give the opportunity to modders to act upon the tree that was hit by an HandWeapon.

[novel rampart]

[proud burrow]

I did not test yet, but you could maybe check the survived hours of the created character.

Events.OnCreateLivingCharacter.Add(function(character, descriptor)
  local isNewCharacter = character:getHoursSurvived() <= 0
  if isNewCharacter then
    
  end
end)

It would be zero until the first update has ran.

[warm gull]

Yup yup, that's what I did

Also checked hours slept

[proud burrow]

Was that successful?

[warm gull]

Yes, but it's not foolproof, it's arguably unoptimized as it gets called every time a character loads in, and the game already knows when you create a character so it already has the entire foundation for a simple event that gets triggered only when you make a new character

[proud burrow]

Well characters are not loaded in often enough to be unoptimized.

Events.OnCreateLivingCharacter.Add(function(character, descriptor)
  local isPlayer = instanceof(character, "IsoPlayer") and isServer() or character:isLocalPlayer()
  local isNewCharacter = character:getHoursSurvived() <= 0
  if isPlayer and isNewCharacter then
    
  end
end)

With this, you make sure it's a player and a local one (if run on client) and you check it's brand new.

[stone panther]

This looks useful... Shame my only gripe with the game modding isn't the lack of hooks, but rather the bugs. Have a few that are messing up our server a bit, but I don't think I can provide anything conclusive through here

[dreamy warren]

Title: Allow Modders to Affect Vision

Introduction:
Hi, I'm Badonn. I'm a Software Engineer and about 5 years into my career. I recently started modding PZ in April and wanted to make the player experience more dynamic with mods that add more traits.

Problem Statement:
Currently the only ways that modders can affect vision are

• Adding Eagle Eyed, Short Sighted, Cat's Eyes, Keen Hearing, Hard of Hearing, or Deaf to a player,
• Turning on foraging vision,
• Turning on night vision goggles.

This leads to a less dynamic player experience, preventing modders from doing things like

• Occluding vision on losing an eye/injuring their head.
• Making players (or zombies!) able to see less or more during night or weather events
• Using in-world items to extend or decrease vision range (Binoculars, etc.)
• Changing perception range not relating to sight
• Etc.

Solution Overview:
Modders will be allowed to affect one of the most important ways a player interacts with the game: vision. This will help increase the longevity of interest in the game and the wow factor some players experience with what's possible in PZ.

Step-by-Step Implementation:
Step 1: Add new properties to IsoGameCharacter (in Kahlua and Java): BasePerceptionDistance, BaseVisionDistance, BaseVisionAngle, and their non-base variants. Additionally add OcclusionStart, OcclusionEnd (using degrees of a circle or percentages of the vision cone).
Step 2: Add non-base properties to LightingJNI.Java where needed. (would be more specific here but decompiled java is only so helpful)
Step 3: Expose Base variants of the above to Kahlua with gets, expose non-base variants with gets and sets.

Supporting Evidence:
During this time of optimization to the engine and chunk-loading, it's the perfect time to add the ability to affect vision. If needed, add Math.Min() to vision cone calculation to not break game.

Conclusion:
Exposing vision properties = more dynamic and immersive game.