teh lag has contributed to 509 posts out of 465642 total posts
(.11%) in 3,576 days (.14 posts per day).
20 Most recent posts:
Make sure that your scripts have actually been compiled. Check the scenario in Guerilla to be sure that the scripts and globals that should be there are actually there. Always be sure that you're debugging the right thing before you go further.
Try issuing the (wake <script>) command from the console to scripts that might be stalling and see if that makes them go. You might have forgotten some silly thing or other. Make sure that there's something actually running your scenario's scripts. I assume you know the basics of how Halo scripts get executed...
If the logical error doesn't immediately present itself, turn on full developer mode (set developer_mode 127) and use the (print <string>) command to trace your scripts' execution, from startup to wherever they seem to be going dead. This is probably your best bet for tracing logical problems in Halo scripts, since we don't have any sort of real-time debugger or state inspector in the actual game. The CMT scripts have a DEBUG_PRINT() macro for this purpose; if you build with #DEBUG turned on they will automatically print to the console.
It's no different from debugging anything else in the game.
Again, I don't really understand what exactly you're trying to do with this configuration. Just revert to the build system's original setup and gradually modify it to meet your project's needs. Clear out all the weird copies of things you've made, they're just going to get in your way and confuse you. Put them aside somewhere if you really need to keep some change you've made.
Probably start with the given test scenario scripts, or the player bonus test scenario scripts, since they're both pretty bare-bones. Read the documentation and take things one step at a time and you'll be fine.
Edited by teh lag on Aug 19, 2015 at 09:24 PM
So, the point of the CMT script build system was to combine the files together while staying under the source-file-size and source-file-count limits. I'm not sure what the intended goal is of outputting every single component as a.hsc on its own, but I can basically guarantee that it's not going to lead anywhere productive. Avoiding situations like the one you have there is a big part of why we introduced the build system in the first place.
Edited by teh lag on Aug 19, 2015 at 08:53 PM
1) I made my copy of HSPP accessible in the scripts directory
2) I cleared out the extra stuff you had floating around, so that the only versions of the scenario files were the ones in src\scenarios\d20. I also deleted the extra .hsc files in there, and the duplicated API header file. Maybe you ended up editing the wrong file with all these versions in there?
3) I fixed the missing parenthese in the cmt_extras_scripts.hs file
4) I ran the build script and it worked
here is the resulting directory: https://dl.dropboxusercontent.com/u/10778064/nmisc/scripts_for_megatron.7z
Edited by teh lag on Aug 15, 2015 at 12:33 AM
Remove this line from your main scenario macros and your scripts will build:
A fix for this problem was included in the player bonus release but evidently you don't have it. If you do want to keep the weapon tracker on, just add the missing close-parenthese to the RECORD_WEAPON_LOW macro definition in cmt_extras_scripts.hs . (It's just the if statement that's missing a close-parenthese, which happened because the system had been turned off for a long time).
"Exact same results"
That would suggest to me that either there is incorrect #include usage elsewhere that needs to be hunted down and fixed; or there are other errors in the script source file with less obvious causes. Could you post the resulting error message after fixing the #includes? Debugging the script builds +/ syntax with the preprocessor is an unpleasant process but usually it only needs to be done once before you get the hang of it.
Since the hsanalyzer tool is basically just providing sanity checks, you can remove it entirely from your build .bat file if you want. If you're using the TSCE / player bonus files as reference, the analyzer is invoked at the very bottom of the script -- just remove those lines and you're good to go. However, if it's failing to parse your script files, I imagine that Sapien's script compilation won't go much better, unless you've uncovered a bug in its parse routine.
I would also double check to be sure that the contents of your /out/ directory are actually being updated when you attempt to rebuild the script files with your latest changes. Sometimes you can end up with stale files that aren't actually the result of your most recent changes, if you've got some input / output directory wired incorrectly. This can be very confusing and it's happened to me many times...
Edited by teh lag on Aug 12, 2015 at 12:25 AM
Quote: --- Original message by: Megatron
To my fellow community members;
Since the thing with the Halo 3 Scarab currently isn't working out, I've decided to check out CMT's resources, and see if I could master their scripting techniques.
Not too surprisingly, I ran into this while trying to pre-process the scripts using the hspp asset:
File "util/hsanalyzer.py", line 94, in <module>
File "util/hsanalyzer.py", line 33, in main
decls = parse_source(source)
File "util/hsanalyzer.py", line 16, parse_source
hsparse.py, line 58, in parse_decls
raise parser.syntax_error("I expected a decl")
parse.syntax_error: [out/scenarios/d20/___components.apis.hsc#3 - ('decls', 3) I expected a decl: #include ('src/scenarios/d20/d20_macros.hsh')
Aside from not knowing what a decl is, I have no idea what to do now, aside from cutting out these assets if the problem takes too long to solve.
The tool is telling you that it expected a declaration ('decl') of either a script or a global. Generally the tool says "I expected a ..." when it runs into a syntax error. I apologize for the obtuse error messages that it spits out in general, but it was originally just intended for internal use :p
The error is occurring on line 3 of "out/scenarios/d20/___components.apis.hsc". I did my best to make the tool report which file + line a syntax error was encountered on, and a general idea of what the error is. The final line of the error output provides this information if it is present. The rest of the error message is printed by Python to assist with debugging in case the problem is caused by an actual programming error.
The specific issue you have a #include statement which was not correctly preprocessed. At a glance it looks like your usage of #include is incorrect: you've surrounded the included file path with (''), when the HSPP (and GPP, on which it is based) expects either "" or <>. No parentheses or single quotes!
Edited by teh lag on Aug 11, 2015 at 03:37 PM
Quote: --- Original message by: War Master V
EXCEPTION_ACCESS_VIOLATION is caused by Tool not having sufficient permissions to write to a directory. Run it as administrator.
As for the invalid format error, I'm not sure. The only thing I can think of is that your tags in those directories are corrupted.
This is not correct. It's a result of the application crashing because it tried to access an invalid section of memory, usually because it encountered an unexpected condition that causes it to behave incorrectly. It is possible that directory permissions could cause such an error, but it also occurs (for example) when a map's model data exceeds the maximum allowed vertex / index buffer size.
Tom, it looks like you're building with shared cache files on. (That's the second boolean parameter in build-cache-file-ex). The "invalid format" message you're getting is about bad data in the shared caches, and it might be related to the application crashing. Set the second boolean parameter to false so it doesn't try to access an invalid shared cache.
Edited by teh lag on Jul 30, 2015 at 08:02 PM
Quote: --- Original message by: Masters1337
If I wold you it would jeopardize what our plan is... That is a big enough hint
it's really good to be underhanded about these things.
what, are you just going to send out the mod with one of those "opensauce portable" archives? lol.
Edited by teh lag on Jun 28, 2015 at 11:12 AM
:) Really cool that you got everything working on your own. I hope that this is helpful to some people!
Quote: --- Original message by: Bungie LLC
i am sorry to report that while basically every tag from the a50 2012 era was backed up, i've not been able to find the sniper rifle. (or the smg for that matter -- it seems like at some point the backup got cut off in the middle of the 's' human weapons). the hek+ is basically your only option.
Quote: --- Original message by: Ubermaniac
lag, which pack has the .3ds files for the weapons and vehicles?
If there is none, could upload one please?
there is none because nobody knows where all of the files are and it would be an unreasonably huge task to try to find and organize them for release. many of the source files probably don't exist anymore because there is content in the mod that goes back to 2007 and earlier, and things just get lost over 8+ years.
Edited by teh lag on May 24, 2015 at 02:34 AM
Here's a maxscript which assigns WRL object names corresponding to error type:
I've found it very useful. You can customize it further to suit your needs.
Edited by teh lag on May 19, 2015 at 12:57 PM
Quote: --- Original message by: unknown
I found a little way into another room on the test map, but after picking up some weapons, it gave me an exception. also found the little halo 5 thing...
Edited by unknown on May 16, 2015 at 10:14 PM
Yeah -- the guns back there are actually the objects used for the backpack weapon system. You probably don't want to go picking them up.
Anyhow, it's here now. It's our final source release.
Title : CMT Evolved Armor Abilities / Player Bonus
Release Date : 05-16-2015
Author : CMT
Description : CMT Evolved's player bonus tag release
ii. Quick guide
This is it: the final release from CMT's Evolved team.
This includes an assortment of bonus tags, scripts and data files for player behavior things that never quite made it into TSC:E. These tags require that you have both the "core" and "scenario" tag / script releases. There's also a quick cute test map for the tags.
Most notable is a scripted armor ability system -- actually a suite of systems -- which includes these armor abilities by default:
1) Shield Booster -- limited-use powerup that lets you recharge your shields on demand. Depletes after two full charges.
2) Portable EMP -- limited-use powerup that, after a short charge-up, kills shields on nearby objects (but also kills your shields). Depletes after three uses.
3) Health Regen -- passive powerup that gives you limited health regeneration, like in Reach. Allows use of your default ability (like flashlight or VISR) while equipped.
4) Health pack -- single-use powerup that instantly refills your health on demand.
5) Active Camo -- limited-use powerup that gives you camo on demand. Running increases the chance that enemies will spot you; crouch-walking makes you fully invisible (unless you're right next to someone).
The CMT Evolved team implemented an armor ability system for TSC:E, but it was cut from the map a few months before release. This is a cleaned-up version of that system. We didn't think that keeping these in TSC:E was worth the associated resource costs. Also it's not very good that this system was implemented with scripts -- it should have been handled by an Open Sauce extension. (That's a big part of why we cut them, in fact). But, maybe one of you out there will find this interesting or useful...
This also includes an experimental system to notify the player of nearby health packs when their health is low.
Additionally, there are a few fixes for script components in the prior scenario release.
ii. Quick guide for lazy people who want to just stick the tags in a map
If you just want to get things running in *a* map, we've provided a test scenario that you can compile. It is located at tags\cmt\scenarios\player_bonus_test\player_bonus_test.scenario. Build it with OS_Tool.exe and you can start messing around. Spawn test AI with "ai_place enc" if you want to see how things perform in combat.
There's a readme in both the \tags\ and \scripts\ directories which explain some of their contents. They'll help you navigate the release contents.
There's unfortunately not much else that's "quick" about this stuff. Take a look at the scripts and the documentation therein, and hopefully things will make sense to you.
The "pb_test_cmt_features" script component in \src\scenarios\player_bonus_test\cmt_features\ is where the armor-ability (and other systems) are linked together with the scenario. Follow stuff from there and you'll eventually find where the magic happens.
NOTE! NOTE! NOTE!
These tags and scripts were cut from TSC:E for a reason. The map may not be able to compile under all of its resource limits with them added; it will likely take a lot of effort to make them work correctly in TSC:E. You have been warned. Good luck.
(Rather than clutter this up with everyone's name, just see credits.txt)
Until next time, everyone.
Edited by teh lag on May 17, 2015 at 04:03 PM
Quote: --- Original message by: Mokou Price
How to use the health regeneration? I don't know how to use it.
It will automatically restore your health up to the next ~2 health blocks if you avoid taking damage for 10 seconds.
Quote: --- Original message by: Bungie LLC
There's a small something hidden somewhere else but it's nothing too exciting. Glad to see that someone thought to play this on noble :)
Edited by teh lag on May 16, 2015 at 06:04 PM
The Evolved team's final tag release draws closer. To whet appetites, I'm releasing the test map that appears in this video from last week:
Just a quick cute test map for the player bonus tag release. Demonstrates the Evolved armor-ability system.
Spawn test AI with "ai_place enc".
Even in a map like this, there are still a few last secrets hiding...
The map is here: http://www.mediafire.com/download/epmwekdsx18mmpg/cmt_evolved_player_bonus_test.7z
The tags and some other things in the Evolved team's final release will hopefully be out this weekend.
Nobody must forget H2CE, which was born in 2004 and died in 2005. A huge amount of the stuff you can do in the game beyond what the HEK tutorial tells you was first applied on a large scale by them. Scripting, injecting custom animations, synchronizing devices over the network...
It is also very easy to forget that for the first ~1.5 years of HaloCE's existence, we did not have the tags needed to build singleplayer maps at all, nor to add the "singleplayer" menu option back to the main menu. It wasn't until Kornman00 released the solo UI widgets (and then later TheGhost made public the full solo tagset) that those things were even an option for the community at large. Similarly, do not forget when we finally solved all of the riddles protecting Km00's scripting bible... (All of those would have been in 2005).
Do not use Tool Pro. These limits exist for a reason. Also, the TSC:E tags will only build with os_tool.
Quote: --- Original message by: Perla117
total tag size is 20.16M (14.34M free)
cache file 0.35M too large (should be 576.00M but was 576.35M)
### FAILED TO BUILD CACHE FILE.
So, you have added more data to the map than is allowed. You will need to remove some things before it can build.
In general, reducing resolution on textures is a good way to get more overall space quickly. This will help you get under the cache file size limit. Fortunately you only need to remove 0.35M overall, which should not be too difficult.
You also have more tag data than can be safely used in the map (14.34M free). You need at least 14.94M free -- this is the size of the largest BSP. If you don't have that amount of tag-space free, the map will begin to cause the game to crash as you move to the larger BSPs. (This is because of an obscure bug in os_tool.) You must remove some tags to add more free space here. Removing animations are a good way to get more tag-space quickly.
The unfortunate reality of the map is that it is very close to almost every size limit in the game. Basically nothing more can be added without removing something else. A lot of the easter-egg content (the egg_captain bipeds, for example) would be a good place to start freeing up data. Swap their palette entries for something else, or remove them in Sapien.
Quote: --- Original message by: Nickster5000
And why are you recompiling TSC:E anyways?
Probably because he's made some modifications that he wants to try.
Edited by teh lag on May 12, 2015 at 07:27 PM
Quote: --- Original message by: sparky
I learned earlier this year that custom playback animations need to have node list checksums of 0 in the .model_animations tag.
what? no. they need checksums that match the model they're played on.
Quote: --- Original message by: Nickster5000
Out of curiosity for the evolved team:
What exporter did you use to export everything?
Thank you in advance for your response!!!
Edited by Nickster5000 on May 3, 2015 at 11:40 PM
(Just answered this in PM but I'll also share it here for everyone else)
I personally used 3ds max 8 for most of development. The others used 2010, 2012 and above, and I eventually switched to 2010 as well after I found a configuration for it that I was happy with.
For most of my Max 8 work, I used Blitzkrieg unless I was working with rigged objects.
For rigged objects in Max 8 (and particularly bipeds), I used a lightly customized version of CtrlAltDestroy's updated Bluestreak exporter:
The modifications in question were to make it correctly ignore the "Bip01" root node for bipeds, since Blitzkrieg ignores that node and Bluestreak (even in the version above) doesn't. We supplemented these modifications with a manual process to fix the child / sibling indices for Bip01 nodes -- since Bluestreak doesn't sort them in a manner compatible with whatever it is that Blitzkrieg does. (It's probably something simple like case-sensitivity but I never bothered to figure out what was actually going on). Any time we exported bipeds with Bluestreak, we also exported their node structure using Blitzkrieg and then ran a batch script to replace the Bluestreak .jms files' child / sibling node indices with those from the Blitzkrieg .jms file. This allowed us to keep the files compatible with other models / animations / etc that had already been exported with Blitzkrieg.
For Max 2010+, we used CAD's Bluestreak upgrade unless we were working with BSPs.
For BSPs in Max 2010+, we used BobbySoon's JMS exporter:
Though it was not as stable as Bluestreak when handling regions, it caused a very significant speedup in export time when working with large BSP files -- particularly when exporting the same file multiple times in the same session.
We paired with with BobbySoon's WRL importer:
(This importer will tag the WRL objects with the error type they came from -- very very useful!)
When exporting animations in Max 2010+, we used the "compact" version of CAD's animation exporter:
(The non-compact version wasn't compatible with Max 2010+)
However, as of this past September, user Sprinkle has publicly released a proper 3DS plugin for 2011+ that handles both model and animation exporting:
I've not experimented with it, but it appears to correctly handle the Bip01 root node, which is the major correctness issue with Bluestreak & friends. I don't know if it sorts biped child / sibling indices in a manner compatible with Blitzkrieg though. But it seems like it can remove a lot of the headache involved with juggling the various community maxscripts.
Edited by teh lag on May 4, 2015 at 07:35 PM