Most maps are at the preset limit. But it can be expanded by changing 2 files. 1 is located in the base.fgd. Top line mapsize. That is the hammer grid size. the other is a little more complex. It's worldsize..... forget the file type. I think it is worldsize.s that sets the playable area of maps in game and would have to be changed by a developer. As it normally gets compiled. So you can make bigger maps with changing the base.fdg But empiresmod will only load a bigger map it you change the worldsize. Or inject a modded worldsize file.
bigger maps... hmm... wait.. I duno... this is good and bad. Maps are already absurdly large in file size... bigger maps would be impossible to share via upload servers during live play and expect people to not say... fuck it.
Yeah the only sensible way would be like gmod and have them on workshop. But Empire don't have workshop. Or have server map packs that have been requested for years. Seriously why do we still not have map packs ?
Empires needs a workshop so we can mod... the mod easy OR I can just bring back the empires mod manager.
Because no one wants to put the time and effort into doing it? People have tried, and people have failed. Numerous times, in fact.
I duno... there were a few map packs done before... and I thought they were great. We should all have copies of most of the standard rotation maps and some specials by now. Any one of us could wrap that shit up into individual packs to share with the new ppl. Drop box is your friend.
Shouldn't be to hard for the servers to do map packs. Just copy all the maps from the download servers to github. Easy fix so that people don't need to wait 10 mins to download a map while playing.
I am fairly sure that it's not even close to being as simple as you said to increase the maximum mapsize. I've always been told it's a hardcoded thing that can only be changed with direct engine access. No. Why? I see nothing wrong with my previous post.
Multiple maps are sitting and a single map is sitting. You can't just combine the past tense of "to sit" with the present of "to be" like that. Perhaps you meant to say are/is set?
He is using passive voice which is constructed by the subject (maps/map in our case) + finite form of to be (are/is) + Past Participle of "to sit" (sat). maps + are + sat --> maps are sat.
It has been done before. But yes there are a lot of other things that would need to be done. Slightly bigger with a few people = not a problem. 1.5x or bigger with full server = problems. Evey time it's been done in the past it was the increased data transmitted that made it not worth converting to bigger maps in other mods. Not sure if that would be different with the changes to source in the past few years or not.
Wrong again! Map/maps is indeed the subject here, but it is not the patient, it is the actor! Because the sentence is about something that the subject does and not about something done to the subject, Trickster cannot be using the passive voice in this context, so he must be using the active voice here!
I'm English. The rest of you are not English. This is my language, whatever I say is correct. so go fuk urselfs. No seriously, I'm like 99% sure that the maps cannot be any bigger without engine access. I remember speaking with the Nuclear Dawn developers and they had to use engine access to increase it. It's nothing to do with limits of what's possible, it's just an arbitrary size set by valve that can only be changed within the engine. I mean, I'd love for someone to prove me wrong but I'm honestly like 99.999% sure that it can't be changed without direct engine access.
I just want to add that if you want to compile the map with static prop lighting then deleting the broken cubemaps and rebuilding them messes up the offsets for the static prop lighting data (which are also in the pak lump) . This causes static props to revert back to point lighting... The workaround I found was this: 1). Compile the map with normal vBSP, normal vVIS and fast vRAD, 2). Fix the cubemaps as before, 3). Then do the final vrad compile on the bsp with fixed cubemaps with the -final -staticproplighting -staticproppolys (I think it overwrites the lighting data from the fast compile, would need confirming though)..... That way you can have cubemaps AND static prop lighting. :D (of course the easier thing to do is to just leave the black cubemaps in as most people don't notice the absence of working cubemaps anyway) TLDR: cubemaps just got even more difficult to build....
