Readables Editor problem

[Fidcal]

I'm getting a problem that sheet paper with carolingia font is showing blank in game. It seems the editor is forcing this to be two-sided when it is only one-sided even if I use the radio button to try to change it. In the xdata it is putting the blanks in for the right side so this is what is stopping it showing anything. If I manually delete that then it is OK.

 

So how does the editor determine which is one and which is two-sided? Only books are two sided. Sheets and scrolls are all one-sided. Presumably it must deduce which from the gui.

 

But some sheets are OK so I don't know why carolingia is different. The gui looks OK although I've not compared it with others. As I recall I would have cloned all the guis when I made these and just changed the font and font sizes etc.

[STiFU]

I can't reproduce this in DR 1.4 x86. I create a readable entity, start the readable editor, open the gui browser, choose "guis/readables/sheets/sheet_paper_calig_carolingia.gui", enter a name for the xdata definition, add some text, hit save and close. After that I have a proper one-sided xdata definition in the respective file.

 

The only time the readable editor changes the page layout itself is at startup (of the RE). If there is no xdata definition on the entity yet, the editor simply checks the name of the entity. If that name contains the word "book" it switches to two-sided editing. If there is already an xdata definition on that entity, the according editing-mode is chosen.

 

You could try the Tools-button in the Readable Editor and start "show last XData import summary" and "show gui import summary" to see if something went wrong during parsing.

[Fidcal]

OK, I'll look at that.

 

Meanwhile I now realize in DR 1.5 it regards everything that it creates new as two-sided; everything. The only way to get round it is to create the blank xdata first, eg, by copying from the prefabs.xd and renaming the header. If I then open that readable in the editor it shows it correctly, and hopefully edits OK.

[Fidcal]

OK, created a scroll readable

Open editor and it shows the default two-sided book with nancy font.

Select mac humaine scroll and it still shows two-sided book

Tools > import xdata shows no xdata to import because it doesn't exist yet.

Tools > gui import shows:

 

Error while parsing guis/readables/test/book10page.gui: DefTokeniser: Assertion failed: Required ";", found "}"
Error while parsing guis/readables/test/book1page.gui: DefTokeniser: Assertion failed: Required ";", found "}"
Error while parsing guis/readables/test/book2page.gui: DefTokeniser: Assertion failed: Required ";", found "}"
Error while parsing guis/readables/test/book3page.gui: DefTokeniser: Assertion failed: Required ";", found "}"
Error while parsing guis/readables/test/book4page.gui: DefTokeniser: Assertion failed: Required ";", found "}"
Error while parsing guis/readables/test/book5page.gui: DefTokeniser: Assertion failed: Required ";", found "}"
Error while parsing guis/readables/test/book6page.gui: DefTokeniser: Assertion failed: Required ";", found "}"
Error while parsing guis/readables/test/book7page.gui: DefTokeniser: Assertion failed: Required ";", found "}"
Error while parsing guis/readables/test/book8page.gui: DefTokeniser: Assertion failed: Required ";", found "}"
Error while parsing guis/readables/test/book9page.gui: DefTokeniser: Assertion failed: Required ";", found "}"

[STiFU]

Ah, ok. So this is a new DR 1.5 issue. Good to know! I'll have a look.

 

Those gui parsing errors have always been like that. I don't know whether those are actually used or not. They should either be fixed or removed from TDM I guess.

[STiFU]

I haven't been working on the DR code for quite some time. Somehow, the debug build is horribly slow now. I am waiting 5 minutes already for the entity browser to show up and DR uses 440 mb of RAM and one core of my quadcore is fully used by the process all the time. This is a little weird. I'll try a release build later. Maybe that's faster...

[STiFU]

Ok, thanks for the report. Should all be fixed in rev. 6264.

[greebo]

I haven't been working on the DR code for quite some time. Somehow, the debug build is horribly slow now. I am waiting 5 minutes already for the entity browser to show up and DR uses 440 mb of RAM and one core of my quadcore is fully used by the process all the time. This is a little weird. I'll try a release build later. Maybe that's faster...

That's the VC++ STL implementaiton in debug builds (iterator debugging - great but slow) plus the impact when launching DarkRadiant directly from Visual Studio which switches the "debug heap" on. The debug heap is a great thing to immediately spot heap corruptions and such but it bogs down memory allocation/deallocation performance by at least one order of magnitude. As gtkmm is also using STL (I'm pretty sure it does) the impact has been getting larger since 1.5.0. The debug heap is also active when launching release builds from Visual Studio, btw.

 

You can switch the debug heap off when adding _NO_DEBUG_HEAP=1 to your environment in studio (Project > Properties > Debugging > Environment), but usually I just launch DR using one of my shortcuts and attach my debugger during startup.

 

The best performance is still achieved when launching a release build from Windows (not from within studio).

[STiFU]

Ahhhh nice, thanks. That speeds it up quite a bit. Awesome!