Pimp Dreams from Modders

khzmusik

khzmusik

Well-known member
Hey, all. I don't think there is already a thread for this, so I decided to start one.

I would like this thread to ask specifically for changes that make modding the game easier. These wouldn't be requests to add features to the game, so much as making it easier for modders to add features to the game.

Because of this, they can have a lot more technical detail than your average request. That means they're usually more targeted, and probably easier for TFP to implement (or reject if need be).

To make it easier for TFP, I think we should explain the use case, why the change makes the use case easier, and why the requested change is better than other options.

I'll start.

Add a common tag to the "ThemeTags" property in the XML of every trader prefab (like "trader", and not just "traderJoel" or "traderJen" or whatever)

  • What is the use case?  Not all users (including me) are fans of the "one trader per biome" feature added to 1.0, and would like to mod it out.
  • Why would this change make it easier? Since the trader POIs do not share the same "ThemeTag", without locking each trader to a biome, RWG will often place one right next to another. Most players do not want that.
  • Why is this better than other options? For TFP, the change is trivial to implement, and should be safe. But for modders, since it's not possible to use XPath on prefab XML (and asking for this would be way too complicated), the only option is to make this change and distribute the entire prefab data for all traders with their mod.


 
Although I'm not really a modder, having only made a couple of minor mods for myself, I would still like to add a suggestion that helps modders (or more specifically, tile designers and potentially overhaul modders who want to use special tile layouts) if that is close enough to the topic.

Suggestion

It would be helpful to have a tag for allowed connections to tiles for each side of a tile.  For example, a tile could have NorthTags, EastTags, SouthTags, WestTags.  Only tiles that have a matching tag can connect on that side of the tile.  Null or "any" would work the same as is currently being done.

Use Case

If you've ever driven down a long road in a town, you have likely noticed that the roads will alternate often between 2-lane roads, 4-lane roads, and even divided roads (boulevards) without much rhyme or reason.  This is because all types of roads can connect to one another.  The vanilla tiles attempt to have transitions at each edge so it doesn't matter what kind of road it connects to, but these often look really odd because they are very short transitions that are intended to work no matter which road type it is being connected to.

An example of using this suggestion would be to design a set of boulevard tiles.  These tiles are tagged to only connect to other tiles that have a boulevard tag on the side that is being connected.  You would also need a set of transition tiles that have boulevard as the tag on the boulevard end of the transition and something like 2lane or 4lane on the other road exit(s), depending what type of road exits the tiles in other directions.

The result would be that you can have a full set of boulevard tiles without needing to have an edge transition that might connect to another boulevard or to a 2-lane road or to a 4-lane road and hope it looks okay in all cases.  You would instead have something like this for a straight road:

Tile 1: Straight tile with 2-lane road at both edges.

Tile 2: Straight transition tile with 2-lane road on one edge and boulevard on the other edge.

Tile 3: Straight tile with boulevard at both edges.

Tile 4: Straight transition tile with boulevard on one edge and 2-lane road on the other edge.

Tile 5: Straight tile with 2-lane road at both edges.

That's just a very basic 5-tile example, but it could include other tile types (T, intersection, corner, cap) and the middle section (Tile 3) could have any number of boulevard-only tiles, including a mix of different tile types.  You could even have an intersection with a boulevard going East to West and a 2-lane road going North to South or other combinations.

By having actual transition tiles, you wouldn't have to worry about what the boulevard connects to, because it will always connect to a boulevard and the transition tile will do the change from boulevard to 2-lane or 4-lane.

Note that for tile edges without roads, the tag would be either null or empty, allowing for any tiles to connect to that side.  The tiles would of course still follow normal connection rules so you don't get a road edge going to a non-road edge.  It would just mean there isn't any restriction to what other tiles can be connected on that side.

Alternate Uses

There are a variety of different types of roads or other things you could use this with, including raised/elevated roads, train tracks, tile-based rivers or lakes, bridges that take up more than one tile, subways, tunnels, and more.  The boulevard example is just one possible use.  This also works for just a simple 2-lane to 4-lane road or one-way roads.  A one-way road could use tags such as OneWayEnter and OneWayExit to make sure the road is facing the right way.  That isn't necessary if the road doesn't have something like a yellow line on one side to designate the direction or arrows on the road to designate the direction, but if you had those on the road, the tags would help.

How is this easier or better than what we have now?

Right now, all road exits can connect to all other road exits without regard to the type of road.  This means that you need a transition at the edge of a tile to handle any possible change in road type, but that can look wrong because the tile designer has no way to know if the tile being connected to will be the same road type or a different road type and no way to know which different road type it will be.  There is currently no way to control this in RWG, which means you have to either manually places your tiles or change the tiles that RWG places.  This is very time consuming and basically makes it so you aren't likely to have anyone designing tiles that aren't basic 2-lane or 4-lane roads, greatly limiting the interesting options you could have for towns.

Other Notes

If this is added, a tile designer would need to create at least one full set of tiles for the road type or whatever else they might be making (train track, rivers, etc), including straight, T, intersection, corner, and cap.  Ideally, they'd make more than one set, but one full set would be necessary.  If they want the road type to be in multiple districts, they'd also need at least one full set of tiles for every district they want the road type to appear in.  In addition, they'd need to have a minimum of one transition tile for each district so that even if the road type is only intended to be in one district, there will be a transition into any other district that RWG connects it to.  It may be necessary to include all tile types in the transition tile (the cap type wouldn't really be a transition, but it would allow the road type to end if connected to another district and RWG wants to place a cap there).  So this does mean that anyone interested in doing something special like this would need to make a lot of additional tiles.  But it would make for some very interesting towns and there are probably some people who would be interested in making something like that.  Unfortunately, the way it is now, there isn't much reason to do so because you'd have to manually place each tile since RWG doesn't control what tiles connect to what other tiles based on road type.

Also note that this would benefit vanilla tiles as well by removing the problem with transitions, though it would mean vanilla would also need to include full sets of tiles for 4-lane and boulevards (I think 2-lane already has a full set), as well as transition tiles.

Clarification

  • I am using "tile types" to indicate T, corner, intersection, straight and cap.  Those are often referred to as road type, but to avoid confusion with the kind of road, I'm using tile type here.
  • I am using "road types" to indicate 2-lane, 4-lane, one way, boulevard, raised/elevated road, etc.
  • Hopefully I didn't mix those up anywhere. ;)
 
Last edited by a moderator:
Oh I would LOVE to see actual boulevards in towns again, like we used to have before the tile system.

Don't get me wrong, the total lack of street furniture, curbs etc. was worse, but spaghetti roads is definitely an unwanted consequence of the change.

 
I remembered another one.

Use interfaces, not concrete classes, for all functional type checks in the C# code

  • What is the use case?  There are a lot, but for me, it involves entities that can have dialogs, and entities that can be spawned into hordes (wandering hordes, blood moon hordes, etc.). It should be possible to enter into dialogs with non-trader entities, and also have these entities spawn into hordes. For example, a horde of the Duke's men, that you have to interact with to give them money or they will try to kill you. This is currently impossible, because these features require that the custom entity class descends from a concrete class (EntityTrader and EntityEnemy respectively). But these are only my examples, I'm sure other modders have many more.
  • Why would this change make it easier? If the code does a type check for an interface, then modders could create a concrete class that implements this interface but is not limited to the methods in that interface. An example would be spawning into a horde: if the spawner merely requires that a class implements (say) an IHordeEntity interface, then it doesn't matter what else it does - it could be a companion which gives quests, or be a non-enemy animal, or whatever. Another example would be an enemy (like an EntityEnemy) that can be interacted with as a trader - provided certain conditions are met (like your relationship with their faction is good enough). There are probably hundreds of other uses that I can't even imagine.
  • Why is this better than other options? First, this has been part of SOLID design principles since the '90s (at least), so it's a good programming practice regardless of use cases. But more importantly, there are no other options. There is no way to do any of the things in the use cases without this feature. These sorts of type checks are beyond the reach even of Harmony patches, so modders have literally no options.
 
Last edited by a moderator:
I don't know how I missed this post, I like the idea you present. Many of the requests that I make follow this same idea. I realized

that making a request to change parameters, just for a single person's preference will most likely get over looked by the devs,

so I try to evaluate whether it benefits all, or I just mod it for myself.

 
One more

The credits screen should be moddable to include credits and/or contact info

  • What is the use case?  Many modders use other creators' work (with permission), like purchased Unity models. Most of that work requires credit of some kind (at the very least). This would allow those creators to get properly credited in a way that is visible to end users. Even if modders don't use other creators' work, this would allow the modders themselves to get credit, and to possibly include contact information for the mod (for bug reports and such).
  • Why would this change make it easier? The credits would all be in one place, and would be available in-game.
  • Why is this better than other options? The other options available to modders aren't user-facing or available in game: README files, comments in the XML code, whatever.
 
khzmusik said:
One more

The credits screen should be moddable to include credits and/or contact info

  • What is the use case?  Many modders use other creators' work (with permission), like purchased Unity models. Most of that work requires credit of some kind (at the very least). This would allow those creators to get properly credited in a way that is visible to end users. Even if modders don't use other creators' work, this would allow the modders themselves to get credit, and to possibly include contact information for the mod (for bug reports and such).
  • Why would this change make it easier? The credits would all be in one place, and would be available in-game.
  • Why is this better than other options? The other options available to modders aren't user-facing or available in game: README files, comments in the XML code, whatever.
Click to expand...
Although I support this, I think people are more likely to see the credits in the readme file.  I doubt many people ever look at the credits in the game.  I know I haven't for this game, or for most.  Since I don't know the people beyond those who are visible (Joel and Rick, and those who post here), seeing their names really doesn't tell me anything worth knowing.  And for those who are visible, I already know them.  For mods, it's more useful, but people using mods are more likely (I believe) to look at any readme/instructions for how to use the mod than they are to look at a credits screen in the game.  I could be wrong, of course.  In either case, like I said, I support this regardless of how likely it will be that anyone would even see it.

 
khzmusik said:
The credits screen should be moddable to include credits and/or contact info
Click to expand...


I don't disagree, though I would point out you can have a Hints or Tips page that is in the rotation as the game loads. It might not offer enough room for extended credits, but you could have more than one. It isn't a perfect hit for what you're suggestion, but an option.

 
It would be very helpful if all the XML documents had descriptions of what things mean. 

For instance, in the entitygroups XML what's the difference between ZombiesWastelandNight and ZombiesWastelandNight2? 

wanderingHordeStage vs FwanderingHordeStage?

sleeperHordeStage?

badassHordeStage?

Also, official support.

I have a zombies mod pack that is pretty popular. They've ended up featured on 2 of the biggest 7 Days YouTube channels. They have this frustrating problem where they attack with no animation when they get knocked down. They'll hit you if you're close enough or you'll hear then hit a nearby object or you'll see grass just fly up in the air if they get knocked down in a grassy area. 

Nobody in the modding community has an answer for this. It would be great if once all avenues get exhausted in the modding community issues could be brought up to QA. I don't think this would add a lot of extra work for the staff because I don't think there are a lot of mods being released all the time and usually most issues can be solved with the help of the modding community. These would be edge cases. 

 
Riamus said:
Although I support this, I think people are more likely to see the credits in the readme file.  I doubt many people ever look at the credits in the game.  I know I haven't for this game, or for most.
Click to expand...


The credits screen was introduced in 1.0 so I don't know how much of that is just us old players being used to the way things worked before. In any case, I am mostly worried about what third parties think is appropriate, and they seem to want credit in the same way that the game gives credit to everyone else.

Having said that, I know from experience that 90% of end users don't look at the README either, because if they did they would know how to use the mods. :)  

zztong said:
I don't disagree, though I would point out you can have a Hints or Tips page that is in the rotation as the game loads. It might not offer enough room for extended credits, but you could have more than one. It isn't a perfect hit for what you're suggestion, but an option.
Click to expand...


I didn't even think about adding credits to the loading screen tips. It's not a bad idea. I'm not sure how end users would react to that, but at the very least, it could be a stopgap until (or unless) TFP give us a better solution.

...In any case, I have another suggestion:

Add bitwise operations to cvar (or other) requirements

  • What is the use case?  An example would be a read-only cvar (set by the vanilla game) indicating which limbs on an entity were currently dismembered. Each limb would be one bit flag in the cvar value: 0=none, 1=left hand, 2=right hand, 4=left shoulder, 8=right shoulder, etc. To see if e.g. the right hand is dismembered, just do a bitwise AND operation with the value 2. As an example of how this would be used, maybe a mod adds damage reduction if a zombie loses one of their hands, but it wouldn't be affected if they lose one of their legs.
  • Why would this change make it easier? Both TFP and modders could use a single cvar (or other) value to represent multiple different Boolean flags.
  • Why is this better than other options? The other options require multiple different cvar (or other) values, even though the value can only be "on" or "off".



EDIT: If anyone is curious, setting or clearing these bits is pretty easy if you have an AND operation. To set a bit in (say) the 3rd position from the right: add 4 (0100), but only if the number AND 4 is zero (so x0xxx). To clear that same bit: subtract 4, bit, but only if the number AND 4 is not zero 0 (so x1xxx). Pretty easy for modders to use for their own flag cvars.

 
Last edited by a moderator:
khzmusik said:
Add a common tag to the "ThemeTags" property in the XML of every trader prefab (like "trader", and not just "traderJoel" or "traderJen" or whatever)

  • What is the use case?  Not all users (including me) are fans of the "one trader per biome" feature added to 1.0, and would like to mod it out.
  • Why would this change make it easier? Since the trader POIs do not share the same "ThemeTag", without locking each trader to a biome, RWG will often place one right next to another. Most players do not want that.
  • Why is this better than other options? For TFP, the change is trivial to implement, and should be safe. But for modders, since it's not possible to use XPath on prefab XML (and asking for this would be way too complicated), the only option is to make this change and distribute the entire prefab data for all traders with their mod.
Click to expand...
technically you could home the trader xml in your mod/localprefabs folder and it over write the vanilla trader xml. 

you can also make your own themetags and the themetag traderjen, trader joel is purely so another trader of the same does not spawn nearer it not that it stop traders spawning in a different biome. 

The traders biome control is in the rwgmixer tho and again a mod could contain within it the changes. 

 
stallionsden said:
technically you could home the trader xml in your mod/localprefabs folder and it over write the vanilla trader xml. 

you can also make your own themetags and the themetag traderjen, trader joel is purely so another trader of the same does not spawn nearer it not that it stop traders spawning in a different biome. 

The traders biome control is in the rwgmixer tho and again a mod could contain within it the changes. 
Click to expand...


Having to distribute modified prefabs is exactly what I'd like to avoid.

Also, the "ThemeTags" property already has one tag per trader, so the same kinds of traders don't spawn near each other. That's not the problem. The problem is that if traders aren't locked to biomes, different traders will spawn next to each other. (So a Trader Jen will spawn right next to a Trader Rekt.) That's what needs to be avoided, and it can easily be avoided by just making a non-specific trader tag and adding it to the prefab XML.

AFAIK, that's not something that can be solved in rwgmixer.xml. If it can be solved by modifying that file, then please let me know, so that I can incorporate it in my mod that allows traders to spawn into any biome. Right now my mod has to include the modified prefabs, and that's just confusing to everyone who uses it.

 
khzmusik said:
Having to distribute modified prefabs is exactly what I'd like to avoid.

Also, the "ThemeTags" property already has one tag per trader, so the same kinds of traders don't spawn near each other. That's not the problem. The problem is that if traders aren't locked to biomes, different traders will spawn next to each other. (So a Trader Jen will spawn right next to a Trader Rekt.) That's what needs to be avoided, and it can easily be avoided by just making a non-specific trader tag and adding it to the prefab XML.

AFAIK, that's not something that can be solved in rwgmixer.xml. If it can be solved by modifying that file, then please let me know, so that I can incorporate it in my mod that allows traders to spawn into any biome. Right now my mod has to include the modified prefabs, and that's just confusing to everyone who uses it.
Click to expand...
<prefab_spawn_adjust partial_name="trader_rekt" biomeTags="forest" bias="20" min_count="2" max_count="4"/>
    <prefab_spawn_adjust partial_name="trader_jen" biomeTags="burntforest" bias="20" min_count="2" max_count="4"/>
    <prefab_spawn_adjust partial_name="trader_bob" biomeTags="desert" bias="20" min_count="2" max_count="4"/>
    <prefab_spawn_adjust partial_name="trader_hugh" biomeTags="snow" bias="20" min_count="2" max_count="4"/>
    <prefab_spawn_adjust partial_name="trader_joel" biomeTags="wasteland" bias="20" min_count="2" max_count="4"/>

in the rwgmixer

 
UPDATE - while it is not possible to do this just with XPath, you can distribute the prefab changes to the "ThemeTags" property, by only distributing the prefab's XML files (and not the other files, like the .ins or .mesh files).

Even so, this doesn't change the root problems, which are a) end users will think the mod is not server-side, because it has files that are outside the "Config" directory, and b) it's a PITA for modders but could be solved by TFP in two seconds with no risk.

So I stand by my ask. :)

UPDATE 2: I'm talking about making traders not spawn next to each other. With the original update that wasn't clear. Sorry!

 
Last edited by a moderator:
Speaking with Stallion's Den (who, if you don't know, is pretty much the new god of POIs) reminded me of an ask that I think would be awesome for prefabbers.

Add a prefab block that will act as a player spawn block

  • What is the use case?  Most zombie games start players in a "safe house" where they are introduced to the story and can gather equipment or other things. Think Left 4 Dead. Or consider the first episode of The Walking Dead - Rick wakes up in an overrun hospital. Modders could use the prefab location to show users what they have to do to survive (and not rely on the quest or challenge system).
  • Why would this change make it easier? Right now the game only puts spawn positions on side roads next to houses in the pine forest. It is hard coded. There is no way for modders to specify spawn positions other than manually editing the world.
  • Why is this better than other options? If players use worlds that are not provided by modders (RWG or TFP provided worlds, which nearly all players use), there are no other options.
 
Last edited by a moderator:
khzmusik said:
Speaking with Stallion's Den (who, if you don't know, is pretty much the new god of POIs) reminded me of an ask that I think would be awesome for prefabbers.

Add a prefab block that will act as a player spawn block

  • What is the use case?  Most zombie games start players in a "safe house" where they are introduced to the story and can gather equipment or other things. Think Left 4 Dead. Or consider the first episode of The Walking Dead - Rick wakes up in an overrun hospital. Modders could use the prefab location to show users what they have to do to survive (and not rely on the quest or challenge system).
  • Why would this change make it easier? Right now the game only puts spawn positions on side roads next to houses in the pine forest. It is hard coded. There is no way for modders to specify spawn positions other than manually editing the world.
  • Why is this better than other options? If players use worlds that are not provided by modders (RWG or TFP provided worlds, which nearly all players use), there are no other options.
Click to expand...
Really like this idea and agree. start em in a house that is easy then when they get outside they are somewhat learnt a few things  as well like the starter quests but it is done inside the poi. Great idea

 
Strictly for modding purposes, there is one class that does not
have a designation "fromxml class". "SkyManager"

Can TFP export it from code as an xml. The parameters it would
help with are TriggeredLightning true\false or on\off option. Realtime QOL safety
for photosensitive users. I'm sure further digging can find more. Maybe next time.

Skycolor presently is "text name" would be more flexible as   "0, 0, 0".
FogColor override "0, 0, 0" for environmental customization. 3 lod levels
of fog, near distance to medium distance to far distance. Artificially creates volume.

Parameters could be distance in meters color, and intensity. The possible benefit is

that distant and unseen assets can be occluded, parallaxed, and or extremely simplified

in lod perspective. Fog variable change rate. Moonlight color mainly aesthetic, but with

a variable intensity added, it can set a feeling. SunColor follows the same idea. sun and

moon variable intensity over time. CloudBlendTex including to make the visual changes

more intense.

Personal question; If there are 496 soundbytes for ambiance divided by 3 variations
is 165, then why are they set to static vs random? I have only heard about 12 ever.

Some of them are "DAW gone good", get it Digital Audio Workstation. but i've never
get to hear them.

 
Thought of one more. I'm betting TFP have thought about it but I want to make sure that they know it is something folks want.

Push images/icons to clients from servers

  • What is the use case?  Many mods do not involve custom C# or Unity packages, but only custom icons (for items or otherwise). Right now any mod with custom icons is not "server-side" so requires clients to manually install those mods, even though they are EAC safe.
  • Why would this change make it easier? There is currently no other way to implement this feature. Also, since image files (nowadays) are not very bandwidth-heavy, images should not delay the joining of servers by a significant amount.
  • Why is this better than other options? There is currently no other option.

Note that I am not asking for executable files (C# .dll files) to be pushed to clients, nor am I asking for anything to be pushed to clients that would violate EAC.

Obviously it would be nice if us C# devs could write server-side safe mods, but that is immensely more complicated, and it is not what I am requesting.

 
Last edited by a moderator:
khzmusik said:
Push images/icons to clients from servers
Click to expand...


There seem to be some POI details that don't get pushed if they are found in a modlet: Localization, Triggers, and Imposters if my memory serves me or there wasn't a recent change. I assume Localization and Triggers should be manageable, but Imposters could be larger.

Maybe it is the case Localization is shared, but something seems to keep it from being used if the POI is installed locally. Maybe the game doesn't have the filename of the POI to associate with the Localization?

Since you look at code (I very rarely do), I wonder if I'm running on correct information here.

 
Last edited by a moderator:
This is a modder's dream from way in the future. Actually just before the last release.

The request is for the original textures, that are used to build the Texture2dArrays
to be posted in either a game folder, or the data.unity3d Bundle file. Along with them,
if this is done, please acknowledge it in the xml.txt, or forum post. Instead of leaving
it as a hidden Easter egg, to be found or not to be found. Textures referred to, Building Blocks,
Terrain Texture, Decorative Paint textures, etc. that resided prior as individuals and or in the
atlases.

Presently they are built as the default unity project is built, not at runtime. Texture2darrays
cover the majority of the associated textures that could be customized by modders to visually adjust
the environment.

Since it is a scripted build, can an additional routine be added, and a menu on/off option, that
a person choosing to mod textures can set to yes. This option would cause the script to build the
internal Texture2darrays associated with either the external, or internal folder reference and
the included images, that are left with the same naming convention. After completion, the option
could be checked to NO. This would allow a person choosing to change a texture to have it build for
them upon a single loadup. This way only they  meaning the modder, as they have set the import
build routine to yes  would have a longer loading time. It would never affect the load times of a
user of the mod. They could then go into the came to check and find what works or needs to be

adjusted, rinse repeat. Once complete, the data.unity3d can be posted using the present format

as an overhaul world decorative mod.

I understand and have experienced the benefit, of the texture2darrays, vs the atlas format. I was
also an advocate for it. I had hoped that the ability to edit the textures would be left, and that
an import from specific folder or atlas would be added.

The reason for post dating the request to the distant future, is because the the hd textures would
directly add to the overall download size of the game.

It is not a request for an addition, but a re-inclusion. So that the environment, which is a large part

of the game setting, can be transformed and custom visualized worlds can continue for new generations.

Thank You for your consideration.

 
You must log in or register to reply here.
Back
Top