As far as I can tell, the CS can handle huge SCTX ( I got it to save one that was about 3MB in size ) records. So as long as you save your script in an OBSE-extended CS instance, the sky's the limit. But I do have to allocate a buffer to transfer the text from the CS to my editor; currently at 2MB on the heap.

Removed, pragmatically - The upper limit was set to the 16MB.

Wow, that is so cool to have! I admit, C++ has kinda spoiled me compared to Oblivion's scripting.

Anyways, I got a request that I've been meaning to post. I sometimes use underscores in function scripts and I know some people do it alot, up until OBSE introduced user functions I thought that the underscore simply wasn't displayed in the list of scripts. But then I tried calling a user function and it complained that it couldn't find it. Removing the underscore in the function call fixed the error and everything worked fine. But I sometimes really really want an underscore in the name (call me nitpicky ) so I'm hoping you can change this. Maybe by tricking the cs in some fancy way :whistling:

Lol, if someone reaches 16MB then they really did something wrong.

-kyoma

The CS truncates any non-alphanumeric character present in the script name at compile time. This shouldn't be hard to workaround, as I cache scripts in the IntelliSense database as it is. I can look for call statements while preprocessing and swap the correct editorID.

Yeeeeee.

Another request. Or, if it's been requested, a vote in favor :whistling:

It'd be nice if Ctrl-click emulated double clicking and selected the entire word.

This is a first. Implemented.

By the way, I've patched the CS to save ESP plugins as masters. In other words, ESPs no longer need to be ESMified. You simply load them as you would any other master file and save your plugin. A quick test revealed that record overriding worked without any hitches. The next thing I shall probably be looking at is getting the CS to treat ESMs as ESPs so that they can be modified without having to flip the bit beforehand.

Even though I am very excited to hear that you are adding such a feature I'd also like to remind you actually release the plugin at some point. Instead of continuously adding new, fantastic features. Or is the big hold up with OBSE v18a?

True, true. Mustn't forget that :nono: That said, the CS can now edit ESM files directly - Simply set one as an active file and use it like an ESP file. Haven't tested it much though - My patch is likely to have a side effect or two. Also, the Author and Description fields in the Data dialog now fully support ESMs - They are no longer disabled (meaning you can modify their data right off the window) and the author name no longer stubbornly says "Bethesda Game Studios".

The next item on the list reads "Fix the 73-bytes compiler bug". This be a lot harder. I'll probably reward myself handsomely if I can pull it off.

By the way, do you folks know of any other CS quirks that could use a fix ?

Mostly this. The plugin currently uses an updated version of the API to get the addresses of the CommandTable. While I can directly pull those from the executable, I also expect command return type info to be exposed in the upcoming update. And not to mention a fix for a couple of delinquent class definitions.

EDIT: Added the ability to directly save plugins as ESMs.

I wish I could put in words how much I'm looking forward to this. I'm not poetic enough though, so I'll settle for emoticons.

:shocking: :celebration: :hubbahubba: :foodndrink: :goodjob: :twirl: :woot: :clap: :tops: :rock:

Damn the 10-smilies-at-most board limit; dammit!

I figured out where the CS stores its data handler and scruggsy has been kind enough to decode most of it for me. Once I get the updated API, I can get around to fix the recompile all handler to just recompile scripts in the active plugin - I've already located a cozy address to hook at.

You've probably thought of it already, but a potential problem with recompiling all the scripts at once comes to mind. Script interdependence.

If Script A refers to a variable in Script B, then Script B has to be compiled before Script A. Otherwise, Script A will complain that it can't find the needed variable.

Rather than inspecting each script to determine the proper compile order, it'd likely be easier to work around these issues by compiling the scripts in multiple passes. Compile what will compile, and then go back and try the failed compiles again until either they've all compiled or some max try limit has been reached.

Quality over quantity..... :mellow: Now that is an all-saying-smiley

I don't think this should be an issue as the CS takes care of this on its own - I shall only be placing a sentry to make sure script objects not belonging to the active plugin are skipped.

This looks awesome for the script kiddies! :read: :flamethrower: :rock:

Interesting... I did not expect human-evolution to happen this quickly... No wait, this is just game evolution - oh well

P.S. Awesome work ShadeMe, it would be interesting to see a snippet of your code just to see how you've done this magic...

A lot of leg work involved. The OBSE plugin itself does nothing more than patch the CS - The script editor is a separate DLL that is linked at runtime and communicates through the interface laid out by the parent plugin.

i'd like to be able to make a script in the CS and if it's wrong (happens a lot with me) I can still save it for another time

You can use the Dump script tool to save your script to a text file.

A ton of new features have been added since my last update to this thread. I'll compile a list of changes and get it posted.

Really looking forward to this, I won't have to do all of my scripting in Notepad++ anymore

I seriously can't think of anything else to suggest so I'll just :hugs:

I've never personally run into this problem but others have, make sure it notices if you have an empty 'endif' line, and make it appear like a normal error.

You reminded me of something.

Can you check for empty elseif lines (an elseif without a condition) and make it appear as an error? This makes the script fail to save, and it won't error either, so it takes forever to find the problem if you don't know whats wrong. I would be very grateful for this, as it has sapped a lot of valuable scripting time for me in the past.