Jump to content
The Dark Mod Forums

Dragofer

Member
  • Content Count

    676
  • Joined

  • Last visited

  • Days Won

    63

Everything posted by Dragofer

  1. Technically speaking what you want to do is very simple. All it takes is to open DarkRadiant twice to open both maps, then select & copy-paste (via ctrl c & v) between them. Names get updated automatically, so if both maps have func_static1 to 100 then the new arrival's func_statics will get renamed 101 to 200. If there are spawnargs referring to these names they conveniently also get updated. What you'd have to watch out for is that you'd probably have multiple ambient_world lights, location setting entities etc. Whether this is advisable at this point is another question: 1) For your first map you could reasonably expect to have your hands full just getting a feel for how all the parts of a complete mission work. The generally advised practice on these forums is therefore to aim to get everything to work on a smaller scale, as each step already takes longer than usual if it's your first time and mistakes are easier to correct, before moving on to more ambitious projects. 2) Each mapper works differently. I've taken over a harbour map from this thread but spent considerable time figuring out how the map's been put together and then reshaping it into a state I personally can work with. For example, rooves and subterranean brushwork were highly irregular, both requiring a redo before I could add attics & basements without getting confused. This kind of work is something I'd recommend putting in if you find a map idea here that you want to see to fruition (i.e. I have a high affinity for maritime environments and also had a large ship looking for a new home). But if you just want to have some more content in your map then I'd say it'd probably be more wholesome for you to use (mostly) your own work. This is just my personal opinion based on my own experience, though.
  2. Personally I find torches to be a crude form of lighting that would feel overwhelming in places where people live and work, with their bright light, crackling sound and open flames. That's a matter of aesthetics, so there'll surely also be mappers to whose taste it would be to employ torches in a more versatile way. What I wouldn't do - anymore - would be to let realism be a major factor in the decision. In my early days I went to some lengths to ensure my map was realistic enough, for example only adding moonlight to rooms which had windows actually facing the moon. At some point I realised that such striving got into the way of building my maps in the best possible way, seen from the gameplay, aesthetics and time-efficiency perspectives. In that particular example, the poor lighting in the non-facing rooms would be much likelier to be noticed than the more realistic portrayal of the moon's lighting. Realism does do a lot of good - TDM and Thief arguably simulate stealth and industrial society fairly realistically - but it can be taken past a certain point where small improvements come at a cost in other areas. Thus, if a mapper's intuition is that a torch would fit best in a certain locale, then I wouldn't want to interfere with that.
  3. The dilapidated old house at the western waterfront of Wrecker's Reach. A local glancing upwards as he hurriedly walks past in the dark of night might notice a window lit up brightly from within, but he would rather not think about how this could be. (This is also the same house that'll feature an excerpt from an eerie short story written by Spooks.)
  4. Brilliant, I'm very pleased with the direction you took this: not only a gentleman scientist's of an early design, but also a beautiful wooden box for it to stand on. Please do make this available to the public as soon as it's ready. My thoughts exactly
  5. Figured out this was caused by targeting the doors from lamps. My doors have windows in them that used lit & unlit skins, and that part works alright. But lamps also will open/close the doors in certain situations: 1) if the door is open and the lamp is extinguished the door closes. 2) if the door is closed and the lamp is relit the door opens. And a second bug, which was at the root of my problem I posted about: if the lamp is extinguished at map start the door will start way off elsewhere. Didn't make the connection between lamps and doors until now because I always tested the skin changes only by extinguishing lamps while the doors were closed, which does not correspond to one of the 2 situations above. Will post a bug report of this later on.
  6. Anybody got some experience with troubleshooting doors that start way outside of their frames? I've got a couple that start on the floor below, then when frobbed they slowly float back to where they should be. While they're floating they can still be 'opened' & 'closed' normally. It's variable which doors are affected, it changes every few days.
  7. Thank you duzenko for looking into this, I've attached a test map with some of the offending interiors. leaks.map.txt
  8. Yes, it would need some careful thought to figure out whether culling of models from closed visleafs could become more effective without having unforeseen consequences for models that touch multiple visleaves. However, the problem exists also for objects that are fully contained within a single visleaf. Patches that are flush with sloped or diagonal sealing geometry are highly likely to leak despite having all their vertices precisely along the line (my ship interiors use 1:2 and sometimes 1:4 slopes on an 8 unit grid). Well I'd assume the engine draws a box around each object and finds that it intersects the diagonal line into another visleaf. An opt-in would be immensely helpful, i.e. a spawnarg to tie an entity to its origin's visleaf, or until the next door (i.e. if the object spans a multi-visleaf hallway). The simplest form of this would already save hundreds of drawcalls in multiple places for me.
  9. Something I'd wish for would be for there to be no more leaking of indoor objects to exterior visleafs. Particles are especially notorious at this. My harbour has several hundred drawcalls coming from the ship interior's sacks, beams etc. despite being built in quite a clean way. Maybe a rule could be made that if something's bounds are 90% or more within a closed visleaf it doesn't get rendered? I do remember SteveL having offered to look into this some years ago
  10. Wonderful, this is pleasant to come back to after a weekend away. The upright design together with the wooden box stand does work quite well together. This is certainly important too, and that's a formidable collection of slides in that chest. My own idea was to go with something more modest like these boxes in the image below as they'd fit better into a ship cabin, but ultimately the choice may depend on whether or not you want the individual slides to be moveable and player-usable. Certainly no shortage of vintage microscope slide designs - remarkable how artistic they were compared to what we work with today: If the player should want to look at the slides under the microscope the Stim/Response system could be used to insert it when it comes close enough and change the frob response of the microscope to trigger a camera when frobbed. Not really sure if this is something the typical thief would be interested in, though.
  11. Thank you for sharing these additional steps, it works like a charm now - I do import meshes quite often, and additionally some shading issues I was having went away now that I started playing with the auto-smooth slider. Didn't need to use those settings before, but I believe this is just a more advanced exporter that takes more factors into account.
  12. Thank you for the great work of providing up-to-date exporters and refining them, it really is much appreciated. Unfortunately I can't get any smoothing with the scripts in this thread, though. Got the latest Blender 2.79b and the 2.79 versions of the scripts from Orbweaver's Github and tried various combinations of checkbox settings. Is there maybe something specific I have to do, beyond setting face shading to smooth and ensuring no double vertices? I've seen there was discussion of going either by smoothing groups or vertex normals in this thread.
  13. Maybe noclipmodel 1 will work? Also, could it be the def_attached items (primarily the head) are what's colliding because they're still solid? You could look up the relative names of the attached itemsby looking at the name_attach spawnargs, then put spawnargs like this on the AI: set noclipmodel on *name* 1
  14. Wiki: Systematic Method for Adding Pathfinding to Uneven Terrain During some recent browsing of the forums I came across not one but two members posting about the difficulty of applying monsterclip to uneven terrain. I realised I could share my approach to making such terrain passable for AI, which Ive first used for the beach segment of One Step Too Far. ​ Concept​ This will create a grid of monsterclip floor brushes. The top surface of each brush is raised or lowered to match the height of the terrain at that location. Steps are added wherever theres a great difference in height between two adjacent brushes. The map boundary is traced by brushes created on an 8-unit grid.​ ​ ​ 1. Preparing the grid​ Start by making a large monsterclip brush that covers your whole terrain. Its height should span from the bottom of the map area to above even the sky, so that itll be easy to click on from above.​ ​ Go to your preferences and ensure your clipper tool does not use caulk. Switch into top-down view and use the clipper tool to cut this brush up into blocks so that you get a grid. A good size would be 192x192 units per block, but you could use smaller or larger blocks if your terrain is highly uneven (i.e. boulder landscape) or quite flat, respectively.​ ​ ​ Delete any blocks that do not touch your terrain. If you have a structure with worldspawn brushes within the terrain, like my mansion here, then enable the filter for entities and use the clipper to remove those parts of the monsterclip brushes that overlap with the house. ​ ​ 2. Using the grid​ Disable the filter for entities, set your DarkRadiant grid size to 8, go into side-view to select the protruding tops of all your monsterclip brushes, hit v to swap to vertices mode and lower all the top vertices just enough that the highest point of your terrain is still covered in monsterclip. ​ ​ ​ Now use the resize tool to lower the top surface of each block so that it intersects with your terrain. This doesnt have to be very exact because you get around 30 units tolerance in both vertical directions. If you see that a brush is completely covered by impassable entities you can delete it.​ ​ ​ ​ 3. Making steps between the blocks​ Some blocks may be considerably higher than their neighbouring blocks, so that steps must be added. Not all AI can handle 16-unit steps, so itd be best to use 8-unit steps for this method.​ ​ Start by hiding everything except monsterclip: enable the filter for monsterclip, select & hide your whole map, then disable the filter for monsterclip. Now use the camera view to identify where steps are needed and add them as shown.​ ​ ​ ​ ​ 4. Monsterclipping the perimeter​ Unhide your map and create a tall brush that spans from your lowest block surface to the top of the map area, which you then delete again. This will inform DarkRadiant how tall you want brushes to be that you create while youre in top-down view.​ ​ Switch to top-down view and trace your terrains boundary, i.e. trees, rocks, walls with monsterclip brushes on an 8x8 grid. Use the camera view to ensure that these objects are completely behind monsterclip: AI can get stuck on any pieces that might stick out, such as branches. Objects on the terrain such as rocks and trees can be monsterclipped normally.​ ​ Remember that AIs need over 32x32 units of space, so you should fill up any alcoves that are 32 units or smaller.​ ​ ​ ​ Testing​ If youd like to test this you can have an AI chase you row-by-row, then column-by-column while you fly backwards with noclip enabled. The AI should always follow you in a straight line.​ ​ ​ Result​ This has applied highly quadrangular monsterclip to an organic environment that should fit well to TDMs 32x32 unit pathfinding system. As the approach is systematic, all areas should be covered correctly. This may be initially more labour-intensive than doing the monsterclip by eye, but in the making of One Step Too Far I kept finding small pockets all over the place where the pathfinding hitched before making the switch. ​ ​ ​
  15. Certainly, we have Obsttorte's keyhole peeking system that could be repurposed, it permits changing the view with mouse movements. For inserting the slides you could either just use custom inventory items, or if you want the slides to be moveables repurpose grayman's audio players.
  16. As far as I can see microscopes changed mainly through increased visual weight and more uniform horseshoe-shaped stands. The differences did look fairly subtle to me, after looking at quite a range of different microscope types. Maybe my searches mainly turned up 19th century microscopes Looking at your first shot, I think the wooden box as the stand is nice, but would find the body of the microscope too frail-looking. Your third shot is quite original and would make a good basis for an alternate-universe take on what a microscope looks like. In any case this would be a general purpose model so inputs & ideas from more people are a good thing to have, and from my own experience I liked to combine my favourite elements from each of the concepts when I modelled the hookah.
  17. As part of my mission I'd like to have more than a handful gentleman scientists studying and cataloguing specimens discovered on an expedition. A vintage, well-used microscope would be an essential asset. No doubt that this would be a versatile model for many other settings as well. What I'd like most would be a simple, worn-textured model like in the first shot. The other shots show additional or alternative style elements that could be interesting to use.
  18. I didn't think I'd see my merchant ship within a harbour at 60 fps, but 2.07 made it happen (formerly 40 fps). Thank you for the excellent work.
  19. This is what I remembered too, but the wiki page linked to in post #2 contradicts this after an edit made by Springheel on 2nd September 2016, which was left unchanged by grayman during later revisions of the same paragraph. So this would suggest AIs should be using elevators efficiently nowadays.
  20. I'd also say to begin with laying out (whiteboxing/greyboxing) the map to get an idea of how the planned pieces can fit together, and from there focusing on completing single rooms or buildings, like Melan or demagogue suggest, the rationale being that if the original idea was too ambitious, the excess can be removed from the whitebox. Another strength of producing complete scenes is that all elements of style are worked on together and should therefore fit together better. For example, lighting can be placed in such a way that it illuminates objects of interest, and objects can be placed to cast shadows that are interesting for stealth gameplay. This would be more difficult to achieve if object placement & lighting were separated into two mapwide worksteps weeks apart.
  21. Wow, the only thing that gave it away were the trees growing underwater in 0:33
  22. Now this is quite ethereal, I can see plenty of potential already in that kind of effect. There is still a faint transparent silhouette in the absence of a spectrum light(my 2nd test map has a moveable light source), but this could be resolved without apparent downsides by taking out the block with blend_gl_one_minus. I've experimented a little more by blending the texture's own diffusemap instead of _white and turned rgb up to 2, which I think brought out some more definition in the texture. It's a very likeable effect. Just tried it out on some other textures: how about finding a faintly green tinged, formerly invisible painting of an old man who's been dead for centuries when you relight his ancient candles? Procedure for creating spectrum materials (correct if necessary): Would you say that in order for spectrum to work correctly for hiding objects it requires the material to be translucent?
  23. My original idea for Down by the Riverside was to give the player a unique moveable light source that would reveal hidden scenes & objects within the mansion, including the ghostly path, requiring special care around the AI as it'd slightly illuminate the player as well. Even a more worldly map could use spectrum i.e. for revealing the hidden writing on a seemingly blank document (could be done by having a spectrum sheet 0.1 units above the blank sheet). Another idea that comes to mind now is having 2 sets of illumination in your map, where switching from one to the other changes how the same area appears to you. So there's quite some potential for creative use out of this I'd say. nbohr1more furthermore mentions the possibility to avoid illuminating certain surfaces, which sounds like it can come in useful but for which I couldn't think of a usage case yet. In the end I reverted to just binding a proximity trigger to the player that fades in the ghostly path when he comes close enough. Doesn't seem like I filed a bugtracker entry back then unfortunately. Speaking of which, would it be possible to have spectrum light that's visible to the player? In the screenshot above you can't see the spectrum light unless you clone in an identical, but non-spectrum light.
  24. As I'm not so well-versed in material definitions I tried to implement this by adding a shaderParm5 Parameter & translucent to the material and setting shaderParm5 to 0.001 on the entity, but it seemed to have no effect. Might be my method was wrong. In any case I've tried out a couple other transparent textures and added a moveable red spectrum light (on a pot lid). On the image from left: - the original rough_wood_darkbrown cube, without my attempt to add alpha. Turns black in the absence of spectrum light. - stainwall doesn't react at all to the spectrum keyword. - web4_id will disappear correctly in the absence of spectrum light, but only a portion of the cube is lit up at any moment depending on light angle. spectrum_v2.pk4.txt
  25. What would seem intuitive usage to me as a mapper would be if a "spectrum" "1" spawnarg could be added to an entity and a light (that order of priority), bringing spectrum into reach even for beginners. The nospectrum spawnarg would complement those spawnargs well I'd think.
×
×
  • Create New...