Spider

Generally a copy of the message is in the email content. :) Cannot reply via the email however its merely a 'notification' of the message itself. It is worth mentioning generally its individual account preference if emails are sent for any type of 'notification' such as a new pm or a reply to an existing (separate) as well as other items such as having part of your post quoted etc etc.

Some other JSW versions have a high score table. :) Well a kind of 'objects collected' high score table.

I don't see why not, I emailed him a while ago (got the email from his site) to ask him about something completely 'un JSW' related. :)

The other thing I should of mentioned was I tried various spacing options out (this may appeal or not to M.M. as its his topic anyway) with regard to having the item display only two characters in length as well a bit of a shuffle. Ignore the font as its part of my slightly custom 48K rom... Note these all display the leading zero for the time however, mainly to check spacing issues. You'll have to ignore the colour choices in these pics as they are merely mockups: 1. This is just a sample with only a "00" rather than "000" object counter: 2. Inset (space at either end) , 00 instead of 000 for objects still and no am/pm indicator. Intended really for a 24hr clock 3. 00 instead of 000 for objects again but simply pushed back to the edges compared to (2)

Yes it did not look quite right somehow. :) :unsure:

One thing I toyed with (for no apparent real reason) was to have it show the leading 0 for the time so it was "07:00" instead of " 7:00" as the block is already set to white anyway for the 0, it did not quite look right somehow :unsure: The other thing I did was change the 'a' and 'p' of am/pm to 'A' and 'P' , this needs a couple of pokes to get it right due to the fact the 'switch' checks to see what char code is there (and a vs A is different) That apart from a 24hr clock with or without rollover.

:lol: True. What you have done with that poke is very similar to what I did, well the effect is in that he cannot fail to get it regardless of which side he falls down from above. I did toy actually with doing something with the Beach object but you have to place it one or two blocks in to get it to auto collect and it was not really ideal as it was possible to jump into the screen and miss it. I then thought about putting it on top of the rope ( ! ) but that was not ideal either. :D

No. :) I just fire up the game and apply it during the title screen. I do then start, exit and restart the game to be sure ( ! ) its taken effect properly. The main reason for the restart is I have noted in the past if you change the starting room during the title screen the change does not take effect on game start, you have to restart but given your info below that does explain why anyway as its not re-initialised until you get back to the 'start' (no pun intended!) of the 'start' routine.

As I see if you apply the changes during emulation it does not appear to work, even if you reset the game a couple of times... :unsure:

Yes. :) Will throw you a quick PM actually about this.

No. :) I did wonder if that was the case as a single poke would not give it a form/shape but no incrementation of counter. Tried with a different copy and just the same. I verified the location too: Although its a disassembly view can see that 42439 is indeed at 53:

:) I used an original version (complete still with keypad!) and simply applied the POKE. I then started / restarted the game a couple of times to be sure it was 'set' but was no able to find the item on my travels :unsure: :)

:) When I tried it a while back, left invisible just in the path at the top of the ramp IIRC one block down from the top was ideal, I did not give it a shape. But I used JSWED to move it then compared the item code area's, and two bytes had changed which I thought odd, but I did not look into if one of the changes would of happened anyway due to JSWED... I can't find the item :unsure: with that poke. Its not in one of the few places I thought it might be, lower down in same screen or in the top of Ballroom. :D

1. Yes, but its not a bad placement by any means just seems a bit too easy to grab. Having said that he'd have to climb the platforms anyway for the lower Tree object at some point... 2. That's a point. Kind of brings onto the subject of rooms with items defined but unused (items rather than fire cells) :unsure: , but their designs are in the room code itself as you know so there is little doubt any item graphic is in the "wrong room" as such... I do agree there should not be a need to copy/move the item design graphic over, similar to how I copied the one from 'Above the West Bedroom' or 'West Wing Roof' to 'The Hall' simply as it was a couple of bytes (IIRC the West Wing Roof is less bytes) and both graphics looked suitable there, but not ideal in either case. The 'fix' for this should be a single byte change. I toyed with moving it and keeping it in the First Landing but putting it at the almost top of the ramp so it was auto collected upon entry, regardless of which side of the floor Willy fell through in Top Landing, but this seemed semi cheating and it appeared to need two bytes to do it as well.

Off hand no I do not think anyone did, this may be due to the possible lack of understanding on how the items are actually stored, its not immediately obvious how it works (to me at least!) until you look closely at it... Thanks for taking the trouble with the investigation. :) I do recall I posted something (but not as detailed) last year. The item location looks sensible in West Bedroom and West Wing too. I do see what you mean about the Swimming Pool symmetry (although as you say its not quite) so I think that one can be ruled out as there is already one item there anyway. Not saying it should not have two though. :D Tree root does look very good moreso with the item shape actually being at the correct angle to sit on the slope anyway. The only downside of this is it means there are now three items in this room*** Out on a limb and Banyan Tree, to me at least they do not look right with the additional object. The location in West Kitchen is interesting although my mind tells me its too low down allowing the player to collect it on their travels without climbing the platforms ? I do agree if practical a single byte change would be better as you correctly put if we have to change more then it could go anywhere instead. :D *** This leads to a new thought, as you know room 47 aka " ] " , this is connected to Tree Root or vice-versa. This does make me wonder **if** your 'slope fixed' item is correct and one of the others, possibly the top right one is not in the right place in this screen as its nearly obvious that 47 was meant to be adjoined here... hmm.

I do remember trying this object location (its in effect "AT 3,26") in different rooms to see the effects. One quick test of this is to set that attribute block to a different colour to check how it would look (for placement and accesbility reasons) in each room. To do this its POKE 22650 , x but you won't see it during an emulator pause in most cases as the screen will not be updated. There are two ways around this: 1. Pause the game with the game's pause option. Use Writetyper if needed to stop it cycling. While the pause is in progress you can apply that poke to see the block highlighted 2. Apply it directly as a single .bin file, although this is slightly more work. x = does not matter that much really. 250 or 175 are reasonable choices here to easily 'see' them. From memory (I've not been through them all) there are only about 3 rooms where the object would be both easily accessible *and* not look too far out of place ie either not floating or if it was in an airbourne position it would not look too far out of place. I guess its debatable if the room ID or the position ID is wrong though :unsure:

The 'I' registers have been a slight source of confusion for me given their unique erm properties, at least as I understand it. :unsure: :)

What I tend to do apart from applying Richard's three pokes to fix the pause bug (if I don't remove the whole routine instead!) is also remove the INC A instruction that lives at 35518 / #8ABE , although in theory I could chop the check out further down removing this as you know will just stop it 'auto pausing' if the in-game tune is disabled. This single change on its own will also in theory at least fix the pause bug on a real machine if an IF1 is attached provided the user never pauses the game too, but for safety I always apply the three fixes anyway as his work properly compared to others but as mentioned my favourite really is to simply remove all that section ideally. Personally I never saw the need for it to either auto-pause (or not) dependent on if the game tune was playing / not playing. :) I started writing a large bit of text here then had a brainwave instead: http://jswmm.co.uk/page/guides.html/_/jetset-willy/pause-bug-fix-r7 :)

It would be useful to gain a few bytes in the main loop yes without (for example) either sacrificing the 'screen flash' routine and / or calling other pieces of code temporarily from within the main loop. Possibly exception to this I guess is the pause control as that could in 99% of cases safely be binned as most will be using emulators where pause is a click away and failing that not too many variants do impose strict time limits.

CTRL+Enter can cause it to think you want to submit, its always been like that though however it can vary between browsers. Its a CKE concern rather than the software directly but as CKE Editor is part of the software, I see what you're saying. Using a mobile device will vary in its behaviour too. I'm sorry you've had editor issues, I can honestly say I've not had any other complaints regarding it as such apart from the odd 'jumble' quote issue where multi-quoting has got out of hand. :) You will however hopefully be pleased to learn the newer version (coming soon here!) has more control on this: In particular 'Return' will either start a new paragraph or go to a new line and the 'paste' feature will still retain its 'pasted' format however there is a button on the toolbar to quickly and instantly kill all formatting in said insertion where needed which may restore a bit of sanity if it got out of hand... Post deletion has never been enabled per member control however there is no issue in having said posts removed, its more a case of 'member accident' with this as I have seen this happen before... I have removed the post. :)

Thank you for the detailed explanation. :) Its interesting you mention more guardian movement as IRF has an article on Diagonal Guardians here in our Articles. During other project work I noted one variant (C+4) had what I could only describe as a near-trapezoidal movement pattern which was quite interesting to watch, probably not much fun to code in however...

That looks quite good like that I think. :) A certain "chunkyness" to it without it being excessive. The ropes in the C64 version are slightly chunky as standard (lets not talk about the square stairs that are difficult to jump through though!) , similar for the C+4 / C16 versions actually...

That's very unusual but I do quite like it. :D

That's quite interesting. :) I like what I see. I do see the erm 'assistance' options although not the immediate method of activation however not a concern. There are some nice features present in this from just a cursory glance, I will have time later to play properly to examine it in more detail.

The effects are brilliant. :D especially the collision and game over. I also appreciate the icons for various in game status such as the tune and keys, and cheats. I also like the fact the 'boot' must be enabled first to use some of these. EDIT... I do not see an immediate change with the keys however :unsure: , I do like the merge ink effect rather than overwrite when WIlly passes near a platform.