Messages

I had an argue about IDs with Iceboty 7000 about a year ago, and funny thing is, back then I was on Ryan's place.
(I may try to find the thread later)

However I quickly learnt there are cases when you must have a way to iterate through part of array, or take out an item by its relative position.
Of course there are ways to do this without numeric ids, but they may be too difficult for usual user of AGS. Any way, this is absolutely not a simple matter.


E: Ah, here you go:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=36835.msg627199#msg627199

+1 .

In fact, I was thinking about three functions:
"speech_begin" - allows to preset/precreate stuff;
"speech_render" - for drawing and changing speech data real-time;
"speech_end" - a place to release all dynamic stuff / hide GUIs etc.

For example:
1. In speech_begin show Gui with a wrappable label.
2. In speech_render add a letter to simulate runtime typing.
3. In speech_end hide Gui.

Also, if user is allowed to create SpeechStyle items in game, he may have several speech-styles to choose from, or even set SpeechStyle for a particular character.
In this case those function may also receive SpeechStyle pointer as second parameter; or, going OO way, these functions may be event handlers of a SpeechStyle object.

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.

Hmm, that sounds reasonable, but I am unsure... I mean, obviously user won't set those properties without intent to use them, but what if he will like to prepare them beforehand and enable later?
Well, anyway, that's easy to add.
And, yes, "attribute" tag automatically creates get/set methods using provided property name. Property (attribute) itself does not contain any data.

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?

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

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.

Dynamically created entities were in plans, but I wasn't intending to do this right away. I can't tell for sure how much more time this will take, and I have no idea if I will find time (and enough devotion) to work on this.
Meanwhile few people already asked me personally for a version with increased limits of objects. So here it goes.
And while what you say may be related to unlimited regions, this topic is not about unlimited regions. It is about Editor UI. (Not any more, it isn't. - moderator)


EDIT: removed overly emotional line.

tzachs, if I understand you right, what you say sounds like a simplified version of my old suggestion:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=46483.msg625473#msg625473

Hi paolo.
What version of AGS do you use?
Is there any window displayed with an error message when the crash occurs?

Hmm, this gave me different idea.
What if there's only one button displaying current selection, but pressing that button will show a "floating" palette, which closes as soon as you choose another item or click elsewhere? This way we don't need to put everything on toolbar.

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.

Anyway, I started this topic for completely different reasons, and I think it is better to continue the discussion on IDs in separate thread.

I really need to figure out how to update user interface. This is pretty irritating, 'cause the code for unlimited regions is practically ready.
So far I can only imagine adding +/- buttons on the topmost panel of Room Editor, as a temporary solution for Alpha version.

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 never knew about it until Monsieur OUXX asked something related on forums.

There are a lot of "game" members, some of which have quite non-obvious meaning, and allow to change different aspects of the engine, that cannot be affected otherwise.

I'm a little confused.
<...>
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.

I am sorry for confusion, Ryan, for the last code example I just mindlessly copied existing code, because the purpose of that example was to show different condition (mouse.Mode == eModeUseinv). I did not even paid attention to what is in the block.
Also, I was speaking about section of code under "button = eMouseLeftInv". There can't be any characters there.
If you read my posts further, you will see that I made two suggestions on how to optimize item comparisons.

Although your variant combines two of them . First you take item from screen coordinates and then still use inventory[game.inv_activated]. If you use "game.inv_activated" there's no need to check item under mouse.

Is there a new official AGS version in development, maybe supporting higher resolutions?

Not yet .

These bounds are only about the graphic resolution?

Yes, I guess so.
Well, I did not do full testing, all I know is that it breaks easily if you start experimenting with other resolutions than 1280x720.

I once made a game for MAGS in 4 days (one of two AGS games I ever made actually). And it contained 3 rooms .

I want to clarify, is the OROW theme-based competition, or one is free to choose the topic/concept?
How will the jury make sure that nothing premade was used?

E: I seriously need to take a rest from C++ coding, so I might join only because of that .

Yes, but that will somehow require to rearrange hostopt.ID when user is deleting one hotspot, wich can be ... disturbing.

As well as deleting a Character, or a GUI. That's being a problem for a long time.
But using explicit ID may be replaced with script name, which is far more safe.
Range operations and calculating relative id will still work so far as you can address array of hotspots from script.

I'll take advance of this opened tread to ask a question: me and my illustrator are making a game in 1280X720 using the SkyGoblin custom resolution AGS version and, untill now, we haven't found any bug (we are still protyping )...
Now I read about problems that this version could give... what do you suggest me to make a game with that resolution in AGS?

I think that Skygoblin's version works well while you stick to its rules. Some people used it for 1280x720 resolution and it worked for them, so I don't see a big problem with that.
What I was saying is that it starts to behave weird as soon as you step outside of certain bounds.
Also, regardless of how well it works for 1280x720, the way it is coded (internally) is not good enough to put this feature to official AGS yet.

I have no idea of what will be the best solution, but I just wanted to enphasize that we should keep a way to quickely iterate things across all (existing) regions, like what we can do now

There's no reason why this may become unusable...
What changes is actual number of hotspots in room, i.e. you will need to write:

Code: ags

while (i < Room.HotspotCount) 

I've been working on removing limits meanwhile, and I've met following problem.

At the moment the number of room hotspots/regions/walkable areas and walkbehinds (I'll call them simply "regions") is constant. User may set name and properties / write event handlers for them even if they are not yet drawn (and even if they never will be).
Interesting thing is, that this opens unusual possibility to have "hidden" (unpainted) regions and still call their interactions with script (e.g. hotspot[20].RunInteraction(eModeTalkTo) or whatever).

Now, assuming that the limit will be removed, or rather increased to technical maximum (which is 256, because the regions are defined with a 8-bit mask graphics), question arises: should their number be still a constant or a variable?
Of course 256 is not 2147483647 (maximal number to store in the "int" variable) nor 4294967295 (unsigned int), and it won't take that much extra memory (the mask bitmap is still only one for all regions, regardless of their count), but it still will take extra memory.
Also it might be pretty confusing for user: how many hotspots does he actually have: the 3 he painted over room or 256?

The actual problem with the variable number of regions is that the current Editor interface is not fit to handle them.
There's no means to define real number of regions (hotspots, etc) and there's no means to add/remove them. You may erase a region from the room background, but the element itself will stay (and may be referred from script, as noted above).

Furthermore, current interface is very inefficient to work with large amount of room elements, in my opinion. Except for using a graphical "picker" to select a region there is a combo box that will become really annoying if you will have, for example, 100 walkable areas.
Though, this issue is far minor relative to the first one.

Does anyone have good ideas how to change the editor interface to allow addition/removal of regions?

I don't get that. The manual states that an interact click on an inventory item will be translated into an useinv action- basically, as soon as your cursor becomes the selected item you *are* in eModeUseInv. So I don't see why this test will fail? (And if it would fail, the template wouldn't work the way I want, but it... seems to do just that  )

Yes, I was wrong... something I forgot about, that engine automatically sets mode to eModeUseInv when you set ActiveInventory.

Other than that, I think I am mistaken about "game.inv_activated", it is not obsolete, and probably can be used, just needs little different code to remove excessive commands.

Code: ags

if (inventory[game.inv_activated].IsInteractionAvailable(eModeUseinv) == 1 && mouse.Mode == eModeUseinv) 
{
   if (player.ActiveInventory.Name != Game.GetLocationName(mouse.x, mouse.y))
      inventory[game.inv_activated].RunInteraction(eModeUseinv);
}
else if (inventory[game.inv_activated].IsInteractionAvailable(eModeInteract) == 1) 
   inventory[game.inv_activated].RunInteraction(eModeInteract);
else 
   player.ActiveInventory = inventory[game.inv_activated];

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:

Code: ags

if (player.ActiveInventory != inventory[game.inv_activated])
      inventory[game.inv_activated].RunInteraction(eModeUseinv);

Another thing that worries me is whether this combination of conditions is proper.
1st condition will succeed if both mode is "use inv" and clicked item has "use inv" handler.
2nd condition will succeed if either mode is not "use inv" or clicked item has no "use inv" handler and item has "interact" handler.
This means that 2nd condition will succeed too if player used an item on another item that does not have "use inv" handler.
This also means that 3rd condition (else) will succeed if player used an item on another item that does not have any event handlers - in which case he will select the latter.

This is, of course, a choice of design. I don't remember how BASS handled this (if you follow BASS UI style). But I may suggest do it this way instead:

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);
}

[health[player.ID] = 10;]

I understand what arrays are and how to use them, except I read this code and wonder what this means :   health[player.ID] = 10;

It is a combination of commands:

1) take object "player";
2) get property "ID" of taken object;
3) use property's value as an index in the array.

More simple example is

Code: ags

int a = 6;
health[a] = 10;

second line means: take variable "a" and use it as an index in the array.

Since I am on it, this is what I am planning to add to script api:

Code: ags

enum SkipSpeech {
  eSkipKeyMouseTime = 0,
  eSkipKeyTime      = 1,
  eSkipTime         = 2,
  eSkipKeyMouse     = 3,
  eSkipMouseTime    = 4
};
  
managed struct Speech {
  /// Enables/disables the custom speech portrait placement.
  import static attribute bool         CustomPortraitPlacement;
  /// Gets/sets speech portrait x offset relative to screen side.
  import static attribute int          PortraitXOffset;
  /// Gets/sets speech portrait y position.
  import static attribute int          PortraitY;
  /// Gets/sets special key which can skip speech text.
  import static attribute eKeyCode     SkipKey;
  /// Gets/sets how the player can skip speech lines.
  import static attribute SkipSpeech   SkipStyle;
  /// Gets/sets the style in which speech is displayed.
  import static attribute eSpeechStyle Style;
  /// Gets/sets how text in message boxes and Sierra-style speech is aligned.
  import static attribute Alignment    TextAlignment;
  /// Gets/sets whether voice and/or text are used in the game.
  import static attribute eVoiceMode   VoiceMode;
};

I should probably also put global functions/variables I am replacing with these properties under "#ifndef STRICT" to disable them unless backward compatible mode is enabled.

E: I can't make TextGUI right now, the related code is bit more complicated than I expected. Engine has TWO text window ids, which may be the same or different, and are used in different cases...