[The Commander]

Hank, on 22 January 2012 - 03:21 PM, said:

@ LeoD (The Commander beat me to it) try rapidshare - I use mediafire, but all my files are below 50MB. Yet, like MegaUpload, they all work with similar advertisment schemes and want you to turn into a 'pro' user. Thus, try it.

Hopefully in a couple more weeks I have better news.

No, don't use RAPEshare either, thats as much ass as megaupload and it will most likely be next to get pulled.

[Hendricks266]

Rapidshare is much more ass than Megaupload. In particular it has slow download speeds. Megaupload got better as time went by, eliminating the 45 second wait and the captcha.

[LeoD]

Back on topic...the new links are ready in Post #1.
Except for the somewhat redundant HRP 4.0 archive.

Btw., I have added the current PolyMER maphacks, buried in a zip, to the Polymost update. To use the orginial levels' Polymer lighting in PolyMOST HRP/PolyMER renderer, put 'polymost_hrp_update_polymer_maphacks.zip' into your autoload folder.

[LeoD]

Hendricks266, on 24 January 2012 - 04:55 PM, said:

The more I think about it, the more your Polymost HRP update patches need to be featured on hrp.duke4.net, although I would like to try my hand at restoring all the deleted polymerized textures if you have not done that already,

Was one of the main reasons to start this whole thing.

Hendricks266, on 24 January 2012 - 04:55 PM, said:

as well as migrating all alt-pals.

First thing I did.

Due to some lack of disclipline the polymerisation process has not been consistent:
- texture X.png was replaced by diffuse, normal, and specular (X_d.png, X_n.png, X_s.png)
but stayed as unused in the repo [very good]
- same as above but old version deleted [easy to recover]
- texture Y.png stayed and normal (Y_n.png) and specular (Y_s.png) map were added
[sometimes confusing but those look best for me]
- texture Z.png was overwritten, normal (Z_n.png) and specular (Z_s.png) map added, no Z_d.png in the repo [bad]
- and of course some new textures triplets were added with no Polymost predecessor

Hendricks266, on 24 January 2012 - 04:55 PM, said:

It may be helpful for the download page to have a two-column layout for the mainline HRP section with one specifically for Polymer and one compatibility for Polymost.

In any case, a potential solution is in the planning stages involving overlapping definitions of textures/models/etc specifically for either Polymost or Polymer. If you know C/C++ it's planned to be like the ifdef directive.

Not sure if I'd like that (if I have understood correctly).
Ideally the Polymost stuff should be put back into the repo. This would add only 31MiB plus some .svn overhead. It would mean some work but since a working on-par Polymost HRP already exists (single zip on my disk) it wouldn't be that difficult.
After renaming the Polymost DEFs one would only have to choose between the topmost DEFs, say duke3d_hrp_polymer.def and duke3d_hrp_polymost.def. (Maybe one more button in the startup window: choose HRP style.)

Hendricks266, on 24 January 2012 - 04:55 PM, said:

Once that is done, as well as my "autoload killer", we should never have to deal with a noob storm relating to Polymer content breaking in Polymost again.

Did I miss something?

[LeoD]

LeoD, on 24 January 2012 - 07:09 PM, said:

After renaming the Polymost DEFs one would only have to choose between the topmost DEFs, say duke3d_hrp_polymer.def and duke3d_hrp_polymost.def. (Maybe one more button in the startup window: choose HRP style.)

BS. Should have gone to sleep earlier. A simple zip overriding the standard duke3d_hrp.def is enough.

[supergoofy]

polymost_hrp-4.9.285.zip 381.6 Mb
md5: f48dd593520627db425ee0701870d94b

http://jumbofiles.com/mir3kinv0ocn

thanks LeoD

note: I merged the zip files. No need for separate download.

[LeoD]

supergoofy, on 25 January 2012 - 12:06 PM, said:

polymost_hrp-4.9.285.zip 381.6 Mb

Thanks. Link copied to post #1.
I tried out half a dozen filehosters for the convenience link but all failed. I suspect my ISP or their router to interrupt upload connections after a certain amount of time or data. What's good about jumbofiles is that they provide a link to delete the upload which can be bookmarked, just like hotfile.
One more thing worth mentioning: when creating an HRP zipfile I'd turn the compression off. There isn't much to gain on JPGs and PNGs anyway and without the inflation operation the texture loading times should be somewhat shorter. (No idea if that is noticeable in real life, though.)

[LeoD]

Hendricks266, on 24 January 2012 - 04:55 PM, said:

The more I think about it, the more your Polymost HRP update patches need to be featured on hrp.duke4.net, although I would like to try my hand at restoring all the deleted polymerized textures if you have not done that already, as well as migrating all alt-pals. It may be helpful for the download page to have a two-column layout for the mainline HRP section with one specifically for Polymer and one compatibility for Polymost.

In any case, a potential solution is in the planning stages involving overlapping definitions of textures/models/etc specifically for either Polymost or Polymer. If you know C/C++ it's planned to be like the ifdef directive.

LeoD, on 24 January 2012 - 07:09 PM, said:

Not sure if I'd like that (if I have understood correctly).

This was meant to the ifdef only, btw.

[Hendricks266]

LeoD, on 24 January 2012 - 07:09 PM, said:

Ideally the Polymost stuff should be put back into the repo. This would add only 31MiB plus some .svn overhead. It would mean some work but since a working on-par Polymost HRP already exists (single zip on my disk) it wouldn't be that difficult.

You are actually right. I was including the additional SVN cost of readding the tons of MB that the alt-pals take up when in fact it would be zero because they are already there. For reason both of ease of use for the end-user and simple theoretical correctness the two versions should remain together. It's not like the Polymost one will be getting much bigger.

LeoD, on 24 January 2012 - 07:09 PM, said:

After renaming the Polymost DEFs one would only have to choose between the topmost DEFs, say duke3d_hrp_polymer.def and duke3d_hrp_polymost.def. (Maybe one more button in the startup window: choose HRP style.)

Never ever ever would we hardcode HRP def names or especially an option in the startup screen for something like this. This isn't SWP, we have standards for separation of mod and program. Then again, the possibility of something like this which can be flexibly swapped in and out by the user.........

The way the "ifdef" idea is discussed would be that the exact same defs would be loaded, but reprocessed whenever either of the OpenGL renderers is initialized. It would be trivial to have two separate packs this way working in tandem as I was previously thinking in my previous post if we had some way to easily harness the command-line -mh def mutator parameter I added........

LeoD, on 24 January 2012 - 07:09 PM, said:

Did I miss something?

I like to hint at things that I have not disclosed publicly but I don't really announce them because it would get people's hopes up which may be bad in case I fail.

[LeoD]

Hendricks266, on 25 January 2012 - 05:41 PM, said:

The way the "ifdef" idea is discussed would be that the exact same defs would be loaded, but reprocessed whenever either of the OpenGL renderers is initialized.

That would cost additional time, and loading times on my machine become more and more epic anyway (mostly because of the executable's evolution I suspect). While the implementation of such a feature seems an interesting idea to me I don't think it's worth it in terms of the benefits for this particular issue. There are two sets of working DEFs already, one of which only needs to be renamed. Anyone contributing to polymerisation would not have to hassle with ifdefs and the polymost part of the HRP if they are kept separated.
Furthermore, if the HRP is to be chosen by eduke32 based on the used renderer it would no longer be possible to run Polymost HRP rendered by Polymer which I do quite frequently in certain situations. (Well, one could switch ingame, but...)

Hendricks266, on 25 January 2012 - 05:41 PM, said:

I like to hint at things that I have not disclosed publicly but I don't really announce them because it would get people's hopes up which may be bad in case I fail.

Ha! Too late, I'm after you.
autoload killer sounds controversial since I like that feature...

Hendricks266, on 25 January 2012 - 05:41 PM, said:

It would be trivial to have two separate packs this way working in tandem as I was previously thinking in my previous post if we had some way to easily harness the command-line -mh def mutator parameter I added........

Uh, Windows noobs and commandline parameters ... well, I repeat my proposal of a DEF in a ZIP.

[Hendricks266]

LeoD, on 25 January 2012 - 06:31 PM, said:

That would cost additional time

Not really. It would take a fraction of the time needed to parse the defs on startup since the steps of parsing and separating ifdef tokens will be split. We've thought this through. You should idle in #eduke32 to see our discussions.

LeoD, on 25 January 2012 - 06:31 PM, said:

Furthermore, if the HRP is to be chosen by eduke32 based on the used renderer it would no longer be possible to run Polymost HRP rendered by Polymer which I do quite frequently in certain situations. (Well, one could switch ingame, but...)

That is true but I don't necessarily see why you would want to run the Polymost HRP in Polymer aside from performance, in which case it is sort of a kludge.

LeoD, on 25 January 2012 - 06:31 PM, said:

Ha! Too late, I'm after you.
autoload killer sounds controversial since I like that feature...

"<something> killer" is a sensational way to phrase something that is more like an upgrade or replacement. I myself am not planning to remove the autoload feature as it stands now.

LeoD, on 25 January 2012 - 06:31 PM, said:

Uh, Windows noobs and commandline parameters ... well, I repeat my proposal of a DEF in a ZIP.

I reiterate that we have thought out solutions that are simple and elegant.

[supergoofy]

LeoD, on 25 January 2012 - 05:25 PM, said:

Thanks. Link copied to post #1.
I tried out half a dozen filehosters for the convenience link but all failed. I suspect my ISP or their router to interrupt upload connections after a certain amount of time or data. What's good about jumbofiles is that they provide a link to delete the upload which can be bookmarked, just like hotfile.
One more thing worth mentioning: when creating an HRP zipfile I'd turn the compression off. There isn't much to gain on JPGs and PNGs anyway and without the inflation operation the texture loading times should be somewhat shorter. (No idea if that is noticeable in real life, though.)

Actually jumbofiles is one of the very few filehosters that utilize my full upload speed. It took though about 1h

And again big thanks for updating polymost hrp. I think that it should be hosted in the official hrp site.

I have also edited my previous post and I have added the md5 checksum of the zip.

[LeoD]

supergoofy, on 27 January 2012 - 02:13 AM, said:

A good poll would be about the new unofficial Polymost HRP by LeoD
http://forums.duke4....loves-and-more/

I think that the Polymost HRP by LeoD should be hosted in the official HRP site.

The reasons are simple:
1. Polymer renderer is not ready yet and even if you have a capable computer, there are still various problems.
2. Polymer HRP is not backwards compatible with Polymost renderer, at least not yet.

Are there other things broken than the RPG currently?

supergoofy, on 27 January 2012 - 02:13 AM, said:

3. Not all users have powerful gpus to handle Polymer.

In my opinion Polymer needs at least a GeForce 9600GT 512MB card, but the recommended would be an 8800GTS 512MB card.

In the early days of Polymer small maps were even somewhat playable with my 6600GT. I do have a GeForce 9600GT 512MB card now and an Athlon 64 X2 2GHz. HRPlaying fully polymerized original maps (textures & maphacks) at acceptable framerates is almost impossible although I have turned down the renderer options to a minimum.

Hendricks266, on 27 January 2012 - 06:23 AM, said:

If you saw the discussion in LeoD's thread, once the def "ifdef" parameter is implemented it makes the most sense to recombine the two packs. I would be willing to do the def writing required.

supergoofy, on 27 January 2012 - 09:17 AM, said:

That would be great Hendricks266. I know that I cannot do that, I don't have the knowledge.

Probably this needs a lot of work, unless it can be done automatically with a vb script or some other way.

If I had write access to the repo I could do the first steps (already obsoleting downloading hundreds of MiB for Polymost HRP):
- Add "_d" to the diffuse maps' filenames which overwrote their Polymost predecessors and patch the DEFs.
- Copy back the deleted Polymost textures
- Provide some polymost_override.zip which only contains the DEFs that activate the polymost contents of the HRP.

I'd have to think a bit about the handling of the changed models, though.

[Hendricks266]

LeoD, on 27 January 2012 - 10:59 AM, said:

If I had write access to the repo I could do the first steps (already obsoleting downloading hundreds of MiB for Polymost HRP):
- Add "_d" to the diffuse maps' filenames which overwrote their Polymost predecessors and patch the DEFs.
- Copy back the deleted Polymost textures
- Provide some polymost_override.zip which only contains the DEFs that activate the polymost contents of the HRP.

I'd have to think a bit about the handling of the changed models, though.

If you want repo access, come on the IRC channel and talk to plagman. However, I would caution you that judging by your third item, you do not fully understand how the new "ifdef" feature will work. Everything would be contained in the same def tree. There is no need for a separate zip which is just kludgy.

Tentative example:

// RPG (2544)

#ifdef polymost
model "highres/sprites/firstperson/2544_rpg_polymost.md3" {
   scale 1.9
   skin { pal 0 file "highres/sprites/firstperson/2544_rpg_polymost.png" }
   frame { name "idle" tile 2544 }
   hud { tile 2544 xadd 0.1 yadd 1.15 zadd -0.68 angadd -12 }
   frame { name "idle" tile0 2545 tile1 2546 }
}
#endif

#ifdef polymer
model "highres/sprites/firstperson/2544_rpg.md3" {
   scale 4
   skin { pal 0 surface 0 file "highres/sprites/firstperson/2544_rpg_d.png" }
   normal { pal 0 surface 0 file "highres/sprites/firstperson/2544_rpg_n.png" }
   specular { pal 0 surface 0 file "highres/sprites/firstperson/2544_rpg_s.png" }
   skin { pal 0 surface 1 file "highres/sprites/firstperson/duke_hand_d.png" specpower 5 specfactor 0.5 }
   normal { pal 0 surface 1 file "highres/sprites/firstperson/duke_hand_n.png" }
   specular { pal 0 surface 1 file "highres/sprites/firstperson/duke_hand_s.png" }
   skin { pal 0 surface 2 file "highres/common/transp.png" }
   glow { pal 0 surface 2 file "highres/common/transp.png" }
   frame { name "frame_1" tile 2544 }
   skin { pal 0 surface 2 file "highres/sprites/firstperson/muzzle_flash_01.png" }
   glow { pal 0 surface 2 file "highres/sprites/firstperson/muzzle_flash_01.png" } 
   frame { name "frame_1" tile0 2545 tile1 2546 } 
   hud { tile0 2544 tile1 2546 xadd 2 yadd 4 zadd -0.5 angadd -64 fov 250 } 
}
#endif

I would also caution you that although it is planned the feature has not actually been made yet. If by step one you are intending to simply rename textures without a _d that also have a _n and/or _s && are Polymer replacements for a prior Polymost texture, then steps one and two would be welcome to be done now.

[LeoD]

Hendricks266, on 28 January 2012 - 01:02 AM, said:

I would also caution you that although it is planned the feature has not actually been made yet.

That's why the zip is still part of my proposal.

Hendricks266, on 28 January 2012 - 01:02 AM, said:

If by step one you are intending to simply rename textures without a _d that also have a _n and/or _s && are Polymer replacements for a prior Polymost texture, then steps one and two would be welcome to be done now.

Exactly.

[Arwu]

Thanks LeoD for these packs Gloves look great and I like that crosshair Im not see many difference in textures but until I not be able to run Polymer then I stick with these packs very good work

[LeoD]

I have added another download option to Post #1:

Quote

Download #5 - Polymost HRP Override Pack (31MiB):
polymost_hrp_override-5.1.285.zip
If you already have the PolyMER HRP v5.1 (svn285) then you can use this pack on top of that to get the PolyMOST HRP back.
If you want to use a Z-pack in combination with the override pack, you'll need the PolyMOST version/Download #3.

[NightFright]

I took the liberty of placing these files onto the HRP website (with additional Duke4.net mirrors):

Full Polymost HRP v4.1.285
Polymost HRP Update Pack v4.9.285
Polymost HRP Override Pack v5.1.285

Also tried to give some brief description so that it's as clear as possible which file is needed for which purpose.

The other two packs contain custom stuff, so I guess it's enough if those links are posted here. Sorry for not adding this earlier, but most of the time I just don't get around to doing things which should happen.

[LeoD]

NightFright, on 31 January 2012 - 02:22 AM, said:

I took the liberty of placing these files onto the HRP website (with additional Duke4.net mirrors)

Appreciated.

NightFright, on 31 January 2012 - 02:22 AM, said:

Also tried to give some brief description so that it's as clear as possible which file is needed for which purpose.

Done well.

NightFright, on 31 January 2012 - 02:22 AM, said:

The other two packs contain custom stuff, so I guess it's enough if those links are posted here.

Otherwise this thread would become somewhat insignificant, wouldn't it?

NightFright, on 31 January 2012 - 02:22 AM, said:

Sorry for not adding this earlier, but most of the time I just don't get around to doing things which should happen.

I'm for sure the least qualified person to blame you for that.

[LeoD]

The Polymost HRP version number (4.*) reflects the fact that the Polymer (5.*) features are missing.
However, for the upcoming version I plan to raise the Version number from 4.9.* to 5.1.* to adapt to the override pack which I suppose to be the mainly used/downloaded version, soon.
Please let me know if you think this is a bad idea.

The new babe model 603 raises another (minor) issue btw.: now different maphacks are needed for some original maps.
So after the ifdef feature is implemented there is a new little pita I'd have to deal with.

[NightFright]

Well, you don't have to necessarily switch to the new babe model right away, you know. The way it is now, there are still some features missing, e.g. improved skin, normalmaps and bra version. Anyway, it's a start, and I am confident someone around here will finish what has been initiated.

[LeoD]

NightFright, on 14 February 2012 - 12:25 AM, said:

Well, you don't have to necessarily switch to the new babe model right away, you know.

The problem would be more keeping the old one. This was mostly addressed to Hendricks266 and the discussion about the possibility of putting the Polymost content back to the repo.

NightFright, on 14 February 2012 - 12:25 AM, said:

The way it is now, there are still some features missing, e.g. improved skin, normalmaps and bra version. Anyway, it's a start, and I am confident someone around here will finish what has been initiated.

Hm, I'm not so confident because apparently most contributors to our community prefer not to build upon other peoples' work but to start their own thing (and hope that the others will find time and motivation to improve their stuff themselves).
Maybe the repo should be branched into development and release tree? Well, better not.

[NightFright]

Hehe, right now we can be glad if someone contributes anything at all, so I guess one repository will suffice. But anyway, your efforts are appreciated here. It's clear that there is demand for this, and Polymer unfortunately isn't for everyone, so we must somehow satisfy the needs for everyone. It's hard enough to do stuff for Polymer, it would be hard to maintain two different HRPs (because that's what it basically is) alone, so this involvement of yours is really helpful. Even though it's not easy, and every change to Polymer HRP can be troublesome to compensate/convert.

[LeoD]

5.1.292 Keeping up with Polymer HRP update...

Polymost HRP Update Pack 5.1.292 :

updated : water textures 0336-0338, 3293_wide, some rotated MD3 models -> all maphacks
added : 0822, 4154_d, 4265_d (the latter two being diffuse maps only but still looking good in Polymost)
removed : 1203
changed : added "_polymost" to some DEF files which differ from their Polymer counterparts.


Z-Packs 5.1.292 :

added : old 0603 hangbabe + according maphacks
changed : added "_polymost" to some DEF files which differ from their Polymer counterparts.


Please note that the packs are bigger then they'd need to be because I'm too lazy to remove some unused stuff for release. Plus, the Polymost version derives from the Polymer version and contains even more stuff which is redundant with the Polymost HRP.


Download links: Post #1

[NightFright]

Duke4.org HRP mirrors updated.

[LeoD]

NightFright, on 14 February 2012 - 08:33 AM, said:

It's hard enough to do stuff for Polymer, it would be hard to maintain two different HRPs (because that's what it basically is) alone, so this involvement of yours is really helpful. Even though it's not easy, and every change to Polymer HRP can be troublesome to compensate/convert.

Sometimes it's a PITA indeed, but mostly after I had a longer break on fiddling with this stuff because of my lack of actual background knowledge (and because of red wine).
ATM there are too many Polymost HRP related downloads available IMO which might confuse noobs. When the next full Polymer HRP like 5.2 comes out, the Polymost 4.0 download should be replaced by a full Polymost 5.2 pack.

Currently I'm waiting to be granted repo access by plagman. After some cleanup and restoring some stuff, both packs could be maintained separately in the repo without much interference as long as no Polymost files are overwritten or deleted. I'm currently renaming the Polymost DEFs so that the Polymost part of the repo would have its own set of DEF files until that ifdef feature is implemented.

If all goes well there should only be the override pack left in the end. This would at least contain its own duke3d_hrp.def and maybe some stuff which might be a nasty task to bring back into the repo.

Btw, does the projections stuff actually do anything currently?

[KareBear]

I have downloaded the Z-Pack and i just want to use the Gloves and the Gold Pistol.Can I get exact instructions on what to do please?

Edit:I think i almost have it now.Only probelm when i use the hud shotgun fov improvement,

http://forums.duke4....096#entry120096

It screws up the other weapons.Can the Z-Pack be updated with the hud shotgun fov improvement?

[Spiker]

LeoD, on 15 February 2012 - 05:05 PM, said:

Btw, does the projections stuff actually do anything currently?

Not in Polymost.

[supergoofy]

I'm uploading the new full pack for polymost 5.1.292

It will take some time I will edit my post with a download link, once the upload is complete.

[edit]

polymost_hrp-5.1.292.zip (385.6 Mb)

md5: 15f956ae1799eef300297ae54c6654cf

Download Link:
http://jumbofiles.com/mrtujhaxwws5


Thanks to LeoD for keep updating Polymost HRP

[NightFright]

Just in order to warn you. I will probably refresh the update pack this weekend because of the fix for the HUD shotgun. You couldn't implement this for the Polymost packs, but there will also be two new textures or so.