jetsetdanny

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 :) .

Yes, it makes sense and I think I understand, thanks, Ian :) .

Ian, when you say "may be skipped", does it mean it is sometimes skipped, and sometimes it isn't, or do you really mean it is *always* skipped (and hence the suggestion to modify the initialisation code)? If it is only sometimes skipped, what does this depend on?

If I understand your point correctly, I would add that you realise this when working in JSWED: often when you delete a conveyor or a ramp (let's say, working on a room which you didn't design yourself), you suddenly see that there were Earth or Water cells beneath it. My first instinctive reaction to it was: How come?, until I realised that ramps and conveyors "supersede" the other types of cells without actually "overwriting" them.

Thanks a lot, Richard! :)

I have to inform everyone interested that the release of the Special Edition of "Willy's New Mansion" will be delayed a little bit. There are two reasons I have not been able to keep my self-imposed deadline: 1. The workload related to creating and playtesting the game and writing and proofreading the Readme file has proved to be excessive in relation to the spare time allowed by real life. 2. Some more bytes have been freed up thanks to optimisations suggested by friendly contributors at this forum, especially Ian Rushforth (IRF), and some new elements have been and will still be introduced in the game. This will enrich it, but, logically, requires more time. I do not want to rush the release in any way. The quality of the game and its being a final, definitive product are the most important. Therefore, I will not set any new release date for the moment other than to declare that ideally I would like to postpone the release not more than a few weeks. Both the game file and the Readme are in its final stages, so it should not be too long now before they are ready. I am sorry to disappoint the thousands of aficionados who have been waiting eagerly for today ;) . I trust that the quality of the game will fully compensate you for your prolonged wait. So watch out for the release announcement coming to these page soon! :)

Ian, I think "Guardian Halo/Shadow" is best, and, after getting used to it, I would say that 'Guardian Aura' is OK, too, after all, if you prefer it.

It sure is, just like here :D .

The connotation of this definition may be "darker" in the sense that's it's an unwelcome, undesired effect, but it's not darker physically at all - quite to the contrary, it apparently has to do with light again, as these definitions attest: Pathology. a sensation, as of lights or a current of warm or cold air, preceding an attack of migraine or epilepsy. Medicine A sensation, as of a cold breeze or a bright light, that precedes the onset of certain disorders, such as anepileptic seizure or an attack of migraine. a subjective sensation (as of lights) experienced before an attack of some disorders (as epilepsy or a migraine).

Thanks for your comment, Ian. In fact, I must have made a mistake when posting the message, or perhaps it was correct at the time and then got changes, because I currently have in the Readme: 91F1 In-game music note index (moved from 85E1). (...) 9BFF Music flags (moved from 85E2). So everything is fine, I believe. However, I appreciate your insight and your comment :) . On an unrelated note: looking at the title of this thread this morning, , I think it may be the best description of the phenomenon, after all: 'Guardian Halo/Shadow' Bug Fix'. Halo and Shadow are two words, but between the two of them they are all-inclusive and they are a perfect description of the nature of the phenomenon...