“It’s the most moddable game ever.â€
sheena_yanai
Join Date: 2002-12-23 Member: 11426Members
Join Date: 2002-12-23 Member: 11426Members
<div class="IPBDescription">maybe, but its not exactly mod friendly</div>made some <a href="http://yanai.blackmage.org/sky2/NS2/index.php?dir=Sounds/" target="_blank">voice overs</a> for my exos since that crysis like heavily distorted "IM THE JUGGERNAUT BEESH!" megatron voice kinda blows, i could barely make out what it was saying, i had to extract them to listen to :o
yeah..well..
but getting the sounds back into the game...
screw that fmod designer.
and soundinfo.exe or whatever else you need to get 3 sounds back into NS2
cant we have a similar system like the old .pak system when the game could priorize and load matching file structures and same filenames which are located in the same directory as the .pak files?
spent hours just trying to figure out that file system, and got frustrated by it when i remembered its supposed to be the most moddable game ever, when i cant even figure out how to replace files.
edit: dang, just realized i am not in the creations forum.
commando! need a phasegate!
yeah..well..
but getting the sounds back into the game...
screw that fmod designer.
and soundinfo.exe or whatever else you need to get 3 sounds back into NS2
cant we have a similar system like the old .pak system when the game could priorize and load matching file structures and same filenames which are located in the same directory as the .pak files?
spent hours just trying to figure out that file system, and got frustrated by it when i remembered its supposed to be the most moddable game ever, when i cant even figure out how to replace files.
edit: dang, just realized i am not in the creations forum.
commando! need a phasegate!
Comments
That's what consistency checking is for, which they are going to implement.
I don't really understand why this is relevant at all?
Some annoying bugs still exist in the editor, things going off grid when moving, models flipping, textures not locking, lots of little time saving features could be added, it's not really fair to waste peoples time with these silly things, better tools will make better content faster.
Sure, modelling and sound tools need to be at a much higher level than they currently are for this to be the able to claim the most modifiable game available.
I do however think the moddability is still good. I can, since I am making full mods, just create my own sound files, and not use the NS2 sounds at all, but that is a lot of work. I can still however extract and use some NS2 sounds in my own mod sound file.
It depends on how much sound customisation you want. If you want complete sound customisation, it is very easy to make your own sound files. If you want to edit sounds in NS2, that produces a whole different can of worms, with regards to cheating etc.
I think what we really need is clarity on what will be moddable and how at release v1.0.
That's what pure servers are for and also more specific whitelists. One server could want sounds from GCF while another would allow it to be modified.
if there's any error it causes another error that console is spammed with and I don't know what was the original one
If I run game in decoda, it tells me where the error is but I can't fix the code and continue as it's possible with Lisp. So I have to run game from decoda which takes like 3 minutes to start because if I try to attach to already running game breakpoints don't work.
And most of all - no static types. It takes more determination than most confusing spaghetti C++ code if you want to understand longer Lua files. Code is both spaghetti-like because of use of (class) global variables and confusing because it's untyped.
I kinda think i did the startup sequence to much like mech warrior. Im open to sugestions and requests to do some more voice overs. Maybe drop me some lines what it should say instead. I might even do some beefier sounds for the exos walk, since it sounds a bit light, adding some nicer servo sounds.
if there's any error it causes another error that console is spammed with and I don't know what was the original one<!--QuoteEnd--></div><!--QuoteEEnd-->
Let me say, I am not a programmer, yet I have produced over 10 mods for NS2, including 4 full gameplay mods, of which I am actively still developing 2. I know some very basic programming, but even I can go through the log trails and work out the problems. Maybe you are used to systems that do this kind of thing for you, but as I said, I don't use other programming languages, I can pretty much only use NS2 lua for programming.
I just open the log file, and go through the trail, following the code and the variables that are being passed until I see the source of the error. It really is easy. Maybe it's easy because I don't know any other ways of doing things, but I know trying to solve problems for me in C++ code (namely the source engine) was impossible and I gave up programming it after 4 months and only adding dual pistols and changing the bullet spread :P
I can't think of anything easier to bug hunt in than ns2's lua code, but that is because I haven't used any tools that do the tracking work for you. Also I learn all I have about the code, precisely because of this method of bug hunting.
If someone with as little programming knowledge as me can produce mods like I can, there can't be that much wrong with the bug-hunting methodology this requires you to use. Oh and I don't use decoda to hunt bugs, purely because my PC can't handle running a debugger and game at the same time, and I wouldn't know how to use a debugger properly anyway...
You can also have types that tell you how long vector is.
<a href="http://www.youtube.com/watch?v=C4D96LVtRMo&feature=player_detailpage#t=920s" target="_blank">http://www.youtube.com/watch?v=C4D96LVtRMo...tailpage#t=920s</a>
The more rich the type system the harder it is to prove anything especially automatically (by the compiler).
On the other hand Haskell isn't (wasn't) exactly runtime debugging friendly. You can for instance see reaction of Haskell programmers to a working stack trace:
<a href="http://www.youtube.com/watch?v=J0c4L-AURDQ&feature=player_detailpage#t=1290s" target="_blank">http://www.youtube.com/watch?v=J0c4L-AURDQ...ailpage#t=1290s</a>
That is essentially how our modding system works. The problem is with how FMOD works with files. It wants them all packed up into those FSB and FEV files, so you can't really overwrite individual files.
A few weeks ago I started on the early stages of a really ambitious project. I went to play with it again today and it just crashes, because of something in build 220/221 that isn't playing nicely with it. I'll get it working at some point tonight, but stuff like that really kills my motivation.
Are there plans to have a stable, stripped-down codebase? This game obviously has a lot of modding potential (by design) but I don't feel like it's possible to really work on something big yet. If everything is relegated to mods like combat, marine vs marine and HUD changes, why put all that work into the LUA frontend?
As soon as UWE decide the code base is stable, or they release a 'Mod Friendly' code base that doesn't get updated every week, I will be back on this and sharing it out for everyone to use :D
I will try and write a little guide on how to do it successfully with Hotloading support and blocking the loading of certain classes (something I'm looking into at the moment) using fsfod's class H.ooker and load structure - it's worked very well for us with Combat (though new builds do tend to break things every now and then, the level of difficulty in getting everything merged and working again is far lower and we are usually back up and running within a couple of hours).
I am about to undertake a similar 'stripping down' project called SparkBasic (which I'll put on GitHub), which just has players with marines running around with two teams and the basic class functionality - none of the specialised classes, structures or weapons included. The idea is that this can then act as a stable base for other projects to fork and pull changes from. I'll do this using the hooks functionality, classloader and script load blocking, which should make it straightforward for others to extend upon and add their own functionality to.
I've been planning to do this for a while but decided to wait until the code base becomes more stable. If you finish before then, then all the more power to you. And it'd save me a lot of time! :)
Mine will be quite some time as I am taking a break from modding for a while as I concentrate on my programming courses. As long as UWE gives us at least a week with the 'Gold' code before release, I will have a GorgeCraft and Proving Grounds release for v1.0. They won't be final, but they will be functional, and hopefully fun :D
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->// Case doesn't matter here!
kCombatFileRemovals = {
"lua/CommAbilities/Alien/Bonewall.lua",
"lua/CommAbilities/Alien/CragBabblers.lua",
"lua/CommAbilities/Alien/NutrientMist.lua",
"lua/CommAbilities/Alien/Rupture.lua"
}
// Case matters here!
kCombatEntityStubs = {
"BoneWall",
"CragBabblers",
"NutrientMist",
"Rupture"
}
if #kCombatFileRemovals > 0 then
Shared.Message ("Registering file removals...")
end
for index, override in ipairs(kCombatFileRemovals) do
Shared.Message ("Removing source file " .. override)
// Hook into the load tracker code to remove the file when we come across it.
// The normalized string is always lower case.
override = string.lower(override)
LoadTracker:SetFileOverride(override, "")
end
for index, stub in ipairs(kCombatEntityStubs) do
Shared.Message ("Stubbing the entity " .. stub)
local result, error
result, error = loadstring(stub .. " = {}")
pcall(result)
result, error = loadstring(stub .. ".kModelName = \"\"")
pcall(result)
result, error = loadstring(stub .. ".kMapName = \"\"")
pcall(result)
end<!--c2--></div><!--ec2-->
I will attempt to create SparkBasic in the next month or so. At the end of that project, there will probably be a useful baseline for other mod developers wanting to make total conversion projects but without having to work out how to make a basic starting point for their code. All you'd have to do is fork SparkBasic and if SparkBasic changes just pull in the changes using Git.
The advantage of this method is that by and large it shouldn't need a lot of actual maintenance work in order to benefit from optimisations made in the basic Spark classes like ScriptActor, PlayingTeam etc.
There are obviously multiple ways to solve it, but I can tell you from experience, NS2 is littered with these calls that break seemingly unrelated things when you remove 1 item. I know, I seem to find more every time I restart the code. :D