Simsillica

Seems when using gradle 5.0, not sure if it affects any other version, I can only get to the repo via

    //SimEthereal
    implementation 'io.github.simsilica:SimEthereal:sim-ethereal-v1.4.0'

anything else fails ie

compile "com.simsilica:sim-ethereal:1.4.0"
implementation 'com.github.Simsilica:SimEthereal:sim-ethereal-v1.4.0'

including this even though grabbing it as demonstrated in the first example does work,

implementation 'io.github.simsilica:SimEthereal:master-SNAPSHOT'

So is there a special trick to grab master branch? using 5.0?

Well, I guess the “compile” dependency is gone in 5.0, isn’t it?

As to the others, I didn’t even know it was possible at all. So I’m not sure. Hopefully someone more familiar with the magic will know.

I know it’s not really addressing your issue… but I’m waaay overdue for a release on that. I’ll try to push one this weekend.

Edit: and if you were asking specifically about the 1.4 release then I’m not sure why gradle is unhappy… but most of those group IDs are wrong, though.

yes, we have api or implementation (compile renamed really).

Thanks. I made this for the examples but you probably want to kill it now.

Final results are I was able to get sim-ethereal, lemur-proto, lemur-props, as shown.

    //Simsilica
    implementation 'com.simsilica:sim-ethereal:1.4.0'
    implementation 'com.simsilica:lemur-proto:1.10.0'
    implementation 'com.simsilica:lemur-props:1.1.0' 
    
    implementation 'com.github.Simsilica:SimMath:master-SNAPSHOT'
    implementation 'com.github.jMonkeyEngine-Contributions.zay-es:zay-es:master-SNAPSHOT'
    implementation 'com.github.jMonkeyEngine-Contributions.zay-es:zay-es-net:master-SNAPSHOT'   
    implementation 'com.github.jMonkeyEngine-Contributions.Lemur:lemur:master-SNAPSHOT'
   
//    implementation 'com.simsilica:sim-math:1.3.0'
//    implementation 'com.simsilica:zay-es:1.3.1'
//    implementation 'com.simsilica:zay-es-net:1.4.0'
//    implementation 'com.simsilica:lemur:1.12.0'

But not the snapshots.

For some reason sim-ethereal did finally work as it should. When I run that statement using “compile” it works just fine now. Might of been a bug in 5.0 because I changed the gradle version to 5.1 and now works.

Lastly, Im not sure if slf4j worked like this before but now all you do is this.

LOG.info("Will walk from {} to {}", getCharacters().get(0).getWorldTranslation(), locOnMap);

Anything over two variables creates a new object, otherwise no.

Yes, for me it’s just easier to gate the trace logs because if a) I don’t need to remember how to format (or escape brackets) and b) if I ever add a third parameter then I don’t need to rewrite the whole statement. So I generally just opt for the isTraceEnabled()/isDebugEnabled() if blocks by habibt.

For what it’s worth, I’ve just released SimEthereal 1.5.

https://hub.jmonkeyengine.org/t/some-new-sim-tools-releases-simmath-simethereal-zay-es-net/41771/2

implementation 'io.github.simsilica:SimEthereal:master-SNAPSHOT' sounds like a jitpack dependency to me, but I think there were some troubles with pauls projects, because SimEtheral e.g. could depend on an unreleased version of SiO2 and thus SimEtheral Snapshots are unable to build because they’d need SiO2 Snapshots on their own. So I end up manually building sometimes.

Personally I had a bug in IntelliJ with implementation where only compile helped (but that was probably gradle < 5.0), where implementation worked fine unless the first build/sometimes randomly it failed to locate the dependencies. Specifying compile and building worked and then I could change it back to implementation. Just FYI.

There’s another good reason for that if you have “computationally intense” logs. E.g. lengthSquared() for human readable vector lengths, some strings you have to fetch from a database or anything like that. That’s what I figured makes the most sense to use them.

Oh, yeah, that’s a good point.

I adopted the isXXXEnabled() idiom so long ago that I’ve long since internalized all of the good reasons to do it. I just know it’s the 100% worry-free way to add a ton of logging for when you need it. And you are right that the largest factor was not really about the extra string builders.