Maybe could you could implement the different types of cameras referenced in the project_yellow tag?
Maybe could you could implement the different types of cameras referenced in the project_yellow tag?
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.
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?
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?
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:
I've uploaded the tag_groups >here<
And the xml, incase i'm doing something wrong in there:
Also, with the shader_postprocess_collection tag, where WERE you going with itCode:<?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>? Compiled into a map, or just a tag loaded externally?
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.
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.Originally Posted by Kornman00
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.
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.
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.
Damn Korn, you should have written OS in nothing but XML. I think I'll do that for my next app.![]()
E:B;eh one second.
So where do I find exception data?
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks