*.em file discussion

[Austin]

One thing on my to-do list in 097 is to clean up the .em files and organize them, and such.

My first concern is if I have over-organized it?
This first post will change as the functions (new and existing) move around.
It will be one of the last changes to take place in 097, though.

Code: Select all

UO.EM
AssignRectToWeatherRegion
Attach
Broadcast
ConsumeReagents
CreateMenu
CreateNpcFromTemplate
Detach
DisableEvents
DisconnectClient
EnableEvents
EnumerateItemsInContainer
EquipFromTemplate
EquipItem
EraseGlobalProperty
EraseObjProperty
GetCommandHelp
GetEquipmentByLayer
GetGlobalProperty
GetHarvestDifficulty
GetMenuObjTypes
GetObjProperty
GetObjPropertyNames
GetRegionString
GetSpellDifficulty
GrantPrivilege
HarvestResource
ListEquippedItems
ListObjectsInBox
MoveObjectToLocation
OpenPaperdoll
PerformAction
PlayLightningBoltEffect
PlayMovingEffect
PlayMovingEffectXYZ
PlayObjectCenteredEffect
PlaySoundEffect
PlaySoundEffectPrivate
PlayStationaryEffect
PrintTextAbove
PrintTextAbovePrivate
RegisterForSpeechEvents
RequestInput
RestartScript
Resurrect
RevokePrivilege
SecureTradeWin
SelectColor
SelectMenuItem2
SendBuyWindow
SendDialogGump
SendEvent
SendInstaResDialog
SendOpenBook
SendOpenSpecialContainer
SendQuestArrow
SendSellWindow
SendSkillWindow
SendStatus
SendStringAsTipWindow
SendSysMessage
SendTextEntryGump
SendViewContainer
SetGlobalProperty
SetName
SetObjProperty
SetRegionLightLevel
SetRegionWeatherLevel
SetScriptController
SpeakPowerWords
StartSpellEffect
SystemFindObjectBySerial
Target
TargetCoordinates
UseItem


GUILDS.EM
CreateGuild
DestroyGuild
FindGuild
ListGuilds


UTIL.EM
RandomDiceRoll
RandomFloat
RandomInt
    

ATTRIBUTES.EM
AlterAttributeTemporaryMod
BaseSkillToRawSkill
CheckSkill
GetAttribute
GetAttributeBaseValue
GetAttributeIntrinsicMod
GetAttributeTemporaryMod
SetAttributeBaseValue
SetAttributeTemporaryMod


VITALS.EM
ApplyDamage
ApplyRawDamage
ConsumeMana
ConsumeVital
GetVital
GetVitalMaximumValue
GetVitalRegenRate
HealDamage
RecalcVitals
SetVital


MAP.EM
CheckLineOfSight
CheckLosAt
CoordinateDistance
Distance
FindPath
GetCoordsInLine
GetFacing
GetMapInfo
GetStandingHeight
GetStandingLayers
GetWorldHeight
ListStaticsAtLocation
ListStaticsInBox
ListStaticsNearLocation


ITEMS.EM
AddAmount
ConsumeSubstance
CreateItemAtLocation
CreateItemCopyAtLocation
CreateItemInBackpack
CreateItemInContainer
CreateItemInInventory
DestroyItem
FindObjtypeInContainer
GetObjType
GetObjtypeByName
ListItemsAtLocation
ListItemsNearLocation
ListItemsNearLocationOfType
ListItemsNearLocationWithFlag
MoveItemToContainer
MoveItemToSecureTradeWin
ReleaseItem
ReserveItem
SubtractAmount


MOBILES.EM
EnumerateOnlineCharacters
ListGhostsNearLocation
ListHostiles
ListMobilesInLineOfSight
ListMobilesNearLocation
ListMobilesNearLocationEx


MULTIS.EM
CreateMultiAtLocation
DestroyMulti
GetMultiDimensions
ListMultisInBox
TargetMultiPlacement


STORAGE.EM
CreateRootItemInStorageArea
CreateStorageArea
DestroyRootItemInStorageArea
FindStorageArea
StorageAreas


BASIC.EM
Bin
CAsc
CAscZ
CChr
CChrZ
CDbl
CInt
CStr
Find
Hex
Left
Len
Lower
Pack
SizeOf
SplitWords
TypeOf
Unpack
Upper


BASICIO.EM
print

BOAT.EM
BoatFromItem
MoveBoat
MoveBoatRelative
MoveBoatXY
RegisterItemWithBoat
SystemFindBoatBySerial
TurnBoat


CFGFILE.EM
AppendConfigFileElem
FindConfigElem
GetConfigInt
GetConfigIntKeys
GetConfigMaxIntKey
GetConfigReal
GetConfigString
GetConfigStringArray
GetConfigStringDictionary
GetConfigStringKeys
GetElemProperty
ListConfigElemProps
LoadTusScpFile
ReadConfigFile
UnloadConfigFile


DATAFILE.EM
CreateDataFile
OpenDataFile
UnloadDataFile

FILE.EM
AppendToFile
LogToFile
ReadFile
WriteFile


HTTP.EM
QueryIP
QueryParam
WriteHtml
WriteHtmlRaw


MATH.EM
ACos
ASin
ATan
Abs
Ceil
ConstE
ConstPi
Cos
Floor
FormatRealToString
Log10
LogE
Pow
Root
Sin
Sqrt
Tan


NPC.EM
CanMove
GetProperty
IsLegalMove
MakeBoundingBox
Move
RunAwayFrom
RunAwayFromLocation
RunToward
RunTowardLocation
Say
Self
SetAnchor
SetOpponent
SetProperty
SetWarMode
TurnAwayFrom
TurnAwayFromLocation
TurnToward
TurnTowardLocation
WalkAwayFrom
WalkAwayFromLocation
WalkToward
WalkTowardLocation
Wander


OS.EM
clear_event_queue
create_debug_context
events_waiting
getpid
getprocess
is_critical
set_critical
set_debug
set_event_queue_size
set_priority
sleep
sleepms
syslog
system_rpm
unload_scripts
wait_for_event


POLSYS.EM
CreateAccount
CreatePacket
FindAccount
GetCmdLevelName
GetCmdLevelNumber
GetItemDescriptor
GetPackageByName
ListAccounts
ListenPoints
Packages
PolCore
ReadGameClock
ReadMillisecondClock
Realms
ReloadConfiguration
SaveWorldState
SendPacket
SetSysTrayPopupText
Shutdown


UNICODE.EM
BroadcastUC
PrintTextAbovePrivateUC
PrintTextAboveUC
RequestInputUC
SendSysMessageUC

[Guest]

One thing on my to-do list in 097 is to clean up the .em files and organize them, and such.

My first concern is if I have over-organized it?
This first post will change as the functions (new and existing) move around.
It will be one of the last changes to take place in 097, though.

Hmm, as it will be much work to update the "use" commands in all the
scripts, the first question would be, is there a significant benefit if you
split up the functions like this? Or is it rather for cosmetic reasons?

Xandros

[Marilla]

I agree that it would be some work, but for some reason, I really like the proposed organization. I always like the idea of having more well-defined includes/headers/etc with a tighter group of related functions/classes, more than having massive 'Uber Includes'.

I think it wouldn't be too hard to alter scripts for such a system, but I can also definitely see the point of anyone who might object to having to do that. They need to get a better, more feature-rich text editor

[Danielle]

I like the idea and I think the hierarcy proposed is good.

[Austin]

Xandros - Internally, as an em file gets smaller, the parser gets faster finding the functions. However that difference is pretty damn negligible, so yeah it is almost entirely cosmetic.

[Tritan]

I like the idea and I think the hierarcy proposed is good.

This is how I have set up all my packages already to make things alot easier for me to find. I like this idea myself and not only will it help find things, it will follow a logical heirarcy which most will find helpful.

[MuadDib]

Not to mention make it easier for finding core functions

[Guest]

Xandros - Internally, as an em file gets smaller, the parser gets faster finding the functions. However that difference is pretty damn negligible, so yeah it is almost entirely cosmetic.

Ok.. then I'm not a big fan of this idea, but if it makes you feel better, go
ahead, the way you want to split it up seems ok.

[MontuZ]

All I can say is, ouch.

It'll be a lot of work to convert, but it'll look much nicer, more organized and easier to find core functions(Quoting Muad).

[Yukiko]

You know I have mixed emotions here.

One the one hand I have always been overwhelmed by the massive size of some of the includes we have in POL. There are so many functions buried in some of them that you need an encyclopedia to list all of them and what they do. I know we are talking about 'em' files here but the idea is similar. So anytime something can be simplified I am usually the first to say "Amen!". Simplicity is one of the reasons I love POL's eScript language.

However, I am continually frustrated by the fact that with EVERY release of POL since 92 (that's where I came into the shard running business) with the possible exception of 93, there are massive changes not only to organization and tree structure of the scripts but to syntax as well ('=' to '==', 'local' etc. var declaration deprecations) etc. Now I am not naive to the fact that some changes are inevitable. The addition of realms for example added a ton of new updates to scripts but it was a good addition/change and was needed.

So when making changes try to keep in mind that many of us aren't going to use the Distro tied to the latest version but instead are going to convert our existing scripts. Some changes I can understand and see why they are made but some, I think, are unnecessary. The example I can think of right off the top of my head is the deprecation of the single '=' to '=='. I fail to see the necessity of that change.

I guess I am for the organization of the 'em' files but it will wreak havoc with a lot of people's scripts. I think that point is forgotten sometimes by the developers.

Now having said all that, I do want you devs to understand I appreciate your work on POL. So please don't mistake my earlier thoughts as a lack of appreciation.

[Marilla]

It wouldn't be difficult to write a quick program to scan all .src and .inc files in a directory, and look for the existence of the functions defined in each module.

It'd just have to have arrays of the function names. As it scans the lines, it should check if any of the functions from any of the modules exists. If so, it marks a bool variable for that module, and stops checking for that particular one.

At the end of the file, it would consider each of the use statements it needs, and see if they exist already in the file. If not, it would add them.


If they decide to go this route, which I support, I'll write up a quick C program to do this, and post the source and Windows binaries. It'll just be 'drop it in and run it', and viola'; all done.

For the record, changing from := to = would be even easier, though I'm not sure if they intend to do that part. (I like the idea myself, as it seems more consistent with other languages.)

[Yukiko]

I agree that it would be easier to convert from ':=' to '=' but my point really was that there are so many changes that take place with new versions that it is overwhelming.

From POL 92 to 94:

local and global declarations were deprecated to var but the compiler still handled them with a warning..

GetSkill() was removed entirely. Skill refs were changed from numbers to text based attributes. This in and of itself required major script revisions.

Those are what I remember but there were more.

Now from 94 to 95 from the upgrade notes file:

Deprecated constructs will give compile warnings. Your script will still compile with them, but will not in POL096.
"local", "global", and "dim" are deprecated in favor of "var"
"begin" and "end" are deprecated, meaning the "do-while" loops are deprecated. Use "repeat-until" with reversed logic.

"=" should now be "=="

"account.SetAcctName()" should now be "account.SetName(name)"

"obj . ("member_name")" has been removed. use obj.get_member("member_name") and obj.set_member("member_name")

Script Data Structures
---
Structs:

You cannot access structs with array notation, i.e. struct_var[2]. You may have scripts that access members in this way. You must change it to access the members by name, i.e. struct_var.Member_Name or struct_var["Member_Name"]. Member names are case-insensative.

Dictionaries:

Checking if a key exists: if ( dict[key] == error ) now becomes: if ( dict.exists(key) )

Arrays:

In array declarations, it is illegal to have a trailing ",". For example: var b := array{1, 2, 3, }; will not compile.

Containers
---
Insert/Remove Scripts:
Change the parameter lists for all your CanInsert and OnInsert scripts:
where the 'program' directives used to look like this:
program CanInsert( mob, container, adding_item )
program OnInsert( mob, container, adding_item )
they now look like this:
program CanInsert( mob, container, movetype, inserttype, adding_item, existing_stack, amt_to_add );
program OnInsert( mob, container, movetype, inserttype, added_item, existing_stack, amt_to_add );

if you want a really easy conversion from POL092-style Can/OnInsert scripts, change the program directive and add
this at the beginning of your 'program' section:
if (inserttype != INSERT_ADD_ITEM)
return 1;
endif

Change the parameter lists of CanRemove and OnRemove to:
program can_remove(mob, container, item, movetype)
program on_remove(mob, container, item, movetype)

Script functions that add/move/delete items to/from containers will call that container's canInsert, onInsert, canRemove, and onRemove scripts (where appropriate, i.e. if MoveItemToContainer first moves an item out of the original container, caRemove and onRemove will be called). As always, if canInsert or canRemove returns 0, the function WILL FAIL to move/add/delete. ALWAYS check the return value of an core function for an error!

Note 'mob' may be uninitialized in these scripts if a core function performed the item move and the container was not owned by any mobile.

Constants for movetype and inserttype can be found in UO.EM.

Note that OnInsert and OnRemove scripts are now run-to-completion (they used to be scheduled with other scripts).
In particular, this means they can no longer sleep.

The container limit defaults have been changed: Containers will default to limits as specified in servspecopt.cfg (if not defined, defaults: 150 items, 250 weight). MaxItems and MaxWeight properties in the container's itemdesc.cfg entry will override these defaults.


Config Files
---
You must add this to itemdesc.cfg:
Container 0xFF02
{
Name WornItemsContainer
graphic 0x1E5E
Gump 0x003C
MinX 0
MaxX 66
MinY 0
MaxY 33
Weight 0
MaxItems 65535
Maxweight 65535
}

Set Weapon 0xF020 to SaveOnExit 0.

xlate.cfg is no longer used, so any item "aliases" you may have (for example "gc" for "garlic") will no longer be converted to an objtype. In these cases, you must add an itemdesc.cfg entry for them.

The default last Skill ID is 49, and you must provide a skills.cfg entry for each skill ID. You can change the max skill id in uoclient.cfg, i.e. "MaxSkillID 48"

NPC Ai Scripts
---
There is no longer a default range for EnableEvents. To make your NPCs respond to Speech events, add an appropriate range parameter to the EnableEvents calls for SYSEVENT_SPEECH.

.props text command
---
.props is no longer an internal text command.

Now that is just from one version to another. Understand I am not saying that some changes are not good but everytime you add one more THING to the changes necessary to be compatible with a new version you make more work for the scripters. My point is if it ain't broke, don't fix it. We are all used to the ':=' for assignment statements. If it works leave it alone.