Hey, sorry for the noob question here, but, does anybody happen to know of a thread or tutorial on using the shader_post_process tags? Again sorry for the noob question, im new to open sauce.
Printable View
Hey, sorry for the noob question here, but, does anybody happen to know of a thread or tutorial on using the shader_post_process tags? Again sorry for the noob question, im new to open sauce.
Just wanted to drop my 5 cents here:
I think the original approach to OpenSauce was not really a good one and for the next step you should rethink some options.
My suggestion is that you make a exclusive dedicated client and server specifically for running OS. I don't know how far your network changes go but I think a loader would be good here.
Server sided: When starting the server a loader loads the haloded file and injects your DLL. Hooking the init parsing function you can include custom parameters which enable OS features like Multi-Team vehicles or the network enhancements inside the init.txt. Upon someone entering the server you do a handshake with the client and send requested features to be enabled on the client as well (Multi-Team Vehicles). If no callback because OS was not loaded, the connection is refused.
Client sided: You can start the loader which injects the client version of OS. In the game browser window only OS-Enabled-Severs will be shown...this could be done via a custom prefix in the server display name along the lines of a signature byte like 0x20 followed by [OS] (the server does this by changing sv_name). Upon entering once again the handshake, checking of OS versions etc.
Apparently even OS Guerilla can be affected (aka automatically shutdown) by certain dll files.
http://codebrainshideout.net/too_awe..._dll_error.png
Office 2010 (which is where GROOVEEX.DLL comes from [C:\Program Files (x86)\Microsoft Office\Office14]) isn't even open at the time, but OS Guerilla insists that this file is required.
Ive seen this "error" happen on older versions of Guerilla (most of the time i think it was TortoiseSVN back then), what is it that exactly causes this error Kornman?
Additionally info is that this error only appeared then the "Open Dialog" box was trying to come up, after I clicked "Open file" in the Files tab.
Also I am not going to uninstall Office 2010 because I use it most of the time nowadays.
Except the basis of OpenSauce is extending what's already there, not completely changing or replacing (thus breaking stock-compatibility). Some of the enhancements that OS does makes it so that it has to be loaded before the majority of program has started initialization. Using a loader would only complicate the runtime chain and add yet another level of detail to deployments. I'd rather have simple drag&drop support in OS which anyone can muster than maintaining a loader along with the DLL which then end users have to go out of their way to use.
OS can target both servers and clients. There is very little dedicated server specific code so I don't run tests for it unless it's for a major release, but the support is there in the codebase.
OS uses non-intrusive XML configurations. It wouldn't make sense to put OS specific config info into init.txt when that file is for stock Halo. Also with XML, the library doesn't have to worry about using custom parsing or writing code, it can use a third party library.
The server list operates by displaying all servers that have a matching version number as the client who is performing the query. If I cared about only showing OS specific servers, all that would need to be done is change the version number to one that would never be used by an offical game update (eg, "2.00.01.16").
The only network packet changes that I was ever going to support in OS was adding new message deltas. I had no interest in changing the lower level data packets that are communicated. When clients get unknown or invalid data from the server, their connection is automatically refused anyway. Nor do I have any interest in using custom networking solutions (a la MultiTheftAuto) that are specific to OS as that would only further complicate the codebase and go against "extending" present game features.
The networking changes I came up with for theoretically increasing online performance are done by changing what's already there in the game, nothing is added. It's a mix of what Delagginator did plus a few other configuration changes.
HaloCE is already plagued by too many versions. The point with OS was building on top of existing game features that wouldn't completely break stock games so there wouldn't need to be yet another level of versioning in CE. This enables people to continue to use OS-enabled games in stock game servers. It also keeps the codebase less complicated.
E @ Codebrain: the stuff in the initial post of this thread is pretty outdated compared to what is in the source repo now. I no longer use pre-built EXEs, but use OpenSauceIDE to "apply" OS HEK changes. This enables users to perform whatever changes they want to whichever HEK EXE (eg, sapien) then "apply" the OS features to a copy of that EXE and also completely removes the issues of those DLL errors seen in past versions of the modified Guerilla.
I didn't know that if you send a custom version number to GameSpy that they would accept it. My idea still would move more people to use OS though when they see a growning numbers of servers using OS.
Well I see where you are going but I don't know if you have realized that not many people are using OS right now even though many people would love its capabilities. Even I myself have problems seeing through how everything is suppose to work. Right now it is not really that clear how one is suppose to extend Halo with OS.
Now sure why you are talking about low level packet manipulations. Not talking about modifying the existing Handshake but making a custom one.
But now that you said that said your network improvements are all inline there is really no need for OS anyway. I still stand at my point though that OS right now if far to obscure for the general public. A simple all-in-one download package would OS for Client and OS for Server would have been a far better option. Just supporting 1.09, anti-cheat measurements, maybe remove the CD Key check and one could unite all players on one version.
Well OpenSauce is really meant for programmers, its how new tags can be made (I mean actually programming what the tag is, not using OpenSauceIDE to actually make the tag be seen by Guerilla/Sapien)
@Kornman, is this source repo available to us (users)? If so, is there a link to said repo?
Seeing as how OS 2 is still currently in development, I don't expect many people to be using it right now. Just like how there are two sides to HaloCE, the game and the editor, there are two sides to OS for HaloCE. Most people are only concerned about the side which has to deal mainly with the game (eg, what Battery did).
Below the game's message delta system, sits a data packet system (and below that, the engine's actual networking interface) that was also used for the Xbox days (the message delta system was developed to support the more distributed nature of the PC gaming). It is here where most of the low level (relative to the engine) networking is done in the engine's code. I wasn't talking about manipulating physical packets. The handshakes are defined though the data packet system so any changes or additions would need to be done there, and as I said earlier, I was only interested in building off the message delta system.
FS developed an installer for OS for CE a while back (the WiX project for it is in the source repo too). When an official release is produced, it will use the installer.
OS already supports 1.09. I don't have the time to develop an anti-cheat component for OS on top of everything else I'm working on (nor do I consider it worth my time). I will never remove the cd key check (1.09 doesn't even require you to have the CD in). I'm not interested in "uniting" pirates into the latest game version.
E @ Codebrain: It's been on Google Code for a while now. Thought I posted that in this thread earlier (guess it was in one of the more recent individual update threads).
In my code I'm just messing around with the values in tag defintions. Can anyone see what's wrong? I'm using scenery.hpp, generated by scythe's os_tool.
Quick rundown: The idea is for people to call the script by the name of the object, so I go to the name list, to get the index of the name, then go to the sceneries, and iterate through them, checking their scenery type, and checking the name index number to see if they're the same.
Then, using that, and getting the scenery type, I should be able to iterate through the list of scenery in the scenario tag, getting to the scenery in there.
After that, the idea is to iterate through the list, and getting a pointer to the desired scenario object. Guess it's not that simple. Or, I'm just overcomplicating it. Anyways, if I can't figure this out, I'm just going to stuff it and make my own tag for these kinds of things.
Code:cstring changeBitmapByObjName(cstring ObjName, cstring nextBMP) {
//objname in the name list of scenario
//nextBMP is more filler than anything right now
bool found_object = false;
int16 index = NULL;
for (int i = 0; i < Scenarion->object_names.Count; i++) {
if (strcmp (Scenarion->object_names[i].name, ObjName) == 0){
found_object = true;
index = i;
continue;
}
}
if (found_object) {
for (int i = 0; i < Scenarion->scenery.Count; i++) {
if (Scenarion->scenery[i].name == index){
return getShaderPathScenery(Scenarion->scenery_palette[i].name.name);
//it's always: players/cyborg/cyborg or whatever. NOT a scenery tag path like we want
}
}
}
cstring untrue = "false";
return untrue;
}
cstring getShaderPathScenery (cstring tagName) {
cstring string;
int x = 0;
for (x = 0; x < Yelo::TagGroups::Index()->count; x++)
{
if(Yelo::TagGroups::Instances()[x].group_tag == 0x7363656E) //Scenery
string = tagName;
//if (strcmp (string, tagName) == 0)
// return "true"; If It were working, the two if staments would be combined....
}
return string;
}