Community
Community Affairs => Forum Support and Suggestions => Topic started by: gumby on November 28, 2010, 04:08:41 PM
-
I'm thinking this section on the Tutorials page needs some love. Looks like it's chronological, but I'm thinking it either needs categorization or alphabetizing or both. What do you guys think?
-
Ordering them in categories makes the most sense. It might be best laid out on a regular web page with screenshots, etc. where appropriate rather than the forum. It would make it easier to add cross referencing, hot links, definitions and the like. I could take a look at that. If there is not enough space/bandwidth here, I could host it on SHP.
-
I agree, it's not a long term solution as is. In the beginning, the idea was that the newest ones up top because you've seen all of the old ones bunches of times. So ideally it would be nice to pull out some of the how to's and stick them in with the regular tutorials. I appear to have an afinity for writing long code over the last few days I could just hardcode the link in the tutorials list. I would like to see Brian's first tutorial stay as is, combine the how tos and brian and troflips with a little rewriting to make it flow like the first as far as building a single game. And then obviously a third branch for point and click. But not everything I don't think would need a spot in the tutorials list. I guess too, we need some sort of standard format... maybe not though.
-
I have started to work on something from the How Tos from here. I have copied the theme from the boards here to a CSS file. I'll make a single page from each thread, keeping credits for each. They can be linked on an index page and arranged from there. I'll then go through them to see what may be good to cross reference and add any appropriate extras. When I get enough to show, I'll upload it to the SHP sever so you can see it and give feed back.
PS, If you would rather I not do it, let me know before I get too far into it.
-
So what happens to the how to threads after they've been converted for tutorial page. presumebly we wouldn't need them, but it would suck to drop them because right now they can be found with a forum search. Also we lose the immediate ability to update the tutorials. for instance if Brandon figures out how to automatically parse for synonyms as part of a complex noun string so instead of just adding a new post, he would need to start a new thread which would then need to be added to tutorial. I'm afraid once we start handling them by hand we may have to handle them alot. a solution that works with smf would be better I think than seperating them. but then again, I'm not positive I have what you're talking about pictured correctly so I dunno...
-
Even if the forum how-to's are converted, there should be no reason to remove the forums version. It is handy for conversation.
-
Yes, leave them. Some may need to ask for clarification or want to contribute further. Perhaps the original post of each thread could be edited to add the URL to the new page and the new page would have a link back to the original thread. That way someone using the static pages could immediately go to the thread if they had a question or wanted to add to it. The main reason to duplicate the threads on a static page is for the extra capabilities that you can do outside of the limitations of the forum software, but keeping the thread too allows for feedback.
-
Well, really it sounds like we are setting ourselves up for a lot of coding. I am almost convinced that it would be easier to transpose our current html tutorials into the forums, then more people: admins, maybe a scholar membergroup, or whatever, who could then be able to edit all of the then tutorial posts, new how-to's and converted tutorials adding cross-references and whatnot. I really don't see that being too big of a problem then hardcoding the tutorials list, and then just using the texts of the posts to display, stripping out all of the other "forum stuff"
I think that would be better long term solution. Really we just need a format for everyone to follow or editors can manipulate it to that would make the transition from forum post to webpage content easier..
-
I have developed a template to match the site, here. At this point I am just copying over the threads into the template before trying to rearrange/edit anything. It should go pretty fast, now that I have a template.
http://sierrahelp.com/SCI/Index.htm
I have the last 6 copied over. I have found a problem. The generic Keypad class thread had the code in an attachment that is missing.
Edit: The CSS and the pages themselves should validate.
-
A Wiki is another possible solution. I setup a trial Wiki with one of the How Tos entered.
http://sierrahelp.com/SCI/Wiki/index.php?title=Determining_location_of_mouse_cursor
This was a simple copy and paste. As you can see, it fails to include all of the script inside of the pre tags, but I am not going to invest much time into sorting this out if no one wants to go this route. It would make for an easier collaborative effort and easy editing.
Edit, By placing a space before the leading code line and the final closing parenthesis the Wiki included all of the code.
-
A Wiki. That's perfect. That's what we need here.
-
The solution to the code is that the Wiki accepts the HTML pre tags, but is not in the tool bar. I am plugging in the How tos now. Should we salvage the old Free SCI info, too?
-
I have all of the How tos entered
http://sierrahelp.com/SCI/Wiki/index.php?title=How_To
-
Should we salvage the old Free SCI info, too?
I vote yes. I know that I refer to it regularly. Its got great technical information on it.
-
I don't know what Cloudee has in mind, but I believe that the resources here are somewhat limited. I don't mind hosting the Wiki. I don't want to step on any toes, but if this is alright with him, others can start to contribute. Gumby, you might be more familiar with what is on SCI info that should be salvaged and what is good info for development. Feel free to add anything you think should be there.
-
Gumby, you might be more familiar with what is on SCI info that should be salvaged and what is good info for development. Feel free to add anything you think should be there.
It seems to all be relevant, I'd vote to just add it all. I'm not sure how to proceed, however. It looks to be about 50+ pages, indexed & linked together (previous/next). The good news is that it can be copied without violating the copyright.
I guess we could just make a new separate 'how-to' section and throw it in there. For anyone interested, go to http://freesci.linuxgames.com/scihtml/book1.html to see the table of contents (it's pretty lengthy).
Thoughts?
-
We can probably dump the section on Free SCI. The rest can be added as is into, perhaps an SCI specification section? After that, anything in it can be copied/modified into the how-tos. We should probably start thinking about some kind of structure. Perhaps general, scripting with sub groups of general scripting and parser scripting, GUI handling, Resource handling, etc.
-
I think that Brian's original tutorials and the advanced tutorials should also be present here as well. This could really be a great thing for SCI development. I don't know what Cloudee thinks either, but either way I think a Wiki should be kept somewhere.
-
My thoughts are that if we use our available resources, well move to new server. Fill it up. As for specs and freesci stuff, I've been thinking a technical section would help with tool/ studio development. I'm not going to have time to do much over the next couple of weeks, but I'm game for changes and additions.
-
I think that Brian's original tutorials and the advanced tutorials should also be present here as well. This could really be a great thing for SCI development. I don't know what Cloudee thinks either, but either way I think a Wiki should be kept somewhere.
I agree. We should put everything on it. Not in lieu of, but in addition. Things have a way of disappearing on the internet. Having information duplicated on different sites is a good thing, but the Wiki could bring it all together in one place for convenience's sake. I am plugging away at it, setting up the frame work, but I don't want to get too much work invested in it if it is to be hosted elsewhere and all of my efforts would have to be duplicated.
-
I'm here for any work that needs to be done. Should I start by copying the structure from the FreeSCI docs verbatim over to your test wiki page Collector - or here? Anyone know how to do this in an intelligent way (i.e. not brute force, copy-paste, etc) to get all that info duplicated in a usable format?
I like the idea of a wiki. It's more structured than free-form posting & can be reorganized at any point. And I feel like I keep coming back to the same issues & sharing new info, which isn't always best presented in a thread.
-
The test Wiki with only a few pages is currently approaching 50MB not counting the database. Adding any images or other files will make this grow. I imagine that the database will also quickly grow. Even if this test Wiki is not to be the Wiki, it can let us to continue to set it up. I'll look into how possible it is to export the database. I suppose that even if things have to be copied over manually, it will already be in the Wiki format, so little to no editing would need to be done for a second copy and paste.
As far as copying the Free SCI stuff over, you can't do a straight copy and paste. Any line that begins with a space gets interpreted as code and a single line break will not be recognized as a line break. It does not recognize BB code. It uses its own code for formatting. Links are handled different. See the following for more.
http://www.mediawiki.org/wiki/Help:Formatting
It does accept some HTML tags, like br and pre. You can hit the edit tab on a page to see how I've started to enter the Free SCI docs. You can create a link before you create the page. The link will be red. If you click on a red link, you will be given a link to create that page. It probably makes more sense to do an intermediate copy and paste into a text editor where you have a search and replace function to speed up the reformatting. Let me know if you need any more help.
-
Okay, I'll start working on the FreeSCI pages soon...
EDIT: In progress. Will take some time, but coming along. Haven't figured out the footnotes, 'sublinks' within a page & the TOC stuff, etc.
-
In the Navigation box, click on the "SCI Specifications". You can start pasting in pages for the red links. I still need to sort out how to do the Wiki foot notes.
-
Wow... someone has been busy. Hope I didn't cause any problems with the little that I did with the FreeSCI stuff. ;D
-
No, it helped. The only thing that I noticed was that you didn't put closing tags on your tables. I've started to mark what need to be done in red, like links and footnotes. You can use the span tag for certain things such as font color. I'm working on the "The SCI Virtual Machine" section. I still have to format the last half of it, yet.
-
I have the Kernel functions section entered. It was a formatting headache. Could look it over to check it out? Just need that "SCI in action" section done, now.
-
This wiki is awesome, one of the best things to happen with this community in while I think. Also I have some server space(a Linux server at godaddy) I pay for monthly and do not use if it can be of use.
This helps get the information into all one source, as currently a lot of the old sources are dying and The Way Back Machine only does so much.
-
The last piece of the puzzle and the icing on the cake would be all the SCI content archived at Mega-Tokyo. I really hope someone has that stuff. Even if it isn't the latest stuff, we need the archived stuff from the past 7 years or whatever.
-
This wiki is awesome, one of the best things to happen with this community in while I think. Also I have some server space(a Linux server at godaddy) I pay for monthly and do not use if it can be of use.
This helps get the information into all one source, as currently a lot of the old sources are dying and The Way Back Machine only does so much.
Cloudee wants it to be all under one roof, but it does eat up space. I'll host the Wiki until he's ready for it. Server space is not an issue for me, as I essentially have unlimited space and don't even come close to my monthly allotment of bandwidth. I feel that is is important to save what we can as soon as possible. If we had had the foresight to save the MT content before it disappeared we could have have all of it. I'll probably keep an archive of the Wiki on SHP as a backup after Cloudee sets it up here.
If anyone can think of anything else that should go in the Wiki, feel free to have at it. Should Brian's tutorial be duplicated in the Wiki? It might be handy. How about some general information about developmental resources, including Omni's SourceForge project? Or adding the fan games to the SCI game list in the Free SCI documentation?
-
I hate recommending things I know I could do myself but the holidays are always busy for me so I will give a general thought process on the whole thing since I am lacking the time to create pages currently.
We need a comprehensive index with a listing of the main categories and a subsection in the index that leads to editing guidelines or best practices for when people update/change/add their own pages.
Links should be kept as a reference where applicable with a link link to the site on the way back machine for the broken/dead links if it has them.
Fangame listings should be summaries with all the games in a single page unless a game has enough information to warrant its own page. Walkthroughs would be their own page in a subsection in the game listings.
I believe Brians tutorials should be duplicated in the wiki if they have any room for improvement. My knowledge of the tutorial game and his tutorial is rather limited compared to others here so if it is hard to transfer or never ever changes or can not be improved upon then I would just link to it.
If I am not clear I will probably reread this in the morning and make adjustments as needed.
-
I have the Kernel functions section entered. It was a formatting headache. Could look it over to check it out? Just need that "SCI in action" section done, now.
Will do. I'll grab some time today & see what I can contribute. EDIT: Okay, kernel functions page is completed, except for the broken links
The one thing that I would love is some 'master index' of topics, with links to where the actual content can be found. Something that ties all the different tutorials together. For example, 'Said() string syntax' might be a topic & under that would have a link (or maybe show all pages combined on a single page?) to Brian's contribution, Troflips, the FreeSCI page, etc. That's what kills me now, I end up having to go into multiple pages strewn hither-and-yon to find what I need.
-
It would be good to have it arranged and linked in some kind of logical, cohesive way. That is part of the point of doing it in a Wiki. I do think we need to concentrate first on gathering all of the information before anything more disappears. I expect the Free SCI site to not be around much longer. Is there anything else on their site that we should get?
Omni mentioned the Web Archive, but this is of limited use. The main thing that would be what we would want to get is the SCI forum of the MT board and forums are never archived at any usable level. Most of the threads are inaccessible and the rest are incomplete. It would probably be more productive to contact an admin of the AGI Games site if they have a backup of the board's data base. I could setup a temporary SMF board to import it into so we could grab the info in the threads. Of course it would be missing any images or files, but the info would be there.
Does anyone know how to contact an admin from the MT board?
-
It would be good to have it arranged and linked in some kind of logical, cohesive way. That is part of the point of doing it in a Wiki. I do think we need to concentrate first on gathering all of the information before anything more disappears. I expect the Free SCI site to not be around much longer. Is there anything else on their site that we should get?
The source code for the FreeSCI project is there too - maybe get that?
http://freesci.linuxgames.com/?page=download
Omni mentioned the Web Archive, but this is of limited use. The main thing that would be what we would want to get is the SCI forum of the MT board and forums are never archived at any usable level. Most of the threads are inaccessible and the rest are incomplete. It would probably be more productive to contact an admin of the AGI Games site if they have a backup of the board's data base. I could setup a temporary SMF board to import it into so we could grab the info in the threads. Of course it would be missing any images or files, but the info would be there.
Does anyone know how to contact an admin from the MT board?
agigames.com has a page on Facebook. Looks like Chris Cromer is the admin. Anyone want to try to contact him (I'm not on Facebook...)?
-
Why not, but I'm not sure what good the Free SCI source would do us. Perhaps for the SCI Studio development? Better to get it and not need it than not and find out later that it would have been of use.
-
There's some SCI sound documentation by Ravi I believe that would be a swell addition:
SCI Sound Resource Format (incomplete) Revision 2
Ravi I. Jan 16, 1999
Preface
The sound resource is basically just a MIDI file. Much of what I write
here comes from outside documents, and I would direct anyone seeking
further information to various MIDI specifications. There are quite a few
floating around - I leave it to the reader to find individual documents.
Some people prefer the one-based numbering system for channel and program
numbers. I personally prefer the zero-based system, and use it here. If
you're familiar with channels 1-16, be aware that I will call them 0-15.
My intention is not to be deviant from other programs but to be more
accurate in representing the way information gets stored. The same is true
for programs 0-127 as opposed to 1-128.
Sierra may have changed its sound file format in the switch to SCI1.
Resources extracted from "Quest for Glory II" (which uses the odd
in-between engine) will not strictly follow this specification. I haven't
had a chance to look at true SCI1 files yet, but will when I can. For now,
I refer only to SCI0 sound files. Games which are known to follow this
specification include:
Conquests of Camelot
Hero's Quest I (Retitled Quest for Glory, but I only have the original)
King's Quest IV
Please post comments or questions to the SCI webboard:
http://www.InsideTheWeb.com/mbs.cgi/mb173941
About the output medium
The output medium (Adlib, MT-32, PC Speaker, etc.) greatly affects the way
music will sound. They may even affect the way sound resources get used.
Not having anything else, I can only play sounds with the Adlib and PC
Speaker drivers. I'd like to get my hands on an MT-32 firstly because it
would make the music sound quite a bit better and secondly because I think
Sierra's composers might have used them.
I have not yet tried to create sounds which play out the PC speaker. My
suspicion is that either the header specifies which channel should be used
for speaker output or the speaker always plays a certain channel. I have
been able to create sounds which play with an Adlib or compatible. If
other devices do not play sounds correctly, I'd appreciate it if people
with them could do some byte twiddling to help me figure out why.
Another issue to deal with in the output medium is the fact that the same
song may exist in two different files. In Conquest for Camelot, the
version of the title music which gets played by an Adlib is in sound.001.
The speaker version is in sound.201. The speaker version will play on the
Adlib (with more than one channel, I might add) but the Adlib version will
not play on the Speaker. While I haven't looked at patch files yet, I
think that different mediums have their own instrument format as well.
First two bytes
The first two bytes in an extracted sound file (they aren't actually part
of the resource) will be 84h 00h. This is the resource type OR-ed with 80h
and stored as a word.
Header
The header is 33 bytes long. The format appears to be:
byte - always 0
2 bytes - initialization for channel 0
2 bytes - initialization for channel 1
.
.
.
2 bytes - initialization for channel 15
The first byte is zero for every extracted file I've seen. Changing it
makes the sound resources I tested not play. Perhaps this is a format
version number: if Sierra wanted to expand the sound resource, they would
increment this byte to signal the player that it won't recognize the file
and should not try to play it.
After the first byte, each channel gets two bytes of initialization. The
first byte seems to initialize controls 4Bh and 4Eh (see command Bx).
The second byte's function is unknown.
Events
The actual music is stored in a series of events. The generic form for an
event is:
<byte - delta time> [byte - status] [byte - p1 [p2]]
Delta time is the number of ticks to wait after executing the previous
event before executing this event. Standard MIDI stores this as a variable
length value. In sound resources, it will be exactly one byte and the most
significant bit is in fact used as part of the value.
The status byte is basically a command. The most significant bit is always
set. This feature is important because the status byte will not always be
present. If you read a byte expecting it to be a command but the most
significant bit is not set, that byte is actually a paramater and you
should repeat the last status byte used. This is know as running status
mode and appears to get used relatively often.
There generic form for a status byte is (in bits) 1xxxcccc - The lower
nibble designates which channel the command affects. The upper nibble is
the command, but as stated earlier, the most significant bit must be 1.
That leaves space for 8 commands, most of which require at least one
paramater. Paramaters will never have their most significant bit set as a
way of distinguishing them from status bytes.
Status reference
8x n v - Note off: Stop playing note n on channel x, releasing the key
with velocity v. If a hold pedal is pressed, the note will
continue to play after this status is received and end when the
pedal is released. Note 60 corresponds to middle-c on a keyboard,
but the patch selection can change the actual pitch. Often, a
zero-velocity note on gets used instead of a note off.
9x n v - Note on: Play note n on with velocity v on channel x. Note 60
corresponds to middle-c on a keyboard, but the patch selection
can change the actual pitch. The velocity is the speed with
which the key gets pressed, which basically means how loud the
note should be played. Playing a note with velocity 0 is a way
of turning the note off.
Ax n p - Key pressure (after-touch): Set key pressure to p for note n on
channel x. This is to modify key pressure for a note that is
already playing.
Bx c s - Control: Set control c to s on channel x. This can be confusing
because there isn't just one meaning. Changing the settings on
different controls will, of course, have different outcomes.
Controls which handle any value are continuous controllers. They
have a continuous range. Controls which are only on/off are
switches. Their defined range is only 01h (OFF) and 7Fh (ON).
However, in order to respond to all values, 01h-3Fh is treated as
OFF and 40h-7Fh is treated as ON. While in practice they may only
use bit 6 as a flag, my personal opinion is that values between
01h and 7Fh should be avoided for the sake of clarity.
Common controls seem to be 07h, 0Ah, 40h, 4Bh, and 4Eh.
Control Refrence (tentative)
07h - Volume: Set the volume. This is a continuous controller
where a value of 00h is muted and a value of 7Fh is
loudest. There is a wide range of recorded values.
0Ah - Panning: Set the pan. This is a continuous controller
where 00h is hard left, 40h is center, and 7Fh is
hard right. There is a wide range of recorded values.
40H - Hold 1 Pedal: This is a switch that defines the state of
the hold pedal. When ON, the pedal is pressed. When
OFF, the pedal is not pressed. When the pedal is
pressed, notes continue to play after a key is
released. The notes will then stop once the pedal is
released. Recorded values are 1 and 127.
4Bh - Polyphonic / monophonic: The value determines the number
of voices which may be played at once on the channel.
Recorded values are 0, 1, 2, 4, 6, and 8. This seems
to be a non-standard control.
4Eh - Unknown: I had originally thought this control was some
sort of volume enable. A non-zero will allow volume
to be determined on a per-note basis with the
velocity paramater to command 9x while a zero value
means the channel will play at channel volume
regardless of the velocity paramater. This doesn't,
however, seem to be the case. Its odd interactions
with control 4Bh make me suspicious that it might be
some parallel to omni mode. Recorded values are 0 and
1. This seems to be a non-standard control.
Cx p - Program change: Set program (patch / instrument / ect.) to p for
channel x. This is a simple instrument change.
Dx p - Pressure (after-touch): Set key pressure to p on channel x. This is
similar to Ax but differs in its scope. Command Ax is applied on a
per-note basis while command Dx is applied to an entire channel.
Ex t b - Pitch wheel: Set the pitch wheel to tb. The setting is actually
a 14 bit number with the least significant 7 bits stored in b
and the most significant 7 bits stored in t. (Remember the top
bit can't be used for either byte.) The range of settings is
0000h to 3FFFh. A setting of 2000h means the pitch wheel is
centered. Larger values raise pitch and smaller values lower it.
FC - The only command I've seen which starts with F is FC and that denotes
the end of a file. Note that the lower nibble does not signify a
channel.
Revision history
Revision 2 - Jan. 16, 1999
- Got rid of the HTML. I originally intented to post this as a message
on the webboard, but ended up distributing the file. If I'm going to
distribute it as a file, there's no need to bother with the HTML
since I can do all my formatting as plain text.
- I found refrences to command 8x in the 1988 Christmas Card, so my
comment about not seeing one got removed. To date, I haven't seen any
examples of commands Ax or Dx.
- Expanded the header section.
- Added information about controls.
- Added information about the output mediums.
- Tried to be more consistent with terminology
Revision 1 - Dec. 29, 1998
- First release of the specification
Here's some fanmade SCI drivers documentation which might have some good information: http://sierra.voyd.net/ (http://sierra.voyd.net/)
-
Feel free to add Ravi's stuff. I am aware of the sierra.voyd.net site, but it seems to be mostly about his drivers and not much about SCI specifically.
-
Looks like it's already there and much newer than mine. Excellent. Though, it is incorrect. Ravi says that KQ1 SCI is the only game he knows of that has digital sound effects and that's not true. SQ3, KQ1, QFG2, and a handful of other SCI0 games also have digital sound effects.
EDIT: Would Wiki-ifying the entire SCI Studio Help file be feasible?
-
Go ahead and make any corrections you see that need to be made. Just comment out the original and notate it.
-
I'm brand new to Wiki. Can you explain that a little more? How do I notate it?
EDIT: I did something, let me know if I did it correctly.
-
The Wiki will accept some HTML code, so commenting is the same
<!-- text inside these tags will not be seen -->
This can be used to hide, but keep the original text with the page. The Wiki software tracks changes, however, commenting out the original text will keep it where it was. I think that the Free SCI document and Brian's tutorial are the only things that we should do this with. The Wiki tracking is fine for everything else.
By the way, it will accept the HTML tag for line break. Probably should use the XHTML version:<br /> since it generates XHTML code. I put links to WikiMedia formatting, linking and tables how tos on the main page.
I have still to work out citations and footnotes, but if I don't have much success, I'll just set named anchors to link to.
-
Hoping someone from Freesci sees this.
Which is most up to date
http://www-plan.cs.colorado.edu/creichen/freesci/freesci.pdf (July 5, 2007)
or
http://freesci.linuxgames.com/scihtml/book1.html
-
Err, Upon further examination it appears the website is just as up to date as the pdf minus the table of contents. The table of contents does not appear to link to all the pages.
-
Hoping someone from Freesci sees this.
Which is most up to date
http://www-plan.cs.colorado.edu/creichen/freesci/freesci.pdf (July 5, 2007)
or
http://freesci.linuxgames.com/scihtml/book1.html
Good question. I did find a few inconsistencies, but nothing conclusive.
-
EDIT: Would Wiki-ifying the entire SCI Studio Help file be feasible?
Yes. Collector - could you please add a link under the left-navigation pane to include the heading 'SCI Studio Help Files'? I can't seem to to figure out how to edit that... content from here (at least that's where I found it, ;D): http://sierrahelp.com/Files/Utilities/SCITools/SCI%20Studio%203/SCI_Studio_3_Help_Files.zip
-
He has already begun adding the that gumby.
http://sierrahelp.com/SCI/Wiki/index.php?title=SCI_Studio_Tutorial
And to be able to edit the side bar he would have to assign special permissions to individual accounts.
-
No, that's the tutorial. I was talking about the actual SCI Studio help file which is loaded with information on the SCI scripting language and isn't available anywhere else.
-
Ahh, I see now.
Edit: It might just be me but I do not think the reference page is set up.
To easily find the problem just click on the reference at the bottom to take you to the reference
http://sierrahelp.com/SCI/Wiki/index.php?title=The_Sound_subsystem
This is the page I used used to make sure I was doing it correctly, it has been awhile since I have done any wiki editing...
http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_%28footnotes%29/Cite_link_labels
-
The SCI Studio Help files could be done, but it is a lot of work. I have started on Brian's tutorial and am getting to a burnout point. I'll have to look into one of the HTML to WikiMedia converters.
It took me a while to figure out how to modify the navigation pane. You have to get to it much the same way that you get to the Chrome file for Firefox and it is only accessible with an admin login. Just let me know when you want something added to it. I have enabled uploads, but because of the security risk regular users do not have permissions. I could try to create a new permissions mask for a trusted group of regular contributors. Please bear with me, as I am new to administering a Wiki.
I am starting to see the Wiki as a valuable tool that many will want to have opened along side Studio or Companion to have all the SCI info we have right at hand. I have thought of a couple of GUI changes that would be nice for Studio once it gets to a point of being as usable as Companion. Have the New Game drop a dosbox.conf in the game's folder and the Run Game launch DOSBox, using that config file. A link to the Wiki and this forum in the Help Menu or on the Toolbar would be great. For NSIS I use NIS Edit. It is an older editor that is becoming dated, but I feel more comfortable with it. A link to the NSIS Wiki and the NSIS forum are right in Help Menu. This is extremely convenient when I am having trouble with something or I get stumped on how to do something new.
Edit: It might just be me but I do not think the reference page is set up.
To easily find the problem just click on the reference at the bottom to take you to the reference
http://sierrahelp.com/SCI/Wiki/index.php?title=The_Sound_subsystem
This is the page I used used to make sure I was doing it correctly, it has been awhile since I have done any wiki editing...
http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_%28footnotes%29/Cite_link_labels
Thanks for the link. As I said in earlier posts I had not figured out the footnotes or citations. I'll try to look into tomorrow.
-
The SCI Studio Help files could be done, but it is a lot of work. I have started on Brian's tutorial and am getting to a burnout point. I'll have to look into one of the HTML to WikiMedia converters.
Yeah, I can imagine the burnout. You've been at a breakneck pace at this from what I can see. Thanks for laying a foundation that we can build from.
It took me a while to figure out how to modify the navigation pane. You have to get to it much the same way that you get to the Chrome file for Firefox and it is only accessible with an admin login. Just let me know when you want something added to it. I have enabled uploads, but because of the security risk regular users do not have permissions. I could try to create a new permissions mask for a trusted group of regular contributors. Please bear with me, as I am new to administering a Wiki.
If you can't find anything on an HTML converter, just throw in a link in the nav pane for the 'SCI Studio Help Files' and I'll give it a go (by hand).
-
I've been looking into the help files and have decided that a different approach is necessary. The HTML is very sloppy and crude. It would need to be drastically redone before conversion. Even then I'm not sure how to keep the easy navigation within a Wiki. I have a couple of ideas about it. Give me some time to see what I can come up with.
I've sorted out the problem with the citations. Oddly, the default install of the Wiki does not include what is required for citations. I had installed the Cite.php extension right after I installed the Wiki. It was already functional, but had not looked into how to use it. The problem with the foot note link is that it doesn't like links in the footnote itself. For footnotes that require a link we will probably need to manually work with named anchors.
-
It's going to take a fair bit to redo the help file, but I think that it will be worth it. I don't think that it will work out to incorporate it into the Wiki as is, but perhaps just extracting the general SCI information in it and inserting it where appropriate in the Wiki. I could link back each other, though, making either one click away from the other.
I noticed that the table of contents is long and cumbersome, so I started to experiment with the table of contents. Keep in mind that this is just the beginnings and is incomplete.
http://sierrahelp.com/SCI/SCIStudio3Help/
-
That's pretty neat!
-
It's going to take a fair bit to redo the help file, but I think that it will be worth it. I don't think that it will work out to incorporate it into the Wiki as is, but perhaps just extracting the general SCI information in it and inserting it where appropriate in the Wiki. I could link back each other, though, making either one click away from the other.
I noticed that the table of contents is long and cumbersome, so I started to experiment with the table of contents. Keep in mind that this is just the beginnings and is incomplete.
http://sierrahelp.com/SCI/SCIStudio3Help/
Yeah, I think that this will work well. I like the expand/collapse nav pane - easier on the eyes.
-
I have also added a link to the Wiki at the top of the navigation pane and a link to the help file in the navigation box of the Wiki. It makes it as convenient as if the help file was in the Wiki, but keep its navigation and format.
-
I have all of the links and footnotes done with the SCI Specifications. I still need to go through it to find any formatting errors. I'm still plugging away at the help file.
-
Man, you have been busy. I've got about 1 more week of hell and then I should be good to participate in whatever way necesary. Good work though.
-
Thanks. I started the tutorial, but got distracted by cleaning up the Studio help files.
-
I have mostly finished cleaning up the help files. They were a real mess. I am assuming the Brian used some kind of WYSIWYG editor from back then that generated junk code, though not nearly as badly as Word would have done. It was done using nested tables, many depreciated attributes, redundant and unclosed tags. I re did it in XHTML, W3C compliant code. The old is over a MB in size and the new is a little over 700 KB, including the original images. It loads a lot faster now and has greater style consistency (due to the use of CSS). I also matched the syntax highlighting with that of SCI Studio.
http://sierrahelp.com/SCI/SCIStudio3Help/
One thing that I found is that there are a couple of missing pages that are also missing from the CHM. vocabresources.overview.html and vocabresources.creatingandediting.html. I copied and modified one of the other resource's overview and creatingandediting pages to stub it out, but this is right up Gumby's alley. Perhaps you could flesh the vocabresources.overview.html?
Next, back to the tutorial.
-
One thing that I found is that there are a couple of missing pages that are also missing from the CHM. vocabresources.overview.html and vocabresources.creatingandediting.html. I copied and modified one of the other resource's overview and creatingandediting pages to stub it out, but this is right up Gumby's alley. Perhaps you could flesh the vocabresources.overview.html?
Sure - I looked for the stubs you are referring to, but couldn't seem to find them in navigation pane. Also, not sure how I can submit the info - I don't think I can modify the help files directly (like the wiki) right?
-
The Creating and Editing stub is here http://sierrahelp.com/SCI/SCIStudio3Help/vocabresources.creatingandediting.html
which is a modified version of http://sierrahelp.com/SCI/SCIStudio3Help/viewresources.creatingandediting.html
This one is as complete as the one for the other resources and probably doesn't need anything more.
The stub is here http://sierrahelp.com/SCI/SCIStudio3Help/vocabresources.overview.html
which is a modified version of http://sierrahelp.com/SCI/SCIStudio3Help/viewresources.overview.html
Feel free to change it as needed, but it is just a brief overview. I only need text. You can post it here and I'll work it in the help file.
-
Let's start with this: (anyone else please feel free to jump in). Modify as you see fit...
- All words that can be inputted by the user must reside in the vocabulary in order for the parser to accept the user input, with the exception of word suffixes (see below).
- It is critical that the correct parts of speech are associated to each vocab word for the parser to interpret what the user is attempting to communicate. It is not recommended to change parts-of-speech of a word just to get the desired result in your code. There is an occasional need for it, but before doing it explore all other avenues.
- Note that the template game has most (if not all) of the vocabulary words from all SCI0 games. This means that the need for adding new words will probably be limited to nouns and qualifying adjectives (and perhaps some imperative verbs & adverbs). When adding new words, it is recommended to find other similar words & model the parts-of-speech from them.
- Word suffixes: It is not necessary to add word suffixes to the vocabulary words unless the game developer would like to make a distinction in their code (specifically in the Said() string syntax) between two words with the same root word (example: tree vs. trees, jump vs. jumping, etc). Suffixes are predefined in another vocab resource not directly accessible for modification within SCI Studio. This means that if 'tree' is defined in the vocab (and it's plural is not), the user is free to enter the word 'trees' & the parser will accept the input, ultimately converting the word down to it's base word 'tree'.
- Synonyms: The use of synonyms is encouraged. Any number of synonyms can be used for a word; they reside with the word in vocabulary, separated with the vertical bar (|) character. Using synonyms limit the amount of code a developer needs to write to handle various inputs & makes it easier to the game player for find a word that matches the intended meaning. Take for example the word 'door'. It could by matched in the input phrase 'open door'. However, if we added a few synonyms to door (like this: 'door | portal | gateway | opening'), then the user could enter 'open portal' or 'open gateway', and the developer's code would work as if the user inputted 'open door'.
-
This is more detail than what I was thinking, but it is more clear than most of Brian's documentation. I have been thinking that the information in the help file should be incorporated in the Wiki in more of a reference form than the current help file form. Something where the aim was to understand and how to work with SCI rather than Studio specifically. It could easily be crossed referenced better than what the help file is.
-
This is more detail than what I was thinking, but it is more clear than most of Brian's documentation. I have been thinking that the information in the help file should be incorporated in the Wiki in more of a reference form than the current help file form. Something where the aim was to understand and how to work with SCI rather than Studio specifically. It could easily be crossed referenced better than what the help file is.
Do you need me to boil what I put together down to a more appropriate overview? Seems like what you've got already on that page does a pretty good job (without going into too much detail).
-
I just combined the two and added it to the TOC. References to it elsewhere in the help file should be OK as I used the same name for the files that the links were looking for.
-
The guys at ScummVM don't seem to agree with the fact that we copied the same FreeSCI documentation that's on their wiki and would rather host the SCI Development Wiki over there. Here's the thread (http://forums.scummvm.org/viewtopic.php?t=9697). What's everybody think? Their argument is that having two sites with the same information is redundant and one is more prone to going out of date. I just really think it's a great second resource for SCI game development as opposed to engine development. And there's a lot of valuable information in the FreeSCI docs for game developers.
I really like the idea of it all being under a Sierra roof, owned and operated by active SCI game developers rather than another thing for ScummVM to swallow up into itself and have control of. I have no say in the matter at all seeing as I didn't make any of this, but I thought it should be brought to your attention since we all own it in a way, being the developers and contributors.
-
I have been following it, but have not responded because I don't like their attitude. They proudly display the GNU Free Documentation License logo on their copy of the SCI documentation as they tell us that we should not have the FreeSCI documentation on our Wiki. I got the documentation from the FreeSCI site, not their Wiki. I also included the original copyright info. We have the legal right to publish it to our Wiki
Permission is hereby granted, free of charge, to any person obtaining a copy of this documentation to deal in the Documentation without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Documentation, and to permit persons to whom the Documentation is furnished to do so
I would hate to have to rely on their Wiki. Besides the fact that their Wiki is closed, I have found the ScummVM server to not be nearly as reliable as SHP's and since it is ScummVM generic, not only would we would have to dig through it to find the SCI related stuff, we would also have to dig through that to find the game development info.
There is a certain amount of arrogance in assuming that a community that has been around longer than the CABAL joke should fold and be assimilated into theirs just because they are the self proclaimed experts of all things Sierra, when they don't even seem to respect the opinions and desires of the traditional Sierra fans. This community has roots going back to the original MT forums, which may predate the ScummVM project. Even though I am currently hosting our Wiki on SHP, I very much consider it to be an extension of this community. I would like to keep it there until this has better hosting.
I understand that the impetus for the Sierra game creation forums on ScummVM came from the fact that AGI Games went down. They might have had the database from the original MT forum, but this for the most part has been the home of the SCI community. Before their forum change, some had posted about new SCI game development only to have some of the devs deride SCI as too primitive for anyone to waste their time with for a new game.
Sorry for the rant, but they are starting to tick me off.
-
No I get you. I don't like their attitude either. I'm tired of the ScummVM team's need to have everything under their own roof. Their arrogance insisting that they know more about Sierra-related material than anybody else just because they did "the impossible" and added SCI into ScummVM is appalling. I'd rather keep this stuff "in the family" so to speak.
-
Agreed. Their attempts to bring it all together come off more as trying to control everything. It makes me want to have all of the AGI stuff here, too. I wish that someone here could get in touch with someone from AGI games. Even if a backup of the database was old, it should have most of the important stuff that we would want.
BTW, I Have finished adding the tutorial to the Wiki. I altered the style to math the Help file with the Studio syntax highlighting. If others could start looking it over to check for any mistakes. What do you guys think of adding a tools section to the Wiki so that everything can be cross referenced throughout the Wiki?
-
Agreed. Their attempts to bring it all together come off more as trying to control everything. It makes me want to have all of the AGI stuff here, too. I wish that someone here could get in touch with someone from AGI games. Even if a backup of the database was old, it should have most of the important stuff that we would want.
BTW, I Have finished adding the tutorial to the Wiki. I altered the style to math the Help file with the Studio syntax highlighting. If others could start looking it over to check for any mistakes. What do you guys think of adding a tools section to the Wiki so that everything can be cross referenced throughout the Wiki?
Again, agigames.com has a page on Facebook. Does anyone here have a relationship with Chris Cromer who could contact him?
I like the idea of the tools section in the Wiki for cross-reference... I find myself bumbling through multiple sites to find what I'm looking for.
As for ScummVM... (haven't read the thread there yet). Do they think that we ripped it from them? My view is that 2 copies is better than one (even if there might be *slight* discrepancies). If the documentation had disappeared from the FreeSCI prior to ScummVM or us grabbing it and making it presentable (big thanks to Collector for the hard work), everyone would be screwed (similar to MT going down). Let them get all worked up about it, I guess. We haven't done anything wrong.
-
Fingolfin came in and calmed everybody down, saying he's not against it. But he did point out that there are some things in the parser documentation that are out of date in our version.
-
I found a Wiki extension that doe automatic syntax highlighting. Of course there was no SCI support, so I hacked it in, using Studio's highlighting as a template. You can see it here:
http://sierrahelp.com/SCI/Wiki/index.php?title=Manipulating_the_Parser_-_Part_1_-_%27Complex%27_Nouns
You use it in lieu of 'pre' tags. For consistency in the Wiki, format any code like this:
<div class="CodeBlockHeader">Code:</div>
<div class="CodeBlockStyle"><syntaxhighlight lang="sci">code goes here
because it acts like <pre> tags it will preserve the code's formatting without adding nonbreaking spaces or line breaks.</syntaxhighlight></div>
This will make the code readable while editing it.
-
I actually prefer Companion's syntax colors to Studio's. Can there be like a toggle?
-
I actually prefer Companion's syntax colors to Studio's. Can there be like a toggle?
The way the extension works it couldn't be easily done by choice of skin/CSS. All of the language info is contained in a language specific PHP file that I made for Brian's highlighting. I chose Brian's for constancy because of the inclusion of the Studio tutorial and help files. If Omni were to change Studio's highlighting to match Companions for his builds, We could distribute that instead and I would change the tutorial and help files accordingly. Of course if we are going to set a default SCI syntax highlighting, we could come to a consensus of what we want. For example, I prefer gray for comments so they don't visually dominate the code. Brian's comments almost overwhelm the rest of what is in the editor.
Edit: This should not prevent anyone from using the tag now. When we do come to a consensus the tags will reflect the changes in the modified sci.php file.
-
Yeah, his comments are pretty brutal. Troflip's comments in companion are italicized and green. Much easier on the eyes.
-
If you come to a highlighting consensus please post a concise list here please so I can refer back to it.
-
Companion does not italicized the comment, but are green.
Highlighting differences are as follows. Troflip's key words are blue and integers a dark red. Brian's are both blue. Brian's strings are green, while Companion uses red. Studio's parentheses and arithmetic operators are dark purple while Companion's are black. Can't say that I am too fond of Companion's strings.
I'd say to start from Studio's, but change the comments to gray. Should the key words and integers be different?
-
I also think that the Companion highlighting is easier to read. With that, I'd vote for:
- Text in single quotes to be red (Said() strings)
- Text in double-quotes. (Print statements, includes) - Not sure.
- Comments to be light green
- Operators - not sure, purple doesn't come through very well
- Keywords - blue, like you've got em
However, these are based on my own biases - I'm sure I'd adapt to whatever is decided. Just putting in syntax highlighting is a major improvement!
-
Indeed, as long as there's something it'd be great. I kinda like the bright-red strings in Companion, though.
-
I have altered the PHP file to make the comments gray, which makes Studio's much easier to read. I guess that I like gray for comments because most of the things I do have gray comments. It makes it easier to ignore the comments when you want to concentrate on just the code. Brian's comments are so "in-your-face" that it makes it hard to read the code. The red is the one thing I don't like about Companion's because it is rather distracting. Perhaps if it was dimmed down a bit?
I have also started to add categories. This could be one of the best ways to organize the pages. You ca see the main Wiki page for more on this.
-
Hey, maroon would be fine with me. Just as long as it's differentiated from doubly-quoted strings.
-
OK, what I came up with is
* blue for keywords
* dark blue for integers
* green for operators
* red for single quote strings (slightly darker that the bright red of companion)
* orange for double quote strings
* gray for comments
You can play around with different code on the test page to try these colors out, http://sierrahelp.com/SCI/Wiki/index.php?title=Test_page
Once we come to a consensus I will post a list in hex for Omni.
-
Sounds good to me.
-
Looks good, but for some reason the green operators are throwing me off. It might just be the green parentheses, I'm not sure. Would black be a better choice for the parentheses?
-
Actually, the green comes from the extension author's C++ highlighting. I could change it, but wouldn't it be good to make them standout a bit? One missing closing parenthesis can make code fail. Perhaps a bit darker green?
-
I changed it to a bit of a darker green so the parentheses don't stand out so much, but is still a bit distinct. In hex:
* blue for keywords - #0000FF
* dark blue for integers - #000099
* dark green for operators - #006633
* red for single quote strings - #CC0033
* orange for double quote strings - #FF6600
* gray for comments - #999999
-
Actually, the green comes from the extension author's C++ highlighting. I could change it, but wouldn't it be good to make them standout a bit? One missing closing parenthesis can make code fail. Perhaps a bit darker green?
I gotcha. I wasn't thinking about interactive syntax highlighting, just readability. I really like the darker green as opposed the lighter green. What you've got now works for me!
-
Well, if everyone else agrees, I'll go with this for the Wiki. It isn't too far off from Companion, but I think it is easier to read. I, too dislike anything that stands out too much. It is especially irritating when you have to stare at the same bit for extended periods trying to find where a script is broken. Also, if Omni changes Studio's highlighting to match, I'll redo that tutorial and help file to match.
-
Oh wait, is it possible (if everyone agrees) that you could switch the colours for the single quote strings and double quote strings? Companion's single quote strings are brown and the double quotes are red. I don't mind the darker red and the orange as replacements, but it looks odd to me to have them reversed. Again, if everyone doesn't mind.
-
I don't mind. I think the main thing is to have the difference. So that would be:
* blue for keywords - #0000FF
* dark blue for integers - #000099
* dark green for operators - #006633
* orange for single quote strings - #FF6600
* red for double quote strings - #CC0033
* gray for comments - #999999
-
Thank you! :)
-
Oh wait, is it possible (if everyone agrees) that you could switch the colours for the single quote strings and double quote strings? Companion's single quote strings are brown and the double quotes are red. I don't mind the darker red and the orange as replacements, but it looks odd to me to have them reversed. Again, if everyone doesn't mind.
Works for me.
-
Hey Collector, thanks for fixing my ugly 'table-based' posts in 'The Parser' section of the Wiki. They look waaaay better.
-
I have been looking into Wiki tables and found how to combine cells in a row on a single line, which makes the edit view much more readable. I also found that adding the attribute {| class="wikitable" makes decent looking table that will give consistency through out the Wiki and {| class="wikitable sortable" will create sortable tables.
-
I've been having problems with the pages that use the syntax highlighting. I get errors like this:
Warning: Invalid argument supplied for foreach() in /home/collectr/public_html/SCI/Wiki/extensions/SyntaxHighlight_GeSHi/geshi/geshi.php on line 4362
I also got it with the test page you set up for the syntax highlighting as well. It doesn't always happen, however - sometimes the page is displayed normally. Navigating away from the page & re-entering it sometimes clears the problem.
I'm running with Firefox 3.6.13.
EDIT: Navigating away & re-entering page seems to *always* fix the problem.
-
I have been having to redo some of them by just hitting the edit then save. Every change to the sci.php file that I have made causes the pages that use it to need to be resaved. I have also found a problem with it when using it more than around 10 times on a single page. It will give that error. Not sure of the line number, though. The geshi.php is a lot more complicated than the individual language files. I haven't looks through it that much, yet to see what I might be able to determine.
-
Fingolfin came in and calmed everybody down, saying he's not against it. But he did point out that there are some things in the parser documentation that are out of date in our version.
I briefly looked into the parser documentation differences. On the surface it appears that it's mostly (if not all) just formatting differences - their's is much more readable. When I get some more time I'll have to compare them side-by-side.
Anyone have a clue if there is a newer version of the specs somewhere that their info came from, or was it simply their own modifications of the document that puts ours out-of-date?
-
Their own modifications.
-
Something that has bothering me about the tutorial are the links to the help file. It is good to have the extra info, but I don't like that referring to them makes your browser leave your place in the tutorial with out right clicking and choosing open in new window or tab. To solve this I enabled plain HTML to add a javascript popup window for these links. You can see how it works on the http://sierrahelp.com/SCI/Wiki/index.php?title=SCI_Studio_Tutorial_Chapter_9_-_Elements_of_a_Script page. Let me know if it works for you or if anyone has a suggestion about it. Because of the security risk to the Wiki and to SHP from enabling HTML, this is one privilege that I am restricting to administrator only. If anyone has need of a popup on one of your pages, let me know so I can add it for you. I am probably going to enable tool tips for quick definitions that won't require a full featured browser window. Any regular user should be able to add that themselves.
-
Works for me. I kind of like it.
-
Yeah, I like it to. It maintains better 'train-of-thought' for the visitor.
-
While trying to track down syntax highlighting extension's display bug, I added the formatting of the <div class="CodeBlockStyle"> tag to the syntax highlighting in the CSS file to simplify things. So that the "CodeBlockStyle" tag is not needed and should no longer be used. I have gone through the Wiki and removed all of the "CodeBlockStyle" tags. Any scripts should now be entered in with just:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">Script here.</syntaxhighlight>
I don't think that the syntax highlighting display bug has been completely fixed yet, but it seems to not be occurring as often.
All of the tutorials have been added and I have also gone through and made all of the tables and various style elements uniform. I had a couple of pages locked that I was working on that are now unlocked. Some pages were moved to arrange them in a more logical way to avoid confusion. With 4 tutorials and the SCI specifications all having a chapter 1, chapter 2, etc. I wanted the page titles to specify what it belonged to. I fixed all of the links broken by this so that the redirects are no longer needed. All of the images have been made uniform and uploaded. I think that most of the typos have been corrected. The basic structure of the Wiki is done.
Besides adding any new material and updating the existing information, the main thing to do is to to start cross referencing everything and making sure that all relevant categories have been added to each page. Since sections within a page cannot be added automatically to a category's page, they will need to be added manually. This can be done by editing the category's page to add links to the named anchor with in that page. These links can be found in the table of contents at the top of the pages. An example can be seen on the Said() Strings category page (http://sierrahelp.com/SCI/Wiki/index.php?title=Category:Said%28%29_Strings) at the top. It links to the Said_specs section of the SCI in action chapter of the SCI specs. We should cross reference as much of the SCI specs document through out the rest of the Wiki as is possible/relevant.
So start looking through the Wiki to find what should be cross referenced/linked and look for any inconsistencies or details that need to be addressed. If you are not sure about something or have a suggestion, start a discussion for that page on the Wiki or in the forum here.
-
That's great news about the highlighting bug. It's been driving me nuts for weeks.
I highly recommend to everyone to have a quick peek at the Wiki if you haven't recently. It's has very consistent style throughout (especially noticeable between the tutorials). It's impressive what you've put together Collector :).
-
Thanks. The tutorials took a while to do. Each had a lot of cleanup that needed to be done. Brian's had very sloppy, invalid HTML, Troflip's was done in Word, the worst HTML editor ever made and the Point and Click had to have this forum's formatting removed. Then they had to be converted to Wiki formatting.
-
Added an extension to allow the embedding of Flash. Some tutorials might benefit from a flash treatment, such as creating Views or Pic resources. Or perhaps using SoundBox? Here is a demonstration.
http://sierrahelp.com/SCI/Wiki/index.php?title=Test_page
The extension can easily be removed if no one thinks that this can be of use.
-
MI, you made some very nice Pics for your KQ2 remake. Would you be up to a video tutorial on making PIC resources?
-
I've thought about it, but I don't really consider myself that great of an artist. I probably do things completely the wrong way and I wouldn't know where to begin anyway. I guess I could document my procedure, but I always thought the best way to do that would be to just open the picture up in a Picture editor and go through each step to see how it develops. The only thing I do probably inefficiently is draw things on the spot without sketching or tracing anything before hand. I really don't have much of a plan going on for what I draw in Pictures besides how I'm seeing it in my head. Sometimes this means I have to backtrack and erase stuff I've already drawn. Sometimes I'll copy elements from other backgrounds from Sierra games (a handy feature in Companion!). I've copied trees, bushes, and foreground objects from KQ1SCI and KQ4.
Also, it's dependent on my time, which is limited right now.
-
It was just a thought. I think that video "how tos" could be a great resource for those trying to learn certain aspects of Studio or Companion such as creating/adding resources like graphics or audio, but not all things. I can see no real benefit to it for learning scripting, for example. Perhaps one for adding music, if you get some time?
-
Indeed. That would be handy for people to have.
-
I'd offer to do a flash tutorial, but I have almost no experience using Studio/Companion with regarding the picture or sound resources.