Jump to content

doughphunghus

Members
  • Posts

    1,293
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by doughphunghus

  1. I re-reported it with dbs screenshots before "incomplete reports" threads allowed comments/updates: https://community.7daystodie.com/bug-test-1/under-review/b121-navezgane-burnt-forest-terrain-decorations-that-are-floatingtrees-not-fully-rooted-r286/
  2. I re-reported it with dbs screenshots before "incomplete reports" threads allowed comments/updates: https://community.7daystodie.com/bug-test-1/under-review/b121-navezgane-burnt-forest-terrain-decorations-that-are-floatingtrees-not-fully-rooted-r286/
  3. yes, that's the spot. The rest of the "holes" show "raw wood" texture. It's a minor thing, just happened to see it and it looked weird
  4. yes, that's the spot. The rest of the "holes" show "raw wood" texture. It's a minor thing, just happened to see it and it looked weird
  5. I ran across this in the "known bugs" list: "Zeds floating with their hands up". This might be a dupe then? It was a crawler that was crawling and then somehow found itself in this position, vs "did this on spawn"
  6. I ran across this in the "known bugs" list: "Zeds floating with their hands up". This might be a dupe then? It was a crawler that was crawling and then somehow found itself in this position, vs "did this on spawn"
  7. It wasn't working when it had 300/300 health and "was not hit". I hit it to see if that would help, just like you do in real life!
  8. It wasn't working when it had 300/300 health and "was not hit". I hit it to see if that would help, just like you do in real life!
  9. I was finally able to upload a screenshot I took of it. I think my "screnshot uploading" issues this morning have been something on my side, not forum side. Also: It's "trailer_park_01", not "trailer_01"... if that makes a difference
  10. I was finally able to upload a screenshot I took of it. I think my "screnshot uploading" issues this morning have been something on my side, not forum side. Also: It's "trailer_park_01", not "trailer_01"... if that makes a difference
  11. Also: I'm not going to comb over the grammar of the other treasure maps and submit reports unless someone wants me to. Just noticed this while playing
  12. Also: I'm not going to comb over the grammar of the other treasure maps and submit reports unless someone wants me to. Just noticed this while playing
  13. DUST2DEATH, Where did you get/generate that graphic for the credits/distribution permissions? I have been wanting a game mechanic (ha ha) like his for a LONG time. This is awesome. Thanks for the mod!
  14. Thanks! If someone wants to "keep it up" or there's a process to migrate it into the Creature Packs, I don't mind doing what I can. I don't know who originally " owns" this so I just did whatever was needed to get them to load up. If you/anyone are making updates to it, I'll happily "archive" it on my github site and put a link to the maintained version! Yeah, I'm sorry I didn't want to hijack the thread I believe you may be right. I put a lot of thought into it today and I think its more work than I'm going to be able to handle. If anyone's interested, the gist of it was: Allow anyone with a forum account to contribute any sounds... allow just .wav and unity3d (less desirable) formats. Document a few required standards (maybe bitrate or something). Then, they hand over the sound files and (if deemed acceptable) they get put into a lightly structured github repository as the "Development Sound files" source repo called "CommunityPack-Sounds-SourceFiles". No one but pack admins will have access to update this repo. This way we will always have the source sounds, and anyone can remix them as they wish (or clean them up) and resubmit. Still a lot of thoughts here on naming/structuring standards and such as it could get messy. Then make a second repo called "CommunityPack-Sounds" that is just the /Resources folder and all <sound>_unity3d files built from the "CommunityPack-Sounds-SourceFiles" repo. Document all the sounds in the files so people can use them easily as these sound names/paths can never change!. Make "smaller files" by sound type vs 1 super big file. Easier to patch/update/distribute them that way. Then anyone go to the "CommunityPack-Sounds-SourceFiles"' to listen to them, then go to "CommunityPack-Sounds" and take the unity.3d files they need and put them in their mods as they see fit. Then, to take it to the extreme, its possible you *could* make a "0-CommunityPack-Sounds-Standard" modlet that is actually playable/loadable for general use. It would contain *only* the unity.3d files sounds that are "generic vanilla stuff" that adds ambiance to the game (like opening the backpack, breaking glass, walking on trash) that can be appended to the existing sound Nodes in sounds.xml. Anyway, That's all my thoughts on this if it helps. Someone else can run with it if they wish!
  15. Let me see if I can set up something for a sound pack on github. I'll make a new thread and post a link here. I already have some sounds I made in a small modlet I was messing with, so I can populate it with some stuff as an example, and maybe come up with some basic instructions to contribute to it. I have limited experience combining sounds to unity.3d, but if the source sounds were made available in some fashion (likely a separate github repo so you don't have to download all the raw sound files to use the modlet in the game) then anyone could rebuild/update//use them. I really want some more sounds for the Z's so you don't know whats "behind that door" when you hear something but I don't have the sound mixing experience to make good ones.
  16. So, after some thinking, this is what I've come up with: I can see 3 separate "modlets" that might be easy to be "communitized". There could be more, but for now these are the ones that at least sketch out how to possibly do it: 0-CommunityDevPack-0-Materials 0-CommunityDevPack-1-Sounds 1-CommunityDevPack-1-Items-Resources Rationale: - Any modlets that do not rely on *any other* modlets (e.g their xml does not refer to any other xml files) have their names start with "0-" - Any modlets that ONLY refer to a "0-" pack, start with "1-" - If there are more modlets that use *only* those below them, name them "2-", "3-" respectively. This is unlikely to happen but that's the way to build it out if needed - Then all modlets are named "CommunityDevPack". This is because when you load them, nothing in the game changes (they are invisible "things" used only to build other modlets with). They are literally modlets to develop other modlets on, not standalone/playable modlets on their own. - Then, just in case (especially with the "items" xml, there are a lot of item types), we add a "-[number]" to hard enforce a load order within the group. Its a bit of overkill, but another "just in case" as load order id vital to any of this working - Then, you name the modlet after the XML file being modified, with a capital letter: "-Items" or "-Sounds", etc. - Then, if there is a particular "type" of thing inside the XML ( items.xml has a lot), you add that type. e.g.: "-Resources" - None of these modlets will modify any other modlet. They will not change vanilla XML, only extend it Having looked though things, I can only see this being the "easiest thing to do" and maybe a few more modlets that could be added: Maybe biomes.xml, music.xml? and a few other things. For example: 0-CommunityDevPack-2-Music 1-CommunityDevPack-2-Biomes <-maybe this would be a 2, at least temporarily The hard part is making these not have as little visible effect on the game and be "activated" only by other mods. Additionally, it might get really messy (a lot of xml to maintain) if Items-Food were added and all the buffs/effects/actions had to all be in there to properly support it. So, for now, not a good idea. Pretty much every other item type in the game besides "resources" looks too complicated. If anything, I would want this to be "as little xml as possible", and something that is lightweight but to test on/get feedback so when the game updates (a19, 20, ...) its not too hard to keep updated. If it starts working out as a useful concept then it can be locked down more as the game goes gold. If these packs go out of maintenance, it will be easy for modders to take over and/or just copy the xml they need out (because the XML will be simple). Additionally: I haven't thought of naming conventions of the XML nodes yet. Will keep thinking about it: input is welcome! I might try putting something small together and see if anyone interested/how it works out in real games. I'm still *very* interested if anyone has any input or a "Danger: Bears lurk here" experience to share Anyway: I don't want to take up too much space in this forum thread (sorry ) just wanted to hear from the people working on the CreaturePacks to see if this was a harder thing than it looks, or commentary on the naming "standard" idea
  17. Yeah, I'm trying to think of a good way to envision how to do it. Thoughts so far are: - It may be difficult to "categorize" every item. Like, is "sugar" a food item or just "an item". It seems like food, but if it was added early it might be categorized under a "generic" or something Some items like "vinegar" can be used in food, bot have other uses so maybe that's a better example - I personally the real challenge (with my own modlets) in adding new items was doing/getting graphics. For a few items its not a big deal, but if a bunch of people are contributing new items to a common pack the graphics are going to feel all "not the same style". I feel it would be a lot of work to make them all "similar", artistically, but then again, if people load a lot of random mods its going to look that way anyway. Personally I feel that maybe graphics may not need to be any sort of standard, at least for awhile. - "junk like" Items (like a gear, or pencil) are almost "stand alone" meaning, they only really have a dependence on anything other than a material, and you likely can use existing in game materials (scrap to steel, wood). Or, maybe they cannot be scrapped. I feel scrapping is going o be difficult without some standard as I wouldn't want to scrap a pencil and get 1 wood pack (its too much wood). So maybe the initial pack "framework" would need to define some "minimal scrap amount" and if an item was smaller than that it either cannot be scrapped, or it scraps to some very small thing that must be pooled to craft a bundle (like scrap 1 earring to get an iron fragment, craft 100 iron fragments to get 1 iron). i realize this could lead to severe "craft and scrap" overkill, but I feel that if some base amounts are not standardized then recipes are going to be really weird if you build on this stuff. In reference to your quote: THe best way to deal with it may to make all items not be "lootable" and have modders add where to loot them. That way you can add teh pack, and nothing happens unless you add another pack to actually populate/add the items to things... which deals with - Looting: I feel that an items pack may not include a loot pack (e.g a "0-Community Items Loot Pack" would be a separate pack? I mean, anything else building on this would be separate) Basically, maybe you load the items pack and no items "exist" to be crafted or found because none of them are lootable. Then modders can choose where they are lootable/craftable. This seems the most logical. This way the "items" pack is basically a "junk" pack (because there are no recipes or looting abilities) then you can load the loot pack just to be able to get all the junk (but nothing to craft with) and then if a modder wants to make a cool loot pack then they say "don't load the default loot pack". There's a lot of options, which is why it seems almost in reach to do (and I wouldn't mind putting a starter one on Github to see what happens) but then again it almost seems like it will be fraught with "growing pains" and very complicated for modders to actually use (want to use exp. if its wonky or a pain to use).
  18. Xyth (and anyone else working on these packs), Creatures seem like a lot of work to make vs other things, but also seem more "contained" in all the dependencies they need ( in terms of XML modding). Can you see a need or benefit or good "packs" (for someone) to create other "community" packs similar to these (but not for entities)? If so, any advice/thoughts on how to go about it ("lessons learned" from the creature packs. Most I've seen are around naming conventions). I don't want to have something pop up and then magically there's 7 community packs being maintained independently for a lot of the same stuff. I can imagine making some on github (so there's a core few people approving additions, making updates) and then having people just do pull requests to add stuff. I feel as though a "items" pack would be useful as it could contain a lot of the basic stuff modders are adding like sugar, nails, screws, other metals, "junk" items, etc. Basically, if you loaded a "0- Basic Items Community pack" you could get to name it 0- so it loads first, and then modders could just focus on making recipes, stat changes, etc. Long ago I though of making some "very complicated electrical recipes" to make stuff, but I kinda got burned out making all the base items/ I know if we had a lot of base "food" items (pickles, salt, vinegar, baking yeast, etc) then people could easily go crazy with recipes for new food items. I could see an items pack needing a "materials" pack to build off of ... maybe...but then that gets complicated "Blocks" is another, but I'm having a harder time seeing it be as "self contained" as an items pack
  19. its already been fixed but....wouldn't they mourn you, bury you using your backpack as a marker, and then move on ,,,, having been enriched knowing you for that short time . It would be kind of neat if there was an option to respawn as a different character each time, you find your old base, etc.
  20. Just some input: After you play it through a few times, these packs are exactly the stuff this game needs to keep it fun without changing any of the core elements of the game. Thanks to everyone who has worked on this!
×
×
  • Create New...