ZZT editor improvements

Discuss how totally awesome Bang! is here.

Moderator: Terryn

66
What can be said now?
Posts: 0
Joined: Fri Mar 14, 2003 8:20 pm

Post by 66 »

It could be made a rule that Global shortcut definitions should appear in the first object (that is, lowest stat number)

The interpretation of the shortcut was indeed correct

And a definition for predefined programs:

like

%programname
%set variable value
%end programname

like
%marquee
%set len 3
%set cycle 2
%set text ZZT RULES YAY
%end marquee
to be
#cycle 2
ZZT
/i
ZT
/i
T R
etc.

inventory engine?
%inventory
%set name hammer
%set label huse
%set notlabel loop
%end inventory
to be
#if not invhammer loop
#clear invhammer
#huse

%inventorymaster
%set name1 Hammer
%set desc1 Patented Electric hammer
%set cant1 You stare at the serial number on the hammer
%set name2 soda
%set desc2 a can of coca cola
%set cant2 Yuck Cola!
%end inventorymaster
to be
#cant think of an inventory engine master object that fast :(

or do you think you should leave out the %set and make it %label value

comments?
User avatar
Mooseka
;-*
Posts: 282
Joined: Mon Sep 22, 2003 5:01 pm

Post by Mooseka »

That makes some sense, but it almost seems like that's more work than just doing it manually.
Image
105
What can be said now?
Posts: 0
Joined: Wed Oct 08, 2003 5:55 am

Post by 105 »

Hmmm... I like using %set for marquees (not %label value because that could conflict with future % command keywords), but it takes up too much space and doesn't resemble anything in ZZT-OOP.

Let's see what options we need. We can ditch cycle because you can just use a #cycle command yourself if necessary (I mean, are we really so lazy?). It might be useful to set the number of idles between each display, though, but this isn't very important. You definitely need to set the width of the marquee (btw, ZZT will actually display lines up to 50 chars long or so on the bottom line, but they suck to edit). Direction might be good, but can anyone think of a use for marquees that scroll to the right?

Looking at the docs for Quill (TikMak), WiL's marquee generator utility, there are something like 12 styles of marquees available, but I don't understand all of them. I think an option for a left and right border text would be nice, and a caps mask (think BanAnA qUEst).

Okay, so here's my suggestion for Marquee format:

Code: Select all

%marquee 4
%set lborder <-
%set rborder ->
%set caps 0110
Hello world.
%end marquee
This becomes:

Code: Select all

'%marquee 4
'%set lborder <-
'%set rborder ->
'%set caps 0110
'%set idles 1
'Hello world.
\i <-    ->
\i <-   h->
\i <-  He->
\i <- HEl->
\i <-hELl->
\i <-eLLo->
\i <-lLO ->
\i <-lO w->
\i <-o Wo->
\i <- WOr->
\i <-wORl->
\i <-oRLd->
\i <-rLD.->
\i <-lD. ->
\i <-d.  ->
\i <-.  ->
\i <-    ->
'%end marquee
To restore the shorthand code, the editor recognizes the '%marquee, uncomments everything up through the '%end marquee, and removes anything that isn't commented. This last step is dangerous, because someone may have unwittingly modified their marquee in another editor.

Anyway, this makes width the only required option. Everything else can be omitted and just default to something (no borders, 1 idle, no caps mask). The actual text can be as many lines as you want, so that something like this can be done:

Code: Select all

%marquee 20
Some really long text that you want to
have scroll by without actually putting
much work into it. So yeah.
%end marquee
Sound good?
105
What can be said now?
Posts: 0
Joined: Wed Oct 08, 2003 5:55 am

Post by 105 »

I just took a look at how ibag works, and don't know if integrating ibag is a good idea. It generates some external files for sharing across boards and is really much more complicated than I care to deal with. Maybe some other time.

I don't think requiring globals to be in the first object would be very easy for the user. I would rather let them make an object named @globals and put "%include globals" in any program that uses them. That way everyone's much more aware of where these shortcuts are coming from.
User avatar
Mooseka
;-*
Posts: 282
Joined: Mon Sep 22, 2003 5:01 pm

Post by Mooseka »

I'm not saying that you'd steal the ibag source, or even run it the same way. I'm just saying it should end with the same conclusion, being an inventory system that's easily manageable.
Image
20
What can be said now?
Posts: 0
Joined: Sat Mar 15, 2003 11:20 am

Post by 20 »

right after the "'Hello world." you could put another comment with some kind of hash of the generated code, so you can check if people have used another editor to mess with what you generated.
66
What can be said now?
Posts: 0
Joined: Fri Mar 14, 2003 8:20 pm

Post by 66 »

Let me think that over (i take bitman's example to make comparison)

%marquee 4
%set lborder <-
%set rborder ->
%set caps 0110
Hello world.
%end marquee

to be

'%marquee 4
'%set lborder <-
'%set rborder ->
'%set caps 0110
'%set checksum 3D34
'Hello world.
\i <- ->
\i <- h->
\i <- He->
\i <- HEl->
\i <-hELl->
\i <-eLLo->
\i <-lLO ->
\i <-lO w->
\i <-o Wo->
\i <- WOr->
\i <-wORl->
\i <-oRLd->
\i <-rLD.->
\i <-lD. ->
\i <-d. ->
\i <-. ->
\i <- ->
'%end marquee

I thought making that checksum by XOR'ing the ascii-values in pairs, but I don't have any experience with such things :(

The alternative is that the editor reads the %-commands and compares the code with it, and if they don't match the editor doesn't change it.

BTW, good global shortcut solution
perhaps we ought to change shorts to
%shortcut:command
instead of
'_shortcut:command
and make it a rule that shortcuts override built-in programs for compatibility
105
What can be said now?
Posts: 0
Joined: Wed Oct 08, 2003 5:55 am

Post by 105 »

Excellent idea, CyQ. A simple XOR of each character (ignoring newlines) should be good enough, since this is just a precaution, not a security measure. That will make it very simple.

Comparing the previously generated code to whatever would be generated is definitely overkill. It costs too much time and doesn't account for any randomizations we might want to add later (random bitmask? text exploding outward?).

I think %shortcut:command is probably the best syntax for shortcuts too. That should keep things consistent and even looks ZZT-OOPish.

It might even be possible to import code from other boards using something like:

%include stuff@objectname

where "stuff" is the name of a board and "objectname" is an object on that board. We can either limit this to boards with single-word names or follow whatever behavior ZZT uses for objects with multi-word names when sending messages to them. (anybody know what ZZT does?)

I need to start thinking about how I'm going to code all of this. It's going to wreck havoc with the way syntax highlighting is handled.
User avatar
Mooseka
;-*
Posts: 282
Joined: Mon Sep 22, 2003 5:01 pm

Post by Mooseka »

All of these ideas are great, and all, but does anyone plan to put them to use =(
Image
136
What can be said now?
Posts: 0
Joined: Thu Apr 03, 2003 2:10 am

Post by 136 »

And then you wood also make sumthing to compile this ZZT editing file into a reel ZZT file.

And also hav template bords in the editing ZZT file, that copys to all bords that use that template. The indivicual bords wood be smaller then normal size, becuse a rectangle in the template wood indicate were changes wood be made. Also commands in spaces in template to indicate stuf on new bord variables set for ech bord.
26
What can be said now?
Posts: 0
Joined: Tue Oct 14, 2003 3:44 pm

Post by 26 »

zzo38 wrote:And then you wood also make sumthing to compile this ZZT editing file into a reel ZZT file.

And also hav template bords in the editing ZZT file, that copys to all bords that use that template. The indivicual bords wood be smaller then normal size, becuse a rectangle in the template wood indicate were changes wood be made. Also commands in spaces in template to indicate stuf on new bord variables set for ech bord.
zzo38 might be on to something here, if I can decipher his typing correctly...

Template boards would be an awesome thing to have, especially on "engine" games with an inventory system or something like that.
Zenith Nadir wrote:you all use external editors because you're WEAK
OHH GOD HE'S FIGURED US ALL OUT RUN AVAY!
User avatar
TTTPPP
Latest band news: &quot;There are no news!&quot;
Posts: 108
Joined: Sat Oct 11, 2003 7:20 pm

Post by TTTPPP »

Straying from the current focus slighty, how can you hope to include all the ways of displaying text that people might want to use?
As well as the normal left/right scrolling text, with/without fixed caps positions, the exploding text, and any others that have been mentioned so far, I can think of X-Files style left to right text, letter by letter sliding across page, two halves coming together, ...

It sounds like it would be a really useful feature, but it's never going to include everything.

In response to the question about should it use case sensitivity: Is case sensitivity used anywhere else in ZZT OOP?
20
What can be said now?
Posts: 0
Joined: Sat Mar 15, 2003 11:20 am

Post by 20 »

xor is far from sufficient for something like this. it would allow for removal of 2 identical characters or lines, for example. a good (ie collision free) hash function like md5 or sha1 is not hard to implement, and there are a million c implementations already anyway.
66
What can be said now?
Posts: 0
Joined: Fri Mar 14, 2003 8:20 pm

Post by 66 »

zzo38 wrote: And then you wood also make sumthing to compile this ZZT editing file into a reel ZZT file.
I think you didn't understand it: by opening the object editor the commented code is compiled to %-OOP and when you close the object editor the %-OOP is automatically converted to ZZT-OOP. You don't need to compile anything
TTTPPP wrote: It sounds like it would be a really useful feature, but it's never going to include everything.
You are probably right. There are so many variations for marquee's (let alone RPG battle engines...!) that it'd be impossible to include them all. We could however say that the marquee has %type linear/exploding/annoying/whatsoever and when people need it they can make a new type of their own. The result of such a thing is that there should some kind of reference list where people can request a name, to prevent there are no duplicates.
CyQ wrote: xor is far from sufficient for something like this
As Bitman said, it's a precaution. And the wa I suggested it doesn't necessarily mean that removing two same characters (or adding) does not change the checksum, since it is two bytes long.

Though you may try something like this:

Code: Select all

long n, s;
int chsum;
s = strlen(objcode);
chsum = 0;
for( n = 0; n < s; n++)
{ if(n & 1) { chsum = chsum xor (char) (objcode[n] + n); } 
  else { chsum = chsum xor (char) (objcode[n] + n) >> 8; } 
}
It'd be fast and it'd prevent most simple errors.
Oh, and PLZ EXCUSE ME IF I BROKE THE LAW OF C. I think it won't work immediately but you'll get the point...
20
What can be said now?
Posts: 0
Joined: Sat Mar 15, 2003 11:20 am

Post by 20 »

both md5 and sha-1 can easily hash quite a few mb/s, so speed is not an issue. and as there already are implementations available, i don't see why you'd want to write your own inferior xor-based hash function.
Post Reply