geegee
-
Posts
215 -
Joined
-
Last visited
-
Days Won
3
Posts posted by geegee
-
-
On 12/14/2021 at 8:06 AM, OrbWeaver said:
if your map isn't actually designed to be huge (e.g. a massive outdoor city area with numerous playable houses), and it still results in a package which is much larger...
The map was designed to tell a story and I think it succeeds. The playable area is large, perhaps comparable to that of Hidden Hands: The Lost Citadel, and like HHTLC has several visually distinct areas.
After converting 17 func_static light fixtures to models, and replacing about 70 func_statics in my map, the .proc file was reduced from 201MB to 188MB so a saving of 13. Zipped, the size went down from 24.6MB to 23.4MB for a saving of a measly 1.2MB. There's more that I can convert and for that I'm going to take your advice and study entity def's, and convert them into entities. I doubt these changes will have much of an impact on this map, but for my next FM it'll help produce a tighter and more optimized structure.
By the way, I use nurb curves a lot in my map. Perhaps that also goes into the .proc size.
eta: now down to 161MB, a cut of 40MB. This is going well and I've learned a new trick!
I noticed a small drop in fps in some areas, most to shrug off but one in an area where the drop put the map into the red (it was already too close). But I slept on it and woke with a visportaling answer (which had eluded me 'till now), making for a significant increase in fps in that whole sector. Yippee!
-
Yes, that's what I figured from the discussion. Copy/pasting around a func_static creates multiple un_precalculatable individuals whereas copying a model around creates multiple instances of what TDM pre-calculates to be one individual.
So I've spent the last few editing hours creating models of the statics. I don't know how to include a light and emitter in a light fixture model, so the models are just of the func_statics, so I use a sensible iterative naming formula to create a S/R trio of the grouped model/light/emitter. Now I can copy/paste that around, deleting the old func_statics as I go. That's going to take awhile, for sure.
I doubt I can whittle it down to anything like Painter's Wife size. Even if technically possible, which I doubt, Painter's Wife is a collaborative effort made by seasoned veterans combining many specialized skills. How could I possibly produce something that rivals the optimization of that? That's an impossible dream.
Thanks for staying with this discussion, OrbWeaver. I appreciate it.
I
-
43 minutes ago, Dragofer said:
One thing to consider is that your figure of 1.7 GB is probably in its uncompressed state, which isn't how you're going to distribute the mission, so I'd look at how much it weighs as a .zip.
ah, with the *_ed.jpg files deleted, the compressed size is 445MB. Painter's Wife is 174MB. I can see several ways to reduce size now, after this discussion, so I'll see how it goes. But the comments have been negative and I doubt I can reach an outcome satisfying the TDM community, so ... it's like seeing the finish line of a marathon and WHACK, a blackjack to the back of the head
-
10 minutes ago, Dragofer said:
I don't think you can compress env images as .dds, it hasn't worked for me in the past.
Too bad - it would have saved 70MB.
I think I read something about "only .tga for env files" way back when. When reading-and-doing, so following along and integrating, I tend to remember, but when I just read a tutorial and I'm not immediately doing, I tend to forget. Then it becomes a total mess and I have a cold beer.
-
1
-
-
1 hour ago, OrbWeaver said:
The Painters Wife has a 56 MB .proc file and a 38 MB .map file — so your map is almost four times the size of the largest map ever released.
.map 61.5M
.proc 200M
brushes 22362
patches 16507 (<- a you were saying...)
entities 9357
# of patches is no doubt because in most cases I just copy/pasted the non-.ase func_static concoctions. So I'll do as you suggest and replace all of them with the corresponding .ase models and see how that works out. And as you said, models render better with fewer glitches.
Following on @Geep reply I tried compressionator v4.1. I had the thing installed but forgot what it was! v4.1 is quite easy to use to batch convert .tga->.dds, but it adds a string of capital letters to the end of the original names and no way to change that behavior, and also capitalizes .DDS. I used a batch renamer (metamorphose) to get the names I wanted. However, the newly compressed .dds (DXT1) in the env folder couldn't be found or read by TDM, and sad to say but it makes quite a difference losing all those fake window reflections. A loss of vitality. Perhaps like .dds textures, .dds env files need to be in another directory?
-
Springheel's prefab facades, the one on the right fitted out as a tavern, as per Springheel's sign outside.
My instinct when looking at this screenshot is to replace the 'lit' widows in the backmost prefab with ones more subtle, that change in intensity as the player moves around.
-
1
-
-
The TDM original is in the middle.
-
3
-
-
- Popular Post
- Popular Post
A 200MB .proc file in maps.
In models there's 159MB of TDM models scaled, 81MB made by me. I might be able to eliminate some from the 81MB batch. There's no way I'm going to learn from scratch how to use Maya or Blender. If I need a model I export an .ase from DR.
I made a lot of alpha/translucent textures, for lampshades, windows, vases and so on. Since I don't know how to combine an alpha with a translucent in the same material definition I overlay the two. I might be able to save a few bytes by checking for duplicate .tga/.dds from before I learned how to refer to the same ones from multiple definitions (this IS my first FM and has there's no way I'll get rid of all the newbie messes made while learning. Like everyone, I learn as I go.)
-
5
-
2 hours ago, OrbWeaver said:
Sorry to say, I think you need to go back to the drawing board
OK, the FM won't be released.
-
3 hours ago, AluminumHaste said:
How does your FM use 476MB's of textures plus 159MB's of DDS textures 108MB of env textures, if you didn't make them yourself?
Sigh. Then I wonder why you would ask if I made the new textures etc. myself? Of course I, in the widest sense, made the new stuff myself. But that doesn't mean I used "all new textures, sounds and models". I interpreted the "all new" to mean I built a bloody TC. The few new sounds are all downloads from freesound. I didn't make them. But they aren't stock. The "new" models are mostly either resized stock or are exact copies of existing models made in DR so I could retexture and add onto them etc., plus some stuff I made into models because as simple DR func_statics they were problematic and -- I don't quite know why -- as models the problems vanished.
Copying those lamp etc. models was a great way to learn how to use patches, to learn about how objects are sized and so on, and gave me an unforeseen insight into all the deep work that must have gone into figuring it out and putting it together from scratch.
As I said, it has been my intention to capture an impression of the existing TDM universe. If a regular TDM player drops in and goes wtf? this isn't TDM, so what is it? Then I didn't do what I wanted to do. Anyhow, anyone wandering down Springheel Lane, past the intolerable Builders, and entering Spooks' tavern will recognize the vibe.
-
35 minutes ago, AluminumHaste said:
So you made all new custom textures, sounds and models?
No. A few things I did were global, like handling windows, light fixtures, transparencies esp., but hopefully the impact is subtle. If not, I did it badly. My intent has been to make an FM that dovetails in with the TDM universe. If it doesn't then I won't release it.
-
3 hours ago, Dragofer said:
Damn ...
Yes. Damn. It doesn't break down as I thought it would:
dds : 159MB, 399 textures
env : 108MB, 144 textures, all .tga
Does anyone know of a good simple batch convertor .tga->.dds?
maps : 432MB
models : 242MB (I was surprised by this) (eta: scaled models are 160MB)
sound : 84MB
textures : 476MB. These have been near 100% culled of unused ones and seems to be entirely _ed.jpg and _local.tga files
the rest : 83MB
Total = 1,584MB
_____________
and since I've got your attention @Dragofer, do you (or anyone reading this) happen to know whether the authors of the original core model assets are listed somewhere? I've done a lot of copying of stuff like gaslight4.lwo, standing_oil_lamp.lwo, etc, into brush/patch duplicates that I retexture and use as base, so where the hard work was already done. I'd like to credit the creators. Somehow I got the impression that you might be one of them.
-
After the tedium of mind-numbingly endless playthroughs I "finished" my work in progress and am studying up on how to package it. The packagings, loading screens and briefings etc. of some of the new missions are daunting in their artistry. I'm not going to try for that!
Problems with the FM in its current state:
1. Low fps in some places will cause premature hair loss and possible heart attacks in high-fps junkies.
2. The FM currently weighs in at approx. 1.70 GB. I can whittle that down some, but not much.
3. The FM requires TDM v2.10 to load. 9350 entities.
-
3
-
-
On 12/11/2021 at 6:45 AM, Wellingtoncrab said:
on preset 3, ... - it just doesn’t work well with objects with small transparent areas like meshes and the like.
Yes, the outline on 3 doesn't handle alpha meshes well. I like both 1 and 2 with a slight preference for 2. I've been working/playtesting my WIP intensively with outlines 1 or 2 on. IMO both are an improvement over the no-outline version and neither are more immersion breaking than with no-outline. I'll also be happy to see the last of that mandatory frob-highlight script that I have to write into every material just in case I use it on a frobable.
-
On 11/3/2021 at 8:35 PM, greebo said:
I adjusted the scrolling code again. Maybe this is behaving better for you, if you care to try it? The version is called 2.14.0_revae1144b.
This version works for me, too - thank you
-
1
-
-
I'd be happy to join the crowd.
-
1
-
-
On 10/29/2021 at 6:47 AM, AluminumHaste said:
Small, fiddly patches and brushes can get broken easily.
Ideally, you would snap all vertexes to the grid, even at Grid 1. Once you have your door the way you want it, export it as ASE model. Then replace the door with the model.This portcullis is made with brushes only, no patches. You can see that the instance on the left where I made the brushes into an atdm:mover_door_sliding has broken geometry with seams in the spikes. The instance on the right follows AluminumHaste's advice to export as an ASE model, then import the model and change the properties from func_static to atdm:mover_door_sliding, then adding in all the required spawnargs (in my case: transparent /1 (since there's a visportal there), frobable /1, locked /1, translate /0 0 -176, used by whatever_key, snd_open /silence, snd_closed /silence, snd_move /door_metal01_move, ...). The geometry is clean on the model.
-
2
-
-
On 10/28/2021 at 7:32 AM, Garreth said:
Brushes and patches, wich intersect eachother..
What I'd do is replace the patches with brushes. I've found that cylinders in particular tend to show seams after any rotation and quite often with no rotation at all, and that trying to fix this by fiddling around eliminating intersections, manipulating vertices, etc. etc., just wastes time causing endless frustration.
-
I've been playing TDM quite intensely for the last little while, going through my own WIP and playing the Hidden Hands series and haven't seen any problems with the new geometric frob outlines. I use preset 2, the soft outline, which appears more finished. I rejected preset 3, the image based preset, because my WIP has a lot of frobable 'grill' type transparent shaders where the outline fills the holes with white, not allowing for a peek thru'.
Thanks stgatilov. You guys are doing an awesome job.
-
1
-
-
I've been playing the HH series in order from Initiation and just finished #3, HH TLC. Wow. The series was great from the start and got better and better, tighter and tighter with TLC being a tour de force, a masterpiece right up there at top level of my gaming experience. Way to go JackFarmer and the crew that helped flesh it out.
I've now started The Anomoly.
-
1
-
1
-
-
The entryways need visportals too, else it's still just one area.
-
1
-
-
Sometimes - quite often in fact - when I KO an AI that I've sat in a chair or bench the AI will be killed. Since I've set "no kills" in objectives, this loses the game through no fault of the player. I've been managing this problem by reconfigure chairs (usually by giving more space so the AI isn't caught in geometry and bounced around) or simply eliminating the sitting entirely. A problem is that such fixes aren't 100% reliable. In some cases an AI that is usually just knocked out will die instead. I can't figure a way to predict the problem or counter it.
My guess is that there isn't an absolute fix for this but I wonder how other mappers handle the problem.
-
58 minutes ago, jaxa said:
I wonder how you got hacked
I think it was a remoteAdmin trojan thing that wrote a loginscript to the registry.
I've been on the net since before Mosaic browser blew everyone away and have never been hacked. At first taking internet security quite seriously I then got very lax, sleepy, not accounting for how the net was rapidly taking over the world, shopping, banking, stuff like docusign, everything. I left myself wide open.
-
6 hours ago, Dragofer said:
the best way to get AIs not to say random stuff is to give them something to say.
Thanks Dragofer. So I'll dedicate my next editing sessions to mastering the conversation system - using dummy files when necessary.
There're many reasons why I'm reluctant to call for voice volunteers. Voice acting is intense work, a lot to ask for. It's my first FM and I wouldn't be comfortable doing that until some experienced mapper has actually looked at it, delivered a critique and maybe pointed out any fixes that might be needed first (I don't mean like z-fighting fixes etc., but game-flow fixes that I might be blind to.) There're other reasons but that's the major one. I haven't earned the right to make such a request, yet.
ps. and damn but some ... succeeded in hacking my laptop and PC, grabbing all my passwords including to my bank. Luckily I was online posting the above note to the TDM forum etc. when it happened so quickly caught on and started shutting things down. They did come close to breaking into my bank acc't tho'. Kinda hair raising..
How to set axis of rotation for DR exported model turned into an atdm:mover_door?
in TDM Editors Guild
Posted · Edited by geegee
To assign the rotation point of a func_static made into an atdm:mover_door I go into vertex mode, select the axis of rotation (the only selectable vertex) and move it to the right spot.
When I export that same func_static as .ase, import the .ase and make it an atdm:mover_door everything works, except the axis of rotation isn't selectable.
When exporting as .ase I check the option 'Center objects at 0,0,0 origin', and the axis of rotation is now centered at exact center of the model. If I leave this option unchecked (default) the axis of rotation is centered at 0,0,0 of the DR grid - so when I put the cursor at a point of the grid and 'create model', that's where the axis of rotation is created while the model itself is offset accordingly. In neither case is this center, or axis of rotation, selectable or moveable independently of the model.
eta: A kludge is to extend the door to be exported as .ase with a nodraw brush so the center of the combo is at the axis location desired. This works but is an abominable kludge which only gets worse since for double doors kludged versions of both L and R are required. Likewise for every other axis adjustment that needs to be made.