IRF

That would bypass the initial phase, taking the guardian straight into its 'settled phase'. To quote myself last night: "I tried using #FD or #FF for the second byte, and it ends up much the same as your file, although yours has an early 4-colour phase where the colours go from 'dark-to-light' (blue->magenta->cyan->white), before settling into a pattern of 'light-to-dark' (white->cyan->magenta->blue) and staying that way. And in yours, the very first pattern is a 2-colour magenta-white phase (just for the first few colour changes) before the 2-colour phase settles on blue-cyan." I actually think it would show much more interesting and quirky behaviour if you revert back to a value of #03 for the second byte. (In my humble opinion. :) ) EDIT: Actually I would go further (and be less humble in the process! :P ) The fact that you chanced upon the value #7F for the eighth byte by accident, and you happened to choose #03 for the second byte, means that you inadvertently came up with the most convoluted pattern of colours it is possible to achieve via this method (which is itself based upon an unintended oddity of Matthew's original game engine)! I think serendipity suggests that you should go for a starting value of #03 for the second byte!

In the test file which I looked at last night ('quite good'), the eighth byte (at address #A007) was set to #7F, whereas the one you've just provided that goes through just three colours has the eighth byte set to #7E. Presumably that's also the case in your 'proper' project? (Remember, JSWED will try to be 'helpful' and fix certain bytes to even numbers to avoid 'Attic Bug' style corruption - I suspect that may have happened in this case?) So I think using #7F for the eighth byte (setting it that way in the Hex Editor rather than the GUI) should resolve it - that worked when I just tried editing #A007 in your '3 colours only!' test file, so it should work on your 'proper project' as well. EDIT: Notwithstanding what I said about only using even numbers for the eighth byte, which is not important unless you want a guardian which also (with the same definition) moves normally in JSW128. I don't think the chosen sprite page (sixth byte) changes things at all. (I was completely mystified as to why it should, until I spotted the difference reported above, at which point I was relieved!) Now, as to why #7E versus #7F makes a difference requires further investigation by me at some point... I'm still not sure how the 'Move the guardians' routine comes out with three colours, when it's incrementing by either 2 or 4... The guardian must be hovering around the transition between 'slow-swinging' and 'fast-swinging' rope phases? EDIT: Yes, I think that's more or less it. Oh, by the way: I'm glad you made sense of them, despite some rather dodgy 'auto-correct' choices by my Tablet! ('Direction of swing' got changed to something very odd - I can't remember what now, having edited the original post last night - but it was 'Direction of sewer's or something like that!)

Our posts just crossed! As I explained in my previous post, I think your guardian does cycle through four* colours for most of the time - it just has regular (but brief) periods where it only cycles through two colours. That's unavoidable since it is behaving like a rope, which speeds up in the mid-point of its oscillations. *I just fixed the pause bug in your test file, freeze-framed through the sequence, and confirmed that four colours (including magenta) are indeed used. P.S. In my earlier analysis, I didn't really go into whether BRIGHT or non-BRIGHT colours are used, but both are at times, it seems. P.P.S. Have you tested whether this guardian 'behaves' in the JSW128 game engine? (It should do, I think.)

Okay, I was curious so I just took a look. (I can see that you used Base sprite 7 so it doesn't animate through different frames.) One of the reasons I investigated this evening was because your description of the colour scheme puzzled me - I couldn't see how it would end up cycling through three colours. In fact, I think you're mistaken on that - having watched it, it clearly goes through all four 'odd' colours most of the time, but with a brief intermediate phase now and again when it just alternates between blue and cyan (when the 'rope' is swinging through its central equilibrilium point, it swings faster, so you just see two colours), before reverting back to the four colours for several 'cycles', and then the pattern repeats. I tried using #FD or #FF for the second byte, and it ends up much the same as your file, although yours has an initial 4-colour phase where the colours go from 'dark-to-light' (blue->magenta->cyan->white), before settling into a pattern of 'light-to-dark' (white->cyan->magenta->blue) and staying that way. EDIT: And in yours, the very first pattern is a 2-colour magenta-white phase (just for the first few colour changes) before the 2-colour phase settles on blue-cyan. So using #FD or #FF is more 'consistent' (always 'light-to-dark' from the offset), but your version (with the second byte = 03) is more interesting and quirky, I would say. :) Incidentally, the test file has a bug whereby if you pause (using the A-G keys) and then unpause it, my emulator crashes and resets!

Try either #FD or #FF for the second byte (instead of 03), with all the other bytes as before. (That's purely a guess!) Does your guardian change animation frames, by the way? (I'll try and get a look at in action tomorrow.)

It probably is relevant! I find it easier to believe that the Attic Bug caused corruption of the guardian data, leading to the same phenomenon, than that the Attic Bug somehow rewrote the game routines to include JSW128-style colour-changing guardians! :P

On second thoughts, it might not be possible to get a guardian which replicates the exact cycle of colours of the barrel, but using Blue/Magenta/Cyan/White - the actual y-coordinate (fourth byte) has to be an even number for the guardian-drawing routine to draw it safely (without an Attic Bug-style incident!), and so it will never match the eighth byte (extremity of swing when it is being 'moved' as if it were a rope) if that is assigned an odd value, and so it will always end up swinging in the same direction, I think (so the order of colours displayed will never go into reverse). EDIT: I've just remembered another factor to consider - the eighth byte needs to hold a value less than #80 (so #7E is the highest practical value, as per the barrels in 'Jet Set Mini', given that it also needs to be an even number), in order for the 'rope' to turn around. That's because the command at #9120 resets bit 7 of the second byte before it compares it with the eighth byte. So keep bit 7 of the eighth byte clear IF you want the colour sequence to reverse periodically. FURTHER EDIT: Looking at your earlier trials, it seems that you didn't try a large value for the eighth byte other than ones which exceeded #80. And all the values you tried were in the range of a 'narrow/fast swinging' rope (incrementing by 4 at a time); the animation frame has to get past #12 (or it might be #14 - see #90F7 and similar commands) before it starts swinging more slowly/incrementing by 2. So ironically, at #0A, you may have stopped just a few increments short of a value that would have yielded more positive results! Anyway, try #7E for the eighth byte. (Note that it will still go through a phase of alternating between just two colours, before it resumes cycling through four, as it passes through the 'near-vertical' position in its 'swing'.) ANOTHER EDIT: The upper three bits of the second guardian definition byte determine the animation mask. The 'rope-like' behaviour might interfere with that, causing the guardian to stop and start animating through different sprite-frames. (That isn't an issue with the 'Jet Set Mini' barrel, as it only has one frame of animation, and I think from memory the barrel bitmap occupies the last 'slot' on the sprite page, with the 'base sprite' set to 7 in the third byte [via the guardian specification byte in the room definition, which also specifies the x-coordinate], thus 'overriding' the animation mask. N.B. I still haven't had chance to see your guardian 'in the flesh', so I don't yet know whether it is animated, or if is meant to animate?) However, none of the above should affect your ability to place the guardian wherever you want on the screen (via the third and fourth definition bytes), since your guardian is non-moving. i.e. the fifth byte, which determines the speed, is set to zero. (N.B. My barrels appear to have a speed setting of 02; I'm not sure why I didn't set that fifth byte to zero - if you transposed the barrels into JSW128 they would probably start moving instead of changing colour! If you want the same guardian definition to be non-moving in both game engines then leave the fifth byte set to 00.)

JSWED's GUI won't let you input odd numbers for the eighth byte, because it thinks you're inputting a y-coordinate, and the y-coordinates work in increments of 2 (they look up pairs of values from a look-up table). Incidentally, the 'Attic Bug' arises from an odd value being used for an arrow's y-coordinate. You should(?) be able to replicate what the flashing barrel in the West Wall of 'Jet Set Mini' does - including the fact that the 'direction of swing' periodically reverses, causing the sequence of colours on display to flip around - but using the four 'odd' colours, by manually setting an odd value for the eighth Byte and then playing around with the other bytes. You won't achieve the same pattern of colours as the JSW128 colour-changing guardians, because that involves a mixture of 'odd' and 'even' colours. The rope-moving routine only ever increments the second byte's value by 2 or 4. EDIT: Bit 0 (the lowest bit) determines whether a number is odd or even, adding 2 or 4 (00000010 or 00000100) leaves the status of bit 0 unchanged (as you'd expect based on your intuitive understanding of the decimal system).

Try experimenting with different values for the eighth (last) definition byte. You're trying to replicate the rope being 'far out' in its swing, where it is being incremented by 2 (as opposed to being stuck near the central/fastest bit of the swing trajectory, when it is being incremented by 4, so you only get two colours when it is drawn. EDIT: You should probably select a multiple of 4 (i.e. the byte ends in either 0, 4, 8 or C), otherwise the position of the 'rope' will never match its outer limit and so won't 'turn around' to swing back again (which is manifested, in this case, in the pattern of colours being reversed). Regarding setting/resetting bit 0 of byte 1 (i.e. to switch between the 'odd' and the 'even' colour palettes), the easiest way is just to change the guardian's colour in JSWED's GUI.

Further to my previous post: I haven't had chance to check out the test files you uploaded yet, but I would guess that the guardian is located quite high up on the screen in which it appears (i.e. it has a low value for its y-coordinate)? And I would also guess that you have the 'default' colour of the guardian (i.e. bits 0-2 of the second definition byte) set to white (or magenta)? Anyway, if you try changing the maximum y-coordinate (the eighth guardian definition byte) to a high value (N.B. this shouldn't affect the placement or static nature of the guardian in either mode, and nor should it affect the appearance/colour sequence of the guardian in JSW128 mode, provided that the guardian's vertical speed [fifth definition byte] is set at zero), then in JSW48 mode, the colour-cycling should go through four colours at times (namely the four 'odd' colours). And if you also reset bit 0 of the second definition byte (i.e. choose one of the 'even' colours as its default colour), then the JSW48 incarnation of the guardian will cycle through the other four colours (again, without affecting the guardian's appearance in the JSW128 engine file). EDIT: In the above, when I referred to the aopearance/placement of the guardian being unaffected, I mean in-game. (When viewed in JSWED's GUI, that might not appear to be the case).

Based on the description, it sounds similar to the colour-changing barrels that can be found half way up the West Wall in 'Jet Set Mini', which are considered to be ropes by the 'Move the guardians' routine, but drawn as guardians (with fatal collisions with Willy, etc) by the 'Draw the guardians' routine. In the JSW48 engine, the former routine only picks up bits 0-1 of the first byte, whereas the latter routine picks up bits 0-2 (compare the commands at #90CA and #91CB), so if you try to create a JSW128-style guardian in JSW48, by using bit 2 of the first byte, then the game treats it differently when it comes to moving the guardian versus drawing it! I believe it should be possible to get your guardian to display a wider 'colour scheme' without making ANY changes to the JSW48 game engine, but by fiddling around with the guardian definition bytes instead. EDIT: In four different colours (either all the odd colours Blue/Magenta/Cyan/White, or all the even colours Black/Red/Green/Yellow), not five as you requested.

May as well, it wouldn't be a big task.

I presume you meant to say there: "The logical sequence from JSW128VK and JSW128VL" ? (Since this is Version M?)

Didn't we figure that out during the development of 'JSW: The Nightmare Edition'? I seem to recall relocating one or two of them, to ensure that they all had a solid block to their left (in which the cleaver is embedded), rather than 'floating in mid-air'. :P

Conservatory Roof: "Those are probably little bears holding bottles" (as per my avatar). That corroborates my theory that they should all be paired up (Fire cell adjacent to collectable item), and any fix for the uncollectable item in there which doesn't pair them up is unsatisfactory.

There's a preview of a few pages of RG201 available online, including the first two pages of the article which Andrew mentioned - and I noticed that a certain Mr Gromann of this parish puts in an appearance!

Interesting - I had those down as bats, flapping their wings up and down. Their ears turn around as well, as if they're navigating using sonar. It's funny how people come up with quite different interpretations for some of the sprites - on the Yahoo Group, someone described that same guardian as a 'woodcutter'! Anyway, I think I'll stick with my interpretation for my project 'Willy's Recurring Nightmare' (if it ever emerges), because

It seems that you're right about that Danny, sadly. Funnily enough, I managed to post some messages on there, and view them, only on Sunday (the 15th, so after the supposed cut-off date of the 14th). So I was hopeful that the site would remain in the same format as before (except for the inability to upload attachments, etc). But it seems that that is not the case after all. :( However, some good has come out of the situation, because it has prompted several Yahoo Group 'veterans' to sign up here! :)

As an early Christmas present to the jswmm community, this project has been updated with the addition of a 'Mega Bonus' Cheat Mode (activated during the loading process by pressing $ whilst the BASIC loader is being executed). This allows you to accrue even higher scores than in the 'Big Bonus' edition! Who will be the first person to score a million points, I wonder? B)

To fix the 'Sticky Bed' bug: POKE 58326,254

There's an inconsistency in the previous post - is the game called "Still Stealin'" or "Steal Stealin'" (or maybe "Steel Stealin'")?

I just posted a new message on the Yahoo group with no bother. ?

Actually, there's probably no need to pause the game at all is there really? Just hit the 'Print Screen' button whilst the game is running on your emulator, then paste into MS Paint (or whatever), crop the image and save it as a JPEG/PNG/whatever. That's what I tend to do (and, like you, take another one if there's an obvious glitch).

It should be accessible by pressing all the keys from 1-6 along with the 9 key (111111 in binary = 63 in decimal). It's only when you go beyond that that you would need to pick up an additional number key. However, depending on what emulator you are using, not all number key combinations are always possible... Another possibility would be to POKE the value of the room number (33824/#8420) to a value of 63/#3F. But then you might (or might not?) enter an IDS before the screen layout is refreshed! [in the same way that POKING the room number in order to try and access The Bathroom can initially cause the toilet to appear in the room you are attempting to teleport from - guardians can even crash into the toilet in such circumstance, killing Willy! - but then the room is refreshed after losing a life, taking you 'properly' to The Bathroom.] ...Anyway, the room name "How on earth did you get here ?!" is very appropriate, it seems! There's also a room called 'Cheating?' in Jet Set 40-40, although you haven't yet created a suite of screenshots for that game in any case.

If you pause the game using the emulator's pause function, then you might chance upon a moment during flow of execution when sprites have only been partially updated - something which Norman Sword refers to as a 'jagged finger' effect, except in this circumstance it would be frozen in time (and therefore very obvious), rather than being an instantaneous (but visible to the keen eye) flicker. Ditto with the updating of the colour-attributes - if you pause at a moment when the pixels have been updated during the current time-frame but not yet the attributes, then you could for example have arrows drawn in an INK colour other than white [assuming the engine isn't hacked for non-white arrows anyway], if the screen in question has Air cells with non-matching INK and PAPER colours [which is usually the case with rooms that have a rope]. So I personally think that pausing the game using the in-game pause button is a more sound approach in order to capture a comprehensive screenshot - but you then have the problem (usually) that the screen colour-cycling kicks in before long. So I would say that a combination of pausing in-game, and then hitting the emulator's pause button before the colour-cycling commences, would probably be the best approach for grabbing screenshots. The quote above appears contradictory to me - I'm not sure whether you're saying that you do include screenshots of rooms that are only accessible by WRITETYPER, or whether you don't tend to include screenshots of such rooms in JSW Central? EDIT: By which I mean, the 'Correction' does not appear to contradict your original statement, despite being labelled a 'correction'! However, the entry for 'Jet Set Mini' certainly does include a screenshot of the unaccessible (other than by using WRITETYPER) room called 'Cheating?' But in that case, accessing the room does not necessarily cause an Infinite Death Scenario [unless you happen to teleport into the path of a guardian], although it does cause Willy's INK colour to turn yellow - with the consequence that even if you teleport back out of that room and back into the mansion, Willy can no longer collect items - a suitable punishment for trying to cheat! I would add that, depending on what causes the instant death, a screenshot captured by pausing the game within such a room may or may not show the full picture. e.g. if Willy collides with a guardian that appears early in the guardian list for the room, and is therefore drawn first, then later guardians in the list would not be displayed. If Willy hits a Fire cell (or if all the Air cells in the room are effectively Fire cells, because the attributes for Air and Fire match), then no guardians will be drawn at all, because the Main Loop reacts to Willy hitting a Fire cell before it gets chance to CALL the Draw the Guardians routine.