Request feature prefabs system in/out

[IZaRTaX]

I don't know if it possible to do that

is a very useful system that cod radiant use, you can place your prefab in your map go into it make your modifications and save them without re export your prefabs again

Here's an example from my old map:

 

Another example, select the prefab go into it

 

Make modifications save them, leave the prefab and it'll be updated in your map

 

[Amadeus]

I second this. I find myself manipulating prefabs a lot, and this seems like it would definitely speed up my workflow

[Springheel]

If you're talking about having prefabs auto-update in your map, what happens when someone changes it in a future release in a way you don't approve?

 

 

[Amadeus]

No, that's not what I'm trying to say. When I made AGN I found myself changing/tweaking a lot of core prefabs to fit the needs of my map. A feature like this would be nice so that it clears away all the clutter on the screen and I can just focus on reworking that prefab until it becomes what I need it to be for my particular map.

[Springheel]

I guess I'm not clear on what "a feature like this" refers to.  If you just want to see the prefab and nothing else, can't that be accomplished by putting the prefab on a separate layer?

 

 

[peter_spy]

Also, if that's the case, a small hint:

H – hide selected

Shift+H – unhide all

Ctrl+Shift+H – hide everything but selected

[Amadeus]

6 minutes ago, Springheel said:

I guess I'm not clear on what "a feature like this" refers to.  If you just want to see the prefab and nothing else, can't that be accomplished by putting the prefab on a separate layer?

It totally can. I'm personally bad at remembering to use layers and need to get better at using them throughout the process. I just thought this was a neat idea, but now I see it might be a bit unnecessary.

3 minutes ago, peter_spy said:

Also, if that's the case, a small hint:

H – hide selected

Shift+H – unhide all

Ctrl+Shift+H – hide everything but selected

Ha, the one saving grace that I did use a lot. But this convo has made me realize that I just need to get better at making layers and using that feature throughout the process so I don't have to keep selecting every little thing to hide everything but selected

[Dragofer]

You can quickly isolate your current selection by pressing I (invert selection = select everything else) + H (hide).

Combined with grouping, that seems quite similar (even if much simpler) to what's been demonstrated in the OP.

[Amadeus]

4 minutes ago, Dragofer said:

You can quickly isolate your current selection by pressing I (invert selection = select everything else) + H (hide).

Oh, I didn't know that. So it seems that this combined with everything else already in DR would make this feature redundant. There's always something new to learn with DR I guess

[IZaRTaX]

Also I mean if you have like 50 same prefabs in the map then you need to do some modification it will update all your prefabs like this example

 

 

[Skaruts]

On 1/21/2021 at 12:52 PM, IZaRTaX said:

Also I mean if you have like 50 same prefabs in the map then you need to do some modification it will update all your prefabs like this example

I like this idea, actually. Every time I make a prefab, I use it all over the place, only to then realize I did something wrong and now I have to fix it in like 10 or 20 places, or not fix it at all. Would be nice to be able to change once, and see it reflected everywhere, even across different maps.

Currently, DR doesn't recognize prefabs as anything other than a regular group of objects. In other words, it's only a prefab while its in the .pfb file. Once you place it in the map, then it's only a bunch of objects like any other bunch.

This requires that DR would recognize a prefab as an actual object. But it would have the potential to make building certain things much easier.

 

 

On 1/20/2021 at 2:59 PM, Springheel said:

If you're talking about having prefabs auto-update in your map, what happens when someone changes it in a future release in a way you don't approve?

That's indeed a concern, though.

Maybe changing the original prefab could have no effect on anything. Perhaps the prefab, once placed in the map, could be stripped of any relation to the prefab in the file. And so, copying it around the map would still make it so changing one copy would affect all others, but those changes wouldn't carry across maps, and changing the original one wouldn't affect your map at all. (Though this would mean that placing that prefab in the map again, from the file, would make it belong to a new set of copies with no relation to the existing set).

And in that case, DR could then provide an interface for replacing a prefab with another, and you could use that to update the ones in the map, where replacing one copy would replace all others of the same set. This would give the user complete control over when and how updated prefabs should affect their map.

Edited August 13, 2022 by Skaruts

[Obsttorte]

You can export complex geometry built in DR as model and use that instead. If the setup contains interactive entities like doors etc. you can export them seperately and create custom entities with those stuff def_attached. So per se this stuff is already possible without having to possibly break an existing funtionality.

What you are talking about is to allow referencing stuff in other map files (that's what the prefab files actually are), which would require both changes in the DR code as well as in TDM. All for the sake of achieving something that is, as said, already possible, only in a slightly more convenient way.

[Skaruts]

2 hours ago, Obsttorte said:

What you are talking about is to allow referencing stuff in other map files

Well, not really. The way I was suggesting it, the map wouldn't reference anything from the file, or else you'd have the issue Springheel was talking about. The map would have to keep track of the prefab only internally. The details of the implementation, I don't know. But I don't think TDM would require any changes. My assumption is that these objects could exist in the map in some similar way to layers, selection sets, etc, and I presume TDM doesn't even know they exist.

But perhaps you're right. I'll have to look into how to create custom entities.

The only problem I see with exporting as models is that it requires you to then manually edit files to support skins on it.

[Obsttorte]

11 hours ago, Skaruts said:

Well, not really. The way I was suggesting it, the map wouldn't reference anything from the file, or else you'd have the issue Springheel was talking about.

That's what I am saying.

11 hours ago, Skaruts said:

The details of the implementation, I don't know. But I don't think TDM would require any changes.

If you don't know the details of the implementation then the assumption of no necessity for code changes is pure speculation, wouldn't you agree?!

11 hours ago, Skaruts said:

The only problem I see with exporting as models is that it requires you to then manually edit files to support skins on it.

You have to create the skin files per hand anyways. What does this has to do with the prefab system?

[Skaruts]

On 8/14/2022 at 8:29 AM, Obsttorte said:

If you don't know the details of the implementation then the assumption of no necessity for code changes is pure speculation, wouldn't you agree?!

Well, that's why I said "I don't think it requires...", and not "it doesn't require...". But I explained my reasoning. I'm only discussing an idea here.

On 8/14/2022 at 8:29 AM, Obsttorte said:

You have to create the skin files per hand anyways. What does this has to do with the prefab system?

With a prefab made of brushes you don't have to create skins, you can just replace textures as you please, and the prefab can exist in a single file.

[Obsttorte]

6 hours ago, Skaruts said:

With a prefab made of brushes you don't have to create skins, you can just replace textures as you please, and the prefab can exist in a single file.

The reason why you have to skin models is because they are refering to external files. You can only retexture stuff inside DR if it is made out of brushes and patches, so stored internally (inside the map file).

If you use a model several times in the same mission, all of them are references to the same external file which only has to be loaded once and which the engine recognizes to be the same.

If you use something build out of brushes and patches, then having several copies of them in the same mission will be dealt as different entities, both when loading the map as well as when dealing with it during rendering.

The idea behind prefabs out of brushes and patches is that some rather complex setup used in one mission gets reused in another mission, but preferable once. Stuff that gets placed several times in mission should consist out of models. Those setups can be stored as prefabs, too, but then you cannot retexture them.

The fact that mappers use prefabs made out of brushes and patches is mainly a bad habit, not something desireable. It's caused by them relying on coders improving performance and avoiding minor extra work like writing skin files (which takes less then a minute).

 

[Obsttorte]

6 hours ago, Skaruts said:

Well, that's why I said "I don't think it requires...", and not "it doesn't require...". But I explained my reasoning. I'm only discussing an idea here.

The point wasn't that you made an assumption, you are of course free to do this. The point was that you made an assumption based on ... nothing. For someone who might be in the position to judge on whether this is possible and how, this reads as "I have no idea but common guys, this can't be hard".

Even an assumption should be based on at least a minor amount of knowledge.

[Skaruts]

 

 

8 hours ago, Obsttorte said:

The point wasn't that you made an assumption, you are of course free to do this. The point was that you made an assumption based on ... nothing. For someone who might be in the position to judge on whether this is possible and how, this reads as "I have no idea but common guys, this can't be hard".

Even an assumption should be based on at least a minor amount of knowledge.

To be clear, my assumption was based on there already being several different object grouping systems in place, and my conception of this new potential kind of prefab being just another kind of grouping system, and so, even if I don't know how it would be implemented (because I'd have to look at DR's code to know more), I'm safe to assume that it is in principle possible. Of course, it might not be possible given further details, but that's where I was trying to get us to.

Anyway, thanks for your other reply. That cleared things up a lot.