Future of trem mapping


#1

I have been always frustrated with the way entites/shaders in trem work.
Now i came up with the idea of making a new package of shaders and entities too along the way for 1.3.0.

What i just realized is that we have 4 possible editor candidates.

  1. netradiant
  2. gtkradiant 1.6.+
  3. .j.a.c.k
  4. Blender (link to exporter plugin/guide plox, made possible by xembie, comment please on status)

Except for gtkradiant 1.6.+, i am aware that maps have been made in each before.
I have not tried any except an old netradiant.
As far as i can see all 4 are maintained.

Now i have no idea if it is possible to create a package/setup for all 4 in one and if that even makes sense.
But i can assume we will need some main editor so we can push in new features for mappers.
Right now netradiant is the defacto standard, but i am quite tired of it handles things sometimes.
I would like to know how others fare compared to it, obviously i am asking here for opinions and concerns from other mappers.
It would also be important imo that the direction of grangerhub chooses one they can rely on to support us.
This is obviously the first and most important step.

Now my idea was that 1.3.0 ships with the gamepack for the editor so that people dont have to hunt it down separately.
Another thing would be to include some documentation such as a updated or even new shader documentation and quite possibly other tutorials, if possible also have them openable from in the editor right away.

As for my ideas concerning shaders and entities, it bothers me the fact that both are mingled up.
Example: lava/slime, even though we have a entity to damage people within it we also have hardcoded lava and slime parameters which only distinguish themselfs by hardcoded damage, sound and obituary values.
In this particular instance the sound and the obituary cannot be changed in the damaging entity, which could easely be implemented.
This is a liability for both the mapper and the game as both need to know them, it also is a confusing idea to have shaders "do" things, exceptions might be non-solid and co and vis hints.
Another problem i have is the fact that entities can be, even if badly at present visualized in the editor, while shaders cannot, you have no real way of telling what a brush does.
This can come in as a real problem for example if you accidentally place a non-solid shader somewhere.
Neither is there a quick way to see what exactly a shader does from within the editor, not to mention creating new ones.
This is only one example, one can find many more.
Now it would be nuts of me to demand realtime display of some shaders such as the flashing and not to mention glowing ones, but some visualization of non-solid and invisible ones would help.
While every mapper worth his salt has learned to work around this and handle it, such behavior should not be considered acceptable in the future, i think non of us forget the nightmares of our first days in radiant, let us spare this fate to the future mappers.
This is why i hinted at editor evaluation first rather than take what we are given.

Lastly bringing up entities more in detail i think many lack functionality that is trivial, for example the func_plat(elevator) has no wait key, this is quite practical yet we dont have that.
Not to mention we dont have a volume key on trigger_speaker, this makes volume control very tricky.
Obviously 1.3.0 will provide new entities and logic either way so its reasonable we update those too.
Not to mention introducing new stuff like movable props and updating other movable things to be more flexible.

I hope that in the future we will also have lua server side support to program entities and map/game logic outside of the maps themselfs but the entities will still need to be in the game code and likewise would a solid modern standard be good.

This is will break new maps on old clients but he to think of this ahead and plan things out.
The exact details are open to change later but its good if theorize on this first.


#2

I've played with GTKRadiant 1.6+, currently, Tremulous is not supported "out of the box", this is something we can and should fix.

I don't think there is really a difference between the files to support games between NetRadiant/GTKRadiant. GTKRadiant simply lacks them IIRC.


#3

I don't think it would. I think the only issue would be that at least the new changes wouldn't work on the old QVMs, and at worst the map wouldn't work on old QVMs. But old clients should be able to work with the changes you have suggested, on new QVMs, except if client side Lua is used, that would only work with new clients.


#4

Just for reference since I read that topic, GtkRadiant 1.6 is nothing more than a rebranded 1.4 one (so it lacks all the 1.5 changes and is painfully hardcoded everywhere as 1.4 is).

In fact, in term of implementation:
GtkRadiant 1.4 < GtkRadiant 1.6 < GtkRadiant 1.5 < NetRadiant < DarkRadiant

GtkRadiant 1.6 just being GtkRadiant 1.4 maintained, and NetRadiant being GtkRadiant 1.5 maintained.
So game pack for GtkRadiant 1.4 must work out of the box in GtkRadiant 1.6 (no need to use obsolete 1.4 build), and game pack for GtkRadiant 1.5 must work out of the box in NetRadiant. DarkRadiant is not usable for Trem mapping (some q3 related work was done but is highly incomplete), I just put it there as “the most evolved radiant out there” reference.


#5

@illwieckz
Thanks for pointing this out to me.

I have had a brief chance to try darkradiant and uforadiant(yeah dont ask).

From what i saw darkradiant uses a slightly different .map format even when exported as q3.
Netradiant seems to be able to open these files, but i didnt check if q3map2 swallows them too.
Not sure what darkradiant has to offer yet, but i think its a possiblity that should be checked.

Uforadiant seems to use the q3 format out of the box, but it is no game generic, though im sure it could be updated easily.
Whetever that is worthwhile is another question.

I have also tried trenchbroom, while it is able to open q3 map files out of the box, lack of reading textures from archives is not supported yet.
I did however manage to get confirmation from the main developer that q3 support is on the todo list.
Trenchbroom seems to be a very promising editor.

There is also aaradiant and wolfradiant, but i never tried these.

Compiling the newest version of netradiant from gitlab didnt work for me, so i can only compare to a quite old version.

I would also like once again to ask all mappers when they have some time to spare to maybe try alternative editors and tell us what some of the advantages and disadvantages are for you.

I believe in the future tremulous should ship with the editor, netradiant being the defacto default currently.
But this doesnt mean we cant ship with configs for other editors too.


#6

I am using GtkRadiant 1.5 to make an escape map :sunglasses:


#7

For some time now i have been keeping an eye on trenchbroom, a promising new level editor for quake.
It doesnt have q3 support just yet, but it can open trem maps, it might not be so useful yet, but base level geometry is nice to edit with it.

I still havent tried much with darkdradiant and ufo radiant.


#8

2 posts were split to a new topic: Setting up a Map Editor for Tremulous Mapping