Dicemaster Slayer

can we see some code? Break and ContinueLoop seem to me to be the best option in this case, but until i see code i can't make a definitive suggestion

yeah sorry about the textwall basically modal windows, how to?

So, writing a game, has one big window that holds everything. Mostly. During a player's turn in the game, they have the choice of 4 actions, all of which have their own windows secondary to the main one. In addition, I have a sort of custom error dialog box that pops up when the user does something I don't want them to (invalid filename entry, trying to load a file that isn't a saved game, etc.), but is also used for help boxes and general information boxes. This error box can be called by the main window or by the secondary windows. What I am trying to accomplish is if the player starts an action (which creates a child window for that action), then they cannot use the main window until that action has finished (the secondary window is GUIDelete'd). Also, if the error box pops up, then you can't use the main window (or any secondary window, if present) until you close the error box. I've attempted this thus far by making the secondary windows childs of the main window, and setting @SW_DISABLE on the main window while the secondary is present. When the secondary leaves, I @SW_ENABLE the main window. This is simple enough (and mostly works), but it caused some flickering of the main window when the secondary was opened or closed. Same with the error box, if the program were to call it then it would disable the current window (which is easy to determine, given the program flow), show the box, and then reenable the window when the box leaves. In this way, a secondary window could call the error box, where the main window would already be disabled, and the error box would disable the secondary. So, tl;dr, I need to be able to have modal windows, also with multiple modal windows up at the same time. I've tossed the idea around in my head of using modal GUIs instead of @SW_DISABLE or ENABLE, simply because (so I hope) it will eliminate or at least diminish the flickering of the main window when the secondary or error windows are created and deleted. My thought is: secondary windows will be declared as modal childs of the main window. The error box will also be declared as a modal child of the main window, so that if a secondary window calls the error box, it will take precedence over the others. And my question is: What do I use to make these windows modal, as in you can't use the parent until the child is closed? $DS_MODALFRAME? $WS_EX_DLGMODALFRAME? Something completely different? Or should I just stick with @SW_DISABLEing the windows?

@PsaltyDS and weaponx : ah, i figured the INI would be throwing things off I'll try converting to Number right at the load. If it still doesn't work, well, I'll take a stab at trying the whole management process from a different angle. Thanks for the advice, and humor, everyone.

Glad my method of designing this provoked such humor among the populace. First let me address the fact that I'm using a 4-D array. It's the closest I could (think of, at least) get to OOP in Autoit, considering there are multiple players, and a lot of information that needs to be handled easily. Yes, there are other ways I could have acheived this. However, it makes enough sense to me, and so far hasn't let me down. I don't know C/++/# to make real objects the way Autoit handles them, nor am I anywhere near proficient enough in any proper database format to use them. Yes, I know the option is there for me to attempt this in some language that does support OOP (i.e. and provoking flames i'm sure, Java). I chose Autoit because of its ease of coding, not to mention everything I need to develop the program is already provided, instead of running around the Internet trying to find something that works. Second, you've probably already guessed this will be a textwall. It's unavoidable. When asking for help, anywhere, I will provide as much information as I possibly can, so that anyone that wants to tackle the problem can have (so I hope) everything they possibly need to solve it. Third, the "sample code" I posted in my first post is actual code that is run. All variables used are declared appropriately in the program ($user starts as 0, is updated when the game is loaded, the $atk_* vars are all declared in the code). It is run after the user has selected an attacker (and updates $atk_attacker) and a target player (updates $atk_targetplayer). Going into the conditional, these values are correct every time. Again, somehow it's getting the actual comparing wrong. Now, a note that I probably should have given before on how the ATK/DEF values are generated. When one loads a game, it loads from a *.ini file that contains all the game's data. The values are stored simply as "M1ATK=6", "M3DEF=12" etc. The game loads these into the $player array directly through IniRead(). Now, if this is creating strings, not numbers, that may be our problem. However, though I am likely mistaken, even if the conditional is trying to compare two strings, why does it get it right most of the time, and sometimes get it wrong. If the problem arises from it comparing strings, shouldn't it get it wrong more often? If that's still a major factor in this bug, then should I be applying Number() to the ATK/DEF values after they're loaded from the INI but before they go into the array?

Sorry about the textwall, but even including Number() around the variables, 18 should not be considered less than 5.

[EDIT] *SOLVED* Thanks to everyone that helped

i'll give those a try, thanks a bunch!

oh i'm sure it's way more complex than it has to be, but it works if i can find a way to reduce mem usage or even get it all down to one program (instead of one program per channel), that'd be greeeat

Well, the present iteration works perfectly. MP3 sounds (so glad i found out you can SoundPlay mp3s), there's a few command line params available too. The finer details on those are in the source, but I also put the switches in the Comments part on the properties box. Also have made thread: http://www.autoitscript.com/forum/index.php?showtopic=52890 the first one was pretty bad, but wasn't totally horrible (loooow quality stuff). second iteration is pretty good, but not as much selection or fidelity on the thunder, and it's wav files so it's really big. hopefully using the idea from here i'll be able to make the fourth iteration even better.

Since my recent expansion of effects will be put to use in EGv4, only the Rain/Storm theme of EG3 is available Because of its use of balloon tips (and no OS checking yet), Environment Generator v3 requires Windows 2000/XP or higher. Environment Generator is a standalone soundscape program. That is, it makes use of many sound effects to create an atmosphere of sound (the environment) on your computer. This is the third iteration of the project. EG1 was both huge and low-quality. EG2, a set of multiple themes, had better quality sounds, but was even larger, because I kept using the original WAV formats. EG3 uses only mp3s, and AutoIt's SoundPlay() function to give the highest-quality environment yet. Everything is compressed into one program, which will make itself a little corner in the Temp folder, and whip up a storm, so to speak. On exit, it removes its corner. Environment Generator's multiple sound channels is accomplished by the use of subprograms for each set of effects. In Rain/Storm, rain is given one program, looping forever. Same for wind. Then there are two channels for thunder, one distant and one nearby. Each randomly plays back a sizable repository of thunder effects. Because my effect library was limited to rain effects, only one EG3 release is available, that of Rain and Storm. On execution, it will begin with the Rain theme. You can switch the themes via the tray menu or with CTRL+SHIFT+A. Pausing is done by doubleclicking (or open the menu) the tray or CTRL+SHIFT+S. And to exit, use the tray or CTRL+SHIFT+Q. These combinations are listed by going to tray menu -> help. You can also execute Rain with various command switches to start it with storm, or paused on rain or storm (to prevent the sudden burst of sound as everything plays at once to start). Enough advertising. On to the release! EG3 consists of 64 files, including scripts and subprograms. The subprograms must be compiled first, followed by the main manager program, obviously with the FileInstall paths corrected. Or just get the compiled program. Same thing. EGv3 - Rain & Storm Download Here Source Code + Sounds Download Here Environment Generator v4 is in planning stages at this time. It will consist of many, many more effects spanning multiple themes, all customizable. We'll try to keep the memory usage to a minimum, but that's probably not easy when you're dealing with many sounds having to play at once, by way of multiple background programs. If anyone has a suggestion on how we could possibly overlay sounds on top of each other (sounds that will loop at different times or play randomly), please do send email.

ah that seems fairly effective i'll see how well that'll work and post back if there's anything else, thanks!

enigmatic thread title, sorry. i'm a mega-lurker when it comes to here, though autoit is my favorite language. tend to consult help file, but when that lets me down or just doesn't help at all, i end up here. so, on to it. *wall-o-text warning* I'm writing a "soundscape" type program using a lot of nature sound effects. What it does (at least the present iteration) is plays back a number of thunder effects randomly, over rain and wind effects. There's about 4 separate channels of sound (rain, wind, and two thunder channels for near and distant effect), each requiring its own autoit-program in the background to play. All is managed by a "main" program that provides play/pause control (kill or run the subprograms) and also theme toggling (i have lighter rain effects so it can toggle to that instead of the big storm). Well now I have a lot more sounds. And I can't really break them all up into separate programs (I use FileInstall to temp folders for the sounds, mp3 format, one program per "theme" set). So I want to make one single program to handle any combination of the effect channels, with a variable number of subprograms to play those channels. I would like to try and keep the number of background processes to a minimum, since I'm guessing it becomes a serious memory hog after a while (multiple SoundPlay, plus random being calculated each time, and the main program constantly checking a tray menu). In the current iteration, I can have the two rain effects (heavy and light) in one program, with a command line parameter telling it which to play when the main program runs it. But I'd like to be able to have the various effect sets be able to start and stop without the need to close and restart subprograms (more fluid that way). So, here is what I'm looking for. I'll use the stormy theme to example since I've done that for each of my iterations. Main manager program spawns off four subprograms, Rain, Wind, Distant Thunder, Near Thunder. Wind contains effects for non-rainy wind, like just a calm wind or something, so Wind is used in multiple themes. Main manager sends a command of some sort to Rain to use the heavy effect. Rain receives it and starts looping the heavy rain. Same happens for Wind, it gets a command from the manager to play heavy wind loops. The two thunders don't get commands since they can be used anytime (like distant thunder over a calm scene, giving the effect of an approaching storm). Everything loops, all is good. Then the theme changes, say to a calm theme. Main program just kills off the Rain and Thunder programs since they aren't needed, spawns off the subprograms for the Calm theme, and then sends a command to Wind to use a calm effect instead of the heavy one. Wind changes, all is good. I'd like to be able to go beyond preset themes and have a bunch of checkboxes for all the possible channels, obviously using radio buttons for those subprograms that contain multiple themed effects (like Wind). That way the end-user can construct their own theme, and the main manager just runs/kills/commands the subprograms accordingly. So is this even feasible? To have this kind of communication between autoits? Also, is there a better way to do this in the first place? Multiple sound channels that loop in different times, without multiple background processes? Is it (easily) possible in any other language? AutoIt's my favorite because it's so easy to do stuff like this, everything else becomes a serious headache. Is something like this not possible to do with just one AutoIt program?

yep, shellexecute and *wait did the trick. thanks! so any thoughts why Run doesn't work anymore? it wouldn't even do the command prompt

thx a ton. unfortunately, the error still occurs when i disable all but one option (so only run one program), still refuses. I'll look into shellexecute though