If you wanna have different objects using the same routine, put this under any 'CustObjXX' label:
LDA #$yy ; Initial index
CLC : ADC $xxxx ; RAM which is either 0 or 1. Here, you can use any RAM address, but I suggest $8C.
The value of 'yy' here refers to the row of values under the respective routine's table. For example, do you want another object which uses the 'SquareObjects' routine? The routine calls a table called 'SquareObjTiles', which by default has one row. Add another row with different values for your tiles under that row, which will be considered as index 0x01 (the first row is index 0x00). So, in place of the 'yy', put 01. Then reapply ObjecTool and insert your object normally. Thanks to MFG for the code.
Tried it out, and so far, so cool! I noticed a small problem though: if I insert custom cluster object 00, it'll appear as garbage in-game. However, I tried the other objects (01 and 02) and they appear fine. Is this an oversight?
Edit: Okay, I noticed that it calls the '.ClusterObjExample' table, which calls tile 0 (water) in all entries. However, even after changing the values to sensible ones (like tile 2C, or coin), the problem's still the same.
Added SA-1 support (moderated by JamesD28 and KevinK).
Hands on: This is one of the best patches out there. It may not be as useful for the average hacker as the display of object 2D and unused extended objects will likely be always glitched but if you're familiar with SMW hacking, you certainly will like this patch!
However, the addition of new objects, one where you can specify rectangular objects of different sizes and even ledges (ableit without any corner), certainly will prove to be useful even if you don't know ASM.
The biggest challenge here is to use slopes. Most objects (including cluster objects) actually follow the size of object 2D but slopes don't (the vertical size simply means how ground tiles are added to the slope but growing horizontally adds a full slope part which grows vertically for a single tile and horizontally for multiple tiles) which means they can potentially mess up the number of screens and z-order (a hack is to put tiles as a bridge to correct the z-order which may be removed afterwards). Their format also isn't easy to grasp as each slope first has got table with indeces to the second table which contains the actual tiles.
Big square objects have got a similar issue with screen size and z-order as their actual size don't always equal to what Lunar Magic expects too.