I want to add this to the javadoc of InputHandler.update:

    * This method should normally not be overwritten by subclasses. If an InputHandler needs to

    * execute something in each update register an action with triggerCommand = null. Exception to this

    * is an InputHandler that checks additional input types.

    * @see #addAction(com.jme.input.action.InputAction, String, boolean)

(comment in addAction changed accordingly)

because the update method should process input only and invoke actions IMO. If this seems right for you, we should reflect that in existing input handlers, namely:

ChaseCamera, ThirdPersonHandler and FlagRushHandler

I don't have a problem with that in the General case, but don't change FlagRushHandler. The whole purpose of the handler is to show people how to do things in jME, and that requires going a bit unorthodox route. That is, it's not a handler that is part of the system, but one that shows how the system works. So, don't touch it, unless you want to rewrite a couple of the tutorials.

Well, especially for the FlagRushHandler I posted here: if people should learn how to do it - it should be the nice way, shouldn't it? I did not want to change it for the reason you wrote - I wanted to ask you to change it in the tut, if you agree it's better…

You can't learn much if you don't dig into the inner workings. After looking at ThirdPersonhandler and chase camera, I'm not so sure Renanse is going to be real excited about this either. Worry about getting all these major changes done that you want to do and don't worry about minor details right now.

I realize I didn't explain myself very well regarding the FlagRushHandler. Let me try again.

What I'm saying is don't modify any existing FlagRushHandler's because the represent a tutorial series. I want to take the reading into different parts of the system even if it doesn't mean doing things the "right way". Then in a later lesson (usually the next) I show a better way to do something. So, future FlagRushHandler's will do things the "right way", but don't modify the old ones (unless it's required to compile).

On a related note:

We should have the ability to create Actions that will be executed by the handler every update cycle (not requiring a trigger).

Ok, agreed on that learning stuff  :slight_smile:

mojomonk said:

We should have the ability to create Actions that will be executed by the handler every update cycle (not requiring a trigger).

Yes, that's already in - specify null as triggerCommand.
Yes, that's already in - specify null as triggerCommand.


Well, so far for me it hasn't been too bad. At first, I'll see a change and start wondering why it was done, and get a little annoyed. But soon, I start playing with it, and see why it was done and that the new way is both easier to use and more powerful. This is also the reason my first response tends to be a little more blunt. Change is hard. As Renanse said this is a major system so when new updates come in, it affects a lot of things and is a little frightening at first. I haven't disagreed with anything you've done so far, after I've understood how it works. But like a said, that initial shock is hard, then add the flack from users, it makes it a little harder to take.

As Renanse said, since we are getting changes a little bit at a time, it requires changing our code a little bit at a time. And causes us to have to go through the process of: "Oh no, my stuff is broken!" -> "Why did that change???" -> "Ok, this is what I need to do" -> "Ah, I like this" each time. It's hard on the nerves. :slight_smile:

So a minimal amount of check-ins and good documentation of what changed, why it changed, and how to convert is good.

Honestly, I have to say that the input changes have been done a bit too haphazardly considering their scope.  In the past when we've had big changes, the developer doing them would completely finish them locally, maybe give the other developers access to test the changes and then check them in when it's pretty certain there will not be further large scale api changes.

I was under the impression that these input changes were done.  Maybe I'm just out of the loop, but the changes keep coming in and are tendrilling their way through the rest of the system.

My two cents.  I realize I'm out of state now and not well in touch, so maybe that's why I feel this way, still…  :expressionless:

:// when I asked Mark about the procedure of making changes, he wrote “basically, the only rules we have are don’t break anything, try to keep your check-ins in the spirit of the roadmap, and post on the forums any time you check something in” - I really tried to adhere to that. I thought checking in to CVS was the way to show the other developers what’s finished. I surely can do it the way you wrote - but someone should tell me  :expressionless:

And about the changes being “haphazardly” (what is a hard word if I understand it) - the API has changed alot, that’s true, but I got the impression that the input system and handlers really needed to be refurbished. And I thought, you both had this opinion, too. So I understood that I should change the api.

It seems to me that it’s partially a communication problem - I asked you (here), Renanse, if you were unhappy with the changes I made, but you did not comment on that (until now)…

Sorry, I need to remember to bit a bit more clear when I post sometimes.  I also like where you are taking the Input code, just as Mark says.  What I was calling "a bit too haphazard" (which means without enough planning) was the number of times and the frequency it was changing in cvs.  Because they are going out to the public "a little bit here and a little bit there", it gets confusing for those people who keep up to date with jME.  I understand it is cvs and they take a chance by using the most recent stuff…  but still, it's just a lot better to either check everything in as a whole and shock people one time, or else write out all of the upcoming changes on the forum ahead of time so people expect them and then check them in a bit at a time.  At least then you can say you already warned them.  As it is now, the average user reading the forums might be thinking each day that the input changes are pretty much done only to find out the next day that they have more work to do.

Anyhow, please don't take it the wrong way.  :)  jME is know for being very friendly to its users and I can be a bit overzealous in protecting that appearance.

We should protect that appearance!  :slight_smile: So I will try to be more careful about that next time and communicate it better…