No it doesn't, I don't see why he would want to use a real (float or decimal) number as the return type. Explain your reasoning.Originally Posted by FRain
Rambo, how exactly are you going about changing the "lighting"? Are you going to switch the bsp and just have multiple bsps in the map, or try to change the lightmap that is referenced in the bsp tag in real time?
Last edited by ShadowSpartan; November 2nd, 2009 at 09:29 AM.
You would have to modify the Halo1_CE project's (part of the OpenSauce SDK) code in order to implement the script functions, then compile the code changes to get a new DLL. C++ programming isn't optional for this kind of stuff.
If you're wanting to be able to get the current index then I would suggest exposing a C++ variable as a hs_global, not a function. Also, for a complex TOD system such as that, a better system would be to have an enum in the tag data which states if the lightmap_set is dawn, midday, dusk, or night then programming a set of boolean hs_functions (since there is no support for defining new hs_types, like a new time_of_day enum) like tod_is_midday which you can then use in a cond block.
You have to set boundries with what you put into HS in Halo 1. It isn't exactly meant to be something like UnrealScript or TorqueScript where you can just program new parts of the engine via scripts. Its meant to drive specific scenario logic.
Thats as far as I'm going to try and explain this as most of this should be apparent with experience in tag definitions, halo script, and C++ programming. You'd probably be best off finding a C++ programmer to help you put this into the codebase. 1234- not it.
Shadow...calm down(e: referring to your earlier post)
Yeah I was afraid of that. If you have any time at all that's free, could you compile the functions into a new DLL so they at least read properly so we could use them with the tag? Chaos doesn't know much C++. He basically programs in VB.Net when making his Tool # program. I'm just asking nicely if you could make it work for the next updated DLL release on the main page of the OpenSauce RC thread. I'd really like to start using the lightmap function and making custom skies to go with it so we can ditch this old way of doing things.
Also, about client-server syncing, is it psible? I ask because I know why it's not working. Remember way-back-when, when Bungie releasd a 1.07 patch to fix "hackers" sending "false" data? Well, the reason why the game drops you from the server when false packets are sent is because they either are not signed or this stupid protection method gets in the way. We need to find a "backdoor entrance into the game by which we can sync up devices and other data more efficiently than a biped kill.
Last edited by Rambo; November 2nd, 2009 at 09:58 AM.
I told you earlier, I wasn't pursuing this. I added some stub definitions for the scenario's yelo extensions but that's about as far as I'm going with this, I just don't have the time. Even if anyway put stub code into the DLL too, you wouldn't be doing anything with TOD...as the process implies, it's stubbed functionality. I'm pretty sure we've gone over this already.
Custom message deltas could be done if someone figures out why the game appears to send them fine, but yet clients don't appear to receive them at all. I've stated this before, the custom networking in OpenSauce doesn't work.
I'm still trying to piece my development environment back together (in what free time I can find) after Windows crashed on me harder than the twin towers, RIP those at ground zero. However, I won't be able to setup anything which will let me test any further additions to OpenSauce so once I do get my environment going again the only thing I will be doing for OpenSauce is making sure Update 2 is ready for release.
Yeah...we all have our days.
What's worse, is that I've spent 15 hours in the scenario tag on Guerilla for the past week or so. I've been using guerilla so much I'm hallucinating. Mb it's come to life and learned to hypnotise people?
The Guerilla background is pretty hypnotic.
Korn, I'll send you the pm or try and catch you on AIM about certain things in the Project Yellow tags etc.
Last edited by Dwood; November 2nd, 2009 at 12:56 PM.
What I have to say is a rather lengthy post but what I feel is a worthwhile one to read, so please, listen up.
I know why the client/server syncing isn't working, guys.
Do you remember way-back-when, when there was a patch to remedy the problem pertaining to "false" data being injected into the data stream causing a server to crash if a malevolent attempt at hacking were to succeed? I believe it was Version 1.07 that addressed this bug, maybe 1.06. Along with that bug also came a slew of other fixes, including the demolishment of the old sightJacker and other programs being broken.
But that isn't the point here.
Anyway, The resulting "solution" involved servers rejecting clients from connecting to the server if they sent a "false" packet or received one. the client would either say, "Network connection lost" or "Unable to join game server."
where I'm going with this is simply this. Kornman00 based his Open Sauce Yellow code off of a patch that was based off of a so-called bugfix patch. He may or may not have been aware of this bug when he designed the d3d9.dll file in the first place, let alone its code. We are this close to a solution to the Server and Client Upgrades. I am aware that Kornman00 tested the functions such as doors syncing and the result was any client that received the data was booted from the server. Why is this? it all goes back to that pesky "security fix" that spawned a slew of "white hat problems", including the device syncing.
It is my wish and desire that somebody out here that knows what they are doing can identify with what I'm saying, look into the issue, and come up with an "unsupported fix" in the form of a new d3d9.dll file that will address this problem.
An easy way to find the problem is to create a PPF file containing the differences between the two versions (source version wihout the problem and destination version with the problem). Another easy solution is to "downgrade" Yellow Open Sauce to support 1.04 or 1.05 Halo CE so that, in the right testing environment, this could be confirmed or disregarded as the problem we've been having. Once it has been determined that the problem does in fact reside in the fix for the hacker problem, we can then create a solution to the problem.
I fully feel that this can be done, guys. I am confident that someone out there will at least consider my thoughts and perhaps investigate them. please, I urge someone to at least look into this issue and help solve a long-standing gripe in the Halo CE community. Thanks.
Sincerely
~Rambo
EDIT: Chaos and I are currently looking into the issue by attempting to downgrade Yellow Battery to a prior version of Halo CE. We are taking it upon ourselves to come up with a test environment for all of you to use to resolve this problem with the device syncing.
EDIT 2: The attempt at modifying the source code failed. We were, however, able to remove the version check; however, we don't know where the DirectX proticols are and how they mask the real DirectX to interface with the Halo CE Executable that is 1.08 so we can make it run on the stock Halo CE framework. Even if we could get a 1.03 or 1.04 build working with d3d9.dll, it would be a blessing. Kornman00, would you please help us, or if not, would someone help us make this work on a early framework? We don't care if it's stable. We just want to test the netcode.
Last edited by Rambo; November 5th, 2009 at 03:41 AM.
It's Yelo. If he wasn't aware of this "bug" then how did he base his code off of that patch? And a better question, how do you know that is what he did? You contradicted yourself, acting like you know more than you actually do.
Don't you mean "in the form of an edited version of Open Sauce's source code". Just having a dll file won't help you much if it can't be implemented into another person's OS codebase.
Wow, I can not believe you just said that. So you want to compare two different versions of the Halo executables, let's say 1.04 and 1.05 as an example, and you think doing a simple hex compare will show you what code was added/removed? Seriously? That won't work because the memory addresses for the same code in the executable will have changed, so the hex will drastically differ.
I doubt anybody will go through the trouble of downgrading OS to a previous version. You would be better off figuring out how to get the client to accept modified packets, and add that into the current version. Downgrading OS will undoubtedly cause a lot of issues and bugs that you will have trouble tracking down and fixing.
It sounded to me like you were pretty confident that is why the server can't send modified packets to the clients, why are you second guessing yourself?
How are you downgrading Yelo Battery without the source code? Unless you were referring to Open Sauce, which in that case, how do you plan on doing this if you cannot even add a script function to the game using Open Sauce?
From what I've understood about the upgrades, Bungie/Gearbox/Microsoft did a patch-fix to disable packets that were unsigned from working. From what I also understood, most of the updates after 1.06 were security fixes, not changes to the actual engine.
In theory, would it not be logical to argue that Yelo/Open Sauce would work on 1.05?
I'm going to say that nobody here besides him and maybe a few others knows exactly where he based his code from.It's Yelo. If he wasn't aware of this "bug" then how did he base his code off of that patch? And a better question, how do you know that is what he did? You contradicted yourself, acting like you know more than you actually do.
Now, back to another theory.
Back before 1.06, it was possible to send unsigned packets to the server. Usually, this would be used for malicious intent (obviously why the patch was released to stop this.) What if, and this is a big if, we drop back down to 1.05 just to test the theory that this patch is the source of the device synchronization error that has eluded a fix for ages.
Until recently, this hasn't been a major problem obviously, we just stick to biped syncing across things to make things click. This is no problem until we start having a whole bunch of bipeds. The whole reason for this 'test' is to see if we were right. If we are in fact right, then we can proceed from there. If not, we tried something that (to our knowledge) hasn't been tried before.
We are pretty confident in this. That's the reason we're trying to go through with this, is to see if this patch that Bungie released is what stopped it from even starting back at 1.05. For all we know, Bungies own solution to a hacker exploited problem could be the curse that's stopping this.It sounded to me like you were pretty confident that is why the server can't send modified packets to the clients, why are you second guessing yourself?
I do have to say, the arguments that are against this is...quite staggering. Why would someone be against something that actually wouldn't cause harm and even further progress the Halo CE community?
I will agree with you there. Here's an even simpler example: I take the MD5 hash of 'a', and the MD5 hash of 'b', and compare them. There is absolutely no chance to know which is which unless you know what they are.Wow, I can not believe you just said that. So you want to compare two different versions of the Halo executables, let's say 1.04 and 1.05 as an example, and you think doing a simple hex compare will show you what code was added/removed? Seriously? That won't work because the memory addresses for the same code in the executable will have changed, so the hex will drastically differ.
Don't you think we have already figured this out? The whole point of doing this is to see if we are right to begin with! Why bother modifying a packet to the 'signed' version if it won't work to begin with. Wasted effort brings no results. If we figure out that the patch was the issue to begin with, then we can confirm these results and figure out how they changed the packets.I doubt anybody will go through the trouble of downgrading OS to a previous version. You would be better off figuring out how to get the client to accept modified packets, and add that into the current version. Downgrading OS will undoubtedly cause a lot of issues and bugs that you will have trouble tracking down and fixing.
Well duh.Don't you mean "in the form of an edited version of Open Sauce's source code". Just having a dll file won't help you much if it can't be implemented into another person's OS codebase.
I'm just curious as to how this even relates to what we're discussing. Care to elaborate?How are you downgrading Yelo Battery without the source code? Unless you were referring to Open Sauce, which in that case, how do you plan on doing this if you cannot even add a script function to the game using Open Sauce?
I shall now sit back, and try to figure out why someone here would, instead of help us, argue against us in something that might actually change the future of how Halo Script needs to be written on devices.
Yelo uses the engine's existing networking framework...there is no "unsigned data". Not only that, but the server reports a success when encoding a message while the client never acknowledges receiving what the server claims to have successfully encoded. The client doesn't drop from the game either when this happens.
AHEM!!!!!!!
Kornman00, by no means do I mean to bash you by saying this, but I'd like to point out the following regarding your previous post pertaining to Chaos' response. This deals directly with the netcode issue and my hypothesized presumption.
As quoted directly from the User Manual for the Open Sauce Yelo SDK...
And there you have it, ladies and gents, exactly quoted from the manual itself. If the 1.04 or 1.06 patch is the culpret, I'd say we have ourselves a possible solution. Now, all we have to do is identify the guilty suspect and passify it.ยท YELO_NO_NETWORK – Applies to all builds. When this is defined, all network based code related to changing the engine's code to support more network message packets isn't called nor compiled under the current build target. Currently the support for new network messages doesn't work. No actual crashes occur however, when one of these new packets are sent to a client it causes said client to think the connection was lost. Obviously there must be some code still only expecting the original game's messages only, thus causing the client to ditch the server thinking it was sent some bad message data.
Last edited by Rambo; November 5th, 2009 at 03:44 AM.
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
Bookmarks