Hi there! You are currently browsing as a guest. Why not create an account? Then you get less ads, can thank creators, post feedback, keep a list of your favourites, and more!
Quick Reply
Search this Thread
Inventor
#26 Old 3rd Dec 2014 at 8:33 AM
That's very useful info.

Little OT (forgive me chazyra):
Let's say we have two variables, "a" and "b" of type/class Sim. Is it safe to use this check
Code:
if (a == b) ...

or it's better to use SimDescriptionID even in this case (with no saved data involved)?
That never gave me any problem in game, but I don't use many features - like traveling
for example, so maybe has not been tested properly.

Back in topic, this solution (cooldown) seems a good choice to me and if you like it you
can even extend the duration of the "subscription" period so you can use gym/dojo
equipments for a full/half day paying only once (maybe instead of using sim minutes
wen can use sim days, I can't check if that's an option right now but I expect it is).

Of course there are at least dozens of other solutions and workarounds (even a
complete overhauling of how the training dummy works) but maybe it's better to
keep it as simple as possible.
Advertisement
Instructor
#27 Old 3rd Dec 2014 at 9:45 AM
If you use PersistableStatic to store SimDescriptionIds, that should be ok to retrieve a saved value. But the main problem is that, you should think of a way to clear Sims from the list when they finish the action, so that the list doesn't stack up and up, causing game lag.
Field Researcher
#28 Old 3rd Dec 2014 at 9:52 AM
Quote: Originally posted by Arsil
That's very useful info.

Little OT (forgive me chazyra):
Let's say we have two variables, "a" and "b" of type/class Sim. Is it safe to use this check
Code:
if (a == b) ...

or it's better to use SimDescriptionID even in this case (with no saved data involved)?
That never gave me any problem in game, but I don't use many features - like traveling
for example, so maybe has not been tested properly.


I don't see EA overriding its equality operator, so it compares if A and B are the very same object. That works just fine, cos if one of the two is "null" or invalid you will still have the desired result. Just make sure at least one of them is not "null", cos if they both are then you're going to get a match (and probably something went wrong in the code). The same goes for SimDescription classes. It really depends on the context anyway, because if one of them is out of town (boarding school, free vacation, etc...) or traveling, the Sim class will be destroyed and the SimDescription class compressed and packed, also known as MiniSimDescription. That's where the SimDescriptionID comes useful, because you can do the following :

Code:
IMiniSimDescription IMSD = SimDescription.Find(/*put SimDescriptionID value here*/);
if (IMSD == null) { MiniSimDescription miniSimDescription = MiniSimDescription.Find(/*put SimDescriptionID value here*/); /*...check for null and work with miniSimDescription here...*/ }
else { SimDescription simDescription = IMSD as SimDescription; Sim actor = simDescription.CreatedSim;  /*...check for null and work with actor here...*/ }


IMiniSimDescription is an interface implemented both by SimDescription and MiniSimDescription classes, which is why I'm using that one. In the end you will have either a MiniSimDescription or a Sim class. If the former results in "null" then that sim does not exist anymore in your game, if it doesn't then that sim exists but it's in another world. If the latter results in "null" then that sim exists but it's currently out of town (I'm unsure whether ghosts or dead sims will result in "null" too, I never had to verify it, but you can check that eventually on the SimDescription variable), if it doesn't then you're good to go.

But again, you should go through this trouble only in a special context where you need to make sure you have a valid sim to work with, otherwise a simple comparison between the two classes is more than enough

Nothing's real. Nothing's unreal either.
The frontier between true and untrue is a shady fuzzy line.
Destiny, or maybe the long flight's time-span, shall decide the issue.
Inventor
#29 Old 3rd Dec 2014 at 2:28 PM
That will take a bit to digest, I'm not much experienced with OOP. Thanks again.

chazyra don't feel overwhelmed by all this information, it's all extra stuff, what you
need to do is relatively simple. You are catching up quickly but if you need help just ask.
Test Subject
Original Poster
#30 Old 3rd Dec 2014 at 3:40 PM
ok at first: thank you guys so much again!!! without you i think i had already given up...
it's really very very much information for me, my programming experience is not sooooo big, and this is my first try to modifying a mod. I thought it would be easier a little bit. I'm proud 'cos the main thing: the payment, is functionally, but it seems like there is still a long way to get this fully working.
I think to check how much time is past since the last payment before trigger a new payment is a very good idea, but i don't know how i can implement this in my code. Can you give me a step by step instruction what i've to do?

btw: english is not my native language, i'm sure you realize that :D
Field Researcher
#31 Old 3rd Dec 2014 at 4:27 PM
I think the best route to accomplish what you want would be to replace the Sims3.Gameplay.Objects.HobbiesSkills.TrainingDummy.Train interaction and override the method that loops to check for the time passed and charge money. Using a listener or an alarm would be too overwhelming imho, plus there are tutorials here on how to replace interactions and it would be easier for you. Then we can help by telling you what to change in the interaction

Nothing's real. Nothing's unreal either.
The frontier between true and untrue is a shady fuzzy line.
Destiny, or maybe the long flight's time-span, shall decide the issue.
Test Subject
Original Poster
#32 Old 3rd Dec 2014 at 4:48 PM Last edited by chazyra : 3rd Dec 2014 at 5:23 PM.
thank you JunJayMdM, but when i override the interaction, then sims must pay wherever they train with the dummy, correct? this is not what i want
the payment per se is already functionally in my code (based on ani_'s mod), the problem is that sims have to pay about every second right now


edit:
my code looks like this at the moment -->

Listener
Code:
private static void World_OnWorldLoadFinishedEventHandler(object sender, EventArgs e)
		{
EventTracker.AddListener(EventTypeId.kUsedTrainingDummy, new ProcessEventDelegate(WorkOutCostsMoney.TrainingDummy));
		}


Action
Code:
protected static ListenerAction TrainingDummy(Event e)
		{
			Sim sim = e.Actor as Sim;
			if (sim != null && sim.LotCurrent != null && sim.LotCurrent.CommercialLotSubType == CommercialLotSubType.kEP1_Dojo)
			{
				CommonMethods.PayForWorkOut(sim, sim.LotCurrent, CommonMethods.ReturnFee(CommonMethods.WorkOut.TrainingDummy));
			}
			return ListenerAction.Keep;
		}


for that matter i only need a query in the if-loop how much time is passed since the last pay, right?
Inventor
#33 Old 3rd Dec 2014 at 6:01 PM
Quote:
btw: english is not my native language

Same here, don't worry.
Quote:
i only need a query in the if-loop how much time is passed since the last pay, right?

Correct. But JunJayMdM was suggesting to use another system: to change directly how the training
dummy behave so it will send a signal only when sims finish training and not every second. It's your call.
Field Researcher
#34 Old 3rd Dec 2014 at 6:07 PM
That's why I suggested overriding the interaction, because I checked the code and it loops constantly every second, that's why you get that. In addition no event is sent when the Sim is finished training, so you will have no clue when to stop the Listener, unless you also check if the Sim is running that interaction. It's not very practical but if you feel more comfortable following this path then what you need is :

1) A PersistableStatic Dictionary<ulong, float> to place in that class, where you store the ID of the Sims and the time the interaction started
2) An alarm that fires every time you want the payment to be issued, which will check if the SIm is still running the interaction, in which case it will get charged
3) A Cleanup function that removes old entries from the Dictionary

This plan has negative aspects though :

1) The Sim might get charged way after the interaction ended, which is confusing
2) If you make them pay in advance to avoid the above problem, then if after the last payment your Sim only trains for 2 minutes, it's not fair

If it's for personal use then it doesn't matter, but if you're planning on making the changes available to everyone then this plan should be dropped. If that's ok with you we can proceed, whatever you decide

Nothing's real. Nothing's unreal either.
The frontier between true and untrue is a shady fuzzy line.
Destiny, or maybe the long flight's time-span, shall decide the issue.
Inventor
#35 Old 3rd Dec 2014 at 6:18 PM
Hey JunJayMdM, I don't understand, correct me if I'm wrong.

Quote: Originally posted by JunJayMdM
so you will have no clue when to stop the Listener


There's no need to stop it. Checking if there's already a recent entry in the Dictionary will tell
if he has to pay again or not. Sure, it's not very efficient, but those events are fired only if a sim is
using the dummy anyway, so handling the listener code wont be much of a burden for the system.

Quote:
2) An alarm that fires every time you want the payment to be issued, which will check if the SIm is still running the interaction, in which case it will get charged


Why are you suggesting to use an Alarm? Sims will pay as soon as the first event regarding them is fired.
What's the matter? The anticipated payment not being realistic?

I agree that overriding/replacing the dummy interactions is probably the best solution though.
Test Subject
Original Poster
#36 Old 3rd Dec 2014 at 6:18 PM
ah ok i thought JunJay means to create the payment statement in the interaction, i was wrong... you're idea is to trigger a new event like "kStoppedWorkingOut" for the Training Dummy, so "kStoppedTrainingDummy" that at the moment dosen't exists. That's amazing!!! How can we do that?
Field Researcher
#37 Old 3rd Dec 2014 at 7:10 PM
Quote: Originally posted by Arsil
There's no need to stop it. Checking if there's already a recent entry in the Dictionary will tell
if he has to pay again or not. Sure, it's not very efficient, but those events are fired only if a sim is
using the dummy anyway, so handling the listener code wont be much of a burden for the system.


What I meant is "stop the Listener from listening on that specific Sim", because we don't know when the interaction ends, unless we check if the interaction is still running. Of course the Listener must be kept or it will work only once XD

Quote: Originally posted by Arsil
Why are you suggesting to use an Alarm? Sims will pay as soon as the first event regarding them is fired.
What's the matter? The anticipated payment not being realistic?

I agree that overriding/replacing the dummy interactions is probably the best solution though.


I suggested an Alarm because I thought I read somewhere that the OP wanted a payment to be issued every hour. If it's just a symbolic payment at the start, then we need a List<ulong> and not a Dictionary and the whole thing becomes much simpler and makes more sense.

Is this what we need to be working on?

Nothing's real. Nothing's unreal either.
The frontier between true and untrue is a shady fuzzy line.
Destiny, or maybe the long flight's time-span, shall decide the issue.
Test Subject
Original Poster
#38 Old 3rd Dec 2014 at 7:23 PM
at the beginning i want that sims have to pay when they're stop to use the training dummy, but there is no event like kStoppedTrainingDummy. Because of that i thougt the only way to get paid is let the sims pay per hour, but when it's possible to modify the interaction itself so that it's triggered a "new" event when sims stopping the training, then we can choose this solution.
Inventor
#39 Old 3rd Dec 2014 at 7:39 PM
I'm puzzled by your first answer, but I feel like I'm only slowing down things
and stealing the focus from what chazyra wants. Thank you again, it has been
fun and instructive to talk with you about this stuff. If you are so kind to help her
then I'll go back to work on my mod, but I'll keep on eye here because I'm sure
I have something to learn. EDIT: I must have missed the post where she talked
about paying every hour, my bad then. This thread is almost a chatroom!
Field Researcher
#40 Old 3rd Dec 2014 at 8:02 PM
Quote: Originally posted by Arsil
I'm puzzled by your first answer, but I feel like I'm only slowing down things
and stealing the focus from what chazyra wants. Thank you again, it has been
fun and instructive to talk with you about this stuff. If you are so kind to help her
then I'll go back to work on my mod, but I'll keep on eye here because I'm sure
I have something to learn. EDIT: I must have missed the post where she talked
about paying every hour, my bad then. This thread is almost a chatroom!


Don't worry about it, it seems we're all non-native English speakers here, so it's easy to misunderstand or fail to explain something properly. As long as we get chazyra to succeed

Quote: Originally posted by chazyra
at the beginning i want that sims have to pay when they're stop to use the training dummy, but there is no event like kStoppedTrainingDummy. Because of that i thougt the only way to get paid is let the sims pay per hour, but when it's possible to modify the interaction itself so that it's triggered a "new" event when sims stopping the training, then we can choose this solution.


That's exactly what replacing the interaction will give us. We can decide when the Sim pays, if we charge per minute or per hour, we may also stop the interaction if the Sim can't afford it anymore and send a notification that states that. We will have much more freedom to do whatever we want in there

In the following post I will post the first step for replacing interactions.

Nothing's real. Nothing's unreal either.
The frontier between true and untrue is a shady fuzzy line.
Destiny, or maybe the long flight's time-span, shall decide the issue.
Field Researcher
#41 Old 3rd Dec 2014 at 8:41 PM Last edited by JunJayMdM : 4th Dec 2014 at 7:32 AM.
#STEP 1 : Create the class for the interaction

Create a new class file in the project, you can name it PracticeEx.cs. Then :

Code:
	public sealed class PracticeEx : TrainingDummy.Practice
	{
		public sealed class DefinitionEx : TrainingDummy.Practice.Definition
		{
			// We need to create a new instance here for PracticeEx so this one will be called instead of the original
			public override InteractionInstance CreateInstance(ref InteractionInstanceParameters parameters)
			{
				InteractionInstance interactionInstance = new PracticeEx();
				interactionInstance.Init(ref parameters);
				return interactionInstance;
			}
		}
	}


Now, save the class and let's forget about it for now and go back to the WorkOutCostsMoney class. Put it back to its original state (i.e. as Ani made it originally, drop all the changes you made) and then proceed with the following additions (they're in bold) :

Code:
// Here we will add a delegate that will do the replacement for the interaction
static WorkOutCostsMoney()
{
        LoadSaveManager.ObjectGroupsPreLoad += new ObjectGroupsPreLoadHandler(WorkOutCostsMoney.OnPreLoad);
	World.OnWorldLoadFinishedEventHandler += new EventHandler(WorkOutCostsMoney.World_OnWorldLoadFinishedEventHandler);
}

private static void OnPreload()
{
        // This is the actual replacement. The EA interaction is now no more!
	TrainingDummy.Practice.Singleton = new PracticeEx.DefinitionEx();
}


That's it for now, just make these changes and try to compile. If you get errors from VS or whatever you're using, post them here. Now I'm off to bed, we will continue tomorrow

P.S. Do not try the mod yet, this is not complete, the interaction will not work cos now the ITUN is not pointing to it anymore and it will fail.


EDIT : I had a doubt now, is this the right class? If the right one is Practice and not Train, just use that one instead, I'm a bit sleepy now so I'm confused. The changes are the same anyway, except you change the name of the class and the one you're replacing.

EDIT 2 : Ok I fixed the code I posted, in case you didn't catch it, I changed to the right class

Nothing's real. Nothing's unreal either.
The frontier between true and untrue is a shady fuzzy line.
Destiny, or maybe the long flight's time-span, shall decide the issue.
Field Researcher
#42 Old 4th Dec 2014 at 4:08 PM
Let me know when you're done with Step 1, so we can move on to Step 2 which will end the replacement phase, then finally Step 3 where we add the new functionality to the interaction.

Nothing's real. Nothing's unreal either.
The frontier between true and untrue is a shady fuzzy line.
Destiny, or maybe the long flight's time-span, shall decide the issue.
Inventor
#43 Old 4th Dec 2014 at 4:25 PM Last edited by Arsil : 4th Dec 2014 at 4:44 PM.
Yeah, I'm a dirty liar, I said I would have kept my mouth shut but I just can't.

Ehm... do you mind explaining "almost every line" of that code?
I'm asking this for chazyra's sake of course, I understand it perfectly...

Jokes aside, can you please explain a bit these 2 things:
- the overriding of the CreationInstance (what exactly is going on there)
- LoadSaveManager.ObjectGroupsPreLoad += new ObjectGroupsPreLoadHandler(WorkOutCostsMoney.OnPreLoad); (total darkness)
Field Researcher
#44 Old 4th Dec 2014 at 5:29 PM Last edited by JunJayMdM : 4th Dec 2014 at 5:51 PM.
Quote: Originally posted by Arsil
Yeah, I'm a dirty liar, I said I would have kept my mouth shut but I just can't.

Ehm... do you mind explaining "almost every line" of that code?
I'm asking this for chazyra's sake of course, I understand it perfectly...

Jokes aside, can you please explain a bit these 2 things:
- the overriding of the CreationInstance (what exactly is going on there)
- LoadSaveManager.ObjectGroupsPreLoad += new ObjectGroupsPreLoadHandler(WorkOutCostsMoney.OnPreLoad); (total darkness)




EDIT : Also added a link to inheritance, if needed

EDIT 2 : I enclosed everything in a spoiler so chazyra won't get confused by all this clutter

Nothing's real. Nothing's unreal either.
The frontier between true and untrue is a shady fuzzy line.
Destiny, or maybe the long flight's time-span, shall decide the issue.
Inventor
#45 Old 4th Dec 2014 at 10:25 PM
Field Researcher
#46 Old 5th Dec 2014 at 7:24 AM
Quote: Originally posted by Arsil



Nothing's real. Nothing's unreal either.
The frontier between true and untrue is a shady fuzzy line.
Destiny, or maybe the long flight's time-span, shall decide the issue.
Inventor
#47 Old 5th Dec 2014 at 10:57 AM Last edited by Arsil : 5th Dec 2014 at 3:29 PM.
Field Researcher
#48 Old 5th Dec 2014 at 1:44 PM
Quote: Originally posted by Arsil


Maybe some moderator can help us moving our posts to another thread, if they find it necessary, meanwhile let's keep "spoiling" XD

Nothing's real. Nothing's unreal either.
The frontier between true and untrue is a shady fuzzy line.
Destiny, or maybe the long flight's time-span, shall decide the issue.
Page 2 of 2
Back to top