Messages

We are now back home.

Mittens was great fun, and it helped a lot that the weather was so lovely throughout the entire week
Meeting familiar faces was great, meeting new people was also great!
New Orleans itself was a real blast, I actually got to ask a voodoo guide "What do you know about gris gris?" which was probably my personal adventure related highlight of the week.
Also, just as an fyi to those who left early, I got to eat a beignet on the very last day, hooray!

Stealing from Grundislav, I would also like to thank all mitteneers for the planning, driving and entertaining.

Mills, indeed I was a spy a lot during the week, but you'd be happy to know that during the weekend IT BROKEN and now Kayla is the undisputed spy.
As for the iphone, I can confirm it is indeed Quintaros's. I believe he "accidentally forgot" it in your car as part of the oldest trick in the book.

I find fishing immoral, but then again, I find most forms of animal exploiting to be immoral.
My (simplified) point of view:
If you can avoid killing/hurting/exploiting an animal without killing/hurting yourself or others (and without too much self sacrifice), you should.
So with that:
Fishing/hunting for sports- no excuse.
Fishing/hunting for food- since most people can live a healthy life without animal based foods (unless you have a specific medical condition), assuming it's convenient enough to live on plant foods in the area in which you live (a lot of cities today are vegan friendly, and while most cities are still not vegan friendly, there is an improvement all around) there's no moral justification for this.

However, I do find fishing or hunting (for food) much preferable to buying from the meat/dairy/egg industries, as the amount of harm you cause is not even close to the suffering an average animal goes on one of those industries (or to the amount of slaughtered animals: http://www.adaptt.org/killcounter.html). I would recommend seeing the movie Earthlings (http://earthlings.com/?page_id=32) for anybody who wants to learn more on that (warning: it's a hard movie to watch).

Now as for games: I don't have a problem with a game where a character kills another animal (I'm including a human being in "animal") if it serves a purpose which is not glorifying the killing.

Thanks guys
And happy belated Edmundito!

Code: ags

SetTimer(my_timer_id, 0);

From the manual:
"Pass TIMEOUT as 0 to disable a currently running timer."

I suggest that "Build -> Run game setup..." will run the windows* setup, but additionally we'll have another option "Build --> Run game setup for... --> Windows, Linux, etc".

* Maybe both the "Run game setup..." and running the debugger should use the appropriate setup based on the running OS, so if we ever manage to support AGS editor on other platforms this would work automatically.

I sympathize in more than one way.
I don't want to make personal suggestions, your post feels more like blowing off steam than asking for advice, but on a practical level,
at least the bit about the stress you feel when making changes, this is something probably shared by all who touched the code.
A possible (albeit partial) solution for that would be to have a set of unit tests, which would give developers more confidence that they're not breaking anything.
Of course this would be a massive undertaking and will require maintenance of its own, and will probably take a lot of time until it bears some fruit,
so maybe we're better off staying at this junction, stressed out and overwhelmed.

Me & Noa are in for New Orleans.

How the hell did you manage to all this in one month?!?
Incredible!
And looks super polished.

[commit]

The NativeDll.sln and the binaries were added by mistake, they will not be a part of the actual commit.

Regarding the commit structure, I agree completely. It's a little late for this commit, but I'll do this for future commits.

In my experience, once I actually commit a renamed file (and git permanently tracks that particular change), then git should be able to detect that the file is 95% the same (or what-have-you) just with a different name, and it can properly track it as a rename. I used a git repo for my final project at school, and this was the behavior that I observed.

Well, it is committed though, isn't it? It's committed to my personal repository, so it is tracked by git and should exhibit the same behavior, or am I wrong?
Anyway the files were not only renamed, but moved to a different folder, so maybe that's why it didn't detect that it's the same file.

[Scroll bars:]

Scroll bars:
That's a no-go I'm afraid. Since Windows forms components acts as containers that are sent out to Windows to deal with. Windows will receive those components and wrap its stuff around them, including scroll bars, I have no control of that one and it annoys me endlessly.

you can use a custom scrollbar to replace the default one.

Going back to the original dilemma: I saw two let's plays of 9 months in where the the players seemed unaware they can right click to look. They missed vital clues and it was very frustrating to watch.
Now, those were experienced gamers, mind you (maybe not adventure gamers, but still quite shocking)!
Switching the button scheme won't help because those same people will still fail to left click and get stuck quite early in the game. Plus this will annoy a lot of adventure gamers (me included, and I never got used to this scheme in BASS, otherwise a great game).

A tutorial is an option, but if it's mandatory it will annoy the existing adventure gamers (again, me included) who just want to start playing, and if it's optional a lot of newbies will skip it, not knowing what's good for them.

So, my attempted solution for THAT DAMN DOG was this:  start a timer at the start of your game. If the player doesn't right click within a few minutes then (and only then) show a "did you know you can also right click, you dumbass?" (Not exact phrasing), or some more extended tutorial.
Did it work? I have no idea...

Ooh, neat trick!

This can work nicely as a plugin:
Right clicking a script will give you the option to make it into a "common" script which will create the link to a predefined folder.
Right clicking a "common" script will give you the option to make into a normal script which will destroy the link (cause sometimes you want to break out of the mold and have some special hack in your script).
And also an option to "Import common script" which will scan the predefined folder and give you all the common scripts that are located within to choose from.
And finally (optional?) a deploy button that will copy all the used common scripts with the game files to the deployed folder.

Thanks, visionmind.

I don't think I will have anything to say regarding C# code, I am rather worried about overall commit contents.

If it helps, a lot of the changes are because I moved files to a different folder, and it seems that git doesn't know how to compare these changes, so it shows it as one deleted file and one added file (quite surprising actually, in TFS it knows to tag it as a "file rename" and shows the file differences as expected).

Tzachs, is there a source code somewhere, just in case?

Source code is here:
https://github.com/tzachshabtay/ags/commit/45010f27e6b66ecf92c30787fb7d07ed6b636946

visionmind, was Crimson Wizard's suggestion helpful?

There's a limit of 256 areas imposed by the 8-bitness of the area mask in AGS.

Thanks, fixed the description.

Tzachs, is there a source code somewhere, just in case?

Well, I was planning to commit once I see there aren't any critical issues.
If you're waiting for it though, I can commit now, let me know.

[The features:]

WARNING: This is an experimental version.
DO NOT USE IT FOR ACTUAL PRODUCTION OF YOUR GAME.
If you do use it, at least BACKUP YOUR PROJECT first.

Download here

This is an experimental version with some new features, which I need help testing.

The features:

- No Limits (almost)

This feature (developed by Crimson Wizard) enables you to use walkable areas/walk-behinds/hotspots/regions
up to a limit of 256 (imposed by the 8-bitness of the area mask in AGS).
To accomodate this feature, there were UI changes that had to be made, and these are integrated in the new
room layers UI.

- Room Layers

This feature allows you to view (and edit) walkable areas/walk-behinds/hotspots/regions/characters/objects/edges
in the same time (as opposed to only seeing one of them at a time, like we've seen before).
Well, not entirely though: walkable areas/walk-behinds/hotspots/regions still can't be seen together (as
they use masks and is part of the natives dll so I skipped it for now) but they can be seen along objects, characters,
and edges.

- Visibility

Each layer can be made visible/hidden by the push of a button.
In addition, for the objects/characters/edges layers each item in the layer can also be made visible/hidden by the push of a button.
This will only affect the editor, not the actual game.

- Locking

Each layer can be locked/unlocked by the push of a button.
In addition, for each layer, each item in the layer can also be locked/unlocked by the push of a button.
A locked item cannot be moved until it is unlocked, useful to prevent mistakes when designing the room.
This will only affect the editor, not the actual game.


How to use these features:

All those goodies can now be accessed from the layers navigation bar, seen here:



The navigation bar is a breadcrumbs control and should be familiar to whoever uses Windows Explorer (from Vista onwards) or Mac Finder.
Selecting the arrow next to the "Room" label will open a drop down with all the layers.
Each one of the layers has two buttons, a lock/unlock button and a show/hide button (the "eye" image).
In the image above, the characters, objects and hotspots are visible, and the characters are also locked.


Another example, here the walkable areas and characters are visible, and the characters are also locked.

Selecting one of the layers will add it to the navigation bar, and then clicking the arrow next to the layer
will show all the items in the layer.


For example in the image above we selected the objects layer which showed us all the objects.
We can see that the piano object is hidden even though the objects layer is visible. Also,
a few of the objects are locked meaning we can't actually select and move them.

Here's an example of when selecting one of the "masked" layers:


Here we selected the hotspots layer which showed us all of the hotspots. While we can't show/hide
specific hotspots, we can lock/unlock them.
Also the last button in the drop down is "Add New..." which allows us to add more hotspots (with no limits!).
There's also a delete button appearing on the last item (hBone in this example) allowing us to delete it.


Additional points of interest:

- Selecting a layer automatically makes it visible (though it can still be hidden after selection).
- Setting one of the "masked" layers to be visible will automatically hide the rest of the "masked" layers.
- The list box in the properties pane is now redundant as we can select the items from the navigation bar. I've kept it for now, but maybe it should be removed in future versions.
- The images were drawn by me. If anybody wants to create better images, here's what required:
Eye open, eye closed, lock open, lock closed and delete. The images should be 15x15 (png with transparency).
- For the "masked" layers, we only allow to delete the last item. Allowing to delete one of the items in the middle is a problem since we
don't want to change the IDs of the items (they can be used by the game developers).
- A possible enhancement in the future is to add drag & drop support to allow changing the ordering of the layers (and have walkable areas to appear
in front of characters, for example).
- Since the navigation bar is basically a horizontal representation of a tree, it will theoretically allow us to develop a feature that will allow
us to "group" multiple items (can be useful for example, to create composite objects).

All feedback will be appreciated.

Have a happy one, Baron!
And a happy belated birthday to you too, Ponch!

Yes, you can load assemblies in runtime with reflection. See here:
http://msdn.microsoft.com/en-us/library/system.reflection.assembly.load(v=vs.110).aspx
I haven't looked, but I assume this is how the plugin framework works.

I don't mind having extra assemblies myself, but loading the assemblies in runtime can give you another theoretical benefit: the ability to provide a generalized solution that other devs could plug into with all kinds of special deployers.
This would work like this: you provide a new Deployer interface and put it in Ags.Types. The interface would have whatever needed to deploy a game. For example, it could have a Deploy method, a IsSupportedOnCurrentPlatform property, a DisplayName property and a GetSettings method that will allow each deployer to provide platform unique settings which the editor could then show a UI for.

The deployer developer will reference the Types dll and implement the interface. It's similar to how the current plugin framework works. AGS will search in a specific folder for all assemblies that contain an implementation to the interface and put them all in a nice deploy menu.

It's just a random thought, it could be cool but I'm not sure it's worth the effort as opposed to simply tailoring a specific solution to every platform.

Awesomeness!
I suggest using this new "Point & Clip" (tm) technology in all of your future videos.