Language: 
To browser these website, it's necessary to store cookies on your computer.
The cookies contain no personal information, they are required for program control.
  the storage of cookies while browsing this website, on Login and Register.

Author Topic:  0.11.0 changes  (Read 253 times)

0 Members and 0 Guests are viewing this topic.

_people_

« on: 20, January 2024, 00:20:01 »
I'm working on the 0.11.0 release right now, which will be incompatible with the 0.10 clients. This requires a client update, which will include improved mouse movement and other changes.

Since this is a great opportunity to make protocol-breaking changes, I'm trying to load as many as possible into 1 update. Many non-protocol changes will wait until 0.11.1.

Changes so far:

I've expanded the number of "status flags" a tile can have. This allows players to have more status effects (blindness now has an icon, although it's not very useful as players can see that they're blind). It'll also be used for unopened corpses, so the client can display special effects rather than the server adding a glow_radius.

I've removed all references to "protocol version". This is part of our old versioning system (B4 and earlier) which no longer serves a purpose.

Tidied up inventory and below window contents - this adds F_IDENTIFIED and F_UNIDENTIFIED to those items. Two distinct flags are used here so that only objects which are both unidentified and significant are displayed by the client as identified. So a random shrub below the player does not show as "unidentified", while the sword on the ground does.

The client is now aware of the type and subtype of objects in the player's inventory or the "below" window.



Please let me know of any other changes which should be made prior to the protocol update.
-- _people_ :)

petarkiller

« Reply #1 on: 20, January 2024, 07:56:01 »
Can something be done about decorations that players can walk on so that looting is easier? Maybe a toggle in settings to hide decorations that players can step on in the looting window.

When I am using storms I'll try to make sure everything dies where there are no decorations. This isn't something that players can ignore as when they loot they have to move away from object first to be able to loot the corpse.

I know that players use the same window to examine decorations to see exactly what they are so it might be bad to have them removed completely but it makes looting worse, so that's why I think a setting could be a good solution.
Worth noting that a lot of decorations are self-explanatory like branch that don't need to be shown at all.

Dolfo

« Reply #2 on: 20, January 2024, 08:24:18 »
Yeah this decoration also annoying me.
Currently we have this priorities.
Layer 0 - System
...
Layer 3 - pickable items
Layer 4 - non pickable items, like chests, chairs, ...
Layer 5 - behind scene deco, like trees, ...
Layer 6 - monsters / players
Layer 7 - magic effects

I reworked client in order, how it shows this in below window (where we pickup items)
So new client shows first your or other players storms, then other players chars same spot, then the behind deco, then the fixed items, then pickable items. I was thinking about twisting layer 3 with layer 5 for a final clean.

So dropping items or also the corspes would have higher priority. But this change is mainly a server change only, client is ready to show the items from highest layer to lowest layer. So this change could be also in 0.11.1. I would go there first for a compatible loader, where loader twist layer 3 and 5. We need also look for some hard code generated items, like when we trigger traps, they change their layers from 0 to 3. With such a loader "hack", we could check if this layer 3/5 twist looks good. If so a final step would be to change this in arc files and maps.

Alternate we can go in client and resort the view there, but we had this in past and that produced a lot of spaghetti, destroying next/prev mechanics, made new corpses last, lead to the container pickup bug. So I personally would prefer to define the layers clean.

Don't believe the shit, you hear in mainstream. Believe your own body. Your body is speaking always the true to you. But you need to understand your body. Hear to your body, not to your ego. And when body is calling to you: "Hey something is wrong!" find the reason(s) for that. Man in White don't go for that, they don't want to heal you. They want earn money and sell you medicine, you should take rest of your life. You are not the patient, you are their customer. Never forget this!

Dolfo

« Reply #3 on: 20, January 2024, 10:11:51 »
Please let me know of any other changes which should be made prior to the protocol update.
When jumping to 0.11.x perhaps it's interesting to build in a kind of multi-command like you said in past? Thinking of my waypoint logic, I still miss a good way to use sentience for non npc's. Would be cool, if we can extend sentience to non npc's. We could build dialogs not only for the waypoint idea, also looking on a bank sign, starting a script showing riches players using sentience mechanics, or showing rankings players reached level 110. I have thought about this some time. Perhaps a kind of multicommand sending command and extensionally text?

Like:
first apply on an item can start a script and also sentience (what is currently working fine), with our apply event but without extra message transfer.
Using this multicommand, client can send apply with extensionally msg, so script can interact with players like we can talk with npc's.
For my waypoints I mainly hacked the say event and used the magic ear to react at least on first sentience interaction, but this is ugly. That's reason I stopped there.
So it's mainly thinking first, how we could implemented such a kind of multicommand. Apply cmd always need the object count and server reaction on sentience need an alternate command to talk to do this. Perhaps we "only" go in apply logics for this.
like
mcmd "apply waypoint", "iluma"
mcmd "apply sign", "richest players"
dunno if we need multicommands to combine 2 commands, i think its mainly, we miss to send additionally informations behind our commands.

Whole help system could be wrapped in one script.

Additionally a command like "get all" could also be wrapped this way, like
mcmd "?M_GET" "all"
for example, for sure this syntax is only example, could be also something like
|?M_GET|all
could also lead to "apply all" for a kind of wardrobe logic to switch gear or full gear switches from containers with one command
going to drop all could also be possible, but could lead to dangerous situations.

So this is only to show, where we can go, when we design a good multi/extended command, mainly wrapping the command in a pack with an extensional string behind?
« Last Edit: 20, January 2024, 13:29:08 by Dolfo »
Don't believe the shit, you hear in mainstream. Believe your own body. Your body is speaking always the true to you. But you need to understand your body. Hear to your body, not to your ego. And when body is calling to you: "Hey something is wrong!" find the reason(s) for that. Man in White don't go for that, they don't want to heal you. They want earn money and sell you medicine, you should take rest of your life. You are not the patient, you are their customer. Never forget this!

_people_

« Reply #4 on: 02, February 2024, 06:29:06 »
I've just finished with some bug fixes with targeting, and accidentally turned it into a rather large overhaul of targeting.

The server now sends the client the HP of all monsters and friendly NPC's if their HP is less than full. It can also send additional flags, which I plan on using for monster modifiers. So if the player has been hit by a mob with extra fire damage or probes such a mob, they will be able to see an icon indicating so. They would also see defensive modifiers the mob has after hitting the mob or probing it.



As for filtering the below window per petar's request: I can adapt the F_IDENTIFIED and F_UNIDENTIFIED change noted above to simply not show items which are neither identified nor important. I believe most scenery objects are unidentified by default.


Next I will work on a stub for Dolfo's request, and that'll probably be it for 0.11.0.
-- _people_ :)

Tags:
 

Related Topics

  Subject / Started by Replies Last post
16 Replies
7022 Views
Last post 14, March 2005, 22:42:05
by MarcK
1 Replies
770 Views
Last post 20, October 2005, 02:03:46
by Unislash
6 Replies
2963 Views
Last post 11, September 2006, 21:33:47
by swords_kid
9 Replies
1790 Views
Last post 27, May 2007, 12:49:44
by spyke
3 Replies
633 Views
Last post 17, June 2010, 10:04:38
by Nobbit