Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Klypto last won the day on February 12 2014

Klypto had the most liked content!

Community Reputation

2 Neutral

About Klypto

  • Rank
  • Birthday 02/12/1992

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

1,469 profile views
  1. I'm having a bit of trouble getting that to work elegantly. What I am doing is a trigger onenter for the popover to set a global flag, have the obstruction (viewer/container) hide when that flag is active, and refresh the window to render the change. Unfortunately this is a bit late for the popover as it's already determined it's own maximum height and would have to be closed and reopened again to size correctly. Is there another approach I should be using?
  2. I am having a similar issue starting after the 13.01 update on my HSB sliders. My RGB selection does not have any issues. If I enter 40, it appears to keep the value but I can visibly tell it's not 40. When I go back to the HSB slides it has a set value of 32. I have to enter 48 to get 40. The only numbers that stay are 91-95 The further away from 93 the greater the difference between my entered value and the result. Once I pass 95 it starts to increase in value. I noticed the same behavior in reverse on the saturation field and my Hue value slowly decreases by 1-2 values. The whole thing is weird and has been driving me nuts. Creating a new file results in the same thing.
  3. Technically, you can if you make a copy of the CSS theme set to the filemaker extensions folder as a custom theme and edit the CSS files. On mac you can see the CSS theme files if you use "open package" on the Filemaker 13 app, then go to Resources > Themes > [Theme Name] Do not edit the files in the App package directly. (Updates will overwrite or delete your css themes) On mac, filemaker can read my custom css themes in a separate extensions folder without overwriting the originals or tampering with the app. I have them in Library > Application Support > FileMaker > Extensions > Themes > [Theme Folder Name] I use this to load in things like negative values in drop shadows, because for some silly reason the inspector won't allow a negative spread value. Some of the CSS selectors for scrollbars are: portal:normal .scrollbar_track { } scrollbar:disabled .self { } scrollbar:normal .scrollbar_top_button { } scrollbar:hover .scrollbar_top_button { } scrollbar:pressed .scrollbar_top_button { } scrollbar:normal .scrollbar_bottom_button { } scrollbar:hover .scrollbar_bottom_button { } scrollbar:pressed .scrollbar_bottom_button { } scrollbar:normal .scrollbar_thumb { } Note: Editing the CSS directly is not officially supported by Filemaker and can break or be lost at any time in future versions. They split portal and portal row into two parts of the same object. Right above the selector for states like Normal, Hover, Pressed is a selector for parts of an object. I was able to get the portal to be transparent on the Enlightened after I made the "portal: row" fill none.
  4. You are being deceived Those are in fact not popups, but a bunch of partially transparent panels with text set in them being hidden with conditional formatting and script triggers. The arrows of the "popups" are an image container with a repeating field and a script positioned next to the panels. Also, popups do not let you click through them or remain open when you select or set focus on objects outside of them.
  5. Ah, nevermind. I came in this morning, fiddled around with turning the server off/on again a few more times and it finally showed up and worked. I guess I gave up on it too soon on Friday. Fabrice, I didn't encounter the same issue you did.
  6. Right now I can't get the plugins to load in the server, so I'm assuming FMS 13 isn't supported at the moment since it's new, but I want to check here just to be sure and that I'm not doing something wrong. I've tried running install plugin scripts on the server (after checking the appropriate options in the console) and placing the plugins in the server's extension directory and restarting the server. The Admin console still shows no available plugins listed. I've done this with both the standard and 64 bit versions of the windows plugin. Using windows Server 2008 R2 SP1 Standard.
  7. I'm getting this too, it's either counter-intuitive or bugged. I would expect that you could double click on the name to edit it. I have found that selecting the field type popup and then deselecting it in the panel and then waiting a second brings the field name back into focus and allows me to edit the field name again. Edit: It appears the double click threshold is too long? It seems to work fine if I treat it as more of a click - wait - click than a double click.
  8. Alright, that definitely got me going in the right direction. I rebuilt some of the simpler script to import the data directly into filemaker (didn't even know it could do that) with some xsl files, one for static data and one for dynamic. The problem I now am hung up on is the actual importing of the weapons data. They store everything under the same tag in multiple locations, for example: <weapon_stat character_id="5428010618040144225" item_id="3700" last_save="1375814217" last_save_date="2013-08-06 18:36:57.0" stat_name="weapon_hit_count" value="5887" vehicle_id="5"/> <weapon_stat character_id="5428010618040144225" item_id="3700" last_save="1375814217" last_save_date="2013-08-06 18:36:57.0" stat_name="weapon_play_time" value="226281" vehicle_id="5"/> <weapon_stat character_id="5428010618040144225" item_id="73" last_save="1371069716" last_save_date="2013-06-12 20:41:56.0" stat_name="weapon_play_time" value="149511" vehicle_id="0"/> In the example 2 of them have the statistics for "weapon hit count" and "weapon play time" in separate tags for the same item, the last one is an entirely separate item with the same stat group as the 2nd entry. Should I be trying to grab it all at once is a series of non-nested loops or should I break them into separate imports, each focusing on one specific type? <xsl:for-each select="weapon_stat[@stat_name='weapon_play_time']" > To me it seems like all at once approach would be best, because it doesn't cause multiple HTTP requests which would probably be the slowest part of the process. However since I just started teaching myself xsl in the past few days, I don't really know how to do that "correctly" or if that is even possible. I'll still try different things in the meantime. If it must use multiple imports, can I reference the XML stored in a field instead of external data? Edit: So I have the new scripts running for importing the weapon data and they are broken into 11 independent imports. It allows for all weapon data to be imported instead of a specific few for each character at a much, much faster rate than my original method would have taken, but the overall result is worse as each character now takes even more time to process. Basically it's greatly improved in a horizontal sense (scope), but slightly worse vertically, where it counts the most. The problem is still the same as I mentioned before though, where they list the different stat types for a single weapon as separate entries with the same node tags, just different attributes. The server is now bottlenecked on the latency from HTTP requests to the API server, and with the xsl imports broken into 11 separate imports for a single character's weapon data, it makes 11 independent HTTP requests & imports. I would rather have one or two xsl imports that are run for each character, as that should be much faster (and far less drain on Sony's API servers, but I'm sure they can handle it). Currently, I identify unique weapons to characters records (where the character weapon statistics are being stored) with a combined key of the character id, the item id, and the vehicle id. The imports match for these fields and add any new ones should there be no matches. That part works pretty well and the actual import into filemaker is pretty quick. XSL example for weapon Fire Count: <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://tempuri.org/impt.xsd" > <xsl:template match="/single_character_by_id_list/single_character_by_id/stats/weapon_stat_list"> <FMPXMLRESULT xmlns="http://www.filemaker.com/fmpxmlresult"> <ERRORCODE>0</ERRORCODE> <PRODUCT BUILD="" NAME="FileMaker Pro XML Import" VERSION="fake" /> <DATABASE DATEFORMAT="yyyy.MM.dd" LAYOUT="" NAME="" RECORDS="" TIMEFORMAT="k:mm:ss" /> <METADATA> <FIELD EMPTYOK="NO" MAXREPEAT="1" NAME="Character_ID" TYPE="TEXT" /> <FIELD EMPTYOK="NO" MAXREPEAT="1" NAME="Item_ID" TYPE="TEXT" /> <FIELD EMPTYOK="NO" MAXREPEAT="1" NAME="Vehicle_ID" TYPE="TEXT" /> <FIELD EMPTYOK="NO" MAXREPEAT="1" NAME="Value" TYPE="TEXT" /> </METADATA> <RESULTSET> <xsl:for-each select="weapon_stat[@stat_name='weapon_fire_count']" > <xsl:variable name="c"> <xsl:value-of select="position()" /> </xsl:variable> <ROW MODID="$c" RECORDID="$c" > <COL><DATA><xsl:value-of select="@character_id" /></DATA></COL> <COL><DATA><xsl:value-of select="@item_id" /></DATA></COL> <COL><DATA><xsl:value-of select="@vehicle_id" /></DATA></COL> <COL><DATA><xsl:value-of select="@value" /></DATA></COL> </ROW> </xsl:for-each> </RESULTSET> </FMPXMLRESULT> </xsl:template> </xsl:stylesheet> Pretty basic, but I have hardly any experience with XSL. I was trying to figure out a way of using "choose" to loop through all 'weapon_stat' nodes and then select the imported fields based on the 'stat_name' attribute, but I'm a bit stumped on the whole linear way in which the metadata to selected value works. I'm still looking into options and reading around to see what I can do with this, (maybe include variables or key selects?). The solution is probably a lot simpler than I think it is. The other part I have also considered is caching the XML data locally before the import process as a semi-cheesy way of getting around the latency during the import, but then I would have the data twice, in XML form on the server and then again stored in filemaker. It would also suck up some disk read/write time to cache 6~ Gigs of XML data on a daily basis. I could combine both for the most efficient import speed I guess, but I still don't know yet how to address the first issue. Side Note: So far in the current system it's only imported the weapons data of 195 of 14087 characters, resulting in 86,000~ weapon stats records. With that I would guesstimate that there are 440-450 weapon stat records per character, leaving the total at 6,339,150 records when finished with the current database. I'm hoping the server doesn't run out of disk space when I expand the character count, but I wouldn't be able to database all 1,314,300 characters since that would leave me at 590,000,000+ weapon stat records). Unfortunately, at the current rate there is no way I would be able to keep up with just the daily login count (estimated at 15K characters, or even a simple goal of 2-3K overly active characters).
  9. Hello I'm working on a personal side project that processes game character information and will (hopefully) provide a set of leaderboards where you can find your ranking with a give weapon or vehicle. The issue I've run into is that even with only 10,000 characters with the most play time and only a small sample set of around 30 weapons from a single class of vehicle, it would take 4-7 days for the server using my script processes to finish a single run of updating that set of character weapon information. I'm looking for ideas on optimizing the script process or alternatives to get the data processed faster. Currently the largest chunk of processing is parsing out information from XML data. Background information: Character data is available through the Sony Online Entertainment API: http://census.soe.com/ They type or data requests I am currently pulling are: http://census.soe.com/xml/get/ps2/single_character_by_id/?id=5428010618040144225 Characters can use a fairly large number of weapons, including weapons they do no own (gunning for another player's vehicles). There are about 12 categories of data I'm interested in for each given weapon id that the character has used (kills, deaths, usage time, shots fired, etc). Statistics for weapons used against that player are also listed, but do not include all categories (roughly 3). There are 3 factions within the game, each with their own "variant" of a weapon. Some weapons between the factions are generic and completely identical, but appear with a different id number within the API to distinguish which faction that weapon is being used by. The server I'm using is a Dell PowerEdge 2850 4x146GB drives (I beleive it's RAID 5, which might limit write speeds) 8GB RAM 2 Xeon 3.6GHz (w/HT? not sure if they are physically dual cores or HT enabled, but there are 4 threads) I have the filemaker server RAM cache at 3,072 MB Right now, I have 5 scripts that run to pull updated character data into the database that are scheduled to run at different frequencies and times. The data is dumped into each character record for other scripts to process. Characters are broken up into 5 levels of ranking based on play time in the past week. This determines the frequency of which the data is to be pulled to limit both overuse of the API and the number of records the server I'm using has to process. The rankings are as follows: not logged in for the past week - Dropped from updating until the end of the month. logged on, but have hardly played at all - Checked at the end of the week logged on for 5 hours - Checked Sunday and Wednesday logged on for 10 hours - checked every other day logged on for 15+ hours - checked every day It's a bit more restrictive than I want it to be, but until it's possible to process more records within 24 hours, I don't see how I will be able to allow more frequent updates. There is another script that runs periodically and checks to see if character data was imported and updates the found set. This script only covers generic character specific data like their total score, in-game rank, play time. This script also updates the rankings for the data get frequency. The final script is a weapons update script. All it does is look for records where the last timestamp recorded when the character data was process is greater than the timestamp for the last time the weapon data was processed. This is the slowest script of the server that has to loop through each character's weapon that is specified. The sample set of weapons I am currently using are from the faction specific Main Battle Tanks (MBTs). Each faction MBT has 10 possible weapons usage / listed with up to 12 categories of data each and 6 of those categories have 3 XML queries each as they are broken up on a per-faction basis. The 20 other weapons used by the other 2 factions each have up to 3 sets of data and 2 of the categories have 3x queries. So in total you have 20*(2*3+3)+10*(6*3+6) = up to 420 XML queries per character. This leaves each character taking about 40-60 seconds to process, which is too long. Reasons it may take so long: The XML I pull has some extra data that is not entirely relevant to what I want to do, bloating the size of the XML document by about 15-20% XML in itself isn't the most efficient for parsing. You can also get the data in JSON, but I don't know how to parse that into Filemaker I have poor experience with using xPath and might be using inefficient queries The server hardware I'm using might not be able to handle it all There's just freaking too much data to crunch and I'm insane for thinking I can do this as a side project Filemaker sucks at doing large scale stuff like this and it should be processed externally I'm approaching the entire project the wrong way. Some things I have done to speed things up: The weapons that are processed are currently limited to only weapons that the character owns (cuts out weapons that he may have used but does not own, and weapons that are used against them). Switched the xPath queries from being done in 360Works to the FM.NEXUS Web services plugin which seemed to be faster I probably will break up the weapons processing script to use the same ranking system and schedule all of them to run simultaneously, each focusing on their own ranking group, so that at least "priority players" will be updated in a semi-reasonable amount of time. I also had the theory that it might be faster if I pre-combine the xpath queries in 360 works and then output the data, but then it has to package the info > dump it back to filemaker > parse and unpack the info into fields which might defeat any optimization gained. Right now with this post I'm looking for higher level suggestions or general guidance. We can get more detailed as this moves along. So if you have any preliminary suggestions or need more information let me know.
  10. What I want to do: I want to conditionally hide or show fields in a portal row. The catch is a simple "background fill transparent" won't work on fields with drop shadow and additional styles as the styles still bleed through. I want the entire field to completely disappear with no trace. I know how to do this with portals on fields on the outside, but this is already part of a portal. The Why: The portal holds line items on an orders screen. When an order is submitted, certain assembly items explode to predetermined levels using their BOM information. I want this information visibly indented based on the the level it is on so that is easy for someone going back to this order in a review session to know what line items were added as part of what assemblies. Currently we have no items where it is necessary to explode beyond the first level to display on a order so single level indentation is acceptable. However the ideal setup would be one capable of indenting on multiple levels as our BOM system can potentially go an indefinite number of levels deep and there are no future guarantees that we will continue to only explode to 1 level. Our BOM view/management system uses indentation, but that is calculated within a elongated field just adding a number of spaces in front of the content based on level. The poor sales people don't have screens big enough to do this. I have an alternative with just plain text I may use in case this is impossible. There's no level of urgency on this though so I figured I might as well ask and try to learn something new before doing it.
  11. Just replace the word "client" in my first post with "horse" then.
  12. A ? without quotes is a filemaker search operator for finding records with an invalid character in that field: You can see the full list of operators here: http://www.filemaker.com/11help/html/find_sort.5.6.html#1027771
  13. Stamping out a buch with labels is pretty clever and looks like it could save me some time in making them. Thank you. Hopefully things will work out in the future and we'll move our internal UI's to a web-intranet based one through PHP in a few years, which should grant me far more flexibility on the UI aspects with CSS3 & jquery and better support for retina displays. Until then I'm just using what I can in filemaker.
  14. But wouldn't that get everything confused? Like Susan visits today and they wrote the note "Susan dropped off a package" in susan's visit notes. Then tomorrow Tommy visits and the autofill in the note for Tommy's client record notes says "Susan dropped off a package", but tommy only ever comes to pick up packages and his name isn't Susan.
  15. With just throwing untested suggestions out there: Two instances of the notes table, with the first one being connected to the field entry on your layout. Notes Table 1's client ID field connects to Notes Table 2's client ID field and has a "does not equal" connection between the note id in table 1 and the note id in table 2 . The relationship is sorted by ID's or time created /entered to ensure that the latest record is first. You should now have access to the latest visit entry for that client that does not include the current entry that you are about to enter. Then use a script to import that information from instance 2 to instance 1 when they click the button.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.