@qoLmE : I have had chat with Izuko in the past, most of his works are basic edits and entity changes - as such the original mapper remains the same, the editor however is still an important contributor for making it available in a different form
As it stands most of the mapping work is not merely work the architecture, certain maps benefit a lot from prefabs, custom textures and skyboxes but we can't fill them all out here, so those need to be mentioned in readme instead
@qoLmE: I think that if only the entities in the map were changed through a program like BSPGuy or BSPEdit, then this does not make you the author of the map
One can only speculate upon stumbling onto the word "remodeled" if any additional info is absent. The choice of phrasing is giving me similar vibes to when "remake" is being used, all due to the fact my mapping knowledge is at the same level as a priest's pole dancing skill
Nonetheless in cases like these it's almost always safe to assume that no changes at all were made to the architecture of a map, granting no credits to the person who did the job. Anyway, thanks to both of you for your insight on the matter.
How does porting actually work? Do you need the rmf for that ( to be able to open it in programs such as hammer )? You have to edit it anyhow to match the game's properties of the one you're making the port for.
Depends, porting from HL to CS or CS to HL is as easy as changing the entities of the map. I could do that via BSPEdit. It's even easier to convert a HL map for OP4 or vice versa due to many common entities.
When porting to a completely different game engine, you need to decompile map on one engine, edit it as necessary and recompile to other engine. In most cases this is a tedious task, generally a good mapper would just prefer recreating the map in new engine
Anyways deciding on a map author is a non-trivial task. There are also cases where someone who doesn't know how to map drafts a "floor plan" of the map on a piece of paper and someone who can map implements it. So creativity comes from one person and implementation from someone else
One single input field is not enough to convey all this info, but readme and proper tags searching mechanisms help. I like to see all maps that have Sock's egyptian textures regardless of who author is because those textures look really good as an example
@FIXXOR: So in case a decompile is done and only the needed functions/entities are changed to make it work in the destination game/module/... as ParaBolt just described, you would still agree to give authorship to the person who recompiled it? As this is, as you said, the one who compiles it.
@qoLmE not clue about the example given of porting from hl to cs, but I'm porting maps from source to goldsrc and the process is: decompile into vmf, open the vmf in jack, convert the source entities into their goldsrc equivalents, convert and reapply the textures, decompile and recompile the models, fix errors caused by the decompiler, optimize, then finally recompile for goldsrc
I like to argue that authorship goes to however compiled the map because each new compile is unique I think, you can get a mismatch if you recompile the same map a second time even without any changes, so the game seemingly recognizes each compilation as distinct
btw you can include any additional info you want about a map in a comment under it, since the search filter goes through all comments not just the readme
@FIXXOR: Thanks for the explanation. P.s.: While going through the byplt-maps, I came across this map and decided to give you credit for it. You'll probably agree with it, right?
I only edited the MaxRange on that one in the entity list, I'm technically the "creator" of that version of the map I guess, but it's pretty superfluous accreditation
in the message field of the game_text entity I left: "Mapped by Spoon & Chris | Infected-Servers.com | Edited to increase Max Range" (this text displays upon launching the map)
technically you can just edit the maxrange property and not even rename the map since it shouldn't cause a mismatch, so it's a useless edit for any savvy host
basically entity properties are decided by the entity configuration of the host, you can outright remove entities such as doors and breakables this way and play with someone who has the original version of the map, because removal in this context just means they won't load, they are still stored in the map file
in the case of the MaxRange property, this just tells the game at which distance from the player's pov the map should no longer be rendered, in-game it will vanishpast that point
@FIXXOR: Highly interesting stuff you're posting here. Good you kept the build-in screen message as reference to the "actual" mappers.
I didn't knew about max range being a setting that can be embedded in a bsp-file. Thought this was only server sided with the use of the cvar "sv_zmax".
17Buddies's website offers at this time 107 945 total uniques and verified maps including 59 063 HL1 maps, 45 579 HL2 maps and 3 303 CS:GO maps, representing 372,47 GB disk space.
There were today 377 maps downloads (607 yesterday) representing 1,47 GB transfered (2,34 GB yesterday).
This page was generated in 0.66 s and required 801 SQL queries.
