Can't change Universe Attributes

[phillipwgardner]

Hi there @ChrisMiuchiz, thanks for this project!

I've got things running so far, but have run into a small problem. It seems so far I have been unable to figure out how to set properly my start world, welcome message and to allow tourist entry. When I try to apply these attributes in the browser they don't take.

Also out of curiosity, would this work with the 5.2 browser or later? I've tried with 5.2 but have been unsuccessful thus far.

Thanks so much! Everything else seems to be working.
@KimRosebush

[phillipwgardner]

Perhaps I stumbled upon something not implemented fully yet. xD

MariaDB [aworld_universe]> select * from awu_attrib;
+----+---------+-------+
| ID | Changed | Value |
+----+---------+-------+
| 17 |       0 | Y     |
|  6 |       0 | Y     |
+----+---------+-------+
2 rows in set (0.000 sec)

MariaDB [aworld_universe]>

[coremaze]

While, yes, the Universe server is unfinished, and I don't have much time to dedicate to this project at the moment, this is a feature I'd expect to work. Keep in mind that AW 4.1 is the primary target, and maybe check the logs for your database to see if the Universe is issuing queries it doesn't like?

With regard to 5.2, I don't know if it would work with that or not. I have never used that version.

[phillipwgardner]

While, yes, the Universe server is unfinished, and I don't have much time to dedicate to this project at the moment, this is a feature I'd expect to work. Keep in mind that AW 4.1 is the primary target, and maybe check the logs for your database to see if the Universe is issuing queries it doesn't like?

With regard to 5.2, I don't know if it would work with that or not. I have never used that version.

Thanks for the reply! I'll continue to tinker with it and see if I can't get it to work (thanks for the DB tip). As for 5.2 I am not sure either, a future prospect perhaps.

[phillipwgardner]

While, yes, the Universe server is unfinished, and I don't have much time to dedicate to this project at the moment, this is a feature I'd expect to work. Keep in mind that AW 4.1 is the primary target, and maybe check the logs for your database to see if the Universe is issuing queries it doesn't like?
With regard to 5.2, I don't know if it would work with that or not. I have never used that version.

Thanks for the reply! I'll continue to tinker with it and see if I can't get it to work (thanks for the DB tip). As for 5.2 I am not sure either, a future prospect perhaps.

Just a heads up, I turned on MySQL logging and I did not see any queries whatsoever towards the server when applying universe settings.

I see these two messages when logging into the universe, though I think it's unrelated to the attribs:

[2023-01-14T06:15:54Z INFO  universe::universe_server] Unhandled packet AWPacket { vars: [Int(SessionID, 1), Int(LoginID, 1), Int(AttributeCitizenChanges, 1491729810)], opcode: Unknown, header_0: 0, header_1: 2 }
[2023-01-14T06:15:55Z INFO  universe::universe_server] Unhandled packet AWPacket { vars: [Int(SessionID, 1), Int(LoginID, 1), Int(AttributeCitizenChanges, 1491729810)], opcode: Unknown, header_0: 0, header_1: 2 }

As a workaround I manually inserted the values into the database, the values are being read correctly.

[coremaze]

For what it's worth, the code path that should handle this is as follows:

in universe/src/universe_server.rs:handle_packet:

            PacketType::AttributeChange => packet_handler::attribute_change(
                client,
                packet,
                &self.database,
                &self.client_manager,
            ),

in universe/src/packet_handler/player/attribute.rs:attribute_change:

    for var in packet.get_vars().iter() {
        if let AWPacketVar::String(id, val) = var {
            log::info!("Client {} setting {:?} to {:?}", client.addr.ip(), id, val);
            set_attribute(*id, val, database).ok();
        }
    }

in universe/src/attributes.rs:set_attribute

    database.attrib_set(id, value).map_err(|_| ())?;

and universe/src/database/attrib.rs:Database::attrib_set is as follows:

    fn attrib_set(&self, attribute_id: Attribute, value: &str) -> Result<(), ReasonCode> {
        let mut conn = self.conn().map_err(|_| ReasonCode::DatabaseError)?;

        // Check if attribute is already in the database
        let rows: Vec<Row> = conn
            .exec(
                r"SELECT * FROM awu_attrib WHERE ID=:id",
                params! {
                    "id" => attribute_id as u32,
                },
            )
            .map_err(|_| ReasonCode::DatabaseError)?;

        if rows.is_empty() {
            // Add the attribute if it is not already existent
            conn.exec_drop(
                r"INSERT INTO awu_attrib (ID, Value) VALUES(:id, :value);",
                params! {
                    "value" => value,
                    "id" => attribute_id as u32,
                },
            )
            .map_err(|_| ReasonCode::DatabaseError)?;
            log::debug!("Set attribute {attribute_id:?} to {value}");
        } else {
            // Try to update the attribute if it is already present
            conn.exec_drop(
                r"UPDATE awu_attrib SET Value=:value, Changed=NOT Changed WHERE ID=:id;",
                params! {
                    "value" => value,
                    "id" => attribute_id as u32,
                },
            )
            .map_err(|_| ReasonCode::DatabaseError)?;
            log::debug!("Updated attribute {attribute_id:?} to {value}");
        }

        Ok(())
    }

I notice that set_attribute(*id, val, database).ok(); effectively discards any errors (because the most obvious reason would be if the database goes down, in which case I don't really know what the best response is), but perhaps it would've been better for me to at least print a warning about it. I don't know where the path to this code is going wrong in your case, but you may be able to use the logged text (or add your own lines to log) to deduce it. You can run universe with --log-level trace to get all logged information, or with --help to learn all the options for that flag.

[coremaze]

This is caused by a bug in the ActiveWorlds client that makes it send the server a malformed packet. The AW protocol has a concept of data types, such as integer, float and string. One of these data types is simply a raw buffer of data, i.e., a byte array. Core ActiveWorlds code forgets to set the data type field if the buffer is empty or greater than 4095 bytes. The resulting malformed packet was rejected by my server as a result. This event occurs, at least, when the object password for CAVs/PAVs is empty. 25d373f stops this from failing. While I haven't fully tested attributes yet, this catastrophic failure should be fixed.

[Elnor147]

Hi @coremaze I am @phillipwgardner, I lost access to my account unfortunately.

Thanks for the response on that, I will report back on the catastrophic failure I believe it was indeed fixed as last I checked.

[Elnor147]

Hi @coremaze I am @phillipwgardner, I lost access to my account unfortunately.

Thanks for the response on that, I will report back on the catastrophic failure I believe it was indeed fixed as last I checked.

This is indeed fixed. You should be able to resolve this issue. 👍