Hello World

@haze said: Hi @t0neg0d,

i get an error when trying it.

java.lang.NoSuchMethodError: com.jme3.math.Vector3f.interpolate(Lcom/jme3/math/Vector3f;Lcom/jme3/math/Vector3f;F)Lcom/jme3/math/Vector3f;
at emitter.influencers.SizeInfluencer.update(SizeInfluencer.java:42)
at emitter.particle.ParticleData.update(ParticleData.java:196)
at emitter.Emitter.update(Emitter.java:808)
at com.jme3.scene.Spatial.runControlUpdate(Spatial.java:570)
at com.jme3.scene.Spatial.updateLogicalState(Spatial.java:688)
at com.jme3.scene.Node.updateLogicalState(Node.java:145)…

Vector3f has an interpolateLocal method but no interpolate…i believe it’s a recent change (i use nightly build, so maybe it’s not released yet). I can’t change it cause i only have the .jar and i think you don’t want to do it now for those don’t use nightly builds. So…just to say you will have to do it…a day.

Maybe i’ll go back to the off release to test it…if it doesn’t break any of my projects ;).

This was switched by @pspeed from interpolate to interpolateLocal then switched back to interpolate (I think??), I think. I honestly don’t know what to do with this atm, because I don’t know which version people are using and which is going to end up in the next release. So… pretty much all code using this method is fucked for the time being.

EDIT: The descepency is between the current release and nightly… so… /boggle… not sure what to do.

EDIT 2: Actually… this is sorta bogus. I understand the name change… but @Deprecated would have been the appropriate way to implement the name change, especially considering iot was changed after a stable release.

@t0neg0d said: This was switched by @pspeed from interpolate to interpolateLocal then switched back to interpolate (I think??), I think. I honestly don't know what to do with this atm, because I don't know which version people are using and which is going to end up in the next release. So... pretty much all code using this method is fucked for the time being.

EDIT: The descepency is between the current release and nightly… so… /boggle… not sure what to do.

EDIT 2: Actually… this is sorta bogus. I understand the name change… but @Deprecated would have been the appropriate way to implement the name change, especially considering iot was changed after a stable release.

Stable branch it’s incorrectly named as interpolate(). 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.x

Non stable head-everything-might-break-at-any-time, it’s properly called interpolateLocal(). So from 3.1.x on it will be the new name.

The issue was that people using it with the incorrect name might have had subtle bugs in their code if they were expecting it to work like all other non-local methods. So in head I fixed it. There may be a 100 other things in head that might break libraries that rely on 3.0.x. This is just one of them and libraries will need a strategy for dealing with that.

@t0neg0d said: This was switched by @pspeed from interpolate to interpolateLocal then switched back to interpolate (I think??), I think. I honestly don't know what to do with this atm, because I don't know which version people are using and which is going to end up in the next release. So... pretty much all code using this method is fucked for the time being.

EDIT: The descepency is between the current release and nightly… so… /boggle… not sure what to do.

EDIT 2: Actually… this is sorta bogus. I understand the name change… but @Deprecated would have been the appropriate way to implement the name change, especially considering iot was changed after a stable release.

Nope, just changed once, but no official message whereas Vector3f is certainly the most used class in any projects ^^
The new name is more correct as @pspeed said. The problem is when the new version will be released to avoid these kind of error ?

@haze said: Nope, just changed once, but no official message whereas Vector3f is certainly the most used class in any projects ^^ The new name is more correct as @pspeed said. The problem is when the new version will be released to avoid these kinds of error ?

You could also say the problem is that you have access to code way before its released ^^

@normen said: You could also say the problem is that you have access to code *way* before its released ^^

yep, i guess it’s entirely my mistake :wink: …but when this change will be released…it will be a bit rough…we will need to modify all the existing libs/projects ^^

@haze said: yep, i guess it's entirely my mistake :wink: ...but when this change will be released..it will be a bit rough..we will need to modify all the existing libs/projects ^^

Yes, sooner or later, marked deprecated or not.

@normen said: You could also say the problem is that you have access to code *way* before its released ^^

Yeah… I don’t really care what the cause is. I can guarantee if it was a commercial project and you had paying customers calling about it, this would not have been acceptable. But, likely that is why companies have project managers and a QA department and don’t rely on devs to make these kinds of calls. Logical != best practice.

Can we move this discussion out of this thread please? I don’t want another 100 fucking page thread of BS, thanks.

@t0neg0d said: Yeah... I don't really care what the cause is. I can guarantee if it was a commercial project and you had paying customers calling about it, this would not have been acceptable. But, likely that is why companies have project managers and a QA department and don't rely on devs to make these kinds of calls. Logical != best practice.

Can we move this discussion out of this thread please? I don’t want another 100 fucking page thread of BS, thanks.

wow, sure we can.

@normen said: wow, sure we can.

Thanks

@t0neg0d said: Yeah... I don't really care what the cause is. I can guarantee if it was a commercial project and you had paying customers calling about it, this would not have been acceptable. But, likely that is why companies have project managers and a QA department and don't rely on devs to make these kinds of calls. Logical != best practice.

Can we move this discussion out of this thread please? I don’t want another 100 fucking page thread of BS, thanks.

So, to get back to the topic. If my customers had the pre-alpha code of my application running on their systems I’d probably either sue them or try to find out who leaked the code. Do you understand that trunk is a WIP? Or what are we discussing here?

@normen said: So, to get back to the topic. If my customers had the pre-alpha code of my application running on their systems I'd probably either sue them or try to find out who leaked the code. Do you understand that trunk is a WIP? Or what are we discussing here?

I understand completely…

Do you understand that people are told to use nightly consistantly to fix bugs that are reported?

And then I spend hours trying to track down a problem because someone is using nightly to fix an issue with some shader and are wondering why my code is throwing an error.

Meanwhile I have NO CLUE that they are using nightly… why would they tell me? A dev told them to use it to fix their other issue.

My problem is not the name change… I get WHY it’s being changed. What I don’t get is they lack of backwards compatibility for a .1 version change. I mean WTF??? If you are changing THAT much from version 3.0 to 3.1, one has to wonder how bad things were fucked up in version 3.0 to begin with.

If the changes are so drastic you can’t keep compatibility between a .1 version change, then you guys seriously need to get yourself someone familiar with the software life-cycle to run this as a project. It’s sad. It’s even more sad that you would publicly defend the choices.

Actually,

I take that back. You likely would not want someone involved at this level, because they would ensure that feature creep didn’t happen unless you were willing to support the current implementation.

@t0neg0d said: I understand completely...

Do you understand that people are told to use nightly consistantly to fix bugs that are reported?

And then I spend hours trying to track down a problem because someone is using nightly to fix an issue with some shader and are wondering why my code is throwing an error.

Meanwhile I have NO CLUE that they are using nightly… why would they tell me? A dev told them to use it to fix their other issue.

My problem is not the name change… I get WHY it’s being changed. What I don’t get is they lack of backwards compatibility for a .1 version change. I mean WTF??? If you are changing THAT much from version 3.0 to 3.1, one has to wonder how bad things were fucked up in version 3.0 to begin with.

If the changes are so drastic you can’t keep compatibility between a .1 version change, then you guys seriously need to get yourself someone familiar with the software life-cycle to run this as a project. It’s sad. It’s even more sad that you would publicly defend the choices.

Who tells people to use nightly constantly? We constantly tell people not to use nightly afaics.

You spend hours tracking down a problem of a method in Vector3f thats not found? And you would not tell a developer that you are using alpha software with his library? Also don’t mix up “saying that it has been fixed in nightly” and “telling them to use nightly”.

As we were trying to explain, it works like it does in MacOSX in jME. MacOSX 10.8.0 (“Mountain Lion”) is not backwards compatible to 10.2.0 (“Jaguar”). A small update like 10.8.0 → 10.8.1 is compatible but can also add features.

So unless you accuse us of inventing the versioning scheme just now… (we explained this earlier here: http://hub.jmonkeyengine.org/2011/10/jmonkeyengine3-sdk-beta-released/) I think we’re on the same page. Its an inevitable, sensible change and it should only be done when theres a major version change in the engine. Thats what we’re doing.

Ok…

Not much more to say on the subject… I’ll keep an eye out for breaking changes and make sure I ask if someone is using stable or nightly before trying to resolve an issue.

There are reasons to use nightly. Say a developer had a solid framework that they wanted to test against the newest jmonkey additions to ensure that before a “stable” version is released they had a chance to say “hey your changes have affected this aspect of jmonkey and caused models to look like something tim burton mashed up (which would be pretty neat)”.

SO on to my point… it is perfectly fine for you to use the Nightly versions because you would be ensuring that any breaking changes in the future you would already be ready because you would’ve been testing on the nightlies ahead of time.

@squizzle said: There are reasons to use nightly. Say a developer had a solid framework that they wanted to test against the newest jmonkey additions to ensure that before a "stable" version is released they had a chance to say "hey your changes have affected this aspect of jmonkey and caused models to look like something tim burton mashed up (which would be pretty neat)".

SO on to my point… it is perfectly fine for you to use the Nightly versions because you would be ensuring that any breaking changes in the future you would already be ready because you would’ve been testing on the nightlies ahead of time.

Well sure but you have to know what you’re doing. When the engine is in flux theres no way of saying if the problem is with your code or with the engine code when something fails, after all its how we exchange the code while we write it. The next commit might fix it, bring the final code that makes the engine work again, break it completely or whatever. Only when a project is very mature and not changed much anymore you can expect a nightly snapshot to work properly and only contain fixes.

Generally, before theres a release we will make pre releases where we say “okay this should basically work, there might be issues [here] and [there] but its a working preview so you can see how you can adapt your current code to it and how to use the new features”. To create that pre-release we make a branch/tag from trunk, at a point where trunk is actually working.