I thought this was in the options for a custom gametype.Quote:
Originally Posted by Rhydgaled
Printable View
I thought this was in the options for a custom gametype.Quote:
Originally Posted by Rhydgaled
Ahh, functions. I haven't messed with them too much, but they seem pretty nifty. I'll have to look into itQuote:
Originally Posted by CtrlAltDestroy
pretty sure that is possible. It might not be able to fully prevent it, what might have to happen is when they get in the seat if they have the flag they get ejected, if they don't they stay in. Pretty sure it could have to be run on the dedicated server although the local host might be able to handle the checks.Quote:
Originally Posted by Rhydgaled
Things are coming along with some new stuff Skyline and I are working on, release soon maybe...:p
Kornman, I know this is a crazy request, but could you (for shits and giggles) up the BSP count to the maximum possible (or 255 BSPs) if allowed? That way, anyone can do whatever they want lighting wise with the BSP as they see fit.
My day-night system uses 12 BSPs for day, 3 BSPs for transitions between night and dawn, and 1 for night. I know I sound like a complete idiot, but if I had 128 BSPs I could do 64 for day and 64 for night, providing really smooth transitions of lighting across the map as the animated sun moves in the sky.
Also, another request. Right now, only eight skies are supported per scenario. Could you up that as well? Right now we're using an animated skybelt model for the custom sky with a static hemi for the moving stars. If we had a lot more skies to play with, we could do killer skies (taken from real life photos) that have beautiful sunrises and sunsets to complement the many BSP switches. Granted, the map file would be absolutely gargantuous, but it would offer an amazing experience for CE players.
One final thing. Please include a way to sync BSPs and devices over the netcode so that we don't have to do so with bipeds. They are bulky and ineffective and a poly / render hog.
I have complaints of lag on my map from some of the users with incorrect graphics settings and / or slower machines with not much RAM. I removed the bipeds just to see what would happen and a good portion of the lag went away, but so did the day-night system. Syncing on-the-fly objects would be a real beauty to add.
So yeah. Please up the BSPs as high as you can within reason, add support for more skies likewise, and try to get device syncing in with other possible syncing. Thanks.
That would make for a ridiculously massive map file...
Indeed, as I am well aware of. However, unless they manage to allow for on-the-fly Lightmaps swaping via a drop-down list in the Lightmaps part of the BSP tag, there is no way in HELL we're going to be able to consolidate the necessary Lightmaps to one BSP.Quote:
Originally Posted by AdmiralBacon
Which takes more? Lightmap data, or BSP data? I'd say the latter, not the former.
Kornman, if you could also incorporate a dev command that awitches lightmaps (e.g. switch_lightmap) and (structure_lightmap_index), we could, in theory, solve this huge BSP crisis with on-the-fly lightmap switching via the same or similar method as BSP switching.
I've come up with some other ideas and I'll try to remember them here:
Point and click banning/kicking. Hold down a button, possibly F1 (the scoreboard button) and use the mouse to select a player, right click, and click BAN, or KICK. The action is automatically carried out.
Make banning and kicking possible without ever having to put -console in the desktop icon target thingy.
Banned player timers, set when banning, which indicate when the ban time will be up (ten years, a week, a month, etc.). Corresponding message that appears when banned or trying to join a banned server that shows how long you've been banned for, when it happened, and why (with reason put in by the server admin).
Command menu for other commands, using a box which has various commands in group boxes, with variables that can be set by the mouse. Setting said variables is accomplished by clicking a scroll box (one that shows a number or sentence/words, that expands when clicked, with more options in the expanded section, and the currently selected one highlighted, sorry I'm forgetting what this was called but I assumed it was the scroll box).
Please DO NOT make it impossible to drive a vehicle when holding the flag. This is halo one, not two or three, and stealing the flag would be nearly impossible without it. Requiring someone else to drive would require some good teamwork, and that isn't possible without some team work communication. Simple text chat isn't going to cut it. Things like communication macros ("I need a driver!", "I need a gunner!", "Help!", "Sniper!", "Guard the flag carrier!", etc.) and possibly voice chat would be wonderful.
Different more realistic player character colors, the ones currently in the games selections screen aren't very much like the in game (while playing) versions. Simple screen shots of the in game color would suffice, edited to only display the character (or some background, if that looks better or something).
HUD changes, like the word "Energy Shield" next to your shield bar, and "Heath" next to your health bar. As a newbie I didn't know what those were for, or that I had low health. The "+" symbol and the shield symbol were lost to me, I only recently figured out what they are (the symbols, not the shield and health).
I can see map files being 1GB soon :P Bigger = better.
Except the part where it takes almost an hour to download the whole thing.Quote:
Originally Posted by Hunter
Not necessarily so. Blood Creek is reaching 300 MB in the test version, and when I 7-Zip it he drops to 30. He...the map...whatever. I just call it something. Ya know, how come people call their computer a he or a she when explaining its stats. lol
At any rate, if people used good compression utilities and not this ZIP crap, we wouldn't have much of a problem. The multiple BSPs DO take up space, but when you compress it the space drops signifficantly. It's mainly raw data like compressed sounds and bitmaps that take up the most room.
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.
i am researching this problem and will get back with you later after talking with igm about it
Oh this idea has probably been said but I'm gunna say it just incase.
If its not to much trouble, maybe you could fix the recorded animations for sapien. I would think OS could make that possible.
I need a (resolution width height refresh_rate) command so I can play in widescreen while actually using Open Sauce on Linux, kthxbye
Why not force it with -vidmode w,h,r?
Or does it not work on that crazy lunix hacker language?
I explain that here, it's either Open Sauce or command line parameters.Quote:
Originally Posted by jcap
Yes I second that. I'm also working on a SP campaign (or trying to) based off of a movie script we have for a movie we're about to do, but cannot proceed past the first level WITHOUT recorded animations, and I refuse to use existing ones because they do not fit the script.Quote:
Originally Posted by malolo420
BTW: Not trying to go off-topic, but in This thread, I didn't say any of you were flamers or any of that stuff. I merely said I've been on boards where people do and I'm tired of it, so I'm sorry if I offended anyone. I know I can come off a little harsh at times, but I'm sorry for it.
Anyway, still looking for help. I'll go back to topic now. Sorry for the diversion.
would it be possible to -have a function that allows you to lower your gun?
-have a "spectator" mode which makes the player basically just a flying camera?
-have a sort of "theatre" mode? (or watch a previous game from the view of another player)
-and can we have more grenade types? (2 is not enough)
:DQuote:
Originally Posted by MissingSpartan7
That's not... entirely... accurate.Quote:
Can not record games. You can watch in real time the view from another player, but hud wont appear.
My favorite quote from Independence Day
I've said too much...
He means like Halo 3, where you can sit back and watch the action unfold.Quote:
Originally Posted by AdmiralBacon
Again... that's not entirely accurate, and I've said too much. Trust me.Quote:
Originally Posted by Limited
1 will only be possible with client-to-server apps, and will not likely be included in Open Sauce. If you want something like that you best be talkin' to IGM.Quote:
Originally Posted by MissingSpartan7
2. This is possible however how I think this to be possible is not plausible.
The replaying of games played won't work. It would involve coding a whole new feature that involves saving a file that contains control data and real-time game data, or at best, an AVI of the game, which would be almost impossible to add to the game engine, but a waste of time.
If you really care to watch replays of your game, use FRAPS or Xfire video.
Sorry man, but let's try to think realistic. Poor Kornman00 has enough on his plate. He doesn't need crazy ideas that are hardly if at all possible. Besides, it would involve modifying the Halo Executable, most likely.
Nice ideas, but they don't seem feasible, however.
You have no idea what you are talking about.Quote:
Originally Posted by Rambo
This only reinforces my above statement. You obviously do not even know what an OS dll does.Quote:
Originally Posted by Rambo
Not sure if this is remotely possible or if it even belongs in here, but a Gungame type gametype? I thought it be might applicable because it requires some form of scripting which OS may be able to assist in? I don't know, this is outside my realm of knowledge so I'm just shooting into darkness, to be honest.
Kornman we need to talkkkkk - a friend and I just got done coding a .dll that for all intents and purposes acts as a devmode toggle + dev trainer, and I want to inject that dll into Halo through Open Sauce.
Here's it... "working" :
http://www.xfire.com/video/1007b2/
<I was retarded in this post>
You'd have to recode it all I side of the Open Saucd project. Look at code already released to help.
Fix the camera code! No third person camera tricks work because you can't aim for shit. I know bitterbanana put his code in there, but something is wrong with it. Didn't he make a third person app that worked fine for aiming?
I don't really post "work" related posts until the weekend, when I'm not actually performing my IRL job during the day.Quote:
Originally Posted by Dwood
Open Sauce should NOT be used to load more DLLs which further alter the game. Don't think you can circumvent the source code license. If you (talking in general here) dare not follow the license and release something OS based without the changes to the source code, you are officially going against community development and are subject to copyleft infringement. I've put the time and effort to put out this shit to you guys for free (because it would just be silly to charge without actual permission to do this from MS\Bungie) and the least any future developers can do is uphold the license agreement of the source code. Don't be the one to ruin it for everyone else. This may be the last official update to Open Sauce, but it doesn't mean I won't release some more works (not specifically just source code or software) down the line for people to reference.
With that said, everything you do should be done via the Open Sauce channel to keep things consistent and ran\installed from a single source.
Just because you can't aim for shit jcap doesn't give you the right to bitch about camera tricks! Also, if you're referring to the code that came in the initial release, that game extension code for the camera was commented out (thus not executed)...you should have more sense when going about enabling code which wasn't enabled by default in an initial release. BB may have done such an app, but it was probably when he was still doing his stuff in VB (poor bloke :()
EDIT: I wasn't jumping the gun, I was laying down the rules before anyone got any funny ideas. Like I said, I was speaking in general, not to any one person. If you're wating to incorporate it into Open Sauce then just modify the Yelo code base. However, devmode isn't required when using OS and forcing expressions to the console isn't the most efficent way to do that flickering wireframe effect
whoa whoa jumping the gun there sparky. I have the code and will release it however I either want a way to inject it or incorporate it into Open Sauce.
(heh... i called you sparky)
Edit b/c of Korn's edit: Okay then what section of Open Sauce do I reference/use?
<I was retarded in this post>
Like kornman said what you want to do is easily done in OS.
Don't look to incorperate code in to OS, simply code in OS. Work out how it runs, what does what. Then incoperate your theory into OS.
could we have speed and jump modifying commands?
eg. (player_set_speed (player_# or just "players") (# *speed multiplier -1 being default*)
and (player_set_jump_height (player_# or just "players") (# *jump multiplier -1 being default*)
or maybe even a command which allows things like suicide grunts and beserk brutes (ai_replace (encounter) (squad) (original ai tag name *"grunt minor needler"*) (new ai tag name/reference *"grunt minor suicidal"*) )
Would it be possible to add two tool commands that seperate the lightmap UV-ing and bitmap creation and radiosity itself? Just so that should people want to bake there own lightmaps they dont have to wait for debug lightmaps to complete, but still have the UV's and bitmap there to use.
Could you modify the tool command lightmaps so it could save as it is still running like radiosity?
This would be nice. Tool can run in the background, but sapien allows mid- lightmap saving. Any way to combine the two would be very useful and time-saving.Quote:
Originally Posted by il Duce Primo
Just going to throw this one out here:
I'd like to see a custom chat interface implemented with Open Sauce. The basic idea here is to remove the built-in chat by making it not display and replace it with one that reads and sends the same strings but adds some new features, particularly:
- Formatting (bold, italic, underline)
- Smileys (especially, ones from here :realsmug: :iamafag: )
- Colors (yeah... pretty simple idea there)
- If possible, extend the character limit if the server is running it.
- Custom chat positioning
- "edit boxes" for all resolutions, possibly WYSIWYG
For best operation, this assumes that the people on the other end are also using Open Sauce and will therefore see the formatting instead of whatever our coding format is (probably bbcode, as it's easy to implement).
I know that this can be done, seeing as Limited and Skyline already have their overlay that does text and images, and Yelo already produces a chat log, and I assume sending can't be that ridiculously troublesome.
I suppose that should be possible, I can see a couple of problems though.
Formatting - If you have to type the formatting it would make sending messages take longer, reducing the amount of time your playing. And even if the formatting is automatic, it still has to go through the normal text system, which would look fugly for non OS players.
Smilies - Don't see why not, the smilies would have to be standard for everybody and would have to look good for a long time, and as such have no meme smilies.
Colours - Same problems as Formatting, although a colour could be assigned to each player so that you can more easily see who is talking.
Character limit - Rather than changing the character limit, could it instead be possible to automatically break up and send a long message on seperate lines?
another great idea, can we have more characters in player names?
(there's so many names i'd like to have that don't fit...)
Why was this removed from sticky?
Update #2 is coming soon, and the ideas have started to dwindle to the occasional bit of "hey, this would be cool" every other week or os.Quote:
Originally Posted by Dwood
At least, I assume that's why.
Perhaps, but I didn't think it was to the point that we remove a sticky. :/
has anyone asked korn if we will be able to make the screen on the sniper like h2? it would be nice if we could get that working :)
or h3 :ohdear:Quote:
Originally Posted by Scooby Doo
Explain what you want it to do a bit more pl0x.
perhaps a function which allows ai to use their flashlight?
e.g (ai_set_flashlight_status "encounter\squad" "boolean")
this could lead to (ai_set_camoflage_status "encounter\squad" "boolean")
or even (unit_set_camoflage_status "player#" "boolean")
I thought you could already make AI use their flashlights and have active camo.
lol
Yes you can. It's called:
unit_set_current_flashlight_state (unit (list_get (ai_actors louis) 0)) true
louis = AI name.
To get a flashlight state, do the following:
if (= (unit_get_current_flashlight_state (unit (list_get (ai_actors louis) 0)))true
true could be false but it needs to be in an if statement.
I find this ammusing how people seem to neglect the basics and overcomplicate things. Then again, I am just as guilty in my own way, so what the hell?
But yes, you can use unit commands with AI. Just reference ai_actors ainame, rather than players and playernumber.
so how the scope displays like a video camera would. can we do that with OS? possibly set up a camera (marker in max?) and go into guerilla and have a shader that will display whatever the camera sees? or mb there is another way to do it, idk...
As far as making camera screens and the like, probably not as that would require full access to the rasterizer code to render the scene for each camera location and I don't think that kind of access is going to be possible without Halo's source.
However, I've been trying out an idea to steal a texture when it's created in DirectX and copying what's on the screen to that texture so that something like the sniper scope could be achieved, but it's not working for some reason.
Okay so I'm opening this thread up again in the hope that people will come up with new ideas.
An Oni style melee system would be all-pwning
I don't think you understand what Open Sauce can do bobby.
Would it be within the realm of possibility for Open Sauce/Synapse to enable server-client map downloading? I'm pretty sure it's not since OS is mainly for map creation, but it would be awesome if it could.
I'm referring to trying to solve the horrible way that CE hosts custom maps, if a client try's to join a server without the custom map they're denied. If Open Sauce could somehow let the client download the map from the server (or another external download location) I'm sure custom maps would become more popular! This would have to be a server-side application obviously.
Well, in general, yes, you could theoretically implement an extra network stream to get files between a server and client that are both running Open Sauce, but let's face it: It'd be slow, and then we're still not quite clear on how to get Halo to work with new maps without restarting it. Also, it's way out of the realm of what OS should do.Quote:
Originally Posted by Freelancer
compression of maps not played in a long time
decompression on-the-fly
a "map not found: [quit] [search]" prompt, that searches for the map (everywhere except halomaps, out of respect for dennis's wishes), verifies it's checksum, and then tries to rejoin the game.
Depends on what it's contributing programmers can do, right?Quote:
Originally Posted by Dwood
I know, it's even more far-fetched than synching ai or defining a shader_portal. I just can't get over how cool it'd be :haw:. Sorry :ohdear:
Well, what's wrong with just having the OS client restart after a new map is downloaded?Quote:
Originally Posted by AdmiralBacon
Either way, I realize that it's still beyond the feasible function of OS.
What's wrong is the load time, a factor of how many megs of maps you have.
how about server queries clients for which maps they have, and skips a map in it's cycle if not all clients have it?
Well, a simpler idea might be to have the server send a link to the map to the client, so thats its easier for them to go and get it.
Mainly for games that are in progress, the server could send a text message to the clients telling them the next map name, and a link to where the map can be downloaded from. The client OS could pick up on this and tell the player whether they have the map, with the option of somehow closing the game and opening a webpage to the download link, or at least copy it to the clipboard.
Although, this would have issues with download link size and the text restrictions, and whether the server owner can be trusted to not send you to porn/virus/shock sites.
Would it be possible to make the loading time faster when starting up CE?
It's really annoying having to wait about 10 min when you have about 200 maps in your maps folder :S
I believe that IS possible. Just be ready for the ultra-long wait when you try to open the map and play it.Quote:
Originally Posted by Pyong Kawaguchi
I talked with Korn over the Downloading maps with Opensauce thing. According to him it IS possible. He doesn't want to do it because people who don't have Open Sauce/Yelo might crash when either the client or server sends a byte/string that can't be handled by the default Halo netcode.
To make it feasible how about we Allow the option of Making "an OpenSauce only" Server Listing as suggested in the Original Open Sauce threads? Another thing, we should have a Special Map that's made for people who only want to dl maps. I would call it a "Server Distributable Map", or SDM, for short.
One last thing to add to that: If someone wants to code the Map downloading then there's mainly one requirement, and 3 suggestions: You must make it so that it's the clients that send the server and tell the server that they're running Open Sauce. (That is, until we get the Open-Sauce listings, ofc)
Suggestion #1 is that you use the Server Redist Map idea. Just a bare-bones map that if you have you can join the game, Makes coding the netcode for the thing much easier (can't join a game without the map). If you allow the downloading from normal servers, there WILL be immense lag for all the players in-game. Another perk of that is You get to play while you wait for the map to stop downloading. :D
Suggestion #2 Figure out a way to stop Halo from having to restart every time you download a map. That, or initiate a restart of the game from Open Sauce, given user input.
Suggestion #3 - Add to the Open-Sauce/Yelo In-Game interface a way for servers to check who has already downloaded, who is downloading, etc. And easily/auto-kick players that are done.
I know It's a Double Post but I think that the methods for the impossible might as well be posted.
In order to Sync ai (possible, but NFWOS)
There are going to need to be 2 main things (i believe)
1: Get Clients to stop from creating their own bipeds
****Pulls out chat logs***
2. Has like 4 possibilities.
---a. Get ai to always make the same decisions
---b. Unrandomize ai decisions
---c. Make the clients depend on the server for the ai's actions.
Another idea which might not be very feasible is to code your own ai scripts in Open Sauce
Having a listing for OS servers only would hugely defeat the purpose for servers running Synapse.
How so?Quote:
Originally Posted by Freelancer
We're trying to collect player stats on a global basis. Segregating the game even more than it is would serve to kill it faster.Quote:
Originally Posted by Dwood
I don't think of it like that. I think of it as a new way to organize servers so people can find other Open Sauce Servers. It doesn't necessarily have to be 100% separate. Just an easy way to distinguish.Quote:
Originally Posted by Freelancer
I should note that Synapse based servers won't be expandable by Open Sauce, but they'll still be able to run some of the more basic OS related features (MTV and upgraded maps)
VIP gametype anyone?
also maybe dual-wielding?
and being able set gravity? (zero-g environments!) or set gravity within trigger_volumes
Spartan
1. Explain. Not enough details.
2. NFWOS
3. We already did that.
Enlighten yourself.Quote:
Originally Posted by Dwood
Correct, proper dual wielding is not possible.Quote:
Originally Posted by Dwood
You could at least tell him how to do it. When you use an OS dll it will add a new global that controls gravity, which can then be edited through the console. Just open the console and type "gravity #".Quote:
Originally Posted by Dwood
Or you can use the new tools to compile a script which sets the "gravity" global. Be sure to pay it with The OS DLL, or else the game will more than likely exception
Btw Korn... are you ever going to reply to my pms? Or have you ignored me completely?
<I was retarded in this post>
C = Bingo!... yes I'm back again XD..... uhhhhhQuote:
Originally Posted by Dwood
I never did much work on AI encounters... but I do remember 1 thing about them
they do auto create themselves in Sapien but not Ingame. they need a Script to run. this is accomplish able via the object_health = 0 server sided only command that i think... rec0 gave out a few years back... it returned Nil instead of 0 on clients because the vehicle didn't exist on clients. only on the server
so that would stop them being created on clients
and as for the ai Updating. you don't have to continuously update the clients... more so just update every 2 or 3 seconds... or alternate between clients being updated. it dosn't have to be exact. only close and only server sided.
in the end if made by the script properly. all you'd have to do is make the server update the client and blam! done :P
57. attach trigger volumes to objects (MissingSpartan7)
I kinda did this... sort of...
Anyone remember my Pelican that could pick up any vehicle under it?
in the end it was going to be a server sided script. it used 3 bipeds to triangulate. and verify if they could all see a vehicle. and it would attach. if the flashlight of the pelican was turned on
the only flaw with my script was... if vehicle attached = true. both vehicles = unexcessible for some reason :S...
and continuously attaching and detaching = seated object warping... don't know how it was worked out on coldsnap... oh well XD
its good to be back:neckbeard:
had semi good idea, imagine being able to switch bsp's in multiplayer!
you could go from a desert map to a snow map of the same shape but with lots of ice tunnels..
Quote:
Originally Posted by MissingSpartan7
uhhhh... its actually possible. server side controlled only BUT! server sided command only...
halomods.org
look for the map called Cold Snap. i think you'll find some of the things in it rather fascinating...
It is halomaps.org, though I'm pretty sure he knows about HaloMaps already, as well as Cold Snap. Simply playing Cold Snap won't help with figuring out how stuff is done in the map. That would require extracting the scripts, which only a handful of people can do.Quote:
Originally Posted by the1
And when you do unless you're in Zteam all you can get generally are the names of the globals.Quote:
Originally Posted by ShadowSpartan
yeah halomaps XD... lol i knew that... and yeah the few that can are...
kornman00 himself. rec0 i believe. and steelix. who have any real ability to get scripts out of a map file because of the way there compiled in
and yeah its a simple script to change bsp. you just have to make sure that you have all the bsp structures you want added to the scenario tag...
you just need to make sure that the script that you use is only initiated on the server.
as i have said in another thread. its the get unit health method.. use it on a vehicle that you have named. just name 1 of the normally spawning warthog's... what else... hmmmm
you want to use an if script unitgethealth()
use it on the warthog
then make it change a global variable from false to true if the condition is true
after that. you can have your day of time script following the if ( is server boolean here (then) (else) )
make it a number of conditions to change the bsp though otherwise itll always change. :P thare easily explained XD
keep in mind i havn't written a script in a bit over 2 years so youll have to structure it a bit better than i just did XD...
I hear OpenSauce allows for multipule campaigns now, if so could the maps for all campaigns but the default one be put into their own sub-folder of the maps folder which aren't loaded at startup? These maps would then be loaded when the relevent campaign is selected from the menu, a loading screen would appear then a load game/select mission screen would come up when the loading is complete (unless the maps for the selected campaign were not there, in which case a different UI widget would be appear to tell you to get the maps). Also, when you have multipule campaigns how would the continue campaign button work, or would it just not work at all?
Finally, nobody ever went through my list of ideas from way back and explained which were possible, I suppose it doesn't matter now at this late stage when the update2 is nearly done.
Stock OpenSauce doesn't allow for multiple campaigns. There is a base for implementing a campaign which is composed of more than 10 scenarios however. Even still, it requires leg work to be done in the mainmenu (errr ui) as there has to be widgets implementing the user interface for the level selection and display.
Really, if a team wants to do any advance work with OpenSauce they require a programmer. A mod team will get no where in terms of adding new things into OS without a programmer. Find a programmer who is half way competent then lay down your ideas. Without one, you're just rattling off unbounded thoughts. With one, at least then you'll have someone to put a sense of direction and boundary on advance engine additions.
I have a semi-good idea.
How about the ability to have sounds get quieter or go completley in space environmets?
Turn on sound hardware acceleration and EAX if you hardware supports it.Quote:
Originally Posted by nuttyyayap
Then play Boarding Action.
Then mess around with sound_environment tags.
:tags101:
hmm...what's CE missing that the other halos have?
Skulls!
perhaps a working skull system/menu so they can be turned on/off through the main menu/pause menu
any thoughts?
yea skulls works, various people have used the most fun ideas, there is an invisi skull on the silent photographer map for example =P
Korn lives from his army endeavors!
hmmmmmmm not to mention that the programmer's going to have to re work the development tools to support any additions to the game and explain how they work...
chances are... it would be far easier if you re made the game from scratch. new engine. better physics support/engine that way you could get it to do exactly what you want it to do.
for instance... a remake of halo with all the feats of halo 2. like duel wielding. uhhhhh can't think of anything else off the top of my head... !!! but yeah... it would be far easier to make your own game engine than it would be to work around the limits of 1 that already exists...
Wow, dude you just pointed out some REALLY obvious shit
yeah I worked with ce for 5 years 7 years ago so yeeeeaaaah i do that from time to time... I'm going to stop pointing out the obvious now..
^ good idea /opinion
anyway, another bunch of ideas
-in-HUD map (sorta lke crysis has)
-maybe in the radar be able to specify a bitmap for players etc. (instead of the yellow and red dots)
you do realize that isn't a map or a radar right? its a motion tracker... and it just uses a bitmap as it is anyway. so you can change it XDQuote:
Originally Posted by MissingSpartan7
Quote:
Originally Posted by the1
:allears:Quote:
Originally Posted by the1
i lold
