andwhyisit said:
No, because 90% of variables do not need to be saved.
Well, alright then.
DragonBoots said:
=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)
I can't see these being at all useful.
DragonBoots said:
=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)
I don't like this; why not use actual operators instead? That is, as follows:
<VAJWWWW:VXXX::==::YYYY - Jump to event W if variable X is equal to Y.
<VAJWWWW:VXXX::<=::YYYY - Jump to event W if variable X is less than or equal to Y.
<VAJWWWW:VXXX::>=::YYYY - Jump to event W if variable X is greater than or equal to Y.
<VAJWWWW:VXXX::<<::YYYY - Jump to event W if variable X is less than Y.
<VAJWWWW:VXXX::>>::YYYY - Jump to event W if variable X is greater than Y.
<VAJWWWW:VXXX::<>::YYYY - Jump to event W if variable X is not equal to Y.
For the record, the numeric values of these would be as follows:
:==: - 11440
:<=: - 11340
:>=: - 11540
:<<: - 11330
:>>: - 11550
:<>: - 11350
And, if you prefer != to <>...
:!=: - 8540
(This assuming that my conversion script is correct, which I think it is. It works for regular numbers, anyway.)
And, assuming you use the VXXX notation for variables, you could do things like the following:
<VAJ1234:V123::==::1234 - Jump to event 1234 if V123 == 1234
<VAJ1234:6621::<=::V021 - Jump to event 1234 if 6621 <= V021
<VAJ0022:V001::<>::V005 - Jump to event 0002 if variables 1 and 5 differ
<VAJ0042:0034::==::0034 - Unconditional jump to event 0042, with the minor bonus that one of the arguments could later be made dependent on a variable
andwhyisit said:
A better debug function would write data directly to a text file.
<VAD - Saves all current variable data to "var.dbg".
Yeah. This method is definitely better.
GIRakaCHEEZER said:
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).
We want to make the language a bit easier to use, I guess; it currently has even less features than assembly. And has someone mentions later, hard-coding is not necessarily a good thing.
GIRakaCHEEZER said:
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
).
Depends what you want to do, I guess. Something simple like variables is logical to do in the script, in my opinion.
GIRakaCHEEZER said:
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.
These changes would not change it into a mini-programming language; at most, it would become a mini-assembly language.
DragonBoots said:
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).
This is a great idea.
GIRakaCHEEZER said:
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.
This
is a somewhat valid point; the TSC parser is horrendously inefficient, apparently.
DragonBoots said:
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.
Kind of like writing functions!
andwhyisit said:
<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.
Yeah, <VDC isn't a particularly good idea really.
DragonBoots said:
<VARXXXX:YYYY:ZZZZ- Put Y into variable form starting at skipflag X via method Z (0000 - Set, 0001 - Add, 0002 - Subtract, 0003 - Multiply, 0004 - Divide and trunicate)
Again, why not actual operators?
<VARVXXX::==::YYYY - Store Y in variable X
<VARVXXX::-=::YYYY - Subtract Y from the value of variable X and store in variable X
<VARVXXX::+=::YYYY - Add Y to the value of variable X and store in variable X
<VARVXXX::*=::YYYY - Multiply Y by the value of variable X and store in variable X
<VARVXXX::/=::YYYY - Divide Y by the value of variable X and store the truncated value in variable X
<VARVXXX::%=::YYYY - Divide Y by the value of variable X and store the remainder in variable X
<VARVXXX::^=::YYYY - Raise Y to the power of the value of variable X and store in variable X
<VARVXXX::|=::YYYY - Combine Y with the value of variable X using bitwise OR and store in variable X
<VARVXXX::&=::YYYY - Combine Y with the value of variable X using bitwise AND and store in variable X
<VARVXXX:
=::YYYY - Combine Y with the value of variable X using bitwise XOR and store in variable X
<VARVXXX::<<::YYYY - Bitshift variable X left by Y bits and store in variable X
<VARVXXX::>>::YYYY - Bitshift variable X right by Y bits and store in variable Y
And the actual numbers for information:
:==: - 11440
:-=: - 9840
:+=: - 9640
:*=: - 9540
:/=: - 10040
:%=: - 9040
:^=: - 14740
:|=: - 17740
:&=: - 9140
=: - 11740
:<<: - 11330
:>>: - 11550
andwhyisit said:
I personally think that to avoid confusion, and for consistency, we should reset all runtime variables on reload. If you closed down the game, opened the game and loaded your save file the runtime variables are not set, so why should they be set when you reload your game without closing it down? Runtime variables aren't skipflags or "skipvariables", we are just using the space occupied by skipflags, not following their behaviour.
Agreed that closing the game and reloading should be equivalent to reloading without closing.
andwhyisit said:
2. Z is dead weight in my opinion. I would rather use 5 different commands for set, add, subtract, store and retrieve (VAR,VA+,VA-,BIS,BIR) then to add 5 redundant characters to every variable-related operation. No offense.
How do you like my idea, in which 2 of those 5 previously redundant characters actually visually indicate the type of comparison?
DragonBoots said:
Anyways, more to the point - What would be a good maximum for storage per-variable?
Anything more than 16 bits would probably be overkill.
DragonBoots said:
However, I'd say 8 would suffice for moist needs.
What about dry needs? Can't forget those!
DragonBoots said:
Though the possibility of -0 kinda disturbs me. ^^;
Standard (IEEE) floating-point representations do have a -0; in the standard integer implementation, though, what would be -0 is instead one less than the lowest value.
Noxid said:
How the hell do you use 14 bits for a number D:
Unless you read it bitwise and then calculated the final value, but that's insane.
You can use any number of bits you like for a number. Using 14 bits, though, would mean you have to do it yourself rather than using the hardware's built-in support (though just for reading and writing the number; you could load it into a register or something for operations on the number).
andwhyisit said:
1. While V++ and V-- would be useful, they are a shorthand for <VA±XXXX:0001 and therefore optional.
2. A TSC script can be easily written to accommodate saving to flag data in a variable-driven TSC, so a command for this use is purely optional.
3. I already made a point about multiplication and division, it's unnessessary.
I agree with 1 and 2, but I think division and multiplication should definitely be included.
andwhyisit said:
How about we use both? First 30 variables (V000 to V029) can be stored variables (flag data) and the rest (V30 onwards) are runtime variables (broken skipflag data). This way you only use up the last 500 flags for variables (leaving you with 7500 for flag use) and you don't save data that you only want to exist at runtime.
This seems a bit silly...
Noxid said:
<VAOXXXX:YYYY?$
XXXX - The variable # being acted upon
YYYY - The number
? - Type modifier - If == V, then YYYY refers to a variable #, else YYYY is just a number.
$ - Operation to perform. Legal operations include +, -, * and %
What about this instead?
<VAOXXXX$YYYY
XXXX - The variable to change (less than 1000)
YYYY - The right operand
$ - The operator; one of =+-*/%^&|@ as described further up
...okay, now that I've responded to a good chunk of the thread, here's my suggestions. And in order to partially avert "too long, didn't read", I'll make a separate post for them.