Itches, Glitches & Anything Else...

[greebo]

Didn't info_player_start use to have an arrow pointer to indicate which way it was facing?

 

On loading a map the camera seems to start at info_player_start's origin but this origin is at the bottom of info_player_start so the camera always starts embedded in the floor for me.

 

Yes, this is the default GtkRadiant behaviour when no other information is available.

 

DarkRadiant saves the last camera position and angles into worldspawn, once you save the map in DR.

 

The DarkRadiant priority is as follows:

- Default: Find worldspawn and use editor_drLastCameraPos spawnarg

- Fallback 1: Find info_player_start and use the angles spawnarg (camera at origin facing in this direction)

- Fallback 2: Place camera to info_player_start origin (angles are missing, hence zero)

- Fallback 3: Set camera to 0,0,0

[Fidcal]

It'd be fine if the info_player_start origin was at eye level No biggy. I've raised my info_player_start until the map is finished.

[greebo]

The player start probably won't be referenced in your map anymore. Once you saved your map using DarkRadiant, the last camera position gets saved into the worldspawn. Next time you load the map, the camview is just as you left it.

 

But I can raise the default camera level just as fine. Feel free to push this into the bugtracker.

[Fidcal]

Will do. If you can raise the camera by about the height of player start.

[Fidcal]

Just got to the point in my wiki tutorial where it says the player start does have an arrow pointer! Is my DR broke? I do not get the direction arrow any more. Perhaps there is a setting?

 

[EDIT] HOLD IT ! - found it immediately - show angles! That is one of the settings I couldn't figure out in the controls wiki so I can add it there now too.

[angua]

Will do. If you can raise the camera by about the height of player start.

Done and on SVN. The starting position will now be at the top of the player_start if there is no saved starting position.

(I'm about 2/3 through "Teach yourself C++ in 21 days" and I got an Introduction To DarkRadiant by greebo, so in the end it wasn't even too difficult.) Greebo committed the changes to SVN (I haven't got write access yet).

[Fidcal]

Thanks angua. Best of luck with the book. I got about 100th of the way through a couple of M$ofts books on C++ then threw myself off a bridge right on my head.

[New Horizon]

Done and on SVN. The starting position will now be at the top of the player_start if there is no saved starting position.

(I'm about 2/3 through "Teach yourself C++ in 21 days" and I got an Introduction To DarkRadiant by greebo, so in the end it wasn't even too difficult.) Greebo committed the changes to SVN (I haven't got write access yet).

 

Wow, that's awesome angua. The two of you can do anything. I'll have to pick up that book myself...I've always wanted to learn C++. Is that a "Sam's" Teach Yourself book? Oh, and did you get my facebook invite? I got a response from Greebo, just wasn't sure if my invite to you went through.

[Fidcal]

Actually, that gives me an idea for a subtitle for my AZ Guide "Teach Yourself Dark Mod In One Day!"

[angua]

Wow, that's awesome angua. The two of you can do anything. I'll have to pick up that book myself...I've always wanted to learn C++. Is that a "Sam's" Teach Yourself book? Oh, and did you get my facebook invite? I got a response from Greebo, just wasn't sure if my invite to you went through.

Thanks! (Well it wasn't that much of a big deal after all ) I don't know where the book comes from, greebo downloaded it some time ago when it was freely available on the net.

Didn't see your invite before, I've added you now as a friend

 

Actually, that gives me an idea for a subtitle for my AZ Guide "Teach Yourself Dark Mod In One Day!"

That sounds great!

[New Horizon]

Thanks! (Well it wasn't that much of a big deal after all ) I don't know where the book comes from, greebo downloaded it some time ago when it was freely available on the net.

 

Cool, what language is it written in? I might be able to find it online somewhere.

 

Didn't see your invite before, I've added you now as a friend

 

Thanks. Great to have you guys on there. If you and Greebo ever visit Canada, come to Prince Edward Island. My wife and I will treat you to dinner, and we have a spare room if you needed a place to stay.

[angua]

Thanks for the nice invitation, if we get an opportunity to come to your place, we'll do so.

 

The book is on ftp now (why should you spend time on the net searching for something we already have?)

http://208.49.149.118/TheDarkMod/Tutorials/cpp_tutorial.rar

[New Horizon]

Thanks for the nice invitation, if we get an opportunity to come to your place, we'll do so.

 

That would be lovely. Mary and I love to entertain guests.

 

The book is on ftp now (why should you spend time on the net searching for something we already have?)

http://208.49.149.118/TheDarkMod/Tutorials/cpp_tutorial.rar

 

Perfect! Thanks so much.

[greebo]

@OrbWeaver: I fixed a few (minor) crashes on shutdown due to the order the GTK window widgets were destroyed. I hope it didn't interfere with your working copy too much.

 

I also saw the new TransientWindow hierarchy, which surely seems like an improvement. Is there anything I'll have to watch out for?

[OrbWeaver]

I know about those GTK warnings, my plan to fix them properly is to get rid of the requirement for Radiant to shut down all of the inspectors itself (which, as I put in t TODO comment, actually results in all of the dialogs being instantiated on shutdown for no good reason) and replace this by a event listener model, whereby each of the inspectors registers itself with GlobalRadiant so that a callback can be invoked on shutdown.

 

I made a first attempt at this today, but got tangled in all of the pointless spaghetti when trying to fix the Radiant module implementation into a single class (rather than both RadiantCoreAPI and Radiant) and gave up; hopefully I can make a more successful stab at this soon.

 

I haven't finished with PersistentTransientWindow either, my current plan is to move all of the WindowPosition code into this class as well so all of the dialogs don't need to maintain their own WindowPosition object (which does exactly the same thing in every class).

[greebo]

I know about those GTK warnings, my plan to fix them properly is to get rid of the requirement for Radiant to shut down all of the inspectors itself (which, as I put in t TODO comment, actually results in all of the dialogs being instantiated on shutdown for no good reason) and replace this by a event listener model, whereby each of the inspectors registers itself with GlobalRadiant so that a callback can be invoked on shutdown.

Ah, yes, that's a good idea. I wasn't too comfortable with writing down that list of shutdown() calls back then.

 

I haven't finished with PersistentTransientWindow either, my current plan is to move all of the WindowPosition code into this class as well so all of the dialogs don't need to maintain their own WindowPosition object (which does exactly the same thing in every class).

That's also something I didn't get around to do. I thought a few times about merging shared Inspector methods together to create some sort of "FloatingDialog" class which handles the windowposition, callbacks and the XMLRegistry stuff, but moving them to the TransientWindow hierarchy is just as fine.

[Fidcal]

Finding an unusual frame lag in my small kitchen I investigated and found 117 clones of a kitchen table! No way did I do that by accident. Don't think my space bar jams down and if it did I don't think it would repeat clone? The table was one I had reduced in size using the rotation hack so I don't know if that is relevant. If there is no obvious explanation maybe leave it for now and see if I or anyone else gets this [again]?

[angua]

While I'm here - another thing that is starting to bug me. I've mentioned before about the camera speed for fine tuning and you kindly reduced the minimum to 1. Now I'm finding I am frequently switching between high speed and low speed as I am spending more time mapping. I can't imagine how people manage with one speed. Is there any way to have some sort of shortcut? Maybe two speed settings and a hot key to switch between? Or maybe better, just the one speed setting as now but slider keys like the keys that zoom in and out the grid size, to increment/decrement the camera speed.

I thought that this is a good idea, and I needed an easy (more or less ) programming task anyway to get me started, so I implemented this. Currently two keys are used to increase or decrease the movement speed by a factor of 2. It's not on SVN yet.

[Fidcal]

Ah, good one angua! Dark Radiant is certainly very versatile!

[greebo]

I just replaced the ModelCache (in referencecache.cpp) by a std::map-based container. This was the last occurrence of the old GtkRadiant HashTable. The cleanup is still to come, but it's technically gone.

[OrbWeaver]

Ah, I didn't realise there were still GtkRadiant hash tables in use. I never figured out that reference cache stuff anyway, it seems to be some convoluted circular way of treating maps and models as the same thing.

[greebo]

Yes. It defines maps and models as "resources", but in the end it's just a bunch of IFs and ELSEs. MapResources are recognised by their ModelLoader* pointer being NULL. Don't know why this was implemented in this way, maybe this was a good approach for other game engines, but for Doom 3 it's just plain complicated. This should be redesigned as well.

[OrbWeaver]

Back when SPoG used to support GtkRadiant, he once mentioned that the idea was that you could have a func_static with "model" "maps/something.map" and it would import the map automatically as a model. Since no games support this AFAIK, it seems like a phenomenal waste of time in my opinion.

[greebo]

Ah, ok, I thought he must have had some purpose for that in mind, but of course, it was a bit daring to implement such a system in an editor, when no game is actually supporting it.

 

If you feel like we should revamp that Model/Map resource manager, feel free to post your design. No need to hurry though, as my hunger for code butchery is satisfied for now.

[OrbWeaver]

It's not a particularly urgent issue anyway, the reference cache does do its job even if the code is not the nicest.

 

The next target for redesign will probably be the scene graph, since this underpins all of the performance issues in the renderer and selection system (although the selection system also needs its own redesign). This will of course require considerably more design effort, starting all the way from high-level requirements.