2008.09.01, 01:09 PM
It works. 
-though it would be alot easier to cut along an edge.
-though it would be alot easier to cut along an edge.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
2008.09.01, 02:15 PM
Brian, you know how in the old portal system you could set portals to automatically change the map when the player enters it? I'm really really missing that feature in the new mesh version. Is there a way you could carry the functionality over?
2008.09.01, 02:17 PM
I think meshes still can send messages when entered.
Just send a message to the map script (or the player script), telling it to change the map.
Just send a message to the map script (or the player script), telling it to change the map.
2008.09.01, 02:22 PM
Bink Wrote:I think meshes still can send messages when entered.
Just send a message to the map script (or the player script), telling it to change the map.
Hmm. Interesting idea. I'll try that.
2008.09.01, 07:39 PM
Bink Wrote:I think meshes still can send messages when entered.
Just send a message to the map script (or the player script), telling it to change the map.
Yes, this is the way to do it. It's actually a better system as it's easier to model a doorway or something smaller to pass into.
When you translate an older map, it picks the first mesh in the portal to get the old portal settings. This probably isn't optimal, but it's the best guess I can make when translating.
[>] Brian
2008.09.02, 06:07 PM
ggadwa Wrote:Bink Wrote:I think meshes still can send messages when entered.
Just send a message to the map script (or the player script), telling it to change the map.
Yes, this is the way to do it. It's actually a better system as it's easier to model a doorway or something smaller to pass into.
When you translate an older map, it picks the first mesh in the portal to get the old portal settings. This probably isn't optimal, but it's the best guess I can make when translating.
[>] Brian
Hmm. Well, Auto Map Change in the Editor mesh settings is broken. I'm basically trying to do something in Super Mario 64-esque, where you walk through a marked out wall and it transports you to a different map. This was very easy with the old portal system- with the new mesh system it's a bit more complicated.
Also, The obscuring system needs work. Observe:
http://i160.photobucket.com/albums/t191/...ure3-9.png
2008.09.02, 09:35 PM
My "problem map" is crashing the engine all over the place, usually when a new mesh comes into view (but not always the same mesh). The crash logs look pretty much useless, too:
Code:
Process: dim3 Engine [2196]
Path: /Users/[excised]/Desktop/MeshOnlyTest/dim3 Engine.app/Contents/MacOS/dim3 Engine
Identifier: com.klinksoftware.dim3.engine
Version: dim3 Engine version 2.5 (2.5)
Code Type: X86 (Native)
Parent Process: launchd [256]
Date/Time: 2008-09-02 18:29:32.285 -0700
OS Version: Mac OS X 10.5.4 (9E17)
Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000001cd0bf04
Crashed Thread: 0
Thread 0 Crashed:
0 ??? 0x18f3a88b 0 + 418621579
Thread 1:
0 libSystem.B.dylib 0x906184a6 mach_msg_trap + 10
1 libSystem.B.dylib 0x9061fc9c mach_msg + 72
2 com.apple.opengl 0x95bdfa1d glcDebugListener + 349
3 libSystem.B.dylib 0x906496f5 _pthread_start + 321
4 libSystem.B.dylib 0x906495b2 thread_start + 34
Thread 2:
0 libSystem.B.dylib 0x9061f68e __semwait_signal + 10
1 libSystem.B.dylib 0x9064a36d pthread_cond_wait$UNIX2003 + 73
2 libGLProgrammability.dylib 0x94847432 glvmDoWork + 162
3 libSystem.B.dylib 0x906496f5 _pthread_start + 321
4 libSystem.B.dylib 0x906495b2 thread_start + 34
Thread 3:
0 libSystem.B.dylib 0x906184a6 mach_msg_trap + 10
1 libSystem.B.dylib 0x9061fc9c mach_msg + 72
2 com.apple.CoreFoundation 0x91dcc0ce CFRunLoopRunSpecific + 1790
3 com.apple.CoreFoundation 0x91dcccf8 CFRunLoopRunInMode + 88
4 com.apple.audio.CoreAudio 0x969df464 HALRunLoop::OwnThread(void*) + 160
5 com.apple.audio.CoreAudio 0x969df300 CAPThread::Entry(CAPThread*) + 96
6 libSystem.B.dylib 0x906496f5 _pthread_start + 321
7 libSystem.B.dylib 0x906495b2 thread_start + 34
Thread 4:
0 com.apple.audio.CoreAudio 0x969cf46f HP_Device::GetNumberStreams(bool) const + 1
1 com.apple.audio.CoreAudio 0x969f07b5 HP_IOThread::PerformIO(AudioTimeStamp const&) + 231
2 com.apple.audio.CoreAudio 0x969eef87 HP_IOThread::WorkLoop() + 1239
3 com.apple.audio.CoreAudio 0x969eeaab HP_IOThread::ThreadEntry(HP_IOThread*) + 17
4 com.apple.audio.CoreAudio 0x969df300 CAPThread::Entry(CAPThread*) + 96
5 libSystem.B.dylib 0x906496f5 _pthread_start + 321
6 libSystem.B.dylib 0x906495b2 thread_start + 34
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x00000000 ebx: 0x00022e84 ecx: 0x19eba020 edx: 0x1d2d9624
edi: 0x00002e8b esi: 0x19f52280 ebp: 0x1cce9078 esp: 0xbfffe7c8
ss: 0x0000001f efl: 0x00010246 eip: 0x18f3a88b cs: 0x00000017
ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037
cr2: 0x1cd0bf042008.09.02, 09:41 PM
Right now, messages always have to be numbers, right?
Could you change that to strings? That would be nice.
EDIT:
I thought about sending messages like "levelChange_castle".
In the message function, you would split the string (removing the _), so you would end up with one string "levelChange" and another "castle".
You can probably guess the rest.
This would be a lot easier, than sending message 1452 to change to the "castle" map, 1453 to change to the "mountain" map, and so on.
Nobody likes keeping a text file with all the message IDs somewhere.
Could you change that to strings? That would be nice.
EDIT:
I thought about sending messages like "levelChange_castle".
In the message function, you would split the string (removing the _), so you would end up with one string "levelChange" and another "castle".
You can probably guess the rest.
This would be a lot easier, than sending message 1452 to change to the "castle" map, 1453 to change to the "mountain" map, and so on.
Nobody likes keeping a text file with all the message IDs somewhere.
2008.09.02, 10:00 PM
Would allow for more dynamic functions that can respond to any situation with far less code. Though I was thinking that it would be better to have a data send function, x.send(id, varname, value) or something. Or possibly automated detection in my message function. But sending data directly to another script is... or should be, A GIVEN! So give us please.
So give us please.2008.09.02, 11:26 PM
I'll look into something more text-based on the messages. Right now, there will be multiple things broken in engine, I'm sure the messages are one thing but I'll look into that, too (I'm concentrating on Editor/Animator right now.)
CYST -- I suspect your map has transparent segments in it -- this is a known bug I fixed but I'm being held up by a couple other things.
Right now, the biggies are the obscuring (this is very beta right now) and auto-UVing. I've got better versions but these are very "human" actions that the computer has to do so it's complex to find a computational way to do it (i.e., seems obvious to a human but tricky for a computer.)
[>] Brian
CYST -- I suspect your map has transparent segments in it -- this is a known bug I fixed but I'm being held up by a couple other things.
Right now, the biggies are the obscuring (this is very beta right now) and auto-UVing. I've got better versions but these are very "human" actions that the computer has to do so it's complex to find a computational way to do it (i.e., seems obvious to a human but tricky for a computer.)
[>] Brian