pirx's Forum Posts

  • I can think of 2 ways to do this, both are quite mathmatically simple.

    First option is to add a random number to your target value.

    target + (random(1) - 0.5) * (100 - precision)

    For the above it assumes precision is in the range 0 to 100, and gives an output between target ± 100 and target ± 0. If you want 100% precision to not match exactly then you can do

    target + (random(1) - 0.5) * (100 - precision * 0.95)

    target ± 100 to target ± 5

    If you want a larger range

    target + (random(1) - 0.5) * (100 - precision) * 4

    target ± 400 to target ± 0

    Second option is to generate a random number and do a linear interpolation towards your target value.

    lerp(random(100), X, precision * 0.01)

    target ± 100 to target ± 0

    If you want to change the range then just modify the number given to random, if you want 100% to not be exact try

    lerp(random(100), X, precision * 0.0095)

    target ± 100 to target ± 5

    One thing you can do with this one is change the probably curve, by performing a power on the precision value like so

    lerp(random(100), X, (precision * 0.0095) ^ 2)

    Yes, thanks! That's exactly the kind of answer I was looking for.

    It actually gets slightly more complicated because in practice I need to do this for a set of coordinates (no big deal, I'll just do it twice).

    I did think about the #1 solution with subtracting from 100 before, but it was a bit too linear, but the lerp stuff is great to tinker around with.

  • Hi,

    I would really appreciate it if someone gave me an idea on how to achieve the following relation:

    I have a target number, say X.

    Now I get a random number Y.

    And I have a "precision" skill/setting that can be set from 0 onwards.

    Basically if the precision is 0, Y is pretty much just random, but the more I increase it, the closer it is likely to be to X.

    For example, if X=100 and the precision is set to 0, you can get anything like 250, 180, 20, 150 or 432.

    If the precision is at 50, then you get closer random values like 120, 90, 85, 110.

    And if it's at 100, you get almost perfect ones 101, 99 or 98 or 100.

    In other words, the greater precision, the smaller the random range of Y around the target number.

    Also would be good if it was a cubic function so that the improvement in precision gets smaller with higher settings, never reaching perfection.

    Any ideas? :)

  • Totalnie zgadzam sie, ze przetlumaczenie wszystkiego to tylko czesc roboty, trzeba bedzie potem powaznie posiedziec nad poprawianiem/ujednolicaniem itp....

    Juz mozna podgladac tlumaczenie w praktyce w developer mode, ale to jest wersja ok. 10%, wiec wielu zmian jeszcze nie widac, ale jesli cos nie pasuje do kontekstu to od razu rzuca sie w oczy

  • widzialny/niewidzialny - zgadzam sie, lepiej widoczny/niewidoczny. Zmienie to.

    aktualny - zastanawialem sie czy aktualny czy obecny, i akurat padlo na to pierwsze, ale moze rzeczywiscie obecny jest trafniej. j/w

    line of sight - ja do tej pory tlumaczylem: linia wzroku (tak wyskoczylo "w internecie"). Zastanawialem sie nad "linia widzenia". Moze zostawmy to ostatnie, dobrze oddaje sens i jest krótkie. Co do "cone of sight", to do tej pory pisalem "stozek pola widzenia", ale w zasadzie samo "pole widzenia" jest wystarczajaco jednoznaczne, i do tego krótsze.

    bryla brzegowa - klóci mi sie troche to "bryla" z tym ze ten bounding box jest plaski. "Ramka brzegowa" brzmi bardziej 2d, ale nie wiem czy to nie znowu "maslo maslane".

  • Po przespaniu sie z tymi terminami pomyslalem tak:

    solid - bardziej chyba podoba mi sie ta "bryla". Brzmi znacznie zgrabniej. Pozmieniam to w swoich tlumaczeniach, na szczescie w poeditorze latwo wyszukac wszystkie wystapienia terminu.

    destroy - w takim razie "zniszcz".

    live preview - "podglad na biezaco" fajnie, bo krótkie i po polsku. Nie za kolokwialne?

    image point - to trzeba ustalic, bo pojawia sie dosyc czesto. Korci mnie ten punkt aktywny bo po prostu dobrze brzmi, ale moze faktycznie zbyt odlegle... z drugiej strony "punkt obrazu" troche mi pachnie taka toporna kalka.

    true i false - ok, w sumie to bezpieczna i przyjeta nomenklatura.

    Co do "on [something]", nie wpadlem na to "po" - chyba najlepsza opcja jesli w ogóle ma tam byc jakies slowo. Do tej pory tlumaczylem w/g tej konwencji z czasownikami, jesli to jest ok to juz proponuje zostawic. Swoja droga, mamy ponad 10%, wiec w nastepnej aktualizacji jezyk polski powinien byc dostepny w developer mode, bedzie mozna zobaczyc jak to wszystko wyglada w kontekscie. Jak znajdziesz ten poradnik to na pewno warto spojrzec.

    Jeszcze jedno: jakies pomysly na "bounding box"? Kompletnie nie wiem jak to ugryzc. Zaraz jeszcze sprawdze jak to jest przetlumaczone w photoshopie, bo tam chyba wystepuje podobne sformulowanie.

    Jeszcze taka dygresja, ze tez kiedys dlubalem w Klick'n'Play, tylko ze to byla wersja shareware, czy po prostu demo, wiec nic wielkiego tam nie powstalo.

  • Okay, Ashley, I'd seen the subforums for the major languages so I thought there's gona be one for each.

    Anyway, there's only two of us so far so I think we'll manage with this thread.

  • Chyba nie ma konkretnego powodu, zeby mówic po angielsku...

    [quote:31mwa89k]Drift in the car movement could be dryft as in a boat's movement. I went for poslizg as it sounds better for me. So now Drift recovery would be something along the lines of Odzyskanie sterowania/kontroli po poslizgu which is quite lengthy compared to the original string.

    Nie moglem wymyslic nic na ten drift -- ale tak bedzie super. W tym "przydlugim", moze "wychodzenie z poslizgu"?

    Dodatkowe rzeczy, które napotkalem, a nad którymi warto sie zastanowic to (wraz z tym jak przetlumaczylem je do tej pory):

    solid - cialo stale ( "bryla"? co prawda krótsza, ale troche mniej oddaje sens)

    family - rodzina (no... rodzina. aczkolwiek wydaje mi sie ze po polsku mogloby sie nazywac inaczej)

    layout - scena (tu ustalilismy, ze tak bedzie dobrze)

    destroy - zniszcz ( czy to nie brzmi po polsku jakos tak.. brutalnie? ).

    live preview - podglad 'Live'. nie sadze ze da sie to sensownie przetlumaczyc. Podglad "Na zywo" brzmi srednio.

    trigger - oficjalnie tlumaczone w innych miejscach jako "wyzwalacz". dla mnie to brzmi nieco dziwnie, bo nie spotkalem sie wczesniej z taka nazwa po polsku w takim kontekscie, ale zasadniczo pasuje.

    node - wezel?

    image point - ? tu trudno o cos logicznego. "punkt obrazka" "obrazu"? czy moze bardziej kreatywnie "punkt aktywny" albo cos takiego

    true i false - ? zostawiamy "prawda" i "falsz", czy zmieniamy?

    I jeszcze dosc wazna rzecz, a mianowicie czesto pojawiajace sie tlumaczenia warunków "On..." , np. "On Object Destroyed". Trzeba by przyjac jednolity sposób tlumaczenia.

    "Na" czesto nie bardzo pasuje -- "Na Zniszczenie obiektu". W tych kilku przypadkach, które juz przetlumaczylem pominalem to On. W interfejsie C3 jest to dosc oczywiste, ze po lewej stronie znajduja sie wydarzenia a po prawej akcje, wiec jesli w kolumnie wydarzen wyswietli sie "Zniszczenie obiektu", to teoretycznie nie powoduje nieporozumien. Rozgraniczenie w tlumaczeniu akcji od wydarzen polega dodatkowo na tym, ze wydarzenia wystepuja w formie rzeczowników lub rzeczowników odczasownikowych (zniszczenie, zakonczenie zanikania, kolizja), a akcje w formie czasowników w trybie rozkazujacym (zniszcz, utwórz, zmien). Pozostalbym przy tej konwencji. Ale nie jestem pewien, moze sa lepsze pomysly.

    Ogólnie nie wydaje mi sie, ze w tej chwili jest w "ekipie" wiecej niz dwie obecne tu osoby

  • Hey,

    We've started the Polish translation (currently at 4%) but we could use a subforum, since there have already been some (constructive) discussions about proper terminology etc. Any chance to add it?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Thank you both. This is just what I was looking for.

  • Hi,

    How do you tackle localization of your games?

    Up to recently I had the strategy of just compiling mutliple language versions of an app and uploading them as separate apps to Appstore/Google Play. This is however super cumbersome.

    So I'd like to do it the proper way, which means loading strings from a file. This is actually pretty easy using arrays but how do I reliably detect the user's language? Also, are there any C3 plugins that would make this easier (e.g. allowing for use of wildcards in the translated strings etc.)?

    Has anybody had experience with successful implementation of this kind of localization in C2/C3?

  • 1. If you are talking about local multiplayer (as in two players using the same keyboard on one screen) then it's pretty straightforward. Just give the tank the desired movement behavior and then set both tanks' controls to different keys. If you have different tank images on different frames then set the animation speed to 0, then you can either set the frame in the properties bar or via the action: Tank - > set frame.

    (if you want to tackle online mutliplayer then just really don't.)

    2. If you have multiple turrets and multiple tanks to pin them to, you need to "tell" C3 which ones belong together.

    I think the simplest way to do that is to create the turrets in game as opposed to doing that beforehand.

    Basically it would go something like this:

    • Tank->on created

    * Tank: spawn another object (Turret)

    * Turret: pin to object (Tank)

    Explanation: Since you create the Turret inside the Tank's "on created" scope, C3 will "take into consideration" the particular instance of Tank and Turret that should be pinned together.

  • I feel doing anything UI related in Construct has always been quite a hassle. I would love to have a new type of group node, where every object inside automatically is translated with that group. Kind of how Container "SHOULD" work, in my opinion. Now you have to use pin, and other workarounds if you want to move/scale/rotate multiple connected objects in realtime, and quite often you wanna do that with UI elements and popups etc.

    +1 on this as well. I doubt we're getting flash style object-within-object-within-object functionality anytime soon (or ever) but the whole pinning things together workflow has gotten a bit old, and generally feels more like a workaround than a real tool.

  • Do you know about the Pick top/bottom condition?

    "Pick either the top-most or bottom-most instance, taking in to account layers and Z index. For example, the instance at the front of the top most layer is the top instance."

    This does not really apply to what we're talking about. The condition you mention is useful when you have mutliple instances of an object stacked and need to pick the topmost one. Like in a deck of cards or something. In the touch-bubbling problem, however, you generally have no idea what will be below your button/window/field/etc during runtime.

  • Well then I have even more of a reason to want the aforementioned functionality, because now I have to watch out for pop ups interfering with other pop ups, keep track of what should be touch-disabled at a given point etc.

    But come to think of it, and considering your question, a dedicated layer may not be the best idea. However, a “stop touch” setting in every layer’s properties would do the trick. I’d just tick that for any layers that are used for UI and be done with it.

  • Hi,

    I would just like to point out this annoyance that could be addressed at some point in the future.

    Popups and UI elements (as in a Pause popup, an on-screen menu, all sorts of game toolbars etc), as do all sprites, currently "leak" touch and mouse click events downwards. So if you click an "ok" button in a dialog box, it will also activate all touch sensitive game elements that happen to be beneath it. This is undesirable for, hopefully, obvious reasons.

    I know this is by design but I deliberately use the word leak because, frankly, I think you need user input to stop at the first (topmost) encountered object way more frequently than you need it to work across multiple stacked things. In fact, I struggle to find a use case for the latter.

    While this can be manouevred around by switching off groups and juggling variables I think it would make way more sense to have a dedicated layer for UI elements or a setting in layer properties to disable touch and click events propagation.

    As an example, I have a game that has a lot of rather complicated inter-related swipe, touch and drag and drop events and some buttons and pop-up messages that appear on top of it. It has already became quite a dancing routine to keep these from interfering with each other. It also introduces clutter with all the logic designed specifically for this purpose.

    I don't mean to rant (too much) but I imagine most games will have things that appear on screen that are not directly game-action related, so this might be worth considering so that C3 continues to be one of the most developer-friendly game creation tools out there.