kornman00 has contributed to 106 posts out of 469684 total posts
(.02%) in 3,483 days (.03 posts per day).
20 Most recent posts:
Quote: --- Original message by: Higuy
Makes little to no sense that there isn't an option for Max 8, considering its literally the best version of 3ds Max to work on for CE.
Except when the poll may be about changing that fact.
If you have 8, but not 9, go ahead and say so. But if you have 9, just say 9.
I'm curious as to which versions of 3ds max the community has access to and/or uses in modding. Doesn't matter if you're modding CE or whatever-the-hell-other-engine.
Also specify if your license is perpetual (good forever) or student (good for only 3 years) based
If you have a modacity account, please vote in the thread over there, as the forum has proper poll tools.
Else, please reply in a format like: "Student license, 3ds max 9, 2012". All other posts will be ignored.
Perpetual License (Forever)
Student License (3yr)
- 3ds max 9 (note: if you only have an earlier version, like 8, feel free to claim that in your response. Else just stick with 9)
- 3ds max 2008
- 3ds max 2009
- 3ds max 2010
- 3ds max 2011
- 3ds max 2012
- 3ds max 2013
- 3ds max 2014
- 3ds max 2015
Edited by kornman00 on May 18, 2014 at 10:15 PM
Have any -finished- maps been released that make use of OS's unit infections extensions? I ask because I'm looking into moving the definitions into the unit tag itself (along with the unreleased boarding extensions), instead of residing in a a project_yellow_* tag. Which would mean any existing maps that implement unit infections via the current setup will no longer "see" the definitions.
If any -finished- maps have, I'll probably keep the unit infection definitions where they are.
Quote: --- Original message by: Georgespartan01
I have a
2GBmemory (used to be 4GB)
Windows 7 64-bits
Edited by Georgespartan01 on Mar 25, 2013 at 12:39 AM
I think a more accurate description of this thread should read "I have too little RAM to run my 64bit computer!"
1) remove the (begin) expressions from the start of your scripts, it's redundant
2) Only static/stub scripts can have return types. so change it to "(script continuous number"
OS v3.1 Trailer video
Extended videos are linked at the end, so be sure to watch the whole thing (hey, it's less than two minutes!)
Announcement post for v3.1
The scenario_structure_bsp tag stores its resources just like all other tags with cached resources. I started the work in BlamLib for the Halo3's structure_bsp_tag_resources, and touched on ODST's, but haven't worked on it since either game came out. I believe Halo4's structure_bsp_tag_resources structure didn't change much, if at all, from Reach though. I know ShadowSputnik has bsp extraction working in his code, so you may want to ask him for help.
The final number on the particles upgrade is still being worked out (waiting on more feedback from Iffy and the CMT testers). Right now, there's well over 512 more particles that can be rendered.
And I was wrong, the max rendered objects is 256. And, at first glance, increasing it doesn't appear to be much of a hurdle. Not promising an upgrade will be in 3.1 though.
You mean the maximum number of rendered objects? That's like 1024 objects IIRC. You seriously have more than that being rendered at once?
Make sure you be as descriptive as possible in what's wrong when filing an issue (especially follow the template instructions). Your post from earlier isn't really descriptive at all.
And the OS HEK writes to the debug.txt file in your "<User>\Documents\My Games\Halo CE\OpenSauce\Reports" folder. Check the error OS_sapien is logging first before filing your issue.
Also, the maximum number of tag instances has been upgraded by 25% since 3.0 was released. If you're hitting that limit, you really need to optimize your tag set.
I notice that you mention that even Windows isn't acknowledging that CE isn't installed properly.
I also notice that CE installed in your "C:\Program Files\" directory.
Now, I also notice that you're running a 64-bit version of Windows thanks to the "WoW6432Node" registry path in your image: https://lh3.googleusercontent.com/-3SziHmisGs4/UNh8qx9rkJI/AAAAAAAACbw/2-kGVzVhRi4/s640/Slide1.PNG
32-bit programs MUST be installed to the C:\Program Files (x86)\ folder. The "C:\Program Files\" directory is for 64-bit programs ONLY.
Due to how Windows on Windows (WoW) works, when a 32-bit app requests the "Program Files" folder it is given the "Program Files (x86)" path. It CANNOT SEE the "Program Files" folder.
Solution: This is a user error (not trying to be mean here), and why you should just use the default installation path unless you know what you're doing. Uninstall CE, then reinstall it either using the default settings or anywhere that's NOT under "C:\Program Files\". 32-bit Windows and OS will then be able see CE.
edit: Oh holy hell of christmas, PLEASE do not circumvent the installer and manually the files in places yourself. This can only hurt you later on.
Why is it so hard for people to submit bugs/problems via our "Issues" system? Help us, help you! :\
Edited by kornman00 on Dec 25, 2012 at 12:01 AM
OS 3.0's d3d9.dll will try to load "d3d9_proxy.dll" if it exists.
However, and this applies to any future 3.x releases no matter what .dll is loaded, if any other modification is loaded into CE while OS is running they can easily conflict with one due to both trying to hook or change the same code in the engine.
Hobbit, you would have to install CE to that harddrive, then you could install OS and it would be put on that harddrive as well. You would then need to specify the profile path you want the game use (if your My Documents isn't pointing to that HDD) via a command line parameter, as we piggy back on that path for settings and such.
Quote: --- Original message by: 1bobsam1
Any word or work done on physics objects, as in proper movable scenery?
Not unless MS decides to open source or license the engine. I would throw down 5 grand to be able to work with the source to Custom Edition, even if the license said that I couldn't make a profit from anything done with it (I'm not doing OS for money after all).
The way Halo1's networking works on the Xbox is much like how Halo3+'s synchronous games (co-op/firefight) work. All the machines start at the same time so everyone is on the same page as far as game state and input go (as why there's no join mid-game support). I forget if H1X's networking requires the player's action input to be sent to the host first then sent back before any response can be made to that input (eg, jumping). It's how it works in Halo3+, which is how they're able to do network games with AI, without having to actually write any networking code for the AI.
Halo1 PC doesn't have support for splitscreen. The max number of local players in the PC builds is defined as 1, where it's 4 on the Xbox. So the support in the game state is just not there.
Adding synchronous game support to OS wouldn't be too difficult to do...but the goals of 3.1 don't involve any networking changes (aside from the addition of two new grenade types, which was a trivial matter and is only activated when the map has > 2 types) as we're still looking at how we can extend the current networking capabilities with new features while keeping backwards support with 1.09 (or lower).
Quote: --- Original message by: KingFisher
I remember seeing the video of unit infections. This will be awesome for my Dead Halo project.
But last I saw, the infections only took place on live victims. Do unit infections apply to dead bodies?
Good work guys.
Thanks, I'll have a chat with CV about tuning the system for dead bodies support. However, it would probably require modifying the AI code, which isn't really the focus of 3.1.
Quote: --- Original message by: The Lodeman
"* We've increased the maximum number of particles that can exist at any given time. We're still playing with these settings, so the exact upgrade amount isn't set in stone yet."
As I haven't messed around with OS recently, how will such a particle increase be applied? Can you just recompile your map as a .yelo and will the particle count be increased?
Edited by The Lodeman on Dec 16, 2012 at 06:04 AM
This upgrade doesn't present any real backwards compatibility issues (except with game saves made with the stock game or pre-3.1 OS builds) so we don't have to have the map say "we need the particles upgrade". So, to answer your question, it's map-independent. It requires no work from the user or map maker to enable.
While it's on by default, it can be turned off with the -no_os_gfx command line parameter in the event that it's too taxing for people's older machines.
Quote: --- Original message by: reeiiko15
May I also suggest (if there isn't already) an ingame option to enable and disable console/devmode. I don't like using the external apps or the "-console" thing and having an in-game option would be much easier.
The devmode behavior is on by default when running OS. We have no plans to force the game to enable the console as well since turning it on via the command line parameter doesn't have any adverse effects like devmode does in the stock game (ie, disabling network games). Just use a shortcut to the game with -console specified.
Note: this post was adapted from the posts made at Modacity and Halomods. This place doesn't have spoiler tags, so beware the longpost...
Today, we here at the (virtual) offices of Kornner Studios are happy to announce that version 3.1 of OpenSauce is coming soon! How soon? Why, none other than next month: January!
Unlike previous releases of the v3.0.x brand, this release introduces a lot of new features and improvements instead of -just- addressing bugs/issues. Hence why that '0' after the period ranked up to a '1'.
For OS 3.1 both FireScythe and I have some really juicy goodies in store for you. But we're not the only ones contributing to this next release of OS. ChokingVictim is a special guest this time around with some more gameplay enhancing features for you map makers to play with! He has contributed work to OS before (e.g., he helped us implement the unit-infections system) but has become more active on the project for the past few months. We're hoping to keep him with us for the foreseeable future.
However, it being near the holidays and all he didn't really have the time to get all his :words: and video written up and made before this announcement was posted. So we're going to follow up later on with details directly from him on what you can expect in 3.1 and (hopefully) beyond. For today, you'll have to make do with what FireScythe and I. Deal with it.
Speaking of FireScythe, let's start with him first. He took the time to write up this longpost about this small feature he made, so why not. Wait, did I say small?
Quote: In-game Map Downloads
Iím sure youíll be happy to hear that I have written an in-game map download system that is built in to OpenSauce v3.1.0 which will be coming to a Halo near you mid-January!
The system has 3 parts to it, the OS client, the OS Dedi and the web server.
You are probably a client which means you have the easiest job :D, simply try to join a server running a map you do not have and the following will happen:
* You will join, then disconnect from the server as you donít have the current map
* OpenSauce will sense your distress and try to find and download the map for you
* It requests the map from the dedicated server first, which may or may not be serving it
* If the dedi isnít serving the map OS will then try to download it from one of a list of master servers (described below)
* If it finds the map on the dedi or master server it will automatically download it, and if successful, extract it into your maps folder
* The map is then added to Haloís map list and with the map now available, OS will attempt to reconnect to the dedi
All this happens without the user having to interact, restart Halo, or any other nonsense!
This takes place whenever you donít have a map the server is running, so if a game ends and a different map is loaded that you donít have, the process starts again to download that map and reconnect you to the server.
Of course, a map download system is pointless without somewhere to download the map from. If you are a cool guy you may well be running one or more dedicated servers, in which case you can serve the maps yourself.
The OS dedi has a HTTP server embedded, which is what makes the magic happen. The server is setup using functions you can pop in to your init.txt to keep things nice and simple. Full details on the OS dedi map server setup can be found here
but the main jist of it is:
* Compress and split your maps using OpenSauceIDE (included in the OS installer)
* Upload the map parts to a 3rd party file host that supports direct linking
* Setup your OS dedi to enable map downloads, pointing to your 3rd party file host as the data source
* Start the game server
When the client requests a map from the OS dedi, it responds with some information about the map and its parts, after which the client requests each part from the dedi. The dedi redirects those requests to the 3rd party file host you are using so that the client can download from them. This means the dediís bandwidth is free to use for the important things in life such as pretending to kill people.
Since the OS dedi has a HTTP server embedded it can also serve the map downloads itself, and as long as the HTTP servers bandwidth is throttled (again, set in the init.txt) this may be a viable option for some people.
If you are running a passworded server you can even encrypt your map using the server password at the map compression stage, so that people who shouldnít have your map donít get your map.
But wait! Thereís more!
ďWhat if the dedi is bad and isnít serving the maps?Ē I hear you say. Well, thats where master servers come in. The master server is a set of php scripts that can be used on a normal web server running PHP and MySQL and is used to serve maps to the entire OS user base.
And this is where OS needs YOU!
The map download system wonít take off without a decent amount of master servers running, as that not only provides more choice to the players, but also distributes the bandwidth cost amongst many kind volunteers which is better for everyone. Halomods is currently the only website running as a master server.
So, we need people who run websites with a good deal of spare bandwidth to donate some of their bandwidth to help make Halo CE more accessible, and hopefully make custom map servers the norm.
The details on how to set up a master server can be found here
FS, if the community had a voice, I think it would be saying "music to our collective-ears". But it doesn't. It's a voiceless being. Well, until you make something that doesn't play well with Xfire. Then it grows a mouth and starts jibber jabbering and raising a bunch of stink.
But guess what?
OS 3.1 no longer fights with Xfire. In fact, they're seeing other people now. OS now infiltrates the game code via pretending to be dinput8.dll, instead of d3d9.dll. That means all you Xfire lovers who have never heard of the superior software known as Steam will be able to play Halo, use OS, and chat via Xfire's ingame overlay all at the same time. Of course, the Steam lovers have been able to do this for some time now. Neener-neener.
On top of various other fixes, we've also got some more user-oriented features coming in OS 3.1:
* You know that 'checking for updates...' message that comes up every time you try to do something MP related? Well now there's an xml setting to make the game think it already ran this check, saving you an additional second or two.
* We now have a command line parameter for specifying what version of the game you want to display a server list for. By default, if a value isn't given via this parameter, we get the ENTIRE server list from all the versions of Custom Edition. Or you can specify "disable" and the server list will behave as normal, populating the server list with 1.09 only servers.
* We've added new xml setting for forcing OS to use .yelo files first when searching for .map files (off by default). So with this feature on, OS will pick a10.yelo first instead of a10.map, assuming both files are present.
* There's now a command line parameter for turning off all OS-based gfx additions/upgrades.
* The installer has been improved. E.g. it installs the VC++9 runtime, allows the user to -not- install OpenSauceIDE, etc
* Mini-dump support has been added to haloce/dedi/tool/sapien (guerilla is the oddman out) to aid in any future debugging efforts when the EXEs crash
Of course, average joe users aren't our only target demographic. Map makers are in for some treats too:
* We've increased the max grenade types to 4. This works in multiplayer as well and there are fields in the scenario's starting profiles to specify the grenade counts for the 2 new types. In order to keep this feature working in MP without having to wait on new networking features, we couldn't go any higher than 4. Some people were already catching on to this new feature
* We've added a script function for playing .bik videos (need to be in the same location as the game's existing .bik videos)
* We've added a system for displaying UI widgets via script code. You execute a function and then it displays a ui widget definition specified in the project_yellow/globals tag.
* We've added a 'runtime vectors' system in a similar fashion as the 'runtime integers' system. This system allows you to perform vector operations in script code. CMT was able to use this setup to essentially perfect vehicle boosting. You can check out teh_lag's prototype video of this here
* We've added script functions to perform bit operations (AND, OR, etc) and converting hex string to an integer
* We've increased the maximum number of particles that can exist at any given time. We're still playing with these settings, so the exact upgrade amount isn't set in stone yet.
* We've increased the maximum buffer size for model vertex and index data that Tool uses when building a cache file.
* The project_yellow_globals tag features a new flag for forcing the game to use 'stun jumping penalty' instead of 'turning penalty' in the engine's biped jump code. We're considering this a "patch" as I'm pretty sure this wasn't the intended behavior in the stock engine.
* We patched the weapon tag's magazine's magazine-objects block so that it will no longer crash when you try to add more than 2 elements. Uses the equipment field for the block name now too. This is a "patch" for a bug in the stock HEK. If you try to open the weapon tag in the stock Guerilla with more than 2 elements in the magazine-objects block, it will crash.
I want to make two special notes here that are aimed at map makers:
* Since ChokingVictim has become a lot more active and has presented quite a number of potential new features that we'll be adding later on, we're giving him his own tag to use to implement these new features: project_yellow_globals_cv. Why this matters to you is because we will be moving the unit-infection definitions *to* this tag -from- the project_yellow_globals tag. We're not aware of any maps that have been released that make use of the unit-infections system yet, so in order to Keep It Clean, we're just going to add this system's tag fields to his new tag group. If there have been any final maps that have been released which use the unit-infections system, speak now or forever hold your peace (and not have working unit-infections in 3.1)
* The team index offset for MP teams for the GBuffer has been changed. MP teams now start at 10, not 9 (game_teams come first, tho technically the last few are 'unused' by Halo proper). This is a breaking fix, but I'm not aware of any major MP map releases that used this specific part of postprocessing.
Developers have things to look forward to as well (well, there's no looking forward as most of this is already in the code already):
* The codebase has been reworked to match that of the actual game engine's.
* There are now only two shared source folders (aside from 3rd party libs), "blamlib" and "YeloLib". These help to draw cleaner lines where there is data/code added/injected by OS, or where there is code that is specific to OS.
* The CheApe compiler has been modified to support faux tag-structs. So if you have tag definitions that have repeated fields (eg, in the case of the engine's shader and hud interface tags), you can use these to essentially have the compiler cut&paste the field definitions for that tag-struct.
* We've been working on a string_id system that is very much like what is used in the games following Halo1. A first-class citizen StringId field type has been added to the CheApe parser so it will handle the underlying hacks that we made to get such a system working in Halo1. When a cache is being built, the system will also take tag_string fields and create ids for their values, then mapping the address of those fields to those generated ids. So existing tag_string fields can be used in code that works with string_ids.
That's all we're wanting to talk about today. Again, stay tuned for future updates involving what ChokingVictim has been working on. There may be even more features that make it into 3.1 from now until release, but we don't want to comment on them until we know their fate for sure.
Edited by kornman00 on Dec 17, 2012 at 12:59 PM
I would assume people would read a lot of things, yet people seem to still run past even readme.txt's
Quote: --- Original message by: goldkilla88
...hopefully the new version will fix this stupid OS Sapien bug.
If you have an OS-specific bug, submit a report using our Issues system: http://code.google.com/p/open-sauce/issues/list
A full installer has to be built, you can't just build with VC++ (it's not all just pure C++) and move the exes around. And the current code is still very much WIP. Which is why we haven't released yet. We could end up changing tag definitions between now and the next official release, or a bad build could FUBAR your tags. The only people who should be messing with the the latest changeset of OS are actual programmers.
Also, Steam has an in-game overlay and works with Halo.
Back? I never left :p. Unless you meant halomaps. In which case, I'm only visiting this part of town.
The next release of OS will be big (and is coming soon!). Big improvements, and big additions, and of course bug fixes. Hopefully the community's interest will continue, as we still have some more big ideas for an additional major release following it. But I'll save the details for another day.
Quote: --- Original message by: HaloExtreme117
If you know any C-based languages you'd know the term - it's a pretty vital term.
Yeah, I thought "HSPP is a C-like preprocessor for .hsc files" would be a give-away to that, but I guess not. Hell, even C# has a rudimentary preprocessor (which was what I was going to implement in the event that this didn't work out). But if someone just stuck their nose in a *barf* Java book and didn't do anything to try and expand their horizons, they would be in the dark when it came to preprocessors.
HSPP is a C-like preprocessor for .hsc files based on GPP (http://en.nothingisreal.com/wiki/GPP)
Usage: hspp [infile] [outfile]
Example: hspp a10.hs a10.hsc
It doesn't care what the file extensions are. However, I recommend using ".hs" for files which contain preprocessor directives so that the HEK doesn't get a taste of them. Then use ".hsc" for your output files, for obvious reasons.
A full list of supported macros can be found here under the "META-MACROS" heading.
The plan is to fully integrate this into the next release of OpenSauce so that it's all transparent. Because of this, I won't be supporting hspp.exe after today so that work on OS isn't interrupted. Until then, feel free to use this to preprocess your scripts before compiling them with Sapien!
(script stub unit player1
(unit (list_get (players) 1))
#define DEFINE_VECTOR(name) \
(global real #1_x 0) \
(global real #1_y 0) \
(global real #1_z 0)
; * DEBUG BUILD *
; * RELEASE BUILD *
(script stub unit player0
(unit (list_get (players) 0))
;(global real temp_x 0)
;(global real temp_y 0)
;(global real temp_z 0)
hspp example.hs example.hsc
; * RELEASE BUILD *
(script stub unit player0
(unit (list_get (players) 0))
(script stub unit player1
(unit (list_get (players) 1))
;(global real temp_x 0)
;(global real temp_y 0)
;(global real temp_z 0)
(global real temp_x 0) (global real temp_y 0) (global real temp_z 0)