 |
This is due to a number of improvements I made in the shop code. (My first bug fix. 0002376) The delay comes from needing to find out the maximum # of arrows you're allowed to have. This TODO note from 0002376 explains what's happening: "1. Due to max_ammo processing, there's a delay (<10s) while waiting for the Shop screen to display. The delay is due to calls to FindEntityDefDict()." The first time this routine is called, there's a 3.5s delay, which makes no sense, unless there's a ton of initialization work being done to build the dictionary of entity definitions. Subsequent calls take decreasing amounts of time until they return immediately. My guess is this delay was already there in 1.02, when the first calls to this routine were done in the map load code (when the title graphic is being shown with the loading bars), where it was lost in the very long load time. Now it's just earlier and more exposed. greebo mentioned looking at it when I first submitted the code for review, but I'm sure he's been busy elsewhere. |
|
|
Two ways to approach this: 1) IIRC, I'm looking for the max number of arrows one can have. If I just hardcode that to 30, it would be a way to avoid the delay. It would be a hack, but it would suffice. 2) See if I can spin off a separate thread parallel to the briefing to query FindEntityDefDict() for each arrow type. That would get the long initial delays out of the way while the player's busy with briefing/difficulty/objectives. Either save the results for use in the shop or let the shop redo the calls when response time is small. |
|
|
Implemented option 1 with hard-coded limit of 50. |
- Anonymous
