UT99.org | Unreal Tournament Community

Currently cylinder collision only, ask dots about it.. didn't have time for this yet

which book? metaphor? Oo

I suggest you test everything for yourself.. not only static meshes

Say, what about volumes?
Is it possible to make a solid, invisible volume to act as collision?

Volumes are not finished yet!

Volumes in the means of invisible BSP collision hull are only useful for static non moving static mesh geometry like architecture

Shadow wrote:Volumes are not finished yet!

Volumes in the means of invisible BSP collision hull are only useful for static non moving static mesh geometry like architecture

Yes and I need it ...exactly this... gimmi gimmi gimmi ...

Real Volumes like in modern Unreal Engine? This is quite difficult..

You really don't want to see an adult man cry and snivel ...right?

Nope.. but I uuh... this is really not easy!

Ok btt. is it really that difficult?
How about a little bit better collision hull than the default one?
Something like a square with definable xyz axis ...would be much better than the default tube.

papercoffee wrote: Something like a square with definable xyz axis ...would be much better than the default tube.

The real limitation of that "tube" (cylinder) is that you cannot define its rotation/orientation, otherwise many other kinds of mods could be done with it (and it could replace a cube just fine in most situations).
Cylinders and cubes are perhaps the most useful primary type of collision hulls, as long as they can be rotated.
Perhaps the only thing Shadow can define is a karma-like collision system, which would do the same job as "collision volumes" (with karma like you have cube/box, cylinder, pyramid, cone and spherical primary collision, which when aggregated you can do more complex collision for a single object).

Just my 2 cents, personally I don't know how hard this is at C++ level for UT.

Like I said, I did not care for 227 until static meshes (unlimited UVs, as like it is supposed to be, material assignments, better lighting, collision and path support) got introduced. For me this is basically the very core of the whole thing (somehow around 75 -80 %), if you get what I mean. I do not care about emitters and co that much, it is a nice extra, but without working static meshes it is just not what I need. I surely do not want to criticize your work Shadow, but the comparison of limited, buggy and bad-lightable [the word does not exist] bsp surfaces against static meshes ist just too huge for me. On top of that, I can not test a whole new thing anymore, otherwise I can screw on my being as mapper once again. The only good thing about the whole 227 testing (for around 1,5 years?) was I was "forced" to learn 3d modelling and I could enhance my formerly non-existing texture skills.
Basically I can only make a low poly map for UT - since I mostly make terrains and caves I have to be FREAKING CAREFULLY. Nodelimit is faster reached than you might think and do not forget about the nice HOMS and ICHs. I could not live without them. The other choice would be to do a map for 227, but seriously, this is a pretty much a waste of time, since nobody really uses the 227 "engine" (226 only "fanboys" and/or 227 "hater" and enough people with old crappy pcs as like Unreal itself, or just no knowledge about static mesh design and/or alpha channels). If I would seriously create something there, I nearly could have an absolute monopoly. But since I like competition among other qualified mappers, this is not the way I want to go.

Feralidragon wrote:Just my 2 cents, personally I don't know how hard this is at C++ level for UT.

I assure you that the C++ part of UT can be very frustrating.

Saya-chan wrote:

Feralidragon wrote:Just my 2 cents, personally I don't know how hard this is at C++ level for UT.

I assure you that the C++ part of UT can be very frustrating.

oh me forgotz one variable -> whole class not usable <3

Creavion, i did map on 227h too.
120k polygon total, meshes taken out from another game and optimized just for fun.

I found a few frustrating limitations I've got to say.
Lighting, lighting, and lighting.

So, i don't care if he's taking his time, if we get to see per vertex lighting or lightmaps on static meshes (not fully static, daylight purposes), I'll build this guy a monument.




PD: Guess what game this map belongs to.

Shadow wrote:

Saya-chan wrote:

Feralidragon wrote:Just my 2 cents, personally I don't know how hard this is at C++ level for UT.

I assure you that the C++ part of UT can be very frustrating.

oh me forgotz one variable -> whole class not usable <3

Not wanting to go offtopic, but that sounds like php (which is written in c++ btw):
- A small syntax error (like missing ";") -> blank page with no error logs, warnings or anything whatsoever. Have fun looking for your mistake
Either you have a nice IDE like Ecplise to check the syntax while you edit it (although it slows down your machine A LOT with classes with lots of code), or welcome to hell.

As of C++, yeah, I have heard pretty bad things about it as far as compile/debug goes... besides being a quite complex language compared with nowadays languages.

Oh shit, Gothic O________o

Ok, congrats, this attack against me was super effective.


Crev fainted!

Joke aside, I am not sure if I get what you are trying to tell me? And how the hell do you know I like Gothic that much, just what the hell is going on here anyway?

Creavion wrote:Oh shit, Gothic O________o

Ok, congrats, this attack against me was super effective.


Crev fainted!

Joke aside, I am not sure if I get what you are trying to tell me? And how the hell do you know I like Gothic that much, just what the hell is going on here anyway?

I would have never expected to see a Gothic fan in the UT community...

I intended to port Gothic to UnrealEngine for many reasons:
- Learning experience
- Cooperative multiplayer (got plenty of friends wishing for the same, but can't code )
- Estabilishing a code base that allows for quick creation of characters, quests, worlds, basically other games could be made using that codebase (Gothic 2 would have been the next project).

I dropped it because it's simply too much work for a single person, but so far I've accomplished:
=> Most of the world layout (Zengin) imported, split, and hidden using custom occlusion code.
----- It still needs a lot of work, around 15-25k polys displayed on screen, FPS goes down to 40 on my Pentium E2180
=> Lighting: day to night transition, includes dawn and nightfall.
----- Directional lighting is impossible here, static meshes in this engine don't properly block light and have normal mesh lighting (origin point)
=> Tree layout and some decorations 99% accurately placed.
----- Achieved using a custom Spacer(gothic editor) savefile exporter (text parser written on Gizmo central) and Unreal Importer (copy output text to special actor in game, generate UnrealEd .t3d map that adds the decorations into the existing world) (*read note)
----- Already added like 8000 unique decorations, still missing around 20000 decals and functional stuff
=> Other maps (Free mine so far) directly attached to the main world.

I had intended to leave code, sounds and animated models to the last.


Going to the actual SDK, origin point lighting on meshes makes terrain building impossible, unless you use unlit terrains which doesn't look pretty at all.
It would seem that 227's approach on static meshes are simply, decorations. So doing any serious terrain mapping is out of question.

I know a lot of work has to be put into it, but static mesh support on the SDK would be kind of a waste if lighting limitations arent dealt with.
I still consider myself a noob at C++, but if I can be of help at anything in the future, I'll try my best to learn.

Suggestion: ability to load Unreal 227 static mesh packages, after all, their editor already has powerful import/export functions, as well as scaling, material assignment, and LOD levels.

Edit: NOTE*. Did I mention the hard time I had trying to convert decoration's rotation matrixes (made of string representation of raw bytes) into unreal rotators?