Framez API incorrect

[OvermindDL1]

I noticed something weird with the Framez movement, ordering seemed wrong, debugged and figured out the issue was in DragonAPI, specifically file: https://github.com/ReikaKalseki/DragonAPI/blob/master/ModInteract/DeepInteract/FrameBlacklist.java Lines 21-22:

import com.amadornes.framez.api.movement.HandlingPriority;
import com.amadornes.framez.api.movement.HandlingPriority.Priority;

Do not exist in the framez API, it looks like this is the old 1.7.2 API or something, the 1.7.10 API should replace the above with:

import com.amadornes.framez.api.Priority;

And thus the code in that file in 3 locations of:

@HandlingPriority(Priority.HIGH)

Should probably be changed to this from what I see:

@Priority(Priority.PriorityEnum.HIGH)

[OvermindDL1]

PR sent: https://github.com/ReikaKalseki/DragonAPI/pull/21

[OvermindDL1]

There were a lot more issues with that file too, fixed them and updated the PR.

[ReikaKalseki]

I cannot implement this without a copy of the new API.

[OvermindDL1]

If you add GT6's maven as a build dependency then you can just add compileOnly "com.amadornes.framez:Framez:1.7.10-0.2-33:deobf" to your dependencies (or compile instead of compileOnly if you want it to run in the dev environment if you launch from your IDE or gradle, I think framez works fine in the dev environment if I recall properly). I have a holy-frick-ton of random dependencies on there of the latest versions, at the very least you can download it from the maven and include it directly if you want. To use the GT6 maven as a maven repo just add this to your repositories block in Gradle (or adjust for whatever build system you use):

        maven {
                name = "gt"
                url = "https://gregtech.overminddl1.com/"
        }

Some of the dependencies I have are for compiling only, they won't execute in the dev environment, but they can still be compiled against and as long as your code doesn't depend on them then you can still run from the IDE (some modders that don't know what they are doing...). I can give you a fairly complete list if you need. Or if you want any specific dependencies updated then I can give you a maven dependency for those as well.

For note, the GT6 maven has everything needed to build not only GT6 (including forge and forgegradle, added those when the forge files server went down for a few days there) but also every potential GT6 dependency, as you can see at https://git.gregtech.overminddl1.com/GregTech-6/GT6/src/branch/master/build.gradle GT6 doesn't even depend on the Forge Maven anymore, and as you can see at https://git.gregtech.overminddl1.com/GregTech-6/GT6/src/branch/master/build.gradle#L223 that should be a 'mostly' complete list of maven-available dependencies (I think most of the versions listed there are up to date but there are a couple that I know aren't, but if you use any then ask and I'll check the maven for the latest version, or you can check it yourself by crafting the URL to the project and manually check in a web browser), should be able to just copy any of those dependency definitions out and use it in your own project as well if you add the GT6 maven (or just download the appropriate file from the GT6 maven using a web browser by crafting the maven URL directly).

[ReikaKalseki]

I am not adding any things to my build script. I need the API as .java files I can directly add to the dev environment.

[OvermindDL1]

I need the API as .java files I can directly add to the dev environment.

I'd highly recommend not doing that, by not using the versioning that Jar dependencies supply this is why the API got out of date as there is no way a MC 1.6 (or anything non-MC 1.7.10) API should have ever been included in a MC 1.7.10 mod and proper dependency versioning would have caught that.

Regardless, the GT6 maven has the API and full source (as well as mod jar, dev jar, api-only jar, source jar, etc.. etc..) as any good maven setup should have, so those are still available if you want to go that route, just use a browser to download them at the traditional maven-style URL's... >.>

[ReikaKalseki]

Your link above just takes me to the GT site, which has none of the API files.

[OvermindDL1]

Your link above just takes me to the GT site, which has none of the API files.

As stated you just need to access the standard maven path as per the maven dependency declaration of com.amadornes.framez:Framez:1.7.10-0.2-33:deobf, which would for that specific one would be: https://gregtech.overminddl1.com/com/amadornes/framez/Framez/1.7.10-0.2-33/Framez-1.7.10-0.2-33-deobf.jar It's all part of the java standards, that URL and all.

[GregoriusT]

Having the Repository and the Dependencies listed inside the build.gradle will cause Gradle to automatically download all of them and add them to your Dev Environment without you needing any of the .java Files added manually anymore.

So once you added them to the build.gradle just call gradlew --refresh-dependencies setupDecompWorkspace build eclipse And everything is in your Dev Environment. Just make sure you backup everything, so in case you screw up (because of lack of understandable instructions by @OvermindDL1) you can easily fix it again. ;)

[OvermindDL1]

(because of lack of understandable instructions by @OvermindDL1)

Heh, sorry, when I'm talking to someone that's been using java for enough years that I instinctively leave out the common knowledge steps and give the parts of the information that build on that to complete. ^.^;

Something I had to learn working with java for 8 years at Xerox... >.>

so in case you screw up

That's why your use git! Which greg finally does, lol. ^.^

[OvermindDL1]

Having the Repository and the Dependencies listed inside the build.gradle will cause Gradle to automatically download all of them and add them to your Dev Environment without you needing any of the .java Files added manually anymore.

Also, for note, the gradle cache directory is designed to be easily kept and cached offline for note, you can even git-commit it if you so wish (though with git-lfs as you don't want to commit large binaries to git).

[ReikaKalseki]

As stated you just need to access the standard maven path as per the maven dependency declaration of com.amadornes.framez:Framez:1.7.10-0.2-33:deobf

I have no idea what any of that means. And your link is to a deobf copy of the mod, not API files.

Yes, I can delete the non-API content from the jar, but because this is a jar being added to the build path, rather than source files, I now have to wait 30 minutes for this:

This is why I do not do things the "official" way just because it is the "official" way.

[ReikaKalseki]

In fact, my workspace is stuck in an endless loop of a random file in the jar failing to be readable (not the same one each time), and an automatic flush and rebuild, thus causing a different file to fail to load...

[ReikaKalseki]

I have only been able to recover it by deleting the framez files entirely, both the source and the jar. The workspace no longer accepts even the previously-working .java files.

So I have deleted all my Framez handling until I have working files.

You want Framez compatibility at all, give me usable files.

[OvermindDL1]

And your link is to a deobf copy of the mod, not API files.

That's because if you just link to that then it works, and you can even test it in the dev environment depending on whether it's added to the runtime classpath or not.

As stated though, it's maven, if you want the sources than grab the sources classifier, which in it's case is https://gregtech.overminddl1.com/com/amadornes/framez/Framez/1.7.10-0.2-33/Framez-1.7.10-0.2-33-sources.jar So can peel out of it what you want. Though you never ever should contain library sources in a project that is not that library itself.

but because this is a jar being added to the build path, rather than source files, I now have to wait 30 minutes for this:

That is absolutely not a fault of adding something to the build path, mcp does not need to rebuild for that, and as for the building workspace that should not be taking that long, I have all your mods building just fine here (I had to create a gradle project as you seem to be missing it on github):

Found AccessTransformer in main resources: DragonAPI_at.cfg
Found AccessTransformer in main resources: CoFHCore_at.cfg
:compileApiJava UP-TO-DATE
:processApiResources UP-TO-DATE
:apiClasses UP-TO-DATE
:sourceMainJava UP-TO-DATE
:compileJava
/home/overminddl1/tmp/greggit/ReikaMods/build/sources/java/Reika/DragonAPI/IO/ReikaFileReader.java:202: warning: non-varargs call of varargs method with inexact argument type for last parameter;
                return getAllFilesInFolder(f, null);
                                              ^
  cast to String for a varargs call
  cast to String[] for a non-varargs call and to suppress this warning
/home/overminddl1/tmp/greggit/ReikaMods/build/sources/java/Reika/DragonAPI/DragonAPIInit.java:807: warning: non-varargs call of varargs method with inexact argument type for last parameter;
                Method inst = c.getMethod("getInstance", null);
                                                         ^
  cast to Class<?> for a varargs call
  cast to Class<?>[] for a non-varargs call and to suppress this warning
/home/overminddl1/tmp/greggit/ReikaMods/build/sources/java/Reika/DragonAPI/Command/BytecodeCommand.java:445: warning: non-varargs call of varargs method with inexact argument type for last parameter;
                                        Object o = cn.newInstance(args);
                                                                  ^
  cast to Object for a varargs call
  cast to Object[] for a non-varargs call and to suppress this warning
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
3 warnings
:processResources UP-TO-DATE
:classes
:ChromatiCraftDevJar UP-TO-DATE
:jar
:ChromatiCraftJar
:ChromatiCraftSourcesJar UP-TO-DATE
:CondensedOresDevJar UP-TO-DATE
:CondensedOresJar
:CondensedOresSourcesJar UP-TO-DATE
:DragonAPIDevJar UP-TO-DATE
:DragonAPIJar
:DragonAPISourcesJar UP-TO-DATE
:ElectriCraftDevJar UP-TO-DATE
:ElectriCraftJar
:ElectriCraftSourcesJar UP-TO-DATE
:GeoStrataDevJar UP-TO-DATE
:GeoStrataJar
:GeoStrataSourcesJar UP-TO-DATE
:LegacyCraftDevJar UP-TO-DATE
:LegacyCraftJar
:LegacyCraftSourcesJar UP-TO-DATE
:MeteorCraftDevJar UP-TO-DATE
:MeteorCraftJar
:MeteorCraftSourcesJar UP-TO-DATE
:ReactorCraftDevJar UP-TO-DATE
:ReactorCraftJar
:ReactorCraftSourcesJar UP-TO-DATE
:RotaryCraftDevJar UP-TO-DATE
:RotaryCraftJar
:RotaryCraftSourcesJar UP-TO-DATE
:VoidMonsterDevJar UP-TO-DATE
:VoidMonsterJar
:VoidMonsterSourcesJar UP-TO-DATE
:coreJar
:devJar UP-TO-DATE
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:extractMcpData UP-TO-DATE
:getVersionJson
:extractUserDev UP-TO-DATE
:genSrgs SKIPPED
:reobf
:sourceJar UP-TO-DATE
:assemble
:check UP-TO-DATE
:build

BUILD SUCCESSFUL

Total time: 1 mins 9.101 secs

Thus not sure what issue you are having other than a potential broken build manager. Are you using gradle or something like ant (which notoriously breaks in a variety of ways) or something else?

In fact, my workspace is stuck in an endless loop of a random file failing to be readable (not the same one each time),

That exceptionally sounds like your build scripts are broken and that should absolutely not be happening with a gradle workspace in eclipse. What else are you using?

I have only been able to recover it by deleting the framez files entirely, both the source and the jar.

You want Framez compatibility at all, give me usable files.

Well the file given works not only for GT6 but also your mods when I compile them manually with the changes specified in the first post.

[ReikaKalseki]

The API you gave me is broken - it makes many references to internal "main mod" code and to some other random project:

That exceptionally sounds like your build scripts are broken and that should absolutely not be happening with a gradle workspace in eclipse. What else are you using?

I am using the same workspace I always have.

[OvermindDL1]

The API you gave me is broken - it makes many references to internal "main mod" code and to some other random project:

I know, I didn't make it, and that's probably why the author didn't distribute just an api jar, but the deobf serves the same purpose except it contains all the files, which if unreferenced never get linked in thus no cost except filespace of a few kb.

Oh yeah, just saw your image, framez is that weird one that needs a certain side library for compiling purposes only (the author did things very weird, I'm not a fan) and I think it's only extra added dependency was: "com.amadornes.jtraits:JTraits:0.1" Or direct link: http://gregtech.overminddl1.com/com/amadornes/jtraits/JTraits/0.1/JTraits-0.1.jar I think the source is on github somewhere, but it's a normal java library, no special obfuscation, no MC anything, etc... etc... So try adding that?

I am using the same workspace I always have.

What build system do you have Eclipse set to using though? I know a couple that Eclipse does very poorly on (ant being probably the most well known troublemaker but there are others). If it's set to a gradle workspace then it shouldn't cause such loading issues as it does everything out-of-band then. Personally I opt for the IntelliJ IDE instead of Eclipse as it has significantly better performance and features over Eclipse (and is the most used Java IDE now).

[OvermindDL1]

Also I noticed in your screenshot that you have a red line on the qmunitylib stuff, if you need that it's on the maven as well: "qmunity:QmunityLib:0.2.118:deobf" Or Direct link: https://gregtech.overminddl1.com/qmunity/QmunityLib/0.2.118/QmunityLib-0.2.118-deobf.jar It does not have a source jar either because the authors don't know how to make proper packages like many modders apparently, but that's their official dev jar and it works in GT6 and when compiling your mods.

[ReikaKalseki]

What I am going to do instead is gut my copy of the API; as long as the method signatures remain the same, compatibility will remain.

[ReikaKalseki]

What build system do you have Eclipse set to using though?

The same one as I have always have, since 1.2.5.

[ReikaKalseki]

OK, done, but you will need to test to make sure it works come v23.

[OvermindDL1]

What I am going to do instead is gut my copy of the API; as long as the method signatures remain the same, compatibility will remain.

Indeedy true, and it's certainly not likely its API will change again considering it's had no updates since it was originally updated to 1.7.10. ^.^;

The same one as I have always have, since 1.2.5.

But what's the build system set to? Eclipse has quite a variety of options. Basically if it's not gradle via ForgeGradle then working in the forge ecosystem is 'probably' broken.

[ReikaKalseki]

But what's the build system set to?

Whaa?

[ChrisJStone]

But what's the build system set to?

Whaa?

@OvermindDL1 is wanting to know the application you use to compile your your code. Is it maven, ant gradle or a homebrew system?

[ReikaKalseki]

Home-made, and largely not of my creation.

[ChrisJStone]

Home-made, and largely not of my creation.

Then that could possibly be what is causing your work space taking so long to build and the problems you are having with framez. Since you are using a homebrew system and I do not know it's workings I have no way of saying for sure.

[ReikaKalseki]

I suspect the extreme build times have to do with the multiple gigabytes of non-code files that eclipse is still insistent on going through - assets, .git, and so on.

[GregoriusT]

multiple gigabytes of WHAT?!? wait a second do you still have that filesnapshots.bin File in the Gradle Folders? Gradle gets slower and slower the more often you build because that File grows to sizes that Windows cant handle anymore after a while!

Edit: forgot to mention its perfectly safe to delete that gigantic File ofcourse. I automatically delete it with my build script btw.

[ReikaKalseki]

I have a filesnapshots.bin, but it is only 58MB (not even one compile in size).

No, I mean like the .git folders, which are a gigabyte or so each, plus the assets folder which is another several GB.

[ChrisJStone]

I suspect the extreme build times have to do with the multiple gigabytes of non-code files that eclipse is still insistent on going through - assets, .git, and so on.

This is just off the top of my head so I'm not sure if this will work.

MineMaarten in his Advanced Modding Tutorials: Part 2, Github Project Management creates a new project for his mod, deletes the auto created src folder and then links to a alternate location for his src and resources folder. After seeing you screen shot this would require linking each folder. A lot of work IMHO for something that may not solve the issue.

If memory serves me there is an option to have the .git directory outside of the working tree directory this may also help. I'll have to look into it more. Perhaps this is why the Egit plugin complains when you try to create a git repo inside of your workspace project directory. I'll look into it and see what I can come up with.

EDIT: A quick google search of separate git dir from working tree shows that it can be done. Not sure if it will help with the build times or not though.

[ReikaKalseki]

EDIT: A quick google search of separate git dir from working tree shows that it can be done. Not sure if it will help with the build times or not though.

I know from trying with symlinks and my Factorio mods that GitHub does not tolerate moving the .git folder of a pre-existing repository. Me and Nexela had quite a long argument about it:

[ChrisJStone]

I know from trying with symlinks and my Factorio mods that GitHub does not tolerate moving the .git folder of a pre-existing repository. Me and Nexela had quite a long argument about it:

Not wanting to restart the argument however this is why I generally don't use "support" apps to help manage my git repos. Granted they do help in making git easier for people new to git or possibly version control in general. However I feel that they also limit the developer in what they can do to manage the repository.

The last thing I want to do is force you to have to develop a new workflow process or force an unwanted change in your existing process. I'll do some testing and see if I can come up with a solution that would work and still allow you to use your existing workflow process.

[ReikaKalseki]

I'll do some testing and see if I can come up with a solution that would work and still allow you to use your existing workflow process.

The big thing is that the folder structure - which I have set up to minimize clicks requires for navigation - remains the same, as does the bulk of the "special" gradle code.

[ChrisJStone]

I know from trying with symlinks and my Factorio mods that GitHub does not tolerate moving the .git folder of a pre-existing repository. Me and Nexela had quite a long argument about it:

After doing some testing on my own I have discovered that GitHub does allow you to move the .git folder and will still work. Perhaps it was the version of GitHub desktop that you were using at the time.

What I did was clone a test repo in GitHub desktop, move the contents of the .git folder to a separate folder outside of the work tree, I then deleted the .git folder from my work tree and in its place created a .git text file with gitdir: path to new .git folder.

Here is the link to my test repo https://github.com/ChrisJStone/test Here is a link to a forked repo https://github.com/ChrisJStone/github-flow

In both cases I was able to have my .git folder outside of the working tree and still be able to interact with github and github desktop. Granted you would have to repeat the above steps

What I also did find out is that if you use git clone --separate-git-dir from git bash GitHub Desktop will fail with an authentication error. However as long as you clone the repo in GitHub Desktop first then use windows explore to move the .git folder to it's new location and create the .git file using a txt editor such as vim or notepad "I used both in my testing" this will work with GitHub and GitHub Desktop.

I don't know if it would be worth your time however if you are right about the extreme build times it may be worth it.

The big thing is that the folder structure - which I have set up to minimize clicks requires for navigation - remains the same, as does the bulk of the "special" gradle code.

The above solution should work with your folder structure. As far as the "special" gradle code I am unsure of that with out being able to view the build scripts. Just based on my testing if you clone any repos from GitHub this will not work with out having to write a custom task or two that would move the .git folder and create .git file. However a git pull should work as normal once the changes have been made to the local repo.

If nothing else I hope this will help with your future modding projects. Keep up the good work

[OvermindDL1]

You really should not be using a homebrew setup, Java compilation is more...troublesome than a language rightfully should be (a simple javac --... ... may be sufficient for small projects, but not anything of any decent size, and certainly not something based on MCP).

I've already made a gradle project for all of your mods (the interdependencies between them was a slice of hell, very NOT standard java, but simple enough to get running), it's in a private git repo currently but I can make it public if you want it. Essentially just clone it --recursively then ./gradlew build and it takes a couple of minutes. Might need a touch of cleaning but some initial tests (I made just enough of it to get an actually proper api jar for my own usage) show it runs just fine in the IDE, supports hot-editing-at-runtime, etc... etc...

But really, using a homegrown thing with forge mods is a recipe for a horror, it is highly not recommended (nor is a homegrown thing recommended for any java project of any reasonable size).

But yeah, I can make that repo public, or give you access to my git server and give you private access. It's pretty trivial though that anyone who barely even knows what they are doing could replicate it in a single evening easy.

EDIT: Oh, and since Eclipse would be running with the gradle backend instead of whatever homegrown horror is including *EVERYTHING*, .git directories are of course ignored, as is everything that is not directly related to the project.

[ChrisJStone]

@OvermindDL1 I would be interested in taking a look at the build script you came up with.

[OvermindDL1]

@ChrisJStone I know Reika has stated elsewhere that he'd prefer such a thing not to be public (I don't understand 'why' though?) so that's why I didn't. The big issue I had was a few of the API's used by these mods are old 1.6.6 or 1.7.2 versions of mods that changed in 1.7.10 (one big reason I know that Reika is not using even a half-decent dependency based build system as that would not be possible if properly done otherwise) as well as a couple of odd coding things that are accessing things by name that don't exist in 1.7.10 (also would not be possibly an issue with proper dependency management combined with forgegradle usage).

So I'll open it if Reika's fine with it, but otherwise it is not even remotely hard to make it yourself (and I can help if you hop on IRC on espernet, same name there as on here, or join us all in #gt-dev as that's the main room I frequent).

[ReikaKalseki]

I know Reika has stated elsewhere that he'd prefer such a thing not to be public (I don't understand 'why' though?)

Such a thing must never be public. My mods are to remain buildable and releaseable only by me, not 5000 people who want to make bootleg versions and cause irreversible and widespread damage.

[OvermindDL1]

not 5000 people who want to make bootleg versions and cause irreversible and widespread damage.

Just as a note, that doesn't happen, maybe once or twice but it quickly goes out of date regardless. The benefit would be getting actually working PR's, which would be helped by actually good git versioning history. Even GregoriousT finally realized that and his mods were probably the most recompiled/copied out there. ^.^

[GregoriusT]

Do note that Bootleg Versions are almost always worse than the original, even if the original is ridden with Bugs, at least in my case that is, people first need to understand your Code in on itself, before they could pull off a working Bootleg Version that people actually want to use, even if they can compile the original Version, the understanding of your Code is a major hurdle as well.

The only reason "GT5U" became popular is because it was a port of an abandoned GT Version, since I started rewriting everything in GT6, people who still played GT5 wanted a continuation.

And "GTCE" became popular as its supposedly a Port of GT5U to newer MC Versions as "Community Edition" with new Code. But that Project absolutely failed because the Project Leader is very allergic to Bug Reports, properly working Solutions and Criticism, even when he isn't the one being criticized, and nobody dared to fork that Project yet.

Right now there is technically 3 people who can compile your Mods: Reika, OvermindDL1 and myself. I only have access to OvermindDL1 s Setup, I don't intend to use it, because Time is the only valuable Resource in Life and I rather waste that playing Factorio, than dealing with other peoples Stuff.

Sure 3 people aren't 5000, and 2 of these 3 people would not release your Mods (I presume that Reika dude still releases it), but the proper Build Setup definitely works as a proof of Concept, though having seen the constant bitching of OvermindDL1 on my IRC channel for multiple hours at how horrible making that Setup was in the first place, it is also a proof of protection against Bootleggery.

But the thing is, you could just not publish the details of the better Setup either, and then people still cant compile your Code, but you can be sure that it is much easier to recover in case of a Hard Drive failure, Computer replacement, "Windows 10 deleting all Files that aren't on the same physical Drive as C:\ without consent, if your Computer uses a specific group of Intel Processors, because long time ago you clicked the Look-for-Updates-Button once, resulting in you unknowingly and irrevocably becoming a Microsoft Beta Tester" (yes, that was what happened to a lot of people in October), or whatever else can happen. If things aren't on a screwed up Homebrew Setup it makes it easier.

I moved all my Stuff from Windows 8 to Linux (Kubuntu) recently (August/September), and it was a horrible process to move it over, but in the end it made it easier to have a proper Git Setup and everything, since i did not have to deal with legacy crap of my old hacky Setup. I had a randomcode.jar File with all the compiled APIs in it just to get it to compile, but now I don't need that anymore, thanks to OvermindDL1 helping me with setting up a proper thing.

And damn I am rambling too much again, sorry for that. ^^"

Point is: Having a nice Setup yourself is good and you can protect yourself from the bootleg in other ways I am sure. ;)