Re: Open Sauce Ideas thread
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.
Re: Open Sauce Ideas thread
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.
Re: Open Sauce Ideas thread
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).
Re: Open Sauce Ideas thread
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.
Re: Open Sauce Ideas thread
Quote:
Originally Posted by
Dwood
I need to count the number of ai the player's killed, in a Single Player map.
The statistics code is no longer a part of OS.
Quote:
Originally Posted by
Dwood
I'm also looking at finding the variables for jump so I can modify it. Then, I want to modify jump height per player.
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.
Re: Open Sauce Ideas thread
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
Re: Open Sauce Ideas thread
Quote:
Originally Posted by
ShadowSpartan
The statistics code is no longer a part of OS
Dang. I didn't even know it was a part of OS in the first place lol.
Quote:
Originally Posted by
ShadowSpartan
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.
Jump Velocity is kept in the scenario tag
Re: Open Sauce Ideas thread
Quote:
Originally Posted by
Dwood
Jump Velocity is kept in the scenario tag
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.
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?
Re: Open Sauce Ideas thread
Quote:
Originally Posted by
Kornman00
The function doesn't show in-game because it's not programmed into the .DLL HaloCE is using.
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
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).
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.
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?
Re: Open Sauce Ideas thread
Quote:
Originally Posted by
Rambo
Then how do we get the DLL to recognize map resources or at best, program it into the DLL as a recompile?
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.
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.
