SAD-creator is in process as a base feature...
Sad functrionality is already included... any post 8. base version includes it

KTD will at best only offer older releases, (and I used to test KTD. It was not bad. Seeding had benefits, but it would fail on new hardware that had not been in DriverPacks or not been put in inf/path by the exception rules during setup.)

reverse logic.
A generic hwid is seeded. (and PnP WILL take a generic from a driver with a close match even if it does not list any super generic)
We should advise to not ever use KTD. Run SAD cmd instead.

make it easy to find SAD, give it a pleasing name
StandAloneDriver
UPDATE
Universal Professional Driver App Team effort.
(joke)

FLASH
Fast Live approved system heal

DoPUP
Do drive pack upgrade

It was not on lmy mind that a SAD disk would make KTD obsolite... but in thinking about it, you're correct

Why keep old drivers around when we can implement the newest ones at any time....

We probably discussed KTD and DPinst.
SAD and warmsnow can take the latest DriverPacks releases and do a proper post setup minisetup.
You fire up SAD's dp.cmd (this ought to be more in the limelight) or warmsnow's and get a minisetup with the latest builds you put in the disc, AND SAD uses the exceptions..

fwiw, the super short M1 I made for myself moons ago supports all but the latest chipsets and setup is just as quick..

this gives it a higher value (newer) than the original pack when we run DriverPacks BASE and it would be used for slipstreaming.

this might be a nice little add-on i could code
- i really see it as a stand alone app - similar to dpinst / SAD disk

don't look for this to show up right away

Helmi wrote:

look up INFs for matching HWIDs (don't we have such a tool already, BTW?)

I think this is what WsnoW's Drivers Pack Unpacker & Installer does (http://forum.driverpacks.net/viewtopic.php?id=2403).

Nope, that may be able to do that but I was talking about a Team-only programme (so you may not know it, was more a hindsight to Jeff ).

Still, if this tool can help with the idea, why not!

look up INFs for matching HWIDs (don't we have such a tool already, BTW?)

I think this is what WsnoW's Drivers Pack Unpacker & Installer does (http://forum.driverpacks.net/viewtopic.php?id=2403).

You're not the only one with this problem

perhaps someone will also find this appealing and write a "Pack Pruner" application
this could easily be a stand alone app that lists folders with checkboxes and a description...
this app could be run prior to DriverPacks BASE for customizing the packs for a specific set of machines (or one).

Ah yes, it could work as follows:

First, you run HWID on all machines that you want drivers from included in the pruned packs.
Then, this stand-aslone app would use these different HWID files as a reference for which files to be kept from the packs.
It would then upack all of them (that will take some space, around 2GB I figure), look up INFs for matching HWIDs (don't we have such a tool already, BTW?), move the folders and sub-folders containing those INFs to a new DIR, repack that as a 3rd party DriverPack and provide it for BASE for slipstreaming.

IDK how to preserve Finisher compatibility this way, but maybe you could do without (3rd party DriverPack ususally do not provide support for the Finisher anyway so you wouldn't have it if you made it yourself, either, unless you were up for some extra work).

Problem's just, I wouldn't know how to code that idea into a binary

Helmi made the best point so far, we are of the mindset of every machine supported every time.

perhaps someone will also find this appealing and write a "Pack Pruner" application
this could easily be a stand alone app that lists folders with checkboxes and a description...
this app could be run prior to DriverPacks BASE for customizing the packs for a specific set of machines (or one).

Thanks for contributing - we never know where ideas are going to lead us!

I'd just noticed copying the driver packs took some time and thought: less copying => less time and I got inspired by (or carried away with) jaws1975's [Add-on] Select desired DriverPacks during M2 install or after install.

In this case, you might be interested in jaws1975's faster version of un7zip.exe.

Might save some time for you, best to see for yourself.

Also, if you use all of the 3rd party DriverPack, you may want to do away with some that you really don't need.
The printer packs aeach are very huge and take the greatest share of copying/extracting time on my systems it seems.
If you do not need them (they only support certain printers anyway, are no use for network printers and require all devices to be connected and switched on during installation) or value speed more than complete driver support, removing them from the 3rd party DriverPack sub-folder is a great idea.

You could always supply peripheral device drivers through a driver's only disc that you execute some point after setup - this is already possible with what BASE supplies so you wouldn't have to seek long for such a solution (please do use search on this forum, however ).

IMHO there's no/little advantage in modifying the pack(s) after extraction; it wouldn't save space or time. Helmi mentioned the use of a database. Perhaps this could replace the listing of 'Supported Devices' from DriverPacks.net > Driver Packs. Adding or deleting drivers (or folders) from there seems easy to me. Selecting for sure is, however a tool would be needed to create the ini file, based on the selected drivers (or folders). I've no idea how difficult that would be.

Nevertheless, I'm happy the way DP is working now. Keep up the good work

from the base side of things this would be cumbersome as the folder names and supported devices change...
this could be addressed - medium high difficulty
  base is blind to the contents of the packs - so we would need to pass pack folder device info to the base program and generate a HUGE list with checkboxes or whatever. and would require extracting and repacking the DriverPacks

most people use M2 and as such the packs are not extracted until the WinPE stage of setup...
this presents two options;
  modify the pack(s) in advance - extract, prune, repack and possibly have to modify the packs INI too...
  this might be scripted however we refer to above... medium high difficulty and very time consuming
  for each new pack that is modded.

  Modify the packs from presetup.cmd after extraction - a small script that deletes a list of folder names.
  this may also require the pack ini's to be edited (maybe not...) this is probably the easyest choice.
  the down side is the full packs are extracted and then pruned so there are some wasted resources. 

It is still early and i havent had a full cup of coffee yet... perhaps i have missed something

it seems to me the easy way to do this is for you to create a script that will be called from presetup
this script will delete a "list" of \D\x\x  folders from the target machine.

this script will need to be manually modified each time the team changes folder names. IE we would need a way to find the folder that contained the 3dfx driver folder to prune it. this would either take codeing and then adding additional INI entries or create new files that serve as an index for each pack. obviously this would not be backward compatable. this also has the down side of additional work for the DriverPacks team...

lets put this idea down as "under consideration, pending feedback"

I endorse your policy. I maintain 8 different systems and DP as it is now certainly is a better option than adding specific drivers for each system. BASE offers a selection possibility (location below D\). Drivers for as much HW as possible still are provided, yet it's a back step creating a Universal Installation Disc

I'd just like to make one additional back step (location below D\x). I don't request nor want a list of thousands of drivers. The listing of 'Supported Devices' from DriverPacks.net > Driver Packs would be great. I.E.: from Graphics B I just need I4, I7 and \Sa. I don't have/use 3dfx, Matrox, S3, Via, .. and it would be nice to skip those drivers to save space and time.

If my request is difficult or takes to much effort; no hard feelings if it will not be approved. Maybe it's a challenge to someone. This has happened before (I.E. software section, jaws1975 and WsnoW).

If you only want to include drivers for HW that's in your system, I'd recommend the opposite approach as stripping all the drivers you do not need will take considerably more efford than just including the ones you do need.
You could either use nLite to add specific drivers (just extract them and point in to the INF dir).
Or, you could create your own custom pack containing just the drivers you needed.
Of course, you'd have to keep those up-to-date yourself, then.

Utilities such as "Driver Genius" (not freeware, though checking for new drivers works even on trial) can help with that.
If you just want to create a pack of your current drivers, you can use Siginet's Driver Grabber. You can then pack them all in one archive for use with BASE.

As to a selection screen in BASE, I think this is quite a difficult act to achive.
It would need to list every single driver contained in the DriverPacks. Those would also need to be displayed in a manner that makes it easy to navigate (no use in having a loooong list of thousands of drivers in the BASE that totally messed up the GUI).
Also, you'd need a database file for these drivers that constantly gets updated with each release as some are added, others removed or renamed.
This would also mean that your proposed INI file becomes worthless after each update and you'd have to redo the selection each time.

I do not code BASE, but I'm sure this would be a major effort, all while the intended use is contrary to our main policy as described above.
May take a lot of work to convince Jeff to take on this task, IMO