lmao, did you randomly input 00 and it worked?

No, I looked at what the tile turned to in the memory and saw it was 00.

Okay, this is gonna be a real short tutorial. I'm not gonna go into depth in anything and I'll just give you the general idea. Mue originally attempted this, and while all the code made sense, the script didn't fire when the lever was hit, even though it should've.

So, to start, you're gonna place the lever with the ID 9E, as it is in the overworld with area ID 13. Next, create a type 8 interaction with the ID 501 (It might work with 500, 502, 503, 504, etc...) and place it where the lever is. Then, create a script to fire in the room. You're gonna perform a tile check, and although you would THINK you're checking for the tile 9F, you're not - you're checking for 00.

For some reason, the game replaced the trigger with tile 00 instead of the contrasting lever id. Why, I'm not sure, but here's an example script.

Code:

writelocation FEBE
setinteraction72 2
checktile 33 00 //Check to see if the lever at 33 has been changed (00)
//Action

Not sure for the reason behind these events, but hey, it works fine, so who cares!

~Lin

Very interesting. The cool thing is anything in level 1 can be used in anything below that, anything in 2 can be used in 2 and below, etc... because the pointers (From what I've studied) are immediately after each other. Good job.

Probably nobody here knows unless you were there when it was mentioned in the IRC channel, but yesterday (May 4th) was ZOLE 4's project creation birthday. The original very first ZOLE birthday is August 26th, 2008, but we'll save another topic until then.

So I just wanted to take this moment to thank everyone - The past year has been great and this is the longest and biggest project I've ever had, and it was only a success because of the motivation you all gave me. Thank you, and I look forward to the future of Zelda Oracles hacking.

~Lin

A quick tool I whipped up that converts addresses to pointers and vice-versa.

http://www.mediafire.com/?1kyo3rv3d8f3k6e

~Lin

As you may know, ZOLE Live is making great progress, and I honestly can't do the entire thing alone. Sure I can connect to localhost, but networking is too fast that way and unreliable. For example, when testing with Fatories, bugs appeared that weren't there locally.

So I'm asking for a few testers. However, my expectations are pretty high, so only apply if you can do the job. If I get no testers, that just means the progress will be slower.

What you need/must be/must provide:
-Have patience
-Readily available
-Contact information (Preferably IRC, see Announcements topic for information)
-Internet bandwidth is not an issue - Upon connect, a ROM is transferred over, and I'd rather not have to worry about it taking up too much of your usage
-Active when testing

Quite a few things, but for proper testing, I need all of the above to go well. I can't tell you how frustrating it is to be sitting there, waiting for the person testing to respond, and have to worry about whether or not they'll be there again to test the next build.

Thanks ahead of time,

~Lin

Lin, why not just fully expand the opcode list, move the ASM that was after it, change the pointer, then for the new pointers just jump to some unused space by following the same routine as a mid bank-bank swap?  Futhermore, there are actually some free opcodes earlier on in the list that are never used, and point to redundant code that you should be able to use.  I think I discovered that it was either in the Bx or the 9X were some opcodes that apparently don't have any use.

Edit:  Apparently A0 to A7 are not used, and point to 43 43, which I don't know what it does.  Just let me check Seasons in case it was used there.  Yup, not used.  I'm not sure what the code actually does, but why need 8 copies of it?  Unless you know the true answer to that, Lin, I'd say those are the best places to add in new opcodes.

Already did that. The ASM after the pointers is just a no-script: pop hl, inc hl, ret. I replaced it with the pointer, and the new opcode is FD, but I never closed this topic. I guess I should do that now. Thanks

ZOLE Live is a modified version of ZOLE made strictly for networking and editing ROMs with multiple people. Things are updated in real time and it's the best way for teams to get work. Basically, any amount of people can be working on the same ROM at one time and they can chat, view each others progress, and do stuff on their own. For example, 3 people could be editing: one could be working on the overworld, another part of level 1, and the other another part of level 1. This is a really fast way for editing, and it takes after Google Docs's live editing idea.

The project was only starting recently, and is making progress fast, so it shouldn't be too long before it's actually out.

~Lin

[4/30/11]

This is the development log for ZOLE Live. Please note the dates don't show only all that happened on that day. They tell about the progress from the last day to this day. For example, after 5/6/11 to the end of 5/8/11, I did what 5/8/11 displays.

4/30/11
Client: ZOLE can no longer open files or launch applications. There's the chat and networking interface on the right, and users can connect to servers. Still a lot to patch up and make look nice. When connecting to the server, the server will stream the ROM and ZOLE will load that data as the ROM, but before it does that, it sends the user's name to the server.

Server: Server accepts connections, feeds the ROM to connecting clients, and requires the name from the client before doing anything. The settings are loaded from a file called "settings.ini", where the server owner can specify his or her name, the hack name, and the name of the file to be fed. Clients are created with their own thread since there will only be a few people to a server. Clients can accept data, send data, and send data to all other clients. The only client > server packets are 00 (Ping) and 01 (Chat message). The 00 packet is sent 10 times per second, along with the cycling of clients. The core is done and all that's left is for the packets.

5/1/11
Client: Now connects. Big packet improvement, and added chat and a real connect window. Also fixed ROM streaming.

Server: Big packet improvement, better speed, more reliable.

Image: http://img801.imageshack.us/img801/5003/live1g.png

5/6/11
Finished map editing. Mainly fixed crashing and big sync issues. Now all is good though. Also, today was the biggest testing day. With 6 people on and editing, the server was using 0% CPU, using 22MB of RAM, and no lag at all. I'd say anyone can host one.



5/8/11
Fixed a small editing bug from left over code (the random crash issue), implemented full interaction editing (editing, adding, deleting), music editing, area id/property editing, and added dungeon room arranging. Also implemented a feature system, where only one feature can be edited at once (and by one person) aside from area/map editing. For example, interaction editing is 0, dungeon map arranging is 1. These also include status updates. The server also saves the ROM upon closing.

~Lin

Definitely sounds doable since you planned out dungeons with Ages bosses and weapons. You should join the IRC (Visit the IRC topic for info) and talk to us about your progress and get help. Sounds like it would turn out well

Today in the IRC, we were talking about how working together would work. I thought of a "Team" mode, and then I thought of it even more, and I came up with the idea of making it like Google Docs. What would this do? It would make it so 2+ people could have ZOLE open working on the same ROM, and could see what each other person is doing in real-time. It would revolutionize team hacking and make it super duper easy, and cool.

So what do you guys think? The feature would take quite a while to be implemented and probably buggy, but be really cool to have. While being worked on, no other real features would be added, and some things wouldn't be able to be viewed live. I think the only thing that would be showed is map editing and interaction editing. Post your opinions

~Lin

Version 1.23. Update log from ReadMe:

Added a feature to back up ROMs and decompress a tileset after setting its 3 main values that used to be editable. ZOSE and ZOTE are now zipped with their original files.

1.05 Beta 2 has been tested and is now deemed as final. Feel free to download it and use it for real.

Released 1.05 Beta 2. Multiple jumps no longer crash the game, "jump3bytemc" works, the decompiler no longer prints out a duplicate of the base part if jumped back to later, there is now a "Decompile 72 Interaction" window because the "Decompile Interaction" no longer works with 72 interactions due to the lack of opcode support in the emulation.

It should be pretty safe, but I don't want to ensure it until more people test.

Released 1.05. Recoded the assembly and created F7D2, the new format for type 72 scripts. This is a beta release with only some testing, and is recommended you don't use it primarily until 1.05 Release is out.

Test and report any bugs here.