Fidcal
-
Posts
16801 -
Joined
-
Last visited
-
Days Won
21
Posts posted by Fidcal
-
-
I just never think about binding keys to these commands! Good idea. Though I'm short of keys I can use some.
BTW, is it possible to create a separate textfile list of commands named say go.cmd and then just enter 'go' in the console?
-
OK, did a quick check of the wiki under console and commands earlier but not a full search. If I do a short list I'll add a link to the user settings and also add an extra link in the main list pages.
Anyone think of any other important ones that betamappers should know?
-
Wow! That is awesome - much better than in Dromed. Seems to me that there are certain commands and cvars that all DM betamappers ought to be aware of. I have a full list but I wouldn't know where to look and many might not even imagine a fly mode. Suppose someone finds out after five years struggling? Maybe there is a case for a favourites list or betamappers short list on the wiki? Maybe also include the full lists if that is not copyright. DM wiki should be self-sufficient if possible.
For example those for testing visportals (I have to keep looking them up myself) and notarget, god, etc. If there is no object I'll start a wiki but if anyone would like to post here their top 10 most used console commands with good description of what they do then I'll add them - or add them direct once I get it up (perhaps I should rephrase that.)
Betamappers Need To Know Console Command And Cvars:
god = god mode. Will not take any damage. *
noclip = fly in game for testing. Use movement keys to go up/down where pointing. Goes through solid. Stays put so you won't fall when stop moving. *
notarget = AI ignore you (though they will notice suspicious things like extinguished torches.*
r_showPortals 1 = shows visportals as wireframe in-game for testing, red is closed, green is open.
r_showtris 2 = shows what is currently rendered as wireframes.
r_useScissor 0 = shows geometry outside the visportal rectangle that Doom still sends to the video card but tells it not to render. IS THIS IMPORTANT ENOUGH? WANT TO KEEP THIS LIST SHORT.
* Only effective when map already loaded and need to re-use each time map loaded.
-
This camera movement through DR is great. When right clicked I can move freely turn and strafe and rise and fall just with mouse and cursors. Was it always like that? I knew about the mouse but I had been using it mainly just to look round and then disengaging it to use the cursor keys, strafe keys, and rise and fall keys, and tilt up and down view keys! Phew! Those DoomEd keys were conceived by an octopus. I had been thinking of changing those keys for a long time but not until I was familiar with the main other defaults in DR. Now I don't need to.
PS, Is there a fly mode in game itself like in Dromed? Having to run and climb everywhere to test a mission would be slow in some missions.
-
With mass cloning it might not be too 'difficult' to make a very large bland and repeating test map with about 50 stacks of 2 x 2 miles each about 200 foot high that's 100 x 100 miles or 10,000 square miles. Big enough for ya? Problem as said is handling the file size but it illustrates that the only limit is labour, imagination, RAM size and so on.
[EDIT] Plus I don't know if there's a pathfinding limit like in T2
-
@greebo: Thanks, yes. I've added it to bugtracker.
@MrMike: Ah yes, - thanks I'd forgotten those buttons.
-
OK, thanks Badcogg. So just needs sorting in the def file. Hadn't realized you can just hit the initial letter. And I see a little search input appears too.
-
What determines the order in the create entity list? I usually struggle to find AI then I just realized it's probably because the folder is capital AI and maybe if it were changed to ai then it would be OK. But inside that I see these which do not seem to have any alphabetical order....
atdm....
Builder
Guard
atdm.....
atdm....
Undead
Non-Comabatant
Belcher
Pagan
Spider
-
OK, got it thanks.
-
There are some great textures to choose from. There are a lot of stone and brickwork under the floor section. I wonder if they should be under the wall section - especially as there are one or two window apertures. If I were searching for a wall texture I probably wouldn't look under floor - but if I wanted a brick or stone block floor I probably would also look in the wall section. (probably this para should be posted in a different forum?)
While looking for stone floors under media I naturally clicked on a great many to see the picture. When finished, all of those were then entered into the texture selector even though I didn't want them. I think they disappear next reload if not used so maybe that is not a problem. But having searched for my texture and selected it in media (to view the picture) I then had to search through the texture selector to put it on the surface. I wonder if it would be better if it went straight on the surface from the media selector. So the media selector does not primarily and only select what goes in the texture selector but actually selects what you want to put on the selected surface. The texture selector then becomes just a shortcut to already-used textures. Does that make sense? Just my two cents.
-
OK - done!Thanks Fidcal for your efforts, I will try to reproduce that. Please open a tracker entry for this, so I won't forget about it.
-
I've made a second pass and it crashed within two places of last time so I'm assuming that I made some clicking error and its really the same. This time I did not count but just opened everything and clicked everything once all the way down to where it crashed before and I was two short of the place at bc_chest3_lid in containers whereas the first time I just reached the wearables section. (note this is not the same as when I did this before where I was almost randomly moving about.) But I may well have missed one or clicked something twice somewhere.
So there is no doubt, the above were clicks including clicking on folders once and then clicking on the + sign on the left - that's two clicks that strictly speaking doesn't select anything (nothing new appears in the 3D view I mean) but I think there are other sub sections like armchair1 that are selections but also have a + sign. I reckon roughly 570 actual model selections.
There's a quicker way to crash this iin probably less than two minutes. Open every section in the dark mod models down to darkmod > props > wearables without actually selecting anything then select dark mod at the top and tap the cursor down key quickly. If you just hold the key down I don't think it works as it then it skims over many selections. Just quick taps and it will 'soon' crash.
I should mention I am using DR v.0.9.0 Build date April 26 2007 17:45:25.
-
Made one pass but I'll resume later it is much slower when keeping count and keeping focused so can't face another pass without a break!
So far 585 of which 50 are opening + subfolders. All mouse clicks. I doubt I was more than one or two inaccurate so if the next pass approximates that then I think we can accept it's the number of selections.
-
These are the last few lines of the console and in radiant.log...
RenderablePicoSurface: using shader textures/common/collision
RenderablePicoSurface: using shader cutlery_ornamental
RenderablePicoSurface: using shader textures/common/shadow2
RenderablePicoSurface: using shader textures/common/collision
RenderablePicoSurface: using shader tdm_cart01
I've done this maybe three times and I'd guess each time it took 3 or 4 or 5 minutes of selecting - the last time with perhaps an hour's lunch in the middle so not just time but as suggested, probably number of selections. I've also mixed mouse clicks with scrolling up and down with the keys - sometimes pausing on a selection; sometimes whizzing past many - so I don't know if they count as selections.
Anyway, I'll now try sparhawk's ideas and report later.
-
No - it crashed again but the output just referenced the last model which in this case was the water pump. I suspect you can always get it to fail if you laboriously work through - but whether that is just time. I'll leave the model selector open while I have lunch......
-
I don't mind going through every one in the list again trying to make it happen if it helps. But remind me again about output. I know there is radiant.log in docs and settings. But wasn't there some other output? Or is any of this likely to be helpful?
-
This happened to me yesterday too. I was going through all the models too see what was already available before posting on the models wanted thread. I can't recall the exact model it crashed on but I did remember it at the time and noted that when I reloaded DR and started again I skipped through to just before that and continued through it without problem. I eventually got half way through the Doom ones before I started skipping quickly to the end. It wouldn't surprise me if you start at the beginning and try to go through the lot... Haha!
BTW I note that it takes quite a while to open the list when first used and it hangs half way through for a few seconds. I just assumed that it was because the list is getting so huge. Maybe it could be broken into sub-lists so there could be divisions in the selector somehow? I don't know how the data is stored but if it were divided into min type-selectors? To the user it would not be much different (edit - any less convenient I mean) to selecting different parts of the tree. Dunno how that might work but just a vague thought..
-
Ratty: I've now posted my TDM review over at TTLG HERE if you want to get the flavour of playing through TDM missions.
-
Haha - Just waiting for the go ahead - but it's got better since I wrote that.
-
I don't think this should work anyway but trying to parent a brush directly with a model door entity gives the error: "The instruction at nnn referenced memory at nnn. The memory could not be read. Click on OK to terminate the program." Shall I add to bugtracker?
-
Yes both same door model, greebo.
Well, this might give a clue as to where the flaw lies maybe. I just reloaded the test map and the rogue is now in the normal correct position. Rubbing my eyes I created a new door and on this one the origin showed in the wrong place again. I then saved the map and instantly it was corrected. Maybe that's why I never noticed before since I save very frequently. Since the doors work OK in game it presumably is a temporary display glitch but is reproduceable. Let me know if you want any log output or whatever or an entry in bug tracker.
-
I've been creating model doors by two methods with no problem that I noticed:
Create brush, give it atdm:mover_door, select model in entity inspector and click button 'Choose Model'
Or...
Create model, edit the name func_static to atdm:mover_door
But now I find with the first method I see the origin point appears in DR to be way out - maybe 25 units to one side and some 1500 units high. Yet both doors work fine in the game. There is no other entity listed in the entity list. I've rebooted XP and started with a fresh map but still the same. This is the top view HERE as the side view the origin is too high to get in the same image.
I can't understand when this started as it could not have always been like this - I've made a hell of a lot of test doors and done a lot of rotating testing where I've paid attention to the centre of rotation.
-
What s & r is working in the mod so far that I can test?
Firstly I've tested the damage stim by applying a stim to an object with various parameters then approaching it, contacting it and the player reacts sensibly to the settings so that's fine.
Next I thought I'd stick with damage as I know it works but test applying a response from another object. I made a house model added houseStim, radius 300, mag 10, duration 1000. Next I made a crate > 300 units away and added a houseStim response : Damage > Info_Player_Start > entityDef damage_fire
In game I carried and dropped the crate next the house but can't get any response. What more is needed? Or have I misunderstood how it works? Or both!
[EDIT] I saw my error the moment I posted this. Forget 'duration' - I changed that to 'interval' - what was I thinking! But it still doesn't work so... ?
-
Just sent off for a couple of gigs of RAM as I'm getting lockups with DR plus Doom plus a few other programs running all at the same time with 500Mb RAM.
I've noticed big missions take quite a while to load. Presumably most of this is processing time as the data is read in. In memory is this data in such a form that DR could have its own save format which would be the processed data? This would use more disk space but load and save faster. The mapper need only save as a map file to test. Just a thought. Not sure if there is any real value in that. Probably depends how often mappers open and save without actually testing.
Itches, Glitches & Anything Else...
in DarkRadiant Feedback and Development
Posted
Wonder what would happen if I bind several commands to one key....