Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Alfred Thayer Mayhem

#1
When shooting/throwing grenades at nearby targets, the graphical representation of the bullet or grenade is scaled proportional to the distance of the shot. This doesn't affect game play beyond making it difficult to see grenades thrown at close range and impractical (visually) to mod any kind of short range projectile weapon.

Normal bullets and grenades:




Squished bullets and grenades (ignore the spontaneous cleaning):




Test was run on a stock just landed colony. If I had to give an uninformed guess about what was going on I'd hazard that, if there are different Y values in the position IntVec3(s) used to track pawns, tiles, etc., when the Quaternion is pulled for the look rotation for targeting it adds a pitch down for closer targets.
#2
A few updates. I'm closing in on the point where integration with DS is becoming a pertinent design point; I've patched the stockpile zone creation mechanics to the point where they can reliably be placed under building_storage (and vice versa), while grow zones interact normally. Right now I've just got placeholders for the groupGrid modification logic.

In my initial experiments with modifying the groupGrid I've discovered another obstacle: I believe the "haul to better stockpile" job dispenser relies on cycling through the list of SlotGroups/ISlotGroupParents present in the HaulDestinationManager, and those are not modified with SetCellFor etc. When the haul destinations remain with no slots/overlap with slots in stockpiles the haul AI goes wacky and throws the "tried to create 10 jobs in a single tick" error (along with vapor locking the pawns). I think it will be necessary to implement a manager to handle the HaulDestinations and SlotGroups. Though not the quickest and easiest I suspect it will be less of a headache in the long run in terms of handling gizmos etc.

Differing priorities within slotGroups doesn't seem strictly necessary to me; I think the interface would be a little wonk, and if the player wants that kind of resolution they can draw a single or double stockpile under a given storage building.

Lastly, and most tricky, slotGroup.parent is used both for DS and the Beauty utility, and if I have a handle on things is how you chunk up the deep storage sections. The stored beauty element seems patch-able (beauty is already calculated on a cell by cell basis, so the patch would shift the check to Building_Storage in the same tile with IgnoredStoredThingsBeauty). Do you think something similar be possible for Deep Storage? I'm looking at the NoStorageBlockersIn patch now and am wondering how much the SlotGroups are tied into the rest of the logic.

*EDIT*: Perhaps I'm getting ahead of myself. Am going to investigate simply removing the SlotGroup cells from the Zone_Stockpile when Building_Storage is present and copying the Zone_Stockpile storage settings over to the Building_Storage. Splitting a Building_Storage up with multiple stockpiles could be accomplished with multiple SlotGroups and ISlotGroupParents attached to a single Building_Storage, and limiting a Zone_Stockpile to only use Building_Storage could be done by removing the base stockpile as a hauling destination, all without breaking any DS functionality.

**EDIT2**: The above would unfortunately remove the functionality for shelves as targets of bill drop offs. Going to investigate patching SlotGroupAt to pass the proper ISlotGroupParent.
#3
Thank you for your input, it definitely got me on the right track. Some hours later (and a very fruitful familiarization with the "Analyze" tool in dnSpy) I think I'm ready to throw out some more ideas.

I've chunked up the problem into a couple of sub-problems. The first is racking (addressed in your deep storage mod) and looks like a wheel that I don't need to reinvent at this time--attachable ThingComp system is indeed cool and flexible and exactly what I'm looking for. The second is the interaction between zone stockpiles and building storage, and I've boiled it down to the following elements:

Stockpile zones and shelves (or Zone_Stockpile and Building_Storage) store their physical positioning data in SlotGroups. Slot groups for Building_Storage are created and destroyed with the furniture according to the shape, with no native support for dynamically modifying it. Zone_Stockpile updates on a per cell basis when the zone is modified. Slightly more detailed step-by-step is shown below, mostly for my own sake (SlotGroup is one of those words that starts to sound funny when you say it in your head for the thousandth time).

  • Initialize Building_Storage w/ IHaulDestination, ISlotGroupParent, IStoreSettingsParent
  • New SlotGroup initialized by Building_Storage, SlotGroup initialization assigns Building_Storage as parent
  • For Thing SpawnSetup, Notify_NoZoneOverlapThingSpawned and AddHaulDestination called
  • Notify_NoZoneOverlap cleans up whatever zone is under the Building_Storage
  • AddHaulDestination calls SetCellFor on slotGroup.CellsList, modifying groupGrid in HaulDestinationManager
Removal of the Building_Storage clears the groupGrid. Adding and removing zones is a similar process, but the Zone_Stockpile SlotGroup is updated by AddCell/RemoveCell, with zone overlaps occurring upstream of that/preventing the creation of the zone.

Here are my thoughts/questions:

  • First, LWM I believe your deep storage uses Building_Storage SlotCells for some counting functionality or another (I haven't waded into it completely but I see that it's in there). That would preclude modifying the hauling grid upstream of the HaulDestinationManager, which is no great loss because that sounds like a mess anyway.
  • Modifying groupGrid is a much more attractive option (maybe. I understand I'm dealing with some fundamental things here). It's 2D (I think? The IntVec3 is ominous but I'm under the impression hauling happens on a 2D plane) so the odds of terrible priority conflicts occurring seem minimal, with the worst thing that can happen is a chopped up chessboard of permissions (obviously still not ideal).
  • The first main game function that needs to be modified is to allow the drawing of Zone_Stockpiles under Building_Storage, and prevent the deletion of Zone_Stockpiles when Building_Storage is built on top of them. This is a little interesting because the canOverlapZones check doesn't distinguish between zone types, but I recklessly estimate that it's possible to address that with a postfix that modifies the result of canOverlapZones if Building_Storage and Zone_Stockpile are true.
  • If all that goes according to plan we've got two stockpiles stacked up(!), so we need some decision making capability for determining what SlotGroup/storage permissions/priorities get passed to the HaulDestinationManager, and a (preferably) lightweight system for keeping track of the unused SlotCells (so they can be easily put back/don't roll under the metaphorical couch). Though initially intimidating, the IntVec3 presents some interesting possibilities; if the 3rd dimension is unused, Building_Storage slot cells could be bumped up a level and Zone_Stockpile slots bumped down. Somebody with more experience in the positioning system let me know if that's a bad idea. I also may be totally misunderstanding the groupGrid system, but cursory research indicates everything exists ∈{x,0,z}.
  • Back to the Building_Storage vs. Zone_Stockpile prioritization, we have two interaction states (shelf on stockpile w/ inheritance, shelf on stockpile w/o inheritance) and five state changes (shelf built on/removed from stockpile, stockpile added/removed under shelf, and presumably some button/gizmo to toggle between inheritance).

Let's number these out and spitball some (pseudo) pseudo-code:

  • Shelf added on top of stockpile: check for existence of stockpile. If exists, check default inheritance setting. If default is to inherit, leave group-grid unmodified, otherwise push Zone_Stockpile SlotGroup to elsewhere and replace with Building_Storage group grid. Will need to check each tile of shelf.
  • Shelf removed from stockpile: reverse, but restoring displaced stockpile SlotGroup/sanitizing unused shelf SlotGroup vector.
  • Stockpile added under shelf: check for existence of shelf, check for shelf inheritance, push one or the other based on result.
  • Stockpile removed from under shelf: check for shelf, sanitize/restore unused SlotGroup values to groupGrid.
  • Inheritance setting change: push/restore values in continuation of theme.
  • *bonus* For limiting stockpiles to only use shelves, we can check all Zone_Stockpile tiles for the existence of Building_Storage entities and flatten all other groupGrid tiles in HaulDestinationManager. Zone display stays for planning/future expansion, but the pawns won't leave stuff on the ground. I know the Zone class checks for continuity, but because the zone isn't actually being modified I'm mildly confident it won't blow up. This would also be accomplished with a gizmo, presumably after I figure out how to add them.

Whew. Anybody let me know if anything pops out at you as a very bad idea compatibility/performance wise (the checks seem pretty lightweight, I could be wrong). LWM, let me know if you think messing around with the groupGrid will have any unintended consequences specifically in regards to Deep Storage (and thanks in advance for chewing through another block of text if you do). Otherwise I'm going to see if I can slap something together in the next couple of days.
#4
Hello everyone,

Long time listener, first time poster. I'm looking to implement a mod to upgrade shelving; I've got a pretty good toolbelt in terms of computer programming (external to video games, mostly related to mechanical engineering analysis and micro-controllers--Python, C#, VBA etc.) but am just getting started with RimWorld (did some modding for Dwarf Fortress in my misspent youth). I'm confident in my ability to grind through whatever documentation or bugs I encounter on my adventures, but figured I'd throw some questions out to get me started in the right direction, save some time, and hopefully make something neat/useful. On to the main bit, skip to "My Vision" and "Hopefully Succinct Technical Questions" for the tl;dr.

Possibility for Improvement (as I see it): Shelves are currently marginally useful, limited to beautifying rooms where lots of otherwise ugly items reside and preserving items outdoors without need for roof + columns. Their lack of movement penalty makes their positioning a little cheesy, but requiring aisles without a corresponding increase in storage capacity is a losing proposition.


My Vision: Upgrade shelves with a moderate degree of racking/quantum stacking* (keeping piles separate for quality/condition tracking) while streamlining the priority, permission, and bill interaction mechanics for multiple shelves in one stockpile. If at all possible I'd like to implement a solution that is nearly seamless with the stock game.

*I gather this may be at odds with the current development policy of stockpiles always visually indicating their contents, but would respectfully like to give it a shot. It's my feeling that the "visually keeping track of stockpiles" ship sails anyway sometime in the midgame.


Technical Solution: It is my understanding that shelves are basically pseudo-mini-stockpiles (same permission systems, can't overlap with zoned stockpiles). My goal is to allow the placement of zoned stockpiles under shelves, and allow the placement of shelves inside existing stockpiles, so that the shelves inherit the properties of whatever zones they inhabit (reducing micro for lots of shelves). Additionally, it would be rather flash to optionally prioritize--on a stockpile level--that pawns place stacks in shelves (for shelves in zones) and forbid pawns from placing items on the ground (in zones with shelves), to effectively limit the usable storage space of a zoned stockpile to only the tiles with shelves on them.

Resulting Gameplay Changes: Unzoned shelves/stockpile zones without shelves operate unchanged except for increased shelf racking capacity. When the player wants to get everything up off the floor, however, they can zone a stockpile as normal, then place shelves within the stockpile to inherit the zone properties and (optionally) prioritize shelf storage (it is currently not possible to draw stockpile zones under shelves, and building shelves in zones removes the zoned stockpile underneath them). This system would simplify the placement of mass shelving and (hopefully) allow interaction with "place in specific stockpile" bill mechanics for single shelves (would be very useful when combined with RimFridge mod/if stock fridges ever come along, for example). In addition, double shelves could be split up into two 1-tile zones, a functionality useful for crafting ingredient storage (currently enabled by 1-tile shelf mods). The motivation for building stock shelves would be provided by the increased racking capacity and making everything look nice. My lifelong experience with putting things on shelves suggests 3x stacks per tile seems like a good number, permitting a reasonable increase in storage space when accounting for aisles (motivated by a modded movement penalty) and thereby rewarding the player for their effort in arranging and constructing the shelving.


Hopefully Succinct Technical Questions:

  • Seems like I'm messing with some fundamental stuff in regards to hauling and priorities. Does the partial integration of shelves and stockpiles seem remotely possible without hacking the game up/breaking compatibility with every mode in existence?
  • In that vein, am I better off adding this functionality to a new piece of furniture or somehow modding the stock shelf behavior? (former seems easier for a test implementation, latter seems ideal for mod integration)
  • I have a hunch that XML ain't going to cut it. What C# files/classes/existing mods can I look at to explore shelf/stockpile/hauling behavior? (no need to get too far into the weeds, just throw me some bones)
  • My experience with Python has taught me to always check first, but I haven't found anything yet: does this mod or something like it already exist?

Stretch Questions:

  • Assuming a generalized modification of shelf behavior (instead of a new piece of furniture), would a generalized modification of shelf movement penalties be possible?
  • For visual identification of things like racked weapons, has changing the position/rotation of a sprite within a tile been explored? (e.g., to get a tidy visual of three charge rifles racked up in a line)

Thank you for reading this far. I look forward to your input and hope you are all as well as can be in these trying times.