I know that much of this is a wish list, a lot of this is impractical and or not pheasable however some of it is.
Attn Mod Teams: what do you need? suggestions thread.
Well, as far as the external editors being too expensive, you should look around the free software world for alternatives to the programs you mentioned. Blender just had a new release, and the multiresolution meshes/sculpting/baking! mean a lot to modding a d3 game.
The d3 engine does let you do a whole lot out of the box without recompiles too- the editor has a ton of realtime modes, and the in-game editors are quite nice. You can access a lot of things in script without touching the sdk- or you could in d3, q4 changed that and maybe etqw has too.
One of the things that might help with the documentation (what mod teams need most) is a well thought out course of tutorials. Broken up into ‘majors’. Modding is a class based game these days- no no farther than the configs that shipped with d3. You’ll see that the modelers’ keyboards have mappings for a whole different set of commands than say, a sound designer. Same goes for lighting. Seriously, crack em open and they’ll tell you a lot about each persons daily workflow.
Id/raven/sd work this way, and I think a lot of modders haven’t caught on to their level of productivity is because they’re trying to master every portion of a complex system. If a team member only needs to learn 1 or two ingame editors, and a small subset of the console commands and cvars, then they’re going to be able to get down to the business of creating content a lot sooner.
Visual Studio has a free version. I use it when we are projecting for ET:QW-AvsB in D3.
With the potential for larger maps, a better way to distribute maps/map packs. Key for getting custom maps played IMHO.
1)It would be a shame if great maps aren’t played just because of file size.
2)Custom maps in RTCW and ET keep things interesting and fresh. Unless you just want to scrim frostbite forever
Just would like to push a little bit extra for one more thing:
Easy to follow short-lists of steps on how you (in SD) manage your asset-pipeline.
Example:
- Create char lowpoly in max and rig it to skeleton.
- Import in zbrush, create highpoly.
- Create a normalmap, apply it to material of lowpoly-char.
- and so on
(I’m not a modeler, so the above is just an example…)
Simple flowcharts/lists on how you already do it will help everyone get up to date with a basic flow of assets, since it can be very different between games (due to different setup and limitations).
two things for me.
1- (kinda related to modding) easy to understand demo playback controls - and if you can pull it off, I think you would be the first to do so, a rewind function.
2- “tweak” mod tutorial - for the inevitable mods that want to change one or two things. such tweak mods may have recoil based on stance (gun movement), movement speed adjustments, put in or take out jump shooting, etc. BF2 did this fairly well but left out some key things such as recoil based on stance, putting in or taking out jump shooting, etc.
A good way of accomplishing this is to have a some kind of overview / roadmap of the code.
To make an example using q3/et, this would describe the 3 VMs and their syscalls and vmMain functions, and then go on to point out the files/functions where various important things happen.
The idea is to give people an idea where to start looking, rather than comprehensively document everything. Just having an idea of what file/directory to start in as big time saver compared to randomly searching the code for likely sounding keywords.
Tweaking is a different beast in Doom 3 though - lots of “tweaks” are made by altering the game’s .def and script files.
Tutorials are better left to the community…imo
Techniques are more viable and usefull information in the end. If all you do is a bunch of tutorials you stifle your own creativity.
not necessarily, tutorials give you a base to start from. If all you do is tutorials I would agree but tutorials for me have been a huge factor in getting me into modding and giving me confidence to continue.
However, if the community creates well made tutorials, then there is no problem - and this has been the case for many games, and if its the case with QW, then it will be ok. However, there are some games where the documentation seems to be made for people who already know the ins and outs of the engine and because of that, I have not taken an interest in modding for those games (the “source” engine is kinda like that to me). Thats why tutorials are helpful, they don’t just say to do something, they show you how to do something and then the modder can take it to the next level after they know how the modding process works on a particular game.
First post I made!
What I would like:
-
keep as much in scripts/def/material/sndshd, etc. files as possible. D3 engine was soooooo fun to play with because you didn’t need anything extra.
-
a breakdown of making some game elements that aren’t readily apparent (like mega texture, or how to setup weapons if different from previous D3 titles). I a) don’t see a reason to repeat work that’s already been posted for other D3 engines & b) if you do everything then nobody will bother to learn how to do new stuff (aka experiment). Something like showing how bounding box vs per-poly hit is setup.
-
perhaps combine forces with modwiki.net so that all your data is on your servers AND a private 3rd party server. Again, no reason to have 50 different bookmarks to look things up at.
-
this is way out there, but any chance of a built-in md5 animator? They’re just text files & not sure why no D3 community coder hasn’t made a stand-alone md5 animation tool yet.
Honestly, I don’t see contests, lots of dev one-on-one support, dev tutorials, examples, etc. helping much. People mod because they want to & if nobody is really in to it all the support in the world won’t help. Encouragement is highly encouraged though, but the best people to encourage us is other modders (I don’t see a lot of that). I mean, there’s stuff you guys would of LOVED when modding Q3F but didn’t get & that didn’t stop you.
It would be nice if we could track in the server logs things as detailed as who fired which weapon by GUID.
Also, which team won on which map, how long the map lasted, and how long each player played on each team.
I use this type of info in etpub to statistically model how balanced the maps are and how balanced each weapon is.
For the those who haven’t seen this, check out, for example, etpub’s global stats map fairness ranking page. It’s not pretty, but it’s interesting.
http://stats.etpub.org/maps.php
I would love to apply Bayesian inference to modeling ET:QW.
Although the Xbox 360 will get Herbrich and Graepel’s Trueskill rating system which is quite good. But it doesn’t yet model map/weapon effects.
For more info on that system, see here:
g’day!
I’m not going to read through eleven pages to see if this was suggested, but…
I would be nice to have a built in scripting language for both server-side and client-side. The ability to create client side scripts without breaking open the source code is always a plus and allows for neat little things such as an MP3 player built in, or scripts that track stats, add HUDS, ect.
Naturally, the client-side would be cut off from certain aspects of the engine to prevent cheating via scripting.
Server-side scripting would allow for easy and quick ways of creating variations in game-types or new game-types all together, as well as adding weapons, classes and even modding certain physics aspects and since it’s all server-side, it should have a decent amount of access to the engine.
But, I’m pretty sure that won’t happen, so plenty of access to in-game content for reference, tutorials from devs on various aspects ranging from simple things like adding new weapons or classes to more complex things like adding custom effects (ie terrain morphing), and, hopefully, a built in gui editor / creator for huds and what not. one thing i’ve always hated is making huds.
map tools would be nice to. i tend to solo a lot of projects for things and end up making every aspect of it. if i’m going to have to do everything, i’d like it to be as easy as possible.
edit: OH! and COMMENT the SDK through and through! one thing i hated about the hl2 sdk was the lack of commenting or completely lack descriptive commenting; they’d put something like
//File: Blah.cpp
//Date: 234526
//Purpose:
function blah
and i cried
Hello Forum,
a “reality mod” to improve reality. To correct the generously at:
- average damage (more deadly one shots not only sniper - also pistols)
- bunny hoping (look Americas Army)
- jump from a roof, and somethings like that
- medic functionality (but realistic for 2065)
- reduce walkable maxspeed
Jung - your post is off topic. The point of this thread is to suggest things that mod teams NEED, not for mod teams TO DO.
Here is something that would be really nice for us stats-junkies, and for analyzing the game in a mathematically good way.
Make it easy in the map scripts, etc., to tell which team is defending vs. attacking, and which objectives go with which team.
And make it easy to track who is contributing to those objectives in the game—at least directly.
WET had some pretty messy scripting that sometimes made it hard to tell exactly which was what, even if you have are modding the game code.
Hello Forum,
sorry i only read Mods + suggestions “What do you need?” So i started to post what i need. A little bit unspecific the title.
not sure if this was mentioned or not… but the ability to import later .map types, not just Q4 & D3… but also Q3, Q2, Q1, ET, etc. so those of us who made maps for those games that may want to port or redo that map for your game can do so without much struggle. (this would also be nice for anyone planning on moving or porting over thier mod project from a previous game or engine)
http://iddevnet.com/quake4/LevelEditor_Q4Conversion
probably won’t be very different