Comments - Mc$core

It looks like the mod itself is fine, just the installer needs a modification. I installed the mod via Windows, then Killer App Mod v1.1a works in proton without any specific issues.

To put it short: No, I probably won't do so.
Right now this project has a variety of issues making the whole workflow cumbersome and error-prone. :( For the unlikely case I find time to improve the basic functionality, I surely can add commands which run the map compiler and the game after map generation. Right now, putting effort in the ease of use (with the actual use being close to zero) just makes no sense.

Hi there again. Sorry it took me so long to respond. I am still pretty tied up in work. I hope to find time to work on this in during the winter holidays.
1) Texture tiling is not necessary. Texture translation does not work reliable in general. The tiling made it better in some circumstances, but I absolutely believe it can produce problems at other ends. I'll dike it out. I am not sure if the compiler will like infinitively huge offsets, though.
2) I'd like to investigate this problem further. The dead project mentioned above had the same issue. As of today, I never ran into it myself. I am eager to try it with your projekt, however, the provided link expired. I'll be in touch with you.
3) I added such a feature already, but I forgot to update the README in the archive. My bad. The paragraph reads as follows:
Tile Naming Convention:
The files may utilize prefixes to define their contents:
"start" marks the tile to be a start (saferoom or open area).
"finale" marks the tile to be the final (rescue or saferoom) tile.
"once" marks the tile to be inlcuded only once (if at all, for crescendo events or special tiles)
"10_" or any other integer followed by an underscore to increase the likelihood of this tile to occur (for repetitive standard tiles).

Use the big download button above Moddb.com or visit my site Hehoe.de

I also looked into the issue of the generator not being random enough and very picky. Actually, I forgot to remove some lines I addeed for debugging. They interfered with the tile selection. Also, especially due to the new "more linear" placement, it is quite possible for the generation to fail. If you are unlucky and the first three tiles are placed in a loop with no portals left, no more tiles can be added. This actually happens more often than I expected (as said, an recursively retrying implementation is pending).

Your encouraging words tricked me into spending another hour on this project. It's good to hear someone is actually toying with (and creating tiles for!) this. :)

I added more detailed instructions for python and numpy. Sorry for the inconvenience.

I changed the tile chooser so the level becomes more linear. Dead ends are still possible (and will be until I implement a recursive and deterministic approach). However, it now is rather unlikely to have more than one tile leading to a dead end.

Your idea for probability prefixes is good. I added a feature to put a tile in the pool more than once to increase it's likelihood to be chosen. Additionally, I added a flag for a tile to be added only once (for big tiles with crescendo events and alike).

The nav_generate issue is one problem that made me abandon this project. I wanted my server to create a random map every week. At some point I found out, the creation of the navigation mandatorily needs user interaction because the crosshair position is only updated by keystrokes, not by scripts. More annoying, the process involves the game client. Almost impossible to achieve this fully automated on a server that has not even a graphic output. :(

Thank you for your appreciating thoughts. :) Sorry I did not reply to your comments at once (in case there is a subscribe button somewhere, I haven't found it yet). I'll try to look into the problems you describe (the generation not being random, not accepting less/more/custom tiles). I am busy with my actual work, but I am not really "gone". Unfortunately I also cannot see that I will "come back" to this project anytime soon. :(

Indeed, the map tiles I supplied are in no way realistic or rich in atmosphere. For this reason I call the project development to be a "proof of concept", not a finished program. Still, I object to your attitude towards generated content. Generated content might not work for Counter Strike as it is a tactic shooter. In Left 4 Dead you are more concentrated on running for your life rather than finding a good spot for an ambush. Take a close look to the existing campaigns. In most cases, you basically move from one building to another. Consequently, a map tile should contain an entire building rather than a single room. The generator then builds a building block you have to find your way out. In my opinion, the fact you don't know where you need to go supports the realistic aspect of Left 4 Dead.
I don't think Hammer is easy to use for everyone. Especially if you want to design maps as large as needed for Left 4 Dead, you need much time to place details. I hoped I somehow could make this effort reusable. The binary BSP map format is rather complicated compared to VMF and hard to edit. Consequently, circumventing the use of the SDK and the map compiler would be incredibly tedious.

Added a more detailed description and commented the code. Happy hacking!

I hope I'll find time to comment the code properly and write a decent description. Until then, feel free to ask me specific questions. I gave a detailed description of how it works here (in german): Thewall.de