Willow and the Storm

Limits on arguments: No way I'm going through every TSC command that takes an argument and putting in a limit check. Plus that takes out fun stuff like <VAJV798:0020:0004:0300. (Jump to 300 if health is greater or equal 20 I think).

The variable data now is just the last 2000 flags. We have... none to burn? But feel free to feed it illegal values to see what kind of fun stuff happens.
Oh and by the way each 'variable' is considered word-length. (16-bits)

And as for divide by zero, again, too lazy. <FOM0000 crashes the game for the same reason...

 

I don't care about the others so much but the skipflags (3 commands), flags (3 commands), and variables (2 commands and VXXX) need limits at least. I'd prefer to not be able to crash the game or cause undesirable effects just because I casually set a variable. All in all it would be so much easier to just go along with the original idea of allocating (is that the right word?) additional ram for variable use. For things like health instead of potentially breaking the game you can use system variables (SXXX). Unlike the standard variable list you cannot edit system variables, only read them. This allows you to use any important value from ram and input it into an argument, including VAR and CMJ.

 

So...about a demo showing off alchemy...

When could that possibly happen?

 

So...about a demo showing off alchemy...

When could that possibly happen?

Uhm...
A week or 8?
I've got the essential TSC commands now, so alchemy will be a piece of cake. :3
...
Granted it won't be nearly as impressive looking all-in-all compared to the huge scripts I've posted before, but eh.

I don't care about the others so much but the skipflags (3 commands), flags (3 commands), and variables (2 commands and VXXX) need limits at least. I'd prefer to not be able to crash the game or cause undesirable effects just because I casually set a variable. All in all it would be so much easier to just go along with the original idea of allocating (is that the right word?) additional ram for variable use. For things like health instead of potentially breaking the game you can use system variables (SXXX). Unlike the standard variable list you cannot edit system variables, only read them. This allows you to use any important value from ram and input it into an argument, including VAR and CMJ.

They will use the last 2000 flags.
There are 120 in total.
The first 5 are reserved for values that are calculated per-frame.
The remaining 115 are usable for whatever.
I'm NOT going (to force Noxid/Lace) to re-do this to include any sort of limiter; especially since there are some pretty neat things you can screw with.

The absolute final command set for WatS:
<VAR
<VAO
<RND
<VAJ
<VAZ

<EXPXXXX - Give current weapon X energy.
<BULXXXX - Spawn bullet X.
<MIMXXXX - Switch to mask X.
<NUMXXXX - Modified to return variable X as text.

As well, VXXX can be passed as an argument to any command.
It substitutes the value of variable X.

Anyways, thanks to these awesome TSC commands, I can now enable BULK ALCHEMY.

So it will essentially go:

Start (Set alchemy flag)
Pick recipe (Set variable X and Y)
* Pick quantity (Set variable Z)
Check IF BaseMaterialAmount>Z, Return *, ELSE continue
Check IF X>0, Return **, ELSE continue
Check IF Y>0, Return **, ELSE continue
Pass XYZ to the alchemy processor
Make items
End
**"You don't have the materials to make this.", Return Start
^ Some sort of psuedo-code

So allow me to open that can of worms once more: What alchemy items should I allow to be created?
As you might be able to gather from the psuedo-code, I am gonna lock in 6 recipes to each of 3 ranks.
HOWEVER.
This is your chance, people.
Tell me what you want your alchemy items to do.

First 2 are already locked in for each tier; a healing potion, weapon energy potion.
If it doesn't involve either of those, I wanna hear it.

 

Agility potion - increases run speed by a bit for say, 30 seconds - 1 min?
Invincibility potion - turns on flashing "invincible" for a bit [might even be a variable that could be accessed / modified with out of bounds <VAR, or just have a TSC event running to turn off collision detection]

 

Agility potion - increases run speed by a bit for say, 30 seconds - 1 min?
Invincibility potion - turns on flashing "invincible" for a bit [might even be a variable that could be accessed / modified with out of bounds <VAR, or just have a TSC event running to turn off collision detection]

Couldn't you just hack an entity to do 0 "damage" but still make you blink? Or is that impossible even if you had russian hackers on your side?

 

Mandrake - causes 20 damage to yourself.

 

For things like health instead of potentially breaking the game you can use system variables (SXXX). Unlike the standard variable list you cannot edit system variables, only read them.

This is definitely a better choice than out-of-bounds VXXX arguments. I can understand why you wouldn't want to do that though; it would require having some sort of lookup table mapping the system constants to their memory location.

In general, though, I completely agree with Andwhyisit. Allowing the program to crash because an out-of-bounds argument was given or because you tried to divide by zero is not a good design. Pixel could get away with it because he never planned to have people write mods, but for this adding the limit check would be a very good plan.

I guess there's no hurry, though...

Uhm...
They will use the last 2000 flags.
There are 120 in total.
The first 5 are reserved for values that are calculated per-frame.
The remaining 115 are usable for whatever.

Uh, your math is a bit off there. Assuming 16-bits variables, 2000 flags is enough for 125 variables, not 120.

And what do you mean by "reserved for values that are calculated per-frame"?

 

This is definitely a better choice than out-of-bounds VXXX arguments. I can understand why you wouldn't want to do that though; it would require having some sort of lookup table mapping the system constants to their memory location.

In general, though, I completely agree with Andwhyisit. Allowing the program to crash because an out-of-bounds argument was given or because you tried to divide by zero is not a good design. Pixel could get away with it because he never planned to have people write mods, but for this adding the limit check would be a very good plan.

I guess there's no hurry, though...

Uh, your math is a bit off there. Assuming 16-bits variables, 2000 flags is enough for 125 variables, not 120.

And what do you mean by "reserved for values that are calculated per-frame"?

Bounds-checking is not required; if you're dumb enough to OOB an argument, then, yeah. You deserve the crash.

And yeah, I know, I know.
But because of the way it works out, the last few don't save properly cm.
And the 'system variables' (variables 0000-0005) are recalculated and updated per-frame.

They are as follows:
- 0000 - Current HP
- 0001 - Max HP
- 0002 - Player Y position
- 0003 - Player X position
- 0004 - Current ammo
- 0005 - Experience until level-up

So, you could pass <SNP0001:V003:V002:0000 to spawn an experience crystal at the player location. :3

 

And yeah, I know, I know.
But because of the way it works out, the last few don't save properly cm.
And the 'system variables' (variables 0000-0005) are recalculated and updated per-frame.

They are as follows:
- 0000 - Current HP
- 0001 - Max HP
- 0002 - Player Y position
- 0003 - Player X position
- 0004 - Current ammo
- 0005 - Experience until level-up

So, you could pass <SNP0001:V003:V002:0000 to spawn an experience crystal at the player location. :3

Sorry but that is hopelessly inefficient. Instead of updating an editable variable every frame it would be so much more efficient to access the values directly. With SXXX you don't need to change much to get it working (at least that is my assumption), you can't edit the values, you don't have to have a operation run in the background continuously updating 6 variables, and there is no risk that you will get an old value when you use the value directly after changing it just because you accidentally got there before it clocked over to the next frame.

 

Sorry but that is hopelessly inefficient. Instead of updating an editable variable every frame it would be so much more efficient to access the values directly. With SXXX you don't need to change much to get it working (at least that is my assumption), you can't edit the values, you don't have to have a operation run in the background continuously updating 6 variables, and there is no risk that you will get an old value when you use the value directly after changing it just because you accidentally got there before it clocked over to the next frame.

Thing is it's faster to update every frame.
And since there's ~50 fps, I don't think you'd have to worry about old values.
Besides, it's cleverly tacked onto an already existing per-frame updating function. :3

 

Sorry but that is hopelessly inefficient. Instead of updating an editable variable every frame it would be so much more efficient to access the values directly. With SXXX you don't need to change much to get it working (at least that is my assumption), you can't edit the values, you don't have to have a operation run in the background continuously updating 6 variables, and there is no risk that you will get an old value when you use the value directly after changing it just because you accidentally got there before it clocked over to the next frame.

Sorry I know DB already replied to this but this has to be the silliest thing I've heard yet. The thing to update six variables is like, a dozen lines of code, in ASM. The additional strain on the engine is so incredibly minimal I can't even fathom how tiny it must be, seeing as the game runs probably tens of thousands of lines every single frame. Anyway, there's no difference between these so-called 'editable variables' and anything else; it's all just RAM somewhere.

You guys talk big but I don't see you all hacking the assemblies here. I know how to get what needs to be done, done, and I don't like to bother with fluff where it's not needed.

 

You guys talk big but I don't see you all hacking the assemblies here. I know how to get what needs to be done, done, and I don't like to bother with fluff where it's not needed.

Whatever, I call it laziness. And I honestly prefer to add the fluff to get something that doesn't look like it was haphazardly thrown together. I get that you prefer to get the result and see everything else as unimportant, but I don't and will always disagree with you in that aspect. I consider limiters and other user input checks important and will strive to improve my code until I am satisfied with it. Last of all I prefer for the language to still feel like TSC.

So since I have not touched x86 assembly before (I only have basic z80 asm experience atm), I need to know what debugger/disassembler you use so that I can attempt it myself.

@DB: I understand that you have what you want, but I would still prefer something cleaner if this is going to be released for public use.

 

So since I have not touched x86 assembly before (I only have basic z80 asm experience atm), I need to know what debugger/disassembler you use so that I can attempt the bloody thing myself.

Ollydebug is what I (and Noxid too I think) use. Works well.

Lace uses an actual disassembler, the only issue with that though is that you have to save the exe every time you want to run it.

 

Ollydebug is what I (and Noxid too I think) use. Works well.

Awesome, thanks. :eek:

 

Well I never said I wasn't lazy - I think I even pointed the fact out a few times already. Anyway, yeah, I use Olly, and I'd recommend it - you should probably use version 2.04 or whatever it is rather than the old one. I still use the old one but only because I'm too used to the way it looks and works.

I look forward to seeing some hacks andwhyisit :]
It's really pretty easy once you get the hang of it. Don't forget the compendium, it's got all the memory and function information you'll probably need.

 

Wait so is boots of dragon actually working on this or is he saying it is "under devolopment"?

I don't wanna sound like the twit who says "WHENZ DIS GONNA GET RELEASED" but really.

 

Wait so is boots of dragon actually working on this or is he saying it is "under devolopment"?

I don't wanna sound like the twit who says "WHENZ DIS GONNA GET RELEASED" but really.

-Insert 'when it's done' image macro-
In all seriousness...
Either really, really soon.
Or 50 years after everyone stops laughing.

 

-Insert 'when it's done' image macro-
In all seriousness...
Either really, really soon.
Or 50 years after everyone stops laughing.

More like 100 years.

I mean, you're trying to cooridinate 3-people so far right? AND you need an artist?

I can wait though.

 

More like 100 years.

I mean, you're trying to cooridinate 3-people so far right? AND you need an artist?

I can wait though.

I'm pretty fair at coordinating people.
And convincing them to help.
And I don't need an artist.
But quality would suffer without one. :3