Non-main menus don't play menu sounds. Is there a bitset I'm missing to enable them?
--
"Today is victory over yourself of yesterday; tomorrow is victory over lesser men" -Miyamoto Musashi.
_______________________________________________ Ohrrpgce mailing list ohrrpgce <at> lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
2009/8/1 Adam Perry <arperry <at> gmail.com>: > Non-main menus don't play menu sounds. Is there a bitset I'm missing to > enable them? > > -- > "Today is victory over yourself of yesterday; tomorrow is victory over > lesser men" -Miyamoto Musashi. They do for me; and there's no such bitset. Are you talking about custom menus, or the built in menus?
On Sat, Aug 1, 2009 at 5:00 PM, Ralph Versteegen<teeemcee <at> gmail.com> wrote: > 2009/8/1 Adam Perry <arperry <at> gmail.com>: >> Non-main menus don't play menu sounds. Is there a bitset I'm missing to >> enable them? >> >> -- >> "Today is victory over yourself of yesterday; tomorrow is victory over >> lesser men" -Miyamoto Musashi. > > They do for me; and there's no such bitset. Are you talking about > custom menus, or the built in menus? Built-in menus called via plotscripting. -- -- "Today is victory over yourself of yesterday; tomorrow is victory over lesser men" -Miyamoto Musashi.
james 2009-08-04 11:02:38 -0700 (Tue, 04 Aug 2009) 246 Update the attack editor's preview to use slices instead of loadsprite/drawsprite This fixes the graphical corruption that happened each time you brought up the F1 help menu from the attack editor Gosh I love slices. They are made out of great. --- U wip/flexmenu.bas
And reinforced with awesome? ------Original Message------ From: subversion <at> HamsterRepublic.com Sender: ohrrpgce-bounces <at> lists.motherhamster.org To: ohrrpgce <at> lists.motherhamster.org ReplyTo: ohrrpgce <at> lists.motherhamster.org Subject: [Ohrrpgce] SVN: james/2782 Update the attack editor's preview touse slices instead of loadsprite/d Sent: Aug 4, 2009 2:02 PM james 2009-08-04 11:02:38 -0700 (Tue, 04 Aug 2009) 246 Update the attack editor's preview to use slices instead of loadsprite/drawsprite This fixes the graphical corruption that happened each time you brought up the F1 help menu from the attack editor Gosh I love slices. They are made out of great. --- U wip/flexmenu.bas _______________________________________________ Ohrrpgce mailing list ohrrpgce <at> lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org -- Mike Caron
http://rpg.hamsterrepublic.com/bugzilla/show_bug.cgi?id=740 --- Comment #1 from Adam Perry <arperry <at> gmail.com> 2009-08-04 11:13:46 PDT --- Is this hard? Is this feasible? If here's not a chance that this will get done anytime soon, I'd like to know. -- -- Configure bugmail: http://rpg.hamsterrepublic.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
james 2009-08-04 11:17:32 -0700 (Tue, 04 Aug 2009) 130 Update enemy editor to use slices for the preview. Fixes graphical corruption when using F1 help. ... and reinforced with awesome --- U wip/flexmenu.bas U wip/subs.bas
james 2009-08-04 11:24:45 -0700 (Tue, 04 Aug 2009) 133 Make sure to free the preview slices for both the Attack editor and the Enemy editor when you exit out of them. fixes a memory leak. --- U wip/flexmenu.bas U wip/subs.bas
http://rpg.hamsterrepublic.com/bugzilla/show_bug.cgi?id=740 --- Comment #2 from Bob the Hamster <Bob <at> HamsterRepublic.com> 2009-08-04 11:29:22 PDT --- I actually have some partial work for this in the current nightlies. I am upgrading the text box system to be draw with slices. You can test it out by pressing ~F8 to switch to the new textbox renderer. The only visible difference right now is that the text appears all at once, not line-by-line. Once I am satisfied with the new textbox renderer, I will turn it on by default and remove the old one. Then I can add a command like: get text box portrait slice which would return a slice handle that you can manipulate as you please. Another thing that is holding me up is that there will eventually be a heckofa lot of different built-in slices like this, and I don't really like the idea of having a separate hard-coded command for getting every single dang one of them. ... although for the specific case of the text box portrait, it is probably okay, and I can worry about the general case later. -- -- Configure bugmail: http://rpg.hamsterrepublic.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
I have an idea I want to throw out for the other developers to comment on. I don't tknow if this is a good idea or not, but I am thinking out out here... Eventually, various standard gui elements will be drawn using slices. I already have a partial implementation of drawing text boxes using slices. I have two somewhat conflicting goals in doing this. 1) I want to make it easier for us as developers to maintain and extend the interface 2) I want to make it possible for game authors to tweak the interface with their scripts. The reason I think these two goals could be at odds, is because once game authors start writing scripts that make assumptions about the tree-layout of the interface, those tree-layouts can't be changed without a risk of breaking games. For example, suppose I implement: get text box portrait slice which returns a handle to the portrait of the currently displaying text box. An enterprising scripter might discover that they can get the text box container by doing parent slice(parent slice(get text box portrait slice)) Then they might discover that they can get a handle to the text of the text box by doing first child(first child(parent slice(parent slice(get text box portrait slice)))) Now obviously that is messy code, but it would work. And maybe I haven't gotten around to implementing "get text box text slice" yet (yeah, the namespace for these command iss a whole different discussion) so since it works, somebody does it, but down the line, maybe I change the order in which the slices are constructed, or add an aditional container slice around the portrait to handle variable padding, or who knows what? Breakage! One option is to grin and bear it. We already have a situation like this with some of our other commands (the one for manipulating enemy data comes to mind) But what if we add a feature to the slices that allows us to mark certain slices as "protected"? A protected slice could still be asked for specifically, maybe by commands like: get text box portrait slice or better yet: slice by name(string) but if you tried to get a protected slice using "parent slice" it would fail and if you tried to get a protected slice with "first child" or "next sibling" it would be skipped. That way it would not be possible to traverse protected slices in a dangerous way, but you could still get handles to them and you could still give them new children. Alternately, maybe we could protect slices but just write a debug warning any time someone tries to traverse to one of them... that would alow people to write bad dangerous slice code, but it would at least give them a heads-up first. Another alternative would be to make protected slices, but to add commands like "unsafe parent slice" "first unsafe child" "next unsafe sibling" to allow scripters to traverse protected slices if they REALLY want to, but making our documentation job easy, since there would then only be a couple places that we would have to write "use this at your own risk!!!" (instead of having to write it in the docs for almost every command :P) --- James
RSS Feed12 | |
|---|---|
81 | |
118 | |
126 | |
68 | |
174 | |
31 | |
48 | |
89 | |
148 | |
27 | |
161 | |
100 | |
108 | |
95 | |
207 | |
140 | |
18 | |
59 | |
108 | |
205 | |
108 | |
215 | |
330 | |
269 | |
219 | |
15 | |
36 | |
204 | |
116 | |
158 | |
339 | |
296 | |
151 | |
67 | |
96 | |
211 | |
207 | |
87 | |
130 | |
253 | |
339 | |
232 | |
390 | |
209 | |
134 | |
61 | |
133 | |
128 | |
190 | |
102 | |
158 | |
170 | |
38 | |
106 | |
275 | |
185 | |
232 | |
128 | |
66 | |
173 | |
73 | |
100 | |
292 | |
211 | |
240 | |
393 | |
203 | |
254 | |
340 | |
322 | |
241 | |
150 | |
204 | |
148 | |
323 | |
95 | |
161 | |
197 | |
97 | |
146 | |
203 | |
446 | |
180 | |
187 | |
125 | |
303 | |
374 | |
201 | |
40 | |
46 | |
143 | |
137 | |
77 | |
99 | |
148 | |
150 | |
56 | |
164 | |
28 |
