Itches, Glitches & Anything Else...

[Fidcal]

I was having trouble loading a big map earlier and I thought it was because I only have 512Mb of RAM and had a few other programs running at the time including Doom 3! When Windows runs out of real physical memory it starts using a large disk file as virtual memory but this is really slow compared to RAM. Later I loaded the same map more quickly when I did not have other programs running. I'm thinking of getting more RAM. Could that be the same problem for you jdude?

 

The only other thing I can think of is build it in three or four parts as different maps and merge it later using prefabs but I don't know how robust or comprehensive those are.

[greebo]

It is not the user's intention to change the shape so it is a fault. In Dromed the brush properties, coordinates, orientation, and dimensions are listed just like any object and the user could type in any acceptable value in any of them. That is another reason I was suggesting that brush properties be displayed in the entity inspector.

Snapping an off-grid object to the grid is equal to changing it - there's really no way around that. The brushes are defined by their face planes and these are the ones that get snapped. There's no way for DarkRadiant to know what shape the mapper wants the brush to be, neither makes the parameter "orientation" any sense for brushes.

 

@jdude: I know that the worldspawn entity can take quite long to load. It may be possible to display a brush counter, I'll have to look into that. Having lots of RAM is never a bad idea, you can't really have enough - in this case of map loading it won't help much though. Adding and managing the 4000 brushes just takes its time.

[Fidcal]

Snapping an off-grid object to the grid is equal to changing it

That is why I was suggesting an additional non-grid snap - a snap to the nearest 90 degrees. But I see now that this would only work with rectangular blocks anyway if brushes are defined by their faces and not their shapes. So one face of a wedge might snap to 90 - but so would the opposite one! I give in on this.

[jdude]

@jdude: I know that the worldspawn entity can take quite long to load. It may be possible to display a brush counter, I'll have to look into that. Having lots of RAM is never a bad idea, you can't really have enough - in this case of map loading it won't help much though. Adding and managing the 4000 brushes just takes its time.

 

Right now I have 1 gig but I hope to up that to 3 gigs soon of ddr2 ram. I know that it wouldn't be a necessity but I think it would be very benefitial to people with low ram trying to open large maps because windows loves to label programs which are busy as "not responding" but if a brush count was there it would be obvious it was loading.

[greebo]

I added a primitive counter to the modal progress dialog (in SVN). The cancel button is also much more responsive when loading large maps.

[bob_arctor]

With the rotation surely just use the arbtitary rotation box? Chose some kind of good input for maintaing shape (45°) then snap to grid.

 

Then you will maintain your shape and have a brush that won't create BSP holes or bugs due to not being on a grid.

[OrbWeaver]

If you rotate by 45 degrees and then snap to grid, there is no guarantee that the brush will keep its shape no matter how you specify the rotation.

[Fidcal]

Where is that box Bob? You mean a box you can enter any angle? Can't seem to find it.

 

So do mappers generally never snap to grid any brush that they have rotated?

[OrbWeaver]

So do mappers generally never snap to grid any brush that they have rotated?

 

I'm not exactly an experienced mapper, but in my view the clipper tool and edge manipulation are a lot more useful for producing angled surfaces than the rotate tool. I have never used the free rotate command in earnest, as far as I recall.

[greebo]

Where is that box Bob? You mean a box you can enter any angle? Can't seem to find it.

If you're using the snapshot release it may be that you have to assign a shortcut before you can open the Transformation Dialog. I forgot to add a menu item for this dialog (which is already fixed in SVN) - please search for "TransformDialog" in the shortcut editor.

 

So do mappers generally never snap to grid any brush that they have rotated?

It's of course always recommended to snap your fundamental geometry to the grid to avoid leaks. If you have a rotated brush, you might want to snap your brush the grid and manually edit the brush using the Edge manipulator. This way you can control the shape of your brush in detail and have the brush on the grid at the same time. Depending on the grid size and shape of your brush you'll might have to make compromises though. (Oh, and don't use the Vertex manipulation mode, it's really only useful for triangular prisms.)

[greebo]

A new build is up on FTP (extract this over the GTK 2.10 build favourably, but it should work when copied over an existing 0.8.1 installation as well). It should resolve the issue with custom stims not being displayed the first time and the crash on shutdown.

 

http://208.49.149.118/TheDarkMod/DarkRadia..._latest_SVN.zip

[Fidcal]

Confirmed. No crash on exit in two or three tests and the stim names are fine.

 

The s & r is basically there now and looking very good. I'll do some more testing when I get the next beta with s & r working as real testing in-game will highlight any glitches. But the interface looks pretty complete. (still think new names should just be typed in then Add or Enter to add but I won't quibble! )

[greebo]

Nice, thanks for testing! It will of course continue to be improved, but I'd really like to draw the line here to get DarkRadiant 0.9.0 ready for release. It will be very convenient to upgrade the S/R Editor as it's a single ~1 MB DLL (as long as no plugin interface changes are made).

 

OrbWeaver, I wonder if we should use the http://darkradiant.sourceforge.net/ website for these kind of things? It may be cleaner than to mess around with forum links and stickies, although it would be more work to maintain the website. A barebone easy-to-maintain website wouldn't be too much work, I could pull that off in half a day or so (if my HTML skills didn't get rusty in the last half year ).

[OrbWeaver]

Yes, by all means. The website is not being used at all as you can see, so feel free to produce something.

[greebo]

Erm, can I do this with my current access rights? Do I have to be sourceforge project administrator or similar?

[OrbWeaver]

Apparently you should have this permission, it is called "Allow access to shell server group space (i.e. web space)" and is ticked for your account.

 

Don't ask me how to access the web space however, presumably there is some documentation on the SF pages.

[greebo]

Ok, I could find the according folder on the sourceforge webhost and upload the logo as a test.

 

I will try to come up with a small site in the evening hours, right now I'm off into our rehearsal room.

[SneaksieDave]

Any chance the selection overhaul (inc. func_*, rotation, origin moving, all that associated complication, etc) will be part of 0.9?

 

*runs!*

[greebo]

No, because this will require some serious amount of work. This will probably take weeks, and 0.9.0 is about to be released. But it is still planned.

[greebo]

OrbWeaver, does the BooleanPropertyEditor work on your end? It doesn't seem to do anything for me, but I definitely remember it working before.

[OrbWeaver]

No, it's broken, I need to look into that before the release. There is also something screwy going on with the PropertyEditors on Windows if you right-click to bring up the Add Property dialog, causing some GTK warnings and a failure to delete the current Property Editor when you select another key. I will try to replicate this in Linux.

[Fidcal]

Why is the drag/resize button labelled QE? Searched the net and can only find Quake Edit but can't see why the button would be called that. I need to refer to it in a tutorial.

[greebo]

It's definitely some quake abbreviation, it's likely that this manipulator has been introduced in some of the older QuakeEd versions. Just refer to it as "drag manipulator".

[Fidcal]

Thanks for restoring the maximize on camview etc. in v.9. I find it handy to double click it big and small.

 

Been meaning to mention but kept forgetting, the grid horizontal coordinate digits corrupt together and are too high on my setup. The side corruption may be my desktop dpi setting I can't tell. That is, it might simply be that every value is running over into the next one. Can they be spaced out more? The vertical thing is the top half is off the top of the window. A screenie HERE

 

Hold on, I see as I zoom in that they space out more so maybe it is sufficient if they are just lowered a half character height?

 

One more thing, can you confirm that the Dark Radiant grid units really are doom units?

[greebo]

Been meaning to mention but kept forgetting, the grid horizontal coordinate digits corrupt together and are too high on my setup. The side corruption may be my desktop dpi setting I can't tell. That is, it might simply be that every value is running over into the next one. Can they be spaced out more? The vertical thing is the top half is off the top of the window. A screenie HERE

These are really huge values you have there on the grid, I guess the grid spacing was not designed to handle these large values sufficiently. I'll have to look at the code and see if I can easily do something about it. The lowering about half a character height should be easy to do.

 

One more thing, can you confirm that the Dark Radiant grid units really are doom units?

Yes, I haven't heard anything contradictory.