Messages

Wait...AGS is easy?!

Easy as childbirth!

[may]

I worked closely with CJ in designing the current source/version control API for editor plugins, but I could never seem to quite wrap my own head about how to properly implement any of the systems I looked at. I knew less about version control then than I do now (which is still not very much), so I may take a look at it later and see if I could come up with anything.

You could test your code by doing this:

Code: ags

/*/
// Original code -- COMMENTED OUT
int a = 42;
float b = 3.14;
String c = "blah";
// ...
/*/ // don't mess with this ;)
// New code -- NOT COMMENTED
int a = 314;
float b = 5.7;
String c = "whatever";
// ...
/**/

Code: ags

/**/
// Original code -- NOT COMMENTED
int a = 42;
float b = 3.14;
String c = "blah";
// ...
/*/ // don't mess with this ;)
// New code -- COMMENTED OUT
int a = 314;
float b = 5.7;
String c = "whatever";
// ...
/**/

By changing a single character (the asterisks on the first line) you can toggle between the two blocks of code.

The meaning you seek is under every, even that one which is not. Finally reached, the answer removes only question.

Can't you just block his IP address?

They'd have to call the Cyber Police to backtrace it first.

You can try, but started this group, we understand these things, you see, they do not understand, not just quantity.

I'm a unicorn, your argument is invalid.

I'm about to release a module that can make the engine explode when used...

Copycat.

Yeah, I guess this sort of fell by the wayside, but it does need to be updated. Again, the majority vote should ideally be given sway here. Anything more than 4 spaces of indentation is just bad style though, I don't care what anyone says. My entire programming career has been based around an indentation size of 2 spaces, and that is enough to create a clear distinction.

[U+0160]

The character code is actually U+0160. The number following the U+ is a hexadecimal value, so that's decimal value 352. AGS only supports characters up to decimal value 255 (or 0xFF). Anything higher than that, even if supported by the font, won't be supported by AGS.

It seems a fairly difficult thing to bring on oneself

As someone who has been banned from the forums before, I can honestly say that it's not at all difficult to get banned. You don't even have to do anything offensive.

I'm not very familiar with foreign characters in AGS, but 1) what are the decimal values of those characters, and 2) are you using a TTF font? Using an WFN font you can only access characters 0-127, a TTF font will let you access characters 0-255. There's currently no support for extended character sets (characters beyond decimal 255).

Issue: Open bracket consuming too many backslashes in text output fields.

[$AUTOCOMPLETENOINHERIT$]

There are two magic words for the import clauses that will have an effect on the autocompleter:

What, no love for $AUTOCOMPLETENOINHERIT$?

(Which, by the way, is currently only used AFAIK by the GUIControl class to prevent such confusingly useless members as Button.AsLabel and Slider.AsInvWindow.)

[any]

I can confirm that this is definitely a bug in the String implementation. Whenever any function manipulates the string (Append, AppendChar, Replace, etc.) (also, string literal -> String conversion) then the open bracket character ('[') will consume all backslashes ('\\') immediately preceding it. The backslashes are not consumed if there is any character between them and the bracket.

You could use similarly named extender methods to specialize the returned output

That's what I'm currently doing, but in order to be sure of what I'm scripting, I need to be sure of the standard behaviour of each control (Label, Display, ListBox...). I think the differences that I've pointed out between Label and ListBox are correct.

Obviously this particular bug is preventing you from doing it, but as an additional thought I just wanted to add that when I said "similarly named" that I didn't mean "almost similar" but rather "exactly similar", e.g.:

Code: ags

import void AddSlashes(this Label*);
import void AddSlashes(this ListBox*);

That way you're invoking separate functions but with the same name, implying the same behavior is taking place.

- in the editor, a string like String s = "aaa\bbb"; should raise an error at compiling time ("unfinished string")

I actually disagree with this. While some compilers would vomit up "unsupported escape sequence" or some other such nonsense, I much prefer the regex approach where any non-escape sequence character can be used as an escape sequence representing itself (which is indeed the current approach taken by the AGS compiler).

- in a Label or Display, "aaa\\\\\[bbb" should appear as:
aaa\\[bbb
and not as:
aaa[bbb

Agreed wholly on this, as per my statements above.

Using the setup you already have, the import/export should look like this:

Code: ags

// GlobalScript.ash
import AudioChannel *bgm_channel;
import void SetBGM(AudioClip *bgm);

Code: ags

// GlobalScript.asc
AudioChannel *bgm_channel;
export bgm_channel;

void SetBGM(AudioClip *bgm)
{
  if ((bgm_channel != null) && (bgm_channel.PlayingClip == bgm)) return;
  if (bgm == null) bgm_channel = null; // added this so you can call SetBGM(null) to disable background music
  else bgm_channel = bgm.Play(eAudioPriorityHigh, eRepeat);
}

Note that the AudioChannel* has to be exported, the function does not.

What exactly is your desired output?

You could use similarly named extender methods to specialize the returned output, effectively achieving a "addslashes"-style function if that's what you're after.

It enforces spaces over tabssssss!

- Alan

Good, it enforces good style.

As I am an author of one of these plugins, I feel I should stick my head in. I still maintain that the AGSteam plugin cannot be usefully open-sourced in any way due to the licensing restrictions of Valve's Steamworks API. That is, with the references to Steamworks removed, there's little left beyond the sample plugin functions -- that's really all there is to it. The plugin exists solely as a middleman between AGScript and the native C++ calls to the Steamworks functions.

All that being said, the Steam platform itself is currently not really portable. I have successfully managed to get the AGSteam plugin running on Steam for Linux, but currently none of the AGS games using Steam have been released for Linux.

I will also note that I am not opposed to sublicensing the source to appropriate parties as needed. Currently I have licensed the source out to Wadjet Eye Games (pending their licensing agreement(s) with Valve, etc.), and would be willing to extend the same to others who may have need of it.



In general, I absolutely agree that making plugins open-sourced will be in everyone's best interests overall. I am actively working to develop a new plugin that has been requested of me, and if I can actually get the thing to work then I will have no qualms whatsoever about sharing my code.