jetsetdanny

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

Thanks for this info, Ian! :)

The dates of the previous millenial milestones were: Post #1000 - 27 November 2015 Post #2000 - 3 January 2016 Post #3000 - 12 February 2016

It's the kind of question like about a man who fell into the water, couldn't swim and drowned. If you say: "the reason he died is because he fell into the water", it's true, but it's not the whole truth. If he fell into the water and could swim, he would get back to the shore and be safe. So the real reason why he died is that he fell into the water AND he couldn't swim. The same goes for Willy. The reason he gets stuck is that he can progress through the Earth cells at head height only in one direction (to the left) AND something (unrelated to the "bug" itself) stops him from progressing to the left.

And, similarly, with good planning Willy wouldn't *ever* get stuck because of the *feature* which allows him to walk left through blocks at head height *if* there was nothing else in his way which would stop him, such as an Earth block at leg height or a right conveyor (or a Fire cell, for example, or the top half of a guardian to block his way). To say that "the fundamental reason he gets stuck is because a bug allows him to progress into Earth blocks, but only in one direction!" is certainly true, but it's not the whole truth. The whole truth is that if he progresses into Earth blocks, he gets stuck *if* something prevents him from going left until exiting these Earth blocks at head height.

On a one-way street cars are only allowed to go in one direction, and while it doesn't have much to do with the natural laws of physics (as doesn't Willy's movement, either), it is perfectly in line with man-imposed laws and regulations ;) .

Thanks! :)

There is no conveyor, but there is an Earth cell at the height of the lower part of Willy's body, which prevents Willy from moving on to the left. If that particular Earth cell wasn't there, Willy could move left (he would then get killed by the Fire cell below, but you couldn't claim that Willy gets stuck because of the bug).

It is the Screen Flash PV (which I call the Flashing Screen PV in "WNM SE"'s Readme), indeed, and its cousin, the Coloured Screen PV. I offer a disassembly of all of my PVs in the Readme, and these two go as quoted below. The descriptions in red are obviously wrong and need to be modified. If you have any suggestions as to what specifically should be put / would make sense there, please let me know :) . Flashing Screen This PV works by setting the value of the screen flash counter and thus activating the screen flash routine (which is unused in the original "JSW", where it resides at #8A11

Thanks for these explanations, Ian! :)

This is post #4000 on the forum :) . Perhaps the next milestones of this kind could be highlighted in this thread?

Thanks to both of you, guys, I appreciate your help!

I am currently working on the Readme file which will accompany the Special Edition of "Willy's New Mansion". I am describing in it, among other things, the way the patch vectors (PVs) which I created work. I have come up against a problem in the description of two of the PVs which has to do with the AND instruction. I will be very grateful for assistance from anyone who is able to answer my query. Many of Geoff Eddy's PVs, on which I based some of my solutions, use the following code to make something happen every n ticks: 3A CB 85 LD A, (#85CB) pick up the minute counter E6 0F AND #0F and make things happen every 16 ticks C8 RET Z only As I understand, the operand of the AND (E6) instruction determines how many ticks something is supposed to happen. For example, #07 (7 in decimal) will correspond to "every 8 ticks", #0F (15 in decimal) will correspond to "every 16 ticks", #1F (31 in decimal) will correspond to "every 32 ticks" and so on. I followed the pattern and used this kind of code in my PVs. However - to be honest - I made a mistake and used: #C0 (192 in decimal) to make something happen "every 192 ticks" - while now, with the benefit of hindsight, I think it should have been #BF (191 in decimal); #E0 (224 in decimal) to make something happen "every 224 ticks" - while now, with the benefit of hindsight, I think it should have been #DF (223 in decimal). The results are fine, I am satisfied with my PVs and I am not going to modify them; it's just their description that I am now struggling with. So my questions are: using the above code, does #C0 make something happen "every 193 ticks" (as would seem logical) and does #E0 make something happen "every 225 ticks", or is it not true, because the code works (with these values in place) in a different way? Looking at the results of applying these values, it seems to me that they do *not* correspond to things happening "every 193 or every 225 ticks". In fact, there is quite a significant difference between how the PV in question works with the value of #BF and #C0, and it doesn't look at all like it's the question of something happening "every 192 ticks" or "every 193 ticks" (where the difference would be hardly noticeable, I think). So I *suspect* something else is in play, which has to do with the way the AND instruction works, which I don't understand. It may seem strange that I have created something and now have a problem describing how it works. However, it happens in the real world as well from time to time, doesn't it? (e.g. scientists creating a new material with amazing properties through experiments, and then trying to explain *why* it has these properties by looking at its molecular structure, etc. - at least that's what I imagine might happen :) ). Any help on this would be appreciated, in the sense of describing how: 3A CB 85 LD A, (#85CB) E6 C0 / E0 AND #C0 / AND #E0 C8 RET Z works will be appreciated before 10 May, when the Special Edition of "Willy's New Mansion" is due to be released (speak now or forever hold your peace! :) ).

Very interesting! :)

My comments in blue:

If it is, then so is setting the flying pig as Willy's sprite in "The Nightmare Room" in the original JSW, isn't it? And *if* the Jukebox routine is called 'Danny's Jukebox routine' (which is an honour to me, of course :blush:), it should be called (as of "Willy's New Mansion SE", when it's released) 'Danny's Jukebox routine perfected by Ian', or something like that, since Ian has noticed and suggested a very significant increase in its efficiency since the release of "The Nightmare Edition" (in the sense of using significantly fewer bytes while achieving the same effect) :) .

Ian, I believe the fact that Willy gets stuck in this particular place is related to the conveyor. If there was no conveyor there (or if it had a different direction), Willy wouldn't get stuck (he could always walk left).