View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0005153 | WHDLoad | [All Projects] General | public | 2021-04-23 14:18 | 2022-01-15 23:14 | ||||||||
Reporter | Paul Head | ||||||||||||
Assigned To | Wepl | Project Info | HD-Installer for OS-Killer http://whdload.de/ | ||||||||||
Priority | low | Severity | feature | Reproducibility | N/A | ||||||||
Status | closed | Resolution | fixed | ||||||||||
Product Version | 18.6 | ||||||||||||
Target Version | 18.7 | Fixed in Version | 18.7 | ||||||||||
Summary | 0005153: PreloadSize tooltype issue | ||||||||||||
Description | If loading from Workbench and I have bracketed the PreloadSize tooltype, a new PreloadSize tooltype will always appear in the game info file after running the game. This doesn't seem the correct behaviour, as I deliberately wanted to inhibit the displaying of the Progress Bar for this game and so I would expect that it should not add yet another PreloadSize tooltype which in turn will display the Progress Bar upon next run. I believe WHDLoad should detect the bracketed "(PreloadSize)" tooltype and not add yet another. I also want to suggest a "NoPreloadSize" option for slaves run from the CLI and also globally in the WHDLoad.prefs file. This could stop all Progress Bars from displaying, and also stop a new PreloadSize tooltype being created when a game is run from Workbench. Of course, a NoPreloadSize actually in a game info tooltype should also inhibit the creation of the PreloadSize tooltype. I have a question too, for which I can't seem to find an answer. How come some slaves show a black colour portion at the beginning of the Progress Bar instead of the whole Bar being blue? | ||||||||||||
Additional Information | Thank you! | ||||||||||||
Tags | No tags attached. | ||||||||||||
Machine | A1200 | ||||||||||||
CPU | 68020 | ||||||||||||
CPUSpeed | 14 | ||||||||||||
ChipSet | AGA | ||||||||||||
GFXCard | None | ||||||||||||
ChipMem | 2 MB | ||||||||||||
FastMem | 8 MB | ||||||||||||
Workbench | OS 3.0 | ||||||||||||
KickROM | 39 - Kick 3.0 | ||||||||||||
KickSoft | None | ||||||||||||
WHDLoad | 18.6 | ||||||||||||
Attached Files |
|
Notes | |
Pascal De Maeseneire (reporter) 2021-04-23 17:15 |
@Paul Head Hi, About Your Preload size... Just Put Preload under () like this (PRELOAD) or just remove preload ToolType ...but it's not good for majority of games... For black colour portion I don't Know.... probably about Cache or memory available (Fastram maybe ??) |
Paul Head (reporter) 2021-04-23 22:30 |
Hello Pascal, I'm aware of the (PRELOAD), but then I have no preload :-) I have no idea what the black portion means, but I am certainly intrigued by it, and maybe you are too! Take care my friend. |
Wepl (manager) 2021-04-24 22:46 Last edited: 2021-05-16 16:07 |
Currently there is no way to suppress writing the PreloadSize if started from Workbench. Please let me know: Why do you want the progress bar? If the game is started from the CLI there is no progress bar as long as option PreloadSize is not specified. Nothing needs to be changes here AFAIK. The progress bar is black for the Examine-Meta-Data-Scan (only Slaves which have that flag set) and blue for file preload. I will extend the docs for that. I could change the behavior so that if PreloadSize is equal -1 there will be no progress bar and no update of the icon. Would that be ok? |
Paul Head (reporter) 2021-04-27 21:56 |
Do you mean why do I not want the progress bar? I actually like the progress bar, although I have to admit not being too fond of the black portion! I use with TinyLauncher mostly, and that runs all tooltypes and so I get the progress bar on games that have been started via Workbench in the past, but no bar on ones that haven't. I realise that I can delete the tooltype after a Workbench run has put in the PreloadSize tooltype, but I'm honestly thinking of others who might have some games with and some without and for consistency I thought it would be a good idea to have a global option. Perhaps I'd be better off contacting gibbs and getting him to put an option in of omitting the reading of the PreloadSize tooltype. The only other reason I can think of is for those pedantic users who might not want their icon files fragmenting across their hard disk. :) That last part you wrote, do you mean if there is a -1 then the bar would not display and also not save anything? And you mean this as in running from Shell? It's not important to me really, I thought I would point out what I thought was wrong and that an improvement could be made, but it doesn't matter. |
Paul Head (reporter) 2021-04-27 22:18 |
I do have another question actually relating to the Splash display and Progress Bar. Depending on the 4-colour palette chosen (this on a 4 colour screenmode), sometimes the Progress Bar is invisible (has the same colour as splash background) and also there is no dithering of the Splash window, and if the bar is visible in the window then again depending on the palette there might not be highlights to it etc. (looks pretty bad) - all depends on the palette of the screen for all three points. Is this palette changing by design? |
Wepl (manager) 2021-05-16 17:10 |
I have made the PreloadSize option global now. But local option will override this! If set to -1 no progress bar is displayed and the icon will not be updated. |
Retroplay (reporter) 2021-05-16 17:48 |
I get an "Error parsing global configuration file line 31 'PreloadSize=-1'" if enabled in prefs. WHDLoad 18.7.6269 |
Wepl (manager) 2021-05-16 23:14 |
Sorry, bad testing. Please try latest beta (build 6276). It should work now. |
Retroplay (reporter) 2021-05-17 00:58 |
Yes, it works. |
Paul Head (reporter) 2021-05-17 12:57 |
@Wepl Thanks for working on this. In it's current implementation as per new 18.7 [6276] the PreloadSize=-1 stops all info files being written per se, including the configuration stuff like ButtonWait tick box etc. Is it simply impossible then to rename it from 'PreloadSize=-1' to just 'NoWriteInfo' in the global config file? The latter describes it much more accurately, and the new docs doesn't quite explain this clear enough (to avoid confusion due to the PreloadSize name referring to not only the Preload size but suppressing of config stuff in tickboxes). My initial idea was just to 'tackle' the Preload bar, I didn't intend for it to cause any other trouble or affect anything else, although I do really like your new 'NoWriteInfo' option instead, it just currently has the wrong name! The new $RC 5 is working brilliantly, so thanks for fixing that, it is much appreciated. |
Paul Head (reporter) 2021-05-24 13:15 |
You know, I've actually warmed to the PreloadSize=-1 thing now. It's more of a specialist setting and so it needs a bit of ambiguity and mystery surrounding it! ;-) |
Wepl (manager) 2021-05-24 23:19 |
I think if PreloadSize should not be updated then there should be no write to the icon at all. I cannot imagine an other use case. Hmm, I didn't want to introduce another new option for that. I will think about... |
Paul Head (reporter) 2021-05-26 16:01 |
An observation after I have looked at this again 18.7 [6276]: If PreloadSize=-1 in the WHDLoad.prefs AND there is no PreloadSize tooltype in the icon, then loading games via clicking in game drawers and double clicking game icons will not save the configuration settings...like a trainer for example, which someone might just want to try once whenever they fancy it and not always having to notice whether it's been selected or not upon the next run. And of course, no new PreloadSize is written in the icon. This is a useful use case in my opinion (but has nothing to do with the loading bar specifically, for that isn't important here as one will never pop up anwyay...This is why I suggested the new name for the option.) However, if there is a PreloadSize tooltype already in the icon, then the configuration options in the splash (like a trainer for example or ButtonWait) gets saved anyway regardless of the PreloadSize=-1 in the WHDLoad.prefs file. If this is how it's supposed to be then it needs mentioning in the docs as it's slightly confusing. Or, do away with it all and forget this mantis report!!! :-P |
Wepl (manager) 2021-05-26 17:36 |
This behavior is already documented: http://whdload.de/docs/en/opt.html#PreloadSize |
Paul Head (reporter) 2021-06-05 20:25 |
Quite right! Thought I'd mention here too that there is an English spelling mistake I came across in the docs under option NoFlushMem. It's 'resources' not 'ressources'. I wonder if it's spelt wrong else where too? |
Wepl (manager) 2021-06-14 00:32 |
Thanks for spelling fixes, applied. I also changed the options as suggested. Behavior of PreloadSize has been reverted and new option NoWriteInfo/S has been added. New beta is on the webpage for download. Thanks for your support :). |
Paul Head (reporter) 2021-06-14 12:21 |
This is brilliant! I've given it a good testing and it appears to work flawlessly and even better than I imagined. It's a lovely feature being able to hold the setting by putting NoWriteInfo in the tooltypes so that the user can cheat when they fancy it but not next time, or play with other options! Good stuff, and also really glad to see the use of tabs in the prefs file. I noticed another spelling mistake - I suppose it depends on whether you want to use English English or American English. "5 - Preload has been canceled via the Esc key in the splash window" Cancelled is the word if English English. Also, in the latest history note: "a new option NoWriteInfo/N has been added as local and global option, if set WHDLoad will will not update/write any .info files (0005153)" Will will! Honestly, I'm not looking for errors but if I happen to read a section with a mistake I'll let you know. Thanks for this latest update! |
Wepl (manager) 2021-06-15 23:01 |
Thanks for the additional spelling check :) first I leave (Am.) second fixed |
Issue History | |||
Date Modified | Username | Field | Change |
---|---|---|---|
2021-04-23 14:18 | Paul Head | New Issue | |
2021-04-23 17:15 | Pascal De Maeseneire | Note Added: 0010085 | |
2021-04-23 22:30 | Paul Head | Note Added: 0010086 | |
2021-04-24 22:31 | Wepl | Assigned To | => Wepl |
2021-04-24 22:31 | Wepl | Status | new => assigned |
2021-04-24 22:46 | Wepl | Note Added: 0010093 | |
2021-04-27 21:56 | Paul Head | Note Added: 0010124 | |
2021-04-27 22:18 | Paul Head | Note Added: 0010125 | |
2021-05-16 16:07 | Wepl | Note Edited: 0010093 | View Revisions |
2021-05-16 17:10 | Wepl | Note Added: 0010275 | |
2021-05-16 17:10 | Wepl | Status | assigned => resolved |
2021-05-16 17:10 | Wepl | Resolution | open => fixed |
2021-05-16 17:11 | Wepl | Fixed in Version | => 18.7beta |
2021-05-16 17:11 | Wepl | Target Version | => 18.7 |
2021-05-16 17:48 | Retroplay | Note Added: 0010277 | |
2021-05-16 23:14 | Wepl | Note Added: 0010280 | |
2021-05-17 00:58 | Retroplay | Note Added: 0010281 | |
2021-05-17 12:57 | Paul Head | Note Added: 0010289 | |
2021-05-24 13:15 | Paul Head | Note Added: 0010340 | |
2021-05-24 23:19 | Wepl | Note Added: 0010343 | |
2021-05-26 16:01 | Paul Head | Note Added: 0010366 | |
2021-05-26 17:36 | Wepl | Note Added: 0010367 | |
2021-06-05 20:25 | Paul Head | Note Added: 0010392 | |
2021-06-14 00:32 | Wepl | Note Added: 0010408 | |
2021-06-14 12:21 | Paul Head | Note Added: 0010409 | |
2021-06-15 23:01 | Wepl | Note Added: 0010411 | |
2022-01-15 23:14 | Wepl | Fixed in Version | 18.7beta => 18.7 |
2022-01-15 23:14 | Wepl | Status | resolved => closed |