Messages

GUI.ProcessClick is new to me but it dosn't work, I tried inv.RunInteraction(eModeUseinv); before but I'm getting an error "Null pointer referenced"

I think at this point it's more a general question of scripting, rather than the use of this module.

You cannot call inv.RunInteraction(eModeUseinv) always, but only if "inv" is valid (inv !=null). You likely will need more if/elseif blocks to handle everything.

Code: ags

  if ((chara != null) || (obj != null) || (hot != null))
  {
    Room.ProcessClick(mouse.x, mouse.y, eModeUseinv);
  }
  else if (inv !=null)
  {
    inv.RunInteraction(eModeUseinv);
  }

Room.ProcessClick, ProcessClick, cJesus.RunInteraction work but wrong interaction I mean, when I have if, else if and else, it ignores the commands in if and else if and prints the commands in else

Wrong interactions, as in wrong verb, or wrong inventory item?

If last, how do you normally check for the used item? For example, if you check "player.ActiveInventory", then you simply may set it before running process click to whatever item is being dropped.

Code: ags

player.ActiveInventory = DragDropCommon._InvItem;

[and]

Hi, I wrote something and I can now interact with hotspots,objects and characters but wrong interaction and inventory items don't interact with other inventory items. Do u know what's wrong?

First of all, I imagine the code above is not your real code, because there are commands outside of a function?

Regarding the problem, Room.ProcessClick does not interact with the inventory items, because they are not inside the room. For them you got to do GUI.ProcessClick, or just call inv.RunInteraction(eModeUseinv);

I did not understand the part about "wrong interaction", could you explain more?

I might need to add another room to this demo showing how to script this kind interaction...

There's no click and hold in allegro4 port - you can't check if a "mouse" button is down in the old allegro 4 Android port.

What happens when you press the finger and hold on Android, what kind of events does it send to AGS, if any?

@Crimson Wizard,  I checked room 4 script and created a gui like in ur module and I could drag the inventory items, but I couldn't let them interact with other inventory items, hotspots, objects and characters.

You need to handle the "DragDrop.EvtWantDrop" event. For example, if you look into the room 4 script, there will be this piece of the code:

Code: ags

function room_RepExec()
{
  <...>
  else if (DragDrop.EvtWantDrop)
  {
    InvWindow* drop_to = GetInvWindowUnderObject(o_x, o_y, o_w, o_h);
    if (drop_to != null && ItemOrigin != null && drop_to != ItemOrigin)
    {
      ItemOrigin.CharacterToUse.LoseInventory(DragDropCommon._InvItem);
      drop_to.CharacterToUse.AddInventory(DragDropCommon._InvItem);
    }
  }
}

You write something similar in your "repeatedly_execute" function (e.g. in global script), and replace this with checking if there's a character, object, etc under the dragged item (or under the mouse x,y if you prefer), and if there's then, for example, call RunInteraction(eModeUseinv) for that object below.

if you are sure eri0o that this this module doesnt work on Android, is there some other code or method anywhere to do that?

This module is not strictly specific to desktop controls, it lets you customize itself to any control scheme you like. The problem is only in finding out what works with Android port, and applying here.

If the new Android port works better, 3.6.0 engine should be running games from previous versions well, you don't even have to recompile them in 3.6.0 (but you may).


I'd propose to separate this in two problems:
1. Making this interact with other objects after you drop the item;
2. Solving the Android controls.

Perhaps its best to test the first problem on desktop (like Windows) to make sure first part works.

There's no click and hold in allegro4 port. This is the main thing I want to change with the new Android port (besides soon adding proper crossplatform multi-touch)

If it's about controls and default ones don't work, this module allows to create custom ones. For example, if you check the demo game, there's one room where you press a key to start drag, and then press it again to stop drag.

I'd imagine there might be a way to figure out a solution on touch devices as well.

EDIT: I mean, that won't be literal "drag" anymore , but rather click/touch to move, click/touch to drop workaround, or something similar.

Amir, are you trying to use this module on Android? It doesn't work with the allegro4 based engine.

What do you mean, why?

Can u drop and drag inventory items with the module and let them interact with other inventory items, hotspots, objects and characters?

I tried but I couldn't get it. Codes or modules for drop and drag of inventory items in other threads would also help although I couldn't find any.

Inventory items themselves cannot be dragged, because they are not real on-screen objects. You need something that would represent them in game.

DragDropCommon module implements this using either a GUI or Overlay, but for items only feasible solution is GUI. If I remember correctly, Overlays don't work well because they are always appear behind GUI, which means they will be behind InventoryWindow too. Which is ugly. So best use GUI mode.

You may check how this is done in the Demo game's room 4 script (download link in the first post).

PS. For a brief example, here's how you set a GUI for representing item drag:

Code: ags

DragDropCommon.DragMove = eDDCmnMoveGhostGUI;
DragDropCommon.GhostGUI = MyGUI; // where MyGUI is the GUI you create yourself for this purpose

That may be enough for starters.

I think mac port should write a log? If you enable logging in config file, or from command line (if you can run this port from cmd line on your mac), then you may know more information on what is happening.

If I understand correctly, the log should be inside a game files subfolder, same place where it puts saves to.

How to configure log is described in the OPTIONS.md file in our repository (scroll down for command line options).
Here's one from 3.5.1: https://github.com/adventuregamestudio/ags/blob/release-3.5.1/OPTIONS.md
and older one from 3.5.0: https://github.com/adventuregamestudio/ags/blob/release-3.5.0/OPTIONS.md

I just refreshed my Mac wrapper with a new version of the game, just copying the .exe and the .tra and renaming the exe "game.ags". Unfortunately, the app does not even open. I can see the icon on the dock, and it shuts down immediately. If I put the old game back, it's working. Is it possible that the wrapper 3.5.0 is not compatible with AGS 3.5.1 ? If not, what else could be the reason?

Could you clarify, what is the "wrapper" and what versions are wrapper and the game files? I may be confused by the above description.

I don't know if related, but I did a small change for 3.5.1. macos port:

- When looking for game files engine will no longer use hardcoded filename, will search for any compatible pack file instead.

Not sure why 3.5.0 Alpha is compatible.

Camera API was added in a later alpha version.

The correct #ifdef for these functions is SCRIPT_API_v3507.

No, my question was rather, why this was blocking a whole system support? Unless I misunderstood what you mean.

Anyway, there's no problem in adding new constants, for web, freebsd, and so on. They don't have to be in a specific order either.

That would be good, that was the reason I haven't advanced anything in the FreeBSD support.

Really, why?
I believe the constant may be reserved anytime if that makes sense. In the worst case new system may return something else like Linux, temporarily (this property is not used too often anyway).

If you want to handle some web difference, System.OperatingSystem is 8 for the web port

Code: ags

bool is_web = System.OperatingSystem == 8;

Maybe we could reserve it in script API just in case to make sure it's not overwritten by something?

Erm, this cutenization thing is a global trend that spreads everywhere.

For example, this is a Zerg creatures from the Starcraft game:



And then the game fans do things like this:
https://i.pinimg.com/originals/5b/0f/00/5b0f006197a9f271376514565327ece3.jpg

and like this...
https://www.deviantart.com/tessryne/art/Zerg-Hydralisk-751696275

The sadder variant of above should be "not because they are necessary, but because we thought they were going to be necessary"...

I think this Overlay.Remove is a good candidate for replacing error with a warning though...

Still, the behaviour is always the same: if I start the game in windowed mode and then switch to fullscreen, the image scales correctly on the external display without any stretching (but if I quit while in fullscreen mode and then start the game again at some other time, it will once more stretch to fill the screen, so the best thing to do is switch to windowed mode before quitting).

When switching modes it uses different algorithm than on startup for MacOSX port, which may be related.
When you startup in mode A engine remembers its settings, so switch forth and back will return to same settings. But when you start in mode B and switch to mode A later, these settings will be taken from "defaults" instead.

Interestingly, if I run the game in windowed mode, the cfg file that's located in the user's Saved Games profile folder sets itself to "scaling". If I run the game in fullscreen mode, the cfg sets itself to "max".

This is how default settings work for these modes, for fullscreen it's "max" which means current desktop size, and for windowed it's "scaling" which means take game size and scale by a integer factor.

I think it could use the main monitor for determining the desktop size. But this does not explain why it improves on switching modes.

PS. Also, in the latest version I disabled saving config by engine itself, so it will not longer change these settings in config file.

@LauraHunt, I just noticed that the MacOSX port does not create window sized like the Windows or Linux ports do, it has some different logic to this and likely not even using mode size from the config.

You mentioned that the problem occurs on the "external monitor", does it also happen on the main monitor (I'm not sure what your setup is).

screen_def cannot be "proportional", I was referring to game_scale_fs option. "screen_def" could be set to "max" that would use current desktop resolution.

The thing is that "screen_def = scaling" will try to set new display resolution to the integer scale of a game's size. Changing resolution itself may be problematic on some systems, but if proper resolution is not supported it will try to find nearest one which may be not what you want.

LauraHunt, ags currently does not detect multiple monitors correctly, maybe that's the part of the problem. Also, I would not use "scaling" in fullscreen, maybe it's best to use "max" to make it keep at current desktop resolution, and "proportional" for "game_scale_fs".