The server browser GUI script can query server info (paraphrased):
onPropertyChanged "gui.serverID" {
if( sdnet.queryServerInfo( serverID, serverSource, "si_teamDamage" ) == true ) {
serverFeatures.addIcon( "friendlyFire" );
}
}
so it’s relatively easy to add your own queries.
The server list is acquired, filtered, and pushed to the GUI from the gamecode, so the server browsing front-end should accessible via the SDK.
The editor has been heavily rewritten (hence the rename to ‘editWorld’.) It should provide a much-improved editing experience to designers.
editWorld has 4 camera modes as of now:
We use TortoiseSVN for our code source and media assets. Engine/tool SVN integration has been on my “it’d be nice” list for a while, but it’s low priority given that TortoiseSVN does such a solid job.
A visual GUI editor was started for the new GUI system, but was discontinued when it was found to interrupt the workflow once a designer was out of the “blockout” stage (a relatively short period of time.) The GUI system has evolved substantially since that editor was started, and I have some ideas for a simple blockout editor, but that’s off in the mists of The Future.
All of the major GUIs in ETQW were created with UltraEdit, ETQW in windowed mode, and a key bound to “reloadDecls.”
This is supported. Doom3’s editor also supported this (and I’m assuming Quake4’s did as well.) It was enabled by pressing F9 while in RenderMode, if I recall correctly.
Maybe for level design (and model management IMO), but for a lot else, it’s pretty painful. When I was doing work for GUIs under UT2k4, I had to edit some files inside UnrealEd (package assets like textures and fonts), change whatever I wanted in code, close UnrealEd (or else it wouldn’t compile my code), compile, run the game, get to the point where I wanted to test the GUI, test it, close the game, and do it all again. It was very frustrating and changing assets like fonts would be a very lengthy process with a lot of compiling and open/closing UnrealEd and the game.
In D3++ I could keep the game and my GUI opened on separate windows, edit the GUI on a text editor, alt+tab, then reloadGUIs. No recompiles or engine reloads necessary. Absurdly faster and easier to debug visual stuff.
That’s not to say D3’s GUI system is better, as its scripting code is pretty limited compared to UT2k4’s one (that relies on compiled game code) while being better in others etc. My point is that simply because UnrealEd exists it doesn’t make the support much better. Working with gui fonts there or managing packages was also a nightmare. UnrealEd is good, but not the best solution, IMO. Just different.
A newb friendly tool for making custom players easy.
Traditionally we get some kinda level editor to make level editing way easy and as a result folks make tons of custom maps. In comparison I havent seen nearly as many custom player models and wondered if there might be some new tool to make the aspect of creating new players easier.
Maybe a default player with default animations you can customize extensively along with some type of plugin to make importing your own replacement models easier, maybe a player generator.
A couple plugins to import models from 3ds and maya
---- and my older request
Download filter: a few new formats much like a pk4 but with new names so players can distinguish what they want to download. Ex.
GPA – Player archive for skins and player models
GMA – Map archive for custom maps and all the other greatness extra spiffy greatness we include
GSA – Sound archive for custom sound packs
GWA – Weapons archive for custom weapon mods, models, skins
GCA – Custom archive for light server modifications like custom HUD’s and gui’s
<3
oh my god, I’m going to love this game, this seems to get the best game for modding ever!
engine side svn support… I wonder why someone would want so many gimmicks… I think you should not add features to the engine which are already available in more comfortable forms…
tortoisesvn is great. same with buildin script editor… there are plenty syntax highlighting editors out there, which are way better, than anything a game company could create from scratch in a short time (no offense).
New _buttons are now defined in gamecode, ie, the SDK side of things.
A preprocessor has been added for most declaration types (materials, entityDefs, guis, string maps, etc.)
You can use #define, #include, #ifdef/#elseif/#endif blocks. For defining templates you use:
$template templateName( Parameters...)
// Stuff
$endtemplate
and then use “templateName( Parms )” inline whereever you need it.
Dependencies are tracked between declarations and included files, so changes to them are properly picked up by reloadDecls.
The major GUIs all use this system extensively; a large UI framework has been
built up over the course of the project using the $template system.
tool source- sounds like the editors are really nice and farther along than d3’s… but with the importance/complexity of tools these days, it’d be nice to mod them as well. Giving sdk access to allow linux/osx programmers to implement in-game editors for their platform would be nice.
expose the gui system?
node based material editor?
better character sdk- q4’s was ok, but wasn’t as well documented as it could have been- just a short tutorial on the rig would have been great.
a little more access to the renderer? i know this is super-duper off limits, but if there’s any way to allow people to extend it without giving away any trade secrets would be good.
I’ve always had a feeling that there were some custom scripts and whatnot lying around for pipeline stuff that didn’t make it into the sdk for d3/q4- stuff like seneca’s modo scripts. It’d be nice to have that sort of stuff to, even if it’s not part of the official sdk, maybe links from the wiki?
umm… a d3 style leak? joke, joke- but as long as mods take these days, some sort of detailed materials to give mod devs a head start would be nice.
tool source
Probably not, but I plan to expose a rather extensive interface to editWorld (probably as a patch later on.) Adding in-game editors should be supported out of the box.
expose the gui system?
The GUI system has been rewritten, and is now entirely within the game (SDK) code.
node based material editor?
Any effect more complex than simple blends/adds is usually created using a vertex or fragment program. You can use one of the available tools like RenderMonkey or FX Composer to get a feel for writing them; they’re always written by programmers here, hence no need for an internal tool.
better character sdk- q4’s was ok, but wasn’t as well documented as it could have been- just a short tutorial on the rig would have been great.
I’ve always had a feeling that there were some custom scripts and whatnot lying around for pipeline stuff…
The art team are already thinking of useful things like this to include.
a little more access to the renderer?
We use text files called “renderPrograms” to handle quite a few features in the renderer. RR2DO2 can probably talk about them a bit more in-depth.
…as long as mods take these days, some sort of detailed materials to give mod devs a head start would be nice.
We’re certainly glad to help everyone out. 
great to hear about the tool/gui exposure. have you guys extended the sort of stuff that was in gameEdit.h, or completely reworked it?
interesting to hear that the gui’s have been rewritten- not that d3’s were bad, but hard to extend in meaningful ways. Any info on this? does it use the same markup/scripting system, or a new/standard one? Is there any capacity for direct drawing to the canvas? are dynamic windowdefs possible? (d3 did not allow for runtime instantiation of new windowdefs)
any changes to the way articulated figures are done? this gave people nightmares- not sure if it’s practical, but it would be awesome to do constraint definition in maya and then get a .af file exported along with an md5.
any more info on these renderPrograms would be great. I’ve been doing some work in d3 that involves heavily dynamic sky rendering, and it’s felt really hacky.
art stuff… some tutorials and example files for getting people’s head wrapped around scale issues would be good.
Character SDK stuff is really important- there’s awesome work being done at places like polycount, but with 2 or 3 exceptions, they never make it in-game. They usually get as far as a model w/textures, but never rig/weight. Those guys live and breathe contests, btw…
One way to help them along- there’s some new stuff in maya related to skin weight transfering. It’d be really nice to have a generic base mesh fit to the character rig with good skin weighting. All someone would have to do would be to position their character model over the rig, then maybe run a mel script to bind it and transfer the weights from the base mesh and have a player replacement 90% there.
The stuff raven gave out like the parts scrapyard was awesome- if you guys care to part with some of your zbrush/mudbox brushes that would be great. I assume something like this would be necessary for megagen anyway.
[/quote]
a game to actually mod would be helpful guys…
i’m hearing early April now in the US?
[smacks self across face - “PATIENCE! PATIENCE!”]
as i’m not primarily a programmer, but a grafixx person, i’d certainly appreciate any gui-based editors, and a better in-program help reference capability would rule.
i toyed with NeverWinter Nights a few years back and their ‘dev-tools’ were incredibly easy to use almost immediately. this was in my ‘pre-FPS doug’ days.
i know i’m kinda comparing apples to oranges here, but the easier it is for gamers/modders to alter things to their creative taste, the more there will be coming up with great content!
peace - graficgod
I have not read anyones posts - so if I duplicate anything I apoligize in advance but an untampered perspective is what you are asking for. I am not asking for this as a mod team but just as a developer. Be warned, call me lazy I would rather spend 5 hours of programming time to save a lifetime of human errors & ease for everyone.
Now to make this more usefull for mod teams make this tool be able to be web-hosted with access rights so teams can calaborate and distrobute on the fly.
Real Time - No compile times, script execution on the fly plug and play as soon as anything is dropped. In other words the mapping editor should be in game with the ability to test anything you bring into the enviroment in the editor. Able to see what your lighting changes as you make them and so on. To hop in and play the game in the editor to test and cut down on development time. You get the concept expound from there.
All tools needed included - No need for external tools such as Microsoft Visual Studio, 3D Studio Max, Maya, Fruit loops or other sound creation files. This can cripple a Mod Team coming up with funding and so on.
Everything Explained - A very comprehensive website with documentation & prefabs of every option the engine currently has built in & explianed. So if you are using an entity or function or anything it has examples of each and they are pre-built for easy drag and drop for tweaking. Again cutting down on development time.
Intergration - Every tool operates out of the same basic premise of ingame no 3rd party creation what so ever. Not working with a terrain generator for example and then porting it in just to find out it does not look the way you want and having to leave the ingame tools to start working on it again and repeating the process. Again cutting down on development time.
Optimization - Tools that debug and optimize with ease. So many developers really do not understand optimization when it comes to modeling, mapping & coding. If we could create tools to go through and recognize what can be done to clean up creation ooh it makes me drool. So developers can focus on creation and not optimization of use.
Editor for items not included - for functions or entities, This ussually requires a programmer and not a scripter to build and insert them into the engine. It would be superior to have the tools for creating new entities, functions or code that does not exist. So creating a an action that has not been built currently into the engine with ease. Making the engine as robust as it possibly can be.
8 ) Cut down on Dev Time in General - Anything that would make creating a mod or additional content in half. Instead of taking 2 years to make a mod, it could take 1 yr. Many teams do this as a passion and when development takes so long its very difficult to achieve without a paying program.
Lastly 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. Granted it means up front programming time but the time saved in the end is priceless to so many.
Thank you for reading and sorry if it is not presented with a proper gramatical format that is acceptable. I do have a history of bad writing. But there you have it enjoy :evil:
No need for external tools such as Microsoft Visual Studio, 3D Studio Max, Maya, Fruit loops or other sound creation files.
That’s completely unrealistic.
OSIAS, I think all your ideas are quite utopian. Of course, your ideas would be nice if they would be implemented, but I can’t imagine how they can be realised before or shortly after the game’s launch.
I thought I’d better warn.
agreed, thats nonsense… mods don’t need all these gimmicks.
A good mod team can do easily without… if a mod team really needs such things, then they probably wont live for a long time, due to the lack of experience/knowledge.