 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
It's better to just take the opinions and criticism you got and apply them to further work than endlessly try to improve previous work.
One of the ways you improve as a designer is to release your work and say "This is my work!" and stand behind it as something you are proud of, and then look to improve in your next project. I think it helps you decide what values you want to define your work, rather than constantly fixing things and trying to make everyone happy. For instance, if you decide you really like spawning dogs behind people as a gameplay mechanic, but all the comments here are negative, then try and think of how you would improve that for next time. Maybe spawn them further back would be enough? Perhaps some sort of warning would make it more acceptable? An example of an improvement of the gameplay idea would be to have the dogs in cages you walk past and can't shoot them, and then just after you pass, you hear them slide open! That would give a narrative and reason and forewarning, which would strengthen the encounter, and still give the "Enemies behind you you must quickly turn and deal with". I don't think it's as easy to stick something like that into an already released map, you end up having to shoehorn which doesn't always work as well as you'd hope. Better to leave until next. On the Paul Steed objectivity scale, visual glitches are much closer to the objective issue end, while gameplay sits on the subjective criticism side of things. So if you really want to release another version, I'd suggest only fixing visual quality stuff, and listen to Scampie for the rest.
..i think i got it.
Won�t change the anything in it, Scampie gets it to the point, and honestly i�m a bit tired of this map. Actually i can�t see it anymore, it�s a pity all this work... But for the fixing, i can tell you i�m working on it, as long as i am not working on something else , i can deliver soon.. And btw, my assumption of a potal error by func_detail in void was wrong, it�s mainly broken or misaligned polys that suck(which makes it even worse). Well that wandered off and fell in a well.
Mfx, to answer your question, it's worth fixing the greyflash and probably moving the spawning creatures out of sight. Personally I'd change the end shamblers for Edie's, but it's not my map :) As long as a player playing on a skill level they 'normally' play on can reasonably expect to survive.
Make your maps for everyone and they'll suck. Make them for yourself and they'll suck until you figure out what your favorite type of play is. Which you by experimenting and making mistakes. In the case of Mainframe Mayhem it'd be a shame for it to be marred by a couple of technical issues. But enemies appearing in sight subjectively described as a 'technical issue' and the end fight is purely gameplay... OK Guys, got the map now so far fixed to compile with no errors. \o/
But as when i load the portalfile in quark, i get this: portals Seems like there are portals expanding into the void on the left, and one is totally 'alone', but what do i know... Will there be problems vising this, does anybody has a clue? thats not fun to debug. have you deleted the old portal files? If it doesnt leak surely it should write a portal file?
yes
File: maps\mfxsp17.bsp 2861 portalleafs 8090 numportals 8061 numrealleafs State file out of date, will be overwritten. Base Vis took like 5 seconds, and now for the elaborate part.. its not leaking, here the tx_qbsp output.
------ LoadMapFile ------ Title: "Mainframe Mayhem" 41478 faces 6672 brushes (1750 detail) 1451 entities 167 miptex 20382 texinfo Added 23 texture frames Building hulls sequentially... Processing hull 0... ------ Brush_LoadEntity ------ ----+----+ 6059 brushes read ------ CSGFaces ------ ----+----+ 37707 brushfaces 30489 csgfaces 26475 mergedfaces ------ SolidBSP ------ 34772 split nodes 14574 solid leafs 19952 empty leafs 247 water leafs 62491 leaffaces 54909 nodefaces ------ FillOutside ------ 5837 outleafs ------ MergeAll ------ 20658 mergefaces ------ SolidBSP ------ ----+----+ 14143 split nodes 6083 solid leafs 7999 empty leafs 62 water leafs 33841 leaffaces 25980 nodefaces ----- Portalize Detail ---- 2861 vis leafs 8090 vis portals 8061 real leafs ------ Tjunc ------ 30705 world edges 95974 edge points 18564 edges added by tjunctions 0 faces added by tjunctions ------ MakeFaceEdges ------ ----+----+ ------ GrowRegions ------ Processing hull 1... ----+----+ ----+----+ ------ MergeAll ------ 14685 mergefaces Processing hull 2... ----+----+ ----+----+ ------ MergeAll ------ 10962 mergefaces WARNING: Marksurfaces 36957 exceed normal engine max 32767 ------ FinishBSPFile ------ WriteBSPFile: maps\mfxsp11.bsp 14042 planes 280840 37478 vertexes 449736 16011 nodes 384264 20382 texinfo 815280 28846 faces 576920 26498 clipnodes 211984 9655 leafs 270340 36957 marksurfaces 73914 132804 surfedges 531216 69520 edges 278080 190 textures 1897064 lightdata 0 visdata 0 entdata 135178 Skipped 2344 surfaces 1 warning If you don't mind, could you put the
It might also be worth trying to compile it in TyrUtils, to see if it's a compiler problem. In what way though ?
If it refuses to compile it because of stricter rules or better error-checking, it's possible that something in the map is done in a way that may better be avoided or done differently. If the map is solid but the output is wrong, then the map might be a good test-case to use to find the problem in the compiler. In any event, there's something to be learned. By the way, the file-format of But why in the world would you want to open a portal file in Quark? I've been mapping for nearly 20 years and I've never felt the need to even look at a portal file.
Mainly texture alignment problems are caused by tyrutils.. i know there a switch to avoid that.
No error msg from quark btw. No error when vising too(by now), i�m waiting for the output to be b0rked again...:) there�s just no other way to check the prt file.
Mainly to see if its congruent to the map structure, or , in this case it�s not. Just curiousity i guess. load
Map -> Check for problems. Humour me, WC has decent illegal face and brush detection. Sometimes a face gets bad contents that isn't even facing the inside of the map. You can identify any illegal brushes or faces in Worldcraft and repair in your editor of choice. Unless you are using Worldcraft already and have already checked in the way I described above, in which case IDK, no ideas :/
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2025 John Fitzgibbons. All posts are copyright their respective authors. |