Jump to content

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


Recommended Posts

Posted (edited)

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 by frxtn
Posted

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!

Posted (edited)

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 by frxtn
Posted

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. 

Posted

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.

Posted (edited)
7 hours ago, frxtn said:

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

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 by Draco18s

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Posted (edited)
54 minutes ago, 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.

 

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 by frxtn
Posted
25 minutes ago, frxtn said:

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

OH MAN, guess how many people do that?

None.

Basically none.

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.