Search the Community

Damn, I hate Windows-specific problems, it means horribly slow compilation and link times. At least if it is replicatable it shouldn't take too long to investigate. Yes, it will be the standard tree/preview/infotable combination. Not sure about the doubleclicking though, it is quite easy to accidentally double-click and loading a large number of textures can take a long time (I need to add a modal progress dialog for this, rather than just blocking the GUI for a minute).

Because the developers are from here. Actually I live kind of next door to them. I also applied for a job with Piranha Bytes some year ago, but they don't want to pay. The boss said, that they rather go with students, because they work almost for the honour and only small money, while I have to pay my expenses. I guess he also didn't think I were suited to the game industry because my resume showed only application development. As if that would make much difference. And no, I wont get it anytime soon. With Gothic I there were so many problems with the copyprotection that it barely run, so I waited on G2 until it matured. By the time it was also cheaper and I saved me the hassle.

Doesn't work (package is not found/known) , that's why I compiled it myself in the first place. I will do a search on ubuntu forums and see if there is anything useful. The Synaptic package manager doesn't list anything like that either. edit: Ok, I found this package on a debian site and could install it after installing the dependent gtkglext1 package. DarkRadiant is booting now, seems like I can be coding again soon.

I've finally installed an ubuntu dapper drake and it took me less time than I expected (two to three hours I think till I could start to work on DarkRadiant). After downloading dozens of development packages DR compiled without errors, but it refuses to run displaying this: /home/greebo/darkradiant/install/darkradiant: error while loading shared libraries: libgtkglext-x11-1.0.so.0: cannot open shared object file: No such file or directory I checked my PATH and it points directly to this file above (it's located in /usr/local/lib), and I even tried to copy over this shared object into the install/ folder of DarkRadiant, but it changes exactly nothing. Is there something I missed? Is it possible that the version of the libgtkglext file is different to the one DR expects? (I downloaded the gtkglext-1.2.0 package and compiled it). My PATH is: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin: ... /games:/usr/local/share/include/:/usr/local/lib/

Now that our attachment system is up and running, we need some more things that AI can wear! Specifically, we could use medieval-style hats and different helmets. You would need to use one of the D3 heads (head_player is good by default) to get the size right (leaving some room to avoid clipping is desirable). If making a helmet, please use the same metal textures as used for our current armour where possible. Reference pics (hats): http://www.globaleffects.com/C_pages/Renta...hcHat514_hi.jpg http://www.medievaldesign.com/cappelli/cappellolanabig.jpg http://www.medievaldesign.com/cappelli/felthatsbigg.jpg http://www.medievaldesign.com/cappelli/baghatbig.jpg http://www.medievaldesign.com/cappelli/pointedhat.jpg Reference pics (helmets): http://erif.org/3dmodels/images/helmet_roundtop.png http://mywebpages.comcast.net/calderon/image343.gif http://forums.thedarkmod.com/index.php?showtopic=1014 We're also going to be looking for other things that AI could wear that could be attached to them separately. Ideas off the top of my head-- braids/ponytails mohawk large beards horns/antlers (pagan head-dress) bear or large bird skull (pagan head-dress) Bracers/bracelets Spectacles hoods

I just got my mail and opened up the import box sets I ordered from UK - the Icewind Dale "3 In 1 Boxset" and Baldur's Gate "4 In 1 Boxset", so now I have them all! should I play the BG series, or IWD series first? I'm leaning toward BG Should I use the BG1Tutu deal? Are there any problems with that program? Is BG2 engine/graphics really that much better, or what would I be missing/getting? From reading their forums and stuff it seems that it works pretty good but is not perfect.

Yes, but we're going to run into organizational problems with this. Suppose I have 3 elite city watch in my map, with two D3 heads and a default head. I'm going to need to make one elite city watch entity with the def_attach1 line, and one without, or else the default head will have two helmets. It gets even more confusing if I want to have different helmets for different heads. I guess the default ai.def would just have no def_attach1 line, and we'd add it in using the editor to each entity as needed? Doesn't seem like the best solution, but I can't think of a better one.

Ok, the basic XMLRegistry system is working and committed now. The "show all light volumes button" is already using the new system. edit: The code is now cleaned up and documented. Next step would be trying to port some of the other globals into the registry and see what problems arise or which interface functions are missing. But before that I will wait till you had a look at the code, in case I made some mistakes.

Good news: I could add three child nodes from three different XML files to the node. One of these was the node from doom3.game, and the other two contained tags, so I ended up with two tags under . The result looks like this: <darkradiant> <game type="doom3" ... patchtypes="doom3 def2doom3"> <filesystem> <shaders>...</shaders> </filesystem> <defaults></defaults> <entityInspector></entityInspector> </game> <ui> <toolbar name="standard"> <separator/> <toolbutton name="open" action="OpenMap" tooltip="Open a map file" icon="file_open.bmp"/> <toolbutton name="save" action="SaveMap" tooltip="Save the current map" icon="file_save.bmp"/> <separator/> </toolbar> </ui> <ui> <toolbar name="test"> <separator/> <toolbutton name="test" action="bla" tooltip="Open a map file" icon="file_open.bmp"/> </toolbar> </ui> </darkradiant> This whole xml::document is stored in memory and can be assembled during DarkRadiant startup. I could retrieve the toolbar named "test" via the following XPath: ui/toolbar[@name=test], so the concept works. Basically we can throw just any XML file into this global document and use it as registry - as long as the container structure is the same, it doesn't matter which XML file the information originally came from. I would suggest writing functions that allow random XML files to be added with a single function call during program start, so that this unified XML structure is created. The second part is writing a small API additional to findXPath to make value lookup and manipulation easy (the findXPath method is fine for lookups but its result still has to be interpreted). I would prefer to have two functions like getXmlRegistryValue("ui/state","show_light_radii") and setXmlRegistryValue("ui/state","show_light_radii","1"). All the safety checks could be delegated to these two functions, which would be much more convenient for the handling of a global variable. For more complex queries like the ones in the EntityInspector the findXPath() can still be used. Nothing of my suggestions is implemented yet, so what's your opinion on this?

Yep, it doesn't take long with any of the bots before they become depressing. The thing is, yes ALICE is obviously primed like crazy, but the 2005 winner(?), Jabberwacky, is simply *terrible*. Try having a decent chat with it. Do anything besides answer it directly with simple answers and you start getting crap like "where am am in they bee-knee". What? Maybe it's more sophisticated as far as code and interpretation goes, but it's just ass-dumb and nonsensical. Not to mention with learning from people, I'm sure more than half of its "knowledge" is the result of pranks and illiteracy. Nevertheless, I can't resist going and trying it out again... Edit: HMM. I'm going to back off on that assertion. Jabberwacky does seem more sophisticated than I remember, and there are definite updates and changes (even putting in reaction and emotion with your statement). I'm 10 lines into a conversation (not much yet, but they usually start to suck by now! haha) and he hasn't done anything stupid -at all- yet. Quite the opposite: Simple, but not stupid. Pretty cool. To give it a try: http://www.jabberwacky.com/ Edit2: ...and of course now the conversation is lost, because of the constant problems staying connected to that site - good to see that hasn't changed. I didn't get to hear the answer to the program question, which was going to be followed up by "Are you a human?", which invariably leads to the "You're not a human, I'M a human!" stupid argument. Another neat one: Edit3: Heh, I see how it works. Whenever it can't come up with an answer to a question, it times out. Edit4: Another funny thought: with "271 talking" right now, I sometimes wonder if instead they just route user questions to each other, and there is no AI.

I thought you might run into that. As you have noticed, the lights are rendered by the entity plugin which has no access to the state of the toolbars or other Radiant config widgets. There are three solutions which spring to mind: 1. Use some horrible "extern" global variables that can be accessed by both entity.dll and DarkRadiant itself. I don't recommend this (I have never done it and wouldn't know how to) but sharing variables between DLLs like this is an option. You might also run into problems with calling conventions across platforms (underscore versus no underscore in symbol names et.c) if you do this. 2. Add an extra function to the Radiant Module interface (include/qerplugin.h) to allow modules to query the state of the UI, just like I did with getXPath(). 3. Merge the ui and game XML trees like we discussed, so that modules can get UI state by looking up paths like GlobalRadiant().getXPath("/ui/state/showAllLightRadii") in the same way they can look up game paths. In the long run I think (3) would be the best, but if the merging of XML structures is not so easy then (2) would be acceptable.

That sounds cool, but with our own AI varying in different sizes...will all the heads still be interchangable? I'm thinking we might see some problems between our smallest and largest AI.

Hmm, I've discovered a problem. There's weird proportion discepancies between our models that is causing problems when attaching heads. The D3 heads all look too small when added to the citywatch, though they look the right size when attached to the builder guard. In order to make sure there is no space between the neck and shoulders on the citywatch, I have to put the heads at an offset of -10.5. It's possible the heads wouldn't look quite so small if I could leave the necks longer, but that won't work the way they're currently set up. And when I compare the two heads, the default citywatch head is definitely bigger. edit: Hmm, it's slightly more complicated than that. The D3 heads are not uniform in size. It looks like the npc heads (betrugar, swann, etc) are larger than the other heads, sometimes by a significant amount. As you can see in the second image, the head on the left is a good size for the builder guard, but the head in the middle is too large. What it boils down to is that the D3 heads won't be quite as flexible as I hoped...some of them will only fit properly on particular models and won't work on others. It will take me some time and testing to see where they will work and where they won't. When it comes time to do our own heads, we'll have to make sure they're a good, flexible size.

First of all thanks for reading through the code, I will do my best and will update the files as soon as possible. Yes, I suspected something like that. I will test if it is sufficient to stack-allocate the class or if this causes problems with the GtkToolbar instances (but it should not, as the GtkToolbars are pointers to GTK-allocated objects, aren't they?). I don't know if this is a memory leak as well: I store all the created GtkToolbar* pointers in a std::map, do I have to clear that one in the destructor of the class or is this done by C++ routines automatically? Ok, I was unsure about that one, I will change this to ui, makes more sense anyway. Ok, so in general, I should not use const char*? I will change this, no problem. I know about that one and I tried to change it once to xml::Document& but it somehow didn't work so I left it, knowing that it is copied into the call stack. I will look into it and iron this out. Ok, no problem, the path to the file is passed to the constructor, so this should be easy. I obviously mixed this one up. I will change the methods to lowercase beginnings. Will change it too, no problem. Yes this should indeed be possible. At first I kept the files separate because GtkUIManager did not like the XML definitions to be encapsulated by another container (it expected the tag to be the root tag). Now that I kicked out GtkUIManager this should be no problem, we just need to store everything within a top level container, in accordance to the XML definitions, like this: <darkradiant> <game> </game> <ui> </ui> </darkradiant> But on the other hand, we take the risk to mix everything into one file (as you said above, the UI is not game-specific) that maybe hard to maintain or overview if it is getting larger. And thanks again for providing the feedback!

Yeah, I'd like to be able to attach helmets, but we'd have to solve two problems...how does the KO system detect a def_attached helmet, and how do we get it to register collisions from arrows and the like (actually, I can't remember if that last one is still an issue or not--I have this vague memory that def_attached objects are non-solid, but obviously the weapons aren't... BTW, I think I can salvage a few more heads with some creative texture modifications...stay tuned....

Yeah, I'm keeping a list of problems & stuff as I find them: http://forums.thedarkmod.com/index.php?act=S...t=4651&st=0

Always assume the CVS as the very last to be causing problems. CVS is quite stable for a VERY long time.

Yet another thread about progress or the lack thereof. Models listed are at least started. Builder Guard As taken from Springheels thread. - clipping of legs through armour when walking (in progress) - hand texture needs modifying - hand size is rather small (in progress) - walk animation is borrowed from proguard so reposition sword bone so it doesn't go on the hip. walk animation is no longer going in circles but now he wanders & changes direction randomly City Watch - rigging touchups (messed up mesh, detached triangles, where the chain mail material is applied FIXED) - more mesh to the neck - fix idle & other animations. The arms & hands clip through body. - cvs commit - figure out why head is showing as black box - separate mesh where chainmail material should go - has mitten hands & head detached City Watch Elite - figure out why head is showing as black box (bb-head) Stupid mistake. I had an older, conflicting def file using the same head mesh - may need to add more mesh to the neck on the main body after fixing bb-head. - update on cvs - has mitten hands & head detached Proguard - resized - detach head - mitten hands - delete weapon from mesh Thief - rigging tweaks may need more tweaks but it's good for now - mitten hands - detached head General - spinning"helicopter" AI (walking animation problems) - WIP (borrowed from proguard) http://forums.thedarkmod.com/index.php?showtopic=3916&hl= - fix head meshes to better fit bodies.

I'm somehow feeling where this thread is leading to... I think I will be able to choose my distro myself. Concerning the toolbar icons: it looks like there is light at the end of the tunnel; it seemed that I forgot to call a gtk_widget_show on the added icon, which is strange, because in ModelPreview.cpp there is not a single call to gtk_widget_show() whatsoever and it's obviously working without problems.

Also I'm not really in favour of locking thread just because they go offtopic. I always hate it when this happens in other forums, but human discussions are not as narrow minded as a forum tries to induce.

There should be a separate mage character, though I can't remember what stage he was at in development. This isn't an in-game shot, by the looks of it. There are three mage*.lwo files in Odd's pack. http://forums.thedarkmod.com/index.php?showt...411&hl=mage There's an eliteguard.lwo was well, along with all the textures. He's the one on the middle in this in-game shot: http://www.mindplaces.com/darkmod/guards.jpg Oh, and I forgot to add the noblewoman to the list. She was already in-game with a couple animations at one point.

I see what the problem is, but I don't know what's causing it. All the thief textures and meshes have moved back to models/chars/thief after the last update, as opposed to being in models/md5/chars/thief where they should be. I saw a lot of "moving thief1x.x to make room for thief2x.x" kind of messages while downloading, but didn't pay much attention to them since I've seen them before. But this time they actually seemed to mean something. Anyone know why this folder keeps moving? edit: actually, that didn't solve the problem. The error message I'm getting is: "...tdm_ai_thief.md5mesh" joint names don't match anim "...af_pose.md5anim"

Update should be fine. You don't need to checkout, becuase that is supposed to be done only once. After that update is enough. But you should look through the options and check the options that make sense (like resetting any sticky tags, deleting old stuff and creating new directories). Most options should be pretty obvious anyway.

It was manually resized in Maya. If anything, it's resizing in Maya that will cause the most problems. The def file setting is the best. No, I just do exactly what I said. I only work on the DarkMod on one computer. But I haven't been using the "checkout" option, just clicking "update" on the entire folder. When I switched to tortoise CVS I forgot about checkout and just thought update was the way to go. So I'll use checkout from now on. Well I'll check that from now on. But the local output from CVS in the console was that the files were uploaded and the operation had finished.

They likely had the same problems and doing it this way is less timeconsuming.