I've been busy with other stuff and it got forgotten - but the corrected version is built. I added dirt mapping as well just for the hell of it. 

Ijed, thank you for taking the time and making the effort.

I forgot to mention one thing. I have found some properties of the qdqstats tool extremely useful for testing maps with the id1 progs.dat - such as genocide (killing every living monster at any time), making triggers visible, toggling trigger and counter etc. info - bound to impulses. Unfortunately each progs.dat seems to need its own tool thus the existence of hipstats and doestats etc.

I sorely missed such a tool during my test on Locust.

In my opinion, if it is possible it would greatly help the work of testers to have a tool for any map with any progs.dat that enables features listed above. All the more so in the case of extremely big maps featuring very complex level design, changing scenery and ever increasing monstercounts, such as the ones in this pack. 

Do you have a link to the uncompiled src?

If not it should still be trivial to add - the src of RRP is released. 

You are welcome to mail me your demos and comments.
I don't know when I will get time to fix the map (know some stuff myself that could need fixin) but I will look at it!
Thanks 

@Hrimfaxi: ok, I'll probably start tomorrow.

@ijed: was your post a response to mine?

In that case I have to admit I don't really know what source means. So it's not clear to me what should or could be done with it and how. 

I can include new qc script for qdqstats, I just need to know where to find the source code, so that I can merge it with my own.

Looking at QDQ pages I can see plenty of places to get a progs.dat but couldn't find the source. 

Well, that would be great if you could add new qc script.

Would it work only for RRP if I understand well?

I ask because even if you would be kind enough to do it I cannot promise I'll actually go ahead and test all the maps. Although it would still be awesome for my upcoming repeat on Locust.

Not sure if the qdqstats source is available. Maybe you (or I can do it if you wish) could ask on the SDA forum or contact Mr. Nolan Pflug aka 'Radix' himself. Updates have been few and far between on the Quake site so it may take while to receive the source.

I can perfectly understand if you come to the conclusion it's much ado about nothing, but I appreciate your willingness to help work on an already tested and released map pack. 

Well, that would be great if you could add new qc script.

Would it work only for RRP if I understand well?

I ask because even if you would be kind enough to do it I cannot promise I'll actually go ahead and test all the maps. Although it would still be awesome for my upcoming repeat on Locust.

Not sure if the qdqstats source is available. Maybe you (or I can do it if you wish) could ask on the SDA forum or contact Mr. Nolan Pflug aka 'Radix' himself. Updates have been few and far between on the Quake site so it may take while to receive the source.

I can perfectly understand if you come to the conclusion it's much ado about nothing, but I appreciate your willingness to help work on an already tested and released map pack. 

For RRP although you could use RRP to run other maps, I think some ammo would fall out because RRP corrected the ammo offset (breaking it for all id1 content...).

I suspect that exposing the details of my map would show where the bugs are - it possible for the tarbaby splits to sometimes throw one out of the world and not delete itself when that happens 100% of the time.

I've got the fixed map on my office machine so will repack it during the week, including the qdq code if it is available. 

Because it has some anti cheating features. That's hardly relevant these days so maybe asking Nolan is a good idea. (I had a copy at some point and maybe still do on a CD somewhere but no idea where, sorry) 

@mwh: thank you for the info. Somehow ensuring to hear it from SDA (ex-)staff.

By the way, love your Rogue runs. The r1m4 demos are favourites.

@ijed: skill 0 crash, long drop, infused, secret armour triggers would be my wishlist.

I forgot another thing: upon loading the maps in developer 1, I had items falling out of each map in the pack. I haven't seen negke mention it, so I began to wonder whether something is wrong at my end. Have you been aware of this issue? 

upon loading the maps in developer 1, I had items falling out of each map in the pack. I haven't seen negke mention it, so I began to wonder whether something is wrong at my end. Have you been aware of this issue?

Maybe a recent engine change/addition is responsible for this, iirc my map didn't have those issues at release. 

I just fired up mfxsp19.bsp in developer 1.
Screenshots for both win32 and win64 verisions:

http://quaketastic.com/files/screen_shots/QS.090.0-windows.jpg
http://quaketastic.com/files/screen_shots/QS.090.0-win64.jpg

They say 4 bonus items fell out the level.

At release, the required version was QS-0.85.10, but as the download links in the topic don't download anything and I couldn't find QS-0.85.10
on the Sourceforge page under the Files either, I cannot tell how the maps runs in it for me. 

i tested with recent versions now and have even more item dropout. 

 

Very weird, I don't recall any qs changes that could affect items dropping out. Will look into it tonight.. 

ok, Spirit archived the 0.85.10-r980 binaries:
https://www.quaddicted.com/files/engines/quakespasm-0.85.10-r980_windows.zip
https://www.quaddicted.com/files/engines/quakespasm-0.85.10-r980_win64.zip

But I always get 4 bonus items falling out on mfxsp19, either with those releases, or the latest qs (0.91.0), or MarkV. So, I don't think it's an engine issue? 

@ericw: thanks for the check.

Thanks to Spirit for the archive.

I can confirm 4 bonus items falling out in both versions. 

If the engine says items fall out, then items fall out. It's caused by improper placement and the authors not testing the map in developer mode like they should. No engine fix necessary. 

Sounds like it. I was just wondering because the progs recently caused similar issues on another engine. 

I have run into the issue testing a map where items would fall out if the map was loaded in a QS win64 executable, but would not fall out if loaded in QS win32 executables. Both on win64 systems. I can make the screenshots if very necessary.

So it seems to me the issue if pretty fucking far from being that easy. 

That sounds like a pretty fucking serious engine bug and I hope you reported it to the QS team with a nice test case. 

It might be considered no biggie if 20 shells or a quad is missing from a map.

In my point of view, the biggie is whether the issue can be considered the responsibility of the mappers and testers, or is it beyond their control to some extent.

It can be considered my responsibility to report the issue since I have never seen it mentioned, however, I did have my reason for the timing.
I apologize for the delay. 

It might be considered no biggie if 20 shells or a quad is missing from a map.

In my point of view, the biggie is whether the issue can be considered the responsibility of the mappers and testers, or is it beyond their control to some extent.

It can be considered my responsibility to report the issue since I have never seen it mentioned, however, I did have my reason for the timing.
I apologize for the delay. 

Yeah, I would be interested in seeing that test case, feel free to email me directly if you prefer. no rush, of course. :-)

It could cause a missing pack of shells, but it could also make maps unbeatable.

There have already been 2 visual bugs in 64-bit QS (mdl lighting, lightmap size calculation) that are fixed / worked around now, but I never ran in to a physics difference (but it's not surprising.)
One can argue that mappers should test on 64-bit engines for compatibility, but for QS I think 64-bit should behave the same as 32-bit.