Messages

[will]

yours will reset the string...Remove that check in your pseudo code for "the correct number of digits" and the two suggestions should behave very similarly.

you can reset the String

I listed "that check" as an optional step, not a mandatory one. Assuming that the check is omitted, then yes, the two give the same results (which was kind of my point in responding to 424).

For what it's worth, Elias' code is still essentially the same thing, we're just listing more and more complicated (and therefore potentially error-prone) means to the same end.

It's arguing semantics, but using four separate slots in an array is more complicated, and error-prone, than using a single String. The String method allows you to compare the result once against a single string-literal, whereas you are suggesting to check the value of four separate slots.

You're not wrong, and the array approach is actually significantly more memory efficient. *shrugs* Whichever is easiest for the end user I suppose.

I've updated the first post with links to the most current version. Moving forward this will only be designed around AGS 3.3.1.

Note that this still compiles the game to a separate "linux" folder. I have not yet had a chance to refactor the native code to by-pass the hard-coded references to "Compiled".

Pretty much the easiest way to do it would be to:

*) Create a global String variable (say, "sPanelPassword")
*) Whenever you show the GUI or enter the room where this panel is shown, set your String to empty (e.g., sPanelPassword = "";)
*) Whenever you click on one of the numerical buttons, append it to the String (e.g., sPanelPassword = sPanelPassword.AppendChar('1');)
*) Now, check it against the correct password (e.g., sPanelPassword.EndsWith("7145"))
*) If it's the wrong password but the correct number of digits have been entered (check sPanelPassword.Length), you can reset the String back to empty and display a "Wrong Password" message

I'm working on getting a full-functioning module version of the Snow/Rain plugin, but I appear to have come across a problem. At the moment (bear in mind this is WIP!!) all of the particles should be falling straight down. Which is working great, so long as I don't try and draw them with any transparency on the DrawingSurface. If there is any transparency at all, from 1 to 100, the particle is never drawn.

I am using the D3D9 graphics driver, I have the GUI and sprite alpha rendering styles set to proper alpha blending, and I am doing essentially this:

Code: ags

DynamicSprite *guiSprite; // used as GUI background image

void Render()
{
  if (guiSprite == null)
  {
    guiSprite = DynamicSprite.Create(myGUI.Width, myGUI.Height, true);
    myGUI.BackgroundGraphic = guiSprite.Graphic;
  }
  DrawingSurface *surface = guiSprite.GetDrawingSurface();
  surface.Clear();
  int i = 0;
  while (i < particleCount)
  {
    // calculate particle position, etc.
    surface.DrawImage(x, y, img, Random(maxTrans - minTrans) + minTrans); // DOES NOT WORK
    // surface.DrawImage(x, y, img); // WORKS PERFECTLY
    i++;
  }
  surface.Release();
}

function repeatedly_execute_always()
{
  // check if snowing/raining, other sanity checks, etc.
  Render();
}

Any ideas why the semi-transparent particles are disappearing entirely?

P.S. The particle sprite in question is 32-bit, no alpha.

I recall there's a Snow/Rain module now (Wadjet Eye used it for Gemini Rue ports)?

Sort of. I'll take a look and see if I still have it.

I don't see anything about it in the OSX docs (checked JanetGilbert and humblebundle's forks), but the Linux README states:

For midi music playback, you have to download GUS patches. We recommend "Richard Sanders's GUS patches" from this address:

http://alleg.sourceforge.net/digmid.html

A direct link is here:

http://www.eglebbk.dds.nl/program/download/digmid.dat

Rename that file to patches.dat. You can now place it:

• in the directory pointed to by the ALLEGRO environment variable; or
  
• if $ALLEGRO is not defined, in $HOME; or
  
• in the same folder of the AGS executable.

I'm sure the process is something similar for OSX, but I don't own a Mac so I can't be certain.

My main beef is with Google regarding the kitkat update, which I didn't have on the S3. Seriously, let me decide who has access to my external SD.

Absolutely. The other changes to Kitkat were fine, but the deathgrip on the SD card is a bit much. Really, they're trying to do away with expandable memory altogether under the premise that you can just store everything in the cloud. Guess what though, my cloud storage does nothing for me if I'm driving down a remote highway with no signal, or flying on an airplane. I want access to my tremendous GBs of music!! Hence the sole reason I rooted my GS4.

I'm under the impression that all mobile devices are kept in a constant state of crapiness, so users always have to upgrade for minor improvements.

This too. You can't say stuff like this without sounding like an insane conspiracy theorist, but the artificial barriers inhibiting technological growth have been a major peeve of mine for several years. Yes, technology has moved forward at an incredible rate, but if greediness and commercialism hadn't done their part to bleed every last drop out of each step then we'd be decades ahead of where we are now.

So I'm currently working retail while I go to school, and so the latest releases from Samsung are a hot topic for our store. The problem is, they're terrible. The latest devices in their lineup bring almost nothing new or worthwhile to the game. In fact, their newest tablet is actually worse than its predecessor. While the Galaxy S5 is a good phone, and I'm sure the Galaxy Tab 4 is a decent tablet in its own right, I don't understand Samsung's motivation in not pushing their devices forward.

Especially given that Samsung has risen up as the main competitor against Apple's iDevices, I would expect better of them than this.

Do you mean the source files? Because those are available in the GitHub repo. I'm not entirely sure what you're asking for on that.

I wrote an open-source variant of the ags_shell plugin. You can grab it here.

NOTE: I'm not sure what scotch originally used for the final parameter to the native method, which controls how the new window is displayed. It may need to be changed to reflect the original behavior.

This version also declares AGS_SHELL_VERSION for your AGS scripts to check for the plugin.

[Edit:]

I haven't been looking into it too much lately, but to be clear I never encountered the problem anyway. I'm not sure how much I can really say, but once Al Emmo is released on Steam, then I'll have a better chance to look into this once again. Quite a few reports came in from Himalaya Studios, but their focus is on Steam for now.

Edit: But please, don't let that stop you from trying out the latest APK and sharing your experiences.

That's what comments are for. Keep in mind that block comments can appear in-line:

Code: ags

if (condition) { }
else /* if (!condition) */ { }

[Edit:]

I now have gotten things sorted out so that the target platforms are selected from the General Settings pane. For now, Windows must always be selected as a target. I removed the option from the Preferences page, and instead included a "Rebuild all platforms" option under the Build menu. Thinking about it, I may rename it to "Rebuild target platforms".

Still on my to-do list:

- Make sure file permissions are set for Linux executables
- Do a full copy of acsetup.cfg instead of hard linking it
- Add a "Build target platforms" option to accompany the "rebuild" option
- Rearrange directory structure:
|-- If building for Windows only, put all compiled files in "Compiled" folder directly
|-- If building for multiple platforms, put compiled files in "Compiled/[Platform]" directory

For the most part this should be relatively easy (the last item here is probably the most difficult). I fully suspect I should have a new build pushed up soon, so it should be out in plenty of time to include in the next 3.3.1 alpha/beta.



Edit: Setting the relative build paths is a bit trickier than I thought it would be. Specifically, there are some hard-coded strings in the native assembly that refer to the "Compiled" directory as being the root of the compilation process. I'll need to approach that with caution.

[what]

Glad you got it working, but I would just like to say that under no circumstances should anyone ever have:

Code: ags

if (condition) { }
else if (!condition) { }

That is what else means.

Code: ags

if (condition) { }
else { }

Is sufficient if all you are doing is checking the inverse of the original condition. You should only have else if when you are checking multiple (more than two) unique possibilities, such as the results of Random(10) or the current mouse.Mode.

I saw your thread and branch about this feature and was wondering why there wasn't a pull request yet.

Maybe people will look at this first and tell if that's ok the way it's done? Just to be sure that it is made conveniently. Just suggesting.

Also, Gurok raised good point about directory structure.

Yes, this is the reason there's not a pull request yet. (Well that, and I have several intermediary commits that don't need to be part of the main repo's history. Once I get a build that everyone's generally happy with then I'll dump it all into a single "initial" commit and pull that in instead.) Agreed about the points you raised, and yes, to prevent clogging this thread up let's continue discussion about it in this thread. A few items were brought up there that I will be working on.

[testing]

I had to change some file permissions because the starter script, ags32 and ags64 were not flagged executable.

Hmm, good point. I'm not terribly familiar with how this correlates to Windows' security, or if it does at all, but I could try setting some permissions on those files directly from the editor.

Would not it be better if the build targets were configured for every project separately, instead of preferences? Thinking about future, if more build targets will be added later this may become cumbersome to always build all targets for every project user works on.

Maybe you're right about this. Is there a way that I could perhaps add to the General Settings pane a dropbox that would have checkboxes for each available target platform? There's also the matter that the Preferences page is becoming a bit too cumbersome IMO for a single dialog. Perhaps if we could add tabs inside the dialog, or just have it open as a normal tab instead...but that's an entirely different matter.

This, and another thing: I have certain doubts about "Build EXE" always building for all platforms. Consider game developer wants to build only Windows build while developing/testing game, and all builds when preparing distribution. Maybe it's worth adding more build commands to menu?
This needs to be thought through, considering more build targets and different situations, IMHO.

No, no, I agree. I did it this way for now because I know that both Linux and Android reuse the Windows executable. I do like the idea of having something in the General Settings (I'll see what I can find to make this work well) and then having a separate "Build All" button (probably add a tooltip that it's "build all platforms" and not "rebuild all files").

None of this is set in stone, that's why I (a) put it in a separate branch of my personal fork, (b) haven't yet submitted a pull request, (c) posted this as a testing build, and (d) held my breath for three days waiting for someone to post some feedback about it.

I also modified this to use hard links for the linux/data copy of the game instead of directly copying the game files. For larger games this makes the compilation much faster, though it does have some side effects. Thinking about it now I will actually modify it to do a full copy of acsetup.cfg, but the other game files should be fine as hard links (unless anyone has any strong objection to this).

Additionally, I realized that for some reason I hadn't included the Linux licenses folder. It may not be necessary to distribute that with your game (I'm not sure), but at the very least it should be included in the files distributed with the editor.

This gives me something to work on.

Ah, well, yeah. That's true. But all winsetup does is call "gamename.exe --setup", so you could just as easily set up a shortcut instead. I generally either edit acsetup.cfg by hand or use the parameter.

Uhm, yeah. The folder name has always set the name for the compiled EXE. And also, nothing has ever prevented you from renaming the EXE. I don't understand what is going on in this thread...

I made a combined build of the new 3.3.1 alpha with the Linux compilation. Hope you don't mind me piggybacking this onto your release.

https://bitbucket.org/monkey0506/ags/downloads/3.3.1%2Blinux.rar