Ok... i have to point out this obvious observation...
That wasn't just obvious... that was Painfully Obvious!. so painfully obvious that it had to be said because everyone else was thinking it! lol
Printable View
Ok... i have to point out this obvious observation...
That wasn't just obvious... that was Painfully Obvious!. so painfully obvious that it had to be said because everyone else was thinking it! lol
^ i am temped to directly tell you to stop posting because you keep posting obvious stuff that's off-topic anyway /rant
anyway another idea
-being able to define an "environment", e.g. like in halo 3 how objects can be placed on the elefant, maybe be able use a script like (create_environment_from *object*) so that we can place objects upon other objects without having to position them manually
hmmmmmm
objects_attach
objects_detach?
and aparently making a deveice machine elevator the same shape of your vehicle. and attaching it on when there's a driver makes anything inside it move like it should :D
please,
we are trying to create new ways of doing things, rather than use the old ways
and also maybe pre-game lobby?
-with things like a chat box that everyone can use
-voting?
also-also a new ingame chat function?
e.g. when you press "t" to talk to everyone you can type "name"/ to talk to a specific person
Saap has voting, and advanced chat is sorta done.Quote:
Originally Posted by MissingSpartan7
It would be nice to create our own Lobby for OS. Perhaps we could have OS contact a 24/7 server and contact that, then while ingame, go to x and x server thru menus?
well its a bit of a drag that the physics engine can't be updated or edited or replaced with a better 1 :(..... uhhhhh hmmmm..... how is the physics engine incorporated into the game?
the only reason i ask is...... how hard could it be to add some friction calculations to it?
seriously, have you read the first post and what Korn had to say about OS in that little section in the first post?
Well it might work, but it depends on the object you want to add friction to.
Only because, compared to ragdoll effects, that would be easy. Assuming you're adding it to a player, you would have to get the surface the player is on and set it from there, probably setting it all as custom globals within an os-only script.
I didn't read all 31 pages so forgive me if this was suggested, but would it be possible to unlock Sapien's function to make custom recorded animations?
I'm damn sure that the recorded animation code was completely ripped out of Custom edition (except for playing them). Although, I'm not sure where I heard this, but you can make recorded animations, just not with Sapien, and you'll have to place the x,y,z coordinates manually. I'm not even sure that works and thats 100% speculation, not sure.
You can make RAs with the current editing kit, you just cant move the units so theres movement in the RA.
This^Quote:
Originally Posted by Masterz1337
The code to read player input is gone, RA code is still there. I've tried binding keys and gamepad buttons to controls via the (bind) function, but it doesn't do anything when I try to move someone or something.
I had an idea for this, but it never really took off. I mapped out the majority of the recorded animation format, I believe it's possible to code something to dump the necessary data to a file based on ingame player movements using open sauce. Then you can merge the dumped data with the scenario tag using an externally created program. I don't see any reason why it wouldn't work, it's just a matter of locating the data in memory, most of which is already mapped in the OS source code.Quote:
Originally Posted by p0lar_bear
Something that would be cool, is a fully functional Novint Falcon plugin.
I had an idea to play .avi files from Open Sauce a while ago, and then people could create hi-res animations if they desired.
I decided not to do it b/c I didnt think anyone would take advantage of it.
You can play .bik files with a function that is in OS already, so there is no need for .avi playback functionality to be added.Quote:
Originally Posted by Dwood
Also, how would you create hi-res animations using an avi file, did you mean cutscenes?
I knew it had been suggested (maybe it was me who suggested it but it may have been somebody else) but I didn't realise Kornman had implemented it. What is the scipt command you need to call it?Quote:
Originally Posted by ShadowSpartan
Well animated .gif files and exported flash animatins are still considered animations by some so I would think any video made using one animation techneque or another (including 3ds Max) could be considered an animation.Quote:
Originally Posted by ShadowSpartan
Don't know if this was ever said, but howabout the ability to dual weild? I'll break down what i'm thinking:
- Picking it up with a button (don't know which)
- The ability to add left hand animations to each of the weapons. So that when you pick a pistol (per say), it has left hand animations and it's a separate weapon.
- Dual trigger shooting instead of just left click. So replace the grenade throw with it.
- If you drop one gun you can keep the other still.
All I can think of for now.
Duel weilding has been said many times and can NOT be done properly.Quote:
Originally Posted by ThePlague
:C
It's not a script command, it is a C++ function contained in Game\EngineFunctions.cppQuote:
Originally Posted by Rhydgaled
Code:void PlayVideo(cstring bink)
If you used that logic then dwood's post would read:Quote:
Originally Posted by Rhydgaled
Doesn't sound correct does it?Quote:
Originally Posted by Dwood
I meant Videos under your definition. You know, animating in 3ds and rendering it, allowing for mediums other than what we have at the moment because atm we can only play .bik, not make anything with them.Quote:
Originally Posted by ShadowSpartan
Effectively, it would be a cutscene. Then CMT or any other SP map team could have better quality cutscenes than what the engine could render.
e2: ThePlague, check the first post. My psp ran out of txt room or id elab.
You could just convert the rendered cutscene from .avi to .bik, there is no need to add .avi playback functionality.Quote:
Originally Posted by Dwood
I enjoy the fact that the Halo games use the actual engine for cutscenes and not a prerendered video. Prerendered videos look amazing when done right, but I prefer the in-game ones.
I'm not familiar with the cutscenes though, but I didn't think that would work right b/c if you drove a hog on the scene, it would still be there for the cuts.
So I assumed conversion wouldnt be possible.
Seriously, I'm confused now, do you know what you're talking about?Quote:
Originally Posted by Dwood
.BIK files are prerendered video files encoded with the Bink codec, provided for free by RAD Game Tools (:google: it). Halo only uses four BIK files by default, named bungie.bik, gearbox.bik, mgs.bik, and ending.bik. The first three are the videos that play at the game's initial load, and the last one is 343 guilty spark floating in space, which plays after the credits roll.
The cutscenes that play in game, such as Johnson's speech to the marines which varies based on game difficulty, are units in-game scripted to do and say stuff.
The two are entirely unrelated.
So Kornman implemented the play bik function itself, but didn't actually make a script command to actually allow you to call that function? Or can C++ functions in Open Sauce be run from haloscript / the dev console (which I very much doubt)?Quote:
Originally Posted by ShadowSpartan
Also I tended to refer to cutscenes/cinematics as videos before I learned the technical terms for such things. I get anoyed when friends call cutscenes (that I still call videos sometimes) something else (adverts I think some of my friends call them, which they most definitlly aren't).
Thanks Polar for the news flash, as I said, I am unfamiliar with how Halo plays its vidjas. believe it or not I appreciate the reality check.
If someone wanted they could make a custom script for playing .biks. I'll look into it this weekend.
more idea
what about campaign scoring?
where points are given per unit and things like headshots
this would be better than the current choices we have for things like firefight at the moment (points per encounter which are recorded with the timer)
Ability to set removable waypoints where the player is looking/standing at which in turn temporarily hijacks the pathing of AI. This can be useful for getting around your ai being dumb as hell sometimes/not following or when you simply want to coordinate team movement in campaign or multiplayer. I thought of this prolly 4 - 5 years ago when I got the idea to make a mod very much the same as Halowars but had no idea of how to.
on the topic of waypoints, could we have team waypoints that show where your teammates are? and change colour if they're taking fire of just died?
Does anyone know if more than 2 grenades are possible? I don't think I saw that one.
There is your answer.Quote:
Originally Posted by Kornman00
Thanks, it's been a while.Quote:
Originally Posted by ShadowSpartan
Actually you can, just not with OS and even though it can happen, this is on a whole other level of reversing and engine modification no one wants to go into currently. Although, claymores would be fun to have. :haw:Quote:
Originally Posted by ShadowSpartan
I asked about multipule campaigns, and was told the OS HEK modifications only allowed you to add missions to the campaign, not add campaigns. However I've been thinking, maybe I could use the OS HEK to create a long campaign (say 26 missions) and put a script at the end of one of the maps (let's say the 10th) which runs the credits and ends the game then and there. Then I could run a scipt on UI startup to unlock the next misson anyway (I think there is already an unlock mission script function) so you could start from that misson because it's already unlocked, essentially that would appear to be 2 seperate campaigns. Would that one new script be easier for somebody to add to Open Sauce than an actual multi-campaign feature?
Also, I don't think I have recived a reply to this:
Basiclly, how far are we from being able to play a .bik file from a script in campaign and UI maps (I don't think there's any point in it for mp maps)?Quote:
Originally Posted by Rhydgaled
Finally (for now), and I may have already asked this one too, could you put some maps (say the campaign ones) in a sub-folder of the maps folder so they don't make the game take longer to load but then load them on request (for example if you access a certain UI screen) instead?
Don't know about all that, but I just looked in OpenSauce and there is a place to add new campaign levels, not missions. Not sure about HEK.Quote:
Originally Posted by Rhydgaled
In Game\EngineFunctions.cpp is a function called PlayVideo(cstring bink). When you call this, it will play the video of the name you inputted. I don't think it's setup as a script or console command, but that can be done easily in OS.Quote:
Originally Posted by Rhydgaled
Um, what?! Not sure what you mean with this. Only one map file is loaded at a time - the one you are playing. The maps aren't all loaded when you start the game, only UI.Quote:
Originally Posted by Rhydgaled
I'm pretty sure he's referring to the checksum (I may have the term wrong) before the UI appears, where CE takes forever to load. IIRC, we've already had this conversation and decided that the only way to fix that would be to obtain the source code, which is impossible.Quote:
Originally Posted by Skarma
I think that he doesn't understand the problem. Masterz explained it best that the problem isn't that we can't play .bik files or things like that, the problem is that we can't create our own animations from the tools in the hek.Quote:
Originally Posted by Skarma
Basically, from what I've gathered from posts and whatnot is that it isn't that the functions to create animations isn't there, it's that there's no way to add User Input at all.
Edit: I mean that the HEK's UI for creating biks is gone completely.
Edit: Or whatever file extension it is that Halo uses to play recorded animations. (ie, every ingame cutscene)
What the hell are you talking about? You don't understand what you are talking about. The HEK does not, nor has it ever had the ability to create .bik files. What you described was recorded animations, Bink Video files are not the same as recorded animations in any way whatsoever. Bink Video is a file format created by RAD Game Tools. There are only 3 Bink Video files played by the Halo 1 game, one for the Bungie logo, one for the Gearbox logo, and one for Guilty Spark flying off at the end of the game (I'm pretty sure that last one is right, haven't played the game in a while).Quote:
Originally Posted by Dwood
Sorry I used the wrong file type name.Quote:
Originally Posted by ShadowSpartan
Recorded animations don't even have their own file type, they are stored in the scenario tag.Quote:
Originally Posted by Dwood
Oh, interesting. Didn't know that. (Obviously)Quote:
Originally Posted by ShadowSpartan
.....that's it!
we could have load points within campaign levels, so from the menu you can load from a major section of the level
(the equivalent of the "rally point" in halo 3)
Yeah, that's right, except I think there are 4 bink files. The 4th .bik is the Microsoft Game Studios logo, it plays along with the Bungie and Gearbox logos at start-up.Quote:
Originally Posted by ShadowSpartan
Now, if somebody makes a script command that runs that play .bik function in OS we might not have to worry about recorded animations anymore. We could render .avi files from 3ds Max, use a video converter to make them into .bik files, and then use said .bik files as cutscenes. Of course right now we can use animated scenery for cutscenes instead, not sure how difficult that is though because I haven't got around to trying it. I would have a shot at making the script command but I've only been taught very basic Java and very basic Delphi (going to be doing Visual Basic this year, very basic Visual Basic probablly).
Quote:
Originally Posted by Skarma
Yeah, not sure about the term checksum either but CE does take longer to load the more maps you have, I was suggesting making some maps be ignored by the game until you click certain buttons. Not possible without getting a look at CE's source code you say?Quote:
Originally Posted by Siliconmaster482
Here's an idea. Use Open Sauce to do the interfacing for this (probably a stretch) but have OS_Tags that are like 3d ui options.
To explain this best it would be like using a biped, once that biped were "killed" OS would take that certain one and commence commands based on what biped has died.
The player would be put into a fixed position where they cannot move, only shoot, and are viewing the 'biped' menu screen in such a manner that they can see all of the menu options. I would go into more detail but I am struggling to stay awake right now.
From what I've heard, this could possibly be used with the now in development Forge as well.
There's a problem with the BIK idea. What if your start-up involves someone flying in on a vehicle or you have cutscenes where you get transported somewhere and get out?
Recorded animations FTW! :P
Heres something that everybody would love.
Right now I am in a predicament with one of my Phantom's, an AI-controlled one that drives around. I changed some of the settings around, and everything works in sapien. No crashes, no problems. Used run_game_scripts and it works like a charm. Perfectly avoids walls and whatnot.
The problem is, when the level loads, and I get to the point where the ai-controlled phantom is spawned, the game crashes with Gathering Exception Data...
My suggestion is to copy that exception data, and put it in a .txt file, like how the chat is copied to a txt file with the use of Yelo from Open Sauce. Unless it's not as easy as it sounds, shouldn't it be just looking WHERE the exception data goes, copy it, and put it in a txt file, and place it in the directory where the other Yelo stuff goes? (Your HaloCE profile in Documents)
How about a script command that allows for arrays to be used?
I'm not sure what it would take to do, myself... but what if we had a new global called 'array' that holds a string which is the name of each global you want to store?
And then there's another idea of doing a more updated version of scripting... here's what it would look like-
(script static "void" variables (var1 var2 var3)
(sleep_until (= var1 1)
(set (= var2 var3)
))
In any case, I hope you get the idea. This way we can seriously cut down on the repetitious coding.
Adding support for generic arrays would require reworking of not only the hs runtime, but also the hs parser and compiler. Even then I don't really see how it can be helpful overall for HS's scripting purpose.
You don't need to put quotes on the return type of a script.
Script arguments can be hacked in, but if the tools are to support them the parser would have to be reworked. You'd be better off just writing a higher level language for HS as you can hide some repetitive implementation facts, but you'd still be having to write your own parser and translator which would have to be ran before the tools.
Halo 3 supports script arguments though. You should upgrade to it :downs:
Oh? I didnt know i could mod halo 3 that way. links or something i can use to look into it?
the ':downs:' was suppose to mark the fact that it was a joke/sarcasm ;x
Sadly, no, can't mod h3 that way (without a dev kit). Not until/unless they make a PC port.
They should dub it H3V7: Halo3 Vista/7!
e: the single quote marks make it looks like the downer has downer arms. ha.
Yeah im posting from my craptacular phone. i cant see emotes on it.
d-d-d-double post!
I would like to expound on my idea with the adding arrays to halo script..
What if you just did it like this:
(global array bool4a (0, 1, 1, 0))
and would be used, in halo script, like the following:
bool4a(1)?
Then when compiling, or pre-compiling, the interpreter or w/e we call it takes the bool and creates 4 separate globals of type boolean, replacing all occurences of bool4a(#) with the corresponding bool...? oh but that wouldn't be advantageous b/c if you introduce randomness, yeah just forget that idea. Might as well do that with an external script interpreter.
Edit coming up with an idea for the 2nd one... Even though it might work better with a separate interpreter outside of Halo.
I'm curious about something, how close was this feature to being finished?Quote:
Originally Posted by Kornman00
What's the point? I don't see any reason why arrays need to be added to the Halo scripting language. Unless you change the way the engine handles the scripts, you would have to create a new script compiler to replace the current one, which will put the new "array feature" into a format the engine can understand.Quote:
Originally Posted by Dwood
Actually you're misreading what I said.Quote:
Originally Posted by ShadowSpartan
Was meant to seal up the array idea.Quote:
Originally Posted by me
I was talking about the script arguments, to which Korn suggested I write my own higher-level language for Halo script (lol)
That is what I was referring to when I mentioned making a higher level language. I originally made up the rough draft (along with how to translate it into usable HS) of PSL during lunch in high school. However, I diverted from the Prom team before any work went into the actual program itself. Rec0 may have worked on it some before he started gathering exception data, but I believe it (in that picture) may have just been an example script of what could be.Quote:
Originally Posted by ShadowSpartan
I never gave up on crafting it myself in my own tools, but I never really drifted too far from the design phase. For me, implementing something like that is a 2.0 (if I ever released a all-in-one version of my tool) feature as there are tonnes more things which would have been more useful (must of them tag management related).
Is that new scripting language to the point where someone just needs to integrate it into a tool or are there still things that need to be designed?
I wouldn't call it a new scripting language, because it doesn't add anything to the Halo Script Language, it's just Halo scripts in a different form.Quote:
Originally Posted by Dwood
Sounds to me like he finished the design phase for the most part. But designing it isn't the only hard part, you will need quite a bit of programming experience to do this.Quote:
Originally Posted by Kornman00
My question was asking more specifically what needs to be done in order for the language to be considered 'complete'. It probably wasn't that obvious however that was the intent. I don't want to assume that he finished the design phase, and then think that he only needs to implement it.Quote:
Originally Posted by ShadowSpartan
-> If it were at that stage I would simply request him to send someone the designs for it and let them complete it.
Yeah, it wasn't obvious. At all.Quote:
Originally Posted by Dwood
I don't see that happening. And even so, who would be up to that task?Quote:
Originally Posted by Dwood
But Halo 3 on Windows already exists! Look, this guy even has completely non-sketchy video proof of him installing an Xbox disc to his computer!Quote:
Originally Posted by Kornman00
Or this video: http://www.youtube.com/watch?v=Yt3CTjZ4nTI
LOOK AT HOW MLG PRO HE IS THAT HE DOESN'T MOVE THE MOUSE!
You never know.Quote:
Originally Posted by ShadowSpartan
e: lol jcap >.>
I'm going to assume that you are wanting to do the project, but I highly doubt you are capable of doing something as complicated as this.Quote:
Originally Posted by Dwood
You assume much. I would like to do it myself, however I know that would be a difficult task which in itself would take ages to do. I wouldn't take it upon myself to do it however I am interested in what Korn had/has designed for Prometheus.Quote:
Originally Posted by ShadowSpartan
Let's look at this quote by Korn again.Quote:
Originally Posted by Dwood
He designed the language, and documented how to translate it into the binary equivalent that is usable by the game engine. That's as far as he got while on the Prometheus team, and he said he wasn't worked on it much past the design phase since then. Why would you need to know the technical information if you don't plan on attempting it yourself?Quote:
Originally Posted by Kornman00
Is it wrong to be curious? You're being pretty hostile when all I'm doing is asking questions that I think that are fairly reasonable. I have not asked Korn for the documentation or technical information or anything like that, and you're attacking me? Jeez.Quote:
Originally Posted by ShadowSpartan
E: actually, let's back up a second here.
That was what I said originally. That was what I wanted to know, nothing more and nothing less. You're taking it a bit far here, do you have like a personal vendetta against me?Quote:
Originally Posted by Dwood
No there is nothing wrong with it, but there is no point in getting the information if you can't even use it.Quote:
Originally Posted by Dwood
*cough*Quote:
Originally Posted by Dwood
You did ask if he would give out the information to somebody, and you said yourself that you wanted to know about it, so you pretty much asked him for the documentation.Quote:
Originally Posted by Dwood
And that was answered in his post about it. "I never gave up on crafting it myself in my own tools, but I never really drifted too far from the design phase." Design phase is pretty much complete, but he has never gotten really deep into the implementation. I don't know how to make it any clearer. If that is all you wanted to know, "nothing more nothing less", then why are you wanting to know about the technical documentation?Quote:
Originally Posted by Dwood
My point was that my original question was there, and that was all that I wanted to know from Korn. I only said those things because you brought them up.
You're taking the original question out of proportion.
And you know what? If you wish to take this conversation further, please take it to Private messages because this little skirmish is seriously detracting from the thread.
And my point is that there was no need to even ask that because his post contained the answer to it.Quote:
Originally Posted by Dwood
Actually, I detailed how to translate it into BSL (HS). There wasn't anything about the proposed language that would have required manipulation of the compiled syntax nodes. Both PSL and BSL were to be supported, so I the best course of action IMO was to just provide a translation unit for the PSL's interpreted syntax tree. This way any optimizations seen fit for BSL could still be applied and such. It was a good separation in my eyes.
I'm sure the documentation I made for "BSL#" (since I no longer associate with Prometheus I'm not referring to it as PSL) will come to light sooner or later.
OK here's what I've done for a Lightmap extender function.
I have set up the appropriate data for structure_lightmap_index and switch_lightmap in the XML file that comes with Open Sauce (examples.do.not.include) or something like that. I then recompiled. Presto! It works fine in Sapien. However, when I try to load the function in game it won't show up. My question is, why? What am I doing wrong? How do i migrate these functions into the project_yellow_globals or at least make them show up?
Please help, someone. Thanks.
Chaos and I are trying to get the lightmap functions to work and we've made it this far.
Technical specifications:
switch_lightmap returns a boolean and the argument is a short. Is this correct? The name for the argument I gave it is structure_lightmap_index.
structure_lightmap_index retrns a short and the argument is a boolean with the name of structure_lightmap_index for the argument name. is this correct?
I'm new to this so please don't come down hard on me. I'm actually trying to make this work. Thanks.
The function doesn't show in-game because it's not programmed into the .DLL HaloCE is using.
You use the CheApe XML definitions (which is later compiled into a memory cache) to make the HEK "OpenSauce Aware". Meaning, any tag group definitions, script definitions, etc. found in your OpenSauce code that you also want to have the HEK interface with must be defined in your CheApe XML.
Also note: Script definitions are just stubbed out HEK, meaning they don't do anything meaningful. They're just there to allow you to properly build "OpenSauce Aware" scenarios.
Why are you defining two functions for this? You would only need one, switch_lightmap (either taking a short to represent the lightmap index or a string which the code will then try to find in the bsp_set blocks).
I need to count the number of ai the player's killed, in a Single Player map.
There are 2 other things I'll be looking at as well:
I'm also looking at finding the variables for jump so I can modify it. Then, I want to modify jump height per player.
2nd, I want to modify speed of the player as well. I'll report back what I find this week.
I want to make all of those editable via scripting.
The statistics code is no longer a part of OS.Quote:
Originally Posted by Dwood
I don't think the jump height is a value in the player table, it would be rather pointless to have it in there. I'm pretty sure the jump height is loaded straight from the biped tag.Quote:
Originally Posted by Dwood
adding more ideas,
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
Dang. I didn't even know it was a part of OS in the first place lol.Quote:
Originally Posted by ShadowSpartan
Jump Velocity is kept in the scenario tagQuote:
Originally Posted by ShadowSpartan
Notice how I said jump height, not jump velocity? You are the one that said jump height in your initial post. I just took a look at the scenario tag, there is not even a single instance of "velocity" in any of the field names. Try again.Quote:
Originally Posted by Dwood
Edit: Well look at that, "jump velocity" is in the biped tag as well. Makes a lot more sense than the scenario tag doesn't it?
Then how do we get the DLL to recognize map resources or at best, program it into the DLL as a recompile?Quote:
Originally Posted by Kornman00
Because, when making a complicated day-night system where the lightmap needs to sync according to the biped killed, you don't want it to just switch Lightmap because then it might get stuck without a check. That's why I incorporated a check function such as structure_lightmap_index to make sure that if someone tries to glitch the lightmaps or BSP switches by selecting a BSP or lightmap other than the one in use to purposefully mess up the time of day to gain an unfair advantage over someone, they cannot. With a complex but robust checking system, the lightmap would be able to be locked to where it is, but that could only be done via a structure_lightmap_index command.Quote:
Originally Posted by Kornman00
Furthermore, I want to have the ambient sounds change according to what time of day it is (e.g. crickets and owls for night time and birds and cicadas for daytime). One could easily do this in a cluster portal, but I'm using sound scenery to make the experience more "full" sounding, if you know what I mean.
So I should set switch_lightmap as a string argument and the return should be a boolean, correct? What should the structure_lightmap_index be?
Common sense says it should return a real for both of those.Quote:
Originally Posted by Rambo
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.Quote:
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?
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 :downs:.
Shadow...calm down :slap: (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.
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... :shrug: 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.
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.
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.Quote:
Originally Posted by Rambo
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.Quote:
Originally Posted by Rambo
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.Quote:
Originally Posted by Rambo
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.Quote:
Originally Posted by Rambo
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?Quote:
Originally Posted by Rambo
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?Quote:
Originally Posted by Rambo
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.Quote:
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.Quote:
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.Quote:
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.Quote:
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.Quote:
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?Quote:
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.Quote:
ยท 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.
I'm pretty sure I got it to the point where the client doesn't lose the connection in the current codebase (read: newer than the Update 2 RC). I'll try to give a build to two people this weekend to try and verify this, but I'm pretty sure I took a little stab at the networking after the RC was released.
Did you look into the v1.04 (or possibly v1.06) patch issues that spawned as a direct result of Bungie's attempt to solve a black-hat hacker related issue of malicious code entering and crashing a server?
If you could compare the code for the network packets from, say, a stock build of Halo CE, and that of the current build (stable 1.08), what would you find? Would you not find that the packets need to be somehow signed or at least verified as not being malevolent in nature (according to the patch requirements of that era) so that the doors and other devices would function?
Kornman00, you're probably going to kill me for asking this, but may i please be one of the people that tests this issue? My map is extremely heavily based in syncable objecs -- BSPs, doors, lights (light fixtures), even the controls themselves that govern the syncing of these very objects that themselves must sync according to the toggle switches. I would be, not only more than hapy to, but very interested in having a stab at the DLL file so that I can report ANY issues to you that I might find.
Would you please at least consider me, since I am working on a map that requires the least amount of bipeds for the least amount of lag? I'd be more than appreciative and grateful. Thanks.
BTW: When you also tested the current runs of the newest DLL, did you remember to remove the line mentioned above in the User Manual quote? if not, perhaps this is why the code isn't responding client-side. Just an afterthought, that's all. And yes, I could test the build and issues locally with no need for a friend online by testing via my LAN over two different computers with the same map and same everything.
PS: Not to stray from the bug topic at hand, but one of my ideas (if it's possible to implement) would be to allow Open Sauced game servers to host a maximum of 32 players instead of 16 on a T1/LAN connection. This would be pure pWn4g3 on a Machinima server or a MMORPG server.
Is it possible to implement this with somewhat fair ease, Kornman00?
Yes, but that is only if you don't mess something up while downgrading Open Sauce. I highly doubt you won't run into any major problems.Quote:
Originally Posted by formlesstree4
I'm just trying to be realistic here.Quote:
Originally Posted by formlesstree4
Why don't you try to figure out why it won't work, rather than jumping on the idea to downgrade OS.Quote:
Originally Posted by formlesstree4
He said that you were downgrading Yelo Battery. The source code to Yelo Battery, to my knowledge, has not been released. Some of the Yelo Battery code was incorporated into Open Sauce though. So did he mean to say that you guys are downgrading Open Sauce? Because Yelo Battery is technically not the same as OS.Quote:
Originally Posted by formlesstree4
As I said above, I'm trying to be realistic. If you cannot even get a new script function working, what makes you think you can downgrade all of OS, as well as reverse engineer the Networking code? Also, this wouldn't really change Halo Scripting in any way, you just wouldn't have to add syncing scripts because they will sync automatically.Quote:
Originally Posted by formlesstree4
..................Wow. It's not possible, end of story. Do you just post about whatever crazy ideas pop into your head without even thinking about them for 5 seconds?Quote:
Originally Posted by Rambo
Listen. If it weren't for "crazy ideas", we wouldn't have HALF of the stuff that WE, as a planetary society, more than take for granted. Things such as how the world was proven to not rest on a turtle's back, or at best, be flat; or how the earth actually revolves around the sun and not the other way around; or for that matter, the electric Lightbulb invented by Thomas Edisson, or even the telephone that actually was, if I'm not mistaken, an attempt at making the telegraph better, attempted by Alexander Gran Bell... Heck, I'll even throw in radio and television and, for that matter, even the microprocessor that ALL OF US HERE on this forum DEPEND on to communicate with one another... All of these things we take for granted and yet they spawned from seemingly insurmountable odds sprung from "crazy ideas", as you so elequently put it. Proud inventors slaved their ASSES over "crazy ideas", to put it so bluntly. Even though, yes, they had the time, patience, and know-how to make "crazxy ideas" work, tey were STILL "crazy ideas" neverltheless.
For every person in this world that ever said such "crazy ideas" would never, i repeat NEVER come to pass, there were more inventors than roadblocks to prevail and this caused the negative people's tauntings to become no more than stumbling blocks to a mad man's dream come true. I may not have the way-with-all as far as know-how to actually accomplish these idead by myself, but I have friends that at least care. Yes I may consider myself to be a sort of visionary-type person with wild ideas, but look at what I've done with the raw conceptualized ideas when capable and put to the test. I know it isn't much, but take a look at the (and I don't mean to come across as a self-piassed, self-righteous person by saying this) beautiful work put into Blood Creek RC3's betas from which the videos themselves came from. I won't even go into WHY it is that I ask for help with modeling because it's not necessay and is of no importance to this current debate you and I seem to be having over "crazy ideas". However, I will say that if you actually took the time to slow down and think before spouting off diarrheic negativity, perhaps people wouldn't get so frustrated when they respond with messages that should be simple counterpoints. I will not reference any links to my Xfire videos of Blood Creek RC3 progress here; however, I will say that anyone with enough time and patience can find them and see for themselves what we've done.
That said, back to topic.
I asked for switching lightmaps. it's in, albeit rudimentary at best. So what if it's stub code with a project_yellow tag reference? it's there, is it not? I'm now asking for 32-player support on a T1/LAN connection only. It could be possible, just as the 32 BSP limit on a Yelo-based .scenario tag was reached (64 if you count all the BSP sets, not including the 32 in the standard .screnario now).
Dude, stop coming across like you're flaming people and actually slow down and try to at least think of the "mpossibilities" that DID happen before you go exclaiming such a thing. Now you're just irritating me and I'm not afraid to say it like some people. Though my ideas may in fact be crazy ones, I'm at least TRYING to suggest things that just might get into the game's OS code. It wouldn't be hard to... No, let me rephrase that. It wouldn't be so impossible as you claim, to add an override function in the Open Sauce code for the network functions and up the playernumber count from 16 to 32 on a LAN server or, for that matter, a T1 server. Unless the rendering issues plague the system, the engine is MORE THAN CAPABLE of handling at least 24 people, if not 32, even though the limit in the .exe file was set at 16.
After all, didn't someone out there on the internet that I don't know exactly the name of reference to, end up hacking a copy of the EXE or the dedi's EXE to handle more clients (users) and even go so far as to bring down the server with a lagfest just to prove a point? It may be rumors, but one of my friends told me some guy actually did succeed.
Please, at least let other people try to get an idea in before you go and inject your negative two cents worth.
There's a difference between scientifically tested theories and jumping to conclusions.Quote:
Originally Posted by Rambo
Point taken. However, even so, crazy ideas are still crazy until proven otherwise.
While some code is there apparently, it doesn't do anything. I've barely taken a look at OS2, so I don't know how much Korn has or has not added.Quote:
Originally Posted by Rambo
No, it's not possible without the source code to the game.Quote:
Originally Posted by Rambo
Ok then, if you know how to go about doing it, then do so. Have fun writing that "override function".Quote:
Originally Posted by Rambo
It's not like there is some number in the engine you can change to magically make it switch from a maximum of 16 players to a maximum of 24 or 32. There are player tables in memory that have a fixed size, only allowing for 16 players. It's not possible to do this without the source code to Halo 1.Quote:
Originally Posted by Rambo
That was e3po, I don't believe anything that he says. He also claimed to have made his own rendering engine that looked exactly like H1, but then Bungie made him stop working on it.Quote:
Originally Posted by Rambo
So what if you don't believe him, fact is, he claimed it was true. if it is, what difference does that make? Even if it were true, what's to stop Kornman00, here, from going in and upgrading the server liit the same way or similarly thereof, he did for the BSP/Lightmap tag count?
He's an unreliable source.Quote:
Originally Posted by Rambo
It's not the same, AT ALL. Increasing a tag block limit is not a hard thing to do.Quote:
Originally Posted by Rambo
How about time.Quote:
Originally Posted by Rambo
He's done his part, Open Sauce is a 3rd party software development kit. It's up to you to use this framework to accomplish these tasks. As for this thread, I recall Kornman stating that he would only be accepting ideas before the release of OS v2.