Messages

My niece has more fighting skill!

I know, she taught you everything you know.

-----------------------------------------------

Your mother wears army boots!

Good idea with the question mark, Crimson.

If possible, we could add a blue question mark like this:   Scaling  [?]
Which will popup a small description if you hover over it.

Crimson, I'm pretty sure he's talking about GUI.Visible or Control.Visible.

As far as I know, AGS skips over GUIs and/or Controls that aren't Visible.

Changing GUI.Visible to false will just make that GUI inactive. Same with changing a single control visibility to false.

I believe me adding the foreach in that code snippet has confused you folks (I'm not actually sure why I even included that into my example in the first place). I never meant this conversation to argue that accessing "Objects" by array was bad coding practice - who the hell would want to abolish an array via index? I was stating that getting the index the "Object" (also via "Object".ID) shouldn't be hardcoded AT ALL.

For instance: when you add a character in the tree, it shouldn't be
0: cGeorge
1: cSally
2: cFrank

Because when you are scripting, you can go crazy typing character[1] all over the place and know it'll always be cSally. But if AGS were to one day improve itself, and one were to ever delete cSally, or insert a new character before cSally, then goodbye to having character[1] point to cSally.

And I apologize for this to have derailed your thread, Crimson. I agree to the topic split.

Oh right. I remember reading about that on the LibGDX forum.

Just imagine the games Ben304 would be making if he could do unusual perspectives like 100x400. I could see him doing it.

Let's ask this in another fashion. Is there a good reason for hi resolution games?

Playing a game like Minecraft or something with very low polygon models, opposed to Crysis, is the same as what we're doing with low resolution games opposed to a hi res 2D equivalent. We want to create games with the blocky style.

Games like Minecraft or all the new "pixelly" style games are in a very strong position of popularity right now. Everyone is still craving those styles because of A: it leaves more for your imagination B: it's the nostalgic trip of remembering old-school games. Or whatever other reasons.

I don't think it's something that should die. It's just something that should be easier handled with AGS and the monitors of today.

An option like "Zoom 2x" in the winsetup.exe might do wonders (or changing the screen resolution itself).

Is this a suggestion? AGS currently has this - unless you're playing an older AGS game which only has the 640x400 or 640x480 zoom.

Should you need a begin, render and end though? I was thinking of it being like this:

Code: ags

function speech_render(SpeechRenderingInfo *info) {
  gSpeech.Visible = true;
  lSpeechLabel.Text = info.Text;
  // play sound
  if (info.Audio != null) {  // I haven't worked with Audio in a long time, so the following code may be wrong
    info.Audio.Play();
    while (info.Audio.IsPlaying) Wait(1);  // of course not forgetting about skipping text if audio is playing, I got lazy to type it
  } else WaitMouseKey(info.Delay);
  gSpeech.Visible = false;
}

Hmm.. Now that I've had time to think of it, someone isn't forced to actually use begin or end if all they wanted to do was what I wrote above. Someone may not want to render their own speech, but they may want a GUI to pop up during each speech call. It's not a bad idea actually.

Also, it is not my invention, this is the replacement for "game.skip_speech_specific_key" variable.

Oh wow. Learn something new about AGS everyday. You've done your homework.

Says me obviously.    If you ever introduced a delete method to delete an "Object" it would reek havoc on any code you have. Whereas the currently deleted character index would be swapped with the last index (or having the whole array sort itself to remove the deleted index).

The only reason I believe it's even useful to have "Object".ID at this very moment is because we don't have support to extend to the current AGS structs yet.

Curious question, will there be an internal Set script for PortraitXOffset or PortraitY which turns CustomPortraitPlacement to true? In case I'm being misunderstood, I meant that whenever you change the PortraitXOffset or PortraitY, have it change CustomPortraitPlacement to true. It sounds like a good idea to me, but I'm not 100% certain if you agree.

Also another question. What is the SkipKey for? In case someone wants a very specific Speech style, where for example, you can only hit Enter to skip the text? Overall I suppose it isn't a terrible idea.

Also let me direct you to this thread. I was going to type it in here but decided a separate thread makes more sense.

Just like the Custom dialog rendering, perhaps having a Custom Speech rendering function.

Just as a quick suggestion to make it similar to the dialog rendering (not that I like this function name, but whatever way you all fancy):

Code: ags

function speech_render(SpeechRenderingInfo *info) {
  // show your own GUI, Overlay, etc, giving a custom way of drawing the speech text to screen
  
  // having access to this stuff: 
    // info.Text to access the text being Said  <-- the text passed with the Say function
    // info.AudioFile  <-- the audofile passed with the Say function
    // info.Delay   <-- the delay that AGS would've had if it were using its own function
    // etc
}

This way for example, when you call Character.Say, this custom speech rendering script will intercept it allowing you to do anything you please without working with AGSs default speech functions. Also this way, you can still have all the AGS abilities of creating voice acting scripts and such whereas now where you currently wouldn't with a custom Say function.

I've used the object[ID] to apply settings to a large number of objects etc during runtime, kind of like Billbis is describing. Not so handy with script names, unless I am overlooking a method.

Indeed, working with ranges of elements is important possibility, and its not going anywhere.
Although I am not sure if Ryan meant accessing elements of array; I thought he means accessing Object.ID property.

Nope. I meant exactly what I said. Accessing "Objects" by a strict ID is a terribly, terribly poor coding practice ("Objects" being GUIs, Characters, Objects, Hotspots, Regions, WalkableAreas, etc). They should be accessible via an ArrayList (which of course is the same thing, but you shouldn't have Character.ID to find what index it is in the ArrayList).

Code: ags

  // Character variables created in the accessible "Game" script
  Character cHenry = new Character("Henry", 100, 150, 5);  // Name: Henry, X: 100, Y: 150, Room: 5
  Character cSally = new Character("Sally", 110, 160, 6);  // Name: Sally, X: 110, Y: 160, Room: 6
  Character cFrank = new Character("Frank", 120, 170, 7);  // Name: Henry, X: 120, Y: 170, Room: 7
  
  // Characters being added to the AGS character ArrayList
  Game.Characters.Add(cHenry);
  Game.Characters.Add(cSally);
  Game.Characters.Add(cFrank);

  // Getting the index of cSally - if you ever needed it, which you shouldn't in most cases
  int sallyIndex = Game.Characters.IndexOf(cSally);

  // iterating through the Characters ArrayList
  foreach (Character c in Game.Characters) {
    c.Visible = false;
  }

  // iterating through the Character ArrayList as it is now
  int i;
  while (i < Game.Characters.Length) {
    Game.Characters[i].Visible = false;
    i++;
  }

Etc etc. You understand how ArrayLists work. This is how AGS should've been designed, without the strict IDs. And yes, I think it's very relevant to the discussion of adding unlimited regions, as even regions should be Dynamic. If you're going to do it, may as well do it right.

Holy you're good. Yup. I loved that game when I was younger.

But using explicit ID may be replaced with script name, which is far more safe.

I'm really not sure why being able to access the "Object" ID was ever implemented in AGS. Likely due to the limitations of AGS script and then trying to stick with the whole backwards compatibility - which in my opinion is only hindering all radical improvements of the editor.

[imgzoom]http://www.bryvis.com/entertainment/other/agsf/guessthegame/guessthegame02.png[/imgzoom]

My apologies. It's been ages since I've last used the game.inv_activated that I honestly couldn't remember what it was. I had also forgotten that AGS had a onClick handler for eMouseLeftInv. So it should've just been this:

Code: ags

if (mouse.Mode == eModeUseinv)
{
  // I don't know how this module was scripted, so as a fail-safe, I put: player.ActiveInventory != null
  if (player.ActiveInventory != null && game.inv_activated != player.ActiveInventory.ID) inventory[game.inv_activated].RunInteraction(mouse.Mode);
}

Edit: Also, I've never played BASS, if you're not going completely strict, the other option is this:

Code: ags

if (mouse.Mode == eModeUseinv)
{
  if (player.ActiveInventory != null && game.inv_activated == player.ActiveInventory.ID) 
  {
    player.ActiveInventory == null;  // deselect inventory item if you click the same item on itself
    mouse.Mode = eModePointer;
  }
  else inventory[game.inv_activated].RunInteraction(mouse.Mode);
}

I'm a little confused.

There is no need to call Game.GetLocationName here, because you already know that it is "game.inv_activated" item id, therefore you can use inventory[game.inv_activated].Name; but further, you don't really need to compare Names, you can just compare pointers:

And then you have this:

Code: ags

// if player has active item in hand, use it no matter what (we may get "unhandled event" here)
if (mouse.Mode == eModeUseinv)
{
   if (player.ActiveInventory.Name != Game.GetLocationName(mouse.x, mouse.y))
      inventory[game.inv_activated].RunInteraction(eModeUseinv);
}

You're assuming that the object, hotspot, character or inventory item you're hovering over won't ever have identical names. I don't understand your logic here.

This would be better:

Code: ags

if (mouse.Mode == eModeUseinv)
{
  InventoryItem *item = InventoryItem.GetAtScreenXY(mouse.x, mouse.y);
  if (item != null && player.ActiveInventory != item) inventory[game.inv_activated].RunInteraction(eModeUseinv);
  else if (GetLocationType(mouse.x,mouse.y) != eLocationNothing) ProcessClick(mouse.x, mouse.y, eModeUseinv);
}

Also, I very much dislike you doing this!:

Code: ags

if (inventory[game.inv_activated].IsInteractionAvailable(eModeUseinv) == 1)

It's a boolean and you're checking if it's 1. I know AGS's booleans are actually integers and this code will always work. But you shouldn't make this a practice. It should either be the two with no exceptions:

Code: ags

if (inventory[game.inv_activated].IsInteractionAvailable(eModeUseinv))
// OR
if (inventory[game.inv_activated].IsInteractionAvailable(eModeUseinv) == true)

If AGS ever gets a variable overhaul turning booleans into actual booleans, then this code could throw an error (if it's strict). Plus it's a VERY misleading condition statement that will only confuse people trying to understand the code.

King's Quest V 

Wow, after watching a few Shadowgate 64 vids, I must say that the game is oddly impressive looking. Albeit the interface is massively outdated, it still has some charm to it.