I'm working on a mouse driven menu system for OS, but I can't find a way to stop the mouse from interacting with Halo's UI while still being functional for my menu, so pointers on how to achieve this in OS2 would be useful.
Printable View
I'm working on a mouse driven menu system for OS, but I can't find a way to stop the mouse from interacting with Halo's UI while still being functional for my menu, so pointers on how to achieve this in OS2 would be useful.
Well I zombified and polished up the ingame menu system from Battery into Yelo. A crude system, but it saves me time from having to develop and test something new. Using it though, kind of breaks my thoughts on having the Yelo codebase being a very thin API to the engine without a bunch of fancy bells and whistles to creep the code of end-users.
However if you're wanting to do a global menu system...I can't think of anything at the moment that would stop the cursor from selecting the actual game's menu.
I love you, babe.
Yeah, FOV, scaling and weapon positioning are back ;p
So Kornman, are my suggestions regarding the BSPs and Lightmaps even possible? I know you said you'd try and expand the BSPs. How far out will ya go and can the new idea of multiple Lightmaps via drop-down box in a single BSP work with a dev command or two dev commands (one for seek and one for state) such as structure_lightmap_index (for seek) and switch_lightmaps (for state)?
Here's my idea on how it would work.
You have a drop-down menu above the lightmaps slot in the BSP tag that supports up to 256 Lightmaps. Each entry represents one Lightmap file.
When you specify the Lightmaps to be processed, you'd do it as follows.
tool lightmaps levels\test\blood_creek\blood_creek_rc3 0 128 0 0.0000001 (where 0 and 128 equal the start and end lightmap range or how many lightmaps to process from entry 0 to entry 128 in the Lightmap block table stored in the BSP. The next 0 would be the quality, and the last 0.0000001 would be the rate to count down to. Same process as it is now, just two more values in Tool.
Tool would thereby run Lightmaps 129 times (including the 0 Lightmap block and compile a series of bitmaps and generate BSP data required for all 129 Lightmap settings. Then, all one has to do is type switch_lightmap to switch to the desired lightmap setting corresponding to the given sky stored in the scenario file.
Lightmaps would be indirectly linked with Sky tags via an entry in the Lightmaps block section that references the sky to be used. This data would be similarly entered the way you reference what sky is used in a given cluster portal. By manually feeding Kornman00.exe (or whatever the app may be in the future that would support this), you set up the total number of lightmap indexes and what sky number is used.
A brief table is shown below to represent how it could be laid out.
------------------------------------------------------------------------------------------------------
Lightmap Block: 0. Lightmap Block | Add | Insert | Duplicate | Delete | Delete All |
------------------------------------------------------------------------------------------------------
Lightmap: (Edit Box) |...| |Open|
Sky: (Edit Box)
------------------------------------------------------------------------------------------------------
Again, as shown above, the drop-down menu houses all the lightmaps. The field below contains the lightmap used (assigned by Tool by default), and the sky number you feed it before processing Lightmaps while all the fields in all the Lightmap blocks are left empty so that Tool will not crash looking for a file that does not exist.
Could you please increased the number of skies to 256 for lighting purposes.
I have taken care to make sure this idea is explained thoroughly. My question again is, is this doable WITHOUT fucking with the rendering engine?
If anything, there will just be a tag block in the yelo tag associated with the scenario which specifies the multiple lightmaps and sky references if it can be done. Not only would including a new tag block in the structure bsp change the normal layout of the tag, causing compatibility issues, it would tie the structure bsp tag to sky tags which is not How It's Done.
Hmm... I see what you're saying, although it would be nice to free up excessive BSP use for the simple purpose of Lightmaps. Instead, for strict Lightmap differences, there should be a way to reference them though to the same BSP.
I just don't like the idea that I have to run 128 BSPs each with the same structure but different Lightmaps just to get a day-night system that's fluid and smooth, wasting massive, and I mean MASSIVE amounts of disk / bandwidth space in the process, mainly on the download end for the end-user, but still...
'twould be nice to consolidate all those Lightmap variants into one BSP.
About device and BSP syncing, is that also possible?
It *shouldn't* require multiple bsps, but I haven't researched how to change the lightmap dynamically during the game so it may or may not require a bsp for each lightmap.
Basically how the data would flow in the yelo tag.Code:structure bsp information
-> skies
- sky reference
-> lightmaps
- bitmap reference
- sky block index
All someone should really have to do is just hook tool's lightmap creation function in a couple of places for autofilling the yelo tag data and saving\closing\changing the current lightmap calculated by tool. Just FYI, it would just be a hack and would take as long as tool normally would if you ran the lightmapper X times at Y quality. Rather simple process (in theory) stringing everything together.
Note that I'm not saying I'm implementing this. As I said, I would answer ideas with possible how-tos for people to implement themselves.
Well, right now, you can only have one lightmap per BSP. There is no way to switch it, as you're probably aware. That lightmap uses Sky0 as a default source for the lightmap, unless the cluster portals in the "Clusters" section of the BSP dictate otherwise. I have set a BSP to use Sky7 in Clusters and it does, but it depends on what's in cluster portals.
We need a way to bypass the Clusters information for lighting and use Yelo's information in the so-called Lightmaps section, or have the two work hand-in-hand where the FIRST lightmap is default by clusters and the SECOND and so on is default by Yelo.
I still say it would take longer to run several lightmaps than it would to run just one because it has to do a "pass" for each and every condition the map is in.
Example:
Let's say Lightmap 0 in the lightmap block is night time. OK, that's good. The sky has the appropriate settings for night. Lightmap 1 would be dawn; Lightmap 2, day; Lightmap 3, dusk. A very rough day-night system like the one in RC2 of Blood Creek. First, Tool would have to render Night's lighting, then Dawn's, then Day's, then Dusk's, in that order. For it to take as long as it would to render one Lightmap (Night alone) seems kind of odd to me.
Care to explain?
I'm just telling you what I've observed. By no way am I trying to supercede your knowledge, Kornman00. I have merely observed that Lightmaps and Cluster Portals are tied together, so in a sense, yes the sky and BSP tags are tied together. You specify the sky in Clusters block and make sure that all the Cluster block entries share the same sky number (as depicted below), and Lightmaps are calculated by that entry.
http://i564.photobucket.com/albums/s...Lightmaps1.jpg
But that's for Cluster portals.
My problem, or question at best, is... How does one assign multiple lightmaps to the SAME cluster portal? How do I say, "OK Cluster Portal #0 in Cluster block! I want YOU to have data for Lightmap file '..\levels\test\blood_creek\night.bitmap" and "..\levels\test\blood_creek\dawn.bitmap' at the same time."?
http://i564.photobucket.com/albums/s...Lightmaps2.jpg
That's exactly what I'm trying to accomplish, guys. Right now I am forced to use a BSP for the sole purpose of lighting and multiply that by the number of times the light changes (hence sixten BSPs with twelve for a day cycle, three for transitionals between dawn and night, and one for night). It's very clunky and an absolute waste of space because the same geometry is also mirrored sixteen times, thereby causing the map to jump exponentially in filesize. If my BSP is 8 MB with Lightmap data, then 8 MB x 16 is what..., 128 MB JUST for BSP data alone? C'mon guys. Please help us all out here. Blood Creek is nearing 300 MB because of this. If we could just shove all the Lightmaps into one single BSP, it would save at least 80% of that space in the 128 MB for all sixteen BSPs. And if I went even smoother on the day cycle and upped it to 64 for day and then did 64 for night so the moonshadows crept across the map?
Please, I beg of you. Do something! I don't think Dennis on Halomaps, or for that matter, anyone, would want to host and/or download a 600 MB uncompressed .map file, compressed to like 200 MB filesize just because he chooses to use .ZIP and not 7-Zip (.7z) for file compresion. And I don't think I'm being selfish here because of Blood Creek RC3. This is also for anybody that wishes to create a day-night-enabled map, because I do intend to not only release the scripts that drive it, but also teach people how to get it working, especially if device syncing works over OSv2.
This isn't just about Rambo, guys; it's about everyone having something to enjoy and work with. My request is not a self-centered one.
Thanks for listening (or reading, or whatever)
Sync'd up scenery. Like lets say you got an MP map with a destructible bridge, but when it gets destroyed and some one joins it looks as if its still there but its not.
Same with the glass material.
And about that one person who said more fp animations, I'm not sure if he meant this but having more then 1 animation per animation, so if he has like 3 melee animations they play in sequence or by random.
I'll probably think of more, but that's what I got for now. I really think my first idea could bring a lot of whole new wicked game play aspects into it, just a thought.