Attn Mod Teams: what do you need? suggestions thread.

(malarky) #1

We’re starting to think about more seriously about what we can do to foster and facilitate mod development once ET:QW is released.

Splash Damage was once a mod team, before all this [waves arms around in a fashion suggesting “bigness”] happened, so we have a good idea of what you guys need from us; we’re looking for more leftfield suggestions that will make your lives easier so you can focus on the making of stuff.

Without promising anything, some of the things we’re thinking about include wiki hosting, running a torrent server for map/megatexture distribution; things along these lines.

Post! Post away!

[note: please do not take the posting or acknowledgement of a suggestion to mean we’re going to do it!] :stroggtapir:

(Zarkow) #2

Invite a number of selected dev-teams to beta-test any and all apps you intend to release aswell as, as a payback one could see it, start to build a resource-bank of knowledge and tutorials with these teams.

How To-tutorials are so essential it cannot be stressed enough. once a team usually gets their head around the initial steps, they will be able to function on their own a lot. But if they don’t have a clear picture of why to do something or does something essential slightly wrong from the start…a whole lot more ‘support’-threads will show up in ‘the’ mod-forum.

And to add what we talked about on irc:

  • Right now what is needed: info. - for example stats regarding the items and models used in the ET-QW-game. This should provide a basic ‘area of target’ for most teams, or ‘budget’ if you will.
(Tron-) #3

Definitely the wiki that it has been mentioned you guys have internally and may be opened up publically after ET:QW ships.

Access to the tools obviously, although I guess that’s pretty much a given.

Some kind of torrent distribution system for maps would be great, but I don’t know how much it would get used. I love the id torrent page for downloading patches, but it never seems to get used much.

Honestly, if the game gets a big following I don’t see it being a real problem. Mod communitys always spring up around popular games, and if the stuff is going to be released that was talked about in the Quakecon vids, any serious modteam should have no problems.

edit: One thing Valve seems to do really well is promoting good mods. With popular user made maps/mods it would be nice to have a little section of the offical ETQW page that gives download links to them and a couple of screenshots or similar.

(ayatollah) #4

I think the torrent idea is great, I don’t know what size maps will be (never mind mods) but I guess they will be pretty large. And to save your bandwidth, and others, torrents are great.

Also, releasing Goldrush.map was great for people learning how to map for ET, I don’t know if its possible but something similar for helping modders learn the new platform would be great too.

(iwound) #5

Yes some kind of mod prefab/template and possibly mod making gui :uhoh:

(rebb) #6

A Wiki would definitely ( okay, i looked the spelling up… ) be useful and can cover a lot of information that people need.
( id and Raven already started going in the right direction with iddevnet.com )

Examples or Source-Files of different Types of Art-Assets would help as well - but those will probably be in the SDK anyway :).

(Joe999) #7

an introductory video tutorial by Matt Wilson would be awesome :uhoh:

(zeh) #8

Wiki/Torrent: good.

1. Sources/samples

One thing that I think could give people a heads up is good samples. For example, let’s suppose you want to show how easy it is to add a new weapon to the game; one developer could create a new mod which just changes a weapon and distribute it. While tutorials also work, having samething to extend from is a great heads up when modding today, I believe.

I’d apply that to weapon scripting, vehicle scripting, and adding new gameplay rules. Having small samples would be awesome. Levels too, of course, if ‘sources’ to the official maps are not provided.

2. Someone to reply to people

Also having somebody to contact when all other options have been exhausted is good. Like what Brian did with id’s devnet, posting news and replying to people’s emails on the website. This is a tough one as I’m sure a lot of people would email to ask the simplest questions, but for some very cryptic/unknown issues, having somebody to ask something which sometimes is pretty small is great.

3. Community contests

In the future, having contests, similar to what id is doing with the Q4 map pack, would be great. This gives modding developers on the community a real reason to bust their asses doing something - even if they’re not the best, they know they have a purpose, a deadline to meet, and it works much better. Players also know the community is doing it (ie, designing maps) so people stay around because they know there will be an influx of new content. Something similar happens with Epic’s make-something-unreal contest, although the scale there is much bigger as it involves not only maps but also everything else.

I’ll not get into the merit of proper compensation for development, as I don’t think it’s the main issue. Just having the contests is usually good enough. I guess people will always “see” the competition under a more positive light if there’s some kind of prize though.

Oh, and give people time to create their content. Like a map contest with ~6 months for people to develop would give people enough time to learn the tools, and test the hell out of the map before submitting it.

That’s it for now. I’m sure I’ll think of more stuff to suggest later. Thanks for posting this topic.

(Sir. Darth_Master) #9

modlight ? :?

(jaybird) #10

One of the things that has given Jaymod issues in particular was the lack of original assets to work with and the tools to do it with. Mr.Mxyzptlk has done a great job with Muskoka that provides support in Maya with the various ET formats, yet support is not (yet) complete and there are still things we cannot do (like create 3rd person animations). There are probably legal reasons behind all of this, but IMO, providing the tools to work with provided original models would certainly help out those that would try to expand on the game.

(TTK-Bandit) #11

based on my q4 experiences:
better access to parts that are accessed by the sdk.

for example:

  • in q4 the gamebrowser was horrible, and there was no way to extend it… well you could hack it by reading all lines one by one and parsing them to generate your own server browser, but thats ugly.

  • the ability to read new si_ cvars from the gamebrowser without just having to use the predefined ones would be nice.

  • playermodels in q4 are hard to define, because some keys are given and you cannot add more key/value sets to the definition.

  • more shaderparms would be nice, and if effects could get shaderparms too that would be great.

  • in q4, you had to export models using maya … an extern model converter or an export plugin with sourcecode would be better…

I’ll try to think of some more things, I can’t remember them all, but in q4 there was a lot that bugged me.
I know et:qw is not q4, but q4 is a good example :slight_smile:

(3j) #12

I agree with the need for better model importing tools. We could never get the Maya importer for D3/Q4 to work, even with the models that came with the SDK.

Official support for core mods (even just a list of mods on the ETQW home page) would be nice.

I would also like to have more access to the editor. Many mods come with features for level designers that would be considerably easier to set up if there was editor customization for it. Also more access to the editor = more 3rd party tools, which is never a bad thing.

(kamikazee) #13

Running a wiki can be good, but don’t forget that projects like Modwiki.net have already collected vast amounts of information.

@zeh: Samples would be great.
But as I said, Modwiki already features a lot of that info so writing fresh new articles is a little moot.

2. Someone to reply to people
I think the way this forum works is nice. Someone posts something and people try to answer it, eventually a dev jumps in too.
Eg. try to look for Sock in the deepest bowels of this forum. Back then, lots of information was just posted on this forum, immediately accessible for everyone.

As for my own wishes: model conversion tools, or at least some support/documentation to make them. (Given that some Doom 3 fans got it done, it shouldn’t be too hard to make those work for ET:QW too.)

Of course, static models are no problem like W:ET was by using native model formats.

(k0k0nat) #14

OH PLEASEEEEE, PLEAAASSEEEE
MAKE STRG+C and STRG+V work !!! ( if it doesnt)

Oh damn… when i remember the Q4-Serverbrowser and the console… it was horrible.
Everybody loves to copy and paste IP’s.!

(mortis) #15

Unreal Tournament included a log-on news page with information about new patches, mods and maps, I found that to be useful.

Epic Games also released fan-created booster packs - I’d like to see an “out of game” update tool that can be launched seperately, hangs out in my system tray, and works as a P2P booster pack downloader that exchanges map packs / mods / skin packs / etc that I have identified for download out-of-game. When I go to bed I can turn it on and miraculously have all the megatextures in the morning. Perhaps a “developers library” can be set up allowing you to select from various custom megatextures, for instance.

I’d like a “default load out” setting so that only default/official packages will be loaded…aka I won’t get the grinch skins when I’m trying to watch a demo or do some devmap work. Or possibly provide a way to identify to the game which pak files to load.

Some versions of UT2k4 shipped with a DVD video tutorial for unrealed…great for teh nubs. A picture is worth a thousand words, and if there were some short “your first room”, “your first vehicle” and a “your first script” videos, it would certainly help.

Sample .map files. Please include more than one, or at least one that uses all or almost all the entities that the game ships with, so that working examples can be seen and manipulated. It is much easier to analyze a working example than to follow instructions, sometimes.

Custom map scripts (like etpromapscripts are to Wolfy). Noone loves custom map scripts more than me. The ability to spawn in or remove entities and brushes is so useful in terms of debugging, removing exploits and honing maps for competition.

(jRAD) #16

It does. 8)

(kamikazee) #17

Spawning new entities works already in Doom 3. :wink:

The only thing I’m not aware of is a “custom scripts folder”.

(k0k0nat) #18

ty jrad, u made my day :evil:
good 2 hear

(rebb) #19

Running a wiki can be good, but don’t forget that projects like Modwiki.net have already collected vast amounts of information.[/quote]

Yes, but it was mentioned in one of the QuakeCon Videos that SD already has an internal Wiki System with loads and loads of first-hand Knowledge in it. So i assumed that the “wiki hosting” malarky mentioned would include at least part of these Articles when it goes live.

(Mr.Mxyzptlk) #20

I think I may get shot for making this suggestion, but anyways here goes. I probably have too much detail in there, and maybe there are some architectural mistakes, but I hope its food for thought.

Variant (Client) Binary Support
-------------------------------
I would like to see the ability to support variant client binaries, where a
DEFAULT is always present, and optional bin(s) for the same platform are
provided at the discretion of SD and/or mod maker.

As we're not familiar with the exact details of binary names, and types of
binaries which will be available for ETQW, please bear with my guesses and
suppositions. Platforms for example { WINDOWS, OSX, LINUX }.

PLATFORM DEFAULTS
-----------------
The platform forms the first component for DEFAULT. This is composed of a
platform name plus a designator for 32 or 64 bit. These essentially form
the minimum base set of client bins.

  1. client-win32.dll
  2. client-win64.dll
  3. client-osx (assuming UB is preferred)
  4. client-linux32.so
  5. client-linux64.so

You might ask why including the PLATFORM name as part of the binary name is
useful if the extensions are unique. This is because the lifetime of ETQW is
unknown, and it may stand the tests of time and actually get ported to other
platforms which share the same dynamic module extension.

VARIANTS
--------
There are many useful needs for variants, especially in the mod-maker arena.
At times, it may be desirable to offer a debug-version of the binary to
permit coredumps. Other times we may desire to offer CPU-specific optimizations
in the binary and/or builds using different toolchains. For example,
in the linux arena, we might desire to offer binaries dynamically linked
to specifc versions of OS libraries such as glibc or libstdc++.

But how does the client select a variant? I propose the client should
always by default get the working choice, and that would be a binary from
PLATFORM DEFAULTS. Once the default binary is activated by the player,
the client may then go to a settings menu, and browse/select special
binaries available to them, if any, which would then be activated upon
game restart. So this extra step/complexity is only necessary for those
who are interested in it, or care about it. Others can stay with platform
default.

.PAK FILE LIST
--------------
Checked by the game would be a .PAK distributed file named 'binaries.tab'.
The NAME must strictly adhere to the basename of its desired PLATFORM
followed by a hyphen and some arbitrary chars.
Sample:

NAME                      DESCRIPTION
-------------------------------------
client-win32-sse2         sse2 
client-win64-sse2         sse2 
client-linux32-pentium4   pentium4 
client-linux32-athlonXP   athlonXP 
client-linux32-glibc23    glibc23 and libstdc++.so.6

DOWNLOADS
---------
If at all possible, the clients should be made to download only
the binaries applicable to their platform. Thus if running on platform #4,
a newly connecting client would reference (and download):

    client-linux32.so
    client-linux32-pentium4.so
    client-linux32-athlonXP.so
    client-linux32-glibc23.so