JTD City scripts (beta)

[Trexian]

Update: attachment updated to ver. 01b
------------------------

Ok, these are my first attempts at any kind of "real" scripting.

No demo mission yet, although I'll work on it.

The JTDCity_init should be run at initialization, or at the beginning of a mission. 

Credit goes to OFPEC, hoz, Spooner, and DMarkwick.   

From the comments/readmes.

Readme for JTDCityPosition.sqf function.
By Trexian/hoz

The purpose of the JTDCityCenter function is to determine the location of a city area. It is almost a direct rip of the FindClosestTown function by hoz, available at OFPEC.  All I did was change the elements returned, and tweaked the mechanism for creating the array, as suggested by Spooner.  All credit for this function really goes to hoz.

Readme for JTDCityCenter.sqf function.
By Trexian

The purpose of the JTDCityCenter function is to roughly determine the center of a city area.  It starts with the position passed to it (likely the config location of the city), and determines the densities of the areas in each direction.  If one of the densities is larger than the inital, that becomes the temporary center.  The search is repeated until the script reaches a position that has no higher density in the surrounding area.  That position is returned.

Readme for JTDCityBorder.sqf function.
By Trexian

The purpose of the JTDCityBorder function is to roughly determine the size of the city being analyzed.  It first determines the baseline density for the center of the city.  The analysis is different, depending on whether it is a high-density or low-density city.  The script uses a circle of the given radius (_radius) to compare the density within the circle to the initial density in each cardinal direction.  When it reaches a certain percentage (_densityCutoff) of the original ratio, it considers that the outer extent of that direction.  The script uses the longer of North/South for the B radius, and East/West for the A radius.  The _radiusFactor is basically something to increase/decrease the size of the radii by an artificial amount, depending on the needs of the developer.  This can also be achieved by altering the returned elements in the calling script.

Also, within the script, the areas to tweak are:
- the first conditional determines the definition between "big" and "small" cities
- the _dist is the increment for the center of the search
- the _radius determines the size of the circle the search examines to determine the ratio to compare to the initial ratio

/*
 JTD City Initialization script
 by Trexian
 
Purpose: run the JTD City functions

Implementation: executed from init or mission.sqm

Future plans will include greater information exchange.
ooooooooooooooooooooooooooooooooooooooooooooooooooo
"JTDCityPosition.sqf"
   - passed no parameters
   - returns an array of all cities in the config, and the config positions
"JTDCityCenter.sqf"
   - passed a position array (most likely from JTDCityPosition)
   - determines the approximate center of the city, by density
   - returns the position of the center
"JTDCityBorder.sqf"
   - passed a position array (most likely from JTDCityCenter)
   - determines an approximate geographic size of the city in X (radius A) and Y (radius B)
   - returns radius A/B for use in marker or trigger

The markers are created to show the scenario developer the location and size of the parameters.

This particular script loads the centers and borders in additional global arrays that are indexed in the
same order as the city list taken from the config.
*/

Apologies if this stuff doesn't merit inclusion.

Edit 1:Correct zip included, although it still suffers from no demo mission and the style issues identified by Spooner.

Edit 2: attached pbo with scripts/functions that should better conform to the standards.   
(This is my first attempt at exporting a mission as a pbo, so if I messed something up, let me know.  Also, should I upload just the scripts/functions, too?)

[hoz]

Glad to hear someone learned something from my work. OFPEC will accept any scripts, everyone has thier own way of doing things and people learn from all kinds of different examples.

Be sure to include demo missions.

[Spooner]

Sorry, some little issues with what you have submitted (and you aren't the first or will be the last to make these mistakes; don't be discouraged). I'll give it a proper look over when there is a demo mission.

Never use compile loadfile to pre-compile your functions; Always use compile preprocessFileLineNumbers, since then you get much better error messages and you can use //, /* */ and #define inside files that you will compile into functions

The correct way to use OFPEC tags is with an underscore, thus "JTD_cityPos", not "JTDcityPos".

Don't put version numbers as part of the script filenames, since this will mean that other scripts will need to be changed every time the version number changes (well, OK, the calling script will need to be changed when you change the parameters, but you will probably release some updates without changing the required parameters). Put numbers in the name of the zip and, if you are keen, inside the files themselves. With version number on the zip it is easier to work out what version the release is without having to open it (and you can clearly see what version is attached to the thread).

[Trexian]

Still unsure how much I can cuss, so I'll say,
FFFFFUUUUUUUUdge.  About this:

Never use compile loadfile to pre-compile your functions; Always use compile preprocessFileLineNumbers, since then you get much better error messages and you can use //, /* */ and #define inside files that you will compile into functions

Freaking drove me crazy, because I'm a BIG user of comments within scripts.

Will fix that stuff when I get a demo mission going.  Won't be anything fancy (since... I don't "do" fancy at this point), just something to give the idea.  Hopefully by the end of the week.

 

EDIT!
DANGIT - the best laid plans of mice and men.... I think the zip has the version of the init I *didn't* want to use.  The one without Spooner's suggested arrays.

I'll get this right at some point....   

[hoz]

The demo mission simply needs to just demonstrate the scripts. How a user would incorporate them into thier mission.

[Spooner]

Yes, in many ways it is important that the mission isn't fancy! Just putting it on Sahrani and putting obvious dynamic markers over the cities would pretty much cover it. That is, it is the simplest mission that shows off what the scripts can do, rather than a full mission that uses the scripts in a real-world situation.

And don't get so worried. This is beta release, not "final", so we know there will be problems (I've released some rubbish in my time  ).

[Trexian]

First post updated.

The mission is pretty lame.   You've got a Humvee and a driver.  Get in the Humvee and have him go to a city.  Might want to go to 3d person view.

When you enter the mission, if you look at the map, you should see red ellipses in the area of the cities.  Those (obviously) are just there for debugging/dev-ing.

One thing I would love to implement is, in the city position function, to have the name of a city passed and have it return the config position of that city.

I can get it to count the number of elements in a config, and I tried to use typename to make sure it was a string, but couldn't work out the specifics. 

Also, WAY open to other ideas on these functions. 

[Trexian]

Ok guys... any issues/ideas/criticisms/suggestions?

Decided not to try to add the function to pass the city name.  By using a global variable for that information, it is just too easy to run a quick filter in the script itself.  I don't know that adding that functionality to the function really adds anything.

[i0n0s]

Hmm, I missed that update.

First point would be to add a readme to the mission. So what can the user expect? What should happen?
Then I would add some infos how to use those functions. There are some readmes, but the doesn't told me that much. And if I could read the CityBorder readme right, I have to manually edit the file for tweaking? Please use parameters at this point.

About the functionality question: Personally, the scriptwriter should know for which purpose he develops his scripts. Scripts without purpose are little *äh* useless?

Maybe talk to Special Ed? As far as I could see, he is working on a "hide show system for towns" and your scripts may be useful for him. I'm not sure what exactly he likes to do, but if it is a "dynamic civilian town populate script", it would be the script every one is waiting for. Especially if it will work on every islands.

[Trexian]

The dynamically-populate-cities-with-civilians is what I've got working, too.  Couple things to work out, but it works.     I can post a couple bare-bones missions if there's some interest.

As far as the tweaking goes, the parameters I've used work for my purposes.  But, I can see how other devs might see other purposes for them, and may want to tweak them accordingly.  I'll try to work out a decent way of making the things tweakable.   

Edit:
What do you mean that everyone's been waiting for a dynamic civilian script?   

[i0n0s]

What do you mean that everyone's been waiting for a dynamic civilian script?  

Loki would say: It would be a ten-turret-tank for mission developer. So shortly: Everyone will use it!

[Trexian]

I have two proof of concept pbos, I guess.  I should probably start a new thread?