sprockets Learn to keyframe animate chains of bones. Gerald's 2024 Advent Calendar! The Snowman is coming! Realistic head model by Dan Skelton Vintage character and mo-cap animation by Joe Williamsen Character animation exercise by Steve Shelton an Animated Puppet Parody by Mark R. Largent Sprite Explosion Effect with PRJ included from johnL3D
sprockets
Recent Posts | Unread Content
Jump to content
Hash, Inc. - Animation:Master

Recommended Posts

  • Admin
Posted

Here are some examples of the additional customization Steffen has programmed into the A:M Community window as of v17Alpha5.

In order to use this feature the user simply adds a customized HTML file named 'Support.html' into the v17 directory.

The capability enabled here is primarily to supply a localized interface or menu within the A:M Community screenspace.

Local administrators, companies, schools and even individual users can then push information utilities to that menu.

Based on their interests or needs some optimized files could be supplied to them.

 

Example 1: Holmes's A:M Properties tiddlywiki

Note that there are some obstacles to overcome if we are to interact with HTML inside of A:M Community.

For instance, input of certain keys are intercepted as we type them by A:M's shortcuts which prevents us from using those letters in searches and editing within the tiddlywiki but... the information is there! A quick workaround to this is simply to open the window in a browser outside of A:M.

 

Example 2: Browsing the A:M Lofi and Hifi Forums

In this case we are looking through Holmes Byrant's Tutorials

 

Example 3: A:M Extras models on view.

 

Example 4: Drawing in the A:M Community window

Paint Program used: Sumopaint was selected in this case because it works well and offers good use of layering and transparency which is valuable in texturing and decaling. Note: Adobe Flash had to update to current drivers prior to opening the paint program. It took about 5 minutes from initial idea of linking the program in to painting into the community window with 3 or 4 minutes of that for the Adobe update. Normal operation with everything update to date should be instantaneous to approx 1 minute.

 

Example 5: Viewing TaoA:M Exercise 1

Note that because the HTML page doesn't auto-resize we don't see all of the screen at the same time. Something to think about when creating pages to view in the community. Viewing videos in the community window is mostly optimal for smaller videos... but larger videos could be launched via a link into a full browser window (which BTW just happens to be the default for clicked links in the Support tab). If we want to keep the link in the current window we need to specify that via the 'target=' tag after the link.

 

This may be a good time to consider how the A:M FAQ/wiki, the revised TaoA:M and such can also be linked in via the localized support tab.

When combined with the new A:M Answers and some of the older features rarely used v17 looks to be highly customizable.

SupportTab.png

BrowsingtheLofi_Hifi__Holmes_Bryant_Tutorials_.png

AMExtras.png

SumoPaintingInAM.png

TaoAM__But_not_optimally_sized__in_AM_Community_Window.png

  • 2 weeks later...
  • Replies 7
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Posted

Here is a nice "Support.html"-file you may like. It is meant to give you inspiration while working on 3d projects.

It will displayed randomly 6 of the best images created with A:M in your Support-Tab of the Community-window.

 

Hope you like it!

To install, just copy the file "Support.html" to your local Animation:Master v17 installation folder.

 

See you

*Fuchur*

Support.html

  • Admin
Posted

That demonstrates the Support tab's utility perfectly.

A quick right click and refresh and we've got a new set of images to view.

Great work Fuchur!

 

As long as these custom support.html files display in the Support tab we may want to make it standard practice a link to the official (online) A:M Support page to added? While we can't force anyone to add these two links, it is the only way I know to maintain the support focus of the tab. As such I think it's important.

 

Under current usage A:M looks into the A:M Directory and sees:

 

A:M will display the default Hash Inc support linking page ( http://www.hash.com/community/Support/Support.htm ) in the A:M Community Support tab

This default html file provides a link to the Hash Inc website support page: http://www.hash.com/?pcode=support_contact

 

A:M will display the contents of this local html file in the Support tab

It can then link the other files as dictated by its publisher

 

The Support tab cannot see any html files that are not linked via the Support.html.

It is assumed A:M's local data folder (v17.0\Data\) is where standard project files, TaoA:M resources and other content is installed is optimal.

Users (and content providers) will need to be able to rely on a location that doesn't change easily.

 

Support Tab Style Guideline 01 Proposal:

Where possible content creators of Support.html pages should include two default links in their custom Support page (preferred location at the top):

 

1. Link to Hash Inc Support page: http://www.hash.com/?pcode=support_contact

2. Link to a standardized "Publishing" directory where shared html files are located (User Collection)

 

What do you say Fuchur?

When we are dealing with only one support page it's a fairly trivial matter.

Its when everyone creates and shares their own custom pages that a little (two link) standardization may become important.

 

You are officially my favorite support tab content provider.

As of today, your new support page is my default!

 

Edit: Corrected bad links!

  • Admin
Posted

Perhaps someone can set me right about the difference between use of '.htm' versus '.html'.

There doesn't seem to be any specific usage preference and depending on the link knowing which one to use can be frustratingly hit or miss.

 

I could wish that local files were .html and online files were .htm

While the rest of the world might not pay any attention perhaps that might be Style Guideline Proposal 02. ;)

 

Any thoughts on that?

 

 

Added: I should note that I do understand the history of the differences and that .htm is preferred to maintain compatibility with the older 3 character extensions. What I don't grok is why some tend to use them interchangeably when that makes it considerably easier to accidentally break an otherwise valid link. The difference means that the link can be broken in two ways either at the hyperlink reference or at the filename (a useful swtich to be aware of if you want a simple way a little control of access to information via hyperlinking). Perhaps in a perfect world all browsers would first test to see if there is an .htm version of the file and if not look for a .html version. Failing to find either would launch the 404 page. Standardizing .htm as online and .html as offline would be useful in that we'd gain the ability to switch files on/off by simply changing, or adding/deleting, the last letter in the extension. The browser would automatically know if the file was suppose to be online or offline even if it sees that it exists. So, while the .htm file is ready for dispaly the .html file (while still viewable) is simply waiting in the wings. Sorry... this is a 15 year old itch. ;)

Posted
Perhaps someone can set me right about the difference between use of '.htm' versus '.html'.

There doesn't seem to be any specific usage preference and depending on the link knowing which one to use can be frustratingly hit or miss.

 

I could wish that local files were .html and online files were .htm

While the rest of the world might not pay any attention perhaps that might be Style Guideline Proposal 02. ;)

 

Any thoughts on that?

 

 

Added: I should note that I do understand the history of the differences and that .htm is preferred to maintain compatibility with the older 3 character extensions. What I don't grok is why some tend to use them interchangeably when that makes it considerably easier to accidentally break an otherwise valid link. The difference means that the link can be broken in two ways either at the hyperlink reference or at the filename (a useful swtich to be aware of if you want a simple way a little control of access to information via hyperlinking). Perhaps in a perfect world all browsers would first test to see if there is an .htm version of the file and if not look for a .html version. Failing to find either would launch the 404 page. Standardizing .htm as online and .html as offline would be useful in that we'd gain the ability to switch files on/off by simply changing, or adding/deleting, the last letter in the extension. The browser would automatically know if the file was suppose to be online or offline even if it sees that it exists. So, while the .htm file is ready for dispaly the .html file (while still viewable) is simply waiting in the wings. Sorry... this is a 15 year old itch. ;)

 

The only reason there is the *.htm or the *.html-extension is the 8+3-notation / Camal-notation available but it would be bad practice to use them in a different way.

One of the reasons would be that Windows does not show the extension by default for users but the icon would be the same. Like that you could not see the difference on a windows-filesystem without changing that.

The other one is, that what is prefered is a webserversetting. Many webservers will favour the index.html over the index.htm-file and only use index.htm only if index.html is not available. After that it will be checked if there is a index.php but this is really only a setting which can be changed and is very different on different machines.

 

The best is, to just let the webserver determine which file should be shown. So don't use "http://xyz.com/index.htm" as the link but "http://xyz.com". The webserver will guide you where you need to go.

 

I for myself prefer the *.htm over *.html because I just like to stay compatible to as many systems as possible. I think the x+y-notation (in difference to x+3) is only a game or only really useful when there are so many file-extensions are involved that 3-letters are just not longer enough. Anyway: The most compatible format is x+3 or even 8+3 and like that I reccomend to use that.

 

See you

*Fuchur*

Posted
That demonstrates the Support tab's utility perfectly.

A quick right click and refresh and we've got a new set of images to view.

Great work Fuchur!

 

As long as these custom support.html files display in the Support tab we may want to make it standard practice a link to the official (online) A:M Support page to added? While we can't force anyone to add these two links, it is the only way I know to maintain the support focus of the tab. As such I think it's important.

 

Under current usage A:M looks into the A:M Directory and sees:

 

A:M will display the default Hash Inc support linking page ( http://www.hash.com/community/Support/Support.htm ) in the A:M Community Support tab

This default html file provides a link to the Hash Inc website support page: http://www.hash.com/?pcode=support_contact

 

A:M will display the contents of this local html file in the Support tab

It can then link the other files as dictated by its publisher

 

The Support tab cannot see any html files that are not linked via the Support.html.

It is assumed A:M's local data folder (v17.0\Data\) is where standard project files, TaoA:M resources and other content is installed is optimal.

Users (and content providers) will need to be able to rely on a location that doesn't change easily.

 

Support Tab Style Guideline 01 Proposal:

Where possible content creators of Support.html pages should include two default links in their custom Support page (preferred location at the top):

 

1. Link to Hash Inc Support page: http://www.hash.com/?pcode=support_contact

2. Link to a standardized "Publishing" directory where shared html files are located (User Collection)

 

What do you say Fuchur?

When we are dealing with only one support page it's a fairly trivial matter.

Its when everyone creates and shares their own custom pages that a little (two link) standardization may become important.

 

You are officially my favorite support tab content provider.

As of today, your new support page is my default!

 

Edit: Corrected bad links!

 

That is a good idea :).

I am with you on that and integrated it into my page. (no action necessary on your side)

For now I added the link to this discussion and if A:M v17 is officially release we will have to change that to the openly available forum-board for that.

(I would add a own board where people can share what they created on the forums here)

 

There is now a button to change the images if you want to.

 

See you

*Fuchur*

  • Admin
Posted

That's a great update to the page. Perfection. (Although 'Update Images' might be even more self explanatory)

I like your support page as it is right now that I'm tempted to always leave it that way. :)

 

 

More stray thoughts about html usage (enter at own risk):

One of the reasons I want to lock down my own use of the .htm extension is that I've set the default URL in my user settings in A:M to "info.htm" (presumably some people put in a personal website but I've rarely seen one that links anywhere). Setting the URL to 'info.htm in my settings means that every Project, Model, Action etc. I automatically has an associated link to a html file in the same folder as the asset. When the link is clicked *and if* an accompanying file named "info.htm" actually exists in the same folder, the info.htm file opens in a browser to display information about that assets.

 

Note that I am not saying I actually use the File Info URL all the time in this way, only that I have had it set up that way for years. It was a byproduct of trying to figure out a good way to store file information/credits on the Extra DVD. The menu for that was originally going to be a tiddlywiki file that could be edited by the user. The idea was premature and was jettisoned without explanation prior to the DVD going to press.

 

The theory here is that every file created should have some documentation in some form or fashion and that is pretty easy to do by creating a file and dropping it into the folder with the asset. That file can then either be opened by clicking on the file itself or by clicking on the URL link inside A:M.

 

Note that this 'user customization' of the URL further compliments AMA by allowing documentation of files that are outside of the scope of AMA's property documentation. (Almost) every A:M file ever created has this URL assigned to it via File Properties. It just usually isn't used in that way.

 

Now, I'm off to test the ability to enter keystrokes into the Support tab window! :)

  • Admin
Posted

Okay, this definitely looks promising.

 

I had completely forgot that back in 2006 or so I had set up a Box.net account (probably for use with the Extra DVD).

Shared files in the A:M Community might be worth looking into.

 

Even if not used in the A:M Community window I could see A:M Exchange gravitating toward something like this.

Keeping it non-commerical is important though unless someone wants to pay $ for it.

 

We could probably just do a standard html FTP thing but this does demonstrate the capability of using Box.net and similar services in the Support window.

 

It should be a bit sobering to understand that we've been able to do stuff like this in A:M since v9.

The rest of the world just had to catch up.

boxnet.png

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...