it was only delete the old optic, but a friend had gathering ecxeption data when he load a pack
Printable View
it was only delete the old optic, but a friend had gathering ecxeption data when he load a pack
Download http://www.microsoft.com/en-gb/downl...ils.aspx?id=35.Quote:
Originally Posted by megajd16
I'll need to mess with this when I get home. The lua scripts look pretty straight forward.
Is it possible to load multiple packs at once? Say, for example, I were to use the Reach medals pack, but I also wanted to run a pack with, say, some custom medals, stats tracking or like some hacky hitmarkers.
It automatically unloads the current pack when you load up another, so no. You can combine the packs, but only if you customize the lua file yourself and place the audio/images in the correct folders.
they are incredible but...
What about stats tracking??
Amit is on the money there. I debated it but figured it'd become too much of a headache for users. I could add a second load command that didn't unload the first pack pretty easily if you really want the option but it's not something I want to support when users can't figure it out or run clashing scripts.Quote:
Originally Posted by t3h m00kz
I do like the idea of at least having the option to force-enable multiple packs if the user knows what they're doing. I feel it would allow more flexibility with adding on small, very specific scripts, kind of similar to Mutators in Unreal Tournament as you can tack on all sorts of little modifications to mix and match.
For example, a user could have the default medals scripts currently available, but could also add in a pack that simply displays a "You SUCK!!!" medal after dying 5 times, or the hit markers that I've got planned.
In a perfect world, packs would never interfere with one another, but of course there's going to be some user out there who tries to load all of the medal scripts together and wonder why everything's breaking. I've not really much idea as to what would cause interference as my scripting knowledge is fairly basic, but I'd imagine that as long as functions and variables maintain unique names between packs, it shouldn't cause too much of a problem.
But perhaps I haven't the slightest as to what I'm talking about, that's always a possibirrity
That's a slippery slope, but it could work so long as the packs don't interfere with each other. It makes me think of the way a mod manager I use for Lord of the Rings Online works. The manager itself is a mod that can be loaded up and used to enable/disable other mods using a GUI interface. Obviously, that's not necessary for this since a force load command would basically do the same thing. Specific instructions to force-enable it could be included in the ReadMe/Install file.
It seems that what you want is a very tailored experience. You'd be better off building it yourself since once you get it just right, you're not likely to change it. At least, that's what my line of thinking is. Maybe I'm too much of a purist, though, who wants to have a no-nonsense set of medals that becomes the standard. A way show off the new system as professionally enhancing the experience while still being inline with what Halo PC/CE is: a seriously solid multiplayer experience.
The purpose of these packs is not to hard-code in a solid experience. It's to allow users to create their own experience as they see fit. If the user wants to have a no-nonsense set of medals, they can stick to what works for them, be that just one well-made pack. On the other hand, some users will want to expand on top of that solid foundation.Quote:
Originally Posted by Amit
To quote BTCC22,
Only supporting one pack at a time will result in multiple big, bulky packs with tons of overlap, when the same result could be acheived by simply loading multiple packs on top of one another.Quote:
Originally Posted by Btcc22
Conflicts are going to be a problem, yes. Like I said before, some nerd is going to attempt to load all 3 of the medals packs together, which I doubt will end well. What would ideally happen is, conflicts would be communicated to the user in a user-friendly way, but also with enough information for pack developers to debug the problem.
It seems very limiting to add the functionality of packs for the purpose of allowing and promoting the creation and distribution of user-created content, then limit the user to a single pack. Everybody's just going to stick with the stock packs. user-created packs designed to add a tiny additional bits of functionality will rarely be used, as users will need to sacrifice one for the other.
What user would ever load a pack with a single "You SUCK" medal at the expense of all of the other medals? And what scripter is going to want to build off of the packs that already exist, rather than having a small, very specific pack streamlined for the functionality they want?
If I were to add hitmarkers as it is now and distribute it, I'd have to create 3 separate packs (one for H3, Reach, and H4), all with every asset and line of code from the 3 stock packs, PLUS my own assets and lines of code. The end user would then have three new packs for one new bit of functionality, rather than tacking it on top. It would be more efficient, less bulky and less cluttered to allow a single additional pack to be loaded on top.
Skilled scripters who understand how the system works will be able to avoid pack conflicts if they test their work appropriately. And if their packs are done well enough, their packs just may be used.
... Not that I'm a skilled scripter in any sense (I'm working on it!!)
... I think my QA may be showing.. ultimately this is up to BTCC22. I can only offer suggestions.
E:
Here's a visual example.
I've been messing with this tonight. I don't entirely have the hang of it, but until documentation is released with more info, I'm doing something simple - attempting to bring back the missing death sounds when the player is killed.
I want to isolate it to just the player, as it's flat, and there's no way to scale with distance. As it is right now, I've got death sounds that queue up whenever ANYBODY is killed.
.. Not entirely certain how to isolate it to just the player just yet (again I'm kind of bad at this)!! I'll mess with it more later
Code:api_version = "1.0.0"
deathVoiceTable={
"audio/death1.mp3",
"audio/death2.mp3",
--"audio/death3.mp3", -- doesn't exist
"audio/death4.mp3",
-- "audio/death5.mp3", -- doesn't exist
"audio/death6.mp3",
"audio/death7.mp3",
"audio/death8.mp3",
"audio/death9.mp3",
"audio/death10.mp3",
"audio/death11.mp3",
"audio/death12.mp3",
"audio/death13.mp3",
--"audio/death14.mp3", -- doesn't exist
"audio/death15.mp3",
"audio/death16.mp3",
"audio/death17.mp3",
"audio/death18.mp3",
"audio/death19.mp3",
"audio/death20.mp3",
"audio/death21.mp3",
"audio/death22.mp3",
"audio/death23.mp3",
"audio/death24.mp3",
"audio/death25.mp3",
"audio/death26.mp3",
--"audio/death27.mp3", -- doesn't exist
"audio/death28.mp3"
}
function register_callbacks(event, victim, player, timestamp)
register_callback(cb['PLAYER_KILLS'], "playDeathVoice")
register_callback(cb['PLAYER_ENVIRONMENTAL_DEATHS'], "playDeathVoice")
end
function playDeathVoice()
if(killer ~= player) then
queue_audio(deathVoiceTable[math.random(#deathVoiceTable)])
elseif(victim == player) then
queue_audio(deathVoiceTable[math.random(#deathVoiceTable)])
end
end
