New Content - Implemented Chateau Mantegna - January 2015 IotM

ChateauRequest.java seems to use the spelling "cheateau" for the rest URLs - cheateau_rest, cheateau_restlabelfree, cheateau_restlabel
Looking at it in game, it seems to be "chateau"? Some example URLs I've seen:

Code: 
place.php?whichplace=chateau&action=chateau_restlabelfree
place.php?whichplace=chateau&action=chateau_restbox

I think this prevents timesRested from being incremented when resting. The test is currently:
Code: 
if ( action.startsWith( "cheateau_rest" ) )

Maybe KOL's URLs were initially misspelled?
 
They were misspelled when I looked this afternoon. Thanks for alerting us to the fix. :)

Edit: I just checked and I see: place.php?whichplace=chateau&action=cheateau_restlabel

I think I'll allow both spellings.
 
Last edited:
Revision works, thank you.

When free rests are available, the URLs I see are:
Code: 
place.php?whichplace=chateau&action=chateau_restlabelfree
place.php?whichplace=chateau&action=chateau_restbox

When resting costs a turn:
Code: 
place.php?whichplace=chateau&action=cheateau_restlabel
place.php?whichplace=chateau&action=chateau_restbox

It looks like the misspelled "cheateau_restlabel" appears when no free rests are available.
 
So, the restbox link rests - whether or not it is free - the restlabelfree link is from the free rest image, and the restlabel link is from the non-free rest image.

That means that if you submit restbox, we cannot tell if it is free. I guess I will log all rests with the current run number.

Revision 15189 does that.
 
Veracity said:
- Using a free rest from the Chateau in preference to using one from your campground dwelling, either always, or preference-controlled.
Click to expand...
lostcalpolydude said:
If someone is trying to rest for a buff from their campground housing (hobo power, some +item buff I think), then this will be the wrong place to rest. I have no idea how that should be handled. I won't be upset if chateau is always used.
Click to expand...
The way lost puts it, I think a preference would be better. Either campground, chateau, or ask before resting so they can make the call at the time.
 
Revision 15190 adds a preference: restUsingChateau. If it is true (the default, although it is configurable in General Options), the "rest" and "rest free" commands will go to the Chateau rather than the campground, and the "free disco rest" checkboxes in the HP and MP restores lists will do the same. I also added a "Rest in the Chateau" menu item to the Travel menu, just above the "Rest in House" menu item.

If they add a third place to rest, we'll revisit that.

No way do I want to add a user prompt.
 
Revision 15191 adds _chateauDeskHarvested and fixes a typo in updating your nightstand item when it is the moxie thing.

That leaves the Daily Deed for the desk item and the Ascension reminder on the gash page.

I don't HAVE to be the one to do those. ;)
 
It's not formatted according to our standards, and it could use a "foreach"-style iteration over the workshed items, but I have installed it (with those things corrected) and will see how it looks on Wednesday.
 
Out of curiosity, how does it diverge from standards, and is there somewhere I could see those defined? I know all too well the importance of a uniform coding standard, and would like to get it right in the future.
 
Here's my adjusted function:

Code: 
	private static final void switchChateau( StringBuffer buffer )
	{
		if ( !Preferences.getBoolean( "chateauAvailable" ) )
		{
			return;
		}

		StringBuilder chateauBuffer = new StringBuilder();

		chateauBuffer.append( "<br>Chateau: " );

		for ( AdventureResult item : KoLConstants.chateau )
		{
			chateauBuffer.append( "<nobr><a href=\"shop.php?whichshop=chateau\" title=\"Change from giving " );
			switch ( item.getItemId() )
			{
			case ItemPool.CHATEAU_MUSCLE:
				chateauBuffer.append( "muscle stats when resting" );
				break;
			case ItemPool.CHATEAU_MYST:
				chateauBuffer.append( "mysticality stats when resting" );
				break;
			case ItemPool.CHATEAU_MOXIE:
				chateauBuffer.append( "moxie stats when resting" );
				break;
			case ItemPool.CHATEAU_FAN:
				chateauBuffer.append( "+5 free rests per day" );
				break;
			case ItemPool.CHATEAU_CHANDELIER:
				chateauBuffer.append( "+3 PvP fights at rollover" );
				break;
			case ItemPool.CHATEAU_SKYLIGHT:
				chateauBuffer.append( "+3 adventures at rollover" );
				break;
			case ItemPool.CHATEAU_BANK:
				chateauBuffer.append( "1,000 meat per day" );
				break;
			case ItemPool.CHATEAU_JUICE_BAR:
				chateauBuffer.append( "3 random potions per day" );
				break;
			default:
				chateauBuffer.append( "unknown" );
				break;
			}
			chateauBuffer.append( "\">" );
			chateauBuffer.append( item.getName() );
			chateauBuffer.append( "</a></nobr> " );
		}

		String monster = Preferences.getString( "chateauMonster" );
		chateauBuffer.append( "<br>Chateau monster: " );
		chateauBuffer.append( "<nobr><a href=\"place.php?whichplace=chateau\" title=\"Check painted monster\">" );
		if ( monster.equals( "" ) )
		{
			chateauBuffer.append( "(none currently)" );
		}
		else
		{
			chateauBuffer.append( monster );
			chateauBuffer.append( " (currently)" );
		}
		chateauBuffer.append( "</a></nobr> " );

		buffer.append( chateauBuffer );
	}
The main "divergence" was your double indentation within the switch statement; if you think of a switch as a variation of an if/elseif chain, you'll see that the code in each block is actually only one level "deeper" than the switch itself.

The rest of what I did was to not allocate memory unless it was going to actually be used, and to use the "foreach" iteration, as I mentioned.
 
Fair enough, I hadn't caught the bit about the switch indentation, because I usually have my editor at 2 character shift width, so it's not so visible. But I do see (with a bit of grepping) that nearly all other switch statements are like that. I didn't know about the iterator thing, as Java is not my primary language, but it does look a lot neater. I basically copied the for loop from get_inventory in textui/RuntimeLibrary.java. Maybe there's a reason it's like that in that situation, I couldn't tell without digging. The order of early return / allocation was copied from switchFolderHolder above. Thought maybe there was a standard about having all declarations at the top, and didn't think further of it. Anyway, thanks for the pointers.

Edit: Actually meant get_chateau, but it follows the same basic template as get_inventory and some other functions, which is probably why it also does it the "old" way.
 
Last edited:
PeKaJe said:
I didn't know about the iterator thing, as Java is not my primary language, but it does look a lot neater. I basically copied the for loop from get_inventory in textui/RuntimeLibrary.java. Maybe there's a reason it's like that in that situation, I couldn't tell without digging.
Click to expand...

I'm pretty sure that wasn't an option in Java 4, so older code isn't done that way, and that stuff sporadically gets updated when someone happens to look at it for an unrelated purpose.
 
Revision 15249 adds your Chateau reminder to the Astral Gash. I initially thought I'd prefer dropdowns for changing the furniture, but upon further thought, since that costs Meat, I prefer your links to the shop. Thanks.

I believe that all that remains here is a daily deed to go to place.php?whichplace=chateau&action=chateau_desk if _chateauDeskHarvested is false?
 
I went ahead and gave the Daily Deed a go. I'm not entirely sure what the version handling thing is about, but when I started mafia for the first time, the deed was added to my panel as I would have expected. The patch also has Valhalla reminder handling for the stationary, which was implemented since the previous patch.
 

Attachments

I've never done a Daily Deed, myself, so I can't explain the version thing, either.
Your patch worked fine, so I submitted it in revision 15274.
I think that finished this New Content.
Thanks!
 
The version stuff auto-adds deeds that are newer than the last version you previously ran, so that people will see new deeds without having to add them but can still remove them if they aren't wanted.
 
fighting the Chateau Monster implemented

Hi, I might have overlooked something but I wasn't actually able to script the Chateau Monster fight.
I tried chateau_painting, chateauMonster and chateau_monster but just get an error (Unable to invoke ...).
When using the URL ( cli_execute("place.php?whichplace=chateau&action=chateau_painting"); ),
the fight is started but not completed (no ccs is triggered and the next command fails as the fight is still going on).
 
YOu can do it in two commands with...

Code: 
cli_execute("place.php?whichplace=chateau&action=chateau_painting")
run_combat();
 
You must log in or register to reply here.
Back
Top