TTLG|Thief|Bioshock|System Shock|Deus Ex|Mobile
Results 1 to 5 of 5

Thread: Brainstorming and issue with window 'tech'

  1. #1
    Member
    Registered: Sep 1999
    Location: Portland, OR

    Brainstorming and issue with window 'tech'

    So I'm taking on having this window be super intractable:


    I don't mind the work for what it will be like in-game. But, I'm wracking my brain trying to find the best solution for what I want, given the limitations of the engine. Right now it’s modeled and ready to be sliced up in the colored sections - each being their own object.

    At first, I was to have Blue and Green, Static with expected Physics BBoxes. Then Red will have 'StdDoor' script with all the door fixings to open. No issue.

    But then I thought about having the panes (Yellow) totally breakable with with fun glass shard flenders and all. Okay sure.

    But to tie that together? Rough.
    This is as far as I can take it:
    Make Blue's BBox small and basically just be hidden in the center support, that way you get your wood thud, plus I figure it will be super rare for people to aim at the sides. This way the panes can have their own sound, BBox, and braking effect. Then once broken out, it’s just empty air, that thrown objects or arrows, can go through since the Blue BBox is only in the middle.

    Green will work the same, but now the Green Bbox will be at the bottom kickplate.

    Now here’s where it becomes more difficult, because Red will be like Green but have the Door props, and so the Yellow pane has to come along with it when it opens. Seems like no link type has helped me:
    ~DetailAttachment - Can’t use, not for physical objects.
    ~ParticleAttachment - Can’t use, not for physical objects.
    ~CreatureAttachment - Can’t use, it’s for AI objects.
    ~PhysAttachment - Allowed me to link, but then the attached object doesn't move with the doors rotate/swing. (Although I just now read about the Relink prop, will look into it after posting).

    If I do figure that out, this next part, involves an issue I’ve never figured out; having objects linked in the Archetype level, before becoming concrete - not coming out into the world together. Example you can see, ~ParticleAttachment Links in the Archetype level Torch, will create concrete instances for the Archetype particle objects it linked to. I can’t seem to do this with the window. I don’t want to place all the sections of the window each time I place it, I wonder if there is another way to place the objects needed to compose the window all at once.

    As a test, I added ~PhysAttachment of a lever object (no reason just needed a physical object), to the Hierarchy Torch, like this:


    But it was never created in-world, like the smoke and flame was. You can see I put it in the metaprop, as it should take precedence over the ‘root’ props of the Archetype level torch. I actually tried both ways, still didn’t work.

    Maybe the engine only creates new concrete objects if they are ~DetailAttachment/~ParticleAttachment linked. Baked in. I wish a NewDark update would fix this.

    Please feel free to comment on this tech I’m trying to accomplish, if you can add any insight, or like I said, if there is another way around these obstacles.


  2. #2
    Member
    Registered: Sep 1999
    Location: Portland, OR
    An update, I may go with Yandro's idea of just going the way of corpse linked broken windows. I have another couple of things to try before giving up. One having a non-physical window pane rotate with door/shutter Red, by taking advantage of ~DetailAttachment and Tweq's LinkRel but have an invisible object to catch a sword or arrow in front of it, that can be free to not rotate, and kill the pane object. Going to try it out.

  3. #3
    Member
    Registered: May 2002
    Location: Texas
    If you don't mind having this as all one object you could use joints on the rotatable part of the window and use the corpse link to a broken version of the window as you said along with glass flinders. I don't think detailattachment works with the door script but I could he wrong. I've never tried it before.

    Having multiple doors or anything that attenuates sound on the same wall and close together will have odd effects. If for example someone breaks the non-door part of the window and it removes the sound attenuation, opening and closing the door part of the window will add the attenuation again. This will seem odd since part of the window is still broken.

  4. #4
    ZylonBane
    Registered: Sep 2000
    Location: ZylonBane
    Just have two versions of each door model-- one with the glass intact, and one with the glass broken. It should be possible to cobble together some combination of NVRelayTrap/NVMetaTrap/some sound trap that switches the door model to the broken version and plays a shattering glass sound when it takes damage. If you really must have flinders, it might be possible to attach an emitter to the door that randomly spews out some glass shards on command.

  5. #5
    Member
    Registered: Sep 1999
    Location: Portland, OR
    Quote Originally Posted by john9818a View Post
    If you don't mind having this as all one object you could use joints on the rotatable part of the window and use the corpse link to a broken version of the window as you said along with glass flinders. I don't think detailattachment works with the door script but I could he wrong. I've never tried it before.
    Oh if not, this might lead me down a very different path. I want don't want to have the whole windows all a glass tap sound when hit with lesser damage. This was the point of make the window panes separate, but yeah, if I have to do it, I have to do it. I appreciate the input. I will at least say away from henges because then you can't throw anything out of the window.

    Quote Originally Posted by john9818a View Post
    Having multiple doors or anything that attenuates sound on the same wall and close together will have odd effects. If for example someone breaks the non-door part of the window and it removes the sound attenuation, opening and closing the door part of the window will add the attenuation again. This will seem odd since part of the window is still broken.
    Yeah I still have this to figure out, good thinking. Perhaps in the end there will simply been no attenuation, figuring the window is super old, and partially busted out.

    Quote Originally Posted by ZylonBane View Post
    Just have two versions of each door model-- one with the glass intact, and one with the glass broken. It should be possible to cobble together some combination of NVRelayTrap/NVMetaTrap/some sound trap that switches the door model to the broken version and plays a shattering glass sound when it takes damage. If you really must have flinders, it might be possible to attach an emitter to the door that randomly spews out some glass shards on command.
    This is good, and what's cool is the thud can still be there per normal, so long as you get so much glass breaking you won't notice it. So the whole object, before 'corpse' version, is safe to have one single bbox with wood material. If the player hits the kickplate it should still make it seam like the vibration knocked out the glass. I should produce the arrow on the floor in front of it so the player can get it back since the pre-corpse object will be made to not let arrows stick. Wait.. I wonder what would happen to a stuck arrow, if the models swapped... if it is destroyed anyway, I can keep the wood metaprop anyway and then place the arrow on the floor.

    This will be a good exercise in learning this stuff to apply to other situation. Thanks ZB, will hack away at it.

Tags for this Thread

Posting Permissions

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