Messages

See this ticket on the github (also illustrates different opinions on the issue): https://github.com/adventuregamestudio/ags/issues/472

Thanks.

@morganw : this discussion is outside of the scope of Editor-hooked events. Thanks though.

Well at the moment it's really weird because I have to resort to two separate functions to manage my GUI :
on_event for the click
on_mouse_click for the mouse wheel.

Also the weird thing is that I *think* that on_mouse_click succeeds in capturing the GUI clicks when it's placed in the global script (and the GUI is made clickable), but not in a module.

Food for thought (I don't want to distract your attention and effort from the important things, that's cleary secondary) but here is how I would do it :
- rename on_mouse_click to on_ingame_mouse_click
- re-introduce interface_click as on_gui_mouse_click
- Pimp up the events system. At the moment it's really poor. A secondary parameter to give more data (e.g. "which button") could save lives.
Then again I haven't given it too much thought so don't be outraged by my statements

AGS 3.4.1.13 (that is 3.4.1 patch 2)

I have that GUI that I've made clickable. Inside a module, I have on_mouse_click and on_event.

Turns out on_mouse_click does detect the mouse wheel being "clicked" but not the regular left click.
For that, I have to resort to on_event (but then I don't know which button was clicked).

Is it still the aftermath of interface_click having been made obsolete? What's the proper of doing it?

I had no idea about that feature

I'm a bit unsettled by the answers provided there.

Back to the basics :
- 32 bits technology is dying. Slowly, but dying anyway. It's now the end of the 32-bit era. Every new driver and most new programs are now targetting 64-bit systems. Maybe not in our favorite open-source communities, but that's definitely where manufacturers spend their energy and money now. I'm wondering where you're being offered to pruchase 32-bit tech. Is it a second-hand equipment?
- About 16-bits programs : morganw is concerned that you might not be able to run programs from 10 to 15 years ago. I'm not sure why he's worried about that. If it's to run Dos games or Windows 95 or windows XP games, then the reasonable solution nowadays would be to install dosbox, or, at worst, a Windows XP virtual machine (VMWare player is free if I recall, and an ISO of windows XP is not too hard to find)

fyi : I've done a pull request.

DragDrop module is finished and working

OK. It's just that it was never confirmed. Cool!

[1685]

Hello,

- Download the following game project : https://drive.google.com/open?id=1CS_A6xhadFua2dKSAtmsU1oO3aWhfcDQ
- Open it with the (slightly outdated) 3.4.1 - patch 2 (that's 3.4.1.13)
- compile the game. The compiler raises no error
- put a breakpoint on lines 1685 and 1715 in VerbGui.asc.
- Run the game.
- single-click anywhere in the room (once). the character starts walking there. Then double-click on the door to the holodeck (south of the screen). This triggers a breakpoint on line 1685.
- Press F5. You never reach line 1715.

This proves that the game crashes on line 1685.

Now, for the strange part : location_id is declared nowhere.
There used to be a line "int location_id;" in this file, but the variable has been moved to a struct and you'd need to do verbsData.location_id to access that value. Proof : just above the line that causes the crash, add "location_id = 0;". The compiler will reject it.
This seems to prove that the compiler lets through this non-existing variable in some specific conditions.

Here is the scenario that I suspect :
1. the compiler lets through a non-existing variable for some absurd synctactical reason (maybe because it's in brackets : hotspot[location_id] )
2. then at runtime, the mistake is still not caught when resolving hotspot[location_id] --> that returns a bullshit pointer
3. this faulty resolution is passed as some sort of faulty this* parameter to RunInteraction(this*, ...).
4. the faulty this* makes the game crash when RunInteraction tries to propagate it as a on_mouse_click.
(but that's just my two cents. I'm just trying to understand how a non-existing variable is caught only at runtime and in some events-related built-in function)

Could it also be some sort of compiler cache issue? (I mean : does the fact that there was an int location_id previously in the code potentially play a role?)

You can find the wfn font in the assets folder in Github, or here on the forums: it is Tom Thumb.
http://www.adventuregamestudio.co.uk/forums/index.php?topic=48798

Cool. That's also the one I've been using in other places.

Tiny issue : the "tiny" font points to the same file as other fonts : xpaider2.ttf. And that file does not seem to be the right one. I tried importing it at small sizes (5 or 6pt) but it's not right. Can you help me?

I think I'm going to fork this module and merge the DoubleClick module with the (unfinished?) DragDrop module from https://bitbucket.org/ivan-mogilko/ags-script-modules/

The goal is to have some sort of unified listener module that lets you listen to almost every possible mouse event. The ultime goal is to require zero function in the global script to listen to control clicks. The clicks are meant to be handled directly inside the module that also manages the GUI controls that come with it (for example: the script for handling the click on "Save" in the custom Save GUI is entirely within the module that comes with it. Nothing in the global script).

I already have such a module, called "StandaloneClick" (it works pretty well, the concept is bulletproof : I even have events like "hover" and stuff), but since it's your module that's used in the Thumbleweed module, I'd rather build on yours. Also yours is more modern and overall better.

hurray!

Exactly. Never assume that the lower 60 pixels of your backgrounds only need to be black, or you'll come to regret it (usually when it's too late).
Usually what lazy people do (and I'm one of them) is drawing the lower part as a bunch of dimly lit foreground objects. Requires very little effort.
Like this : https://78.media.tumblr.com/c0ceece2d199a72c964d39f05f1f0ea4/tumblr_inline_ot218yxYYQ1qcsurn_500.png
Or this : https://agsezine.files.wordpress.com/2007/07/aok5.gif?w=477&zoom=2

[Photopea.com :]

Photopea.com : This is a 99%-faithful clone of Photoshop (literally a clone : it's Photoshop only with a different name. I couldn't believe my eyes when I found it), but it's online and free (www.photopea.com). It's a life-saver when you can't open .psd files because you're not on your usual work computer or when you don't have the permissions to install stuff on the machine. Just open Chrome or Firefox, go to photopea.com, and here you go.

Yes, that's the kind of ideas im fishing for.

I considered that too. The thing I don't like about it is that if the gems become a McGuffin at some point, they feel like they have low value (more like a resource than an actual precious artifact). Its like the orichalcum in FoA.
I had planned to keep that only for the very final occurrence of the puzzle (the one with the twist), and the gems were going to be provided just beforehand.

I'm trying to dig in the direction of the "alignments" except I'd like to fond a way to bind the constellations with some landmarks on the ground (like some Inca temple or what not). Maybe a visor carved in stone through which you should look at the sky (problem is : it's either real stars OR painted stars, can't have both)

I don't know in which culture the game takes place and if this fits.

Well it's a weird mix of 8th-century Christian world and fantasized Aztec world (15th century central America) (but you can drop some Maya stuff, which is 2000BC to 1000AD south america, nobody will notice).
So the clock hands would be OK anyways even if they have to be camouflaged as just pointing thingies. I was considering using the gears of the Maya calendar wheels but I found them too similar to FoA's 3 discs.

I want something really cool, that will make the player say "wow, I never imagined that". A bit like the weavers' threads in Loom., which have exactly the targetted "time and space and fabric of the universe" feel to them. By the way there's something similar in real life : the Inca khipu

[count]

Let's not try to make this a secret : I'm designing the "main" puzzle for a Fate-of-Atlantis-like full-length Indiana Jones game.
By "main puzzle", I mean the stones puzzle: earth stone, moon stone, sun stone.

In Fate of Atlantis, the puzzle is roughly as follows :

Spoiler

1) At 25% into the game, the player acquires the manual to this puzzle before the puzzle. The instructions are (moderately) hidden in plain sight in the Lost dialog of Plato.
2) At 47% into the game, te player acquires the first stone, which also makes it for a dumbed down version of the puzzle
3) At 64% into the game, the player needs to use two stones
4) At 75% into the game, the player needs to use 3 stones.
5) In the last 25%, the player will need to re-enact the puzzle once more, this time reverted
6) In the last 3% of the game, the player wil need to do the puzzle one last time, except this time the instructions are not inside the manual, but instead een in the background of one room (if the layter pays enough attention)

The objects count is : 3
the objects shape is : discs
The objects name is : "stones"
The objects theme is : earth, sun, moon

[close]

Now for my own game I've come here so far :
- In this game, at 3 key moments, Indy will encounter a large contraption (stone of metal machinery)
- the first one will be very primitive (might be a simple large fresco on a wall) while the last one will be huge (the size of a building) and controlled from a central, human-sized panel (but still preferably big)
- just like in FoA, the first one will be a dumbed down version, the last one will be the witty version
- the machinery relies on CONSTELLATIONS. the idea is that the player must "connect" or "dial" one or several constellations. (preferably one). If he manages to do so, the puzzle is won.
- the machine has to be powered up beforehand, but I've got that part covered.


My requirements are :
- There must be some mystical mystery (the objects are not everyday objects. There's loaded with an aura of magic or legend). Think : "cross of coronado", "headpiece of the staff of Ra", "earth/sun/moon stone". Of course there's also a non-mystical object always coming along (the journal of the Grail) but that one I've already taken care of separately. That object will also play the role of the Lost Dialog.
- It must not be a copy of the sun/earth/moon stone. That's a very tricky part :
    - because of the shape - It's always either a disc or a sphere that comes to mind,
    - because of the number : and it's very easy to end up having 3 of them. Yuck.
    => I was thinking of either a rope/thread/gold string, OR an arrow/lightning bolt/pointy stick OR a staff/set of tall cylinders OR a plain spherical stone with carvings on it.
- There's a twist coming from the fact that the player will not always be on the same hemisphere, therefore the sky will not always have the same constellations. The twist within that twist is that the constellations don't use the same stars depending on the cultures. Therefore the player must recognize a handful of "key" stars rather that the so-called constellations. For the first occurrence of the puzzle, though, happening in North hemisphere, we'll start with our well-known Zodiac constellations, drawn as-is.

So, with all that, the question I'm trying to sort out is : how does the player perform that "connection" to the constellation(s) in a fun and tricky way?

I've had a few ideas :
- the simplest version that immediately comes to mind is : paint all the constellations on the fresco, and have the player point some sort of cursor towards the right one. But that's not good for two reasons: 1) It cannot be "complexified" later on in the two subsequent occurrences of the puzzle, and 2) the player can simply win by trying all the constellations one by one.
- for the intermediate versions : Since the player won't always be in the same hemisphere, i thought that at some point I might have a map of the entire sky (South+North hemisphere projected onto a flat map) and he must "draw a line" or half circle that represents the horizon line. That would tell us exactly how the player would see the sky if he was physically present at that location on Earth. Somehow, choosing the two (or more) constellations located low on the horizon (and defining the horizon curved line) could be the puzzle? And the constellaiton he must dial is the one at the center of the circle? But now that makes me stuck with a half circle or full circle, which is not an easily transportable object like the earth/sun/moon stones. Hence my idea of a thread, but... Meh.
- In the last occurrence of the puzzle, he will have to pinpoint the stars he wants to include in the targetted constellation, and "draw" te constellation. That's not hard, but the difficulty will come from somehwere else -- I've got that convered.

So anyways as you can see I've got this puzzle stuck half way. Anything that would create a sense of "opening gates through time and space" is welcome. At some point I was considering also including osme sort of dial to choose a year (since there's a connection between the PLACE where you are when you look at the sky, the TIME at which you do that, and the POSITION of the stars in the sky when you do that). Choosing the yea and the position of the stars could reveal a place on earth, or something like that. But these three variables could create some cool puzzle but it makes the puzzle overly complicated.

I'm not happy with the fact that I can't decide if the puzzle should be solved based solely on KNOWLEDGE (which constellation to dial) or if some OBJECT(S) are required too (like the 3 stones in FoA). I'm terrified to create yet another one of those puzzles where you need "the three legendary pieces of whatnot" or "the seven pieces of the broken whetever".

What do you think?

If you complete this module, could you make it compatible with the Thumbleweed module? I mean: make sure that the variables and GUI names don't conflict, and ideally make it possible to switch from one to the other easily.

The Freddy Pharkas work documents are exactly what you're trying to achieve, except they found the right formula : https://archive.org/details/FreddyDesign

When you double-click on the hologram character, the player does not "fast walk". Is that intended? I haven't tested but I guess the same thing would happen when you double-click on objects or hotspots?