Jump to content
The Dark Mod Forums

DR and its shifting planes

grayman
 Share

Recommended Posts

  • Replies 242
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

OrbWeaver
OrbWeaver

New builds have been uploaded which should no longer exhibit this problem. The links are the same as before:  

OrbWeaver
OrbWeaver

I implemented the translation-only code, which stopped changes to the normal vector but there were still progressive errors in the distance value. Switching to the maths provided by Obsttorte seems to

Sotha
Sotha

Yeah, it exports the selection you have into a model. The model cannot be changed anymore so it is DR object corruption bug immune. Downside is you need to export it again if you want to change it lat

Posted Images

grayman

grayman

Posted
  • Author
Posted

I opened my map in 1.7.3 and every brush that's part of a func_static is mirrored/shifted elsewhere in the map.

 

It looks like 1.7.3 might not understand the 1.8.0 format, or it's doing something to the func_static brushes as it's reading them in.

Link to comment
Share on other sites
OrbWeaver

OrbWeaver

Posted
Posted
I opened my map in 1.7.3 and every brush that's part of a func_static is mirrored/shifted elsewhere in the map.

 

That sounds like the additional/removal of origin has gone wrong and is being done an incorrect number of times or with an incorrect distance vector.

 

Do you have a minimal test map which can illustrate this issue?

DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts

Link to comment
Share on other sites
grayman

grayman

Posted
  • Author
Posted

Open brushShift1.map, which is one of the two maps I posted to help debug this problem.

 

In 1.8.0, the func_static of two brushes is where it should be.

 

In 1.7.3, its origin is correct, but the two brushes have moved far away from where they belong.

Link to comment
Share on other sites
OrbWeaver

OrbWeaver

Posted
Posted
In 1.7.3, its origin is correct, but the two brushes have moved far away from where they belong.

 

Yes, I see the issue too. I was so busy looking at the numeric values that I never actually zoomed in to inspect where the brushes appeared.

DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts

Link to comment
Share on other sites
nbohr1more

nbohr1more

Posted
Posted

Thank you Orbweaver!

 

 

(I will probably get back on track to do some "serious mapping" soon (rather than just fixing broken missions, etc).)

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites
grayman

grayman

Posted
  • Author
Posted

Brushes are now back where they belong.

 

Thanks!

 

I need to finish a bit of code, then I'll spend some time mapping.

 

I did do a quick test on brushShift1.map, banging away at the Save key, and didn't notice any shifting. Hopefully y'all have nailed this bug.

Link to comment
Share on other sites
grayman

grayman

Posted
  • Author
Posted

I guess we got this fix just in time.

 

I had a 45-degree-angle support beam on each end of a ceiling joist. Both angled beams were shifting in the same direction, so one was becoming larger and the other smaller. Starting with a 24x24 symmetry, one had shrunk to 18x18 and the other had expanded to 30x30. The dirt patches I'd placed on them originally were still in the same place, making for a totally bonkered mess.

 

Multiply that by dozens of these support beam pairs, and that's a whole mess of work that needs to be repaired because of the shifting problem.

 

I've repaired the support beams, but deleted all the dirt patches. If the beams can stay put for the next couple months, I'll add the patches back at the end.

 

Thanks again for the fix. I hope it holds up.

Link to comment
Share on other sites
grayman

grayman

Posted
  • Author
Posted

I'm having a problem texturing brushes.

 

Using the Surface Inspector, regardless of what setting I enter for Default Scale, when I hit the "Natural" button, the scale applied to the surface is 1x1.

 

Anyone else seeing this, or have I accidently gotten myself into a state that causes this to happen?

 

For example, if I manually set the scale on a texture to 0.25x0.25, then enter 0.5 in the Default Scale field, and hit the "Natural" button, the scale is reset to 1x1.

 

Edit: More on this problem.

 

The first time I use the normal button on a brush surface with--say--a Default Scale of 0.5, the surface textures properly at 0.5x0.5.

 

But if I reset "Default Scale" to 1.0 and hit the Normal button again, the texture stays at 0.5.

 

If I then select a different texture, which is already at 1x1, and hit the Normal button again, it changes to 0.5x0.5, even though the Default Scale is now 1.0.

 

It's as if the first press of the Normal button reads and applies the Default Scale, but subsequent presses continue to apply that same scale, regardless of what I've changed the Default Scale value to.

 

I've stopped my testing until this gets fixed. (Or someone figures out what I'm doing wrong.)

Link to comment
Share on other sites
RPGista

RPGista

Posted
Posted

It was fun to watch you guys crack this nut.

 

It actually went way over my head, you guys are freaking math geniouses. :) If the moving planes issue is fixed, this means I'm back in business with updating my mission, once and for all. Thanks guys for all the effort.

Link to comment
Share on other sites
OrbWeaver

OrbWeaver

Posted
Posted
@Orbs, any idea when you can have a look at this showstopper..?

 

I will have a look. Any idea when the problem first appeared? It seems unlikely that the plane translation changes alone would have introduced a new issue with texturing, but it could have arisen from some other change that went into Git since the last release.

DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts

Link to comment
Share on other sites
OrbWeaver

OrbWeaver

Posted
Posted
Btw, why did the version number go backward to 1.7.3, instead of forward to 1.8.1

 

There was never an actual 1.8.0 release (the latest on the website is 1.7.2). I believe 1.8.0 was an unofficial build that somebody (Stifu?) created for testing purposes. Since this latest release contains only bugfixes I have incremented only the "bug" suffix rather than the "new feature" minor version number.

DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts

Link to comment
Share on other sites
Obsttorte

Obsttorte

Posted
Posted

I fairly doubt that the changes regarding the plane translation could have caused this error. Changes on anything texture-related would only be necessary if the func_statics would get rotated as well, what isn't the case as I was told. Also grayman said he has this problem with brushes, what I would interpret as worldspawn, which is also not affected by this change. I hadn't had the time to check this out so far, so ... :unsure:

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

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.

×
 Share
Go to topic listing

  • Recent Status Updates

    • OrbWeaver

      OrbWeaver

      Does anyone actually use the Normalise button in the Surface inspector? Even after looking at the code I'm not quite sure what it's for.
      · 5 replies
    • Ansome

      Ansome

      Turns out my 15th anniversary mission idea has already been done once or twice before! I've been beaten to the punch once again, but I suppose that's to be expected when there's over 170 FMs out there, eh? I'm not complaining though, I love learning new tricks and taking inspiration from past FMs. Best of luck on your own fan missions!
      · 4 replies
    • The Black Arrow

      The Black Arrow

      I wanna play Doom 3, but fhDoom has much better features than dhewm3, yet fhDoom is old, outdated and probably not supported. Damn!
      Makes me think that TDM engine for Doom 3 itself would actually be perfect.
      · 6 replies
    • Petike the Taffer

      Petike the Taffer

      Maybe a bit of advice ? In the FM series I'm preparing, the two main characters have the given names Toby and Agnes (it's the protagonist and deuteragonist, respectively), I've been toying with the idea of giving them family names as well, since many of the FM series have named protagonists who have surnames. Toby's from a family who were usually farriers, though he eventually wound up working as a cobbler (this serves as a daylight "front" for his night time thieving). Would it make sense if the man's popularly accepted family name was Farrier ? It's an existing, though less common English surname, and it directly refers to the profession practiced by his relatives. Your suggestions ?
      · 9 replies
    • nbohr1more

      nbohr1more

      Looks like the "Reverse April Fools" releases were too well hidden. Darkfate still hasn't acknowledge all the new releases. Did you play any of the new April Fools missions?
      · 5 replies
×
×
  • Create New...