tudnátok ebben konkrétan segíteni ?
eddig nem én csináltam
csak ő el van havazva
és már nem tud vele foglalkozni

Itt regisztrálnod kell egy API key-t, hogy működjön a dolog. Én a v2-vel boldogultam, a v3 az semmit nem akart hosszabb távon megenni.
De a bal oldali menüben ne legyenek kérdőjelek! A Servicesben tudod aktiválni az API-kat. ráklikkelsz az off-ra és így állítod át on-ra. A Team menüpontban tudsz hozzáadni felhasználókat, ha kell. Az API access menüpontban pedig kulcsot generálni.

[ Szerkesztve ]

Ha hallgattál volna, bölcs maradtál volna.

most eddig eljutottam

ezt már csak be kell másolnom a php editorba felülírva az előző kódot ?

http://maps.google.com/maps?file=api&v=2&key=ABQIAAAABD-wgyp55XtjATFDY-GlWxSI23GfI6Vg4NQIHQ2aKR1xcv-8oBQ2lEetLqK2wIFtwPzuqlvEPyPNqQ

Én simán kihagyom belőle a key=akármi részt és megy...

<script type="text/javascript" src="http://maps.google.com/maps/api/js?v=3&sensor=false"></script>

[ Szerkesztve ]

"Moonshine Whiskey (70°, ízesítés nélküli) van. Fincsi" - Teebee - "De az kiírtaná az egész családomat..Akkor is ha csak én innék belőle.." - forintuser

Hát pedig tévedsz, DeltaPower jól mondta, nem kell a v3-hoz API-kulcs. Itt röviden összefoglalják: [link]. Lényeg: 2-eshez még kötelező volt, 3-asnál NEM az.
De ha nem elég bizonyíték, itt van egy nagyon egyszerű példa, mindenféle API-kulcs használata nélkül: http://jsfiddle.net/aknYP/4/
itt találsz még párat...

De hogy mire lehet jó az API-kulcs használata:
https://developers.google.com/maps/documentation/javascript/tutorial?hl=hu#api_key

"Using an API key enables you to monitor your application's Maps API usage, and ensures that Google can contact you about your application if necessary. If your application's Maps API usage exceeds the Usage Limits, you must load the Maps API using an API key in order to purchase additional quota.

* Google Maps API for Business developers must not include a key in their requests. Please refer to Loading the Google Maps JavaScript API for Business-specific instructions.

[...]
By default, a key can be used on any site. We strongly recommend that you restrict the use of your key to domains that you administer, to prevent use on unauthorized sites. You can specify which domains are allowed to use your API key by clicking the Edit allowed referrers... link for your key."

===

(#12949) futár :
"Ez egy idióta dolog"
Ezek fényében nem túl hiteles, hogy engem kritizáltál amiatt, hogy gagyinak/fosnak neveztem az általad korábban emlegetett kódot, amely iframe-használatot erőltetett (bár akkor még nem is láttunk kódot, csak ahogy bemutattad, az alapján nem volt túl meggyőző), itt viszont egy annál ezerszer komplexebb és alapvetően jól működő dologról van szó...
Azért kell új kulcsot beszerezni a 2-es változathoz is, mert történtek változások a Google-alkalmazások körül, azok nyilvántartásában, lett ez a konzolos dolog, amit be is linkeltél, a változtatásokhoz való adaptálás érdekében meg frissíteni kell a kulcsot.

Egy oldalon én is API-kulcs használata nélkül jelenítem meg a térképeket a v3-as API segítségével (pontosabban Drupalban egy modul kódja jeleníti meg, de beregisztrált API-kulcs nélkül).

[ Szerkesztve ]

Sk8erPeter

most ezt a hibát dobja ki pár mp után
viszont megjelenik mindkét oldalon

[link]

Egyértelmű, az api key nem jó neki.

próbáltam a v2 és a v3 -at is ugyan ez a hiba fogadott

Sziasztok!

Van annak módja, hogy megmondjam egy oldalnak, hogy milyen széles? Ebből a leírásból csinálok egy felugró ablakot és nem szeretném megadni, hogy hol jelenjen meg, azaz a "left" értéknek kéne dinamikusnak lennie. Hogy pl.: a lap szélességének fele-a felugró ablak szélességének fele azaz épp középre bukkanjon fel a felugró.

Van erre vmi megoldás?

köszi!

═════════════════════════════════════════

window.innerWidth, document.body.offsetWidth stb [link] elég böngészőfüggő, valamint ez javascript topicba való kérdés, nem php.

"Moonshine Whiskey (70°, ízesítés nélküli) van. Fincsi" - Teebee - "De az kiírtaná az egész családomat..Akkor is ha csak én innék belőle.." - forintuser

Hogy a péklapátba lehet windows alatt git-hez private ssh kulcsot használni? Nem találom seholsem, sima git és tortoise git van fent.
Ha rámegyek, hogy clone git akkor nem tudom betallózni neki a kulcsot.

Git bash pedig ezt írja:

[ Szerkesztve ]

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Van egy PHP-m ami egy űrlapot jelenít meg. Több elemmel együtt van 2db Select benne, amik összefüggenek.

A helyzet:
A select1 településeket mutat, a select2 cégeket.
Ha kiválasztok select1-ben egy települést, akkor select2-nek már csak azokat a cégeket kellene felajánlania, amik azon a településen találhatóak.

A feladat:
Oldal újratöltése nélkül szeretném megoldani.

Nem kell feltétlen kód csak egy elmélet, hogy miként lehetne ezt megoldani?

Ajax bevonásával:
www.w3schools.com/php/php_ajax_database.asp

Ja sejtettem.

[ Szerkesztve ]

De a git-ben benne van elvileg az ssh-agent. Itt lesz amúgy a baj, azt írja hogy nem tud csatlakozni az agent-hez, holott az agent már fut...
A socketet mutatja, de ha tesztelni akarom az ssh -T -vel, akkor permission denied.
Illetve az ssh-add sem megy.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Sziasztok!

Szeretnék készíteni egy összehasonlító oldalt, ahol pl szórakozóhelyeket hasonlítanék össze. Minden szórakozóhelynek lehetne felvinni mondjuk szolgáltatásait, árakat, stb. Mindenhez lehetne kommentelni és mondjuk lehetne értékelni is az adott szolgáltatást, vagy szolgáltatót.

Tudok ajánlani valamilyen scriptet rá? (php+mysql alapokon)
Amit én találtam: http://crowdvox.com/
Ehhez hasonlóra lenne szükségem.ha tudok még alternatívát ajánlani, akkor megköszönném!

Üdv,
Laci

Ez azért ennél bonyolultabbnak tűnik első hallásra.

Ha hallgattál volna, bölcs maradtál volna.

Neked egy tartalomkezelő kell. Amit linkeltél, fizetős. Ezért fizetnél?
Ott a wordpress.

Konkrétabban?

Sk8erPeter

Ez Drupallal egyszerűen* összekattintgatható, még scriptelned sem kell hozzá.
Létrehozol egy "Szolgáltatók" nevű content type-ot, a szálakba rendezett kommentelés innentől eleve biztosított, hozzáadsz tetszőleges mennyiségű űrlapmezőt (szolgáltatások listájához lehet, hogy taxonomy-t kell majd használnod, megvalósítástól függően; árak felviteléhez is megvalósítástól függő a megoldás), értékeléshez pedig a Fivestarnál nem nagyon ismerek egyszerűbben összeklattyogtatható értékelésre szolgáló modult.
Vagy biztos WordPress-szel is megoldható, azt nem ismerem.
De nem két perc, arra számíts. Ajánlott szakirodalom magyarul: http://nagygusztav.hu/drupal-7-alapismeretek.

Szerk.:
*: kezdetben semelyik CMS nem egyszerű, SŐT. Nagyon nehéz az elején. De megéri legalább egyszer ráérezni az ízére, mert egész komplex oldalakat is akár "gyorsan" össze lehet hozni vele azután. Persze egy CMS mindig sokkal erőforrás-igényesebb lesz, mint egy erős, igényesen kódolt és használt framework.

[ Szerkesztve ]

Sk8erPeter

Deklaráltam a ~/.ssh/config-ban, az adott hosthoz, hogy melyik rsa fájlt használja és egyből működött a dolog.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Köszönöm a segítségeket!

Gondolom sokan ismertek ilyen böngészős játékokat, mint például The West, Bitefight, Battleknight, stb.
Már gondolkodtam rajta, de nem tudtam rájönni, hátha ti segíteni tudtok. Tudjátok van benne élet és mana. És ha ezekből vesztünk, mert mondjuk megsebeznek vagy képességet használunk, akkor az egy idő után vissza tölt. De azt hogyan? Tehát:
1. Hogyan tudnám megoldani, hogy az adatbázisomban a felhasználók életpontja mondjuk fél óránként nőjön, legyen most 50-el.
2. Hogyan tudom ezt kirajzoltatni? Tehát lenne egy csík, és kiszámolná, hogy meddig kéne feltölteni, az aktuális életpontoknak megfelelően?

:D Semmi :D

A kifejezés, amit keresel: cron job.

Megjelenítés: veszel egy divet, ami az életerő csík lesz, mondjuk 200 pixel széles, adsz neki háttérszínt. Ha nem teljes az életerő, akkor 200*(aktuális_életerő / max_életerő) pixel szélesre kell állítanod. Ezt berakod egy 200 széles, 1px borderes divbe, hogy látsszon, hogy hol van a max.

[ Szerkesztve ]

"Moonshine Whiskey (70°, ízesítés nélküli) van. Fincsi" - Teebee - "De az kiírtaná az egész családomat..Akkor is ha csak én innék belőle.." - forintuser

Én ezt a belépéskor vizsgálnám a helyedben.
Azt nem tudom, hogy mi a feltétele a "mana" növekedésnek, mikor "resetelődik" a töltődés (gondolok itt arra, hogy mondjuk a legutóbbi mana használat után 30 percenként nő 1-gyel a manád).
Ha így van, ahogy gondolom, akkor mindig mented, hogy mikor használt a játékos utoljára manát.
Belépéskor összehasonlítod ezt az időpontot a belépés idejével, megnézed, hányszor telt el 30 perc azóta, majd rögtön hozzáadod a mana töltődést.
Ha globálisan akarod csinálni, akkor esetleg írsz egy cron job-ot, amit 30 percenként meghívsz.

Rip and cut and mutilate the innocent, his friends, and again and again and on and on.

Aham, és ezt a cron jobot mi hívja meg?

:D Semmi :D

A szerver operációs rendszerén a háttérben futó processz. Linuxon cron-nak hívják, Windows szerveren task scheduler-nek.

Nem lenne egyszerűbb akkor frissiteni mikor meg van jelenitve ? Kell egy aktuális manna érték, egy legutoljára frissités, egy növekedés/óra (vagy ami tetszik), felesleges egy cronjobot létrehozni, mert ennek real timenak kéne lennije, a cron meg nem arra való hogy 30sec-enként lefusson, akkor inkább daemon.

1 vagy 2 update az egész, ahogy elsőnek írta félóránként frissülne. Nem százmilló soros adatbázison századmásodpercek alatt lefut.

"Moonshine Whiskey (70°, ízesítés nélküli) van. Fincsi" - Teebee - "De az kiírtaná az egész családomat..Akkor is ha csak én innék belőle.." - forintuser

Egyszerűbb talán, de jobb semmiképp.
A mana érték egy játékban sokszor frissül, ergo rengeteg olvasási művelet lesz. Továbbá biztosítani kell, hogy ez esetben óránként (vagy akármikor) csak és kizárólag egyszer fusson le, ezt nem teljesen triviális jól megcsinálni.
A cron pedig simán futhat akár 30 másodpercenként is. Továbbá a cron az maga egy daemon, ami pont arra van, hogy megoldja ezt a problémát, minek erre fejleszteni egy másik daemont?

[ Szerkesztve ]

A mana érték egy játékban sokszor frissül, ergo rengeteg olvasási művelet lesz.

Jah, épp ezért lehetne megoldani egyszerűen, hogy ha belovassuk akkor már a jó értéket jelentítsük meg (egy egyszerű matematikai müvelet és kész), nem lesz semmivel nagyobb terhelés, mert csak akkor írunk ha változás történik.

Továbbá biztosítani kell, hogy ez esetben óránként (vagy akármikor) csak és kizárólag egyszer fusson le, ezt nem teljesen triviális jól megcsinálni.

épp ezért irtam, hogy el kell tárolni egy utolsó frissitést plusz egy mana/h-t és nem is kell frissiteni feltétlenül.

A cron pedig simán futhat akár 30 másodpercenként is.

Alapból nem, de nyilván megoldható.

Továbbá a cron az maga egy daemon, ami pont arra van, hogy megoldja ezt a problémát, minek erre fejleszteni egy másik daemont?

Fejleszteni nem kell, mert már megtették mások, ezért nem nehezebb semmivel mint egy cron job-ot beállítani. Ha már feltételezem a LAMP környezetet akkor miért ne? Sokkal jobban illeszthető a környezetbe és egyszerűbben is konfigolható. ( a futás gyakoriságától kezdve a kiépitett logolásig) .

Persze vannak hátrányai is, meg előnyei is.

DeltaPower : Nem 30sec, hanem 30perc, igaz. Nem a sebesség miatt irtam feltétlenül, csak ha belegondolok, hogy a kérdező valószínűleg mit akar elégni akkor nem vagyok benne biztos, hogy 30percenként érdemes frissiteni. Mi van ha egy felbuffolt embernek 1 perc alatt megtellik? Tudom, hogy kicsit tovább gondoltam mint az alap kérdés, de ha már ugyis megnézzük mennyi a manna az adatbázisban éppenséggel frissitett adatot is vissza adhatunk, akcio után meg a jo adatot beirjuk.

[ Szerkesztve ]

Jah, épp ezért lehetne megoldani egyszerűen, hogy ha belovassuk akkor már a jó értéket jelentítsük meg
A cron lényege, hogy valamit időzítve futtasson, mondjuk jelen esetben egy írási műveletet. Ettől te még akárhányszor kiolvasod, a helyes értéket fogod kapni, a frissítés ugyanis nem az olvasások számától függ, hanem az eltelt időtől.

épp ezért irtam, hogy el kell tárolni egy utolsó frissitést plusz egy mana/h-t és nem is kell frissiteni feltétlenül.
Lehet így is, csak fölösleges minden egyes olvasási műveletnél lefuttatni az ellenőrzést, hogy kell-e frissíteni, tekintve, hogy az olvasások száma várhatóan sokkal nagyobb, mint az írásoké. Plusz ez web, itt több szálon történik a dolog, tehát lock-okat is kell alkalmazni, szóval tovább rontod az alkalmazásod teljesítményét.
Van egy ütemezett feladat, ennek futtatására van standard módszer (cron). Miért kéne ehelyett egy bonyolultabb és lassabb megoldást alkalmazni? (Annak eldöntése, hogy kell-e frissíteni, az minden, csak nem atomi művelet, ezért kell gondolni a párhuzamosságra is)

Alapból nem, de nyilván megoldható.
Ok, akkor 1 percenként, na .

Ha már feltételezem a LAMP környezetet akkor miért ne? Sokkal jobban illeszthető a környezetbe és egyszerűbben is konfigolható. ( a futás gyakoriságától kezdve a kiépitett logolásig) .
Miért, egy cron által meghívott php script miért nem illeszthető jól bele a környezetbe?

[ Szerkesztve ]

"Továbbá biztosítani kell, hogy ez esetben óránként (vagy akármikor) csak és kizárólag egyszer fusson le, ezt nem teljesen triviális jól megcsinálni."
Ezt nem igazán értettem. Miért, mi benne a bonyolult?

"fölösleges minden egyes olvasási műveletnél lefuttatni az ellenőrzést, hogy kell-e frissíteni, tekintve, hogy az olvasások száma várhatóan sokkal nagyobb, mint az írásoké. Plusz ez web, itt több szálon történik a dolog, tehát lock-okat is kell alkalmazni, szóval tovább rontod az alkalmazásod teljesítményét."
Az írásra vonatkozó rész még okés, de maga az ellenőrzés miért lenne olyan nagy gond? Eleve az aktuális manna értékét ki kell olvasni, akkor még az utolsó írási művelet dátumát kiolvasni, majd aktuális dátummal összevetni minden, csak nem egy igazán erőforrás-igényes művelet. (Jó, ha nagyon akarom, ilyen alapon az aktuális dátum és idő lekérdezése miatt szükséges OS-szintű rendszerhívás is erőforrás-igényes. )
Hangsúlyozom, itt az ellenőrzéssel kapcsolatos aggályaidra reagáltam elsősorban, nem az írási műveletekre. Bár hozzáteszem, az ilyen szinten egyszerű félóránkénti (!) írás csak elég durva felhasználószámnál jelenthet szerintem gondot, szóval picit úgy érzem, ebben az esetben túl van parázva a dolog. Ha ötpercenkénti írási műveletekről lenne szó, akkor jogos.

(#12990) Soak :
hogy a másik oldalhoz is szóljak
"> A cron pedig simán futhat akár 30 másodpercenként is.
Alapból nem, de nyilván megoldható."
Ezt hogy érted? Az adott script futtatása olyan időközönként fut, ahogy konfigurálod... Itt mi az, hogy "alapból"?

"> Továbbá a cron az maga egy daemon, ami pont arra van, hogy megoldja ezt a problémát, minek erre fejleszteni egy másik daemont?
Fejleszteni nem kell, mert már megtették mások, ezért nem nehezebb semmivel mint egy cron job-ot beállítani. Ha már feltételezem a LAMP környezetet akkor miért ne? Sokkal jobban illeszthető a környezetbe és egyszerűbben is konfigolható. ( a futás gyakoriságától kezdve a kiépitett logolásig) ."
Másik daemont fejleszteni? Nem világos. Mire? Az időzített feladatok futtatására? Vagy nem vágom.

[ Szerkesztve ]

Sk8erPeter

Az alapbol az, hogy linuxon a cron leggyakran 1 percenkent futhat le. (a konfigban a perc a legkisebb egyseg).

A masiknal pedig en epp a System_Daemon php daemonrol beszeltem ami ad egy elfogadhato alapot php alapu daemonok gyartasahoz.

maga az ellenőrzés miért lenne olyan nagy gond

Szerintem itt erre gondolt: Pistike rángógörcsöt kap, és egymás után tizenhét alkalommal kattint valamelyik linkre. Az adott oldalon olvasni kell a manát, és ekkor történik a növelés szükségességének ellenőrzése is. A számos egyszerre bejövő processt ütemezi az OS, ebből három véletlenül így jön ki:

- #1: aktuális érték olvasás
- #2: aktuális érték olvasás
- #3: aktuális érték olvasás
- #3: ellenőrzés, növelés
- #1: ellenőrzés, növelés
- #2: ellenőrzés, növelés

Szóval mivel az olvasás-ellenőrzés-növelés nem atomi művelet, simán válthat közben az OS (jó eséllyel fog is). Ha szerencsétlen mód úgy jön ki, mint fenn, akkor van három processed, ami mind növeli, szóval rögtön eltelt másfél órád néhány másodperc alatt. Ezt lehet mondjuk lockolással elkerülni, de nem triviális feladat. Sokkal egyszerűbb cronból, ütemezve írni, és csak ott.

Persze ez a fenti helyzet egyszerűsítve van, sok függ a környezettől, szerverbeállításoktól, hogy használsz-e sessiont...

+1 a cron-ra.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Miért kell túlbonyolítani cron-al, ami nem mindenhol elérhető?
Nem próbáltam ki a kódot, csak elméleti szinten pötyögöm be

update players_table as player
set player.mana_level = player.mana_level+(floor((unix_timestamp()-player.last_manaupdate)/60)*2),
player.last_manaupdate=unix_timestamp()-mod(player.last_manaupdate, 60)

Ebben a formában 60 másodpercenként 2 egységet kap, oszt' viszonthallásra.
Ezt egyszerűen beteszi az oldal elejére, így simán lefut, amikor vki lekéri az oldalt.

[ Szerkesztve ]

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

Soak megoldása is kivitelezhető, sőt láttam már rá működő példát is. Külön lock kezelés se feltétlen kell hozzá, ha pl. meg van adva hogy 30 percenként (1800s) 50 mana töltődik, akkor:

UPDATE character SET mana=LEAST(max_mana, mana+((NOW() - last_mana_timestamp)/1800)*50), last_mana_timestamp=NOW() ...

szerk: oleslie: megelőztél, kb ugyanarra gondoltunk

[ Szerkesztve ]

"Moonshine Whiskey (70°, ízesítés nélküli) van. Fincsi" - Teebee - "De az kiírtaná az egész családomat..Akkor is ha csak én innék belőle.." - forintuser

update (timelimit miatt nem megy a módosítás)

update players_table as player
set player.mana_level = player.mana_level+(floor((unix_timestamp()-player.last_manaupdate)/60)*2),
player.last_manaupdate=unix_timestamp()-mod(player.last_manaupdate, 60),
player.mana_level = IF (player.mana_level>100, 100, player.mana_level)

egy sorral egészíteném ki a végén, így nem megy 100 fölé a szint.

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

Na igen
Bár az én második megoldásom sem tökéletes (már rájöttem hol van benne a hüba), meghagyom annak megtalálását és kijavítását Dave-11 -nek

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem