MacManChomp

You should be able to pack up any loose files as a zip file fairly easy. Look for a nmm mod packing tutorial. You used to need to maintain the same file structure and I'm sure you still do. Just start by creating a folder named after your mod then the folders necessary for your loose file to be added. I'm not very good at explaining this sorry. It doesn't help much that I'm on my phone. :p

Race! In all honesty just make your mod, if the shortcoming of the other mod becomes apparent later ( which all mods have shortcomings) maybe look at resolving that shortcoming in your mod when it does become apparent. Usually this is something like compatibility with other mods. Or if it never shows up, just do your thing. If you're passionate about this you shouldn't have any problems. :)

I'm sure the guy who did the backpack mod could point you in the right direction. He made a strapless version of the backpack to prevent terrible clipping errors, which means he had to make a portion of the texture invisible. Not removing the texture but just making it invisible. http://www.nexusmods.com/fallout4/mods/3258/?

I'd say that a mod like this on its way to become a hot ticket item. if only we could add scripts in cuz I'd like to see settlers renamed to the job they're doing. As in farmer guard merchant scavenger and any other jobs I'm forgetting.

Someone with some NifSkope experience should be able to help guide you to the right information, essentially you should be able to make the textures you want invisible.

I would love to see this type of thing. I love the pipboy but it can definitely be difficult to read. I use power armor often just because I prefer the pipboy menu. Never thought I would be saying that, but seriously the pipboy ui needs a revamp but for the time being I would love the Power Armor pipboy interface. :)

Namaskar I was saying that making it modular is a good idea. Essentially agreeing with bacon. Making a large mod available as not only a package but also modules encourages a more polished product as well as giving more freedom to the users.

Probably not. If the sound file that you sampled from has an active copyright then it's technically theft. I would say if you want to avoid that, create your own sounds or look for free sounds that are copyright free.

TCL or ToggleClipping also affects object placement to avoid doing weird things with rugs. Also I haven't noticed any difference between the rug method and doing the same thing without a rug. Essentially, pre-building changes clipping and allows for a better fit.

This.

Two great ideas guys. I agree that there should be a point where the dislikes of a particular action should permanently taper off. I'm about ready to cut Strong loose for complaining about me hopping into power armor since I store all of it at the castle and he stays there too. Danneyo: That's right on track with my original thought, though expanded to individual NPC's. My original thought along those lines was to award companion affection only for the actual clearing. Though killing the head honcho seems like a more realistic, and easier to balance concept. And don't worry Bacon I'm not skipping the rest of what you said, that opens a very large door to the world of companion affection. And I agree that some of the higher skilled takedowns should have at least one companion that awards the behavior. I think that so far the trend is pointing to a different method, rather than time-based. Perhaps a kill-based method could be implemented in-stead. This actually sounds like a very good idea, since balance may be easier to achieve and maintain, by essentially flooding the affection meter with more changes. For example: Cait seems to have a good reason for hating raiders, so why shouldn't a small amount of affection be added when killing strong(Legendary?) or named raiders? Whereas Strong is a super-mutant and might have a dislike for killing fellow super-mutants.

Disclaimer: This will likely be impossible until we can start working on scripts. Possibly before GECK release if anyone has the know-how, but until someone presents information forward I see no method of modifying existing scripts or adding new scripts. The companion affection system can be a bit hairy at times due to the mechanics of it. Forbes has a nice write-up that makes a valid point: http://www.forbes.com/sites/insertcoin/2015/11/19/companions-are-fallout-4s-best-characters-and-worst-gameplay-mechanic/ The idea of slowly adding companion affection is really what I'm looking at here. As well as eventually adding a page to the pip-boy that shows companion affection stages and progress in a similar fashion to level progress. The basic outlines of the idea would be as follows: Build a time-based or action-based companion affection supply. For example: clearing locations could be a viable way of adding a new affection source, and possibly weighing the amount of affection gained by existing companion preference and/or Charisma level. Or alternatively (and much more simply) create a very slow affection feed from just playing the game with the companion.Create a new page for the pip-boy under DATA for companion affections. (might be possible today, if anyone would like to share information on this subject please do! :smile:)The early development stages would be to find a good balance. From my understanding companion affection is maxed out at 1000 units. 1000 units / 60 minutes would take just under 17 hours of gameplay to max a companion out if you were doing nothing that they liked or disliked at 1 unit per minute. This to me appears to be a viable option for those who would wish to supplement their affection gains, effectively allowing them to ignore some of the dislikes and missed likes so that they might play the way that they enjoy playing the game. Note that this would not allow the player to disregard their companions feelings without making their companion upset, but rather pay a little less attention to it. Another thought along these lines would be to add a Charisma based control over this speed. For example: a player with 1 Charisma might get 10 or 15 companion affection per hour, while a character with 10 Charisma might get 100 per hour. Though re-reading that last sentence makes 10 Charisma sound a little over-powered, especially when some characters can be leveled to 250 or even 500 in only a few hours, making these characters take a single night to reach 100%. In response to the previous point, the idea of a lower cap on the function of this additional or supplemental affection might be valid. Not everyone is going to "love" you for just having them along for the ride. This could break the immersion, so possibly only bring this into effect during the lower side or maybe teeter off at the top to something equal to players Charisma per hour, which would allow players to maintain high affection and without having to leave their companions at home or change their play style to fit the companion. Before commenting on this please understand that what I am looking for is simple, starting a community discussion on balance, flaws, validity of concept and possibly (though not likely at this stage) production methods. From my knowledge of Skyrim modding this seems like something that could be partially pre-written (basic functions and scaling concepts) for release on GECK arrival. I will be somewhat monitoring this thread and generating an outline for the project, so please be helpful in your comments! Another thing to keep in mind is how messy scripts can be when altered, added, or deleted. The script would be best implemented as a perk in my opinion, which would allow the player to remove the perk before uninstalling to clean up the unwanted memory hog that can damage save games. If anyone has any other ideas on this or perhaps some knowledge on how one can make sure that their script is not being wasteful that would be much appreciated. Perhaps a check that looks for the existence of a marker? Sorry if I ramble, but comment away!

.

Current is working perfect! Nice and cleaned up thanks to tips from steve40!and thank you en0z3!

success!!!! Though the values are wrong! For some reason it missed the Iron Ingot (I don't know why, looking into it now!) But I have successfully removed a selection of ingots from my inventory and moved them into the container! Edit: I forgot the Iron Ingot on the form list >.> but it seems that everything works now, thank you for the help! I will continue to make more scripts for use with other types of items such as weapons, soulgems and more.

Yeah thanks I already fixed that, sorry about the stupid mistakes. in my most recent build I am finding that object references are required to add or remove an item but not obtainable from the forms. To be expected, but I need to find a way to get the references of all of these items. Is there a way that I could do something more like a addform with a blank form to populate the entire form with viable object references? I have this right now: Scriptname CSItemSorting extends ObjectReference {An item sorting script to move player inventory into chests. (hope this works out..... )} Int iIndex Int iReference ObjectReference Reference ObjectReference Property Landing Auto FormList Property ListOfObjectsFLST Auto Message Property ActivateMSG Auto Message Property FailedMSG Auto Int Button Form Item Event OnActivate(ObjectReference akActionRef) If akActionRef == Game.GetPlayer() Button = ActivateMSG.show() If Button == 0 iIndex = ListOfObjectsFLST.GetSize() ; Indices are offset by 1 relative to size While(iIndex > 0) iIndex -= 1 Debug.Trace("Form " + iIndex + " is " + ListOfObjectsFLST.GetAt(iIndex)) Item = ListOfObjectsFLST.GetAt(iIndex) ; Note that you must typecast the entry from the formlist using 'As'. Debug.Trace("Item is " + Item) Debug.Trace("FormID is " + Item.GetFormID()) Debug.Trace(" Item count is " + Game.GetPlayer().GetItemCount(Item)) Debug.Trace("Reference = " +Reference) If Game.GetPlayer().GetItemCount(Item) >= 1 Debug.Trace("player has enough items of " + Item + ": " + Game.GetPlayer().GetItemCount(Item)) iReference = Game.GetPlayer().GetItemCount(Item) Game.GetPlayer().RemoveItem(Item, iReference, false) Landing.AddItem(Item, iReference, false) EndIf EndWhile EndIf EndIf EndEvent still in the middle of some extensive reworking as the debug file is always showing a count of 0 on the player. Is there maybe a way to add these items to the player and remove them from the player without having to get rid of the formlist? the debug output is aggravating me and I can't seem to Incorporate the skse functions into my script like GetName() and such. It just fails to compile and I cannot find any information on how to use the skse functions.... *pulling my hear out here*

Yet another update... Starting to feel stupid. with the addition of tracing the item count, I am finding that it counts none on the player! There must be another way, as I have worked on this too much to just give up because Papyrus doesn't allow me to check for the item associated with a form on the player.

UPDATE: A little more trial and error got me so far as to get this read-out: [08/21/2012 - 06:16:18PM] Form 9 is [MiscObject < (0005ACE5)>] [08/21/2012 - 06:16:19PM] Item is [MiscObject < (0005ACE5)>] [08/21/2012 - 06:16:19PM] FormID is 371941 [08/21/2012 - 06:16:19PM] Form 8 is [MiscObject < (0005ACE3)>] [08/21/2012 - 06:16:19PM] Item is [MiscObject < (0005ACE3)>] [08/21/2012 - 06:16:19PM] FormID is 371939 [08/21/2012 - 06:16:19PM] Form 7 is [Form < (0005ADA0)>] [08/21/2012 - 06:16:19PM] Item is [Form < (0005ADA0)>] [08/21/2012 - 06:16:19PM] FormID is 372128 [08/21/2012 - 06:16:19PM] Form 6 is [Form < (0005AD99)>] with this script: Scriptname CSItemSorting extends ObjectReference {An item sorting script to move player inventory into chests. (hope this works out..... )} Int iIndex Int iReference ObjectReference Reference ObjectReference Property Landing Auto FormList Property ListOfObjectsFLST Auto Message Property ActivateMSG Auto Message Property FailedMSG Auto Int Button Form Item Event OnActivate(ObjectReference akActionRef) If akActionRef == Game.GetPlayer() Button = ActivateMSG.show() If Button == 0 iIndex = ListOfObjectsFLST.GetSize() ; Indices are offset by 1 relative to size While(iIndex > 0) iIndex -= 1 Debug.Trace("Form " + iIndex + " is " + ListOfObjectsFLST.GetAt(iIndex)) Item = ListOfObjectsFLST.GetAt(iIndex) ; Note that you must typecast the entry from the formlist using 'As'. Debug.Trace("Item is " + Item) Debug.Trace("FormID is " + Item.GetFormID()) If Game.GetPlayer().GetItemCount(Item) >= 1 iReference = Game.GetPlayer().GetItemCount(Item) Game.GetPlayer().RemoveItem(Item, iReference, true) Landing.AddItem(Item, iReference, true) EndIf EndWhile EndIf EndIf EndEvent as you can see there are no errors, but the items are not removed from my inventory or added to the container. Maybe I am doing something wrong? It seems as though I have made good progress and the script looks good to me, but I am certain I am missing something.

okay so Dawngaurd does use it's own scripts! Helpful information here, you can't have them just yet. when setting up the CK you should get a bunch of script source and more pre-compiled scripts. I believe that with the use of the ck you can edit the source of scripts that you do not have the source for already unpacked (they should be packed in the bsa!) So to answer your question yes Dawnguard uses it's own scripts and more importantly almost everything you would want to look at is inside that bethsoft archive. You may want to just up and unpack the whole thing and rummage around, but my suggestion would be to load the dawnguard dlc into the ck and look for the effected items. quests maybe? Anywhere that a script could be attached and contain the wanted effects. Look more into the skill tree and look for information on making your own perks. (new perks excite users, adding a simple perk that shortens shout regeneration times unlocked by using your shouts would be a wondrous addition to the game.) I'm loading up my CK now and going to look a little more into this.

With some work I have managed to get very close to having a working script to sort items from player inventory to containers. It seems that the only way to accomplish this goal though is through a very long script. For Example: ObjectReference Property IronIngot Auto ObjectReference Property Container Auto int iCount Event OnActivate (ObjectReference akActionRef) iCount = Game.GetPLayer(),GetItemCount(IronIngot) Game.GetPlayer().RemoveItem(IronIngot, num, true) Container.Additem(IronIngot, num, true) endEvent you would have to do this for every item you wanted the chest to handle. I don't have the time to do this. I am looking for a way to move the items (so far only MiscObject with the use of a FormList. Something more like Scriptname CSItemSorting extends ObjectReference {An item sorting script to move player inventory into chests. (hope this works out..... )} Int iIndex Int iReference ObjectReference Reference ObjectReference Property Landing Auto FormList Property ListOfObjectsFLST Auto Message Property ActivateMSG Auto Message Property FailedMSG Auto Int Button Event OnActivate(ObjectReference akActionRef) If akActionRef == Game.GetPlayer() Button = ActivateMSG.show() If Button == 0 iIndex = ListOfObjectsFLST.GetSize() ; Indices are offset by 1 relative to size While(iIndex > 0) iIndex -= 1 Debug.Trace("Form " + iIndex + " is " + ListOfObjectsFLST.GetAt(iIndex)) Reference = ListOfObjectsFLST.GetAt(iIndex) as ObjectReference ; Note that you must typecast the entry from the formlist using 'As'. Debug.Trace("Reference is " + Reference); Trace the output of the ObjectReference Reference, currently only returns none!!! Debug.Trace("FormID is " + Reference.GetFormID()) iReference = Reference.GetItemCount(Reference) Debug.Trace("iReference is " + iReference) If Game.GetPlayer().GetItemCount(Reference) >= 1 Game.GetPlayer().RemoveItem(Reference, iReference, true) Landing.AddItem(Reference, iReference, true) EndIf EndWhile EndIf EndIf EndEvent The upsetting part is that even though this SHOULD work, it does not. The line Debug.Trace("Form " + iIndex + " is " + ListOfObjectsFLST.GetAt(iIndex)) is outputting [08/21/2012 - 04:17:11PM] Form 1 is [MiscObject < (000DB8A2)>] And using a MiscObject instead of an ObjectReference does not compile. The above script will compile and will run, asking you if you want to add your ingots to the chest and regardless of choice continue to open the chest. (I have it attached to the container for now, plans are for buttons or maybe a magical wall of buttons to move items into respective chests.)