khzmusik

You should be able to hire my civilians. If you can't, that is a bug. But, if you also can't hire the Baker character, that also might be a bug. When you try to hire the Baker, what exactly happens? If you don't have enough Dukes, you'll go through the whole hiring process (open the "Hire" dialog, click confirm) but at the end it will show a tooltip message saying "You cannot afford me. I want (X) Dukes." It's easy to miss the tooltip message.

It's probably not possible. The drone has a "Class" property of "EntityDrone" and traders have a "Class" property of "EntityTrader". These values correspond to C# types that determine their behavior, and they're not even close to interchangeable.

If this does what I think it does, then it would effectively remove spawning of anything inside a POI, whether it's a zombie or not. The world would be full of very empty buildings. I think a better idea would be to replace the zombies with the special "none" entity: <set xpath="//entitygroup/entity[starts-with(@name,'zombie')]/@name">none</set> You should only do this after you replace any zombies with other entities that you think are OK, like animals or human NPCs. But, there may be "gotchas." I know that if there are no entities in an entity group, the game will throw errors, but I don't know about only having "none" entities. Also, there are notes in the entityclasses.xml files about not having "none" be the first entity in the entity group, because that determines whether the entity group is an "enemy group" or not. (See the "EnemyAnimalsDesert" entity group.) Incidentally - if you are replacing zombies in sleeper volumes with human NPCs, then you might be interested in a modlet I wrote called "Variable NPC Sleepers." Assuming you're using NPCs that are based on the 0-XNPCCore modlet, it adjusts their behavior so that they behave more like vanilla zombies. If you don't use that modlet, then by default they become fully active when they spawn in, and end up wandering all over the place - this is especially bad if you accept "clear" missions from traders. The modlet is part of my thread here: https://community.7daystodie.com/topic/27333-a20-khzmusiks-modlets/ Also, if you are substituting zombies with human NPCs, keep in mind that most human NPCs can't be spawned into hordes (wandering hordes or blood moon hordes). The entities in hordes are required to descend from a specific C# class, and most human NPCs don't, because that class has limited functionality. (My Whisperers entities are exceptions, but you probably don't want those since they look like zombies.) I'm in the process of making more enemy human NPCs right now, and I will try to make those also able to be spawned into hordes.

When you get there, go to the #a20-prefab-rules channel, and look for a post with the attachment named "RWG_POI_and_Tile_Guide.pdf". It's a very good reference. It was supposedly produced by TFP themselves, but I don't know where else to get it.

You should not ask questions like this in this thread. It is better if you create your own thread in the "Discussion and Requests" forum. But to sort of answer your question, yes, that's going to need C# programming, and it probably wouldn't be simple.

I believe Cranberry Monster wants to double-check that you are using this code in a modlet, and that the modlet is properly organized. This code cannot go directly into the game's config files. The "<remove..." and "<append..." tags are XPath commands, not configuration XML. The game only recognizes XPath if it is inside a modlet, in that modlet's "Config" folder, in a file whose name matches the name of a file within the game's "Config" folder. (EDIT: the filenames must match exactly, so "Progression.xml" won't match "progression.xml".) Also, the modlet won't work unless there is a ModInfo.xml file inside the root folder for that modlet. If all that is true, then I'm not sure what to tell you. The code you posted above looks like it should not produce errors. Whether it will do what you want, I cannot say. I searched the game's XML files and could not find a "seedHarvest" string anywhere. Getting a seed seems to be determined by the "Destroy" drop event in the crop's block, and that does not have any tags.

This is just a notion, but maybe you could make a night vision variant of the binoculars. That would probably make them worthwhile even if they take up a slot in your toolbelt.

What I think would be cool is if you could specify a "base color" of a texture. That would get rid of some of the textures ("orange metal" or "red concrete") and offer a lot more flexibility. Of course, the real issue is space. There are only so many bits in a block, and if you add even two bits to store the index of a color map, that's two less bits to store the index of the texture map, meaning four less textures would be available. So who knows if that's worth it. The ideal solution would be to simply use more bits per block, but I'm guessing they're using a standard bit size (like a ushort), so moving up to the next bit size (like a uint) would double the bits per block. The map itself would take up four times the amount of memory it does now, as would any code that dealt with map chunks. So I understand why they won't do that.

I have not. If it works I'm going to steal it.

Unfortunately I have not heard of any way to get rid of that. It annoys me too, and we're not the only ones. I can do a deeper dive into the C# code, but since it annoys a whole lot of people, if there was a solution it probably would have been published already.

There are a lot of groups there, so I think you're probably the better judge of which Whisperers belong in which groups. I can make some recommendations though. In my opinion: There are three Whisperer characters that would be at home in snow biomes: Whisperer Female Lumberjack, Whisperer Male Lumberjack, and Whisperer Male Young. (I think I already have those spawned into the vanilla snow biome.) Otherwise, they probably work better in forest biomes. Their threat is in stealth, and it's more difficult to be stealthy without trees to hide behind. They probably would not work well with any armored or special zombie types, or animal zombies. So probably don't spawn them with vultures, soldiers, football players, etc. On the other hand, "crazies" or "camos" would probably work. If they're wandering with zombies (and not in their POIs) then they should use relatively silent weapons - meaning melee weapons (especially knives) or bows, and no firearms. In my own headcannon, they're religious fanatics, so any zombie groups with religious overtones (zombie priests or whatever) would be especially appropriate for Whisperers. Whichever you choose, it's probably worth it to just copy what I have for the "wanderingHorde" or "FwanderingHorde" groups in the modlet (and use whichever gamestage number you want). Those probabilities take into account things like weapon difficulty or health points, and you probably don't want to recalculate all that stuff. There is a Node.js script in the Scripts folder if you are in the mood to modify that and use it for your own groups, but copying what's there is probably the better option. Hope that helps.

First, this should be moved to the "Discussion and Requests" forum. The "Mods" forum is for announcing and discussing actual mods that are released to the public. But to answer your question - AFAIK no mod or modlet exists to do this, because I don't know anyone who plays 7D2D and doesn't like zombies. However, it's possible to write a modlet yourself that does it (or at least goes most of the way there - see below). What you want to do is to substitute all the zombies with animals. Which animals go with what zombies is up to you of course. The file you want to modify is entitygroups.xml. That controls which entities spawn. Keep in mind they spawn in many different contexts - biome spawns ("in the wild"), in wandering hordes, in blood moon hordes, in POIs, etc. I'm not sure which contexts you're talking about, or if you're talking about all of them. In general, you want to make a modlet that uses XPath to substitute each zombie for some animal equivalent. You can also use XPath to specify which entity groups you're targeting, and since they have predictable names, you can target the different "contexts" by entity group name. As a simple example, this targets biome spawn groups for zombies, and if that group spawns a zombie cop, it will spawn a zombie bear instead: <set xpath="//entitygroup[starts-with(@name, 'Zombies')]/entity[@name='zombieFatCop']/@name">animalBear</set> But there are limitations. According to comments in that file, "Bears/Animals aren't controllable by the BloodMoon horde system until the animal code is re-factored." I think I know what they're talking about, and if so, that isn't just the blood moon horde system, it's also wandering hordes. So it may not be entirely possible to substitute all zombies with animals. But it will get you at least partway there. Try it and see. Good luck!

The reason you can't find them on GitHub is because my modlets are all on GitLab. (Same idea, different service.) Here's the one for the Whisperers: https://gitlab.com/karlgiesing/7d2d-a20-modlets/-/tree/main/1-khzmusik_NPC_Whisperers For the most part I think you're right, my modlets and EN's probably don't overlap. But ironically, the one that might be an exception is the Whisperers modlet. That's because the Whisperers (unlike most human NPCs) can spawn into hordes, and I added them to the wandering horde groups. @ErrorNull I don't know if you changed the wandering horde entity groups or not, but if you did, then that's something you will have to consider with the Whisperers. Also - I haven't actually looked at EN zombies for a while, but if you like I can help you add my NPC packs to your updated biome spawn groups. Let me know.

Thanks! Though, to make sure you know, the quests that go to POIs aren't enabled, because there aren't enough POIs to support them. That's what I'm working on now, in fact. In the past I stayed away from Nexus, for a couple reasons - the users aren't used to how 7D2D mods work, they'd try to use the Nexus mod launcher which is iffy on 7D2D support (it didn't support Harmony/C# mods), it would be splitting my time between different platforms, etc. But I don't know how valid those reasons are with A20, since you can now install C# mods the same as XPath/XML mods. So, maybe I should look into that again, when I have time. EDIT: I just remembered one reason I don't use it right now. A whole lot of my modlets depend upon other modlets to work (particularly SCore and/or NPCCore). Those aren't on Nexus, so in order to use any of those modlets, people would have to come to these forums anyway.

Since you're in the A19 thread, I guess you're asking about how it worked in Alpha 19? In A19, there was global weather, and a global temperature. That global temperature was modified by biome (so for example it would always be 20 degrees hotter in the desert biome). The weather in each biome had a complex calculation (number of days without rain, fog, etc.) but it was all dependent on the global temperature. All my seasonal weather mod did, was set the global temperature according to the number of in-game days that had passed. It used a sine wave, where the upper peak was the summer, and the lower peak was the winter. A seasonal year was one cycle of that sine wave. I didn't do much more than that. The biome calculations for fog, rain, snow, etc. basically took care of themselves. All of this changed in A20. In that update the entire weather system was rewritten. There is no more global temperature, and each biome's weather is independent of other biomes. For that reason I can't update the seasonal weather modlet. That's most of what I know. Once I knew that I couldn't update my modlet, I didn't look very closely at the new weather system to see how it could be modded. If you want to research it yourself, the class is called WeatherManager in the game's C# code. You'll have to decompile assembly-csharp.dll to see it.

No, you can't do this. Entity tags in entity groups do not support the "maxcount" attribute at all. Instead you should do as Arramus suggested, and reduce the probabilities of all the NPCs in each biome group. (Or at least those that you see more than you like.) That's actually not how it works. There is no such thing as a 100% chance unless there is only one entity in the entity group. In fact, if there is no probability added, then it defaults to a probability value of 1. That's not 100%, that's a probability equal to entities that also have a value of 1. Here's how the probabilities are actually calculated. First, the game sums up all the probabilities of all the entities in the entity group (after mods add them, if applicable). Then, it takes each individual probability, and divides it by this sum. Mathematically, this is called normalization - it means the total probability for each entity group will be exactly 1. Now, each time an entity should be spawned from this group, it chooses a random number between 0 and 1. It goes through each entity in the entity group, in order, using the normalized probabilities. For the first entity, if the random number is less than its probability, that is the entity which is used. Otherwise, it adds that entity's probability to a running total, and moves on to the next entity in the entity group. If the random number is less than that entity's probability plus the running total, that entity is used. Otherwise... the process repeats until an entity is used. Also note that there is no "keeping track" of entities. It's all determined by RNG, so the same entity can be chosen multiple times. (Using the terminology of probability theory, choosing an entity is an independent event.) So, if modlets add a lot of NPCs to the zombie groups, then they can overwhelm zombies, so that there is a higher probability to spawn an NPC than a zombie. This can happen no matter how small each individual NPC's probability is. If an entity group has 10 zombies without probabilities (meaning: a probability of 1 per zombie), then this will happen as soon as the combined probability values of all the NPCs reach 10. If you install a lot of NPC modlets, and they all add their own NPCs into the same biome spawn groups (which they do), then this is almost guaranteed to happen. This is why I originally advocated that when NPC authors add their NPCs to a biome spawn group, the combined probabilities of all NPCs in that pack should add up to 1 in that group. This would mean there is an equal chance to spawn one of their NPCs, as there is to spawn a single zombie in that group. It also would mean that NPC packs with lots of NPCs (and/or weapon variations) wouldn't blow out NPC packs that had fewer NPCs. That didn't happen. C'est la vie. That's correct. It's because POI spawners are the only ones that are gamestaged, at least in vanilla - biome spawns aren't. (Wandering hordes are too, but you can't spawn most NPCs into wandering hordes, that will throw exceptions because most NPCs don't descend from the C# EntityEnemy class.) It's also easier to figure out POI spawning, since NPCs don't spawn in the same groups as zombies, so I didn't have to worry about zombie-vs.-NPC ratios like I would with biome spawns. I still don't know what most people expect that ratio to be (or even if there is any consensus at all).

The red errors in the first screenshot are due to changes in A20.6. The "onSelfRangedBurstShot" trigger is no longer in the game. (I know this because it also affected the NPC Mod.) If you are using A20.6, I suggest reverting to A20.5 (or earlier) until the mod can be updated. The yellow warnings in the second screenshot, are happening because you can only downgrade from one block to another ten times. I don't know what block is doing that. This also needs to be fixed by the mod author. Hope that helps you and @ShoudenKalferas track things down.

As a general rule, prefabs from A19 and earlier won't work for A20. Here's a not-necessarily-complete list of the reasons why: A19 contains blocks that aren't in A20. There is an A19-to-A20 conversion process, but some blocks simply can't be converted automatically. POI authors need to fix them even after conversion. A20 RWG uses Tiles for everything (except wilderness POIs). Tiles can only accept POIs of certain specific sizes (like 42x42 or 60x60). A20 POIs need "driveway" parts in order to connect to roads. The way A20 places POIs is through the values in a "Tags" property in the POI's XML file. That property did not exist in A19. Also, it looks like TFP want everyone to put POIs (and mods) inside the user's %appdata% folder, and to avoid putting anything into the game's directory structure. Apparently this is a requirement to get 7D2D to work with Microsoft game stores and cross-play.

What about prefabs that are part of a mod, and are in the game's Mods folder? Will they have to be moved in order to be edited?

I see you've worked this out, but if you're curious, here's what those files are. The .dll file is the compiled binary file that contains all of the custom code for the modlet. It is required. (7D2D doesn't care about the source files. Those are included either for people to look at the code, or because the mod author wants to keep the source code in the repository, or both.) If you didn't upload that file, then basically you didn't upload the mod at all (as far as the game is concerned), so it's not surprising that you got errors. The .pdb file is a Microsoft "program database" file. It contains details about the relationship between the compiled .dll and the source code. It is mainly included for debugging purposes - for example, if an error was thrown within the .dll, then without the .pdb, you couldn't get the stack trace for the error. So it's not required, but it is worthwhile to have. Just in case you're curious.

1. Unfortunately, if your mod/modlet has any non-XML assets, they will not be pushed from server to clients, so the clients will have to install them. Those include custom icons, Unity assets, compiled C# .dll files, etc. (I think Localization.txt gets pushed, but I could be wrong about that - it didn't used to, but someone told me it does now, can't remember who.) 2. You can add placeholders to the quest text in the Localization.txt file. Here's an example: Fetch / Clear ([DECEA3]{poi.distance} {poi.direction}[-]) The "[DECEA3]" part is a hex RGB color; the "[-]" part ends the color. For the placeholders inside curly braces, you can use "poi.direction", "poi.distance", or "poi.name". (There might be others, but those are the only ones TFP uses.) I don't know if you can do this outside of Localization.txt though (if you're putting your text directly in the quest XML). You could try it and see.

Well, it's hard to know what's wrong when you say "did`t get the desired result" and "the result isn`t what I expected" - but you never say what you expect, vs. what actually happens. As far as I can tell, from looking in the C# code, this is how it works (I'm using XPath syntax, hopefully that's easier to understand): trader_items[@count="all"] seems to be ignored. The count is determined by the min_inventory and max_inventory values in the trader_info tag. The game simply picks a random entry from trader_items until a random number between min_inventory and max_inventory is reached. The prob attributes are taken into account, where no prob attribute translates to a probability of 1. (That doesn't mean "guaranteed," it means it has an equal "weight" against other entries with a probability of 1.) trader_items/item[@count="X"] will spawn X items from the matching trader_item_group. Note that the trader_item_group must come before the trader_items in the XML file. I think that trader_item_group[@count="Y"] will determine how many items are spawned for each X in trader_items/item[@count="X"]. I think that trader_item_group/item[@count="Z"] will determine how many items are spawned for each Y in trader_item_group[@count="Y"]. Every item entry in trader_item_group has a random chance to spawn whenever an item from that group is spawned - meaning there could easily be duplicates depending on RNG. I could easily be wrong about this, but that's how I interpret the code. What are you seeing that you aren't expecting?

You are You are right, the change that Arramus suggested simply changes the model used by the existing quest satchel. It would change the appearance of all quest satchels used by all fetch and hidden cache quests. What you want is possible but not at all easy, and would require new POIs. Here's why. I guess you already looked at the block placeholders named "cntQuestRandomLootHelper" and "cntQuestNoPHRandomLootHelper". Those are the two block helpers used by POI designers. And as you can probably tell, what they do is choose the container to spawn according to quest tag. Those quest tags are specified by the POI's "QuestTags" property in its XML file, and quest tags are enumerated values. You can't use any values other than the ones already used by the game. That's why you're getting an exception about an invalid quest tag value - it's trying to parse your string as a C# enum value that doesn't exist. What this means is that if you try to add your custom quest satchel to those block placeholders, it would have to replace the one that's already being used by that quest tag - and it would be for all quests that use that quest tag, meaning all fetch quests. So it wouldn't be any better for you than Arramus' suggestion. In order to use a custom quest container, you'd have to create your own block placeholder, along with a matching block (with the different model). You would then have to create or alter POIs so they use that placeholder, rather than the vanilla ones, for their fetch quests. Of course, if this is multiplayer, then all clients would need their own copies of the POIs. And another catch is that your quest could only go to those POIs. The vanilla "RandomPOIGoto" objective does not allow you to do this. SphereII has a mod called SCore that offers an objective that will allow this (I wrote it ), but it requires custom C# coding, and chooses POIs by a tag value (from its A20 "Tags" property, not its "QuestTags" property - those tags are strings so you can have custom tags). All of this is a huge amount of work, and I don't know if it's worth it. You can already choose different items to fetch from the containers. (You may have figured this out, but they're defined in "quest_items" in quests.xml, and their "id" property is mapped to the objective's "quest_item_id" property.) That might be good enough for your purposes. Hope that puts you on the right track. (EDIT: Also, this should really be in the "Discussion and Requests" forum.)

It would be very interesting to modify the storm lightning so it has a chance to set stuff on fire (a la Icarus).

Just be aware that you modify the XML files at your own risk. Once you do that, it's nearly impossible to help you, because we don't know how your edits might have affected things. (Example: the entity_class tags in entityclasses.xml don't have an attribute called "id", so we can have no idea what you reordered, or why you believed order was important in the first place.) My advice? First make sure you covered all the basics: You verified the 7D2D game files through Steam. You installed the latest, unmodified versions of all modlets from these forums. (If you get them from 7daystodiemods or similar, they're often out of date.) After putting the modlets into the server's Mods directory, you restarted the server. (Or at least restarted the game's executable.) After restarting the server, you started a completely new game, you didn't continue an existing game. Prior to joining the server, all clients (your game and your friends' games) had the same modlets, and the same version of those modlets, installed locally to their Mods folders. If that all is true, and you find that the problem still persists, don't try to change anything. Instead use Pastebin to give us the logs from the dedicated server, and, if possible, the logs from the player that experienced the issue. You can find info on the output log directories, using Pastebin, and other useful tips in this post from TFP bug reporting team: