ScriptUO

Scripting Resources & Utilities => Inactive scripting projects => UOAI Corner => Topic started by: casca on September 20, 2009, 06:54:21 AM

Title: Interesting
Post by: casca on September 20, 2009, 06:54:21 AM
I'm very interested in this project... I wonder if that packet sniffer he built can detect hidden items/people :P
Title: Re: Interesting
Post by: TrailMyx on September 20, 2009, 05:45:15 PM
Great historical summary.  Thanks for sharing that!
Title: Re: Interesting
Post by: Masscre on September 20, 2009, 05:48:52 PM
Did i miss something?  I am really confused now i think !? This also sounds like the old enigma project that i worked with back in the late 90's.
Title: Re: Interesting
Post by: Artaxerxes on September 21, 2009, 12:14:00 AM
Did i miss something?  I am really confused now i think !? This also sounds like the old enigma project that i worked with back in the late 90's.
I think you might have missed the other two threads in this UOAI Corner? (http://www.scriptuo.com/index.php?topic=2693.0 & http://www.scriptuo.com/index.php?topic=2689.msg20364#msg20364 )
(though enigma code might have been more interesting? :D)

I'm very interested in this project... I wonder if that packet sniffer he built can detect hidden items/people :P

Well, i think not. If with hidden you mean the result of the hiding skill or invisibility spell or anything like that... than the server actually removes these items/mobiles from all client's screens and doesn't send a packet about them anymore until they are revealed. On the other hand you can detect a mobile being removed from your screen, for which the reason might be hiden (though you would have to analyze other packets to determine the actual reason)
If hidden just means invisible because something is blocking any sight to it, than yes, it can be detected; not only packet based.

Greetz,
Artaxerxes
Title: Re: Interesting
Post by: casca on September 21, 2009, 08:17:28 PM
Quote
Well, i think not. If with hidden you mean the result of the hiding skill or invisibility spell or anything like that... than the server actually removes these items/mobiles from all client's screens and doesn't send a packet about them anymore until they are revealed. On the other hand you can detect a mobile being removed from your screen, for which the reason might be hiden (though you would have to analyze other packets to determine the actual reason)
If hidden just means invisible because something is blocking any sight to it, than yes, it can be detected; not only packet based.

Thanks for the reply :)  Yes by hidden I mean invis/hiding/stealth.  I seem to remember something called "the all seeing eye" or something like that back in the day that allowed you to see hidden people in another RPG (microsoft's one I dont' remember the name off hand but it was big at the time).

If it's removed... then what happens when someone uses detect hidden or tracking?  Does it populate the info at that time for EVERYONE or just the client using those skills?... Also if you are using the skill tracking or detect hidden for instance... does it bring the data into the stream at that point or does it wait for a successful roll?  Just curious, but is sounds like perhaps if played with there might be an opportunity.
Title: Re: Interesting
Post by: Artaxerxes on September 22, 2009, 01:44:01 AM
If it's removed... then what happens when someone uses detect hidden or tracking?  Does it populate the info at that time for EVERYONE or just the client using those skills?... Also if you are using the skill tracking or detect hidden for instance... does it bring the data into the stream at that point or does it wait for a successful roll?  Just curious, but is sounds like perhaps if played with there might be an opportunity.

My guess: Tracking info is built server-side and only sent to the client actually doing the tracking. Detect hidden is probably similar. Also only on succesfull tracking/detect hidden it will send you that info, not earlier.
I didn't check any of this; i would have to delve into the runuo code or watch the packet stream a little closer to give a definite answer; but i know what it looks like client-side:  Items can be flagged hidden internally in the uo client; but even then they are still visible: you see them like you see yourself if you are hidden: grayed or something like that. If an item is completely invisible on the client it simply has been removed, so the server isn't sending updates on it anymore. So if other client's would be getting updates on the mobile being tracked; they would at least see a mobile flagged hidden (grayed type), which they don't.
Title: Re: Interesting
Post by: TrailMyx on September 22, 2009, 10:26:03 AM
It makes sense why EasyUO has has a "hideitem" command, but no "showitem".
Title: Re: Interesting
Post by: Masscre on September 22, 2009, 11:15:13 AM
It makes sense why EasyUO has has a "hideitem" command, but no "showitem".

But in the same cheffe has always steered away from hacks and things that alter the play stype of the game.
Title: Re: Interesting
Post by: Artaxerxes on September 22, 2009, 11:49:51 PM
It makes sense why EasyUO has has a "hideitem" command, but no "showitem".

But in the same cheffe has always steered away from hacks and things that alter the play stype of the game.

It's possible to write both hide/show item i think; depends a little on how the euo hideitem works though whether it can be shown again. But this kind of 'hiding' is ofc a different one than the invisibility casca is talking about... if a mobile is hidden server side; than even euo wouldn't be able to show it; cause it doesn't know about the item, only the server.

Cheffe did always steer away from hacks and things like that; but i personally do not agree with that choice. I can understand this choice in the sense that he would not want easyuo to be considered as a cheating tool, but rather as a nice macroing tool. I think however that it's not the responsibility of the script tool (or library in my case) developer to limit functionality to funtionality that can't be abused; but it's in the first place the responsibility of the user to not abuse it. I can also think of very little cheating tools, more powerful than current euo scripts,  that could be implemented for UO. Even if a showitem would be present (i've f.e. thought about a creatable item class in UOAI, where "Item customitem=new Item(ID, type, ...) " would work, i can see very little tools that could abuse this: an item would only be visible to the current player. The only thing i can think of would be a scam: someone selling a non-existant item to someone else which was shown on the other the scammed player's client. That would however require the scammer to get a program running on the scammed player's computer; and if you ask me the real issue here would then be the scammer gaining the scammed player's trust rather than UOAI being able to show an item on a player's client.
I can also see many avantages to showing items and gumps and being able to modify things on the client: f.e. with a more powerfull UOAI it would be possible to create a "player-event" system; where every player joining the event would have to have the event's UOAI tool present on it's computer. This tool could then do things like limiting a player's movement to a certain arena, showing special items on all player's in the event (weapons, etc. things related to the event), displaying gumps that track scores, etc... basically an event-p2p system without having to run the world server. It's just an idea... not really going to implement this (current UOAI is not powerfull/stable enough anyway)... but i personally wouldn't consider tools like that an exploit, but you are allowed to disagree! :D
Title: Re: Interesting
Post by: Endless Night on September 23, 2009, 04:35:31 AM
I have to agree Artaxerxes .. I think it would be extremely useful to be able define my own player seen gumps and such. This could possibly replace external menus. 

I was playing or rather trying to play you your dll last night couldnt get delphi to load it up .. any pointers on that would be appreaciated. The installation of c# on my system is borked.  So before I wipe the entire system clean (much needed) throught id give delphi a go.
Title: Re: Interesting
Post by: TrailMyx on September 23, 2009, 09:47:24 AM
Try out SharpDevelop, EN.  Don't even bother with VStudio.
Title: Re: Interesting
Post by: Endless Night on September 23, 2009, 10:56:32 AM
Try out SharpDevelop, EN.  Don't even bother with VStudio.

Thanks downloading it now.. but i really should wipe my system so much bloat in it at this point.
Title: Re: Interesting
Post by: Masscre on September 23, 2009, 12:36:29 PM
Dont wipe it just dust it out a little.  A good fart always helps with bloat also.  Seriously though when you say wipe are you thinking of erasing and reinstalling everything?  If this is your thought I made a nice fix for this.  I format and reinstall my os and basics.  Then get all my utilities that i need to get it working the way i want including AV and UO.  Then with Acronis true image I back up my drive the way it is not the os but the drive and when I get a problem i just do a restore.  This restore usually takes be about 15-20 mins to get everything back on the hard drive and i am back in business.  Also Acronis runs under linux so the restore program can be done from (booted from) cd/dvd and then load the image and you are good to go.
Title: Re: Interesting
Post by: Artaxerxes on September 23, 2009, 01:02:29 PM
I was playing or rather trying to play you your dll last night couldnt get delphi to load it up .. any pointers on that would be appreaciated. The installation of c# on my system is borked.  So before I wipe the entire system clean (much needed) throught id give delphi a go.

From Delphi you'll have to create an instance of the COM components directly. I know little Delphi right now, srry, but i guess it will involve importing "CoCreateInstance" from Ole32.dll and creating an instance of the UOAI class from there using the UOAI class and interface GUIDs (See the UOAI.h in the COM libraries sourcecode for those GUIDs). I tried to google for an example of using COM components from Delphi; didn't find anything suitable yet, except maybe the client part at: http://www.delphi3000.com/articles/article_3439.asp?SK= (http://www.delphi3000.com/articles/article_3439.asp?SK=). Note that you will need "CoCreateInstance" rather than "CoGetObject" I think, GetObject only works for a COM server exposing one active object.

I will provide documentation for different languages on how to use the COM library eventually. Currently i'm focusing on getting the next stable .NET library version online, since most users are using UOAI from .NET right. This next library should be far more stable and easier to use, so once this is launched i'm hoping to find more time to focus on documentation and the next COM library.
But even with documentation, from some languages the COM library is really easy to use (scripting languages like vbscript, javascript, LUA; also visual basic, C++ (though right now a suitable header for this is lacking), ...) but from other languages like directly from C or i'm guessing also Delphi; there will always be some points at which care is required; and therefore a simple dll might have been easier to use than a COM library.

Edit: it seems there must be easier ways from Delphi to use COM objects too; though i know too little on Delphi right now to help you along... the ComObj and ActiveX units (http://delphi.wikia.com/wiki/Category:ComObj_Unit (http://delphi.wikia.com/wiki/Category:ComObj_Unit) will provide anything you need... you'll need to get Delphi to either create an instance of the UOAI class using it's easyname/progid ("UOAI.UOAI") or using it's GUID (see UOAI.h). Next will be to get Delphi either making calls through IDispatch (activex method calls... i'm not sure how this is done in delphi) or by somehow providing an interface definition for the UOAI objects so that delphi can call the interfaces directly. I'm not sure if any of that makes... :)

Dupport for Delphi will be an issue when i eventually get to writing decent documentation for the COM library; that is after i finish the next .NET library; write documentation for it; and maybe even after finishing the next COM library... Let me know however if you figure out how to use it yourself, that would save me some time :).

Let's, however, not turn the UOAI corner into a support forum!

Artaxerxes,
Title: Re: Interesting
Post by: Endless Night on September 23, 2009, 06:21:55 PM
Artaxerxes I think ive got the Delphi setup worked out.  Its actually pretty easy i was barking up all the wrong trees last night.  Once i have it fully worked out ill send you the details on your site.  ;D

So far got it loaded and it launching new clients.. yet to test rest of functionaily. :-\
Title: Re: Interesting
Post by: TrailMyx on September 23, 2009, 08:17:08 PM
Man EN, what are you doing with that dinosaur??!?!?  Lol, I spent most of my early college using Pascal.
Title: Re: Interesting
Post by: Endless Night on September 23, 2009, 09:11:08 PM
Yea it is a dinasour.. + its delphi 5 ..lol not even the latest dinasour.. whats that from 95 93 !!  dont rember. But hell got it working and that was really my point, Im just fiddleing around untill my system gets wacked... not really in the mood for massive reinstall... will take to much time.. downloaded the one you recommended.. will play with that later.
Title: Re: Interesting
Post by: Artaxerxes on September 25, 2009, 10:30:58 AM
Yea it is a dinasour..

Ah, we had to use Pascal in some classes too... I remember me fiddling around with pointers for the first time in Pascal, trying to write a simple database system while my classmates where still getting a headache trying to write implementations of boring algorithms to do things like calculating primes, etc. ;) :D Never moved on to Delphi though, got fascinated by C after that, and that's still my preferred language now!

I'm wondering though, are you able to get UOAI's events working from Delphi?
Title: Re: Interesting
Post by: Endless Night on September 25, 2009, 12:14:33 PM
I'm wondering though, are you able to get UOAI's events working from Delphi?

The Events show and you can add code to them.. but they dont ever trigger.
(2 events... onclientstart, onclientexit)

Title: Re: Interesting
Post by: Newsman on January 08, 2011, 06:57:37 AM
Is this project dead?
Title: Re: Interesting
Post by: Endless Night on January 24, 2011, 06:11:05 AM
no i dont believe it is .. but it has moved locations... do a google for uoai you should be able to track it down.
Title: Re: Interesting
Post by: TrailMyx on December 10, 2012, 09:36:01 AM
Artaxerxes,

There has been some interesting projects since yours.  First is Stealth (http://www.scriptuo.com/index.php?topic=9203.0).  Great project, but since you have to program it in either Pascal or Python, this is a total turn off for me personally.

Next is AssistUO.  This looks to be a Razor replacement, but if you look at what Ximan said at EUO, the author is intending to use Java scripting to automate and that's intriguing.:
http://www.easyuo.com/forum/viewtopic.php?f=2&t=49444#p408190

If your core could be less fragile (like both Stealth and AssistUO - i.e. survive patches) and allow for C# scripting, that would be a great development indeed.
Title: Re: Interesting
Post by: NObama on December 10, 2012, 04:29:38 PM
You also need to work the word "deconvolve" into your project, somehow.  TrailMyx is a big fan of that word.  I don't personally believe it exists.

 ;D
Title: Re: Interesting
Post by: TrailMyx on December 10, 2012, 05:18:19 PM
Cough... (http://en.wikipedia.org/wiki/Deconvolution)

Enjoy the headache.
Title: Re: Interesting
Post by: gimlet on December 10, 2012, 05:51:04 PM
Cough... (http://en.wikipedia.org/wiki/Deconvolution)

Enjoy the headache.

Gim - Eats this up!
Title: Re: Interesting
Post by: TrailMyx on December 10, 2012, 07:09:29 PM
Gim - Eats this up!

That's because you are the Prince of all nerds an also seem to have an affinity for poop. :p (pay no attention to this Elite discussion. heh)
Title: Re: Interesting
Post by: NObama on December 11, 2012, 05:18:19 PM
Cough... (http://en.wikipedia.org/wiki/Deconvolution)

Enjoy the headache.

Whatever.  I can make a fake wiki page, too. 

I will admit, however, that you are taking this deception to impressive lengths.  That math stuff almost looks real.

 :P
Title: Re: Interesting
Post by: Kraz on January 03, 2013, 09:00:14 AM
Artaxerxes,

There has been some interesting projects since yours.  First is Stealth (http://www.scriptuo.com/index.php?topic=9203.0).  Great project, but since you have to program it in either Pascal or Python, this is a total turn off for me personally.

Next is AssistUO.  This looks to be a Razor replacement, but if you look at what Ximan said at EUO, the author is intending to use Java scripting to automate and that's intriguing.:
http://www.easyuo.com/forum/viewtopic.php?f=2&t=49444#p408190

If your core could be less fragile (like both Stealth and AssistUO - i.e. survive patches) and allow for C# scripting, that would be a great development indeed.
Yes, we are intending to add Javascript v8 support as an alternative macro engine, for advanced users; however it is not our priority right now, we have to keep in mind that we are providing an assistant not a bot program (:

Anyways, our simple macro engine allows much more than Razor and it is really flexible, we are adding support to new commands and stuff as soon as we have time, also, writing our documentation on our main website. Javascript engine will come, not sure when, there are a few things we have to deal with such as Map/Positioning system and some other features.

We are also planning to add a task manager to AUO which will help people to bind events to macros and handle account connectivity.
Title: Re: Interesting
Post by: TrailMyx on January 03, 2013, 09:50:04 AM
I'll be nice to see that map added to AssistUO.  That was started in Razor, but never really had any actual functionality.  In a pinch it was useful for generally figuring out where you are, but it wasn't very useful without markers, icons, names, etc.