TSC - Now complete!

It's been a long time coming, but it's official: All TSC commands are now known *precisely* what they do; even the long-misunderstood <CAT.

For your convenience, I bring you this news with a trio quartet of gifts:
[The Complete TSC Notes - HTML and XLS]
[The Complete Modders Guide]
[Updated CE_TSC_Info.txt] < Right click + Save Target As...
[CMG Good Modding Practices (NEW!)]

Of note:

• <CAT is almost the exact same as <TUR, EXCEPT that you place it BEFORE <MSG/2/3, not inside. Additionally, it will work across multiple <MSG/2/3's (stops at <END) and even across script jumps.
• The Y value of <PS+ is not a location, it's an event - The event will be called when you select the item from the menu.
• There is a maximum value for <MP+ - The highest flag you can set without odd effects is 0127. Setting 0128 will result in your character being essentially dead, except you can still shoot. This probably relates to the maximum number of maps in CS.

I hope this finds use among the many modders out there.

- DragonBoots

Ps. The CMG is a work in progress; specific functions will be added slowly. There are, however, a couple handy tables and lists.

 

So that's what <CAT does?
Interesting, that one was always a mystery to me...
Nice work , maybe this should be stickied or something? {Though we do have a lot of stickies in this section...}
At the very least, there's no possible reason for a newbie to say they can't learn TSC now. {Not that there was much before}

 

I said it earlier and I'll say it again: I LOVE YOU.

 

Freakin' awesome.

I think this covers all the basic info that newbies learning their TSC's will need to know. I'll sticky it if you want, but in that case I dunno if this one should stay stickied, since it's basically thisthread-lite.

 

It is exceptionally useful. I'd rather have the full version that tells me what all the commands do, than the one that doesn't.

Sticky it. At least so it won't get lost in the forums.

 

Freakin' awesome.

I think this covers all the basic info that newbies learning their TSC's will need to know. I'll sticky it if you want, but in that case I dunno if this one should stay stickied, since it's basically thisthread-lite.

Yeah, de-sticky that and stickify this. I'm actually going to import my sample scripts into the CMG (after all, it wouldn't be complete without them).

I said it earlier and I'll say it again: I LOVE YOU.

Love you too.
(No kissing this time, please.(Maybe just one~))

So that's what <CAT does?
Interesting, that one was always a mystery to me...
Nice work , maybe this should be stickied or something? {Though we do have a lot of stickies in this section...}
At the very least, there's no possible reason for a newbie to say they can't learn TSC now. {Not that there was much before}

Yeah, <CAT was originally listed as a speed-up text command (in the original TSC note by Kapow), but it never clarified the usage (and thus became confused as useless). That said, I'm disappointed it didn't allow for coloured text like I was hoping... :'(

And TSC is easy.
BBCode - THAT'S hard.

It is exceptionally useful. I'd rather have the full version that tells me what all the commands do, than the one that doesn't.

Sticky it. At least so it won't get lost in the forums.

All the commands are listed in the TSC notes and explained fairly well.
I might get around to doing a specific "W does X when used with Y and Z"-type deal, but that's a helluva lotta commands to extrapolate.
'Sides, the CMG covers the most common screw-ups.

It's funny... A year of procrastinating contemplating doing this, 4 months of researching TSC and 2 weeks of wallbanging over the unknowns boiled down to 6 hours work with a half-hour break...

Also, partial credit to Celticminstrel - We kinda had a quid pro quo via IRC (I *hope* I helped him with the CSC, anyways).
Oddly, the distraction of IRC motivated me. ^^;

Anyways, this is far from finished. Can anyone think of anything I've overlooked?
Entity that is important? (Except 0000... That one is *fairly* obvious...)
Heavilly-used TSC command that should be expanded on?
Anything at all?

- DragonBoots "DB" Tenretni

EDIT: And it's updated, including a new bulletin on the index page. Eat your heart out, standard blog.

 

Hm, I think the <FOB command has a superflous parameter (which is always set to zero) before the camera focus speed parameter. So instead of:

<FOBxxxx

you would say:

<FOB0000:xxxx

 

This might rub you the wrong way because of my passive-aggressiveness lately, but it's also something I want to say. Not at all to discredit your work, this is stuff nobody has bothered doing for nearly three years and you should be, and are, duly praised. But... your sorting of the TSC info text file... while grouping them by type would make sense if there was syntax to separate them thus, as in the html/xls versions, there isn't any, so it kinda looks like the commands were randomly sorted, and has even in the version that was coupled with CE. You probably did it that way because it was more convenient simply to copypasta, and I'll do it for you if you want, but it looks more orderly in alphabetical order.

 

Also, partial credit to Celticminstrel - We kinda had a quid pro quo via IRC (I *hope* I helped him with the CSC, anyways).

Yes, you did... for example with discovering the location of map flags within the save file. And other things that I can't remember just now.

 

Hm, I think the <FOB command has a superflous parameter (which is always set to zero) before the camera focus speed parameter. So instead of:

<FOBxxxx

you would say:

<FOB0000:xxxx

Does it?
I'll check that out.
Though my guess is that it would need to be set to the boss entity #, if anything. ^^;

This might rub you the wrong way because of my passive-aggressiveness lately, but it's also something I want to say. Not at all to discredit your work, this is stuff nobody has bothered doing for nearly three years and you should be, and are, duly praised. But... your sorting of the TSC info text file... while grouping them by type would make sense if there was syntax to separate them thus, as in the html/xls versions, there isn't any, so it kinda looks like the commands were randomly sorted, and has even in the version that was coupled with CE. You probably did it that way because it was more convenient simply to copypasta, and I'll do it for you if you want, but it looks more orderly in alphabetical order.

Eh, alright.
I'll sort it out.
Though I am going to bug ask Wistl if he can add support for some way to seperate commands in CE. ^^;
Although...
Hmmm...

Yes, you did... for example with discovering the location of map flags within the save file. And other things that I can't remember just now.

Well, glad to have helped. ^^;

 

superflous parameter

NO!!!
if there's a parameter it has reason. if whatever cheezy sez is true, I'll investigate it.
That and num.

 

NOT THAT ANYONE CARES but I found out what the numbers on num did.

Take this example script:

#8357
<KEY<MSG<AM+0005:0038
WOWZERS! <NUM0000 AMMO!<NOD<CLR
AND <NUM0001 TOO!<NOD<CLR
<END

- num0000 gets the ammo, as previously noted
- num0001 is annoying. what it should do is

Hidden text highlight (or click) to view:

get the number of chars from the start of the event that the last char in <AM+/whatever (not including numbers) is.

but in actuality, it sorta returns the id of the tsc command. <AM+ is 56(?) ML+ is 17 and so forth.
- other values may do something, but most should ret 0. here's a nifty little table to help you visualize what the command does.

0000	[4a5b34]
0001	[4a5b38]
0002	[4a5b3C]
0003	[4a5b40]

first column is input, second is what's returned.
but that's assembly nerd stuff.

 

Thanks DragonBoots for making this guide, it helped me a lot!

 

NO!!!
if there's a parameter it has reason. if whatever cheezy sez is true, I'll investigate it.
That and num.

NOT THAT ANYONE CARES but I found out what the numbers on num did.

Take this example script:

#8357
<KEY<MSG<AM+0005:0038
WOWZERS! <NUM0000 AMMO!<NOD<CLR
AND <NUM0001 TOO!<NOD<CLR
<END

- num0000 gets the ammo, as previously noted
- num0001 is annoying. what it should do is

Hidden text highlight (or click) to view:

get the number of chars from the start of the event that the last char in <AM+/whatever (not including numbers) is.

but in actuality, it sorta returns the id of the tsc command. <AM+ is 56(?) ML+ is 17 and so forth.
- other values may do something, but most should ret 0. here's a nifty little table to help you visualize what the command does.

0000	[4a5b34]
0001	[4a5b38]
0002	[4a5b3C]
0003	[4a5b40]

first column is input, second is what's returned.
but that's assembly nerd stuff.

Edit button, Laceyface, edit button.

Thanks DragonBoots for making this guide, it helped me a lot!

No prob, dood. :3

 

Permission to add this to the site?

 

Permission granted... Once I fix said mistakes.

^^;

EDIT: Go for it.

EDIT EDIT: On second though, no. At least, not yet. >_>

 

here's a nifty little table to help you visualize what the command does.

0000	[4a5b34]
0001	[4a5b38]
0002	[4a5b3C]
0003	[4a5b40]

first column is input, second is what's returned.
but that's assembly nerd stuff.

The brackets are equivalent to C's * operator, right? So, there's a pointer to 0x4A5B34 (call it "long* p"), and there's the input (call it "int n") and the function returns p+n? (ie it adds n*sizeof(long) to the value of p, where sizeof(long) = 4.)
Something like this:

[color=#7F7F7F]void[/COLOR] NUM([color=#7F7F7F]int[/COLOR] n) {
    [color=#7F7F7F]static const long[/COLOR]* p = [color=#7F7F7F]0x4A5B34[/COLOR];
    printf("%d",*(p+n));
}

Except of course it's printing to the screen rather than the console, and the pointer is more likely a global than a static local... and it may not be const either.

Also... why do you list absolute addresses? Would the addresses be different if you started another program before running Cave Story? They are RAM addresses, right? What is stored at that address? Would it be possible to locate where in the program the memory at that address is allocated so that you can determine how much memory was allocated there? If only four bytes were allocated, then any input other than 0 is probably useless.

-Calling an event on interaction (pressing down). Setting flag 2000 (see Entities) on an entity will do *two* things: make it non-hostile, non-shootable (see the Gaudi in the Labyrinth shop) and make it run an event when interacted with. <-- two should be three, and there should be a comma before the last and

Said comma is optional, and if he said "make it non-hostile and non-shootable (...), and make it run an event" then it could be considered as two things. (In that case the comma isn't optional, though.)

-If you wish to use *.bmp as your image extension, just change the file extension in CE. It will automatically change all the *.pbm's* into *.bmp's*. <-- remove apostrophes

I dunno... there are legitimate cases where an apostrophe is used in a plural (eg A's instead of As to pluralize the letter A), and I think this might be one of them. In fact, taking out the apostrophe might even cause a bit of confusion... but on the other hand, leaving out the apostrophe isn't really incorrect...

Permission to add this to the site?

While you're at it, perhaps you could also add the new version of my Python script?

 

Said comma is optional, and if he said "make it non-hostile and non-shootable (...), and make it run an event" then it could be considered as two things. (In that case the comma isn't optional, though.)

Eh, I decided to got for the 3 list.

I dunno... there are legitimate cases where an apostrophe is used in a plural (eg A's instead of As to pluralize the letter A), and I think this might be one of them. In fact, taking out the apostrophe might even cause a bit of confusion... but on the other hand, leaving out the apostrophe isn't really incorrect...

Well, seeing as there has historically been a need to worry about an apostrophy when pluralizing file extentions.
My thought: Use it if the extension is lower case and not (but lower case 's') in the event the extension is upper case. ^^;

While you're at it, perhaps you could also add the new version of my Python script?

Get your own thread. >
Please just link it, though.
My site needs moar traffic.

 

The brackets are equivalent to C's * operator, right? So, there's a pointer to 0x4A5B34 (call it "long* p"), and there's the input (call it "int n") and the function returns p+n? (ie it adds n*sizeof(long) to the value of p, where sizeof(long) = 4.)
Something like this:

[color=#7F7F7F]void[/COLOR] NUM([color=#7F7F7F]int[/COLOR] n) {
    [color=#7F7F7F]static const long[/COLOR]* p = [color=#7F7F7F]0x4A5B34[/COLOR];
    printf("%d",*(p+n));
}

Except of course it's printing to the screen rather than the console, and the pointer is more likely a global than a static local... and it may not be const either.

I believe so, I'll just give you a picture of the memory it accesses if it's all good with you, I'm not very good at C.

0x4A5B34: [color=#7F7F7F]00 00 00 0A[/COLOR] [color=#7F7F7F]00 00 00 11[/COLOR] [color=#7F7F7F]00 00 00 00[/COLOR] [color=#7F7F7F]00 00 00 00[/COLOR]

if n is 0, it points to the memory in red, if it's 1, it points to purple, etcetera.

What is stored at that address?

well, at 0x4A5B34 the number that was just +'d or whatnot is stored, +0x04 seems to be some sort of tsc id, nothing is stored at the next two bytes, and I dunno what's stored beyond that.
for example, the color coded memory above would show that you had just used <ML+0010.

Also... why do you list absolute addresses? Would the addresses be different if you started another program before running Cave Story? They are RAM addresses, right?

I'm not really sure how the ram in cs (or in general, really) works, but the addresses never change. And yes, they are RAM addresses.

Would it be possible to locate where in the program the memory at that address is allocated so that you can determine how much memory was allocated there? If only four bytes were allocated, then any input other than 0 is probably useless.

Sort of. As far as I know, this memory is just part of the massive RAM allocation that most things are stored in,* and it's not specifically allocated, so it isn't limited to just those four bytes. They are the most readily accessible, yes, and probably the purpose of NUM, but if you put a massive number in, you might get to some other bits of ram.

oh yeah, as far as putting massive numbers into tsc goes, you can use chars instead of numbers, your entire keyboard holds higher values except !#$%^&*()-+'"., and space. also, don't use <. cause it'll smash your head in half. Furthermore, by doing <ML+~~~~, you can toggle between infinite and 0 health.

*to my knowledge, just the maps, tsc scripts, BIG bosses, etcetera have ram reserved for them.

 

So... 0x4A5B34 holds the first argument to the command, while 0x4A5B34 holds the id of the command.

It seems to me that it would be a bad idea to use any argument other than 0 to <NUM, then.

Sort of. As far as I know, this memory is just part of the massive RAM allocation that most things are stored in,* and it's not specifically allocated, so it isn't limited to just those four bytes. They are the most readily accessible, yes, and probably the purpose of NUM, but if you put a massive number in, you might get to some other bits of ram.

What I really wanted to know is if there's a way to determine the size of the variable that was allocated at that memory location, but it seems that it's probably just a long. If it were an array of long, I would have suggested that the maximum meaningful input to <NUM was the length of said array. But it doesn't look like there's an array here.