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. 

I asked the mapper in question if he doesn't mind.
If he agrees, I'll send screenshots and demos by mail.

I'm willing to test all versions on Sourceforge Files page from QS.0.90.0 tomorrow on Locust.

It seems the map behaves differently in 85 than in 90 with regards
to z-fighting. Should this be the case? Namely no z-fights in 85 where I found some in 90.

Let me take this opportunity to thank you for your continuous efforts and work on Quakespasm, my engine of choice. 

Thanks, glad to hear it.

Namely no z-fights in 85 where I found some in 90.
Yes, this is expected. 0.85.9 had a hack to fix z-fighting, which was causing mappers to put z-fighting in their maps because QS was hiding it. It would also cause a seam to appear around secret doors. We disabled this in 0.90.0. You can re-enable it by setting "gl_zfix 1".

I'm willing to test all versions on Sourceforge Files page from QS.0.90.0 tomorrow on Locust.
I'd suggest using the latest QS version 0.91.0, unless you are looking for a regression between 0.90.0 and 0.91.0? 

Those darn mappers! >:-( 

which was causing mappers to put z-fighting in their maps

Accidentally? Or could it have any benefit so that there is a point to do it intentionally?

0.85.9 had a hack to fix z-fighting(...)QS was hiding it

This seems dangerous to me.
The maps (ab)using this feature are exposed in the later engine version.

you are looking for a regression between 0.90.0 and 0.91.0?

No, I was just curious when the differences were introduced.

In which version were the maps tested?

The topic says the required engine was 0.85.10.
All z-fightings in the maps hidden, even before the eyes of testers?

Now, in later engines, light may come onto issues the
mappers and testers might not even have dreamed about? 

Was for something else. 

I haven't received an answer from the mapper about the item fell out issue yet.

With several demos and a couple of new screenshots for Hrimfaxi done, I decided to give Telefragged a go.

I didn't get very far yet because I have run into the following issue.

I loaded the map I think in 0.90.0 win32.
Developer 1 says 13 items fell out.
http://quaketastic.com/files/telefragged_itemfell1.jpg
I loaded the map in 090.0. win64, I believe.
This time there are 14 items dropping out.
http://quaketastic.com/files/telefragged_itemfell2.jpg
Then I decided to reload the map again.
http://quaketastic.com/files/telefragged_itemfell3.jpg
This time it's 15 items.
I honestly lost track with version I was running.

These screenshots seem to indicate it's not (only)
dependent on whether it's win32 or win64.

And I quote mfx here:

Strange
#344 posted by mfx [78.55.209.78] on 2016/01/24 22:48:06
i tested with recent versions now and have even more item dropout.  

I'll do some more revisions once I get the time.

I've got the files in the cloud now so shouldn't be as bottlenecked as before. 

I've got the files in my butt now so shouldn't be as bottlenecked as before.

I love the web 2.0. 

This is the headline for you:

http://www.reuters.com/article/us-health-genomics-cloud-insight-idUSKBN0OL0BG20150605 

I love the diciplinarian rigidity of an efficient system that adheres to pre-defined rules 2.0 

Dirtmapping is slooooow in this map :)

Vis took 10 minutes.

I've fixed all the b0rkage I should have done last time in the bsp along with less obvious technical issues like lack of vis blocking and gameplay logic problems (yes the pipe that blows up).

I didn't get any items dropping. Could this be a framerate issue? The mod loads all items on map load and if there's not enough memory allocated then maybe some stuff gets lost. Just a blind guess. 

I was thinking a patch plus a new download:

rrp_v1.1.zip
rrp_patchv1.1.zip

With it implicit that the first release was v1.0.

Both of the above would include the link to the current engine change in the readme, and the telefragged bsp, lit and map files.

Updating the devkit alone seems like overkill for just one file, even if it is a fairly complex one.

Sound good? 

Now lots of item dropping 0_o 

But I don't get all the ones in the screenshots - those same errant 3 seem caused by something else.

Will see if I can narrow down the issue. 

can't release update without inclusion of additional bonus maps by Sock and Scampie


Standards are changing. 

You're up! 

Sounds great. I can test it before release if you want, just shoot me an email.

Also, I don't know if this is useful but DarkPlaces reports more items falling out in telefragged, like 24-25. I'm guessing it's due to Darkplaces' different handling of rotated bounding boxes than Fitzquake family engines, and a lot of the pickups are rotated. 

That was the issue I alluded to before of engine fixing the fix - I redid the ammo bsp's with their centre corrected, and DP has a gameplay fix for that as well. So I suspect it may be offsetting some ammo boxes a further 16,16 units and therefore just enough for them to drop out.

The dumb bugs are fixed and I fixed some of the vis blocking. Unfortunately there's no fix for poor layout without rebuilding large sections of the map (the main hub and conncetors) so the wpolys still get up to 10k from certain angles, possibly 11k from very specific viewpoints.

Nevertheless it's improved by a few cheesy blockers and walls scattered around to break the LOS.

A HOM also appeared which wasn't there before, but there are several offgrid errors being reported so I need to chase down the suspect brushes.

It may be that these errors didn't bother the older version of the compilers (from 2014!) but the newer ones HOM the dodgy brushwork.

I'll knock out one more compile (10mins vis, 40 light) and send it over if its not too badly broken - thanks :) 

Worse yet, it crashed my game of Darkest Dungeon, just when thing were going well D;

It's late, time for sleep.