[NightFright]

Due to recent events involving outdated info in the FAQ section of the HRP website, I think it's a good idea to ask you guys what you think is missing, should be improved, updated or whatever.

I'd especially like to add at least some basic info about getting the HRP to work on non-Windows operating systems. If any of you has experience with it and can assist with gathering necessary info, feel free to shoot here!

[Hendricks266]

I'm hoping that as time passes, using the HRP will be easier every step of the way, minimizing the amount of instructions that need to be given.

This feature, which I've been planning for years, will supplant autoload and batch files with a built-in mod selector, but I am still revising the spec. It will work cross-platform.

Additionally, it would only take a simple bash script for the Duke4.net server to make a zip download from the HRP SVN after every commit. The days of uploading versioned packs would be over, though you could still announce milestones and augment a version as a publicity manager.

[TON]

Steveeeie should be added in credits section:

============ 3D Models and Skins ============



http://hrp.duke4.net/about.php

[Hendricks266]

That credits section needs some redesign... I can't tell for sure, but it looks like SD_Duke credits were merged in at some point. I don't know when else the HRP would have had "Map/Con Hacking" unless it means mhk maphacks.

[NightFright]

Yeah, the credits section is a pain. It is basically a merge of each and every name that has ever been involved with the pack, regardless whether the content they contributed is still included or not. The scale of this project is too complex to provide a reliable list of who did what exactly (as I was able to do for the much smaller DukeDC HRP project), especially considering all the recent revisions. It's really hard to figure out what an up-to-date list could look like. Maybe two separate lists could be created, one with contributers of the earlier years ("Hall of Fame" style) and one with those of the more recent HRPs.

An all-in-one solution for multi-platform download/building of "bleeding edge" HRPs would indeed be appreciated and could help to "unbloat" the website and its offerings quite a bit, especially in the download section. I am also still trying to get a planned redesign of the site going, so things might also look a bit better from a visual point of view after that.

[Hendricks266]

What about the site design itself needs changing? I know Parkar worked hard to design it. The only thing I can think of is that it is designed for a 1024x768 screen, but ideally it should have a dynamic width. I don't think that needs a full redesign.

"hrp2.psd" in this package is Parkar's original layered site design, which would be invaluable to make modifications to the existing layout.

As for the credits, it would be relatively simple, clerically speaking, to execute "svn log" and write up individual credits.

[Forge]

if your plan is to abandon hosting "static" compressed packages and converting to a "every commit" svn repository what are your contingency plans if something is "broke"
people won't be able to easily "back date" to a working version and someone should stay on top of it like the eduke32/mapster32 developers to provide quick fixes.

[NightFright]

Guess that's the risk with bleeding edge custom builds - they can be flawed and you should keep your previous working copy as a backup always (if possible). Of course this can also apply to official releases, but usually they are tested before (at least I do a playthrough of at least 1-2 episodes with a candidate to make sure).

But well, FAQ topic again. Anything else that could be improved?

[Hendricks266]

Forge, on 08 February 2014 - 11:22 AM, said:

if your plan is to abandon hosting "static" compressed packages and converting to a "every commit" svn repository what are your contingency plans if something is "broke"
people won't be able to easily "back date" to a working version and someone should stay on top of it like the eduke32/mapster32 developers to provide quick fixes.

On the other hand, downloading an entire zip is a lot of bandwidth to transfer for even one iteration of bisection.

[LeoD]

Static full ZIPs are the way to go for HRP releases IMO. Anything else just offers more ways of doing it wrong to the customers and increases the number of Q/A iterations in support communication. The HRP is quite complete and stable. If something spectacular shows up like last year's Duke/Cycloid models, or enough other stuff has accumulated, an update pack may be issued. (Thinking about Easter)
There's the sticky TortoiseSVN thread for anyone who wants to follow the ongoing polymerisation efforts more closely.
In contrast to EDuke32, bisecting is of not much use to nail down HRP issues, btw.