jetsetdanny

I believe that this is post #5000 now :) . Sorry about it, Ian; I'm feeling like like the American women's relay team at the Olympics, kind of... :lol: .

Unless the code was so tweaked that the warning sound would be when the arrow is e.g. 10 rows from Willy, or something like this...

Ian, that's a fantastic invention, I really like it! :D Congratulations! So you have created a true "constant arrow" now. I once used that adjective to refer to what Andrew Broad described as "bouncing arrow" (because I couldn't remember which word he used - meaning an arrow which goes back and forth, really being eight arrows inserted at appropriate intervals). And now you've made my description a whole new reality :) . For a possible future game design, it's better that the arrow doesn't become valid and invalid, IMO. If it did, it would mess up its possible applications. Just one question now: the way you've implemented it, it would affect all arrows in the game, wouldn't it? It would be nice to have such special arrows only in some selected rooms...

Or the Nightmare has cast a bit of its ugly shadow there... :lol:

Ian, thanks for this info. You are referring to Room 59 (not 69), besides 61 and 62. I believe these are not errors. The thing is that the disassembly may not (actually I think: does not) reflect exactly the code in all of Geoff's games. I suspect (without analysing it right now) that the disassembly may have been done on the basis of his first game, "J4 (The Fourth Remix)". In his later two games there must have been some slight changes, and in the fourth game there must be many changes (as it's the so-called Geoff Mode 2). The PVs disassemblies have to be analysed by looking at the actual code of each game in question rather than by comparing them to the disassembly of Geoff Mode. In case of "Willy Takes a Trip" the pertinent code which is called indeed starts at #9763. Also, the printing routine (which I believe is something Geoff wrote, I don't believe it exists in the original "JSW") used by PVs in the rooms 10 and 53 of "Willy Takes a Trip" is where the PV disassembly indicates. I can testify to it, because I copied it into "WNM SE" and it works just fine :) .

Congratulations on post #5000, Ian! :D Concerning the previous millenial posts, I went by what Andy indicated to me concerning No. 1000, 2000 and 3000 (to identify which ones they were), and I posted No. 4000 immediately after posting No. 3999, and I did it by watching the home page where it says how many posts there are. IIRC it was 3998, I posted one on a different subject (bringing the total to 3999) and then I posted the one which was No. 4000. So, yes, I trust it was the one.

Yes, they are restored, indeed.

Not in a JSW48 game, but they are supoported in a JSW64 game.

Personally, I don't ever use the number keys to control Willy's movement. So I wouldn't mind these keys being assigned a different function.

I believe this can be done in the original "JSW" (and the remakes) by pressing any of the keys that pause the game and then pressing one of the QWERTY keys (or thereabouts, I didn't check which ones exactly). This unpauses the game without changing the status of the music.

Thanks for this info, Ian!

Thanks, Ian!

I think it may be useful, especially to non-native English speakers, to have a thread in which some language questions may be asked and answered. I am currently working on the Readme for the Special Edition of "Willy's New Mansion". I have the following description there, in the section dealing with code changes: 8356

Same here. Amen!

Apparently it's someone who runs Your Sinclair Rock and Roll Years and, according to one opinion, "is extremely biased against anybody running or modding WoS who's name isn't Martijn". It's supposed to be visible on his Twitter feed @YourSinclairRRY. There is some more (as well as some contrasting opinions) info about him on various pages of the thread in question.

WoS may have less than 8 weeks of life left! What a mess... :(

A very good suggestion - something which definitely belongs to the Trivia section!

I had a case of matching attributes while working on "WNM SE" earlier today. The beginning of a PV code - the LD HL command (21) - placed where the attributes for the conveyor normally are matched the attributes of the Water cells in "Willy's Personal Hideout". I set the starting point within the figure of Willy in that room (for testing purposes) and was surprised to find out I couldn't move, only jump! Then I set the starting point to "Copin' with Ropin'" and when I entered the Hideout everything seemed to be fine. So I was even more puzzled, until I reached Willy's figure made up of Water cells and Willy ("the little one") started running to the right. And then it dawned on me what was happening :) . I solved the problem by shuffling two pieces of the PV code around: I put an LD DE (11) instruction up front, it is now followed by the LD HL (21) instruction. Fortunately, it was an easy fix. I am writing this not to discourage anyone from using the attribute byte in the way we are discussing, but to give a true account, the first ever (in the history of the Universe :lol: ) of such a problem as a testimony that it can arise, and that it can also be solved satisfactorily :) .

Thanks for the suggestion, Ian. I guess it could also work if Offset #D9 was left as 00 as a break in the code (NOPPed out, so to speak). So, for example, there would be some meaningful code before it, then 00 at #D9 and then e.g. a jump to somewhere else (C3 .. .. ) at #DA - #DC. I doubt I will apply it in "WNM SE" (there's no need for it), but it's something to keep in mind for the future...

I would like to add another suggestion to this open thread, copying it from Ian (IRF)'s PM. This is Ian's "invention", which I would like to quote while at the same time testifying that it works just fine - I have applied it in the (soon-to-be-released) Special Edition of "Willy's New Mansion". So here is Ian's idea: --- More potential spare bytes: In any room where there is no Ramp or Conveyor (or Fire cells, etc) - the eight (contiguous) graphic bytes associated with each such unused room element. This also applies where there are composite room elements (Ramp-Conveyors, etc), for the eight graphic bytes of whichever component is lower down the list (Conveyors in the example of Ramp-Conveyors). Because the pixel pattern of the earlier room component will be picked up and used to draw the composite cells (e.g. the Ramp graphic in the above example), the space in the code attibuted to the pixel pattern of the latter component (e.g. Conveyor) is unused. However, in contrast, recycling the unused cell attribute bytes is not safe, since a Z80 command inserted therein might accidentally match an attribute byte of another room element, affecting the properties of such elements. e.g. if Water cells on a particular, Ramp-less screen have colour attributes set to Blue Ink on Green Paper [00100001 - #21 in hex], and then a '21' (LD HL, $00) command were to be inserted into the attribute byte for Ramps on that screen, then all Water cells would become Water-Ramps! N.B. It is only safe to use the eight spare graphic bytes if Stuart's Cell Graphics Bug Fix is in place (otherwise the same 'coincidence effect' mentioned above could take place!) --- I would just rephrase the above saying that if the value of the new code does *not* match the cell attribute, it is safe to use the attribute byte as well. And, in fact, the probability of the two values matching is rather low, I believe. So in most cases you can have additional 9 spare bytes for each element if Air, Water, Earth, Fire or Ramp are not used in a room. Furthermore, you can have additional 12 bytes for the conveyor, because after the 9 bytes analogous to the other cell types (at ... CD - ... D5) there follow immediately four more bytes specific to the coveyor (at ... D6 - ... D9) and the last of them is length. So I believe that as long as the length byte is set to 0, the other additional bytes (specifying the direction of the conveyor and its location in the attribute buffer) can be safely overwritten (if there is no conveyor, it doesn't matter what direction is has). SkoolKid's disassembly illustrates the layout of this potential free space. In one instance in the Special Edition of "Willy's New Mansion" (the room "Internet Cafe", where Fire, Ramp or Conveyor cells are not used) I had a continuous chunk of 30 spare bytes, which is quite a lot! Many thanks to Ian for his insightful coming up with this helpful idea! :)

Congratulations on this novelty, Ian! :) I like the round-and-round one better. There is something disconcerting to its movement... :unsure:

Congratulations on this fix, Ian! :)

Well, to be honest - I don't know. I was just going to say that both boxes (the one corresponding to "Adjacent ropes patch (new)" and the one corresponding to "Adjacent ropes patch (old)") are ticked and hypothesise that the "old" one gets ticked automatically once you tick the new one (because you can't apply both fixes at the same time). However, I've just had a look in JSWED, in the Game tab, and it looks like both of these boxes (as well as *all* of the other ones *except* for "Black Willy") *cannot* be either ticked or unticked - they are filled with blue, sort of. I'm not quite sure how to interpret this... And concerning what exactly #A3FA was overwritten with - I can't remember. I *think* it wasn't 00 or 01, but I'm not sure. I do have these files somewhere, but I have hundreds of files of "WNM SE" already and it would be too time-consuming to try to find the right one now (it would actually be much quicker to just reinsert the code into the space in question and see what happens when the game starts).

I think it's a person with his/her hands outstretched :blink: .

Not yet, but I am aware of it and I will work on it when I'm done with the code in "WNM SE", which should be very soon, hopefully. Thanks in advance for the document :) .