Process

jaynabonne
Now that I've begun stepping into the Quest code, I was wondering about guidelines or at least the preferred process for implementing changes.

As an example: looking at "HandleCommand", I can see at least two possible immediate simple changes based on both my own experience and what I have read in the forums:

1) Allow (via a game attribute) multiple command processing to be turned off.
2) Disable (via a game attribute) echoing the command the user has just typed.

Or, coming at a different way:
1) Invoke a script on the game object which takes the input line and returns a list of commands (defaults to current behavior of splitting the command line, but a simple override could just return the command line as is).
2) Invoke a script on the game object to echo the line (defaults to current behavior of echoing but a simple override would do nothing).

That raises a few questions. First, can we just go in and start mucking with things, or should we create an issue first so that it can be at least tracked and possibly even pre-approved? I know that it is often down to a single person (Alex in this case) to have the design principles in mind and enforce them, and make sure that the code doesn't go off the rails, so the question is, is that done and if so how?

The second question is just that of design philosophy. In the two "ways" above, the former allows behavior change with a simple game attribute change but is less flexible. The latter way gives the move advanced scripter more control, but might be tricky for the more novice.

I suppose a third question would be: if we do make multiple changes, is it better to have separate pulls for each of them, so they can be separately approved/rejected and integrated? Or is a single pull able to be selectively accepted? (Or does it matter?)

Any thoughts on the above would be greatly appreciated!

Alex
In this particular case I think it's better to have simple boolean attributes on the game object that can turn the options on or off. I think if a game author wants complete control, they can just go in and modify the core library anyway, so I can't see much value in having a separate mechanism for a game script to override the behaviour.

If you create an issue first, that will at least give everybody some idea of what you're working on, so people can comment on it. But on the other hand if it's quite quick to implement, there's no harm in just going ahead and doing it and then sending a pull request.

For multiple unrelated changes, I'd prefer you to use separate forks. That way the changes can be merged (or not) independently - as a pull request is all or nothing (well, there may be some advanced Mercurial things I'm not aware of I suppose but it makes sense to me to just keep things simple).

jaynabonne
Understood. :) Thanks very much.

This topic is now closed. Topics are closed after 60 days of inactivity.

Support

Forums