Sorry your browser is not supported!

Hey guys, have noticed that I cant have a function and a type with the same name in the IDE for AppGameKit Studio.

Just thought I would mention it in case the bug doesnt exist for others.

It can get annoying trying to find my function through all the code, I end up searching for the function name instead of just clicking on the dropdown bar.

Thanks
Thoams

yup, not fun.

to be more specific, both the Type and Function work as intended but whichever is declared 2nd will not be available in respective Pulldown.

IE,

...leaves SomeFun() omitted from the Function Pulldown, while:

...does show SomeFun() in the Function Pulldown but only SomeFun.ID in the Type Pulldown (better but not necessarily practical).

meanwhile, reported @ GitHub.

note, title renamed to something more helpful.

Strictly speaking here the bug isn't with the IDE., but rather AppGameKit Script itself...
In somewhat blunt terms no Variable, Constant, Type, Function or Label should have the same signifier., and if AppGameKit Script was a compiled language; such a bug that allowed would cause serious problems.
AGK Script being an Interpreted Scripting Language however., well there is likely some 'automation' behind the scenes to ensure Type Safe behaviour (ala Java, Lua, Python, etc.)

Now as a note if you use #option_explicit (which _should_ be default behaviour) at the top of your code., it will disable AppGameKit Script from supporting various things, such-as using the same signifier names for different things but it also means you ALWAYS have to declare a variable before you use it.
I'd argue however this will force you into good programming etiquette.
You should always be declaring Variables, and each Object should always have a Unique Identifier.

I'm really not a fan of AppGameKit Script., at least compared to Dark BASIC v3.0... there are of course some good improvements such-as Array Functionality, and Function Reference (Safe) Pointers.
Still this comes at the cost of performance (which given the primary focus is Mobile Development, which is already far less performant than Desktop) and various core language behaviours common to Compiled Languages.
It would've been good had AppGameKit Studio, actually switched to an LLVM Language Compiler; to build a Native rather than Interpreted; but then I also don't understand the point in supporting Vulkan, while not supporting features beyond OpenGL ES 1.1 (OpenGL 2.0 Subset)... which in terms of features is actually less complete than DirectX 9.0c that Dark Basic Professional uses; and the lack of Multi-Threading to take advantage of Multi-Core / Multi-Threaded Processors (which every CPU since 2007 has been) ... well again is a baffling choice, esp. not to correct it with a "Modern" Version of AGK.
Esp. as support continues for AppGameKit v2 ("Classic" / "Standard"), which could keep said legacy compatibility for legacy devices that don't support Vulkan or more modern features.

It essentially means that for more Serious / Complex Projects., you're more or less forced to switch to "Tier 2" (C++) with the AppGameKit Engine SDK... but then that never made sense to me., because AppGameKit as an Engine is so limited in it's Features and Functionality not to mention it does come at a cost; where-as various alternatives do not., that it makes very little sense unless you're transitioning from AppGameKit Script to stick with AGK.
In fact there are various Free, Open Source and License Free Options available for anyone going C/C++ that provide far more modern features with similar scalability and support from Legacy (Low-End) Mobile to Bleeding-Edge Hardware.
AGK's "Benefit" is arguably it's easy usability, but then it's also often quite restrictive and limited in functionality... and again more so than something like even TGC past offerings like Dark Engine SDK; which can be used even on Mobile with a Darwine Layer.

•

I'd argue that AGK's biggest boon is the fact that it is a BASIC Language., which is far easier to learn and use for Rapid Application Development (RAD).
It is an excellent entry level programming point, while scaling quite well to more advanced concepts... and had it built upon what Dark Basic v3.0 had left off., would arguably be very close to C/C++ in terms of overall functionality right now.
The inclusion of an All-in-One Application Programming Interface (akin to DirectX) while also being relatively easily expandable., is again an excellent aspect.
One that if you look back at Dark BASIC Professional was one of it's biggest strengths against it's competition at the time (Blender, Unity, Blitz, etc.)

How this has been approached with AppGameKit however., it seems (to me at least) that this isn't something that either TGC doesn't understand, or isn't interested in pursuing.
There is a bit of a schism between what the Community itself wants and what TGC seems to want to focus on.

With the irony being that the Community essentially want TGC to focus on what they're actually good at producing., while TGC want to focus on what the Community is good at producing.
AGK as a result is stuck in this weird middle-ground between the two., not what either really wants.
It a shame as it's a lot of wasted talent, effort and potential.

Heck AppGameKit Studio is a perfect example., as it took what 2-3 years to produce; essentially exactly what we already had with little more than a meaningless bullet point.
What's the point in switching to Vulkan, if the language and functionality isn't also enhanced to take advantage of what it offers?
Why spend years updating Graphics, when things like the Audio Interface is beyond basic?

I know there was an actual thread (which keeps being locked and unlocked) about this all., but all of it just has me scratching my head over what TGC are hoping to achieve; and basic concepts (such-as your query) where your led to believe something is a bug with the IDE when it's an oversight with the Core Language (Scripter).
Well, it just kind of highlights this.

"Hey guys, have noticed that I cant have a function and a type with the same name in the IDE for AppGameKit Studio."

What programming language allows that? I mean, some will allow it if they're done at different levels (ex: global and local) , but most will either error out or ignore the second instance of the same identifier. Using the same identifier for both a function and a variable/UDT seems like bad practice, no?


"Heck AppGameKit Studio is a perfect example., as it took what 2-3 years to produce; essentially exactly what we already had with little more than a meaningless bullet point.
What's the point in switching to Vulkan, if the language and functionality isn't also enhanced to take advantage of what it offers?
Why spend years updating Graphics, when things like the Audio Interface is beyond basic?"

EXACTLY.

This is the first programming language ive used. Besides DarkBasic.

I had no idea it wasnt standard that things couldn't have the same name. But there you go. I assumed you could have a function named projectiles() and a datatype that goes with it projectiles[]

But this is frowned upon/not possible in other languages?

It's possible, but people tend to be terrified at the idea of keyword collisions these days.. So they tend to push the single instance line. Multi instance is fine when the usage of a keyword is contextual (as you've pointed out), so the compiler can suss out the programmers intent, even if there's a collision.

I often use the same function name for a UDT when I need some kind of constructor for the UDT.
This also works with option_explicit.

I wouldn't want to miss it.

I would just like to add that if you use Linux then you get used to 'Case Sensitive' being a thing. I tend to differentiate between caps, underscore or both. I prefer both.

the usual method is to either use case sensitive approach
i.e.
all functions have capital letters and variables have lower case
e.g.
function SomeFun()
Type someFun

or use a signifier like t before your names (so all names with t are Types)
e.g.
function SomeFun()
Type tSomeFun

This actually brings up memories of Java for me where multiple functions of the same name are a thing and the compiler goes to what one matches the parameters.

I ended up added _routine to the function names.

So projectiles_routine does stuff to projectiles[]

At some point I will branch out and learn another language but so far AppGameKit is so great

You have made a great choice to get started. It becomes addictive. And you are on the right track, just so you know a routine is a block of code like this:



And a function block of code is this:


Have fun!