Building a plugin for GtkRadiant 1.5 ... STLPort issues?

Discussion for Level editing, modeling, programming, or any of the other technical aspects of Quake
Post Reply
Johnny Law
Posts: 179
Joined: Tue Nov 16, 1999 8:00 am

Building a plugin for GtkRadiant 1.5 ... STLPort issues?

Post by Johnny Law »

I'm looking at updating an old plugin so that it works with GtkRadiant 1.5.

In 1.5, I believe that plugins have to instantiate an object of type SingletonModule. This apparently uses STLPort code, so the plugin DLL won't finish building unless you statically or dynamically link it with the STLPort library.

This confuses me a bit. Looking at the plugins that shipped with GtkRadiant 1.5, they're not big enough to be statically linked with STLPort, and there's no STLPort DLL around to support a dynamic linkage. And if I look at them with PE Explorer, it doesn't look like they're importing anything from STLPort.

It's been a long time since I've tried to work with Windows DLLs, so I'm probably missing something. Any GtkRadiant plugin devs around here that could clue me in? If it matters, I'm using VC++2008 and STLPort 5.2.1; I don't currently have any older version of VC++ installed, and older versions of STLPort don't work with VC++2008.
^misantropia^
Posts: 4022
Joined: Sat Mar 12, 2005 6:24 pm

Re: Building a plugin for GtkRadiant 1.5 ... STLPort issues?

Post by ^misantropia^ »

STLPort templates become part of the executable, you shouldn't need any DLLs (at least, I never did). But can't you compile it with the STL implementation that comes with VC++2008? STLPort was an alternative for the crappy STL that came with old versions of VC++ but the current implementation is fully conforming.
Johnny Law
Posts: 179
Joined: Tue Nov 16, 1999 8:00 am

Re: Building a plugin for GtkRadiant 1.5 ... STLPort issues?

Post by Johnny Law »

It's definitely demanding a library link; looks like perhaps I should try configuring it for _STLP_NO_OWN_IOSTREAMS.

I first tried compiling without STLPort, but the sample plugins won't build without it... various syntax errors. If using STLPort continues to be cantankerous I'll see if I can completely debug that original issue.

Thanks!
obsidian
Posts: 10970
Joined: Mon Feb 04, 2002 8:00 am

Re: Building a plugin for GtkRadiant 1.5 ... STLPort issues?

Post by obsidian »

How do plugins work for GtkRadiant? Can they be installed independently or are they highly dependent on the main executable? Are they GtkRadiant version dependant?

I took a look at the 1.5 directory structure and they look like a number of .dll files in the plugins directory. 1.6 has a bunch of stuff in \modules. I assume you can't just copy and paste those files and expect them to work.

In particular, I'm interested in the TexTool plugin that is included with 1.6 but not 1.5. I think TexTool is included with the 1.5 source, but no one has recompiled a new binary of 1.5 for quite some time.
[size=85][url=http://gtkradiant.com]GtkRadiant[/url] | [url=http://q3map2.robotrenegade.com]Q3Map2[/url] | [url=http://q3map2.robotrenegade.com/docs/shader_manual/]Shader Manual[/url][/size]
Johnny Law
Posts: 179
Joined: Tue Nov 16, 1999 8:00 am

Re: Building a plugin for GtkRadiant 1.5 ... STLPort issues?

Post by Johnny Law »

They're dependent at least on the plugin API used by that version of Radiant.

GtkRadiant 1.5 definitely has a different plugin registration/invocation API than GtkRadiant 1.1-TA did. It looks like trunk development is moving toward something else yet again ("synapse" stuff, if you're looking at the code) but I haven't paid much attention to that, and I'm not sure where 1.6 falls.

Apparently for 1.5 a plugin DLL only needs to export one function, Radiant_RegisterModules, and provide an object that implements the Module API (to return a set of standard functions that can be invoked on the plugin). If the plugin code wants to invoke something on Radiant, I think it needs to use the various Global* functions defined in the i*.h header files; e.g. use GlobalSelectionSystem().foreachSelected(...) to iterate over the current selection.

If the 1.6 source seems to provide a similar interface, then the plugins could be compatible. (But if 1.6 is no longer using plugin DLLs then that sounds like a bad sign.) I'm not sure what source was used to compile 1.6; the svn repository only has a tag for the 1.5 release. Is it perhaps the "ZeroRadiant" branch?

TexTool and a lot of other plugins are in fact in the 1.5 source, but they seem to be a mixed bag as to whether or not they are actually using the correct plugin API for 1.5 and whether they are actually in a compilable state. I haven't looked very closely at TexTool in particular.
obsidian
Posts: 10970
Joined: Mon Feb 04, 2002 8:00 am

Re: Building a plugin for GtkRadiant 1.5 ... STLPort issues?

Post by obsidian »

Yes, 1.6 is ZeroRadiant.

For me, TexTool is one of the potentially more useful plugins but it's missing from 1.5. I'm not in any position to do anything about it so that's why I'm asking.
[size=85][url=http://gtkradiant.com]GtkRadiant[/url] | [url=http://q3map2.robotrenegade.com]Q3Map2[/url] | [url=http://q3map2.robotrenegade.com/docs/shader_manual/]Shader Manual[/url][/size]
Johnny Law
Posts: 179
Joined: Tue Nov 16, 1999 8:00 am

Re: Building a plugin for GtkRadiant 1.5 ... STLPort issues?

Post by Johnny Law »

I just did some quick browsing around at http://qeradiant.com/cgi-bin/trac.cgi/b ... ns/textool and the TexTool code is confusing. A lot of it looks like it is using the old plugin interface from around the time of 1.1-TA. But the bottom of TexTool.cpp has the "Synapse" stuff creeping in. I'm not sure what's going on, but in any case it doesn't look 1.5-compatible.
Johnny Law
Posts: 179
Joined: Tue Nov 16, 1999 8:00 am

Re: Building a plugin for GtkRadiant 1.5 ... STLPort issues?

Post by Johnny Law »

Johnny Law wrote:...looks like perhaps I should try configuring it for _STLP_NO_OWN_IOSTREAMS.
Yup that was the problem.
Post Reply