Jump to content
The Dark Mod Forums

Prefab Insertion


Recommended Posts

I looked into the prefab insertion stuff and it looks like the most part of this is already functional with the following exceptions:

  • The file saved by DoomEdit has the Version saved as floating point number "Version 2.00" which couldn't be recognised by DarkRadiant. I already fixed that by casting that number onto an int so it passes the version check.
  • The "Import" file chooser dialog currently allows .map and .reg as extensions. There should be a third option with .pfb as extension.
  • I tried to select a .pfb file by typing its name by hand and it looks like the .map gets automatically appended to the filename, which prevents it from loading.

Orbweaver, as the MapFileManager was written by you quite recently, you probably know best where to start to allow the thing selecting and loading .pfb files as well. Do you have time to look into this? If not, I'll happily take a look at it, but you're probably a lot faster as it's your code.

 

Basically, we perhaps need to be able to specify the extensions we want to have listed and whether an extension should be automatically added or not, that should do the trick.

Link to comment
Share on other sites

The MapFileManager is actually pretty basic, all it does at the moment is hold on to the last directory so that the Open and Save dialogs can default to the same place. The file extensions are actually held in a separate module, called GlobalFiletypes() (ifiletypes.h) and are registered by the mapdoom3 module itself in the MapDoom3API() constructor.

 

I'll have a quick look at this, it may be that simply adding another filetype for "*.pfb" into mapdoom3 does the trick.

Link to comment
Share on other sites

Thanks!

 

I'll look into that stuff in the late afternoon, I really ought to work on my thesis now. (I probably should rationalise my DarkRadiant coding time a bit in the next few weeks, but we'll see.)

Link to comment
Share on other sites

Prefab insertion should be done now. There are two new menu commands under the "File" menu, "Load prefab..." and "Save selected as Prefab..". Standard file extension is .pfb of course.

 

func_static childs are handled correctly, as are the entity connections. I tested it with a complex room of lights and connected entities that I inserted twice (to check for name conflicts). I also checked if a DarkRadiant-generated prefab can be inserted in DoomEdit and vice versa. Everything seems to work fine, so I set the issue to "resolved".

 

edit: new build is on FTP in 3 minutes.

Link to comment
Share on other sites

Question about our prefab system. I'm wondering if there is a way to take it up a step from DoomEd's?

 

Perhaps it's not a huge issue, but when I construct a prefab and then try to rotate it...the individual parts don't act as a unit, they rotate around their individual origins and it's really messy. :)

 

I think what I'm looking for, is a way to treat a prefab as a single entity...or manually place an origin that all parts of the prefab would rotate around...rather than spin off on their own origin.

Link to comment
Share on other sites

I have assigned the "Rotation modes" issue to me and I can see that it's annoying. However, I fear that may be hard to resolve given the weirdness of the selection manipulator system. I'll at least have a look at it.

 

I think I know what the cause of the prefab rotation weirdness is. Due to the func_static origin transformation stuff I've been changing recently, I seem to have broken the joined model rotation. Main reason of this problem is that both models and func_statics use the same Doom3Group class, which is a crappy design in this case (involving a lot of IF statements). I'll have to disentangle these two and create a separate class for model-based entities. It's basically a separate issue, so I'll open a new entry for this.

Link to comment
Share on other sites

Prefabs are still individual objects, as seen from the editor, right? What we probably need is a parameter that defines a common center point that is added when you save a group of objects as a prefab. Of course DR would have to keep track of this group though.

Gerhard

Link to comment
Share on other sites

No, prefabs are technically just a bunch of map objects (brushes, entities, patches), not a group in that sense. The .pfb file is basically just a small map file.

 

When you import a prefab, the whole group gets highlighted and selected, allowing you to rotate it to fit your needs.

 

The problem here is that this rotation has been broken (by me) when I changed the func_static group entity transformation behaviour. I'll have to fix that and the problem will be gone.

Link to comment
Share on other sites

No, prefabs are technically just a bunch of map objects (brushes, entities, patches), not a group in that sense. The .pfb file is basically just a small map file.

 

Yes. That's what I meant. ;) That's causing the problem, because all of these objects have their own rotation center, as the editor doesn't see it as a group.

 

When you import a prefab, the whole group gets highlighted and selected, allowing you to rotate it to fit your needs.

 

So in that case the rotation is around a common center?

 

The problem here is that this rotation has been broken (by me) when I changed the func_static group entity transformation behaviour. I'll have to fix that and the problem will be gone.

 

But AFAIK this problem also exists in DoomEdit, or am I wrong about this?

 

Well, you know the code best, so I trust that you can fix it either way. :)

Gerhard

Link to comment
Share on other sites

So in that case the rotation is around a common center?

Yes, a bunch of selected objects should rotate about its centroid. That's how it used to be working in DarkRadiant until I changed the func_* stuff.

 

But AFAIK this problem also exists in DoomEdit, or am I wrong about this?
Don't know exactly, but DoomEdit seems to have three "modes", one of them rotating about the center and one rotates the objects independently (although I've been told they're buggy)

 

Well, you know the code best, so I trust that you can fix it either way. :)

Let's hope for the best. :) I already thought about an approach to fix this.

Link to comment
Share on other sites

Do the new "Load prefab" and "Save prefab" commands do extra processing that is not present in "Import" and "Save selected"? I'm thinking about the proliferation of load/save commands, we now have 4 methods of saving (regular, region, selected and prefab) which are almost certainly going to lead to confusion.

 

Is there any rationalisation of commands possible, e.g. "Save selected" and "Save region" use the same command but have a checkbox to surround the exported objects with sealing walls? If there is extra processing involved for saving prefabs, could this be activated by selecting the "*.pfb" option in the aformentioned unified dialog?

Link to comment
Share on other sites

The "Save Selected" and "Save Prefab" options are technically very similar, but they consist of only a few lines anyway (they're using the same utility functions).

 

The prefab command is querying a "prefab" module to be loaded which causes the .pfb extension to have higher priority than ".map".

 

I agree that "Save selected" and "Save Region" can use the same dialog with an additional checkbox, although this will entail a change in the filechooser stuff (which I didn't want to touch, since it's your code and you wrote it quite recently, I think). At the moment there's just the call to getMapFilename() which hides all the implementation details.

 

Perhaps a redesign of the filechooser dialog is necessary turning it into a proper class with some interface to set the properties like isOpenDialog, moduleType, GtkWidget* getDialog() to allow customisation.

 

Another possibility would be to move the "Save Selected" command to the Edit menu, although I'd not prefer that option.

 

We should of course consider the naming when merging commands. "Save Selected" + "Save Region" = ?

"Save Region" and "Save Selected" is of course not the same from the mapper's point of view and confusion may arise if the mapper has to choose a command that's called differently than its functionality.

Link to comment
Share on other sites

Don't know exactly, but DoomEdit seems to have three "modes", one of them rotating about the center and one rotates the objects independently (although I've been told they're buggy)

Let's hope for the best. :) I already thought about an approach to fix this.

 

Yeah, Doomed mucks stuff up when you rotate it too. I was hoping we could get another leg up on DoomEd by fixing it. :)

Link to comment
Share on other sites

I fixed the joint model rotation, it's working again now (on SVN). I'll add a toggle button like DoomEdit to switch between independent and joint rotation to throw another tool into the box.

Link to comment
Share on other sites

I think I've covered it all now:

  • Prefabs are inserted and can be rotated as desired.
  • Models can be rotated optionally around their own centers (Free Model Rotation, see screenshot below, the icon is ripped from DoomEdit)
  • I fixed the "jumpy" behaviour when rotating models about the z-axis first and about any other axis afterwards.
  • func_statics are still behaving correctly.

freerotationys1.th.jpg

 

What remains is the orthocontext menu option "Insert Prefab here" which imports the prefab at the clicked point.

Link to comment
Share on other sites

The "Insert Prefab" command in the orthocontextmenu is functional now. This should be it.

 

prefabinsertionnx6.th.jpg

 

 

This function is probably one of the best functions the mapping community at this time could have. I'm willing to add numerous detailed creations into our library of prefabs to get going. It will also provide those who are better with complex mapping things such as creating custom sky boxes to be able to share their works. I've very excited about this, when is the next version of DarkRadiant looking to be released?

Link to comment
Share on other sites

Don't know exactly. Orbweaver is currently working on the Objectives Editor, and I have a couple of issues to bite through. I'd say a couple of weeks?

 

However, there are two more possibilites to get the "bleeding edge" version:

  • Get the latest snapshot build I'm regularly uploading to the FTP server (linky).
  • Build your own DarkRadiant directly from SVN (see Guide here).

The usual disclaimer here is: although the latest SVN has the most and coolest features, it may well be that things are broken. Additionally, user settings have a higher probability to be changed during the ongoing development phase, and it's sometimes required to delete your settings entirely.

 

Apart from that, I'm glad you like the features, it's always nice to hear that the hard work is appreciated. :)

Link to comment
Share on other sites

Maybe we should be looking at an intermediate release. I still haven't fully decided how the Objectives GUI should work interface-wise, and it also needs to be moved into a plugin taking advantage of the new UIManager, so I don't know how long it will take.

Link to comment
Share on other sites

  • 2 weeks later...

I will drag the discussion of issue #228 here:

 

The problem is described as follows:

When an item is duplicated or prefabbed, the entity names and links need to be smartly incremented. For a simple example, open torchtest.map (in the repository).

 

light_candleflame_moving_2 binds to candle_1

 

However, if you duplicate (or prefab) the item,

 

light_candleflame_moving_2 and light_candleflame_moving_3 now BOTH bind to candle_1

The problem I see here is that if the mapper selects the light that has a bind to the candle_1 (only the light , NOT the candle_1) and duplicates this object, DR can hardly know what the mapper intends to do. What should happen? Should the bind key deleted or left pointing to the same entity?

 

A completely different scenario would be if both the light and the candle are selected and duplicated. Here, the situation is clear, the bind between those two should be preserved and the keyvalue should be incremented. I checked that with a light that has a target onto the candle_1 and this worked, so I'm positive that this behaviour can be extended to the bind key as well. At least I hope that it's possible, because the implementation is complicated like hell.

Link to comment
Share on other sites

Not sure I understand the first question. If light_1, bound to candle_1, are both duplicated, they'd become light_2 and candle_2. So the bind is incremented to candle_2. Of course, that will probably require always incrementing new objects (never filling in the holes, e.g., never going back to candle_1 because it was deleted, but always going forward) or I'd imagine it could get very complicated. Warning: I believe that is currently what DR does.*

 

A completely different scenario would be if both the light and the candle are selected and duplicated.

Oh I get you (above). Right, that's what I envision as "proper usage." If the person is intending to duplicate or prefab something, and they're selecting individual parts, then it's user error, their fault when it doesn't work right.

 

 

*Edit: I think that's not described well. What I mean is, say you have item1, item2, item3. You delete item2. You duplicate item3. Now the new duplicate becomes item2, going backward to "fill in the gap." The next item will be item4. That would probably make things a mess without some special logic. Maybe just keeping it simple would be best, always incrementing one beyond the highest existing, no matter if there are 'holes' or not.

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

    • 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
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...