Messages

Perhaps preventing PHP links from being used in your avatar or footer is necessary. Not to bash Monkey's avatar, it's a great idea, but it's a little unfriendly if people are having any issue due to his avatar; whether slower loading or a false threat detection.

AFAIK you can't scroll with custom GUI Dialog's, unless someone has made a module or other to do so.

A module is simply just AGS Code. If there's a module that can do it, then you can do it. Unless you meant to say plugin.

Ignoring that, yes, you can do scrolling with a custom dialog. It's just a tiny bit more work.

This doesn't change the cursor to eModePointer:
     mouse.UseModeGraphic(eModePointer)

What that's doing is changing the current mode's graphic to the graphic of eModePointer.

Are you sure there isn't something in your script that's changing the mouse mode to eModeWalkto?

There's no good/bad as long as it works well for your game.

Yes, that's the one talking about having custom speech rendering.

As for custom dialog rendering, it allows you to customize how you want the dialog choices to be shown.

Right here

That was a fantastic movie. Too bad it had subtitles for English.

Code: ags

  if (!Game.SkippingCutscene) {
    // insert any code that should be skipped if you press ESC in this condition statement
  }

[Sprites.George.Stand.Left001]

First, I think without this, the IDs are nearly useless, because unless you are simply looping through every character

Yep. The only reason they should have any use would be because we currently still require the ID for making matching arrays. Like the hats example (preferably the one Monkey posted). Unless in the future there was a way to add your own properties to any Object. Or a ListArray of any AGS variable type - including structs.

you're going to want to restrict it to some index range, and that relies on knowing something about how they are ordered.

Which, as I've said, is error-prone and a very bad coding practice.

Not all the AGS object types have scripting names (sprites, views and speech clips being the most obvious)

Views have their own variable name. Albeit the View is actually just an integer variable, and I'm pretty sure very few people actually use it.

My main argument was about Characters, Objects, GUIs and the Controls. Everything else can slowly follow along.

It's not obvious that forcing a user to name every sprite (for example) is a good idea.

But the sprite is already named before you import the file.    [/joke]
I haven't had a full desire of sprites dropping the ID number. But I certainly wouldn't argue as it's much nicer reading code that has readable sprite name like this   Sprites.George.Stand.Left001   vs    5.  What sprite is 5? I don't remember, let me keep browsing through all my sprite folders until I find it.

Only if you actually wanted to generate new character dynamically at run-time would it be impossible to know the IDs ahead of time.

Or as I've discussed about deleting a character via the editor before compiling. Calling it by the Index instead of the variable name is almost as bad as randomly doing  character[10]  and hoping it points to the right one. Without extensive searching through code to find the problem, no one would be able to work on your project, and you couldn't walk away from it for a year and come back. Once you delete that one character everything goes to hell.

Fourth, I don't really see what your problem is with the existing feature. Some sort of visceral revulsion? That it "feels" too low-level and not properly object-oriented? Not compelling arguments to me.

To be honest, yes. Except for the visceral revulsion part, because that would be better described as your feelings. All my points why we shouldn't know the indices before compile are logical and would help make everyone a better coder. You want the exact opposite.

As for the low-level and not properly OO, that's the main reason. I haven't come across a single UI compiler that assigns the Index for you to see before compile; for the very reason that it allows the  possibility for poor coding.

Anyway, since different participants seem to have had different understandings of what we were discussing, I've renamed the thread again.

I still don't agree with the name because I never tried to change how we access objects by index. Which is why I suggested you to name it: 
AGS Indexing Objects  [shouldn't be assigned before compile]
That's all I wanted this thread to be talking about and I don't want others coming along thinking someone wants to eliminate accessing objects by array index.

As for why I ever mentioned removing the property Object.ID and replacing it for the Game.Characters.IndexOf(Character*) was for the very same reason. Having the ID as a property to the Object will give any inexperienced coder a sense of security that the index integer they receive will always point to their Character. But if it's something they can only get via the Character array, it may help them realize that it's not the Character "ID", it's actually the index of the Character in the array. Right now there's no issue having Object.ID as we don't have the ability for dynamic objects yet.

So could you please, just rename it to what I suggested and allow this thread be a tiny little bit less confusing.

*BEWARE!!! MATURE CONTENT*

It's no worse than your avatar.

@Kastchey: I'm really loving your art style. Fabulous.

[neither]

How do I iterate on a collection of objects if I have neither "objects[ i ]" nor an iterator (foreach or something else) ?

I know you've crossed this text out, but it leaves me wondering if you or anyone actually believe I want to abolish accessing AGS "Object" members via array using indices. I realize after I had read them again that my posts above have come across this way, but this is not the case at all (I think it was this post. I had quickly quoted Crimson and Mite, wrote some code examples and then forgot to break up the quotes later to further explain that I hadn't been talking about the "Object" array - oh well).

I suppose whoever moved this thread over and named the thread "Accessing AGS objects by array index" didn't help matters.

Also I'm sorry if I've come across as condescending. We're like a group of friends gathering together on the net. I get heated up in a debate that, to me, is completely logical to rid AGS of the editor-side hardcoded indices. Having them assigned at compile time, where you wouldn't know what they are before compile which can only lead to fallible code.

Now with me having discussed ridding the Object.ID was mostly if AGS were to advance in the scripting department. So that was me talking about a semi-future AGS, not this one. Overall there isn't a huge issue having access to it in this manner, but I personally can't see you needing it. If you did though, you would have access to the index with the Object's ArrayList. On an unrelated personal opinion, I am slightly bothered by how it's called ID instead of Index - perhaps it's a personal vendetta.

Configuring key values at the top of the script is disorganized now?

In my opinion, from that example, yes. it's not exactly a coding practice I would teach anyone (on a side-note: there's actually a fog module that Dualnames mostly wrote off some code I supplied him. I did that very same thing with index start and amount. It was only as a quick example to show how the fog should be designed - graphically, not scripting. I never meant for it to turn into a module or ever be used in someone's game. I feel guilty about that module even existing. Ha).

It was just a code example based off the code Snarky posted about how he finds the index being shown to you editor side as useful.

Code: AGS

#define HATTABLE_START 15
#define HATTABLE_COUNT 8
#define HAT_START      328

I didn't want to scroll up so I just tossed in arbitrary numbers as he had.

Edit: I was just proving my point at how unorganized it was.

Edit again: Snarky, how does someone take a hat off?   (I meant with the module of yours - you don't have to post code, I was only being an arse)

I really don't see it as any better than my example.

I do. Flexibility and yours is chalked full of potential issues.

If you were creating a module, would you have:
  hatModule_SetStartCharacterIndex(50);
  hatModule_SetHatStartCharacterIndex(60);
  hatModule_SetHatCharacterAmount(10);

Nope. Or at least I would hope not.

If AGS had ArrayLists, I wouldn't need to iterate through every character, I could simply just iterate through the ArrayList which contains all the Characters with Hats.

Direct access to object array indices is a convenience/optimization that is useful for games programming.

Direct access yes, but not having AGS tell you beforehand so you can code everything with the indices - aka magic numbers.

Lol about my extending example. I actually edited my post to remove it before I saw yours. I was sitting here working on my 3D modeling when it suddenly hit me how wrong that code was. I've only extended a Class a few times and that was over a year ago. 

As for my example using a struct, I only did that for organization. Since you'd likely have X and Y offsets and such. I kept it simple as an example with only the character pointer, but you're right, my example should've been a dynamic array (or a bunch of dynamic arrays - if you were to add more elements). There's nothing wrong with characterHats_Hat[] versus characterHats[].Hat. I just have slight OCD tendancy when it comes to keeping things grouped together. lol

The main question is, do you agree about AGS not showing the developer what the index of the "Object" is in the tree?

Ryan, I understand your point, but you're saying nothing new : using "character[1]" instead of "cSally" is bad coding practice.

No, quite frankly you don't see my point. You should NEVER have a reason to use character[1] instead of cSally. NEVER! Not even if you're a level 100 master programmer. 

When you add a button in Visual Studio, does it tell you that the ID is 0. No. Why? Because why would you reference the button via button[0] when you have a completely error prone method via bButton1.

Quit trying to argue that it makes sense to use character[1] to point to cSally. It doesn't and never will. No. (face palm coming very soon)

Edit: Actually the funniest thing you've said is this:

And if he wants to do that, we assume he's scripted long enough to understand what he's doing.

This is AGS. Nearly every programmer making AGS games are completely new to the experience. If ANYONE, advanced programmer or complete noob use the array pointer instead of the syntax name (whatever the correct terminology is for that), they obviously don't know what they're doing. Unless you access it via array looping statement, but that's not what we're arguing here.

That right there is an example of borderline magic numbers - which lead to error prone code.

There are numerous ways to deal with something like that, one being this:

Code: ags

#define CHARACTER_COUNT 44
struct CharacterHat {
  Character* Hat;
};
CharacterHat characterHat[CHARACTER_COUNT];

void AssignHat(this Character*, Character* hatCharacter) {
  characterHat[hatCharacter.ID].Hat = hatCharacter;
}

function game_start() 
{
  if (CHARACTER_COUNT < Game.CharacterCount) AbortGame("Due to AGS limitations: CHARACTER_COUNT is less than Game.CharacterCount");
  
  cGeorge.AssignHat(cGeorgeHat);
}

function repeatedly_execute() 
{
  int i;
  while (i < Game.CharacterCount) {
    if (characterHat[i].Hat != null) {
      if (character[i].Room != characterHat[i].Hat.Room) {
        characterHat[i].Hat.ChangeRoom(character[i].Room);
      }
      characterHat[i].Hat.x = character[i].x;
      characterHat[i].Hat.y = character[i].y;
    }
    i++;
  }
}

And yes, before you mention it, I did use character.ID. Only reason is that I can't extend the Character struct (which to me is the main reason why anyone should ever need the ID). Edit: I've deleted the struct extend example because I'm quite sure I screwed it up.

Edit: With your example, if you suddenly realized you forget to add a character to the tree and its hat character, good luck getting his hat to match without deleting all characters to make the IDs match again.

I don't really see your point, Ryan.

I know you aren't. I don't know why you don't see the point, which is why I'll have to explain it in full depths.

Let me walk you through this so you understand in clear logic. In AGS create 2 GUIs, 2 buttons, 2 dialogs, 2 characters, 2 objects, etc. Then access these elements via script referring to them by the very specific ID AGS allows you to believe they are. For example: your first character is Character1, second is Character2. The Character ID's are as follows:

Character1 = character[0]
Character2 = character[1]

Or as I said above:

0: cGeorge
1: cSally
2: cFrank

You know that when you type the following it will always point to the Character1, because AGS tells you it will.

Code: ags

character[0].Visible = false

Now after you've added all that code pointing to character[0] or any of those multiple "Objects", delete it from the editor.

My argument is that it is using hardcoded numbers in the EDITOR, making you feel safe that that's the ID number to use, when in fact it ISN'T. Deleting that numbered "Object" only reorganizes all other objects, therefor making the constant ID mute and a TERRIBLE design for the editor. If I still don't have a bandwagon of followers, I'll have to post a double face palm picture or something of the sort. 

Now in a future version of AGS where everything is Dynamic, the "Object".ID can still actually stay, just have the Get function access the ListArray like in the code example I posted above. Having it find the first and only matching object in the array, telling you the index. Or you can go the arduous route of an integer variable within every object, but that requires a change every time other objects get a new order - which is a much heavier issue to deal with and more prone to errors on the editor/engine scripting side of things.

Just so we're clear, I'll say it one last time to be sure. AGS shouldn't tell you what ID the "Object" is in the tree. If ANYTHING, it should be assigned during compile time. Thank-you for your time.

Also that's why I posted this in the Editor thread, but that's fine.. It can always get moved back. But now that I've reread my posts, I suppose my arguments have been half and half on both matters.

Edit: I'm just really terrible at clearly pointing out and describing what I thought was a very known caveat about the editor.

I'm currently using Unity making a 3D test game for experimenting and learning. I have a question that I'm not sure what is appropriate. If you were to have a bunch of game objects, would it better to have each object with their own texture, or should I group textures with similar objects.

For instance if I made a desk and bookshelf that might show up in other rooms together, or sometimes separate, would I be better off grouping those two textures together, or having each separate?

Graphics filters can help you to get low-resolution games running well on high-resolution monitors.

the "running well" seems vague to me. And is the 'can help you' needed? how about this?

I agree. I also never saw this text (and I actually looked at the setup before I posted that suggestion). Our minds can easily skim over things that aren't grouped together. I still agree with the idea the [?] hovering box and removing that cluttering text. The setup file needs to be reorganized really. It looks pretty clunky. Perhaps I'll look at making a Photoshop rework. Does the setup file easily allow for all form controls and such?

[Custom dialog options rendering]

When I pass with the mouse cursor over the "ugly black box for dialogue choices", the mouse cursor become invisible.

Sounds like it's changing to eModePointer. Check the sprite you have for that pointer graphic.

As for making it transparent, look at Custom dialog options rendering in the manual. Change the following line:

Code: ags

  info.Surface.Clear(14);  // Clears the area yellow

change to:

Code: ags

  info.Surface.Clear();  // Clears to transparent

That will also allow you to set its position and size.