Jump to content

Haidrgna

Members
  • Content Count

    738
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by Haidrgna


  1. Yeah we'll see. I do want to make generic mud and blood covered walking dead like zombies for the hordes. Special ones you never see, and leave the distinguished ones out of horde night. I always felt it was immersion breaking to see cheerleaders and football players in hordes just for the sake of variety. In the walking dead no one zombie stands out, they are all kind of the same and that is how I want our hordes to be. We could save memory and performance doing this as we could instantiate more of the same model.

     

    Not like this reference, but only in the sense that no one zombie stands out much different than the others:

    https://www.marxist.com/images/cache/53f8976f87b65dc011f5deee844b6eb1_w700_h561.jpg

     

    At a minimum maybe we will just cover the existing zeds in more dirt and blood and desaturate their clothing further. But I'd rather make some special blood moon zeds for this, like these are the crazy ones that only come out once a week on blood moons, and that explains their ability to know where players are.

     

    Yeah something like that could work, a similar way to how Left 4 Dead did it where horde zombies where just more grey and hardly stood out, while the special infected did have a specific appearance to stand out, and gaining a performance boost, more zombies on the field as a bonus.


  2. It would require a UI change to make it clear, especially if you want to be able to specify how many of which alternate items you want to use in a recipe. For the vanilla game, there are only a couple of places where it would really help - like glue for instance. Right now, we can only make glue with murky water. We could have a second recipe to make glue with clean water but then there are two "identical" recipes in the list and you have to make sure you get the right one. It's not a big deal but it would be a nice QoL improvement as well as giving the game a bit of polish.

     

    Where it would really change the game is in modders' hands because new items and recipes are a huge part of what modders bring to the table. Creating a more powerful framework for them to work with would open up a lot of possibilities for mods.

     

    All it would really take is having a description key added for a recipe, rather than always using the output material as name. Even better if an alternative icon could be set, or overlay for the icon. But this probably is not in scope at all, though not sure what will happen with the icon overhaul they are doing.


  3. It doesn't make sense for zombies, they don't need to wear armor, or seeing armored Arlene would be jarring.

     

    It would indeed not make sense if it would just be armor, but you said yourself it is also heads and other pieces. Armor is clothing, a dress is clothing. If you already are making a system to randomize parts of bandits then it would be a waste to not extend this functionality to zombies at some stage of development. I get it will not come to A18 or even A19, but can could you at least consider the fact that the game will be become so much more awesome if zombies are not the same or even worse where you enter a house and it is almost all the same zombie?

     

    Even if you do not use this new system, the game already has a system to replace materials of entities on spawning (used now for the radiated skins of zombies). We modders use that system to add variety to the zombie skins, so could you. Having access to the source material it would be really easy to make a dozen per zombie and have the game select one at random.

     

    I know it is not in scope for A18, I just hope that this aspect of the game at least comes in scope at some stage.


  4. Thank goodness! From there it should be a hop, skip, and a jump to what I've always wanted: procedurally building what the zombies look like, at least in terms of clothes and texturing. I really hope you'll try to use this upcoming tech on the zombies, since they're the most numerous characters in the game and you've said they'll always be the number one antagonists.

     

    I agree, just a few tints on the zombie skins already do wonders.

     

    6D9ED50BEB40F1E56A059625E547E16B4F0F1AD6

    This includes some skins made by Mumpfy and some tinted by myself, but it is al the same (Arlene) zombie.


  5. They already are AFAIK.

     

    @Madmole They are up until gamestage 50, then it loops back to 1.

     

    And when on the subject, maybe Scout (screamer) and Biome spawns could also move to gamestages. Those are the only thing in the spawning.xml that still does a thing. I was hoping A17 would streamline all spawns into the gamestages.xml file. Maybe A18 this could be a thing?


  6. Ah yes had forgotten about that. Well, additionally, for any sum of money to matter, economy must be no less perfect/robust in my experience. So at the time I thought: "ah just another zero-cost way to avoid the horde besides vehicles and the underground". I haven't used the traders lately, after MM allegedly balanced them, so I wouldn't know if this is the case at the moment.

     

     

     

    You are correct, in fact I found a thread of mine complaining about this back in 2016 >.< https://7daystodie.com/forums/showthread.php?53718-Zombies-reward-too-much-xp

     

    As far as I can remember (and going back into my modding history till 13.8) zombies have always awarded xp for being killed by the player. But also since then and before, crafting and/or action xp, especially crafting, overshadowed kill xp greatly. A17 is probably one of the first where kill xp greatly overshadows crafting xp and only harvesting xp at some stage becomes just as great.


  7. Heh. I'm there part time (I have a real job, too. =) and I'm not complaining.

    It's certainly interesting because "design, technical design, game data and balancing" has me all over the place.

    100+ book perks + the research / technical design to be able to task programmers with the required code to make it possible to do all the effects can be a daunting task until you break it down into manageable parts and a workflow.

    If it was easy everyone would do it, right? ;)

     

    There are mathy parts like this that some people find off-putting but you need something like that or it would have been impossible to do any gamestaged spawns. Pre-generating this keeps the actual spawning code "simple" (there are plenty of gotchas as is) and separates the game data from the code so it can be changed (or modded) easily.

     

    You should ask the coders if maybe the entitygroups.xml groups can work the same way as loot.xml or the rwgmixer.xml. Will save you a ton of mathy stuff and a ton of xml code if groups can list other groups so code does not need to be replicated. And while you are at it, maybe ask for the possibilty of an emtpy list so we can get rid of the dummy spawns as well. :)


  8. Isn't the entire library of what we paint with available to users? That is a crap load of textures.

     

    Sadly its not, I even found at least one paint (on the Navezgane road bridges, the asphalt) that you can copy with the (dev)paint tool but not select from the paint selections.

     

    At least we have a lot of paints at our disposal and its great, but it could be better if indeed all of them where on the list.


  9. Yeh I agree.

     

    Who the hell knows how to make a acid bomb lol. Grab a bit of metal stick it in a key hole that seems far more fitting.

     

    Or a screwdriver and a hammer, will break the lock but not the door. I doubt many people would actually tear down doors all day. And we are not even talking doors, but actual safes, would be way more efficient to crack the lock than to actually pound on the door, cracking the lock should have more options than just the pickaxe. Variety is the spice of life right, even if underwater is uses the exact same mechanics.


  10. All they need to do is add basic parts to the gun and we will still have gun parts that a weapon is composed off. The basic parts then can be replaced with the modified parts to increase the stats of the gun.

     

    Attachments should go into extra slots that could be tied to the quality or type of weapon.

     

    I really like the gun part system the game has, finding complete guns should not have to exclude finding parts. I use both systems in my modding and it works fine, that is finding a complete gun or finding parts of them. But it also has to technically work well and there might be the problem that it seems to take the place of the old assembly system rather than being added to it.


  11. We're much more quiet for A17 because a lot of the changes going in are system changes that let game features talk to each other, until the new content is created in XML for the new setup, there just isn't much to show. (That and I need to get into the UI bits on it and clean them up)

     

     

     

    The reason some things got overhauled was because I was tasked with redesigning the item modifiers, progression/skills, buffs then making them all able to touch each other.

     

    The overhaul process (Items):

    What happened is that in A17 we were bringing in a better loot loop in that even as a level 1 you'll be able to find a full gun instead of part of one. It won't have very good stats but will likely come with a mod or attachment of some sort. Removing a mod has a chance to break the weapon where an attachment can be put in and taken out at will. This changed the items to only really need 6 tiers. The tiny variations in value weren't fun and were pure vertical progression.

     

    This required us to be able to still use a system similar to the old one that would allow modification of values. Like the parts mods also will modify values on the item they live in. Adding this in required me to build a new central class to process the modifier values.

     

    The overhaul process (Ranged Weapons):

    Ranged weapons have always felt wrong to me. The crosshair spread didn't represent the cone of fire and on top of that the FOV/resolution would change accuracy. I implemented the same fire cone code that I put in for the turrets. With that the new events/effects allowed us to set up things like clip size, fire rate, accuracy kickback as well as many other things. You can basically simulate just about any weapon now via xml values.

     

    The overhaul process (Progression):

    With the new system we wanted to be able to have chunkier skills and perks and less of the incremental gains. With that we wanted to be able to punish the player through their progression stats via illnesses and injuries to keep things interesting. While testing I noticed the skills system made tons of garbage and we don't want that so I went in and redid it to be lightweight and to not make garbage to clean up.

     

    The overhaul process (Buffs):

    Finally the buffs, these guys have timers. Similar to progression, very similar. So I designed a system that was nearly identical to the new progression system. This keeps it lightweight, only storing the timer and a pointer to the single instance of that buff so there is only ever one instance of the heavy data needed. With the buffs we found that actions also needed fired off for particle effects so I started adding an action system. Also at the same time it was discovered that there would need to be requirements to keep buffs from firing something too often or to clean up after itself on login/logout. The need for this kind of cleanup added the need for "events" these started out as simply onBuffStart, onBuffUpdate, and onBuffEnd so we could do a few things but has now grown to include everything from gaining xp to placing a block.

     

    The overhaul process(Overall):

    So basically the needs of each area added to the effect system I initially put together for just the items, then as each system was worked on, instead of shoe-horning it in and causing even more garbage in ram, I instead opted to redesign them from the ground up knowing exactly how they'll be used at this point in our development. I left it as open as possible so we can expand in any way we want/need with little or no code support.

     

    So, sometimes you hit a point where you have to tear things down. Oganically growing code becomes very unwieldy the longer it exists and sometimes a rewrite is needed to encompass all the other features that came along after it.

     

    /data_dump

     

    This sounds wonderful and I fully agree that sometimes you just need to take a few steps back and start from scratch again applying all you have learned and make it better. This sounds to me that it has not only gotten better but also leaner and to boot will give the developers and modders more options. I am just hoping the xmls are not totally changed hehe, but I am guessing we can forget any backwards compatibilty on blocks.xml, items.xml, buffs.xml and progression.xml at least, and possible more xmls that will also call upon these. But that the price of progress I guess :D


  12. Not to mention that it's pointless to have 20 different assault rifles with 20 different ammo types if they all do basically the same thing, which is to shoot bullets very fast.

     

    If they had actual differences such as damage values and such, them it would make more sense, but otherwise why bother? Better to just have one gun for each type.

     

    If they are just the same there is indeed no point to having different ammo types, but the game supports damage by ammo type, thats what I have been doing so far in my mod. I have added some extra ammo types and the weapons no longer decide the damage but rather the type of ammo (and it's grade).

     

    The system is already there for the pimps to use should they decide to add some more depth. I personally like to have a bit more variety and thus also justify the existence of a weapon by the type of bullet(s) it can fire. The hunting rifle at the moment becomes obsolete the moment you find a sniper rifle just because it shoots the same bullet less effectively. Where when it shoots a different type it becomes a (cheaper) alternative you can use.


  13. Every time Madmole shows 3rd person mocap improvements to the player character model that is also progress for bandits.

     

     

     

    This IS what I was referring to but it has a lot more significance than simply fatigue. Maybe Gazz will come on and give some details on the new Integrated Survival System since it has technically been shown now. All I'll say is that A17 will end the #hungerandthirstbargate once and for all... :)

     

    FRtUzjG.png

     

     

     

     

     

    Wow. You sure you don't want Sherlock as your handle?

     

    Maybe, but Sherlock is more observant than I am.

     

    But this is clever, I see it now (I think).

     

    Your maximum stamina is now determined by you fullness and or hydration. So if you keep yourself fed you have more stamina at your disposal. So basically you can see how much hunger/thirst you have by looking at your stamina :) Will make keeping yourself fed more important than it already was, since I think it already affected your regeneration rate before.

     

     

    As for the cupboards, I think the idea is nice, the implementation is a bit a off. Ideally a closed one would turn to an open one after looting (but might still have items in it) an open one will show a player its likely been searched before and will this take its loot from a different table with lower chances or less stuff. I would certainly use these models that way in my mod, loot something and it turns into a open one.


  14. btw.....Madmole inadvertently showed a brand new feature in the most recent video but you have to be really observant to have caught it. If someone can spot the change I'll confirm it and it may lay to rest one of the biggest #gates we've had around here...

     

    Things I have spotted so far:

     

    - Game runs on DX11, but thats already been spoiled.

     

    - Clothes seem to have lost quality and stack to 500 now.

     

    - Same goes for minibike parts.

     

    - Some blocks (with stack numbers) have quality now, could not see what blocks they were but could be electric ones.

     

    - Mining hat as the 'Assembly' option so it can be assembled from parts now I think?

     

    - Spawn menu seems overhauled with optional more than 1 screen of zombies to spawn (which is great for me as a modder).

     

    - Seems there are is a Bandit Leader now and some NPC survivors added. But only visible on the list so no way to tell if it works.

     

    - Zombie kills give a lot more experience by the looks of how fast he levels from killing just a few (but that could just be a wip side effect).

     

    - Zombie ragdoll movement seems to work, they fly when hit by the shotgun.

     

    - Weapon parts are no longer there when a weapon is assembled, so they could be out and replaced by the new attachment (this new system would likely otherwise conflict with the existing weapon part system and create a lot of xml entries for multiple weapons as it is in A16).

     

    - The bedroll starter quest does no longer seem to need the bedroll to be crafted or placed, only fiber gathered.

     

    - It seems that Madmole can attach weapon mods to his shotgun/use the assembly but cannot repair it because he does not have the recipe learned. This means that perhaps finally these two systems have been separated so that repairing is not tied to being able to assemble a gun. But it could also be that assembly with the recipe known will show the weapon parts that as mentioned before are not visible.

     

    - New stats on weapons that show, but these seem for debugging and only horizontal/vertical spread are new.

     

    - Scrap frames are now Iron frames (but thats just a rename in localization.txt)

     

    - The Inventory has a TRASH button :D

     

    Edit:

     

    - Wellness is not gone yet (from the GUI at least).

     

    Probably more that I missed, but lot of cool stuff here :)


  15. With the addition of the Health Bar for zombies this game will really something akin to the Ranger Mode from the Metro series. A mode or setting that removes much of the HUD/Crosshairs health bars etc. Or something akin to Realism mode in Left 4 Dead 2. Then new players can enjoy the game with a lot of visual feedback guiding and helping them and veterans/masochists/survivalists can play with this mode on.

     

    But I guess this for now will be something we will need to turn to modding for.

     

    I liked all the other stuff I saw in the video. Though I am wondering what happened to the standard weapon parts, seems they have been removed in favor of mods. Does this mean eventually all weapons come with like default parts on each slot that can be swapped out, or is the base weapon just no longer composed of parts anymore?


  16. 2017-01-27T17:53:41 28.957 ERR Loading and parsing 'loot.xml' (lootgroup 'ak47+ammo' is defined multiple times)

     

    Here you go, you have duplcate entries.


  17. Setting probability to 0 in the entititygroups.xml for anything you dont want to see should be the easiest way to achieve that. Removing zeds from groups has the same effect, but if you later want to readd it is gone :)


  18. Yes. It should work, it's quite a common desire by serveradmins. When the devs will work on modding support, I'll bring this to their attention. Among a few other things.

     

    - - - Updated - - -

     

    My post #378 sums up my findings: Have wasteland within a radius of 2500 blocks around the center and have the cells of a maximum size of 1250-1300. I assume that if you made the cells bigger, you have to have a larger radius, but didn't experiment with it, since I like small cells, because I have 80% rural hubs.

     

    I have 100% rural hubs, except for the central city which is a 4 block tiny city. I have 1250 wasteland_hub in the center, cells of 1350. Going down in cell size usually results in 0,0 spawn and that yellow warning, but with some biome testing I made ALL of the world become wasteland/wasteland_hub/city_wasteland and some other biomes. Only with the wasteland biomes and cell size that does not give the error on a normal world I had 100% 0,0 spawns and that warning. Perhaps its the small cell size combined with a central wasteland that causes it, as I often spawn right at or near the border of my central wasteland.


  19. Spawning at 0,0 I think might caused by the game attempting to spawn a player in the wasteland, tho not 100% sure. It 100% happens when you set the world tot be totally covered by wasteland/wasteland_hub or city_wasteland. You get a warning that player was spawned at wrong position and you appear at 0,0 with usually a missing or partially missing hub buildings.

     

    It may have something to do with addition in A15 that should prevent you from spawning in the wasteland. Still this does not work all the time, I sometimes just spawn in a wasteland, even in vanilla RWG settings.

×
×
  • Create New...