Visualizza la versione completa : Calcoli produzione in Situazione Economica? Bug Mulino?
Stanotte stavo facendo i calcoli per un file excel che userò per tenere traccia della mia produzione ma ho scoperto "qualcosa" che non torna con la produzione del "Mugnaio"
Entro nel dettaglio sperando che qualcuno possa trovare il bandolo della matassa. Ho verificato invece sul Macellario e i conti sembrano tornare a me, ma ad un mio compagno di gilda non tornano manco quelli.
Un Mulino Liv. 3 accanto (dx) del Magazzino mi dice che un ciclo completo per 3 di farina viene compiuto in 6:24
Iniziamo a fare i conti in tasca al mugnaio...
6.24m = 384 sec
12h = 43200 sec
43200 (12h) / 384 (ciclo di produzione) = 112.5 (cicli di raccolta ogni 12h)
112.5 x 3 (sacchi di farina) = 337.59 (sacchi ogni 12h)
Il mugnaio in-game nella Situazione Economica da = 336 (-1.59 sacchi ogni 12h)
arrotondando, sono 1 o 2 sacchi di farina in meno SEMPRE. Ovviamente per molti sarà trascurabile, ma moltiplicato per settimane mesi, anni è un numero grosso... che il mugnaio abbia un ladro in mezzo ai propri operai? E se questo problema si presenta in produzioni molto costose?
Chiedo lumi dallo staff, almeno che se ci sono errori d'interpretazione ne possiamo essere al corrente, mentre se è un bug venga segnalato a chi di dovere.
Premessa:
-Non erano presenti buff
-Il bug o errore è stato verificato da piu giocatori)
-I calcoli sono stati rifatti varie volte
-Il problema è saltato fuori perchè le mie formule di excel calcolavano giusto e il game no!
-Altri edifici sono calcolati tenendo presente solo 2 decimali
Update:
Ulteriori verifiche hanno portato a scoprire che un Mugnaio liv4 non ha nessuna perdita nenahce minima, forse per il tempo e la distanza dal magazzino o per altro?
Ecco i dati
6.40m = 400 sec
43200 (12h) / 400 ciclo di produzione) = 108 (cicli di raccolta ogni 12h)
108 x 4 (sacchi di farina) = 432 (sacchi ogni 12h)
STESSO VALORE riferito nella Situazione Economica di questo caso particolare.
Potrebbero essere i decimali? Forse ma improbabile, nel caso sopra 337.59 andrebbe arrotondato matematicamnete a 337 o 338 ma mai a 336.
Potrebbe essere che gli edifici sono "programmati" per perdere produzione ai livelli piu bassi? Forse
Oppure forse è un bug/errore di calcolo...e per un gioco che basa tutto sulle risorse, sui tempi di raccolta e sulla poszione per ottimizzare quest'ultima, è degno di attenzione secondo me.
Tutti noi cerchiamo e diventiamo pazzi a inventarci idee per mettere produzioni vicine a magazzini, con pochi sec di raccolta e nelle zone giuste, anche poche perdite vanno a inficiare questo lavoro di precisione.
gabbianano
03.02.14, 11:09
quoto in pieno.
Pzsniper questa perdita molto probabilmente è dovuta tra la fine è l'inizio di un ciclo produttivo in fase di elaborazione si ha una perdita di qualche secondo che sommate in 12h si ha una perdita di produzione irrilevante e difficile da stabilizzare!
Stanotte stavo facendo i calcoli per un file excel che userò per tenere traccia della mia produzione ma ho scoperto "qualcosa" che non torna con la produzione del "Mugnaio"
Entro nel dettaglio sperando che qualcuno possa trovare il bandolo della matassa. Ho verificato invece sul Macellario e i conti sembrano tornare a me, ma ad un mio compagno di gilda non tornano manco quelli.
Un Mulino Liv. 3 accanto (dx) del Magazzino mi dice che un ciclo completo per 3 di farina viene compiuto in 6:24
Iniziamo a fare i conti in tasca al mugnaio...
6.24m = 384 sec
12h = 43200 sec
43200 (12h) / 384 (ciclo di produzione) = 112.5 (cicli di raccolta ogni 12h)
112.5 x 3 (sacchi di farina) = 337.59 (sacchi ogni 12h)
Il mugnaio in-game nella Situazione Economica da = 336 (-1.59 sacchi ogni 12h)
Il problema è nella divisione "43200 (12h) / 384 (ciclo di produzione) = 112.5 (cicli di raccolta ogni 12h)" in cui è sbagliato l'arrotondamento. Infatti il sistema probabilmente arrotonda a 112 (ed infatti 112 x 3 = 336, il numero che tu ti ritrovi), mentre essendo 112,5 avrebbe dovuto (secondo l'approssimazione matematica) arrotondare a 113 (da 5 a 9 si arrotonda sempre alla cifra superiore). Sarebbe interessante capire se è un'approssimazione calcolata male solo per questo edificio (ma non credo) o se l'approssimazione è sempre stabilita in questa maniera da parte del sistema (per qualsiasi edificio chiaramente).
Quoto con l'interpretazione di Eleinad :)
Dicendo anche che è da 6 a 9 che si arrotonda per eccesso, mentre sul 5 ci sono vari correnti di pensiero: difetto, eccesso o niente :)
Purtroppo anche io ho pensato questo Eleinad ma sulle 24h NON esiste il problema del decimale infatti è 225 e non esiste errore id calcolo dercimale li... ma perdi LO STESSO.
Ho verificato coemedetto gia questa porobabilità, ma gli arrotondamenti limano i 2 decimali al numero prima o quello dopo non tolgono 1.5.
Sul Macellaio un mio compagno di gilrda aveva un ammanco di qausi 3 salsicce sulle 12h sono 6 sulle 24!
Mi fa piacere abbiate messo anche voi un po di tempo a capire l'inghippo, ma credo solo uno dello staff può aiutarci a capire...
Stasera dopo cen aproverò a verificare altre produzioni a lato magazizno e vediamo cosa salta fuori...
Preciso che il problema non è tanto la persita di 1 sacco o 2 è che se è un errore di calcolo possiamo aspettarci che in altre produzioni e consideratate quante sono le variabili che entrano in gioco (distanza magazzino, buff, livello..) ci sia la possibilità che ognuno di noi abbia un lenta, minima ma COSTANTE eperdita di risorse... questo è un probkema di meccanica di gioco. Se è un bug va segnaalto, se è un arrotondamento o regola definita dai dev sarebbe opportunos aperlo.
Dico la mia teoria esposta anche PzSniper in chat globale:
I calcoli si basano sulla precisione assoluta quindi 1minuto=60secondi, mentre forse il gioco non ha tutta questa precisione quindi 1minuto=60.2secondi sembra irrilevante ma su 12h abbiamo una non produzione di risorse.
Dopotutto vi siete mai accorti che le 24h della ricerca di un esploratore non sono 24h ma 24h e qualche minuto?
Per me può essere questo il problema, dopotutto non si potrà mai avere la precisione però i dati forniti dal gioco sono esatti sulle reale produzione questo è buono :)
Ringarzio Armadillo per il tempo perso su sta faccenda... dunque, ammesso che quanto dice Armadillo sia possibile, di solito in un gioco online nel calcolo dei tempi di risposta entra in campo il fattore "lag" cioè la latenza tra cui il ns pc invia un'informaizone tipo (sposta mirino a destra) e questo si rifletta realmente suls erver e per gli altri giocatori... in questo caso la "lag" potrebbe influenzare un esploratore o un rilegatore aggiungendo qualche secondo in piu di produzione, ma questo non andrebbe a intaccare piu di tanto il magazzino e sopratutto sarebbe VARIABILE la perdita.
Se c'è la rete congestionata oggi perso 3 sacchi, domani che il server è meno carico perdo 1 sacco... ma se è cosi sorgono altre domande:
Il tempo è calcolato precisamente o c'è uno scarto impostato dai developers?
Come mai alcune produzioni tipo Mugnaio liv 4 NON soffrono di questo ritardo?
Molte domande e poche risposte heheh... speriamo di poter far luce presto...
o semplicemente il gioco non approssima i decimali, e quando calcoli 102,5 lo riporta semplicemente come 102 e basta, così vedi che i conti tornano.
il gioco si basa su una tabella che no ha decimali e approssima in difetto. prova a correggere la tua tabella in excell e vedrai che ti trovi.
Secondo me fissarsi sulla cosa dei decimali per giustificare dei conti errati non regge, ho gia spiegato in varie simulazioni che anche se ci sono i decimali sulle 12h (112.5 cicli) non ci sono sulle 24h (225 cicli) nel caso del Mugnaio liv 3, dopo l'analisi qui fatta credo bisogni attendere solo una risposta ufficiale, se è una questione di decimale buono a sapersi, ma l'arrotondamento è sempre del solo decimale stesso NON di 1 nuemero primo come gia ho detto su.
"Potrebbero essere i decimali? Forse ma improbabile, nel caso sopra 337.59 andrebbe arrotondato matematicamnete a 337 o 338 ma mai a 336."
Attendiamo lumi ^^
Credo che l'arrotondamento venga fatto prima del calcolo finale.
E` vero che sarebbero 112.5 cicli di produzione ogni 12 ore.
Ma un "mezzo ciclo" non produce nulla, quindi in 12 ore vengono completati 112 cicli.
In 24 ore, però, i cicli completati sono 112.5 x 2, cioè 225 (perché in questo caso i due mezzi cicli fanno un ciclo completo).
Io farei una verifica sulla produzione effettiva nell'arco delle 24 ore, non mi baserei solo sulla visualizzazione della produzione su 12h.
Secondo me l'unica cosa che viene arrotondata è la visualizzazione, ed in modo corretto, perché un ciclo incompleto non produce nulla e va sempre arrotondato per difetto.
Il fatto che con altre strutture o altri livelli non si noti l'arrotondamento, forse dipende solo dal fatto che il numero di cicli in 12 ore è un numero intero.
Tra l'altro, la produzione non avviene in blocchi da 12 ore, bensì per ogni ciclo di produzione vengono aggiunte risorse.
Chi ha tempo e voglia, faccia una verifica sulla produzione effettiva e non su quella riportata nella schermata.
Per attendere 24h e vedere le giacenze reali serve avere magazizno vuoto della risorsa e aspettare ... insomma forse è eccessivo perchè cmq i dati sn quelli che vedi non è che ti trovi piu risorse a fine delle 24h, la matematica non è un'opione no? :) Poi se la schermata economica mette numeri a caso quello non lo so..ma mi auguro di no.
Dopo cena proverò a verificare altre produzioni e fare altri calcoli che posterò qua.
Niente, stesso problema si presenta x una Fattoria a caso...
Fattoria Liv 4
NO BUFF
Tempo Produzione Ciclo (12:44) 764 sec x 4 grano
43200 (12h) / 764 (ciclo di produzione) = 56 (arrotondato) cicli di raccolta ogni 12h
56 x 4 grano
Produzione sulle 12/h IN SITUAZIONE ECONOMICA = 224 Grano
ANCORA DISCREPANZE!
43200 (12h) / 764 (ciclo di produzione) = 56.54 cicli di raccolta ogni 12h
56.54 x 4
Produzione sulle 12/h CON LA CALCOLATRICE = 226.16 Grano
Anche qui arrotondamento o decimali che volete ma il calcolo è sbagliato... doveva essere o 226 o 227 /12h!
43200 (12h) / 384 (ciclo di produzione) = 112.5 (cicli di raccolta ogni 12
Oramai è inutile stare a fare verifiche ulteriori è ASSODATO che i conti nella schermata del gioco SITUAZIONE ECONOMICA sono in diverse occasioni sbagliati per via dei decimali. Non è un'opinione è matematica...
Ribadisco quanto gia analizzato da altri player, *sembra* che il gioco ANNULLI completamente i decimali e sempre IN DIFETTO... strano per un gioco che si basa sull'economia e calcolo risorse i dev abbiamo inserito una regola cosi poco precisa.
L'unico che può spiegarci realmente quali regole e/o quali arrotondamenti siano fatti è solo lo staff.. attendiamo fiduciosi, cosi da poter noi stessi farci i conti tenendo presente la reale meccanica che poi il gioco utilizza (specie per i fogli di calcolo excel tutto sballati attualmente)
Come mai è importante capire la formula di arrotondamento? Perchè se applicate ad un foglio di calcolo la produzione di carcone come nell'esempio sotto notate che è impossibile stabilire un trend corretto, notate come dal mio excel risultano i calcoli:
http://i.imgur.com/qWmNSHC.png
Quadrato Blu = calcolo CORRETTO con decimali del consumo di legno di pino basato sul tempo.
Quadrato Verde = calcolo ARROTONDATO a +1 (vedi formula (H9*J9)+ARROTONDA(1;0)) per compensare e avere il valore dato da Situazione Economica
Quadrato Verde = calcolo ARROTONDATO a -3 (vedi formula (H31*J31)+ARROTONDA(-3;0)) per compensare e avere il valore dato da Situazione Economica
Come vedete è impossibile capire come arrotondare per far combaciare i dati del gioco con calcoli reali, NEMMENO sul consumo della risorsa, in questo caso legno di Pino, quindi NON SOLO sulla produzione, degli esempi prima, della Farina o Grano.
Viene lecito domandarsi a che serve stare a cercare di ottimizzare i piazzamenti delgi edifici attorno al magazzino sfruttando le posizioni più vicino 6secondi, 8 secondi, 10secondi e cosi via... se poi il tutto viene "ammazzato" da arrotondamenti netti.
PzSniper: guarda che la soluzione è semplice.
è esattamente come ha scritto Looka:
Credo che l'arrotondamento venga fatto prima del calcolo finale.
E` vero che sarebbero 112.5 cicli di produzione ogni 12 ore.
Ma un "mezzo ciclo" non produce nulla, quindi in 12 ore vengono completati 112 cicli.
In 24 ore, però, i cicli completati sono 112.5 x 2, cioè 225 (perché in questo caso i due mezzi cicli fanno un ciclo completo).
il gioco mica calcola su valori continui, bensì su valori discreti.
cioè, prendiamo ad esempio una fattoria:
quanti cicli completi fa una fattoria in 12 h?
56.
NON 56.54.
56 x 4?
224.
i conti tornano.
fine della storia.
tu invece fai i calcoli contando i mezzi cicli (o cicli non completati, se preferisci chiamarli così)
...che ovviamente, non esistono.
il gioco conta solo i cicli completati, mica quelli che sono ancora a metà della produzione.
e quindi non c'è nessuna discrepanza:
ANCORA DISCREPANZE!
43200 (12h) / 764 (ciclo di produzione) = 56.54 cicli di raccolta ogni 12h
56.54 x 4
Produzione sulle 12/h CON LA CALCOLATRICE = 226.16 Grano
Anche qui arrotondamento o decimali che volete ma il calcolo è sbagliato... doveva essere o 226 o 227 /12h!
tu calcoli un 0.54 di ciclo che non esiste in pratica.
0.54 x 4 = 2,16
224 + 2,16 = 226,16
vedi che i conti tornano sempre? ;-)
nel foglio di excel sbagli perché non devi arrotondare il risultato finale, bensì il numero di cicli effettuati in 24 h (arrotondato per difetto, ovviamente)
prova e vedrai che i conti tornano perfettamente!
Quoto quando espresso da vigno, sarebbe però bene che i calcoli fossero verificati da chi di dovere!
No , quello è gia stato assodato prima (che i decimali si sono annullati), ed è un passo avanti nella comprensioen della meccanica del gioco.. ma vai avanti a leggere il resto dell'indagine... come applicare tale arrotondamento? Che regole ha? Guarda dei test per correggere questo comportamento su Excel..come fare a creare una formula corretta?
Quella che vedi è la formula applicata al consumo di pino MA anche ai cicli ho emsso la formula arrotondo sempre
Infatti =((43200/E8)) DAVA 211.76 cicli
tramutata in
=((43200/E8))+ARROTONDA.PER.DIF(-1;0) CHE DA 221 cicli (come in game) x far quadrare tutto
Ma come fare x dare uan regola unica alla formula excel? Mi sballa a seconda del ciclo! Vedi Ultima simulazione riga 31
Si Pippof, è chiaro che vigno e altri player, me comrpeso, alla fine nella prima parte dell'indagine abbiamo identificato CHE SI, il gioco NON considera i decimali, ma ora c'è da capire come fare per estrarre e calcolare sempre correttamente le produzioni per nostro uso.
Che regole mettere in excel per non trovarsi tutto sballato?
e poi..
Come influenza questo realmente la posizione del magazzino?
Ci sono molte domande a cui mi piacerebbe avere risposta (emerse nei vari messaggi su), senza limitarci a dire "ok non conta i decimali del ciclo" e basta ^^
Sempre a beneficio della community al fine di una maggior comprensione delle meccancihe di gioco.
Si Pippof, è chiaro che vigno e altri player, me comrpeso, alla fine nella prima parte dell'indagine abbiamo identificato CHE SI, il gioco NON considera i decimali, ma ora c'è da capire come fare per estrarre e calcolare sempre correttamente le produzioni per nostro uso.
Che regole mettere in excel per non trovarsi tutto sballato?
e poi..
Come influenza questo realmente la posizione del magazzino?
Ci sono molte domande a cui mi piacerebbe avere risposta (emerse nei vari messaggi su), senza limitarci a dire "ok non conta i decimali del ciclo" e basta ^^
Sempre a beneficio della community al fine di una maggior comprensione delle meccancihe di gioco.
La regola da mettere in Excel francamente non saprei quale può essere e non penso di volermi mettere lì ad estrarla :P
Per quanto riguarda la posizione del magazzino è chiaro che ha influenza sui quegli edifici che porterebbero ad un'approssimazione decimale piccola, mentre ha pochissima influenza su quegli edifici ad approssimazione decimale alta.
Faccio l'esempio con la torre d'oro.
Produce 58 monete l'ora.
Mettendola a 24 secondi dal magazzino il ciclo sarebbe di 744 secondi.
Il ciclo di 12 ore sono 43200.
Il risultato è 43200/744 = 58,06
Portandola ad una distanza più lontana, per esempio 28 secondi il risultato sarebbe 57,8. La produzione totale visualizzata nella situazione economica sarebbe 57 e si perderebbe 1 moneta ogni 12 ore a causa del posizionamento.
Proviamo a prendere un esempio al contrario.
Le mi segherie di legno duro sono poste a 32 secondi e producono ogni 572 secondi.
Significa che la produzione è 43200/572 = 75,52, chiaramente 75.
Se fossero state alla distanza minima per un magazzino, 24 secondi, il risultato sarebbe stato superiore (il denominatore è più basso): 76,59 quindi 76.
Trovo questo esempio molto interessante perchè nella posizione ottimale sia ha comunque una discreta perdita, nella posizione successiva (a 32 secondi) si perde un
asse e si continua ad avere una discreta perdita per l'approssimazione.
Se facessimo il calcolo a ritroso per 76 assi la posizione ottimale sarebbe a 28 secondi, a 36 secondi per la posizione che produce 75.
Purtroppo il calcolo mi sembra abbastanza complesso per poter comprendere, a priori, qual è la posizione ideale per ogni edificio. Quindi, considerando che ogni il calcolo è in difetto uno dovrebbe valutare la propria produzione a 24 secondi quanti decimali ha. Se ne ha pochi, può valutare il peso spostando l'edificio a 32 secondi: se non intacca l'unità e ha solo più decimali (quindi in teoria maggior perdita) ha liberato la posizione a 24 secondi che può sfruttare con un altro edificio che potrebbe averne un guadagno. Ad ogni modo parliamo di differenze che valgono il recupero di 1 pezzo ogni 12 ore... ossia 2 pezzi al giorno.
E' vero che non si butta via niente ma in un anno parliamo di 726 pezzi persi nelle approssimazioni...
Voglio fare un esempio ancora più lampante di questa cosa ahaha :D
Scuola del villaggio: tempo di produzione di 1 settler 2 ore. In teoria sarebbero 6 settler ogni 12 ore ma dato che c'è il tempo di trasporto al magazzino (ma basterebbe anche 1 secondo in più al tempo di produzione), la produzione è di 5,98 settler ogni 12 ore. Morale della favola: dato che alla fine sempre 5 settler prendi, uno potrebbe mettere la scuola a 24 minuti da un magazzino senza avere nessuna perdita (a 24 minuti prenderebbe esattamente 5 settler).
Capitan_Fungus
04.02.14, 15:18
Secondo me è un finto problema.
Il dato di produzione ogni 12 ore è solo indicativo, quello che importa è ogni quanto si completa un ciclo.
Se volete vederla così è la stessa cosa, la produzione si completa in tot cicli e non tot secondi quindi non sono 12 ore, ma a seconda dell'edificio e della distanza dal magazzino, potrebbero essere 11 ore 58 minuti e 34 secondi (ho detto un numero a caso).
Comunque quello che importa è che non c'è una reale perdita di produzione.
Secondo me è un finto problema.
Il dato di produzione ogni 12 ore è solo indicativo, quello che importa è ogni quanto si completa un ciclo.
Se volete vederla così è la stessa cosa, la produzione si completa in tot cicli e non tot secondi quindi non sono 12 ore, ma a seconda dell'edificio e della distanza dal magazzino, potrebbero essere 11 ore 58 minuti e 34 secondi (ho detto un numero a caso).
Comunque quello che importa è che non c'è una reale perdita di produzione.
Quoto, perchè non c'è una non produzione e quindi perdita di risorse ma solo una valore errato sull'economia. Perchè dopotutto il ciclo continua e non si resetta ogni 12h in modo da perdere la produzione.
Che non si perda niente è chiaro. Se io in 12 ore produco 70,5 assi in un giorno 141 assi li produco di sicuro. Non è che facendomi vedere 70 allora quello 0,5 è andato perduto :D
Però se io faccio 70,5 ogni 12 ore alla posizione a 24 secondi e a quella a 32 secondi la produzione passa, per esempio, a 70,1: mi è cambiato qualcosa? Sì, alla fine della giornata non avrò i 141 assi ma ne avrò 140 più un ciclo produttivo che è al punto di avermi prodotto, a quell'istante, 0,2 su 1.
Infatti il mio discorso è stato su questo punto, sull'eventuale posizione dell'ottimizzazione degli edifici:
- x+24 secondi è il tempo della mia produzione ottima
- x+32 secondi è il tempo della mia produzione buona
- valuto quanto è la differenza produttiva in un giorno (meglio delle 12 ore perchè il valore che ottengo posso considerarlo alla stregua di una costante che moltiplicato per il numero di giorni è in grado di dirmi, magari in un anno, a quanto di quel materiale sto rinunciando).
- se sto rinunciando ad un valore che per quel bene a mio avviso è basso posso spostare l'edificio nella posizione buona e recuperare la posizione ottima per la produzione di un bene che ritengo più vantaggioso
Quindi l'approssimazione non fa perdere niente dal punto di vista del materiale in questione. Ma da un punto di vista di posizioni vantaggiose intorno ai magazzi conta, e non poco. Avere una produzione a 24 secondi di 1,95/12h (visualizzato 1) non è come avere una produzione di 1,05/12h (sempre visualizzato 1).
Secondo me è un finto problema.
Il dato di produzione ogni 12 ore è solo indicativo, quello che importa è ogni quanto si completa un ciclo.
Se volete vederla così è la stessa cosa, la produzione si completa in tot cicli e non tot secondi quindi non sono 12 ore, ma a seconda dell'edificio e della distanza dal magazzino, potrebbero essere 11 ore 58 minuti e 34 secondi (ho detto un numero a caso).
Comunque quello che importa è che non c'è una reale perdita di produzione.
esattamente.
PzSniper: quello che cercavo di dirti è che tu stai fraintendendo tutto. xD
per calcolare la produzione degli edifici non c'è bisogno di arrotondare un bel niente!
i calcoli che hai fatto all'inizio sono corretti.
il punto è che è normale che nella tabella Situazione Economica vengano riportati dati diversi da quelli che ottieni...
..perché ti riporta i dati delle risorse effettivamente prodotte in 12 ore, senza l'uso dei decimali, ovviamente.
avrebbe avuto poco senso dirti che in 12 ore produci, che ne so, 200,54 monete:
mica si possono produrre 0,54 monete!
o ne produci 1 oppure ne produci 0 (cioè: il ciclo per la produzione di 1 monete non è stato ancora completato)
il punto, riassunto, è che i dati nella tabella Situazione Economica sono calcolati contando solamente i cicli effettivamente completati in 12 ore.
fine.
ovviamente se allarghi il lasso di tempo a 24h o a 1 mese, i risultati, anche contando solamente i cicli effettivamente completati, saranno più vicini a quelli ottenuti non arrotondando e usando i decimali.
insomma:
non c'è nessun problema. xD
non c'è la perdita di nessuna produzione.
..ed non essendoci nessuna perdita di produzione, la distanza dal magazzino influisce eccome!
perché mai non dovrebbe influire?
Che non si perda niente è chiaro. Se io in 12 ore produco 70,5 assi in un giorno 141 assi li produco di sicuro. Non è che facendomi vedere 70 allora quello 0,5 è andato perduto :D
Però se io faccio 70,5 ogni 12 ore alla posizione a 24 secondi e a quella a 32 secondi la produzione passa, per esempio, a 70,1: mi è cambiato qualcosa? Sì, alla fine della giornata non avrò i 141 assi ma ne avrò 140 più un ciclo produttivo che è al punto di avermi prodotto, a quell'istante, 0,2 su 1.
Infatti il mio discorso è stato su questo punto, sull'eventuale posizione dell'ottimizzazione degli edifici:
- x+24 secondi è il tempo della mia produzione ottima
- x+32 secondi è il tempo della mia produzione buona
- valuto quanto è la differenza produttiva in un giorno (meglio delle 12 ore perchè il valore che ottengo posso considerarlo alla stregua di una costante che moltiplicato per il numero di giorni è in grado di dirmi, magari in un anno, a quanto di quel materiale sto rinunciando).
- se sto rinunciando ad un valore che per quel bene a mio avviso è basso posso spostare l'edificio nella posizione buona e recuperare la posizione ottima per la produzione di un bene che ritengo più vantaggioso
Quindi l'approssimazione non fa perdere niente dal punto di vista del materiale in questione. Ma da un punto di vista di posizioni vantaggiose intorno ai magazzi conta, e non poco. Avere una produzione a 24 secondi di 1,95/12h (visualizzato 1) non è come avere una produzione di 1,05/12h (sempre visualizzato 1).
è esattamente quello che ho fatto io mesi fa (e tenevo per me come segreto =P ):
ci sono edifici che conviene tenere vicino al magazzino.
altri che si possono pure posizionare lontano e la differenza di produzione è davvero minima.
è esattamente quello che ho fatto io mesi fa (e tenevo per me come segreto =P ):
ci sono edifici che conviene tenere vicino al magazzino.
altri che si possono pure posizionare lontano e la differenza di produzione è davvero minima.
Ho rovinato il segreto di Alasdair ahah xD
Sembra che nessuno dello staff ci legga... :( è passata una settimana senza conferma o smentita alcuna...
Salve,
Come ipotizzato da qualcuno di voi, la (minima) differenza è dovuta ad arrotondamenti nel risulato finale della produzione.
In caso di produzioni non "intere", il risultato viene arrotondato per difetto, molto spesso senza creare differenze nel totale.
Come è stato detto poco sopra, potete basarvi su questo fatto per ottimizzare al massimo le vostre produzioni, adeguando le posizioni dei vostri edifici rispetto ai magazzini.
Spero di essere stato d'aiuto.
Buon Proseguimento
Powered by vBulletin™ Version 4.0.4 Copyright © 2025 vBulletin Solutions, Inc. All rights
Traduzione italiana Team: vBulletin-italia.it |