neogeographica / meshtex Goto Github PK

MeshTex doesn't need these, but other plugins might... would be nice for the "generic" part of the framework to not drop them on the floor.

If it's really generic enough, walk the walk. Probably best to tackle the 1.6 investigation (issue #1) first though.

This is closely related to the 1.6 port, but even if that falls through there are reasons to chase this work at least a bit. Especially it seems like it would be nice to better manage the interaction with Radiant's undo system -- currently every operation handler basically has to jump through similar hoops to use the undo system.

Philosophically I didn't want this constructor to make any assumptions about what widgets or callbacks the dialog would use, but this may be a useful exception.

I suppose it's possible a dialog might want to intercept and reject the close? Can't think of a usecase right now (at least not one that wouldn't really annoy the user), but maybe it's best to leave that possibility open.

If UltraMon is configured to add window title buttons, GtkRadiant 1.5 will hang on exit. Have just observed this without investigating much; need to figure out:

• if this only happens when MeshTex is installed
• if this only happens after a certain MeshTex action (like raising a dialog)

Could spend a bit of time chasing a solution, but not a really high priority... if it becomes intractable, release-note it and move on.

It's the wave of the future. Probably some interesting architectural differences that will make me change everything!

Currently this input is rejected. It's not nonsensical though... it can be interpreted as having a constant value for the texture coordinate along the slice. To make it work I'll probably need to dodge some divide-by-zero errors.

Low priority.

May be able to salvage some of the old PatchAlign readme, but probably not much.

• brief description of patch mesh texturing
• explain primary usecases for plugin
• description (and demonstration with pictures?) of each operation, and the options for each operation

Seen this a few times, seems to happen when dragging the camera view around. Lots of error dialogs spawned that each show many instances of the above message.

It's happened when I haven't ever invoked the MeshTex plugin, although the MeshTex plugin is installed... so I don't think it is related to the plugin but I'm not sure.

Also it has only happened when I was running GIMP (which also uses GLib and GTK+) at the same time as GtkRadiant. Possibly a coincidence.

I've caught this in the Visual Studio debugger, but it seems like useful thread context is long gone by the time the error dialogs are raised. It would be nice to have libglib symbols... maybe something to chase down when I'm more motivated to look at this particular issue.

Hi!
I want to include MeshTex with Netradiant (which is significantly improved fork of 1.5 branch)
Precompiled binary works well untill applying changes (->crash)
Editor is crossplatform as well, so decided to include plugin to the build system, as any other plugin there
So currently trying on windows+mingw+gcc

The problem happens at init; app throws 'unknown software exception (0x80000003)'
Debugging shows, that the problem occurs at
static PluginUI singleton;
line
As far as i understand, 1st call of this one triggers constructor, which triggers that line again
And then we get a problem.

Any help with this would be nice, thanks.

For autoscale, choose shrink instead in this case. For explicit stretch command, pop an error window.