MODULE: expression-speech-style v0.3

[Crimson Wizard]

What I usually do to perform a quick upgrade is to actually recreate custom functions with the exact same syntax as the missing ones:

FALLLLLLSSSSEEE!

As SSH learned with the BackwardsCompatibility module (which was designed for this purpose), your function won't be called.

I made a test, it is actually called when the implementation is in the same script:
Example:

Code: ags

int StrLen(String s)
{
  return 10;
}

// called when the game starts, before the first room is loaded
function game_start() 
{
  String s = "aaa";
  int a = StrLen(s);
  Display("a = %d", a);
}

This code displays "10".

This is because script function in same script is called with different internal command.

However, if you put it into separate script, then import and call from another, then the built-in AGS function is called.
The reason is that AGS registers all functions, including deprecated ones, before loading your scripts, and they take the place of your "substitutes", since they have same names.


UPD: The possible solution could be to give them slightly different name, like StrLen2 or something. This way you will have to rename them everyone in script, but the rest of the script will stay the same.

All you need is the imports, e.g.:

Code: ags

import int StrLen(const string);

If you go that way, it is easier to just turn Backwards compatibility mode on ("Enforce new style strings" to False in General Settings).


UPD2: Since my attention was brought to this, I think this is an incorrect behavior of AGS. It links functions that are not declared; this would cause problems if someone scripts function, using name of deprecated function, even if he did not know it is.
I think engine should not register old functions if they are not used in game.

[Monsieur OUXX]

I picked that example randomly, maybe it doesn't work for StrLen. As I said I do it only for functions that cause trouble. But it's good to know that the old functions are still there, just slightly hidden (well, unless it's a faulty behaviour, like CW pointed out).

[monkey0506]

UPD2: Since my attention was brought to this, I think this is an incorrect behavior of AGS. It links functions that are not declared; this would cause problems if someone scripts function, using name of deprecated function, even if he did not know it is.
I think engine should not register old functions if they are not used in game.

Just as a point of reference, this is what CJ said about it:

The AGS engine still exports all the old-style functions, the only thing that happens when "Enforce object-based scripting" is ticked is that they are removed from the script header so that your script won't compile.

So in fact, all your BackwardsCompatible module needs to do is provide a script header with the appropriate import declarations in it

He didn't seem to think it was problematic for the built-ins to still exist (be registered) even if not using them. I do agree that it could be useful to omit them...but I will also then have to admit that I have used some of the functions (old-style String functions, in particular) in modules which are designed to still use the old functions even if they are "disabled". Honestly, I don't recall if I did that in any production code, but there are cases where using StrCopy is faster than String.Append or String.Format, and I've toyed around with that a fair amount.

[Monsieur OUXX]

So in fact, all your BackwardsCompatible module needs to do is provide a script header with the appropriate import declarations in it

He didn't seem to think it was problematic for the built-ins to still exist (be registered) even if not using them.

Good to know.
I say leave them for now. There are still billions of old-yet-still useful modules out there.

[monkey0506]

Oh, also I'll note that it would be easy for the BackwardsCompatible module (if anyone still has it or wants to recreate it) to be updated with toggle-able features, based on macros. For example, if you wanted to import the old-style Character functions without fully adding the old-style code support, there could be a macro like BC_CHARACTER that, if defined, would import those functions, or otherwise would omit them.

Code: ags

// BackwardsCompatible.ash
#ifdef STRICT
#ifdef BC_CHARACTER
import void AddInventory(int item);
import void LoseInventory(int item);
import void SetActiveInventory(int item);
import void NewRoom(int roomNumber);
import void NewRoomEx(int roomNumber, int x, int y);
import void NewRoomNPC(CHARID, int roomNumber, int x, int y);
import int  GetCharacterProperty(CHARID, const string property);
import void GetCharacterPropertyText(CHARID, const string property, string buffer);
import void RunCharacterInteraction (CHARID, CursorMode);
import void DisplaySpeech (CHARID, const string message, ...);
import int  DisplaySpeechBackground(CHARID, const string message);
import void DisplaySpeechAt (int x, int y, int width, CHARID, const string message);
import void DisplayThought (CHARID, const string message, ...);
import void FollowCharacter(CHARID sheep, CHARID shepherd);
import void FollowCharacterEx(CHARID sheep, CHARID shepherd, int dist, int eagerness);
import void SetPlayerCharacter(CHARID);
import void AddInventoryToCharacter(CHARID, int item);
import void LoseInventoryFromCharacter(CHARID, int item);
import void AnimateCharacter (CHARID, int loop, int delay, int repeat);
import void AnimateCharacterEx (CHARID, int loop, int delay, int repeat, int direction, int blocking);
import void MoveCharacter(CHARID, int x, int y);
import void MoveCharacterDirect(CHARID, int x, int y);
import void MoveCharacterPath(CHARID, int x, int y);
import void MoveCharacterStraight(CHARID, int x,int y);
import void MoveCharacterToHotspot(CHARID, int hotspot);
import void MoveCharacterToObject(CHARID, int object);
import void MoveCharacterBlocking(CHARID, int x, int y, int direct);
import void MoveToWalkableArea(CHARID);
import void FaceCharacter(CHARID, CHARID toFace);
import void FaceLocation(CHARID, int x, int y);
import void SetCharacterView(CHARID, int view);
import void SetCharacterViewEx(CHARID, int view, int loop, int align);
import void SetCharacterViewOffset(CHARID, int view, int x_offset, int y_offset);
import void SetCharacterFrame(CHARID, int view, int loop, int frame);
import void ReleaseCharacterView(CHARID);
import void ChangeCharacterView(CHARID, int view);
import void SetCharacterSpeechView(CHARID, int view);
import void SetCharacterBlinkView(CHARID, int view, int interval);
import void SetCharacterIdle(CHARID, int idleView, int delay);
import void StopMoving(CHARID);
import int  AreCharObjColliding(CHARID, int object);
import int  AreCharactersColliding(CHARID, CHARID);
import void SetCharacterSpeed(CHARID, int speed);
import void SetCharacterSpeedEx(CHARID, int x_speed, int y_speed);
import void SetTalkingColor(CHARID, int colour);
import void SetCharacterTransparency(CHARID, int transparency);
import void SetCharacterClickable(CHARID, int clickable);
import void SetCharacterBaseline(CHARID, int baseline);
import void SetCharacterIgnoreLight (CHARID, int ignoreLight);
import void SetCharacterIgnoreWalkbehinds (CHARID, int ignoreWBs);
import void SetCharacterProperty (CHARID, int property, int newValue);
import int  GetPlayerCharacter();
#endif // BC_CHARACTER
#endif // STRICT

This could serve as a more powerful option than the catch-all "enforce object-based scripting".

[Crimson Wizard]

This could serve as a more powerful option than the catch-all "enforce object-based scripting".

And what is the actual benefit? You still won't be able to have function names identical to old function names without calling latter instead.
In fact, that can cause terrible confusion, if someone would make a module function with seemingly "unused" name and then catch all kinds of strange bugs in his game, when the hidden built-ins will be called.

The true solution would be to implement game option, that would enable/disable particular parts of the built-in header, and also be passed to engine to tell it not to link particular functions.