Yeah, unfortunately, the ones who do know C++, are busy :(
Printable View
Yeah, unfortunately, the ones who do know C++, are busy :(
Or are quitting modding.
I'm looking at you shadowspartan.
He never had enough C++ experience to mess with this.Quote:
Originally Posted by Inferno
Does anyone know if this warning matters, as I'm 99% sure I am getting the same one. Also who else is getting exceptions whenever they kill an enemy? I'm really keen to get it working properly so I can test out multi-team vehicles and figure out how to ajust gravity (I think I heard Open Sauce allows ajustable gravity).Quote:
Originally Posted by bobbysoon
You can still do all that with the stock DLL (adds a (gravity) global), just don't kill anyone.Quote:
Originally Posted by Rhydgaled
Actually its a global, but oh well :rolleyes:Quote:
Originally Posted by p0lar_bear
I never really saw anyone really take to OS. True, the code organization is rather horrid, but its legacy from when the project first started (2004\05). There are a few things which I would lay out and do differently (using a precompiled header for starters) if I were to recode it from the ground up today. However there are other things which I'm busy working on which I will sport for my demo reels as I only have about 12 more months in my current job left (not counting vacations :party:). Some of the works may carry over to you Halo people. Not making any promises or statements to raise false hope.
So as far as OS updates go, I never saw a high demand from developers so there wont be a high supply in development...from my end. If there were some biters, then maybe I would change my mind. Note, I'm not pulling a gearbox (sorry gbx) when I say that either; you dont need to find 1k developers for me to come back to this...then not have me actually come back.
Due to recent life events, I can't take up working with OS (am much as I'd love to), but what's killing me is a lack of API documentation. I have no idea what I can and can't do with Open Sauce, what shortcuts exist in the form of pre-existing functions and methods (Occam's Razor) etc. Only people really dedicated to CE modding would have the time and patience to browse the code and take note of everything, and it seems that that type of person is far and few today.
I know you're busy as well, but I thought I'd throw that gripe onto the table.
I wish I knew how to program, otherwise I'd be happy to mess with this for weeks on end.Quote:
Originally Posted by p0lar_bear
I can teach you some Java to get you started.... :PQuote:
Originally Posted by rentafence
So gravity ajustment was included in the stock .dll then, thanks for clearing that up. I was thinking of trying out a sp level with a section in space, so if I ever get round to working on that particular idea I would use the sauce, except you won't be getting very far in an sp level without killing somthing (unless you use cheat deathless player).Quote:
Originally Posted by p0lar_bear
I know a litte Java too, and some Delphi, but even if the one of the languages I know was C++ I don't think I'm anywhere near the level I would need to be to do anything with open sauce.Quote:
Originally Posted by Dwood
I only registered just to post this.
It's a nice source Korn, though it's very poorly documented. I had to search around to even figure out which address is which in the engine pointer functions.
It's a pity to say that you basically wasted your time with this. Not many on this forum are even capable of programming in C++ and even if they can, it requires an extensive knowledge of not only the language itself but also about the engine.
I would be able to use the source but I would not because I, like many developers, prefer to write my own style of code (even though yours would be more clean, efficient etc.). So, for whom did you write this?
If it's meant for the general public so they can call the ToggleMultiTeamVehicles() function and say that they coded a proxy dll, then you don't really have my support.
It took us months, even years to figure out stuff like this why should we (you) open the doors so easily? This source code and how it's handled shows very well that not the resources given make a great product but the dedication and intentions behind it. It would have been better that you mapped out the engine, documented parts and how they worked.
I don't want to show off but if I am already here...similar to Bitters:
Quote:
Originally Posted by Eluveitie
By the looks of it a user manual was/is planned. If and when this is released maybe extensive knowledge about the engine won't be so necessary to any developers interested in using Open Sauce. Although at present I would be way out of my depth if I went looking at the Open Sauce code, I expect I would take a good look at the user manual in the hope of understanding enough to make a stab at doing somthing with the sauce (I probablly wouldn't understand enough, but I think it would be worth a try).Quote:
Originally Posted by Kornman00
EDIT: Eluveitie, I just watched your gravity gun video and thought "Forge", it isn't exactly like Forge, and personally I don't see the point in making Forge for HALO Custom Edition anyway (we have Sapien, far more powerfull tool (although 3d weapon placement for netgame equipment would be nice)). That said I've seen some topics (probably on halomaps) asking for a Forge mode to be made for CE, which is why I decided to bring this up.
Quote:
Originally Posted by Eluveitie
Code:if you share your findings, then
Open Sauce += engine function pointer table
Kirby was working on it last I heard. In fact, he has a few things scripted. Like moving rocks etc. around.Quote:
Originally Posted by Rhydgaled
I just bought a C++ book for beginners and am about halfway through it so hopefully I will at least be able to understand what's going on on a rudimentary level.
I don't see a reason why he shouldn't share the info so openly. Just because you've been grasping at it for years, you're asshurt about it? Get fucking real. Kindly fuck/kill you're saelf.Quote:
Originally Posted by Eluveitie
I'm on my iPod
I released to see if things would take off. While I normally am very closed source with even "close friends" when it comes to Blam!, I was finding it harder to justify continued development. I hoped with a developer base to give the demand I could continue the supply part. However things didn't take off. The plan was to even go as far as adding Yelo Xbox to OS. There were tools made for h1 that I was in the process of porting to work with h2 xbox/pc, like the custom tag definition util.
Really it comes down to finding reason to continue on the old when I still have new works (h3,Torque,etc) which I also have to dedicate time to. I'm VERY stingy with my time and how it's spent. I consider it money even when it doesn't bank in anything, to help keep focused.
Seems like Korn and me have to commit suicide then. You shouldn't talk about a subject you don't know anything about. And no, don't even compare this to 3d modeling.Quote:
Originally Posted by SnaFuBAR
You sound as stupid as the people who cried about Bungie revealing the secrets of Halo 3 screenshots :\Quote:
Originally Posted by Eluveitie
The engine is becoming old and outdated. While I always try to keep bungie's IP that I uncover underwraps, I also get sick at the wasted oppertunity that was available for crafting a mature nodding environment plus community. The engine towers over the other moddable engines. I only agree with open source to a certian extent, and opening up and documenting a engine that isn't mine is out of the question. There are engine aspects still in use by the latest Blam! albiet not the same implementation from h1. I only chose the parts which I thought wouldn't jeperdize the integrity and confidentiality of today's engine.Quote:
It took us months, even years to figure out stuff like this why should we (you) open the doors so easily? This source code and how it's handled shows very well that not the resources given make a great product but the dedication and intentions behind it. It would have been better that you mapped out the engine, documented
To top it off I get sick of seeing the engine disgraced with the typical shit produced from copycats (a la HMT). Maybe that helps your "why now?" question. Keeping your 'high seat' shouldn't interfear with trying to correct the problems at hand. Leave that to the bullshit politics.
Sorry, have to use my iPod for replying still. Not the best foruming method
Why the hell shouldn't kornman "open the doors"? Because we're all retards who don't know how to code? Because you're speshul for knowing how the engine works and you fear that if other people know stuff, you won't be so speshul? It's true that there are virtually no Win32 programmers in the CE community, but that isn't a reason to withhold resources from the general community.
It may be a waste of time, but if you knew anything about CE's history, you would know that the information pool has grown since CE's release, where all we had was a single tutorial on how to create a collision BSP and import it into the game. And guess who filled the pool? Everyone. If it weren't for people exploring and adding their knowledge and resources to the general collective, CE would have gone belly-up quicker than Halo 2 for Windows Vista.
I'm not saying that you need to tell us everything you need to know right now, but that you shouldn't be criticizing someone on releasing potentially valuable tools and information because the community is incapable or because knowing this information somehow makes you special.
PS: Snaf's post was correct, thank you very much. Plz2b fucking you're saelf.
I don't need to know jack shit about something to know you're being an immature crybaby prick. No, no dyslexia, it was an inside joke that is used around here. Nice attempt. BTW, your reading comprehension is lacking if you can't tell I was suggesting you off yourself because of your uptight attitude. Just because you've been working at something for years doesn't mean jack shit when it comes to other people developing something. So like i said, kill yourself, or answer why he shouldn't open the doors for others. Your years of work and selfishness is not applicable.Quote:
Originally Posted by Eluveitie
Not applicable to Karnmon00 unless you plead and plead and possibly pleasure him.
Thanks for visiting again Patrick.
This has absolutely nothing todo with "crybaby" or me losing status. I had never had any problems sharing my knowledge with other people...Korn was always the one keeping everything in the dark. He was the one having all the knowledge for 3 years and he didn't share it and now that it's basically dead he releases something...but I don't blame him...I can understand him.
There is a difference between giving out a source code or sharing knowledge. Grenadic showed us the map file structure and didn't release a source code so we could have 5 versions of HMT.
This source code only extends knowledge to just a few people so don't pretend that this is something useful for the community if only 3 people can really even read it.
I don't really care but you guys are always the ones starting to cry about any type of Bots...well here are your "doors" to it.
@p0lar
Don't talk about CE's histroy. I was there back then when you registered.
@Snaf
Don't call me selffish as I have shared my knowledge more openly than Korn. I don't care about your little forum inside jokes...if you people don't have a real social life I don't care if you shat bricks or fucked you're self.
just b/c you think there are only 3 ppl in this "coumminty" doesn't mean there is. There are lurkers, passer-bys, academics and potentials who may use the source as a starting ground for what is a new science to them. Don't think so relative. The knowledge is never for anyone to give out unless from the original creator(s). I didn't make the engine and neither did you.
Eluve why do you even care? Anyways, Korn, I'm taking a look at Open Sauce in-depth for once. It seems Open Sauce doesn't play with MS VS C++ 2008 very well but hey it opened right up. ^_^. If I have problems playing with it I'm going straight here. Also, what areas do you recommend to look at first? I did main.cpp but I can't decide where to go from there.
Im with KM on this one.Quote:
Originally Posted by Kornman00
he's done so much for the community already, and all to lend us a hand.
it would of been easier for him to not bother and leave this community rot but because of him where still here.
Modacity exists and so does it's little community.
He's already proven his worth time and time again, and where yet to see you come up with anything for us, so why should we listen to you.
E: alias's for the loose.
main.cpp has all the component initialization references, just trace the call graph for each component (ie, Console or GameState) to see whats being done behind the scenes.Quote:
Originally Posted by Dwood
Use your iPod to read my PM about the Delaggonator. :embarrassed:Quote:
Originally Posted by Kornman00
Your still a selfish faggot. :caruso:Quote:
Originally Posted by Eluveitie
sup guys
so is what I just downloaded really the halo CE source code?
how does this not cost money?
Ugh, no, read the first post again.Quote:
Originally Posted by DrJaul
This basically allows you to create your own tag classes, script functions, and script globals.
yeah I gleaned all that from the first post. what I want to know is exactly what am I holding right now... and when I compile it as is what will it make? is it the engine code? a modding tool? what?
LOL
Given you read the whole thread and compile it correctly, it will spit out a file called d3d9.dll. If you put this into the CE directory, you will have multi-team vehicles, the ability to maniuplate gravity through an added (gravity) variable, and you will only see servers that are running with the same build of d3d9.dll as you.
And unfortunatly whenever anything is killed the game will exception:( Unless somebody has fixed that of course (I would try and fix it myself, but I wouldn't know where to begin, although I can program (kind-of) this is way above my level as far as I can tell).Quote:
Originally Posted by p0lar_bear
Main.cpp @ Line 241 comment outQuote:
Originally Posted by Rhydgaled
and you shouldn't encounter that exception anymorePHP Code:COMPONENT_NON_DEDI (Yelo::Statistics)
Hoshi- thanks.
Has a build been uploaded?
I got that line at 113Quote:
Originally Posted by Kornman00
I dl'd OpenSauce_20081116_1350EST.rar. Is this the latest version?Code:COMPONENT_NON_DEDI (Yelo::Statistics) // No active code in Update currently
Thank you:D, oh and do you mind if I upload the working .dll to halomaps? (To everyone else, I tested it out on bloodgultch ai for a short time and it seems to be working now, I went and played around with the gravity dev command afterwards).Quote:
Originally Posted by Kornman00
Bobbysoon, I also found the line: "COMPONENT_NON_DEDI (Yelo::Statistics) // No active code in Update currently" to be at a different line number to the one Kornman said (I think it was line 113 but I'm not sure).
Yeah, uploading a version without the statistics compiled in is fine. Be sure to include a note of that change to the source to fix those issues.
Also, I was referencing a the internal Main.cpp by mistake. I run a tool over the source and project files to perform any changes to the source needed for public releases (making some source files have more or less code). This helps with removing code which hasn't been fully tested and\or implemented.
Obviously statistics wasn't meant for AI, so a check needs to be put into place to tell if the killer or killee unit has a player index and if not, ignore the statistics record event, thus once again enabling statistics. That or have a special branch which details AI related killings.
Kornman00, I was ecstatic when I looked through your sauce. I had been working hard last summer on reversing the dynamic object structures, I'm sure you seen my documentation. I had posted my findings and have written smaller SDK's after you posted this, but I didn't know about this until a week ago. You are a really great coder and an even better reverse engineer! This has given me a great push towards better development.
Would I be able to use some of your data structures? I would use your complete source to expand on, but I really am not use to your coding style and it bugs me in some ways. Mainly your abundant use of macro functions, seems a bit overboard, especially when you wrote out every static address. I know in-lining functions are more efficient, but was all that necessary? Between the lowercase notation and awkward struct/func names, it's really quite the task to understand, especially when there is a huge lack of comments. Without a manual or documentation/wiki, most of this will not make sense to the casual Halo programmer, unless they are familiar with the engine. :( You may also want to look a bit more into making the d3d wrapper xfire compatible. Xfire also hooks Reset, possibly other functions and will be a major cause of crashing when it's called. I think xfire only hooks the first 5 or 6 bytes, so maybe hook deeper into the functions?
So I guess what my real question is, how do I go about using these reversed engine structures in my projects without breaking your license agreement? All my work has been GPL open sourced since I started programming, so do I need to include your entire source or just include copies of the used files or use your GPL or my GPL? What do I need to do on my end so I'm legal?
Hope we can collab one of these days, unless you are more on the independent side? I can send you some of my stuff.
Great thanks for this :dance:
Skarma:
Not all macros declared were meant to be used in place of a function. The macros used for defining engine-build dependent symbol addresses are one of these. In order to use the addresses in both the assembly and C++ code, a constant was needed which is what I used, an enumeration value.
Also, some data structures needed some rather nasty initialization schemes like declaring custom packets in MessageDefinitions.cpp or in the scripting code. Other uses can be exampled in TStruct which was more of a kludge to accessing engine objects which I didn't have the entire layout of. The fact of the matter is macros aren't just the old C way of declaring "inline" functions, they also help ease the pain of repeated code\data declarations and hiding away rather ugly implementations which you have to use since the code itself is interfacing with an alien system you can't change.
The underscore naming convention was used in the Halo engine so I decided to keep with that when it came down to engine related code. However in my own code I perfer CamelCase. I can't stand java's convention and never understood the point of lowercasing the first letter of the word while uppercasing the rest. IDK, maybe its just my OCD.
Yelo doesn't "hook" into the DX system, it acts as an inceptor with its own definition of the IDirect3DDevice9 interface. From there it forwards calls to the respected DX implementations, while performing any custom code. If Xfire hooks the DX system, it should be retaining the code it replaces. I don't think they would just assume the DX functions they hook into have the same bytes in each version that comes out, so they would have to have a dynamic way of handling the code they overwrite (so that its still executed when they return the IP back to the original code).
If you're not intending to use the source in the projects you make, then I ask that you just note in the code where you referred to OS and include a note in any releases that some of the code is based off OS code. Since you already open source your stuff I have no other qualms with how you use the code.
Coding style seems to be a never ending battle lol. Personally I don't care what style other people use, I also have my own OCD about my style haha. I was just pointing out that since you released this as an open source sdk for developers like me, it just makes it that much more difficult without the documentation.
I thought you were actually hooking the entire d3d device, my mistake. So from what I see in your initialization, you're just grabbing the device pointer and assigning it to your own device interface? This looks a lot like Azorbix starter kit wrapper. He never copyrighted it so I'm not saying you ripped it, but that would be a ton of work if you wrote out all 119 functions by hand! :confused2:
I had started on a few projects, but right now I have started from scratch so I can focus on writing out my own SDK for Halo engine. When I'm near done, I will undoubtedly create some applications with it. All of which will be open source, of course. I will gladly credit you for the information I rip out. I wouldn't be posting here if I did respect your work! Just wanted the OK from you. Thanks :)
No problem at all, I appreciate the consulting.
Bitterbanana was originally the one who brought up the idea to using a dll proxy for DX instead of hooking the game's code (note: we still weren't hooking dx, just the game's rendering code). Using a proxy dll isn't some closely guarded secret though, and it doesn't just stop at DX. It was orignally the method I had in mind for loading the dedi version of Yelo when we first started, by having a proxy Strings.dll.
Cool cool!
Just out of curiosity, why did you guys decide to go the proxy route and not hook some engine draw functions for your app? I only seen a video, so I'm unaware of how far you went with drawing. Was it just the fact that it's an easy route to get your dll injected? I'm currently going the VMT route, by grabbing Halo static device pointer, which I think is triple pointer deep:
I only have console output hooked and haven't yet reversed any other drawing functions, which is why I'm still playing with EndScene lol.Code:IDirect3DDevice9*** pHaloDevice = (IDirect3DDevice9***)0x0071D09C; //halopc
vTable_D3D9* vD3D9 = (vTable_D3D9*)**pHaloDevice;
As for a modified Strings DLL, did you guys have to reverse and rewrite it? Is it a possibility to add in a LoadLibrary call to Strings DllMain to load your own DLL?
Just trying to chisel info outta ya, a great cure for my boredom! :p
Using the proxy method we ensure compatibility with potential future game releases; we won't have to see if we need to re-find the addresses we patch (or if we did anything hpc, but I told banana that I would give hpc no attention, I'm CE only). It also gives us more control and stability in some aspects. It also kills a third bird and that is making the game load our code extensions. Originally this wasn't a problem in CE v1.0 days, but afterwords we couldn't just modify the exe's code with no strings attached.
Banana made a Textbox and Menu system but I left implementation of stuff with that up to him while I worked on other core stuff.
For the strings.dll route, I was actually just going to have Yelo load the real strings.dll and patch the game to have that dll's runtime handle so everything is all savvy again. Simple setup, as we don't have to rewrite anything or add extra resources (like string data) to our dedi builds.
I read many walls of text but from what I understand you're getting "Yelo" for 1.08?
.Quote:
Originally Posted by Kornman00
More like Make-Your-Own-Yelo for 1.08.Quote:
Originally Posted by Rook
KM,
I've been working on reversing all the tag structures including all the tag blocks (bleh) using guerilla.. I wanted to ask if you would give me advice on the best way to implement them in C++. This is for my devkit thing, but I was going to use it for this modding tool I want to develop. It's an in game tool, so I will be able to use pointer power. -> fo life! Right now I'm not even wanting to think about file operations, but will implement some save features in far distance future. I notice you did a lot of template type stuff in your sauce, but I couldn't really understand exactly what was going on. Since the tagblock count is always different, would it be a good idea to use STL Vector templates to access tag blocks through pointers? Example of what I would want to do:
AnimationTrigger->Units[Count];
where Units is defined as:
TagBlock<AnimationTriggerUnits> Units;
I hope this makes sense and the above is just suedo, I know very little about templates and know nothing about STL, yet. Thanks for your time
Don't use std::vector. The TagBlock<T> class I defined allows for accessing a tag_block's data via an indexer or via the 'Definitions' field. The tag memory has already been managed prior to the cache being built, so you don't need to do (or rather you shouldn't be doing) any memory operations on the tag data besides accessing. No adding or deleting. Unless you really know what you're doing.
Basically the tag definition memory should always be treated as read-only.
I think you understood me backwards KM! I don't want to mess with the tagblock definition. I want to use it to my advantage to access the tagblocks so I can read and display and possibly edit the information in the existing tagblocks. In my example, I was using the 'Count' variable as an indexer/array element to the array of constant sized structures pointed to by the tagblock pointer. I don't want to manage anything myself, I just want to define everything so I can use pointers to my advantage and grab info. Would you be interested in helping me at all?
I looked through your code a bit more.
That is very similar to what I'm going after, except project_yellow_group will be replaced with any tagblock. Your template definition for Definition() is confusing to me. I don't understand it fully yet. Does it just return a pointer to whatever the tagblock type is by type casting? What if I want to access the 5th instance in that tagblock?Code:_global_yelo = Instances()[tag_index].Definition<project_yellow_group>();
Edit: I got it working using a template! Woot!
I would still enjoy your 2 cents though. I will PM you the project, since I have not yet attached any GPL nor credits to it yet. Don't feel obligated though.
Check your PMs
That code retrieves a tag definition instance. While internally in the engine tools a tag definition is treated as a tag block, when you access them in Yelo its not the same way you would a tag_block as they always have an owning tag definition.
That is really all there is to accessing a tag block's specific element. If "type_index" was '4' then you would be accessing the 5th instance.PHP Code:const gameplay_game_type_player* type_definition =
_global_yelo->game_type_player[type_index];
did someone mention vertex shaders?
I think I found something relevant to that: Vertex Shader Architecture (scroll down 1/3~1/2)
There it is, should someone feel up to it.
oh please god :ohdear:Quote:
Originally Posted by p0lar_bear
I can't seem to get it to work.
I installed Visual Studio C++ 2005, along with the DirectX update just a few minutes ago.
For whatever reason, I get 28 errors when building the solution.
It asks for "windows.h" and "d3dx9math.h"
I know I installed both the SDK and C++, I dont see why this is happening.
Also, I got the 1350EST download.
Doesn't sound like your VC++ include directories are setup. Tools->Options->Projects and Solutions. The paths to the platform sdk and dx9sdk should be in there.
Also, this is the actual full VS05 and now VC++ Express right?
As long as you didn't modify the vcproj which came with the source there shouldn't be any problems. The fact that its bugging you about not finding windows.h isn't right tho...make sure your include directories are setup correctly.
Fixed.
Got everything I needed, however, a new challenger arises to stop me once again.
Looks like in textblock.obj (which is in \OpenSauce\Halo1_CE\Interface\, both TextBlock.cpp and TextBlock.hpp) is failing on a symbol related problem.Quote:
Originally Posted by Visual C++ 2005
No edits were done to the file, or anything in general.
SetRect is a windows function. Since you somehow had a messed up VC++ directories setup, I'm pretty sure it is still plaguing you. Its a linker error, meaning you're not including the module which defines\exports the SetRect symbol (probably user32.lib).
You may want to re-install VS05, you shouldn't have had these problems unless you made changes to the install options (or to program files), if which is true, makes helping you that much harder. I can help debug Yelo because I have the source too, but now you're getting into the actual program state which I don't have a copy of to analyze...nor do I want >_>
Quote:
Originally Posted by Kornman00
I too am currious as to why Dennis rejected the .dll I uploaded, maybe I accedently uploaded the wrong file (very unlikely) or my readme was deemed not good enough, getting the file rejected before test. Or maybe it was rejected before test because I said in the readme I would be uploading the source code soon and asked for a link to be added to the readme to the source code file (the upload of the source code failed on me the first attempt, and I missed the posting of files).Quote:
Originally Posted by Rhydgaled
It's not that your files are being rejected, all Open Sauce files Dennis has received crashed his test system.Quote:
Originally Posted by jcap
User error.
Also:Quote:
Originally Posted by PM to Kornamn
You got some splainin to do Korny :toughguy:Quote:
Korn still needs to make the User Manual for Open Sauce, he said he was doing that back in November:
Oh my god is Korn turning into the non-reliable CAD?!?!? D:Quote:
Originally Posted by Kornman00
w0rd.Quote:
Originally Posted by CodeBrain
This warning is not much to worry about. To fix it though, you have to make sure your dll output name is the same as the library name in the .def file. You can edit this in some project settings. I don't use 05, so not sure where exactly. Or you can just change the library name in the .def file to the name of your dll to get rid of the warning.Quote:
Creating library J:\LAPTOP\Halo Custom Edition\OpenSauce\bin\Debug\Halo1_CE\d3d9.lib and object J:\LAPTOP\Halo Custom Edition\OpenSauce\bin\Debug\Halo1_CE\d3d9.exp
d3d9.exp : warning LNK4070: /OUT:Halo1_CE.dll directive in .EXP differs from output filename 'J:\LAPTOP\Halo Custom Edition\OpenSauce\bin\Debug\Halo1_CE\d3d9.dll'; ignoring directive
As for these errors, follow this useful advice he already gave you:Quote:
TextBlock.obj : error LNK2019: unresolved external symbol _D3DXCreateFontA@48 referenced in function "public: void __thiscall Yelo::TextBlock::SetFont(char const *,long,unsigned long,bool,unsigned long)" (?SetFont@TextBlock@Yelo@@QAEXPBDJK_NK@Z)
TextBlock.obj : error LNK2019: unresolved external symbol __imp__SetRect@20 referenced in function "public: void __thiscall Yelo::TextBlock::Refresh(void)" (?Refresh@TextBlock@Yelo@@QAEXXZ)
J:\LAPTOP\Halo Custom Edition\OpenSauce\bin\Debug\Halo1_CE\d3d9.dll : fatal error LNK1120: 2 unresolved externals
You need to link your d3d libs!Quote:
Originally Posted by Kornman00
This weekend will see official announcement of Update 2 of the OS SDK and list a few of the new additions that will be seen in it.
However there will be some other news included that some of you may not like.
Breaking News: Kornman00 (Sean Cooper) is leaving the HCE community!
Tune in on the weekend to hear his goodbye speach!
:'(
Hes getting pregnant >:O
Yay new release. New additions sounds good. Hope bad news isnt this is final update on OS or support is dropped :(.Quote:
Originally Posted by Kornman00
Good News: Update 2 of the OS SDK
Bad News: C&D
I'm getting this error when compiling: Error 2 fatal error C1083: Cannot open include file: 'd3dx9math.h': No such file or directory c:\users\smash\desktop\opensauce\halo1_ce\Common\T ypes.hpp 27 Halo1_CE
38 times... that's just the random one I copied and pasted from the list... any ideas, I tried searching the forum but nothing came up about the d3dx9math.h
Do you have the direct X sdk installed?Quote:
Originally Posted by SMASH
Would this probably allow syncing of stuff that would sync? Such as AI and stuff?
I still haven't quite figured out why the networking extensions aren't working still.
Also, syncing AI is just out of the question. Go play Halo 3.
Unless you're host, you'll always get a 0.5 second delay. At least, that's what I always get, you probably already knew that though. I prefer to play CE with the AI not syncing than to have that delay. It just makes it so hard to play correctly.Quote:
Originally Posted by Kornman00