Logan Publicado 1 de Octubre del 2011 Publicado 1 de Octubre del 2011 Hola Zip. Pues la verdad no sé qué decirte. En principio sí tendrías que preocuparte, pero no por los estáticos. Esos valores en rojo aparecen cuando el editor "ve" que hay peligro a la hora de compilar el nivel y que puede cascar. Hace casi dos años me pasó a mi con mi nivel de Venecia. Aparecieron esas advertencias en rojo y yo seguí construyendo como si nada, hasta que el nivel cascó y no me dejó ni siquiera compilarlo. Te diré que todo depende del "exe" que esteas usando. Si el motor está preparado para soportar cierta cantidad de objetos, no deberías preocuparte. Por ejemplo, en el BtB de este año me comentaron que Nadine había modificado el ejecutable para que aceptase más objetos, y que aunque aparecieran esos datos en rojo podríamos seguir construyendo. Es más, mira un pantallazo del área de datos de mi nivel finalizado: Como ves, a mí también me han salido esas advertencias, y a pesar de tener más movibles y más estáticos que tú, el nivel se compiló sin problemas y chufló. El problema no está en los estáticos; puedes poner más de 1.000 que no creo que pase nada. El verdadero problema del NGLE (o por lo menos el que había hace un par de años) está en los "moveables". Los objetos que se pueden mover (armas, munición, llaves, etc.) consumen mucha memoria y pudiera ser que el editor cascase si tiene que procesar tantos Mb. Y no estoy hablando de la memoria de tu ordenador precisamente, sino de la que puede soportar el motor del juego. Como referencia, puedo decirte que hace dos años, el límite estaba en unos 240 moveables, pero realmente no sé que versión del "engine" estás usando, así que no puedo aseverar nada en firme. Habría que contactar con Paolone y ... En fin... Siento no poder ayudarte más. Yo la experiencia que tuve fue esa. Yo de ti en principio continuaría construyendo como si nada; eso sí, guardando los PRJ periódicamente cada 20 ó 30 minutos de trabajo (yo este año he guardado más de 200) y en el momento que veas que el editor casca al compilar o que el juego se cuelga al arrancarlo ya sabes por qué es: demasiados "moveables". Espero que no sea así y que puedas desarrollar toda tu creatividad sin este tipo de limitaciones. Un saludo.
ZipGeek Publicado 1 de Octubre del 2011 Publicado 1 de Octubre del 2011 Gracias Logan Yo uso la ultima version del NGLE ,la 1.2.2.6 . Y no me ha dado problemas ,excepto con las FMVs (pero esto es aparte) Creo que esperare hasta que el compilador haga "crash" ,para asi saber los verdadedros limites. O como "spoiler" ,disminuire la cantidad de salas y dividire el nivel. Gracias Bye
Marcos Publicado 5 de Octubre del 2011 Publicado 5 de Octubre del 2011 El flame_emitter quema a Lara aunque ella esté a centímetros del fuego sin tocarlo. Es decir, no hay una coincidencia lógica, Lara se quema cuando no debería quemarse. ¿Alguien sabe si hay una manera de reducir el área de afectación del flame_emitter?
ZipGeek Publicado 10 de Octubre del 2011 Publicado 10 de Octubre del 2011 Al parecer no existe solucion para eso. (Problemas del motor) ,pero... puede probar con los triggers "Variables" . Si usas NGLE , si usas el TREP puede que este la opcion. (Yo no se porque no lo uso) Pero yo tengo un pequeño problema : Cada vez que agrego el objeto "FONT_GRAPHICS" a mi wad , lo modifico (Para usar la fuente Times New Roman) Compilo el nivel pero cuando quiero "entrar" al menu de Opciones el juego se cierra y me encuentro con el sig. documento. Aqui el texto: Version=1.2.2.6 CRS=Disabled Last diagnostic mexage:FileClose Last directX error: START_P1:1002D0D7 END_P1:10071FDD START_P2:10083677 END_P2:100A8DD6 START_P3:100B2487 END_P3:100E3BF2 START_P4:10007207 END_P4:1000FDC4 ............... QUICK DIAGNOSTIC LOG ............... .................................................... CRASH REASON: EXCEPTION_ACCESS_VIOLATION The thread tried to read from or write to a virtual address for which it does not have the appropriate access. EXTRA_INFO: VIOLATION ON READ AT OFFSET 0x959596BF RECOVERABLE : YES CRASH OFFSET: 0x6DE31AAD REGISTERS: EAX=959595FB EBX=181FA8 ECX=959595FF EDX=959595FB ESI=180AAC EDI=0 EBP=2F3FE9C EIP=6DE31AAD ESP=2F3FE90 DYNAMIC POINTER LIST: ------------------------------------------ 00000019:Camera_Room 0000000C:Camera_TargetRoom 0013FF4C:BaseSalvaStack1 0442FFB4:BaseSalvaStack2 02E3FFB0:BaseSalvaStack3 ------------------------------------------ MEMORY USAGE ------------------------------------------ VetNemiciPunta memory <EMPTY: never used> StructEnemyArray memory <EMPTY: never used> ZonaFXBulbNemici memory <EMPTY: never used> VettorePerFogBulb memory <EMPTY: never used> ZonaDynamicLights memory is full at 6.12 (Used 0xBC bytes) ZonaSceneMemory memory is full at 14.03 (Used 0x3BA14 bytes) VetEditObjects memory is full at 16.61 (Used 0x45C bytes) Mex_savegame_Argd memory is full at 3.13 (Used 0x8 bytes) ZonaParticelle memory <EMPTY: never used> ZonaGameStruttureMesh memory is full at 0.46 (Used 0x7128 bytes) ZonaPuntatoriGameStruttureMesh memory is full at 0.12 (Used 0x1C8 bytes) VetMexNomiWav memory is full at 99.66 (Used 0x3FC8 bytes) ZonaFogBulbs memory <EMPTY: never used> ZonaDebris memory <EMPTY: never used> ZonaItemInStanza memory <EMPTY: never used> WARNING: [ZonaUsataPerFireSpark] memory is full at 99.50(Used 0x74 bytes) ZonaUsataPerFireSpark memory is full at 99.50 (Used 0x31C bytes) ZonaDiSmokeSpark memory <EMPTY: never used> ZonaRecordGunShell memory <EMPTY: never used> ZonaQuattroSample memory <EMPTY: never used> RecordSpriteSangue memory <EMPTY: never used> RecordSpriteEsplosione memory <EMPTY: never used> SpritePerFuoco memory is full at 6.05 (Used 0x7C bytes) ZonaTextureAnimate memory <EMPTY: never used> SaveGame_220_DatiMoveables memory <EMPTY: never used> VettoreAttivaFlipMaps memory <EMPTY: never used> VettoreFlagFlipMaps memory <EMPTY: never used> ZonaFlyCameras memory is full at 8.96 (Used 0x72C bytes) VetByteFlyCamera memory <EMPTY: never used> VetFlyCameraByteAltro memory is full at 3.13 (Used 0x4 bytes) VetItemCombinabili memory is full at 24.78 (Used 0xE4 bytes) Ptr_MemBufferLivello memory is full at 36.91 (Used 0x70A520 bytes) ------------------------------------------ Lara: x=6656 y=0 z=76288 StateId=2 NextId=2 AnimNow=103 Room=25 Stack=0x2F3FE90 pContesto=0x2F3FBC4 pInfoEccezione=0x2F3FBA8 PRIMARY_STACK: ESP=0x2F3FE90 STACK_TRACE: 0x47EBB7 0x47DAE8 0x44E2A0 0x100A770B 0x451C67 0x1005DCDD 0x1005DD4C 0x45126D 0x45EC82 0x475155 0x49E67C 0x49DF08 0x49E61D END_STACK_TRACE SECONDARY_STACK: ESP=0x13B12C STACK_TRACE: 0x43005C 0x430010 0x490046 0x430000 0x410040 0x430042 0x450044 0x470046 0x490048 0x410060 0x430042 0x450044 0x470046 0x490048 0x410040 0x430042 0x450044 0x470046 0x490048 0x43492E 0x470446 0x4A6FE0 0x48D323 0x470446 0x4A6FE0 0x470446 0x4A6FE0 0x4A6FE0 0x4A6FE0 0x470446 0x48CC6B 0x470446 0x48CACE 0x49F26B END_STACK_TRACE OTHER_STACK: ESP=0x442B194 STACK_TRACE: <CRASH DURING STACK TRACE> END_STACK_TRACE Bueno y aqui estoy ,no se cual es el problema y tampoco porque se provoca ,ya que he visto otros niveles , y hechos con el NGLE que cambiaron la "fuente" del texto y no presentan problemas. Bye
Marcos Publicado 6 de Noviembre del 2011 Publicado 6 de Noviembre del 2011 Debajo del agua, debido a las ondulaciones que ocurren en las paredes (a causa del agua) aparecen y desaparecen estos "cortes" en los bordes. Detrás se ve luz, es el horizonte. ¿Hay solución? Ya probé sin éxito estos cambios: *bajar la numeración del agua *hacer coincidir exactamente las divisiones horizontales verdes y amarillas
Adngel Publicado 6 de Noviembre del 2011 Publicado 6 de Noviembre del 2011 Sí, eso se corrige haciendo coincidir las aristas de los muros. En este tutorial hay varios dibujos que expresan lo que digo: http://www.skribblerz.com/tuts/ngle/ngle2/crackmode.htm Para ello, puedes ayudarte de las aristas separadoras del techo, (teclas SW y FR) junto con las del suelo (teclas AQ y DE). Si todas las aristas conectan con los vértices, esos cortes no sucederán bajo el agua (además de que la iluminación también será un poco más suavizada). *hacer coincidir exactamente las divisiones horizontales verdes y amarillas Tal vez sea esto de lo que estoy hablando, sólo que en mi pc no hay amarillo, sólo distintos grados de verde
Marcos Publicado 7 de Noviembre del 2011 Publicado 7 de Noviembre del 2011 Sí, a eso me refiero, las aristas coinciden... Leeré el tutorial completo del link que me enviaste. Gracias!
McRaider Publicado 7 de Noviembre del 2011 Publicado 7 de Noviembre del 2011 Otra simple solucion es texturizar la parte inferior del cono del horizonte,con textura negra o similar. Yo lo hice y me dio resultado..
Marcos Publicado 19 de Noviembre del 2011 Publicado 19 de Noviembre del 2011 Gracias a ambos. Solucionado. Ahora una inquietud: hasta el momento utilicé el fuego del sprite original, si bien desde hace unos años casi todos los creadores usan un sprite nuevo. Las llamas del sprite nuevo no me convencen, me sigue gustando el fuego original. ¿Qué opinan ustedes? Si alguien sabe explicarme qué tiene de mejorado el nuevo fuego, porque yo no alcanzo a apreciar que sea de verdad más realista...
Pemon Publicado 20 de Noviembre del 2011 Publicado 20 de Noviembre del 2011 Marcos, creo que las imagenes hablan por si solas pero, todavía más durante el juego. Sprites originales Custom Sprites Saludos. Off topic; porqué las imagenes salen reducidas en el mensaje?
Marcos Publicado 20 de Noviembre del 2011 Publicado 20 de Noviembre del 2011 Las imágenes se ven pequeñas pero pueden ampliarse. Lo que no me convence es que las llamas del nuevo fuego tienen curvaturas muy pronunciadas que no son realistas. Por eso, ante la opción, siempre quise usar el viejo fuego. ¿Tú no lo ves así? ¿Es una apreciación errónea mía?
Adngel Publicado 20 de Noviembre del 2011 Publicado 20 de Noviembre del 2011 Pienso que depende más de gustos y cómo se quiere dibujar ese fuego. A mi me gustan más las llamas de la 2º imagen, (las alternativas) pero no por realismo, si no porque las otras en plan de pequeños círculos no me gustan para las llamas pequeñas. Sin embargo para efectos como el del agua o la niebla, pienso que esos circulitos del fuego standard encajan mejor. Por esto, tiendo a elegir las 2º llamas, pero si resulta ser un nivel en el que hay poco fuego y mucha agua y humo, tal vez sería mejor centrarse en algún sprite que los represente, no más real, si no más fiel a tu idea del ambiente que quieres dar. El fuego puede manifestarse de muchas maneras así que también le veo cierta libertad.
Marcos Publicado 21 de Noviembre del 2011 Publicado 21 de Noviembre del 2011 Cierto, el fuego toma formas muy variadas, no había prestado suficiente atención, las fotos son elocuentes. También tienes razón respecto a que el humo del nuevo sprites es defectuoso. Ya me estaba convenciendo a mí mismo de usar el nuevo fuego, pero ahora me echo atrás a causa de que el humo no luce bien...
McRaider Publicado 22 de Noviembre del 2011 Publicado 22 de Noviembre del 2011 Si no me equivoco el fuego de la segunda imagen son sprites de Teme9,muy buenos.Marcos,podes texturizar el cono del objeto fuego con textura color aqua y ese humo blanco cambiara a verde/azulado..mejor efecto visual.
Pemon Publicado 22 de Noviembre del 2011 Publicado 22 de Noviembre del 2011 Si no me equivoco el fuego de la segunda imagen son sprites de Teme9,muy buenos.Marcos,podes texturizar el cono del objeto fuego con textura color aqua y ese humo blanco cambiara a verde/azulado..mejor efecto visual. Es esto cierto? no lo sabia creo que cuando tenga tiempo lo probaré. Saludos
Publicaciones recomendadas
Crear una cuenta o conéctate para comentar
Tienes que ser miembro para dejar un comentario
Crear una cuenta
Regístrese para obtener una cuenta nueva en nuestra comunidad. ¡Es fácil!
Registrar una nueva cuentaConectar
¿Ya tienes una cuenta? Conéctate aquí.
Conectar ahora