Messages

We're considering leaving the PayPal option open for a little while after the campaign ends

In that case make it clear in your announcements on every related website. If I were a potential donator and had a big message "the deadline is gone" right in my face on the front page, I'd think "pah, I'm too late!"

It's working! Thanks.

The "return" statements you have after "goto-dialog" are redundant and should be removed.

Yes, I know, I added them in a desperate attempt to trick the compiler.

However, the "goto-dialog" statements count as a "return/stop statement", so you can't have any script command (including braces) on the line following that command.

Ok. But I need to launch either one dialog or the other depending on the boolean test.

could you use the normal scripting command Dialog.Start

Let me try that. The compiler is accepting it but I need to test in-game that it doesn't make it explode.

Congratulations Ali!
Now get back to work and that darn game! We're begging you!

["Dialog 7(84): Script commands can only be used in the area between a @ entry point and the closing return/stop statement"]

It's probably obvious but I don't understand why this script (appearing in a dialog) throws the error : "Dialog 7(84): Script commands can only be used in the area between a @ entry point and the closing return/stop statement"

Code: AGS

@5  // Listen carefully, all of you...
Indy: The subject will be...

  //did we already resolve this?
  if (DialogsLogic.GetVar(eDialog_FoundProperSubject))  {
Indy: ...wood carving...
Indy: ...artwork...
Indy: ...constantinople...
Indy: ...Mehmet IIs reign.
goto-dialog 10 //dStudent2_HowAbout3. That will compute the outcome  
return
  }  /////////// THAT LINE THROWS THE ERROR /////////////////////
  else
  {
goto-dialog 9 //dStudent2_HowAbout2
return
  }
  
return

Because of that error, I get another error "Dialog 8(1): Error (line 1): Nested functions not supported (you may have forgotten a closing brace)" in the dialog immediately after. But I suppose it's only a side-effect.

If I remove the bit I quoted just above, then the code compiles fine.

I was thinking of something that could be a brilliant game concept, if properly handled :
Basing the game on "Dorian Gray's portrait".

By essence, it's something old, and something new. Also the theme definitely makes you blue. And the painting definitely borrows something from Dorian Gray (and vice versa).
The entire game would be a close-up on the portrait (I suppose one could scroll up/down/left right over the picture). The puzzles would be interactions with bits of the picture: his face, his clothes, background elements, etc. It would be very atmospheric, slightly scary. As puzzles get resolved, the portrait gets older or younger -- as in the book, life gets stolen from Dorian Gray. Some elements would change in the picture. It would end up with death or some sort of cursing.

The whole idea would be to make the presence of the character in the portrait totally fascinating. And to make you feel the old, and the new, and the borrowed, and the blue. Through his looks. Or the voice-over of a narrator.

Oh, and before you ask: no, I'm not doing it. Nobody ain't time for dat shit. Just sharing the fun.

Rgarding your original question : "is the boat moving too much".
It is, and it isn't.
It isn't because that's how it would move in reality.
It is, because the waves stay still even though there should be big waves.

So, it's like a boat shaking on non-existing waves.

[@stupot]

@stupot : I like your latest production but I think it can do without the bubbles -- that pattern is too big compared to the other nearby patterns. Smaller bubbles could be worth a try.
@selmiak : I like your latest productions but I think it can do without the pointy flares around the small cup. I'm not even sure the smaller cup is necessary at all -- its style conflicts wi the larger cup's style.

Like you said, you're updating the part of memory that contains the surface, but it hasn't been drawn yet, and thus CreateFromScreenshot will never reflect these updates in the same loop.

Damn.

Nevermind. I think I'll just take my screenshot once at the very beginning of the game loop, and then use this outdated version for all the drawings in the loop. I think this will fool the end-user's eye.

[lastest screen update]

In my game, I do a lot of drawing onto the BackgroundGraphics of one GUI.
I do it in repeatedly_execute_always.
I have a loop that updates various graphic items on that BackgroundGraphics's surface : I do a bit of drawing, then call "Release()" (to update the display memory), and then "GetDrawingSurface()" again (to start drawing again) -- several times in one game loop.

The reason why I'm doing it little by little is because I need the display to be up-to-date (if not on-screen, at least in memory), because I also use "DynamicSprite.CreateFromScreenShot" (to save the aspect of some of those graphic items, without requiring to redraw them) and I want the created sprite to contain the lastest screen update.

Since I'm inside repeatedly_execute_always, I can't call Wait(1) to force-update the display.

Despite calling Release on my drawing surface, the "CreateFromScreenShot" snapshots are always one frame off.

I don't know what I'm doing wrong. Do you see if I'm wrong in my reasoning? Do you have general advice regarding the use of these functions?

I'm taking th eliberty of un-hiding this, as it can be overlooked by someone just browsing

some more

Flat cup



grande cup
]


grande cup with round handle

Selmiak, did you consider combining your 2 concepts? (pixels behind the cup and inside the cup).
Also, maybe you could replace the pixels behind by some sort of horizontal rainbow Roger? (you take Roger's sprite, turn it 90 degrees, and apply effects, so that only connoisseurs notice it's actually Roger)

O, thanks for the answers!

...And that's a module by Dualnames, namely the guy who keeps a huge database of all existing modules. 

Hi all,

According to the manual :

on_mouse_click (MouseButton button)
Called when the player clicks a mouse button. BUTTON is either LEFT, RIGHT or MIDDLE, depending on which button was clicked. The "mouse.x" and "mouse.y" global variables contain the mouse's position.

It doesn't say anything specific about GUIs.
Yet, when I click on a GUI (it's "on" and "clickable"), then on_mouse_click is not called. When i click outside, it's called.
I don't understand why. As a workaround I call "IsButtonDown" in repeatedly_execute_always.

Thanks to Monsieur Ouxx' module thread, I stumbled across this nice splash from Subspark and Ryan.

I was just about to post it! Did you infer it was by subspark just by reading "sub" in the cropped picture ?
The thread is here, and you have many images :
http://www.adventuregamestudio.co.uk/forums/index.php?topic=42573.0

I'm note sure it would be that simple to implement GUI elements (especially textboxes and listboxes) without using regular GUIControls (having to check for cursor position, dynamic text length, etc.).
By the way, how do you intend to handle elements positions and sizes when resizing windows in version 2?

I'll be resizing the controls while the window gets resized, and when the control is overlapped I'll make it either fully visible or fully invisible, or something. Or replace it with a gray rectangle. There's always a simple workaround.

Next step: a menu/toolbar module?

We'll see. I don't need those for my personal project.

(By the way, shouldn't this topic go in the Modules&Plugins board?)

It's done manually by the admins. It has to be posted here first.

I actually wrote a more complete GUI system for AGS which had support for layout based arrangements and had a full suite of controls but it's written in Lua so I doubt anyone would use it.

Post it here! I was looking for one!

This looks fun. Can I actually have GUI elements (labels, buttons et al) on them, or some means to catch a click and process it? Or is this "just" to display images?

Yes, you can do it yourself rather simply, but it's not implemented -- but here is how I intend on doing it for version 2:
- either you draw your own controls and use the boundaries detection functions already present in the code to intercept clicks there
OR
- you use regular GUIControls, and in repeatedly_execute_always you make them "follow" the windows as they get dragged around.
Either way, it's very simple.

[What does it do?]

What does it do?
- This allows to create small windows, as if you were in your favorite OS.
- They have a title bar
- They are skinned (borders+background) -- in the screenshot, Dennis is a window with a transparent shape. You can create as many styles as you want.
- you can do drag&drop to move them and resize them
- the window with the focus is on top of the others (z-buffer)

Why not just use built-in AGS GUIs?
This allows you to do things similar with playing with GUIs (moving them around, using Z-order, etc.), except all the windows here are drawn to a surface of your choice. For example you can have all your small windows drawn to the background of a GUI, or to the room's background.
This lets you have more control over what you draw and where you draw it.
Also this is an open door to infinite refinements if you decide to expand the code (frames, new controls, etc.).
Finally, you can have hundreds of windows (if you used GUIs you'd be blocked by AGS built-in GUIs and Controls upper limit)

No, seriously, why not just use built-in AGS GUIs?
Do as you like.

Is this module any good?
No. Performance-wise, it probably doesn't scale up well. Also the code is not optimized at all, and probably badly written in some places.
But this is still a nice little piece of script if you needed a primitive windowing system (to simulate a computer screen, etc.) but were too lazy to create it.


DOWNLOAD (version 1.0)


Manual
See "Windows.Test()" for the most simple code snippet in the universe.

Compatibility: Made with AGS 3.2.1

this way please

Damn, you've been faster than me!