SMB92

THREAD IS NOW OBSOLETE, MOD PLEASE LOCK. NEW THREAD HERE: https://forums.nexusmods.com/index.php?/topic/6198786-spawns-of-the-commonwealth-wotc-2-new-thread/

Here is the invite to our new and fresh server: https://discord.gg/u6DWaPZ The reason why we have a new server is because the last one was trashed and unorganised. We were running a lawless society and while I thought it was cool at first to have no rules, we ultimately paid the price for what that entails. Apologies to anybody that may have got the raw end of that stick. Needless to say, we now have a much nicer structure and rules. Cos people need a government! Lol. HOW TO BECOME A MEMBER: If you are interested in becoming a recognised member we got a fun little system going on. When you join, you'll see there is a channel at the top of the list called "membership and roles" under the SERVER INFO category. There you will find a detailed list of F4 Factions that you can join. All of these are the same, we just thought it would be fun for our members to represent a faction in our server, given this is a giant spawn mod after all :smile: You can request membership in the Public Channels category under a channel called "membership requests" (quite fittingly). Members have more access to certain channels. It's okay to be a lurker, but generally we don't automatically make people a member straight away. You can be a member without dropping a request to join a faction, but we don't go through it all the time and add new joiners. We generally respond much faster to requests in that channel made for that purpose. At this stage the server is small and contains not a lot of information. It will be the place for all alpha/beta testing in future so if you are interested in following the mod, it will be the place to be.

Hi all, Decided to start a new thread to match the new Discord server (info below in second post). Since the previous thread (found here) I started some time ago, the core scope and features of the mod has advanced significantly. EDIT MAY 2018: SOTC has undergone a lot of changes over the past 12 months of development, and is now a fully modular engine of it's own. This means that third party modders can make addons for this mod. I have deleted all the older documentation that was on this page as a lot of it is outdated now, and as of this moment there isn't a whole great deal of documentation as I haven't had time to write it. However you can find a fair amount of commentary in my scripts. Speaking of which SOTC now has a Github! https://github.com/SMB92/F4-SpawnEngine You may have noticed I have changed the name. That is correct, it is now called SpawnEngine (aka SOTC) as this better reflects what the mod is. If you would like to follow the project more closely, I'd recommend you join my Discord server (link in sig). I spend most of my social time there these days.

Thanks for the reply Fifty, I'll take a look at that when I get a chance. Got a few things on at the minute.

Apologies I haven't had time to follow this, have you made any progress?

Indeed it is frustrating. Hence why I started building my own mod :D

For what it is worth, I run into the same issue. Without WoTC I have a very stable game, with WoTC (which I freakin love BTW) I get serious crashing issues especially when i'm deep in the city between Goodneighbor and Old North Church (or whatever it is called where you meet the Railroad). I'm really hoping the new version will have fewer issues. NOTE: i suspect the real issue with the mod is between adding all the actors and trying to calculate all the conflict they are generating off screen (but still in the same zone) that our systems are simply choking on all the additional data. Further I'm wondering if that combination isn't creating some save bloat which contributes to the random crashes. The real issue is more than likely if no definitely, the use of the PlaceAtMe function rather than the PlaceActorAtMe function (one is a function of ObjectReference, the other ActorBase which extends ObjectReference but works slightly differently + takes different parameters specific to actors rather than objects). There is also a lot of errors with MoveToNearestNavmesh, but some experienced modders I talk to have observed errors with this 1000 times and not seen a crash. SO it's almost a guarantee what is happening is the PlaceAtMe function - which is known to place mobs half way through the floor - is causing the crash when actors end up anywhere but on the navmesh (paticularly if the movetonearestnavmesh function fails) and walking around - if they fall through the map, the game will CTD, this is a definite. Another theory is that WOTCs script might be lagging behind and therefore when a spawned group is ready to be placed, the area may have unloaded as the player moves about, which would lead to the exact problem described above. I am not aware of any other reason a CTD would occur with mod. Regarding save bloat, the mod is simply making persistent all actors it spawns and therefore tracks, and furthermore the way WOTC has spawn points setup is heavily convoluted - the new mod uses just 1 marker where as WOTC uses 1 marker surrounded by groups of actual actor markers, which from memory are also immediately persistent therefore in the save game. Now, the new mod will have fluctuations in save game size depending entirely upon your settings (how many actors you are potentially spawning and tracking vs how long you are letting a group remain active before cleaning up). My mod will extensively clean itself and the majority of data it generates, all completely customisable.

Just looking at your code there Thorald, so what I could do is place dummy markers at each location, which are simply only persistent when an array of them is filled, and then on my spawn marker I can point to a temporary marker and use placeatme at spawn time to instance it at a random dummy and move to another on package complete. Your code would also make the performance better cos I won't need to relink the ref. Now the headache remains, what will be the best way to deal with the whole group via the package script? It's easy enough on a single actor but gonna be a bit more challenging to deal with the whole group. I'm thinking I should keep a count on the spawn marker, each time one of the actors completes the package, increment the count, and have a while loop running every 30 seconds or so that will check the count vs the length of the group array, and once equal, run a function on the spawn marker that way. Something like this at least.

Thanks for the replies, but seems I didn't get the email until just now. Thorald, that could possibly be an idea, to have a temporary marker stored on each spawn marker that could get placed around at different locations, although the end result is similar to the solution I came up with, I will have to restart the package on every actor using a while loop after moving said marker. But I think your method may be better for persistence. SKK50, the problem is the way I have packages atm with markers placed in the world, the markers are always persistent as they are the location target of packages. I also have to make multiple packages which means multiple ref aliases, to emulate random location travel. So each package has 3 locations for example, a predefined route that actors will just travel between and sandbox at each one (sometimes guard package as well). I am able to just use the option in the travel package to "linked ref" and then at spawn time select from a predefined array of location markers and link them, which means I can dump these array later and not have any persistent markers, but it means I have to iterate through each spawned actor and manually unlink/relink to new marker and restart the package. Fortunately this doesn't affect any of my clean up code either way, but I do not like the idea of having to iterate through every group and do this, especially if there becomes a lot of spawned actor groups active, and also it will be competing with any spawn points firing off. But maybe I am underestimating Papyrus and it might not hurt performance too much.

If your gpu is running 100% then that just means your CPU isn't bottlenecking it usually in this game. Or some other background thing is hooking into the gpu for whatever reason. New mod will not have the problems this one has. I recommend you join my Discord server for more up to date info and chats

@player yes you can conclude that. Sometime you have bad luck and game will ctd a lot of times in a row with WOTC. I need to blow away this thread and start another one. I am having a hard time managing my time because I have little of it. Apologies that tlthe documentation is not kept updated here.

Hi all. Thought I'd drop a post and hopefully gather some ideas from fresh minds, as mine is kinda spent on this issue right now :smile: So I am working on a spawn mod as some of you here may know, and one of the "systems", namely the very core and main one, I'd like to have actors travel to a random location in a region, effectively emulating patrol routes. I am already doing things for this of course, but I'd like to try and avoid persistence and also avoid costing too much performance overhead with Papyrus. Cos I suck at explaining things let me iterate over where I am at and what I know so far. The Random branch on AI package is straight up broken. And it wouldn't work with what I want anyway. Moving on. Currently I place a number of XmarkerHeadings at a few locations in a region, and these are the locations which actors will travel to. I then have multiple Travel packages that have a number of these "locations" in the procedure, with a sandbox package in between each one (so actors will arrive at said location, sandbox the area for a given time and move on). I then store each variation of package in Reference Aliases on the quest that controls that area. At spawn time, I select a random Ref Alias and apply it to each actor spawned (keywords and linked refs provided where need be through script as well) so they all follow the preset route/package. Now this means those Xmarkers are persistent always because they are pointed at via the packages etc etc. It's not actually that bad though because even if the mod was uninstalled this doesn't really pose a CTD risk, the game will just clean them up (albeit dropping an error in the log when player first walks into that area again for the first time after uninstall), as far as my testing has revealed. But I would like to just have one Travel package, and randomise the location (or linked ref) everytime the package completes. I can keep an array of the Xmarker "locations" for this purpose. Let me just talk about the spawn script so that you have an idea of that. When actors are spawned in, they are spawned one by one and data applied to them, including the ref alias with package. They are then stored in an array on that spawn point for later cleanup and manipulation. Its about that simple. There can be multiple groups of actors spawned at one point and different arrays stored for each group, but that's not of any major concern with this. Here is the current idea: At spawn time, applytoref to get the package, when actor reaches location run sandbox and then on complete call back to the spawnscript to change the linked ref randomly and restart the package (using array of Xmarkers for the region and if it rolls the same location well that will just emulate a longer sandboxing :D ). To do this though I will need to re-iterate through the actor array stored on spawnscript and reset the linked ref and re-evaluate. I would setup a custom function to handle this, but not sure I like that performance hit, maybe I am just being petty though. Could be potentially iterating through a fair few actors. I'm also not sure how I'm going to pass in the property of the actual script instance it will need to talk to, but shouldn't be that much of a problem, probably with a script applied by the ref alias to the actor (i'll cross that bridge when it comes I suppose) If anybody has any further ideas to this, would be happy to hear them :smile: OR maybe I should just stick with the way I had it. TL;DR: I'd like to use only one Package with a travel + sandbox procedure and change the location when it finishes by changing the linked ref on the actor and restarting the package if possible. This way the markers used as travel "locations" do not come persistent until they are pointed at through the script system.

Well I'm just gonna put a check list and make sure we've been through it all. So here's what you could try: 1. Use/make custom race 2. Change/make new AI package and/or use override package with modded values. 3. Make custom class with modified values 4. Make custom combat style with modified values 5. Avoid use of other ActorBase or LNPC for templating anything on your ActorBase record So those are the easy Ck things I can think of off the top of my head. Failing all this for whatever reason I would try scripting a forced AI package change. Probably via Ref Alias, either filled or applied, and on the bleed out event. I am not in a position to write an example code right now if you are not sure how to script, but if somebody doesn't beat me to it I could do this for you at some point tomorrow.

Oh cool, sounds like fun. Here's a link to ur Discord, maybe we can swap pointers or something :D https://discord.gg/np64PMu Mine works with static points placed around the world, or will work like that once I get back to the stage of actually pointing points on the map, the menu is doing my head in :D

Hey fancy meeting you here :D When I seen that post about the Pipboy, I figured that was the end of that story. Not much point to it now. Well the regular messagebox system it is, with 1s and 0s :/ @SKK,thanks for the reply. You working on some kind of spawn mod as well?

This is good info thanks. I'm rather confused though. I wanted to make a holotape menu, but I seen a post saying that the Pipboy is not an object reference therefore cannot apply any of this AddTextReplacement to it. As we know, message box can only deal in floats/ints for parameters but I'd like to show custom texts in place of these and also bools if possible. Such as Yes No On Off etc. So at this stage I'm leaning back towards using the message boxes instead if terminal. I will have to have a look at the mentioned example scripts here too. Edit: looks like messagebox menu with 1s and 0s is the road to sanity...

Hi folks, Decided to post and see if anyone is willing to help me in understanding and creating large scale, multi-level menu system out of the Terminal Menu for a settings holotape. I continue to study into it as well. So what I need to do is basically access and set variables on many instances of scripts, which are attached to quests. One of the problems I have been having trouble understanding is how to display different texts in the terminal, based on what values are currently stored on said scripts. So for example I would like to display the current value of the variable as well as show/hide options based on other variables. I have a problem with the Terminal Menu though, as opposed to MessageBox SWF menu where I can pass in parameters and display simple Ints, these menus require what seems to be quite fancy methods to do what I want. I can't really use Conditional scripts, because of the way things are setup, so conditions system is kinda out the door. Unless I'm understanding the whole idea of Conditional scripts wrong, I have many other things going on in the script, its not just purely for conditions, and it would be painful to setup a conditional script just to store a copy of said settings for menu use. So ideally, I'd like to be able to display ON or OFF for some bools that are true or false, display the current Int or Float Value of a variable, have different menu options appear based on some variables current setting. This is just the jist of it, if anyone has experience with these menus I'd much appreciate some advice. I know I am being vague on the details of the mod in question, it's for the Spawns of the Commonwealth mod which I am building to replace WOTC. I can do what I want with the MessageBox menus but users have expressed they'd like a holotape menu, and that I shouldn't use MCM for dependency reason which I am actually inclined to agree. Thanks for any input.

No worries itsbuffy. We will be hard at work over this weekend to get everything sorted and ready to start building in CK. @Everyone else, I am strongly considering starting a new thread soon as a fair bit has changed (although the core functionality detailed in he OP remains the scope/same). Some features were dropped given they were maybe considered too gimmicky or not worth the time, other features were brought in, and the same true for some of the customisation options.

Mmm this leads me back to darker territory. Thicket Excavations. If anyone recalls there is still a cell reset bug present, it happens for me here after the little mission and the water is drained. Anyway, I don't think it makes sense for the precombined to have a disabled object even considering the airport etc, how does/would the game know to switch the precombined mesh in? Or not load the material? And also considering modifying a cell and loading an esp that refers back to the vanilla data causing original precombined to appear on top... I'm not putting anything past it, something still doesn't seem right. Do you happen to be using the new ck version 1.10? Cos I'm seeing some strange behaviour with my stuff as well. Namely patches I generate, they work but then later crash the game, or outright crash the game now.

That can't be right man, some things up. I have tested this myself, although when I fixed up Greekrages Starlight mod, I had seen performance gains in disabling a lot of stuff he had left enabled, but the draw call count still seems high, too high, for the building he has. But then I think about the occlusion box in Monsignor in vanilla, disabling this allows generating around there to work as normal, where as it borks your gen if it's enabled. Are you positive you have removed all the No Previs flags from you WIP file? And confirmed tpc is showing as enabled in your test area in game?

Turf Wars is an optional system that can be turned on or off at any time from within the mod. It allows actors to vie for control of a region. Just to remind everyone, the Commonwealth alone has 13 regions. This can be turned on or off in any number or combinations of regions you choose. I will say a couple things about it. One is, you want a well balanced game (using Raider Overhaul as it is now you would probably end up with Raiders in control of everything) and Two is, it is meant to be in the later stages of the game so you probably want to use it it whether the Carnage Spawns preset. Unfortunately I cannot make this system as dynamic as I envisioned, I believe Bethesda also dropped their own version of this with the shipped game. Simply too many restrictions with the base game to do it through script alone, and the scope of this mod maintains that I will not edit vanilla, as to keep compatible with all mods. Thus this feature will just be a fun little mode to play around with.

General public update: Work restarted on the mod at the start of the month and work on the core scripts is almost done. Unfortunately I've dropped plug and play support for other mods however it still won't be hard to actually add new content from other mods. I have also taken away certain levels of customisation, mainly just the micromanagement, because it is taking too much time to deal with and highly likely users won't ever use or need such fine controls. You still get a shitload of options, don't worry ;). The only major thing to mention is that you will only be able to set a preset for all regions or per region, rather than per system. I have however devised and implemented a Turf Wars system. I won't go into further details yet, I'll leave it to your imaginations.

There was a beta and it was working sublimely, except the part where Papyrus started kicking my Properties out of the script or not filling them after a certain point. They've put a limit of 4096 bits to a single script. Either going to break it up a bit (which leads to some other added benefits from a coding perspective) or what I am trying really hard to do now is make the mod fully modular so that other authors can tap into it, however this is starting to look highly unfeasible for me to do because of micro management reasons. I have sorta had a break, but other things have been burdening me quite heavily, and while those things have let up I'm starting to make advancements in this job I'm in which is going to ensure that the only time I spend working on the mod will be in my own time, outside of the 42 hours a week I spend at work on average. Add 4 kids and a wife to that mix and do the math, you can safely say I'm pretty much at peak load. But the show must go on. Fortunately Bethesda games are pretty much my hobby, outside of building machines (which I do little of thanks to finances not permitting it :p ) @Nethan - you might try looking at FO4Edit to see if there is any direct conflict between mods here, particularly with precalc (cells records conflicting mainly) but otherwise you might be looking at that spot being maybe having a dud spawnpoint in WOTC.

That's possible, I haven't looked to deeply into it yet. My menu will be one of the biggest, if not the biggest ever seen though ;) We are thinking of going back to using Holotape now though, because on flash menus we can only display a list of 20 things (but there are other benefits).

Yes and no :( There has been no physical update to the mod itself. But I am developing new ways to tackle this severe problem with Papyrus. I'v needed a break for the past few weeks, but as much as I just wanted to play the game to get a bit more love for it back, I have been plagued by hardware issues (my own doing for buying new extravagant toys for my rig, as it stands the $900 monitor I just bought went back for warranty today). I've also touched on another project I was working on for the past 6 months, just for a bit of reinvigoration. You can see that here: https://www.nexusmods.com/fallout4/mods/26824? I hope to start work again full swing sometime before the start of October. You can follow our convos on the Discord server if you like. At the moment we've just been talking shiz for the past few weeks.