These were just transfers straight from the old Forge. The main reason there are no Behaviors attached currently was that we needed to verify that all the featured Behaviors that would be attached to actors would actually work. Given the number of Behaviors that needed overhauling, I didn't want to have a bunch of actors with broken Behaviors in them.

That said, I think we're now in a good space to set up featured actors appropriately.

The reason why actors currently don't have behaviors is because it's common to pull an actor down for the graphic itself. If actors all had behaviors (in the current system, speaking), we'd run into problems if Actor A had behavior A, and Actor B also had behavior A. You'd suddenly end up with duplicates of that behavior. Ceric also brings up the issue of maintaining behaviors.

The solution in the future is clear - there should be a way to lightly link a resource to another without physically bundling it in (and make that optional to download), but that is not the case today.

One light solution to the problem is to add a visual tag to actors that do come with behaviors like you did for featured games.

I don't know of too many games that use any of the actor graphics that are on Forge, unless people are using them as placeholder graphics. If I want a cannon in my game, I'd much rather download a cannon actor with a cannon behavior than download a cannon actor with no behaviors, then search for a cannon behavior to download and attach to the cannon. A user is probably going to replace the graphics with something original anyway.

This is one situation that comes to mind. You're using the jump and run kit, and want to download a new player Actor. If that player Actor on Forge was bundled with all the jump & run behaviors, when you downloaded it you'd have duplicates of everything.

So I can see both ways. Normally I like to already have my behaviors in place before downloading an Actor - but that's mostly because I like to have more control over what behaviors are in my game.

We should selectively bundle behaviors on key actors and mark actors that bundle behaviors as such.

Long term (starting in Forge 2), we should do the "right" thing, which is to bundle but allow the user to opt out (the same argument can be made for resource packs). The problem with doing the "right" thing today is that the drawbacks outweigh the benefits at the moment.

(On another note, we should nix the Mario actor. That definitely should't be there.)

I like how with things like uTorrent you can look "inside" the file your downloading and check/uncheck specific items in there to download or not. It definitely speeds up the time frame if you're only looking for one specific piece, not to mention you don't get what you don't want.

::

Patience is a Virtue,But Haste is my Life.

Proud member of the League of Idiotic Stencylers; doing things in Stencyl that probably shouldn't be done.

I like how with things like uTorrent you can look "inside" the file your downloading and check/uncheck specific items in there to download or not. It definitely speeds up the time frame if you're only looking for one specific piece, not to mention you don't get what you don't want.

That's a pretty good idea, I like that system too. On the reverse side, which may be technically challenging, it would be nice to have the option to re-upload selected items to an existing pack. Say I have a "movement" resource pack, and I find that I need to make a change to one of the behaviors. Being able to "insert" just that one behavior back into my pack that's on Forge would be cool, instead of reuploading the whole pack.

I like how with things like uTorrent you can look "inside" the file your downloading and check/uncheck specific items in there to download or not. It definitely speeds up the time frame if you're only looking for one specific piece, not to mention you don't get what you don't want.

I actually have the UI for this one mocked up and did it yesterday. I think it's possible to do in a second pass of Forge (first pass, I want to get through rather quickly to deliver those benefits before we start looking at other stuff).

I've also added Greg's part to the roadmap since I think it has merit.

The idea that might work with regards to packs in general is to shift some of the burden online, which will allow packs and other composite resources to "link" to other resources. This will eliminate duplication of resources, for one thing.