[SOLVED] AccessTransformer - which way of implementing it is the right ?

[frxtn]

Heya,

 

I'm kinda conflicted on how to implement my accesstransformer. I read a lot of stuff and i ended up with two ways:

 

1. by telling my build.gradle to move my *_at.cfg to meta-inf and adding a manifest attribute FMLAT specifying my accesstransformer cfg and running setupDecompWorkspace everytime i change something about it

 

2. by extending AccessTransformer and linking my *_at.cfg in the superconstructor (and link to it from my coremod-class?).

 

so which is the right way?

Edited September 18, 2019 by frxtn

[frxtn]

knowing that the 2nd method is gone with 1.13 i will use method nr 1. 

my coremod is already separated from my main mod (and yes i needed one to intercept vanilla packets but i did that and it works like a charm and shouldnt conflict with other mods either, since i injected unintrusive bytecode only.)

 

thank you nonetheless!

[frxtn]

i couldnt find another way of injecting custom cancelable and stageable events

 

edit:// with "intercepting" packages i meant also being able to get the event stage and having the option to cancel both sending packages and processing received packages

Edited September 18, 2019 by frxtn

[frxtn]

damn, now that's news. i gotta say i was struggling with finding readables about anything going beyond standard forge coding so i didnt come across this at all. my coremod doesnt only supply events from networkmanager though, i also injected a bunch of other events which i need (player mounted rideable/player dismounted rideable yadda yadda) so i guess having my coremod isn't too bad after all. and, dont worry, i'm handling it carefully. i'm only injecting enclosed code which cant possibly interfere with other people's code. 

[frxtn]

i have no idea how i missed that in the event type hierarchy. seriously ... lol.

 

i know that if people inject shitty bytecode it could mess up shit, but as long as nobody searches for injection nodes by opcode without verifying context there shouldnt be any problems. i always insert pre-events as closed if's (if cancelable) and post events as single method invokes.

[Draco18s]

  On 9/18/2019 at 10:38 AM, frxtn said:

i'm only injecting enclosed code which cant possibly interfere with other people's code. 

Expand  

Following what D7 said, its super amazingly easy to inject bytes that mess with other people's code. The crusade against coremods and insuring the events were present in Forge instead is a testament to that.

 

For example, lets say there's a method that you want to exit early (effectively cancelling behavior) and so you insert that code at the top of the method, couple of JVM-bytes for "get value, test against zero, return, else jump."

 

Someone else wants to put functionality at the end of that method and knows that there's only 1 return statement.

 

So they write some ASM code that "finds first return, insert new functionality before it."

 

Guess what? Your patch just messed up theirs (and depending on how you set up your "else jump" their patch might mess up yours). Were they right to find the first return rather than the last? No. But their code in isolation works Just Fine.

Edited September 18, 2019 by Draco18s

[frxtn]

  On 9/18/2019 at 6:28 PM, Draco18s said:

So they write some ASM code that "finds first return, insert new functionality before it."

 

Guess what? Your patch just messed up theirs (and depending on how you set up your "else jump" their patch might mess up yours). Were they right to find the first return rather than the last? No. But their code in isolation works Just Fine.

Expand  

 

I'm not disagreeing with you as this is somewhat exactly what i meant when I said "but as long as nobody searches for injection nodes by opcode without verifying context".

 

I also understand that i have to retract from my initial statement a bit, since having my shit messed up is really easy no matter how well I think i'm doing it. i'm still standing with having it done decently (on a technical level), but i will remove the entity class patches for the mount dismount events and i will see if i missed any other forge events for which i injected custom bytecode. i want to keep my mod as unobstrusive as possible after all.

Edited September 18, 2019 by frxtn

[Draco18s]

  On 9/18/2019 at 7:22 PM, frxtn said:

as long as nobody searches for injection nodes by opcode without verifying context

Expand  

OH MAN, guess how many people do that?

None.

Basically none.