TSC - Now complete!

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.

Let me guess. Pixel doesn't actually check if the values are digits, but simply subtracts 0x30 ('0', 48) from them and then adds them up using the formula (1000a + 100b + 10c + d) (for a given number abcd).

Since '~' is 0x7E or 254, that means '~~~~' would encode the number 282194. Am I correct, or way off?

Also, I'd expect that '^' would work, but '/' would not... and did you check if those "!#$%^&*()-+'".,/" give negative values?

 

Let me guess. Pixel doesn't actually check if the values are digits, but simply subtracts 0x30 ('0', 48) from them and then adds them up using the formula (1000a + 100b + 10c + d) (for a given number abcd).

Since '~' is 0x7E or 254, that means '~~~~' would encode the number 282194. Am I correct, or way off?

correct without deviation.
~ is the highest value you can get besides delete, but you can't input that,which is why I ignored it. As far as the actual number, 0x7e - 0x30 = 0x4e = 78.
78+780+7800+78000 = 86658, which should be more than enough for all your tsc needs. Now, I dont know why the life was reset to 0, but I imagine the complete overflow of the ram, as normal decimal values would only take up to 270f in hex (two bytes allocated). 86658 is 15282(three bytes, where only two are allocated). If there is in fact this overload issue, the highest value intakable would be ffff, or 65535, which would be _535.

Also, I'd expect that '^' would work, but '/' would not...

why?

And did you check if those "!#$%&*()-+'".,/" give negative values?

No, but they should. Erm, These would be (decimal conversion):

[size=1][color=#7F7F7F](space)[/COLOR]	[color=#7F7F7F]-16[/COLOR]	|	[color=#7F7F7F]1[/COLOR]	[color=#7F7F7F]1[/COLOR]
[color=#7F7F7F]![/COLOR]	[color=#7F7F7F]-15[/COLOR]	|	[color=#7F7F7F]2[/COLOR]	[color=#7F7F7F]2[/COLOR]
[color=#7F7F7F]"[/COLOR]	[color=#7F7F7F]-14[/COLOR]	|	[color=#7F7F7F]3[/COLOR]	[color=#7F7F7F]3[/COLOR]
[color=#7F7F7F]#[/COLOR]	[color=#7F7F7F]-13[/COLOR]	|	[color=#7F7F7F]4[/COLOR]	[color=#7F7F7F]4[/COLOR]
[color=#7F7F7F]$[/COLOR]	[color=#7F7F7F]-12[/COLOR]	|	[color=#7F7F7F]5[/COLOR]	[color=#7F7F7F]5[/COLOR]
[color=#7F7F7F]%[/COLOR]	[color=#7F7F7F]-11[/COLOR]	|	[color=#7F7F7F]6[/COLOR]	[color=#7F7F7F]6[/COLOR]
[color=#7F7F7F]&[/COLOR]	[color=#7F7F7F]-10[/COLOR]	|	[color=#7F7F7F]7[/COLOR]	[color=#7F7F7F]7[/COLOR]
[color=#7F7F7F]'[/COLOR]	[color=#7F7F7F]-9[/COLOR]	|	[color=#7F7F7F]8[/COLOR]	[color=#7F7F7F]8[/COLOR]
[color=#7F7F7F]([/COLOR]	[color=#7F7F7F]-8[/COLOR]	|	[color=#7F7F7F]9[/COLOR]	[color=#7F7F7F]9[/COLOR]
[color=#7F7F7F])[/COLOR]	[color=#7F7F7F]-7[/COLOR]	|	[color=#7F7F7F]:[/COLOR]	[color=#7F7F7F]10[/COLOR]
[color=#7F7F7F]*[/COLOR]	[color=#7F7F7F]-6[/COLOR]	|	[color=#7F7F7F];[/COLOR]	[color=#7F7F7F]11[/COLOR]
[color=#7F7F7F]+[/COLOR]	[color=#7F7F7F]-5[/COLOR]	|	[color=#7F7F7F]<[/COLOR]	[color=#7F7F7F]12[/COLOR]
[color=#7F7F7F],[/COLOR]	[color=#7F7F7F]-4[/COLOR]	|	[color=#7F7F7F]=[/COLOR]	[color=#7F7F7F]13[/COLOR]
[color=#7F7F7F]-[/COLOR]	[color=#7F7F7F]-3[/COLOR]	|	[color=#7F7F7F]>[/COLOR]	[color=#7F7F7F]14[/COLOR]
[color=#7F7F7F].[/COLOR]	[color=#7F7F7F]-2[/COLOR]	|	[color=#7F7F7F]?[/COLOR]	[color=#7F7F7F]15[/COLOR]
[color=#7F7F7F]/[/COLOR]	[color=#7F7F7F]-1[/COLOR]	|	[color=#7F7F7F]@[/COLOR]	[color=#7F7F7F]16[/COLOR]
[/size]

so the negative equivalent of <ML+0010 would be <ML+00/0 or <ML+000&, just as normal +0010 could be simplified to +000:

blablabla.

stuff for your ease and my boredom:
- I done went and color coded it. hex, dec, tsc.
- I shalt updater w/ new table soon-ish. copypasta broke again. (dun)
- I think this is sorta cool. TALK!

 

I like the colours this thread has.
But, Lace, does that mean we can do ML- with the standard ML+ command?

 

it appears so.
I mean, I dun see why not.

and ml=, too;
just ml+~~~~ either one or two times to set it to 0, and then + whatever you want it to be.

Erm, all this is as yet untested, but it should work.
like, go test it.

 

correct without deviation.
~ is the highest value you can get besides delete, but you can't input that,which is why I ignored it. As far as the actual number, 0x7e - 0x30 = 0x4e = 78.
78+780+7800+78000 = 86658, which should be more than enough for all your tsc needs. Now, I dont know why the life was reset to 0, but I imagine the complete overflow of the ram, as normal decimal values would only take up to 270f in hex (two bytes allocated). 86658 is 15282(three bytes, where only two are allocated). If there is in fact this overload issue, the highest value intakable would be ffff, or 65535, which would be _535.

why?

No, but they should. Erm, These would be (decimal conversion):

[size=1][color=#7F7F7F](space)[/COLOR]	[color=#7F7F7F]-16[/COLOR]	|	[color=#7F7F7F]1[/COLOR]	[color=#7F7F7F]1[/COLOR]
[color=#7F7F7F]![/COLOR]	[color=#7F7F7F]-15[/COLOR]	|	[color=#7F7F7F]2[/COLOR]	[color=#7F7F7F]2[/COLOR]
[color=#7F7F7F]"[/COLOR]	[color=#7F7F7F]-14[/COLOR]	|	[color=#7F7F7F]3[/COLOR]	[color=#7F7F7F]3[/COLOR]
[color=#7F7F7F]#[/COLOR]	[color=#7F7F7F]-13[/COLOR]	|	[color=#7F7F7F]4[/COLOR]	[color=#7F7F7F]4[/COLOR]
[color=#7F7F7F]$[/COLOR]	[color=#7F7F7F]-12[/COLOR]	|	[color=#7F7F7F]5[/COLOR]	[color=#7F7F7F]5[/COLOR]
[color=#7F7F7F]%[/COLOR]	[color=#7F7F7F]-11[/COLOR]	|	[color=#7F7F7F]6[/COLOR]	[color=#7F7F7F]6[/COLOR]
[color=#7F7F7F]&[/COLOR]	[color=#7F7F7F]-10[/COLOR]	|	[color=#7F7F7F]7[/COLOR]	[color=#7F7F7F]7[/COLOR]
[color=#7F7F7F]'[/COLOR]	[color=#7F7F7F]-9[/COLOR]	|	[color=#7F7F7F]8[/COLOR]	[color=#7F7F7F]8[/COLOR]
[color=#7F7F7F]([/COLOR]	[color=#7F7F7F]-8[/COLOR]	|	[color=#7F7F7F]9[/COLOR]	[color=#7F7F7F]9[/COLOR]
[color=#7F7F7F])[/COLOR]	[color=#7F7F7F]-7[/COLOR]	|	[color=#7F7F7F]:[/COLOR]	[color=#7F7F7F]10[/COLOR]
[color=#7F7F7F]*[/COLOR]	[color=#7F7F7F]-6[/COLOR]	|	[color=#7F7F7F];[/COLOR]	[color=#7F7F7F]11[/COLOR]
[color=#7F7F7F]+[/COLOR]	[color=#7F7F7F]-5[/COLOR]	|	[color=#7F7F7F]<[/COLOR]	[color=#7F7F7F]12[/COLOR]
[color=#7F7F7F],[/COLOR]	[color=#7F7F7F]-4[/COLOR]	|	[color=#7F7F7F]=[/COLOR]	[color=#7F7F7F]13[/COLOR]
[color=#7F7F7F]-[/COLOR]	[color=#7F7F7F]-3[/COLOR]	|	[color=#7F7F7F]>[/COLOR]	[color=#7F7F7F]14[/COLOR]
[color=#7F7F7F].[/COLOR]	[color=#7F7F7F]-2[/COLOR]	|	[color=#7F7F7F]?[/COLOR]	[color=#7F7F7F]15[/COLOR]
[color=#7F7F7F]/[/COLOR]	[color=#7F7F7F]-1[/COLOR]	|	[color=#7F7F7F]@[/COLOR]	[color=#7F7F7F]16[/COLOR]
[/size]

so the negative equivalent of <ML+0010 would be <ML+00/0 or <ML+000&, just as normal +0010 could be simplified to +000:

blablabla.

stuff for your ease and my boredom:
- I done went and color coded it. hex, dec, tsc.
- I shalt updater w/ new table soon-ish. copypasta broke again. (dun)
- I think this is sorta cool. TALK!

You just broke reality, Lace.
Way to go.

But, uh, wow.
This means big things.
It means that it's possible to switch characters (including the health).
It means negative flags(?).
It means Wistl has a lot of work to do to fix the CE TSC editor to handle non-numerical arguments.
It means I have something to put in the advanced section.

 

Yeah, this is pretty revolutionary. I recall a post/thread by Rune somewhere that said you could, by setting obscenely large flags, mess with the data and do something like modify the screen flash colour.

So, what's right before the flag data, anything interesting?

EDIT: This is what I have:

0049E190 OccasionalFlash If set to true, the screen flashes occasionally.
0049E1C4 FlashColor [Color of the flash, RGB]
0049E1DC SoftQuakeDuration [How long the screen shakes for. Soft shake.]
0049E1E0 HardQuakeDuration [How long the screen shakes for. Hard shake.]
0049E1E4 CursorPosition [Cursor position ID, maybe just for the title screen...]
0049E1E8 GameState [0: title, 3: normal play, 4 game over/black fade, 5 event, 7 status screen; &2=accepts input]
0049E1EC GameTime
0049E1F0 DirectInputObj [Instance of the Direct Input object, once created.]
0049E328 FullExePath [Full path to the executable.]
0049E37C (last possible flag...)
0049E44C AppInstance
0049E458 AppWinHandle
0049e464 ShowFPS [Set to non-zero to have an FPS counter.]
0049E468 CanAcceptInput [Set to 0 when focus is lost. Locks keyboard when unset.]
0049e46C Timer1000Time [Final Time the 1000 timer took to complete.]
0049e470 Timer1000Elapsed [Time elapsed during the 1000 tick counter's countdown.]
0049e474 Timer1000Ticks [Timer updated every 1000 ticks.]
0049E5B8 ???, x 0x0080 MPJ array, indexed by map ID...

 

It means that it's possible to switch characters (including the health).
It means negative flags(?).
It means Wistl has a lot of work to do to fix the CE TSC editor to handle non-numerical arguments.
It means I have something to put in the advanced section.

Responses in order:
- Quite true, young chap. You'd need to use other flags to track health, though.
- reccomend against it, you'd be using something elses memory, which would cause that to do weird things. sorta like how flags above 8000 an be wacko, except it happens immediately when you go backwards*.
- Meh.
-

You just broke reality, Lace.
Way to go.

Thanks a cow, but, errr, can someone test this? please?
I know for a fact all the positive values work, and that the +~~~~ clears*, but negative stuff is just... sorta... hypothetical.
SHOULD work though.

*Yeah, this is what noxid said, too. not sure at the location of the flag memory, but there is sure to be some little scrum of weird data. specially with being able to go back so far.
*only on hp. just makes weapons have massive ammo.

 

It also means that non-numerical characters need to be mapped at values...
And I did a random test with j.
Massive health was obtained.
Hmmm... >_>

 

I just tested it, and, ML- with ML+000, worked like a charm. However, it got kinda screwy when I did that ML+~~~~ wherein it would show 0 HP, I'd still be alive, and my ML+0004 and ML+000, entities wouldn't do anything. Player health is only two bytes long, so... it may be doing strange things.

 

However, it got kinda screwy when I did that ML+~~~~ wherein it would show 0 HP, I'd still be alive, and my ML+0004 and ML+000, entities wouldn't do anything. Player health is only two bytes long, so... it may be doing strange things.

Strange, when I tried <ML+~~~~, it displayed 9999 health on my counter, and I took several hits from a Basil {100 damage a hit} without it dropping.
Same thing with <ML+000! and <ML+000/, too.... {So much for negatives?}
Nevermind, apparently I screwed up my entity numbers.
<ML+000! gave about 81 life, but <ML+000/ actually subtracted 1 each time, and when I hit 0 the game crashed.

 

Oh, right, well, what I actually did was try <ML+~~~~<ML+~~~~<ML+0010 to get the desired ML= effect, but it failed on me.
And, when I used ML+000, the increment was 4, and when I got to 0 things still ran fine >.>
Your problem might be because you made it hit exactly 0, which the game didn't like. I probably pushed it to something like FFFD or whatever.

EDIT: Furthermore, after said below-zero healthifying, I was able to bring it back up incrementally to 1, 5, 9, etc.

EDIT2 (3?): interesting find: Using ML+ to incrementally take your health above 225 or whatever starts pushing your health bar outside the holder at a linear rate. Using ML+ to start bringing it down after that keeps pushing it out, but the rate seems to accellerate! Then, I used ML+ and the thing started going back down at the rate it was going up, so now I'm moving large chunks of health bar up when I ML+000, and down when I <ML+0004. Oh, I made it too big and the game crashed. According to Visual Studio 2008, it had a divide by zero error.

Unhandled exception at 0x0041a2c6 in Doukutsu.exe: 0xC0000094: Integer division by zero.

Further analysis shows that [49e6D0] that was the offending 0, however at the time the number of my health showed 49 >.>

 

Your problem might be because you made it hit exactly 0, which the game didn't like. I probably pushed it to something like FFFD or whatever..

Yeah, it kinda acted fine when I removed more health than I had and went right past 0.
But then it started acting funny for me, compared to:

EDIT: Furthermore, after said below-zero healthifying, I was able to bring it back up incrementally to 1, 5, 9, etc.

My health counter went back up to 9999 when I went past 0, and I couldn't 'bring it up', so even after trying <ML+000! to get that invincible goodness I had earlier, the Basil still one hitted me.

Unhandled exception at 0x0041a2c6 in Doukutsu.exe: 0xC0000094: Integer division by zero.

Garsh, isn't this fun.

EDIT:
Alright, I think I see that I've actually been getting the same exact things as Noxid, it's just that the counter showing 9999 whenever I had gone below 0 made it hard to tell.
{Messing with <ML+~~~~ at the same time didn't help}

 

You would definitely get the "divide by 0" error if your max hp was 0, since the game calculates how to draw your current hp by dividing your current hp by your max and then multiplying it by the total width of the hp bar (something like that, been awhile since i've looked at the original code for the hp bar).

You can set your current hp (not max hp) to something negative, and the game won't kill you (unless you hit a damage dealing entity) which pretty much makes it so that 0 or less current hp is the same as having 1 hp.

 

You would definitely get the "divide by 0" error if your max hp was 0, since the game calculates how to draw your current hp by dividing your current hp by your max and then multiplying it by the total width of the hp bar (something like that, been awhile since i've looked at the original code for the hp bar).

How come it overflows for 255 HP then?

 

How come it overflows for 255 HP then?

I did some test with adding 252 hp at a time, and it appears that the max hp has a cap for how much can be added to it with the <ML+. If you set the max hp with a save edit or something, it will be fine. But the <ML+ capped my max hp at E8 (232).

Oh here's the ASM for ML+, where you can even see where it caps the HP at E8. Even though it does this, it does not cap the current hp.

00419CB0  /$ 55             PUSH EBP
00419CB1  |. 8BEC           MOV EBP,ESP
00419CB3  |. 0FBF45 08      MOVSX EAX,WORD PTR SS:[EBP+8]
00419CB7  |. 0FBF0D D0E649  MOVSX ECX,WORD PTR DS:[49E6D0]
00419CBE  |. 03C8           ADD ECX,EAX
00419CC0  |. 66:890D D0E64  MOV WORD PTR DS:[49E6D0],CX
00419CC7  |. 0FBF15 D0E649  MOVSX EDX,WORD PTR DS:[49E6D0]
00419CCE  |. 81FA E8000000  CMP EDX,0E8
00419CD4  |. 7E 09          JLE SHORT Doukutsu.00419CDF
00419CD6  |. 66:C705 D0E64  MOV WORD PTR DS:[49E6D0],0E8
00419CDF  |> 0FBF45 08      MOVSX EAX,WORD PTR SS:[EBP+8]
00419CE3  |. 0FBF0D CCE649  MOVSX ECX,WORD PTR DS:[49E6CC]
00419CEA  |. 03C8           ADD ECX,EAX
00419CEC  |. 66:890D CCE64  MOV WORD PTR DS:[49E6CC],CX
00419CF3  |. 0FBF15 CCE649  MOVSX EDX,WORD PTR DS:[49E6CC]
00419CFA  |. 8915 D4E64900  MOV DWORD PTR DS:[49E6D4],EDX
00419D00  |. 5D             POP EBP
00419D01  \. C3             RETN

So basically it does it's calculations right graphics wise, except since you have more current hp than max hp, your bar begins to overflow.

 

I remember messing with save edit. If you increase your health with it, it stays in the health bar until you mess with a health canister, where it overflows from 255.

 

So basically it does it's calculations right graphics wise, except since you have more current hp than max hp, your bar begins to overflow.

Oh crap lol, I thought that 255 WAS the max.
*Fixes Hell mod*

 

why?

Because '/' is less than '0', but '^' is greater than '0'.

so the negative equivalent of <ML+0010 would be <ML+00/0 or <ML+000&, just as normal +0010 could be simplified to +000:

We should probably work out a standard representation for these. My suggestion is to only use symbols in the leftmost digits for large numbers, and for negative numbers to use the same "spelling" as for equivalent positive numbers, but with the symbols /.-,+*)(' instead of the symbols 123456789.

Spoiler

(etc)
00/. -12
00// -11
00/0 -10
000' -9
000( -8
000) -7
000* -6
000+ -5
000, -4
000- -3
000. -2
000/ -1
0000 0
0001 1
(etc)
9999 9999
:000 10000
:001 10001
(etc)
:999 10999
;000 11000
;001 11001
(etc)
;999 11999
<000 12000
<001 12001
(etc)
<999 12999
=000 13000
=001 13001
(etc)
=999 13999
>000 14000
>001 14001
(etc)
>999 14999
?000 15000
?001 15001
(etc)
?999 15999
@000 16000
@001 16001
(etc)
@999 16999
A000 17000
A001 17001
(etc)
A999 17999
B000 18000
B001 18001
(etc)
B999 18999
C000 19000
C001 19001
(etc)
C999 19999
D000 20000
E000 21000
F000 22000
G000 23000
H000 24000
I000 25000
J000 26000
K000 27000
L000 28000
M000 29000
N000 30000
O000 31000
P000 32000
Q000 33000
R000 34000
S000 35000
T000 36000
U000 37000
V000 38000
W000 39000
X000 40000
Y000 41000
Z000 42000
[000 43000
\000 44000
]000 45000
^000 46000
_000 47000
`000 48000
a000 49000
b000 50000
c000 51000
d000 52000
e000 53000
f000 54000
g000 55000
h000 56000
i000 57000
j000 58000
k000 59000
l000 60000
m000 61000
n000 62000
o000 63000
p000 64000
q000 65000
r000 66000
s000 67000
t000 68000
u000 69000
v000 70000
w000 71000
x000 72000
y000 73000
z000 74000
{000 75000
|000 76000
}000 77000
~000 78000
~999 78999
~:00 79000
~;00 79100
~<00 79200
~=00 79300
~>00 79400
(etc)
~}00 85700
~~00 85800
~~:0 85900
~~;0 85910
~~<0 85920
~~=0 85930
~~>0 85940
(etc)
~~}0 86570
~~~0 86580
~~~9 86589
~~~: 86590
(etc)
~~~D 86600
~~~N 86610
~~~X 86620
~~~b 86630
~~~l 86640
~~~v 86650
~~~w 86651
~~~x 86652
~~~y 86653
~~~z 86654
~~~{ 86655
~~~| 86656
~~~} 86657
~~~~ 86658

It means Wistl has a lot of work to do to fix the CE TSC editor to handle non-numerical arguments.

Why?

Yeah, this is pretty revolutionary. I recall a post/thread by Rune somewhere that said you could, by setting obscenely large flags, mess with the data and do something like modify the screen flash colour.

I wouldn't make a mod rely on this sort of thing, though.

So, what's right before the flag data, anything interesting?

If the RAM is arranged in the same way as the profile.dat (which is quite likely, but not definite), then before the flag data is the word "FLAG", and before that is the map flags (which the original game does not use).

- reccomend against it, you'd be using something elses memory, which would cause that to do weird things. sorta like how flags above 8000 an be wacko, except it happens immediately when you go backwards

Well, if the RAM is laid out like the profile.dat, then flags -1, -2, -3, and -4 would probably be safe.

Using ML+ to start bringing it down after that keeps pushing it out, but the rate seems to accellerate!

Because it doesn't alter the current health.

Oh crap lol, I thought that 255 WAS the max.
*Fixes Hell mod*

Actually, 255 is the maximum health the game will accept, but it's only obtainable by save editing. Anything higher will result in the game reverting your health to 0.

But 232 is a cap with <ML+.

 

It means Wistl has a lot of work to do to fix the CE TSC editor to handle non-numerical arguments.

Why?

The editor will say "Error in Syntax" whenever you try saving using these symbols in place of numbers.
It gets rather annoying after awhile.
You can also see this error when modifying the Head TSC script, because this is tucked in at the bottom:

#0049
<CLO<FAO0004<ESC


[B]XX: head.tsc   4000 - 4099
4000:Almond…“ï[/B]

{And this bit of code is thought to be the reason you don't die when your breath counter hits 0 in the Core room}

 

Actually, 255 is the maximum health the game will accept, but it's only obtainable by save editing. Anything higher will result in the game reverting your health to 0.

Wrong. Health is stored in profile.dat as a double-byte value. Values over 32767 (7FFF) are reverted to zero, values between 10000 and 32767 are interpreted as 9999 by the game (270F), anything below that is exactly the amount specified in profile.dat when the game loads.

So 9999 is the maximum health the game will accept.