Messages

I guess I deserved to be kicked out of my lazy butt and "forced" to take a stroll to the mittens site... and to read this thread...

as for places to stay as of right this moment [because you don't want to read the thread] room will be free because it's at my camp... unless you want to pay that is then i'm more than happy

Yes... I have a HUGE surplus of money right now... It's such a pain to have to SWIM my way to the front door through all the bills everytime I want to leave my home... A five star hotel will come in handy...

fjeronimo

Actually the story of my avatar is a long and bloody one...
...It all began in a dark and stormy night...

...wait a minute... I just remembered... I don't have one!... Ops...  

fjeronimo  

First of all, I really love the background: Not only the sky but also the rocky environment. It gives a surreal look that really captures the attention.

However, I have to agree with the character's stance comments. It looks like he's dangerously leaning to the side, as if the handgun was so heavy that it was dragging him along to a great fall to the ground.

Another small thing I noticed is the strangeness of the connection between his left hand and the wrist. It seems the hand is fully articulated, a bit like a wooden marionette's hand, staying at a weird angle which doesn't seem very natural for a human being.

On the whole, great work here. Ah... and really good choice of colors.

fjeronimo

When the final preparations are taken care off, where will the data relative to this event be posted? The forums?

And how long will mittens 04 last? A day? A weekend? A week? Also related, I hope some of you guys who actually live there know of interesting (read good and cheap) places to stay, since I guess the trip will be 'hell' for Europeans (like myself)...

fjeronimo

Actually, Dragonrose, I think that the Log writer plugin I just released can do exactly that.

For instance, in the examples you provided, you could have:

LOOK at DOOR:

log(LOG_LEVEL_INFO, "%s looked nervously at the door. He had no idea where it lead", avatarName);

USE DOOR:
log(LOG_LEVEL_INFO, "%s opened the door and moved to room %d", avatarName, roomID);

where avatarName is a variable holding the main character's name and
roomID a variable holding the id of the room where the door leads.

Check the following thread (http://www.agsforums.com/yabb/index.php?board=2;action=display;threadid=9606) for more details.

Of course, logging dialog events is a different thing altogether and as Chris pointed out, it would require a few changes to the plugin interface.

So, Mittens will be in the USA. But when will it be held? And will it be announced "officially" in the main site or as a forum sticky?

fjeronimo

Ps - I hope this hasn't been answered in the previous 9 pages of this thread, but since my connection is quite slow at the moment, I didn't really feel like checking...

Ps2 - Concerning American laws, I also hear that it's about the only country in the world (in some states at least) where you can go out at night and not get home with your clothes smelling like a tobacco factory (i.e. Bars and clubs without anybody smoking!!!!).

Yes, that would be quite interesting Chris. I might even have a few other plugin ideas that might use such an interface feature.

fjeronimo

Thanks Chris. This will come in handy.

fjeronimo

I haven't read the previous post you mentionned, but if I understand correctly, you would want to store all dialog contents and then retrieve and display them at will during gameplay. In other words, a dialog history, which could also be sorted by character, by key plot elements or by whatever sorting factor.

Something widely used in RPG games (a recent example is 'The temple of elemental evil') and more rarely in adventure games.  Is that so?

Well, it sounds like a nice idea and it shouldn't be too hard to implement, although to make it truly powerful and user-customizable it might take some time. Currently, I have a few other projects in hand (including a couple of AGS plugins), but I might give it a go later if nobody has picked it up by then...

fjeronimo

Hey Chris,

I was wondering if there is any way I can find out the equivalency between plugin interface versions and the AGS engine version?

I wanted to provide correct requirements for all my plugins and I wanted to have a table, so I can check the maximum version of the plugin API functions used  and map them to the appropriate required AGS version.

Thanks in advance,

fjeronimo

It's been my pleasure After.

Have you or anybody else tried the plugin yet? I wanted to make sure everything is working as expected...

fjeronimo

Thanks Chris. I'm glad to be back.

By the way, has anybody tried the plugin? Is it working as expected?

fjeronimo

Note - This is a cross-post. I did it because I think this might interest everybody.

Hello everybody,

It's been a long time and I'm not sure anybody remembers me. I won't dwell into details about my long absence, suffice to say I'm glad to be back and I hope to stay for a long time. Besides, I never forgot about AGS and this great community. And since it's customary for long time absentees to offer a gift, here's my contribution: A new plugin. I hope you enjoy it.

The plugin is a log writer implementation for AGS. It has been added to the AGS plugin page (http://www.agsforums.com/games.php?category=21) or you
can get it directly from my site at (http://mega.ist.utl.pt/~fjds/programming.html)

The first thing we should cover is the definition of logging. Logging is a
systematic method of recording information, usually to a storage device like
an hard drive, that should be, in our specific case:

   * Simple, requiring minimal effort to enter information.
   * Traceable, requiring minimal effort to understand.
   * Maintainable, requiring minimal effort to change information when
       a game is modified.

Logging is usually associated with debugging, which is the process of locating
and correcting errors in a computer program code. Indeed, inserting log
statements in your code is a low-tech, albeit effective, method of debugging.
However useful, debugging is far from being the only utility of logging as more
creative uses can be thought of. For instance, you could use it to keep track
of the actions of the main character and make that available during gameplay.
Or, you could use it to store vital information and statistical data. Or, to
trace the flow of normal game execution or even to form the basis of a
scripting system. It's all up to you.

Logging equips you with detailed context for game failures. On the other hand,
testing provides quality assurance and confidence in the game. Logging and
testing should not be confused. They are complementary. When logging is wisely
used, it can prove to be an essential tool.

This plugin offers a few features, commonly available in logging packages
like log4j, that help in the logging process:

   * Hierarchical level - Log statements with lower priority than
       currently active base level are ignored.
   * Buffered output - Possibility to store several log entries in memory
       before saving them to disk.
   * Formatted output - Possibility to format log entries, like
       AGS functions Display and StrFormat.
   * Enriched output - Possibility to prepend log entries with data, like
       for instance the current time and date, the logging level or a
       user-defined prefix.
   * Multiple loggers - Creates, deletes, modifies and manages a list of logger
       objects, each associated with a log file.
   * Data control - Possibility to append or overwrite existing data.
   * Flexibility - Each function has several different versions
       available, which can affect the currently active logger or one
       referenced by a supplied id or name, or even all existing loggers.
   * Control - Possibility to enable/disable any given logger.

An example of a log file might look like this (taken from the example in the readme.txt file):

---- Log Started ----
This line has no options on. Only plain text
[ 23.27.01 ] WARN -- This is a common prefix -- This same log entry will appear differently in the two loggers
[ 2003.11.08 23.27.01 ] ERROR -- This is a common prefix -- Logged by Id (log 1)
[ 2003.11.08 23.27.01 ] FATAL -- This is a common prefix -- Logged by Name (log 1)
[ 2003.11.08 23.27.01 ] INFO -- This is a common prefix -- This should appear in both logs
[ 2003.11.08 23.27.01 ] INFO -- This is a common prefix -- This should display logger 2' name('my_logger2.txt'): my_logger2.txt
[ 2003.11.08 23.27.01 ] DEBUG -- This is a common prefix -- Active logger id (should be 2): 2
[ 2003.11.08 23.27.01 ] DEBUG -- This is a common prefix -- Active logger name (should be 'my_logger2.txt'): my_logger2.txt
[ 2003.11.08 23.27.01 ] DEBUG -- This is a common prefix -- Number of used buffer lines in logger 1 (should be 2): 2
[ 2003.11.08 23.27.01 ] INFO -- This is a common prefix -- Should print value -4 (LOG_NOT_FOUND): -4
---- Log Stopped ----

For more information, be sure to check the enclosed readme.txt

Although simple in design, this plugin was by far the longest one to complete, mostly due to the sheer number of available functions (62!). Documentation was particularly "painful" (66 pages). So, any feedback/comments/criticism is more than welcome.  

fjeronimo

[Download here]

Hello everybody,

It's been a long time and I'm not sure anybody remembers me. I won't dwell into details about my long absence, suffice to say I'm glad to be back and I hope to stay for a long time. Besides, I never forgot about AGS and this great community. And since it's customary for long time absentees to offer a gift, here's my contribution: A new plugin. I hope you enjoy it.

The plugin is a log writer implementation for AGS.

Download here (Thanks Neole!)
(Mirrors wanted)

The first thing we should cover is the definition of logging. Logging is a
systematic method of recording information, usually to a storage device like
an hard drive, that should be, in our specific case:

   * Simple, requiring minimal effort to enter information.
   * Traceable, requiring minimal effort to understand.
   * Maintainable, requiring minimal effort to change information when
        a game is modified.

Logging is usually associated with debugging, which is the process of locating
and correcting errors in a computer program code. Indeed, inserting log
statements in your code is a low-tech, albeit effective, method of debugging.
However useful, debugging is far from being the only utility of logging as more
creative uses can be thought of. For instance, you could use it to keep track
of the actions of the main character and make that available during gameplay.
Or, you could use it to store vital information and statistical data. Or, to
trace the flow of normal game execution or even to form the basis of a
scripting system. It's all up to you.

Logging equips you with detailed context for game failures. On the other hand,
testing provides quality assurance and confidence in the game. Logging and
testing should not be confused. They are complementary. When logging is wisely
used, it can prove to be an essential tool.

This plugin offers a few features, commonly available in logging packages
like log4j, that help in the logging process:

   * Hierarchical level - Log statements with lower priority than
        currently active base level are ignored.
   * Buffered output - Possibility to store several log entries in memory
        before saving them to disk.
   * Formatted output - Possibility to format log entries, like
        AGS functions Display and StrFormat.
   * Enriched output - Possibility to prepend log entries with data, like
        for instance the current time and date, the logging level or a
        user-defined prefix.
   * Multiple loggers - Creates, deletes, modifies and manages a list of logger
        objects, each associated with a log file.
   * Data control - Possibility to append or overwrite existing data.
   * Flexibility - Each function has several different versions
        available, which can affect the currently active logger or one
        referenced by a supplied id or name, or even all existing loggers.
   * Control - Possibility to enable/disable any given logger.

An example of a log file might look like this (taken from the example in the readme.txt file):

---- Log Started ----
This line has no options on. Only plain text
[ 23.27.01 ] WARN -- This is a common prefix -- This same log entry will appear differently in the two loggers
[ 2003.11.08 23.27.01 ] ERROR -- This is a common prefix -- Logged by Id (log 1)
[ 2003.11.08 23.27.01 ] FATAL -- This is a common prefix -- Logged by Name (log 1)
[ 2003.11.08 23.27.01 ] INFO -- This is a common prefix -- This should appear in both logs
[ 2003.11.08 23.27.01 ] INFO -- This is a common prefix -- This should display logger 2' name('my_logger2.txt'): my_logger2.txt
[ 2003.11.08 23.27.01 ] DEBUG -- This is a common prefix -- Active logger id (should be 2): 2
[ 2003.11.08 23.27.01 ] DEBUG -- This is a common prefix -- Active logger name (should be 'my_logger2.txt'): my_logger2.txt
[ 2003.11.08 23.27.01 ] DEBUG -- This is a common prefix -- Number of used buffer lines in logger 1 (should be 2): 2
[ 2003.11.08 23.27.01 ] INFO -- This is a common prefix -- Should print value -4 (LOG_NOT_FOUND): -4
---- Log Stopped ----

For more information, be sure to check the enclosed readme.txt

Although simple in design, this plugin was by far the longest one to complete, mostly due to the sheer number of available functions (62!). Documentation was particularly "painful" (66 pages). So, any feedback/comments/criticism is more than welcome. 

Sorry for the long post

fjeronimo