Page 14 of 56 FirstFirst ... 4 12 13 14 15 16 24 ... LastLast
Results 131 to 140 of 557

Thread: OpenSauce Halo CE SDK Update #2 (RC)

  1. #131
    Taiko Drums = Win
    Join Date
    Sep 2006
    Location
    Longbranch, WA
    Posts
    2,692

    Re: OpenSauce Halo CE SDK Update #2 (RC)

    Maybe could you could implement the different types of cameras referenced in the project_yellow tag?

  2. #132
    Kid in the Hall Kornman00's Avatar
    Join Date
    Sep 2006
    Location
    ◕‿◕, ┌( ಠ_ಠ)┘
    Posts
    3,130

    Re: OpenSauce Halo CE SDK Update #2 (RC)

    I didn't use these two weeks to add any real new features left out from the initial RC. Instead I just wanted to get the tools tested, find any hidden bugs and finish up some of the SDK in terms of documentation.

    I'll try to find the original up-side camera code bitter did for inclusion but as far as implementing those camera modes, it isn't happening. Really, the biped camera type and those networking flags shouldn't be declared in a tag definition but instead in user settings. I'm really just thinking of tossing the fields from the editor for the final release as the scenario and it's child data should have no say in those options (or at least, not in the manner of which they're currently presented). I just never cared to remove them from the code and xml definitions since I did them in 2005.

  3. #133
    Senior Member Rambo's Avatar
    Join Date
    Jun 2009
    Posts
    135

    Re: OpenSauce Halo CE SDK Update #2 (RC)

    Quote Originally Posted by Kornman00 View Post
    I need more information than that, please post the actual exception data...


    I don't have the time to research how to implement a switch_lightmap script function. It could just be as easy as changing the lightmap tag reference in real time however, it would be much more I just don't have the time to dedicate figuring out this kind of feature in my free time for this old engine. I provided a base structure in the tag definitions so that someone in the future could figure it out.
    But that's exactly how easy it is. If I run Lightmaps on a BSP, then swap the Lightmaps tag out, what happens is it adopts the new shadows. I can do this and verify it in the form of a video if need-be, provided I am 100% accurate. If this works then all one has to do is swap Lightmap tags. It's just a bitmap that goes over the BSP coordinates, that's it. With no Lightmap tag defined, everything is completely lit with no shadows.

    Also, about the extra client data issue, didn't Bungie do that on purpose when they released 1.07, just to prevent people from hacking you?

  4. #134
    Kid in the Hall Kornman00's Avatar
    Join Date
    Sep 2006
    Location
    ◕‿◕, ┌( ಠ_ಠ)┘
    Posts
    3,130

    Re: OpenSauce Halo CE SDK Update #2 (RC)

    No, I'm talking about at runtime. It may not just be as easy as changing the lightmap reference in the structure bsp definition during game. I'm not talking in any way shape or form about running radiosity.

    What are you talking about? What extra client data issue?

  5. #135
    Senior Member FireScythe's Avatar
    Join Date
    Sep 2006
    Location
    UK, England
    Posts
    321

    Re: OpenSauce Halo CE SDK Update #2 (RC)

    Quote Originally Posted by Rambo View Post
    But that's exactly how easy it is. If I run Lightmaps on a BSP, then swap the Lightmaps tag out, what happens is it adopts the new shadows. I can do this and verify it in the form of a video if need-be, provided I am 100% accurate. If this works then all one has to do is swap Lightmap tags. It's just a bitmap that goes over the BSP coordinates, that's it. With no Lightmap tag defined, everything is completely lit with no shadows.

    Also, about the extra client data issue, didn't Bungie do that on purpose when they released 1.07, just to prevent people from hacking you?
    Thing is, doing that while the game is actually running might not be that easy. There would be more to it such as figuring out when and where to make the changes, managing the resources, handling bsp changes, etc. It's very rarely as easy as it sounds. Plus it's not down to kornman to do it, no harm in having a go yourself .

    Sorry i'm a bit late with this, but there's one more bug for CheApe.

    If I build a CheApe project the tag definitions tend to be fine in guerilla, but if I make a change, such as a field name in the xml, then build again without closing CheApe, the tag definition has a load of gobbledegook names.

    Screenies:

    Right:

    Wrong:


    I've uploaded the tag_groups >here<

    And the xml, incase i'm doing something wrong in there:
    Code:
    <?xml version="1.0" encoding="us-ascii" standalone="yes"?>
    <definitions game="Halo1">
        <flags>
            <Flag name="effect_activation_flags">
                <field>initially active#Is the shader active when the game starts</field>
                <field>active during cutscenes</field>
            </Flag>
            
            <Flag name="shader_collection_flags">
                <field>enable fake hdr</field>
                <field>enable shader effects</field>
                <field>enable motion blur</field>
            </Flag>
            
            <Flag name="motion_blur_flags">
                <field>use vignette#Reduces the amount of blur towards the centre of the screen</field>
            </Flag>
        </flags>    
        
        <enums>
            <Enum name="effect_render_point_enum">
                <field>pre alpha blended faces</field>
                <field>pre hud</field>
                <field>pre menu</field>
                <field>post menu</field>
            </Enum>
        </enums>
    
        <data>
            <TagData name="shader_postprocess_bitmap_file_location_data" maxSize="256" isTextData="true" />
            
            <TagData name="shader_postprocess_effect_source_code_data" maxSize="32768" isTextData="true" />
            
            <TagData name="shader_postprocess_effect_compiled_code_data" maxSize="32768" />
        </data>
    
        <blocks>        
            <TagBlock name="shader_postprocess_bitmap_block" maxElements="4">
                <field type="String" name="value name" blockname="true" />
                <field type="Data" name="relative location" definition="shader_postprocess_bitmap_file_location_data"/>    
            </TagBlock>
            
            <TagBlock name="shader_postprocess_bool_block" maxElements="8">
                <field type="String" name="value name" blockname="true" />
                <field type="ShortInteger" name="value"/>
                <field type="Pad" definition="2" />    
            </TagBlock>
            
            <TagBlock name="shader_postprocess_int_block" maxElements="8">
                <field type="String" name="value name" blockname="true" />
                <field type="LongInteger" name="value"/>
            </TagBlock>
            
            <TagBlock name="shader_postprocess_float_block" maxElements="8">
                <field type="String" name="value name" blockname="true" />
                <field type="Real" name="value"/>    
            </TagBlock>    
                
            <TagBlock name="shader_postprocess_dynamic_float_block" maxElements="8">
                <field type="String" name="value name" blockname="true" />
                <field type="RealBounds" name="value bounds"/>
                <field type="Real" name="change per second"/>        
            </TagBlock>
            
            <TagBlock name="shader_postprocess_pass_block" maxElements="16">
                <field type="String" name="pass name" blockname="true" />
                <field type="RealPoint2D" name="scale" />    
            </TagBlock>
            
            <TagBlock name="shader_postprocess_shader_block" maxElements="32">
                <field type="String" name="name" blockname="true" />
                <field type="Point2D" name="render quad tesselation" />    
                <field type="Block" name="additional bitmaps" definition="shader_postprocess_bitmap_block"/>
                <field type="Block" name="bools" definition="shader_postprocess_bool_block"/>
                <field type="Block" name="integers" definition="shader_postprocess_int_block"/>
                <field type="Block" name="floats" definition="shader_postprocess_float_block"/>
                <field type="Block" name="dynamic floats" definition="shader_postprocess_dynamic_float_block"/>
                <field type="Block" name="passes" definition="shader_postprocess_pass_block"/>
                <field type="Data" name="effect code" definition="shader_postprocess_effect_source_code_data" />
                <field type="Data" name="compiled code" definition="shader_postprocess_effect_compiled_code_data" />
            </TagBlock>
            
            <TagBlock name="shader_postprocess_effect_shader_block" maxElements="12">
                <field type="LongBlockIndex" name="shader" definition="shader_postprocess_shader_block" />            
            </TagBlock>
            
            <TagBlock name="shader_postprocess_effect_block" maxElements="16">
                <field type="String" name="name" blockname="true" />
                <field type="Enum" name="render point" definition="effect_render_point_enum" />
                <field type="ByteFlags" name="flags" definition="effect_activation_flags" />
                <field type="Pad" definition="3" />
                <field type="Block" name="shaders indicies" definition="shader_postprocess_effect_shader_block" blockname="true"/>
            </TagBlock>
        </blocks>
    
        <groups>
            <TagGroup name="shader_postprocess_collection" groupTag="shpc" version="1">
                <field type="ShortInteger" name="version" locked="true" />
                <field type="Pad" definition="2" />
                <field type="ByteFlags" name="flags" definition="shader_collection_flags"/>
                <field type="Pad" definition="3" />
                <field type="Real" name="luminosity target"/>
                <field type="Real" name="luminosity change p/sec"/>
                <field type="RealBounds" name="luminosity change bounds"/>
                <field type="Real" name="motion blur amount"/>
                <field type="ByteFlags" name="motion blur flags" definition="motion_blur_flags" />
                <field type="Pad" definition="3" />
                <field type="Block" name="shaders" definition="shader_postprocess_shader_block" />
                <field type="Block" name="effects" definition="shader_postprocess_effect_block" />
            </TagGroup>
        </groups>
    
    </definitions>
    Also, with the shader_postprocess_collection tag, where WERE you going with it ? Compiled into a map, or just a tag loaded externally?

  6. #136
    Senior Member Rambo's Avatar
    Join Date
    Jun 2009
    Posts
    135

    Re: OpenSauce Halo CE SDK Update #2 (RC)

    Quote Originally Posted by Kornman00 View Post
    No, I'm talking about at runtime. It may not just be as easy as changing the lightmap reference in the structure bsp definition during game. I'm not talking in any way shape or form about running radiosity.
    Radiosity was an example of how I could swap lightmaps and then recompile the map. I didn't mean it as something to be confusing.

    Quote Originally Posted by Kornman00
    What are you talking about? What extra client data issue?
    I was referring to the device syncing problem with respect to extra client data causing the game to boot someone off the server when sending extra data across. I said that Bungie did this as a way of keeping someone from sending "false" packets. All one has to do is go back to the 1.06 EXE and see how the code works there in retrospect to the 1.07 code. They "fixed" that bug, thus preventing us from sending packets across that would sync the clients with the servers.

  7. #137
    Sarcastic Bitch
    Join Date
    Sep 2006
    Posts
    811

    Re: OpenSauce Halo CE SDK Update #2 (RC)

    Quote Originally Posted by Rambo View Post
    Radiosity was an example of how I could swap lightmaps and then recompile the map. I didn't mean it as something to be confusing.
    Korn wasn't confused, he understood what you were talking about. You are the one that is confused. Changing the lightmap tag reference and recompiling the map is not the same as changing it at runtime (while the game is running). Read the very beginning of FireScythe's post, he explains why it more than likely won't be as simple as changing a tag reference.

  8. #138
    Senior Member Rambo's Avatar
    Join Date
    Jun 2009
    Posts
    135

    Re: OpenSauce Halo CE SDK Update #2 (RC)

    OK. It still should work, in theory. You aren't rerunning radiosity each time, just changing the tag. If recompiling it makes it work, on-the-fly lightmap switching should work in the same way switching BSPs on the fly works.

    I'd do it, but I don't know XML or any programming language. I'm just a sound man and script in Halo some.

  9. #139
    Sarcastic Bitch
    Join Date
    Sep 2006
    Posts
    811

    Re: OpenSauce Halo CE SDK Update #2 (RC)

    Quote Originally Posted by Rambo View Post
    OK. It still should work, in theory. You aren't rerunning radiosity each time, just changing the tag. If recompiling it makes it work, on-the-fly lightmap switching should work in the same way switching BSPs on the fly works.
    No. There is no guarantee that changing the tag reference while the game is running will force the lightmaps to change. That would imply that the lightmap tag reference field is constantly being checked for any changes, which it is not. There would be no point in monitoring if the tag reference changes, especially since the lightmap cannot normally be changed at run time. Use common sense.

    This would not have the same effect as the "switch_bsp" command. When you switch a bsp using that command, the new sbsp tag is loaded, as well as all of it's dependents. One of the dependents is it's corresponding lightmap tag. You have no idea what you are talking about, so please stop.

    Quote Originally Posted by Rambo View Post
    I'd do it, but I don't know XML or any programming language. I'm just a sound man and script in Halo some.
    Damn Korn, you should have written OS in nothing but XML. I think I'll do that for my next app.

  10. #140
    Gar TVTyrant's Avatar
    Join Date
    Apr 2008
    Location
    Hillsboro, Oregon
    Posts
    4,690

    Re: OpenSauce Halo CE SDK Update #2 (RC)

    E:B;eh one second.
    So where do I find exception data?

Thread Information

Users Browsing this Thread

There are currently 2 users browsing this thread. (0 members and 2 guests)

Tags for this Thread

Bookmarks

Posting Permissions

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