Quake 2 Valve220 breaks when editing and saving .map

[motorsep]

I have Quake 2 Valve220 map and every time I add something to it or modify anything on the map and then save it, it breaks the map file badly.

Does NetRadiant Custom even support loading/saving Quake 2 Valve220 maps ? Thanks

[Garux]

Yeah, it's supposed to work. Works here with a test map: What exactly gets broken for you? Any test map to reproduce? We've recently caught crash during writing a map with nearly infinite texture projection, which was borking a .map also. Here is wip build with it fixed: https://www.dropbox.com/s/uqq46o8grlrolu4/netradiant-custom-wip.7z?dl=1

Only problem i've noticed so far: surf/cont flags are not displayed correctly by surface inspector for the loaded v220 map, while modified in runtime are. Same is true for BP map.

[Garux]

Ok, found fix for the latter, but there is one more obscure problem. Flags are always written to .map with BP/220, even default ones. How does compiler handle this, when there is also texture with embedded flags applied?

Also why are we looking into this, are there Q2 mappers, using nrc? There might be need to have unset flags function to support compiler's way of handling to make flags thing usable properly.

[motorsep]

@Garux I am working on a project using Q2RTX - converting some of the best maps for Quake 1 into Quake 2 to be rebuilt for Q2RTX using qbism's q2tools (which recently got extended q2bsp format - QBSP, akin BSP2 for Quake 1).

Here is an example of one of the converted maps: https://www.youtube.com/watch?v=UBmeh5YrV68

I have that one map, spmaxx, which is Valve220 map. It got converted to Q2 .map format nicely and loads up into NetRadiant Custom just fine. However, of I change anything on it (like add a brush or adjust a brush or turn brush into detail/structural, etc.) and save it, it breaks. It breaks in a sense where some func entities "explode" with most of the brushes comprising it get moved outside of editor bounds. 4bsp compilers quits because of some "brush 1 - floating plane inverted normals" issue.

Note that if I compile that converted map right away, without loading it into NetRadiant, it compiles just fine (but leaks).

I am at work right now, but I can upload that map for you to try and see for yourself.

As for surfaces flags, it looks like I had mostly no issues with other maps (standard, non-Valve220 converted maps). It seemed that NRC loaded surface and content flags from .wal files perfectly fine for the most part (there were some rogue cases where some clip brushes had weird totally random surface/contents flags set). At least NRC doesn't corrupt the .map as Trenchbroom does when loading Quake 2 maps :P

P.S. as for other Q2 mappers, there is Nail & Crescent teams that might use NRC. Also with this new QBSP format and Q2RTX support added to it last night, perhaps we'll see more Q2 mappers coming around.

[Garux]

Right, it's would be logical to check with problematic map, as idk how such scary things can happen in general.

[motorsep]

@Garux There ya go: https://drive.google.com/file/d/1gunh6uFjKaDhXHV_7j9NJTFT3dzelspu/view?usp=sharing

Here is a video showing the issue: https://www.youtube.com/watch?v=76EwGk7Ep48

[Garux]

Well, very interesting. Nothing like that happens here after reproducing steps exactly. Resaved map file i'v got: sp_maxx.zip

[Garux]

Ah ok, was blind guess, but i ticked this option and reproduced the problem. Don't use it w/o knowing what it does really!

[motorsep]

I have no idea what that is - I didn't even bother with options. Probably it's checked by default ?

Yep, that did the trick. Thanks!

[Garux]

No, it's off by default and has no options to default it.

[Garux]

Should probably remove this snap option altogether, as it's only required for very ancient compilers, not supporting float input, and does not do any deep thinking, but just snaps to int.

As for flags issue, radiant was writing them unconditionally in BP, 220 formats, just like TB. Fixed: https://github.com/Garux/netradiant-custom/commit/b58408344c2684245594ecd461f0bcb4eee99ea3 Also added unset flags function: https://github.com/Garux/netradiant-custom/commit/8d71aea0595e08fc036c3578581d8704cffc1f4c build: https://www.dropbox.com/s/uqq46o8grlrolu4/netradiant-custom-wip.7z?dl=1

Flags editor is not very precise still, e.g.: -no newly set detail flag display, if flags are not specified (ok after map reloading, flags toggle) -making brush with .wal flags detail still displays the former, while only detail flag is there in fact (ok after map reloading, flags toggle) Detail logic is separate from flags, probably because it's wanted to be only applied to whole brush, this requires deep analysis to be resolved gracefully. Tell me, if there are more of problematic cases to consider.

[The-Gig]

Maybe, instead of completely removing the option, adding a note like "Dangerous. Only enable if you know what you are doing.", with a mouseover tip like "Required only for very old compilers. MIGHT BREAK YOUR MAP FILE." (text just for example, you can surely find better wording)?

[Garux]

There is no much space for text, by design it's just one line. Cool addition would be tooltips with extended descriptions, but nobody reads tooltips :) I think the way is to remove and see, if anybody still needs it, it's easy to revert removal. Option is quite crappy anyway, as planepoints are not necessarily in touch with winding points; snapping these may result in significant precision loss.

[The-Gig]

Then, just a "DANGEROUS"? (Otherwise, remove it..)

[motorsep]

@Garux Is there any chance to get new release binaries for Windows ? 😊

[Garux]

@motorsep i've linked fresh build above in the text

[motorsep]

@Garux Unfortunately nothing changed:

All I did was I changed texture on one side of a brush to "skip" and set flag to NODRAW. Saved the map, recompiled it and when I loaded the map, not only I see all the brushes that I shouldn't see, but also player spawned outside of the map :(

[Garux]

Need more concrete details on this, like 'i take this clip brush without flags, save, get brush with unwanted flags written', because i've just tested with the linked build + your .map, and it operates with flags as expected.

[motorsep]

ugh, it might be damn qbism tools ruining it :( I'll do more tests with different build first.

[motorsep]

Yep, damn tools are messing up the map/bsp. Sorry @Garux , I can't even test this build of NRC without being able to compile the map :(

[motorsep]

@Garux alright, it was indeed an issue with 4bsp and now that it's fixed, I can confirm that so far that build of NRC (above) works fine. I opened the map, did some changes (assigned texture, flagged it as nodraw/mist), saved the map, compiled it and it looks as expected. Haven't done extensive testing though.

[motorsep]

There ya go, the result (I was fixing vine brushes):

https://www.youtube.com/watch?v=VmaaTgbatiY

[RazielZnot]

Should probably remove this snap option altogether, as it's only required for very ancient compilers, not supporting float input, and does not do any deep thinking, but just snaps to int.

Don't do this. I use it very often exactly for the sake of backward compatibility with old compilers and editors.

[Garux]

Aww, so do they fail to read .map file with planepoints in float? Commonly used atoi function seems to work: https://godbolt.org/z/KfqceK3q7