Renault on 29/5/2013 at 15:35
Question for all the dromeders out there...
I've been toying with the idea of coming up with some type of updated DEDX type project, basically an attempt to give new (and old) authors a bigger selection of resources to use for their missions. One big part of this would probably be creating a new gamesys and a base mission to give authors a solid starting point.
My question is - is there any harm in creating a giant gamesys which includes 5-10x as much as the standard one? I know the DEDX gamesys caused some problems, but I don't know specifically what caused them. My initial thought was to create a gamesys that includes everything from COSAS Mission X and maybe King's Story and a few other large collections of objects and meshes. I would think if everything is categorized properly, it shouldn't be too hard to navigate and would give dromeders a ton more options. In addition to this, we could collate a bunch of large texture collections and make them available in the package as well. With NewDark's method of adding texture families, it would be as simple as unzipping the new collection into your dromed folder.
Thoughts on any of this? Obviously there's no point in going through what would be a ton of work if it's going to be counter-productive. Or maybe, is there a better way to do all of this? I'm completely open to ideas and suggestions.
PsymH on 29/5/2013 at 16:28
That would be really awesome. I hope there will be no technical difficulties. :thumb:
kdau on 29/5/2013 at 16:50
What about using dbmods/DMLs? That would let you offer a wide variety of new materials without incurring the enormous .GAM size. The archetypes could be grouped into small categories that authors could pick from. The dbmod_load command in DromEd applies a DML to the loaded gamesys, according to the documentation, so it should be relatively simple to incorporate the desired items.
My guess is that part of the problem with DEDX was maintaining quality control over such a large set of new objects when they were added simultaneously and dispersed across the stock hierarchy. With dbmods, you would always know exactly what changes and additions had been made, and could isolate issues to specific categories if needed.
zacharias on 29/5/2013 at 23:13
When i first used DEDX, there were a few framerate issues caused by some of the new Act/React things Rob had added (I forget exactly which ones, this was ages ago) but once these stims were removed I had no problem with framerates. (This'd be less of an issue with quad cores and such anyway, although I realize that's not really the point).
DEDX is pretty sweet i reckon so an update would be great..is there any chance you could get in touch with Rob Hicks and get him to send you the existing work he did on DEDX2? ;) :sly: (unlikely I know but I thought it's worth a shout)
Renault on 29/5/2013 at 23:55
Quote Posted by zacharias
is there any chance you could get in touch with Rob Hicks and get him to send you the existing work he did on DEDX2? ;) :sly: (unlikely I know but I thought it's worth a shout)
Already tried - all his methods of contact are out of date/not working, and he doesn't stop by here anymore. There were a few people from TTLG working on the project with him as well, but they don't have any of the resources he was working on. So unfortunately, looks like we'll be starting from scratch. :(
zacharias on 30/5/2013 at 01:08
Yep, fair enough. I guess I still think in this day and age there should be some way to track him down in real life (presuming he's still with us etc.) and one would think he'd be open to releasing all his hard work to the world in some form..
It is a tricky one though.
Going through some old threads it seems the gamesys was giving him trouble too with the amount of new stuff he had added, so maybe a more streamlined thing would be good in the long run anyway.
Anyway, sounds cool and all the best with it.
Yandros on 30/5/2013 at 04:48
Quote Posted by kdau
What about using dbmods/DMLs? That would let you offer a wide variety of new materials without incurring the enormous .GAM size. The archetypes could be grouped into small categories that authors could pick from. The dbmod_load command in DromEd applies a DML to the loaded gamesys, according to the documentation, so it should be relatively simple to incorporate the desired items.
My guess is that part of the problem with DEDX was maintaining quality control over such a large set of new objects when they were added simultaneously and dispersed across the stock hierarchy. With dbmods, you would always know exactly what changes and additions had been made, and could isolate issues to specific categories if needed.
This is IMO the best way to do a project like this these days.
Renault on 30/5/2013 at 16:57
I'm going to have to do some research on dbmods/dmls, I don't know much about them. Is the basic idea that all the gamesys properties are written to an external file, and then that file is loaded into the current gamesys on a temporary basis?
R Soul on 30/5/2013 at 17:12
Properties can be added/modified/removed to/from existing archetypes. You can do the same with links and sources & receptrons. The only limitation is that new archetypes cannot be created.
kdau on 30/5/2013 at 18:20
Quote Posted by R Soul
Properties can be added/modified/removed to/from existing archetypes. You can do the same with links and sources & receptrons. The only limitation is that new archetypes cannot be created.
I hadn't realized that new archetypes weren't an option. I suppose dbmods wouldn't be useful for this project, then. :erg:
Quote Posted by Brethren
I'm going to have to do some research on dbmods/dmls, I don't know much about them. Is the basic idea that all the gamesys properties are written to an external file, and then that file is loaded into the current gamesys on a temporary basis?
They are generally temporary, but they can be made permanent in DromEd with the correct setting and/or command.
