xdaniel

Cartridges for at least some systems can be physically modified to accept EEPROMs, by removing the on-board ROM and replacing it with an IC socket. That's more or less how ex. SNES reproductions are made. Of course that means you'll need to sacrifice an official cartridge - and with systems where cartridges contain memory mapping hardware (ex. NES, GB, SNES), you'll need different donor cartridges for different games -, you'll need to be able to solder and desolder components on a PCB, and you'll need to be able burn EEPROMs... and I don't know if you can even do this so easily with an N64 game. Nowadays, getting a modern flash cartridge - sd2snes, 64drive, the various Everdrive models, etc. - is the easier, albeit more expensive way.

Railgun S episode 15:

petrie911: Trying to implement it right now. The way I'm planning it, you'll still need to open a compatible ROM beforehand - as a lot of data will still be loaded from it, and I really don't want to change this - but afterwards you can open a separate pair of scene and room files to sort of "override" the ROM. They will stay active until you close the scene/room pair from the menu. Not sure if this'll be in the next build, but it's looking good, I guess. Hope this'll work for you. In other news, I came across the update-checking-sample-demo thingy I posted in one of haddockd's Master GUI threads again and decided to add such a function to SceneNavi. Starting with the next release, you'll be able to check for updates to SceneNavi by using the "Check for Update" function in the "Help" menu. It'll either tell you that you already have the most recent version, or be able to direct you to a download of the newer one.

I guess that first spider is kinda cute, but... it just ends up reminding me of the Cave Spiders in Minecraft <.<

Think I'll leave the UI for collision editing like this for Beta 4. I will add more, separate options for exit triggering, damage, etc. in later builds, but for now this'll have to do. Also aiming for a release of Beta 4 soon-ish, maybe Sunday or so.

Listening to the first part of the Hard4Games interview with Shadow Fire, I felt reminded of the podcast and was wondering: Is there any chance you could bring it back, despite Zeth's removal, and thus maybe with a rotating panel of three or so members of the administration, depending on who has time? I very much enjoyed the two episodes you made previously, so I'd really like to hear more of it in the future.

UoT's certainly been an inspiration for a lot of things in SceneNavi (and SayakaGL, and OZMAV2, and "Old OZMAV"). It has a solid UI, although I feel like it's rather messy - or maybe it's gotten messy over time, can't remember its original incarnations very well. I guess I'm trying to take what I feel is good about its interface - ex. the mouse controls -, while at the same time making it cleaner and more... adhering to design conventions, I suppose? Like not having colored, underlined text and silder/trackbar controls in the status bar. It's those tiny things that look out of place, that I hate about UoT. And that some older version of it killed my Forest Temple by ruining the transition actors...

Progress report time; turned out a bit long but might be interesting to read: As I've said before, mouse-based movement of actors and waypoints is now implemented, although I've since changed how it works. There's now three mouse modes, similar to UoT and SayakaGL: camera mode (only allows camera movement, no selection or movement of "things"), moveable objects mode (allows selection and movement of actors and waypoints) and static objects mode (allows selection of, so far, collision polygons). You can switch through the modes either by using the menu ("Tools" -> "Mouse Mode") or by clicking on the mode label on the (now actually used!) status bar, in the lower left corner. Moving things is done via the left and/or middle mouse button: hold the left button to move the thing up, down, left and right (meaning, X and Y axis with neutral camera position), hold the middle button OR hold Ctrl on the keyboard plus the left button to move the thing forward or backward (Z axis w/ neutral camera). Also, moveable objects have a context menu that's displayed when you right-click them. The menu allows you to rotate the thing by 45 degrees in both directions on any of the three axis. This function is only enabled for things that actually have rotation values, so waypoints cannot be rotated, and only the axes that are supported by the thing can be changed, so ex. treasure chests can only be rotated on the X and Y axis. The status bar, as mentioned, now actually does something. Besides the mouse mode, it now displays the camera position, as well as some information about the currently loaded scene or room, like its name and actor counts. Minor addition, but might be useful. The menus have changed a bit, too: the collision highlight option has moved to the new "Tools" menu, which also contains the aforementioned mouse mode option, as well as one to reset the camera position. There's also a new VSync toggle in the Options menu to limit the FPS - the FPS is now also only shown when VSync is disabled, as otherwise it'll mostly be around whatever your monitor's refresh rate is anyway. Speaking of FPS, one thing that really destroyed the performance previously was the collision rendering. I've added some caching via OpenGL display lists, so the collision overlay is now only re-rendered if it changes, ex. when you select a collision polygon, or when you change something in a polygon type. Once something changes, the collilsion overlay is flagged as dirty, then deleted and recreated on the next frame and cached again until another change occures. What does that mean for performance? Screenshots in the spoiler, showing the Fire Temple, which is one of the more demanding ones to render (along with ex. Water and Spirit, I believe). EDIT: Oh, and before I forget, I added some more housekeeping stuff regarding OpenGL extensions, texturing and combiner emulation. This'll meant that, hopefully, people with not-so-good graphics cards, that do not support the extensions required for ex. the combiner, will at least be able to use the program, albeit without textures.

Just set this one up, and... well, it's not purely yet another Madoka Magica wallpaper, it's also... remembering a character that got shafted in a certain pair of remakes.

Heh, well, the key modifier's still useful for those with laptops, where the touchpad usually only has two buttons, so no harm done Still surprised you didn't know about the wheel, tho maybe that's just me as I use the button for scrolling at times.

The next version will allow switching the OGL control's VSync on and off, so unless your monitor does a 300 Hz refresh rate, it should be much easier to navigate scenes with that enabled In the meantime, try holding down Shift while you move around, that slows the camera's speed down somewhat while Space speeds it up.

Yeah, that should explain it. I'm adding some byte order detection and swapping code to the program; it'll detect if the ROM has the wrong order, then ask the user if it should swap it and where to save the resulting ROM, and finally reload the now correctly ordered file.

Hm, the only Path.Combine calls in the ROMHandler's constructor are for creating the paths to the XML files, thus the actor definitions, name tables, etc. "Illegal characters" can occur if you try to load a ROM with the wrong byte order, as the program ends up reading the game ID incorrectly, which is needed as part of the path. Can you read the ROM header if you open the ROM in a hex editor; the title "THE LEGEND OF ZELDA", etc.? If not, try byteswapping and opening it in SceneNavi again. Gotta add some exception handling for that kinda situation...

What? No clickable scroll wheel or anything? How old is that mouse? Uhm, I guess I'll add a modifier key that, when pressed, changes the right-click function into the middle-click one... like, hold down ex. Ctrl and the right button drags the object forward/backward, instead of up/down/left/right. EDIT: WIP, more details about the changes later:

I was gonna post a short progress report, but first... So, uh, no other feedback? Airikita, Antidote, !Tommy, do you still get the errors you've been getting, and if so, what do the details say? Anyone else with any bug reports, ideas, etc.? ...now for the progress. Dunno if it's dedication or foolishness, but I've worked through the night - literally, it's 7:45 am here - to get mouse-based actor and waypoint movement working. And yeah, I did get it to work. Holding the right button down on such an object allows dragging left/right/up/down (or on X and Y axis with neutral camera), while holding the middle button allows dragging forward/backward (Z axis neutral). The left mouse button is purely for camera purposes. Also rewrote parts of the picking code, added a VSync option to limit the FPS, and did some tiny changes and fixes to the GUI.

Railgun S episode 14:

I had put up some preliminary documentation on the actor definition format a while ago: http://magicstone.de/dzd/random/xmlactor/ - The format IIRC hasn't changed since and likely isn't going to anymore, either. Support for more Controls could/might happen, but that's about it. A final version of this document - as well as proper documentation for the editor itself - will be packaged with the first non-Beta build. EDIT: Actually, disregard the Description parameter of the ActorDefinition tag, that's now in the separate ActorNames.xml file. Just use <ActorDefinition> ... </ActorDefinition>. And there's not really a way to simplify generating the files, besides basing a new definition off of an existing one, like the default Generic.xml.

SceneNavi v1.0 Beta 3 Changes since Beta 2: Support for ROMs with z64tables hack ROM loader error handling changed; now allows access to exception details for reporting Human-readable actor names now read from ActorNames.xml instead of individual actor definitions XML data files rearranged; removed AddressTranslations.xml and address translator class, added more versatile hashtable reader class, also used by actor names Object names are now version-independant, using the hashtable reader class mentioned above Added collsion rendering with two different highlighting modes (all white, or approximately by ground type) Actor definitions changed to use hexadecimal values for rotation Collision editing as shown above will be in Beta 4; it's still not very well tested and missing a lot of GUI features, so it's not available in this build.

The error handling in Beta 3's ROM loader will be able to give you more details about an exception, which in turn you can post here for me to see where exactly the error occured. That said, it does work for sure with unaltered 1) MQ Debug and 2) decompressed OoT ROMs - if it doesn't do so for you, it's probably a, in some way, "bad" ROM. It does not work with compressed OoT ROMs or Majora's Mask. Also nice to hear that it works on Mono, although I cannot guarantee that it'll work 100% perfectly.

More Steam sale stuff: Burnout Paradise: The Ultimate Box Half-Life 2 & Lost Coast Burnout is quite cool and actually runs alright on my system, even with its rather crappy video card. No full HD resolutions, no anti-aliasing or anything, tho. Also, not gonna bother with the online stuff in the game, as that apparently needs an EA account or whatever...

mzxrules: That would be great! There's not very many actor definitions yet, every new one counts Also, speaking of which, the fixed (as in, using mzxrules' information) definition for the info spot: <?xml version="1.0" encoding="utf-8" ?><ActorDefinition> <Item Index="0" ValueType="System.UInt16" DisplayStyle="Hexadecimal" Usage="ActorNumber" Description="Actor Type" ControlType="System.Windows.Forms.TextBox"></Item> <Item Index="2" ValueType="System.Int16" Usage="PositionX" Description="Position (X)" Mask="0xFFFF" ControlType="System.Windows.Forms.TextBox"></Item> <Item Index="4" ValueType="System.Int16" Usage="PositionY" Description="Position (Y)" Mask="0xFFFF" ControlType="System.Windows.Forms.TextBox"></Item> <Item Index="6" ValueType="System.Int16" Usage="PositionZ" Description="Position (Z)" Mask="0xFFFF" ControlType="System.Windows.Forms.TextBox"></Item> <Item Index="8" ValueType="System.Int16" DisplayStyle="Hexadecimal" Description="Trigger Radius" Mask="0xFFFF" ControlType="System.Windows.Forms.TextBox"></Item> <Item Index="10" ValueType="System.Int16" DisplayStyle="Hexadecimal" Description="Unknown (1)" Mask="0xFFFF" ControlType="System.Windows.Forms.TextBox"></Item> <Item Index="12" ValueType="System.Int16" DisplayStyle="Hexadecimal" Description="Unknown (2)" Mask="0xFFFF" ControlType="System.Windows.Forms.TextBox"></Item> <Item Index="15" ValueType="System.Byte" DisplayStyle="Hexadecimal" Description="Message Number" Mask="0xFF" ControlType="System.Windows.Forms.TextBox"></Item> <Item Index="14" ValueType="System.Byte" DisplayStyle="Hexadecimal" Description="Switch Flag" Mask="0x3F" ControlType="System.Windows.Forms.TextBox"></Item> <Item Index="14" ValueType="System.Byte" Description="Manually triggered (C-Up)?" Mask="0x80" ControlType="System.Windows.Forms.CheckBox"></Item> <Item Index="14" ValueType="System.Byte" Description="Unknown modifier" Mask="0x40" ControlType="System.Windows.Forms.CheckBox"></Item></ActorDefinition>

Not sure if we have a thread for this already; if we do, I couldn't find it and would like to request merging this one into it. Anyway, this is a thread for basically posting information about actor variables and properties that isn't yet on the wiki. Why not post it to the wiki directly? Because one might not be 100% sure about what they've found out, or because the information is incomplete, or another such reason... like it is for what I'm about to post. So, OoT actor 0x011B, the Navi information spot. First of all, the "variable" broken down into its bits: T?CFFFFF MMMMMMMM [*]T, bit 15: Trigger type. If this bit is set, the information spot is triggered manually by pressing C-up when prompted by Navi, if it is clear, Navi's information pops up automatically. [*]?, bit 14: Unknown [*]C, bit 13: Clear on exit. If set, this appears to clear the flag this spot is attached to on leaving the scene. [*]F, bits 12-8: Flag number. What flag this spot is attached to. [*]M, bits 7-0: Navi message number, as already documented in the big actor list on the wiki. EDIT, as per mzxrules: naviIcon = ((Variable & 0x8000) > 0); switchflag = (byte)((Variable & 0x3F00) >> 8); dialog = (byte)(Variable & 0xFF); Also, what are commonly an actor's rotation values have different meaning here, too. X rotation, for example, is the trigger radius. The higher the value, the further away this information spot gets triggered from. For example, the "see down below this web" spot from the Deku Tree uses 0x28 here, which is a radius that's just a bit bigger than the physical shaft in the room geometry, while ex. 0x48 allows you to trigger the information spot from halfway between the dungeon entrance and shaft, and 0x70 allows triggering from just beyond the entrance. The other two rotation values, Y and Z, are also set to non-zero values in some of the information spots in the Deku Tree, but I do not know what they're used for. And to blatantly advertise SceneNavi's versatility, an actor definition for this can easily be written in a matter of a minute or two, if you know the properties (like above) and a bit about data types (byte, uint16, etc) and bit operations.

Railgun S episode 13...

Noticed that Seitokai Yakuindomo OVA 6 is out, just had to watch it right away... Ahhh, what I would give for another season with weekly episodes, instead of waiting half a year or so for each new OVA. Plus, there's apparently only one more OVA coming anyway. It's been pure perverted fun as usual. And I'm aware of the irony of having "pure" and "perverted" in the same sentence. Spoilered, although no-one's probably watching SYD anyway...

I saw your shout half an hour or so late, after you'd already gone, so I guess you didn't see my reply. Although I had just confirmed that, yeah, Magia was one of the songs played, anyway There's still more stuff to add, fix and/or make sure works correctly before the next version, but I'll hopefully get one out by the weekend or so. Oh, and it does support custom maps, there's been a screenshot or two of the SharpOcarina demo scene in SceneNavi in this thread before