Please Fix the Battery Creation and Recharge Exploits
Jacke
Calgary Join Date: 2017-03-20 Member: 229061Members
Calgary Join Date: 2017-03-20 Member: 229061Members
There are exploits to get around both creating and recharging batteries. I really think they should be fixed.
Information current as of Experimental 54573.
Exploit #1. Create alternate-cost Batteries via the Repair Tool blueprint.
The Repair Tool blueprint creates a fully charged Battery inside the Repair Tool without needing Copper, using mats more easily obtained than Copper:
Silicone rubber + Cave Sulphur + Titanium => Fabricator => Repair Tool (100% charge)
While Cave Sulphur can be tricky to get, its only uses in early game are for Flares and Repair Tools. Not a big demand. So with the other mats each Cave Sulphur can be made into a Repair Tool, which has a fully charged Battery inside that can be extracted and used anywhere. This exploit is made worse together with the recharge one, as this one then only needs to be done to create enough Batteries.
Exploit #2. Recharge Batteries for trivial cost via the Scanner blueprint.
Currently, blueprints with a Battery as a component ignores the charge of the incoming Battery and always make a fully charged Battery in the created item. This means by consuming a single Titanium, a Fabricator can recharge a Battery via the Scanner blueprint:
Battery (0% charge) + Titanium => Fabricator => Scanner (100% charge)
The fully charged Battery can then be extracted and used elsewhere.
To fix these exploits there are two approaches, which can be both be used.
Solution #1. Make the blueprints of items that contain a Battery require a Battery as a component. And transfer the charge state of the component Battery to the charge of the Battery in the created item.
The Repair Tool blueprint would then become:
Silicone rubber + Cave Sulphur + Titanium + Battery (X% charge) => Fabricator => Repair Tool (X% charge)
and similarly all other blueprints would carry over the charge of the component Battery to the created items' internal Batteries.
Solution #2. Make the blueprints of items that use Batteries create the items empty of their Battery.
The Repair Tool blueprint would then become:
Silicone rubber + Cave Sulphur + Titanium => Fabricator => Repair Tool (no battery)
and similarly other blueprints could be changed to drop the Battery component as well as creating the item empty of a Battery.
This second solution might not be such a good idea as some players may not realise their tools come "batteries not included". Perhaps better to do the first solution.
Information current as of Experimental 54573.
Exploit #1. Create alternate-cost Batteries via the Repair Tool blueprint.
The Repair Tool blueprint creates a fully charged Battery inside the Repair Tool without needing Copper, using mats more easily obtained than Copper:
Silicone rubber + Cave Sulphur + Titanium => Fabricator => Repair Tool (100% charge)
While Cave Sulphur can be tricky to get, its only uses in early game are for Flares and Repair Tools. Not a big demand. So with the other mats each Cave Sulphur can be made into a Repair Tool, which has a fully charged Battery inside that can be extracted and used anywhere. This exploit is made worse together with the recharge one, as this one then only needs to be done to create enough Batteries.
Exploit #2. Recharge Batteries for trivial cost via the Scanner blueprint.
Currently, blueprints with a Battery as a component ignores the charge of the incoming Battery and always make a fully charged Battery in the created item. This means by consuming a single Titanium, a Fabricator can recharge a Battery via the Scanner blueprint:
Battery (0% charge) + Titanium => Fabricator => Scanner (100% charge)
The fully charged Battery can then be extracted and used elsewhere.
To fix these exploits there are two approaches, which can be both be used.
Solution #1. Make the blueprints of items that contain a Battery require a Battery as a component. And transfer the charge state of the component Battery to the charge of the Battery in the created item.
The Repair Tool blueprint would then become:
Silicone rubber + Cave Sulphur + Titanium + Battery (X% charge) => Fabricator => Repair Tool (X% charge)
and similarly all other blueprints would carry over the charge of the component Battery to the created items' internal Batteries.
Solution #2. Make the blueprints of items that use Batteries create the items empty of their Battery.
The Repair Tool blueprint would then become:
Silicone rubber + Cave Sulphur + Titanium => Fabricator => Repair Tool (no battery)
and similarly other blueprints could be changed to drop the Battery component as well as creating the item empty of a Battery.
This second solution might not be such a good idea as some players may not realise their tools come "batteries not included". Perhaps better to do the first solution.
Comments
https://forums.unknownworlds.com/discussion/152836/i-will-never-run-out-of-batteries-already-now-that-batteries-dont-need-copper-hurray#latest
In my opinion, the DEVs made the repair tool / scanner recipes easy so new players can get started in the game more quickly. I wish there were some way to code it so that you could only ever create one of each tool. But I know that would create its own sort of headaches when people misplace those tools and thus want to craft another one.
I had another idea:
What if the recipes for both tools were much more complex but you could create the first version of each tool using some resource found in the Life Pod? For example:
Repair Tool Recipe : "Old" Repair Tool found in Life Pod 5 plus other stuff you find easily.
If they want to make the Scanner Recipe only require a battery plus a piece of titanium, then the easy solution is to just directly transfer the charge from the battery to the new scanner as mentioned by other folks much smarter than me.
New players probably wouldn't learn how to game this until after it no longer mattered.
If wanting to really solve it though, a lazy solution without causing balance issues would be to add an 'unstable power source' battery they spawn with by default which is destroyed on removal.
I think pursuing that solution would be more difficult internally and likely to cause bugs. Going with Solution #1, adding a Battery to the Repair Tool blueprint and having item creation carry over the charge state of component Batteries is more likely to solve this and not create further issues once implemented.
While it's logically simple to just pass the value of the battery being used to make a tool to the value of the battery in the tool, from a coding standpoint, it's probably not possible without a lot of reworking. Function calls have established value passes; software functions can't just access all of the data being used by the application - the programmers decide which variables are needed and pass only those. "Okay, so just add those variables." Usually not as easy as that when the function wasn't designed that way from the start. Adding variables - particularly ones which will have values altered and passed back to the main function - is a pain. If you hadn't counted on having to do that, you'll probably have to create a new variable to handle the value manipulation. "So add the new variable." Again, this creates all kinds of potential knock-on effects...we call them bugs. Your function calls the wrong variable, or you update the wrong variable, or the math references the wrong variable, or this function calls everything correctly but that one is still using the old variable names - speaking from an abundance of personal experience, it's a pain, and that's being excessively polite.
It is, however, relatively straightforward to adjust which objects a function creates in a game world - and when it comes to whether an object is "loaded" in some form, it's even easier; you set the state flag or the variable state to whichever setting you've established as "it has nothing" and wham, you're done. So if the UWE coders decided that a device without a battery has a charge value of -1, then you set the default charge value not at 100 like it is currently, but to -1. Now the new whatzit doesn't have a battery and the exploit is closed.
There's a reason programmers like Occam and his razor.
When the Battery is removed from a device, the program creates a Battery with the current charge state of the item and puts it into inventory, then changes the item to have no battery. When a Battery is exchanged, the program creates a Battery with the current charge state of the item, then sets the charge state of the item to that of the incoming Battery, then destroys the incoming Battery.
That code could be used or adapted to work for the Fabricator as well.
Sorry; didn't mean to impugn your coding knowledge.
Absolutely this needs fixing; it's an immersion-breaking exploit. It could be handwaved by saying that the fabricator charges the battery during the process, but that just reeks of weak retconning and actually kinda makes it worse.
The battery exchange point is valid, but don't forget that's calling a different function; the variable passes for item creation probably don't include battery state because, well, they never have (or at least never have shown any evidence of doing so). Adding that function could be a problem. Even kludging the battery-exchange function into the fabrication function probably wouldn't work, since I doubt the fabrication function receives any variables - the ingredients-present check is probably run before the function is even called and the items are removed from inventory before the fab process is started, so the object has probably already been deleted from the database.
But I think you're onto something. If a global slop variable were created to store the battery's charge before the objects are removed from the player inventory, the fabrication function called and executed, the new object created, then its charge remaining variable set to the temp value...that should do it, and wouldn't involve modifying the fabrication function at all. Plus, we're only adding one int var, so it's not like there's going to be any performance impacts.
int batt_chg=0;
if(inv_diamond >= 1 && inv_titanium>= 1 && inv_crash_powder >= 1 && inv_battery >= 1){
batt_chg=0;
batt_chg=inv_battery.charge;
Fabricate(laser_cutter); //Assuming that the Fabricate function is a void and handles inventory deposit without a passback
inv_laser_cutter.charge = batt_chg;
}
Technically, that slop var could be used for nearly any temporary-hold feature, which means that there could well already be a temp var for that purpose.
Alternatively, the object_ID could be pushed into a storage variable, the fab process run, and rather than having a new battery object_ID created, dump the stored object_ID into the new container (the tool)...but that would probably mean being able to pass the object_ID to the fabrication function, and it doesn't look like the function can take that.
Either way, you're right on both counts: it's a loophole that needs fixing and it should be very plausible to get it done. Personally, I'm behind the "no included battery" approach purely for the sake of simplicity, but the value-set approach should work, too.
Say, three batteries: That would give you enough for a Scanner, Repair Tool, and Seaglide.
The mats for batteries are easy to find for the most part: copper is the one thing you may have to dig a bit for, whereas acid mushrooms are everywhere... *EVERYHWHERE*.
There are also tons of batteries in vacuum packs around the world. I have two full battery chargers, *and* about 10 spare batteries, *and* all the tools I've crafted, and only created perhaps one or two batteries in total.
Batteries and cells are separate parts, they should be independent.
https://trello.com/c/7JJZqCVE/6655-address-battery-exploit-in-welder
I assume this is in response to being able to just spam build welder (Repair Tool) for free batteries.
Good. The recharge exploit by crafting a Scanner with a dead battery still needs to be fixed too.
However I would suggest only two batteries. To me the seaglide already marks the transition from the early game to a more exploratory phase, one that will require more batteries to fulfill their exploratory needs.
Couldn't they just save the charge of the ingredient battery to a new variable. After the item is fabricated (with a fully charged battery) add a single function call that would change the new battery charge to the one previously stored.
Please don't think I'm being condescendent. I consider myself to code at a very basic level, so I might really be missing the mark.
In theory, yes. But there would need to be a new variable for each battery, and then you'd have to mess with the battery charger code and the loot crates...
I still fail to see it. The variable I suggested doesn't need to exist outside of the fabrication loop.
You create the variable after initiating the fabrication process (only if it require batteries), after the process is complete (but before the player access the item) you change the battery charge level to the stored variable and then delete the variable.
Nothing else would change in the game.
You would then have to create two kinds of "battery" objects, one being the crafted battery, and one being the one found in boxes. When each battery is made, it must be of the crafted variety. Having two kinds of batteries would make modding EVERY RECIPE using a battery, because there would need to be two recipes, one for each kind of battery. You'd also have to modify the charger. Also, deleting a variable inside said fabricator loop still uses memory, so it would possibly create lag. The battery power level itself is a variable, and, in at least the languages I've coded in, deleting a variable can have far - reaching effects in other joined programs.
Can you please explain why you need two kinds of battery objects? All batteries in the game already have a charge already.
As @Maalteromm has said, we only need for the Fabricator to transfer the charge from the battery that is an ingredient to the battery contained in the fabricated object. The battery ingredient already has a charge, and the battery in the constructed item also has a charge. This is only a very simple problem of making the fabricator transfer the charge from the input battery to the battery contained in the "output" constructed item.
As @Maalteromm mentioned, any variable has a very short life as it exists only for the milliseconds required to construct an item and is used to insure the charge is transferred from the input battery to the battery in the output object.
I cannot figure out why you would think there need to be two kinds of batteries; all batteries have a charge. We are simply talking about making the fabricator "preserve" the charge of the input battery and transfer it to the battery in the constructed object. So, instead of getting a scanner with a 100% battery when constructed with a 15% battery, you instead get a scanner with a 15% battery.
This should be a trivial piece of code to write, I think. And, it should be trivial to test.
Here is what I'm reading in the previous posts:
1. @scifiwriterguy wants to avoid changing the fabricator code. I assume his approach requires new battery objects.
2. @Maalteromm *does* want to change the fabricator code. Zero changes to batteries.
Assuming I'm understanding what @Maalteromm is suggesting, there are NEVER any changes to the batteries in his approach. Rather, there is only a change to the fabricator itself. The fabricator reads the charge of the batteries and transfers that charge to the output battery. All batteries in the game already have a charge. It's just that the fabricator doesn't consider the charge of the battery used to construct an item. There are no changes to batteries. All batteries are exactly the same. The changed code is only in the fabricator. Again, I think @scifiwriterguy wants to avoid changing the fabricator while @Maalteromm *does* want to change the fabricator. I agree wholeheartedly with @Maalteromm's approach.
Actually, I share the opinion of @scifiwriterguy and others, as stated above and repeated here:
However I would suggest only two batteries. To me the seaglide already marks the transition from the early game to a more exploratory phase, one that will require more batteries to fulfill their exploratory needs.
However I got intrigued by the supposed difficulty to change the batteries charge level, since it looks super simple to me.
@kingkuma
I cannot see the difference between batteries crafted and batteries found on the environment. And the memory used/possible lag should be negligible since it's probably a small, single precision, float number that will exist for no more than a few seconds.
It sure is funny, but it is no loling matter for the devs.
They will certainly fix it before launch, as indicated by the SN development trello you linked yourself.
Whatever path they choose, will require changing code. Both solutions seems simple enough.
To me it will probably be a matter of game design instead of programming. Is it more immersive to spawn the item 'use ready' or make the player 'reload' the item before its first use?
Another solution that we didn't even explore (and that should also be simple) is to force the player to use fully charged batteries while crafting.
Personally, I find this discussions super entertaining.
1. Use six Titanium to make six scanners to recharge my batteries, or
2. Build a battery charger, load 4 batteries, wait for them to charge, and load the remaining two batteries.
I have a ton of Titanium. So, I'm probably just going to burn the six Titanium to quickly recharge my six batteries.
I REALLY hope they didn't use floats for these things. Horribly inaccurate with progressive problems as you do math on them. A simple int will more than suffice to represent what a battery charge needs to be.
While I agree the implementation should be fairly simple, I'd actually prefer they just make everything craft without batteries. I'd find it more enjoyable to have to craft the power I need to run them from the beginning.
It's a vice really,
I can't work with ints, so to me every number in a computer is a float.
Actually, I'm not advocating any new objects at all. Sorry if it came off that way.
My suggestion was to remove batteries completely from the fabrication recipes. Players then fabricate a battery separately and install it in whatever device. The same base object that batteries ever were, only now no longer part of the finished fabrication routine. We've no need to create a new object class. (As a side bonus, it also introduces players to the battery replacement mechanic in the game. Build your new tool, stick a battery in it.)
Changing code is a problem. Always. Whenever you start messing with code that works, you run the very serious risk of ending up with bugs you never had and, really, never needed to have. As a result, you only mess with your code when it doesn't do the job it needs to do or it's become bloated. The fabricator code works. Adding new variables to push around values that, in the end, don't need to be pushed around is just inviting headaches. It's a lot easier, simpler, and safer to update an object or case table to remove a result than it is to muck around with the function itself to play musical chairs with a variable.
When you're at alpha build stage, sure, code editing is part and parcel with creating the product. But when you're in a nearly finished state, going back and changing function calls that are fundamental to the operating of the software as a whole is irresponsibly dangerous except in the most severe circumstances. (And this is experience talking - having to build a machine language compiler is a powerful learning experience on the comparative value of code editing.)
Simpler solutions are nearly always better. Faster, cheaper, and safer.
If the game properly introduces the players to the concept that they are crafting items "batteries not included" and playing with "batteries not included" doesn't have sufficient impact on the players to handle all new items as "batteries not included", then the two solutions are close to equivalent in their impact on the use cases.
But pursuing the "batteries not included" solution means more has to be done besides just changing the blueprints to exclude batteries and to have them produce items empty of batteries. The game will have to introduce new players to this important concept. The worst cases won't be the Seamoth, Cyclops, or PRAWN, as they won't move without power. The problem is if players keep making tools and swim out without realising there's no batteries in the tools. If they have enough spares in their inventory and have sufficient knowledge to know how to fix things, great. Assuming they're not dead because of this.
And adding such an important gameplay tutorial section to a game this close to release is an issue in itself. And I think changing blueprints and the Fabricator and Mobile Vehicle Bay to make items with no batteries in them aren't trivial either. So both solutions have their own complexities.