These are chat archives for highfidelity/hifi

11th
Jul 2014
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 03:01
To all code contributors… the Coding Standard has been updated to reflect some previous omissions.
Notable additions:
4.3.5 Never include Horizontal "line break" style comment blocks
4.1.9. Switch/Case Statements:
3.1.3 Use of const
changes to 4.2.5. Declaring and Calling Functions
3.4.3. Write the expression of a conditional similar to how you would speak it out loud.
3.5.1. Constants and Magic Numbers
webdood
@webdood
Jul 11 2014 05:31
Love the coding standards doc! - typo in section 1.2.2 should be "team->computePowerPlayPercentage();", you could add "begin/end" to 1.2.11, I LOVE 1.2.12, the four space thing I could do without - (I am a two-spacer) , but whatever. I realize this is primarily for C++, but in my JS coding, on the subject of global vars, I will typically have a single global variable that contains a JSON structure of variables that I need to access as globals. So something like MyApp._globals = { filePath: "foo, appName: "My App" }, etc. I LOVE 3.4.2, 4.1.2, 4.1.6. You should mention that, in a loop, you should de-reference the ending value so it is not re-evaluated every time through (not sure if you have to "care" about this in C++, but in JS for (var i=0,iEnd=myStuff.length;i<iEnd;i++) is vastly more performant than for (var i=0; i<myStuff.length; i++). I do not agree with 4.3.5 as I always break up code with start/stop demarcation lines but, to the extent that you have you code separated into many tiny little files, this is not all that necessary. So, really the only things I don't completely agree with are 4 vs. 2 spaces and 4.3.5. Since I'm not writing C++, it doesn't matter at this point. Thought you might appreciate a code review of your coding standards document though!
AlericInglewood
@AlericInglewood
Jul 11 2014 15:48
@ZappoMan Just a quick scan of the code blocks: 1.2.16., 4.1.3. and 4.1.8. have a semi-colon missing at the end. 3.2.4. contains a syntax error (declares a reference without initialization). 3.1.3.1 has a semi-colon too much at the end(!) Same for the two methods in 2.1.3. ... Not sure about this: 4.1.10. catches a non-const reference, that seems just weird.
Andrew Meadows
@AndrewMeadows
Jul 11 2014 16:05
I fixed all of the typos except for the 3.2.4 case. Extra code there seemed to detract from the message... or I couldn't come up with any things to initialized numCups to that I found satisfactory. Someone else can fix that one.
AlericInglewood
@AlericInglewood
Jul 11 2014 16:18
@AndrewMeadows I use to have a reference page about the use of const on my home page (which I cancelled a month ago or so, cause I stopped using that ISP), called "Understanding the const qualifier". It was quite popular, got dozens of hits per day.

On that page I used this:

<PRE class="code">
const <I>TYPE</I> x = ...;
</PRE>

So, I changed the coding style page to do the same :P

I should set up a webserver on my home PC I guess... Not having any webpage kinda sucks.
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 16:22
WRT 3.2.4 - I just changed it to be a function prototype instead, which is a more typical usage for a reference anyway.
AlericInglewood
@AlericInglewood
Jul 11 2014 16:32
@ZappoMan Yeah, guess that is even better in this case.
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 16:33
@AlericInglewood - wrt catch handlers… it is legal to catch a non-const reference to an exception class...
AlericInglewood
@AlericInglewood
Jul 11 2014 16:33
Oh ok.. I didn't know that.
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 16:33
here's MS's tech note on order of catch handlers...
you can find many other examples of this throughout the interwebs.
AlericInglewood
@AlericInglewood
Jul 11 2014 16:35
I was looking for mirrors or caches of my home page.. but they didn't keep a copy of that page it seems. A million links to it though :/. Oh well.
archive.today contains a backup of my homepage, but not of every link on it :p .. that's pretty useless.
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 16:35
that said it causes a copy to do so… and the const& is clearly optimal.
David Rowe
@ctrlaltdavid
Jul 11 2014 16:36
@ZappoMan Hi ... For model file upload to Amazon S3 I need to be able to read the file's content in JavaScript ... into a byte array I expect, probably via a new method on some suitable Script object ... and then send via XMLHttpRequestClass::send() ... via a new XMLHttpRequestClass::send(const QByteArray& data) overload perhaps.
Or perhaps could add an XMLHttpRequestClass::sendFile(const QString& filename) method that accepts a filename to read and send without mangling it in JavaScript.
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 16:37
@ctrlaltdavid - I believe that the implementation of XMLHttpRequest should read local files for you.
@ctrlaltdavid - Check with @huffman on that… if it doesn't work then that would be something we would want to add.
Changing the XMLHttpRequest interface is NOT a desireable solution… because that interface is a standard interface in JS.
we would prefer that interface to match the standard.
AlericInglewood
@AlericInglewood
Jul 11 2014 16:40
Haha, I found one copy, on a Korean website! :)
http://blog.daum.net/oranewbie/8792356
David Rowe
@ctrlaltdavid
Jul 11 2014 16:42
@ZappoMan Can't see file reading in XMLHttpRequest ... will discuss with @huffman ... thanks
Thijs Wenker
@thoys
Jul 11 2014 17:24
Are particles supposed to disappear when they collide with another particle?
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 17:25
no - but whatever is happening is crashing the particle server…
AlericInglewood
@AlericInglewood
Jul 11 2014 17:25
Yep, when one is an anti-particle
:P
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 17:25
I think that there are some ilformed packets edit packets being sent out
Thijs Wenker
@thoys
Jul 11 2014 17:27
I keep sending particle edits to make them spin
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 17:27
well - maybe for now… let's stop. ;) until we fix the crash. ;)
do you have a particular script you're using? can you share it.
Thijs Wenker
@thoys
Jul 11 2014 17:30
I'll see if I can get my own particle server stable and test further on my own domain, I had some problems with flickering particles
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 17:38
@thoys - Chris sent me your frisbee.js script… is that the script you've been running? and what's the repro case ? what are you doing with that script?
Thijs Wenker
@thoys
Jul 11 2014 17:42
@ZappoMan - yeah its a script based from your toyball script, I create new particles rather than catching the old one because of the lifetime, you cant throw them forever if you do set a lifetime, not sure if you can get or reset the age and add on to that every time that would be better. I had some frisbee throwing with a few misses, so they drop down into the abyss, some colliding that may cause it to crash
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 17:42
when does the crash occur?
I am running locally...
Thijs Wenker
@thoys
Jul 11 2014 17:43
after a whole lot of voxels that are thrown, try 50
then wait a while
i mean particles
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 17:43
I see a couple of issues, first of which is that the particle server thinks you're sending edit commands for a particle ID that doesn't exist… that's a clue that something could be wrong in the packets.
Thijs Wenker
@thoys
Jul 11 2014 17:44
ah yeh, that might cause some crashes
That might be happening in the simulateFrisbees loop
I need to make a cleanup there
function controlFrisbees(deltaTime) {
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 17:46
well - it shouldn't cause a crash. we should handle that.
I think maybe a recent change has broken something. I think we tweaked the packet format and aren't handling it correctly.
AlericInglewood
@AlericInglewood
Jul 11 2014 17:47
Could this be related to what I said a day ago?
[2014-07-10T20:18:08] Packet of type 8 received from unknown node with UUID QUuid("{55f01146-f05d-4b3a-a4cb-643517cf95be}")
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 17:48
no
AlericInglewood
@AlericInglewood
Jul 11 2014 17:48
I got that line 40 times every 4 seconds. I commented it out in my source code now :\
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 17:48
that's not related
AlericInglewood
@AlericInglewood
Jul 11 2014 17:48
k, thanks
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 17:49
although it may be noisy - that message usually happens when you change domains and/or a new server comes on line in a domain
because you'll get packets from the node (server) but the domain server isn't yet (or is finished) authenticating those packets
AlericInglewood
@AlericInglewood
Jul 11 2014 17:49
I never recovers... it just goes on and on.. that doesn't seem right.
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 17:51
you're probably running an old build then
that packet type 8 is an audio packet… so definitely not related to particles
AlericInglewood
@AlericInglewood
Jul 11 2014 17:51
Several days old yes - I don't usually pull while I'm still working on new patches.
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 17:52
the packet format for audio has changed recently
AlericInglewood
@AlericInglewood
Jul 11 2014 17:52
Ok, thanks! I'll update then :)
Thijs Wenker
@thoys
Jul 11 2014 17:54
@ZappoMan would it be something to expose the particle age? I would prefer to use the ones that already exist and extend their time rather then creating new ones all the time
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 17:56
you should be able to get the particles age already… isn't it part of the properties?
AlericInglewood
@AlericInglewood
Jul 11 2014 17:57
@thoys: I think that the idea behind particle age is the same as that of temporaries in SL maybe? The idea there is to stop users from building with them and doing other long-term stuff, while still being able to rez bullets in an otherwise empty sim. Or is it more like SL particles, where the life time is simply to make sure that new particles get a chance to be visible and older ones disappear as fast and news ones come in at some point (all it being viewerside)...
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 17:58
we already support lifetime in particles
Thijs Wenker
@thoys
Jul 11 2014 18:00
@ZappoMan I don't see it in the ParticleProperties class
AlericInglewood
@AlericInglewood
Jul 11 2014 18:00
Both cases however have to do with controlling/preventing loading the system too much. Imho, it seems therefore more logical to set a limit on the total number of particles that a user maybe have active: once the oldest particles disappear when the user creates more particles than allowed, then it could be allowed to instead increment the timeout of an existing particle instead. Otherwise it might be possible to get too many particles active at once.
Thijs Wenker
@thoys
Jul 11 2014 18:01
@ZappoMan I do see a property called script, is there an example how to use that if its usable?
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 18:07
particles in HiFi today are poorly named… they should be called "movables" or something like that. They are designed to be used in the manner that @thoys is using them… the are models that are given a velocity and other parameters that impact their movement (gravity, damping, etc)...
AlericInglewood
@AlericInglewood
Jul 11 2014 18:09
ParticleID editParticle(ParticleID particleID, ParticleProperties properties)
seems usuable. @thoys
Thijs Wenker
@thoys
Jul 11 2014 18:09
yes I do use that function @AlericInglewood
hmm time to brainstorm for a new name for the particles?
AlericInglewood
@AlericInglewood
Jul 11 2014 18:11
@ZappoMan Then am I correct to compare them with prims in SL that have 'Physical' box checked, as opposed of those that are not managed by the physics engine?
Thijs Wenker
@thoys
Jul 11 2014 18:12
DynamicObjects ?
AlericInglewood
@AlericInglewood
Jul 11 2014 18:12
Hmm, not entirely I guess... as I understand it you can still collide with non-particles.
Sprites ;)
David Rowe
@ctrlaltdavid
Jul 11 2014 18:16
@ZappoMan ... Uploading world model to S3 overwrites file if it already exists. Can have JavaScreipt check to see if file already exists and prompt user, "overwrite?" (or disallow overwrites, thought it's only JavaScript so can be circumvented) ... It seems that for avatar model uploading the S3 directory must be configured to disallow overwrites unless the original author? Anything to be done for world model uploading?
Leonardo Murillo
@murillodigital
Jul 11 2014 18:18
@ctrlaltdavid I think the code that handles models in world may need rewriting to match that which deals with avatars
Im not sure if thisis the case as is, but interface should NOT write to S3 directly
it should use data.highfidelity.io to authenticate the request (make sure the model doesnt already exist, if it does, only overwrite if its yours) and data.highfidelity.io should be the one that does the actual PUT
it may be that, as is, interface is writing directly to S3, if thats the case, I wonder what set of keys it’s using
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 18:30
@thoys - I think I found the problem that causes the server to crash, will have a PR with bug fix shortly.
David Rowe
@ctrlaltdavid
Jul 11 2014 18:30
@murillodigital At present, for the purposes of Worklist 19840, am successfully doing a PUT to http://highfidelity-public.s3-us-west-1.amazonaws.com/meshes/ direct from JavaScript ... can certainly do a HEAD or GET first to check it doesn't exist for the time being, though I'm wondering whether this S3 directory needs configuring so that it sends responses like it does for the avatar model uploading
Thijs Wenker
@thoys
Jul 11 2014 18:30
@ZappoMan ty
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 18:32
@murillodigital - @ctrlaltdavid is working on a new "upload model" feature in JS.. the goal is to write this in JS so as to demostrate that our scripting language has sufficient power to do this… as far as directly writing to S3.. the avatar model loading code does that does it not?
Leonardo Murillo
@murillodigital
Jul 11 2014 18:32
does not
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 18:32
or are you just saying he should be using a different URL… that gets mapped to s3 via reverse proxy or the like
Leonardo Murillo
@murillodigital
Jul 11 2014 18:32
well the real problem is that S3 doesn’t really give us much means to authenticate a request
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 18:32
give him the correct url to write to
Leonardo Murillo
@murillodigital
Jul 11 2014 18:33
short of giving each interface user their own set of IAM keys
and that of course is not appropriate
so, by means of s3 alone, going forward it would be impossible to identify who uplaoded what
and therefore set limitations in place to disable users from replacing other user’s contents, etc
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 18:33
s3 is a red herring - what url do you want him to PUT/POST to
Leonardo Murillo
@murillodigital
Jul 11 2014 18:33
so, data.highfidelity.io does that
well he’d have to PUT to data but we’d need to have the proper endpoints in data.highfidelity.io API to handle that request
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 18:34
what is the expected flow from an HTTP protocol perspective?
what endpoints are used for avatar mesh upload? why is that not the same?
Leonardo Murillo
@murillodigital
Jul 11 2014 18:35
I guess we could use the same (with small modifications)
one sec
@ctrlaltdavid I need to make a slight mod to the data.highfidelity.io api to handle a new “category” of model (as it currently is hardcoded to support only heads and skeletons)
David Rowe
@ctrlaltdavid
Jul 11 2014 18:38
OK ... Interface's ModelUploader.cpp writes to QString S3_URL = "http://public.highfidelity.io/models" and apparently handles file existence and ownership
My JavaScript's currently writing directly to http://highfidelity-public.s3-us-west-1.amazonaws.com/meshes/ ... may want to disallow that : )
Leonardo Murillo
@murillodigital
Jul 11 2014 18:38
indeed
you’ll have to POST to data.highfidelity.io/api/v1/models
passing a form encoded (if I recall correctly) set of parameters, including a category parameter
that we have to define a name for (as mentioned, we currently have heads and skeletons for avatars, need a name for this category of model)
also, are you sticking assets for the model (textures, etc) in the same directory as the fbx/fst?
David Rowe
@ctrlaltdavid
Jul 11 2014 18:40
Posting there will return "exists" and possibly "can_update" along the lines of avatar model uploading?
Leonardo Murillo
@murillodigital
Jul 11 2014 18:40
GET there will return that
if !exists then POST
if exists then PUT
if PUT and you don’t own, error
we’re basically following the same lines as avatar execpt need to define a new category and directory structure for in-world models
David Rowe
@ctrlaltdavid
Jul 11 2014 18:42
Textures aren't included in world models' FBX and SVO files?
(Am not doing FST)
Leonardo Murillo
@murillodigital
Jul 11 2014 18:43
well AFAIK (hardly know anything about the format) but from looking at, say, http://public.highfidelity.io/models/attachments/Idle%20Horse
seems like assets could be independent files that would need to accompany the fbx as well
the way that we handle it with avatars currently is all avatar-related files (assets included) get zipped up prior to POST/PUTing to data.highfidelity.io, and data handles the decomrpessing/putting in place
Thijs Wenker
@thoys
Jul 11 2014 18:47
@murillodigital are there plans to cache model data, or does it have to be redownloaded every time you restart your interface?
David Rowe
@ctrlaltdavid
Jul 11 2014 18:48
I'll see if I can get some complete example models from Chris to work with ... is looking like it's going to be a matter of reimplementing pretty much all of ModelUploader.cpp in JavaScript
Leonardo Murillo
@murillodigital
Jul 11 2014 18:49
@thoys dunno about that but certainly sounds like a proper plan (specially for bandwidth-challenged people like myself)
@ctrlaltdavid I think it may be a good opportunity to do that since we’ll have to do that sooner than later — but talk to @cozza13 about it and see what you guys find more effective
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 18:59
@thoys - the fix to crashing particle server has been merged - so in the next few minutes servers will redeploy and we shouldn't see server crashes from your script
Thijs Wenker
@thoys
Jul 11 2014 18:59
ty
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 18:59
you will want to rebuild/redeploy your own servers
Thijs Wenker
@thoys
Jul 11 2014 18:59
working on it
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 18:59
assuming this fixes it - note: I couldn't actually repro the crash… but I deduced what was happening...
your script could be improved if you didn't try to edit particles that don't exist
the typical problem would be that the particle has died because: it went out of bounds of the domain or it's lifetime expired.
the server will now, better gracefully ignore those attempted edits (it was attempting to do that before, but could have ignored part of the buffer which would cause the remaining data in the buffer to become out of sync and corrupt)...
Thijs Wenker
@thoys
Jul 11 2014 19:03
alright, I better fix the cleanup part too then, I think I know what I also did, I teleported while the edit loop was running
so those particles never existed in the domain
Thijs Wenker
@thoys
Jul 11 2014 19:21
@ZappoMan I did a proper build of my domain and the particle's still flicker, is this a known issue?
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 19:27
flicker is unrelated to changes I made
Thijs Wenker
@thoys
Jul 11 2014 19:28
yep I know, but is it a known issue, that particles flicker on some domains?
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 19:28
not a known issue, if you can provide more details and a bug report that would be useful
flicker typically means that some conflicting "state" data is coming in from the server that conflicts with simulated state on the client
this can happen if there's significant clock skew -- but the system should handle it gracefully and not flicker
so this may indicate some some kind of another problem
now...
I haven't thought about your script.. but consider this...
if you change the position of the particles in addition to the rotation… then you might be causing flicker due to the velocity simulation being out of sync with your position in your edit
you should be able to change only the rotation, and not have this type of conflict (if that's what's happening)
Thijs Wenker
@thoys
Jul 11 2014 19:31
hmm, ok , thats not what I'm doing though, i let gravity do the movement atm, only modifing the model rotation, which should be just a visual effect
I just tried the toybal.js and it also flickers
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 19:32
agreed
hm
Thijs Wenker
@thoys
Jul 11 2014 19:32
you could go to hifi://thoys.nl and try it
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 19:35
yes - @thoys - I am seeing that too
I am also getting ignoring unreasonable packet... flightTime: -4294867519
this is definitely a clock skew problem
we will need to look into this.
that shouldn't happen
Thijs Wenker
@thoys
Jul 11 2014 19:36
Its running on a VPS somewhere
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 19:36
does this happen even on your local network? can you file an issue on WL with the details of your setup
ah
Thijs Wenker
@thoys
Jul 11 2014 19:47
yes!
@ZappoMan no worries, it works now, I had to install ntp and synchonize it
thanks for pointing out it had to do with time
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 19:48
ah… intersting
so now the flicker is gone? Cool!
Thijs Wenker
@thoys
Jul 11 2014 19:48
yep
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 19:48
there you go.
ntp is required… or at least a system time that is legit
Thijs Wenker
@thoys
Jul 11 2014 19:48
maybe add this to a FAQ?
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 19:49
yes - definitely should be
AlericInglewood
@AlericInglewood
Jul 11 2014 19:56
I hope this won't be a problem once random people start to run their own Domain servers on machines with more or less random clocks.
Brad Hefta-Gaub
@ZappoMan
Jul 11 2014 20:24
the goal of the system is to allow for nodes to have different clocks