|
Post by giftmacher on May 18, 2015 9:26:16 GMT -5
I haven't played Phrantic in either game but it looks like a really fast-paced and tight map, much like aerowalk, not as circular I guess. I've never dueled in Q2, the little dueling I've done I did in QuakeLive, Q2 overall feels a bit off, I mostly like it for it's SinglePlayer and overall visuals I took a look and I like it, you've done the ground work, looks really solid gameplaywise and visually for a standard Q2 map. Since it is a popular map in several games I'm guessing everything regarding item placement etc is in place. LG -> CG is the way to go yes, It's the closest to a lighting gun Maybe some experienced Q2 dueler could have further insight? Of course how much you want to improve the visual quality of the map is up to you, some things to consider that I know is quite popular to do in Q2 1. Lower the spawnpoints by 10 units into the floor, they will no longer be visible but work all the same. (This might actually be important for gameplay too because you can stand on them and stuff) 2. The Q2 teleporter model is perhaps not the most breathtaking visually you could lower it 10 units as well and then put some fancier brush work ontop to symbolize a teleporter. (If you are going for the standard q2 look then keeping it isn't wrong either) Some resources to check out: 1. j-spot.backshooters.com/maps.html <- If you want ideas and inspiration for visual improvments, check this guy out, his work is amazing and he used Radiant as far as I know. 2. dfspspirit.wordpress.com/category/level-design/ <- another great Q2 mapper. Especially duel/DM maps. Also radiant user. 3. home.versatel.nl/djbloot/quake2/quake2maps.htm <- Pan's maps, many of them uses standard q2 textures, check out Rigor Mortis because I think the theme matches quite well with yours. Hope this helps!
|
|
|
Post by giftmacher on May 17, 2015 12:24:12 GMT -5
Aha! nicely done Thanks, I'm working on the map now, the puzzle map will be delayed, would like to optimize this map now... Edit: I see it, I will work on providing him with all the information he asked for (screenshots etc), will take an hour Edit: I see you copy the origin/angle numbers, would it not have the same effect to just tag the front face and then use "wrapping" to wrap the texture to the other faces? Tag i.imgur.com/5xKLFBA.jpgWrap i.imgur.com/lmbuQhA.jpgEdit: Some improvements already with the stuff you provided here margaal, down to 1711 brushes and no drop in detail... Edit: Yes you can delete the screens, I have done most of them now,
|
|
|
Post by giftmacher on May 17, 2015 10:41:36 GMT -5
Yes since it doesn't matter to make a solid hull apparently I can try and use the hull more and delete some walls and floors, in the first pictures that vertex manipulation I don't know how to do that. Explain please
|
|
|
Post by giftmacher on May 17, 2015 5:15:53 GMT -5
Yes because I've used various approaches, some good, some bad, but all of them hit the limit around the same amount. A good mapping approach should award more than just 50 brushes (solid or detail, doesn't matter) compared to a crappy and careless one, I've used both! Edit: I posted on the Quark forum now Margaal, hopefully there will be some answers -> quark.sourceforge.net/forums/index.php?topic=1072.0
|
|
|
Post by giftmacher on May 17, 2015 4:56:24 GMT -5
Yes I've downloaded your compilers but first I'll try and hit the limit with these I got with Gtkradiant, then I'll try yours.
Edit: Yes should be more organized, it would be great to have a F.A.Q or a sticky thread with clean answers to all the questions asked throughout the years.
Edit: Ok hit the limit at 1779 with these compilers.
Edit: Same with the ones you provided there Margaal, crash at 1779.
That's a shame!
|
|
|
Post by giftmacher on May 17, 2015 4:04:05 GMT -5
Yes maybe it got lost throughout the years, that information, I searched for it or anything regarding "too many surfaces" error and didn't find much. I will see how many brushes I can add, if it's just 30-100 then it is not worth it and the problem is more complex.
|
|
|
Post by giftmacher on May 16, 2015 15:58:43 GMT -5
Ok good to know about func_wall / func_group, got it. I did as you said and switched the compilers and it granted me some interesting results, as follows -> Quark with standard compilers qbsp3.exe arghrad.exe timvis3.exe 1755 brushes (according to .map file) = Error too many surfaces 1754 brushes (-1 brush) = Works -------------------------------------------------------------------------------------------- Quark with Gtkradiant compilers (Or well, the ones I got when downloading Gtkradiant 1.6) Qbsp3.exe (same as above but this is the .exe I got with radiant, so different file) Qrad3.exe Qvis3.exe [Errors] 1. Two leaks needed repairing. 2. Some texture and brush mis-alignment 3. Map is full bright, even with full compile 1754 brushes = Works - I added 5 square cube brushes - 1760 brushes = Works (!) -------------------------------------------------------------------------------------------- Finally to fix the lighting (I guess Qrad3 is for Q3? I'm a newb for gods sake Qbsp3.exe (Radiant one) arghrad.exe (Quark one) Qvis3.exe (Radiant one) Same errors with textures/brushes but lighting works with some lighting bugs here and there, but more importantly the map loads with 5 additional brushes. This was not possible with the standard setup of compilers. 1760 brushes, I have not gone beyond that so I don't know if this is a "fix" yet. I will do some more testing. But I'm guessing and asking you Jaydolan, is it/was it the Qbsp3.exe and/or timvis.exe shipped with QuarK that was broken? Margaal, do you have these compilers to test with?
|
|
|
Post by giftmacher on May 16, 2015 13:00:11 GMT -5
www.youtube.com/watch?v=sqcLjcSloXs Indeed... Yea that is one way, try and open up as many areas as possible to sky light, all brushes used for light sources is quite a lot, especially if you want more than just the square brush with a light texture on it.
|
|
|
Post by giftmacher on May 16, 2015 12:28:36 GMT -5
Yea and I appreciate his help, just want to get to the bottom of this. Hopefully there is someone active on the Quark forum who might know. I could try and do some func_walls but this error is stoping me from making one last hallway-stair-connection in the map that would make it run better :/ 4.5 mb is a very big bsp I must say, but entities and everything else goes into that size. SPoGSP1 is 5,4 mb.
|
|
|
Post by giftmacher on May 16, 2015 12:03:29 GMT -5
Also, you can't add anything more in terms of brushes, detail brushes does not get past this limit either, so it appears it has nothing to do with it being solid or detail brushes, just the amount of faces in general?
Edit: At 1755 brushes (according to .map, yea probably many more after compile as you say Jaydolan) adding just 1 more square detail brush produces "Error - Too many surfaces" in giftdm8.
|
|
|
Post by giftmacher on May 16, 2015 11:29:12 GMT -5
That is an interesting side note indeed! Makes me wonder how he managed to make such a map with the hardware of that day, I mean Quark lags for me on my modern PC when my maps become large enough. Turning off the 3D view I suppose is key For sure I'm not doing this perfectly, looking into a few things already, noticed my clip brushes was not detail!, as well as my water brushes and a few others I was able to spot. What is bugging me however, is that I pretty much used the approach that TRaK is doing (I got the idea from spirit and his .map files originally), making a solid layout as you say and then pretty much everything else is detail brushes. It just alerts me that this map crashes around the exact same brush amount as my messy contest map 'giftdm6'. Another example, before getting to the current giftdm8, I made 2 other attempts which I decided to scrap, one was constructed completely in solid brushes! And both this version (which got well over 1000 detail brushes) crashes around the same amount as my completely solid map. Making me think it has something to do with Quark, the editor/way of compiling. Here are two images from giftdm8, first one is the solid layout, the second one is with all the detail brushes showing: (It compiles in 15 seconds, although is it relevant since we are now on modern day PCs?)
|
|
|
Post by giftmacher on May 16, 2015 6:47:26 GMT -5
I was hoping there was a way to import the brush work from QuarK to Gtkradiant to continue mapping there, but yes unless there is a solution I think picking up Radiant is the right way, it's a big undertaking and will take a long time.. In the end though you will be able to do more things that you can't do in QuarK and make larger/more detailed maps. I will start to tinker with radiant to learn how to use it. There is also Trenchbroom, but I know nothing of its capabilities or limits, can it do everything Radiant can? I can try and post on the Quark forum but as far as I know they are not doing any more work on it? Edit: Waiting for my forum registration to go through on Quark forum, anyway I found this: --- About Quark and GtkRadiant --- -=[Question]=- Hi all, Does anyone know of a way to move .map files back and forth between Quark and GTKRadiant? Quark seems to open Radiant's .map files with little or no troubles, but Radiant suffers a hard crash when trying to open Quark's .maps. Can anyone think of a way to do this? By the way, I'm working with Quake 3 maps, so WinBSP doesn't work for making conversions (I already tried). Thanks in advance. -=[Answer]=- Under the map options, choose saving to brush primitives format, & things ought to work. GtkRadiant doesn't like some of the comment codes that QuArK writes into map files,there are options to turn various of them off, but using bp format is probably best. There is some fairly tricksy & recent coding (latest 6.3 snapshot) to address problems caused by the fact that QuArK writes floating point coordinates which GtkRadiant doesn't read. Empirically it seemed to work, but the issues are more complicated & more testing would be good, eg. maps sealed with brushes meeting at crazy angles, etc. -------------------------------------------------------------------------- Weird though that I did not find this option in Quark under Conf -> Map -> Options.. Maybe it's for Q3 only or something? It would be a solution to move .map file from Quark to GtkRadiant so you can do some finishing touches only.
|
|
|
Post by giftmacher on May 16, 2015 5:56:18 GMT -5
Ok so I'm not alone! First I was convinced it was my method, but after trying different approaches and all maps crash at the same limit it didn't make sense. My contest map giftdm6 was a big mess, lots of diggers and suboptimal brush work, but giftdm8 is actually pretty carefully constructed (not perfect but still much better than giftdm6..). Both maps crash around 1750+ brushes, making me think it is as Margaal says -> QuarK who compiles the map in a weird way. Ok I can try that Margaal, I was also thinking about this -> openeing my .map in GtkRadiant and compiling the map there? Is that possible? You tech guys should let us know if we are completely off the rails here or if there could be something in this Edit: Ok didn't work to load the .map file in Gtkradiant, I see no brushes and the map produces a leak when I try to compile it. Edit #2: Found a faster way of checking that it is QuarK causing the problem Margaal, I tried to compile SPoGSP1 in QuarK and it caused the "Too many surfaces error" right away.
|
|
|
Post by giftmacher on May 15, 2015 17:37:52 GMT -5
Yea it must be suboptimal, I suppose it's overlaping then, tried with -chop 1024, still hiting too many surfaces around 1760+ brush, it's really bugging me because it prevents me from finishing some of my maps. I can't imagine I'm close to hiting the limits, I've seen some insane maps out there that run just fine, that SP map SPoG1 (or something) for example, It's HUGE and looks great..
7000 brushes.. wow! I will have a look at it.
I must find this ugly habit, 1768 brushes in giftdm8 and adding just 1 or 2 square brushes will cause the error.
|
|
|
Post by giftmacher on May 13, 2015 13:43:13 GMT -5
Look at all those nifty banners! thanks...
|
|