From: Erik V. <eri...@hc...> - 2007-06-18 20:00:34
|
Committed some bug fixes and minor improvements to the previous commit. I have also implemented two feature requests to sort buyable privates and trains in selection popups such that those controlled by the current player come before those controlled by other players. Erik Vos |
From: brett l. <wak...@gm...> - 2007-06-23 19:37:13
|
Awesome... I fixed my classpathing issue, so now the game runs again. So... first question I have is in the Game Status window, in the Move menu, why are there two undo options? There's "Undo" and "Undo!". Next... it seems that I can't open the Map during the Start Round. When I select it from the Game Status window's Options menu, I get a ClassCastException. Last... it looks like there's an issue with Util.getStreamForFile(). It's not finding any of the images for me. I'm going to try to debug this. ---Brett. On 6/18/07, Erik Vos <eri...@hc...> wrote: > Committed some bug fixes and minor improvements to the previous commit. > > I have also implemented two feature requests to sort > buyable privates and trains in selection popups such that > those controlled by the current player come before those > controlled by other players. > > Erik Vos > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: Erik V. <eri...@hc...> - 2007-06-23 21:13:11
|
> So... first question I have is in the Game Status window, in the Move > menu, why are there two undo options? There's "Undo" and "Undo!". The idea is that ultimately players will only be able to undo their own moves, but the game master will be able to undo everything. So the whole undo stack is kept, but players can only move between certain boundaries. Undo! simulates this master command; for now it is there mainly for testing. Don't expect it to work everywhere yet. > Next... it seems that I can't open the Map during the Start Round. > When I select it from the Game Status window's Options menu, I get a > ClassCastException. Fixed. > Last... it looks like there's an issue with Util.getStreamForFile(). > It's not finding any of the images for me. I'm going to try to debug > this. I have wrestled with that as well. I think the fix was to put all images in the Rails jar file. Finding property and image files clearly still needs work. Erik. |
From: brett l. <wak...@gm...> - 2007-06-24 02:39:44
|
On 6/23/07, Erik Vos <eri...@hc...> wrote: > > So... first question I have is in the Game Status window, in the Move > > menu, why are there two undo options? There's "Undo" and "Undo!". > > The idea is that ultimately players will only be able to > undo their own moves, but the game master will be able to undo everything. > So the whole undo stack is kept, but players can only move between > certain boundaries. > Undo! simulates this master command; for now it is there mainly for testing. > Don't expect it to work everywhere yet. > Ahhh... how about we relabel it as "Master Undo (for testing)" ? > > Last... it looks like there's an issue with Util.getStreamForFile(). > > It's not finding any of the images for me. I'm going to try to debug > > this. > > I have wrestled with that as well. I think the fix was to put all images > in the Rails jar file. Finding property and image files clearly still needs > work. > I found the problem. there's a leading forward slash on the path name. it needs to be removed. ---Brett. |
From: Erik V. <eri...@hc...> - 2007-06-24 13:50:17
|
> On 6/23/07, Erik Vos <eri...@hc...> wrote: > > > So... first question I have is in the Game Status > window, in the Move > > > menu, why are there two undo options? There's "Undo" and "Undo!". > > > > The idea is that ultimately players will only be able to > > undo their own moves, but the game master will be able to > undo everything. > > So the whole undo stack is kept, but players can only move between > > certain boundaries. > > Undo! simulates this master command; for now it is there > mainly for testing. > > Don't expect it to work everywhere yet. > > > > Ahhh... how about we relabel it as "Master Undo (for testing)" ? Hmm, isn't that a bit longish? I was inspired by the vi commands that get a forcing character when suffixed with a !, for instance q! forces quit where q doesn't. I agree that some explanation is needed, perhaps a tooltip? > > > Last... it looks like there's an issue with > Util.getStreamForFile(). > > > It's not finding any of the images for me. I'm going to > try to debug > > > this. > > > > I have wrestled with that as well. I think the fix was to > put all images > > in the Rails jar file. Finding property and image files > clearly still needs > > work. > > > > I found the problem. there's a leading forward slash on the path > name. it needs to be removed. Ah, yes, that is what happens if tile.root_directory does not have a value in my.properties. I have now made sure that the slash is only inserted if that property exists and is not empty. Erik. |
From: brett l. <wak...@gm...> - 2007-06-24 16:10:18
|
On 6/24/07, Erik Vos <eri...@hc...> wrote: > > On 6/23/07, Erik Vos <eri...@hc...> wrote: > > > > So... first question I have is in the Game Status > > window, in the Move > > > > menu, why are there two undo options? There's "Undo" and "Undo!". > > > > > > The idea is that ultimately players will only be able to > > > undo their own moves, but the game master will be able to > > undo everything. > > > So the whole undo stack is kept, but players can only move between > > > certain boundaries. > > > Undo! simulates this master command; for now it is there > > mainly for testing. > > > Don't expect it to work everywhere yet. > > > > > > > Ahhh... how about we relabel it as "Master Undo (for testing)" ? > > Hmm, isn't that a bit longish? > I was inspired by the vi commands that get a forcing character when > suffixed with a !, for instance q! forces quit where q doesn't. > I agree that some explanation is needed, perhaps a tooltip? > A tooltip would help, but in general having two menu options named the same thing is going to be confusing. I don't really see a problem with a long menu option. We're not limited for space there. > > > > Last... it looks like there's an issue with > > Util.getStreamForFile(). > > > > It's not finding any of the images for me. I'm going to > > try to debug > > > > this. > > > > > > I have wrestled with that as well. I think the fix was to > > put all images > > > in the Rails jar file. Finding property and image files > > clearly still needs > > > work. > > > > > > > I found the problem. there's a leading forward slash on the path > > name. it needs to be removed. > > Ah, yes, that is what happens if tile.root_directory does not have > a value in my.properties. I have now made sure that the slash is only > inserted if that property exists and is not empty. > Excellent. That sounds like a better fix than the one I had come up with. ---Brett |
From: Erik V. <eri...@hc...> - 2007-06-24 20:47:23
|
> > > Ahhh... how about we relabel it as "Master Undo (for testing)" ? > > > > Hmm, isn't that a bit longish? > > I was inspired by the vi commands that get a forcing character when > > suffixed with a !, for instance q! forces quit where q doesn't. > > I agree that some explanation is needed, perhaps a tooltip? > > > > > A tooltip would help, but in general having two menu options named the > same thing is going to be confusing. > > I don't really see a problem with a long menu option. We're not > limited for space there. Actually, I meant that the appearance of two options is temporary. ultimately, I think there would be only one undo option (labelled just "Undo"), and it would depend on the user's role (player or Master/Moderator) what its meaning would be. For now I suppose we have two ways in which the program can be used: 1. "Hotseat", which (if I'm right) means that players take turns behind one screen. In that case, the (restricted) player undo would apply. 2. Moderator, in which case one person replays or moderates a game. In this case the unrestricted version would apply. What about adding a startup option (two radio buttons?) to select between these two usages? Then the "Undo!" could go. Erik. |
From: brett l. <wak...@gm...> - 2007-06-24 21:06:22
|
On 6/24/07, Erik Vos <eri...@hc...> wrote: > > > > Ahhh... how about we relabel it as "Master Undo (for testing)" ? > > > > > > Hmm, isn't that a bit longish? > > > I was inspired by the vi commands that get a forcing character when > > > suffixed with a !, for instance q! forces quit where q doesn't. > > > I agree that some explanation is needed, perhaps a tooltip? > > > > > > > > > A tooltip would help, but in general having two menu options named the > > same thing is going to be confusing. > > > > I don't really see a problem with a long menu option. We're not > > limited for space there. > > Actually, I meant that the appearance of two options is temporary. > ultimately, I think there would be only one undo option (labelled just > "Undo"), > and it would depend on the user's role (player or Master/Moderator) what > its meaning would be. > s> For now I suppose we have two ways in which the program can be used: > > 1. "Hotseat", which (if I'm right) means that players take turns behind one > screen. > In that case, the (restricted) player undo would apply. > > 2. Moderator, in which case one person replays or moderates a game. > In this case the unrestricted version would apply. > > What about adding a startup option (two radio buttons?) > to select between these two usages? Then the "Undo!" could go. > Here are some other ways we could do it: 1) We could add a new temporary drop-down menu for testing new functionality, and just enable/disable it this new menu with a "development mode" startup option. 2) We can move the "player undo" back onto the game status window, next to the Done button. Then rename the Move menu to something like "Moderator", so that the Undo that's in there is more clearly a "Moderator Undo" I like #1 because then we can add anything in there without worrying too much about choosing a permanent position within the UI for it. This also allows us to have these potentially confusing UI elements disabled by default when we ship out new JARs. I like #2 because it creates a clear differentiator that may be useful for other features and could be a less temporary (more permanent) way of presenting that feature. At this point, it doesn't *need* to be fixed right away. We can simply disable it if there are enough other things that have changed to merit a release. ---Brett. |
From: Erik V. <eri...@hc...> - 2007-06-24 21:28:28
|
> -----Original Message----- > From: rai...@li... > [mailto:rai...@li...] On Behalf > Of brett lentz > Sent: Sunday 24 June 2007 22:06 > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Fixes & sorting > > On 6/24/07, Erik Vos <eri...@hc...> wrote: > > > > > Ahhh... how about we relabel it as "Master Undo > (for testing)" ? > > > > > > > > Hmm, isn't that a bit longish? > > > > I was inspired by the vi commands that get a forcing > character when > > > > suffixed with a !, for instance q! forces quit where q doesn't. > > > > I agree that some explanation is needed, perhaps a tooltip? > > > > > > > > > > > > > A tooltip would help, but in general having two menu > options named the > > > same thing is going to be confusing. > > > > > > I don't really see a problem with a long menu option. We're not > > > limited for space there. > > > > Actually, I meant that the appearance of two options is temporary. > > ultimately, I think there would be only one undo option > (labelled just > > "Undo"), > > and it would depend on the user's role (player or > Master/Moderator) what > > its meaning would be. > > > s> For now I suppose we have two ways in which the program > can be used: > > > > 1. "Hotseat", which (if I'm right) means that players take > turns behind one > > screen. > > In that case, the (restricted) player undo would apply. > > > > 2. Moderator, in which case one person replays or moderates a game. > > In this case the unrestricted version would apply. > > > > What about adding a startup option (two radio buttons?) > > to select between these two usages? Then the "Undo!" could go. > > > > Here are some other ways we could do it: > > 1) We could add a new temporary drop-down menu for testing new > functionality, and just enable/disable it this new menu with a > "development mode" startup option. > > 2) We can move the "player undo" back onto the game status window, > next to the Done button. Then rename the Move menu to something like > "Moderator", so that the Undo that's in there is more clearly a > "Moderator Undo" > > > > I like #1 because then we can add anything in there without worrying > too much about choosing a permanent position within the UI for it. > This also allows us to have these potentially confusing UI elements > disabled by default when we ship out new JARs. > > I like #2 because it creates a clear differentiator that may be useful > for other features and could be a less temporary (more permanent) way > of presenting that feature. Both look good to me. In fact we could marry your two options by leaving Move in *and* adding Moderator. Another factor to look at is consistency between the various screens. Currently, StartRound has a menu (incl Move), but OperatingRound hasn't, so it needs the Undo/Redo as buttons. > At this point, it doesn't *need* to be fixed right away. We can simply > disable it if there are enough other things that have changed to merit > a release. Indeed. I don't have strong feelings about how the final UI should incorporate all possible user actions, but I tend to prefer an approach where normal game actions are executed via buttons, and exceptional actions via menu options. That would favour putting Undo/Redo into the menu in all screens. Erik. |