Have you tried uninstalling\reinstalling Adobe 8)
EDIT: Like I told jcap, this problem isn't new:
http://www.modacity.net/forums/showt...hlight=MSVCR80
Printable View
Have you tried uninstalling\reinstalling Adobe 8)
EDIT: Like I told jcap, this problem isn't new:
http://www.modacity.net/forums/showt...hlight=MSVCR80
Okay, so I'm a complete noob to OpenSauce.
I am trying to get Yelo Battery from the source code. I do not know what I am supposed to build to get it.
I am on VS2008 that I got from college.Quote:
Included is also a new version of Yelo Battery to provide an example of the possibilities of the SDK. Battery can fix the aspect ratio of the HUD on widescreen monitors, adjust the field of view (FOV), and modify weapon placement (anywhere you want the weapon to be held on your screen). There is also full chat logging saved right in your Halo profile folder.
:neckbeard:
When you compile the project, it will create a "d3d9.dll" in your bin folder. Copy that dll into your Halo CE directory, then run Halo. Make sure you are running version 1.08 of CE, since that is the only version OS is compatible with.Quote:
Originally Posted by taterSALAD
If I recall correctly, pressing F7 ingame will open the Yelo Battery menu.
If you just want to use Yelo Battery, you don't need to compile it from source. The source that is currently available for download is only from RC1 and does not contain the recent bug fixes.
The d3d9.dll available for download at the bottom of his post is the compiled version with the most recent fixes. The source code for that will be released with RC2.
Okay, guerilla is working now, and Sapien is asking me for a d3dx9_40.dll now.
After installing d3d9.dll into the CE root, getting lots of issues.
- Game won't even load sometimes. Windows 7 will end Aero to start the game, but it will load right back up after the game crashes.
- After a few initial crashes, the game starts in safe-mode, with horrible quality graphics.
- After a few more crashes, the game starts in normal-mode, and throws an exception upon joining a server.
Here's the data, per request.
EDIT: Found that Xfire was throwing the exception, as said in the Event Viewer and other people on the forum. :P If only it worked with Xfire. |:Code:Faulting application name: haloce.exe, version: 1.0.8.616, time stamp: 0x489a3b7e
Faulting module name: d3d9.dll, version: 2.0.0.1, time stamp: 0x4a984fec
Exception code: 0xc0000005
Fault offset: 0x000067ca
Faulting process id: 0xae94
Faulting application start time: 0x01ca28f61d4eac43
Faulting application path: D:\Program Files\Microsoft Games\Halo Custom Edition\haloce.exe
Faulting module path: D:\Program Files\Microsoft Games\Halo Custom Edition\d3d9.dll
Report Id: 6b0bc164-94e9-11de-b6f6-001676bf3a2e
Did you install the latest version of DirectX? http://www.microsoft.com/downloads/d...displaylang=enQuote:
Originally Posted by FRain
What did you do to get it working? Did you just reinstall Adobe Reader?
Use Acrobat instead of Reader, problem solved. :downs:
Okay, so I got that all working, and then I made my project_yellow tag and my project_yellow_globals tag which included me setting the biped camera to third person loose (deathcam). I wanted to try this out so I referenced the project_yellow_globals tag to my project_yellow tag, and the project_yellow tag to my scenario, and compiled it with OS_toolbeta.exe
I got the whole "this is a kludge" error, so I removed it from my directory and compiled it, moved it back and when I spawned ingame it was just FP.
I put the d3d9.dll back into the folder and then ignored the whole "kludge" error. I went ingame and it was still FP.
because I never got around to implementing that...
Oh, okay.
Product
Halo
Problem
Stopped working
Date
8/30/2009 5:30 PM
Status
Report Sent
Problem signature
Problem Event Name: APPCRASH
Application Name: haloce.exe
Application Version: 1.0.8.616
Application Timestamp: 489a3b7e
Fault Module Name: d3d9.dll
Fault Module Version: 2.0.0.1
Fault Module Timestamp: 4a984fec
Exception Code: c0000005
Exception Offset: 00016686
OS Version: 6.0.6001.2.1.0.768.3
Locale ID: 1033
Extra information about the problem
Bucket ID: 1439092421
Next time post more information than just the exception data :|
I need to know if you were running xfire, SoftTH, DXTweeker etc etc.
I dont know what any of those are, and I exited Xfire 15 minutes before I ran halo.
have you tried running it since this last crash? if not, give it three more tries
What does the OS_haloceded do? I take it it's just a dedi which can run Open Sauce? Are there any other special features to it?
Still exceptions.Quote:
Originally Posted by Kornman00
Happens when I click Open or Save.
-Snip- Imaged redirected to a different one...
This dll is from Autodesk Inventor 2010 Professional.
Also, TortoiseSVN will cause Guerilla to do something like this as well. And Open Office will cause Guerilla to get a similar error when you right click while on the open and save screen (like when trying to make a new folder).
I used to have TSVN installed, but don't recall if I ever ran the HEK while it was installed so I can't say if I ever had a problem with it.
http://www.modacity.net/forums/showt...hlight=MSVCR80
I'm pretty sure the problem stems from how I package the tools, but thats the only solution I can offer at this time. If it was a more widespread problem I would have tried harder for a solution but its not something that pressing to me as there are work arounds.
I can't uninstall it. I need it for school...
This tuesday will mark the two weeks after release. This weekend is when you can expect the final release of Open Sauce. The bug fixes and any additions will be included of course.
For those with Guerilla problems: If you're getting dll errors for Adobe or other programs, try closing any processes (not just programs) which are for that program then try using guerilla. I had that guerilla Open Tag dialog issue once when I had just used Acrobat, but later on it worked without a problem and nothing related to Adobe was running. This is an unconfirmed bug fix, this is just something I noticed. So if someone else with the problem can try this that would be great.
On the topic of Synapse. I've bit my tongue on this for too long and now the taste of iron is just getting too much. The whole re-announcement of C&S was done unprofessionally and premature. It was handled in a way which we try and preach to new comers on how not to handle their map creations: Don't post until you have something tangible. In other words: don't get ahead of yourself which I feel is what we did especially considering the team size. Yes, we have the grounds for the web interface but we were able to carry some of that over from back when this was H2V related and there are many other pieces to the puzzle which still aren't complete or targeted. I agreed to the project because I would love to see stats for this game, and still do. However it was after I told myself that I would start pushing away from Halo 1 affairs as it really is holding me back in learning and creating new technology (I do this in whatever free time the us gov't gives me remember...). I'm really tired of being depended on for a project which I shouldn't have committed myself to to begin with. It's not that I can't complete the Synapse side of the project, I can. I know what needs to be done to get the awesome stats we have planned and how to do it. However I didn't take into account at how burnt out I'd get from pushing Open Sauce out the door.
I've dragged this post out too long. I'm taking it upon myself to declare Synapse development on hold publicly. Development for it will still continue, but I feel the project needs to go under the radar until we have something more for the public to consume. Doing that I feel is better than keeping people wondering whats going on and\or posting time tables which don't meet just to post a new one and so on.
I kind of suspected that.Quote:
Originally Posted by Kornman00
I realize this is a little late to ask for, but can you please incorporate the switch_lightmaps and structure_lightmap_index commands so we can use dynamic lightmap switching? Thanks.
Also, when this comes out, will you please include the DLL this time so we don't have to ask for it like last time? Thanks a ton Kornman00.
So do I rename the d3d9_20090829.dll to just d3d9.dll? How does this work? I have put it into the folder, but when I hit F7 for Yelo, nothing happens.
Yes.Quote:
Originally Posted by TVTyrant
Did it and got an instant exception. Halp.
Says this:
Was Xfire running? This doesn't work with Xfire.
I've tried it with xfire on and off. Doesn't work either way.
Should I try safe mode?
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.Quote:
Originally Posted by Rambo
Does it complain about DirectX 9 not being installed? You need DirectX 9 with this.
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.Quote:
Originally Posted by Kornman00
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 :downs:.Quote:
Originally Posted by Rambo
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 it :p? Compiled into a map, or just a tag loaded externally?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>
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
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.Quote:
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.Quote:
Originally Posted by Rambo
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.Quote:
Originally Posted by Rambo
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. :rolleyes:Quote:
Originally Posted by Rambo
E:B;eh one second.
So where do I find exception data?
XP:
Quote:
Originally Posted by Kornman00
Vista:
Start>Control Panel>System and Maintenance>Problem Reports and Solutions>Find Halo report at specific date/time and copy to clipboard
W7:
Start>Search for "View all problem reports">Find Halo report at specific date/time and copy to clipboard
That stuff?
Yes, that is correct.Quote:
Originally Posted by TVTyrant
Fixed. Wasn't resetting a few things when there was a re-importQuote:
Originally Posted by FireScythe
The tag was to be built into cache files so that people didn't have to use external files like you initially had with your post-process demo
Ah ok then. I'll probably still have external shaders aswell, for global effects, with compiled shaders for map specifics, but that's for another time :P.
About the lightmap thing, I would code it myself, if I knew XML, but I don't know any program languages except some HaloScript.
If someone could generate a library package with support for the lightmap functions I requested so we can at least find out what happens, I'd greatly appreciate it. Again, I don't know any programming languages at all. Sorry guys. I just want to see how well it works. I have this hypothesis it will work just fine, but I want to see to be certain.
If I were to program it, how would I go about it? I might ask around to see if there's people that could code it, but they'd need to know to what specifications and how.
OpenSauce is not written in XML, nor is it even possible to write a program in XML. OS is written in C++, the only part of it that uses XML files is when defining custom tag groups. I don't know what your fascination is with XML.Quote:
Originally Posted by Rambo
Did you just completely skip over or disregard my post?Quote:
Originally Posted by Rambo
If somebody is going to go through the trouble of telling you how to do it, they might as well program it themselves.Quote:
Originally Posted by Rambo
The part needed to add the script command is done in XML, but it needs to reference the stub code in OS itself for the solution to work, for example, the index for the script and what not.
I was asking if someone could please program that "connection point" between the stub code and the end-user by programming the XML part knowledgeably.
And I didn't mean to skip over your post or be an asshole.
Dude...someone doesn't just sprinkle magic dust on some code and all of a sudden things work. Someone would actually have to reverse engineer the game engine to figure out how it goes about updating to the render current lightmap, then program a script function in C++, as thats what the codebase is written in, to force that update to happen with a new lightmap. Things just don't appear out of thin air
Fine I give up. I suggested the idea because I thought it would be fairly simple to get in-game, not knowing any programming languages. I thought that the current rendering part of the engine could handle it as-is and that all it would require was just coding into Open Sauce. Since it's obviously more complicated than that, or so it would seem, I'm done with it. I'll just assign my 64 lightmaps to 64 BSPs and make a huge filesize map and be thankful for that, even if it's at the expense of others for having to download such an attrocious filesize just to switch lightmaps more smoothly.
It shouldn't have to be that way. I still think it can be done, yet I'm stuck with "what is" because I'm a n00b that can't code a thing outside of Halo. I'm just stupid like that. I've never been good with coding or modeling (not that that even matters) or any of that stuff.
I'll just stand back and read from now on, since I feel so worthless and unwelcome here in this thread. After all, it's not my area of expertise, now is it?
Whoa there, no ones saying it isn't possible, were just saying you need to find a programmer who is willing to do the hard work for you. But it's probably not going to be anybody here.
Back on to OS, in the final release, is it going to be possible to create our own utilities for OpenSauce IDE? Or is that purely for your own use?
This, dude. You're way too fucking ahead of yourself. I'm not a coder I have no idea how to code and no idea how C++ is written, the only language I know is HaloScript, but I already know that changing lightmaps during runtime is going to be a pain in the ass thats probably even not possible and you'd have to completely rewrite a shit ton of stuff before it works.Quote:
Originally Posted by Kornman00
No. I don't see what the point would be. Yes it would be nice to have a single-entry-point tool for developing, but I really don't have the time to create and test a new plug-in interface for it. More was planned for it (a couple useful tag based utilities) but I just never got around to creating a UI side to some of the tools. There is even a CheApe system for H2V but I never got around to implementing a Yelo for H2V's runtime so there isn't much use there.Quote:
Originally Posted by FireScythe
Didn't want to read 16 pages to find this out sorry. But my question is if I compile a map with this, will someone else need this SDK to play it?
Only if you take advantage of OS-specific features. If you use the OS HEK without touching any features such as gravity, you will not need OS to play.Quote:
Originally Posted by UnevenElefant5
Is it possible to compile a map that has the gravity changed? Because i imagine that if things were not like that it wouldnt sync.
E: Wow this was a retarded post.
jcap just told you, if you would use gravity for example, you WILL be needing the OS to let it function properly
I remember reading something about a manual some long time back... did that come out somewhere I didn't see, or is that gonna come out sometime eventually?
I'm interested in it enough that if I get it, I might come back to CE, but w/o a manual.. I don't want to spend a whole lot of time reading the source to figure it out myself.
A rough draft of the documentation is included in the SDK RC download
The final release hasn't come out yet due to my day job being overexerting this past week. I really haven't had time to both relax and do my "night" job
It is probably better if you do read the source. The code portion of the SDK isn't meant to be a high level API, but more of a guide into manipulating the engine. Just browsing the code can reap benefits from knowing what all is happening in the background in each component. It's just like any SDK, the documentation will only take you so far. Getting neck deep into it's provided source will take you further. Putting it all together will take you all the way. However I really can't sit down and do a super manual for the SDK, I can't allocate that much of my free time to this anymore.
I've just noticed that opening Guerilla creates two guerilla processes, is this normal?
E: So do tool and sapien.
yeah its a compadibility issue. its required for os_tool and os_sapien to use all the OS feats properly... :S....
Okay in the hek, if you compile or ever get an error saying "can't find i've got a lovely bunch of corncobs.project_yellow" from OS_Sapien's debug.txt:
Just create your own tag like that from Guerilla.
That tag name is internally used. Did you not set your scenario's project yellow reference before loading os_sapien? If you're not using open sauce then you should be using the stock HEK programs instead.
I did not realize that there was a new tag field called "project yellow definitions" at the top of the scenario tag. So nope, I didn't. Another thing to note is that for some reason the field is set to that automatically.Quote:
Originally Posted by Kornman00
e: I'm going to edit my OS quick debug/tutorial thread.
I fixed the code so it shouldn't be an issue in sapien anymore
Thanks. Any word on an Update #3?Quote:
Originally Posted by Kornman00
Since when was there a 2nd Release Candidate?Quote:
Originally Posted by Dwood
lol yeah... I meant Update #3Quote:
Originally Posted by ShadowSpartan
Also, as far as I know the next release is final.
something i don't think anyone else thought of... but... for the gravity stuff in the globals tag. is it possible to set that as a base normal gravity for the map and set up different local gravity's within trigger volumes or something?
say the level's in a ship with artificial gravity. as soon as you leave the ship you enter a trigger volume that changes the gravity relatively from full gravity to no gravity. or would that be asking too much of CE? lol
and just out of curiosity... with the multi biped in the yellow globals... what allows us to choose between 1 or the other?
You could potentially do something like that. However you'd have to setup a tag block in your scenario's py tag- Wait no scratch that, the py tag is closed source. You'd have to create your own scenario_trigger_volume_extension tag or something which has a tag block which takes the name of the trigger volume and a real value for it's gravity. Then you could just have an Update function check to see if the local player (this would only work for campaign) is in any of those, lets call them gravity well volumes, and then update the gravity to what that extension says.
you could end up with something like:
If this was halo 2 or later, you'd have the benefit of a mapping_function to define a much more robust interpolation function.Code:scenario_extensions
* tag_block: scenario_gravity_well_block
- tag_string: trigger volume name
- word_flags: flags
- use interpolation
- short integer: interpolation speed (game ticks or something)
- real: gravity f(x)
- real_bounds: gravity interpolation range
For your second question: it's not implemented...please explore the source code.
thanks. not much of a programmer. so ill have to look into it a bit when i get an editor.Quote:
Originally Posted by Kornman00
Would it be possible to have something that pushes the person too, like gravity + an angle?
Me and Dwood were trying to figure out this problem, haven't solved it yet:
Everything needed for OS (DirectX SDK March 09 and Boost C++ Libraries all set up in Project Directories) are set, so I have no idea what's going on.Quote:
fatal error RC1015: cannot open include file 'afxres.h'
Google said that afxres.h is installed with the Microsoft Platform SDK, in a MFC Folder. :/
It's not installed on the express editions of visual studio. You can just delete the Halo1_CE.rc file.
I don't use Express edition of VS (which doesn't have MFC). You'll need to delete the resource data in the DLL's project. I only used a VS_VERSION_INFO (or w/e it's called) resource so it's nothing terribly important
I deleted the Halo1_CE.rc file, it resulted in:Quote:
Originally Posted by skyline
Korn, unfortunately I am having trouble locating the resource data for Halo1_CE. Is it the resource.h in the Halo1_CE folder?Quote:
1>fatal error RC1110: could not open .\Halo1_CE.rc
1>Project : error PRJ0002 : Error result 1 returned from 'C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\rc.exe'.
Remove the following from the Halo1_CE.rc file:
Code:#define APSTUDIO_READONLY_SYMBOLS
/////////////////////////////////////////////////////////////////////////////
//
// Generated from the TEXTINCLUDE 2 resource.
//
#include "afxres.h"
/////////////////////////////////////////////////////////////////////////////
#undef APSTUDIO_READONLY_SYMBOLS
and optionally (doesn't do anything):Code:#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)
#ifdef _WIN32
LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US
#pragma code_page(1252)
#endif //_WIN32
#ifdef APSTUDIO_INVOKED
/////////////////////////////////////////////////////////////////////////////
//
// TEXTINCLUDE
//
1 TEXTINCLUDE
BEGIN
"resource.h\0"
END
2 TEXTINCLUDE
BEGIN
"#include ""afxres.h""\r\n"
"\0"
END
3 TEXTINCLUDE
BEGIN
"\r\n"
"\0"
END
#endif // APSTUDIO_INVOKED
E: Forgot to mention you can't directly open the .rc file using the express edition so just edit it with a text editor if you need to.Code:#ifndef APSTUDIO_INVOKED
/////////////////////////////////////////////////////////////////////////////
//
// Generated from the TEXTINCLUDE 3 resource.
//
/////////////////////////////////////////////////////////////////////////////
#endif // not APSTUDIO_INVOKED
Thanks FireSythe, got it working :D
Now, does anyone happen to have the source for the d3d9.dll plugin on the first post, that has the updated stuff in it?
Ugh. You didn't remove the file from the project...Quote:
Originally Posted by CodeBrain
Quote:
Originally Posted by skyline
Quote:
Originally Posted by FireScythe
?Quote:
Originally Posted by CodeBrain
MacrosCpp.hpp
LoL whawhawha redundant muchCode:#define MACRO_JOIN_TOKEN3(a, b) a##b
#define MACRO_JOIN_TOKEN2(a, b) MACRO_JOIN_TOKEN3(a, b)
// Join two macro arguments, even if the argument is a macro as well
#define MACRO_JOIN_TOKEN(a, b) MACRO_JOIN_TOKEN2(a, b)
Were you just bored here ? haha :downs:
Actually it's allegedly needed to join Macros, but what's worse is him having that while using the boost version too:
(from BlamScriptingDefinitions)
#define HS_TYPE(hstype) BOOST_JOIN(Yelo::Enums::_hs_type_,hstype)
(from the BOOST library)
not sure why.. maybe he added boost later, after making his own macro to combine macros.Code:// Helper macro BOOST_JOIN:
// The following piece of macro magic joins the two
// arguments together, even when one of the arguments is
// itself a macro (see 16.3.1 in C++ standard). The key
// is that macro expansion of macro arguments does not
// occur in BOOST_DO_JOIN2 but does in BOOST_DO_JOIN.
//
#define BOOST_JOIN( X, Y ) BOOST_DO_JOIN( X, Y )
#define BOOST_DO_JOIN( X, Y ) BOOST_DO_JOIN2(X,Y)
#define BOOST_DO_JOIN2( X, Y ) X##Y
Very epic. Should have read that over again. If there's one thing about Kornman00 I will never forget, it's that he loves macros and macros inside macros! :downs:Quote:
Originally Posted by Aßyll
I have been looking more into OpenSauce and it's starting to pull together for me. I wasn't aesthetically pleased at first, but it sets in after some time staring at it. Usually have to open 8 files to figure out a line of code, those dang fishy macroronies. hehe
Abyll, I have been thinking about it, using OS for Forge and that other..secret project..
If only I could fix Xfire grabbing an invalid device pointer...ugh
Yeah, boost came later, those macros were from the old Project Yellow days. I think COMPILE_ASSERT may also still be lingering in the cpp macro definitions which I've since replaced it with BOOST_STATIC_ASSERT.
Macros can help in areas where I don't want some hidden compiler inititializer thunks and instead just want the compiler itself to initialize the data. However, sometimes the compiler will still amazing do both (even in optimized builds). *sigh*. That's not the only reason I use them but they really are a great tool when used properly (not saying I always use them properly though heh).
Xfire should just look at being more friendly with it's interfacing.
did kornman just do a
"bad Xfire... you shouldn't go doing things like that!" ???
lol
meh Xfire sucks anyway XD
Question,
and sorry if im bumping i dont mean to but i would enjoy knowing this
Does this DLL work for FV(Full Version)? Or is it ONLY Custom Edition?
One thing to note is that both versions are full. And no, it is not. (Only works in Halo CE)Quote:
Originally Posted by Helixv3
Open Sauce is only compatible with the Custom Edition version of Halo PC. On another note, is this who I think it is? You can at least be a little less obvious e3po.Quote:
Originally Posted by Helixv3
Im not e3po...Quote:
Originally Posted by ShadowSpartan
Previous Names
Avensys
Genesis
Triple Helix
Helix
=] If you know me by one of those names then yes it's me.
Why do all caches have a salted index and a normal index for their instances instead of just a normal index? I just noticed that the first two letters of the DataHeader name is ORed with 0x8000 as the first salted index, then increased from there. Thought it was kinda cool, but can figure out why Kornman!
The vista side of my macbook went kaput after almost 34 months of use. However, since I can run OSX fine, I don't think it's hardware related (unless OSX is just THAT awesome...hmmmm).
So yeah, until I get an alternative dev environment up, all endeavors of mine are down for the count. Expect designing. Don't need windows to design new things. Just the code development part heh.
I guess it's fitting, since I'm moving next week and need to pack anyway vOv
Man, that sucks. Good luck with the move and hope things will get back to normal for ya :downs:
On another note, while reversing a function, I was referencing off your object definition struct for offsets and found a minor struct error. Your object_header_block_reference struct is backwards, the size is first and offset is second.
Example of it being used in CE 1.08:
Which is object_data.NodeMatrixBlock.Offset into edx, then object_data + offset.Code:004F9D22 MOVSX EDX,WORD PTR DS:[EBX+1F2]
...
004F9D33 ADD EDX,EBX
If you go to the address put in edx, it's the matrix block. If you highlight the matrix block, it adds up to the size at object_data + 0x1F0. So, just thought you might know in case you ever go to use it.
E: Also, do you have node matrix definition in OS? I can't seem to find it. I know that it's always 13 floats: first float is usually, if not always 1.0f, the next 9 floats are unit vectors, and the last 3 floats are node world position. This is an unusual matrix, do you have any information on it?
Found a bug, although you've probably already fixed it, but here it is just in case.
In YeloSettings.cpp the LoadSettingsUser function doesn't close the file that it opens, which stops any settings from being saved later on. Also, in some of your components' LoadSettings functions you have "int32 i" being declared inside the if statement that reads from the settings file, which results in the component always loading default settings.
Also, in Main.cpp the Settings component is initialised and loads all settings first, but should to settings not be loaded last? As currently it loads the settings of other components, which are then initialised afterwards, plausibly reverting any loaded values to defaults.Code:int32 i = 0;
if (file != NULL && fscanf_s(file, "[FOV]\n") != EOF)
{
int32 i = fscanf_s(file, "vertical radians: %f\n", &_fov_globals.fov.vertical);
fscanf_s(file, "\n");
}
//i will always be zero
if (i < 1)
_fov_globals.InitializeToDefaultSettings();
Yeah, those were the fixes I had to apply to get the settings working. At least C# will typically inform me of silly mistakes when redeclaring variables in child blocks.
There shouldn't be any cases in my own use of the system where the settings are modified in the component's Initialize function. The settings initialization should all occur within the LoadSettings crap, even when it is just to set them to the default values.
The Initialize\Dispose system should really just be for runtime based computations. If the settings are known before the Yelo game state begins, then the initialize code can perform any game changes based on variable settings once and should treat all setting values as read only. It's not until the Yelo update state begins where it should be assumed safe to change the values of the settings.
Could a better system been created? Of course (think XML). I really just wanted to keep a very simple system in place and decided to reuse the old Battery code with some adjustments in code flow and such. Allowed more time to be spent on other things
Hey Korn before the final release of Open Sauce can you look at opening up Hud_Messages for editing in Guerilla?
What are you talking about? There is no "hud_messages" tag type, are you talking about "hud_message_text"?Quote:
Originally Posted by Dwood
Yes.Quote:
Originally Posted by ShadowSpartan
Odd, some of the fields for that tag are still locked. You can use Korn's old Guerilla, it edits that tag fine.Quote:
Originally Posted by Dwood
Thanks! I didn't think of that, sadly >.>Quote:
Originally Posted by ShadowSpartan