Can NRC be used for non-quake/doom based engines? about netradiant-custom HOT 38 OPEN

godot nrc gamepack.zip

from netradiant-custom.

Hey, coming back to this as recently func_godot was released, with improved support for NRC.

While the current user audience is limited, this still is one outstanding thing I'd appreciate; especially now that I'm further into development of my own project.

I'm happy to take a look at the code myself if you have any points to start.

Cheers

from netradiant-custom.

The origin brush is just an extra brush with the common/origin shader applied within the entity for non point entities to specify an origin for things like model or some effect that is part of the entity like model2 key. It's not "special" in idtech2.5 and 3 I don't know about 4. The map compiler discards the brush and inserts the origin. This is expected behavior for mapping with those engines on entities that are brush based and need an origin key for other reasons at a specific point, otherwise it's going to be determined by the brush center and iirc manually specifying it will actually move the entity in runtime but I could be wrong on that latter part.

from netradiant-custom.

Currently only bitflags key per entity is supported and it has fixed name spawnflags.
So far this was enough for supported games.
It would be cool to add support of multiple keys with arbitrary names, but there is no plan to do so quickly.

from netradiant-custom.

It is feasible to use NRC with Godot. You haven't defined your wanted setup details exactly, but e.g. if you run it with Quake3 config, texture browser will list baseq3/textures/*/ loose folders.

from netradiant-custom.

Ah, that did indeed load the textures. I changed basegame="assets" so it sees assets/textures.

But I'm confused, though. I can't tell why Quake3 config sees my textures while my config doesn't.

I may also need a different map file format, though, as Godot's importer plugin (TBLoader) didn't successfully import the map. In TrenchBroom I was using a Standard format, which I presume is Quake1, but I could be wrong. I tried using Quake1 config, but it also doesn't see my textures. I tried adding mapq1 to maptypes in Quake3 config and save the map with quake 1 format, but it didn't work either.

I'm currently in the process of installing another importer plugin (Qodot) to see if it works (and because I prefer it). I don't know how compatible they are with NRC, but I presume the .map formats should be the same across editors.

from netradiant-custom.

Texture browser doesn't list loose folder, when editor is configured for .wads.

Q3 uses Q1 mapformat + 3 extra flags in the end of face definition.
try

  maptypes="mapq1"
  brushtypes="quake"

You also likely want 220 mapformat for more texturing opportunities.

from netradiant-custom.

My config already has those two settings, since I duplicated hl.game to make my own config.

This is my test.game:

<?xml version="1.0"?>
<game
  type="hl"
  index="3"
  name="Test Game"
  enginepath_win32="C:/Sierra/HalfLife/"
  engine_win32="hl.exe"
  basegame="assets"
  default_scale="1.0"
  no_patch="1"
  no_bsp_monitor="1"
  basegamename="Test Game"
  unknowngamename="Custom HL modification"
  show_wads="1"
  archivetypes="wad"
  texturetypes="png"
  modeltypes="obj"
  maptypes="mapq1"
  shaders="quake3"
  entityclass="halflife"
  entityclasstype="fgd"
  entities="quake"
  brushtypes="quake"
  patchtypes="quake3"
/>

I don't know what you mean by 220 mapformat.

from netradiant-custom.

Do you say importer plugin doesn't like .map after this cfg? Example map, exact line it complains?

220:

from netradiant-custom.

I keep having NRC giving me errors at startup whenever I try to customize my game definition.

I found a better alternative to Qodot, but it only supports Q1 maps for now.

So basically what need is a definition that:

• sees loose textures inside game_folder/assets/textures
• exports q1 format
• has entities defined in an fgd file (I already have the fgd file from another Qodot project)

Is there some place where I can read about how to create this? I'm used to the way TrenchBroom does it, which doesn't need a .game file.

from netradiant-custom.

Ooh, that works! Thank you. :)

qbsp isn't generating the same bsp output, though. I created two simple maps exactly the same in trenchbroom and in NRC, but the compilation is slightly different, for some reason.

This is a bit of a problem because the BSP importer is not importing the NRC version. It's causing some internal errors in Godot. It could be a problem with the importer code.

But shouldn't the the BSP be the same? The compilation log is exactly the same until a certain part where the values start being different, and I can't tell why they're different:
https://www.diffchecker.com/HCP0W8hA/

from netradiant-custom.

I don't see how this may be related to editor, make sure you do not do obvious bs.
Sus: WARNING: No entities in empty space -- no filling performed (hull 0)

from netradiant-custom.

Got it working. Tbh I don't know why it wasn't working, but it's working now. 👍

And yea it wasn't anything related to NRC, I just wanted to understand it.

Many thanks for all the help. :)

from netradiant-custom.

Just one unrelated question, is there some way to visually edit the origin of a brush entity that has an origin? Like a gizmo in the 2D or 3D views?

This is useful for making rotating doors/windows, for example, where the origin marks the position of the rotation pivot (the hinges). But it's hard to tell where it is just by editing the spawnarg numbers.

EDIT: actually I just noticed that changing the origin of a brush entity also changes the brush's location in space. I'm used to DarkRadiant where that doesn't happen, so I was assuming NRC had the same behavior.

Is there still some way to have a gizmo for setting some kind of pivot point on a brush entity?

from netradiant-custom.

There is no such thing. In most of supported games origin is set by origin brush.

As soon as you've got it working for Godot, do you approve inclusion of the config in editor releases?

from netradiant-custom.

That's unfortunate. It makes making doors and windows harder...

As soon as you've got it working for Godot, do you approve inclusion of the config in editor releases?

I think so. I may not be the best person to say that, but it seems fine to me.

from netradiant-custom.

See, this is how it works in every editor that I've used before, including TrenchBroom. To make rotating doors, or windows, or levers, or anything that rotates, you use the origin of the entity to define the point of rotation:
https://developer.valvesoftware.com/wiki/Func_door_rotating#Setting_the_Origin

It works the exact same way for The Dark Mod in DarkRadiant. (It's like editing a vertex, in this case.)

In all cases (except TB) there is a visual gizmo that you can manipulate to move the origin of the brush entity. And in all cases, moving the origin does not change the position of the brush.

from netradiant-custom.

This is rather debatable stuff.
Idk why this was changed in NR, OG behavior was 'do nothing', just like in TB.
Can see good qualities of such behavior definitely

• it's exactly what game engine does
• good visual aid, while using bmodel instances
• good visual aid, while doing bsp modding

In DR i couldn't figure out the way to select origin alone; editing it though modifies brushes to keep them unmoved:

so factually origin moves brushes, just like in game, but DR does some cheating on top of this.

from netradiant-custom.

In DR i couldn't figure out the way to select origin alone

Oh, it's a little different. DR handles the origin just like a vertex, so you have to press V for vertex mode. (And to edit the brush vertices you first have to click Select Group Parts and then select the brushes and press V.)

so factually origin moves brushes, just like in game, but DR does some cheating on top of this.

I didn't know that. And, tbh, I think it does make sense that the origin moves the brushes. But it also makes sense that the editor keeps the brushes in place when you move the origin, or moves the origin when you move the entity (which also doesn't happen in NRC currently). The editor has to provide a way to define a rotation point, so that you can make things that rotate. And it has to be the origin because that's what the engine expects. If you make maps for HL, HL2, Q3, etc, the engine will probably expect that too.

In the case of Godot, brush entities have their own origins separate from the origin spawnarg. The only thing that matters is the position of the brush's vertices. (At least with Q1 format. I've never tested others.)

Ultimately, for Godot it wouldn't have to be the origin. Anything will do, as long as:

• it can be edited using some kind of visual gizmo
• it is automatically updated by the editor when you move/rotate the entity

But usually the origin satisfies those requirements.

from netradiant-custom.

But it also makes sense that the editor keeps the brushes in place when you move the origin

It does not for the use cases i mentioned. Also implicit brushes modding is not ultra cool in general. Number of required behaviors and selection modes leads to mess and low intuitivity.

The editor has to provide a way to define a rotation point

It provides, but it's editor agnostic :p Origin brush.
Alternative removed way was to set origin key (not handled by editor at all). In either way it's up to map compiler to move the geometry (-origin) and add origin key (if origin brush).

from netradiant-custom.

It provides, but it's editor agnostic :p Origin brush.

No engine supports that.

from netradiant-custom.

No. This is the way it works for most of supported games.
In the case of Godot there is importer, which can handle origin brush business.

from netradiant-custom.

Can you show me a screenshot or something, of what you mean by "origin brush"?

I'm not sure I properly understand what you're talking about.

from netradiant-custom.

from netradiant-custom.

No, Godot plugins don't support that.

from netradiant-custom.

So the Godot plugins are missing features then? Can't have more brushes in an entity? Origin brush has been a thing since quake 2 iirc. I can't say if it's in q1 as I'm not familiar with that.

from netradiant-custom.

You can have as many brushes as you want in an entity. Don't know why you'd think you can't. That's not the issue. The issue is the origin brush is only recognized as a special brush (or something) by the oldest quake engines, probably due to limitations no other engine has. To all other engines, and to Godot's plugins, the origin brush is just another brush.

Moreover, the reason why engines started using the origin property as rotation pivot, is probably because the origin property is otherwise completely useless for brush entities. So they might as well make it useful for something. The engines aren't missing features. Quake was.

from netradiant-custom.

Of course it's special. If it gets handled differently by having the origin texture, just like you described, then it's a special brush.

It's not special in other engines. It's not treated differently.

This is expected behavior for mapping with those engines

And only with those engines, up to idtech 3 at most. Not with any other engines.

from netradiant-custom.

Of course it's special. If it gets handled differently by having the origin texture, just like you described, then it's a special brush.

It's not special in other engines. It's not treated differently.

This is expected behavior for mapping with those engines

And only with those engines, up to idtech 3 at most. Not with any other engines.

Considering the issue at hand is based around the map compiler for those engines I would say it's expected behavior but if you think the editor can handle manual origin input without shifting the whole entity before compile then I don't see an issue with allowing it on per game config basis. The engines themselves do not care about the origin brush only the map compiler does. The origin brush feature makes the most logical sense IMO. A door pivot point sounds like it should use a different key pair name all together, but that's a game/engine design flaw I guess.

from netradiant-custom.

Mate, the origin is always the rotation point of 3D models in 3D modeling apps, and of objects in games. It's already the way things are done everywhere. The origin is the rotation pivot of everything in existence. That's the whole purpose of the origin. It only makes complete sense that the origin property also gets used as the rotation pivot of brush entities in these editors as well.

Another reason why the origin makes sense, is because the editor can provide a visual gizmo for manipulating it. If you created a hinge property on a door entity, how does the editor know that property is a point that needs a gizmo to manipulate it? As far as I'm aware .fgd and other formats have no way to tell the editor "this property needs a gizmo".

And then, even if you could do that, you'd just be making the origin 100% redundant in brush entities, and the new property wouldn't serve any more purpose than the origin already serves (or could serve). It would be a complete waste of time and effort to implement.

Also, it doesn't even need to be on a per game config basis. I think that would be a waste of time to implement as well. Origin manipulation doesn't interfere in any way with the usage of an origin-brush, so they can co-exist without any issues, and each user can just use whichever they need without any hassle. And even if you set both by mistake or something, your game engine will use the one it needs and ignore the other. Still no issues.

from netradiant-custom.

Hey @Garux can you make a PR for the Godot Game Pack?

Sorry for the tag btw. It just would be nice to have this merged into NRC to use with Godot Engine and Qodot or TBLoader. :)

from netradiant-custom.

@HeadClot sure let's add it. I'm not using repository for gamepacks, so just drop it here and i'll add.
Or is the one i proposed good nuff?

from netradiant-custom.

@HeadClot sure let's add it. I'm not using repository for gamepacks, so just drop it here and i'll add. Or is the one i proposed good nuff?

The one you proposed is good enough. :)

from netradiant-custom.

I don't know if this is the right place to ask this, but does NRC support Unity? I would like to use a level editor similar to Hammer++ in Unity and this looks like I could learn it. I have had luck importing Quake map files in unity before but I would rather use a more direct approach that would allow me to properly place entities for example.

A quick google search lead me to OpenRadiant (https://gamedev.stackexchange.com/questions/78011/gtkradiant-to-unity)
but it seems it's not actively developed and people are reporting issues with it. Will NRC also be able to treat art assets like a modern program and not Quake-specific?

from netradiant-custom.

Is your aim to target the map files or the compiled bsp?

from netradiant-custom.

Which exactly art assets do you want? There is support of dozen model formats via assimp library if you imply this.

from netradiant-custom.

Hi, one small update and request following the recent fixing of spawnflags.

Is it possible to define the spawnflags key name, instead of forcing an override?

For example, in my game's FGD:

@BaseClass color(204 204 204) size(-8 -8 -8, 8 8 8) = appearance[
	appearance_flags(flags) = [
		1 : "Not on Easy" : 0
		2 : "Not on Normal" : 0
		4 : "Not on Hard" : 0
		8 : "Not on Ultra" : 0
	]
]

@BaseClass size(-8 -8 -8, 8 8 8) color(204 204 204) = lock[
	lock_flags(flags) = [
		16 : "Red Lock" : 0
		32 : "Green Lock" : 0
		64 : "Blue Lock" : 0
		128 : "Yellow Lock" : 0
	]
]

results in a series of calls setting the key "spawnflags" on the entity to the value

I do not fully understand how this is currently implemented in NetRadiant, so if this is an unreasonable request, it is OK (especially given this is used for exclusively non-Q3 apps) to pass, just let me know.

from netradiant-custom.

No worries. It's still usable, and in practice there still should be plenty of values - it's a 'nice to have' if you wanted to push NRC support towards more generic games

from netradiant-custom.