MOH .bsp to MOH .map
Moderator: Moderators
MOH .bsp to MOH .map
hey i know of this program called mohbsptomohmap or somthin and u can take bsp files and change them into (guess what...) map files. so i wanna try to modify original maps and i cant find the original map files so i was gonna try to use this, but when i run it and look at it in the editor everything is WIERD. like for a simple brush there are 6 different brushes that make up it. any clues??? thx
-
[ARGW] Tenebris
- Corporal
- Posts: 43
- Joined: Tue Apr 20, 2004 3:58 am
- Location: Buenos Aires, Argentina
- Contact:
Well, if the guys at EA were so generous as to make the mapping engine of the game a free distribution tool and, even so, they didn't provide .map files for the stock maps, there's got to be a reason... Don't forget there's copyright laws involved...
Anyway... I haven't seen a succesfull .bsp to .map convertion yet... And I don't think that's really possible... At least, not "flawlessly", since the natural process (.map to .bsp) eliminates or re-accomodates lots of structures that aren't really necesary... That's what I understand, at least...
If you insist in converting original stock .bsp to .map you'll have to deal with all those errors and correct them yourself... And it's gonna take lots of time... In mi opinion, it would be faster if you just try to remake the stock maps from scratch...
Believe me... I tried when I accidentally deleted a map I was working on, and I was left with the .bsp only (I know.... I can get so stupid sometimes...) I ended up starting all over again, since every attempt to go back from the .bsp resulted in a mess beyond posible repair (at least, not without ending up shooting myself in the middle of a nervous breakdown... But there's been people with enough patience to pull it off... Just don't expect a perfect .bsp to .map convertion, cause that's not gonna happen...)
Anyway... I haven't seen a succesfull .bsp to .map convertion yet... And I don't think that's really possible... At least, not "flawlessly", since the natural process (.map to .bsp) eliminates or re-accomodates lots of structures that aren't really necesary... That's what I understand, at least...
If you insist in converting original stock .bsp to .map you'll have to deal with all those errors and correct them yourself... And it's gonna take lots of time... In mi opinion, it would be faster if you just try to remake the stock maps from scratch...
Believe me... I tried when I accidentally deleted a map I was working on, and I was left with the .bsp only (I know.... I can get so stupid sometimes...) I ended up starting all over again, since every attempt to go back from the .bsp resulted in a mess beyond posible repair (at least, not without ending up shooting myself in the middle of a nervous breakdown... But there's been people with enough patience to pull it off... Just don't expect a perfect .bsp to .map convertion, cause that's not gonna happen...)
decompiler
Decompilers are used, mainly, to study the bsp and learn how things were done. It would take longer to repair a decompiled map, than it would to recreate it form scratch. If you are determined to do it, copy a few brushes at a time to a new map.
Tom Trude,
The problem is all 'brush' data is lost in a .bsp, there is no such thing in a .bsp, everything is a face. So there is no way to tell what faces are part of a single brush so all faces are now a brush. So typically each orignal brush is now 6. Also any caulked and cliped surfaces are lost. So pretty much even if you get the brushes back to normal you'd practically have to retexture everything. Most static models are lost and any texture data like scales shifts. You'd have to retexture a lot of stuff. Any triggers are now a textureless box as there is no real data defining the shape of it 
.
Modifiy these stock maps be decompiling is a VERY bad idea in short. Anything should be added via script.
Now with the AA sdk you do get the source for m4l1 I believe and with the SH sdk you get t2l1 and MP_Berlin_TOW so you'd have to stick with those...
Sorry...
.Modifiy these stock maps be decompiling is a VERY bad idea in short. Anything should be added via script.
Now with the AA sdk you do get the source for m4l1 I believe and with the SH sdk you get t2l1 and MP_Berlin_TOW so you'd have to stick with those...
Sorry...
-
Kentaro-K.21
- Lance Corporal
- Posts: 20
- Joined: Wed Jul 17, 2002 3:14 pm
- Location: Japan
about trigger_xxx
hi.
as far as i remember, trigger and some kinds of brushes are vanished when .map is compiled in .bsp file.
although their brushs lack, valid bounding box, that enclosing all brushes in the model, still exists.
therefore i coded so that the tool extracts the bounding box as a single trigger brush.
and, anyone needs source code set of mohbsp2mohmap? it's written in VC6 C++ with MFC (however core codes are very dirty and much obsoleted).
i don't have to keep that source because i'm not interested in mohaa and quake engine things now.
as far as i remember, trigger and some kinds of brushes are vanished when .map is compiled in .bsp file.
although their brushs lack, valid bounding box, that enclosing all brushes in the model, still exists.
therefore i coded so that the tool extracts the bounding box as a single trigger brush.
and, anyone needs source code set of mohbsp2mohmap? it's written in VC6 C++ with MFC (however core codes are very dirty and much obsoleted).
i don't have to keep that source because i'm not interested in mohaa and quake engine things now.
Kentaro-K.21
Kentaro-K.21 - If you have a better decompiler, can you please send it to me or upload it to the internet somewhere for download? I wouldn't know what to do with the source code for it, but a better decompiler would benifit everyone.
Tom Trude,
-
Kentaro-K.21
- Lance Corporal
- Posts: 20
- Joined: Wed Jul 17, 2002 3:14 pm
- Location: Japan
hi.
to tltrude:
i agree with your intension; better one would benefit everyone. so i'll update it *someday*.
i merely upload the latest files "as is" for now, because recently i don't have enough spare time to improve it.
homepage3.nifty.com/kkdf/MohBSPToMohMAP-0.0.1.400-src.rar
homepage3.nifty.com/kkdf/MohBSPToMohMAP-0.0.1.400-win32.rar
although i had published ver 0.0.1.400 in Sep 2002 in japan, i confirmed fileplanet hosts the prior version 0.0.1.350 (i don't register it myself).
latest version has experimental capacity to decode texture paraemters (offset x, offset y, angle, scale x, scale y) for extracted brush (still undecoded for texture params of patch mesh and LOD terrain map).
about condition of conversion process from bsp to map, i agree with Tenebris, tltrude, and blue60007.
there is no known good idea to recover the map from bsp file.
if you succeed to decompile and get the map file by any chance, it is merely useful to know the knowledges included in map. it is not easy work to recover the original map or tweak the existing map with your ideas.
at most i can do by coding the conversion tool is converting faces to brushes (and entites/static decals) and reduce some of unnecessary brushes.
if you have any good idea or advices to improve the decompiler, plz post it here. i or other decompiler author may realize your idea in the future.
to tltrude:
i agree with your intension; better one would benefit everyone. so i'll update it *someday*.
i merely upload the latest files "as is" for now, because recently i don't have enough spare time to improve it.
homepage3.nifty.com/kkdf/MohBSPToMohMAP-0.0.1.400-src.rar
homepage3.nifty.com/kkdf/MohBSPToMohMAP-0.0.1.400-win32.rar
although i had published ver 0.0.1.400 in Sep 2002 in japan, i confirmed fileplanet hosts the prior version 0.0.1.350 (i don't register it myself).
latest version has experimental capacity to decode texture paraemters (offset x, offset y, angle, scale x, scale y) for extracted brush (still undecoded for texture params of patch mesh and LOD terrain map).
about condition of conversion process from bsp to map, i agree with Tenebris, tltrude, and blue60007.
there is no known good idea to recover the map from bsp file.
if you succeed to decompile and get the map file by any chance, it is merely useful to know the knowledges included in map. it is not easy work to recover the original map or tweak the existing map with your ideas.
at most i can do by coding the conversion tool is converting faces to brushes (and entites/static decals) and reduce some of unnecessary brushes.
if you have any good idea or advices to improve the decompiler, plz post it here. i or other decompiler author may realize your idea in the future.
improvements
As you say, the main reason for using a decompiler is to study the map. The only improvement I can think of would be to the preview screen. It is not really needed and it might be better to replace it with statistics of the newly created map--number of brushes, number of entities, file size, number of duplicate planes, etc...
Of course, if you could make it get rid of "duplicate planes" and "evil polys" too, that would be super! We use the Roque plugins to do that now and it take a long time. So, if you add that, make it an option--not automattic.
Thanks for the update.
Of course, if you could make it get rid of "duplicate planes" and "evil polys" too, that would be super! We use the Roque plugins to do that now and it take a long time. So, if you add that, make it an option--not automattic.
Thanks for the update.
Tom Trude,
-
Kentaro-K.21
- Lance Corporal
- Posts: 20
- Joined: Wed Jul 17, 2002 3:14 pm
- Location: Japan
thanks for your suggestions
hi.
to tltrude:
thanks, i'll attach the statistics you points, and remove the preview in next release.
and, i'm interested in "Roque plugins". i have never heard about it, i guess it will normalize the redundant map file generated by decompiler, i don't know the actual effect. would you tell me a little more about Roque plugins?
to blue60007:
thanks for your report!
and that slider means Thread Priority of worker thread.
it does not affect to quality of decompiled map file at all.
i'll remove it due to meaningless in next release.
i recommend you fix the slider at most left. this will pass the cpu time to another application if cpu load is high.
to tltrude:
thanks, i'll attach the statistics you points, and remove the preview in next release.
and, i'm interested in "Roque plugins". i have never heard about it, i guess it will normalize the redundant map file generated by decompiler, i don't know the actual effect. would you tell me a little more about Roque plugins?
to blue60007:
thanks for your report!
and that slider means Thread Priority of worker thread.
it does not affect to quality of decompiled map file at all.
i'll remove it due to meaningless in next release.
i recommend you fix the slider at most left. this will pass the cpu time to another application if cpu load is high.