You're right about that. Changing FOV did fix it. I deleted the Yelo settings files which didn't help like I thought the fov setting was messed up. I don't understand why this is randomly just happening now. =[
Oh well, just have to deal with it
Printable View
You're right about that. Changing FOV did fix it. I deleted the Yelo settings files which didn't help like I thought the fov setting was messed up. I don't understand why this is randomly just happening now. =[
Oh well, just have to deal with it
Make sure you get the Appetizer.rar (in the first post) too. I think that might have had the fix for the FOV crap in it.
Oh I did, it did not have any effect.
I had this problem a while ago - fixed it by simply commenting out the fov functions in the main.cpp... then one day I un-commented it and it worked again... LOL.Quote:
Originally Posted by Skarma
I am building some tag definitions using your OS object and device definitions as examples. I was just wondering, when should you use a TAG_FIELD and when to not use it? I have been using it for only variables that have tooltips and other text next to the edit box in guerilla. Also what kinds of variable arguments are accepted in tag fields and in what order? Thank you
E: I am assuming the variable argument in TAG_FIELD does nothing currently.
Do you have the tag definitions already mapped out into c structures? If so, would you be so kind to release them with or without the next OS build? Just asking in case I am being redundant and should just wait until then. I have reversed most of them, but not into standard halo/os format. And hey, if not I can send them to you to put into the next build if I get them done in time.
This is for Forge by the way. I haven't yet looked through all your map/tag code -- there is SO much I have yet to explore it's ridiculous lol. Right now I am just working on editing existing tags, but I eventually wanted to be able to create new objects and delete existing objects. I saw a script command object_create and was thinking of making use of that to temporarily spawn an object but I am unsure. I guess I would need to update all the pointers in the map file if I wanted to save changes for adding and deleting tags. Can you help me sometime?
I found a bug in yo code, yo.
Keithstone.cpp:
All the calls in the engine functions are pointers to the function address not the actual function address.
Example: static uint32 TEMP_CALL_ADDR = GET_FUNC_PTR(KS_GETWINDOW); returns 0x6BD0C0
Also, you should add the remaining keystone functions to the next update. :downs:
I thought it would be an appropriate time for this lol...
I haven't messed with that area of the code in a long time. I believe I used the address of the engine-owned function pointers which the engine itself loads via GetProcAddress (since they're in a DLL). I never ended up really using them aside from some UI fix-ups (which are currently deprecated) so they didn't get tested.
lol @ stone
This sounds so cool! :D How do you use opensauce btw? I downloaded it on HM.org but I did not know what to do with it.
I'm sure Kornman can give you a better answer than me, but basically OS allows programmers to create extensions for Halo. OS, which is loaded as a part of the game itself, exposes a lot of the game's internals to the programmers for use in their extensions. Where previously app developers had to make use of memory hacking and tricks to accomplish their goals, OS allows them to work directly with the game as a part of the game.Quote:
Originally Posted by Goldkilla
If you downloaded the SDK, then you probably won't be doing much with it unless you're trying to develop one of these extensions. If you downloaded something that someone made using the SDK, then you put the .dll in your Halo Custom Edition folder and follow the instructions for whatever it is you have.
I started looking into GTA4 mods since I got the game on Steam too now. They also have their own game hook that allows people to modify the game with C++ code. Difference is that their hook seems to be solely based around the game's scripting system.
Also noticed that they have a .NET interface for game hooking. Sadly, it looks like both the native game hook and the .NET interface's internal code are closed-source. If they were open, I'd look at seeing how they did things and seeing if a .NET interface was possible for OpenSauce in some way.
Maybe you could contact them about it. A .NET side to OS would go nicely with BlamLib.
Hi. Im totally new to this open sauce thing. Wanted to know about the open sauce thing a bit more. Could some give me a more elaborate description of the Open Sauce HEK and how to use it?
What's your game modding background?
That is to say, what other games have you modded? Are you a programmer or just a general game modder (ie, you use data editors to manipulate game data values)
Im am just a general game modder curious about how OS HEK works?
At its core, OS is an SDK for Halo (in this case, Custom Edition). It allows game/editor extensions to be written. One example of an extension for the editors is the ability to add new tag groups (which are defined by programmers who use the SDK. 'biped' is an example of a tag group). Then modders instance those new tag groups like they would any other by a tag definition (eg, grunt.biped is a tag definition).
OS offers a couple new tag groups of the of the box. One is called "project_yellow". It's what your scenario references for custom OS data. For example, the project_yellow tag has a field for overriding what globals tag is used. This way, you can use another globals definition besides the default "globals\globals.globals".
While using the "d3d.dll" attached in the OP and a clean install of 1.09 with the 1.08 "haloce.exe" and "Strings.dll" the F7 menu only flashes in-game when I press "F7". I see all the options but the menu doesn't stay open.
Help!
Blame Canada?
So I've got some ideas on how to better some of the existing networking...however, part of the changes would make OS invalid with connecting to or from stock game builds. I'd like to at least try testing the changes in a full server this or next month just to see if such a change is worth it. The changes assume everyone is running on broadband connections...which should have been the assumption by MS from the get-go, but I digress.
I could also probably make it so that you can toggle the networking enhancements on and off, to allow you to connect to stock client/servers. However, I'd have to assume the end-user isn't a complete twat to know how to work the console to execute a script function...which is almost asking a lot, so the default would probably have to be off :ugh:.
OS exclusive servers? Sounds all right to me...
If it can prove to reduce the leading, I'm sure you'd get people to use it. That would fix the number one biggest issue we've always had.
I pushed some code changes to OS's repo on google code which includes a debug-only test function which enables the possible fixes (if anyone wants to try it themselves, you'll need VS2008 to compiler a build). I'll try getting a test conducted later this month or next.
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:Quote:
Originally Posted by Kornman00
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)Quote:
Originally Posted by Patssj6
@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).
Sorry to keep on asking, but how exactly would I download this source code using TortoiseSVN/whatever you use?Quote:
Originally Posted by Kornman00
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;
}
Turns out the problem was on this line:
return getShaderPathScenery(Scenarion->scenery_palette[i].name.name);
Instead of [i] I should have used [index]. Just needed to sleep on the issue. I spent about two hours trying to fix it last night. Found it in less than 5 minutes of turning on my computer. eff.
Well, while I was neck deep in some gamespy code, I stumbled upon a way to load OS *without* using a dx9 hook (so you could use whatever dx9 hook that exists, no more having to do the d3d9_proxy.dll workaround) or an external loader. It'd still be in DLL form though of course, and I think I can set it up so that you can specify the DLL name via a command line argument, eg, "-os:OS.dll". The DLLs could then be placed in the HaloCE user directory (under the OpenSauce folder) too (I'd more than likely wouldn't use this setup for the OS HEK dlls however).
No technical information on what you found? :P
Who framed Roger wrabbit?
You just watched that movie because of the hentai women.
While this isn't strictly HaloCE related, I figured out a few things in H2Guerilla that are kind of interesting. The internal builds (as far as I can tell) had what was basically a "create restore point" hotkey for tags you have opened.
For instance, say I have a biped opened and was about to do some changes but the changes were just some new ideas and would affect multiple fields and block elements, potentially causing some problems. I'd hit this "restore point" hotkey and then that tag would have it's own restore point I can later go back and revert to. Each tag that is left open while running H2Guerilla will keep their restore points (so if you close the tag or H2G, the restore point will be lost). What's neat is that you can save the tag (eg, this theoretical biped tag) back to disk then say "oh ffffffffffffffffffffffffuck, I just borked the change colors block! oh ffffffffffffffffffffffffuck, and I've already saved the tag!" then be reminded that you hit the "create restore point" hotkey and be rest assured that the shit you just borked can be reverted. So you hit the revert hotkey and blam, the change colors block and all other fields are back to the same exact values as when you first created the restore point.
I also was able to get H2G's tag importer utilities to run; there's two, an auto pilot reimporter and a visual tool interface (as shown in the attached image). However, I haven't actually tested these to see if they properly run yet without further modifications (eg, it passes everything to h2tool and does a dance), but everything looks in order. In fact, it would even be possible to write custom re/importers for tags too using CheApe with the H2EK (with some elbow grease; 1-2-3-not it!).
I'd have to modify some of the program resources to actually make these features usable (for testing purposes I hacked in some ways to execute these utilities). Hopefully will be able to include at least the restore point feature in the H2EK OpenSauce builds (whenever they may be) however, it would require me to redistribute the H2Guerilla.exe since I'd be adding data, not just replacing (unless I used some 3rd party diff tools, but that still complicates things). Not sure I'm savvy with that (the current OS installer auto applies the CheApe extensions, no need to redist the HEK exes).
Attachment 1996
would there be any way to do something like this for CE? this would be VERY useful when editing in CE
Sure, if someone wanted to do it. I'm not that someone.
For those not in the know, GameSpy released their SDKs to indie devs a while ago. I used the opportunity to update the structures documented in OpenSauce.
This release is a pretty big deal as it basically drops the pants on the GS systems. Albeit, the structures and some of the core code aren't exactly the same from 2003 (when HPC came out) as I saw when updating my engine documentation with the new SDK's information.
Part of Patrick's code for making the dedis report to multiple game versions is actually a mod of the function "qr2_check_send_heartbeat" (in qr2/qr2.c). I had fun going through this fountain of new information. I like having my code on point with correct or almost-correct names of whatever program I've RE'd.
Potentially, new gamespy features could be added to Halo...but don't look at me, I'm just saying potentially. At the same time, no one really has to fear about gamespy taking down the master server for HaloCE...someone could use the info in the GS SDK to create an emulator.
So that's where you got your reserved spaces from :P
Something cool would be a WHOIS so the server shows its server location (country) based on IP? But for that you don't really need to occupy the reserved spaces in the GS communication thingy...
I cannot think of anything besides a flag that shows if the server is running OpenSauce.
Double Pene
So your version changing actually works correctly now? Is there a way I could fix it in my exe in the mean time before OS gets released?
I'd like to know if in BlamLib there's a way to check if a map is protected before opening them. I just added a test class for cache extraction, and am seeing what can be done about that particular thing.
Edit: Also, I'm interested in FP animations... does anyone know if there's a way to find out what animation is playing?
I haven't integrated the rolling-version-changer stuff into production code yet. I'd recommend writing a simple C# app that applies the changes you make so you're not releasing dedi.exe after dedi.exe...(and that allows you to change the app's build info too, so people know when it's old or new)Quote:
Originally Posted by Patrickssj6
I've never dealt with protected maps using BlamLib (other than Reach) so there's no support for it in Halo1. I know I asked Steelix to make the first tag instance's (so, the scenario) group tag to be 'prot' but that was only for OS's sake. If he flags the map as protected somewhere in the cache header then I can see about adding support for them. If the only "flag" is that 'prot' thing I asked for way-back, then it will take some tweaking/hacking to the tag header/instances loading code.Quote:
Originally Posted by Dwood
I just compiled the Guerilla portion of the OpenSauce HEK project, and I have the dll file that Visual Studio built, but I can't seem to find a way to build the CheApe program (That or find it at all in the OpenSauce directory or the Halo CE directory)
How would I get CheApe?
use OpenSauce IDEQuote:
Originally Posted by CodeBrain
CheApe is basically the codename for the editing kit modifications, just like how Yelo is for the game engine modifications. There's the native CheApe dlls (which you built) which are loaded by OS "enabled" HEK programs. Then there's the CheApe interfaces in OpenSauceIDE. The thing you want is "CheApe Applier" under the Tools menu. Click it, select Halo1_CE as the engine in the popup dialog, then specify all the paths. It will then apply the changes needed to copies of the selected source HEK exes (eg, tool and/or guerilla and/or sapien) then output the results to the specified directory.
Note: Just think of the native CheApe dlls as the CheApe runtime and the interfaces provided by the OpenSauceIDE as the CheApe SDK (tools).
From there you can use the main CheApe interface in OpenSauceIDE to build tag_groups.map cache files. You'd again select Halo1_CE as the engine in the popup dialog then use the CheApe project editor to build your additional editor data that will be used by the CheApe runtime proper.
To give some history on CheApe: It initially began (around this same time, back in 2006) as a Guerilla-only modification as sort of a proof-of-concept for allowing designers to document tag definitions. I started off with only allowing new tag groups to be defined (instead of overriding existing ones, which is what a designer would need the ability to do in order to markup the tags with their own comments and such) and went from there (never really did work on allowing it to override existing tag groups since it was no longer a PoC project). Eventually I added tool and sapien support and eventually added support for things besides custom tag groups (eg, custom scripting definitions and HEK EXE fixups). I kept the tag_groups.map name just for legacy's sake, though I probably could have gone with "CheApeCache.map" or whatever instead.
He can't compile LowLevel.dll, his boost set up is borked or something.
I could certainly write a patcher but my question was really, do you have any idea how I could fix this problem we are having?Quote:
Originally Posted by Kornman00
After applying the changes to the regular HEK exe's using OpenSauceIDE, the following occurs:
1. OS_Guerilla fails to load. It opens for one second before automatically closing. debug.txt shows the following:
2. OS_Sapien has no problems. Works as intended.Code:03.05.11 20:30:56 guerilla pc 01.00.09.0620 ----------------------------------------------
03.05.11 20:30:56 reference function: _write_to_error_file
03.05.11 20:30:56 reference address: 4011a4
03.05.11 20:30:56 EAX: 0x004E121A
03.05.11 20:30:56 EBX: 0x77656101
03.05.11 20:30:56 ECX: 0x00000000
03.05.11 20:30:56 EDX: 0x00000000
03.05.11 20:30:56 EDI: 0x0018F1F8
03.05.11 20:30:56 ESI: 0x00000000
03.05.11 20:30:56 EBP: 0x0018F0D0
03.05.11 20:30:56 ESP: 0x0018F0C0
03.05.11 20:30:56 EIP: 0x77B50BD2, 83 C4 04 C2 ?????
03.05.11 20:30:56 EXCEPTION halt in \halopc\haloce\source\memory\data.c,#544: data
3. When called upon by Command Prompt, OS_Tool shows commands up to "import-device-defaults" before spitting out an error:
Any idea on what this would mean?Code:EAX: 0x00000000
EBX: 0x0060F601
ECX: 0x00000000
EDX: 0x00000000
EDI: 0x0018FB40
ESI: 0x00000000
EBP: 0x0018FA18
ESP: 0x0018FA08
EIP: 0x77B50BD2, 83 C4 04 C2 ?????
EXCEPTION halt in \halopc\haloce\source\cseries\debug_memory.c,#160: Attempted an operation with pointer at 0x6e2cf0 when no pointers have been allocated. (\halopc\haloce\source\tag_files\tag_groups.c:2637)
Edit: Dwood helped me with this problem, you need the CheApe dll files in the Halo CE root Directory as well as OpenSauceIDE's files as well
Since it's not listed anywhere as far as I can tell in the first post, where do I extract these fucking files?
Just pushed some changes to the code repo that largely relate to CacheView in OpenSauceIDE. Opens all supported engine's cache files and displays their information. Haven't finished adding the UI code for tag extraction yet, however.
Just pushed some WIP changes, mostly relating to CacheView's tag extraction. Haven't done any specific testing yet for the extraction UI logic, but it's based mostly off the old H2GuerillaRadio code and the current BlamLib.Test's tag extraction unit tests. The most code hacks I've done in a long time, but I'm just doing this to finally have a UI over the extraction APIs that I can use. End users beware.
Attachment 2028
03.25.11 21:01:41 file_open('tags\i've got a lovely bunch of corncobs.project_yellow') error 0x00000002 'The system cannot find the file specified. '
03.25.11 21:01:41 couldn't open project_yellow tag 'i've got a lovely bunch of corncobs.project_yellow'.
03.25.11 21:01:41 failed to load scenario tag 'levels\test\tutorial\bkup\tutorial'
03.25.11 21:01:41 Increasing sound decompression buffer size to 1048576 bytes
03.25.11 21:01:41 file_open('tags\i've got a lovely bunch of corncobs.project_yellow') error 0x00000002 'The system cannot find the file specified. '
03.25.11 21:01:41 couldn't open project_yellow tag 'i've got a lovely bunch of corncobs.project_yellow'.
03.25.11 21:01:41 failed to load scenario tag 'levels\test\tutorial\bkup\tutorial'
03.25.11 21:01:41 need to get the following tags:
03.25.11 21:01:41 i've got a lovely bunch of corncobs.project_yellow
03.25.11 21:01:41
03.25.11 21:01:41 game_load() failed.
:L
The files hosted on the first page are outdated and thus no longer supported. Since OS is still in development, the only supported builds are current builds based on the most recent codebase. Right now, only people who know their way around visual studio can compile a build since, like say, it's still in development.
Why don't you just remove those downloads from the front page already? :P
Punishment for those who don't read :p. I really hate when people don't read or BTFW (browse the fucking web). Sometimes I hate myself, but that's beside the point.
And I have a firm belief in that, when it comes to the internet, nothing should ever be removed, only appended. When the next version of OS is ready, this thread will get locked (since I can still lock my own threads) with a last post pointing to the new OS thread.
Can you make it compatible for V1.9 please? I really want to see what OS can do, but it's hard with that error...
If you tried it right now you'd be underwhelmed. Better to get a build of halo 1.08, and OS postprocessing because the features on that version are readily apparent.Quote:
Originally Posted by Goldkilla
The current codebase is compatible with 1.09
Yeah, but until scythe (re) publishes his postprocessing and shader replacement format//a way to compile the new versions that's compatible with current builds... I modified like 30 shaders via the replacement, I am vry sad to see them go :(Quote:
Originally Posted by Kornman00
Is that GUI written in C++? Then balls to you sir. :v:
It's .NET
I how can I switch without using that crappy Version Changer? I want to change my version back to 1.07. I hate 08-09.Quote:
Originally Posted by Dwood
I don't know what your options are right now (so I can't help you right now), but we plan on supporting an in-game version changer in the next OS release (via a script function, which you can execute through the console).
Can you at least open the damn thing with OS enabled on 1.09? You can't change your version with console if you can't even open Halo. ;)
Version Changer is the best solution out there, not to mention extremely easy to use and install. If you can't use it why are you even concerned about Open Sauce? It's way beyond you.
Our compatibility systems are starting to come online. For instance, I've got it setup to where OS now uses ".yelo" files for OS-enabled maps. It's pretty transparent to the end user, as they still see the same map name in-game. However, the retail game will never touch the .yelo files and will thus never crash from OS shenanigans.
There is one caveat to the system, however. If there's a "bloodgulch.map" and a "bloodgulch.yelo", the game will always pick the .map version. I didn't want to take 3 characters away from modders and their map names by placing an 'OS_' prefix. It will be up to them to do that. Or think of more clever names.
Next on the list is seeing if we can incorporate an extra gamespy query field that basically says "we're running OS lulz!". If it causes stock clients to fail when browsing the server list, I may nix the idea. It's better than forcing all OS users to a custom server list. We want to give users wings, not funnel them into a prison cell.
Is there a way for gamespy to use a secondary password or something? Then we can have an Open Sauce password that stops them from getting into the game without opensauce or something like that.
no
Everyone trying to enter the server without OpenSauce will be OSOD'd.
I've been messing with the preview dll in the OP; positioning weapons, adjusting FOV etc, but every time i left click to save the game freezes and sound loops. Tabbing out gives me an exception window.
Windows 7 32bit, directX up to date.
Exception details:
Quick question, could you re-enable shader_transparent_genric with OS in any way, or is that completley dead for CE?
I wasn't aware that is "disabled"
^apparently its not supported anymore in the pc version, the shader transparent generic was in the xbox and was used to create the shield effects for covie equipment. very simplified way of getting the shield flash effect.
System.Reflection.TargetParameterCountException: Parameter count mismatch.
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
at System.Delegate.DynamicInvokeImpl(Object[] args)
at System.Windows.Forms.Control.InvokeMarshaledCallba ckDo(ThreadMethodEntry tme)
at System.Windows.Forms.Control.InvokeMarshaledCallba ckHelper(Object obj)
at System.Threading.ExecutionContext.runTryCode(Objec t userData)
at System.Runtime.CompilerServices.RuntimeHelpers.Exe cuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.RunInternal(Exec utionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ExecutionContext.Run(ExecutionCon text executionContext, ContextCallback callback, Object state)
at System.Windows.Forms.Control.InvokeMarshaledCallba ck(ThreadMethodEntry tme)
at System.Windows.Forms.Control.InvokeMarshaledCallba cks()
Attempting to extract a globals.globals tag with OpenSauce IDE extractor into folder with dependents
CacheViewer has been WIP for a while. At first I just did a port of GuerillaRadio's logic with some async operation support. Then I started moving that to work with BackgroundWorker systems. The later code got accidentally committed when I was pushing some changes for something else (and I haven't pushed new changes for it yet since it's not finished).
If you're going to work with code from the repo, you need to know how to debug or at least know how to evaluate problems. None of that information even remotely helps me, especially since it's a stack dump of MS code (with no link to my own).
Linking it to the debugger doesn't work. can you replicate the problem?Quote:
Originally Posted by Kornman00
Can you make it so the OS Sapien won't bitch to you about how your AI/Biped has a dialog tag but no mouth data (Mouth Animations)? It lags the whole fucken thing and get pretty damn annoying after awhile.
This will probably be my last post in this thread. Couldn't hold this back any longer.
Epic. And detail maps? Holy crap.
To be specific, 1 base normal map, 2 detail normal maps (masked by the base normals alpha channel) and 1 specular colour map :).
Well hot damn. Beautiful work.
Very nice.
:o
WHY DO YOU DO THESE THINGS AFTER 90% OF THE COMPETENT USERBASE HAS RETIREDQuote:
Originally Posted by FireScythe
goddamn I would've loved to have normal maps in ASCM, if you guys end up releasing something even bigger I won't be able to keep myself from updating the bloody thing
stop now
Wow, and here I've been still using "a hobo" and "kornman00" all this time, wish I'd seen this sooner!
You can write your own shaders and compile them in the map and any os thing will work with it... what more do you want?Quote:
Originally Posted by Ifafudafi
This needs more documentation.
Or an FAQ or something.
first off can these new tags be compiled into a normal halo map file and run on clients without a bunch of extensions, or whatever?
Yes. All they would need is that specific OpenSauce dll. The maps won't break if people load the map without the OS dll, either. They just won't be able to use those normal mapsQuote:
Originally Posted by NVOUS
The only thing which would cause your map to be incompatible with the stock game would be if you used OS's memory upgrades (eg, more tag memory, new script functions, etc). When you build a map using the new build-cache-file-ex, it uses a ".yelo" extension instead, which a stock game will never use. However, we currently don't perform checks when you use the regular build-cache-file, to see if you're using any of the new script functions/globals exposed by OS (you're expected to use build-cache-file-ex).
Of course, if you're not running OS, none of the new tags will be used, so none of your detail maps will be rendered, and you'll be back to the old days.
As far as a FAQ goes, it's the reason why I don't respond to anyone over IM with individual questions. You got something to ask, ask it in an active thread so everyone can learn from the response. I don't have time right now to produce a detailed FAQ when I'm developing the OS codebase (which has more to it than some HaloCE related stuff), working on halomods, working on other code, and working in real life.
Most likely this has already been asked, but what's the issue with the d3d9.dll message saying one of the programs tried to access it but it is only compatible with Halo CE? I downloaded the new one from the attachments in the OP and renamed it to the original one, and it still gives the same error.
The build in the first post is insanely old, and unsupported (and doesn't have all the features found in that vid). As far as that message, we have checks in place to make sure that Halo is trying to load it, and if the app isn't Halo, it will throw up that warning. The current codebase will silently ignore cases where say Sapien or Tool tries to load the local d3d9.dll.
Considering there are 50 pages to look through, could you give me a link to download the newest version? :P
The next RC hasn't been released yet.
So that people don't get the wrong idea, you can compile post process shaders into tags that get added to the map cache, but you cannot create your own model pixel/vertex shaders.Quote:
Originally Posted by Dwood
I've written documentation for my post processing and shader extensions which i'll make available when/shortly after OS is released.Quote:
Originally Posted by NVOUS
As Korn said, adding post processing tags and/or the shader extensions on their own won't cause non-OS clients to exception. However, using the post processing script functions would, unless they were avoided using conditionals.
A caveat to this in the shader extension is that using a specular colour map results in the parallel and perpendicular colours being used to tint the specular colour map by multiplying it. So if you don't want those values to tint the specular colour map you would set them to white, and that would make the specular reflections on vanilla CE white as well. It would look bad, but wouldn't exception :).
OpenSauce isn't a lone DLL dropped into your HCE folder, it has resources files that it depends upon, all of which will be neatly packaged into an MSI installer.Quote:
Originally Posted by Dwood
ty fs <3
Ah, I thought you were implying you had posted it somewhere else within the topic. Well, looking forward to its fruition!Quote:
Originally Posted by Kornman00
Oh, no, sorry not yet. With the release of Halomods and some personal problems, our OS schedule kind got shook up. We're currently targeting the next RC for very soon. Then once we know that all systems are green, we'll settle on a final release sometime after that.
I just found the video you mentioned (and once again, apologies for any repeated questions) but I was wondering - you said the implementation of those effects were done via script, are they new commands added to the engine which will be included in the next build (along with a list of them, I'd hope, haha) or did you unlock the dozens of rasterizer commands which have previously only been available in Sapien, not in-game?
PS I registered at Halomods.