SpotLight.java keeps printing Debug Code

@normen said: That doesn't mean you can't commit to trunk as a non-core-member though. If you paste a patch here so we can check it and ask us if you can commit that as it is you sure can. But for breaking or changing the engine you need to be a core member. :)

Yeah, we’ve given non-core devs commit access before. Many times.

For stuff that isn’t already discussed patches (or simple stuff like removing printlns :)) usually it’s good to post to the forum first for discussion. It prevents heartache if the commit then just gets reverted because it had some problem that would have easily come out in discussion.

For really active committers, it’s also good to have them in the core dev chat. @sgold, I actually recommended you for this some time back in a “we should keep an eye on him because he may be good for the dev chat” kind of way. You were a little light on the forum for a bit after that so I didn’t think about it again. I still think you’d be a good fit there.

2 Likes
@normen said: That doesn't mean you can't commit to trunk as a non-core-member though. If you paste a patch here so we can check it and ask us if you can commit that as it is you sure can. But for breaking or changing the engine you need to be a core member. :)

that sort of methodology kind of just encourages people to not bother to contribute though. this situation even just showed even if a patch is accepted (like the wont i posted back in october). it likely wont ever even get put in to stable, despite how trivial the patch is.

you guys (the core developers) clearly work very hard and have devoted a lot to this project, and you guys have done very good work. jMonkey is pretty much THE 3D scenegraph for java. However, I think you guys might want to consider loosening your grip on the project some and allow some of the load get offloaded on to the community.

jMonkey is your guy’s project, if youd rather keep the tight grip just because thats what you want to do. thats your choice. I run my own projects the way I want to run them as well.

However if youre looking for outside contribution, I dont think it is very inviting to say “make a post and maybe a developer will like it enough to remember to implement it, and even then it might just get lost in chaos”. I know github has been suggested due to how it has features just for these sort of purpose built in to it. But im not really interested in lobbying for what tools you guys should use. but i just want to throw in that theres community members who want to contribute but dont necessarily want to have to spend the time to break through the social barrier on the forums.

@icamefromspace said: this situation even just showed even if a patch is accepted (like the wont i posted back in october). it likely wont ever even get put in to stable, despite how trivial the patch is.

I think this conclusion is inaccurate.

Patches accepted into trunk can be expected to eventually reach a stable release (unless they’re reverted). Patches made prior to September 2013, for instance, are already in 3.0.5. The fix in question missed the deadline for 3.0final, but I expect it’ll be in 3.1 or 4.0 or whatever the next branch ends up being. There may be no announced target date or feature set for 3.1/4.0, but that doesn’t mean it won’t happen.

Presumably someone will correct me if I’m mistaken on this.

@sgold said: I think this conclusion is inaccurate.

Patches accepted into trunk can be expected to eventually reach a stable release (unless they’re reverted). Patches made prior to September 2013, for instance, are already in 3.0.5. The fix in question missed the deadline for 3.0final, but I expect it’ll be in 3.1 or 4.0 or whatever the next branch ends up being. There may be no announced target date or feature set for 3.1/4.0, but that doesn’t mean it won’t happen.

Presumably someone will correct me if I’m mistaken on this.

That’s right. The next trunk release will be 3.1 and include all of the stuff done to trunk. No ETA yet but it’s not soon.

This patch will probably make it back into 3.0.x also.

1 Like
@icamefromspace said: that sort of methodology kind of just encourages people to not bother to contribute though. this situation even just showed even if a patch is accepted (like the wont i posted back in october). it likely wont ever even get put in to stable, despite how trivial the patch is.

you guys (the core developers) clearly work very hard and have devoted a lot to this project, and you guys have done very good work. jMonkey is pretty much THE 3D scenegraph for java. However, I think you guys might want to consider loosening your grip on the project some and allow some of the load get offloaded on to the community.

jMonkey is your guy’s project, if youd rather keep the tight grip just because thats what you want to do. thats your choice. I run my own projects the way I want to run them as well.

However if youre looking for outside contribution, I dont think it is very inviting to say “make a post and maybe a developer will like it enough to remember to implement it, and even then it might just get lost in chaos”. I know github has been suggested due to how it has features just for these sort of purpose built in to it. But im not really interested in lobbying for what tools you guys should use. but i just want to throw in that theres community members who want to contribute but dont necessarily want to have to spend the time to break through the social barrier on the forums.

First thats not what we talk about here. We are talking about contributors that take the initiative and commit whatever they want changed themselves. Letting us do the work will obviously make the result dependent on our personal time.

And if you want a game engine where everybody can commit as he likes and the contributions are not checked properly, you can still download jME2. jME3 won’t be that. What “social barrier” could there be when a patch is posted that clearly makes the engine better? None. And in these cases there never is one. “Social issues” arise when people want to tell use how the engine should look and we don’t agree or when somebody posts changes that cannot be incorporated as they are (like the various deferred shaders, animation systems that don’t base on the existing one, vegetation systems that don’t work according to jME paradigms etc.).

Finally, you can always grab the whole engine code and do whatever you want with it. Make a branch, make a project where you accept everybodys contributions. Whatever. Just don’t tell us what to do just because you downloaded something we put out for free, ok?

I am quite sure nobody here want that everybody has full commit rights. From my point of view, the current workflow secures a stable engine in the long run. But it also implies that changes are implemented slower in the stable branch…

It’s just that some modifications require lots of changes deep in the core code, lighting is probably the best example here, it is basically not possible to just write a plugin that changes the whole lighting system. And for such stuff it is very likely that user code won’t be accepted anyways. (Kind of understandable however)

Beside that, i would bet that anybody out there writing a bigger scale game has his local copy of the engine and develop against that.

As a future note, i have never seen a list of stuff a “plugin” must have in order to follow the jme3 way…

@zzuegg said: It's just that some modifications require lots of changes deep in the core code, lighting is probably the best example here, it is basically not possible to just write a plugin that changes the whole lighting system. And for such stuff it is very likely that user code won't be accepted anyways. (Kind of understandable however)

Note: this is a particular area I keep an eye on. If there is some change I see, architectural or otherwise, that would facilitate doing more things as add-ons then those are my goals. Custom buckets being one example. Core lighting may always require core changes but for example, I suspect that there is also some middle ground where a new lighting model could be injected/overlaid (ignoring the existing one) without the developer of such model requiring core engine mods.

Some things will never be possible but the “ideal” is my personal dream.

@pspeed said: That's right. The next trunk release will be 3.1 and include all of the stuff done to trunk. No ETA yet but it's not soon.

This patch will probably make it back into 3.0.x also.

In that case … may I commit the following patch to /branches/3.0final/engine/src/core/com/jme3/light/SpotLight.java :

--- Base (BASE)
+++ Locally Modified (Based On LOCAL)
@@ -77,7 +77,6 @@
             outerCos -= 0.001f;
         }
         packedAngleCos+=outerCos;
-        System.out.println("anfle"+ packedAngleCos);
     }
 
     @Override

?

Not to the 3.0 final branch, no.

@normen said: Not to the 3.0 final branch, no.

Is there a reason we can’t remove this println from 3.0 final?

@pspeed said: Is there a reason we can't remove this println from 3.0 final?

Yes. It will be built with the changes but the version number will not advance.

@normen said: Yes. It will be built with the changes but the version number will not advance.

Ah, so the fix would be ok if we up the version also… before midnight EST?

…then I start to wonder if there was any other safe stuff that should go over to the branch.

@pspeed said: Ah, so the fix would be ok if we up the version also.... before midnight EST?

…then I start to wonder if there was any other safe stuff that should go over to the branch.

Exactly :slight_smile: We should collect these, especially as Stephen seems to be on a roll :wink:

@sgold while you on a roll, and before I forget, can you commit this? @nehon must still be hungover :roll:

http://hub.jmonkeyengine.org/forum/topic/bug-fix-for-mesh-deepclone/

1 Like

May I commit the following patch to /branches/3.0final/engine/src/core/com/jme3/light/SpotLight.java :

--- Base (BASE)
+++ Locally Modified (Based On LOCAL)
@@ -77,7 +77,6 @@
             outerCos -= 0.001f;
         }
         packedAngleCos+=outerCos;
-        System.out.println("anfle"+ packedAngleCos);
     }
 
     @Override

if I also commit the following patch to /branches/3.0final/engine/src/core/com/jme3/system/JmeVersion.java

--- Base (BASE)
+++ Locally Modified (Based On LOCAL)
@@ -32,5 +32,5 @@
 package com.jme3.system;
 
 public class JmeVersion {
-    public static final String FULL_NAME = "jMonkeyEngine 3.0.5";
+    public static final String FULL_NAME = "jMonkeyEngine 3.0.6";
 }

and the following patch to /branches/3.0final/engine/src/core/com/jme3/scene/Mesh.java

--- Base (BASE)
+++ Locally Modified (Based On LOCAL)
@@ -240,8 +240,8 @@
             }
             
             clone.vertexArrayID = -1;
-            clone.vertCount = -1;
-            clone.elementCount = -1;
+            clone.vertCount = vertCount;
+            clone.elementCount = elementCount;
             
             // although this could change
             // if the bone weight/index buffers are modified

?

No, you may not commit to the 3.0final branch at all. You can tell us which commits to trunk you’d like to see merged in the next stable update though.

@Normen, what’s the timeframe for proposing the list of commits?

@sgold said: @Normen, what's the timeframe for proposing the list of commits?

Don’t know, before we put out another update I guess ^^ We had a relatively high frequency of updates with some coming out for only one fix, I’d like to collect a few more before 3.0.6

Followup: I proposed a list of commits yesterday and POOF now we have a shiny new 3.0.7 release which fixes this issue and many others.