Messages

Code: ags

Error: Ya se agregó un elemento con la misma clave.
Version: AGS 3.0.1.28

I really question the value of localization of internal error messages. I think it gets more difficult to get support from the authors, which may not understand the error, or even to google for it, since the solutions may not be available in the same language as the error. Anyway, it's just my personal view.

To help spot the problem, it seems the error message in plain english is:

Code: ags

Error: An item with the same key has already been added.

Which is the same as the error posted a couple of messages above.

And most importantly, since almost every animation I set up uses sequential sprites, it would really be useful to have a shortcut (either a button or a keystroke) to automatically make the next frame set as the next sprite.

At the sprite window, select multiple sprites and right-click, you should see an option 'assign to view' in the context menu. If this is what you're looking for, it's there since 2.72 I guess...

I would like my gamers to stay IN the game and out of the gamesetup execultable as much as can be managed. Having said that, perhaps it's time for the controls in the gamesetup to be incorporated as default GUI's in the game editor itself that can be turned off at will and customized to fit the game's appearance.

That's an interesting topic. I agree with subspark that we should have a way to change the resolution in-game, through scripting/custom GUIs. But resolution-independent savegames should be discussed first! Otherwise it would be somewhat useless, if you know what I mean...

You create your fancy in-game setup options dialog. Mrs Player downloads your game, starts it up, and changes the resolution to 640x400 using your GUI. It turns out her monitor doesn't support that resolution, so now whenever she tries to start the game, she gets an error. She can't go into Setup to correct this error, because it's inside the game. End of story.

It would be up to the game designer to prevent this, confirming that the resolution actually works, just like Windows XP does, for example. If the user can't confirm, the game 'downgrades' to the old resolution.

And, regardless of where the display configuration is, the 'mrs. player problem' could happen anyway, not because she decided to change the resolution, but because the default resolution, chosen by the game designer, did not work, for whatever reason.

To prevent that, there should be a 'safe mode' shortcut to the game, in which the game would be invoked in windowed mode, and THEN the user could be led to the setup screen.

In that case, I think it would also be useful to have a variable to track whether a dialog is running or not!  Then you could do nifty things like make the person being talked to get bored if you wait too long to respond, or tweak idle animation times...lots of things, really!  8)

I had to make my own dialog engine because of this... well, actually there are a couple of other issues, like the user does not have access to his inventory during a dialog, because every GUI is 'disabled'.

If only the dialog data structures were available through scripting... that would be great.

[After]

On that note however naltimari, it would be useful if we had an eEventEnterRoomAfterFadein event

Totally agree.

But DOES player.room say the room the player is going to? At that point, HAS the player actually switched rooms? Maybe it hasn't, we need to take these things into consideration. eEventLeaveRoom is one of those actions that take place in that sort of limbo, isn't it?

I thought about that. I think it is being called from the leaving room, but I cant say for sure, since I didnt perform many tests. I will do it, then I'll report here.

IMO, your suggestion can be so specific that a simple variable, to be set at the leaving room and read back by the function...

Well, you're right, this could be done, but this is sort of a hack to me, and I try to avoid using globals whenever I can. To me, globals are only justifiable if they are used in many places. In this case, I think it's not justifiable, especially when there's an event where we could hook our code onto.

[on_event()]

I have a suggestion for on_event(). When event == eEventLeaveRoom, data carries the room number the player is leaving. Well, this is kind of pointless to me, because we already know this information, it's player.Room!

IMO, data would be more useful if it carried the room number the player is moving to.

I know it's not good to alter this behaviour, because it has a potential to break existing code, especially considering that many modules use this function. So, I suggest creating an #ifdef for testing at compile time, like this:

Code: ags

function on_event(EventType event, int data)
{
  if (event == eEventLeaveRoom) {
    #ifdef AGS_VERSION_301_beta3
    int room_number_the_player_is_going_to = data;
    #endif
    ...
  }
}

Well, maybe there is a better way to implement it, this is just an idea.

EDIT: On a second thought, one could watch eEventEnterRoomBeforeFadein, and fetch player.PreviousRoom and player.Room... this way he would get both room numbers, where the player WAS and where the player IS... Nevermind.

May I suggest a DrawingSurface.DrawStringWrapped function?

I would find it very useful too.

An easy way of determining it is this:

Interesting piece of code... Even after 8 months using AGS daily, I still bump into commands that I never heard of, like this HasPlayerBeenInRoom().

But this code would only count rooms the player has already been into. OTOH, if the function returned 'null' for any non-existant i-th room, it could be used to find all the room numbers up to 300.

Knowing the room count wouldn't necessarily be useful, because rooms can have such random numbers. You could have a RoomCount of 2, but the two rooms could be Room 53 and Room 641.

This is a different problem, but indeed it is a problem. AFAIK, the only way to get the room number at runtime is by fetching player.Room whenever a player is at a room. The other ways require you to be very methodic and organized, like creating (and maintaining) a room property or numbering the rooms sequentially.

For what purpose do you need to know? It might be possible to implement something to help.

I had an idea about a module that would need to create a dynamic array with (Game.RoomCount * AGS_MAX_OBJECTS) positions. I changed my mind, and ended up doing things differently, but I guess Game.RoomCount would not be so hard to implement, and a module writer could benefit from it.

Actually, that does beg the question ... should the editor folders be arranged like they are at the moment, or should there simply be one root "Game" folder, and then you can just right-click and "Add character", "Add view", "Add font" or whatever else to have everything arranged wherever you feel like it?

I think that, as long as we can delete any item (characters, views, fonts, guis, rooms, etc), i'm happy with the current layout.

In AGS 3.0.1 b2, pratically all items can be deleted (if not all), as opposed to AGS 2.72, in which we could only delete GUIs, if I recall correctly.

Besides that, the current folders act as a cue to newcomers that all those elements are part of a 'normal' AGS game, and the designer can, if he chooses to do so, include items under them.

Well, I tried to change some options in dev-cpp, but there arent many, and none of them worked.

dev-cpp is mostly a GUI for MinGW's gcc, but there are a lot of gcc switches that dont show up in its interface. But one can pass compiler switches directly to gcc, on the command line, as long as one KNOWS how they work, which is not my case...

Can you point me to what specific switches you are referring to?

I'm trying to compile a plug-in that uses AGS' IManagedObject interface in dev-cpp, but it's crashing AGS upon startup.

I'm almost sure that it is due to a different (incompatible) binary layout between VC++ and dev-cpp, because the same code runs fine when I compile it in VC++. Also, if I try to compile a plugin which does not use C++ in dev-cpp, it works in AGS. So, my guess would be name-mangling/binary layout incompatibilities.

I know CJ was explicit about using VC++ for plugins, but I wonder if it wouldnt be a matter of setting the right compiler switches to make things work.

Anyone has any clue about it?

From the manual:

Because there is no new keyword, you cannot create object instances.

Well, this certainly isn't true anymore, as we now do have a 'new' keyword, hehehe.... Seriously, creating Objects and Characters dynamically would be a big feature for me.

Another need, especially for module writers, is the ability to use struct pointers inside other structs (allowing complex data structures, or 'object-oriented-ness') and to return custom struct pointers from functions.

I realize this is more likely to be in AGS 3.1 than 3.0.1, but somebody has to ask for it...

One more bug (or lack of an old feature), this time in Object.Animate(). According to the manual,

The RepeatStyle parameter sets whether the animation will continuously repeat the cycling through the frames. [...] If RepeatStyle is 2 then it will do the animation once, but then return the graphic to the first frame and stop.

However, when RepeatStyle is '2', the loop does not get 'rewinded' as promised, it only plays once and stops at the last frame, as if RepeatStyle was eOnce.

[EDIT]

There's a bug somewhere in the parser, because the next line:

Code: ags

player.AddInventory(inventory[Collectables.GetValueByID(o.ID)]);

won't compile, giving me:

parse error after '['

The same line does compile if I change Collectables.GetValueByID() for a scalar.

EDIT: Collectables.GetValueByID is a static function which returns a 'short'.

I need to know how many rooms there are in my game.

Since there is no 'Game.RoomCount' property (shouldn't there be one?), how can I do this? Help!

[this other thread]

Erm... maybe i'm being a zealot, but shouldn't this other thread be used instead of the current one, as CJ asked?

I've being following the other one, but it seems that this one is getting all the attention.

Along with the suggestion to group the header and the script under a parent node on the 'Scripts' tab, I would find very useful to know which of the 'global' functions (i.e. game_start(), rep_ex(), on_event(), etc) are in use in each module.

Example:

...
[-] Fonts
[-] Scripts
   [-] ParticleEngine
      - repeatedly_execute
   [-] KeyboardMovement
      - repeatedly_execute
   [-] MyCoolModule
      - repeatedly_execute
      - on_mouse_click
      - on_event
   [] AnotherModule (closed node does not show children)
   [-] GlobalScript
      - game_start
      - on_mouse_click
      - repeatedly_execute
...

One click on each of the child nodes would take you right into the module, inside the function.

The motivation is that sometimes one has to open many scripts to see exactly what is being executed every game cycle (in rep_ex ou rep_ex_always, for instance), or to see how the mouse clicks and keypresses are being handled throughout the game.

Well, it's been a long time coming, but AGS 3.0 is finally here!

Has anyone tried the new 3.0 editor on Linux+Mono? Is it worthwhile?

Would anyone have any strong objections to me changing those editor warnings into compile errors when you don't fill in all 4 loops in character views, because this isn't the first time that people seem to have ignored the warning and then reported a bug?

Hmmm... Personally I would find it *really* annoying. The way they are now, the warnings are annoying enough.

Maybe if the editor creates four (empty) loops upfront whenever one creates a character, then you could leave the warnings and avoid the issues that you mentioned, without getting too much in the way.