TTLG|Jukebox|Thief|Bioshock|System Shock|Deus Ex|Mobile
Page 2 of 2 FirstFirst 12
Results 26 to 43 of 43

Thread: devblog: "furis, o anima!"

  1. #26
    Registered: Apr 2011
    compositionally, youre right. but as a gameplay space, it was just: go in through the window, proceed straight across the room and out the door on the other side. not particularly interesting even with a civilian ai wandering around. but the secure room in the middle gives you a way to avoid ai contact even without much shadow, which i like. and if you fail at stealth, well cheesing the ai is always fun!

    though as soon as i posted the screenshots i was thinking of undoing the change: not for the sake of the room layout itself, which i definitely think is better, but because theres another reason to want the secure room in the corner instead of the middle. so who knows, i might change it back later!

    Quote Originally Posted by nicked View Post
    It's a good model - don't forget you can always convert worldrep into models via the export tool, useful if you have any complex brushwork left with minimal collision/lighting requirements
    personally i think its a terrible model, but appropriately terrible — and yeah, i nearly always start a model by exporting a brushwork blockout (even if just a cube) for size. this one is not much more than a direct conversion.

  2. #27
    Registered: Apr 2011
    jan xx-28, 2023

    no screenshots today, because today was all about debugging the worldrep merge tool. all very technical stuff, so skip this if youre not here for programming blather.

    so, the problem i had been wrestling with on and off for the past week or two was this: i merged the two worldreps into one. it seemed cromulent. but if i loaded the level into dromed, dromed crashed the moment i moved the camera into any "in the world" space, as it tried to render the view from inside a cell.

    unfortunately, the olddark dromed with debug symbols wasnt at all helpful here, because it didnt crash! it just didnt render anything. so i was having to wade through the newdark dromed disassembly in visual studio, while correlating it with the disassembly/decompile in ghidra, and correlate that with the leaked source, just to try to begin to figure out what was happening. problem was, keeping track of things in visual studio was a mess, because of ASLR. Address Space Layout Randomisation is a security feature in windows that loads programs at a different base address in memory every time it launches, which means that the addresses of the functions and variables in the program change also. which means that i would launch dromed, put breakpoints in various functions and inspect various variables for one run, and then hit the crash, realise i needed more info from what was happening before the crash, and so have to relaunch dromed—and now all my breakpoints and memory references were wrong. just far too much overhead, i couldnt juggle all that and try to understand what dromed was actually doing.

    all i had managed to discover up to this point was that it was trying to access the render info for a cell that was offscreen, and had never been prepared for rendering. if i had messed up the bsp nodes when doing the merge, or the "destination cell" ids in the portal info, that would have been an obvious cause. but no, i double checked that. even wrote a function to dump the merged bsp tree to a graphviz file so i could generate a diagram, making it much easier to check for correctness. here are the two trees that were the input:

    and merged, with a new root node inserted, and all the node and cell ids renumbered:

    and all that looked just fine. i couldnt for the life of me figure out why this offscreen cell was ending up in the list of cells to be rendered! so i set the whole merging thing aside for a while to focus on building out the ruins (i.e. the stuff from the previous post).

    anyway, yesterday i learned of a way to disable ASLR by patching dromed.exe with this very helpful utility. with that, dromed.exe now always launched with the same base address every time, so i could finally keep consistent breakpoints and memory dumps between runs. which meant i could finally effectively trace what was happening. i set up a few breakpoints at the entry point of various functions that would print out the relevant arguments, and similarly a few leading up to the crash point itself. here's what they printed (with some explanatory comments afterwards):

                                        // at the beginning of the render pass:
    initialize_first_region( 2 )        // camera is in cell 2, so put it in the list to be rendered.
    setup_cell( 0x0a6b0970 )            // prep cell 2's pointer for rendering.
    examine_portals( 0x0a6b0970 )       // find other cells connected to 2 that also need rendering.
    add_region( 1, ..., 0x0a6b0970 )    // found cell 1, add it to the list.
    setup_cell( 0x0a6b0850 )            // prep cell 1's pointer for rendering.
    examine_portals( 0x0a6b0850 )       // find other cells connected to 2 that also need rendering.
                                        // (there are no more to find that would be onscreen).
                                        // now later in the render pass, just before the crash:
    > active_regions[ 0 ]               // look up the first cell in the list...
    > wr_cell[ 2 ]                      //     its cell 2 (just as expected)
    > cell ptr: 0x0x0a6b0970            //     and here is its pointer again.
    > active_regions[ 1 ]               // look up the second cell in the list...
    > wr_cell[ 0 ]                      //     its cell 0?? how? it was cell 1 that got added to the list above!
    > cell ptr: 0x0x0a6b07f0            //     yeah this is cell 0's pointer. wtf is going on?
    Exception thrown at 0x00552801 in DromEd.exe: 0xC0000005: Access violation writing location 0x00000028.
    it still didnt make sense, but now that i could step through all this in repeated runs, exploring different pieces of the code along the way, i finally discovered where the list of cells to render was getting mangled. and it was in a function called "sort_via_bsp()", whose job was to sort the list of cells to render in front-to-back order. this didnt make sense to me: this function has a simple job, which obviously worked just fine ordinarily. and my bsp tree all looked correct! how could it be messing up when walking my merged bsp tree but just fine with either of the original two? and then i stopped looking at the logic and maths that sort_via_bsp() was doing, and noticed something small, something obvious and usually unremarkable: it was checking a "Marked" flag on each leaf node it encountered; and if the flag was set, writing that node's cell id into the (sorted) list of cells to render. to make that work, just before sort_via_bsp() is called, a function called setup_bsp() is responsible for setting those flags: it first calls unmark_bsp() with the root node, to clear all the Marked flags; and then for each cell in the (unsorted) list of cells to render, it sets the flag. so this Marked flag simply means "this cell is going to be rendered this turn". all very ordinary, and normally i would never have batted an eye at this code. but…

    but i remembered the flags i had seen days earlier in the bsp trees i was using as input. two of the flags made sense for the data structure, but the third flag, "Marked" had been set on some nodes, even in the .mis on disk, and i didnt understand what it meant. i had looked up where this flag was used, seen it was only used for this common clear-and-mark pattern that meant it was transient and its value on disk didnt matter at all, and disregarded it. i wasnt even checking the flag when generating the visual graphs. but now that it was implicated, i regenerated the graphs with an 'M' for the marked nodes. the pictures above are output from this updated graph generation, and you can see that all of the non-leaf nodes in the "top" worldrep are marked; and all of the nodes in the "bottom" worldrep are unmarked. and when merged, my root node obviously was unmarked, because why would i set this flag on it? after, every node gets the marked flag cleared at the start of the render pass, right? right?

    nope! turns out the unmark_bsp() function responsible for clearing the flags is written recursively. and to avoid walking more of the bsp tree than it needs to, if it encounters a node that isnt marked, it concludes that its subtrees are also entirely unmarked, and takes a shortcut: it doesnt recurse any deeper from there. and this shortcut is perfectly reasonable and in line with how the marked flag is set later on. but with my new root node that was not marked, this shortcut meant that the entire tree was never getting unmarked.

    so that finally explained how cell 0 had ended up in the sorted list: as you can see in the merged graph, its parent, node 11, had the marked flag set (as do the parents for cells 1 and 2, which were the cells that were actually supposed to be rendered; so they wouldve been marked regardless).

    so this little unremarkable flag, that honestly, being transient, should never have been written to disk at all, turned out to be the cause of days of pain for me.

    like most bugs, once the cause is understood, the fix is easy. when i merge the two worldreps, i go through every node and clear the marked flag. it really should never have been written to disk, so lets just clear it from the on-disk bsp tree. and with that, my crash went away! the merged worldrep rendered perfectly.

    of course, i immediately encountered a new crash! but that will be a job to debug another day…

  3. #28
    Registered: Apr 2011
    feb 2, 2023

    big progress on the worldrep merge in the last few days. first new thing to be merged in is lighting, including animlights. while the lightmaps themselves are stored alongside each cell, and so end up correctly merged "for free", the table of light data at the end of the worldrep, which is used for calculating the amount of light shining on the player and to objects, does not come quite so easily. up until now my code had just recklessly skipped writing this light table entirely, since my test maps did not have any lighting at all.

    but merging lighting was more of a pain than i expected, particularly animlights. there is a table at the end of the worldrep that maps each animlight to the cells that it illuminates; and each cell has a small table of the animlights that illuminate it. so thats a double set of references that need to all be correctly fixed up when i merge together two sets of cells and two sets of lights-that-reached-cells.

    but for the first time i had to move beyond the worldrep chunk of data (named "WR", "WRRGB", or "WREXT") in the .mis file: because the Renderer>AnimLight property itself on animlight objects also stores references to the animlight-to-cell mapping table in the worldrep. so now i needed to read and write the "P$AnimLight" chunk too. and, of course, the data format has changed slightly in newdark (thankfully PinkDot's data structure notes had forewarned me of what exactly was different), so i need to support two versions of the chunk. well, for the actual mission im making, only support for the newdark version would be needed; but supporting olddark is important for developing this tool because i can debug olddark dromed problems a lot more easily.

    anyway, after a bunch more code and the usual number of flubs along the way, i got that all working. it doesnt look like much, but heres screenshots from my test map generated by merging separate "top" and "bottom" .mis files; each with one normal light and one animlight:

    the top:

    the bottom:

    but there was still the "other crash" i mentioned in the previous post, and, as luck would have it, it only happened in newdark dromed, not olddark! all i knew going in was that newdark dromed was trying to clearing some memory that olddark dromed didnt bother about; but the memory hadnt actually been allocated, so a crash resulted. thankfully without aslr anymore, it was now easy to correlate the address of the crash with my annotated disassembly, and by studying that a little more, identify what this piece of memory was supposed to be.

    after all the lighting bits, there is one more set of data tables at the end of the worldrep, that is called "csg internal data". its only used by dromed; thief.exe itself never bothers to read it from the .mis. its a set of tables that map the polygon faces in the worldrep to the brush faces that they belong to, and vice-versa, so that you can click on a face in the 3d view and select it; and so that dromed knows which polygons in the worldrep to redraw when you change the texture on a brush face (without reportalizing). again, up until now i had been skipping outputting this data while i focused on all the rest of the worldrep. but it was easy to see that the crash was happening because newdark dromed was trying to clean up this csg internal data—which wasn't there in my test map!

    but these half-dozen tables actually looked pretty straightforward to merge: one of them has one entry per polygon; one of them has one entry per brush. i wrote the code to do the merge in one go, and—of course it didnt work. i stopped for lunch, and as i was washing the dishes afterwards, i facepalmed: i suddenly realised i had merged all these tables together but never written them back out to the final .mis! after fixing that oversight, all this seemed to be hunky dory! i could:

    select brush face by clicking it...

    ...and change its texture

    so my little test map was working great! time for another stress test with two parts of the actual mission. i had high hopes.

    which were immediately dashed. my little test map has only 6 non-object brushes (2 in the top, 2 in the bottom, and 2 area brushes demarcating each part), and so there were naturally 6 entries in the per-brush csg table. but my mission has over 6000 terrain brushes—9,027 brushes in total when you include object brushes. and yet the per-brush csg table in the "top half" input .mis had 9,203 entries—176 more! and "bottom half" input .mis file had 9,377 entries in its table—350 more than expected! what in the builders name is going on?

    well, i dont know for certain yet, but i have a strong suspicion i know the evil culprits causing these strange numbers:


  4. #29
    Registered: Oct 2004
    Location: Slava Ukraini!
    Do you even need doors?

    A bit more seriously - great to see the progress! And I appreciate the detailed explanations. I'm sure I'll make a use of that knowledge at some point.

  5. #30
    Registered: Apr 2011
    february 3, 2023

    so the problems with doors are very many and quite well-studied, but the specific problem i am having with them in the dark engine is this:

    they need their own special little cell so that they can turn off its portals when closed. this means the renderer doesnt even need to think about drawing anything on the other side of the door.

    a door in a room, with "cell view" enabled. each different colour is the sides of a different cell:

    but how does a door get its own special little cell? when you tell it to portalize dromed sneakily creates a new brush for every single door in your mission (that has the "Blocks Vision" flag on). this brush is set to the blockable type (indeed this exact use is why that brush type exists), which is really a hint to the portalizer and optimizer to not optimize away its edges; that way the cell will always be there, and be guaranteed to remain the right size for the door. once the portalize is complete, dromed sneakily deletes those extra brushes again, leaving you and me none the wiser.

    when the door is open, you can see the periwinkle cell on the near side, and the olive cell on the far side, and just a glimmer of the tiny puce cell that was made by this door's blocking brush:

    zoomed in for a better look:

    why is this a problem for me? well it shouldnt be, except that: there is a variable that keeps track of what is the id to use for the next brush that gets made?. i dont know its real name, but lets call it next_brush_id_jim. whenever you add a brush, dromed adds 1 to next_brush_id_jim. when dromed sneakily adds these door brushes, it adds 1 to next_brush_id_jim for each of them. what can happen is that although your level looks like it only has 1,000 brushes, meaning next_brush_id_jim ought to be 1,001, the actual value of next_brush_id_jim can be hundreds higher than that.

    but so what? its just a number, right? well the other bit that makes this a nuisance is the "csg info" tables at the end of the worldrep. these are really only there so that dromed can answer the questions of if i click on a polygon in the 3d view, what face of which brush should be selected? and if i change the texture on a brush face, which polygons need to be updated? in other words, a two-way mapping, brushes => polygons and polygons => brushes. but the brushes => polygons table is created with one entry for every brush id just up to next_brush_id_jim. so because of the door brushes, this table can end up containing hundreds of entries beyond the ones that actually belong to actual brushes.

    again, so what? there are no brushes with ids corresponding to those table entries, so nobody is ever going to look at those table entries. and this is true, except i am that nobody, because i am doing shenanigans. to merge my two worldreps, i have to make sure all these tables have cromulent data in them. yet here i found myself with all this extra data that couldnt be merged together, because it didnt make sense. so its no problem for anybody except me:

    if worldrep one has table entries for brushes 1, 2, 3, 4, and 5, and worldrep two has table entries for brushes 1, 2, 3, 4, 5, 6, and 7, how do i merge those together in any meaningful way, especially if only brushes 1, 2, and 3 actually exist?

    thankfully by poking around in various places and doing some tests, i determined that all these extra table entries were really not going to be used. so now i figure out what next_brush_id_jim is set to (by looking at all the brushes stored in the .mis file), and once ive merged all the entries that belong to real brushes, not fake lying dromed brushes, i just say "la la la im not listening" and ignore the rest of the table entries. so the merged table would end up with entries for only 1, 2, and 3 (because i insist that the two .mis files have the exact same actual brushes; that's just fine for my purposes, and simplifies a whole lot. but more on that in a later post about editing workflow).

    the important thing is that now, with all this csg data sorted out and sensible, i can use the merged .mis file in dromed without it crashing anymore! at least for the trivial test maps. does it work with the pieces of the real thing?

    merged island test, upper part:

    merged island test, lower part:

    yes! you can't really tell it from the screenshots, but these two different versions of this island were in their separate .mis files, and successfully merged together here! and so far everything about them seems all in good order.

    i still have a little more work to do to be sure: i have to look into flow brushes, room brushes, pathfinding, and physics stuff, at least to see if they need any work or if i can simply go about rebuilding them post-merge. and i need to iron out the workflow for when i do need to make terrain changes to this mission, but…

    this success is a decisive—albeit highly constrained and not at all generalisable—VICTORY OVER THE TYRANNY OF CSGMERGE CELL COUNTS!!

  6. #31
    Registered: Sep 1999
    Location: Texas

  7. #32
    Registered: Apr 2001
    Location: Lost in the BSP...
    It's a shame there's not a way to "fix" doors to where they no longer require a vision blocking brush in them. I think there are some vision-blocking objects, and can't that property be set manually on them? If you could create a solid door of sorts, maybe you could replace the standard doors with more modern "engine friendly" doors. We have cemetery gates and other portcullis types..

    No idea if this would affect how sound propagated through them, but it might also remove the need to have some extra, small Room brushes around doors.. is it even possible? Or would sound just travel willy-nilly through rooms and make an entire building seem like it was one big room???

  8. #33
    Registered: Apr 2011
    Quote Originally Posted by Hit Deity View Post
    It's a shame there's not a way to "fix" doors to where they no longer require a vision blocking brush in them. I think there are some vision-blocking objects, and can't that property be set manually on them?
    well you can make any door you like non-vision-blocking, just go into its Door>Rotating or Door>Translating property and untick "Blocks Vision". but this cell-blocking is a good thing to have! it makes rendering more efficient. dont confuse this feature of doors with the AI>Utility>Blocks AI Vision property, thats an entirely separate thing that doesnt have any worldrep/rendering implications.

    Quote Originally Posted by Hit Deity View Post
    No idea if this would affect how sound propagated through them, but it might also remove the need to have some extra, small Room brushes around doors.. is it even possible? Or would sound just travel willy-nilly through rooms and make an entire building seem like it was one big room???
    no; the interaction of doors with room brushes is entirely separate from its interaction with the worldrep/renderer.

  9. #34
    Registered: Apr 2001
    Location: Lost in the BSP...
    Ahh okay. I figured there had to be a reason to have them in the first place, other than just a hard limit for vision. Thanks for the succinct explanation.

  10. #35
    Registered: Apr 2011
    february 9, 2023

    i dont have a useful screenshot of it, but i went forward with the merging of all three island pieces, which worked great! this was a huge boost to me, as having this capability to rely on resolved a whole lot of worries about the project and its progress.

    so of course, the next day, the merging promptly failed again—as i was demoing it on twitch for some other mappers. i should have expected it of course, the curse of demos is not to be sneezed at. what was happening now is that one island slice or another was being treated by dromed as if it was inside out. i have a rough idea why, but after all the intense work on the merge i didnt have the headspace anymore to debug this problem, so i made notes and parked it.

    the lack of an actually functioning merge tool isnt a bottleneck yet: i still have plenty of ordinary building in dromed to do, and i can use area brushes to keep things down to a portalizable size. so my plans arent ruined.

    what is ruined is the mansion. well, parts of it; but not enough yet. the last main building work had been interior detailing in the unruined mansion, completing it. but the ruined slice still just had bare devtextured blockouts on the interior, and so all of these interiors needed to be copied over. however, due to the relatively tight layout of the mansion and all the other brushwork going on, using an areabrush to select each room in turn and clone it wasnt going to work: it would pick up far too many other neighbouring brushes that would need to be picked out. so i spent a day and a half slowly (though unpleasantly so) manually working through each brush in a room, highlighting it, and then multibrushing the highlight to create a clone. not the fastest work, but made significantly easier by writing scripts to move the selected brushes straight up/down to the next layer and to move the camera up/down between layers too, which i bound to shift+pgup/dn and pgup/dn respectively. handy! the camera move in particular let me easily compare both parts to ensure they were the same.

    well i got a few rooms done that way, before realising there was another problem. and it was this, the ruined east wing blockout:

    see, the east wing was to be almost entirely collapsed, with only a few walls left standing, and barely a single bit of floor (excluding the basements of course). lovely and picturesque for exploring the ruined version of the island. the standing walls looked beautiful in the fog. and the openness of the ruin served a couple other small purposes too. but it simply did not fit the gameplay needs for timeline teleporting. the lack of intact floors meant that if you were in the east wing in the past, and needed to teleport back to avoid a guard or something, you would suddenly find yourself in midair, and unable to hover even for as long as wile e. coyote. this would be a quick route to dying or losing most of your health to fall damage, repeatedly. you might object, "but you could just look down through the device and see that there wasnt a floor there". and that does work. everyone knows players dont look up, but they really dont look down either. i knew of this problem; i knew where the ruins had bits of intact floor and where they didnt; and yet i still found myself teleporting into empty space far too often. it just wasnt going to be good enough if this problem was ubiquitous throughout the east wing. so i realised i would need a shiny fresh new copy of the unruined east wing, that i could then ruin anew in a more playable way.

    and that made me realise that i had been going about getting the new interiors to the ruined island all back to front. the amount of detailing work in the ruined slice was quite small: only the east wing basement (which was essentially a vertical slice to test out the texturing and modelling workflows i would need), and one room in the west wing basement (to test out a puzzle mechanic). it would be far easier to take a fresh new copy of the entire mansion, and just regraft those two pieces onto it.

    fortunately, i had been careful to keep the geometry of the bare island terrain and the mansion separated in time. first in time came all the brushes for one slice of the bare island; then the near-identical second slice of bare island; then the near-identical third slice. after that came all the brushes for the healthy mansion. and finally all the brushes for the ruined mansion. (object brushes of course come after all of this; but objects are much easier to manage just by area multibrushing, so they dont really matter for this problem).

    to illustrate, here is the unruined mansion slice:

    if i set time_filter_hi, i can hide all the brushes at a higher time to get just the bare island:

    and if instead i set time_filter_lo, i can hide the low-time-value bare island brushes to get just the mansion:

    and that—together with area brushes to isolate the basement parts that i needed to keep (relatively easy to unpick them from the rest, since the basement levels are much more flat than the rest of the mansion) meant that in another day i was able to get a fresh mansion fully ready to keep ruining. so thats what i have been doing now; heres the last screenshot for today, showing the destruction-in-progress:

  11. #36
    Registered: Apr 2011
    February 15, 2023

    a really quick update today. no time to take screenshots for it.

    ive continued ruining the west wing of the mansion. progress is slow, largely because theres a lot to do; when i did a "vertical slice" test of ruining the east wing basement, i unconsciously benefited from the relatively few textures that area used, that i needed to make ruined variants of. but in the more richly decorated rooms upstairs in both wings, i had been throwing textures at the walls and floors and ceilings with wild abandon, making it look sumptuous when fresh, neglecting to consider that i would need to make it look, er, slumptious in its ruined state. making each ruined variation of a texture only takes a few minutes—most of the work is reusing various dirt/grime/moss/cracks overlays i had prepared already—but theres a lot of it. and then more models to make ruined variants of, too! but the progress is pretty steady.

    i also discovered that while i had decorated the walls of the west wing main hall, i had neglected to furnish it in any way. and in doing that realised that i needed some more paintings to hang around the mansion. i decided the works of the French painter Hubert Robert were exactly what i was after for this mission, and selected a whole bunch of his paintings (source from wikimedia commons) and converted them to appropriate size textures.

    so thats all good progress. but the real news today is this: i figured out why my merge tool had suddenly, confusingly broken a week and a half ago: its because it hadnt! instead, i had made a ridiculous tiny mistake when creating the batch file to automate the merge process. see, between the first (ruins) and second (intact mansion) layers of the island, a rough halfway point is at Z 416.0. so i had put in the batch file that the separating plane between these two should be 0 0 1 416 (the 0 0 1 is the plane's normal vector, meaning it should be a flat plane facing straight upwards). but the last number, 416, is not the Z coordinate of a point on the plane, as i had clearly confused myself into thinking, but rather the fourth coefficient of the plane equation, ax + by + cz + d = 0; geometrically, it is the distance from the plane to the origin, in the direction of the plane's normal. which means the plane, facing straight upwards, sitting at Z 416, needs its fourth coefficient to be minus 416. it should have been 0 0 1 -416. the merge had started failing simply because i wrote it out wrong when making the .bat file. sigh.

    at any rate, i am very happy to have found the cause of the fault. i wasted a lot of time trying to understand why the output of the merge was wrong, trying various different strategies to debug it, without actually double-checking if the input was right! i would say "lesson learned", but this is an old, old lesson that i clearly still havent fully learned. oh well.

  12. #37
    Registered: Apr 2011
    february 20, 2023

    progress is slow in ruining things. because of my profligacy with detail, every other room needs a whole lot more ruined textures, and some more ruined models. still, progress, although slow, is progress. heres another before/after of a room:


    meanwhile the next rooms i started to ruin had wallpaper instead of wood tile textures, so my previous process for doing dirty/faded/moss-grown texture varieties needed some changes. i dont know yet whether i will want moss growing on the wallpaper? but i do want torn wallpaper. so heres some of the wallpaper variants i put together today:

    there is a little other progress, but i am too tired to write it up or go chase down screenshots. so thats all for todays update!

  13. #38
    Registered: Apr 2001
    Location: Lost in the BSP...
    Looking very interesting..

  14. #39
    Registered: Jan 2006
    Location: On the tip of your tongue.
    How is that tree growing inside though? Needs more holes in the roof.

  15. #40
    Registered: Apr 2011
    Quote Originally Posted by nicked View Post
    How is that tree growing inside though? Needs more holes in the roof.
    there is a big hole in the roof thats not really visible in that shot—but yeah, wouldnt really let in enough light for a tree that size. the tree is also of a species that doesnt grow on this island, so i need to change it anyway. for now, think of the tree as a metaphor, or something.

  16. #41
    Registered: Apr 2001
    Location: Lost in the BSP...
    It's your island, it can grow whatever tree you want it to.

  17. #42
    Registered: Oct 2004
    Location: Slava Ukraini!
    @vfig - I can't believe you have ruined all you had built so far...

  18. #43
    Registered: Apr 2011
    march 3, 2023

    progress continues on ruining the mansion, albeit slower than i would like. i needed a break from the rote work that it involves, and decided to do some other tedious rote work instead: room brushing!

    yesterday i roombrushed the east wing of the mansion:

    today i finished off the west wing:

    theres probably a spot or two that i missed, but i will do another run through with show_bad_rooms turned on tomorrow, to check with fresh eyes.

    as always, the trickiest bits are always the nice bits of architecture: round drum towers, the sweeping curve of the colonnade, spiral staircases, and the interior and exterior of the domes. a few slivers of "bad rooms" are inevitable.

    but as long as they are abutting a wall and too small for the player or AIs to get into (with either head or foot joints), then they will have negligible impact on gameplay. at worst a broadhead shot at that specific sliver of wall will fail to make a distraction; and since youre not going to be shooting arrows around much in this mission, thats even less of a problem!

    the other important thing to be careful of is interior and exterior roombrushes touching when not at a doorway. this allows sound to leak out through the walls, so that you can hear ais through them too easily, and worse: they can hear you too easily. when building the terrain, i was keeping most of my walls typically 2 units thick, which allows some space for interior and exterior room brushes around the "interesting" architectural parts to extend a little into the walls without touching through them; but really i should have aimed for 4 units thick in these places to make the roombrushing a little less fiddly. oh well.

    the dome interior needed more compromises, and so most of the space immediately below its ceiling is "bad room". but the player wont get there—the ceiling isnt ropable—and there's enough good room around the oculus to support roping and traversing through it.

    Last edited by vfig; 3rd Mar 2023 at 21:30.

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts