PROJECT: Playest II

[J Bytheway]

Sorry about this, but due to scircumstances beyond my control I won't be able to upload any new versions until September - if one is wanted before then another willing person will have to be found to put it together.

Keep the bug reports coming .

[BureauBert]

CityIsValid always returns true

I already had the impression in earlier testing that CityIsValid always returns true.
Now I tested it again using a sound and AddCenter:

int_f IsCityAtLocation(location_t theLoc) {
	location_t tmpLoc;
	city_t tmpCity;

	tmpLoc = theLoc;
	GetCityByLocation(tmpLoc, tmpCity);
	if(CityIsValid(tmpCity)) {
		PlaySound("SOUND_ID_BOO");
		AddCenter(tmpLoc);
		return 1;
	}
	return 0;
}

I am using the above function to check if an army is in a city - if so it shall not be used as an offensive army ...
Observation: I am getting the "boo" every time the function runs, the screen often centering on locations far away from any city (when tmpCity should be empty/invalid).
The only conclusion I can think of: CityIsValid always returns true.

[Fromafar]

In the way you are using it here, it will return true every time after the first valid city has been found.

You are using GetCityByLocation, but are not checking its return value. When GetCityByLocation returns 0, there is no valid city at the location. In this case, the tmpCity variable is not updated, so it will still have the - valid city! - value from the last successful call.

[Martin Gühmann]

First why do you make it so complicated, the following is enough:

if(GetCityByLocation(tmpLoc, tmpCity)){
	//Do some stuff if there is a city at tmpLoc
}

Get city returns 1 if there is a city at rhe given location, otherwise it returns zero. From the source code the CityIsValid function is OK. And I think your problem is rather that you don't know how slic works.

All variables dicleared in slic keep their value until slic is relaoded or a new values is assigned.

When your IsCityAtLocation is entered for the first time the tmpCity variable may be filled or may be not filled by the GetCityByLocation. If the value of tmpCity is a valid city, the value is not set back to zero, when the function is called again, it keeps its value. The GetCityByLocation function only does something with tmpCity variable if at the given location is a city, otherwise the old value is keept. So once your function retuned true it will always return true until the city contained in tmpCity is destroyed.

-Martin

[BureauBert]

posted by Fromafar
In the way you are using it here, it will return true every time after the first valid city has been found.
You are using GetCityByLocation, but are not checking its return value. When GetCityByLocation returns 0, there is no valid city at the location. In this case, the tmpCity variable is not updated, so it will still have the - valid city! - value from the last successful call.

Thank you, this explains it, so there is no need for fixing.

posted by Martin Gühmann
From the source code the CityIsValid function is OK. And I think your problem is rather that you don't know how slic works.

You do believe me that I am not doing all this for getting rich and famous, dont' you? Like most of the people here I am researching SLIC for having some serious fun. Let me put it in other words: This is not my profession, and even in this case I could not be blamed for "not knowing how SLIC works", since this scripting language is not documented too well. I think it is not completely dull to assume that a function "GetCityByLocation(location_t, city_t)" would just fill city_t with the city if there is a city and leave the variable empty (assign 0, NULL, whatever) if there is no city.
If I knew how GetCityByLocation works I could have considered the fact that SLIC keeps the value of local variables, somehow. But I have to admit that I didn't know either what this *exactly* means until you provided this information in your above answer (if I am interpreting it correctly): "In SLIC, local variables keep their values inside the function they are declared in (when the function is called again)". I wonder what happens if two local variables have the same name: Will SLIC recognize them as different local variables? For being on the safe side, most modders seem to be careful about using different names for local variables ...
Anyways, I am trying to contribute to a proper documentation of SLIC and other modding stuff and I updated some information here for helping SLIC-ignorants like me to become SLIC-gurus one day.
I will still appreciate any information about how things *really* work.

[BureauBert]

I know this is the playtest thread but I had a brief look at the descriptions for similar functions in the original documentation and, though they are all referenced to as int-functions, their description does not clearly state what this means. I would suggest the following:

• GetArmyByIndex(int-player, int-index, armyvar): Returns true if the indexed army of the given player exists and stores it into armyvar
• GetArmyFromUnit(unit, armyvar): Returns true if the given unit belongs to an army and stores the army into armyvar (AFAIK units always belong to an army, so this function would really always return true)
• GetCityByIndex(player-int, index-int, cityvar): Returns true if the indexed city of the given player exists and stores it into cityvar
• GetStopResearchingAdvance(player1, player2, intvar): Returns true if player1 wants player2 to stop researching an advance and stores the advance's index (-> Advance.txt) into intvar
• GetUnitByIndex(int-player, int-index, unitvar): Returns true if the indexed unit of the given player exists and stores it into unitvar
• GetUnitFromArmy(army, int-index, unitvar): Returns true if the army contains a unit given by index (from 0 up to number of units in the army - 1) and stores it into unitvar
• GetUnitFromCell(location, int-index, unitvar): Returns true if there is a unit given by index (from 0 up to number of units in the cell -1) at the given location and stores it into unitvar

Any comments/corrections on these descriptions?

[Fromafar]

The descriptions look good, except for GetStopResearchingAdvance. That one always returns 0 (false) and does nothing, because it has not been (re)implemented yet.

Your interpretation of the working of local variables is correct. For C programmers: all local variables behave as if the declaration would have contained a 'static' keyword.

Furthermore, there is no danger at all in giving the same name to different local variables. Internally, the Slic interpreter will rename every local variable by adding the function name, so they all are unique. In your example, the 'tmpLoc' variable is expanded to something like 'tmpLoc@IsCityAtLocation'. Because you are not allowed to use @ in variables names, you will not be able to generate the same expanded name.

[kaan]

Originally posted by BureauBert

You do believe me that I am not doing all this for getting rich and famous, dont' you? Like most of the people here I am researching SLIC for having some serious fun. Let me put it in other words: This is not my profession, and even in this case I could not be blamed for "not knowing how SLIC works", since this scripting language is not documented too well.

Hi BureauBert
I would like you to understand something about Martin Gühmann. Although he is very good at english and have a large vocabulary he is still using German grammatics most of the time (and im using Danish grammatics most of the time).
This can sometimes have result that what he writes can be highly offensive if this is not taken into account.
Please do not take offence of his writings, I am sure that he is just pointing out the fact that the error isnt in the source code but in your understanding of SLIC.

Regards
Klaus Kaan

[BureauBert]

Good morning, gentlemen!

Thank you, Fromafar, for your useful additional information. Although I am not a C-programmer (I used to work with "Clipper" a long time ago, if anyone remembers that and I have some experience with Perl, that's about it - and I did learn all I know about "programming" by doing) - anyways: Thanks to your explanation I now *do* understand for the first time how those local variables are handled in SLIC. And I am now able to add the above descriptions to the "knowledgebase".
Hi Kaan! Well I do understand that there are different people form all over the world in this forum and they all contribute some of their local habits, in most cases also their humor - this is what I always enjoyed here. I am afraid that I am contributing some of my Viennese habits, too. And I really don't mind if someone corrects me or even tells me my understanding of certain items in our "modding toolbox" is complete nonsense. If I am reporting a "bug" and someone tells me it's no bug at all but my own fault in using some SLIC-function, I am always glad to learn how to use SLIC correctly and I think there might be one or two other people out there who do not already know everything about SLIC, too (just as a sidenote: usually I *do* try and think about it myself before posting here , though the result might not always look like that).
As for grammatics and offense: I think I should eventually discuss this one with Martin himself in the first place (maybe via PM rather than via this thread). And yes: I am absolutely willing to take some minor differences between german and viennese language into consideration, too ...

With my best regards to all of you
Bert

[Martin Gühmann]

I'm sorry BureauBert if you felt being offended. However I think the cause of the missundarstanding wasn't a problem of grammer, but rather of word selection. Actual I wanted to say something about linkage, scope qand storage in slic. And also state this in the sentence, but I thought that you might not know these terms and actual more important I would have been in the need to look it up myself either to get it right. And my time this week is limited.

However slic in general is not uncomplicated, because it doesn't work as you expect, because of design, because of bugs. The storage duration you encountered is one example. IIRC I read somewhere that slic uses a c like syntax, for me that implies that local variables lose their values when the block of their declaration is left. It is not very nice to figuere out why a function does something else than expected, just because an array is not emptied when a function is left. In particular if you have to do it the hard way.

For the names of local variabled I don't know if you can use them in other block. At least I know that this gives an slic error:

HandleEvent(BeginTurn)'Test_Name'post{
int_t i;
}

HandleEvent(ArmyClicked)'Test_Name'post{
int_t i;
}

Because i is defined twice in the Test_Name event handler. Both event handle blocks have the same name. But I don't know if you can use the i in both blocks if you just define it in one block.

Doing this would be very interested, because if you need a variable that should be used in more than one event handler, you don't need to make it global. Something that you don't like if you are used to program object orientated.

-Martin

[BureauBert]

Good morning once again & Hi Martin!

I'm sorry BureauBert if you felt being offended. However I think the cause of the missundarstanding wasn't a problem of grammer, but rather of word selection.

OK, OK, it's OK for me and you are certainly right in your analysis about grammar/word selection.
This is such a small, nice community of people dealing with SLIC and CTP2-modding at all that I really don't want to "make a mountain out of a molehill" (that's what my dictionary suggests - it's about 20 years old ). Those viennese people can be so touchy at times .

And my time this week is limited

Ah, yes, at least some of us do have a life.

However slic in general is not uncomplicated, because it doesn't work as you expect, because of design, because of bugs.

... and the efforts and insights of the source code team will certainly help sorting these things - sometimes maybe even my "bug-" or bug-reports and questions ...

[Fromafar]

Originally posted by Martin Gühmann
[...]
Both event handle blocks have the same name. But I don't know if you can use the i in both blocks if you just define it in one block.

Doing this would be very interested, because if you need a variable that should be used in more than one event handler, you don't need to make it global. Something that you don't like if you are used to program object orientated.

Hadn't thought of this possibility. In C, non-static function names were supposed to be unique. However, the event handlers are never called explicitly, so multiple blocks having the same name is not an immediate problem.

If you define the variable (only once) in some block, it will be shared by all blocks with the same name. Defining it twice - as in your example - will result in an error.

I doubt this is an intended feature. Most likely it is a design flaw. While you may have a valid use for it, it will have a nasty consequence as well. When you (think you) are intentionally accessing a global variable in some function, you will end up accessing a completely different variable when someone else later adds an event handler with the same name as your function.

[Martin Gühmann]

dp

-Martin

[Martin Gühmann]

Originally posted by Fromafar
When you (think you) are intentionally accessing a global variable in some function, you will end up accessing a completely different variable when someone else later adds an event handler with the same name as your function.

It is not my intention to access an global variable. My intention is to access local variables in more then one context, and here lies the problem, because my goal is to encapsulate such a variable, so that it can only be used locally, and noone can change the value of my variable without modifing my code. But here you just need to write such an event handler and you are fine.

Originally posted by BureauBert (that's what my dictionary suggests - it's about 20 years old )

Maybe you should try my dictionary.

-Martin

[Fromafar]

Originally posted by Martin Gühmann
It is not my intention to access an global variable. My intention is to access local variables in more then one context, and here lies the problem, because my goal is to encapsulate such a variable, so that it can only be used locally, and noone can change the value of my variable without modifing my code.

That's the problem exactly. There is no encapsulation of the variable at all. Without changing your code anywhere, I can still access your variable. I only have to define a new event handler with the same name. And worse, I may even do this while being completely unaware of your code. When I do not define the variable in my piece of code, I may think that I am accessing a global variable, but I am actually tricked into accessing your variable.