HSC Studio - Halo Script Code IDE

[Choking Victim]

HSC Studio

FAQ
Q: What is it?
A: HSC Studio is an application I developed in order to streamline the development of scripts for halo CE. Think of it like a Visual Studio counterpart for the halo script language.

Q: What can it do?
A: The application has a range of features to increase the efficiency of script development and make it easier on the user to develop and read scripts. The current features include:


Intellisense - Detects what the user is currently typing and offers existing haloscript functions that start with what you've typed.
Syntax Highlighting - Color codes text to make it easier to read.
External script definitions - Allows the user to define custom scripts or globals created in Open Sauce. Any functions added to the definition files will appear in the intellisense list and will be formatted with the colors you define.

Q: Are any other features being added?
A: The project is still under development, so yes, and that is the point of this thread. The community can suggest features and, depending on the feasibility, I will implement them as I see fit. Some features I am planning to add include:


C/C++ style directives - Allow the user to define commonly used values in a script using the "#define token [value]" structure. The token is the directives name, the value is the value of the directive. If a directive such as "#define DIR 8" is defined, you can use the 'DIR' keyword in place of the value '8', when you build the project, all instances of 'DIR' will be replaced with the numerical value '8'. This is useful if you use a value multiple times in your script, you'll only have to change the value of the directive instead of all instances of that value.

Q: When will it be released?
A: I'm hoping to release it before August, but the answer right now is "when it's finished". I'll most likely hold a public beta somewhere between now and then.

Video of the application in action:
Ch9GHG7Ht8M

Feature requests welcome, but I can't guarantee all will be implemented. Discuss.

[teh lag]

It'd be nice if there was some way for it to support built-in documentation for script functions and scripts themselves. I'm used to working in Eclipse for Java programming, and when you hover over something it displays a popup thingy with the Javadoc for it, if Javadoc is available.

Ex: if I write the following...


/**
* Creates a new Fart object with a given intensity
* @param intensity - the intensity of the Fart
* @return the Fart
*/
public Fart emitGas(int intensity)
{
return new Fart(intensity*5000);
}
...if I then hover over a call to that function, the popup window will show the Javadoc I wrote right above it.

If user-defined documentation isn't possible, maybe just do it for the function descriptions from hs_doc?

[Choking Victim]

It'd be nice if there was some way for it to support built-in documentation for script functions and scripts themselves. I'm used to working in Eclipse for Java programming, and when you hover over something it displays a popup thingy with the javadoc for it, if javadoc is available.

Ex: if I write the following...


/**
* Creates a new Fart object with a given intensity
* @param intensity - the intensity of the Fart
* @return the Fart
*/
public Fart emitGas(int intensity)
{
return new Fart(intensity*5000);
}...if I then hover over a call to that function, the popup window will show the javadoc I wrote right above it.

If user-defined documentation isn't possible, maybe just using the function descriptions from hs_doc?
One of the features I wrote for intellisense displays a tooltip of the currently selected script function in the intellisense listbox. It's briefly visible in the video above, but the functions I used have no description and arguments to display.

Here's a screencap:
http://imgur.com/Bi7Vl.jpg

EDIT: These descriptions can also be edited in the external script definitions I described.

[Higuy]

Sweet, this should be handy.

[Kornman00]

Are you allowing this to support any Blam engine (plus its various platforms which can have differing script definitions)?

If you're going to support a preprocessor for the script code then might I suggest also implementing the #pragma directive? This way you can offer specific functionality just like a C compiler would. One pragma directive that I would suggest adding is "#pragma engine("Halo2_Xbox")". This pragma directive would appear at the first line of the script file to explicitly declare what engine the script is for. That or the scripts can just fall back on whatever the project settings specify.

I had originally designed a "PSL" language for Prometheus which was basically a C-like wrapper over BSL. I don't have the design document handy but I had translations planned out for allowing things like for, switch, templates, a preprocessor, etc. Ideally, if you're going to extend the language you might as well go-for-the-gold and make a wrapper language so you're free from existing language constraints or users accidentally trying to include a marked up hsc file. But that was just my feeling on the matter. At least then it would be easier to implement auto doc comments with xml or, ugh, javadoc. You'd also be able to make use of namespaces then too for easier narrowing of where functions are declared (ie, all opensauce script data would be declared under a "Yelo" namespace)

[Choking Victim]

Are you allowing this to support any Blam engine (plus its various platforms which can have differing script definitions)?
I only currently have plans to support Halo CE, since that's the only one we can compile scripts for.

[CodeBrain]

I am not so certain about that.

Using a fully unlocked H2Guerilla (not kornman's sorry) and Expert Mode enabled, you can create scenario_hs_source_file tags. (Note: You don't need expert mode to actually create the tag, you need it to be able to edit the tag.)

Halo 2 Vista uses scenario_hs_source_file tags instead of .hsc files like Halo CE. Make your script within the tag, and then reference it in your scenario.

H2Tool and H2Sapien, when compiling/loading scenarios, they compile scripts. See my pictures from way back:

http://i19.photobucket.com/albums/b152/ShadowFireMario/Making_Level.jpg

http://i19.photobucket.com/albums/b152/ShadowFireMario/Making_Scenario.jpg

Unfortunately thats as far as I gone with compiling scripts, because H2Tool crashes during compiling scenarios for me. It could just be that my H2EK is messed up and needs to reinstall. I will do that now and see if it still happens.

Of course if you already knew this then excuse me :p

Also, sorry for jacking your thread Choking <_>

[Choking Victim]

So in other words, my point still stands and what you just said is redundant. I do know of a way to compile scripts for h2v, but I won't cater to the nonexistant community that develops for it.

[CodeBrain]

I only currently have plans to support Halo CE, since that's the only one we can compile scripts for.

My post was referring to that part. I had thought you meant that there was no way of compiling scripts for H2V. Guess I didn't look into it more.

[Kornman00]

Halo 2 doesn't use the resource tag for its scripts; just like in Halo 1 the scenario's hs definitions are still in the actual scenario tag and .hsc files are still used as the source code files. If you look around you'll find other scenario resource tags as well. That crash probably comes from the tools when they're try to merge the scenario resource(s) into the destination scenario tag. Scenario resources weren't exactly something H2V was intended to let us use so it's functionality (assuming all of it is still there) wouldn't have been tested.

Stubbs the Zombie's scripting system is the exact same as Halo 1's (since not much tech was actually changed rather than added when comparing the two). The HEK could potentially be modified to target that game. Stubbs still had the multiplayer engine in it (albeit, Halo 1 Xbox era, so no HaloPC-like MP support).

IMO, it's better to give thought about future uses of applications such as these. It's good lifecycle practice and makes you think and develop code in a manner which will allow easy extending later on. It really wouldn't be all that difficult to target later engines as long as you make all points about the scripting system definable via .NET assemblies or with XML.

Just my two cents, but if you just want to stick with HaloCE, go for it. It'll be useful and used by people around here either way.

[CodeBrain]

Halo 2 doesn't use the resource tag for its scripts; just like in Halo 1 the scenario's hs definitions are still in the actual scenario tag and .hsc files are still used as the source code files. If you look around you'll find other scenario resource tags as well. That crash probably comes from the tools when they're try to merge the scenario resource(s) into the destination scenario tag. Scenario resources weren't exactly something H2V was intended to let us use so it's functionality (assuming all of it is still there) wouldn't have been tested.

Just letting you guys (and you too korn) that reinstalling my H2EK fixed the crash, and my test script works. (Example with physics_set_gravity to 0.5)

Will record a tutorial on it.

[DarkHalo003]

Maybe some tutorials (short ones of course for convenience) on how to script in certain types of advanced stuff:
-Proper sound scripts (where the starting restarts for each new music).
-Rotating cameras.
-Globals (please please please)

Also, something like QuickTips, where it'd give something random each time your opened it, like how to set player speed randomly through a trig or how to do effect explosions (the last wasn't a proper name btw).

[Choking Victim]

IMO, it's better to give thought about future uses of applications such as these. It's good lifecycle practice and makes you think and develop code in a manner which will allow easy extending later on. It really wouldn't be all that difficult to target later engines as long as you make all points about the scripting system definable via .NET assemblies or with XML.

Just my two cents, but if you just want to stick with HaloCE, go for it. It'll be useful and used by people around here either way.
The scripts and globals used in the intellisense and formatting are all defined via an external xml definition. The user can use this application for whichever version of the blam engine they want if they were to define all the scripts and globals for that engine in the xml files, so it's fairly extendable.


Maybe some tutorials (short ones of course for convenience) on how to script in certain types of advanced stuff:
-Proper sound scripts (where the starting restarts for each new music).
-Rotating cameras.
-Globals (please please please)

Also, something like QuickTips, where it'd give something random each time your opened it, like how to set player speed randomly through a trig or how to do effect explosions (the last wasn't a proper name btw).

Well, I'm not necessarily here to teach you how to script. That's on the end user. When I asked for feature requests I meant something more along the lines of something you want auto-formatted or something like teh_lag suggested. Thanks for the input nonetheless.

[Kornman00]

The scripts and globals used in the intellisense and formatting are all defined via an external xml definition. The user can use this application for whichever version of the blam engine they want if they were to define all the scripts and globals for that engine in the xml files, so it's fairly extendable.
The scripting system doesn't just stop there. There are also script types and value types. Some values can be converted to over values (implicitly and explicitly with a casting script function). Halo3+ also allows the scenario scripts to define parameters.

[Dwood]

Does the program recognize globals and then check to see if the globals match the required types of the functions they're used in?

Also, have a separate area for globals to be declared and then another section for the scripts. It's annoying scrolling up and down to double check the global names when you're working with long scripts.

[Kornman00]

Or you could just define all your scenario globals in a separate hsc file

[Shock120]

he used "begin". :beast:

There's probably alot of noobs in scripts, if people want to learn scripts, they should start with the simple ones.
a database integrated with the app, containing simple scripts submitted by the community, may help them tackle on some custom advanced scripts.

When scripts are compiled with custom names, and then linking them in other scripts, autofill? maybe?

any instance of the word begin should be auto removed, and everyone to embark on a worldwide hunt on the person who started this begin trend.

@ CodeBrain
Very nice work, I wish you released a map with that.