Messages

Congrats. That had to be one of the longest beta/patch marathons I've seen for a while.

What a shame! I've archived all episodes here for posterity:

https://archive.org/details/bluecuptools

I used to listen to the podcast from time to time during my commute and unfortunately realized this week that the links to all episodes were now dead. I was wondering if they've been archived somewhere by someone by any chance?

This also got me to finally register on the forum after lurking for a long time. So "hi everyone"!   

Update: I added a few lines that allow for a Button to be draggable using the GhostGUI/Overlay:

Code: ags

//===========================================================================
//
// DragDropCommon::TryHookGUIControl()
//
//===========================================================================
static bool DragDropCommon::TryHookGUIControl()
{
  if (!DragDrop.EvtWantObject)
    return false;
  GUIControl *gc;
  // TODO: pixel perfect detection
  gc = GUIControl.GetAtScreenXY(DragDrop.DragStartX, DragDrop.DragStartY);
  if (gc == null)
    return false;
  if (DDSet.TestClickable && !gc.Clickable)
    return false;
  DDState._GUIControl = gc;
  DragDrop.HookObject(eDragDropGUIControl, gc.X, gc.Y);
  // Allow for GhostGUI/GhostOverlay when dealing with GUIControls that 
  // are buttons
  if (DDSet.Move != eDDCmnMoveSelf)
  {
    if (gc.AsButton != null)
    {
      int sprite = gc.AsButton.Graphic;
      DDState.CreateRepresentation(DDSet.Move, gc.X, gc.Y, gc.OwningGUI.X, gc.OwningGUI.Y, sprite,
                                   DDSet.GhostTransparency, DDSet.GhostAlpha);                                   
    }

  }
  return true;
}

For anyone interested in using this code to make buttons draggable via ghostguis/overlays: of note are the offsets "gc.OwningGUI.X" and "gc.OwningGUI.Y" - control positions are always relative to their parent GUI. So I've used the parent GUI's current position as the offset, to ensure that the overlay is created at the right spot.

@vga256,
Another workaround would be to only support controls which are drawn using sprites:
* Empty GUIs with background image and nothing else;
* Buttons which have a graphic assigned to them.

With the current module though, you would have to resort to scripting a custom drag-drop mode. The easiest method may be to replicate "Ghost GUI" or "Ghost Overlay", but let it set any image instead of knowing what AGS object you're dragging. You may follow examples in documentation, or use either demo game or DragDropCommon module as an example.

Thanks for the explanation - that all makes sense. Since I am specifically only trying to drag and drop buttons (with assigned graphics), I will go that route and try to come up with custom drag mode based on GhostGUI.

I'll provide an update here when I come up with something workable.

Hi CW. This module has become one of the most important modules I'm using for an art project that has a fake macintosh-style OS.

I'm running 1.1.0 and I'm wondering if the limitation "eDDCmnMoveGhostGUI - drags supplied custom GUI with object's image on it (currently does not work for GUI and Controls, but this is ONLY way to make inventory items drag & drop)" can be overcome?

I've got a situation where I want to simulate dragging a GUIControl from one GUI to another. The GUIcontrol does not have to actually move from one GUI to another, I just need it to *appear* that way (e.g. show a graphic that follows the mouse cursor to its drop point). The usage scenario is dragging an icon from Window A (a remote FTP, gFTP) to Window B (a local hard drive, gHardDrive).

Currently, the DragDropCommon module allows me to drag a GUIControl, but the control is only moved within its parent GUI... it cannot move beyond the boundaries of the parent GUI. After spending a few hours reading through the DDC module, it appears that the eDDCmnMoveGhostGUI setting is ignored for GUIs and GUIControls.

And yet, according to the documentation, "GhostGUI" mode works with everything, and is the only way to drag Inventory Items. You must provide a GUI though, by setting DragDropCommon.GhostGUI. GhostGUI also uses GhostTransparency property.

Is this just an inconsistency between the documentation and the module code? Is there a conceptual workaround that would allow me to simulate dragging and dropping (via a GhostGUI) a GUIControl from one GUI to another?

Thanks for your help and the great module!

I managed to reproduce the above (thanks @vga256 !), I opened an issue here:

https://github.com/adventuregamestudio/ags/issues/1847

many thanks to you and CW for the patch. Looking forward to testing it in the next RC.

First off - so glad to see how 3.6 has progressed. I took a few months away from AGS to work on other projects, and I'm glad to be back.

I'm running RC3 and I noticed a (new) bug with the SDL2 Software Renderer. There is a single line of missing pixels at the very bottom of each room. When I hover the mouse over the location, the immediate area surrounding the mouse renders properly. When the mouse leaves, the pixels return to black as shown in the link below:

Screencap of missing pixels

It seems to only affect the room background, as GUIs dragged down to this area render properly.

Let me know if you'd like me to upload a test project to demonstrate this. My project is running in 512x384, with room backgrounds of exactly 512x384.

When I switch to the OpenGL renderer, it renders properly. Testing all done in Windows 10.

Thanks for the clarification.

I am not sure if this is a bug, or is historically how AGS works, so I apologize if this turns out to be a scripting error or a case of incorrect expectations.

I'm using the latest beta, and I noticed that when I run:

Code: ags

Object *roomObject = Object.GetAtRoomXY(testDropPosition.x, testDropPosition.y);
if (roomObject != null)
    Display("Found object!");

if the roomObject's "Clickable" property is set to false, no object is found at that location. If the roomObject's Clickable property is set to true, an object is found as expected.

This behaviour does not appear to be mentioned anywhere in the documentation, so I'm wondering if I've either mis-scripted something, this is historically how AGS has worked, or if I've hit a bug with the beta. Happy to share the project source if that helps to replicate.

I think our current thought is to shift to developing "AGS 4" and only keep 3.* branch for perfomance improvements. This is way long overdue.

Gotcha.

Thanks for the feedback CW.

Hearing no objections to the idea, please consider this as a feature request for a future release of 3.6.x!

I'm not sure if this is a reasonable or easily implementable request, so this is more of an RFC for the time being: would it be possible to add Custom Properties for GUIs and GUI controls in the editor? I'm working on a game that is extremely GUI-heavy, and one of the pain points is being unable to assign custom properties to GUIs and controls that would allow me to customize behaviour for each control.

For example, I have the "Expandable" property which applies to window GUIs. This allows a window to be maximized, minimized, and returned to a standard size. Right now, I keep track of this via a huge struct array that I have to manually populate in script like this:

Code: ags

  Windows[gDottedWindow.ID].Vertical = new WindowExpansion;
  Windows[gDottedWindow.ID].guiID = gDottedWindow.ID;
  Windows[gDottedWindow.ID].Panel = RightPanel;
  Windows[gDottedWindow.ID].Vertical.ExpandedSize = gDottedWindow.Height;
  Windows[gDottedWindow.ID].Vertical.CollapsedSize = WINDOW_TITLEBAR_HEIGHT;
  gDottedWindow.AddToStack();

Ideally, I'd love to be able to do something like this instead:
Via the editor, create "IsExpandable" and "ExpansionState" boolean custom properties to all GUIs.

Then in code I could call it like this:

Code: ags

if (currentGUISelected.GetProperty("IsExpandable"))
{
    ExpandGUI(currentGUISelected);
    currentGUISelected.GetProperty("ExpansionState") = true;
}

I would no longer have to keep track of each GUIs properties via an array of struct, and this would make GUIs more consistent with how Rooms are designed.

Welcoming any thoughts on this idea.

Awesome, and thank you! Looking forward to comparing notes and seeing what I can come up with. It's great to see some new life breathed into the module after quite the dormancy period.

Will respond in-kind in the thread with my modifications once I've got something serviceable.

Thanks Grundi and Ben for your (ten!) years of service. For a long time, BCT was my only source of intelligent conversation about adventure game design and development. The show eventually (pretty directly) led to me quitting my career and starting work on commercial AGS titles many moons ago. The adventure game landscape is different now than it was in 2012 when the show got off the ground, and I hope you're proud that you're partly responsible for re-shaping it over the years!

Thanks. It's a commercial title. Per Besh's module licensing agreement (LGPL 2.1), I will be releasing the modified module source afterward.

About the technical parts: I added two main features on top of the module -  setting it up in a way that a certain stroke order has to be followed and that strokes start and end within a given area. I think I also modified the the module interface a bit to support specific angles, but I will have to take a closer look at the code to be sure. I sadly was not able to add support for curved gestures. tbh most of the code in Besh's module was way above my head

Thanks for the reply. The math in Besh's module is above my paygrade as well. Your concept makes a lot of sense - how did you implement stroke start/end for specific shapes? I'm having a hard time imagining how to pull this off!

Cat - sorry for the necropost, but I just played Gakusei and really enjoyed it. I stumbled on your post after looking for bugfixes for Besh's Mouse Gestures module so I could support - you wouldn't believe this - Kanji drawing in the game I'm working on. Hard to believe you built an entire experience around that already!

The gestures work exactly as I would have hoped in your game. Would you be able to describe your implementation a little bit? I'm trying to think about how I could add support for angled/curved gestures like these to the module. (e.g. how to interpret fairly complex prototypes in the right locations)

Cheers,
vga.

My name is Keegan. I'm from the US and I'm a newbie! I have very little coding experience and absolutely no game dev experience. My background is in video production/filmmaking. I'm trying to make a first-person PnC horror game based on an unfinished animated horror short that I half-made.

Welcome Keegan - glad you found your way here! You'll find yourself in good company - some of us are (former/current) filmmakers as well. AGS makes a pretty cheap film production suite

[int toPanning, int fromPanning=0]

As always, thanks for this lifesaving module Edmundo.

I've been using some of the less-often-used tweens lately, and was wondering: what do you think about adding a "from" and "to" Panning setting for TweenPanning? I made a few minor changes to the module (seen below), and this new TweenPanning function allows me to start a Pan at any location (from -100 to 100) and end it at another panning location. This gives me a crude form of procedural dynamic sound for rooms (e.g. rolling a chair across the floor from center to left, and then left to right).

The default (unmodified) behaviour is to start all tweens at their current panning position (usually zero) and takes no "fromPanning" parameter. I could also imagine having the parameter order changed to int toPanning, int fromPanning=0, so the "fromPanning" parameter can use zero as a default value for backwards-compatibility sake.

Tween.asc:

Code: ags

int TweenPanning(this AudioChannel*,  float timing, int fromPanning, int toPanning, TweenEasingType easingType, TweenStyle style, float startDelay, TweenTimingType timingType) {
  return _StartAudioTween(_eTweenAudioChannelPanning, this, timing, TweenMaths.ClampInt(toPanning, -100,  100), 0, TweenMaths.ClampInt(fromPanning, -100, 100), 0, easingType, style, startDelay, timingType);

Tween.ash:

Code: ags

import int TweenPanning(this AudioChannel*, float timing, int fromPanning, int toPanning, TweenEasingType easingType=Tween_EASING_TYPE_AUDIO, TweenStyle style=Tween_STYLE_AUDIO, float startDelay=Tween_START_DELAY_AUDIO, TweenTimingType timingType=Tween_TIMING_AUDIO);

I'm not sure if this was the most elegant way of doing it, but you get the idea

Can anyone else confirm if AudioChannel.Panning is not working for them with 3.6.0? Demo files here. Unless I've made some obvious basic mistake with scripting, I'm not getting any kind of audio panning regardless of the int (-100,100) passed to AudioChannel.Panning. Replicated the same behaviour in TweenPanning which uses this function as well.