Jump to content

khzmusik

Members
  • Posts

    1,250
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by khzmusik

  1. There are mods that try to revive the Behemoth, and they reveal some of the problems with it. Pathing is only part of the problem. The main issue is that the zombie AI is designed to target only two block heights for destruction: the one at "eye" level, and the one at ground level (so, two blocks high). If any zombie is taller than two blocks high, they can be trivially blocked by placing a weak block three blocks above ground level. No matter how weak, it will block movement, because the zombie will never target it for destruction. You could make a three-block-high wall of wood frames and be totally safe. So either the Behemoth needs to adjust its collision mesh so it clips through blocks higher than the second block (which looks ridiculous), or it will need to be shrunk so it fits within two-block openings (which makes it not so much a "behemoth" as a new zombie skin). The mods that try to bring it back have tried both approaches, and neither really makes for a compelling gameplay experience. It would be cool if TFP made the AI changes necessary for enemies to destroy blocks relative to the entity's size. (I for one would like a 7D2D version of the Stranger Things mindlfayer.) But this is quite a bit of work, and I don't think they will push other things aside just for this.
  2. Just as an FYI, I recently provided code to SCore that gets around this. Normally when a quest giver gives a quest that goes to a POI, that quest giver needs to have an associated trader protected area (it presumes the quest giver is a vanilla trader). If you substitute "RandomTaggedPOIGotoSDX, SCore" for the vanilla "RandomPOIGoto" objective, then it should get around this. If there is no trader protected area around the quest giver, then it should just choose a random POI, without considering the used POIs around that specific trader (it can't do that without a trader protected area). There is always the danger of repeated POIs, but it should at least work without throwing errors. To use it, you would need to use the "RandomTaggedPOIGotoSDX" objective instead of the vanilla "RandomPOIGoto" objective.
  3. Each entity can have only one faction, that property does not accept a list. What you want can be done, but it's not easy. It would involve creating new entity classes for every single NPC you want duplicated (including weapon variations), and then adding those NPCs to spawn in the game. Let's say you wanted to make unfriendly versions of my "Male Cowboy" civilian NPC. I am going to assume you want them to be of the "bandits" faction (not one of the other unfriendly factions like "whisperers"). The first thing to do is to make bandit versions of the character and weapon type. Example: <entity_class name="npcBanditMaleCowboyKhzClub" extends="npcMaleCowboyKhzClub"> <property name="Tags" value="entity,male,npc,melee,bandit" /> <property name="Faction" value="bandits" /> </entity_class> <entity_class name="npcBanditMaleCowboyKhzKnife" extends="npcMaleCowboyKhzKnife"> <property name="Tags" value="entity,male,npc,melee,bandit" /> <property name="Faction" value="bandits" /> </entity_class> <!-- ...etc. for all weapon types --> The "Tags" property doesn't extend so you need to specify it, and you need to change the "Faction" property value to whatever faction you want the NPCs to be. I'm pretty sure that's all you need to change to get things working. The next step is to get them to spawn into the world. In general there are two ways NPCs can spawn: In the world, outside of POIs. This is controlled by the biome spawn groups. In NPC specific POIs. This isn't widely used yet but will be in the near future when people start making POIs that are dedicated to NPCs. In both cases, spawning is controlled in the "entitygroups.xml" file. For biome spawning, I suggest just copying-and-pasting the XPath that puts the NPCs into the "ZombiesAll", "ZombiesNight", and "SnowZombies" entity groups. You can mess around with other groups later once everything is working, if you want. For POI spawning, I suggest copying the XPath that puts the NPCs into the various "npcWhiteriver" and "npcFreindly" groups, except that you should instead put them into the equivalent "npcBandits" and "npcEnemy" groups. There is a catch: the Civilian NPCs (and in general other folks' friendly NPCs) can be interacted with and hired, and that means they can't be spawned into horde groups (wandering hordes or blood moon hordes). It's possible to modify them so they can be spawned into these groups without throwing errors, but that's more complicated. I can tell you how to do that if you want. Hope that helps. FWIW, I do plan to make a "Rogues" pack that has more "normal looking" unfriendly NPCs. They will still be distinct, but perhaps not so obviously "bad" as other NPC bandit packs. (There will also be others that are more obviously "bad" though.) I still have a lot more to do before I get to that - mainly making NPC POIs - but it's on the roadmap.
  4. First, make a new item display info tag in ui_display.xml: <item_display_info display_type="modArmorCritResist" display_group="modAttire"> <display_entry name="PhysicalDamageResist" display_type="Decimal1" title_key="statPhysicalDamageResist" display_leading_plus="true" /> <display_entry name="ElementalDamageResist" display_type="Decimal1" title_key="statExplosionResistance" display_leading_plus="true" tags="heat,electrical" /> <display_entry name="BuffResistance" title_key="statBuffResistance" display_type="Percent" tags="critResistDisplay" show_inverted="false" /> </item_display_info> (You can name it whatever you want, I chose "modArmorCritResist" because that made sense to me.) Next, update your custom item to use that display type: <property name="DisplayType" value="modArmorCritResist" /> That should do it. (That is the XML, I didn't include the XPath commands to insert it.)
  5. This looks cool. But, does it only turn off the flames? I could definitely see uses for being able to turn them on, like if you have a "defend this POI" quest you could use them to trap the areas where the pipes are broken.
  6. I think you're talking about a character from the 1-VaultDwellerzPack modlet. Either that or you're playing the Wasteland mod, since I believe it uses that modlet. So the appropriate place to ask is in either the NPC Core thread or the Wasteland thread. However - I'm pretty sure I know the cause. If the entity has a "LootListAlive" property, then it will show the "Press <E>..." prompt when it's dead. You could remove that property, but that would disable the character's inventory if it's a hired NPC. The NPC Core folks get around this by having hirable NPCs despawn almost immediately after they die, so most players can't get the prompt. So either you have power armor NPCs that can't be interacted with or hired, or you live with that bug. Personally I think that bug is a small price to pay.
  7. Hey, all. I'm hoping someone with a lot of C# skills can help me with this. In C#, I'm creating a custom quest objective to go to a POI. It is designed to be a drop-in replacement for ObjectiveRandomPOIGoto, except that it accepts additional properties: included POI tags, excluded POI tags, and a distance (range or max distance) from the quest giver. This is all working in single-player, but now I want it to work in multi-player. And, in multi-player, this is my understanding of how it should work. 1. The method to find a POI is called on a client. Don't do it, and instead send a NetPackage to the server for it to find the POI. 2. The server receives the NetPackage, and the NetPackage itself does the job of finding the POI. It should use the same logic as the Objective would in single-player. 3. Once the POI is found, the server sends another NetPackage back to the clients with the POI information. 4. The clients receive the NetPackage, and "finalize" the objective (set the POI position and size). I am pretty sure that's accurate, but I want to get another set of eyes on it. One question is about step 3. I assume that, as long as the client is sent the POI position and size, that it doesn't need to be the same (custom) NetPackage type that the client sent to the server; that instead a vanilla NetPackageQuestGotoPoint type would do (this is what the vanilla ObjectiveRandomPOIGoto uses). Also: All the vanilla NetPackage classes have a GetLength method, and I can't tell what that is supposed to represent. Some return 8, others return 32, still others return a different length depending upon the count of some internal list or other. If you're reading this and can't answer, then would it be possible to help me test? I don't have any way to test a multiplayer game by myself.
  8. I'm the one who wrote that modlet, so I can tell you the technical details. DMT is being sunsetted, but not because XML modding can do the things DMT could do. DMT used to be used for C# patching using Harmony, and that is now supported natively by the game. But it's still C# code, so requires both client and server installation. The main reason I haven't updated that modlet to A20 is not because of DMT, it's because weather itself was totally revamped in A20, and none of the A19 code can be used. Another reason is that A20 severely nerfed farming, so making crops be able to die - thus making farming even more difficult - is something I thought was unnecessary, and not something I thought anyone else would be interested in. The placeholder block idea from Telric is probably your best bet if you want an XPath-only modlet.
  9. Those "progression" modlets are designed to work with the various NPC packs. Since there's no way for me to know which packs a user has installed, I had to make one modlet per NPC pack. They're named after the pack that they work with, except they start with a higher number, and have a "_khzmusik_Progression" suffix. So, "2-XNPCCore_khzmusik_Progression" is designed to work with "0-XNPCCore", and "2-RaiderzPack_khzmusik_Progression" is designed to work with "1-RaiderzPack", and so forth. That's the recommended way to name modlets that are designed to work with other modlets. (For example, the "2-NPCXSpiderPack-ColonyExpansion" by Arramus is designed to work with/extend "1-NPCXSpiderPack".) I thought this was either obvious or common knowledge, so I didn't explain it in the post itself. Obviously I was wrong, so I'll update the post. EDIT: The list also says which modlet it was designed to work with. So the link to "2-RaiderzPack_khzmusik_Progression" says explicitly that it is "for 1-RaiderzPack". EDIT 2: Maybe the installation procedure, as opposed to the modlet relationship, isn't clear? In general, if a modlet is designed to work with another modlet, it doesn't include that other modlet. They need to be downloaded and installed separately. That's true of all modlets in general. And, yes, they should all be installed into the "Mods" folder.
  10. I forgot that was still in NPC Core. I thought we changed that when it moved to using tags. I guess that means the animal factions are actually live, I didn't think they were. I just updated my post with this information. Thanks!
  11. I wrote a good chunk of the faction-related code that is in SCore, so I can give you the details. I expect a lot of people will have questions about NPCs and factions, so I'll try to answer them here. This is meant to be kind of a "user's manual" so it's long and detailed. Skip it if you're not interested in modding the factions or NPCs. 1. How are factions and relationships defined in XML? Each faction, and its relationships with other factions, is defined in npc.xml. There are factions that are defined in vanilla XML, and factions defined by NPC Core XML. Here is the vanilla XML that defines the "duke" faction: <faction name="duke"> <relationship name="*" value="neutral"/> <relationship name="whiteriver" value="dislike"/> <relationship name="undead" value="hate"/> <relationship name="bandits" value="dislike"/> </faction> Between vanilla and NPC Core, there are a whole lot of factions. But if you want to define your own, that is the XML you would need to write. 2. What factions are already defined? Vanilla defines these factions: "none": for non-player entities that don't specify which faction they belong to (see below) "animals": vanilla animals - can't be used for faction targeting "undead": zombies "bandits": human enemies; "bad guys" "whiteriver": Noah's clan (apparently based on the real Whiteriver, AZ); "good guys" "duke": the Duke's clan "trader": traders NPC Core defines these additional factions: "whisperers": TWD-style whisperers (I just released a pack for these guys, see my thread if you want it) "vault": Fallout-style vault dwellers "military": military "redteam": sample military faction, currently unused "blueteam": sample military faction, currently unused "blueteam": sample military faction, currently unused "mechs": enemy mechs, robots, cyborgs, etc. "allymechs": currently unused NPC Core also created these animal factions, and it sets the factions of vanilla animals to use them: "companionanimals": used by the NPC Core fox "zombieanimals": bears, vultures, dogs "passiveanimalssmall": rabbit, chicken "passiveanimalsmedium": stag, doe, boar "passiveanimalslarge": not currently used "aggressiveanimals": not currently used "aggressiveanimalssmall": snake, coyote "aggressiveanimalsmedium": wolf, dire wolf, mountain lion "aggressiveanimalslarge": bear, Grace 3. What do the relationship values mean? In the XML, the "relationship" tag defines a relationship between the faction and another faction. The "name" property specifies the other faction. The special value "*" means "any other faction that isn't defined here." That includes all player characters. (It does not include members of the same faction.) In 7D2D, the relationships between factions are stored as numbers between 0 and 1000 (inclusive). The values in XML specify the tier of the relationship. Here are the values for each tier: "hate": 0 "dislike": 200 "neutral": 400 "like": 600 "love": 800 The relationship between members of the same faction is always "love". (TFP hard-coded this.) A relationship of "hate" means that the NPC will attack the member of the other faction (or player) on sight. Otherwise, the NPC will not attack the other NPC/player, unless that other NPC/player damages them first. The faction relationship also determines "friendly fire" rules. If a the relationship with the other entity is high enough, the NPC can't damage that other entity. Note that the "other entity" could be any entity, including the player. If the NPC descends from the C# EntityNPC class, the relationship needs to be "neutral" or higher to be damage immune. If the NPC descends from any other C# class, the relationship needs to be "love" or higher to be damage immune. Regardless of C# class, if the other entity is a player, the relationship needs to be "hate" for the player to be damaged. However, if an NPC is damaged by another entity, that other entity becomes their "revenge target" (this is actually what TFP calls it). Regardless of the above rules, an NPC can damage its revenge target. (An NPC can only have one revenge target.) The "friendly fire" relationship level can be changed by setting the "DamageRelationship" cvar on the entity class. For instance, to make the player able to damage any NPC, set a cvar when the player spawns in: <effect_group name="Damage All NPCs"> <triggered_effect trigger="onSelfFirstSpawn" action="ModifyCVar" cvar="DamageRelationship" operation="set" value="1001" /> <triggered_effect trigger="onSelfEnteredGame" action="ModifyCVar" cvar="DamageRelationship" operation="set" value="1001" /> <triggered_effect trigger="onSelfRespawn" action="ModifyCVar" cvar="DamageRelationship" operation="set" value="1001" /> </effect_group> (This XML is in the NPC Core entityclasses.xml file but is commented out.) If you want this to apply to NPCs, then you would have to set that cvar on the XML entity class that defines those NPCs. All characters that use NPC Core descend from the "npcMeleeTemplate" entity class, so if you want it to be set on all NPCs (human or otherwise), you could use that. The exception to all of the above is the vanilla "animals" faction. SCore is hard-coded such that enemy entities which are part of that faction, totally ignore all faction-based rules. (This was done to fix a bug where the mere presence of SCore, with or without NPC Core, would make all animals immune from damage. It's probably not necessary now that we use tags - see below - but it's still in the code AFAIK.) 3. Which entities use factions? How can you change that? Please note something important: The entity does not have to use Utility AI (UAI, used by human NPCs in Core) in order to use faction targeting/friendly fire rules. An entity's faction is defined by the "Faction" property in its entity class XML (in the entityclasses.xml file). That property is inherited. All vanilla and NPC Core entities have their factions set already. That doesn't apply to players. Each player is assigned its own unique faction. (So, NPCs have unique relationships with each player in a multi-player game.) Player faction relationships can't be specified in XML, and I'm pretty sure the game would ignore the "Faction" property if you tried to set it on a player's entity class. However, the mere presence of the "Faction" property doesn't necessarily mean the faction is actually used by the entity. SCore has a "config feature block" which is used to configure various things, including NPC behavior. If you want all entities in the game to use faction targeting/damage rules, you can set the "AllEntitiesUseFactionTargeting" property value to "true". It is set to "true" in NPC core, so this is the default. If you only want certain entities to use factions, then you should set that value to "false": <set xpath="/blocks/block[@name='ConfigFeatureBlock']/property[@class='AdvancedNPCFeatures']/property[@name='AllEntitiesUseFactionTargeting']/@value">false</set> You can then specify which entities use factions, according to the tags on the entity (in its "Tags" property in the entity class XML). Note that tags are not inherited. In the SCore config feature block, the "UseFactionsTags" property defines which entity tags use faction targeting. To change it, you could edit that by hand, or you could use XPath in your own modlet. For example, this is what I did in my Whisperers pack, so that zombies don't attack whisperers, and vice versa: <append xpath="//block[@name='ConfigFeatureBlock']/property[@class='AdvancedNPCFeatures']/property[@name='UseFactionsTags']/@value">,zombie</append> Another approach is to add one of the existing SCore tags to whichever entity you want to obey faction rules. These are the entity tags that SCore currently uses to determine whether the entity uses factions: human bandit survivor npc trader 4. What about follower (hired) NPCs? Followers (like hired NPCs) always use the faction rules of their leader (like the player that employs them) for targeting and damage. The exception is when they are hired by one player, and are targeting another. In this case, they use the same "friendly fire" rules as the players themselves. So, if two players cannot damage each other, then one player's hires can't damage the other player, and one player's hires can't damage the other player's hires. In either case, the follower's faction is no longer relevant. All of this is hard-coded in SCore and can't be changed. 5. Are faction changes save-game safe? Absolutely not. You must start a new game if you ever add factions to, or remove factions from, the game. Here's why. 7D2D saves the factions in an array (with a numeric index), not by name. Let's say you add a new faction. In the game save, the faction at index 10 might have previously belonged to a player, but now belongs to the new faction you just added. It will be a mess - and is hard to debug, because it might not even result in a red error in the console. So, just don't do it. Hope that helps!
  12. I am very pleased to announce that I finally finished the Whisperers pack! It includes characters that can be either "basic" (standard enemies) or "advanced" (if using mods/modlets that change faction alignment, you can talk with them, or even hire them, once your standing with the Whisperers faction is good enough). Also included are Whisperer voices that I recorded myself, and came out pretty creepy, I think. The link to the repo is in the first post, but here it is if you don't want to hunt it down: https://gitlab.com/karlgiesing/7d2d-a20-modlets/-/tree/main/1-khzmusik_NPC_Whisperers
  13. The NPC Core is designed to be a base that other modders work off of. The only NPCs that you get are meant to be used as tutorials as much as anything else. The only zombie in Core itself that will spawn is called "zombieFemaleTutorial." Having said that, there are a whole bunch of zombie packs out there. I have one that is updated to A20. Most of them (including mine) are linked in the first post. Or if you want mine specifically you can also grab them from my thread: https://community.7daystodie.com/topic/27333-a20-khzmusiks-modlets/ Trying to use the CP zombies from A19 will work, but just barely. You'll almost certainly have to make some XML tweaks to not get console warnings. They also will probably have other issues (weird fire particles, etc). Personally I'd stick with the various A20 packs. Also, if you don't mind UMA, then you can always grab Error Null's zombies. There is quite a variety, but that modlet also makes significant changes to entity groups and spawning, so might not play nice with other modlets. It's here if you want to check it out: https://community.7daystodie.com/topic/24594-enzombies-more-zombie-variations/
  14. You're right. The file that will do this is the "Config/Options/entitygroups_nocorespawn.xml" file - rename it to "entitygroups.xml" and move it into the "Config" folder (replacing the existing file). Sorry for not mentioning this.
  15. I just added a series of modlets that restore gamestage progression to the NPCs that spawn into POIs. A recent update to the NPC Packs for NPC Core removed all the probabilities from the entities which are spawned into sleeper volume groups. As a result, players will encounter the same NPCs at gamestage 400 as they do at gamestage 1; and at all gamestages, they have an equal probability to encounter an NPC with an M60 as they do an NPC with a club. This is obviously not balanced. So if you are playing with - or designing - POIs that use human NPCs, I highly recommend that you download these modlets for a better gameplay experience. The probabilities were generated by scripts (one script per NPC pack), and the scripts are in the modlets. Feel free to modify them for you own use. You will need to know JavaScript (but nowadays, who doesn't). Now that those are out of the way, I will get back to creating Whisperer NPCs. After that, there should be NPC packs for all the different factions, so I will finally be able to start porting over (or redoing entirely) the NPC POIs I created in A19.
  16. You can also just remove them altogether. Xyth added the "none" entity to all the custom entity groups, which spawns at a very low probability, so there won't be any empty entity groups if you do remove them (empty entity groups cause issues). If you want to create your own modlet, all you need is a Config/entitygroups.xml file that contains this: <config> <remove xpath="//entity[starts-with(@name, 'npcBaker')]" /> <remove xpath="//entity[starts-with(@name, 'npcNurse')]" /> <remove xpath="//entity[starts-with(@name, 'npcHarley')]" /> </config>
  17. I see two possible avenues to examine, but I can't tell if either one will bear fruit. The immediate error is caused by the Faction Manager not being able to load a faction. I think you probably did this, but you absolutely must start a new game after installing any mods that add additional factions. Game saves have faction information in them, and if you add or remove factions, that information points to the wrong faction (or to null). The other avenue is what Xyth said: it could be due to putting the modlets in AppData. I notice in the log that the game is still trying to load some files from the Mods folder in the Program Files location. (See e.g. line 84 in your latest log file.) It might be that 7D2D hasn't yet migrated everything over and is still trying to load Harmony patches from the Program Files location; or it could be something specific to SCore. Or it could be a red herring. When you have time tomorrow, try one or both of those things, and see if the problem persists.
  18. Well, for those mods, nothing has changed. You'll still have to either overwrite the vanilla game files (with all the Windows/Steam headaches that implies), or modify a second copy of the game. I expect people will still use the Mod Launcher to do the latter. Luckily there's not much that you can't do with Harmony that would make BepInEx necessary. (Add properties/methods to existing classes is the only thing I can think of.) Plus, it's not like TFP ever intended to support BepInEx in the first place, so it's no skin off their nose.
  19. This is all very good news. It will probably be easier for people to install mods now, assuming they are tech savvy enough to know how to create a folder and modify a shortcut. ...which admittedly is a big assumption. But for the non-tech-savvy there's always the Mod Launcher. With this change it also might not be necessary to have separate game installations, assuming the mods only use Harmony and/or XPath and don't need to modify the game files directly.
  20. What all does it read from that folder? Is it just mods, or is it also saved games, generated worlds, the player profile? Since mods usually break game saves, and may include custom POIs, it would be great if all that were stored in one location.
  21. No worries. I might not be the best person to ask though, just because my answer will probably be "use the Mod Launcher"
  22. No idea why you pinged me, but I'll put in my two cents. Personally, I have always used SphereII's Mod Launcher to launch modded games. The reason is simple: I will never, ever mod the game that is in the Steam folder. I have always played concurrent modded and vanilla playthroughs. I have also always played the latest experimental as soon as it's available, even though I usually have a long-term playthrough on the previous alpha that I still play until the next alpha is stable (and sometimes after that). Not to mention mod development. I have done lots of development where I have totally broken the game saves. I've sometimes broken things bad enough that I've had to re-install the game. But that has always been OK, because every mod I've played has been on a different copy of the game, in a different folder on the hard drive, each of which has a different mods folder. The Mod Launcher makes this very easy which is why I recommend it. So, the move to keep all the mods in one place is a very bad idea to me. It doesn't matter where that place is. If mods have to be in any one place, and that place only, then I'll have to stop playing mods, and my relationship with this game will end a whole lot sooner. Having said that, the game has always allowed things to be loaded from different directories through command-line arguments. (It's how the Mod Launcher keeps game saves and worlds for different game installations in different places.) As long as that is still an option then I will be OK. But it would be better if the game could specify these locations in some way that is far more convenient. A new entry in the game's settings screen, a "browse" option in a launcher, whatever. It should be easy enough such that anyone who knows how to open a folder can do it.
  23. Thank you both for asking. It does mean a lot to me. If you don't know, in A20 I was part of the NPC Core team. While it was good at first, it ended up being a very bad experience for me, largely due to one other team member. (It's not Xyth or anyone else on the forums.) In essence, any time I brought up stuff I wanted to do - like dynamic factions, or a "reputation" mechanic - the guy basically said "I know what players want, and nobody wants that" and insisted I make changes that very nearly made these things impossible. (These same changes ended up causing major bugs which I spent weeks fixing.) Unfortunately he became the major driving force for NPC Core. It really soured me on not just modding, but the game in general, and it also made me act like an ass. I had to step away, and in fact I quit Guppy's Discord entirely. But, I am still working on all of that. I just am not working as hard as I was before, and you're right, it is a whole lot of work. My current project is to make Whisperer NPCs, complete with custom sounds and whatnot. Once that is done, then there should be NPC packs for all the factions we had in A19. I was going to move on to POIs next, and I still hope that with the stuff I did that is now in Core, more people will be making NPC POIs. The quests are probably the last thing that will happen. To work as it did in A19, we need a drop-in replacement for the "Goto" quest objective, so quests can target POIs with certain tags (and so vanilla quests won't target those POIs). A20 changed the way that the game chooses POIs, and it's a lot more complicated now (especially in multiplayer). The fact that you guys showed interest is really good for me. I can feel justified putting more time into this now.
  24. I meant to reply earlier, sorry about that. I see now what you mean - you're not so much crafting a "stack of dyes" so much as a separate item that is stackable. It's not a bad idea, but it's probably a bit complicated. I think I will simply make dyes craftable from paint. That's consistent with what the game already does for other items. Since scrapping items vs. smelting them loses 25% of the materials (I asked about this in a separate thread), I figured that it should take 25 paint to craft a dye, since scrapping a dye gives you 20 paint.
  25. The original idea was that the bandits and players would use the same clothing system. Is that still the idea?
×
×
  • Create New...