You seem to be quite proficient in writing good mods, was thinking of a mod, don't know if its possible. Want the scanner/visor to work while in a exocraft, for searching for hotspots, don't you think that'll be awesome?
Could you just sorta toss the scanner out the window. and have the hotspots show up with a ship scan? similar to this https://www.nexusmods.com/nomanssky/mods/2600?tab=description But you know just focused on the hotspots. Or do they actually not exist in the world untill you scan them, so it would be actually super impossibe.
man i really dont want to search these worlds anymore.
Alright well thanks for entertaining the idea. I went and learned how to do some basic text edit modding of the game. and bumping up the survey range/speed helped me find those S class hotspots LOL. I spent less time learning how to mod it than I did looking for these stupid things.
Seems to be faulty for Worlds Pt1. When this pak is active, placing any electricity generator or using the electrical hotspot survey visor causes an instant and very consistent crash. Edit: While this mod page doesn't have the lua for its most recent versions, the big gurmsk mod collection does. gHot is in the uncommonly updated pack, and when I used the lua, I was able to make an updated pak that does not cause the crashes. If anyone is having the same problem, do that.
Using old pak files (aside from the few that are only texture or shader replacements) is a bad idea.
Since most mods edit some MBIN files and repackage the entire file (MBINCompiler translates the MBIN to an EXML file and back again) in the mod pak. Using an old file omits any new data that should exist in the file (not all MBINs are changed every patch so sometimes works) for the current patch (which may crash or cause other odd behavior when the game tries to use the missing data).
Rebuilding from the Lua modifies the current MBIN according to the instructions in the Lua (when doing a merge it applies a series of Lua files [in alphabetical order, same order that NMS loads mods] to the same copy of the file before repackaging it).
i dont know whats going on but your mod makes my extractors have "infinite" ores, no matter how much i take out of my extractor storage it never decreases, please help me with this issue. thanks
I was trying to use the LUA scripts with AMUMSS to build the mod (from both the AMUMSS's library and the nexus download for Gumsk's Mods), yet I noticed I get this for all class weighting and strength values:
?Based on PRECEDING_KEY_WORDS: >>> {"Power","ClassWeightings",}, <<< Looking for >>> ["6"] New value will be >>> [20] of type [NUMBER] >>> Replace operation is [ONCE] based on key_words: {"Power","ClassWeightings",}, >>> INTEGER_TO_FLOAT is [FORCE] >>> Searching in lines 14-19... [[NOTICE]] NO Replacement done. Could be Ok, you decide... [[WARNING]] No action done!
Checking the MBIN's shows the line numbers are correct (IE. 15-18 has class weightings C to S) and the values are correct (10/6/2/1) for power as an example to the Original_Hotspot_Array that I've not modified, yet it is failing to actually change those values and I'm not sure what is going on there or how to resolve that myself.
The way the LUA is written it can never have worked. It tries to use the old value of the lines as key, but according to the documentation that does not work.
They changed the file structure with 4.0 and added value names, which broke the script and I didn't get it updated. Thanks for the fix. I'm going to rewrite the script mostly I think to take account of the changes.
Hello, I have run this mod through amumss to update it to fractal, and although the mod does work, there are a couple of serious flaws present. The first is that this mod changed a C class sodium mine to an S class parafinium. I have no idea why this mod would change the resource type, but though this is annoying, the most serious error, is that on one of my bases, it changed the mineral extracted to an S class cobolt mine, but there is no cobolt listed as a resource for this particular planet.
Is it possible that with fractal, that the lua script needs to be updated again?
I downloaded and used the latest provided lua.
It would be appreciated if you could take a look at this and see if you can adjust it so that it does not change what an existing mine is producing, and that it only extracts what is available as a mineible resource on a planet.
The issue of changing resources at hotspots is expected and should be due to the ProbabilityWeighting change. Default is to have all resources equally likely, and I have it changed to something I consider more balanced. If you want to test without these changes, in the Lua change the second line in the New_Hotspot_Array (the first line of numbers) from 25,20,13,9,20,13 to all 1. That will remove the probability changes and hopefully prevent the resource changes.
As to it changing to a resource that shouldn't even be on that planet, that is unexpected and I've never heard of it before. I would need time to test it, which I don't have right now, unfortunately. In any case, the ProbabilityWeighting change above will likely address this as well.
After making the changes that you suggested, I can confirm that the hotspots revert back to what they were originally, and are still s class.
After checking my bases, the resources collected are all back to what is available on the planet. It is a shame that this happened, as I like the weighting that you gave the hotspots.
I had set all my bases up to gather resources for my stasis device farm ship. I use the method of mines, posted by a helpful steam community member to obtain all of the required resources, rather than using plants, as it was getting a bit much with 40 plus bio-domes worth of plants. I cut this down to 1 bio-dome per plant, which is more than the guide says, but gives a larger starting amount when expanding the resources in the refiners, so when this mod changed things, I was a little concerned, but the one issue that really stood out, was having a resource on a planet that was not meant to be there.
I understand that real life duties come before recreational projects, so I will gladly wait to see if you can locate the issue and fix it some time in the future.
Had to uninstall due to the mod doing weird things.
Just installed this mod and went looking for activated indium. I found an A class spot but once scanned the max density was only 33%, went a ways away and found another mineral deposit that was class C and once scanned its max density was 8%.
I went back to the original A activated indium spot and saved then removed the mod. When loading back in it turned into an A class dioxite deposit but the max density was back to 80% that it should be for an A class.
sadly I can confirm this as well for electromagnetic hotspots, found an B-Class spot which was only max 16% and produced only 182KP. This could be related to new defined min-max ranges in the lua-file?
But I'm more confused about some defined variables in the gHot.lua file: PoleSpacing,HotspotsPerPoleMin, HotspotsPerPoleMax, SpacingSameCatMin and SpacingDiffCatMaxOverlap Because they are not used in that file and won't have any effect if I'm right.
The Game use the value for the highest yield (the S spot) as 100%, so lower yield spots will show lower % value even when they give as much as they did before, it's the yield per % the is changed.
So, all the chances between C, B, A, S, add up to 100%, so if I wanted to make the chance equal across the board for C, B, A, and S, I would just give them all a 25% chance.
I like the way you rebalanced the output and it's WAY easier to find a power hotspot but I'm still spending a lot of time (about 4 hours so far) trying to find an S-Class activated indium hotspot. I started wondering (what else to do with 4 hours of jetpacking through the air and scanning right?) would you consider making a version of your mod that keeps your modified output but makes ALL hotspots S-Class? Also having an equal chance for each mineral would be cool I have found a few S-Class hotspots but they're pyrite not activated indium (fool's gold instead of blue gold lol) just looking to reduce the grind.
Try the gHot All S file I just uploaded. It should make all the mineral and gas hotspots equal and all hotspots should be S. I haven't tested it at all, so you'll have to let me know if it works.
Thank you for the awesomely fast response I almost went to bed without checking for a reply or an update. I flew and scanned for about 15 minutes and the power hotspots were all S-Class and I found one of each mineral hotspot also all S-Class so the mod appears to be working great. I'll check the gas hotspots in the morning just to be 100% sure but I think you nailed it! Thanks again good stuff.
41 comments
Want the scanner/visor to work while in a exocraft, for searching for hotspots, don't you think that'll be awesome?
But you know just focused on the hotspots. Or do they actually not exist in the world untill you scan them, so it would be actually super impossibe.
man i really dont want to search these worlds anymore.
I went and learned how to do some basic text edit modding of the game. and bumping up the survey range/speed helped me find those S class hotspots LOL. I spent less time learning how to mod it than I did looking for these stupid things.
Edit: While this mod page doesn't have the lua for its most recent versions, the big gurmsk mod collection does. gHot is in the uncommonly updated pack, and when I used the lua, I was able to make an updated pak that does not cause the crashes. If anyone is having the same problem, do that.
Since most mods edit some MBIN files and repackage the entire file (MBINCompiler translates the MBIN to an EXML file and back again) in the mod pak. Using an old file omits any new data that should exist in the file (not all MBINs are changed every patch so sometimes works) for the current patch (which may crash or cause other odd behavior when the game tries to use the missing data).
Rebuilding from the Lua modifies the current MBIN according to the instructions in the Lua (when doing a merge it applies a series of Lua files [in alphabetical order, same order that NMS loads mods] to the same copy of the file before repackaging it).
?Based on PRECEDING_KEY_WORDS: >>> {"Power","ClassWeightings",}, <<<
Looking for >>> ["6"] New value will be >>> [20] of type [NUMBER]
>>> Replace operation is [ONCE] based on key_words: {"Power","ClassWeightings",},
>>> INTEGER_TO_FLOAT is [FORCE]
>>> Searching in lines 14-19...
[[NOTICE]] NO Replacement done. Could be Ok, you decide...
[[WARNING]] No action done!
Checking the MBIN's shows the line numbers are correct (IE. 15-18 has class weightings C to S) and the values are correct (10/6/2/1) for power as an example to the Original_Hotspot_Array that I've not modified, yet it is failing to actually change those values and I'm not sure what is going on there or how to resolve that myself.
Change:
? {
["PRECEDING_KEY_WORDS"] = {tostring(Original_Hotspot_Array[1][i]), Preceding_Array[j-1]},
["VALUE_CHANGE_TABLE"] = {
{tostring(Original_Hotspot_Array[j][i]), tostring(New_Hotspot_Array[j][i])}
}
}
To:
? {
["PRECEDING_KEY_WORDS"] = {tostring(Original_Hotspot_Array[1][i]), Preceding_Array[j-1]},
["VALUE_MATCH"] = tostring(Original_Hotspot_Array[j][i]),
["VALUE_MATCH_TYPE"] = "STRING",
["VALUE_CHANGE_TABLE"] = {
{"IGNORE", tostring(New_Hotspot_Array[j][i])}
}
}
I have run this mod through amumss to update it to fractal, and although the mod does work, there are a couple of serious flaws present.
The first is that this mod changed a C class sodium mine to an S class parafinium. I have no idea why this mod would change the resource type, but though this is annoying, the most serious error, is that on one of my bases, it changed the mineral extracted to an S class cobolt mine, but there is no cobolt listed as a resource for this particular planet.
Is it possible that with fractal, that the lua script needs to be updated again?
I downloaded and used the latest provided lua.
It would be appreciated if you could take a look at this and see if you can adjust it so that it does not change what an existing mine is producing, and that it only extracts what is available as a mineible resource on a planet.
As to it changing to a resource that shouldn't even be on that planet, that is unexpected and I've never heard of it before. I would need time to test it, which I don't have right now, unfortunately. In any case, the ProbabilityWeighting change above will likely address this as well.
Thank you for your reply.
After making the changes that you suggested, I can confirm that the hotspots revert back to what they were originally, and are still s class.
After checking my bases, the resources collected are all back to what is available on the planet. It is a shame that this happened, as I like the weighting that you gave the hotspots.
I had set all my bases up to gather resources for my stasis device farm ship. I use the method of mines, posted by a helpful steam community member to obtain all of the required resources, rather than using plants, as it was getting a bit much with 40 plus bio-domes worth of plants. I cut this down to 1 bio-dome per plant, which is more than the guide says, but gives a larger starting amount when expanding the resources in the refiners, so when this mod changed things, I was a little concerned, but the one issue that really stood out, was having a resource on a planet that was not meant to be there.
I understand that real life duties come before recreational projects, so I will gladly wait to see if you can locate the issue and fix it some time in the future.
Just installed this mod and went looking for activated indium. I found an A class spot but once scanned the max density was only 33%, went a ways away and found another mineral deposit that was class C and once scanned its max density was 8%.
I went back to the original A activated indium spot and saved then removed the mod. When loading back in it turned into an A class dioxite deposit but the max density was back to 80% that it should be for an A class.
This could be related to new defined min-max ranges in the lua-file?
But I'm more confused about some defined variables in the gHot.lua file: PoleSpacing,HotspotsPerPoleMin, HotspotsPerPoleMax, SpacingSameCatMin and SpacingDiffCatMaxOverlap
Because they are not used in that file and won't have any effect if I'm right.
The key to look for in the GCGAMEPLAYGLOBALS for the HotspotScan Range is now called "SurveyMaxDistance"