Understanding the Code

[STiFU]

Most Definitely! I've already been planning it in my head the last few days. This time I'll do it really clean and step by step. After that some more logic will be necessary in the Readable Editor. I guess I'll write some sort of content management class for that, so that the ReadableEditorDialog doesn't get so messy.

 

I want to enable editing of full-custom readable guis. For that I'll have to identify text-blocks in guis, retrieve their names and link the content of dynamically created textviews to them. The amount of textviews should still remain limited to 4 and I have to develop some logic that decides which textviews shall be linked to which key-values initially, basically the current GUI of the Readable Editor should be maintained. I'll have to find a good way to allow the user to switch the "linkage" of the textviews. I guess a pulldown menu over every textView could serve as a switch and a key-value identification simultaneously. The Pagelayout radiobuttons will then just toggle a 2x2 or 2x1 layout of the Textviews. The space will be equally distributed among the textviews, because we don't directly differ between title and body anymore, but we could maybe add a paned, to let the user decide how much space the rows should take up.

 

I guess I'll switch back to the readable-branch then for now, right? I would merge the trunk back into the readable-branch then.

[STiFU]

This approach would also allow users to create readables with mixed one-sided and two-sided guis by the way. Like a one-sided cover at first and then a two-sided book. It'll be completely custom! Rather a general purpose gui-Text editor than a Readable Editor then...

[greebo]

I guess I'll switch back to the readable-branch then for now, right? I would merge the trunk back into the readable-branch then.

You can choose. You can continue working in the trunk, unless you're committing serious changes which would leave the readable editor unusable, then it's better to switch to your branch and merge the recent commits from the trunk into your branch.

[greebo]

Just a quick note, STiFU: I see you're using a StringVectorMap for storing a the filenames associated to a specific definition. An equivalent implementation could also build upon std::multimap which allows a given key appear several times in the mapping, like:

 

readables/test => xdata/unnamed.xd

readables/test => xdata/unnamed2.xd

 

std::multimap also provides a count() method which allows you to check whether a certain xdata is registered and how many this is the case.

 

It's up to you to decide whether this is easier for you to handle, just thought I'd mention it, because std::multimap is less commonly known.

[STiFU]

Yeah, I know about multimap, but somewhere along the line I decided for this solution for some reason. I don't remember anymore which reason it was though... I'll have a look and maybe use multimap.

[greebo]

It seems we have a serious bug in the code preventing DarkRadiant from finding fonts which are stored in PK4 files. This affects basically all users out there working with TDM 1.00/1.01, so a bugfix release should be prepared.

 

As you already compiled the 1.2.0 files, could you take care of the 1.2.1 release too?

[STiFU]

By the way, I have a nasty problem on the readables branch again. I didn't change anything on the old files and out of nowhere, I get these errormessages.

 

"'entity::EclassModelNode': Cannot create instance of abstract class e:\Dark_Radiant_SVN\plugins\entity\eclassmodel\EclassModelNode.cpp Line 81"

 

And the same errors comes from EntityCreator.cpp. Building only succeeds if I clean dm.gui and build that project completely afresh.

 

If I launch DR with "Load last map on startup", DR crashes during loading the map.

 

How can I copy paste the stacktrace in Visual studio? It's just in a pulldown menu and I can't select anything in it for copying.

[STiFU]

Ah, didn't see your post there. Sure I can. Is everything good to go as it currently is? I guess I'll delete the 1.2.0 folder on sourceforge, right?

 

Let's just hope that entity build bug is not on the trunk.

[STiFU]

So, I am ready to upload. Just need your "ok"! I tested loading of fonts from archives on both x64 and x86. Works fine!

 

Edit: I think I messed up the readables branch with a merge. I'll try to create a fresh branch of the current trunk by deleting the readables branch and recreating it.

[greebo]

Ah, didn't see your post there. Sure I can. Is everything good to go as it currently is? I guess I'll delete the 1.2.0 folder on sourceforge, right?

The 1.2.0 can be left as it is, just add the 1.2.1 folder and set the default Windows download to 1.2.1 x86. The old releases should be there for archive purposes.

 

Thanks for looking into it, in any case.

 

So, I am ready to upload. Just need your "ok"! I tested loading of fonts from archives on both x64 and x86. Works fine!

I trust you on that. I take it you did a full recompile such that the new 1.2.1 version number is visible in the DarkRadiant.log and the Help > About dialog?

 

Edit: I think I messed up the readables branch with a merge. I'll try to create a fresh branch of the current trunk by deleting the readables branch and recreating it.

Yeah, that's the safest bet. You can also create a new name for the branch, but deleting the old one is fine too.

[STiFU]

Ok, all done. I guess you'll do another proper announcement then. I'll only let the guys having problems with the Readable Editor know that the new version is online.

 

I tried to follow the release mechanics article, but didn't find a way to set 1.2.1 to released on the bug tracker. I guess I don't have the rights to do so. Same goes for the Dark Radiant page on sourceforge.

[greebo]

Thank you, STiFU, for taking care of this. I updated the website and the tracker. The sourceforge page is automatically updating itself after some timeout.

[STiFU]

How can I derive the necessary key values from a gui file? Had another look at the readables script but couldn't find anything. If I look at the gui files, I notice that only the windowDef is called e.g. "leftBody", but the text only says "<body>". As I said, I want to support basically all guis, so I need to derive the keyvalues somehow from them.

 

   windowDef leftBody {
       WORLD_SCALE
       rect 75, 30, 185, 320
       forecolor 0, 0, 0, 0
       font "fonts/chrishand"
       text "<body>"
       textscale 0.45
   }

[greebo]

Yes, this is a little naming inconsistency which in the end forced me to add GUI script support. The readable GUIs have a small script section in the Content windowDef:

 

onTime 0 {
	if ("gui::worldDisplay" == 1)
	{
	set "title::forecolor" "0 0 0 1";
	set "body::forecolor" "0 0 0 1";
	}
	set "title::text" "$gui::title";
	set "rightBody::text" "$gui::right_body";
	set "leftBody::text" "$gui::left_body";
}

Where the GUI state variables are loaded into the correct window registers. It's a bit unfortunate that these are not named the same as the windowDefs themselves, but changing that would break all existing readables out there.

[STiFU]

Ah, now I finally understand then why we needed that GUI script support in the first place... Thanks.

[STiFU]

After looking at the screenshots of Goldchocobo's campaign, I have been dreaming about a little today and I had an idea that would be damn useful to mappers. I am not so deep into DR mapping myself, I just know the basics, so my assumptions might be wrong.

 

So, I was thinking, func statics are treated just like models, right? Wouldn't it be possible to write a plugin that allows vertex painting on func statics so that mappers can apply vertex blending of textures easily from within the editor? Would probably be quite a big task, but would also improve the average visuals of TDM quite a bit, as not everyone has access to modeling apps or is willing to learn one.

 

An approach like this would also be a lot more flexible, because you could realign textures easily and stuff like that.

[Serpentine]

Doing that as a standard func static brush would not work (as far as I know). Func static'd brushes are still traditional brushes however they are just excluded from the map compiler optimization and such, they can have args and such but at no time do they become a true model (brushes themselves do not have support for vertex colouring).

 

You could however undertake doing it as a macro via 'export to obj' and including some kind of simplistic vertex painting tool where you can just assign verex colours and preview what it would look like with a material that supports vertexcolouring (the 'exported' model is then 'imported' back into the same location to substitute). But that's quite a lot of work.

 

On the extreme-other-side there is using a different map compiler, similar to how q3map2 allows vertex blended brushes ala simon's tut ; I remember one of the teamblur guys said that their map tool supports doom3 maps, this is pretty unrealistic with current dev time and the actual mapper work is a lot more than simply using a model tool.

[New Horizon]

On the extreme-other-side there is using a different map compiler, similar to how q3map2 allows vertex blended brushes ala simon's tut ; I remember one of the teamblur guys said that their map tool supports doom3 maps, this is pretty unrealistic with current dev time and the actual mapper work is a lot more than simply using a model tool.

 

I believe they had given me access to their compiler at one time...in fact, I think I have it on my hard drive somewhere.

[STiFU]

Func static'd brushes are still traditional brushes

Ah ok, what a shame. The obj-approach could work I guess, but flexibility would suffer. The idea with the other map compiler seems a little over the top to me.

 

Edit: Ah I just noticed that that simon guy is the one who made pyramid of the magician. His medieval court looks pretty impressive too, considering it's the good old q3 engine...

[New Horizon]

Just looked up my info on the Team Blur map compiler. It can support Doom 3 map format, but only in terms of taking the map built in the D3 editor and compiling it for their Overdose engine, it doesn't create .proc files or the like.

 

The team did give us permission to use some of their tools, and I believe I posted a link to the source code but I don't know if it was ever looked into.

 

They have a custom TGA to DDS conversion tool...all d3 compatible, so we wouldn't be tied to ATI anymore and it could be repackaged as a TDM product.

 

I'm sure later on down the road their map compiler could be rewritten to spit out the necessary D3 files, but that would require a lot of work.

[STiFU]

Hey Greebo, I can't concentrate on both the Readable Editor and my thesis right now, because I wanna be done with the latter as quick as possible. It's also just too interesting to be coding for something else. I hope you understand... Should I change status of issue #2168 to suspended for now?

[greebo]

Pity, but it's fair enough if you don't have time.

[STiFU]

I've just been looking into the issue Fidcal reported with the Readable Editor. I see a lot has been changed in the gui code since I worked on it the last time and I am also a little rusty as far as gtk coding is concerned.

 

I nailed at least part of the reported problem down to the event callback methods onOneSided(..) and onTwoSided(..) not actually being called when the radio buttons are clicked (BUTTON_PRESS_MASK does not seem to work). So I converted those methods to signal callback methods and connected them via signal_clicked().connect(...); to the radiobuttons. Clicking the radiobuttons now has an effect on the editing layout again. However, I now receive random access violations when I start the Readable Editor and stack overflows in BlockingTransientWindow.h when the gui selector dialog is supposed to show up. Also, when I have a two-sided layout and click on one-sided, the program calls onTwoSided and after that onOneSided, while it should directly call onOneSided. This misbehavior also takes place the other side around. Any ideas?

[greebo]

I'd need to take a look myself, can't say what's wrong. I found in the past that some gtkmm callbacks require the actual call order to be specified, but maybe that's not the problem here.

[STiFU]

Other than what Fidcal just reported, there is also the issue that the gui selector always launches in one-sided mode (although the start parameters are correct) and always switches to two-sided after closing it again.

 

This is all pretty confusing...