greebo

Just wanted to drop a note here, that I changed the name of _QER_FuncTable_1 to RadiantCoreFunctions and added some documentation to qerplugin.h. If there should be a problem with renaming the struct, I will revert it of course, just tell me.

I just did a quick check and put the module into radiant/brushexport, i.e. copied the code into the radiant core (commented the module stuff out), and it works like a charm. Something has to be amiss with my module implementation. Took me 3 whole minutes including compile... I will now look into the plugin code.

Hm, ok, I will have to take a look how the current systems queries the commandlist and how it treats this information. Perhaps I can come up with something good enough so that it will be usable in those future plugins.

So how would such a plugin interface look like? Would there exist a generic iplugin.h abstract base class which defines the methods that are needed to attach the plugin to the core (like "getCommandList", "getMenuPath", "getSomething" and so on)? What about Dependencies? Would they be handled like they are with the current modules?

I adapted the XMLRegistry Module, created a new abstract base class, created the module reference and its dependencies, instantiated the module and tested it with some std::cout The problem is most probably buried somewhere here (as it's working as a plugin, it must be me ), so as next step I intended to take smaller steps and try to create working code within the radiant core (as you suggested) and then try to move it into a module. I didn't expect this thing to create such problems, the module implementation was straight forward to the point where the BrushInstance cast crashed, so I guess I took one step too large. I will look into this in the evening when I get home and I will keep you posted on my progress. I'm still curious why the getTypeId function returns the value 64 (which is one too large and it's crashing on accessing the array[64]) when traversing through the scene (usual values are around 7 to 8), but I'm afraid that I won't reach the bottom of this problem.

Sorry, can't follow you, but this is most probably me being too tired at the moment. Well, at least I could figure out why the thing's crashing: there is this member variable TypeCast m_casts; in class TypeCastTable. And the method cast() gets called with exactly SIZE as index, which is perfectly out of bounds and this is where it crashes. I just implemented a bounds check, but I don't know if this is leading anywhere... What the heck is this for? typedef void*(*TypeCast)(void*);

Thanks, that may be possible, I will check that. I roughly understand this structure (I was there before but while wading through this mess my brain eventually goes blarg...

This maybe a problem if the registry gets reorganised a lot. In this case I could try and implement a stage-wise upgrade, so that an xml file with version 0.7.0 gets "converted" into 0.8.0 and then upwards till it reaches the most recent version. This shouldn't be too hard, I think, and I will take care about this when it becomes necessary .

I've reorganised the brushexport plugin into a module and I'm running into a crash when this is called: BrushInstance* bptr = InstanceTypeCast<BrushInstance>::cast(instance); This should convert a general instance into a BrushInstance, but it crashes for some reason. Apart from this everything is in place, the module gets loaded correctly and I can successfully draw a brush and call the option from the menu. I can even select the file from the GTK dialog and as soon as the visitor class starts traversing the scene, it bails out. I'm working on it (slowly, because the std::cout debugs are tedious and compile times increase as I reach the deeper include files with lots of dependencies), just wanted to post my progress here.

I get your point, but it's not very complicated, the forum's "code formatting" doesn't help, I have to admit... I didn't want to hardcode all this stuff and thought it could come in handy.

The upgrade code is committed now including two upgrade paths from earlier versions. All the upgrade information is stored in the install/user.xml in some sort of a scripting language. For example, this allows the colour schemes and the state of the showAllLightRadii button to be copied into a higher user.xml version: <upgradePath fromVersion="0.6.0"> <!-- Find the currently active scheme and store its name to Memory 1 --> <saveAttribute name="name" xPath="/user/ui/colourschemes//scheme[@active='1']" memoryIndex="1" /> <!-- Make sure the default schemes are removed before copying user schemes --> <deleteNode xPath="/user/ui/colourschemes//scheme[@name='QE3Radiant Original']" /> <deleteNode xPath="/user/ui/colourschemes//scheme[@name='Maya/Max/Lightwave Emulation']" /> <deleteNode xPath="/user/ui/colourschemes//scheme[@name='DarkRadiant Default']" /> <deleteNode xPath="/user/ui/colourschemes//scheme[@name='Black & Green']" /> <!-- Clear all active attributes in the base registry --> <setAttribute target="base" xPath="//user/ui/colourschemes//scheme" name="active" value="0" /> <!-- Copy all remaining colour schemes into the new registry --> <copyNode fromXPath="/user/ui/colourschemes//scheme[@readonly!='1']" toXPath="user/ui/colourschemes" /> <!-- Set the active scheme to the one that was stored in Memory 1 --> <setAttribute xPath="/user/ui/colourschemes//scheme[@name='{$1}']" name="active" value="1" /> <!-- Import the state of showAllLightRadii into the new registry --> <copyValue fromXPath="/user/ui/showAllLightRadii" toXPath="user/ui/showAllLightRadii" /> </upgradePath> I will do some testing before the next release, where I will ask some of our beta mappers for their current user.xml, so that I can test it on my machine (angua's version is already working ).

Should we somehow "mark" these dummy brushes, so that DR can automatically strip these brushes on load via a boost::regex?

phew... *wipes sweat from his brow and sinks back into chair* I'm working on the upgrade system now, btw. Things are progressing quite well so far.

The changes are committed, could you have a look, if everythings runs smoothly?

I finally managed to implement this, I had to add the command GlobalModuleServer::instance().set(GlobalModuleServer_get()); right before instantiating the GlobalRegistryModuleRef. It took me quite a while to figure this out, but now everything is working. I will now do a full checkout and add my changes to the clean version. My working copy is cluttered with debug output

Ok, thanks, will try this!

I found some time today to look again into moving the XMLRegistry into a module. So far I was able to avoid any nasty crashes (which is an achievement for me, believe me ), but there still remains the problem that the registry should already be loaded when the stack of Radiant Dependencies is instantiated. It seems to me that there is no way to reliably place the registry's importFromFile() calls between those instantiations, so I believe the only solution would be to pass the actual AppPath to the registry constructor, so that the registry can handle the load on its own during its instantiation. I see two problems: - The registry would have to figure out of its own where the actual doom3.game file is located, unless we could place this information within the user.xml. And I'm afraid that the abiltiy for multiple game files would somehow be lost. Don't know if we need this in the first place. - The AppPath_get() function is out of reach for the XMLRegistry, so I would have to implement its own function to determine the "root" directory of Radiant. (The question here would be: is there a standard, platform-independent method of doing this, apart from the one Radiant has built in?). Or is there another possibility to pass the AppPath string (or any structure) to the GlobalModuleRef instantiation?

That's an interesting point. I should talk to angua about this...

Yeah, be sure to check your post for any weird character combinations. This server's Apache doesn't seem to like this...

So what could be solution for this? Should DR automatically turn every entity into a brush-based one by adding this dummy-brush? As long as DoomEdit is still required to achieve some mapping goals this should assure the portability of the maps, but we can dump this as soon as DoomEdit becomes obsolete.

Is it possible, that the colon-underscore-replacement does cause any troubles? Maybe DoomEdit is relying on the name of the Entity as well? It's unlikely as one could change the name to something arbitrary by using the entity name, but it would be worth a check.

Well, can you eat a whole seal?

Having to use a debugger is a problem for me as I couldn't get gdb to work in Windows and my Linux is a little screwed at the moment. So I'm probably not much of a help for you here, I'm afraid. Well yes, I can imagine that, but you never know...

This may be connected with these deprecated vector3 functions I removed in one of the last commits. I'm at work, so I cannot do anything till the evening, I hope this is soon enough. Would I need a debugger to investigate this? Is the light_center necessary? Ordinary lights "without" center are fine?

Thanks! I obviously didn't look deep enough into the module code where the dependencies are handled. I thought every module is instantiated as soon as the dll is loaded... Back to work then! You mean like this: inline TestModule& GlobalTest() { static GlobalTestModuleRef ref; return GlobalTestModule::getTable(); } or is the static not necessary? Without the static it crashes again, so I guess this is necessary. Or did you mean something different?