logic portals help
Wait, so what your saying is that custom maps using the bonus map script format can't have cubemaps?
I personnaly put the bonus script files in a subfolder and the maps in the main maps/ folder. It works that way.
Author of Minecraft mods (MAtmos, Minaptics, NoteSlider) and Garry's Mod addons (Gunstrumental, SharpeYe, GarryWare, DepthHUD).
Hmm i should try that, it seems to have worked for me though, yet it does look a bit off, on the reflections.
I gave it a quick try and I can confirm what Hurricane is saying; placing the map anywhere other than maps/ results in blank cubemaps, even if you generate them after moving the map.
Sorry, I need some clarification there, so putting a map here: portal/portal/maps/TS13/ would have no cubemaps?
I'm not sure about the cubemaps, but what I can confirm is that the .BMZ format forces you to have a flat directory structure, sort of.
See, everything in your BMZ, which can contain folders, is unzipped into a sub-folder of portal/portal/maps. For example, Hober.bmz would have all of its files and sub-folders unzipped (preserving directory structure in the zip) to portal/portal/maps/Hober/
This is why the Nov map pack didn't come in a .bmz flavor: people had stored some materials in portal/portal/materials/vgui and there is no way to put those files there by using a .bmz, as far as we know. (I have a dim hope that there is some way to tell the .bmz to extract into portal/portal/ instead of its place, but I have no reason or proof that exists.)
Also, I agree with msleeper, who said that the whole point of the .bmz was to keep the map and of its retinue in one file, like a miniature GCF. But if the BMZ's contents get dumped to your hard drive, that entire point is almost obliterated. And with how much trouble it seems to be to package a BMZ, I see no reason to use them. People have managed to use unzip utilities for many years now, and I think they'll manage with that (especially where the map designer provides documentation on how to unzip the file).
P.S. Can we get this thread renamed? There's a good dicussion going on, but it has nothing to do with logic portals.
That is correct, even after loading it in Source and running buildcubemaps. Upon reload, the cubemaps will not be properly loaded and it will appear as if there were no cubemaps in the first place.
Actually doing it the way they have implemented the BMZ is the only solid way of doing it, if you think about it, as long as the following holds:
1) Any texture (or other external asset) that you need for your map can be either placed in your own directory structure below your map directory (portal/portal/Hober/VGUI/ for example) or embedded in the BSP.
2) Maps work flawlessly when put in a subdirectory beneath maps.
3) Relative path names work correctly in BNS and BSP alike.
I'm unsure about item 1, since I don't build maps myself. Now currently it seems that item 2 is definately being called into question on the whole cubemaps thing. And I have my doubts about item 3.
But those are technical issues that I'm sure Valve will fix if somebody actually tries them out and concludes that they don't work as intended.
The whole point of extracting everything below portal/portal/maps/Bmzname/ is namespace. This way it's impossible for people to accidentally overwrite eachothers assets, unless they actually name the BMZ files the same. And even then I think that Portal actually autogenerates a unique dirname based on the BMZ name, yes?
Currently it's, to be quite honest, a pain to install and update maps as they're released. Everybody uses slightly different approaches. Some use zip, some rar, some base it on the portal dir, others on portal/portal. Some just put a bsp and a bns. Others just a bsp. Some put folders which have to be extracted to different directories (ie. no actual root dir).
It's a pain. And it shouldn't be necessary.
Whether or not Portal unzips the contents of the BMZ or just copies it and mounts it as a GCF style thing is fairly irrelevant to be honest.
As to "how much trouble it is to package a BMZ" I think you should remember that as you distribute something you do the trouble once if you do the BMZ whereas if you don't everybody who will be installing the map will be doing the trouble. So yes, less trouble for you, but more trouble over all. And especially more trouble for your "customers" which is what you don't want if you want people to play your maps.
Nazzo fast, guido.
Actually, the discussion in this thread is about how putting a map in a subdirectory beneath maps breaks its cubemaps.
In my discussions with Shmitz, to whose knowledge I must yield, I was informed that, if I remember correctly, the sound script file and BSP file had to be in the portal/portal/maps. Now, I'm not sure exactly what that means philosphically, but in practice, it meant that by moving the accident prone BSP file into any non-maps directory irreparably broke it. And given that this seemingly-phantom sound script file was not an actual file and could not be moved along with the BSP, the only way to keep the map working was to put the BSP into the maps folder.
I will concede this may be an artifact of not being built to be contained in a BMZ, but the point is that it was made this way because there was no other way to use relative pathnames. Shmitz, please correct me if I'm misusing your words here.
As for the namespace business, Portal will not overwrite folders written from identically named BMZs. For example, if you imported Hober.BMZ twice, you would end up with maps/Hober/ and maps/Hober01/.
In my opinion this is rhetorical hyperbole. Sure, some idiots mess it up. But by and large the file has a well-defined directory structure with instructions on where to put the file. The point about some people using .rars is, regrettably, true. Some people just don't realize that not everyone has WinRAR. But that's the mapper's problem. If the mapper's map is hard to install, he will have fewer people playing it. That's why almost without exception, all of the skilled mappers we have here take the time to make the job of the end-user as easy as possible.
At any rate, I think this argument is ultimately pointless. You are very much in favor of the use of BMZs, because they purport to be a great time-saver. I agree wholeheartedly with this view. However, in the 8 or 9 fruitless hours I spent trying to make a BMZ for the November map pack, I became thoroughly disenchanted with the entire concept.
It may be that maps can be built to work fine inside BMZs, but from my experience of trying to use them, a ZIP proved to a far simpler and more elegant solution, as odd as that sounds. I would dearly like to use BMZs for everything, but at this point I don't see it happening.
I may not have made it clear enough, but the list of 3 items was indeed items that do not seem to be currently satisfied but was a list of preconditions that need to be fulfilled before BMZ usage is practical.
But my post was mainly a defense of the "design" of the BMZ (ie. the whole "extract beneath portal/portal/maps/BMZname/" thing).