kanaverum

So I’m seeing a rough pattern forming in many of these replies: 1. I don’t like it 2. Actually, I do like 99% of it - I just think it might make someone else uncomfortable 3. I’m not a prude, I’m even down for nude [ I’m paraphrasing ] I think it’s ok for us to relax some and assume positive intent. Nobody (including TFP, imho) genuinely think 7 Days to Die should become: “hot mamas go in there blasting but find the only way to stop zombies is with a firm smack from their 4-gallon jugs: the game”. After all, that’s what modders are for (kidding) On a more serious note, the desired result from everyone is for more people to embrace and enjoy 7 Days to Die and for that to be an engaging, rewarding experience. That said, I think we also need to be aware that TFP ultimately shoulder the vast majority of the risk when making creative decisions. It’s important for us to understand that no one wants 7 Days to succeed more than TFP.

Ah, I interpreted what you posted as 2 separate topics (like a list of things you were pointing out about the model): - she'd look even sexier if her chest were a bit more natural - and the flesh was relaxed a bit so that they don't look like two balloons about to pop "more natural" has often been used in conversations about 'women in video games' to suggest "boobs aren't that big irl" (when in real life, some are much larger and completely natural). I can't speak for anyone else, but will say this is a key point where I misunderstood you. Taking what you were saying originally as being 1 single concept about the model, I understand you're suggesting a "natural" [naturally] sitting in the top - as in, referring to physics/weight/etc. Thanks for the added clarification [on the dev stream topic] For the dev stream, I recall them saying (on stream) that the female underwear model was excluded from the stream because presenting it would send the wrong message; maybe the exact words were "would cause too much trouble", but I can't recall perfectly. So it does seem, to me, that they are at least making an attempt to be mindful of their female audience. I would've loved to see more female outfits as well... though I think we'd be equally surprised if TFP present cold-weather gear for the female rig that amounts to little more than a fur-clad bikini lol

Sometimes conversations like this can feel exhausting for people because just about everywhere you look, people are getting outraged about "everything" when it's really unnecessary to do so. You seem to be bringing this up with an open mind rather than blind rage and I appreciate that about your post. And because you seem to have an open mind, I think you might also appreciate another perspective. This is a pretty personal subject for me; I'm bringing it up only because this topic seems to be glossed over in popular culture fairly often. Everyone has a right to be critical of anything they find to be concerning; this is America and we have the freedom of speech - I think that's a good thing. That said, being critical of certain things can also send an unintended message. I personally know many women with fit bodies and/or larger chest sizes (no plastic surgery) who have been criticized unnecessarily through part of their lives (nearly always by other women... which I don't fully understand; the guys I know don't treat each other that way). My own wife fits into this category. <-- the personal part So when others are critical of in-game character art that looks similar to their own bodies, I think that sends the wrong message to people like my wife. Just more bullying or attempted erasure of their own image in media. Isn't fair representation of all people part of the goal here? I think it is... so why are images in media that actually do reflect the body dimensions of some women constantly being attacked? (not by you, necessarily; I'm speaking generally here) When I look at that new female character art slated for A22, I can think of multiple women I know in real life who look roughly the same, dress similarly (for hikes or when generally acceptable to do so - mostly in hot weather), and they have even larger bust sizes than the character art depicts. It doesn't seem fair to me for others to look at this A22 female character art and suggest something that basically amounts to: "real women don't look like that". I promise you, there are real women who do. And while I haven't been able to confirm 100%, community members have informed me that Trader Jen's model is based off of the artist's wife. I'm informed that TFP were given no end of grief for the way Trader Jen looked and all I could think when I heard about this was "I wonder how it made the dev's wife feel."

One of my greatest joys lately is refreshing this main post each day to see newly added items. I share each of them with my community as I notice changes and everyone is pretty hyped! Really love the trend of features leaning into more of the survival aspects of a zombie apocalypse and have tried to focus on modding efforts that go along with this. A21 is shaping up to be an incredible experience!!

"...it exist if you play in small group (4-8) too?" Yes, every issue Zipcore posted at the top of this page has been reported to happen even in multiplayer with as few as 2 people. [edit; grammar] I think everyone here believes that TFP will continue to do the best they can and try to deliver a great gaming experience. But I also think that it helps to provide feedback. This is what everyone is trying to do in their own way. I see that you're attempting to explain that TFP are going to work at it. I also expect that TFP will work at improving the experience. Since this thread is focused on 4 key issues with the multiplayer experience and you have already explained you lack knowledge on managing an open server for 7 Days to Die or playing 7 Days to Die with others, I can only assume that you're here to learn more about the experience? Allow me to reset expectations a little and offer some clarifying information to help provide the extra context that seems to be missing: I have personally experienced most of the issues Zipcore posted with as few as 2 players. And yes, that map never had more than 2 players play on it at any time, ever. From the beginning, TFP described their ideal game as "Walking Dead + Minecraft with your friends". Multiplayer has always been a central part of the experience and represents the ultimate target of the game. The only issue I haven't personally encountered yet is the floating/base-destroying tree. I am aware of other admins/servers/communities struggling with this bug, though. While TFP officially support single player and peer-to-peer 'friendly co-op' multiplayer, they do also officially support dedicated servers. In fact, they deploy a dedicated server build with every release to Steam and this is what we use to host these games. It's entirely understandable that someone who only plays single player would not be aware of this, but now you know. TFP actually support up to 16 since A20's release. You can click to start a new game right now in A20 and see this for yourself: 8 players remains the default, but you can click the right arrow (since A20) and select 16 players as an officially supported option for peer-to-peer games. So if you decide to play multiplayer one day, you can invite 15 of your friends (or maybe even more, if 7DTD supports more by then). Sure, 7 Days to Die will never become Rust with 300 players per server and that's ok. We want 7 Days to Die to be 7 Days to Die. No software or game will ever be perfect. TFP were very kind to support official streams of modding. So as modders and sever admins, we spend a fair amount of our free time fixing bugs to help support the intended experiences that TFP were going for and sharing those fixes/mods with others. They didn't ask us to do this. We just started doing it on our own because we love 7 Days to Die. Zipcore has released dozens of multiplayer fixes and has helped a lot of admins and players out as a result. The issues Zipcore posted are the kinds of issues that cannot be modded or fixed with modding. TFP are smart people, but nobody can know all things at all times. They ask for our feedback and this post is one way that the community seeks to provide feedback. Yeah, it seems a little hostile. But I hope you can appreciate that it's coming from a good place: from a love for 7 Days to Die and the desire for it to remain as one of the best zombie survival multiplayer experiences. Anyhow, hopefully this helps to provide a foundation for what and why we're discussing in this thread.

But does anyone know of a way to pass/copy a CVAR value from one entity to another? More context and tests/results below: I have a CVAR on my player and I want to set the value of this same CVAR on another entity so that once the trigger completes, both entities have the same CVAR with the same Value (i.e. a copy). Test 1: In this example, I'm using this block with the Trader to make things simple (won't need other humans for this testing). At this point, my player cvar was at 5 and trader was at 2. <buff name="setTraderFromSelf"> <duration value="1" /> <effect_group> <triggered_effect trigger="onSelfBuffStart" action="ModifyCVar" cvar="testVar" operation="set" value="@testVar" target="selfAOE" target_tags="npc" range="10" /> <!-- show player current value --> <triggered_effect trigger="onSelfBuffStart" action="LogMessage" message="PlayerCVAR" /> <triggered_effect trigger="onSelfBuffStart" action="CVarLogValue" cvar="testVar" /> <!-- show trader current value --> <triggered_effect trigger="onSelfBuffStart" action="LogMessage" message="TraderCVAR" /> <triggered_effect trigger="onSelfBuffStart" action="CVarLogValue" cvar="testVar" target="selfAOE" target_tags="npc" range="4000" /> </effect_group> </buff> Outcome 1: Unfortunately, this didn't result in any change to the trader's CVAR (bummer). Test 2: So I tried another approach to confirm a hunch <buff name="addTraderFromSelf"> <duration value="1" /> <effect_group> <triggered_effect trigger="onSelfBuffStart" action="ModifyCVar" cvar="testVar" operation="add" value="@testVar" target="selfAOE" target_tags="npc" range="10" /> <!-- show player current value --> <triggered_effect trigger="onSelfBuffStart" action="LogMessage" message="PlayerCVAR" /> <triggered_effect trigger="onSelfBuffStart" action="CVarLogValue" cvar="testVar" /> <!-- show trader current value --> <triggered_effect trigger="onSelfBuffStart" action="LogMessage" message="TraderCVAR" /> <triggered_effect trigger="onSelfBuffStart" action="CVarLogValue" cvar="testVar" target="selfAOE" target_tags="npc" range="4000" /> </effect_group> </buff> Outcome 2: This results in the trader's own "testVar" cvar doubling - which makes sense, it turns out: the value reference of "@test" isn't *my* value - it's the trader's. So this would lead me to believe that any value reference to a CVAR is going to refer to the target only and there might not be any way for a value to be copied/passed in by another entity. Test 3: I've also tried using requirements to see if I can at least confirm if a value is out of sync and then sync it up with onSelfBuffUpdate. I rushed this example, so it might just be incorrectly written.. <buff name="syncWithTrader" icon="ui_game_symbol_players" icon_color="0, 128, 255"> <effect_group> <requirement name="CVarCompare" cvar="testVar" operation="LT" value="@testVar" target="other"></requirement> <triggered_effect trigger="onSelfBuffUpdate" action="ModifyCVar" cvar="testVar" operation="add" value="1" target="selfAOE" target_tags="npc" range="10"/> <triggered_effect trigger="onSelfBuffUpdate" action="LogMessage" message="cvar is low" /> </effect_group> <effect_group> <requirement name="CVarCompare" cvar="testVar" operation="GT" value="@testVar" target="other"></requirement> <triggered_effect trigger="onSelfBuffUpdate" action="ModifyCVar" cvar="testVar" operation="subtract" value="1" target="selfAOE" target_tags="npc" range="10"/> <triggered_effect trigger="onSelfBuffUpdate" action="LogMessage" message="cvar is high" /> </effect_group> <effect_group> <requirement name="CVarCompare" cvar="testVar" operation="equals" value="@testVar" target="other"></requirement> <triggered_effect trigger="onSelfBuffUpdate" action="LogMessage" message="cvars are synced" /> <triggered_effect trigger="onSelfBuffUpdate" action="RemoveBuff" buff="syncWithTrader" /> </effect_group> </buff> Outcome 3: this hasn't worked either, I'm sorry to say

For now, we created buffs as 'admin triggers' that simply change state of a global cvar (one to enable and another to disable). The downside is that this has to target a player who's currently logged in, which we should be able to do with server-side scripting and parsing the output of the admin `listplayers` (lp) command. Not having to do this extra step would be awesome, but this is our current path forward if there really is no other way to impact cvar without requiring the admin to log in.

Working on some mods lately -really starting to dig into cvars and feel kind of dumb for not noticing them before. I had this expectation that I'd be able to read/adjust cvars with admin commands (turn on a flag for an event, etc.), but... am I blind, or are there no admin commands for making these kinds of adjustments?