Printable View
Without a second queue, Lacewing disconnects if the frame rate isn't high enough, as it cannot respond to pings from the server in a timely fashion. By moving the handling immediately, pings are responded to instantly, retaining the connection. For a demonstration, add Popup Message Box 2 + Lacewing and keep a popup open while Lacewing is connected.
Unless the framerate is one frame every 30 seconds I doubt Lacewing will disconnect due to ping timeout.
As for my negativity toward your code and the general unhelpfulness associated with it, I am expressing that the things you are doing are generally frowned-upon and lead to problems. You have some good features like half-implemented support for properties in the JSON, and multilanguage support in the JSON, but you're also doing some bad things like multithreading, renaming many structures and variables, rewriting entire extensions to add 'simplicity' features (yes I see in the help it says you needed to fix a few issues with a time critical project, meaning that you spent time rewriting an entire extension to evade simple workarounds), and general malpractice. I read your help file on dumping and it's my fault for making the assumption that it was an action called Dump and not an expression that returns the string that got Dumped. On top of that, a simple "sorry" in a commit message doesn't grant you permission to decompile, edit, and recompile copyrighted work. I'd've given permission for that help file if you had asked, but now I'm just angrily/grudgingly giving you permission so I don't have to deal with that.
When I'm negative about the things you do I try to hint at what's not right. Call it poor constructive criticism if you will, but my intent is to guide and not harm. Although I was off topic, I was responding to your post which was also (slightly) off topic. Accusing me of making a fool of you in public is not uncalled for, though, but I have a hard time not being condescending if I feel that my opinions are being turned away as complaints.
I'm trying to point out that you're doing things a bit wrong and that while I've overreacted and made assumptions in the past you're still missing the point: I'm being a "this-isn't-right" detector.
Yes, I'm being annoying. Seat belts are annoying too. I don't agree with a lot of people, but I try hard not to be ignorant. Yes, I've looked at the changes, and I believe I have stated a few points to start with.
I've run a test with PMO2 and Lacewing and been disconnected after <4 seconds, since while a popup is open the event loop is not being processed. In addition, I was getting problems when just using popup menus. If a Lacewing server is attempting to send a TCP message and doesn't receive a reply, it can safely assume the program should be disconnected.Quote:
Originally Posted by LB
It was not a simple workaround LB, I was unable to use text nor number messages as both were being corrupted. And since the game used a popup menu, I found the clients kept getting disconnected. My first rewrite came after 2 weeks of trying to get Jamie's attention, and being that my creation of a C++ Lacewing game server only took 3 days at max, it was incredibly frustrating to get up every day and look at my email inbox, check my PMs, check the chatroom, and then sigh and repeat to the other people on the project "No, he still hasn't gotten back to me." I contacted him on the chatroom, via CT PM, via email, even via the CEO of CT and still not even a "I'm busy give me a couple of days". So after delaying the project for 2 weeks I ended up recoding the entire client. And he still hasn't responded as to my request for his Lacewing code. I would be much happier repairing bugs in an existing object than writing an entirely new object, as you say below, it's kinda ripping the original author off. But if the author causes more delay to your project than is acceptable, you have no alternative.Quote:
Originally Posted by LB
Well, it is said above that it's an expression...Quote:
Originally Posted by LB
To continue my original point about rewriting, I was stuck with either using my Lacewing help file, which is less informative and organised than yours, or using yours, which might honk you off. I preferred the latter because I didn't want to put down the effort you made in creating the help files. I'm afraid my enthusiasm lead to me honking you off. I assumed you were alright with it as you made no comments about its use when I told you about the edit.Quote:
Originally Posted by LB
I know your limitations and the setbacks thereof, and as I said, I value all feedback. The reason for my aggression was that this was the second time you have derailed this thread in order to question my posts. There are now 56 posts, half of which are just three people flapping at each other like angry hens.Quote:
Originally Posted by LB
Attachment 7535
Your desire to not appear ignorant and to be helpful is common to any intellectual, and in this thread I haven't meant to put you as a failure in that. Your feedback was correct and appreciated, otherwise I would have simply ignored it and rolled my eyes. The issue was that you were too forward in your questioning twice over, and it lead to you misinterpreting due to insufficient data. Although I could see your sources for your insufficient data and thus understand why you were in error and why with your source you were correct.Quote:
Originally Posted by LB
The first accusation was that I was wrong about how MMF2 handles the structures, whereas in fact it was your tests that used the wrong SDK.
The second accusation was that all my added features could already be done with little effort, and that I hadn't been working with Lacewing and multithreading enough to know it's based on a single-threaded event pump. Practically every project I'm working on uses Lacewing, both MMF2 and C++, and if you took the time to look at how my events were handled, you'd realise it's just another thread providing a secondary queue for responsiveness, by no means does it ever communicate with MMF2 outside of MMF2's own calls, and thus there is little chance of any issue with MMF2 due to multithreading access failures or memory overwrites.
Your posts were just making assumptions which, for most of the people you help on the forum, is quite accurate, due to the low level of difficulty in their requests, but for something I have spent a good portion of four months on you can expect some hostility when you question absolutely every single change I've done Lacewing -> Bluewing. I got the view that you just looked at my change list and started writing a put-down immediately before you looked at how I coded it, because I know you're fond of Jamie, and no doubt my rewriting of what I seem to call a 'superior' Lacewing is undoubtedly an offence to that affection. My intention is not to deprecate Jamie's work, which is the entire reason I called it Bluewing; it's certainly not because the two are incompatible. For all I know, he's slamming out a new Lacewing in two weeks and three days.
With regards to Jamie's feedback, he denotes that it is inefficient (and from his perspective useless) to have a second queue, and I agree; if Lacewing could remain connected while its Tick() function is delayed by user-set amounts of time (who knows how long it'll take for a user to close a popup message or finish selecting an item on a popup menu), that shift to multithreading would have been downright stupid and just added over-complexity. But the <4 second margin is quite unacceptable, and hopefully he will find a workaround for that. The original single-threaded method was coded and tested just as thoroughly as the multi-threaded.
I make bad assumptions and don't fully go into details. You're right, I'm wrong. But would you at least consider that there are workarounds? EG sending binary messages for strings and numbers, and using Jaffob's popup menu object which supports model-less popups? (Why do you need model dialogs?)
I'm sorry for being an idiot with no idea of what you're dealing with other than your crude humor in ClickConverse (which is probably not anywhere near as offensive as Eliyahu's). I've stubbornly built a poor image of you and your work just from repeated minor incidents and experiences. I've been a hypocrite and I've been rude without mercy. I'm also highly antisocial.
And to be honest I don't care if you reuse the help file, I guess when I wrote that I was looking for ways to incriminate you or something. I'm at fault here. "Derp".
In other words, I apologize for completely destroying your public image and wasting your time.
My humor is not offensive; you just don't like me mentioning bulbasaurs.
Keep it nice folks or I'll lock the thread and then you'll have an angry Phi to deal with!!
Or the "number" 0.Quote:
Originally Posted by Eliyahu
The angry Phi is revealing a screenshot taken 6am earlier today taken on his old IRC made to look like Gwerdy:
http://dark-wire.com/temp/screen.png
This entire raging was a psychological analysis of the two prominent extension developers in order to gain a perspective into LB and Jamie. I spent a good hour working on my reply in order not to leave a sour note. Unfortunately I'm incredibly blunt and hence this post. The meaning of things I say are usually not as obvious as they appear.
I'm confused, lol
You're not on ClickConverse enough, I was interested in getting to know how your mind works a bit better, and I knew being aggressive brought made you talk more, so I went aggressive against you.
I don't go on CC when I'm angry because it makes me angrier ;)
You're angry too often then... ;)
For pity's sake everyone, please get back on topic XD. Some of us actually want to know about Dark EDIF, you know ;)
Can we have more control over menus? Presently, I think the SDKs tend to micromanage the menu systems (in my opinion anyway), which is a pity because it's an opportunity to really create a powerful interface for our extensions. Things like icons on our menus, for example, and greying options out depending on our properties, stuff like that.
It's an aspect of extension development which I think gets overlooked at present.
I'm desperately trying to get an admin to clean up this thread. Jeff did his usual "I'm suddenly not here when Phi's talking to me" on ClickConverse and I'm not sure other admins can edit this particular forum.Quote:
Originally Posted by Dines
It's an interesting idea. I'll look into implementing icons and such. In EDIF, you can disable items, but not at runtime. rSDK micromanages the menu support, and EDIF completely removes most of the support. I haven't modified that particular aspect beyond optimisation (changing a pointless loop to an array, removing three unused variables from a struct, creating container-aware generation). So I can look into menu icons and see how they would work.Quote:
Originally Posted by Dines
I'm considering adding a "Depends" icon for the menus which would allow you to set a submenu to depend on a property being selected (i.e. only show "Advanced" submenu if "Advanced usage" is checked in properties). But I haven't finished with DarkEDIF properties either, I'm stalled on MMF2's incredibly basic form of edittime->runtime property copying.
My latest blog post covers menu items to some extent. My next post will be another a/c/e example and will go into more detail on what you can tweak and to what effect.
Alright vast herds of fans, DarkEDIF had another update about 23 minutes ago and now has fully working JSON properties! Including unlimited-length strings, as many languages and preferences thereof as you want, and no reason to throw cake out the window!
Well, the last part is optional. You can still code your own properties if you're into maintaining compatibility with older objects (i.e. Bluewing uses old properties to ensure switch-ability with Lacewing).
But if you want to bid farewell to the days of changing several variables and using preprocessor definitions for your properties, this update gives you the ability to set up a property just by editing is the JSON - the way it should be. ;)
DarkEDIF's fancy code will take care of all the reshuffling of data when strings change length, all the precise memory editing when numbers change, all the weird combo box crud that no one on the planet likes looking at for more than a 15.3 seconds... you just worry about the JSON and if your translations were correct.
You can add your own variables to EDITDATA despite all that fancy code - DarkEDIF requires just two properties, preferably at the end of EDITDATA. It'll automatically move your data across with its own properties, keeping your settings intact. :o
Tested fully:
• Editbox Number
• Editbox Text (allows forcing of upper/lower-case)
• Static text (not stored anywhere but in the JSON, no extra memory space wasted)
Unfortunately MMF2 doesn't appear to provide all the property options that the properties should have available. Despite passing restriction flags, such as "this property should be bold", MMF2 ignores it and makes nothing bold.
Because reasons.
So don't assume it's me for those :(
Also, Bluewing has had a stability update.
Download link is here. Should be fully stable and comes with a dodgy edited version of LB's help file.
£20 by PayPal to the first person who can isolate a crash. Only the first person, mind. I don't want to be bankrupted by an ego problem >_>
Okay, time to work on finding and isolating a crash in Bluewing. :P
Just so you know, I don't have a PayPal account, but my parents do, so I might be able to ask them about it if I succeed in finding a crash.
EDIT: Wait, I just realized I don't have MMF2 on here yet. Oh well, I guess I can wait, I still have time.
Phi, I've found a crash in Bluewing. See the attached example. If you check the "automatically clear binary" checkbox, then it will no longer crash. Is that good enough for you? It actually was able to crash my whole computer. You need to leave the example running for long enough for it to crash, though (it will probably give you an error that it was sending a message that was too big before then, but you need to keep it running after that point). If it doesn't crash after 5 minutes, I would like to see a screenshot of that, since it probably means you have a lot of RAM.
You're reporting user error as a crash? Exhausting a program's memory intentionally is your fault, not Phi's.
He specified a crash, he didn't say that it couldn't be something like that. He thought it was immune to all crashes (which would include the kind I put up), but he was wrong (as I've proven). That's what he has implied, anyway (I think it was on ClickConverse). We'll just have to see if he counts it, though.
This is a user error Mr. HGF. The binary/stack messages are allocated memory for as they need it.Quote:
Originally Posted by happygreenfrog
If you don't check to automatically clear the binary, the binary will get larger and larger until the program runs out of memory and cannot create more.
At which point this kicks in to report the problem.
A crash is expected behaviour in these conditions - the fact Bluewing didn't crash, but your computer, suggests a different extension/program tried to get more memory and failed to handle the lack of it properly.
That's a fairly good indicator that you're screwing up somewhere. I think the limit for messages is 2 or 4gb.Quote:
Originally Posted by happygreenfrog
If you're for example adding a byte with value 503 and Bluewing crashes, that's a bug I need to dish out for. If you join a channel, send a message on subchannel 256 and all the other clients flee to the Netherlands, that's another one.
Using up all the available memory on the system isn't a crash that would be a fault of the extension. In fact Bluewing should be complimented for handling it in its stride, despite other programs around it not doing so.
So no payout on that one unfortunately Mr. HGF. You haven't gotten the extension to crash, just to do something that in real world scenarios will not happen.
Okay, thanks for the clarification, Phi!
I'm not able to negate the condition "Is connected" like the old relay client did... any way around this?
Valurinn, I can negate it here.
What are you using it in? MMF2 or CTF2.5?
Also, try upgrading the version from here.