Lyon
Moderator: Terryn
Re: Lyon
Got the ZZT Encyclopedia BoardEdge+Passage illusion to work. The rewrite made graphic updates work just like ZZT (so some artifacts may appear here or there depending)
Re: Lyon
Going to refactor how I treat code sets and make it so Banana Quest works. (Sorry, WiL, running in anything other than BQZZT is probably what you wanted to avoid in the first place.)
Re: Lyon
Banana Quest is playable. I really hope it isn't much more than swapping a couple strings.
Redesigning the editor. Editor windows are different from gameplay windows, and you can't switch between them. However, you will be able to run tests directly from the editor window in a *separate* gameplay window. Worlds do not need to be saved to test changes, however once a game has started any changes to the world will not take effect until you run another test. The way it works is, whenever you run a test, it exports the whole world to memory, then imports it to a gameplay window. The benefit is you get to see exactly how the world is going to be loaded.
Redesigning the editor. Editor windows are different from gameplay windows, and you can't switch between them. However, you will be able to run tests directly from the editor window in a *separate* gameplay window. Worlds do not need to be saved to test changes, however once a game has started any changes to the world will not take effect until you run another test. The way it works is, whenever you run a test, it exports the whole world to memory, then imports it to a gameplay window. The benefit is you get to see exactly how the world is going to be loaded.
Re: Lyon
what was changed in the exe besides the names of items and the default messages?
also a request for breakpoints/trace features.
also a request for breakpoints/trace features.
*POW* *CLANK* *PING*
Re: Lyon
That is a hefty feature :) I'll see about it sometime in the future.Commodore wrote:what was changed in the exe besides the names of items and the default messages?
also a request for breakpoints/trace features.
BQ changed the names of some labels and commands. Only a few, but enough to cripple the game if they aren't implented (TOUCH, END, PLAY, CYCLE)
Re: Lyon
When simulating, if there is a crash for any reason (dead scroll, etc) the program will not completely crash, but instead offer to show an internal stack trace and close the crashed session. This isn't a trace for OOP code, it's a trace for Roton code. So you'd see something like Execute -> ExecuteMain -> Act -> ActScroll for a dead scroll, for example. This probably isn't terribly useful for the average user, but it will help track down any remaining bugs that I don't find.
And it won't trash your editor session.
And it won't trash your editor session.
Re: Lyon
ZZT labels are so screwed up, holy shit.
Becomes:
We knew this. Interestingly...
Becomes:
So only one label is affected here. Even stranger:
Becomes:
Also.
Becomes:
If you change the labels you use, you can actually choose whether or not #RESTORE will restore all labels or just one. If you want to restore just one label, slap a number on the end of the label itself and don't include it in the #RESTORE statement. #ZAP still only zaps one.
Code: Select all
#restore x
#end
'x
'x
Code: Select all
#restore x
#end
:x
:x
Code: Select all
#restore 1
#end
'1
'1
Code: Select all
#restore 1
#end
:1
'1
Code: Select all
#restore 2
#end
'1
'1
Code: Select all
#restore 2
#end
:1
'1
Code: Select all
#restore electro
#end
'electro1
'electro2
'electro3
Code: Select all
#restore electro
#end
:electro1
'electro1
'electro1
Re: Lyon
Think I found out zzt didn't like numbers in labels when I was making wolfenstein. I ended up writing out numbers: enemyone, enemytwo, &c.
usefulIf you want to restore just one label, slap a number on the end of the label itself and don't include it in the #RESTORE statement.
*POW* *CLANK* *PING*
Re: Lyon
The part that baffles me most is that the exact same code is executed for all these conditions. I have all the code in front of me that is run when a send/zap/restore is executed (these three statements all share most of the code). And I still don't understand how this even works.
OOPReadWord will attempt to read a word from OOP code. If the first character is a number it returns nothing. If subsequent characters are numbers, this is ok (in fact valid characters are 0-9, A-Z, _, and :. That last one is for the sake of going through other targets.) But this is not the same code as used to actually search the OOP code. It uses some really messed up string matching that I don't fully understand. Even worse, variables are manipulated from within these functions so when you call them, the input values change radically.
This whole section of the OOP engine is one heaping pile of shit.
Here's the translated version of the search code:
So basically it is a match if a letter or _ does not follow what it found as a possible match in the code, and it comes back with the first discovered instance.
Also, Code.Code is due to the way strings are handled in VB, they are treated as values, not references. Therefore I had to create a class that would hold the code, so it could be referenced and shared by multiple things on the board.
Unrelated: ZZT has a 4kb limit on messages generated by OOP.
OOPReadWord will attempt to read a word from OOP code. If the first character is a number it returns nothing. If subsequent characters are numbers, this is ok (in fact valid characters are 0-9, A-Z, _, and :. That last one is for the sake of going through other targets.) But this is not the same code as used to actually search the OOP code. It uses some really messed up string matching that I don't fully understand. Even worse, variables are manipulated from within these functions so when you call them, the input values change radically.
This whole section of the OOP engine is one heaping pile of shit.
Here's the translated version of the search code:
Code: Select all
Private Function OOPSearch(ByVal ThingData As Thing, ByVal SearchString As String) As Integer
Dim Offset As Integer
Dim CodeOffset As Integer
Dim Index As Integer
Dim SearchOffset As Integer
Do
If (CodeOffset > ThingData.Code.Code.Length) Then
Offset = -1
Exit Do
End If
SearchOffset = CodeOffset
For Index = 1 To SearchString.Length
If (ReadOOPByte(ThingData, SearchOffset).ToUpper = SearchString.Substring(Index - 1, 1).ToUpper) Then
Continue For
Else
CodeOffset += 1
Continue Do
End If
Next
Select Case ReadOOPByte(ThingData, SearchOffset).ToUpper
Case "A" To "Z", "_"
Case Else
Offset = CodeOffset
Exit Do
End Select
CodeOffset += 1
Loop
Return Offset
End Function
Also, Code.Code is due to the way strings are handled in VB, they are treated as values, not references. Therefore I had to create a class that would hold the code, so it could be referenced and shared by multiple things on the board.
Unrelated: ZZT has a 4kb limit on messages generated by OOP.
Re: Lyon
The editor is coming along nicely. I've included a Test submenu on right-click which will allow you to test from either the title screen (as if you'd loaded the world) or from the currently visible board (as if you'd loaded a saved game). This should aid in rapidly debugging games.
When plotting Players, they will always be treated as clones. In order to move the actual player, you will need to right click -> Player -> Move Here.
When plotting Players, they will always be treated as clones. In order to move the actual player, you will need to right click -> Player -> Move Here.
Re: Lyon
Right clicking gives you some more options for objects.
* Bind - allows you to bind an object to another named object on the board. Unnamed objects and objects with no code will not be listed.
* Create - creates an object under the cursor.
* Create hidden - creates an object that matches the character and color of whatever is under the cursor.
* Bind - allows you to bind an object to another named object on the board. Unnamed objects and objects with no code will not be listed.
* Create - creates an object under the cursor.
* Create hidden - creates an object that matches the character and color of whatever is under the cursor.
Re: Lyon
Looking online, does anyone really care about SuperZZT?
I haven't made any games yet and was looking to create a game with Lyon's editor to show its capabilities, but if I do anything in SuperZZT will it be completely overlooked? From what I observe, the answer looks to be YES. But maybe that's because nothing really spectacular has been done for it before. I really want to have an inventory system that uses H.
I haven't made any games yet and was looking to create a game with Lyon's editor to show its capabilities, but if I do anything in SuperZZT will it be completely overlooked? From what I observe, the answer looks to be YES. But maybe that's because nothing really spectacular has been done for it before. I really want to have an inventory system that uses H.
- Quantum P.
- Level 17 Accordion Thief
- Posts: 1433
- Joined: Fri Sep 12, 2003 1:41 am
- Location: Edmonds, WA
- Contact:
Re: Lyon
I don't think anything SuperZZT will be completely overlooked. If it's easy to do, and it seems like you want to do it, why not?
I'd play it.
I'd play it.
Re: Lyon
That's a bit more reassuring :)Quantum P. wrote:I don't think anything SuperZZT will be completely overlooked. If it's easy to do, and it seems like you want to do it, why not?
I'd play it.
Everything in the program is functional, I am just adding useful features to the editor as I create the world. That'll also help to remove all the bugs before release. Right now both ZZT and Super ZZT worlds can be created, saved, played, and restored. Boards can be imported and exported. It handles corrupt boards by replacing it with an empty board for now, but might contain some repair function later.
Tracing / breakpoints won't happen for a while, but I'd like to combine that effort with syntax highlighting. I have not yet learned how to code for Rich Text yet.