Changing "description" of objects in game...

[Technocrat]

In my GUI, I have an @OVERHOTSPOT@ telling me the descriptions for objects in my room. I'm aware that the "name" of objects is read only, but am I able to alter the "description" of them with the script, to therefore alter what it says in the GUI? I'll have to look for a workaround if it's not possible.

Merci!

[monkey0506]

If you need to change the name of the object the easiest way might be to just use a Character instead. AGS 3.0+ has no limit on Characters and the Character.Name property is writable.

Otherwise you would have to store a custom variable and update it, as well as modify the text on the label whenever the object is under the mouse.

So my suggestion, just use a Character.

[lsb]

i believe you can just change it with the .Name property, if i'm not mistaken. i've done this before with a character whose description changed once you found out his name. I think it works for hotspots and objects too, but you'll have to check.

[Mr Flibble]

Is there a reason you can't change object.name at runtime?

[monkey0506]

Hotspot.Name and Object.Name are presently read-only.

It's just that the more stuff that AGS has to remember about each room, the more memory is used up and the bigger the save game files are.

But still, in this case I think it's worthwhile.

Get/SetObjectName is already on my to-do list.

Get/SetHotspotName would be a possibility.

So the reason they're currently read-only is due to the fact that making them writable would potentially bloat the size of save game files. Whether this is still as relevant today as it was 4-5 years ago...debatable. But for now at least they cannot be written to.

[lsb]

interesting. but then why would you be able to change the names of characters then? wouldn't that take up a lot of space as well?

[Khris]

Character's aren't room specific.

Adding ~100 strings per room to a savegame shouldn't be that much of a file size issue anymore.

[monkey0506]

What I actually find interesting about it is that Hotspot.Name and Object.Name are defined as String variables, the same as Character.Name. I asked previously (on the tracker entry page) what difference it would make to the size of the save games seeing as these are already String properties, but I got no answer.

I think perhaps that at compile-time these names are actually being stored in a statically sized char array and the way the room files currently access them it expects these arrays to stay the same size (just a complete stab-in-the-dark; no idea honestly).

Of course even if that were true I doubt anyone would object to having a static limit applied to the length of the names (descriptions) so long as they were writable at run-time.

The size of a String variable is 4 bytes plus the length of the text, so worst case scenario it would bloat the required memory by 4 bytes per String. 50 hotspots and 40 objects per room gives us a total of 90 Strings per room. In a large game with, say 300 rooms that's 27000 Strings. If we were to go for a generous average of 10 characters per String that would give us a total of 378000 bytes (or 369 kilobytes)...

It might be fair to give CJ a nudge and see if he could shed any further light on this.

[Technocrat]

I hadn't expected to open up such a can of worms with this! Hopefully in the near future AGS will allow alterations to the object names. I think for my purposes, I'll look for a workaround that doesn't use the characters, since the names aren't *necessary* (more aesthetic), but using the objects as room-specific helps my code work. Many thanks, though!

[Khris]

Setting up a workaround is actually pretty easy:

Put something like this in rep_ex:

Code: ags

  Object*o = Object.GetAtScreenXY(mouse.x, mouse.y);
  int pr = player.Room;
  int i;
  String s = "@OVERHOTSPOT@";
  if (GetLocationType(mouse.x, mouse.y) == eLocationObject && o != null) {
    i = o.ID;
    if (pr == 2 && o == 4) {    // room 2, object 4
      if (tv_broken) s = "broken TV";
      else s = "TV";
    }
    ...
  }
  LABELNAME.Text = s;

(I'm not sure if Object.GetAt returns the object even if the mouse is over e.g. a character which stands before the object, thus I'm also checking GetLocationType.)

I've just thought of another way that works 'decentralized':
Put the alternate name into a custom property, then use e.g. even vs. odd baseline coords to trigger the change.
That way one would simply name the objects as usual and doesn't need to constantly add lines to the rep_ex function.

[monkey0506]

Well the problem with the "baseline/property" workaround is how to go about "making the change" without having to add all these lines in rep_ex. The fact that Object.Name is read-only means that whatever is set in the editor is going to be the only result you will get from "@OVERHOTSPOT@" or Game.GetLocationName.

As you've shown a workaround for a single object/hotspot wouldn't be that difficult. But what if for example it was a game where the objects/hotspots weren't actually named until you'd looked at them? If you had dozens of objects then your rep_ex function would very quickly become an unmanageable mess. Not to mention the fact that you would have to have a unique variable for every object as well!

So if it's a one-off then the workaround isn't so bad, but if it's going to be a recurring usage where you want to change the description, I still hold that using a character instead is the easiest workaround.

Based on what you've said Technocrat it looks like the workaround would be viable for you, but I just wanted to reiterate for others reading why it may not be viable for everyone.

[Khris]

What I meant:
Set the baseline y of all the objects to even numbers. One pixel up or down should hardly matter.
(Alternatively, one could use a Transparency setting of 99, it shouldn't be noticeable. Combine those and you have even four states for every object.)

In rep_ex, check if the baseline y of the object under the mouse is odd, and if it is, make the label read o.GetTextProperty("alt_desc").

Ergo, no adding lines in rep_ex for every object.

[monkey0506]

Okay I see what you're saying. You're saying that by using a text property like that you could create a generic workaround as opposed to the object-specific workaround. You would put it in the global rep_ex and check it against Object.GetAtScreenXY.

I understand now, sorry.

[Dualnames]

In my GUI, I have an @OVERHOTSPOT@ telling me the descriptions for objects in my room. I'm aware that the "name" of objects is read only, but am I able to alter the "description" of them with the script, to therefore alter what it says in the GUI? I'll have to look for a workaround if it's not possible.

Merci!

You can use properties, and you can use a module by monkey if I'm not mistaken that you can alter custom properties in-game. I'm doing a similar thing on HHGTG, instead of overhotspot and it's not hard to script either..