Willow and the Storm

That's the current state of affairs, yes, but why not make a separate section in the profile for the variables? Wouldn't that be a bit easier?

No, because 90% of variables do not need to be saved.

 

No, because 90% of variables do not need to be saved.

Suppose if variables and flags were made inheritly inter-complexed?
Hm.
Just a thought, anyways.
I mean, having the abillity to save variables and recall them could be invaluble.
Though, in an idealist world...
<VBSXXXX:YYYY:ZZZZ - Save Variable X to bitwise flag range Y:Z
<VBLXXXX:YYYY:ZZZZ - Read range X:Y and store in Variable Z

Those two commands, along with an increment and a decrement could allow so much simplification of the existing script (I estimate a total savings of 10k+ characters).

I mean...

#0100
<VA+0001:V002<VBS0001:0100:0107<END // Increment by V002 and save
#0101
<VA-0001:V002<VBS0001:0100:0107<END // Decrement by V002 and save
#0102
<VBL0100:0107:V002<VA+0002:0100<EVEV0002 // Load to V002, add 100 and run the resulting event [An Example - Could also just load it and print it as text]

Voila!
The above is the entirety of what is needed for an increment/decrement script.

andwhy already said that, basically. >w<
Although...


Lemme idealize:

*All commands can take between V000 and V255 as an argument, using the resulting variables' value*

=Required=
<VARXXXX:YYYY - Set VarX to Y
<VA+XXXX:YYYY - Increment VarX by Y
<VA-XXXX:YYYY - Decrement VarX by Y
<VASXXXX:YYYY:ZZZZ - Save X to flag range Y:Z
<VALXXXX:YYYY:ZZZZ - Load to X from flag range Y:Z

=Optional=
<VAJWWWW:XXXX:YYYY:ZZZZ - Jump to event W if VarX compares true to Y with method Z
<VAPXXXX - Displays variable X as text
<VAGXXXX - Generate a random number and save it to variable X
<INAXXXX - Displays a NSFW picture of Misery for variable X ticks (JayKay)

=Debugging tools=
<VADXXXX - Dump all variables to flag range starting at X, ending as required
<VAF - Dump all variables as their value + variable number flags (Eg. Var0001 = 1312, so the resulting flag set is 1313)

=Methods=
0000 - Equal (X=Y)
0001 - Greater than (X>Y)
0002 - Less than (X<Y)
0003 - Not equal to (X=/=Y)
0004 - Equal to or greater than (X>/=Y)
0005 - Equal to or less than (X</=Y)

=Inherit Things=
<FL+VXXX - Set flag VarX
<FL-VXXX - Clear flag VarX
<EVEVXXX - Run event VarX
Etc.

 

I'd like to make an addition to your list.

=Optional=
<V++XXXX - Increment VarX by 1
<V--XXXX - Decrement VarX by 1

Also if Var0002 = 1311 and Var0001 = 1312 then <VAF will fail horribly. Sorry but each set flag gives 256 possible variable values, assuming it wasn't set before running <VAF. And <VAD is just messy.

A better debug function would write data directly to a text file.

<VAD - Saves all current variable data to "var.dbg".

 

How do you guys understand stuff like this?

 

How do you guys understand stuff like this?

It's all kind of second nature to anyone who's spent any great deal of time with any programming language.

Basically what we're discussing is ways to improve TSC (either by simplifying existing functions or adding new ones).

@andwhy: Eh, <V++/--, while maybe handy for somethings, are already covered by <VA+ and <VA-.

 

@andwhy: Eh, <V++/--, while maybe handy for somethings, are already covered by <VA+ and <VA-.

I meant it as an optional shorthand for <VA+XXXX:0001 and <VA-XXXX:0001, because incrementing or decrementing by 1 is a common operation.

 

I meant it as an optional shorthand for <VA+XXXX:0001 and <VA-XXXX:0001, because incrementing or decrementing by 1 is a common operation.

Eh. If it wouldn't add too much work why not. :3

So...
The question becomes can any of what we've discussed in the last ~3 pages actually be implimented?

 

Can? Absolutely.
More of a question of "Will it".

 

The question becomes can any of what we've discussed in the last ~3 pages actually be implimented?

You obviously fail to understand what can be done with assembly.

If it can be done on the computer, it could be done with ASM. (But there are some things that would be hard).

The various things you've listed all really don't seem that hard at all, but I'd still question their practicality. Sounds to me that you really just want to create a programming language, rather than extending the TSC. I'm sure most of the things you want to do in TSC could be achieved by hard coding it in assembly (as in, instead of making all the new TSC functions just get lace to put it in ASM).

 

would it be possible to make some sort of command that jumps to event Y if flag X is not set?

 

would it be possible to make some sort of command that jumps to event Y if flag X is not set?

Of course. <FNJ (or whatever you guys are calling it) would not be very difficult to implement. But it's still possible to avoid using it and stick with <FLJ for most scripting scenarios.

As for the variable commands, saving to flagdata is a good idea if you don't want to do save-able vars via memory allocation. Would take a few bitwise operations (or maybe not?), but it wouldn't be hard to put it in.

 

Can? Absolutely.
More of a question of "Will it".

You obviously fail to understand what can be done with assembly.

If it can be done on the computer, it could be done with ASM. (But there are some things that would be hard).

The various things you've listed all really don't seem that hard at all, but I'd still question their practicality. Sounds to me that you really just want to create a programming language, rather than extending the TSC. I'm sure most of the things you want to do in TSC could be achieved by hard coding it in assembly (as in, instead of making all the new TSC functions just get lace to put it in ASM).

Here's why I want it in TSC: I don't know excactly what I'll need just yet.
I know what I want, but in terms of how-to-do it there are gaps.
Gaps that would be most easilly filled by a flexible solution.
I want to have options for dealing with problems.
And more over, I want to be able to stop bugging Lace. D;

And what I mean by "actually be implimented" is "actually be implimented without Lace stabbing me".

Of course. <FNJ (or whatever you guys are calling it) would not be very difficult to implement. But it's still possible to avoid using it and stick with <FLJ for most scripting scenarios.

As for the variable commands, saving to flagdata is a good idea if you don't want to do save-able vars via memory allocation. Would take a few bitwise operations (or maybe not?), but it wouldn't be hard to put it in.

<FNJ's been created, if I recall.
And the deal with that is simple streamlining.
I could write ~30 lines of script to do something, or write ~10 with <FNJ.
And at this point my biggest concern is in fact trying to keep the TSC buffer from needing to be expanded too terribly much.

 

The various things you've listed all really don't seem that hard at all, but I'd still question their practicality. Sounds to me that you really just want to create a programming language, rather than extending the TSC. I'm sure most of the things you want to do in TSC could be achieved by hard coding it in assembly (as in, instead of making all the new TSC functions just get lace to put it in ASM).

Hard coding is inefficient in the long term. Why have someone else hard code a command for each operation you want written when you could just use an expanded tsc to write your own instead?

In any language I find it more efficient to write a function that I can use in multiple scenarios rather than just one. The same logic should apply to creating tsc commands.

Of course it's practical.

 

Hard coding is inefficient in the long term. Why have someone else hard code a command for each operation you want written when you could just use an expanded tsc to write your own instead?

In any language I find it more efficient to write a function that I can use in multiple scenarios rather than just one. The same logic should apply to creating tsc commands.

Of course it's practical.

If you know what you need to do, you could pull it off faster with just assembly (heck you could even CALL functions in assembly, a completely foreign concept ).

The main point being what DB said about not expanding the TSC buffer. If you had both a TSC version and an ASM version, the ASM version would run faster and would likely take up less space than the TSC version in binary.

The only issue here is that DB doesn't know ASM (or hasn't bothered to get off his lazy butt to learn it, it's really simple once you do and with his apparent grasp of programming languages should be pretty simple), so he wants lace to make the TSC so that he can "code" (script) in the language he is familiar in.

But yeah you can write and call functions in assembly (you knew this, right?), so it isn't like that would be an issue.

It just feels like you're overdoing the whole TSC thing, since the modifications you guys are suggesting would change it from a scripting language to a mini-programming language. Plus I keep seeing posts that are 2-3 screens long, and I am amazed at how complex you want it to be.

 

If you know what you need to do, you could pull it off faster with just assembly (heck you could even CALL functions in assembly, a completely foreign concept ).

The main point being what DB said about not expanding the TSC buffer. If you had both a TSC version and an ASM version, the ASM version would run faster and would likely take up less space than the TSC version in binary.

The only issue here is that DB doesn't know ASM (or hasn't bothered to get off his lazy butt to learn it, it's really simple once you do and with his apparent grasp of programming languages should be pretty simple), so he wants lace to make the TSC so that he can "code" (script) in the language he is familiar in.

But yeah you can write and call functions in assembly (you knew this, right?), so it isn't like that would be an issue.

It just feels like you're overdoing the whole TSC thing, since the modifications you guys are suggesting would change it from a scripting language to a mini-programming language. Plus I keep seeing posts that are 2-3 screens long, and I am amazed at how complex you want it to be.

Yeah, I'm aware the entire game could be written in assembly (in as sense already is).
Heck, gimme a couple weeks of nothing but poking around and experimenting and I could probably do it.

But there is other things to it as well.

For starters, I intend to release the TSC-modified EXE as a modding tool; something for people to try out more advanced scripting (otherwise impossible).
And granted maybe the discussion of variables is taking it a little far, but no denying they would be useful.

I really don't see this division you're seeing, Gir, between assembly-modding and assembly-assisted TSC-modding.

Anyways, if you don't buy any of that, my final point is this: I've anticipated the problems I will encounter and devised the most effecient series of tools to deal with them.
And they just happen to take the form of the following commands:

<*NJ - 5 Negation jumps (Flag, Arms, Items, Equipment, Map (Optional, really))
<MIM - Mimiga Mask expansion
<BUL - Draw a bullet
<SMY - Spawn NPC at player location

And two others I don't recall. ^^;
Everything else being discussed currently is purely hypothetical and would just add extra icing to the cake.

EDIT: Also, if I expand the TSC buffer more than a couple hundred bytes, it starts to degrade performance on my computer, lousy piece of crap it is.
So the reason behind my reason is so I can actually play my own mod at reasonable speeds. ^^;

 

Plus I keep seeing posts that are 2-3 screens long, and I am amazed at how complex you want it to be.

All that is needed is variables (2-byte integers only mind you), constant (XXXX) or variable (VXXX) input for all command arguments, and commands that deal with variables, specifically for set, add, subtract and conditional jump. That's it, just basic integer variable support. Everything else mentioned was either us working stuff out, optional stuff, or both (yes, saving to flag data would be optional as well).

And you might want to have a look at the definition of "scripting language":
http://en.wikipedia.org/wiki/Scripting_language

Complexity does not a programming language make.

 

All that is needed is variables (2-byte integers only mind you), constant (XXXX) or variable (VXXX) input for all command arguments, and commands that deal with variables, specifically for set, add, subtract and conditional jump. That's it, just basic integer variable support. Everything else mentioned was either us working stuff out, optional stuff, or both (yes, saving to flag data would be optional as well).

And you might want to have a look at the definition of "scripting language":
http://en.wikipedia.org/wiki/Scripting_language

Complexity does not a programming language make.

I guess the biggest issue is that adding more and more to the TSC might cause lag-issues, something you wouldn't see with just pure ASM.

I mean, for example, I find it just silly that Lace likes to call TSC events in an entity's code (so he can spawn more entities normally). Hence why he made it so that TSC scripts don't take away vulnerability.

Also what I would do, instead of trying to save more variables to the profile.dat, I'd use some unused flags in the profile.dat for "variables", kind of like seriousface's money thing. Only difference would be that instead of doing the calculations in TSC, you would do it in ASM. Basically, have something like <VARXXXX:YYYY:ZZZZ where X would be what flag you wanted to start from (like if it was 0048 then it would use flags 48-80, giving you a full 32 bit integer), Y would be the operation done with the number (0000 = set value, 0001 = add, etc), and Z would be the second part of the operaion (like if it was <VAR0048:0001:0049, it would add 49 to the "variable" stored at flags 48-80).

You would need to make one other function thing too, like a <VAJXXXX:YYYY:ZZZZ:WWWW, where X would be yet again the variable offset for the flags, Y would specify what kind of comparison it would do (like 0000 would be equal, 0001 would be greater than, 0002 would be less than, 0003 would be greater than or equal, 0004 would be less than or equal), Z would be the number being compared to the variable specified in X, and W would be the event to jump to.

I think those 2 tsc functions alone would be enough to accomplish what you want.

 

I guess the biggest issue is that adding more and more to the TSC might cause lag-issues, something you wouldn't see with just pure ASM.

I mean, for example, I find it just silly that Lace likes to call TSC events in an entity's code (so he can spawn more entities normally). Hence why he made it so that TSC scripts don't take away vulnerability.

Also what I would do, instead of trying to save more variables to the profile.dat, I'd use some unused flags in the profile.dat for "variables", kind of like seriousface's money thing. Only difference would be that instead of doing the calculations in TSC, you would do it in ASM. Basically, have something like <VARXXXX:YYYY:ZZZZ where X would be what flag you wanted to start from (like if it was 0048 then it would use flags 48-80, giving you a full 32 bit integer), Y would be the operation done with the number (0000 = set value, 0001 = add, etc), and Z would be the second part of the operaion (like if it was <VAR0048:0001:0049, it would add 49 to the "variable" stored at flags 48-80).

You would need to make one other function thing too, like a <VAJXXXX:YYYY:ZZZZ:WWWW, where X would be yet again the variable offset for the flags, Y would specify what kind of comparison it would do (like 0000 would be equal, 0001 would be greater than, 0002 would be less than, 0003 would be greater than or equal, 0004 would be less than or equal), Z would be the number being compared to the variable specified in X, and W would be the event to jump to.

I think those 2 tsc functions alone would be enough to accomplish what you want.

Now we're cooking with cycloquiozene.
Anyways...
Effectively you're suggestion not to add an additional variable set, but work with the already existing flags, right? </obvious>

Basically a souped-up <FL+, <FL- and <FLJ capable of processing more than just binary values (<FLJ being essentially a binary IF ELSE).

Although...
Hm.
I did like the idea of using variables as arguments in TSC commands because that would allow (by setting a few variables) the same block of script to perform multiple tasks.

Sorta...

#0001
[Variable preamble 1]<EVE0004
#0002
[Variable preamble 2]<EVE0004
#0003
[Variable preamble 3]<EVE0004
#0004
[Block of code which acts as a global processor (say, some method of counting)]<END

The idea being that you, say, call event 1, 2 or 3, which sets the appropriate variables, which changes what the processor processes.

In the example, calling 1 might add one to the count, calling 2 might remove 1 from the count, and calling 3 zero's the count.

I dunno, 3 options doesn't illustrate the idea I'm aiming for here very well.

Basically, rather than writing a fixed processor for each option, write one, and have the appropriate variables passed to it by calling the appropriate event.

It makes a little more sense on a bigger scale (with, say 24 things that utilize similar but differently values systems).

 

Although...
Hm.
I did like the idea of using variables as arguments in TSC commands because that would allow (by setting a few variables) the same block of script to perform multiple tasks.

Sorta...

#0001
[Variable preamble 1]<EVE0004
#0002
[Variable preamble 2]<EVE0004
#0003
[Variable preamble 3]<EVE0004
#0004
[Block of code which acts as a global processor (say, some method of counting)]<END

The idea being that you, say, call event 1, 2 or 3, which sets the appropriate variables, which changes what the processor processes.

In the example, calling 1 might add one to the count, calling 2 might remove 1 from the count, and calling 3 zero's the count.

I dunno, 3 options doesn't illustrate the idea I'm aiming for here very well.

Basically, rather than writing a fixed processor for each option, write one, and have the appropriate variables passed to it by calling the appropriate event.

It makes a little more sense on a bigger scale (with, say 24 things that utilize similar but differently values systems).[/QUOTE]

What you could do then is introduce a 3rd function like <VDCXXXX (variable declare) which would specify which set of flags you would work with, and could just get rid of the first value for the other 2 I specified.

It would be like... 

#0001
<VDC0048<EVE0004
#0002
<VDC0080<EVE0004
#0003
<VDC0112<EVE0004
#0004
<VAR0000:0045<END

Basically what you would have to do to get it to work is to hijack some unused (or one that you don't want to use) RAM value, and use VDC to set that up.  Then <VAR and <VAJ would be dependent on that ram value.  At least, I think that's what you would want, judging from your post.

Also, lol, <VAJ.

 

Well since variables only need to exist at runtime, and most do not need to be saved, there is little point in storing them in flag data outside of certain variables and storing the full list of variables in flag data would use a minimum of 3584 flags.

So all you need is:
<BISXXXX:YYYY - Store value from var x into a series of 14 flags starting at flag y.
<BIRXXXX:YYYY - Retrieve value from a series of 14 flags starting at flag y and store into var x.

The variable data is stored elsewhere in ram and the above commands are for those 3 or 4 variables you want to store in profile.dat.

<VDCXXXX is an alright idea I guess, but it is based on the concept of storing variables in the flag data. Plus it also assumes that you only want to declare only one variable which is unlikely.