FAQFAQ   Ban ListBan List   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
 NewsNews   DownloadsDownloads   Wiki & TutorialsWiki & Tutorials   IRC ChatIRC Chat 

logic portals help
Goto page Previous  1, 2
 
Post new topic   Reply to topic    ThinkingWithPortals.com Forum Index -> General Discussion
View previous topic :: View next topic  
Author Message
Hober

That's Sir Pompous Asshole


Joined: 13 Oct 2007
Posts: 850
Location: Raleigh, NC

PostPosted: Sun Nov 25, 2007 5:06 pm    Post subject: Reply with quote

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.

_________________
Back to top
View user's profile Send private message AIM Address
Korjagun
Test Supervisor


Joined: 08 Nov 2007
Posts: 120


PostPosted: Sun Nov 25, 2007 5:21 pm    Post subject: Reply with quote

youme wrote:
Sorry, I need some clarification there, so putting a map here: portal/portal/maps/TS13/ would have no cubemaps?


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.

_________________
Link, mah boi, this peace is what all true warriors strive for!
Back to top
View user's profile Send private message
Player1
Test Supervisor


Joined: 24 Oct 2007
Posts: 144


PostPosted: Sun Nov 25, 2007 6:57 pm    Post subject: Reply with quote

Hober wrote:
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.)


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.

Hober wrote:
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).


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.
Back to top
View user's profile Send private message
Hober

That's Sir Pompous Asshole


Joined: 13 Oct 2007
Posts: 850
Location: Raleigh, NC

PostPosted: Sun Nov 25, 2007 7:20 pm    Post subject: Reply with quote

Nazzo fast, guido.

Player1 wrote:
2) Maps work flawlessly when put in a subdirectory beneath maps.


Actually, the discussion in this thread is about how putting a map in a subdirectory beneath maps breaks its cubemaps.

Player1 wrote:
3) Relative path names work correctly in BNS and BSP alike.


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/.

Player1 wrote:
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).


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.

_________________
Back to top
View user's profile Send private message AIM Address
Player1
Test Supervisor


Joined: 24 Oct 2007
Posts: 144


PostPosted: Mon Nov 26, 2007 4:40 am    Post subject: Reply with quote

Hober wrote:
Actually, the discussion in this thread is about how putting a map in a subdirectory beneath maps breaks its cubemaps.


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).
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    ThinkingWithPortals.com Forum Index -> General Discussion All times are GMT - 5 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group