z2
http://zzt.org/fora/

Lyon
http://zzt.org/fora/viewtopic.php?f=9&t=3320
Page 5 of 38

Author:  Saxxon [ Tue Oct 04, 2011 3:34 am ]
Post subject:  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)

Author:  Saxxon [ Tue Oct 04, 2011 5:38 pm ]
Post subject:  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.)

Author:  Saxxon [ Wed Oct 05, 2011 4:33 am ]
Post subject:  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.

Author:  Commodore [ Wed Oct 05, 2011 1:59 pm ]
Post subject:  Re: Lyon

what was changed in the exe besides the names of items and the default messages?

also a request for breakpoints/trace features.

Author:  Saxxon [ Wed Oct 05, 2011 6:41 pm ]
Post subject:  Re: Lyon

Commodore wrote:
what was changed in the exe besides the names of items and the default messages?

also a request for breakpoints/trace features.

That is a hefty feature :) I'll see about it sometime in the future.

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)

Author:  Saxxon [ Fri Oct 07, 2011 4:12 am ]
Post subject:  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.

Author:  Saxxon [ Fri Oct 07, 2011 5:22 am ]
Post subject:  Re: Lyon

Speaking of editor sessions..

Attachments:
mrwaifedit.png [54.08 KiB]
Downloaded 64 times

Author:  Saxxon [ Fri Oct 07, 2011 5:43 pm ]
Post subject:  Re: Lyon

ZZT labels are so screwed up, holy shit.

Code:
#restore x
#end
'x
'x

Becomes:
Code:
#restore x
#end
:x
:x


We knew this. Interestingly...

Code:
#restore 1
#end
'1
'1

Becomes:
Code:
#restore 1
#end
:1
'1


So only one label is affected here. Even stranger:

Code:
#restore 2
#end
'1
'1

Becomes:
Code:
#restore 2
#end
:1
'1


Also.

Code:
#restore electro
#end
'electro1
'electro2
'electro3

Becomes:
Code:
#restore electro
#end
:electro1
'electro1
'electro1


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.

Author:  Commodore [ Sat Oct 08, 2011 1:34 am ]
Post subject:  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.

Quote:
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.


useful

Author:  Saxxon [ Sun Oct 09, 2011 4:47 am ]
Post subject:  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:
Code:
        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


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.

Author:  Saxxon [ Mon Oct 10, 2011 3:14 pm ]
Post subject:  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.

Author:  Saxxon [ Thu Oct 13, 2011 1:32 pm ]
Post subject:  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.

Author:  Saxxon [ Fri Oct 14, 2011 8:34 pm ]
Post subject:  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.

Author:  Quantum P. [ Sun Oct 16, 2011 2:14 pm ]
Post subject:  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.

Author:  Saxxon [ Mon Oct 17, 2011 3:27 am ]
Post subject:  Re: Lyon

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.

That's a bit more reassuring :)

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.

Page 5 of 38 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/