Quake3World

He mentioned something about gmax in his first post so that's most likely what he meant:

a13n wrote:1stly I made a simple cylinder in gmax then deleted the meshes except the top one.

Can't really see any benefit in this idea though. Sounds like 'mapping the hard way' to me.

dichtfux wrote:He mentioned something about gmax in his first post so that's most likely what he meant:

a13n wrote:1stly I made a simple cylinder in gmax then deleted the meshes except the top one.

Can't really see any benefit in this idea though. Sounds like 'mapping the hard way' to me.

'Alen' has a history of confusing posts so no, he may not be talking about Gmax, hense my comment.

@Kat
Acutally any max or app will do as long as it can deal with splines effectively and can pass the final meshes to milkshape in any form.



My next map will be a cpma-oriented map.

a13n wrote:@Kat
Acutally any max or app will do as long as it can deal with splines effectively and can pass the final meshes to milkshape in any form.



My next map will be a cpma-oriented map.

Mate seriously, you *really* need to stop and think about this. If someone has access to 3DS Max they should be using ASE models and simply exporting out to that format and then boxing the resulting models in a caulk hull.

If they're using Gmax and doing nothing more complex then you've shown here then you can use the Tempest plugin and compile a BSP/map file directly from that.

Both of those methods mean you're working directly with fully built meshes that have UVWmapping applied to them *at source* which can be used *directly* in editor/game *as is*. That's two tools and two processes; model and UVW in a 3D app and then import, box and compile in Radiant.

If after reading this you *still* think that using four tools and as many processes (incidently where is UVWmapping? Are you doing that in Radiant?);
1) building in gmax, exporting to MD3
2) importing MD3, resizing, exporting to .map
3) importing .map file, compiling
4) scaling via compile, final output
5) rinse and repeat 4) until you get the proportions correct relative the gameplay and entities.

...is a 'good' thing then I don't know what to say else to say really except to agree with dnky about creating a "not noob friendly" warning sticker to place in threads like these which are woefully misguided, albeit with good intentions.

I'm really surprised by your lengthy joke again and again. :icon30:

By the way you can import/export continuous "large" geometries at once.
Beyond that milkshape automatically "func_group"s them based on the mesh group.
So in most cases import/export count should be low and exported brushes should be quite easy to handle unless something unexpected happens to map file.

I still don't think you're getting it. Why are you adding all these complex import/export steps to your workflow 3-4 times between different applications when just a single export step will do the exact same thing? Just seems to us as if you are deliberately making things more difficult without any benefit to the appearance, performance or ease of mapping.

I mean, if you want to make your life harder as a learning experience, then by all means no one will stop you. But to post on a forum like it's some sort of tutorial that everyone including beginner mappers should try is pure folly.

Until you've actually provided a tried and true method that yields better results, this is strictly an experimental technique at best. You haven't yet explored possible limitations of your method so for all you know, this may not be feasible at all.

a13n wrote:I'm really surprised by your lengthy joke again and again. :icon30:

He's not joking.

If plained laid an egg

it wouldn't fall far from the tree

:icon3:

@obsidian
The 1st layout/gameplay alpha, which would be released this weekend if everything goes well, would be a decent proof, I hope.

@foo
Thanks.

Here is an in-editor shot.
Have a look at the pillars.
They were located elegantly by making full use of spacing tool.

No.
They are, at least, on grid 1.
Almost everything goes well though some retouches are required.

I name this method "Dynamic Level Planing Ultra Fast(TM)"
In short D.L.P.U.F(dee el pAf).

If grid 1 is too hard-boiled for you, you can shift to grid 2 by setting larger scale in milkshape, which would result in less unexplainable leaks at the expense of deeper consideration of final scaling of geometry, lightgrid and lightmap.
In that case you have to be more careful to entity placement.

a13n wrote:If grid 1 is too hard-boiled for you, you can shift to grid 2 by setting larger scale in milkshape, which would result in less unexplainable leaks at the expense of deeper consideration of final scaling of geometry, lightgrid and lightmap.
In that case you have to be more careful to entity placement.

So wait..! You mean you have to fix a shit load of "unexplained" leaks as well as all the other stuff you have to do to get this to work?

Hmmm I wonder what could possibly be causing the compiler to find leaks like that? Could it be that, oh I don't know, your map actually has leaks due to the method you're using!? :icon22:

It's funny but when I build maps I very rarely have *any* leaks never mind "mysterious" ones.

Sounds like entirely too much work for almost no payoff. I could dig a swimming pool with a gardening spade, but that would be a bit ludicrous wouldn't it?

Actually there were a few leaks in my map(grid 1).
At 1st they seemed to be unexplainable.
But after subtle struggles they turned out to have some kind of law.
I'll list up the 2 reasons once it is surely proved to be the ones.
I need more tests which takes time.

By the way I'll post yet another related method later, which would likely to be more acceptable to everyone.

a13n wrote:Actually there were a few leaks in my map(grid 1).
At 1st they seemed to be unexplainable.
But after subtle struggles they turned out to have some kind of law...

Yes... build a map correctly and you don't get any. Simple really.

:icon22:

MaxGaMin wrote: You should be a moderator.

you should gouge your eyes out with a spoon.

I second the motion that the idiot child should be moderator.

For the lulz.

The only reason why I haven't locked this thread yet is because of the 'lulz'.

This method is undeniably stupid but I'm worried that we're setting a precedent for thread shitting which could bite us in the ass later.

I'm just waiting for a13n to create an alt and have a conversation with himself like that old Mapcenter thread. Assuming he hasn't already.

I did cross my mind that Max was.

one word:
Judge the new type of gameplay instead of the method itself.
BSP will be released near future.

a13n wrote:Judge the new type of gameplay instead of the method itself.

So...you make not just one, but two threads about a new method of mapping? Then when people don't agree with you regarding the usefulness of this method, you ask that it not be judged and tell them to wait for a map?

I haven't seen anything at all about gameplay in these threads.

If you don't want people to judge your method, then I see no reason to leave these threads open.

Feel free to make a new thread when you have a map and want people to judge gameplay.