Jump to content
The Dark Mod Forums

Darkman

Member
  • Posts

    77
  • Joined

  • Last visited

Everything posted by Darkman

  1. thanks shadow/sotha... if there really is no limit, this might explain how johannes manages to have (more or less)ever single stone in his map built by an own brush or patch (instead of only using fitting textures)... haha, even f.e. a singe stair seems to be made of more patches/brushes than other fm's as a whole by the way, is your mission still in progress, shadow?
  2. just another question: as far as i know, there is a entity-count limit of about 8k. but is there also a limit for patches/worldspawn? thanks!
  3. A very nice mission! - looks pretty (esp. poly count not too high and also not too low; good usage of colored lights ) - has atmospheric cutscenes/"events" - offers a smooth gameplay (meaning f.e. that important objects, like keys, where not hidden that good, that they become almost unfindable)! so: at least in my eyes this mission is a little jewel! it was a honour to play it!
  4. yes, i meant the one and only, the master of shadows himself! oh guys, this was only some kind of fun. i did not aim for really "warning" anybody by the way: hey shadow! *wave*
  5. WTF? did i miss something? is johannes working with anohter editor/game? all those screens with original tdm-stuff? oh, and... don't feel sad but... these visuals won't satisfy "mr. S"... *cough*
  6. i have allready tried that. basically, this does work properly but there are also some problems occuring: f.e. the candle then has some kind of clipmodel whereas it does not collide if it's moved. so, you can stick a broadhead arrow in it as long as it's standing still but if you move it around itself, it won't collide with walls, etc. strange... beside that, frobing the holder won't extinguish the flame - but that's not the biggest problem. oh, these are the results if the candle is set to a model. if i set it to a ~adtm:mover_candle entity instead, it's even worse, as relighting the candleflame will also spawn a new candle with the originalskin that substitutes the one i placed before... i hope that this was somehow understandable... well, maybe i will have some time to see what i can do here today evening...
  7. evening guys! i need help in the following task: changing the skins of attached models that are spawned at runtime. example: one of those atdm_candleholders (this entity includes 1 holder, 1 candle and 1 candleflame; candle and candleflame are spawned at mapstart). it's easy to change the skin of the holder, as it's immediatelly accessible in editormode; the skin-spawnarg helps here. but it's not possible to do the same for the candle/candleflame, as they don't exist before runtime and there is no "skin-spawnarg" for attached entities... so how to change the skins of the candle/candleflame? ps: haha, hey, shadowhide! *wave*
  8. @shadowhide: as a master of the shadows, you are NOT allowed to fail in releasing an excellent fm!

  9. heaven, earth and hell... NOOO!!! well, but it's indeed better to quit (mapping) for some time instead of "burning" out... however, i will miss you (on the editors' side), you really built some pretty maps. Don't stay off too long! *wave*
  10. hey melan! wtf, all those screenshots/building-progress after 24h only? really looks like a pretty example for what may be possible within a short peroid of time! my editing sessions always feel like spending 24 hours to simply construct a piece of paper or a waterglass...
  11. oh, sounds like an interesting idea!
  12. nice! Disabling code really works again now! thanks!
  13. yeah, that's even better as possible errors will be merged when leaving/entering a zone again. sounds reasonable... thanks! i have allready rewritten my testscript/testmap, works like intended
  14. @ print button: ouch! i have heard of this "formidable" button but i thought the screen would immediatelly be saved somewhere but i never found out where... but if i got this right, in fact the screen is only loaded in memory, waiting there to be pasted... /facepalm @ issue: hm, maybe not the worst idea well, is any team interested in looking at my testmap to investigate this "phenomenon"?
  15. unfortunatelly i don't know how to take a DR-screenshot without downloading any suitable programms from the net before. however: the separating wall on the shots has a thickness of 8 units in DR. - one of those outdoor trees truly penetrates this wall on its outer side; it stops very close (~ 2 units) before raching the inner wall face - the other tree does not even reach the wall; it stops at least 24 units before the outer wall face => but both trees are rendered even if the player sits in the indoor area... well, we could discuss this endlessly. but no matter if it is the engine's fault or not and no matter if it's possible to derivate any rule here or not: at least mappers should be alerted as tall entities come close to a small leaf-border if there is another leaf behind - but mappers should check their maps with 'r_showtris x' anyway... just keep my warning in mind, as we all "lose" if maps suffer under unnecessary performance hunger
  16. well, the engine would render such a func_static under those circumstances, that's surely correct. however, fs's may also be rendered by the reason i mentioned above. i figured out, that the chance for such "render-errors" raises especially in relation to the thickness of leaf-brushes and the entities' tallness and position: - the error mainly occurs when a small distance between leafs/leafborders (in my case: one box at grid size 8 = 8 units) meets with tall objects (in my case: largest version of a pine with leaves) which additionally are located close behind to such a small leaf-border (in my case: ~a gap of about max. 5 meters). - the chance raises even higher, when such a leafborder is drawn by diagonal brushes, rather than by straight ones. but do not regard this as an exact rule...
  17. Sure! This kind of error is nothing new for me - and also the reason for my recently opened thread around hiding/unhiding entities (which you have noticed or not.). Here is an example, taken from a little nice testmap: - Shot 1 ("outside") shows two marked trees - Shot 2 ("inside") shows them from the other side of the wall - both are still processed...
  18. @stumpy: looks like you missunderstood me. VP's do not help here, as the error lies in the engine still rendering trees which are fully located in a leaf where the player is not in - even if all matching VP's are closed and that leaf is culled for that reason (well, except it's trees)... as i experienced, this can mainly happen where large func_statics are sitting behind but close to a leaf-border which separates the player's leaf from the one with such func_statics. so at the very end i look for a possibility to somehow force the engine not to render func_statics (under the mentioned circumstances)... @sotha: perfect! that's exactly that i was looking for! as a result of your link to the wiki-files, i was really able to create a testmap where trees (sitting in the courtyard) were hidded while the player was inside a building - including model, shadows and collision model. Once he left the building and so entered the courtyard, the trees were unhidden. that will later give me to chance to optimise my map through connecting func_statics to fewer but bigger ones and still force the engine not to render these, as long as not necessary. @both: thanks a lot! you two became my heros now
  19. hi guys! i hope that anybody can help me out... so here's the base problem: situation: think of a map with one indoor and one outdoor area; the outdoor area contains some big trees. both areas are connected by some kind of hallway, tunnel or whatever. the task i demand help for is about hiding all the trees in the outer area as long as the player is located inside the inner area. this aim refers to having some trees rendered even if the player sneaks through the indoor by default - although they are located in a complete different visportaled and so culled place. for the moment, just believe me that this is not caused by internal leaks but lies in the engine's responsibility. so i'm aiming for hiding the trees as soon as the player reaches the indoor area (forget the LOD-system, as this solution would require some distance) and unhiding them as he gets close to the other place. by default, this can be done by simply triggering the tree-entities (sets "hide" to "1"); another triggering-effect unhides them. so, there should be 2 triggers in the hallway: one sitting close to the indoor-entrance and hiding the trees and one sitting close to the outdoor-entrance and unhiding them. and here lies the problem: i'm only capable of creating triggers/multitriggers that, as soon as the player runs into them, trigger the trees. but that only changes the hiding-state, whatever it is at that moment - so if you run into the same trigger twice, that state isn't really changed after all. that's why i need one trigger only to be capable of saying "hide" and another trigger only being able to say "unhide". of course i'm also open for any other ideas, like a script maybe of whatever... but i hope that i was at least able to carve out the problem itself... oh and one further question: am i right that hidden objects do nearly have zero performance-impact (no polygons/shadows/cm performed as long as they are hidden) ?!
  20. somehow funny... half of biker's map "vanishes", while i have the problem that on some places func_statics are rendered altough they are in a completly closed area
  21. lol, yes, thats somehow right
  22. yeah... it's a pitty that creating fm's eats up so much time
×
×
  • Create New...