Guys just wait until Skarma gets done with his reversing. How about instead we focus on someone doing a *silent* version changer for Open Sauce?
Printable View
Guys just wait until Skarma gets done with his reversing. How about instead we focus on someone doing a *silent* version changer for Open Sauce?
OK. He could be the one that could do it. He could compare EXE code between stock netcode and where the patched code was inserted, then make a fix for Open Sauce.
It's been tried about a million times. The game is not coded to handle more than 16 networked players, and shit happens when the 17th player joins.Quote:
Originally Posted by Rambo
Korn has made it clear that there are a lot of things, mostly things such as revamping the game's existing systems, that are simply not feasible without the game's source code. IIRC OS is meant to add to the game's engine, not change anything.
OK I accept. well put, mate.
Well imho it is possible but who wants to dissassemble overQuote:
Originally Posted by p0lar_bear
10,000100,000 lines of assembler code just to find out what's going on?
About the updated Netcode fix Kornan00 made to his Open Sauce 2 build, I have a suggestion.
No offense to kornman00, but regarding the current build he has of the Netcode fixes, I don't fully trust the conditions that this current build for testing purposes would subsequently create. I do, however, believe that it very well could still work; however, there is a part of me that feels the upgrade would act as a hindering factor to bute-force testing. I'd still very much like to see the results of the test. However, it is in my opinion, that in order to flush out this pesky bug, we need an environment that is rigged to kick a client from the server. If we can use that rather than his reroutes or "fixes" or whatever he did, then we could possibly come up with a more "direct" solution.
Kornman00, I am still very much interested in a possible position as a tester. However, I just wanted to point out the preceding as what I feel are more viable testing conditions. By "fixing" one problem and causing the server to send packets and the client to supposedly ignore them, we may have pevented the detection of te real problem at hand.
I don't think any of the networking code is implemented in the RC release.Quote:
Originally Posted by Rambo
It's not a bug. A bug is code doing something that is unexpected. It is expected for Halo to not accept modified packets, so it's not a bug, but instead a security feature.Quote:
Originally Posted by Rambo
Dude, for Pete's sake, just be quiet and quit trying to introject your two cents' worth of non-constructive criticism.
and you didn't bother to even research the SDK, did you? The post I quoted from in the Manual said that, by default, it is DISABLED, not unimplemented. Unimplemented, in most cases, means not even structured to function. All one has to do is remove the macro in the build conditions to include the netcode environment, and bingo! Now you have a netcode that will crash clients' connections the instant a foreign packet is introduced into the data stream from the server.
You never saw it coming because you didn't test a build you comiled yourself. You relied on the stock DLL file provided on the release thread's first page.
beore you start spewing diarrheic nonsense, I'd advize you to make sure that the conditions for your statements are fully met on all levels and from all angles. That means, do your so-called "homework" before you post another negative spiel such as this.
Yea ShadowSpartan, Just because you can't do ANYTHING!!!! that anyone else wants to know how to do dosen't mean you can go around and be a BRAT and try to make your self look good.( YOU DON'T KNOW WHAT YOU ARE DOING!!!!) Rambo is one of my good friends and he has researched extensively the differences between the various patches' conditions and what they fixed. Although he is not a programmer himself, he is aware of these problematic issues that were corrected and can thereby logically conclude the resulting consequences of an issue such as the black-hat hacker fix. Now stop acting like you know everything and stop being a troll okay? And go tell someone that cares and will put up with this crap!
FOR EXAMPLE! :Quote:
Originally Posted by ShadowSpartan
Why is this even an argument when we can all just wait for Skarma and worry about more apparent problems?
I said that it was not implemented....so what is your point? I know that it is not implemented, but you acted like it was in your previous post when you said you didn't "trust" OS as a test environment. Just don't touch anything networking related in OS, and it is a fine testing environment.Quote:
Originally Posted by Rambo
See below.Quote:
Originally Posted by Rambo
Shut the fuck up. You have no fucking idea what you are talking about. I may not have messed with OS2, but I have with the original OS release, and I have compiled numerous of my own OS dll's. I fail to see your point with that statement. You sure do love jumping to conclusions without any evidence to back it up don't you?Quote:
Originally Posted by Rambo
I did do my "homework", I said it was not implemented. You were the one who was acting like the networking code was implemented by default, not me.Quote:
Originally Posted by Rambo
Lol, really now? I can't do anything? You have no idea what I have done in terms of Halo modding, so do not act like you do. A lot of my work is private, and exclusive to the team it was created for.Quote:
Originally Posted by skywalker71291
This argument is getting us nowhere. Let's just wait until we have some more information from either Kornman about OS, or skarma if he's reading this about reversing some of the netcode [possibly]. Internal corruption was a benefactor to Rome falling, let's not become an example and look like idiots arguing with ourselves, which will only get us nowhere.
I'm terribly sorry for making this seem like an argument and thereby humbly apologize for seeming as such.Quote:
Originally Posted by Dwood
Chaos and I care because we have a yearning desire to understand the nature of this beast, not because we want to meddle around is business that may not be our business. That is why we persue this so ambiguously.
Agreed but Spartan needs to clean up his act. And stop doing all this trolling.
ugh all of you shut up
OK, here's what I want to do. I intend to prove that this is a network related issue having to do with 1.04's security fixes.
I will work with Chaos on getting the 1.08 build working with network code updates. Then I'll take a video of me opening a door on the client side in Blood Creek and the client crashing the connection as a result. When this happens, and I know it will because Kornman00's manual for the current public build says it will, I'll present the data here for all to see.
EDIT: We have a problem. When compiling the DLL and placing it into the root CE folder, when we run Halo CE, the BSP does not show. In fact, the only video we have is the HUD. Any recommendations on how to fix this? The only change we made to the codebase was removing version check in an attempt to get it to accept <1.08 builds. Could this be what causes the video to not work properly?
All I can think of is that the DLL is "confused" as to what program to hook the wrapper routines into, so it bugs out.
This.Quote:
Originally Posted by teh lag
Seriously Shadow, chill out man. Your posts make me think you're going to give yourself an ulcer. :ohdear:
And skywalker, for the love of what's good, please don't jump into the community making blind assumptions about our established members.
Use 1.08 ? Get Omega's Version changer, set to 1.09 or get an alternate ui that removes autoupdate. Then test. (After replacing the code that checks for version #)Quote:
Originally Posted by Rambo
You're better off making Halo think it's v. 1.09 than making it not check versions via OpenSauce.
I made halo think it is 1.09, but it will not join the majority of 1.09ce servers. To do so I simply hexed Omegas files, I replaced the 1.00ce version string with 1.09ce in both dlls; now i am able to change to 1.09ce no problem, however it only joins certain servers.Quote:
Originally Posted by Dwood
I see you mentioning code that checks for a version number, I am half retarded, what are you referring to?
if anyone could help this old moron, I would appreciate it.
Nonono, listen. I manually updated to v1.08 with a hotfix and blocked the updates with my own UI (download it here). From there, I was able to run the Open Sauce no problem.Quote:
Originally Posted by Dwood
What I was saying is we removed the version check on Open Sauce itself so that it wouldn't come up with an error dialog while running on older versions of Halo CE. In doing so, we must have broken something else. Sad-face...
This sounds like the FOV bug that was in the original RC. jump into a game (SP or MP) and change your FOV using the Yelo battery menu (F7).Quote:
Originally Posted by Rambo
Thank you, FireScythe. I will surely check it out. I will let you know what happens.
EDIT: I cannot access F7 (Battery). The menu simply will not appear.
Wow, who on earth are these blithering idiots? You prance around here making crazy accusations. Yet you cant even fix simple issues? You cant even think what the issue could be.
I havent put any thought into it, and I'm assuming its an issue with the camera, like fire said it could be FoV, it could also be camera location.
About a version changer in OS, I made working one a while back for v1, I might give it a shot adding 1.09 in, I still dont see it possible connecting to dedicated servers, considering the handshake is different and picky.
I think the developers around here should get together with me soon to actually update OS, so everyone can stop bitching about updating Halo. The world is not blowing up guys! :saddowns: All that needs to be done is update every single memory address in _EngineLayout.inl, then OS will be completely compatible for 1.09. It is a bit intimidating, there are hundreds of addresses to update, but in a few weeks or less and with a little pattern scanning, this drama can be all over.
Now swallow that chill pill I just gave you.
Skarma, will you please help me work on the Netcode problem? I know what it is but can't program. I've pointed you guys in the right direction. See Page 39.
Are you ignoring what Korn said completely?Quote:
Originally Posted by Rambo
Quote:
Originally Posted by Kornman00
I was tag about our version of the SDK, not his version. But OK.
In that case, how do we make the client accept the packets?
I say screw that, people in community are way too demanding, yelling at us to fix shit. Why should they call the shots, I think us devs should either not update stuff, or at least wait a while.Quote:
Originally Posted by Skarma
You have to be doing stuff in the first place Limited. :iamafag:Quote:
Originally Posted by Limited
Oh SNAP. Also theres reasons why I stopped doing Halo stuff. Main reason is I'm working on alot of other big projects that are taking up all my time. I just cant disclose what the projects are though.Quote:
Originally Posted by Dwood
Updating OS would require 1,487 offsets to be corrected. Sure, it can be done, but it's pretty unnecessary if you ask me. While it really would be nice to run the newer version, there isn't much of a benefit over using the 1.08 files with OS overriding the version. Maybe we should just start packing the CE exe and strings with OS...Quote:
Originally Posted by Skarma
Well, I'll still keep my high hopes. About half of those (702 to be exact) are script function addresses. They can be knocked out in a few minutes time because there is a nice table of script function pointers in memory that can be iterated through and printed. There is a bunch of these that I can remember looking at from reversing, all the functions can be pattern scanned easily within minutes too. As far as structures, just find references to them in functions and scan. Honestly, I care about this and would like to see it properly done than some other ghetto version changing method. I hope Kornman00 sees that some of us really care and respect his work. Trust me I'm envious of some of this stuff and would like to see him pursue another update if I can help update these addresses. Too bad he won't let me work with him, I got some good stuff here that I haven't posted to site yet
Any person that doesn't respect Kornman's work is a complete an utter tool.
Also Skarma you're awesome.
/asskissing.
For those who have looked at the lights section of Open Sauce, what can be done with it?
Made this 2 months ago. Now, if you guys can find a way to make global booleans that connect to the UI and an SP map, this will be possible in the single player. (And in my maps).
Also, sorry for the sudden intrusion in your... conversation... but I had been expecting some kind of breakthrough to make this possible.
Yeah someone should find a way to expose variables to Open Sauce that carry over between sessions...
You can use these globals. So there is no need to use OS for that.Quote:
Originally Posted by Dwood
Not enough globals. I have, what, six skulls right now? Besides, we might need some for other things... would be VERY useful if we had lots of empty variables to use.
The problem is if those values still be there when I turn off the game and start it back up again & what sinow said.Quote:
Originally Posted by ShadowSpartan
You don't need a single global for each skull. You could do, for instance, 2 skulls per float. If f0 = 0 then Skull A and Skull B are not active, if f0 = 1 then Skull A is active, if f0 = 2 then Skull B is active, if f0 = 3 then Skull A and Skull B are active. Those 5 globals are more than enough for you to do the skulls.Quote:
Originally Posted by Sinow
Of course the values won't be there when you close Halo, but why would you even need them to be?Quote:
Originally Posted by Dwood
Certain Single player elements like what weapon you ended with , how much ammo perhaps, et cetera.Quote:
Originally Posted by ShadowSpartan
There are also a few other things I would find use for them but to explain further why I want the variables to carry over between sessions of Halo is something that I'm not ready to disclose publicly. You have my AIM so you can message me about it but only if you're willing to create a way to expose variables in Open Sauce. :P
Not true. If one of those variables means that two skulls are inactive, then that would be misleading; I cross-referenced all skulls, with scripts that detected which skulls, specifically, were on or off.Quote:
Originally Posted by ShadowSpartan
And also, in Halo 2, the same thing happened; turn off the game and the skull effects would be erased until gotten again.
HOWEVER it would be cool if I could make a new part of the main menu to include skulls; that way you can activate skulls which you've already gotten in the campaign from the very beginning, like in Halo 3.
Misleading to who, yourself? It is pure laziness to not try and create a compact way of doing something, you should not be wasting "resources" like that. If you have scripts that detect which skulls are active or not...you can just check the globals like I described, and add onto that idea for as many skulls as you want to add. I fail to see how the way I described of doing it is bad.Quote:
Originally Posted by Sinow
Why do it your way when it is easier to simply have 6 booleans?Quote:
Originally Posted by ShadowSpartan
Because you can do the same thing with a single global, use the other four for something else, and ultimately not have to rely on an OS dll for anything.Quote:
Originally Posted by Dwood
You're talking about resources... when it comes to a mod you have no idea about, a computer than runs on simple energy and would take JUST as much energy to do something as it would anything else, and criticizing me for an IDEA I had?Quote:
Originally Posted by ShadowSpartan
And, also, you contradicted yourself. How is that laziness to make a compact way of doing something? If you want to make something quicker, you want to use LESS effort. In any case, it is not that I am trying to find a quicker way; its that I'm trying to find a way to do that ONE thing first.
Why would you want to have to rely on an OS dll when you have another option of doing it with the game in it's current state? It's not bad doing it this way.Quote:
Originally Posted by Sinow
Less effort to accomplish something does not make something quicker in terms of computing. I'm not talking about speed anyway, I am talking about using what you have already in the engine without modifying it through an OS dll. Having a single global for each Skull is not a compact way of doing it. You do not need a single global for every skull, and you do not necessarily need to use OS for this.Quote:
Originally Posted by Sinow
Possibly not, but we don't need Kornman for everything, do we? We could export everything from Guerilla and edit it like that; but no, as you said, it is a way of conserving time and energy. But, is it possible without OS to have constant variables? Is it possible to do most of what H2 and H3 does without OS? You're right, we don't need OS to do what I have already done, seeing as I did it already. But some of the things I mentioned would be easier, or simpler, or possible with OS.
OS2 has a settings component that you can used to save/load values between sessions. Then there's an InitializeForNewMap function in TagGroups that you can use to update things between maps. The advantage of using OS for something like skulls, is if it was built completely in OS without scripts, then it would be map independent and could be used on any SP map the user decides to play.
I was wondering. From what i've heard, using OS script functions on a non OS installation causes an exception, but does this happen when the function is actually used or when the map is loaded? Because if its only when it is used, would it be possible to have a predetermined script global bool (ie one defined in a halo script) that will be false by default but set to true by OS if the user has it? If so this would let map makers use OS functions only when OS is available.
Um no, computers dont necessary consume the full amount of power. It depends what tasks are running and what devices are running.Quote:
Originally Posted by Sinow
Whats the deal with mislead people posting and demanding stuff in his thread?
It would exception anytime the engine ran into the script function/global that wasn't native.Quote:
Originally Posted by FireScythe
One thing you could do is set developer_mode to a specific value (ie, 88) and this would represent that OS is in fact running.
I had put forth some code which checked the script imports in the loaded map and compared it with the script functions/globals in the current game state (the script exports). Pretty sure the final version of it wasn't in the RC though. Anyway, the hope was to use this to try and gracefully put the player back at the mainmenu when they didn't have the required scripting implementations in their OS that the map said it imported. Using this built in system plus a hard coded change of a known script global would be a sufficient setup considering this is just an external game extension and not a source modification.
The only problem then lies within the scripter to actually have the brains to remember to encase their OS script usage inside a check of "(= developer_mode 88)" or what have you.
Also, the skulls system shouldn't be handled by scripts at all. If anything, they should employ their own settings group like Fire was saying. Since this would be OS specific, you shouldn't put too much dependency in the map's design on OS specific data which doesn't have anything to do with its scenario (which is why the netcode enhancements aren't part of the scenario settings anymore, it's a setting for the user not the map maker). OS has its own mechanisms for editing settings while in-game.
If I can get this together right then my goal will provide an excellent mod via OS.
needs creative crit on my suggestion from a few pages back
you know in vehicle tags how you set the vehicle type as "human jeep" "alien fighter" etc
is it possible to combine these traits to create vehicles like the brute chopper
so a "front" field and a "back" field but perhaps also a "movement control" field to allow things like the strafing ability in the ghost to other vehicles
or just a "can strafe" flag
I added 12 custom globals to Open Sauce. Half are booleans and the rest are Floats. Probably should add some ints but I don't feel like it right now lol.
Trying to add Custom function where it'll save the value of those globals whenever you invoke it.
So there is a way to save settings that will not be lost when the game is shut-down then? If there wasn't I was going to ask why you couldn't just put some code in to save a text file, elements of which could then be loaded into varibles by OS next time you play the game.Quote:
Originally Posted by Kornman00
I haven't tried this but is it possible to get the coords of a specific projectile when it is destroyed, and then move a (specific) command list point to that (now destroyed) projectile?
I know this is a double post, but what if we had a way to define our own in-game hud so we don't have to depend on the map itself?
something on the killcam, playing odst made me think: if the player could still rotate the camera after their dead it would make dying so much more interesting
or even being able to activate a flying camera which is not attached to the players dead body
Both have been accomplished before by Skyline and I. The first one is working in 1.09 (non OS).Quote:
Originally Posted by MissingSpartan7
and I have it :realsmug:Quote:
Originally Posted by Limited
He gave you STL?Quote:
Originally Posted by CrAsHOvErRide
and Syphilis :O
I would like to add an idea, where instead of referencing our custom SCRIPT globals in XML and compiling it with cheApe, we have a single scripting globals TAG that lets us define them... would that be too hard to add to OS Sapien (korn)?
What's wrong with how it's set up right now?Quote:
Originally Posted by Dwood
Nothing, but being able to just have a tag type for defining hs globals would make it easier to add new ones.Quote:
Originally Posted by ShadowSpartan
For one, it is far easier to copy/cut/paste XML definitions than using the HEK to try such things. Second, I'm not redesigning the internals of the HEK extensions to depend on a tag file instead of a lower level implementation file (thus, I don't have to wait for the tag system to be initialized before I setup the scripting additions). The pros outweighed the cons for this setup.
The only reason I include them in any tag definition to begin with so anything which loads the compiled map knows how to process the custom script data.
Just make a program which acts as a frontend (GUI provider) to the backing XML definitions if it is that much of a factor.
Would you be able to make it so when you pick up a flamethrower or chaingun it autmatically changes to third person like in halo 3? (with the camera close to the player and to the right a bit).
Or make it so it goes to 3P when you pick up a weapon with "3p" or something in the tag name (for custom tags)
That shouldnt be too hard but i cant remember if 3p was working or not.Quote:
Originally Posted by Gravemind
IIRC Choking Victim got a 3p system working, but it involved using a script to make your player enter a biped that had a seat. The colors did not sync, and their might have been more problems.
This is Open Sauce, this wouldn't need any fancy tagging :PQuote:
Originally Posted by CodeBrain
Yes it is possible. I did it months ago, though it wasn't complete and not the best way to implement it.Quote:
Originally Posted by Gravemind
However, you do need to be a competent programmer in order to do anything useful with Open Sauce.Quote:
Originally Posted by Dwood
his user title is "Programmer"
You mean me? Yea I am a programmer but im new to open sauce... And C++. I usually do VB and C# but im still familiar with some C++ stuff, although im having problems getting the OS v2 to open with the express edition of visual C++Quote:
Originally Posted by Heathen
Just a little heads up, if you are trying to compile OS with Visual Studio 2010, it won't work. OS and VS2010 don't get along, I tried for quite a while to get it to compile with no luck. Once I switched back to VS2008, everything worked fine. If this isn't your problem, I suggest you post in this thread, and give details about the problem you are having.Quote:
Originally Posted by Gravemind
No that not the problem, i have the full VS2008 Express with visual basic, visual C#, visual C++ and web stuff, the problem is that when i open the .sln file and the .vcproj file, it says
Solution folders are not supported in this version of the application.
Solution folder '<folder name>' will be displayed as unavailable.
and it does this for each folder. Then it complains that the projects in the YeloDebug folder are .csproj files and wont work with visual c++... (if i open it with C# it says complains about the C++ parts...) then it says "Some of the properties associated with the solution could not be read".
I dont know what to do about the solution folders part because i cant afford to buy the non expreass version of VS (if its not supporting solution folders because its the express version)
I separated the projects into solution folders based on their categorization since OS isn't just for one specific game or really even platform. Like Express says, it isn't supported. I use VS2008 Team System so I have a lot more over the free editions of VS. I wasn't aware of the solution folder issue though. It's not a real issue as long as you can open the actual project files (eg, Halo1_CE.vcproj)
I'm pretty sure you're using Express editions of specific products (IE, Visual C# Express). I don't think there is an Visual Studio Express. If there was, you wouldn't be getting complaints from the system as far as the csproj or vcproj files.
What i have came from microsoft.com as an iso and calls itself "Visual Studio 2008 Express edition", it has all the express editions in one. (VB express, VC express etc). I tried opening only the Halo1_CE.vcproj file rather than the solution file, but it still says the same errors...
While the ISO may have had all of them in one package, unless the actual editor itself is Visual Studio (and not just single executables like Visual C#) then you'll get those errors.
I don't remember anyone having problems opening Halo1_CE.vcproj in Visual C++ Express so I'm not sure what you could be doing different. Either way, I don't support the Express editions since I don't use them.
I managed to fix it by deleting the solution file... Is Halo1_CE the main project file i need? Or do i also need the YeloDebug?
Edit: (to avoid a double post)
Would you also be able to make the OS tool allow compilation of sound tags where the .wav file is more than 12mb? (or 14, whichever it was)
Just re dl vc++ express and install that.
He already has Visual C++ Express installed...why would he reinstall it? Those errors are normal when you open the OS project files using the Express edition. It will compile file, once you have the boost libraries of course.Quote:
Originally Posted by Dwood
I never had those problems with vc++ Express Edition ... create a new project with ee and add the files?
I highly doubt that. Visual C++ express does not support solution folders, so when you open the OpenSauce solution, there will be 4 error messages relating to solution folders. After that two more errors shows up about "YeloDebug" and "Xbox Controller Emulator". Those projects cannot be opened because they are C# projects, not C++.Quote:
Originally Posted by Dwood
I merged all of the errors that C++ Express gives when you open the OpenSauce solution into a single image below. You had to have edited the project in some way, disable warnings in C++ Express, or just forgot about seeing these errors. My C++ installation has not been edited in any way, and that is a clean OS build.
http://shadow.modacity.net/misc/opensauce_errors.png
I dont remember those errors but then again i havent used vc++ ee for at least 3 months. i do remember the grey folders though so yea you most likely are right.
Those are exactly the errors I was getting, although I fixed it by making a new solution with only the halo1_ce folder. Now it when I compile it, it says it cant find "afxres.h", which im guessing is supposed to be in the same folder as "resource.h" (in the project folder) because it is right after it in the #include parts. I looked around in and near all the extra include folders but I couldnt find the file... I have installed the three things Korman had links to in the OSv2 RC thread. (DX9 SDK, Boost libraries, and DX runtime)Quote:
Originally Posted by ShadowSpartan
Have you added them properly to vc++?
I put the boost libraries in the program files folder and added it to the extra include folders in the settings, and none of the boost parts have had errors so far. The DX SDK integrated itself into VC++ and the runtime installed normally... I also made sure the boost version I got was the same as the one that was first in the include folders settings, the DX SDK i downloaded was dated at March09, if that helps, although it was the only one on the linked page
You can happily remove the greyed out project folders from the solution without any problems. The only error you will get then is the properties could not be read error. Just a minor annoyance.
For the afxres error see here:
http://www.modacity.net/forums/showt...787#post466787
+rep ^
Thanks, it compiles fine now
Edit: In the list in the first post, making moveable objects (without calling them "vehicles") is #3, but its crossed out. Is this because its done or is not possible? -->
You could create a tag type similar to the "crate" tag type in halo2 but that would probably mean creating a new object type as well, and the OS sapien would need to be updated to be able to place the objects...Quote:
What you can't do:
- Create new object types
Edit2: Would it be possible to use open sauce to increase the grenade limit? If you just increase the block limit in the grenades part of the gobals it might work but it might also conflict with something and maybe need hud fixes
Edit3: Would it be possible to make a new console command to test if two objects are within a certain distance of each other? eg: (test_object_distance <object1> <object2> <distance>) and it would return true if they are within that distance of each other
Also, on your third idea, it's possible to use variables to call functions so that could work too. Someone needs to be able to get the positions (x, y, z) based on strings someone inputs.Quote:
Originally Posted by Gravemind
(Answers in bold)
With the grenades, i meant adding more types, like how halo 3 has four types, what i meant about the globals is that in the grenades section (above rasterizer data) it only allows you to add 2 types.
With the 3rd part, im pretty sure its possible to get an objects XYZ positions, if i knew how to get the positions and add the console command i could do a function to get the distance between them, although like you said, the script functions with parametres need to work properly
Oh it's possible, I just don't know how.Quote:
Originally Posted by Gravemind
If the position testing console comand did get get done, would sapien have to be updated to compile game scripts with the new functions? Or would it be easier to attach a trigger volume to one or both of the objects?
Korn's included, inside of Open Sauce, a way to define our own functions in Sapien. Sapien won't run the commands, per se, but it will happily compile them so that you may use them ingame.Quote:
Originally Posted by Gravemind
Oh ok, i knew you could make script functions but i didnt know you could define them in sapien, although i dont really know terribly much about open sauce, but im learning
Go into the Open Sauce folder and get the Open Sauce toolkit. (all the Sapienbeta, Guerillabeta, etc as well as the Open Sauce folder and the Open Sauce ide. In the Open Sauce folder I'm talking about should be a che Ape folder. Look at the xml that's included inside that folder.Quote:
Originally Posted by Gravemind
Oh I see, i thought they were examples for guerilla tags, i didnt notice the script functions/globals parts. Thx, that will help with some things i thought might become problems
+rep on that post ^
I have an idea... dynamic maps...
I'll detail it a bit more in a picture and doublepost.
Proof of concept of giving Halo soft particles:
http://i362.photobucket.com/albums/o...particles1.jpg
http://i362.photobucket.com/albums/o...particles2.jpg
Just takes a couple of extra lines in my GBuffer code to put the depth texture into a texture sampler, with a small addition to the effect vertex shaders to get the particle depth. However, it requires re-writing the effect pixel shaders to use the two depths to get a fade value, but I can't be bothered to do that :v:.
Epic.