[SOLVED] How to make a fireball in jME3.1

Unfortunately I do… It’s the problem which is stopping me from releasing new SDK versions. You can manually fix it by reverting Distribution package does not include jbullet dependencies · Issue #456 · jMonkeyEngine/jmonkeyengine · GitHub or more precise
Fix #456 · jMonkeyEngine/jmonkeyengine@93001ec · GitHub

However I’d love to hear from gradle gurus how I can fix that for the engine.

What happened is that the engine is now specifying jbullet.jar as explicit dependency and we can’t tell gradle that we have that.
I tried Try to fix the engine builds as reaction to jMonkeyEngine/jmonkeyengi… · jMonkeyEngine/sdk@74a8a07 · GitHub but it didn’t work…

Maybe you could also just remove jbullet from the sdk dependencies if you don’t want to change the engine source code

1 Like

@ndebruyn you can create a project with an old version of the SDK and just change jme dependencies in the project.
You don’t have to build the SDK.

@Darkchaos I don’t get why you need this. you only need a reference to jme-jbullet and jme-bullet.

1 Like

Well I do want to fix the problem at hand as well as get a latest version of the sdk which I already have running.
Also, I changed the netbeans version of the sdk I am building back to 8.1 so that I have android build support because of that nbandroid plugin bug:

I love working in the sdk and that is my preferred editor for jME. Al in one place…

2 Likes

yeah me too. I like the original SDK most. But I switched to gradle for building, works as well tip top with the SDK, I just needed to find a way to still be able to import the models, for that I have standard jme project in the SDK aside the gradle project :slight_smile:

2 Likes

What?!? Then our build dates are totally messed up.

That build date says december 11th to any sane person on the planet. This totally bypasses any European versus American month-day day-month standard. When you put the year first then it’s year-month-day. Anything else is totally ridiculous.

1 Like

Or… I just misread, Relax.
What matters here is the commit hash anyway. Indeed it might have been build on December 11 but still with an old version.

1 Like

Okay thanks all. I solved the problem.

1 Like

How then?

1 Like

Well I think the sdk was holding onto my previous version/build of the engine.

I manually deleted the engine dir in the sdk and the .m2 maven dir.

I then commented out the jBullet optlib build and ran the buildSdk.

I then ran the netbeans and ran the jme sdk from netbeans just to see that the latest jme was taken.

Then I did a clean and build in netbeans and build the distros.

That was basically it.

3 Likes

How many actions you need to do to solve it :open_mouth:

1 Like

That’s true, however as you can see from travis:

* What went wrong:
A problem occurred evaluating root project 'sdk'.
> Could not resolve all dependencies for configuration ':optlibs'.
   > Could not resolve org.jmonkeyengine:jme3-jbullet:3.2.0-SNAPSHOT.
     Required by:
         :sdk:unspecified
      > Could not resolve org.jmonkeyengine:jme3-jbullet:3.2.0-SNAPSHOT.
         > Could not parse POM file:/home/travis/.m2/repository/org/jmonkeyengine/jme3-jbullet/3.2.0-SNAPSHOT/jme3-jbullet-3.2.0-SNAPSHOT.pom
            > Unable to resolve version for dependency 'jbullet:jbullet:jar'

This means said jbullet pom requires jbullet or something. Maybe I’d have to name my jbullet.jar also like jbullet.jar-3.2.0-SNAPSHOT?

I have actually looked into “merging” the SDK Project Class and the Gradle Plugin’s one, so that you could build gradle while having an SDK Project. Unfortunately they don’t share the same base class so it’s not so easy to do.

Personally I have a regular sdk project but just hop into the command line to build/run. The downside is you have to manually add the libraries so that syntax highlighting etc works.

That’s what happens quite often to me as well. You’re just not used to month-day notations.

Glad you solved it :slight_smile: Yeah, it used the version that you built on 11th December

I’ve just checked it and Netbeans 9.0 still isn’t out sadly, so you are stuck with 8.1

1 Like

No, or you misundestood what I wrote. If the year is first then it is always always year-month-day. Nehon suggested it was otherwise and that made me panic that there are crazy countries or something.

If our build is somehow outputting year-day-month then we should fix it because that’s not a standard anywhere sane people hang out.

1 Like

Yeah, that’s a bad typo there:
“We’re just not used to…” (as in the Europeans).
That’s why it can always happen that we try to read each date in the dd.mm.yyyy format, even though it’s yyyy/mm/dd (it’s actually really simple, it’s only completely mirrored).

1 Like