Jump to content
The Dark Mod Forums

Prefab Insertion


Recommended Posts

Ok, if I'm lucky, I've found an easy solution to this. I'm uploading a new build right now, so please test this once again. The incrementing should work for both "target", "name" and "bind" keys now.

 

The above (user error) case with selecting a single element from a "bound" structure and duplicating it is of course not covered by this, but duplicating whole prefabs should be ok.

Link to comment
Share on other sites

I like the idea of Insert Prefab option in right click menu. I haven't tried it yet, but are there any chances to have them sorted in folder tree structure similar to the models' one (plus some extra, probably)? No doubts the list will be pretty long with time... Same applies also to entity list, actually...

Link to comment
Share on other sites

The entity list could already be arranged in a tree, it's just a matter of adding the according "editor_displayFolder" key to the .def files. Perhaps I'll do this myself soon, if no one else is up to it.

 

As for the prefabs: those are files, this means they have to be parsed through and arranged in a list, although no meta-information is available. This could possibly be saved in the worldspawn node. Not a high priority feature, but if it becomes pressing, the issue is definitely solveable.

Link to comment
Share on other sites

As for the prefabs: those are files, this means they have to be parsed through and arranged in a list, although no meta-information is available. This could possibly be saved in the worldspawn node. Not a high priority feature, but if it becomes pressing, the issue is definitely solveable.

 

Walking the prefab directory and building a tree of prefabs that can be displayed alongside the entity list is not difficult, although it would require probably a new PrefabManager module to maintain the list. However in my opinion it would be better to address the cause of needing so many prefabs in the first place, such as by building more entity primitives in the SDK to function as doors, buttons etc, rather than hacking ever-more complex functionality into the editor in order to make a group of objects behave like a single entity.

 

My view of prefabs is that they should be used for things that are conceptually a pre-defined group of entities, such as a house or clump of trees, rather than using them to represent things which should actually be a single entity.

Link to comment
Share on other sites

I don't think that the SDK is a good place for this. After all, the SDK is like a lego block. You should use it's funciton to build stuff with it. The concern with rotations is valid, but then the question is wether it can be adressed instead of hacking it into the SDK. Also I'm not sure what a button would be in the SDK?

 

Don't know if that helps, but if we need functionality that overlaps in the SDK with the ditor, we can provide functions, and the editor can then load the game DLL. Don't know how usefull that would be right now though, but maybe it's worth thinking about. Id did basically the same with some things, as there is an editor interface in some classes.

Gerhard

Link to comment
Share on other sites

However in my opinion it would be better to address the cause of needing so many prefabs in the first place, such as by building more entity primitives in the SDK to function as doors, buttons etc, rather than hacking ever-more complex functionality into the editor in order to make a group of objects behave like a single entity.

There's a limit to how much things can be integrated in the SDK without massively changing the inheritence structure so that lights can have rigid body physics and other stuff like that, which might also lead to unanticipated problems.

 

It's quite possible to do things like doors that auto-create the handle on spawn, but I believe the handle would not show up in the editor. We should probably test this with a simple case of an entity that spawns something else at spawn, and see if it shows up in the editor. It's a question of whether the editor calls Spawn() on the stuff you place. I seem to remmeber looking at our log file and seeing some logs from Spawn() when I placed something in the editor, but could be wrong. Of course then it wouldn't work in DR.

 

In some respects prefabs are more userfriendly: The mapper can see it all in the editor (so they don't have to worry about an auto-spawning door handle spawning in the same space as something else they place in front of the door, and they'll know exactly what shadows will be created by the objects). I would argue that modifying stuff from the default settings is easier with prefabs. It's easier to to select one entity from a prefab and change it than to go into a def file for some massively integrated object, find the key/vals describing the component they want, change that and make a new entityDef for their modified object. As I recall, that's part of why we decided to have "flame" entities separate from torch models, so it would be easy for the mapper to mix and match light housings and flames.

Link to comment
Share on other sites

It's quite possible to do things like doors that auto-create the handle on spawn, but I believe the handle would not show up in the editor. We should probably test this with a simple case of an entity that spawns something else at spawn, and see if it shows up in the editor. It's a question of whether the editor calls Spawn() on the stuff you place. I seem to remmeber looking at our log file and seeing some logs from Spawn() when I placed something in the editor, but could be wrong. Of course then it wouldn't work in DR.

 

Such functionality could probably be added, assuming it wasn't too complex. I wouldn't want to write a whole-sale script interpreter, but just spawning the child entities might be possible.

 

In some respects prefabs are more userfriendly: The mapper can see it all in the editor (so they don't have to worry about an auto-spawning door handle spawning in the same space as something else they place in front of the door, and they'll know exactly what shadows will be created by the objects). I would argue that modifying stuff from the default settings is easier with prefabs. It's easier to to select one entity from a prefab and change it than to go into a def file for some massively integrated object, find the key/vals describing the component they want, change that and make a new entityDef for their modified object. As I recall, that's part of why we decided to have "flame" entities separate from torch models, so it would be easy for the mapper to mix and match light housings and flames.

 

Yeah, the problem is though that the mapper isn't just able to select the individual components of a prefab, he has no choice. This is likely to lead to confusion because the mapper might assume that his prefab torch entity is a single object and then wonder why the flame gets left behind when he moves the torch somewhere different.

Link to comment
Share on other sites

Yeah, the problem is though that the mapper isn't just able to select the individual components of a prefab, he has no choice. This is likely to lead to confusion because the mapper might assume that his prefab torch entity is a single object and then wonder why the flame gets left behind when he moves the torch somewhere different.

That problem (and many more...) would be solved if there was some grouping system, but I suppose, that's too complicated for now...

Link to comment
Share on other sites

Ok, if I'm lucky, I've found an easy solution to this. I'm uploading a new build right now, so please test this once again. The incrementing should work for both "target", "name" and "bind" keys now.

I got an immediate crash on launch, until I agreed to wipe out my user config again. :(

 

The good (actually great) news is, I've successfully duplicated and prefabbed the lit candle. Ladies and gentlemen, adding a lit candle (or presumably any prefab?) to a TDM map just became as easy as a right click followed by insert prefab. :)

 

No problems found yet; will of course report on any I might come across.

Link to comment
Share on other sites

Yeah, the problem is though that the mapper isn't just able to select the individual components of a prefab, he has no choice. This is likely to lead to confusion because the mapper might assume that his prefab torch entity is a single object and then wonder why the flame gets left behind when he moves the torch somewhere different.

 

The best solution woul dbe to define a prefab structure, that defines all kind of elements, and the mapper gets a dialog where he can choose what he wants. For a door/button/window, this would be the frame, the handle, rotation parameters and such, and then he would also be able to preview it in real time, if the rotation is correct.

Gerhard

Link to comment
Share on other sites

That sounds like a solution that is awfully complicated to implement. We have exactly one camera window in DarkRadiant, I don't know how hard it would be to allow for multiple camviews, but I suspect that this requires some serious redesign. And then we'd have to implement the controls like rotation and still the mapper wouldn't know how it would look like when embedded in his map. Additionally, the prefab wouldn't easily be transformed afterwards, after the dialog is closed. This would open a can of worms, IMO. With models that is easy, as they are monolithic, but prefabs aren't.

 

(Anyway, I personally think that the whole prefab stuff is overestimated. Not that I want to make map editing more complicated than it has to be, but mappers aren't stupid after all.)

Link to comment
Share on other sites

You don't need a seperate preview window for that. You can just dump it somewhere in the map, or the mapper can place it, and then the camera is positioned accordingly. So the only "controls" would be the parameter for orientation and rotation, but you already got them from the other dialog.

 

As for your comment about mappers, I agree. I'm not sure wether we should really go out of our way to create to much right now. It might help the occasional mapper a lot, but for the one who really want to make good maps, I'm not sure that they would use such features extensively. And if there is such a demand it can also be added later on.

Gerhard

Link to comment
Share on other sites

Maybe we're not talking about the same thing here, but functional 'groups' for the handling of prefabs (or other complex multi-object things a mapper may wish to define as such) is not really a luxury, so much as a necessity. Once all objects of a prefab are treated as a functional group, duplication, placement, rotation (around a shared origin) are all the same as with, for example, a func_static. On the other hand, not having this functionality means that every time you want to duplicate or move a prefab, you must select every object within it, no matter how big or complex it might be (the very nature of a prefab suggests they will be big and complex, else why prefab it?), rotating it would be troublesome as there is no shared origin, and more problems I'm sure.

 

Anyway, just making the point of the importance of functional grouping before it's squashed, and that it's definitely not hand holding or a luxury. It's vital to this type of editing, and since we've already determined that items like TDM torches, candles, and surely a lot more to come must be prefabs and not some single complex entity, we're pretty much roped into needing this anyway. They exist in DoomEd for some reason - I'd wager this is a big part of it.

 

Edit: Just confirmed, it appears func_groups work in both DoomEd and DR (not fully tested, but it's there). Now, if the functionality could be extended to a new type (so not to remove func_groups), a func_whatever, and to include any type of object instead of just brushes, we'd be set. Func_groups already are selected as a whole, have a unified origin that can be moved, rotated around, etc. In other words, we're almost there. One thought: there'd have to be new functionality (like revert to world) to separate objects from a func_whatever, without destroying them or turning them to worldspawn, but instead, just freeing them and keeping their entity type intact (obviously - just thinking aloud).

Link to comment
Share on other sites

All the func_* entities can only contain primitives as children, which limits their use as prefab containers. Problem is that entities are not allowed to have child entities (well, technically they could be, but DarkRadiant's scenegraph doesn't support this and the map file format neither). All entities have to be top-level.

A "parent" key could possibly be saved into the map file which is parsed upon loading to restore the grouping, but making the transformations work homogeneously for the whole group might be quite a task.

 

The least we can do is to agree on a priority for such a feature. Is this needed for DR 1.0?

Link to comment
Share on other sites

It's vital to this type of editing, and since we've already determined that items like TDM torches, candles, and surely a lot more to come must be prefabs and not some single complex entity, we're pretty much roped into needing this anyway. They exist in DoomEd for some reason - I'd wager this is a big part of it.

 

That's the part that I have been recently questioning -- prefabs may be the only current option, but from a design point of view they are a hack. A torch is conceptually a single entity and therefore ideally it should exist as a single entity in the editor and in game.

 

Whether we add support for multi-model entities in the SDK or improve the prefab handling in DR, a non-trivial amount of work is still going to be needed either way. Given that greebo is starting to get involved with the SDK now, and it probably would have been him that implements such functionality in DR anyway, it would make sense to at least have a look at inserting the functionality in the "correct" place.

Link to comment
Share on other sites

I dunno about adding multi-model-per-entity support in the SDK. AFAIK we don't have any level of control over the renderer beyond controlling the camera position and telling it "hey, do some rendering now", and you'd have to modify physics-related code in so many places that it doesn't bear thinking about. So I don't think there's any choice; it has to be implemented using multiple entities at some level.

 

Given that you need multiple entities to achieve the prefab-like effect, adding a "parent" key like greebo suggests sounds like a decent compromise to me; while each entity would still be "top-level" from D3's point of view, and all objects would be saved using world coordinates, DR would convert world coordinates to parent coordinates whenever it loaded a child entity (and vice versa when saving). Updating the position/rotation of an entity would then also cause its children to move. So then you'd have a "parent" entity in each prefab (possibly an invisible object, but it could just as easily be the "main part" of the prefab, e.g. the torch bracket or the door itself), which you would move/rotate in order to move/rotate the whole prefab.

 

I guess you could also mirror this effort in D3 so that it has a similar concept of "child" entities. Then you could have in-game movements of the parent entity also affecting the children. But I suspect the behaviour would be identical to the existing "bind" functionality in D3, in that collisions would fail to work correctly upon the child entities. This could be a very bad thing; you wouldn't be able to have arrows colliding properly with door handles, for example, and it could have worse consequences for other as-yet-unmade prefabs. (If you did want that effect, you could achieve it simply by automatically binding whenever a "parent" key is present, so the effort required would be small.)

 

Either way, it needs to be implemented in DR at the very least.

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to comment
Share on other sites

I realize that an entity can probably only be one thing at a time, so I'm not trying to suggest that something be a light and a func_group. Rather, and since func_groups already exist in both editor for brushes, I'm talking about some DR metadata as a mapping tool and nothing more, which uses much of the same logic as func_groups (for selection, unified origin, rotation, etc).

 

If it's a complicated task, of course no one can say it must go in now, but it's undeniably important (ultimately) for the use of prefabs (at least). Imagine if every time Dram needed to select his railing func_statics, he had to point and click or try to area select every single part of them (hundreds). It's like if right now, clicking on a func_door, func_static, or func_* didn't select or unify the origin of the whole thing - it'd be a real bitch to work with. Not the end of the world, but a major pain and time waster.

 

I don't know the ins-and-outs of what can be put into maps that the compiler, game, and DoomEd will ignore, but if it really is as simple as giving them a parent (or DRParent if parent is taken?) field that the user can manually assign (or with the assistance of a dialog), that would be great. When a child is selected, any member of that family is selected. When selected, a shared origin (just like func_*) is calculated in realtime (don't know how you'd store it, for the sake of origin rotations).

 

I tried the existing(?) parent function last night with hope, but it didn't seem to do anything. I was pleased to see how well func_groups (for brushes) work though - learn something new every day.

Link to comment
Share on other sites

I suppose it could just be "relative" instead, sure, but the rotation (as you mentioned) could be important in some cases. In the editor, a shared origin is needed for rotation at all of course, while an adjustable origin is only desired for more friendly rotation. In the game, if the whole prefab (etc) needed to rotate or hinge around such an origin, where ever it may lie, it'd need to be defined somewhere in the map data, as opposed to the version in the editor that can be forgotten/not saved. I guess the parent would hold that origin? I don't know. How else would such a position be stored?

Link to comment
Share on other sites

So there's two different things: Rotation in the editor, for placement, and rotation with movers in the game. If you actually want stuff to rotate together in the game, that's what the "bind" keyword is for. Just bind everything to a mover, then when the mover entity rotates about its origin, everything bound to it sticks in the same relative orientation to the bindmaster. That is a parent/child relationship, using the existing bind functionality, and it's distinct from what I was thinking of as grouping things in the editor.

 

When grouping in the editor, I was envisioning it as just a more convenient way of moving around and orienting groups of objects. Maybe you have a set of furniture in one room, and you want to clone it and re-orient it in another room. So you'd temporarily group all that furniture, clone it, translate it, rotate it, then you could ungroup it if you wanted, or leave it, since it wouldn't effect anything else in the game. I don't think this necessarily needs a parent/child, the only reason would be if you wanted it to use an in-editor rotation mode where it rotates around one parent.

 

Picking which ent of the group to rotate around could also be done in the editor rotation functionality. I.e., you click on a group, execute the rotate command and then optionally click on one entity within that group to chose it to rotate around. I think that would be more flexible than setting a permanent parent for a group, but I'm not sure how well it would work with the existing rotation modes.

Link to comment
Share on other sites

As long as the group is permanent (for example with a prefab, and in the editor), then either method is welcome, really. In fact, functionality similar to picking one of a group is already in place for func_* with multiple brushes. Select one selects them all, tab through to pick just one to do something with; that tabbing through could pick the rotation master (or whatever).

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...