Bug - Fixed Auto-create failing with r19351
- Thread starter Magus_Prime
- Start date
Sending that file through the old version and the new version with "test fight" with debugging on, I see just a handful of differences in how HTML cleaner cleaned things. In particular, the old version stuck in a could of "<p>" tags which the new one did not.
I have not compared to the raw source, yet.
Won't have time until tomorrow.
Here is an example:
old parse tree:
new parse tree
I have not compared to the raw source, yet.
Won't have time until tomorrow.
Here is an example:
old parse tree:
Code:
<table>
<tbody>
<tr>
<td>
<p>
<!--familiarmessage-->
<center>
<table>
<tbody>
<tr>
<td align="center" valign="center">
<img src="https://s3.amazonaws.com/images.kingdomofloathing.com/itemimages/familiar19.gif" width="30" height="30">
<td valign="center">
Pokey dribbles some juice into your ear, healing you somewhat. I know that doesn't make any sense but give me a freaking break, it is the
Code:
<table>
<tbody>
<tr>
<td>
<!--familiarmessage-->
<center>
<table>
<tbody>
<tr>
<td align="center" valign="center">
<img src="https://s3.amazonaws.com/images.kingdomofloathing.com/itemimages/familiar19.gif" width="30" height="30">
<td valign="center">
Pokey dribbles some juice into your ear, healing you somewhat. I know that doesn't make any sense but give me a freaking break, it is theHere is the difference between how the old and new HTMLCleaner handle "p" tags.
<p> tags do not need a </p> tag to close them. The close tag is implied when the HTML parser encounters the next "block level" tag. According to w3schools, the following are "block level" tags in HTML5:
The old HTMLCleaner treated <center> as a "block level" element and thus automatically closed a <p>. Perhaps that was correct pre-HTML 5.
The new HTMLCleaner nests <center> within <p>, which is correct for HTML 5.
The issue from your file is that a <p> node with a VYKEA companion messages was followed by a <center> with additional actions, which we ignored.
Revision 19363 fixes that.
There may be other instances of this; there are a lot of things which, if encountered in a <p>, will return after handling them.
Every one of those "return" statements will ignore subsequent child nodes within the <p> node.
Notice the Evilometer, which I fixed earlier, because the Evilometer text is within its own <p> node within a <center> within a <p> (which had no text of its own) and we now process the text in the nested <p> nodes individually.
The issue will still occur if one of the above "return" cases has the text it is looking for at top level within a <p> node with additional children. That was the case for VYKEA companions, but not the Evilometer.
If there are additional issues, get a DEBUG log, and it should be easy enough to fix, now that we understand the issue...
<p> tags do not need a </p> tag to close them. The close tag is implied when the HTML parser encounters the next "block level" tag. According to w3schools, the following are "block level" tags in HTML5:
Code:
<address>
<article>
<aside>
<blockquote>
<canvas>
<dd>
<div>
<dl>
<dt>
<fieldset>
<figcaption>
<figure>
<footer>
<form>
<h1>-<h6>
<header>
<hr>
<li>
<main>
<nav>
<noscript>
<ol>
<p>
<pre>
<section>
<table>
<tfoot>
<ul>
<video>The new HTMLCleaner nests <center> within <p>, which is correct for HTML 5.
The issue from your file is that a <p> node with a VYKEA companion messages was followed by a <center> with additional actions, which we ignored.
Revision 19363 fixes that.
There may be other instances of this; there are a lot of things which, if encountered in a <p>, will return after handling them.
Code:
if ( FightRequest.handleEldritchHorror( node, status ) )
{
return;
}
if ( FightRequest.handleKisses( node, status ) )
{
return;
}
if ( FightRequest.handleCrimboPresent( node, status ) )
{
return;
}
if ( FightRequest.handleChakra( node, status ) )
{
return;
}
String str = FightRequest.getContentNodeText( node );
// Camera flashes
// A monster caught on the film
// Back to yearbook club.
if ( FightRequest.haiku && str.contains( "Back to yearbook club" ) )
{
FightRequest.handleYearbookCamera( status );
return;
}
if ( FightRequest.handleFuzzyDice( str, status ) )
{
return;
}
if ( FightRequest.processFumble( str, status ) )
{
return;
}
if ( FightRequest.handleEvilometer( str, status ) )
{
return;
}
if ( FightRequest.handleKeyotron( str, status ) )
{
return;
}
if ( FightRequest.handleSeahorse( str, status ) )
{
return;
}
if ( FightRequest.handleMayoWasp( str, status ) )
{
return;
}
if ( FightRequest.handleSpelunky( str, status ) )
{
return;
}
if ( FightRequest.handleFamiliarInteraction( str, status ) )
{
return;
}
FightRequest.handleVillainLairRadio( node, status );
boolean VYKEAaction = status.VYKEACompanion != null && str.contains( status.VYKEACompanion );
if ( VYKEAaction && status.logFamiliar )
{
// VYKEA companion action
FightRequest.logText( str, status );
}
boolean ghostAction = status.ghost != null && str.contains( status.ghost );
if ( ghostAction && status.logFamiliar )
{
// Pastamancer ghost action
FightRequest.logText( str, status );
}
int damage = FightRequest.parseNormalDamage( str );
if ( damage != 0 )
{
FightRequest.logMonsterAttribute( status, damage, HEALTH );
MonsterStatusTracker.damageMonster( damage );
FightRequest.processComments( node, status );
return;
}Notice the Evilometer, which I fixed earlier, because the Evilometer text is within its own <p> node within a <center> within a <p> (which had no text of its own) and we now process the text in the nested <p> nodes individually.
The issue will still occur if one of the above "return" cases has the text it is looking for at top level within a <p> node with additional children. That was the case for VYKEA companions, but not the Evilometer.
If there are additional issues, get a DEBUG log, and it should be easy enough to fix, now that we understand the issue...