Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve: speed up bulk room creation #7184

Open
wants to merge 11 commits into
base: development
Choose a base branch
from

Conversation

vadi2
Copy link
Member

@vadi2 vadi2 commented Mar 13, 2024

Brief overview of PR changes/additions

Speed up bulk room creation so people can make million-map rooms quickly:

Motivation for adding to Mudlet

https://discord.com/channels/283581582550237184/1215109133150199889/1217359192835358741

Other info (issues closed, discussion etc)

Somewhere along the line we forgot that https://wiki.mudlet.org/w/Manual:Mapper_Functions#updateMap needs to be called from scripts to update the map for this very reason - performance

@add-deployment-links
Copy link

add-deployment-links bot commented Mar 13, 2024

Hey there! Thanks for helping Mudlet improve. 🌟

Test versions

You can directly test the changes here:

No need to install anything - just unzip and run.
Let us know if it works well, and if it doesn't, please give details.

@vadi2 vadi2 changed the title Disable map updates on room area placement Improve: speed up bulk room creation Mar 16, 2024
@vadi2 vadi2 marked this pull request as ready for review March 29, 2024 13:29
@vadi2 vadi2 requested review from a team as code owners March 29, 2024 13:29
@vadi2 vadi2 added the needs documentation This pull request changes things the players would use/see and thus needs an update in the manual label May 28, 2024
if (lua_gettop(L) >= 2) {
areaID = getVerifiedInt(L, __func__, 2, "areaID");
}
// defer area calculations as all new rooms are initialised at 0,0,0 anyway
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 If we are extending room creation to put them in the wanted area directly why not go the whole hog and accept the coordinates to position them in the area as well...? Fair enough - I am not sure what the Lua API would look like for that!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding room coordinates isn't slow, so leaving it be for now

while (lua_next(L, 1) != 0) {
const int id = getVerifiedInt(L, __func__, -1, "roomID");
if (!host.mpMap->mpRoomDB->getRoomIDList().contains(id)) {
return warnArgumentValue(L, __func__, csmInvalidRoomID.arg(id));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it not be reasonable to identify the index (starting at 1 obviously - it is a Lua table) of the invalid room id that prompted the error - or do you consider it sufficient to report only the bogus value?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think just thr wrong value is enough

if (!host.mpMap->mpRoomDB->getRoomIDList().contains(id)) {
return warnArgumentValue(L, __func__, csmInvalidRoomID.arg(id));
}
roomIds.append(id);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Beware - there is nothing to stop the user providing the same room Id more than once - and if they do - and one of them is the last one provided - then the check later on to only do the area extremes recalculation on the last room will be triggered multiple times. OTOH this should not be harmful but could be avoided with a std::set rather than a std::vector which prohibits duplicates (and is sorted as a side effect)...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll check this

@@ -277,18 +277,18 @@ inline QDebug operator<<(QDebug debug, const TRoom* room)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<aside>How come you never put in code to report the custom exit line colour, whether it ends in an arrow-head and the line style?</aside>

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to be an omission

}
if (id <= 0) {
QString error = qsl("addRoom: illegal room id=%1. roomID must be > 0").arg(id);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<aside>🚨 I18n - this text is presented to the error console in the editor and other such texts displayed in this way are put through the translation system (twice in other cases - which is also suspect - the second one prepends "[MAP ERROR:] with no space after it in TMap::logError(...)!)</aside>

QString error = qsl("addRoom: illegal room id=%1. roomID must be > 0").arg(id);
mpMap->logError(error);
}
return false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We return false if the room is not created - but we do not report here if the room already exists AND that is why this method failed. Perhaps we review the usage of this method and determine whether the reporting of failures need to be unified/be made more rational?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs documentation This pull request changes things the players would use/see and thus needs an update in the manual
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants