Scoremonger's Forum Posts

  • Thanks for your answer —

    Rex has updated his plugin TagText, so the stroke option with border width is now available:

    https://www.scirra.com/forum/viewtopic.php?f=153&t=92363&p=1100592&sid=16ff5b639bcf4860b7428c8446ed5a51#p1100592

    Great amkp, thanks for the heads-up! That's good since I believe I deleted my test plugin.

  • Hi —

    SuperRex add a Stroke parameter in his plugin TagText but not the possibility to modify Stroke width.

    Do you think it would be possible you send me your custom text plugin with stroke width, just to understand how you made the change ?

    Hey amkp, I will try to dig that up, sure. I may have deleted it though, so in the meantime here's an example of stroke width in pure HTML/JS.

    http://www.html5canvastutorials.com/tut ... xt-stroke/

    If I recall, I just added ctx.lineWidth to the draw call, and exposed a number variable for it in the editor. I also exposed a variable for the stroke color in the same way the text color was done. Mostly copy/paste stuff tbh.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    > Things will change soon.

    >

    >

    >

    I feel that perhaps you've confused this with forum with an American political one.

    Indeed... I really need C3 to distract me from this nightmare.

    > MY GOSH LOOOOOL buildobox is so crazy expensive XD even my 3dsmax or photoshop are less expensive than that i definitely stay with cnstruct 2 & 3

    >

    Their pricing is similar to Unity's pricing for a license that doesn't require Unity branding or a revenue cap.

    Yeah, it's not a crazy price if you have a proper company with a decent revenue stream/startup capital, but it is crazy for the average hobbyist. I'm a little shocked they don't have a limited free version, apart from the 30 day trial. Once I saw the price I didn't bother to download it, because even if I love it there's no way I'm paying that.

    Besides, I've been very happy with C2.

    I'm much more interested in some of the hinted-at workflow/organization improvements than native export, even if it were a possibility.

    Edit:

    I have a feeling the natives will be throwing spears at me pretty soon for that one.

  • Thanks for pointing out the tag text plugin, Yura G. I didn't know about that one, and it looks like it'll do all I wanted and then some.

    The thing is, I normally avoid using third-party plugins since they aren't guaranteed to be supported and I've often found them to be buggy. It sucks to invest time into integrating some plugin only to realize it isn't reliable and/or isn't supported by the author. I might break down and use this one since rex is so active, but I would still love to see official support for more text options.

    I don't make direct changes to official plugins btw, for the reason you mentioned. I made a copy of the text plugin with my changes to test that what I was asking for could be done easily. But still, I wish I had named it "Super Text"... I called it "Text Stroke" which now seems very boring.

  • Hi,

    I'd like to request an addition to the Text plugin: the ability to define stroke color and width for text.

    I modified the official Text plugin to do it, as a test. I added Stroke Color and Stroke Width properties, then inside the text.draw method set ctx.strokeStyle and ctx.lineWidth to the user-defined values. It worked as expected in Firefox, Chrome, Edge and even I.E., so I hope this is just a standard browser feature that can be supported.

    I'm a Javascript novice, and I'm sure there are gotchas that I don't know about, but it was so easy for me to hack something in I'm hopeful it's not a huge ask to get official support.

    Thank you!

  • Wow. Thank you! Adding a "for each mover" in the on timer event condition solved it!

    That is not how I expected it to work. Construct has loads of these little quirks... but it's still my favorite tool.

  • Hi, I'm having an impossible time debugging some object behavior I set up, and I'm hoping a power user out there can point out the problem. I'm mainly looking for what's wrong with my existing setup but suggestions for alternative approaches are welcome too.

    I have a "mover" sprite and a "target" sprite. For each mover, I create a target, and the mover bullets towards it. When it reaches the target, it starts a "wait" timer. When the timer expires, it moves the target to someplace random and bullets towards it again. This loops indefinitely.

    The problem is, a single instance of this seems to work fine, but once I start adding more instances, they will stop working after some random number of cycles. They always seemed to stop when they reached their destination, which made me think it could be a timer problem - sure enough, if I replace the wait period with another command to go to a new position, they never stop. So, my timers are broken somehow. It's as if they just get removed without ever completing their countdown.

    My question is how? Why? The logic seems straightforward. I've got a .capx here, if any of you care to check it out. Click to spawn additional movers. https://www.dropbox.com/s/tj8gctbg1tnj2 ... .capx?dl=0

    Thank you.

  • From the bug report guidelines:

    [quote:1lpfim9z]Due to heavy spam on the forum, we have to block the posting of links for new users. If your link to the .capx is blocked, either remove the http and www parts, or insert * characters through them, e.g.

    example.com/myproject.capx

    or

    h*t*t*p://w*w*w.example.com/myproject.capx

    You can post your file that way.

  • I realize these bug reports aren't actively monitored once closed, but I'd also +1 for changing this for a future release.

  • I found this issue in the Bugs forum - it's a property of the turret behavior (AKA "Not a bug") that turret settings are passed to ALL other members of the family even if you change a single instance.

    So there is no way to change turret behavior settings on an instance-by-instance basis if the turret behavior is coming from a single behavior in the family. This seems like a less-than-ideal implementation, because it limits what you can do with the turret behavior. I assume there is some under-the-hood reason for doing it this way, but as an end-user I can see no benefit.

    So, the only ways to do what I want are to give all turrets with different target lists their own families with their own turret behaviors, OR to add multiple turret behaviors to the common Turret family and only activate the individual turret behaviors needed for each turret faction. So my Turret family would have behaviors TurretRed, TurretGreen, etc. Since it's easier to do one of those than try and write my own turret plugin (which is otherwise working wonderfully, I should add), that's what I'll do. It's messier than I want, but it'll work.

    Thanks for your suggestions megatronx, much-appreciated.

  • Thanks for the reply! That's a valid way to do it, but I want to keep all turret initialization logic in the turret's on created event even if it adds one additional condition per faction (color). I'll have various things using these faction families and hate to spread the initialization logic for them around at that level. But your suggestion should definitely work and in the short term I'll probably do something like that so I can move forward.

    Still, my first approach should work - do you have any idea why it wouldn't? I'm using a similar picking system in other cases to treat families more like components, and it seems to be working just dandy. But this makes me think I'm misunderstanding something fundamental (and apparently pretty important) about the way families work, picking works, and/or the way the turret behavior works.

  • Hi, I have what looks like a bug in my project. I have two types of turrets both in a family called "Turrets", and each also in a family of their own color ("Green" and "Red"), which I use to give objects factions. So, two turrets, three families. I want the turrets to automatically target members of the opposing color when they're created.

    To do that I have an "on created" event for the "Turret" family. I first attempt to pick the first color family using the the UID of the turret that was just created. So:

    Turret On created
(sub event)
     Green Pick instance with UID Turret.UID   Turret Add Turret target Red

(sub-event)
     Else
     Red Pick instance with UID Turret.UID   Turret Add Turret target Green[/code:gkne4bdv]

These turrets are both set to Target mode "Nearest", by the way.

The problem is that all the turrets end up picking [i]themselves [/i]as targets. If I disable one of the picking sub events, the other works perfectly. But if I leave them both enabled, all the turrets wind up wanting to shoot themselves. And after hitting my head against the wall for awhile on this problem, I can sympathize with them. <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink">

Here is a capx of this problem. 

[url=https://www.dropbox.com/s/4em3r96astjglmr/TurretBug.capx?dl=0]https://www.dropbox.com/s/4em3r96astjgl ... .capx?dl=0[/url]

Does anyone know what the cause might be, or if there is a workaround? If not I'll file a bug.

Thank you!

  • Hmmm, reading some of these comments more carefully I see I viewed some posts through the lens of my current need.

    What I'm asking for is more of some kind of layer manager that can span multiple layouts. For example, I would love the ability to select several layouts and alter their properties, including layers, in the same way it's possible to select several objects and alter properties on them. But this is a new request - sorry for the necro-post!