jDRP - 1.01 Vs 1.1 Alpha
OK i've been trying to get a grip on the addons for Doomsday and their current status. I was working on combining the jDRP 1.01 and 1.1 Alpha into one pack. I have a couple of questions:
1. The 1.1 alpha contains some resources from the jDUI Pack - infact, everything except the 'New Face Sprites' mugshots. Was this intentional? Should we move all the Hi-Res HUD graphics out of jDRP 1.1 and leave that to jDUI or is jDUI planned to be liquidated into the new W.I.P. 1.1 Alpha of jDRP?
2. Halfway through making and testing my 1.1 Alpha Repack (or 'Backpack'), which is essentially 1.01 as a base and all possible updates from 1.1 Alpha over-written the old ones and jDUI integrated/liquidated into it, I noticed that the new CacoShot depends on a model "Data\jDoom\Models\Projectiles\CacoFireball\caco_e.dmd". This doesn't exist in 1.1 Alpha, but 1.01 DOES have a Caco_E.md2. Am I to assume that, now, these two things (a) jDRP 1.1 Alpha is supposed to be loaded "on-top" and after jDRP 1.01 and (b) this is a typo or simple mistake in that the above md2 needs to be converted to a DMD...? Or is 1.01's CacoFireball completely replaced by 1.1's CacoShot (if so, is there a reason why the older 1.01 is still needed)
OK those are long questions. In conclusion, I realized that 1.1 Alpha is probably designed to be loaded after 1.01 jDRP and will therefore replace everything that's been updated in 1.1 but keep the non-updated resources in use. Is this efficient enough? Should I not bother with continuing to make my re-pack of 1.1 Alpha to be inclusive of 1.01?
1. The 1.1 alpha contains some resources from the jDUI Pack - infact, everything except the 'New Face Sprites' mugshots. Was this intentional? Should we move all the Hi-Res HUD graphics out of jDRP 1.1 and leave that to jDUI or is jDUI planned to be liquidated into the new W.I.P. 1.1 Alpha of jDRP?
2. Halfway through making and testing my 1.1 Alpha Repack (or 'Backpack'), which is essentially 1.01 as a base and all possible updates from 1.1 Alpha over-written the old ones and jDUI integrated/liquidated into it, I noticed that the new CacoShot depends on a model "Data\jDoom\Models\Projectiles\CacoFireball\caco_e.dmd". This doesn't exist in 1.1 Alpha, but 1.01 DOES have a Caco_E.md2. Am I to assume that, now, these two things (a) jDRP 1.1 Alpha is supposed to be loaded "on-top" and after jDRP 1.01 and (b) this is a typo or simple mistake in that the above md2 needs to be converted to a DMD...? Or is 1.01's CacoFireball completely replaced by 1.1's CacoShot (if so, is there a reason why the older 1.01 is still needed)
OK those are long questions. In conclusion, I realized that 1.1 Alpha is probably designed to be loaded after 1.01 jDRP and will therefore replace everything that's been updated in 1.1 but keep the non-updated resources in use. Is this efficient enough? Should I not bother with continuing to make my re-pack of 1.1 Alpha to be inclusive of 1.01?
Comments
music
models
textures
sound
environment
user interface
but also supply a one in all pack:
*****resource pack
I want to remove the j prefix from all of them and have the version scheme using dates yyyymmdd
e.g
dhtp-20090813.pk3
dmp-20090812.pk3
if you relesase two a bug fix the same day then add a -# after the date
eg
dhtp-20090813-1.pk3
I have started doing that wiht doom hires texture pack. but havn't touched jdrp and I need to fix the environment pack, but I keep forgeting what is wrong with the current pack
As far as the formats are concerned, while a .pk3 (i.e., a ".pack" in Doomsday 2) can contain other .pk3s/.packs, a .box can be used to conveniently separate the contained .pk3s/.packs into optional and required ones. So while a "sound pack" would be a .pack, the full all-in-one thing should be a .box ("resource box"?).
Yeah the j isn't needed... where did it originally come from (jDoom and jHexen) out of curiosity? J is for Jake I assume
Well is it OK if I go ahead and continue with what i'm doing then? Correction - is it helpful at all to continue doing it and submit results? Here's the current layout of the .box:
Syntax of [addonname]-[category]-[name]-[version] where [category] is the arrangement/folder in Snowberry and [version] is which jDRP it was taken from.
Considering the jDRP currently is made up of 90% models, I suppose the 'jDoom Resource Pack' or jDRP would effectively become the new 'Doomsday Model Pack' or DMP then. Or is DMP for Music? And Model Pack could be uhhh... D3P or something
OK well, I will strip the "gui" pk3's from the above box and that will keep only the models, they can stay in a seperate DUIP. But then the 'core' pk3 of jDRP contains additional particle effects to complement the models, aswell as the new 'Blood Drip' and 'BFG/Respawn Flash' effects so what category would they go into - a new effects pack called DFXP I suppose.
skyjake, i look forward to seeing the doco on the virtual file/directory mapping and addon format improvements comming with Deng2
EDIT: How would I arrange the above .box as it is to match a Deng2 standard you guys can agree on? Something like this perhaps... although a zip inside a zip inside another zip might not be the greatest thing...
Or do you mean provide every .pack into one "Doom Resource Pack.box"....? Something like this is especially good I just realized as it would allow us to mix-and-match different addon components with ease. Regardless, I hope you guys arn't too busy to decide on some standard soonish as I am also converting some older addons and MegaWads to this Doomsday format
P.S. [Off topic quick question] Skyjake, with Snowberry being phased out, I assume that means all our addon and config will be done from within Deng2 itself. If so, would that means one day in the future we'll get a feature to "preview" a certain addon from right in the menu? For a model or particle effect that would be very handy!
In light of that, I hope nobody ever tries to drop 'jHexen' for 'dengHexen' or something else like that... J is a cool letter (why would I think that?) and it's a great simple name that's unique, short and "sticks" in your mind <:-P
To correctly address and explore every point raised in this thread would take up far more time than I currently have available. Instead I'll try to infere my rebutals with an open question and a statement:
or lighting from a skybox
With lots of requires/depends in the Info metadata...? I know what you mean though, take this case - I load an addon for a new monster that has a 3d model and new sound effects, but I also want to use a PlayStation SoundFX Addon that conflicts with the new monsters' sounds. Snowberry can't specify a load order, and there's no real way for a user to see that there is duplicate/conflicted parts of two addons let alone dig through their Addon Tree to individually disable that one monster sound from the PSX Soundpack, to make sure the New Monster sounds are used only...
...Assuming that Snowberry feeds the list of addons to load to Doomsday alphabetically, and that Deng loads them in that order, mayhap it'd be a good idea to ensure that "official" addons (DRP) are loaded first always so that other extra addons from the user will replace the changes from the "official" addons... does that make sense? I'm sure you know what I'm talking about just by using the term loadorder. Well anyway there should be a more elegant way than adding three tilde's ~~~ to the beginning of every .pk3 file to make sure it loads first
Those were my original thoughts on this... I was thinking along the lines of the entire Doomsday Addon collection being in one DRP.box, then every single individual component only be in their own pk3 file - only because I don't know too much of Deng2's addon handling nor how the .pack differes from .pk3. Using categories such as "Sounds" and "Models" I think is better than, say, "Weapons" or "Monsters" (i.e. addon categories based on type not by literal content) as it would be more flexible for the user to mix-and-match.
Putting a pk3 inside another pk3, while handy for mass-distribution, would not be handy for minor updates. Consider if, for example, the "new Deng2 Resource Pack" was on the repository and one of you guys commits a new Barrel particle effect... an SVN checkout (or a Doomsday Update *hint*) would either have to download a ~100KB decorations-barrel-20090814.pk3, or a ~10MB models-decorations-20090814.pk3, or (gasp) a ~300MB drp-models-20090814.pack ... I don't really know what my point was there but as you've probably assumed most of my long-winded posts are more food for thought if not anything else!
I liked your idea of addons categories by type (model/sound/textures/etc) which could then be referred to as "model assets" or "sound assets". Although, couldn't all the shared/common resources of lighting and the particle engine go in "required", and for an addon named "Particle effects for CacoShot" (example) could go in the Effects category - but require "Model for CacoShot"?
Maybe it could be categorised by it's primary type and remain in one .pk3. Taking the above example - CacoShot has a Model and Particle effects, so it essentially crosses into two categories. Instead of splitting them up and messing with dependencies, put them both into a DRP-Models-Projectiles-CacoShot.pk3 because the particles are based on the model, designed to compliment it and as such are virtually useless without the model. Hence only standalone particle effects/lighting would go in the "Effect Assets" category, that'd involve things such as RespawnFX, Shaders and Screen Wipes which are global, and also "generic/universal" effects such as Bullet Effects (Richochet/Puffs/Smoke) that are shared across several weapons (or maybe not - just an example).
Look at the size of that... i'm such a criminal. skyjake, DaniJ and KuriKai - i'll leave you guys to ponder on this however long you wish. The least I could hope for is that this thread might've inspired some changes and improvements in Addon handling for Deng2.
Note that the plan is to continue using the old deng 1.9 resource management in Beta7, so the deng2 file system details and resource packaging won't be in focus for some time yet. The repository has Snowberry addon examples (which will rather closely resemble what deng2 will support.)
They can't be packaged based on their type. Any modularization should be done according to what makes sense to the end user: so we have an "enemies" pack, "UI" pack, "world surfaces" pack. Behind the scenes, these may actually use some of the same resources from a common pack (not visible to the end user).
I think it is a good requirement that whatever the components are in the "super" pack, they can also be used independently of each other. In this case the common resources could be packaged within the independently distributed packs, while in the "super" pack there is only one copy of the common resources present.
Also, I would like to say that I've been toying with the idea of a built-in runtime addon manager in deng2, which would be able to download resource packs from dengine.net (and sourceforge.net). If the repository would store the "super" pack as individual .pk3s and/or files, it would be possible to update one's copy of the resource pack automatically by just downloading the updated files and not the full pack.
.pack is the exact same thing as .pk3 (i.e., a ZIP archive).
Mind you, the deng2 addon handling hasn't been defined yet. It will resemble what Snowberry is doing, and what deng 1.9 does with resources, but the new internal file system provides some new possibilities that will affect how addons are handled. I expect this will be clarified once the work with Beta7 is done.
Having such a system would allow mods for Doomsday be more capable of choosing which resources are required. While memory usage can be easily made no concern though code, having an organised structure or "addon map" is an interesting idea in itself... plus it would mean shorter load times
If all addons were mapped accordingly, the .box could be in one pane, and all the assets of original Addons with a previously selected Custom Mod would be arranged all in the same categories for visually organised fine-tuning. Custom Mod files could be colour-coded for clearer indication and [way-future-rant]in Deng2 advanced options could show over-rides to use e.g. Hexen monsters in a Doom game[/way-future-rant]
[Digression] Forgive me if it's a little too "probing" of future direction that might be personal, but have you ever wondered about 'monsters' or 'enemies' being something... Creatures? Spawns? When you start to wonder about Mods or, jStrife for example...
Before snowberry was created, before I joined the project, I made packages of doomsday and the resources for debian.
When I did this I made several packages named along the lines of deng-jdrp-YYYYMMDD deng-jhrp-YYYYMMDD deng-jxrp-YYYYMMDD.
These packages were effectively meta-packages (similar to the .box thing skyjake has, but no optional bits) - I made the up by striping down the existing resource packs into smaller .pk3 files containing only the resources needed for each object. eg All level textures in one .pk3, all music in another .pk3, all resources for the imp object (models, projectiles etc etc) in another .pk3
This allowed me to to update any individual object with updated resources, and just push a new integrated resource pack out. As far as I'm aware - users either had the "whole" resource pack, or no resource pack - so I never saw any reason to add toggles to turn them on or off (which was one of the many reasons I didn't want to package snowberry)
Anyway - more food for thought.
@JonusC - This is my current mix of jdrp1.01 and 1.1
I do remember witnessing this big change.
That's all very good and well, but we shouldn't forget the importance of these optional subchoices. For example, many players love the 3D models and have them enabled, but wan't to keep sprites for just the monsters. Or just the HUD weapons.
Your codebox there Yagi makes complete sense but it doesn't give a lot of insight, I really have a problem with the older jDRP 1.01 structure where every single pk3 is just chucked into one folder, with concatenated filenames and absolutely no categorization whatsoever. It was very good once don't get me wrong, all i'm saying is that it's probably due for a bit of an overhaul. [a bit of an overhaul... best oxymoron ever]
I suppose your post was purely an informative one, to give a little background on why it is how it is. So for that, thanks for the input - it helps.
This is why I started the thread. I would like to see my addon folder, at a glance, and understand what everything is just by looking at the folder tree / heirarchy tree / filename format (whatever it ends up being). It would be much easier to maintain and keep track of changes that way.
The other main reason why I started babbling my insanity in this thread is because I think standardization is important - particularly for compatibility purposes. skyjake already established that everything has to be categorised by "asset class" (e.g., Creature-HellKnight, Weapon-Chaingun, etc.) as it makes most sense to the End User. That's fine, very good, everyone can work with it. But how are duplicates accomodated for? If there's a HiRes sprite for the shotgun or a model to choose? Different music packs to try out?
Example of a current Info Metafile for the Chaingun from jDRP v1.01:
I just realized after looking at said Info file, it obviously must be categorized by 'class' rather than type - that is, Weapon, Creature, Pickup, etc. Otherwise conflict resolution for mini-mods and the like would be a complete nightmare.
Well, KuriKai I believe you mentioned you started doing this sort of thing a while ago (I think). Have you made any progress since? I was going to sit down and absorb this thread, then take a serious crack at combining every addon into one box, just to put something into practice. But if anyone has done anything since, please do share, I plan to start soon
The plan should be to remove the dependence on the shared files turning each module into an entirely independent addon, at which point the .box becomes unnecessary.
Also, you mentioned about planning to update old mods and megawads into new Snowberry addon formats; this is also unnecessary. There is nothing to be gained from doing so. Creating manifest files where necessary would be a much better option.
Obviously I have to do a little more research then. I was thinking that, a new Doom Resource Pack, which contains models, High-Resolution bitmaps (UI, fonts, intermission screens, etc), particle effects, pretty much every visual addon except for the High Resolution World Surfaces; would be in a DRP.box - I should have given that example instead of assuming everyone would somehow gather the same conclusion I did :P This would be suitable? The DRP would further be categorised by asset class: Creatures, Pickups, Weapons (HUD only, world weapons would go into a subcategory under pickups) as it makes the most sense to the average user and can more easily be selectively loaded in the event of conflict (or, more easily over-ridden with mod-specific assets).
The Info manifest/metafile was mostly what I was thinking of. I was however considering trying to move as many DEH functions into DED's where appropriate and possible, but in light of your reply in the Beta 6.6 announcemnt thread - yes I agree, DEH should should be preserved - for authenticity purposes, if not anything else.
Well I will go ahead and restructure my personal collection of addons just for the sake of it. Then at least there's an actual physical thing presented before you all that can be more easily criticised and consulted on. It's no trouble at all whether I do it right or wrong, the truth is i'm just an eager beaver. I easily have fun with this sort of thing <:-P
the
thread
B-)