A great mod! I've wanted this mod for a long time, it would be even better if support more machines even support farmland that has not been watered, fertilized, and no-seed, and it can be configured separately or show bubbles only when pressed a key
Could you add an X offset config (or get the bubbles to align with UI zoom)? Currently I have my UI zoom upped and the bubbles are way off to the side from where they're meant to be :P
Thank you for the update! But you may want to increase the range - I have my UI zoom at 110% and it's not enough to make the bubbles line up. (I've attached an image so you can see what I mean - this is with X offset all the way into the negatives, and with bubbles enabled for all the defaults plus Dehydrators.)
According to the folks in the SDV Discord server, this happens when UI zoom and game zoom are different from each other (I have UI zoom at 110% but game zoom at 100%). While it's probably easier to just increase the config range, if possible a better long-term fix would be to account for UI zoom, although I don't know how feasible it is since I've never made a non-content-pack mod.
After some testing, I can't find a way to properly make the bubbles align with UI zoom. I considered just increasing the range on the offsets, but then I noticed that when you move, the bubbles ALSO move. So just increasing the range on the offset isn't enough to fix it.
I found that this issue only occurs when using zoom 100% AND UI zoom not 100%. If the zoom is set to anything other than 100%, then it doesn't matter what the UI zoom is, the bubbles will render in the correct position. Which is weird, but that's just seemingly the way it works.
That means that your only option is to play at a zoom level other than 100%. Which might be unfair because you might really like zoom level 100%.
Instead, I'll provide a new config option that sets the zoom level to 99%. Visually, it will be almost the same, if not the same as zoom level 100%. Functionally, because the zoom level is technically not 100%, the bubbles will render properly regardless of UI zoom level. Hopefully that is a fair solution.
I found that this same issue also occurs with other mods too (e.g. Better Friendship). So if you use that, then this new config option will also make those bubbles render in the correct position too, regardless of UI zoom.
Highlighted Jars still works and does basically what this mod does and would have saved you a lot of time. Works on Jars and Kegs, but nothing else (since you don't always want to make sure that everything is going).
Now that you have a big list of selectable machines, from a performance point of view, I would suggest you make a change to your code. That massive list of micro method logical OR calls, one each machine, is pretty harsh from a performance perspective. I mean every game tick (60p). I would suggest that on warp to a new map you build a list of enabled machines to walk in your Render method.
Such a change could also allow you to support any machine in the Data/Machines list. This would include Mod machines. Of course there is a lack of enable/disable for modded machines. Well, that too can be done but it is a bit of work. Loading the Data/Machines is something that should not be done per tick. On warp should be okay.
edit: ObjectListChanged may be a better choice than player warp for building a list of enabled machine objects.
Good point with getting the list of machines on ObjectListChanged and Warped instead of on render.
Although I'm not sure how to incorporate Data/Machines, because even after I load it and use it to filter out non-machines from Game1.currentLocation.Objects, I would still have to filter out machines that don't need bubbles to be rendered (e.g. Lightning Rods) or are disabled in the config. Or maybe I am misunderstanding how to make use of Data/Machines.
Well your current list gen filter code can just go into the Warp event. ObjectListChanged handles someone placing/removing a machine. Here you can edit the list generated in the Warp event. The list is used in Render. Render simplifies to just a list walk.
For using Data/Machines. That only comes in if you want to support machines other than your hard coded vanilla machines. Data/Machines is where Mod machines end up in 1.6. The Triggers field is how you can tell if something takes input. ItemPlacedInMachine. So if you did want to go this way then your filter logic does change some.
The objects list the game gives can be checked against the machine list to see if that object is a machine. Vanilla machine ids you already know about so really no need to check the machine list. You can of course treat them generic but you have fixed config enable code for these machines. So you can skip the machine list check, as you already know. Anything you do not know about you can check the Data/Machines list to see if the map object is in that list and if so then does it take input. If yes, then that map object gets added to your draw list. They are always enabled. Not too complicated.
Where it does get complicated is if you want to have a Config enable/disable feature for unknown machines.
Anyway, if you wanted to support Mod machines with your bubble, always enabled (no cfg), it is probably not too much work with the machine list. Might be simpler to make your own list of applicable machine ids from the Data/Machine list for easier/quicker compare during a filter operation (Warp).
Thanks for your detailed response, Norman! I'm learning a lot from this. I think that it's more reasonably optimized now. I also managed to add in support for modded machines as well, although without config support. I don't use any modded machines, but I think it should be a decent compromise for those that do.
You can optimize the RenderBubble method a bit more. You do not need the .ToList() where you are using the Enumerable Where method. Where is deferred execution. All it does is create "something" that actually enumerates the "something". ToList uses the enumeration and creates new fresh data in the form of a list. That data is used only once in a simple enumeration of the list and is then discarded. Sorry to be critical but that is a very very poor use of data.
Dumping the .ToList() executes about twice as fast on a shed with 60 empty kegs waiting to be loaded. In this case the Enumerator in .Where gets moved into the foreach statement. No intermediate one off data.
There is a slight further optimization that is very slightly faster, at best. Within margin of error in my one off test. However this is not within your coding style. Basically just foreach on the Machines list and have a "if" statement with your filter logic from .Where. Inside that if just call DrawBubbles.
This is an insanely big ask, so I completely understand if you say no, but I love this idea and was wondering if you could bring compatibility to the Machine Progression System mod? Regardless, thank you for your hard work and great idea!
32 comments
https://smapi.io/json/i18n/c2d858a787194bee83c7e9832c42383b
Thanks for your mod, have a good day !
It's a really good mod ^^
https://www.nexusmods.com/stardewvalley/mods/23307
According to the folks in the SDV Discord server, this happens when UI zoom and game zoom are different from each other (I have UI zoom at 110% but game zoom at 100%). While it's probably easier to just increase the config range, if possible a better long-term fix would be to account for UI zoom, although I don't know how feasible it is since I've never made a non-content-pack mod.
I found that this issue only occurs when using zoom 100% AND UI zoom not 100%. If the zoom is set to anything other than 100%, then it doesn't matter what the UI zoom is, the bubbles will render in the correct position. Which is weird, but that's just seemingly the way it works.
That means that your only option is to play at a zoom level other than 100%. Which might be unfair because you might really like zoom level 100%.
Instead, I'll provide a new config option that sets the zoom level to 99%. Visually, it will be almost the same, if not the same as zoom level 100%. Functionally, because the zoom level is technically not 100%, the bubbles will render properly regardless of UI zoom level. Hopefully that is a fair solution.
I found that this same issue also occurs with other mods too (e.g. Better Friendship). So if you use that, then this new config option will also make those bubbles render in the correct position too, regardless of UI zoom.
Thanks so much for your work on this mod!
Such a change could also allow you to support any machine in the Data/Machines list. This would include Mod machines. Of course there is a lack of enable/disable for modded machines. Well, that too can be done but it is a bit of work. Loading the Data/Machines is something that should not be done per tick. On warp should be okay.
edit: ObjectListChanged may be a better choice than player warp for building a list of enabled machine objects.
Probably both events.
You can probably just load the machine list at SaveLoaded. New mods with new machines are not really added during gameplay.
Although I'm not sure how to incorporate Data/Machines, because even after I load it and use it to filter out non-machines from Game1.currentLocation.Objects, I would still have to filter out machines that don't need bubbles to be rendered (e.g. Lightning Rods) or are disabled in the config. Or maybe I am misunderstanding how to make use of Data/Machines.
For using Data/Machines. That only comes in if you want to support machines other than your hard coded vanilla machines. Data/Machines is where Mod machines end up in 1.6. The Triggers field is how you can tell if something takes input. ItemPlacedInMachine. So if you did want to go this way then your filter logic does change some.
The objects list the game gives can be checked against the machine list to see if that object is a machine. Vanilla machine ids you already know about so really no need to check the machine list. You can of course treat them generic but you have fixed config enable code for these machines. So you can skip the machine list check, as you already know. Anything you do not know about you can check the Data/Machines list to see if the map object is in that list and if so then does it take input. If yes, then that map object gets added to your draw list. They are always enabled. Not too complicated.
Where it does get complicated is if you want to have a Config enable/disable feature for unknown machines.
Anyway, if you wanted to support Mod machines with your bubble, always enabled (no cfg), it is probably not too much work with the machine list. Might be simpler to make your own list of applicable machine ids from the Data/Machine list for easier/quicker compare during a filter operation (Warp).
Dumping the .ToList() executes about twice as fast on a shed with 60 empty kegs waiting to be loaded. In this case the Enumerator in .Where gets moved into the foreach statement. No intermediate one off data.
There is a slight further optimization that is very slightly faster, at best. Within margin of error in my one off test. However this is not within your coding style. Basically just foreach on the Machines list and have a "if" statement with your filter logic from .Where. Inside that if just call DrawBubbles.
This is an insanely big ask, so I completely understand if you say no, but I love this idea and was wondering if you could bring compatibility to the Machine Progression System mod? Regardless, thank you for your hard work and great idea!
Thank you so much! This is so awesome and I can't wait to give it a try!