By mere luck i found this community this afternoon. Im a developer for a shard called Age of Valor. We are a runUO based shard, and after reading about the engine you guys have created, im wondering if your engine would be a better solution, as we have had a nightmare of a time recently with some of or core systems. I was hoping one of the devs here could answer a few questions that i didnt see answered on the main site.
will runUO based C# scripts work with POL?
are any other languages able to be integrated into the POL engine such as c++ or py?
How hard would it be to edit some of the core POL systems to incorporate some of our techniques.
will existing map and player data work seemlessly with POL from a runUO core?
would you guys at POL be interested in incorporating some of our concepts into the POL for future releases?
would some of you be interested in sharing core related information to help us bring some of our currently sidelined projects back to life?
**edit
Have you guys fixed any of the known exploits in the UO/runUO core, if so can i get a list of items that have been fixed?
From the posts that I read, you guys seem to be ALOT nicer then the guys over at runUO. I am looking forward to hearing some of your thoughts questions and concerns.
thankyou
Greetings and Salutations
Re: Greetings and Salutations
will runUO based C# scripts work with POL?
> no -- POL Core is written in C++ and you customize using eScript.
are any other languages able to be integrated into the POL engine such as c++ or py?
> POL Core is written in C++, and you can customize with a simpler language called eScript (It's pretty much based on events: certain predefined programs that you'll write in eScript will be called by pol core when some stuff happens -- combat, logon, many others). So: pol code -> C++, customizations -> eScript.
How hard would it be to edit some of the core POL systems to incorporate some of our techniques.
> To edit POL, you need to know C++, but I think it's pretty much the language and the standard library. The code probably is big, so you'd have to take time to read and understand it, so you can change it. Not hard, I'd say time consuming. Editing other people's systems, written in eScript should be a lot easier.
will existing map and player data work seemlessly with POL from a runUO core?
> no clue
would you guys at POL be interested in incorporating some of our concepts into the POL for future releases?
> no clue
would some of you be interested in sharing core related information to help us bring some of our currently sidelined projects back to life?
**edit
> no clue
Have you guys fixed any of the known exploits in the UO/runUO core, if so can i get a list of items that have been fixed?
> no clue
Good luck. And read the docs for more info on eScript. Look for script types to know more on that "event based" thing I mentioned.
Unless you're planning to write an extremely complex and big shard, you'll probably do well with just eScript. It's small, and easy.
POL has its issues too. Customization is a heaven (it trully is -- mixture of eScript and the events I mentioned makes a lot of things easy), but sometimes, I think efficiency... not so much of a heaven, maybe an earth, but a little of a hell (I believe POL is much slower than it should be).
Never tested, but I feel as if runUO is faster than POL. No clue if that's true. But back when I was in Windows, I barely noticed runUO opened the few times I runned it. POL, on the opposite, I could see it making my whole computer a little slower. Both cases considering an empty world, and initial configuration ("bare setup" mode, for POL is much more bare than if compared to the bare setup I got for RunUO -- RunUO had some already built commands, and some other stuff I don't remember).
Even though, I'd not use RunUO -- too much work to get too little done -- and I've seen big shards on POL running on normal server computers (web server quality computers -- no biggy), and they were doing great (my ex favourite is one of those).
> no -- POL Core is written in C++ and you customize using eScript.
are any other languages able to be integrated into the POL engine such as c++ or py?
> POL Core is written in C++, and you can customize with a simpler language called eScript (It's pretty much based on events: certain predefined programs that you'll write in eScript will be called by pol core when some stuff happens -- combat, logon, many others). So: pol code -> C++, customizations -> eScript.
How hard would it be to edit some of the core POL systems to incorporate some of our techniques.
> To edit POL, you need to know C++, but I think it's pretty much the language and the standard library. The code probably is big, so you'd have to take time to read and understand it, so you can change it. Not hard, I'd say time consuming. Editing other people's systems, written in eScript should be a lot easier.
will existing map and player data work seemlessly with POL from a runUO core?
> no clue
would you guys at POL be interested in incorporating some of our concepts into the POL for future releases?
> no clue
would some of you be interested in sharing core related information to help us bring some of our currently sidelined projects back to life?
**edit
> no clue
Have you guys fixed any of the known exploits in the UO/runUO core, if so can i get a list of items that have been fixed?
> no clue
Good luck. And read the docs for more info on eScript. Look for script types to know more on that "event based" thing I mentioned.
Unless you're planning to write an extremely complex and big shard, you'll probably do well with just eScript. It's small, and easy.
POL has its issues too. Customization is a heaven (it trully is -- mixture of eScript and the events I mentioned makes a lot of things easy), but sometimes, I think efficiency... not so much of a heaven, maybe an earth, but a little of a hell (I believe POL is much slower than it should be).
Never tested, but I feel as if runUO is faster than POL. No clue if that's true. But back when I was in Windows, I barely noticed runUO opened the few times I runned it. POL, on the opposite, I could see it making my whole computer a little slower. Both cases considering an empty world, and initial configuration ("bare setup" mode, for POL is much more bare than if compared to the bare setup I got for RunUO -- RunUO had some already built commands, and some other stuff I don't remember).
Even though, I'd not use RunUO -- too much work to get too little done -- and I've seen big shards on POL running on normal server computers (web server quality computers -- no biggy), and they were doing great (my ex favourite is one of those).
Re: Greetings and Salutations
well some of that is good news, some of that is bad news. I guess I should have expressed that we are all experienced programmers with degrees. We have tossed around the idea of completely writing our own game repeatedly. The head dev over at AOV (Red) actually has written he own server core completely from c++, and it works, it just crashes from time to time for no reason. I spoke to Red about POL and he was quite familure with it, he said he didnt think it would work, the package was out of date by alot, i looked, just not and i didnt even notice that when i made this post yesterday. Im going to run POL in a private test bed and examine it for research. But it looks like as of the current status, its not gonna work. I could be wrong, i love some of the ideas at work in POL.
Re: Greetings and Salutations
The thing about POL is that POL has two separated parts (the "separated" is good). The CORE and the DISTRO. The CORE is good. It's up to date. I never did anything that required support for any expansion of UO that goes further than UOML, but I've heard people doing UOSA. The core handles default behavior for packets (you can write replacements in eScript), starts scripts based on some events (the script types), etc. It doesn't do much that the player would see by playing: the core doesn't implement spells, skills, items, hit effects, quests, npcs, etc. The core has its default behaviors for some things, but you may alter (check system hooks or script hooks in the docs). For example, the core handles combat, but you may tell it to use your comba handling script, written in escript, instead.
The CORE is good. It's up to date. It's also written in C++, which you know, which is good. Some people tend to modify the core to make it more flexible; that requires knowing C++.
The POL Script Base (we call it DISTRO), is what is written in eScript. That's probably not up to date. Never used that myself though. Many people use the distro as something to look for ideas, or to get some generic packages that could help anyone (e.g. gump handling stuff).
The point is that POL makes so easy to write your own script base that creating a shard from scratch is not actually a problem. That event based system (script types) I told you frees you from having to program everything that could be complicated, in terms of internal technicalities.
People from the outside often are unaware of this division CORE/DISTRO, and when they see a shard running using CORE+DISTRO they see something that is not even close to an OSI-like shard, which is true; so they conclude POL is not up to date. Truth is that POL people normally don't build OSI-like shards. If you look at the shards list, you'll see that most have different skills, spells, maps, items, combat, etc.
I don't know the DISTRO in detail, but I'd agree that it's not up to date. It's a good start though. I believe some shards took the distro and went on from there.
The CORE is good. It's up to date. It's also written in C++, which you know, which is good. Some people tend to modify the core to make it more flexible; that requires knowing C++.
The POL Script Base (we call it DISTRO), is what is written in eScript. That's probably not up to date. Never used that myself though. Many people use the distro as something to look for ideas, or to get some generic packages that could help anyone (e.g. gump handling stuff).
The point is that POL makes so easy to write your own script base that creating a shard from scratch is not actually a problem. That event based system (script types) I told you frees you from having to program everything that could be complicated, in terms of internal technicalities.
People from the outside often are unaware of this division CORE/DISTRO, and when they see a shard running using CORE+DISTRO they see something that is not even close to an OSI-like shard, which is true; so they conclude POL is not up to date. Truth is that POL people normally don't build OSI-like shards. If you look at the shards list, you'll see that most have different skills, spells, maps, items, combat, etc.
I don't know the DISTRO in detail, but I'd agree that it's not up to date. It's a good start though. I believe some shards took the distro and went on from there.