[Kubo]

Tranquillo, esporta pure la porta del garage che desideri da openiv, poi la importi in 3DS insieme al garage. Una volta fatto la posizioni dove vuoi ed esporti l'ide.

PS: io non posso provarlo che mi da errore perché è compatibile con 3ds 2012 e il mio è successivo

[RYANCQQPER]

Domani ci provo , grazie .

[Kubo]

Di nulla, fammi sapere perché non ho la certezza funzioni.

Edit: naturalmente dall'ide esportato prendiamo solo le stringhe della porta, ci servono solo quelle, poi le andiamo ad inserire nell'ide di public_2

Messaggio modificato da Kubo il 23 novembre 2015 - 00:00

[Wesser]

Kubo, il 22 novembre 2015 - 18:22 ha detto:

Traumatizzare i novizi?

Non prenderla sul serio, stavo scherzando (ho dimenticato le virgolette). Comunque, mi hai frainteso in un paio di circostanze.

Kubo, il 22 novembre 2015 - 18:22 ha detto:

Il numero di poligoni incide tantissimo sulla complessità del lavoro, secondo te è più facile convertire un modello con meno di 800 poligoni o un modello con oltre 200.000 ?
A scuola inizi studiando l'afabeto o Dante?

Incremento di dettagli delle texture si traduce in mappare più mesh con la stessa texture, quindi? Una volta che si impara a mappare fa poca differenza farlo sulla stessa texture o su una diversa ogni volta.

Mi riferivo ai modelli creati da 0. Se da un lato quelli low-poly sono meno complessi in termini di poligoni, dall'altro in alcuni casi i dettagli necessitano di essere disegnati su una texture piuttosto che scolpiti (basti pensare a finestre e cerchioni). Per le conversioni cambia il tipo d'approccio, il modello e le texture son già belli e pronti, quindi basta "semplicemente" rimappare i poligoni dividendo le texture secondo i parametri previsti dal gioco ove necessario e logicamente per un modello high-poly la mole di lavoro da portare a termine ed il fastidio possono risultare certamente maggiori.

A mio parere, la difficoltà non può essere quantificata in base al numero di poligoni, è la complessità del tipo di modello che si intende scolpire a sancirla in quanto è la conformazione di quest'ultimo a dettare la dose di conoscenza richiesta circa gli strumenti in dotazione. Alla fine, è una questione prettamente soggettiva: in fondo, meno restrizioni più libertà, ogni limitazione ha i suoi punti a favore o viceversa.

Kubo, il 22 novembre 2015 - 18:22 ha detto:

Esatto, apparentemente. Un linguaggio può essere semplice o complesso alla base.
Io a scuola ho iniziato studiando il C, proprio per la sua semplicità. Secondo il tuo ragionamento mi verrebbe da chiedermi perché mai non abbiamo iniziato con il Malbolge.
Mettere più comandi nella stessa stringa non significa aumentare la complessità dal mio punto di vista. Se in un'unica stringa trovassi char, while, if e print al massimo portei perdere il filo, ma se conosco perfettamente la funzione che svolge ognuno, di suo rimane pur sempre un linguaggio semplice.

Parlavo dei linguaggi ad alto livello largamente utilizzati e non mi riferivo alla sintassi in cui ognuno e strutturato. La difficoltà consiste nel tipo di modifica/aggiunta da mettere in atto ed in parte al linguaggio scelto, anche se un bravo programmatore dovrebbe essere in grado di compensare le mancanze che una diversa tipologia di linguaggio potrebbe non presentare. Se il linguaggio utilizzato non si presta al raggiungimento degli obiettivi prefissati, allora è semplicemente la sua scelta errata ad essere alla base degli impedimenti.

Per la cronaca, la R* ha sviluppato un linguaggio in-house denominato GTA3script per la trilogia di GTA allo scopo di gestire gli script, compilati in un proprio bytecode, al di fuori dell'eseguibile. La sintassi è molto basilare ed è stata concepita appositamente per ottemperare a determinati usi e facilitarne la leggibilità. IV e V seguono lo stesso filone, ma che io sappia nessuno si è ancora preso l'impegno di dar vita ad un compilatore/decompilatore che dia la possibilità di scriptare in maniera nativa, quando invece si è optato per la controversa scelta di programmare mediante l'uso di linguaggi .NET.

Siamo OT, non vorrei dilungarmi più di tanto e rendere frammentarie le risposte inerenti alla discussione, però è comunque un argomento interessante.

[RYANCQQPER]

Kubo, il 22 novembre 2015 - 20:59 ha detto:

Tranquillo, esporta pure la porta del garage che desideri da openiv, poi la importi in 3DS insieme al garage. Una volta fatto la posizioni dove vuoi ed esporti l'ide.

PS: io non posso provarlo che mi da errore perché è compatibile con 3ds 2012 e il mio è successivo

Non ci riesco ad esportare l'ide , ho provato poco fa anche importando la porta da sola e quando clicco esport ide da gimps iv mi dice sempre : Can't find the "dev_map" parent dummy . Ho anche selezionato tutti i file della porta ma non va.

Oggi penso di aver finito l'esterno della casa , quanto lavoro , siccome la casa nuova era diversa dalla originale ho dovuto smontare scale e vari pezzi della porta per ridimensionarli e farli combaciare il piu possibile , ho dovuto poi tagliare anche pezzi di muro esterno intorno alle porte della casa ,quante prove ne ho fatte entrando in game e verificare . Sono contento di quello che sono riuscito a fare con il tuo aiuto e quello di google.

[Arcash]

Ma poi la renderai disponibile al download?

[Kubo]

Wesser, il 23 novembre 2015 - 13:10 ha detto:

Non prenderla sul serio, stavo scherzando (ho dimenticato le virgolette). Comunque, mi hai frainteso in un paio di circostanze.


Mi riferivo ai modelli creati da 0. Se da un lato quelli low-poly sono meno complessi in termini di poligoni, dall'altro in alcuni casi i dettagli necessitano di essere disegnati su una texture piuttosto che scolpiti (basti pensare a finestre e cerchioni). Per le conversioni cambia il tipo d'approccio, il modello e le texture son già belli e pronti, quindi basta "semplicemente" rimappare i poligoni dividendo le texture secondo i parametri previsti dal gioco ove necessario e logicamente per un modello high-poly la mole di lavoro da portare a termine ed il fastidio possono risultare certamente maggiori.

A mio parere, la difficoltà non può essere quantificata in base al numero di poligoni, è la complessità del tipo di modello che si intende scolpire a sancirla in quanto è la conformazione di quest'ultimo a dettare la dose di conoscenza richiesta circa gli strumenti in dotazione. Alla fine, è una questione prettamente soggettiva: in fondo, meno restrizioni più libertà, ogni limitazione ha i suoi punti a favore o viceversa.


Parlavo dei linguaggi ad alto livello largamente utilizzati e non mi riferivo alla sintassi in cui ognuno e strutturato. La difficoltà consiste nel tipo di modifica/aggiunta da mettere in atto ed in parte al linguaggio scelto, anche se un bravo programmatore dovrebbe essere in grado di compensare le mancanze che una diversa tipologia di linguaggio potrebbe non presentare. Se il linguaggio utilizzato non si presta al raggiungimento degli obiettivi prefissati, allora è semplicemente la sua scelta errata ad essere alla base degli impedimenti.

Per la cronaca, la R* ha sviluppato un linguaggio in-house denominato GTA3script per la trilogia di GTA allo scopo di gestire gli script, compilati in un proprio bytecode, al di fuori dell'eseguibile. La sintassi è molto basilare ed è stata concepita appositamente per ottemperare a determinati usi e facilitarne la leggibilità. IV e V seguono lo stesso filone, ma che io sappia nessuno si è ancora preso l'impegno di dar vita ad un compilatore/decompilatore che dia la possibilità di scriptare in maniera nativa, quando invece si è optato per la controversa scelta di programmare mediante l'uso di linguaggi .NET.

Siamo OT, non vorrei dilungarmi più di tanto e rendere frammentarie le risposte inerenti alla discussione, però è comunque un argomento interessante.

k tranquillo
Si ho capito che intendi, con un very high poly basta mappare la mesh su un texture totalmente di un colore perché non necessità di ulteriore dettaglio, invece con un low poly serve più precisione per "incastrare" perfettamente la texture. Però c'è anche da dire che se è stato creato da zero come dici la difficoltà si sposta dall'uv map alla modellazione della mesh che richiede molta più dedizione.
Per la conversione dipende, prende il nome di conversione un modello 3D adattato e strutturato in modo da soddisfare le richieste di un determinato gioco, quindi potrebbe essere anche un modello creato da zero, non per forza dev'essere proveniente da un altro gioco.
Un modello high poly richiede più impegno e attenzione anche per un una semplice selezione, poi come dici può darsi sia una cosa soggettiva.

Le mancanze di alcuni linguaggi difficilmente si possono compensare, ogni linguaggio ha il suo limite il quale anche un bravo programmatore non sarebbe in grado di superare. Per questi motivi in base al risultato finale desiderato si sceglie il tipo di linguaggio.
Con il C si possono creare "giochi", ma i risultati finali non sono all'altezza delle aspettative, per questi motivi si opta per il java.

La scelta di scriptare nativamente probabile sia stata scartata a prescindere. Scriptando in .asi, .lua, .net, .cs, etc, si ha la possibilità di aggiunta/rimozione degli stessi in modo facile e veloce, oltre alla possibilità di controllare funzioni native del gioco (esempio lo script che separa retromarcia e freno).
Comodità e semplicità che svalutano totalmente compilatori/decomplicatori.

OT neanche più di tanto, si è parlato anche pagine fa di script, 3D, e quant'altro

RYANCQQPER, il 23 novembre 2015 - 20:35 ha detto:

Non ci riesco ad esportare l'ide , ho provato poco fa anche importando la porta da sola e quando clicco esport ide da gimps iv mi dice sempre : Can't find the "dev_map" parent dummy . Ho anche selezionato tutti i file della porta ma non va.

Oggi penso di aver finito l'esterno della casa , quanto lavoro , siccome la casa nuova era diversa dalla originale ho dovuto smontare scale e vari pezzi della porta per ridimensionarli e farli combaciare il piu possibile , ho dovuto poi tagliare anche pezzi di muro esterno intorno alle porte della casa ,quante prove ne ho fatte entrando in game e verificare . Sono contento di quello che sono riuscito a fare con il tuo aiuto e quello di google.

Perché bisogna sistemare la gerarchia poi vediamo come fare.

Bel lavoro, poi magari posta qualche foto di com'è ora.

Messaggio modificato da Kubo il 23 novembre 2015 - 23:43

[RYANCQQPER]

Arcash, il 23 novembre 2015 - 23:04 ha detto:

Ma poi la renderai disponibile al download?

Quando la casa sara completa con interno ed esterno certo che la rendero disponibile per tutti .
Se ti riferivi solo per l'esterno perche la vuoi provare posso fare anche quello appena risolvo un problemino .

@Kubo il problemino sarebbe il seguente : esterno casa finito in zmodeler provato nel gioco ed e ok . Gli mancava i poligoni dei muri da tagliare ed in zmodeler non so come si fa percio l'ho fatto in 3ds max selezionando l'intera casa convertire to edit poly poi selezionato i poligoni da tagliare e usato quick slice; tutto perfetto nel programma ,poi convertito di nuovo in edit mesh ed esportato in odr . Ora nel gioco tutto l'esterno della casa non si vede piu , cosa ho sbagliato ?

Messaggio modificato da RYANCQQPER il 24 novembre 2015 - 14:16

[Wesser]

Kubo, il 23 novembre 2015 - 23:43 ha detto:

Prende il nome di conversione un modello 3D adattato e strutturato in modo da soddisfare le richieste di un determinato gioco, quindi potrebbe essere anche un modello creato da zero, non per forza dev'essere proveniente da un altro gioco.

La conversione presuppone l'esistenza di qualcosa che venga convertito, quindi o un modello creato da zero oppure uno estratto da qualche parte. Questo intendevo.

Kubo, il 23 novembre 2015 - 23:43 ha detto:

Con il C si possono creare "giochi", ma i risultati finali non sono all'altezza delle aspettative, per questi motivi si opta per il java.

Noto con grande rammarico che sottovaluti il povero C. Non è un linguaggio orientato agli oggetti ed il suo utilizzo è prevalentemente incentrato allo sviluppo di API, ma per contro permette di avere il pieno controllo sulle operazioni a basso livello ed una maggiore correlazione tra il codice precompilazione e quello postcompilazione visto che il sorgente viene compilato direttamente in linguaggio macchina anziché in un bytecode intermedio. Il Java dal suo canto può avvalersi dell'ereditarietà di classi, può produrre un codice meno performante ma limitatamente cross-platform. Per l'ambito di riferimento, si dovrebbe optare per un linguaggio C esteso, ovvero il C++ per certi versi.

Kubo, il 23 novembre 2015 - 23:43 ha detto:

La scelta di scriptare nativamente probabile sia stata scartata a prescindere. Scriptando in .asi, .lua, .net, .cs, etc, si ha la possibilità di aggiunta/rimozione degli stessi in modo facile e veloce, oltre alla possibilità di controllare funzioni native del gioco (esempio lo script che separa retromarcia e freno).
Comodità e semplicità che svalutano totalmente compilatori/decomplicatori.

Il motivo per cui è stata scartata è molto semplice: non ne si conosce la sintassi. Non so se sia stato "dimenticato" qualcosa nelle copie a partire da IV, ma nei capitoli precedenti è possibile appurare parte della composizione del linguaggio all'interno di un file sorgente lasciato incustodito. Successivamente, con le edizioni rilasciate in occasione del decimo anniversario di III, VC e SA, la War Drum Studios ci ha, non so quanto volutamente, omaggiato con quasi tutti i file sorgenti dello script di III (senza quello principale che include tutti gli altri), con il compilatore utilizzato dagli sviluppatori per compilare i sorgenti di VC (purtroppo non rilasciati) da cui sono state estrapolate le definizioni di tutti i comandi supportati dal suddetto gioco (tipi di dato di ogni argomento annessi) ed infine con la lista di tutti i nomi dei comandi disponibili in SA all'interno dell'eseguibile. In questo modo, si è potuto constatare con un'accuratezza di un buon 90% quale sia la sintassi nativa e ricostruirla lì dove non vi sono state fornite informazioni tangibili. Se sei interessato, cerca "GTA3script III/VC definitions" su Google (i primi 2 risultati, tutta opera mia). Per IV, V e successivi si potrebbe procedere con un adeguamento della vecchia sintassi secondo le innovazioni apportate al nuovo sistema scripting.

I linguaggi .NET sono sicuramente più versatili, di fatti come hai accennato possono invocare oltre ai comandi di scripting anche funzioni interne all'eseguibile senza molti raggiri (uno dei motivi per il quale la libreria CLEO è stata sviluppata) e sfruttare le varie peculiarità del linguaggio ma, a giudicare dalla costanza con cui V viene aggiornato, al momento è una soluzione assai problematica e rivedibile. Uno dei limiti è certamente l'impossibilità di modificare gli script originali, cosa che un compilatore/decompilatore, ovviamente, permetterebbe. Per una questione di principio, per le motivazioni per cui è nato (prima fra tutte la semplicità seguita dalla leggibilità e dalla velocità di redazione), il metodo nativo di scripting dovrebbe essere il più accreditato sempre e comunque.

Messaggio modificato da Wesser il 24 novembre 2015 - 16:42

[Kubo]

RYANCQQPER, il 24 novembre 2015 - 14:15 ha detto:

@Kubo il problemino sarebbe il seguente : esterno casa finito in zmodeler provato nel gioco ed e ok . Gli mancava i poligoni dei muri da tagliare ed in zmodeler non so come si fa percio l'ho fatto in 3ds max selezionando l'intera casa convertire to edit poly poi selezionato i poligoni da tagliare e usato quick slice; tutto perfetto nel programma ,poi convertito di nuovo in edit mesh ed esportato in odr . Ora nel gioco tutto l'esterno della casa non si vede piu , cosa ho sbagliato ?

Non serve convertire in edit mesh, lascia tutto così ed esporta.
Non si vede l'intera casa? O c'è solo quell porta posizionata male?
Ora non ho capito bene che è successo, se hai un backup precedente a questa modifica usa quello, così vediamo questa cosa in tranquillità.

Wesser, il 24 novembre 2015 - 15:31 ha detto:

In questo modo, si è potuto constatare con un'accuratezza di un buon 90% quale sia la sintassi nativa e ricostruirla lì dove non vi sono state fornite informazioni tangibili. Se sei interessato, cerca "GTA3script III/VC definitions" su Google (i primi 2 risultati, tutta opera mia). Per IV, V e successivi si potrebbe procedere con un adeguamento della vecchia sintassi secondo le innovazioni apportate al nuovo sistema scripting.
A giudicare dalla costanza con cui V viene aggiornato, al momento è una soluzione assai problematica e rivedibile. Uno dei limiti è certamente l'impossibilità di modificare gli script originali, cosa che un compilatore/decompilatore, ovviamente, permetterebbe. Per una questione di principio, per le motivazioni per cui è nato (prima fra tutte la semplicità seguita dalla leggibilità e dalla velocità di redazione), il metodo nativo di scripting dovrebbe essere il più accreditato sempre e comunque.

Questo è interessante, forse per V appunto è ancora impossibile visto i continui aggiornamenti, ma per IV si potrebbe fare tranquillamente.

[RYANCQQPER]

@kubo Si ... il file che avevo esportato da open 4 per tagliare i poligoni in 3ds max aveva un bug ,ci riprovo

Edit : ci sono riuscito , come vedi il telaio della porta e piu grande e compatibile con la porta stessa ,poligoni dei muri tagliati e in game funziona anche questo. Manca spostare la lampadina all'ingresso un po a destra (ancora non la trovo) e una porta garage se riesco ad aggiungerla

Messaggio modificato da RYANCQQPER il 24 novembre 2015 - 20:23

[Kubo]

RYANCQQPER, il 24 novembre 2015 - 18:04 ha detto:

@kubo Si ... il file che avevo esportato da open 4 per tagliare i poligoni in 3ds max aveva un bug ,ci riprovo

Edit : ci sono riuscito , come vedi il telaio della porta e piu grande e compatibile con la porta stessa ,poligoni dei muri tagliati e in game funziona anche questo. Manca spostare la lampadina all'ingresso un po a destra (ancora non la trovo) e una porta garage se riesco ad aggiungerla

Okk buono, devi lasciare sempre la modifier list com'è al momento dell'esportazione, altrimenti si creano bug
La porta non era quella bianca? non ce sto a capì più nulla
Per la porta facciamo una cosa, dopo che hai importato garage e porta, in alto nella barra dove ci sono le opzioni di selezione, movimento, scala, etc, a destra accanto a material editor (la palla a quadri) c'è schematic view, clicca e fammi uno screen di quella schermata che vediamo com'è messa la gerarchia.

PS: ma il garage si trova in puclic_2 giusto? La porta del garage dove si trova?

Messaggio modificato da Kubo il 24 novembre 2015 - 21:39

[RYANCQQPER]

Certo che era bianca , ho dovuto cambiare la texture per essere uguale al telaio della porta
La porta garage si trova in maps/jersey/nj_01.img/nj01_garagedoor03.wdr è quella originale del garage nuovo che ho sostituito al posto del vecchio garage.
Eccola , come vedi la porta sta sotto la casa ,non l'ho sistemata perche ti ricordi non voleva esportare l'ide.

Messaggio modificato da RYANCQQPER il 24 novembre 2015 - 22:35

[Kubo]

ahh ok ok
Saprei come metterla, il problema è che dovrei ragionarci su su come renderla dinamica
Se la dobbiamo mettere lasciando statica basta eliminare "nj01_garagedoor..." e "NJ01_garageDoor..." in verde dalla gerarchia, spostare "nj01_garagedoor..." blu (o viola chiaro) sotto "nj01_bigwhiteho...", attaccare "nj01_garagedoor..." blu a "nj01_bigwhiteho..." blu (in modo che sotto "nj01_bigwhiteho..." rimangano solamente "nj01_bigwhiteho..." e "0"), e infine esporti in odr.

Se la dobbiamo fare dinamica ripeto, devo ragionarci un po' su perché la porta del garage è un modello a se e fa parte dello stesso file img, prima erano solo poligoni texturizzati.
Qui abbiamo anche il wpl e xpl, si fa un po' più complessa la cosa.
Adesso vedo un po' cosa si può fare.

[RYANCQQPER]

Guarda ,per me puo restare anche senza porta garage ,tu me l'hai proposto nelle prime pagine e mi era piaciuta l'idea ma se è cosi difficile si puo rinunciare. Casomai si aggiunge una con simple native trainer object spam che sara pure dinamica .Siccome per la prima non sono capace lascio a te decidere , poi mettero anche il tuo nome come collaboratore del progetto quando sara finito se sei d'accordo

Edit :Mi è venuta un idea , se faccio una copia di quella porta garage e invece del nome originale nj01_garagedoor03 ci metto nj01_garagedoor04 ,poi in zmodeler o 3ds max la sposto la copia fino alla casa mia ,salvo e la importo nel file img .... potrebbe funzionare o serve per forza una stringa ide tutta sua ?

Ti ricordi anche il bug alle scale e tu hai detto che è colpa di rockstar , ho trovato il suo file e l'ho sistemato

Messaggio modificato da RYANCQQPER il 25 novembre 2015 - 12:06

[Kubo]

No ma è meglio se la mettiamo dimanica per conto suo
ahah come vuoi per me non c'è problema

No tranquillo non serve a niente copiarla, non comparirebbe comunque senza la stringa sua, modifichiamo il wpl. Sto già sistemando qualcosa, solamente che qua giusto per complicarmi un po' la vita i valori sono a casaccio e non più in ordine


Ok, prova a sostituire il file nj_01.wpl con il mio: http://www.mediafire...s6yfc/nj_01.wpl
Se sta andando dovresti vedere una porta di garage che svolazza esattamente sopra la tua casa.

Messaggio modificato da Kubo il 25 novembre 2015 - 17:54

[RYANCQQPER]

Fatto , qualcosa è andato storto pero , guarda le texture di ogni cosa e poi mancano palazzi e strade . Comunque se sei riuscito a spostarla è un passo avanti perche mi servira sapere come si fa per spostare vari oggetti nella casa (esempio armadietto per meccanico ,crick per motori andranno messi nel garage).
Io adesso sto lavorando sul garage perche il terreno sotto di esso non è dritto cosi ho deciso di alzare di poco il garage mettere una collisione sotto , aggiungere una rampa con collisione è sta venendo su bene , insomma come ai garage che vedi in giro in game

Foto per il tuo wpl

[Kubo]

Eccola, no non l'ho spostata, è proprio un'altra porta garage che ho aggiunto io

Se rimetti il wpl originale torna tutto normale? Devo capire se la colpa è del wpl.

Dopo che mi dai la risposta dobbiamo fare altri 2 test, sempre sul wpl.
Poi successivamente vediamo anche di cambiare anche il modello della porta garage che quella è troppo stretta e soprattutto come renderla dinamica.

Messaggio modificato da Kubo il 25 novembre 2015 - 22:37

[RYANCQQPER]

Si tutto torna normale con il wpl originale . Scusa se non ho risposto ieri sera , guardavo Colorado .
AH qualcosa simile mi è successo anche a me quando ho trovato la stringa dello stereo che suona heavy metal , eliminandola dentro casa stereo era sparito ma le ombre erano diventate strane come nella prima foto per il wpl .

[Kubo]

Tranquillo quando vuoi e puoi rispondi, non c'è fretta
E la stringa della radio dove l'hai trovata? Dentro che file era?
Io direi che il fatto delle robe mancanti cerchiamo di risolverlo dopo, prima mi servirebbe capire un paio di cose con quei 2 test di cui ti parlavo.

k, l'altezza è la stessa, è sempre più in alto della casa. Mi servirebbe uno screen di fronte e di lato della casa per capire se è andato avanti/indietro/di lato (e da quale lato):
http://www.mediafire...25zuz/nj_01.wpl