hey guys. just how shoe selling spambots got past that damned 'capcha' security deterrent is beyond me!

im not a spam bot :D
just a noob, sorry i'm 10yrs late to doing something for Deus Ex, real life (tm) got in the way.

so some catchup questions: (sorry if i ask badly, feel free to rage)

questions:
#1) How many Zones does UnrealEd1_DX support? i find answer of 63 on beyond unreal for ut, is it same?
#2) Possible to overuse Zoneinfo? is it bad form to make lots of zone infos? because lighting seems a bit bugged in some areas of my maps (staircases in particular) ie. walls completely not illuminated even tho light actor only 32uu away... so i am using zoneinfo with ambient brightness 4 in those zones, while leaving levelinfo at 0, along with pain zones, water, outside etc this might be alot, any possible problems when sitting in zone.X with ambient lighting = 0, looking out window at zone.Z with BRIGHT OUTDOOR ambient lighting and also seeing zone.Y to side with ambient lighting= 2/4 (stairwell?) or other such zone property differences..
#3) Is it possible to trigger off an Unlit surface property of a texture? example: do some walking, maybe some talking, make a thing go BOOM, lights triggered off. oohhhh spooky, but unlit textures are still there... (refer to sshot for really obvious flaw when leaving via walking upstairs)
#3b) if #3 not possible, i looked for ages thru triggers and did not find anything how to hide? are movers located 'to first' or 'to last' of brushwork? semisolid at that, can i trigger movers to hide unlit textures? or is it easier just to make pre-BOOM lvl1, post BOOM lvl2?
#4) What is the upper limit on the complexity of a mover? lvl in question is an underground train station at moment, and hence it needs a train, and i want it to be triggered to rush past and crush a kitten. jokes. is there a limit on polys or overall size or the number of attached bits, ie sparks, noise and lights etc. i did a little experimenting with my truck model (4000polys) but i made it before i knew proper on the grid vertex snapping :(. it moved but had invisible lines running vertical at every surface intersection.
#5) Do movers need to snap to the grid? basically i have lots of .t3d/.unr prefab furniture i made, aprox 250 - 500polys each. all of these prefabs use small grid, down to 2 and 1 :\. are they useless? at moment (as adds/subs or .t3d import prefabs) they freeze the editor when i add lights, will making them movers (ie breakable wall / wood fragments) make them usable?
#6) What is the .u3d format used for?, under Brush/Save. Photoshop takes about 2mins before giving me an error and crashing

hope that was how it works and stuff. im sure ill have more to ask later. thanks veteran coolguys

incase anyone cares i did play dxmp for a tiny bit in highschool, almost 10yrs ago.. as meatsack (a rather bastardized phonetic wordplay of my surname). it was only in pcpowerplay oz server tho.

also some extra new to forum questions: what resolution to use when adding sshots?

mikak wrote:
#1) How many Zones does UnrealEd1_DX support? i find answer of 63 on beyond unreal for ut, is it same?

Yes but what you will find is that SDK can't count them properly. When you get to 64 zones, the editor has already lost count long ago. The number of zones will change according to each rebuild, even when there is no bsp error or anything else that could affect zones. This may have something to do with doorways and whether you add a mover to doorway or not, it can start counting as zones.

#2) Possible to overuse Zoneinfo? is it bad form to make lots of zone infos? because lighting seems a bit bugged in some areas of my maps (staircases in particular) ie. walls completely not illuminated even tho light actor only 32uu away... so i am using zoneinfo with ambient brightness 4 in those zones, while leaving levelinfo at 0, along with pain zones, water, outside etc this might be alot, any possible problems when sitting in zone.X with ambient lighting = 0, looking out window at zone.Z with BRIGHT OUTDOOR ambient lighting and also seeing zone.Y to side with ambient lighting= 2/4 (stairwell?) or other such zone property differences..

I personally never had any problem having a zone info in each zone. The problem with your lighting is more like brush/actor issue. Check out DXMP_Mini_Dust, it has a number of lighting bugs in corners of the stairs inside the house and there's no reason for them, but you can see the issue affecting it is the geometry.

#3) Is it possible to trigger off an Unlit surface property of a texture? example: do some walking, maybe some talking, make a thing go BOOM, lights triggered off. oohhhh spooky, but unlit textures are still there... (refer to sshot for really obvious flaw when leaving via walking upstairs)

Sounds like triggers to me.

#3b) if #3 not possible, i looked for ages thru triggers and did not find anything how to hide? are movers located 'to first' or 'to last' of brushwork? semisolid at that, can i trigger movers to hide unlit textures? or is it easier just to make pre-BOOM lvl1, post BOOM lvl2?

Check out DXMP_S9 on Altfire server, spawn the opposite end from the water garden and shoot the lights out, the lights stay out. Sorry that I can't explain how this works, but I don't think he's using textures at all, he's using lights of some sort.

#4) What is the upper limit on the complexity of a mover? lvl in question is an underground train station at moment, and hence it needs a train, and i want it to be triggered to rush past and crush a kitten. jokes. is there a limit on polys or overall size or the number of attached bits, ie sparks, noise and lights etc. i did a little experimenting with my truck model (4000polys) but i made it before i knew proper on the grid vertex snapping . it moved but had invisible lines running vertical at every surface intersection.

This depends very much on the rest of your map and also luck or being a maths genius. Sometimes you can struggle to make a door which isn't buggy, then sometimes you can import very detailed prefabs and they work fine as movers. It really depends on there being no errors already in the map sometimes I think. Sometimes I can't achieve the mover inside the map, but can make it fine in a separate map, then simply (worst case scenario) paste it in to the desired map.

The question is more like, how complex can a mover be and still we can finish the rest of the map.

#5) Do movers need to snap to the grid? basically i have lots of .t3d/.unr prefab furniture i made, aprox 250 - 500polys each. all of these prefabs use small grid, down to 2 and 1 :\. are they useless? at moment (as adds/subs or .t3d import prefabs) they freeze the editor when i add lights, will making them movers (ie breakable wall / wood fragments) make them usable?

If you are using the right/small enough grid size, then the mover should fit in place. If you change the pivot on a mover, you're generally screwed. Some people with disagree with me, but grid size 1 is asking for big trouble. I generally work no less than grid size 4, except for very basic things like railings or ladders. I avoid much trouble by using 4 or more.

awesome stuff to know, thanks ShadowRunner .

#1 VERY HELPFUL. i thought i broke the editor when it showed 15 zones on a geometry rebuild, 50 on bsp rebuild. (15 closer, it was 12zones, + 'Da Workshop' + 2 tunnel ceiling bits which were zoning off even tho solid)

i vertex snapped the landing i was referring to in #2 (to the right of the staircase sshot) to be 48uu longer to fit an airvent on the wall, and the wall texture went from pitch black to textured and lit properly (ie 96uu to 144uu). 192Hx96Wx192B did not show any lights except on the floor

#3 i was looking at it in the wrong way, needed to move those light strips away, instead of trying to move small walls to slide over & block them off. but that said the 2 map solution is looking better. BOOM fallout! intersection heaven. also there are just way too many tiggers involved to shut down the whole normal world and activate another

i'll build the train and if it doesn't break the world i'll come back with the follow on questions

#5 prefab stuff i will leave until the map architecture is completely finished. because freezing is not my friend.
i did start using grid 4 at smallest; hence the hand rail being enormous!

Hello there, welcome to the FGS forum.
To your questions.. I'll try to give precise answers:

mikak wrote:#1) How many Zones does UnrealEd1_DX support? i find answer of 63 on beyond unreal for ut, is it same?

Since it's the same engine, so it should be identical.

mikak wrote:#2) Possible to overuse Zoneinfo? is it bad form to make lots of zone infos? because lighting seems a bit bugged in some areas of my maps (staircases in particular) ie. walls completely not illuminated even tho light actor only 32uu away... so i am using zoneinfo with ambient brightness 4 in those zones, while leaving levelinfo at 0, along with pain zones, water, outside etc this might be alot, any possible problems when sitting in zone.X with ambient lighting = 0, looking out window at zone.Z with BRIGHT OUTDOOR ambient lighting and also seeing zone.Y to side with ambient lighting= 2/4 (stairwell?) or other such zone property differences..

When placed right, zones can reduce BSP trash. The cause of buggy light can often be attributed to problems with the BSP tree. That means, if you have light problems at zone borders, the zone portal itself is not the problem cause, it's just the location where you can see the effects of the problems. For instance.. zone portals are naturally non-solid and translucent, which means light can pass. BSP issues at the zome portal region can cause the zone portal to change its properties. So it suddenly doesn't let light pass.

mikak wrote:#3) Is it possible to trigger off an Unlit surface property of a texture? example: do some walking, maybe some talking, make a thing go BOOM, lights triggered off. oohhhh spooky, but unlit textures are still there... (refer to sshot for really obvious flaw when leaving via walking upstairs)

Unfortunately not.

mikak wrote:#3b) if #3 not possible, i looked for ages thru triggers and did not find anything how to hide? are movers located 'to first' or 'to last' of brushwork? semisolid at that, can i trigger movers to hide unlit textures? or is it easier just to make pre-BOOM lvl1, post BOOM lvl2?

Uhh.. this are independent questions in a row..
1. Movers are technically brushes too. They are put in the order how they were placed. But ingame they come AFTER the usual brushes.
e.g. If you make a mover and afterwards you add a subtract brush at the same location, the mover won't be 'hidden' behind the subtract brush.
2. In theory you could do that.. like having a double wall. However, that mover must be in the position of hiding the unlit surface when you start the rebuild process of the map, because the light that's projected to the mover is NOT dynamic. It's calculated at the rebuild process.
Thus, the mover surface will be black, if you initially hide your mover in a dark room and then let it move in front of the (unlit) surface.

mikak wrote:#4) What is the upper limit on the complexity of a mover? lvl in question is an underground train station at moment, and hence it needs a train, and i want it to be triggered to rush past and crush a kitten. jokes. is there a limit on polys or overall size or the number of attached bits, ie sparks, noise and lights etc. i did a little experimenting with my truck model (4000polys) but i made it before i knew proper on the grid vertex snapping . it moved but had invisible lines running vertical at every surface intersection.

There can't be declared a concrete upper limit. Generally can be said, movers got the same flaws like normal geometry, but they are even more sensitive. Thus..
1. Movers don't like if they're not created on grid.
2. It's not good if the polygon complexity is centered at single spots.
3. They tend to feel uncomfortable in areas with complex brushwork.

mikak wrote:#5) Do movers need to snap to the grid? basically i have lots of .t3d/.unr prefab furniture i made, aprox 250 - 500polys each. all of these prefabs use small grid, down to 2 and 1 :\. are they useless? at moment (as adds/subs or .t3d import prefabs) they freeze the editor when i add lights, will making them movers (ie breakable wall / wood fragments) make them usable?

Movers as whole don't need to snap to grid, but the brushwork of the mover itself should be alinged to grid. e.g. IF you snap the mover to grid, all its polygons should become alinged to grid.
However, adding the brushes as movers just to avoid the lightning crash is not the solution.
You should reduce the lightradius of light actors instead.
If those prefabs are exported from newer unreal engine games, you should reconsider using them at all. Those prefabs often got many polygons which are overkill for our poor old engine!

mikak wrote:#6) What is the .u3d format used for?, under Brush/Save. Photoshop takes about 2mins before giving me an error and crashing

u3d is actually used for storing models within an universal 3D format. I just wonder how that is related to photoshop. However, I'm no modeler, so someone else can help you there better.

mikak wrote:also some extra new to forum questions: what resolution to use when adding sshots?

Well, you can use the attachment function and place pictures inline. Alternatively you can use image hosts, like imagocentre.com

Re: Movers - I should add, there does seem to be a limit to the total number of movers you can have and it seems to be just over triple figures, hundred and something. Chinny would advise you better, he reached that limit on Cozmo RPG.

Zone Portals - If you do have light issues at a doorway or entrance, simply adding a light actor (and brushes for the light source) to blend the zone lights will help.

Movers - I would add, the level of complexity you can reach, is according to the existing complexity of your map or amount of bsp issues already there. For example, I needed 17 attempts to make the X-wing fighter in DXSG_Orbital move properly, the previous 16 attempts, it just didn't like the geometry, but when I changed the shape of the X-wing, it finally made a solid mover. Looking at version 16 and version 17, it's impossible to see why 16 didn't work and 17 did, so what I'm saying is, if your mover design fails immediately, it might not be a bad or overly-complex design, it just needs to "fit" to SDK's satisfaction.

You can see why I suggested to post querys rather than contact individual mappers, because you get all the info in one place and the variety of the info and tips is greater.

You can use light bulbs that emit light, and when shot, do not. Ah the mover limit was around 130-150 odd I think.

chin.democ. wrote:You can use light bulbs that emit light, and when shot, do not.

LOL, intellectual sentence of 2013. That's quoted.

awesome guys, thanks.

just to clarify : total number of movers = 130-150aprox. and that includes all the doors/airvents (opening/closing movers), AND the breakable wall/glass movers? have got lots of intersected pillars for some subway platform assault rifle carnage (matrix style)

got baked and looked at pic of trains until 3am. might take awhile..

~][FGS][Nobody~ wrote:u3d is actually used for storing models within an universal 3D format

Nevermind me, accidentally chose save instead of export, and then the .u3d file auto associated with photoshop, was just wondering

~][FGS][Nobody~ wrote:If those prefabs are exported from newer unreal engine games

nothing imported from newer engines, built everything in unrealed1 (like this table from my illuminati prostitute bedroom collection), will need some vertex snapping touchups to make stable

mikak wrote:awesome guys, thanks.

just to clarify : total number of movers = 130-150aprox. and that includes all the doors/airvents (opening/closing movers), AND the breakable wall/glass movers? have got lots of intersected pillars for some subway platform assault rifle carnage (matrix style)

I once made something for fun with significantly more than 150 movers (imagine a city tower block with each individual window being a mover and you get the idea) and it was still workable by the time I was done with it... Whether that would be the same on a real map is another question entirely...

I'm sure the complexity of a mover would make the number of movers change.
Trial and error i guess on any map to find a stable build without errors left right and center.

[FGS]Chees wrote:I'm sure the complexity of a mover would make the number of movers change.
Trial and error i guess on any map to find a stable build without errors left right and center.

Don't forget the complexity of surrounding areas, too... lots of brushwork in a small area plays havoc with the BSP trees, increasing the chance of errors cropping up. It's one of the main reasons the use of semi-solids for non-structural geometry is recommended, since those don't cause BSP cuts

I know! I was only talking about movers but yeah the rest of the map needs to be considered for the end result of how much can UED handle. Like I said trial and error. Just wing it, read the logs if it blows the hell up to see what caused it and find a way round it for a final working map.

thinking of it I like to make movers in a fresh map so nothing else is involved but the subtract and the mover and maybe some light if testing. if problems occur then you can rule out one or 2 things.

From technical aspect, there is no limit of 150 for movers, literally because 150 is no power of 2.
But as Magus stated, the environment has significant influence there.

Magus wrote:

[FGS]Chees wrote:I'm sure the complexity of a mover would make the number of movers change.
Trial and error i guess on any map to find a stable build without errors left right and center.

Don't forget the complexity of surrounding areas, too... lots of brushwork in a small area plays havoc with the BSP trees, increasing the chance of errors cropping up. It's one of the main reasons the use of semi-solids for non-structural geometry is recommended, since those don't cause BSP cuts

If you think about it, it is difficult to paste any mover into a map which has a bsp issue, without there being some effect on the mover, so environment is crucial. I think PC/hardware and OS is a contributory factor too, because results vary between people. Also I think it is crucial to be consistent in the way you make movers, two differently made sets of movers seem to cause issues in subsequent rebuilds. Definitely rebuild and save a map before adding a mover.

The most complex movers I've worked with were probably Fuhrpark vehicles, the issue there is making sure they are solid.