Messages

wth???  I didn't change anything to do with xml at all in this update.  That code is exactly the same as the earlier release.  What I did change was the export function which now is two-part (user editing and then bmp export).

I shall investigate and see if I can duplicate this.

I was playing around with separating the walls a little so there are walls for material types.  Largely because I didn't like that plasteel is stonger than stone (no....just...no) and architecturally, it just wrong.  A wood wall does NOT look, act, have anything in common aside from being a "wall" than a stone or metal wall.  Construction techniques, methods, structural engineering etc is all different when building with wood/stone/metal.

Anyway, I found that if buildings share the same uiIconPath, they will stack in the designators menu.  So, if your menu icon for "WallWood" and "WallStone" are the same, you won't see two icons like you expect.

Is there any other "kooky" behaviour like this I should be aware of?

What the derp...?

Can you send me the log file?  Perhaps I've borked something which doesn't show up for me...

WinRar is cross-platform and Win32, Win64, Android, Linux, Linux x64, FreeBSD and Mac OS X.  Not to mention being the proper tool for rar files (as it is their container format).

7zip will open rar files (as will many [de]compressors) but it's always better to use the native tool.  And 7-zip doesn't open "anything," but it does have a long list of what it can handle.

this looks amazing! Maybe you could add drones if you are removing the teleporters. Like an MD2 Ore collector being serviced by a adrone to pick up resources. Either by a extra 1x1 loading bay or directly from the extractor. Anyway im looking foward to using this mod with MD2.

Yeah, I doubt droids will every be added to this.  And as you pointed out...MD2 has droids, lots of droids.  A2B Conveyors + MD2 Logistics Droids = w1n.

Also, the MD2 Ore Extractor can connect and feed A2B loaders directly, no need for pawn hauling.

Updated to be "more" user friendly.  Now 0.000000000001% easier to use.

Yeah, I'll look through the code and see where/what changes would need to be made to accomplish the desired effect.  The changes are minimal the problem is from the modders side it's not practicable.

Yeah, I've been monkeying around and I found you're supposed to use MethodBase.MethodHandle.GetFunctionPointer() instead of RuntimeHelpers.PrepareMethod( MethodBase.MethodHandle ) except...it doesn't work either.  I've done self-modifying code and code injection with other development platforms (c, asm, x86, arm) and other tool chains (gnu) but I don't know enough about the C# lexer and emitter to know what my code is being translated into.  If I knew what it's producing, I could figure this out but my usual tools for debugging and disassembling just produce huge amount of wtf garbage.  RimWorld disassembled to 57M of crappy x86 assembly which was of no help.

It would be really nice if Tynan moved the code from the classes referencing the NPD directly into the NPD and used functions (public virtual please) in the NPD so we can mod the NPD and hopper system without potential unsafe code changing references the game assumes are otherwise static or using dirty work-around-hacks like I'm attempting.

The idea here is that the dispenser can be upgraded to better versions and more than one version of a dispenser can exist.  So you could have small dispensers which only serve small meals, for example, and/or another dispenser which can do various meals (including sythahol), etc.

To do this, the dispenser has to accurately report what it can make at a given time, ie, can it do fine meals but only has enough ingredients available for nutrient sludge?  Either way it has to report the meal it will make so the decision tree can properly choose between the dispenser which can do fine meals, the dispenser which can only do paste right now and the simple meal on the floor.  There are other things it needs to report/do as well in this process but for illustration purposes I think the above suffices.

If I can get this to work one way or the other, the dispenser will actually be a useful alternative to large kitchens and pawns cooking.  I built a dispenser in one colony and the only thing it saved was time cooking, the mood debuff and it's enormous size made it useless though.

You're both on right track but this is where I hit the wall.

The first method I tried was simply replace the building with a new one, no problem there.

Test it, uh-oh, pawns won't take from the new dispensers.  Ok, where is it used?  eep, everywhere:
Alert_PasteDispenserNeedsHopper (already dealt with and works)
FoodUtility.BestFoodSourceFor
FoodUtility.NutritionAvailableFromFor
JobDriver_FoodDeliver
JobDriver_FoodFeedPatient
JobDriver_Injest
JobGiver_GetFood
Toils_Ingest.TakeMealFromDispenser

And because FoodUtility has methods which need to be updated, so do other classes including...
WorkGiver_FeedIncapped
WorkGiver_Warden
Map.MapUpdate (method referenced isn't reliant on npd it seems so it's ok to leave)
ThingDef.SpecialDisplayStatus (not fully investigated)

So, I would have to modify all those and I did with the exception of Toils_Ingest since there is a lot going on there and it's hidden from the debugger/decompiler.  I did re-create the code for all the other hard-coded classes though and updated the xml to reflect the changes.  When done all that, I just got null reference errors when anything looked for food, being it animal or human.

This is where I switched tracks to doing a minimal code replacement and just inject the new methods.  This means I would only have to recreate the building (done) and alert (done), then inject the code (done but fails).

So, I have two paths which lead to results which only partially work.  The first attempt to recode it all but got snagged when dissecting Toils_Ingest, the second where the code injection reports success but nothing happens.

Trust me, I didn't wake up and say, "code injection!"  This was more of a last resort since some methods/classes are private/sealed/internal.

New additional selector components as a mod add-on available now, see the OP!

Gives you a total of 12 selectors for all your Rube Goldberg configurations!

Original thread [locked]: A2B - Selector Options

This add-on requires: A2B Conveyor Belts

Not affiliated with A2B Corp. in any way.

Your mod order needs to look like this:

Code Select Expand

RW_A2B
RW_A2B_Selector

This adds additional options for selector components.  It expands the options from the single core selector to a total of 12 different selectors.

There are five new selectors with different pathing options and six selectors which are "soft" filtered variants.  The difference between the normal ("hard") filtered selectors and the "soft" selectors is that the "soft" selectors will send an item which would be filtered to an alternate path if the filtered path is blocked.

The new selectors will show up in a new tab "A2B Selectors" beside the "A2B" tab.  The original selector has not been moved.  The same research is required to access the new selectors as the original - "[A2B] New Components".

The selectors are in individual xml files so you can remove the ones you don't want (all are enabled by default).


[attachment deleted due to age]

I've done all that, actually. See the OP attachments.

The injection example is the same code you found that I did it seems, it's been slightly modified (Intel parameter ordering instead of AT&T parameter ordering) and I added an additional test case (sealed classes).

Testing is Community Core Library with the injection code in a sub-project (compiles to Community Core Injection) along side the main project (Community Core Library) injecting the new dispenser methods.

Here you have hook bridge that i use for multistructure machines

...

and here is code for code for hopper :

...

this way you can hard hook to any other custom class building and call there public method and acces public var.

But if you cant inject in dispencer class (but whot for if you can override it just) make work around .

Everything hopper related works fine actually.

It's the dispenser which doesn't because it's using a hard-coded reference which I can't dynamically change as it may break underlying logic which may be between states and are assuming the reference to be otherwise a constant.  So, I tried to replace the methods to the new methods which can handle the additional functionality and are injected in place before the IL JIT happens.

The problem is that it doesn't inject properly it seems.

@Acruid:  I've tested the injection example under mono building against .NET 3.5 and that works.  But if Unity is using a modified version I will have to explore what changes it's made and maybe making the necessary adjustments will work.  Hopefully it's just a matter of binding to the proper CLR and that it supports the hacks I'm attempting.

Also be aware that on game load, ExposeData is called before SpawnSetup.  I discovered this by setting default value in SpawnSetup and expecting ExposeData to be called after.  ExposeData is not called when the building is first created (eg, when the wall blueprint is complete, SpawnSetup is called on the wall but ExposeData is not).  So you need to make your variable initializers use default values for those that need them.