First of, I know native bullet isn’t done yet. Hopefully this test case will help getting it there eventually This is nightly.
I was playing around with ray casting and in native bullet the hit fraction seems to be the inverse of what JBullet does. There also seems to be a difference in the sizes of boxes, haven’t really understood what that is about but if the FUDGE_FACTOR is set to 1.0f JBullet detects collisions but native bullet does not.
Don’t rightly know what to make of this or what to do about it but here it is.
I just updated nightly + clean and build, still the same difference. Don’t know what else to do to make sure I’m updated. But it sounds like that is the fix alright
Here is an idea, wouldn’t it be great if the stats view included a version + build number? Is that information available somewhere?
@shirkit said:
It could be stored anywhere, what he wanted is that the build number should show up on StatsAppState debug text.
Exactly. Ive done similar things in many ways, generating a "Version.java" file from Ant-scripts, reading maven metadata from META-INF. The thing is, it helps to identify what is deployed. If it were visible on the StatsAppState and people upload screenshots of whatever problem they have it might be useful.
Could this be causing my issue with the GhostControl collsions? I haven’t dug to far into how the control does detection yet (its on my list), so I’m hoping so.
@jmaasing said:
Exactly. Ive done similar things in many ways, generating a "Version.java" file from Ant-scripts, reading maven metadata from META-INF. The thing is, it helps to identify what is deployed. If it were visible on the StatsAppState and people upload screenshots of whatever problem they have it might be useful.
Ah, generally, I thought for the natives or something.. Thing is, what part of the engine would define that? The single plugins all have build numbers but the people that deeply mess up their installs often have mixed jar files and whatnot. Also whats with the people who build themselves?
Basically the right place to do such a thing would be the svn system unfortunatly there is no way to attach a hook to a commit event, and increase a number in a file then. And doing this manually will lead to forgotten increments, false increments ect. This would only work if people would be forced to use nightlys, but that is not a real solution either.
Actually can’t you do it the other way around? The commit event already generates a version number. Usually there are “magic strings” you can put in files that on a fetch put that version number there.
@normen said:
Ah, generally, I thought for the natives or something.. Thing is, what part of the engine would define that? The single plugins all have build numbers but the people that deeply mess up their installs often have mixed jar files and whatnot. Also whats with the people who build themselves?
Yes this won't help in all cases (manually messing up the composition of the system). As Empire_Phoenix says the trick is to be able to backtrack from an installation to a revision in source control. I've usually tackled this in the build system (like zarch suggests) and assumed that the installation "bundle" can have a single number even if the components have their separate revisions.
I probably confused the issue by talking about build numbers, it is probably more accurate to talk about something akin to release-numbers and consider every nightly build a "release". The composition of the release (i.e. what revisions of the various modules) needs to tracked but that can be solved.
Not a big thing but I think it could be helpful. In dream-land :) it could shorten this:
User: "I have a problem, here is a screenshot"
Forum: "Is this stable or nightly?"
User: "Nightly"
Forum: "When did you update?"
To:
User: "I have a problem, here is a screenshot"
Forum: "I see you have revision X, that has been fixed in revision Y"
The nightlies all have build numbers in the respective SDK plugins version numbers, the stable ones will be e.g. 3.0.1 in the future. Like I say it only makes sense if you have an actual original build (SDK update).
…and this is something that is created and packaged on build, not on commit… using either something similar to what zarch suggests or some other approach.
For Mythruna, I stick a build.time file in the build/classes directory and look it up as a class resource.
Normen is right, though… it gets more complicated for the plugins and stuff.
Yeah, it might be misleading to invent a single number for the set of plugins in the SDK that is updated everytime one plug-in is updated. I was mostly thinking about the engine version and something like pspeed says with build.time or something, but still, more trouble than it is worth I guess.