Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

485 Friendly


About isomorphism

  • Rank
    Experienced Member
  • Birthday 11/06/1997

Contact Methods

  • Discord

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

3,130 profile views
  1. I knew this day would come. I've started roleplaying on MTA when I was about 11 or 12 years old. You couldn't even call it "roleplaying" as my sole objective was to acquire stats and just go around DMing. I barely knew any English at all and got myself banned a ton of times. That was Valhalla, then it became Root, and then Owl was formed. I caught up later on. Over the 10 years of me roleplaying on MTA on and off, I learned so many things. To make my portrayal more accurate, I learned things from real life in fields that I probably would have never heard of. I learned the English language by talking to strangers on MTA. Seriously. I met a lot of very interesting people in here. To become a part of a gaming community online and have the opportunity to socialize with people from many different backgrounds and learn a lot of things about different cultures, get movie/TV/music recommendations, was a really valuable experience to me. The death of MTA as a popular RPing platform was inevitable. I really hope that V carries the spirit forward and grows even more than MTA ever had. I want to thank everyone in here for the great memories and time well spent. Farewell, MTA!
  2. Holy shit, Pepet0x. I remember roleplaying with you ca. 2011 in vG's LSPD. I'm Berk. Whoa, dude. Online communities.
  3. doğum günün kutlu olsun kardeşim

  4. That's why I gave the runcode example though. It does not need to restart a resource to run your code afaik.
  5. Pretty much, I'd say it's still closer to scripting objects at TTS. I do agree that this has a Garry's Mod feeling, though.
  6. Script Suggestion What would be the name of the script(s)?- In-game scriptable items What kind of script(s) are you suggesting?- Items What is the suggestion?- You should probably not read this script suggestion. In Tabletop Simulator, almost every object in the game can be scripted. This allows you to give them unique behavior when players interact with the object. This is great when you’re designing a board game that requires some background operations/calculations that need to be scripted. Last time I checked, the OwlGaming script featured over 300 different items, each of them hardcoded in the script to accomplish one (and only one) behavior. The only exceptions are the generic items which you can give a specific name, a specific description and a specific GTA model. They have been very useful. Admins can spawn a generic item whenever required and you can work it into your roleplay. (Right-click menu of each object has the scripting option, where the script will be attached to the object’s unique GUID) (You can write code in-game and execute it) What I’m suggesting here is a system that allows the members of the Scripting Team to create a special type of generic item: “Scriptable Item”. The behavior of this item can be modified in-game. Similar to the runcode resource (which allows scripters to run Lua code without having to push code to the live server), an interface will pop up, allowing the scripters to write and edit the code of every item. Every scriptable item inherits one (and exactly one) item class. The base item classes are: Button, Collection, Consumable, Converter, Destroyer, Dispenser, Non-Interactive, Proximity Sensor, and Redeemable. Let me describe each item class. Button: Buttons are objects that you can only use when the object is in your inventory, and you can use it as many times as you like (unlike Consumables, they do not get consumed). Example in psuedo-code: -- Dog whistle Function onPressed() PlaySound3D(“dog_whistle.mp3”) End Collection: Collections are containers for smaller objects. For instance, a six-pack of beers is a collection of beers, and you may withdraw a beer only when the Collection is in your inventory. Contrast this to Dispensers, where you can withdraw items only when it is placed in the world. Example in psuedo-code: -- Beer Function onPressed() GiveItem(player, this.Items.pop()) PrintAction(player.name + “ takes a bottle of beer from the pack of beers.”) End Consumable: Consumables are items that disappear after using. All food items belong to this category. Example in psuedo-code: -- Surprise cocktail Function onConsumed() Print(player, “The cocktail tastes very bad.”) SetHP(player, player.HP - 5) Destroy() End Converter: Converters take a set of items as input and produces another set of items, effectively consuming all of its input. This is sort of like a crafting mechanism, but unlike those in RPG games, Converters can perform only one kind of conversion. Example in psuedo-code: -- Turns cocaine into crack Function convert() If input == GlobalItems.Consumable.Cocaine then TakeItem(player, input) GiveItem(player, GlobalItems.Consumable.Crack) end End Destroyer: This item class serves only one purpose. It destroys a given item, and that’s it. Depending on the item which was destroyed, it might call another function or raise an event. Example in psuedo-code: -- Cafeteria pass Function destroy() If item == GlobalItems.Generic.CafeteriaPass then openGate() End destroyItem(item) End Dispenser: When this object is placed in the world, players can click on it to obtain items. Infinite dispensers are possible. Example in psuedo-code: -- Soda dispenser Function onUsed() TakeMoney(player, 1) GiveItem(player, GlobalItems.Consumable.Soda) End Non-Interactive: These are the items that perform a specific task on an interval. Privelged users may stop the item and it will stop operating. Example in psuedo-code: -- Annoyance, this function is called every five minutes Function performTask() PrintEnvironment(“The squeaking sound of a window is heard.”) End Proximity Sensor: These items change their behavior when a certain amount of players enter the area. When a player re-enters the area, a function may be called to notify them. Very useful for a variety of RP scenarios. Example in psuedo-code: Function onPlayerEnterProximity() Print(player, “You notice a strange smell in the room.) If this.NearbyPlayers >= 5 Then PrintNearby(“Everyone around you seems to be smelling something weird.”) End End Redeemable: These items are placeholders for other items that the player has not, due to OOC circumstances, acquired completely. Best used when a player technically has the item in posession, but giving the actual item may have undesirable side effects. The object may be redeemed at a specific time interval. Note: I’ve created psuedo-redeemable objects when I was an admin. I was supervising a robbery where the robber asked the cashier to fill his backpack with the money. Now, since the robbery was technically successful, I should have given him the money he had stolen, but there is no way to distinguish between the “money in the wallet” and the “money in the backpack”. So before he left, I gave him a voucher - he could /report to redeem the money when he got away from the police. See, if he were to be arrested, the police would look into the backpack and see the amount of damages caused to the victims. This would not have been possible without the unredeemed money in the inventory. Example in psuedo-code: Function redeem() If “2016-12-17 00:00:00” >= currentTime >= “2016-12-16 22:00:00” then GiveItem(player, this.Item) Destroy() end End Possibly there could be many more item classes that would make sense to be in the base classes. If you have such an idea, let me know. Scripted items are created by following the object-oriented paradigm. For instance, a scripter creates an item based on the Destroyer class: “Trash”. It literally does nothing, other than destroying the item thrown at it. Admins are able to create copies of this item and make minor modifications (only change the parameters, such as the name, the capacity, etc.) and players can obtain these items through the in-game report system. A huge amount of effort is required to build a library of scripted items written in this OO-fashion. But it comes with the benefit of allowing people to customize their items to the fullest. What are the advantages?- This is the be-all, end-all solution to all script suggestions relating to items. All requested items may be implemented by creating an item which inherits one of the item classes listed above. What are the disadvantages?- Lordy, I dunno. This probably means the entirety of the item-system has to be rewritten. Even then, a lot of scripting will have to be done to reimplement the currently existing items. The maintenance of the code would be extremely difficult. Do you have any resources to support our scripters in making said suggestion?- We can talk about that later. How would you go about implementing this idea?- rm -rf item-system mkdir items; cd items vim classes.lua First, we're required to write all the item classes. Every other item basically overloads the base functions in the base class. The actual in-game mechanics though, will need a lot of work...
  7. Thanks. I'm the author of the script, and it's currently my only contribution to the server resources. In /togattach, there is a list on top of the script with the IDs of the objects for guns (prop guns, if you like). There could simply be another list with the "allowed" objects. And a subroutine to go through the inventory of a player to see if a generic item with that exact objectID exists. If so, it would be listed among the options like any other gun. The problem here is that I didn't write the specific parts of the script abstract enough to allow for other types of objects to be added. Each weapon, for instance, has a weaponID and a slot (e.g. all pistols are grouped in one slot). This information is retained in the XML file that saves the attachment detail. The way I see this could be made to work, is to add a number of extra slots (-1, -2, -3...) for generic items, as many as needed (if you have 3 slots, for example, you can put on a hat, sunglasses, and a burger in your hand, but nothing else). And instead of the weaponID, the objectID itself would be recorded. In short, this is technically not very difficult to implement. Maybe I'll take a stab at it in the future.
  8. A police scanner item should be given to individuals with Senior+ approval. This item, while turned on, reads all transmissions on the LSCSD's departmental radio frequency. (In real life, basically anyone can get ahold of this, really). The inter-departmental radio should be available to every member of a news faction. It's not like the cops are sharing government secrets over the radio. Hell, most of it (realistically) should be dispatch telling what the cops should be doing. If you're doing sensitive work, use encrypted radio channels. That's what police do in real life - they have tactical/operational channels where they can securely transmit whatever they want to. For a small price, you would be giving players a lot more exposure. And if you think that you will constantly have to deal with the news factions arrivng at the scene before you do, well, deal with it. Because that does happen in real life. If you think that criminals will somehow get ahold of a scanner and flee before you even have a chance to respond a call, deal with it. Police operations security is not an issue which news factions/criminals should be dealing with, it's an issue which the police needs to address. Anyone who claims that this suggestion is unrealistic knows nothing about how news are made. It's such a disappointment that staff members like JameZ and GentleFart are stating unsupported opinions, lacking proper argumentation. If you have never been in a news faction, you do not know the difficulty of actually finding news. LSCSD always seem to flatter themselves by creating non-inclusive roleplay, i.e. the type of roleplay where the average civilian cannot get into. After the cops are done with some situation, they slap each other in the ass and head back to whatever they're doing. It's almost like nobody in the department cares for the news anyway. @TheNeonGuy you're bringing a knife to a gunfight. This is a serious thread touching on a serious matter. It's not the place for reaction gifs. Don't post to this thread unless you are willing to read what the others are saying.
  9. No. I would advise you to learn from roleplayers of other genres and learn to do more with less.
  10. Your signature triggers me. So much agony and misery in one picture.

  11. I support this. People do not know how to realistically roleplay a rich person.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use, Privacy Policy and follow our Guidelines.