Thomas Fjellstrom: You mean having a bounding area defined within the trigger? So you can turn up/down the trigger area?

That might actually work... but will the "max trigger area" be confined to a single tile, or will it be able to be as large or small as the developer wants (giving us a "hey, they're about 10 tiles away from the DO NOT PUSH destructor button! Get him!" kind of effect)?

Yeah, I would think a trigger could be any size. it is an "entity" like the rest of the object after all isn't it?

For the tiles, if nothing else, yes. I don't recall having heard him sound off in a long time though.

Why don't you do it?

Got around to my e-mails, and found this:

At j0rb, I work mostly with Web-based stuff. Recently I've been working on ASP.NET stuff, which Visual Studio is happy to debug on the local machine with a virtual server. However, some older code is ASP based and the only way we currently know of to debug is to apply changes to shared development Web servers and test that way (there are a couple of alternative approaches that I've thought of, but they each introduce extra overhead and more maintenance so they aren't really being considered right now...).

Anyway, after I learned how to use Subversion I convinced j0rb to make use of it as well. In order to avoid overwriting each others' changes on the ASP development Web servers, we've let the Subversion servers handle the process of updating the development Web servers using hook scripts. Unfortunately, this means that every little change to the code that you want to test "requires" a check-in to the Subversion repository. As you can imagine, for the most simple fixes this is easily 3 to 5 revisions. For complicated changes; tens or hundreds. The repository has quickly grown into many thousands of revisions. As you can imagine, my coworkers aren't very keen on documenting every little change with a detailed message (understandably).

As a result, a lot of the value in version control is lost. The logs are mostly useless and attempting to track certain changes takes forever. So when I work on that code I typically just manually copy my files to the appropriate development Web server, bypassing the Subversion repository until I'm satisfied with the changes, and then commit after I'm satisfied. There is a chance that I could overwrite my colleagues' updates on the development servers, but that is something that we've lived with until recently anyway and both their working copy and the repository have copies of their changes. I figure preserving the repository is more valuable than preventing the occasional, rare collision between developers (which is usually noticed pretty quickly when things don't work as expected).

My coworkers don't see it that way so the logs are essentially 100 generic messages (or an empty message), followed by a detailed message or two by me, followed by another 100 generic messages...

Well, many of the commits haven't been logged very well, but I know it can be hard (especially without design documentation to work from). I was more or less just ranting about work, but it was triggered by the many successive revisions you just made, many of which I'm assuming were probably unnecessary...

Actually, yes, I take it back. OnlineCop, you seem to be doing a great job logging your commits. At least those recent ones.

Does this mean that the SVN is current a-ok and everything compiles fine, or an accusation that "I dun broked sumthin'?"

I felt it was important to get things functional enough that we can start making large enough maps to know what is needed. Even with the multiple TODO lists, known "what's needed next" is easier when I can see "oh that's not working... I should fix/work on that".

Team Leaders, read the todo lists and start assigning stuff to your delegates.

According to the original post, we have several people working on a multitude of portions of this game.

Have either of these been updated recently?

How is this coming?

How is this coming?

Meow.

I really like all the stuff you've been doing lately. What else are you working on? Anything I (or we) can help with?

I'm really interested in this. How's progress? Is it slow-going or actually moving along quite well? What can we do to help?

Are you still up to some programming? Do you have anything you'd like to work on? Need help with anything?

If we could get OpenGL fonts, and you know how to do/implement them, that would be really cool.

Leaders: Do we know what kinds of sounds we will need at this stage of development? Should we get even a basic framework with a few really repetitive and script-based sounds going on? What can decepto work on at this stage?

Leaders: Ditto.

Are you still following this ever-lengthening thread? Still wanting to help? Need anything to do, work on, start on, finish up, clean up, or debug?

Speak to me.

MANY thanks for the continued access we have to this. It's been great to have such a good place to work on and collaborate our code. Still much appreciated.

We still go in and flesh out ideas, implementation ideas, etc. in #allegro-monday on occasion, so if anyone wants to go in and poke each others' brains, I'm sure the zombies won't mind. (Mmm, brains...)

...which is why we keep on reviving this old thread in hopes to generate a lot of chatter (even if idle chatter)

Besides the storyline ideas and whatnot on the monday pages, do we have some specific things we can start looking at?

Something like:

1. The first scene will have a scripted dialogue between two NPCs and Monday (the main character [name still WIP]).

2. After the dialogue, the player will walk from the current map to an adjacent map that contains ____.

3. The player will need to pick up several items from this room, including (and especially) the ____. You can't progress until you pick up that item (and use it somewhere).

I think that we need to delegate someone to start scripting up "the whole game" in great detail. Then, after the details are hammered out (yes, that means that everyone and their dog will see the spoiler and all cheats, hidden items, bugs), we can all start working on the different parts that need to be done.

As it is, I'm personally scratching my head and not entirely sure WHAT to work on, because I don't know who needs which "piece" of this before they can start on their own project portions for Monday.

Anyone up for some creative brainstorming and fleshing out the game so we can see what art/music/scripts/maps/etc. we need?

ATM, it's slow going. I'm still trying to wrap my head around binding Lua to C and C++. I kind of got distracted and took a break from it. Hopefully with a 4-day weekend I can find time to get back into it.

#lua on irc.freenode.net showed me a couple of handy wrappers used for binding C++ to Lua in what looks like a much more dynamic and reusable way than manually doing it. I only glanced at them so I could have this wrong, but I think there are two available wrappers (the second of which may be a revised version of the first): luna and lunar; which appear to be user-submitted wrappers around the Lua binding code (I'm not sure yet about licensing or really anything, including how useful they really are, but they look better than what I'll end up with anyway...). I think I'd prefer to learn to do it without those wrappers first and then look into using them for Monday if they seem like a cleaner approach. It should help me to understand what's happening.

I did a little looking into the Lua C API code in Monday, but didn't really look thoroughly and didn't really see where the real magic was happening. So I don't know if something already exists for this. I basically have been working on a small test program binding a simple Person class (with name and age properties, whose only access is through accessor methods) to Lua. From what I did see of the Lua binding in Monday it looks a bit like everything is done the C way (that is to say with stand alone functions instead of object-oriented/methods). If that's the direction we want to go we can, but it should be completely possible to wrap a C++ object into a Lua "object" that behaves very friendly. For example (AFAICT, --[ and ]-- delimit a "long"/block comment in Lua, but it's been a while since I've actually written any)...

--[
    Create a new "Dragon" instance (I'm using Dragon as an example entity because I
    don't know what entities actually exist in Monday...). This would create an
    actual instance of the Dragon class in the host application (i.e. Monday). The
    pointer to the created object would be returned to Lua and stored on the dragon
    table as [light]userdata.
]--
dragon = Dragon();

--[
    Even though this looks like simple property assignment, it is actually going to
    be calling an accessor method in the host application. The dragon Lua table
    won't actually have a "Name" property (i.e., index). Rather, it will interface
    with C++ using metatables and metamethods and traditional Lua binding routines
    (i.e., I think the __newindex metamethod).
]--
dragon.Name = "Puff";

--[
    The dragon Lua table wouldn't have a function indexed at "MoveTo" either. This
    too would be calling a C++ method on an existing object. Of course, this API is
    just being pulled from thin air since I don't know how things are being done
    in Monday.
]--
dragon.MoveTo(102, 820);

--[
    This would destroy the Lua table (eventually), assuming no other references
    exist. I'm not yet sure how or if we can manage host memory when it comes to
    garbage collection. In other words, should this, and can this, destroy the host
    object as well; or should it just clean up the Lua wrapper and leave the host
    engine to handle destruction of the underlying object?
]--
dragon = nil;

Anyway, that is an example of what I'm thinking... It would help me get caught up if whoever has been in charge of the Lua bindings so far tells me what's been done so far and where. And feedback on my plans and what your plans are would help too so we're on the same page and working towards the same goals. Obviously since I'm testing this out on a simple project I haven't made any progress yet to Monday.

I would like to do some work with this, but I can't get it to compile (some problems with my libstdc++). Maybe I'll reinstall. Of course, last time I did that I bricked my system.

I would say before trying anything drastic you should post whatever errors you are getting.