jDRP - 1.01 Vs 1.1 Alpha

edited 2015 Aug 18 in Addons for DOOM
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?

Comments

  • Personally, I want to make sure things are split into packs like:
    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
  • KuriKai wrote:
    Personally, I want to make sure things are split into packs like:
    music
    models
    textures
    sound
    environment
    user interface

    but also supply a one in all pack:
    *****resource pack
    I agree that is a good way to do it. Also agree on the version numbering and naming you mention.

    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"?).
  • The date and sub-version numbering is definately a good idea, especially the year-month-day format that so many people don't know the point of.

    Yeah the j isn't needed... where did it originally come from (jDoom and jHexen) out of curiosity? J is for Jake I assume :D a d prefix is good enough to just signify D-engine

    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:
    jDRP.box\
    
    info
    jDRP-decorations-Barrel-1.1.pk3
    jDRP-decorations-BigLamp-1.1.pk3
    jDRP-decorations-BrainStem-1.1.pk3
    jDRP-decorations-Candle-1.1.pk3
    jDRP-decorations-EvilEye-1.1.pk3
    jDRP-decorations-Firesticks-1.1.pk3
    jDRP-decorations-FloatingSkulls-1.1.pk3
    jDRP-decorations-stalag-1.01.pk3
    jDRP-decorations-Stalagmite-1.1.pk3
    jDRP-decorations-TallTorches-1.1.pk3
    jDRP-decorations-TechPillar-1.1.pk3
    jDRP-effects-ArchVileFire-1.1.pk3
    jDRP-effects-BloodSplat-1.1.PK3
    jDRP-effects-DecorLights-1.1.pk3
    jDRP-effects-ImpactFX-1.1.pk3
    jDRP-effects-RespawnFX-1.1.pk3
    jDRP-effects-ScreenEffects-1.1.pk3
    jDRP-effects-TeleportFX-1.1.pk3
    jDRP-gui-FontPack-1.1.pk3
    jDRP-gui-GUIPack-1.1.pk3
    jDRP-gui-StatusBar-1.1.pk3
    jDRP-gui-StatusBar-1.1.txt
    jDRP-items-AmmoBox-1.1.pk3
    jDRP-items-AmmoClip-1.1.pk3
    jDRP-items-Armor-1.1.pk3
    jDRP-items-Backpack-1.1.pk3
    jDRP-items-Cell-1.1.pk3
    jDRP-items-CellLarge-1.1.pk3
    jDRP-items-HealthPotion-1.1.pk3
    jDRP-items-MediKit-1.1.pk3
    jDRP-items-RocketBox-1.1.pk3
    jDRP-items-RocketItem-1.1.pk3
    jDRP-items-Shellbox-1.1.pk3
    jDRP-items-Shells-1.1.pk3
    jDRP-items-SkullKeys-1.1.pk3
    jDRP-items-SpiritualArmor-1.1.pk3
    jDRP-items-Stimpack-1.1.pk3
    jDRP-monsters-Arachnotron-1.1.pk3
    jDRP-monsters-ArchVile-1.01.pk3
    jDRP-monsters-BaronOfHell-1.01.pk3
    jDRP-monsters-BossCube-1.1.pk3
    jDRP-monsters-Cacodemon-1.1.pk3
    jDRP-monsters-Demon-1.1.pk3
    jDRP-monsters-Keen-1.1.pk3
    jDRP-monsters-LostSoul-1.1.pk3
    jDRP-monsters-Spectre-1.1.pk3
    jDRP-powerups-BezerkPack-1.1.pk3
    jDRP-powerups-ComputerMap-1.1.pk3
    jDRP-powerups-Invisibility-1.1.pk3
    jDRP-projectiles-ArachnoShot-1.1.pk3
    jDRP-projectiles-BaronFireball-1.01.pk3
    jDRP-projectiles-BFGShot-1.1.pk3
    jDRP-projectiles-CacoFireball-1.1
    jDRP-projectiles-CacoFireball-1.1.pk3
    jDRP-projectiles-Rocket-1.1.pk3
    jDRP-weaponshud-BFG-1.1.pk3
    jDRP-weaponshud-Chaingun-1.1.pk3
    jDRP-weaponshud-chainsaw-1.01.pk3
    jDRP-weaponshud-fists-1.01.pk3
    jDRP-weaponshud-pistol-1.01.pk3
    jDRP-weaponshud-plasmarifle-1.01.pk3
    jDRP-weaponshud-rocketlauncher-1.01.pk3
    jDRP-weaponshud-shotgun-1.01.pk3
    jDRP-weaponshud-SuperShotgun-1.1.pk3
    jDRP-weaponsworld-bfg-1.01.pk3
    jDRP-weaponsworld-chaingun-1.01.pk3
    jDRP-weaponsworld-chainsaw-1.01.pk3
    jDRP-weaponsworld-plasmarifle-1.01.pk3
    jDRP-weaponsworld-rocketlauncher-1.01.pk3
    jDRP-weaponsworld-Shotgun-1.1.pk3
    jDRP-weaponsworld-SuperShotgun-1.1.pk3
    
    jdrp.box\required\
    jDRP-Core-1.1.pk3
    

    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 :) Oh from what I remember there are example addons in the SVN...? Deng2 formatted ones? I might take a browse through the repository.

    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...
    \Doom Resource Pack.box
        \DMP-20090813.pack
            \decorations-20090813.pk3
                \DMP-decorations-Barrel-0.45.pk3
                \{Other decorations}
            \monsters-20090813.pk3
                \DMP-monsters-Arachnotron-0.21.pk3
                \{Other monsters}
        \{What else would go in a "Resource Pack" box apart from the Model pack (DMP)?}
    
    \Doom Interface Pack.box
        \DUIP-20090813.pack
            \Fonts-20090813.pk3
            \StaticScreens-20090813.pk3 {contains title/about/intermission screens}
            \HUD-20090813.pk3
    
    \Doom Music Pack.box
        \Classic-20090813.pack
            \doom2.pk3
            \doom-tnt.pk3  
                {RE: Since TNT recycles some Doom2 tracks, can we set this pk3 to require
                a flag that all varieties of doom2.pk3 music packs would provide? i.e. is
                it possible to do that with Info metadata}
        \RemixedByJohnSmith-20090813.pack
            \doom-ultimate.pk3
    
    \Doom SFX Pack.box
        \PlayStationSounds-20090813.pack
            \required
                \doom-all.pk3
    

    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!
  • The j prefix stands for Jaakko - as in Jaakko Keranen, the original creator of the Doomsday engine, also known as skyjake.
  • Yeah that's what I ment... I had a great-grandfather named Jaakko who moved to Australia from Estonia, and when he did he chose to 'Romanize' his first name to Jacob (which can also be Jake or Jack for short).

    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
  • I sat down to type out what would have inevitably been a pretty long response to the points raised in this thread. The more I began to swill them around my brain the more disheartened I became...

    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:
    • How can resources be packaged based on their type (audio, graphic, model, etc...) when many game objects utilize one, more or all of them (e.g., enemies)?
    • jDoom Resource Pack. It was named such that eventually, all resources were a part of it, as "modules". In other words, once all of the big packs had been broken down into modular chunks, there would only be one "super pack" that could be rolled automatically if so desired but the modules would all be distributed seperately.
  • we need to find out how we can split up things then, granted we would not split particle effects from a model
    or lighting from a skybox
  • DaniJ wrote:
    I sat down to type out what would have inevitably been a pretty long response to the points raised in this thread. The more I began to swill them around my brain the more disheartened I became...
    I spent a few hours writing my second post, now I re-read it a lot of it probably wasn't necessary :| I'm easily overwhelmed by things like this, but if you programmer guys with your epic fortitude can't eventually grasp this then what hope could us minions have?
    DaniJ wrote:
    How can resources be packaged based on their type (audio, graphic, model, etc...) when many game objects utilize one, more or all of them (e.g., enemies)?
    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 :))
    DaniJ wrote:
    jDoom Resource Pack. It was named such that eventually, all resources were a part of it, as "modules". In other words, once all of the big packs had been broken down into modular chunks, there would only be one "super pack" that could be rolled automatically if so desired but the modules would all be distributed seperately.
    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!
    KuriKai wrote:
    we need to find out how we can split up things then, granted we would not split particle effects from a model or lighting from a skybox
    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.
  • JonusC wrote:
    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!
    Yes, Doomsday will be handling the addons & config. Addons will be at least able to provide a preview image/screenshot/icon. It remains to be seen whether previewing the effects of an addon "live" while in-game are feasible (in theory they will be).
    JonusC wrote:
    skyjake, i look forward to seeing the doco on the virtual file/directory mapping and addon format improvements comming with Deng2 Oh from what I remember there are example addons in the SVN...? Deng2 formatted ones? I might take a browse through the repository.
    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.)
    DaniJ wrote:
    How can resources be packaged based on their type (audio, graphic, model, etc...) when many game objects utilize one, more or all of them (e.g., enemies)?
    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).
    DaniJ wrote:
    jDoom Resource Pack. It was named such that eventually, all resources were a part of it, as "modules". In other words, once all of the big packs had been broken down into modular chunks, there would only be one "super pack" that could be rolled automatically if so desired but the modules would all be distributed seperately.
    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.
    JonusC wrote:
    I don't know too much of Deng2's addon handling nor how the .pack differes from .pk3
    .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.
  • I was bored and i'm just throwing it out there. Completely public domain spam-like data.

     Everything in these two levels
       would be Enabled by default
                  |
         _________|_________
        /                   \
    
    \Doom Resource Pack.box
        \Decorations
            \Barrel.pk3
                \Model
                \Effects (Particles)
                \Sounds (barrel explosion noise might be shared example)
                \Future things... SM2.0 features, bump mapping, etc
        \Enemies
            \Cacodemon
                \Model
                \Effects (Particles)
                \Weapon Model
                \Weapon Effects (Particles)
                \Sounds
        \World Surfaces
            \Hi-Res Textures &lt; Can we make the Addon choice be Radio Select instead of checkbox?
                \All
                \Common
                \Doom-Unique
                \Doom2-Unique
                \Doom-TNT
                \{etc}
                \Custom... &#91;New window with advanced selector, supports searching maybe&#93;
        \Required
            \The common pack - Shared data files and big chunks (FMV/music)?
    			Is this handled efficiently...?
        \UI
            {etc}
        \Weapons
            \Fists
            \Shotgun
            \Plasma Rifle
                \Model
                \Effects (Particles)
                \Projectile
                \Projectile Effects (Particles)
                \Sounds
    



    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...
  • A long long time ago in a galaxy far far away ...

    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
    yagisan@eeepc:~/opensource/jpacks/doom/yagipick$ ls                                           
    d1music.pk3                   jdrp-guipack.1.10.pk3             jdrp-particles.1.10.pk3       
    d2music.pk3                   jdrp-hangbyfeet.1.01.pk3          jdrp-plasmashot.1.10.pk3      
    dhtp-20090226.pk3             jdrp-hangingleg.1.01.pk3          jdrp-player.1.01.pk3          
    jdrp-ammobox.1.10.pk3         jdrp-hanginglegs.1.01.pk3         jdrp-procket.1.10.pk3         
    jdrp-ammoclip.1.01.pk3        jdrp-hangnobrain.1.01.pk3         jdrp-radiationsuit.1.10.pk3   
    jdrp-arachnoshot.1.10.pk3     jdrp-hangnoguts.1.01.pk3          jdrp-respawnfx.1.10.pk3       
    jdrp-arachnotron.1.10.pk3     jdrp-hangnoleg.1.01.pk3           jdrp-revenant.1.01.pk3        
    jdrp-archvile.1.01.pk3        jdrp-hangtlookdn.1.01.pk3         jdrp-revrocket.1.01.pk3       
    jdrp-armor.1.10.pk3           jdrp-hangtlookup.1.01.pk3         jdrp-rocket.1.10.pk3          
    jdrp-backpack.1.10.pk3        jdrp-hangtnobrain.1.01.pk3        jdrp-rocketbox.1.10.pk3       
    jdrp-baronfireball.1.10.pk3   jdrp-hangtorso.1.01.pk3           jdrp-screeneffects.1.10.pk3   
    jdrp-baronofhell.1.01.pk3     jdrp-hangtskull.1.01.pk3          jdrp-shellbox.1.10.pk3        
    jdrp-barrel.1.10.pk3          jdrp-headcandles.1.01.pk3         jdrp-shells.1.10.pk3          
    jdrp-bezerkpack.1.10.pk3      jdrp-headonastick.1.01.pk3        jdrp-shinemaps.1.01.pk3       
    jdrp-bfgshot.1.10.pk3         jdrp-headsonstick.1.01.pk3        jdrp-skullkeys.1.10.pk3       
    jdrp-biglamp.1.10.pk3         jdrp-healthpotion.1.01.pk3        jdrp-skullpillar.1.01.pk3     
    jdrp-bigstonepillar.1.01.pk3  jdrp-healthpotion.1.10.pk3        jdrp-smalllamp.1.10.pk3       
    jdrp-bigtree.1.01.pk3         jdrp-heartpillar.1.01.pk3         jdrp-smallstonepillars.1.10.pk3
    jdrp-bloodpools.1.01.pk3      jdrp-hellknight.1.01.pk3          jdrp-soulsphere.1.01.pk3
    jdrp-bloodsplat.1.10.pk3      jdrp-hud-bfg.1.10.pk3             jdrp-spectre.1.10.pk3
    jdrp-bosscube.1.10.pk3        jdrp-hud-chaingun.1.10.pk3        jdrp-spidermastermind.1.01.pk3
    jdrp-brainstem.1.10.pk3       jdrp-hud-chainsaw.1.01.pk3        jdrp-spinalcolumn.1.01.pk3
    jdrp-cacodemon.1.10.pk3       jdrp-hud-fists.1.01.pk3           jdrp-spiritualarmor.1.10.pk3
    jdrp-cacoshot.1.10.pk3        jdrp-hud-pistol.1.01.pk3          jdrp-sssoldier.1.01.pk3
    jdrp-candelabra.1.01.pk3      jdrp-hud-plasmarifle.1.01.pk3     jdrp-stalag.1.01.pk3
    jdrp-candle.1.10.pk3          jdrp-hud-rocketlauncher.1.01.pk3  jdrp-stalagtite.1.10.pk3
    jdrp-cell.1.10.pk3            jdrp-hud-shotgun.1.01.pk3         jdrp-statusbar.1.10.pk3
    jdrp-celllarge.1.10.pk3       jdrp-hud-supershotgun.1.10.pk3    jdrp-stimpack.1.10.pk3
    jdrp-clip.1.10.pk3            jdrp-imp.1.01.pk3                 jdrp-stonepillar.1.01.pk3
    jdrp-colongibs.1.01.pk3       jdrp-impactfx.1.10.pk3            jdrp-talltorches.1.10.pk3
    jdrp-computermap.1.10.pk3     jdrp-impaledtwitcher.1.01.pk3     jdrp-techpillar.1.10.pk3
    jdrp-core.1.10.pk3            jdrp-impfireball.1.10.pk3         jdrp-teleportfx.1.10.pk3
    jdrp-cyberdemon.1.01.pk3      jdrp-invisiblity.1.10.pk3         jdrp-tree.1.01.pk3
    jdrp-demon.1.10.pk3           jdrp-invulnerability.1.01.pk3     jdrp-w-bfg.1.01.pk3
    jdrp-evileye.1.10.pk3         jdrp-keen.1.10.pk3                jdrp-w-chaingun.1.01.pk3
    jdrp-explosions.1.01.pk3      jdrp-keycards.1.10.pk3            jdrp-w-chainsaw.1.01.pk3
    jdrp-fire.1.10.pk3            jdrp-lightgoggles.1.10.pk3        jdrp-w-plasmarifle.1.01.pk3
    jdrp-firecan.1.01.pk3         jdrp-lostsoul.1.10.pk3            jdrp-w-rocketlauncher.1.01.pk3
    jdrp-firesticks.1.10.pk3      jdrp-mancfireball.1.01.pk3        jdrp-w-shotgun.1.10.pk3
    jdrp-floatingskulls.1.10.pk3  jdrp-mancubus.1.01.pk3            jdrp-w-supershotgun.1.10.pk3
    jdrp-fontpack.1.10.pk3        jdrp-medikit.1.10.pk3             plmusic.pk3
    jdrp-formercommando.1.01.pk3  jdrp-mediumlamp.1.10.pk3          tntmusic.pk3
    jdrp-formerhuman.1.01.pk3     jdrp-megasphere.1.10.pk3
    jdrp-formersergeant.1.01.pk3  jdrp-painelemental.1.01.pk3
    
  • Hi Yagisan [and greetz], sorry for the late response. Completely forgot about this thread.
    Yagisan wrote:
    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. {...}
    I do remember witnessing this big change.
    Yagisan wrote:
    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)
    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:
    name: Chaingun
    category: hudweapons
    provides: doom-model-hudchaingun
    

    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 :)
  • Combining every addon into one box is unnecessary. The idea with the box format is to provide a system whereby multiple addons can be combined into a single entity. In the case of jDRP this is necessary because the modules rely upon a core set of definitions and files shared among them.

    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.
  • DaniJ wrote:
    Combining every addon into one box is unnecessary. The idea with the box format is to provide a system whereby multiple addons can be combined into a single entity. In the case of jDRP this is necessary because the modules rely upon a core set of definitions and files shared among them.

    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.

    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).
    DaniJ wrote:
    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.
    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
  • Sorry to bring up an old topic, but any updates to the jDRP? I'm still using 1.1 alpha as it has some better models than 1.01 but would be nice to get some new stuff.
  • Some of us are working on the dmp2, check out the thread
  • Seems kind of strange to me that jDRP 1.01 was compiled back in 2004 - over 11 years ago, and 1.1a has been floating around since about 2005, but there really hasn't been much new 3d model content since then. In addition to 1.1a I got a pinky monster model as a separate addon, and caco demon, but thats it. Am I missing any cool new stuff?
  • edited 2015 Aug 18
    Check


    the


    thread


    B-)
  • och wrote:
    Seems kind of strange to me that jDRP 1.01 was compiled back in 2004 - over 11 years ago, and 1.1a has been floating around since about 2005, but there really hasn't been much new 3d model content since then. In addition to 1.1a I got a pinky monster model as a separate addon, and caco demon, but thats it. Am I missing any cool new stuff?
    If you read the thread as suggested you will see that people are indeed working on new models. Dday is opening up to a new model format and from what I gather, the new models are not being released until a new pack is put together and working well with the new format.
Sign In or Register to comment.