greebo
-
Posts
16733 -
Joined
-
Days Won
51
Posts posted by greebo
-
-
It did not work at first, the plane coordinates did not change after the creation of the entity (it got moved after re-opening the map file in DarkRadiant).
I could track the problem down and solve it by changing this (in map:cpp:1767)
Brush* brush = Node_getBrush(path.top()); if (brush != 0) { // We have a brush, apply the transformation brush->transform(_transMat); }to
Brush* brush = Node_getBrush(path.top()); if (brush != 0) { // We have a brush, apply the transformation brush->transform(_transMat); brush->freezeTransform(); }Now the brush coordinates get saved as well and the brushes stay in place. I will do some more testing and report if I find something more.
-
Cool, I will compile it right now and test it (after lunch of course
). -
Would you prefer the whole entity to be selected and moved as a single unit? This is what DoomEdit does, but I noticed in DarkRadiant the brushes are still selected and moved independently which I find a bit annoying.
At least for the readables it would make sense to handle them as a single unit as long as the texturing of the single brushes stays unaffected. I would vote for the DoomEdit solution.
I can't say if there is a case where it would be an advantage to move the child brushes of an entity independently as I've not that much experience with the Dark Mod entity types.
-
There is of course scope for a hack here -- just set the origin to "0 0 0", then no relative coordinates are necessary (because the func_static's origin will be the same as the world origin). I imagine this would be confusing to mappers however.
EDIT: Actually, is this really that much of a hack? Do mappers actually need an origin key for brush-based entities, or is this just something to keep the game happy?
The origin should really be in the geometric center of the entity brushes (at least for the readables), as the code for readables relies on this value.
If you placed the origin somewhere in the room next door (for instance) and frobbed the readable brushes, the onscreen readable would not show up in the center of your monitor. I can post a screenshot illustrating this if you want, I'm not sure if I'm explaining this clearly enough.
This also happens when I move the readable brushes away from where the entity was originally created, as the origin value of the entity is not updated when moving its brushes (at least in DarkRadiant). The onscreen readable would not appear where you expect it to, the center would always be directed towards the entity's origin, not towards the brushes. So, at the moment I create my readable and leave it right where they are. If I need them at a different location, I delete the entity and create a new one.
I also tried selecting the entity in the entity list and dragging the brushes around, but that does not work either, as the brushes are highlighted but somehow frozen as long as the entity itself is selected.
-
There seems to be another issue connected with the above one. If you create your brush-based entities in DarkRadiant and open up the map in DoomEdit it totally screws up your brush positions. It seems that the missing origin key is added by DoomEdit automatically on saving and the coordinates are not corrected accordingly.
This is kind of annoying, as all our func_liquids got scattered all over the map and we had to reposition all of them.
-
I'm experiencing some issues while creating readable entities with DarkRadiant. The problem is: when I create an entity out of my two brushes (the parchment and the entitygui) the "origin" key is not created by DarkRadiant. DoomEdit however does create the key (its value should be at the geometric center of the two brushes).
As a result, I'm unable to read the parchment, it never appears on the screen after frobbing (the screen fades out and in very quickly, as it is supposed to do). I suspect that the missing origin value is assumed to be "0 0 0" and the readable appears somewhere out of my field of view. As a consequence the readable_face_tolerance value is kicking me out of reading mode.
This problem only seems to occur when creating entities out of brushes, as lights and other entities that can be created without a brush selected (I tested with atdm:loot_vase) get their origin value set correctly.
I'm using the latest compile from SVN (but the problem appears in version 0.5.3 as well). Perhaps this is a known issue, but I thought I'd post it here. I can post the differences of the two map files (from DarkRadiant and DoomEdit), if it is helpful.
-
Another thing that I can't seem to find is the ability to project one brush face onto another. (except that you can project a brush face onto a patchmesh)
You can copy a brush face texture onto other brush faces by Ctrl-Shift-MMB (you have to copy the face texture beforehand). Or did you mean something different?
What I really miss is D3Ed's feature for copying brush face textures onto a patch (the MMB feature in D3Ed). I could not find any function like this in DarkRadiant, which is my main reason for switching between D3Ed and DarkRadiant at the moment. But I could imagine, that this would be a feature hard to implement.
-
Are you planning on finaly creating the Alarus Extention, complete with bow-upgrade?
rofl, yeah, I already thought about it... imagine, all the hopes and dreams finally become reality! Oh dear, I've got it all on my hands, should I spoil it completely...?
-
New screenies... we chose an octagonal room in the Bonehoard level, but this time we took ourselves a tad more "artistic freedom".
All the models and textures are custom (except for the little low-poly skull on the floor, which is a bit rough).
@OrbWeaver: yes, you're right, it seems to be a bug in DarkRadiant. The light_center value can be set in relative coordinates and the game is rendering it correctly, but the little green point is completely off track.
-
I added the light_center as a recognised property, so it can be edited as a simple vector3 (not yet committed to SVN though). It appears though that dragging the centre like in D3Ed is not possible, and it also seems to be using world coordinates which is a bit strange (unless D3Ed does this as well and I never noticed). I would expect that a centre of would be at the geometric centre of the light, not at the world origin.
Angua played around a bit with this option and found that the light_center values in DoomEdit are measured relatively to the center of the light volume. What we don't know is, if the values are being translated in the background by DoomEdit, where they could be saved as world coordinates. We can do some more fiddling with this to find out. Thanks though for adding the property!
-
Ah, ok, didn't know that! I never got my hands on the original Thief demo...
-
No you don't, you can use a precompiled binary
Oh, thanks for the link, didn't see that one... my first compile was somewhere around July 3rd, and I just synchronized with the SVN repository every second day since then. Scons does a good job on recompiling the changed bits. I'm still reading your code changes regularly, but I couldn't get myself into the position to change something myself (still planning to do something, but the recent mapping ate all of my Dark Mod time budget...
)Still, kudos on getting it compiled and running without any assistance. It's ironic that the only people to build anything substantial with DarkRadiant are not even members of the team.Thanks and kudos back to you, since you are doing the substantial work with DarkRadiant here, I suppose. We thought it would be best to get used to DarkRadiant, even if it's not as packed as the native DoomEdit. It's quite stable, I could only get it crashing once - but we are still far away from pushing the limits, I reckon.
Still, we fired up DoomEdit once in a while (e.g. for using the preview function of the particle effects). One thing we missed was the "light_center" property which is present in DoomEdit, since our light sources are all centered within the light volume for the moment. You can still add the property by hand (leaving a "unrecognised property") to get it working, but I did not get a grip with the appropriate coordinates yet.
What I really like is the new context menu in the orthographic view, that's a real plus!
Did you not have rope arrows at Baffords?I really can't remember. Actually in TG were the arrows handed out type by type, really slowly, like in TDS?
I only played TG two years ago or maybe even less...
No, there are no rope arrows at Bafford's even at Expert difficulty, but I admit that the wooden beams look really tempting. Ah, I can still remember my first thieving experience at Bafford's (frickin' 8 years ago), I ran around like a complete retard firing broadheads at random guards.
-
Hello all,
we (that's angua and me) fiddled around a bit with DarkRadiant lately and as this level creating thing is totally new to us, any feedback is helpful and would be greatly appreciated.
We know it's not very creative, but for getting into the "business" we thought it would be best to rebuild an original level, as the goal is to create something thief-inspired.
This is what we accomplished so far, I've included some "original" shots for better comparison:
[snip]
The whole thing was built from scratch in DarkRadiant, models > Blender, textures & normalmapping > Photoshop.
Thanks in advance!
-
My guess is that the cos() and sin() functions expect values between 0 and 2*pi, and not "real" degree values that are in the range between 0 and 360.
I think you have to convert your degrees into radian: rad = deg*pi/180
-
Is it just me or is the Darkmod Wiki down?
"This Account Has Been Suspended
Please contact the billing/support department as soon as possible."
-
Did you compile on Windows or Linux? I'm very pleased if it's Windows because it took a long time to get the build script working and it hasn't been tested on any other machine except mine.
I compiled it on Windows XP Pro, using ActivePython, MinGW, Scons 0.96 and GTK+ 2.8.18. I had to gather two DLLs from the internet to get Darkradiant actually running, as I could not find any package containing them (they were missing in GTK somehow). I could write a wiki entry or a standalone tutorial, if desired.
Do you prefer working on front-end GUI or back-end systems coding? I can certainly give you some ideas of things I want to do but I haven't really looked into many of them yet so there would be a lot of investigation needed on your part.I dont' know what would be easier to start with, just point me in any direction and I will see what I can do.
C++ is not difficult, but it is very unforgiving at times. You really need to understand the differences between (say) pointers, references and objects, the difference between virtual and non-virtual functions, local objects versus heap-allocated objects and so on. Still, the basic ideas should be familiar so for a reasonably experienced programmer it is just a question of learning the details.No problem there, I do know these differences
. I fooled around a lot with pointers twelve years ago in Pascal, but the concept in C++ is not very different, same with heap allocation. The concepts are clear to me, what I need is practice. -
You will need to get set up with Scons (which requires Python or ActivePython on Windows) and the GCC toolchain (available as MinGW on Windows). If you are on Linux you will need to get these tools from your distro. These will allow you to build DarkRadiant.
If you want to develop you will need to know C++, there is a thread in the public forum with people's suggestions for learning resources. I found http://cma.zdnet.com/book/c++/ to be quite helpful.
Ok, I have downloaded and compiled Darkradiant (from "trunk") and I had a quick overview over the source files. I played around a bit with the editor (even managed to crash it once, when I tried to stretch a texture to zero value, I think) and clicked through most of the menus. Where would it best to go from here? What are you currently working on and where could I possibly help?
I'm over halfway through the C++ Tutorial you linked, much of it seemed quite familiar to me (as I read a Turbo C book over ten years ago), but some parts were of course new to me (mostly the class inheritance part). Could use a bit more practice though
. I've quite some experience with classes from PHP, but those are much less sophisticated in comparison to the ones from C++ it seems. But it should not be too hard to get used to, I believe.That sounds similar to my programming background when I started, so I would think you could handle stuff like scripting with no problem. A lot of D3 is done with scripting, which is based on C++ but without all the features (no arrays or structures). We could maybe use someone to script some random player tools like flash bombs and telescopes and whatnot, and you could move up to working with the C++ game code as you got more familiar. On the other hand, it sounds like there's work to be done on the DarkRadiant project too.I'm motivated to help out with anything, really. All I need is some small task to get me started and perhaps some directions too, as I expect your code base to be huge and I would have to learn some tricks here and there. If you have the time to get me involved, it may pay off later, but I would understand if you would consider this as too tedious and time-consuming.
I even thought about helping out with texturing, as I have some Photoshop skills, but that would probably not good enough for your standards - and it would be too time-consuming for you to teach me, I reckon.
Would your wiki be any good for me in all these matters - Darkradiant, Scripting and such?
-
Thank you, I just had a quick look at the GTK+ 2.0 Tutorial which does not look that bad. Currently I'm downloading the entire darkradiant repository (takes quite a long time, I'd say).
This weekend I will have the time to dig into the whole thing - do you have any directions for me?
-
Hmm..that depends. Greebo - do you have any experience writing GUIs with GTK, or with OpenGL/graphics in general?
Sorry, no experience in that area... do you consider it to be hard to learn (GTK)?
-
Well, that depends.
I have gained programming experience in some languages since I was 12, when I started in Pascal and moved on to Assembler (I did quite a lot of system programming then). As a student I got to know C, FORTRAN and MATLAB, although I'm no wizard in these languages (but I can handle these, I think). I suppose you guys are primarily looking for C++ coders?
I know that this may not sound very good to you, as I have no C portfolio to show, but I can catch up really quick with things and I'm always eager to learn new stuff. At the moment, I'm studying Technical Physics, and I hope to finish my diploma thesis within the next year.
Do you have any specific problem you can show to me, perhaps? There may be an isolated (smaller) task for me to dive into things, at least I could have a look at it.
Of course, if you want to stick with really experienced C++ coders, I do fully understand, just say it then.
-
Are you still in need of such a tool or is this thread heavily outdated?
-
Does anyone know where I can find and download the following files?
Si3112r.inf
Si3112r.mpd
Si3112r.sys
SIISUPP.VXD
SIWinAcc.sys
TxtSetup.oem
Hi Springheel,
I have a similar Silicon Image controller on my mainboard, and I always downloaded my drivers from the Silicon Image Website. You may want to look at this (hope this direct linking works):
http://www.siliconimage.com/support/suppor...&ctid=2&osid=4&
Under "SiI3x12 32-bit Windows SATARAID Driver", a ZIP can be found that contains nearly all of the files above.
Besides, I would recommend a fresh install of Windows XP (after backing up your data, of course). Changing core-drivers like RAID drivers did not work very well for me.
I Cannot Post
in The Dark Mod
Posted
I'm having some problems too, everytime I want to Post or Preview in the Private Forums, a message occurs.
Edit: forget it, it's resolved now (the server or the server does not like the term "g plus plus" (the compiler name with the actual plus characters)...)