Messages

We're conducting a demographics survey in my intro to video game design course. I'd greatly appreciate if you could take this survey for me:

https://www.surveymonkey.com/s/VZWJW3B

Thanks!

[1. That you have read the manual (at least looked for pertinent entries).]

sorry that didnt work what does 1blquit does beacuse its giving me a error.

While this is the beginner's help forum, there are still certain measures which are generally expected of you to take before you post asking for help. I won't reiterate the entire list of rules for this forum, but the three most basic expectations we (those trying to help you) are:

1. That you have read the manual (at least looked for pertinent entries).

It's not always simple to find exactly what you're looking for, but the answer I gave you (which seems to have been what you were looking for) is almost identical to the example the manual gives for the Random function.

2. That you have tried searching the forums.

Searching for "random message" yields 4 pages of results. Some of them are out-of-date, but the basic concept behind the first result in the list is still the same, and the manual redirects you to the appropriate properties/functions for those same commands.

3. That you have a basic concept of how programming works.

Simply put, you're not going to be able to make a game in AGS without doing some programming. Simply reading through the scripting tutorial (in the manual!) should give you some idea that if you see something like "lblQuit", then it's probably referring to some entity in your game. It's not enforced or even provided as the default for new controls, but the prefix "lbl" is conventional (not just in AGS) to indicate that you are referring to a GUI Label control named "Quit". If you can't comprehend programming well enough to make interpretations such as this from variable names, then you need to take a step back and learn some programming basics first. I'm not saying this to be rude, but as I said, programming is an essential requirement for making games in AGS. Understanding concepts like this (especially after a meaningful error message was raised) is one of the most basic and fundamental parts of programming.

I'm not saying this to be rude, but in the sincere hope that you actually take it to heart. I'm not meaning to berate or belittle you, but this thread has gone downhill very, very fast.

Thanks for the help, sorry took me a while to understand I forgot there was a button to make labels in the gui up top, my brain is slow. thanks again

From this I'm not sure you've understood slasher's meaning. He wasn't talking about adding controls to your GUI in the editor at design-time. He was telling you to call the code earlier on at run-time. This is another misunderstanding predicated by your lack of understanding for basic programming concepts. Essentially, it should look something like this:

Code: ags

function btnQuit_OnClick(GUIControl *control, MouseButton button)
{
  int ran = Random(5);
  if (ran == 0) lblQuit.Text = "Are you sure you want to quit?";
  else if (ran == 1) lblQuit.Text = "You're giving up already?";
  // ...
  else if (ran == 4) lblQuit.Text = "Can't take it any more?";
  gQuit.Visible = true;
}

Obviously this will not work out-of-the-box, especially not if you just cut and paste it. You have to understand what it's doing first. This is an event handler for when the GUI Button btnQuit is clicked on by the player. btnQuit would probably be a button on your Menu GUI. The event handler has to be linked in the Events pane of the button's properties (select the button in the editor, and click the lightning bolt icon in the Properties pane -- you can then click the ellipses ("...") button for the event to automatically create an empty event handler for it) or it will not be called. I've also reused the same code I gave you previously to illustrate the point of how it is meant to be used. lblQuit is not some built-in function, but represents your GUI Label control on your Quit GUI. Similarly, gQuit doesn't exist either, but represents your Quit GUI. What this code does, when properly implemented, is set the label text to one of a set of messages at random, and then displays the Quit GUI, showing the message on a GUI Label and containing GUI Buttons for the player's Yes or No response.

This cannot be made more clear, so if this doesn't make immediate sense, please take the time to understand it before moving on.

This is a pretty common question, actually. Typically you'd do something like this:

Code: ags

int ran = Random(5);
if (ran == 0) lblQuit.Text = "Are you sure you want to quit?";
else if (ran == 1) lblQuit.Text = "You're giving up already?";
// ...
else if (ran == 4) lblQuit.Text = "Can't take it any more?";

Blackthorne, have you tested QFI on Android? I know Himalaya Studios was having issues with their games silently crashing, but I could never reproduce it.

While we sort out what to do, I've created an open-source stub for the AGSteam plugin, which was the main offender in this case (as Flashlight and SnowRain have built-in workalikes).

https://github.com/monkey0506/agsteamstub

The Steam version of the game can still load the plugin (on Windows) even if the Steam client isn't installed or isn't running. The problem here is the lack of a plugin for Android (and/or, a missing/deleted plugin). The plan is for future versions of AGS to allow these plugins to be stubbed for precisely this type of situation. You can read more about that in this thread.

Visual Studio 2008 Express (e.g., the "free" edition of VS) has always been able to build the engine, but if this crops out unnecessary header info then I don't see why not.

As far as contributing to the project, the way it usually works is that you create a fork of the official git repo and then submit a pull request. This is actually pretty simple using a Github account (which is also free), or you can always upload your fork elsewhere (my fork is cloned on Github.com and Bitbucket.org).

The function is fine; if minimo < massimo && minimo != 0, it will not return 0, ever.
If that happened, you're either using bad parameters or made a mistake somewhere else.

Khris is exactly right about this. Seeing as AGS allows recursion though, it's pretty simple to error-proof your function:

Code: ags

int NumeriCasuali(int minimo, int massimo) //int min, int max
{
  if (minimo == massimo) return minimo; // same value, only one possible result
  if (minimo > massimo) return NumeriCasuali(massimo, minimo); // min and max reversed, swap them out
  return (minimo + Random(massimo - minimo)); // correct
}

I never use the offline [help file (manual)], cause for some reason it is always on top, and then I can't see the editor.

This is a known bug feature of the editor, which can be disabled in your Preferences.

That would make plenty of sense to me.

While you're at it, if I could, I'd like to suggest you add File.Copy and File.Rename as well. These functions would help really make the file class complete.

My only critique would be that AGS doesn't really have generic streams, so maybe FileSeek would be a better enum name.

Oh, and "whence" does feel a bit antiquated (from a native speaker's POV). Maybe just "from".

[already]

The variant with the separate file should definitely be used because...

To be clear, the engine already has the ability to look for assets in the game directory if they are not found internally in the game's data file. The option to bundle it into the game file should be present, and the engine can fall back to the game directory if needed.

[or]

Well with your suggestion that the return types of the stubbed functions being restricted, it seems unlikely that a stub would do anything malicious, right? So the ability to have the stub built into the game package or run from the game directory is good. Isn't it? It seems like you might be trying to discourage this.

Presumably this would be one of the files that is built into the game data? So, for example, the plugin author would publish the DLL/SO file(s) alongside a STUB file which the developer would put in the editor directory. Then on building, the STUB would be built into the game file, and the DLL copied to the Compiled folder?

That seems like a good route to me (if I understand you correctly).

It was recently suggested that I create a plugin stub for the AGSteam plugin, so games which use it can be run on non-Steam platforms. This is particularly relevant if trying to run a Steam game on a platform which doesn't support Steam.

My question is this -- There are already some plugins which are built into the engine source code, but I'm worried that we might bog things down if we start including and/or stubbing every "useful" plugin (AGSteam would have to be stubbed due to Valve's licensing). What is the general consensus on this? I already have a stub written, I just need to more thoroughly test that the full plugin can usefully tap into the stubbed features. Would it make sense for me to build it into the engine, or should I just provide it separately for those who need it?

I understand it's probably not "best practice" under normal circumstances, but as far as creating a hard link from a framework-agnostic C# assembly, there's not much of a better way AFAICT. I referenced the "/bin/" directory because in the SO article that gave me the idea, someone was complaining that Process.Start wasn't finding ln, but someone else suggested their PATH may have been mucked up. I could leave it to just "ln" if that's a better solution.

[gigabytes]

Well to me, ideally, you should just be able to zip up the build folder and ship it off, sans any additional copying. In order for that to work, the editor will basically have to copy the game data file (whether or not the Windows engine is attached) to every platform's distribution/deployment folder. That's why I thought that using hard links would be nice, because it would save copying potential gigabytes of data (namely, commercial games). There doesn't seem to be a nice, consistent, cross-platform way of creating a hard link from the editor though. The end result is the Compiled folder growing by a factor of one for each additional platform (Windows only = factor 1; Windows and Linux = factor 2; Windows, Linux, and Android = factor 3). Hence, the additional copying is unfortunate.

I've been reading further into it, and I think I've found a reasonable (and yes, cross-platform) solution. Instead of relying on the preprocessor for conditional compilation, it seems we can use Process.Start with run-time checks against the framework that is in-use:

Code: CSharp

public void CreateHardLink(string destFileName, string sourceFileName)
{
    string fileName = "mklink";
    string args = String.Format("/h {0} {1}", destFileName, sourceFileName);
    if (IsMonoRunning())
    {
        fileName = "/bin/ln";
        args = String.Format("{0} {1}", sourceFileName, destFileName);
    }
    Process.Start(fileName, args);
}

This should allow building the assembly without any compile-time dependency on a specific framework variant.

Also, you have rather convinced me that I should refactor my work before doing any commits to the main repo. This will delay any official builds targeting anything other than Windows, but you've made your point. In response to that, I am working to implement a uniform structure for the build target classes. The biggest portion of the work will come from refactoring the native build code (targeting only Windows) to instead build only the data file, and then handle the rest from the new classes.

[this]

The compilation of this assembly (to IL) would be referenced against the precompiled Mono or MS binaries, but the preprocessor would be running in this assembly, not in the framework binaries.

http://stackoverflow.com/a/5159714/1136311

Edit: Reading a bit further, I do see that one of the goals of Mono is for assemblies compiled against either the MS or Mono binaries to be able to run seamlessly while using either, interchangeably. In this case perhaps it is just best to avoid hard links since there isn't a consistent way of creating them from C#, though the extra copying is rather unfortunate.

I agree with what you're saying, this was just more of a starting off point. Bear in mind that this is the first non-Windows build option that the editor has offered, so a lot of this code was initially experimental.

As to creating hard links, .NET doesn't provide any framework methods, so it will have to be done by native assemblies. Mono's framework provides a link method for *nix systems. We can use the preprocessor to select the right method based on the loaded .NET runtime (MS or Mono).

Sorry about the script being in the wrong folder. As you discovered it needs to be moved up a level.

I've finally gotten around to mucking with the native code (mostly, just adding a parameter here and there for the compiled folder name), and I think I've just about got it working. I need to work out a couple of bugs, and then I should have a working version ready to pull into the 3.3.1 dev branch.