Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Tier 1 will not allow type called play to be created - issue

Author
Message
Satchmo
19
Years of Service
User Offline
Joined: 29th May 2005
Location:
Posted: 25th Jun 2013 20:15
Pretty self explanatory. I tried to create a type called "player" and it spits out an error along the lines of "could not find structure called player". Changing the type name fixes the issue.

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 25th Jun 2013 20:21
Curious?

Can you show the original code that caused the error?

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Satchmo
19
Years of Service
User Offline
Joined: 29th May 2005
Location:
Posted: 25th Jun 2013 20:47 Edited at: 25th Jun 2013 21:03


error is exactly:
"Cannot find structure 'player:$F1' in local declaration at line 4 inside gameplay.agc"

The gameplay file it references here is completely empty. Removing the include for that file yields the same error but referencing a different file in the project. It's a strange error and doesn't really cause any problems because the fix for it is so simple, but I just thought I should bring it to the attention of the tgc team.

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 25th Jun 2013 20:59
I just tried your code at the top of a working Tier 1 project and it compiled without complaint.

I suspect you are seeing some issue with your include files that actually doesn't have to do with the type definition in and of itself.

Unless you had another variable actually named player. That would cause problems.

I need a bigger context than just the snippet above, it turns out, to try to figure out why you are getting that error.

Also, try using the code delimeters. After typing your code in a post, highlight it and then click on the 'code' button on the far right of the buttons in the dialog area that you enter posts in.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 25th Jun 2013 21:03
did you use a variable player somewhere?
or exist a function named player?
Satchmo
19
Years of Service
User Offline
Joined: 29th May 2005
Location:
Posted: 25th Jun 2013 21:03
Actually, I have a function called player so I guess that would be the problem haha.

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 25th Jun 2013 21:16
Quote: "Actually, I have a function called player so I guess that would be the problem haha."

Yup, that would certainly do it.

So, not an AppGameKit issue at all.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
haliop
User Banned
Posted: 25th Jun 2013 22:02
you can simply change the type name to :

option 1 : type coolPlayer
option 2 : type sexyPlayer
option 3 : type aPlayerIsIt


funny post...
using a variable named player... haha
good stuff.

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 25th Jun 2013 22:14
It's generally good practice to name types (structs in Tier 2 as well) starting with something that makes it clear it is a type. Like 'tPlayer' or 'tPlayerPosition' ('t' for 'type').

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Satchmo
19
Years of Service
User Offline
Joined: 29th May 2005
Location:
Posted: 25th Jun 2013 22:45
Yes that makes sense, I'll use a system like that from now on.

Types still confuse me a bit though, I don't know if im using them correctly all the time. For example,



To me it seems redundant having a name for a type even though that name never gets used when using the variables. I usually just end up declaring a variable with the same name as the type its declared as. Any advice?

basjak
14
Years of Service
User Offline
Joined: 16th Apr 2010
Location: feel like signing up for mars
Posted: 25th Jun 2013 22:52 Edited at: 25th Jun 2013 22:53
to avoid such issue, always start your variables with _.
exp: _PLAYER, _SPR, _TXT ...........

MarcoBruti
13
Years of Service
User Offline
Joined: 20th Nov 2011
Location: Caput Mundi
Posted: 25th Jun 2013 22:59
Quote: "to avoid such issue, always start your variables and dashes with _.
exp: _PLAYER, _SPR, _TXT ..........."

In some SDK, the variables with prepended _ may be used internally. Alternatively you could prefixes like <module name>_<var name>.

For example, if your module is called UTILS and your var should be called foo, the final name could be: UTILS_foo.

Only a thought, maybe wrong of course.

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 25th Jun 2013 23:41
It just isn't a good idea to name multiple things (types/structures/classes/functions/variables) with the same name.

A name should only be used for one thing - any of the above things.

Otherwise you are asking for trouble.

Any scheme you want to use for distinguishing objects is fine.

You can do some googling on naming conventions in programming (or something like that) and find a variety of pages that will offer lots of advice.

It comes down to what you are comfortable with. But don't name types and variables the same (or types and functions or functions and variables, etc.).

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 26th Jun 2013 09:40 Edited at: 26th Jun 2013 09:41
i used types with t char at first

with your example:
type timages
imgbrickwall
imgstonefloor
imgstonewall
end type

levelimages as timages
baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 26th Jun 2013 10:00
I started using a system that is pretty easy to remember:



this.mess = abs(sin(times#))
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 26th Jun 2013 10:13
The "T" convention is just about universal in the Delphi world. It becomes second nature.

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
MikeMax
AGK Academic Backer
12
Years of Service
User Offline
Joined: 13th Dec 2011
Location: Paris
Posted: 29th Jun 2013 02:24
Quote: "The "T" convention is just about universal in the Delphi world. It becomes second nature."


+1 ! It becomes a notation standard in several languages.
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 29th Jun 2013 16:43
Everyone has their own system, and a personalised one is okay if you only ever plan to work alone. If you ever plan on sharing code, it should be highly obvious or follow a coding standard. For me, I use...

tPlayer - Type
gPlayer as tPlayer - Global typed variable
arrPlayer[] as tPlayer - array of typed variables

Marl
13
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 1st Jul 2013 20:20
't' as a prefix might work well in disciplined languages but when the language is not case sensitive ( as with Tier 1), there is no difference between; say tOps (for a type about operations) and the variable Tops

I use a similar system to Baxslash;

The suffix "Type" couldn't be any more obvious.
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 1st Jul 2013 21:00
But one can be disciplined in Basic, it just takes practice.

When I was working on my WIP in Tier 1, I was careful about cases across the board (including in the AppGameKit commands). This made my conversion to Tier 2 go so much more smoothly.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 1st Jul 2013 22:18
Pascal is not case-sensitive. It's a style issue.

Actually, case-sensitivity can be a trap. In C you can declare a variable or function called If. Spooky danger!

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 1st Jul 2013 23:36
Quote: "In C you can declare a variable or function called If. Spooky danger!"

Agreed. That is why discipline is needed in personal coding habits.

I'm fairly certain Fortran and Cobol were not case sensitive. Mostly because I don't remember if the card punch machines had a shift key or not (it's been quite a while).

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master

Login to post a reply

Server time is: 2024-11-24 15:47:02
Your offset time is: 2024-11-24 15:47:02