Also there's nothing stopping the rivals from just repacking them. The trick with the lump file works because - correct me if i'm wrong - it never gets downloaded to the client.
Another community has been stealing my community's official map
- Thread starter AwesomeX
- Start date
True, Sword. Any file that you make your clients download will be available to the thief, and if they are using an automatic packing program, they only need to point it in the direction of their download folder.
It's very important that the lump file be stored on the game server only, and not on the FastDL server. It's unlikely the file would automatically be downloaded by the client if it were placed on FastDL without the use of a .res file, but some SourceMod plugins might add it to the download queue, and FastDL servers are not normally secure, meaning anyone can usually browse them with a web browser. Game server folders aren't public.
It's very important that the lump file be stored on the game server only, and not on the FastDL server. It's unlikely the file would automatically be downloaded by the client if it were placed on FastDL without the use of a .res file, but some SourceMod plugins might add it to the download queue, and FastDL servers are not normally secure, meaning anyone can usually browse them with a web browser. Game server folders aren't public.
All I think is that you could send Valve's VAC ban human resources to black list the community, the ip, anyone involved and lock your map download, as someone mentioned earlier: the cost wouldn't be justified to take legal action, but there is some nasty things you can do.
Valve does not care if someone takes your map. They will not ban or blacklist the server
- Aug 7, 2014
- 1,241
- 1,025
Leminnes
aa
- Jan 20, 2010
- 1,317
- 902
I'm sorry those guys are being dicks about it. I do agree with some people that ignoring them is a good policy in some respects just to get them to stop bothering you but not get them to stop stealing your map. The lump solution should help with that. Good luck bud!
I'm a bit late to this, awesomeX, but yeah, I know your map.
Other communities steal it as well, not just the one.
in fact, I came across a server where the owner took a rather large chunk of your map and slapped it onto his own. He removed any decals giving credit to you and put only his credits on the spawn room walls. He used other maps as well. I told him that this was not the nicest of things and that the very least he could do was give credit, so I got banned.
unfortunately there really is no way around this. Neonheights has had the same problem for the past 3 years as well.
Other communities steal it as well, not just the one.
in fact, I came across a server where the owner took a rather large chunk of your map and slapped it onto his own. He removed any decals giving credit to you and put only his credits on the spawn room walls. He used other maps as well. I told him that this was not the nicest of things and that the very least he could do was give credit, so I got banned.
unfortunately there really is no way around this. Neonheights has had the same problem for the past 3 years as well.
- Jan 26, 2014
- 15
- 1
I've finished my map update, and have been trying to get the .lmp or lump method to work.
I've compiled my map normally with all the ents and what not like normal. Then I moved that map to a separate location "my desktop"
And then I compiled another version with the VisGroup "Point Entities" disabled.
I extracted "MAPNAME"_l_0.lmp from the full compile, and moved that into my maps folder, alongside the stripped down map version.
However, when I try launching the stripped map on a local server, It doesn't seem to read the .lmp at all, thus having the map become broken.
I compiled both versions of the map with VVIS and VRAD set to normal. Help would be great.
I've compiled my map normally with all the ents and what not like normal. Then I moved that map to a separate location "my desktop"
And then I compiled another version with the VisGroup "Point Entities" disabled.
I extracted "MAPNAME"_l_0.lmp from the full compile, and moved that into my maps folder, alongside the stripped down map version.
However, when I try launching the stripped map on a local server, It doesn't seem to read the .lmp at all, thus having the map become broken.
I compiled both versions of the map with VVIS and VRAD set to normal. Help would be great.
- Jan 26, 2014
- 15
- 1
I just tried a few different things. Like compiling the stripped map with -noents and tried using that with the lump. But it still doesn't work.
Also, I have a question about disabling the VisGroup "Point Entites", whenever I click it, it also disables other VisGroups, like lights and props, I believe that's what I want, but I need to double check.
Edit*
I also read through some of this - https://developer.valvesoftware.com/wiki/Patching_levels_with_lump_files
But I just can't get it to work.. I even tried it on my official server, and, nothing..
Edit*
If there's someone here who's done this before, it'd be great if you could post what steps you did to get it working properly. All I can think of is it must be something with my compile options.
Also, I have a question about disabling the VisGroup "Point Entites", whenever I click it, it also disables other VisGroups, like lights and props, I believe that's what I want, but I need to double check.
Edit*
I also read through some of this - https://developer.valvesoftware.com/wiki/Patching_levels_with_lump_files
But I just can't get it to work.. I even tried it on my official server, and, nothing..
Edit*
If there's someone here who's done this before, it'd be great if you could post what steps you did to get it working properly. All I can think of is it must be something with my compile options.
Last edited:
Don't worry about lighting, it's baked in to the map. Only dynamic lights are stored in the entity lump. You can add entities to your own custom visgroups if you need to enable them separately.
You don't need to compile the map fully a second time, you can use -onlyents -keepstalezip in the VBSP line in Hammer's advanced compile interface and disable VRAD and VVIS. That means you can disable absolutely everything in the map and it won't matter, because only the entity data lump will be affected. You can stop the console message about there being a stale zip by removing the stale.txt file from the bsp using VIDE, but it's safe to ignore it. Make a backup of your full compiled map before you change its entity data, so you can extract the lump file later.
In your shell map you want to aim to have your entity lump file mostly empty. You'll still have some information about the map itself:
Notepad++ shows .lmp files in a readable form.
I've experimented and have found that TF2 does not seem to be loading the entity data from my extracted lump file. I have tested on a listen server (game client) and a dedicated server (SRCDS), with the .lmp file in maps and maps/lumps.
However, you can load your entity data using the Metamod:Source plugin Stripper:Source. You can use the contents of the lump file from your backup or you can use Stripper's dump command in the server console to make a text file from the entity data of your backup map. Put Add: at the beginning of the file and save it as <mapname>.cfg in addons/stripper/maps.
This works very well.
Note that entity lumps contain all the entity data about brush models (dynamic brushes) but they don't contain information about the brush itself, e.g. its shape, size, coordinates, textures. However, these dead brush models won't show up in the shell map without entity data, and won't appear in a decompiled VMF! It's fucking fantastic.
But be cautious as before, if anyone gets their hands on your Stripper config, they will probably be able to restore the map.
SHELL MAAAAAAAAP!
You don't need to compile the map fully a second time, you can use -onlyents -keepstalezip in the VBSP line in Hammer's advanced compile interface and disable VRAD and VVIS. That means you can disable absolutely everything in the map and it won't matter, because only the entity data lump will be affected. You can stop the console message about there being a stale zip by removing the stale.txt file from the bsp using VIDE, but it's safe to ignore it. Make a backup of your full compiled map before you change its entity data, so you can extract the lump file later.
In your shell map you want to aim to have your entity lump file mostly empty. You'll still have some information about the map itself:
Notepad++ shows .lmp files in a readable form.
I've experimented and have found that TF2 does not seem to be loading the entity data from my extracted lump file. I have tested on a listen server (game client) and a dedicated server (SRCDS), with the .lmp file in maps and maps/lumps.
However, you can load your entity data using the Metamod:Source plugin Stripper:Source. You can use the contents of the lump file from your backup or you can use Stripper's dump command in the server console to make a text file from the entity data of your backup map. Put Add: at the beginning of the file and save it as <mapname>.cfg in addons/stripper/maps.
This works very well.
Note that entity lumps contain all the entity data about brush models (dynamic brushes) but they don't contain information about the brush itself, e.g. its shape, size, coordinates, textures. However, these dead brush models won't show up in the shell map without entity data, and won't appear in a decompiled VMF! It's fucking fantastic.
But be cautious as before, if anyone gets their hands on your Stripper config, they will probably be able to restore the map.
SHELL MAAAAAAAAP!
- Jan 26, 2014
- 15
- 1
Alright so.. I tried using Stripper Source as you suggested. I got the latest linux snapshot installed, and have confirmed it's installed properly. I then took the lump file from my full compiled map, and tried using that in a Stripper config file, "and yes I added "add:" to the start of it" and when I restart my server, it doesn't start, it just seems to hang.
I tried putting the full compiled map on the server, and went into it to get a Stripper dump file, and that went alright. Shut the server down and put the empty map back in, and edited the Stripper map config and used the Stripper dump from the full map compile and again, yes I added "add:" to the start.
The server started up, I was pretty hopeful... Then I saw that it didn't do anything, it was just the empty shell map.
I'm starting to lose hair, lol.
I tried putting the full compiled map on the server, and went into it to get a Stripper dump file, and that went alright. Shut the server down and put the empty map back in, and edited the Stripper map config and used the Stripper dump from the full map compile and again, yes I added "add:" to the start.
The server started up, I was pretty hopeful... Then I saw that it didn't do anything, it was just the empty shell map.
I'm starting to lose hair, lol.
Last edited:
Update.
When I did an -entsonly compile on my deathrun map, I had hidden everything in Hammer, and the lump file 0 changed to reflect that, going down to about 230 bytes (it only contained the worldspawn entity, which is the map itself). But when AwesomeX did the same the lump file in his map didn't change. He was able to get it working by enabling everything in the map then just hiding the Entities visgroup. That compiled the new lump file and he was able to copy its contents in to a Stripper config, removing the header and footer special characters. Unfortunately I found that Stripper's dump output is unsuitable for use as a config because it puts ending and starting curly braces on the same line (though you could fix that with an advanced text editor and a find & replace).
The problem was, prop_statics weren't showing up in the map, which is weird because those aren't kept in lump 0. It seems that -entsonly compiles affect more than just that lump file. So this time he enabled prop_statics, compiled, converted to a Stripper config and it's working fine.
I was searching for tools to strip out entity data from a BSP. VIDE lets you import a lump file (so for example a recompiled data lump with no entities inside it) but it can't successfully save the BSP. It lets you delete entities but only one at a time, which is a bit tedious.
I found a link to a Java app made by asherkin of AlliedMods, named Bulwark, designed to strip out entity data from a BSP, but it seems to be Java source code and I'm not familiar with compiling apps. I think something like that would be the cleanest way to remove entity data from a map, considering how prop_static was affected. But hiding all entities except prop_static seems to have done the job, it's just more work.
It's a shame TF2 doesn't want to load lump data. Perhaps it was disabled because of security concerns?
When I did an -entsonly compile on my deathrun map, I had hidden everything in Hammer, and the lump file 0 changed to reflect that, going down to about 230 bytes (it only contained the worldspawn entity, which is the map itself). But when AwesomeX did the same the lump file in his map didn't change. He was able to get it working by enabling everything in the map then just hiding the Entities visgroup. That compiled the new lump file and he was able to copy its contents in to a Stripper config, removing the header and footer special characters. Unfortunately I found that Stripper's dump output is unsuitable for use as a config because it puts ending and starting curly braces on the same line (though you could fix that with an advanced text editor and a find & replace).
The problem was, prop_statics weren't showing up in the map, which is weird because those aren't kept in lump 0. It seems that -entsonly compiles affect more than just that lump file. So this time he enabled prop_statics, compiled, converted to a Stripper config and it's working fine.
I was searching for tools to strip out entity data from a BSP. VIDE lets you import a lump file (so for example a recompiled data lump with no entities inside it) but it can't successfully save the BSP. It lets you delete entities but only one at a time, which is a bit tedious.
I found a link to a Java app made by asherkin of AlliedMods, named Bulwark, designed to strip out entity data from a BSP, but it seems to be Java source code and I'm not familiar with compiling apps. I think something like that would be the cleanest way to remove entity data from a map, considering how prop_static was affected. But hiding all entities except prop_static seems to have done the job, it's just more work.
It's a shame TF2 doesn't want to load lump data. Perhaps it was disabled because of security concerns?
As i recall, Valve did update pl_upward once with .lmp file in order to fix an issue where RED were able to shoot grenades to the BLU starting spawn (looking from behind the cart, left side of it on top of the spawn) or then it was a case where sniper could shoot through a crack into the same area of the BLU base. Maps has been since recompiled many times, they just did an easy fix at that time.
So in theory, lumps should work unless Valve disabled them afterwards for some reason.
So in theory, lumps should work unless Valve disabled them afterwards for some reason.
Just remember to not remove internal point entities. (Which is exactly why prop_static messed up.)
- Jan 26, 2014
- 15
- 1
So I managed to get Stripper Source working with my map, so a lot of entities are spawned by Stripper at start.
However, it seems that now on the scoreboard, both player counts equal 0. No matter what, always 0.
I think this has to do with some entity that's on the map, or spawned dynamically, but I don't know which one handles player counts.
However, it seems that now on the scoreboard, both player counts equal 0. No matter what, always 0.
I think this has to do with some entity that's on the map, or spawned dynamically, but I don't know which one handles player counts.